netdev - Re: drivers/of/of_mdio.c needs a small modification

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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 29 Aug 2020 18:00:47 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Adam Rudziński <adam.rudzinski@....net.pl>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        netdev <netdev@...r.kernel.org>, robh+dt@...nel.org,
        frowand.list@...il.com
Subject: Re: drivers/of/of_mdio.c needs a small modification

> This is true assuming that the PHYs are always and forever connected to one
> specific MDIO bus. This is probably reasonable. Although, in i.MX the MDIO
> bus of FEC1 and FEC2 shares the pins.

In general, they do not. In fact, i don't see how that can work. The
FEC drive provides no mutual exclusion between MDIO operations on
different MDIO controllers. So one controller could be performing a
read while the other a write. If they are sharing the same pins, how
do you drive the clock pin both high and low at the same time? How do
you have the data pin both high impedance so the PHY can drive it, and
also drive out a 0 or a 1 to perform a right?

What is suspect you can do is use pinmux to connect the pins to either
ethernet1 MDIO controller, or ethernet2 mdio controller. But never
both. You have to decide which gets to control the bus, and the other
controller is isolated.

> I'm sure of that - LAN8720A needs to have the clock from FEC or external
> generator to be able to talk over MDIO.

O.K. Then you need to core to enable the clock before scanning the
bus.

	Andrew