linux-kernel - Re: [PATCH net-next v2 1/2] dt-bindings: net: adin: add property for link-status pin polarity

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: <1fe2dce3-972e-420e-b4e1-f07e15b6b35f@solid-run.com>
Date: Sun, 21 Apr 2024 09:07:25 +0000
From: Josua Mayer <josua@...id-run.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Michael Hennerich <michael.hennerich@...log.com>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rob Herring
	<robh@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>, Alexandru Tachici
	<alexandru.tachici@...log.com>, Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>, Jon Nettleton <jon@...id-run.com>,
	Yazan Shhady <yazan.shhady@...id-run.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2 1/2] dt-bindings: net: adin: add property for
 link-status pin polarity


Am 20.04.24 um 19:09 schrieb Andrew Lunn:
>> Main reason for having a vendor-specific and non-led property
>> is that this pin is not a led.
> So you are not driving an LED with its? What are you using it for?

The unit I am currently working on connects an LED, yes.

Therefore I agree with you that it could be described adequately
by an led node with active-low property.

I merely don't like the idea that this makes no sense for the other
possible pin functions.
Once somebody uses this pin for different use-case, they will need
to solve it again.

>> This kind of configuration is much more like pinctrl than led.
>  
> So what is the pinctrl way of describing this? You should not be
> inventing something new if there is an existing mechanism to describe
> it. We want consistency, not 42 different ways of doing one thing.
I am mostly familiar with the
#define PIN_FUNCTION magic-numbers
pins = <PIN_FUNCTION more-magic-numbers>;

But on Marvell platforms there is:
marvell,pins =  "mpp1";
marvell,function = "gpio";

I also found more generic???:
Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml
Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml
which have output-high/output-low, function, pin.

Interestingly LED_0 supports some non-led functions, too:
- collision detection
- carrier sense
- tx/rx start
- tx error
so polarity is also relevant to non-led usage of LED_0 pin.

Might be I am not seeing the big picture how this fits a generic structure.