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

[Krzysztof Kozlowski]

On 12/10/2026 20:56, Jérôme de Bretagne wrote:
> Le lun. 12 oct. 2026 à 18:53, Krzysztof Kozlowski <krzk at kernel.org> a écrit :
>>
>> On 12/10/2026 18:38, Konrad Dybcio wrote:
>>> On 12/20/25 10:12 AM, Krzysztof Kozlowski wrote:
>>>> On Sat, Dec 20, 2025 at 06:04:00AM +0000, 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 at gmail.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.
>>>
>>> [...]
>>>
>>>>> Is this really a hardware description though ?
>>>>>
>>>>> Its really more of a logical/functional description. It tells the runtime
>>>>> what todo, not what the hardware is.
>>>>>
>>>>> You could also have a list of quirks in ath12k for this or have a user-space
>>>>> utility look for the appropriate platform device string name and disable
>>>>> rfkill.
>>>>>
>>>>> I think this logic belongs in drivers/net/wireless/ath/ath12k/ triggering on
>>>>> a compat string.
>>>>
>>>> This is good point. Either this could be deducible from the compatible
>>>> or this should actually describe the hardware and whatever is there
>>>> wired/configured, not what OS should do.
>>>
>>> Sorry for digging up an old thread. The board-compatible change is now
>>
>> I don't get why exactly the board-compatible option was chosen, except
>> of course finding workaround which did not need digging out the root of
>> the problem. I suggested the compatible of this device or proper
>> hardware description.
> 
> Could someone give an example of what a "proper hardware description"
> would be in this case, to move the needle a bit? It is quite abstract for me.

qcom,wl-disable-pin-grounded
qcom,firmware-needs-hw-reset
qcom,firmware-reset-bug
qcom,mismatched-disable-polarity

etc.


Best regards,
Krzysztof