linux-kernel - Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <v4hxei4t7n6ebvw6heoccei2t3mskq7uo7zejv6dyvvq5fr5sv@xzpsiic5x7a4>
Date: Mon, 22 Dec 2025 17:15:05 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Hans de Goede <hansg@...nel.org>
Cc: Bryan O'Donoghue <bod.linux@...w.ie>, jerome.debretagne@...il.com, 
	Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Johannes Berg <johannes@...solutions.net>, 
	Lorenzo Bianconi <lorenzo@...nel.org>, Maximilian Luz <luzmaximilian@...il.com>, 
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, Jeff Johnson <jjohnson@...nel.org>, 
	linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-wireless@...r.kernel.org, platform-driver-x86@...r.kernel.org, ath12k@...ts.infradead.org, 
	Jeff Johnson <jeff.johnson@....qualcomm.com>, Dale Whinham <daleyo@...il.com>
Subject: Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add
 disable-rfkill property

On Mon, Dec 22, 2025 at 11:23:18AM +0100, Hans de Goede wrote:
> +Cc Mani
> 
> Hi,
> 
> On 20-Dec-25 07:04, Bryan O'Donoghue wrote:
> > On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
> >> From: Jérôme de Bretagne <jerome.debretagne@...il.com>
> >>
> >> For some devices, Wi-Fi is entirely hard blocked by default making
> >> the Wi-Fi radio unusable, except if rfkill is disabled as expected
> >> on those models.
> >>
> >> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
> >> disabling specific features based on ACPI bitflag") added a way to
> >> support features set via ACPI, including the DISABLE_RFKILL bit.
> >>
> >> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
> >> equivalent for devices described by a Devicetree instead of ACPI.
> >>
> >> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@...il.com>
> >> ---
> >>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
> >>   1 file changed, 6 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
> >> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >> @@ -29,6 +29,12 @@ properties:
> >>         different 5 GHz subbands. Using them incorrectly could not work or
> >>         decrease performance noticeably
> >>
> >> +  disable-rfkill:
> >> +    type: boolean
> >> +    description:
> >> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
> >> +      blocked by default otherwise
> >> +
> >>   additionalProperties: true
> >>
> >>   examples:
> >>
> >> -- 
> >> 2.47.3
> >>
> >>
> >>
> > 
> > Is this really a hardware description though ?
> 
> I would say yes it is. The wifi chip has an rfkill input pin and
> things will be broken when that pin is hardwired to a fixed value
> rather then being actually connected to a GPIO from say
> the embedded controller.
> 

IIUC, even if the M.2 slot has the W_DISABLE1# signal routed from the host,
the device won't make use of it as there is no physical connection. So you want
the WLAN driver to change the state through SW?

> So I think that we would need here is not a disable-rfkill property
> but some way to indicate in the DT-node that the rfkill input pin
> is not connected and thus should be ignored.
> 
> This (the rfkill input pin being not-connected) IMHO very much
> is hw-description.
> 

Though we can argue this way, I would prefer to handle it in the driver. For
example, with my M.2 series, we will end up describing the M.2 slot:

	connector {
		compatible = "pcie-m2-e-connector";
		w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
		...
		ports {
			...
			endpoint@0 {
				reg = <0>;
				remote-endpoint = <&pcie4_port0_ep>;
			};
		};
	};

Then if we use a DT property to convey the RFKILL pin state of the device, we
would need to describe the endpoint device in DT and hardcode the state:

	&pcie4_port0 {
		...
		port {
			pcie4_port0_ep: endpoint {
				remote-endpoint = <&m2_e_pcie_ep>;
				disable-rfkill;
			};
		};
	};

So this will essentially make the M.2 device non-swappable unless you change the
DT since you've how hardcoded the device property in the binding. This is
something I try to avoid to make the M.2 slot really swappable.

For this reason, I would prefer to handle the RFKILL state in the WLAN driver
using the device specific compatible. This will be problematic only if multiple
cards of the same Device ID have different RFKILL state and the devices are not
distinguishable even with sub IDs.

FWIW, ACPI support added with commit c6a7c0b09d5f, suffers from the same
limitation.

- Mani

-- 
மணிவண்ணன் சதாசிவம்