netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Cc: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>,
	M Chetan Kumar <m.chetan.kumar@intel.com>,
	Loic Poulain <loic.poulain@linaro.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	Bjorn Helgaas <bhelgaas@google.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>,
	netdev@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] net: wwan: iosm: Fix hibernation by re-binding the driver around it
Date: Tue, 7 Jan 2025 17:45:30 -0600	[thread overview]
Message-ID: <20250107234530.GA191158@bhelgaas> (raw)
In-Reply-To: <5ec25117-e0c3-477b-96da-dd2adf870408@gmail.com>

On Wed, Jan 08, 2025 at 01:13:41AM +0200, Sergey Ryazanov wrote:
> On 05.01.2025 19:39, Maciej S. Szmigiero wrote:
> > Currently, the driver is seriously broken with respect to the
> > hibernation (S4): after image restore the device is back into
> > IPC_MEM_EXEC_STAGE_BOOT (which AFAIK means bootloader stage) and needs
> > full re-launch of the rest of its firmware, but the driver restore
> > handler treats the device as merely sleeping and just sends it a
> > wake-up command.
> > 
> > This wake-up command times out but device nodes (/dev/wwan*) remain
> > accessible.
> > However attempting to use them causes the bootloader to crash and
> > enter IPC_MEM_EXEC_STAGE_CD_READY stage (which apparently means "a crash
> > dump is ready").
> > 
> > It seems that the device cannot be re-initialized from this crashed
> > stage without toggling some reset pin (on my test platform that's
> > apparently what the device _RST ACPI method does).
> > 
> > While it would theoretically be possible to rewrite the driver to tear
> > down the whole MUX / IPC layers on hibernation (so the bootloader does
> > not crash from improper access) and then re-launch the device on
> > restore this would require significant refactoring of the driver
> > (believe me, I've tried), since there are quite a few assumptions
> > hard-coded in the driver about the device never being partially
> > de-initialized (like channels other than devlink cannot be closed,
> > for example).
> > Probably this would also need some programming guide for this hardware.
> > 
> > Considering that the driver seems orphaned [1] and other people are
> > hitting this issue too [2] fix it by simply unbinding the PCI driver
> > before hibernation and re-binding it after restore, much like
> > USB_QUIRK_RESET_RESUME does for USB devices that exhibit a similar
> > problem.
> > 
> > Tested on XMM7360 in HP EliteBook 855 G7 both with s2idle (which uses
> > the existing suspend / resume handlers) and S4 (which uses the new code).
> > 
> > [1]: https://lore.kernel.org/all/c248f0b4-2114-4c61-905f-466a786bdebb@leemhuis.info/
> > [2]:
> > https://github.com/xmm7360/xmm7360-pci/issues/211#issuecomment-1804139413
> > 
> > Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
> 
> Generally looks good to me. Lets wait for approval from PCI maintainers to
> be sure that there no unexpected side effects.

I have nothing useful to contribute here.  Seems like kind of a mess.
But Intel claims to maintain this, so it would be nice if they would
step up and make this work nicely.

Bjorn

  reply	other threads:[~2025-01-07 23:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-05 17:39 [PATCH v2] net: wwan: iosm: Fix hibernation by re-binding the driver around it Maciej S. Szmigiero
2025-01-07 23:13 ` Sergey Ryazanov
2025-01-07 23:45   ` Bjorn Helgaas [this message]
2025-01-08  0:15     ` Sergey Ryazanov
2025-01-08 19:51       ` Bjorn Helgaas
2025-01-08 20:03         ` Maciej S. Szmigiero
2025-01-08 20:17           ` Rafael J. Wysocki
2025-01-08 20:18             ` Maciej S. Szmigiero
2025-01-08 20:14         ` Rafael J. Wysocki

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=20250107234530.GA191158@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=bhelgaas@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=m.chetan.kumar@intel.com \
    --cc=mail@maciej.szmigiero.name \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=ryazanov.s.a@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).