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 01:14:33 +0200
From:   Adam Rudziński <adam.rudzinski@....net.pl>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     robh+dt@...nel.org, frowand.list@...il.com, f.fainelli@...il.com,
        netdev <netdev@...r.kernel.org>
Subject: Re: drivers/of/of_mdio.c needs a small modification

W dniu 2020-08-29 o 00:53, Andrew Lunn pisze:
> On Sat, Aug 29, 2020 at 12:34:05AM +0200, Adam Rudziński wrote:
>> Hi Andrew.
>>
>> W dniu 2020-08-29 o 00:28, Andrew Lunn pisze:
>>> Hi Adam
>>>
>>>> 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?

Best regards,
Adam