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

On 8/28/2020 4:14 PM, Adam Rudziński wrote:

W dniu 2020-08-29 o 00:53, Andrew Lunn pisze:

quoted

On Sat, Aug 29, 2020 at 12:34:05AM +0200, Adam Rudziński wrote:

quoted

Hi Andrew.

W dniu 2020-08-29 o 00:28, Andrew Lunn pisze:

quoted

Hi Adam

quoted

If kernel has to bring up two Ethernet interfaces, the processor 
has two
peripherals with functionality of MACs (in i.MX6ULL these are Fast 
Ethernet
Controllers, FECs), but uses a shared MDIO bus, then the kernel 
first probes
one MAC, enables clock for its PHY, probes MDIO bus tryng to 
discover _all_
PHYs, and then probes the second MAC, and enables clock for its 
PHY. The
result is that the second PHY is still inactive during PHY 
discovery. Thus,
one Ethernet interface is not functional.

What clock are you talking about? Do you have the FEC feeding a 50MHz
clock to the PHY? Each FEC providing its own clock to its own PHY? And
are you saying a PHY without its reference clock does not respond to
MDIO reads and hence the second PHY does not probe because it has no
reference clock?

      Andrew

Yes, exactly. In my case the PHYs are LAN8720A, and it works this way.

O.K. Boards i've seen like this have both PHYs driver from the first
MAC. Or the clock goes the other way, the PHY has a crystal and it
feeds the FEC.

I would say the correct way to solve this is to make the FEC a clock
provider. It should register its clocks with the common clock
framework. The MDIO bus can then request the clock from the second FEC
before it scans the bus. Or we add the clock to the PHY node so it
enables the clock before probing it. There are people who want this
sort of framework code, to be able to support a GPIO reset, which
needs releasing before probing the bus for the PHY.

Anyway, post your patch, so we get a better idea what you are
proposing.

    Andrew

Hm, this sounds reasonable, but complicated at the same time. I have 
spent some time searching for possible solution and never found anything 
teaching something similar, so I'd also speculate that it's kind of not 
very well documented. That doesn't mean I'm against these solutions, 
just that seems to be beyond capabilities of many mortals who even try 
to read.

OK, so a patch it is. Please, let me know how to make the patch so that 
it was useful and as convenient as possible for you. Would you like me 
to use some specific code/repo/branch/... as its base?

This is targeting the net-next tree, see the netdev-FAQ here for details:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netdev-FAQ.rst

I will be posting some patches for our ARCH_BRCMSTB platforms which 
require that we turn on the internal PHY's digital clock otherwise it 
does not respond on the MDIO bus and we cannot discover its ID and we 
cannot bind to a PHY driver. I will make sure to copy you so you can see 
if this would work for you.
-- 
Florian