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!
