| Message ID | 20210621103310.186334-1-jhp@endlessos.org (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: bcmgenet: Fix attaching to PYH failed on RPi 4B | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | success | Link |
| netdev/tree_selection | success | Guessed tree name to be net-next |
| netdev/subject_prefix | warning | Target tree name not specified in the subject |
| netdev/cc_maintainers | warning | 2 maintainers not CCed: davem@davemloft.net kuba@kernel.org |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/verify_fixes | success | Link |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 31 lines checked |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
| netdev/header_inline | success | Link |
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. Andrew
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: diff --git a/drivers/net/mdio/mdio-bcm-unimac.c b/drivers/net/mdio/mdio-bcm-unimac.c index bfc9be23c973..d1844ef3724a 100644 --- a/drivers/net/mdio/mdio-bcm-unimac.c +++ b/drivers/net/mdio/mdio-bcm-unimac.c @@ -351,6 +351,7 @@ static struct platform_driver unimac_mdio_driver = { .pm = &unimac_mdio_pm_ops, }, .probe = unimac_mdio_probe, + .probe_type = PROBE_FORCE_SYNCHRONOUS, .remove = unimac_mdio_remove, }; module_platform_driver(unimac_mdio_driver);
On 6/21/21 9:37 AM, Florian Fainelli 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: > > diff --git a/drivers/net/mdio/mdio-bcm-unimac.c > b/drivers/net/mdio/mdio-bcm-unimac.c > index bfc9be23c973..d1844ef3724a 100644 > --- a/drivers/net/mdio/mdio-bcm-unimac.c > +++ b/drivers/net/mdio/mdio-bcm-unimac.c > @@ -351,6 +351,7 @@ static struct platform_driver unimac_mdio_driver = { > .pm = &unimac_mdio_pm_ops, > }, > .probe = unimac_mdio_probe, > + .probe_type = PROBE_FORCE_SYNCHRONOUS, > .remove = unimac_mdio_remove, > }; > module_platform_driver(unimac_mdio_driver); This won't build try this instead: diff --git a/drivers/net/mdio/mdio-bcm-unimac.c b/drivers/net/mdio/mdio-bcm-unimac.c index bfc9be23c973..53fecb53cd65 100644 --- a/drivers/net/mdio/mdio-bcm-unimac.c +++ b/drivers/net/mdio/mdio-bcm-unimac.c @@ -349,6 +349,7 @@ static struct platform_driver unimac_mdio_driver = { .name = UNIMAC_MDIO_DRV_NAME, .of_match_table = unimac_mdio_ids, .pm = &unimac_mdio_pm_ops, + .probe_type = PROBE_FORCE_SYNCHRONOUS, }, .probe = unimac_mdio_probe, .remove = unimac_mdio_remove,
On Mon, Jun 21, 2021 at 5:39 PM Florian Fainelli <f.fainelli@gmail.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. Regards, Peter
Am 21.06.21 um 18:56 schrieb Peter Robinson: > On Mon, Jun 21, 2021 at 5:39 PM Florian Fainelli <f.fainelli@gmail.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. Best regards [1] - https://github.com/raspberrypi/linux/issues/3108#issuecomment-723550749 [2] - https://archlinuxarm.org/forum/viewtopic.php?f=67&t=14806 [3] - https://github.com/lategoodbye/rpi-zero/issues/51 > > Regards, > Peter > > _______________________________________________ > linux-rpi-kernel mailing list > linux-rpi-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
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@gmail.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
Florian Fainelli <f.fainelli@gmail.com> 於 2021年6月22日 週二 上午5:47寫道： > > 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@gmail.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. MODULE_SOFTDEP("pre: mdio-bcm-unimac") mentioned in the comment [1] solves this issue. Tracing the code by following the debug message in comment #2 [2], I learned the path bcmgenet_mii_probe()'s of_phy_connect() -> of_phy_find_device() -> of_mdio_find_device() -> bus_find_device_by_of_node(). And, bus_find_device_by_of_node() cannot find the device on the mdio bus. So, I traced bcm2711-rpi-4-b's device tree to find out which one is the mdio device and why it has not been prepared ready on the mdio bus for genet. Then, I found out it is mdio-bcm-unimac module as mentioned in comment #4 [3]. Also, noticed "unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus" comes after "bcmgenet fd580000.ethernet eth0: failed to connect to PHY" in the log. With these findings, I try to re-modprobe genet module again. The ethernet on RPi 4B works correctly! Also, noticed mdio-bcm-unimac module is loaded before I re-modprobe genet module. Therefore, I try to make mdio-bcm-unimac built in kernel image, instead of a module. Then, genet always can find the mdio device on the bus and the ethernet works as well. Consequently, the idea, loading mdio-bcm-unimac module earlier than genet module comes in my head! However, I don't know the key word "MODULE_SOFTDEP" until Florian's guide. That is why I have a loop to connect the PHY in the original patch. But, I understand MODULE_SOFTDEP is a better solution now! I think this is like the module loading order situation mentioned in commit 11287b693d03 ("r8169: load Realtek PHY driver module before r8169") [4]. [1] https://bugzilla.kernel.org/show_bug.cgi?id=213485#c6 [2] https://bugzilla.kernel.org/show_bug.cgi?id=213485#c2 [3] https://bugzilla.kernel.org/show_bug.cgi?id=213485#c4 [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11287b693d03830010356339e4ceddf47dee34fa Jian-Hong Pan
On 22.06.2021 08:29, Jian-Hong Pan wrote: > Florian Fainelli <f.fainelli@gmail.com> 於 2021年6月22日 週二 上午5:47寫道： >> >> 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@gmail.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. > > MODULE_SOFTDEP("pre: mdio-bcm-unimac") mentioned in the comment [1] > solves this issue. > > Tracing the code by following the debug message in comment #2 [2], I > learned the path bcmgenet_mii_probe()'s of_phy_connect() -> > of_phy_find_device() -> of_mdio_find_device() -> > bus_find_device_by_of_node(). And, bus_find_device_by_of_node() > cannot find the device on the mdio bus. > > So, I traced bcm2711-rpi-4-b's device tree to find out which one is > the mdio device and why it has not been prepared ready on the mdio bus > for genet. > Then, I found out it is mdio-bcm-unimac module as mentioned in comment > #4 [3]. Also, noticed "unimac-mdio unimac-mdio.-19: Broadcom UniMAC > MDIO bus" comes after "bcmgenet fd580000.ethernet eth0: failed to > connect to PHY" in the log. > > With these findings, I try to re-modprobe genet module again. The > ethernet on RPi 4B works correctly! Also, noticed mdio-bcm-unimac > module is loaded before I re-modprobe genet module. > Therefore, I try to make mdio-bcm-unimac built in kernel image, > instead of a module. Then, genet always can find the mdio device on > the bus and the ethernet works as well. > > Consequently, the idea, loading mdio-bcm-unimac module earlier than > genet module comes in my head! However, I don't know the key word > "MODULE_SOFTDEP" until Florian's guide. That is why I have a loop to > connect the PHY in the original patch. But, I understand > MODULE_SOFTDEP is a better solution now! > > I think this is like the module loading order situation mentioned in > commit 11287b693d03 ("r8169: load Realtek PHY driver module before > r8169") [4]. > The reason in r8169 is different. When people add r8169 module to initramfs but not the Realtek PHY driver module then loading r8169 will fail. The MODULE_SOFTDEP is a hint to tools building initramfs. > [1] https://bugzilla.kernel.org/show_bug.cgi?id=213485#c6 > [2] https://bugzilla.kernel.org/show_bug.cgi?id=213485#c2 > [3] https://bugzilla.kernel.org/show_bug.cgi?id=213485#c4 > [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11287b693d03830010356339e4ceddf47dee34fa > > Jian-Hong Pan >
Heiner Kallweit <hkallweit1@gmail.com> 於 2021年6月22日 週二 下午2:50寫道： > > On 22.06.2021 08:29, Jian-Hong Pan wrote: > > Florian Fainelli <f.fainelli@gmail.com> 於 2021年6月22日 週二 上午5:47寫道： > >> > >> 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@gmail.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. > > > > MODULE_SOFTDEP("pre: mdio-bcm-unimac") mentioned in the comment [1] > > solves this issue. > > > > Tracing the code by following the debug message in comment #2 [2], I > > learned the path bcmgenet_mii_probe()'s of_phy_connect() -> > > of_phy_find_device() -> of_mdio_find_device() -> > > bus_find_device_by_of_node(). And, bus_find_device_by_of_node() > > cannot find the device on the mdio bus. > > > > So, I traced bcm2711-rpi-4-b's device tree to find out which one is > > the mdio device and why it has not been prepared ready on the mdio bus > > for genet. > > Then, I found out it is mdio-bcm-unimac module as mentioned in comment > > #4 [3]. Also, noticed "unimac-mdio unimac-mdio.-19: Broadcom UniMAC > > MDIO bus" comes after "bcmgenet fd580000.ethernet eth0: failed to > > connect to PHY" in the log. > > > > With these findings, I try to re-modprobe genet module again. The > > ethernet on RPi 4B works correctly! Also, noticed mdio-bcm-unimac > > module is loaded before I re-modprobe genet module. > > Therefore, I try to make mdio-bcm-unimac built in kernel image, > > instead of a module. Then, genet always can find the mdio device on > > the bus and the ethernet works as well. > > > > Consequently, the idea, loading mdio-bcm-unimac module earlier than > > genet module comes in my head! However, I don't know the key word > > "MODULE_SOFTDEP" until Florian's guide. That is why I have a loop to > > connect the PHY in the original patch. But, I understand > > MODULE_SOFTDEP is a better solution now! Forgot to place some reference as note: * MODULE_SOFTDEP is defined in include/linux/module.h [1] * modprobe.d has an example: [2] Assume "softdep c pre: a b post: d e" is provided in the configuration. Running "modprobe c" is now equivalent to "modprobe a b c d e" without the softdep. [1] https://elixir.bootlin.com/linux/v5.13-rc7/source/include/linux/module.h#L170 [2] https://man7.org/linux/man-pages/man5/modprobe.d.5.html > > I think this is like the module loading order situation mentioned in > > commit 11287b693d03 ("r8169: load Realtek PHY driver module before > > r8169") [4]. > > > The reason in r8169 is different. When people add r8169 module to > initramfs but not the Realtek PHY driver module then loading > r8169 will fail. The MODULE_SOFTDEP is a hint to tools building > initramfs. Thanks for Heiner's quick clarification. Maybe I missed some background of the commit ("r8169: load Realtek PHY driver module before r8169"). Jian-Hong Pan > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=213485#c6 > > [2] https://bugzilla.kernel.org/show_bug.cgi?id=213485#c2 > > [3] https://bugzilla.kernel.org/show_bug.cgi?id=213485#c4 > > [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11287b693d03830010356339e4ceddf47dee34fa > > > > Jian-Hong Pan > > >
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c index 5335244e4577..64f244471fd3 100644 --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c @@ -289,6 +289,7 @@ int bcmgenet_mii_probe(struct net_device *dev) struct phy_device *phydev; u32 phy_flags = 0; int ret; + int i; /* Communicate the integrated PHY revision */ if (priv->internal_phy) @@ -301,8 +302,22 @@ int bcmgenet_mii_probe(struct net_device *dev) priv->old_pause = -1; if (dn) { - phydev = of_phy_connect(dev, priv->phy_dn, bcmgenet_mii_setup, - phy_flags, priv->phy_interface); + /* Try to connect the PHY on UniMAC DMIO bus up to 3 times. + * Wait a while between each time for mdio-bcm-unimac module's + * loading and probing. + */ + phydev = NULL; + for (i = 1; i < 4 && !phydev; i++) { + netdev_info(dev, + "connect %s on UniMAC MDIO bus %d time", + priv->phy_dn->full_name, i); + phydev = of_phy_connect(dev, priv->phy_dn, + bcmgenet_mii_setup, + phy_flags, priv->phy_interface); + if (!phydev && i < 3) + msleep(500); + } + if (!phydev) { pr_err("could not attach to PHY\n"); return -ENODEV;
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. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=213485 Signed-off-by: Jian-Hong Pan <jhp@endlessos.org> --- drivers/net/ethernet/broadcom/genet/bcmmii.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)