netdev - Re: [PATCH net-next v2 1/2] dt-bindings: net: adin: document a phy link status inversion property

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <82884b6a-33a1-dd8f-a537-771d99c513ee@sord.co.jp>
Date: Fri, 2 Jun 2023 11:46:16 +0900
From: Atsushi Nemoto <atsushi.nemoto@...d.co.jp>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, devicetree@...r.kernel.org,
 Michael Hennerich <michael.hennerich@...log.com>,
 Alexandru Tachici <alexandru.tachici@...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+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Horatiu Vultur <horatiu.vultur@...rochip.com>
Subject: Re: [PATCH net-next v2 1/2] dt-bindings: net: adin: document a phy
 link status inversion property

On 2023/06/01 23:45, Andrew Lunn wrote:
> We are now getting close to having all the pieces of the puzzle to
> decide if this is the right or wrong way to do this.
> 
> This appears to be the 'Vendor Crap' driver. You are patching mainline
> here, so it is the mainline PRU driver we care about:
> 
> https://lore.kernel.org/netdev/20230424053233.2338782-1-danishanwar@ti.com/T/
> 
> Looking at the device tree binding, it uses the standard phy-handle,
> phy-mode properties. There is also emac_adjust_link() which is used by
> phylib to tell the MAC driver the link is down.
> 
> So you now need to convince me this change is actually needed in
> mainline.

Looking for purpose of MII_RXLINK signal, it seems like just for
EtherCAT's "enhanced link detection" feature.
refer: https://software-dl.ti.com/processor-industrial-sw/esd/docs/indsw/EtherCAT_Slave/PRU_ICSS_EtherCAT_firmware_API_guide.html#pru-icss-mdio-host-side-apis

So maybe standard linux driver can ignore this.

Then, what really needed is controlling just an LED, i.e. could be
done using the LED subsystem as your advice.

I will try it if I use this combination of devices in the future.

Please drop this patch series for now.

---
Atsushi Nemoto