[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d1808d5-f166-488d-97b0-78fdd7d8ed0e@kernel.org>
Date: Tue, 14 Oct 2025 23:54:41 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Mark Brown <broonie@...nel.org>
Cc: Joan-Na-adi <joan.na.devcode@...il.com>,
Liam Girdwood <lgirdwood@...il.com>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, Joan Na <joan.na@...log.com>
Subject: Re: [PATCH v3 3/3] dt-bindings: regulator: Add MAX77675 regulator
binding
On 14/10/2025 15:11, Mark Brown wrote:
> On Tue, Oct 14, 2025 at 10:14:15AM +0200, Krzysztof Kozlowski wrote:
>> On 14/10/2025 07:31, Joan-Na-adi wrote:
>
>>> + maxim,en-mode:
>>> + description: |
>>> + Enable mode configuration.
>>> + "push-button" - Push button
>>> + "slide-switch" - Slide switch
>>> + "logic" - Logic mode
>
>> You just repeat the name in the description. Say something useful.
>
> Do you have concrete suggestions there? I can see dropping the
> descriptions entirely but otherwise I'm not sure there's much to
> usefully add.
Then just drop descriptions. I could imagine datasheet has something
more, but if not, then really no point to copy paste.
>
>>> + maxim,latency-mode:
>>> + description: |
>>> + Latency mode for voltage transition:
>>> + "high" - High latency (100μs)
>>> + "low" - Low latency (10μs)
>
>> So use values 100 or 10, and proper type (-us)
>
> Without knowing the device specifics at all I rather suspect those
> numbers are more ballparks than specifics.
That would be fine then. It should be reflected in commit msg, though.
>
>>> + maxim,dvs-slew-rate-mv-per-us:
>
>> ... like here.
>
>>> + description: |
>>> + Dynamic rising slew rate for output voltage transitions, in mV/μs.
>
>> Except you said mv/us, not us. Confusing.
>
> That's what I'd expect for a slew rate? It's the speed with which the
> device ramps between voltages during voltage transitions, mV/us is a
> perfectly normal unit for that.
Yeah, but the property unit suffix "-us" says that unit is us, so not
mv/us. I think we did not have that case so far, unless I missed such,
so either we ignore description mismatch from property-units or we
change it to something, like "-mvperus".
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml
The actual type - uint32 - is suitable, so maybe mismatch in description
for that unit type does not really matter. I'll defer this to @Rob.
Best regards,
Krzysztof
Powered by blists - more mailing lists