0001 ===============================
0002 rfkill - RF kill switch support
0003 ===============================
0004
0005
0006 .. contents::
0007 :depth: 2
0008
0009 Introduction
0010 ============
0011
0012 The rfkill subsystem provides a generic interface for disabling any radio
0013 transmitter in the system. When a transmitter is blocked, it shall not
0014 radiate any power.
0015
0016 The subsystem also provides the ability to react on button presses and
0017 disable all transmitters of a certain type (or all). This is intended for
0018 situations where transmitters need to be turned off, for example on
0019 aircraft.
0020
0021 The rfkill subsystem has a concept of "hard" and "soft" block, which
0022 differ little in their meaning (block == transmitters off) but rather in
0023 whether they can be changed or not:
0024
0025 - hard block
0026 read-only radio block that cannot be overridden by software
0027
0028 - soft block
0029 writable radio block (need not be readable) that is set by
0030 the system software.
0031
0032 The rfkill subsystem has two parameters, rfkill.default_state and
0033 rfkill.master_switch_mode, which are documented in
0034 admin-guide/kernel-parameters.rst.
0035
0036
0037 Implementation details
0038 ======================
0039
0040 The rfkill subsystem is composed of three main components:
0041
0042 * the rfkill core,
0043 * the deprecated rfkill-input module (an input layer handler, being
0044 replaced by userspace policy code) and
0045 * the rfkill drivers.
0046
0047 The rfkill core provides API for kernel drivers to register their radio
0048 transmitter with the kernel, methods for turning it on and off, and letting
0049 the system know about hardware-disabled states that may be implemented on
0050 the device.
0051
0052 The rfkill core code also notifies userspace of state changes, and provides
0053 ways for userspace to query the current states. See the "Userspace support"
0054 section below.
0055
0056 When the device is hard-blocked (either by a call to rfkill_set_hw_state()
0057 or from query_hw_block), set_block() will be invoked for additional software
0058 block, but drivers can ignore the method call since they can use the return
0059 value of the function rfkill_set_hw_state() to sync the software state
0060 instead of keeping track of calls to set_block(). In fact, drivers should
0061 use the return value of rfkill_set_hw_state() unless the hardware actually
0062 keeps track of soft and hard block separately.
0063
0064
0065 Kernel API
0066 ==========
0067
0068 Drivers for radio transmitters normally implement an rfkill driver.
0069
0070 Platform drivers might implement input devices if the rfkill button is just
0071 that, a button. If that button influences the hardware then you need to
0072 implement an rfkill driver instead. This also applies if the platform provides
0073 a way to turn on/off the transmitter(s).
0074
0075 For some platforms, it is possible that the hardware state changes during
0076 suspend/hibernation, in which case it will be necessary to update the rfkill
0077 core with the current state at resume time.
0078
0079 To create an rfkill driver, driver's Kconfig needs to have::
0080
0081 depends on RFKILL || !RFKILL
0082
0083 to ensure the driver cannot be built-in when rfkill is modular. The !RFKILL
0084 case allows the driver to be built when rfkill is not configured, in which
0085 case all rfkill API can still be used but will be provided by static inlines
0086 which compile to almost nothing.
0087
0088 Calling rfkill_set_hw_state() when a state change happens is required from
0089 rfkill drivers that control devices that can be hard-blocked unless they also
0090 assign the poll_hw_block() callback (then the rfkill core will poll the
0091 device). Don't do this unless you cannot get the event in any other way.
0092
0093 rfkill provides per-switch LED triggers, which can be used to drive LEDs
0094 according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
0095
0096
0097 Userspace support
0098 =================
0099
0100 The recommended userspace interface to use is /dev/rfkill, which is a misc
0101 character device that allows userspace to obtain and set the state of rfkill
0102 devices and sets of devices. It also notifies userspace about device addition
0103 and removal. The API is a simple read/write API that is defined in
0104 linux/rfkill.h, with one ioctl that allows turning off the deprecated input
0105 handler in the kernel for the transition period.
0106
0107 Except for the one ioctl, communication with the kernel is done via read()
0108 and write() of instances of 'struct rfkill_event'. In this structure, the
0109 soft and hard block are properly separated (unlike sysfs, see below) and
0110 userspace is able to get a consistent snapshot of all rfkill devices in the
0111 system. Also, it is possible to switch all rfkill drivers (or all drivers of
0112 a specified type) into a state which also updates the default state for
0113 hotplugged devices.
0114
0115 After an application opens /dev/rfkill, it can read the current state of all
0116 devices. Changes can be obtained by either polling the descriptor for
0117 hotplug or state change events or by listening for uevents emitted by the
0118 rfkill core framework.
0119
0120 Additionally, each rfkill device is registered in sysfs and emits uevents.
0121
0122 rfkill devices issue uevents (with an action of "change"), with the following
0123 environment variables set::
0124
0125 RFKILL_NAME
0126 RFKILL_STATE
0127 RFKILL_TYPE
0128
0129 The content of these variables corresponds to the "name", "state" and
0130 "type" sysfs files explained above.
0131
0132 For further details consult Documentation/ABI/stable/sysfs-class-rfkill.
