mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Fiona Klute <fiona.klute@gmx.de>
Cc: netdev@vger.kernel.org,
	Thangaraj Samynathan <Thangaraj.S@microchip.com>,
	Rengarajan Sundararajan <Rengarajan.S@microchip.com>,
	UNGLinuxDriver@microchip.com, Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-list@raspberrypi.com, stable@vger.kernel.org
Subject: Re: [PATCH] net: usb: lan78xx: Enforce a minimum interrupt polling period
Date: Thu, 10 Apr 2025 16:43:54 +0200	[thread overview]
Message-ID: <0901d90d-3f20-4a10-b680-9c978e04ddda@lunn.ch> (raw)
In-Reply-To: <dc8ef510-8f7d-4c96-9fd8-76b67a22aaf9@gmx.de>

> > Ah, O.K. This tells me the PHY is a lan88xx. And there is a workaround
> > involved for an issue in this PHY. Often PHYs are driven by polling
> > for status changes once per second. Not all PHYs/boards support
> > interrupts. It could be this workaround has only been tested with
> > polling, not interrupts, and so is broken when interrupts are used.
> > 
> > As a quick hack test, in lan78xx_phy_init()
> > 
> > 	/* if phyirq is not set, use polling mode in phylib */
> > 	if (dev->domain_data.phyirq > 0)
> > 		phydev->irq = dev->domain_data.phyirq;
> > 	else
> > 		phydev->irq = PHY_POLL;
> > 
> > Hard code phydev->irq to PHY_POLL, so interrupts are not used.
> > 
> > See if you can reproduce the issue when interrupts are not used.
> It took a while, but I'm fairly confident now that the workaround works,
> I've had over 1000 boots on the hardware in question and didn't see the
> bug. Someone going by upsampled reported the same in the issue on Github
> [1], and pointed out that people working with some Nvidia board and a
> LAN7800 USB device came to the same conclusion a while ago [2].
> 
> That leaves me with the question, what does that mean going forward?
> Would it make sense to add a quirk to unconditionally force polling on
> lan88xx, at least until/unless the interrupt handling can be fixed?

I don't think you need a quirk:

static struct phy_driver microchip_phy_driver[] = {
{
        .phy_id         = 0x0007c132,
        /* This mask (0xfffffff2) is to differentiate from
         * LAN8742 (phy_id 0x0007c130 and 0x0007c131)
         * and allows future phy_id revisions.
         */
        .phy_id_mask    = 0xfffffff2,
        .name           = "Microchip LAN88xx",

        /* PHY_GBIT_FEATURES */

        .probe          = lan88xx_probe,
        .remove         = lan88xx_remove,

        .config_init    = lan88xx_config_init,
        .config_aneg    = lan88xx_config_aneg,
        .link_change_notify = lan88xx_link_change_notify,

        .config_intr    = lan88xx_phy_config_intr,
        .handle_interrupt = lan88xx_handle_interrupt,

Just remove .config_intr and .handle_interrupt. If these are not
provided, phylib will poll, even if an interrupt number has been
passed. And since these functions are not shared with any other PHY,
you can remove them.

Please write a good commit message, we want it clear why they where
removed, to try to prevent somebody putting them back again.

And please aim this for net, not net-next:

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

The change will then get back ported to stable kernels.

	Andrew

  reply	other threads:[~2025-04-10 14:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10 16:59 Fiona Klute
2025-03-10 18:06 ` Alan Stern
2025-03-11 12:37   ` Fiona Klute
2025-03-10 21:27 ` Andrew Lunn
2025-03-11 12:30   ` Fiona Klute
2025-03-11 13:22     ` Andrew Lunn
2025-03-11 14:36       ` Fiona Klute
2025-04-10 14:14       ` Fiona Klute
2025-04-10 14:43         ` Andrew Lunn [this message]
2025-04-14 15:31           ` Fiona Klute

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=0901d90d-3f20-4a10-b680-9c978e04ddda@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=Rengarajan.S@microchip.com \
    --cc=Thangaraj.S@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fiona.klute@gmx.de \
    --cc=kernel-list@raspberrypi.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®