From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
"Jakub Kicinski" <kuba@kernel.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Paolo Abeni" <pabeni@redhat.com>,
"Hubert Wiśniewski" <hubert.wisniewski.25632@gmail.com>,
stable@vger.kernel.org, kernel@pengutronix.de,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
"Lukas Wunner" <lukas@wunner.de>, "Xu Yang" <xu.yang_2@nxp.com>,
linux-usb@vger.kernel.org
Subject: Re: [PATCH net v1 1/1] net: usb: asix: ax88772: drop phylink use in PM to avoid MDIO runtime PM wakeups
Date: Tue, 16 Sep 2025 09:18:09 +0200 [thread overview]
Message-ID: <aMkPMa650kfKfmF4@pengutronix.de> (raw)
In-Reply-To: <aMUS8ZIUpZJ4HNNX@pengutronix.de>
On Sat, Sep 13, 2025 at 08:45:05AM +0200, Oleksij Rempel wrote:
> On Fri, Sep 12, 2025 at 03:37:52PM +0100, Russell King (Oracle) wrote:
> > On Fri, Sep 12, 2025 at 10:29:47AM -0400, Alan Stern wrote:
> > > On Fri, Sep 12, 2025 at 09:33:05AM +0100, Russell King (Oracle) wrote:
> > > > On Thu, Sep 11, 2025 at 10:30:09PM -0400, Alan Stern wrote:
> > > > > The USB subsystem uses only one pair of callbacks for suspend and resume
> > > > > because USB hardware has only one suspend state. However, the callbacks
> > > > > do get an extra pm_message_t parameter which they can use to distinguish
> > > > > between system sleep transitions and runtime PM transitions.
> > > >
> > > > Unfortunately, this isn't the case. While a struct usb_device_driver's
> > > > suspend()/resume() methods get the pm_message_t, a struct usb_driver's
> > > > suspend()/resume() methods do not:
> > > >
> > > > static int usb_resume_interface(struct usb_device *udev,
> > > > struct usb_interface *intf, pm_message_t msg, int reset_resume)
> > > > {
> > > > struct usb_driver *driver;
> > > > ...
> > > > if (reset_resume) {
> > > > if (driver->reset_resume) {
> > > > status = driver->reset_resume(intf);
> > > > ...
> > > > } else {
> > > > status = driver->resume(intf);
> > > >
> > > > vs
> > > >
> > > > static int usb_resume_device(struct usb_device *udev, pm_message_t msg)
> > > > {
> > > > struct usb_device_driver *udriver;
> > > > ...
> > > > if (status == 0 && udriver->resume)
> > > > status = udriver->resume(udev, msg);
> > > >
> > > > and in drivers/net/usb/asix_devices.c:
> > > >
> > > > static struct usb_driver asix_driver = {
> > > > ...
> > > > .suspend = asix_suspend,
> > > > .resume = asix_resume,
> > > > .reset_resume = asix_resume,
> > > >
> > > > where asix_resume() only takes one argument:
> > > >
> > > > static int asix_resume(struct usb_interface *intf)
> > > > {
> > >
> > > Your email made me go back and check the code more carefully, and it
> > > turns out that we were both half-right. :-)
> > >
> > > The pm_message_t argument is passed to the usb_driver's ->suspend
> > > callback in usb_suspend_interface(), but not to the ->resume callback in
> > > usb_resume_interface(). Yes, it's inconsistent.
> > >
> > > I suppose the API could be changed, at the cost of updating a lot of
> > > drivers. But it would be easier if this wasn't necessary, if there was
> > > some way to work around the problem. Unfortunately, I don't know
> > > anything about how the network stack handles suspend and resume, or
> > > what sort of locking it requires, so I can't offer any suggestions.
> >
> > I, too, am unable to help further as I have no bandwidth available
> > to deal with this. Sorry.
>
> Thanks for all the valuable input.
>
> I’ll process the feedback and investigate possible ways to proceed. As a
> first step I’ll measure the actual power savings from USB auto-suspend
> on AX88772 to see if runtime PM is worth the added complexity.
I ran quick power measurements to check whether USB autosuspend is worth the
added complexity.
Meaning:
- "admin up/down" = ip link set dev <if> up/down.
- No link partner was attached, so the physical link was down in all tests.
Setups:
- Debian 5.10 (USB autosuspend present, no phylib).
- Debian 6.1 (phylib present, no regression).
- Power meter: Fnirsi FNB58.
- Env: QEMU 9.2.1 (USB passthrough)
xHCI host Intel 100/C230
device ASIX AX88772B (0b95:772b)
Legend:
- "RT: active" = runtime PM on;
- "RT: suspended" = runtime PM auto (device suspended).
Results:
- Kernel 5.10.237-1
admin up (link down): 0.453 W (RT: active)
admin down: 0.453 W (RT: active)
admin down: 0.453 W (RT: suspended)
- Kernel 6.1.148-1
admin up (link down): 0.453 W (RT: active)
admin down: 0.248 W (RT: active)
admin down: 0.248 W (RT: suspended)
Observations:
In this setup, USB autosuspend did not reduce power further (admin-down power
is identical with/without autosuspend).
The drop from ~0.453 W -> ~0.248 W on 6.1 appears to come from the phylib
migration (PHY powered down on admin-down), not from autosuspend.
Proposal:
Given autosuspend brings no measurable benefit here, and it hasn’t been
effectively functional for this device in earlier kernels, I suggest a minimal
-stable patch that disables USB autosuspend for ASIX driver to avoid the
PM/RTNL/MDIO issues. If someone needs autosuspend-based low-power later, they
can implement a proper device low-power sequence and re-enable it.
Would this minimal -stable patch be acceptable?
Best Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2025-09-16 7:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250911135853eucas1p283b1afd37287b715403cd2cdbfa03a94@eucas1p2.samsung.com>
2025-09-08 11:26 ` [PATCH net v1 1/1] net: usb: asix: ax88772: drop phylink use in PM to avoid MDIO runtime PM wakeups Oleksij Rempel
2025-09-08 17:00 ` Hubert Wiśniewski
2025-09-09 7:17 ` Oleksij Rempel
2025-09-09 23:56 ` Jakub Kicinski
2025-09-10 4:16 ` Oleksij Rempel
2025-09-09 2:05 ` Xu Yang
2025-09-09 23:58 ` Jakub Kicinski
2025-09-10 4:11 ` Oleksij Rempel
2025-09-11 0:50 ` Jakub Kicinski
2025-09-11 1:00 ` patchwork-bot+netdevbpf
2025-09-11 13:58 ` Marek Szyprowski
2025-09-11 14:39 ` Russell King (Oracle)
2025-09-11 14:55 ` Jakub Kicinski
2025-09-11 20:46 ` Russell King (Oracle)
2025-09-12 2:30 ` Alan Stern
2025-09-12 8:33 ` Russell King (Oracle)
2025-09-12 14:29 ` Alan Stern
2025-09-12 14:37 ` Russell King (Oracle)
2025-09-13 6:45 ` Oleksij Rempel
2025-09-16 7:18 ` Oleksij Rempel [this message]
2025-09-16 14:42 ` Jakub Kicinski
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=aMkPMa650kfKfmF4@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hubert.wisniewski.25632@gmail.com \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lukas@wunner.de \
--cc=m.szyprowski@samsung.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=xu.yang_2@nxp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.