linux-kernel - Re: [RFC PATCH 6/7] dt-bindings: motion: Add adi,tmc5240 bindings

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

Message-ID: <7a123b5e-bcdd-484d-a65f-f013df458185@kernel.org>
Date: Fri, 28 Feb 2025 15:01:23 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: David Jander <david@...tonic.nl>
Cc: linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
 Jonathan Corbet <corbet@....net>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, devicetree@...r.kernel.org,
 linux-doc@...r.kernel.org, Nuno Sa <nuno.sa@...log.com>,
 Jonathan Cameron <jic23@...nel.org>, Oleksij Rempel <o.rempel@...gutronix.de>
Subject: Re: [RFC PATCH 6/7] dt-bindings: motion: Add adi,tmc5240 bindings

On 28/02/2025 10:51, David Jander wrote:

>>>>
>>>> Second sentence is both redundant and really not relevant to this
>>>> binding. It's not this binding which decides about sharing.  
>>>
>>> Good point. I think I should drop the whole property, since it is indeed
>>> irrelevant. If extra supplies need to be specified, they always can be, right?  
>>
>> You should specify all supplies now, because hardware should be fully
>> described by binding and DTS.
> 
> In the case of the hardware I use for testing all of this, there are several
> tmc5240 chips which have their "SLEEPN" pin tied together controlled by a
> single GPIO pin that needs to be pulled high before any of these chips can be
> talked to. The usual way I know of solving this is by specifying a common
> "virtual" supply of type "regulator-fixed" with an enable gpio.

No, that is not usual way. Representing pin as fake supply is hack and
not correct hardware description.

> But this isn't strictly a supply that has to do with this chip or driver, so I
> don't think it should be specified in the schema. I do need to use it in my
> particular case though. Is there a better way of doing this?

I speak about voltage and current supplies. These you must specify.

> 
>> What's more, the necessary supplies (according to datasheet) should be
>> required, not optional.
> 
> Do you mean that they should be in the binding definition as well? I.e. add
> all of Vs, Vdd1v8 and Vcc_io here?

Yes, all expected supplies must be in the binding.


Best regards,
Krzysztof