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.
