linux-kernel - Re: [PATCH v2 1/1] power: supply: gpio-charger: Support to disable charger

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] [day] [month] [year] [list]

Message-ID: <dd4a1d34-4266-43de-9a41-4b7b247d3226@kernel.org>
Date: Fri, 3 Jan 2025 10:08:51 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Stefan Raufhake <raufhakestefan@...il.com>,
 sebastian.reichel@...labora.com
Cc: sre@...nel.org, linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, s.raufhake@...khoff.com,
 s.dirkwinkel@...khoff.com, s.raufhake@...khoff.de, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org
Subject: Re: [PATCH v2 1/1] power: supply: gpio-charger: Support to disable
 charger

On 03/01/2025 09:18, Stefan Raufhake wrote:
>>> to be bad. Please suggest better wording :)
> 
> Which part of the documentation is being referred to: the binding, the commit message, or another section? 
> Once clarified, I can suggest a better wording in this part of the documentation.
> 
>>> P.S.: binding and driver should be send in separate patches.
>>
> 
> In the next version, I will split the binding and driver into two separate patches.
> 
>> Yeah, still all my comments should be addressed.
>>
> 
> Krzysztof, in the bindings for 'gpio-charger.yaml' (Documentation/devicetree/bindings/power/supply/gpio-charger.yaml), 
> is the property name 'enable-gpios' suitable for you, or should I rename it? 
> If a rename is needed, which name makes the most sense to you for this function?

enable-gpios is correct, assuming these is a different GPIO than one
used for "charge-current-limit-gpios" for value of 0, as pointed out by
Sebastian.

Existing example DTS in the binding clearly defines A.11 as
enable-gpios. Maybe that's just coincidence, but I wonder how it would
work for three gpios?

Anyway the example should be then fixed to reflect real intention, e.g.
add enable-gpios and change "<0 0x02>; // 0 mA => GPIO A.11 high" into
some value like 300 mA.

Best regards,
Krzysztof