From: "Neronin, Niklas" <niklas.neronin@linux.intel.com>
To: Michal Pecio <michal.pecio@gmail.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: Tue, 31 Mar 2026 12:59:50 +0300 [thread overview]
Message-ID: <b3a945bf-65e9-4a8e-9a88-341bc59f6c8d@linux.intel.com> (raw)
In-Reply-To: <20260330114510.2b1e5f05.michal.pecio@gmail.com>
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).
>
> BTW, debugfs/port_bandwidth interface queues commands and I'm not sure
> if it's synchronized in any way with power management. IOW, it might be
> possible that command are pending at suspend, but I'm not sure.
>
>> +
>> + /* Clear data which is re-initilized during runtime */
>> + xhci_for_each_ring_seg(xhci->interrupters[0]->event_ring->first_seg, seg)
>> + memset(seg->trbs, 0, sizeof(union xhci_trb) * TRBS_PER_SEGMENT);
>> +
>> + for (int i = xhci->max_slots; i > 0; i--)
>> + xhci_free_virt_devices_depth_first(xhci, i);
>
> This loop is a bit ugly, it could be a function in xhci-mem.
Will be addressed in xhci_free_virt_devices_depth_first() rework.
>
>> +
>> + xhci_rh_bw_cleanup(xhci);
>> +
>> + xhci->cmd_ring_reserved_trbs = 0;
>> + 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.
I would like to remove xhci_clear_command_ring() eventually,
instead have:
xhci_ring_reset()
...
xhci_set_cmd_ring_deq()
or
xhci_ring_clear()
...
xhci_ring_init()
xhci_set_cmd_ring_deq()
Then xhci_ring_*() functions can be used for all rings,
and now it is clear that the CRP is set.
Thanks,
Niklas
next prev parent reply other threads:[~2026-03-31 9:59 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 [this message]
2026-04-01 10:38 ` Michal Pecio
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=b3a945bf-65e9-4a8e-9a88-341bc59f6c8d@linux.intel.com \
--to=niklas.neronin@linux.intel.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=michal.pecio@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox