netdev - Re: [PATCH 1/1] dt-bindings: net: rfkill-gpio: document reset-gpios

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 for Android: free password hash cracker in your pocket

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

Date: Tue, 28 May 2024 14:20:09 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Chukun Pan <amadeus@....edu.cn>
Cc: conor+dt@...nel.org, devicetree@...r.kernel.org,
 johannes@...solutions.net, krzk+dt@...nel.org, netdev@...r.kernel.org,
 p.zabel@...gutronix.de, robh@...nel.org
Subject: Re: [PATCH 1/1] dt-bindings: net: rfkill-gpio: document reset-gpios

On 28/05/2024 14:00, Chukun Pan wrote:
>> Please focus instead on why.
>>
>> https://lore.kernel.org/all/d096d9ea-39db-4a15-9c4d-ae228db970cb@linaro.org/
> 
> Thanks for the link, I missed it.
> But for the 4/5G modules, it usually has multiple gpio connections
> and cannot be controlled through just one gpio. For example, when
> rfkill unblock, if the module is not reset again, it will not work.

Please send a patch with proper hardware description used as rationale.
Your argument - driver has it - is not correct for the bindings.
Bindings do not describe drivers.

Read the old v1 (which had reset GPIO) and the arguments presented
there. Include your counter-arguments to that old v1 arguments in your
patch.
> In this case, can rfkill-gpio be allowed to use reset-gpios property?



Best regards,
Krzysztof