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