diff mbox series

net: bcmgenet: Fix attaching to PYH failed on RPi 4B

Message ID 20210621103310.186334-1-jhp@endlessos.org
State New
Headers show
Series net: bcmgenet: Fix attaching to PYH failed on RPi 4B | expand

Commit Message

Jian-Hong Pan June 21, 2021, 10:33 a.m. UTC
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(-)

Comments

Jian-Hong Pan June 22, 2021, 6:29 a.m. UTC | #1
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
Heiner Kallweit June 22, 2021, 6:50 a.m. UTC | #2
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
>
Jian-Hong Pan June 22, 2021, 7:46 a.m. UTC | #3
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 mbox series

Patch

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;