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]
Date: Sat, 9 Mar 2024 16:35:21 +0100
From: Javier Carrasco <javier.carrasco.cruz@...il.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: trivial-devices with vdd-supply: true

On 09.03.24 16:00, Krzysztof Kozlowski wrote:
> On 09/03/2024 13:22, Javier Carrasco wrote:
>> Hi,
>>
>> I am trying to figure out the current policy to add trivial devices
>> (I2C/SPI devices with at most one interrupt) to trivial-devices.yaml or
>> include a dedicated file.
>>
>> Apparently, bindings for the same sort of devices where "vdd-supply" is
>> provided require their own file, and I wonder why there is no
>> "vdd/supplied/whatever-trivial-devices.yaml".
>>
>> Instead, files with trivial bindings + "vdd-supply: true" are added on a
>> regular basis. That property is not saying anything specific about the
> 
> Anything needing supply is not really trivial anymore, because we want
> the supply name to match more or less what's in datasheet.
> 

That seems to be the case for devices with multiple supplies, but for a
single supply "vdd" seems to be preferred over any name in the datasheet
like "vcc", probably due to a copy+paste effect?

> Solution is sometimes to allow generic "power-supply", like panels have,
> AFAIR. If you have new device, just add new binding for it or add the
> device to existing binding with very, very similar device.
> 
> See also:
> https://lore.kernel.org/all/YUz+psAILnF5L5GH@robh.at.kernel.org/
> https://lore.kernel.org/all/20210921131804.GC1864238@roeck-us.net/
> https://lore.kernel.org/all/CAL_JsqKJgvK8g+zbzLCBxnKbgAioBcdHWNAvqe4Z9BzkNMwPpA@mail.gmail.com/
> 
> 
>> device beyond that it needs a supply, which is very common. Is that
>> intended and no more generic bindings are desired?
>>
>> On the other hand, trivial-devices.yaml includes several devices that do
>> require a single supply (e.g. several sensors), but it is not explicitly
>> documented. Did the requirement of providing vdd-supply arise after
>> those devices were added to trivial-devices? I think that some devices
> 
> You would need to analyze the history... requirement of providing
> supplies was kind of always. Just like trivial devices were.
> 
>> that were added to trivial-devices in the last months could have also
>> had a vdd-supply property, so I am not sure about the rules to choose
>> one way or another.
> 
> https://lore.kernel.org/all/20230505204810.GB3506915-robh@kernel.org/
> 
> Best regards,
> Krzysztof
> 

Thank you for the references. In that case a device in
trivial-devices.yaml is better than no bindings at all, but if a supply
is required (which is often the case), dedicated bindings or addition to
existing bindings from a very, very similar device is better.

Best regards,
Javier Carrasco

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ