From: Michal Pecio <michal.pecio@gmail.com>
To: "Neronin, Niklas" <niklas.neronin@linux.intel.com>
Cc: mathias.nyman@linux.intel.com, linux-usb@vger.kernel.org,
raoxu@uniontech.com
Subject: Re: [PATCH 9/9] usb: xhci: optimize resuming from S4 (suspend-to-disk)
Date: Wed, 1 Apr 2026 12:38:07 +0200 [thread overview]
Message-ID: <20260401123807.1719ff57.michal.pecio@gmail.com> (raw)
In-Reply-To: <b3a945bf-65e9-4a8e-9a88-341bc59f6c8d@linux.intel.com>
On Tue, 31 Mar 2026 12:59:50 +0300, Neronin, Niklas wrote:
> On 30/03/2026 12.45, Michal Pecio wrote:
> >
> >>
> >> - xhci_dbg(xhci, "// Disabling event ring interrupts\n");
> >> - temp = readl(&xhci->op_regs->status);
> >> - writel((temp & ~0x1fff) | STS_EINT, &xhci->op_regs->status);
> >> - xhci_disable_interrupter(xhci, xhci->interrupters[0]);
> >> + cancel_delayed_work_sync(&xhci->cmd_timer);
> >> +
> >> + /* Delete all remaining commands */
> >> + xhci_cleanup_command_queue(xhci);
> >
> > Considering that xhci_suspend() clears the command ring anyway, it
> > could probably do this too so we don't need to.
>
> It makes more sense to have all clearing in one place, instead of
> spread out over suspend and resume. This will be addressed in the
> next patch set, i.e. remove clearing from suspend (if possible).
And this patch leaves command cleanup spread across suspend and resume.
If a future patch moves clearing the ring from suspend to resume then
it can also move completing and freeing stale commands with it.
> >> + xhci_for_each_ring_seg(xhci->cmd_ring->first_seg, seg)
> >> + memset(seg->trbs, 0, sizeof(union xhci_trb) * TRBS_PER_SEGMENT);
> >
> > This looks like a bug because it nukes link TRBs. I know that
> > xhci_init() will fix this up (unless somebody changes that without
> > updating here), but it looks confusing.
And it's unnecessary because xhci_suspend() wiped the ring already.
Which means that xhci_init() calling ring_init() is unnecessary too.
> I would like to remove xhci_clear_command_ring() eventually,
> instead have:
>
> xhci_ring_reset()
> ...
> xhci_set_cmd_ring_deq()
Fair enough, in some cases one may be useful without the other.
> or
>
> xhci_ring_clear()
> ...
> xhci_ring_init()
> xhci_set_cmd_ring_deq()
Not sure what ... would be, however?
If clear() doesn't include init(), is there ever a good reason to
maintain the ring in an invalid state? A state where forgetting
about ring_init() would cause the HC to escape the ring and IOMMU
fault or interpret random memory as commands?
Regards,
Michal
prev parent reply other threads:[~2026-04-01 10:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 12:34 [PATCH 0/9] xhci: usb: optimize resuming from S4 (suspend-to-disk) Niklas Neronin
2026-03-27 12:34 ` [PATCH 1/9] usb: xhci: simplify CMRT initialization logic Niklas Neronin
2026-03-27 12:34 ` [PATCH 2/9] usb: xhci: relocate Restore/Controller error check Niklas Neronin
2026-03-27 12:34 ` [PATCH 3/9] usb: xhci: factor out roothub bandwidth cleanup Niklas Neronin
2026-03-30 8:29 ` Michal Pecio
2026-03-31 9:34 ` Neronin, Niklas
2026-04-01 9:58 ` Michal Pecio
2026-03-27 12:34 ` [PATCH 4/9] usb: xhci: move reserving command ring trb Niklas Neronin
2026-03-27 12:34 ` [PATCH 5/9] usb: xhci: move ring initialization Niklas Neronin
2026-03-30 8:42 ` Michal Pecio
2026-03-30 8:53 ` Neronin, Niklas
2026-04-01 9:31 ` Michal Pecio
2026-03-27 12:34 ` [PATCH 6/9] usb: xhci: move initialization for lifetime objects Niklas Neronin
2026-03-30 8:49 ` Michal Pecio
2026-03-27 12:34 ` [PATCH 7/9] usb: xhci: split core allocation and initialization Niklas Neronin
2026-03-30 8:57 ` Michal Pecio
2026-03-27 12:34 ` [PATCH 8/9] usb: xhci: improve debug messages during suspend Niklas Neronin
2026-03-30 9:14 ` Michal Pecio
2026-03-30 11:44 ` Neronin, Niklas
2026-03-27 12:34 ` [PATCH 9/9] usb: xhci: optimize resuming from S4 (suspend-to-disk) Niklas Neronin
2026-03-30 9:45 ` Michal Pecio
2026-03-31 9:59 ` Neronin, Niklas
2026-04-01 10:38 ` Michal Pecio [this message]
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=20260401123807.1719ff57.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=niklas.neronin@linux.intel.com \
--cc=raoxu@uniontech.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.