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] [day] [month] [year] [list]
Message-ID: <ZwKK4xMlqq3TyDyt@makrotopia.org>
Date: Sun, 6 Oct 2024 14:04:35 +0100
From: Daniel Golle <daniel@...rotopia.org>
To: Krzysztof Kozlowski <krzk@...nel.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: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'.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ