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

[Johannes Berg <johannes@sipsolutions.net>]

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