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

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

Message-ID: <b6f5ff0f-65e1-4b46-8f18-edf24ab3cea5@solid-run.com>
Date: Mon, 29 Apr 2024 09:54:29 +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 21.04.24 um 19:54 schrieb Andrew Lunn:
>> 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.
> There are not too many different uses of this pin. The data sheet
> indicates you can connect it to the MAC to indicate link. You might
> also be able to use it with an external PTP stamper, using the start
> of frame indication.
>
> I don't know of any bindings for such use case, but something will be
> needed to describe how the pin is connected to the other device. And
> at that point, the active low property could be used.
>
>>>> 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.
> So that is probably your alternative if you want to not use the LED
> binding.
I will consider using pincfg/-mux
>
>> 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.
> Collision detection is an LED usage, you just don't see it very often
> since half duplex is pretty unusual this century. Carrier sense is
> also similar age, from when Ethernet was CSMA/CD.
>
> Since they are not really used any more we don't have them in the LED
> framework, but i think we could implement them if somebody actually
> wanted them. My intention was to keep the LED framework KISS, since
> vendors tend to implement all sorts of odd LED blink reasons. But if
> nobody wants them, nobody has a good end user use case for them, why
> support them?
I see. So in fact most functions I wanted to enable muxing are LED functions,
leaving only some specifically for pinmux.

I believe pinmux is more correct, but there is overlap with led function.

I will  try to find some time for
1. describing both signals as LEDs, taking care of active-low
2. look into using pinmux (lower priority).
I think this would be more interesting to bigger phys with more muxable signals,
adin1300 is rather small.

Thank you for all the comments!