From: Lukas Wunner <lukas@wunner.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, linux-usb@vger.kernel.org,
Steve Glendinning <steve.glendinning@shawell.net>,
UNGLinuxDriver@microchip.com, Oliver Neukum <oneukum@suse.com>,
Andre Edich <andre.edich@microchip.com>,
Oleksij Rempel <linux@rempel-privat.de>,
Martyn Welch <martyn.welch@collabora.com>,
Gabriel Hojda <ghojda@yo2urs.ro>,
Christoph Fritz <chf.fritz@googlemail.com>,
Lino Sanfilippo <LinoSanfilippo@gmx.de>,
Philipp Rosenberger <p.rosenberger@kunbus.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Ferry Toth <fntoth@gmail.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
'Linux Samsung SOC' <linux-samsung-soc@vger.kernel.org>
Subject: Re: [PATCH net-next v3 5/7] usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid polling
Date: Thu, 26 May 2022 15:55:54 +0200 [thread overview]
Message-ID: <20220526135554.GA22214@wunner.de> (raw)
In-Reply-To: <YozJqD5bhg31gjz7@lunn.ch>
On Tue, May 24, 2022 at 02:03:52PM +0200, Andrew Lunn wrote:
> As for this hardware, if it does not support WOL, why are interrupts
> still enabled?
LAN95xx chips do support WoL and will signal a USB wake event.
But whether that actually results in resume from system sleep
depends on the capabilities of the SoC and its USB host controller.
LAN95xx supports a variety of wake options (WoL, PHY Energy Detect, ...)
and can use either its integrated SMSC PHY or an external PHY.
I'm not sure all wake options will work with arbitrary external PHYs.
If WoL or Wake on PHY Energy Detect is not used, we just program the
LAN95xx to enter a deeper power state which results in the respective
wake events being ignored. As a result, interrupts may be left enabled
even though they're not used as a wakeup source. The phylib doesn't
provide an API to selectively disable or enable interrupts, other than
phy_stop() and phy_start(), which does a lot more.
The patch I've submitted today treats such unnecessarily enabled
interrupts leniently: It will not signal wakeup if that wasn't enabled
and just remembers that an interrupt occurred. The interrupt will be
replayed upon resume and that's it.
Thanks,
Lukas
next prev parent reply other threads:[~2022-05-26 13:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1652343655.git.lukas@wunner.de>
[not found] ` <CGME20220517101846eucas1p2c132f7e7032ed00996e222e9cc6cdf99@eucas1p2.samsung.com>
[not found] ` <748ac44eeb97b209f66182f3788d2a49d7bc28fe.1652343655.git.lukas@wunner.de>
2022-05-17 10:18 ` [PATCH net-next v3 5/7] usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid polling Marek Szyprowski
2022-05-19 19:08 ` Lukas Wunner
2022-05-19 21:22 ` Marek Szyprowski
2022-05-23 9:43 ` Lukas Wunner
2022-05-23 11:38 ` Marek Szyprowski
2022-05-23 12:34 ` Andrew Lunn
2022-05-23 13:47 ` Lukas Wunner
2022-05-24 0:52 ` Andrew Lunn
2022-05-24 1:08 ` Andrew Lunn
2022-05-24 6:16 ` Marek Szyprowski
2022-05-24 12:03 ` Andrew Lunn
2022-05-26 13:55 ` Lukas Wunner [this message]
2022-05-24 12:13 ` Lukas Wunner
2022-06-06 1:28 ` Andrew Lunn
2022-08-26 6:51 ` Marek Szyprowski
2022-08-26 7:19 ` Lukas Wunner
2022-08-26 7:41 ` Marek Szyprowski
2022-08-26 7:53 ` Lukas Wunner
2022-08-26 8:29 ` Marek Szyprowski
2022-08-29 11:40 ` Marek Szyprowski
2022-09-18 19:13 ` Lukas Wunner
2022-09-18 20:41 ` Florian Fainelli
2022-09-18 20:55 ` Lukas Wunner
2022-09-18 22:11 ` Florian Fainelli
2022-09-23 4:20 ` Lukas Wunner
2022-09-22 13:21 ` Marek Szyprowski
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=20220526135554.GA22214@wunner.de \
--to=lukas@wunner.de \
--cc=LinoSanfilippo@gmx.de \
--cc=UNGLinuxDriver@microchip.com \
--cc=andre.edich@microchip.com \
--cc=andrew@lunn.ch \
--cc=chf.fritz@googlemail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fntoth@gmail.com \
--cc=ghojda@yo2urs.ro \
--cc=hkallweit1@gmail.com \
--cc=krzk@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linux@rempel-privat.de \
--cc=m.szyprowski@samsung.com \
--cc=martyn.welch@collabora.com \
--cc=netdev@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=p.rosenberger@kunbus.com \
--cc=pabeni@redhat.com \
--cc=steve.glendinning@shawell.net \
/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