linux-kernel - Re: [PATCH net-next 1/4] dt-bindings: leds: add 'active-high' property

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: <6d3hvesqhslk7jaszo44orbaqabl7go6duzpu4beye44sa6lpn@b3c56bp6x3ce>
Date: Mon, 7 Oct 2024 08:38:27 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Andrew Lunn <andrew@...n.ch>, 
	Heiner Kallweit <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Xu Liang <lxu@...linear.com>, 
	Christian Marangi <ansuelsmth@...il.com>, Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, 
	Robert Marko <robimarko@...il.com>, Russell King <rmk+kernel@...linux.org.uk>, 
	Abhishek Chauhan <quic_abchauha@...cinc.com>, Jacek Anaszewski <jacek.anaszewski@...il.com>, 
	linux-leds@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/4] dt-bindings: leds: add 'active-high'
 property

On Sun, Oct 06, 2024 at 02:04:35PM +0100, Daniel Golle wrote:
> On Sun, Oct 06, 2024 at 02:44:44PM +0200, Krzysztof Kozlowski wrote:
> > On Sat, Oct 05, 2024 at 05:24:20PM +0100, Daniel Golle wrote:
> > > Other than described in commit c94d1783136 ("dt-bindings: net: phy: Make
> > 
> > Please run scripts/checkpatch.pl and fix reported warnings. Then please
> > run 'scripts/checkpatch.pl --strict' and (probably) fix more warnings.
> > Some warnings can be ignored, especially from --strict run, but the code
> > here looks like it needs a fix. Feel free to get in touch if the warning
> > is not clear.
> 
> Sorry about that, I was expecting '--fix-inplace' to take care of that
> but it didn't and I didn't notice. I will address that in a follow-up
> patch.
> 
> > 
> > > LED active-low property common") the absence of the 'active-low'
> > > property means not to touch the polarity settings which are inherited
> > > from reset defaults, the bootloader or bootstrap configuration.
> > > Hence, in order to override a LED pin being active-high in case of the
> > > default, bootloader or bootstrap setting being active-low an additional
> > > property 'active-high' is required.
> > > Document that property and make it mutually exclusive to the existing
> > > 'active-low' property.
> > > 
> > > Signed-off-by: Daniel Golle <daniel@...rotopia.org>
> > > ---
> > >  Documentation/devicetree/bindings/leds/common.yaml | 14 ++++++++++++++
> > >  1 file changed, 14 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
> > > index bf9a101e4d42..7c3cd7b7412e 100644
> > > --- a/Documentation/devicetree/bindings/leds/common.yaml
> > > +++ b/Documentation/devicetree/bindings/leds/common.yaml
> > > @@ -202,6 +202,12 @@ properties:
> > >        #trigger-source-cells property in the source node.
> > >      $ref: /schemas/types.yaml#/definitions/phandle-array
> > >  
> > > +  active-high:
> > > +    type: boolean
> > > +    description:
> > > +      Makes LED active high. To turn the LED ON, line needs to be
> > > +      set to high voltage instead of low.
> > 
> > And then we are going to get 2 more bools for other variants...
> 
> I don't see a problem combining 'active-high' or 'active-low' with
> 'inactive-high-impedance' which would be the equivalent of
> 'active-low-tristate' and 'active-high-tristate'.

Oh, I missed that we have already two bool properties. I thought that
there is only active-high.

> 
> > 
> > I think this should be just string enum, see marvell,marvell10g.yaml
> 
> I found the vendor-specific 'marvell,polarity' property in
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231214201442.660447-5-tobias@waldekranz.com/
> 
> However, I can't find that file in any Linux tree.
> 
> Looking at the suggested patch on patchwork, I got a few questions on
> how to deal with the situation as of today:
> 
> So should the existing support for the 'active-low' and
> 'inactive-high-impedance' properties be replaced by that string enum?
> Or should the string property be interpreted in addition to the
> bools defined in leds/common.yaml?
> 
> Should the string property be defined for each PHY or should we move
> it into a common file?
> 
> If so, should that common file also be leds/common.yaml or should we
> create a new file only for PHY LEDs instead?
> 
> Sorry for being confused, I don't mind going down what ever path to have
> LED polarity configurable properly in DT.

Let's ignore my idea.

However I still wonder whether your choice for lack of properties is
appropriate. Lack of properties as "bootloader default" means it can
change. Why would anyone prefer to keep bootloader default? The wiring
is fixed - it's never "we design PCB based on bootloader, so with new
bootloader we will change PCB"?

And if you meant bootstrapping through some hardwired configuration,
then again it is known and defined.

Best regards,
Krzysztof