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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250228105148.5f465aa3@erd003.prtnl>
Date: Fri, 28 Feb 2025 10:51:48 +0100
From: David Jander <david@...tonic.nl>
To: Krzysztof Kozlowski <krzk@...nel.org>
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>, david@...tonic.nl
Subject: Re: [RFC PATCH 6/7] dt-bindings: motion: Add adi,tmc5240 bindings

On Fri, 28 Feb 2025 10:35:38 +0100
Krzysztof Kozlowski <krzk@...nel.org> wrote:

> On 28/02/2025 09:48, David Jander wrote:
> > 
> > Dear Krzysztof,
> > 
> > Thanks for reviewing...
> > 
> > On Fri, 28 Feb 2025 08:11:04 +0100
> > Krzysztof Kozlowski <krzk@...nel.org> wrote:
> >   
> >> On Thu, Feb 27, 2025 at 05:28:22PM +0100, David Jander wrote:
> >> [...]  
> >>> +
> >>> +  enable-supply:
> >>> +    description: Optional external enable supply to control SLEEPn pin. Can    
> >>
> >> That's odd. regular pins are not supplies. This must be named after
> >> physical supplies. There is vdd18, vcc, vcp but nothing about enable
> >> supply in datasheet.
> >>  
> >>> +      be shared between several controllers.    
> >>
> >> 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.
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?

> 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?

Best regards,

-- 
David Jander