Am 20.04.24 um 18:10 schrieb Andrew Lunn: >> + adi,link-st-polarity: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + LINK_ST pin polarity. >> + enum: >> + - 0 # active high >> + - 1 # active low >> + default: 0 >> + > How does this differ from: > > Documentation/devicetree/bindings/leds/common.yaml > > + active-low: > + type: boolean > + description: > + Makes LED active low. To turn the LED ON, line needs to be > + set to low voltage instead of high. > > > Why do we need a vendor property when there is a generic property? It differs in tree depth and naming. To use led binding we need to add a leds node with a led node inside, and decide on an index for this not-an-led pin. Sure, could be done but maybe should be documented somewhere as it is not intuitive. Main reason for having a vendor-specific and non-led property is that this pin is not a led, it is merely a signal. The PHY can be configured to provide via this signal either: - link-status - collision detection - carrier sense - tx packet start - rx packet start The purpose of the binding I propose is just polarity of this signal. A more complete binding would also allow selection from the above listed functions. This kind of configuration is much more like pinctrl than led.
