kernel/linux.git/include/linux/rfkill.h, branch v6.12.80

wifi: rfkill: Correct parameter type for rfkill_set_hw_state_reason()

2024-08-27T08:28:55+00:00

Change type of parameter @reason to enum rfkill_hard_block_reasons for API rfkill_set_hw_state_reason() according to its comments, and all kernel callers have invoked the API with enum type actually. Signed-off-by: Zijun Hu Link: https://patch.msgid.link/20240811-rfkill_fix-v2-1-9050760336f4@quicinc.com Signed-off-by: Johannes Berg

rfkill: define rfill_soft_blocked() if !RFKILL

2022-03-01T09:59:13+00:00

If CONFIG_RFKILL is not set, the Intel WiFi driver will not build the iw_mvm driver part due to the missing rfill_soft_blocked() call. Adding a inline declaration of rfill_soft_blocked() if CONFIG_RFKILL=n fixes the following error: drivers/net/wireless/intel/iwlwifi/mvm/mvm.h: In function 'iwl_mvm_mei_set_sw_rfkill_state': drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:2215:38: error: implicit declaration of function 'rfkill_soft_blocked'; did you mean 'rfkill_blocked'? [-Werror=implicit-function-declaration] 2215 | mvm->hw_registered ? rfkill_soft_blocked(mvm->hw->wiphy->rfkill) : false; | ^~~~~~~~~~~~~~~~~~~ | rfkill_blocked Signed-off-by: Ben Dooks Reported-by: Neill Whillans Fixes: 5bc9a9dd7535 ("rfkill: allow to get the software rfkill state") Link: https://lore.kernel.org/r/20220218093858.1245677-1-ben.dooks@codethink.co.uk Signed-off-by: Johannes Berg

rfkill: allow to get the software rfkill state

2021-12-20T10:02:38+00:00

iwlwifi needs to be able to differentiate between the software rfkill state and the hardware rfkill state. The reason for this is that iwlwifi needs to notify any change in the software rfkill state even when it doesn't own the device (which means even when the hardware rfkill is asserted). In order to be able to know the software rfkill when the host does not own the device, iwlwifi needs to be able to ask the state of the software rfkill ignoring the state of the hardware rfkill. Signed-off-by: Emmanuel Grumbach Link: https://lore.kernel.org/r/20211219195124.125689-1-emmanuel.grumbach@intel.com Signed-off-by: Johannes Berg

rfkill: add a reason to the HW rfkill state

2020-12-11T11:47:17+00:00

The WLAN device may exist yet not be usable. This can happen when the WLAN device is controllable by both the host and some platform internal component. We need some arbritration that is vendor specific, but when the device is not available for the host, we need to reflect this state towards the user space. Add a reason field to the rfkill object (and event) so that userspace can know why the device is in rfkill: because some other platform component currently owns the device, or because the actual hw rfkill signal is asserted. Capable userspace can now determine the reason for the rfkill and possibly do some negotiation on a side band channel using a proprietary protocol to gain ownership on the device in case the device is owned by some other component. When the host gains ownership on the device, the kernel can remove the RFKILL_HARD_BLOCK_NOT_OWNER reason and the hw rfkill state will be off. Then, the userspace can bring the device up and start normal operation. The rfkill_event structure is enlarged to include the additional byte, it is now 9 bytes long. Old user space will ask to read only 8 bytes so that the kernel can know not to feed them with more data. When the user space writes 8 bytes, new kernels will just read what is present in the file descriptor. This new byte is read only from the userspace standpoint anyway. If a new user space uses an old kernel, it'll ask to read 9 bytes but will get only 8, and it'll know that it didn't get the new state. When it'll write 9 bytes, the kernel will again ignore this new byte which is read only from the userspace standpoint. Signed-off-by: Emmanuel Grumbach Link: https://lore.kernel.org/r/20201104134641.28816-1-emmanuel.grumbach@intel.com Signed-off-by: Johannes Berg

rfkill: Fixes and cleanup of kernel-doc in the header file

2018-06-15T11:37:07+00:00

Fixes kerneldoc parameter names to match implementation, rfkill_set_hw_state(), rfkill_set_sw_state(). Fix description of rfkill_resume_polling(). Fix typos in documentation of rfkill_find_type(). Consistently start kerneldoc description with uppercase letter. Signed-off-by: Peter Meerwald-Stadler Signed-off-by: Johannes Berg

net: rfkill: add rfkill_find_type function

2016-02-24T08:12:45+00:00

Helper for finding the type based on name. Useful if the type needs to be determined based on device property. Signed-off-by: Heikki Krogerus [modify rfkill_types array and BUILD_BUG_ON to not cause errors] Signed-off-by: Johannes Berg

rfkill: disentangle polling pause and suspend

2016-02-24T08:04:22+00:00

When suspended while polling is paused, polling will erroneously resume at resume time. Fix this by tracking pause and suspend in separate state variable and adding the necessary checks. Clarify the documentation on this as well. Signed-off-by: Johannes Berg

UAPI: (Scripted) Disintegrate include/linux

2012-10-13T09:46:48+00:00

Signed-off-by: David Howells Acked-by: Arnd Bergmann Acked-by: Thomas Gleixner Acked-by: Michael Kerrisk Acked-by: Paul E. McKenney Acked-by: Dave Jones

Revert "rfkill: remove dead code"

2012-08-21T18:50:25+00:00

This reverts commit 2e48928d8a0f38c1b5c81eb3f1294de8a6382c68. Those functions are needed and should not be removed, or there is no way to set the rfkill led trigger name. Signed-off-by: AceLan Kao Signed-off-by: Johannes Berg

device.h: audit and cleanup users in main include dir

2012-03-16T14:38:24+00:00

The header includes a lot of stuff, and it in turn gets a lot of use just for the basic "struct device" which appears so often. Clean up the users as follows: 1) For those headers only needing "struct device" as a pointer in fcn args, replace the include with exactly that. 2) For headers not really using anything from device.h, simply delete the include altogether. 3) For headers relying on getting device.h implicitly before being included themselves, now explicitly include device.h 4) For files in which doing #1 or #2 uncovers an implicit dependency on some other header, fix by explicitly adding the required header(s). Any C files that were implicitly relying on device.h to be present have already been dealt with in advance. Total removals from #1 and #2: 51. Total additions coming from #3: 9. Total other implicit dependencies from #4: 7. As of 3.3-rc1, there were 110, so a net removal of 42 gives about a 38% reduction in device.h presence in include/* Signed-off-by: Paul Gortmaker