[PATCH v1 0/1] rfkill: expose hardware-only block state

[PATCH v1 0/1] rfkill: expose hardware-only block state

[Sai Teja Aluvala]

This series adds a public rfkill helper for querying the hardware-only
block state.

The existing rfkill_blocked() helper reports the effective state, which
is set when either hardware or software rfkill is active. Callers that
need to distinguish those cases currently cannot do so because struct
rfkill is opaque.

Add rfkill_hard_blocked(), protected by the rfkill lock and available
with a CONFIG_RFKILL-disabled stub. The helper is used by a follow-up
Bluetooth debugfs test hook, which must verify hardware rfkill state
without confusing it with a software block.

The follow-up Bluetooth series will be submitted separately to
bluetooth-next and depends on this patch.

The patch has been prepared against wireless-next/main.

Changes in v1:
  - Initial version.

Sai Teja Aluvala (1):
  rfkill: add rfkill_hard_blocked() helper

 include/linux/rfkill.h | 12 ++++++++++++
 net/rfkill/core.c      | 13 +++++++++++++
 2 files changed, 25 insertions(+)


base-commit: 21b4248bfa0f410fa22202fc2c82f4808d672cda
-- 
2.53.0

[PATCH v1 1/1] rfkill: add rfkill_hard_blocked() helper

[Sai Teja Aluvala]

rfkill_blocked() reports the effective block state, i.e. set when the
device is either hardware or software blocked, and rfkill_soft_blocked()
reports only the software state. There is no equivalent accessor for
the hardware-only state, and struct rfkill is opaque to drivers, so a
caller that needs to distinguish a hardware block from a software block
cannot do so.

Add rfkill_hard_blocked(), which reads RFKILL_BLOCK_HW under
rfkill->lock in the same way as rfkill_soft_blocked(), together with a
stub returning false when CONFIG_RFKILL is disabled.

The first user is the Bluetooth HCI debugfs force_hw_rfkill test hook,
which must report and compare against the hardware state only.

Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com>
---
 include/linux/rfkill.h | 12 ++++++++++++
 net/rfkill/core.c      | 13 +++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index deea02a034c3..9877ed4ea6ab 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -231,6 +231,13 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool hw);
  */
 bool rfkill_blocked(struct rfkill *rfkill);
 
+/**
+ * rfkill_hard_blocked - Query hardware block state
+ *
+ * @rfkill: rfkill struct
+ */
+bool rfkill_hard_blocked(struct rfkill *rfkill);
+
 /**
  * rfkill_soft_blocked - Query soft rfkill block state
  *
@@ -310,6 +317,11 @@ static inline bool rfkill_blocked(struct rfkill *rfkill)
 	return false;
 }
 
+static inline bool rfkill_hard_blocked(struct rfkill *rfkill)
+{
+	return false;
+}
+
 static inline bool rfkill_soft_blocked(struct rfkill *rfkill)
 {
 	return false;
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 9e143c4bfe6a..684139591e9d 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -979,6 +979,19 @@ bool rfkill_blocked(struct rfkill *rfkill)
 }
 EXPORT_SYMBOL(rfkill_blocked);
 
+bool rfkill_hard_blocked(struct rfkill *rfkill)
+{
+	unsigned long flags;
+	u32 state;
+
+	spin_lock_irqsave(&rfkill->lock, flags);
+	state = rfkill->state;
+	spin_unlock_irqrestore(&rfkill->lock, flags);
+
+	return !!(state & RFKILL_BLOCK_HW);
+}
+EXPORT_SYMBOL(rfkill_hard_blocked);
+
 bool rfkill_soft_blocked(struct rfkill *rfkill)
 {
 	unsigned long flags;
-- 
2.53.0

Re: [PATCH v1 1/1] rfkill: add rfkill_hard_blocked() helper

[Johannes Berg]

On Wed, 2026-09-30 at 13:12 +0530, Sai Teja Aluvala wrote:
> rfkill_blocked() reports the effective block state, i.e. set when the
> device is either hardware or software blocked, and rfkill_soft_blocked()
> reports only the software state. There is no equivalent accessor for
> the hardware-only state, and struct rfkill is opaque to drivers, so a
> caller that needs to distinguish a hardware block from a software block
> cannot do so.
> 
> Add rfkill_hard_blocked(), which reads RFKILL_BLOCK_HW under
> rfkill->lock in the same way as rfkill_soft_blocked(), together with a
> stub returning false when CONFIG_RFKILL is disabled.
> 
> The first user is the Bluetooth HCI debugfs force_hw_rfkill test hook,
> which must report and compare against the hardware state only.

Probably should CC Bluetooth list (done now) for a change that's prep
for BT infrastructure.

The user is:

https://lore.kernel.org/linux-bluetooth/af7525184b7c910d8f5bc313805ac31293711c19.1790752799.git.aluvala.sai.teja@intel.com/

which does two things with it:

 1) refuse debugfs write when it's already hw-blocked by some real hw

 2) show the rfkill's hw-blocked status in debugfs read

The tool that's intended to use the debugfs file is this:

https://lore.kernel.org/linux-bluetooth/66971d6f85d714f2728b29fada7136d5a2fbb3c2.1790752800.git.aluvala.sai.teja@intel.com/

It implicitly uses the write part by failing if the write fails, and
explicitly uses the read part by checking that it applied.

The write part could be easily checked in the tool from userspace via
rfkill sysfs (it already accesses that), and the validation against
sysfs already happens on the read as well there, so IMHO neither is
necessary - the tool could check sysfs before starting the test and
abort if it's already hw blocked before, and the debugfs read isn't
necessary at all since it reflects the exact same value as the rfkill
sysfs read, so validating both is useless.


However, if BT folks disagree with my assessment then feel free to just
merge this patch along with the user.

johannes