netdev - Re: [PATCH net-next v2 1/2] dt-bindings: net: adin: add property for link-status pin polarity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b3c4301b-afae-44fb-86c5-94f23d363c0a@solid-run.com>
Date: Sat, 20 Apr 2024 16:56:19 +0000
From: Josua Mayer <josua@...id-run.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Michael Hennerich <michael.hennerich@...log.com>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rob Herring
	<robh@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>, Alexandru Tachici
	<alexandru.tachici@...log.com>, Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>, Jon Nettleton <jon@...id-run.com>,
	Yazan Shhady <yazan.shhady@...id-run.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2 1/2] dt-bindings: net: adin: add property for
 link-status pin polarity

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.