From: Florian Fainelli <f.fainelli@gmail.com>
To: "Heiner Kallweit" <hkallweit1@gmail.com>,
"Daniel González Cabanelas" <dgcbueu@gmail.com>
Cc: "Andrew Lunn" <andrew@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
gregkh@linuxfoundation.org, netdev@vger.kernel.org,
"Álvaro Fernández Rojas" <noltari@gmail.com>
Subject: Re: [PATCH v2] bcm63xx_enet: fix internal phy IRQ assignment
Date: Thu, 25 Feb 2021 20:12:23 -0800 [thread overview]
Message-ID: <35f5f66b-fe19-8e45-7e8a-8af85d73149f@gmail.com> (raw)
In-Reply-To: <4ee0ce3b-39b8-8645-77ce-dd9cb1b1f857@gmail.com>
On 2/25/2021 2:56 PM, Heiner Kallweit wrote:
>>>>> It's still an ugly workaround and a proper root cause analysis should be done
>>>>> first. I can only imagine that phydev->irq is overwritten in phy_probe()
>>>>> because phy_drv_supports_irq() is false. Can you please check whether
>>>>> phydev->irq is properly set in phy_device_create(), and if yes, whether
>>>>> it's reset to PHY_POLL in phy_probe()?.
>>>>>
>>>>
>>>> Hi Heiner, I added some kernel prints:
>>>>
>>>> [ 2.712519] libphy: Fixed MDIO Bus: probed
>>>> [ 2.721969] =======phy_device_create===========
>>>> [ 2.726841] phy_device_create: dev->irq = 17
>>>> [ 2.726841]
>>>> [ 2.832620] =======phy_probe===========
>>>> [ 2.836846] phy_probe: phydev->irq = 17
>>>> [ 2.840950] phy_probe: phy_drv_supports_irq = 0, phy_interrupt_is_valid = 1
>>>> [ 2.848267] phy_probe: phydev->irq = -1
>>>> [ 2.848267]
>>>> [ 2.854059] =======phy_probe===========
>>>> [ 2.858174] phy_probe: phydev->irq = -1
>>>> [ 2.862253] phy_probe: phydev->irq = -1
>>>> [ 2.862253]
>>>> [ 2.868121] libphy: bcm63xx_enet MII bus: probed
>>>> [ 2.873320] Broadcom BCM63XX (1) bcm63xx_enet-0:01: attached PHY
>>>> driver [Broadcom BCM63XX (1)] (mii_bus:phy_addr=bcm63xx_enet-0:01,
>>>> irq=POLL)
>>>>
>>>> Currently using kernel 5.4.99. I still have no idea what's going on.
>>>>
>>> Thanks for debugging. This confirms my assumption that the interrupt
>>> is overwritten in phy_probe(). I'm just scratching my head how
>>> phy_drv_supports_irq() can return 0. In 5.4.99 it's defined as:
>>>
>>> static bool phy_drv_supports_irq(struct phy_driver *phydrv)
>>> {
>>> return phydrv->config_intr && phydrv->ack_interrupt;
>>> }
>>>
>>> And that's the PHY driver:
>>>
>>> static struct phy_driver bcm63xx_driver[] = {
>>> {
>>> .phy_id = 0x00406000,
>>> .phy_id_mask = 0xfffffc00,
>>> .name = "Broadcom BCM63XX (1)",
>>> /* PHY_BASIC_FEATURES */
>>> .flags = PHY_IS_INTERNAL,
>>> .config_init = bcm63xx_config_init,
>>> .ack_interrupt = bcm_phy_ack_intr,
>>> .config_intr = bcm63xx_config_intr,
>>> }
>>>
>>> So both callbacks are set. Can you extend your debugging and check
>>> in phy_drv_supports_irq() which of the callbacks is missing?
>>>
>>
>> Hi, both callbacks are missing on the first check. However on the next
>> calls they're there.
>>
>> [ 2.263909] libphy: Fixed MDIO Bus: probed
>
> This is weird. The phy_device seems to show up on both MDIO buses,
> the fixed one *and* the bcm63xx_enet bus.
Yes that does not make sense to me at all, but maybe something broke at
some point for non-Device Tree systems and we are just catching it now.
The largest rework that occurred during v4.4 and v4.9 was the
introduction of mdio_device.
--
Florian
next prev parent reply other threads:[~2021-02-26 4:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 15:44 [PATCH v2] bcm63xx_enet: fix internal phy IRQ assignment Daniel González Cabanelas
2021-02-24 21:44 ` Heiner Kallweit
2021-02-24 22:01 ` Florian Fainelli
2021-02-24 23:54 ` Daniel González Cabanelas
2021-02-25 7:22 ` Heiner Kallweit
2021-02-25 16:36 ` Daniel González Cabanelas
2021-02-25 20:05 ` Heiner Kallweit
2021-02-25 22:28 ` Daniel González Cabanelas
2021-02-25 22:56 ` Heiner Kallweit
2021-02-26 4:12 ` Florian Fainelli [this message]
2021-02-26 7:13 ` Heiner Kallweit
2021-02-26 9:10 ` Daniel González Cabanelas
2021-02-26 9:32 ` Heiner Kallweit
2021-02-26 9:38 ` Heiner Kallweit
2021-02-26 9:49 ` Daniel González Cabanelas
2021-02-26 10:08 ` Heiner Kallweit
2021-02-26 10:19 ` Daniel González Cabanelas
2021-02-26 14:16 ` Andrew Lunn
2021-02-26 14:28 ` Heiner Kallweit
2021-02-26 16:14 ` Daniel González Cabanelas
2021-02-26 16:55 ` Florian Fainelli
2021-02-25 13:53 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35f5f66b-fe19-8e45-7e8a-8af85d73149f@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dgcbueu@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=noltari@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).