diff mbox series

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

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

Checks

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

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

Andrew Lunn June 21, 2021, 1:09 p.m. UTC | #1
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
Florian Fainelli June 21, 2021, 4:37 p.m. UTC | #2
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);
Florian Fainelli June 21, 2021, 4:47 p.m. UTC | #3
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,
Peter Robinson June 21, 2021, 4:56 p.m. UTC | #4
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
Stefan Wahren June 21, 2021, 8:15 p.m. UTC | #5
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
Florian Fainelli June 21, 2021, 9:47 p.m. UTC | #6
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
Jian-Hong Pan June 22, 2021, 6:29 a.m. UTC | #7
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 | #8
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 | #9
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;