netdev - Re: [PATCH] net: bcmgenet: Fix attaching to PYH failed on RPi 4B

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:   Mon, 21 Jun 2021 14:47:09 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Stefan Wahren <stefan.wahren@...e.com>,
        Peter Robinson <pbrobinson@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, Jian-Hong Pan <jhp@...lessos.org>,
        Doug Berger <opendmb@...il.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux@...lessos.org,
        bcm-kernel-feedback-list@...adcom.com,
        linux-rpi-kernel@...ts.infradead.org
Subject: Re: [PATCH] net: bcmgenet: Fix attaching to PYH failed on RPi 4B

On 6/21/21 1:15 PM, Stefan Wahren wrote:
> Am 21.06.21 um 18:56 schrieb Peter Robinson:
>> On Mon, Jun 21, 2021 at 5:39 PM Florian Fainelli <f.fainelli@...il.com> wrote:
>>> On 6/21/21 6:09 AM, Andrew Lunn wrote:
>>>> On Mon, Jun 21, 2021 at 06:33:11PM +0800, Jian-Hong Pan wrote:
>>>>> The Broadcom UniMAC MDIO bus comes too late. So, GENET cannot find the
>>>>> ethernet PHY on UniMAC MDIO bus. This leads GENET fail to attach the
>>>>> PHY.
>>>>>
>>>>> bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
>>>>> ...
>>>>> could not attach to PHY
>>>>> bcmgenet fd580000.ethernet eth0: failed to connect to PHY
>>>>> uart-pl011 fe201000.serial: no DMA platform data
>>>>> libphy: bcmgenet MII bus: probed
>>>>> ...
>>>>> unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus
>>>>>
>>>>> This patch makes GENET try to connect the PHY up to 3 times. Also, waits
>>>>> a while between each time for mdio-bcm-unimac module's loading and
>>>>> probing.
>>>> Don't loop. Return -EPROBE_DEFER. The driver core will then probed the
>>>> driver again later, by which time, the MDIO bus driver should of
>>>> probed.
>>> This is unlikely to work because GENET register the mdio-bcm-unimac
>>> platform device so we will likely run into a chicken and egg problem,
>>> though surprisingly I have not seen this on STB platforms where GENET is
>>> used, I will try building everything as a module like you do. Can you
>>> see if the following helps:
>> For reference we have mdio_bcm_unimac/genet both built as modules in
>> Fedora and I've not seen this issue reported using vanilla upstream
>> kernels if that's a useful reference point.
> 
> I was also unable to reproduce this issue, but it seems to be a known
> issue [1], [2].
> 
> Jian-Hong opened an issue in my Github repo [3], but before the issue
> was narrowed down, he decided to send this workaround.

The comment about changing the phy-mode property is not quite making
sense to me, except if that means that in one case the Broadcom PHY
driver is used and in the other case the Generic PHY driver is used.

What is not clear to me from the debugging that has been done so far is
whether the mdio-bcm-unimac MDIO controller was not loaded at the time
of_phy_connect() was trying to identify the PHY device.
--
Florian