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

[Josua Mayer <josua@solid-run.com>]

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!