Messages in this thread | ![/](/images/icornerl.gif) | | From | Josua Mayer <> | Subject | Re: [PATCH net-next v2 1/2] dt-bindings: net: adin: add property for link-status pin polarity | Date | Sat, 20 Apr 2024 16:56:19 +0000 |
| |
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.
| ![\](/images/icornerr.gif) |