From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: "Michał Pecio" <michal.pecio@gmail.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] usb: xhci: Unify duplicate inc_enq() code
Date: Mon, 24 Feb 2025 13:49:29 +0200 [thread overview]
Message-ID: <91e9b2f6-d9f6-460e-965a-bf2d5b13878c@linux.intel.com> (raw)
In-Reply-To: <20250224004542.5861d4dc@foxbook>
On 24.2.2025 1.45, Michał Pecio wrote:
> On Fri, 21 Feb 2025 16:54:11 +0200, Mathias Nyman wrote:
>> On 21.2.2025 0.47, Michal Pecio wrote:
>>> Remove a block of code copied from inc_enq(). As often happens, the
>>> two copies have diverged somewhat - in this case, inc_enq() has a
>>> bug where it may leave the chain bit of a link TRB unset on a
>>> quirky HC. Fix this. Remove the pointless 'next' variable which
>>> only aliases ring->enqueue.
>>
>> The linnk TRB chain bit should be set when the ring is created, and
>> never cleared on those quirky hosts.
>
> OK, I see, there is stuff in xhci-mem.c. I'll remove the above text
> and any code which touches the bit on quirky HCs.
>
> Speaking of which, I have some evidence that NEC uPD720200 has the
> exact same bug as AMD, namely after a Missed Service Error near the
> end of a segment it fetches TRBs out of bounds and trips the IOMMU
> or stops with Ring Underrun. Link chain quirk seems to fix it.
Interesting, I wonder if setting the link TRB chain bit would
also help with the TRB prefetch issue on VIA VL805 hosts.
Maybe we could avoid allocating the dummy page by just setting this
quirk instead.
>
>> maybe
>>
>> if (trb_is_link(ring->enqueue) && (chain || more_trbs_coming))
>> inc_eng_past_link(xhci, ring, chain);
>>
>> Avoids calling inc_enq_past_link() every time we increase enqueue,
>> and explains why we call it.
>
> I can do that too. By the way, do we actually want this while loop in
> inc_enq_past_link() at all? Currently links only exist at the end of a
> segment and always point to the beginning of the next segment.
>
> I noticed that per xHCI 4.11.7, "Software shall not define consecutive
> Link TRBs within a TD". I suppose "consecutive" means "one pointing to
> another". And if it's prohibited inside a TD, it will likely always be
> easier to avoid doing it at all than try to manage special cases.
I don't think that loop is needed. The xhci driver is the only creator
of link TRBs, and at the moment they are placed exactly as you said.
Thanks
Mathias
next prev parent reply other threads:[~2025-02-24 11:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-20 22:43 [PATCH 0/3] xhci: ring queuing cleanups Michal Pecio
2025-02-20 22:44 ` [PATCH 1/3] usb: xhci: Simplify update_ring_for_set_deq_completion() Michal Pecio
2025-02-21 13:23 ` Mathias Nyman
2025-03-05 8:24 ` Michał Pecio
2025-02-20 22:46 ` [PATCH 2/3] usb: xhci: Simplify moving HW Dequeue Pointer past cancelled TDs Michal Pecio
2025-02-20 22:47 ` [PATCH 3/3] usb: xhci: Unify duplicate inc_enq() code Michal Pecio
2025-02-21 14:54 ` Mathias Nyman
2025-02-23 23:45 ` Michał Pecio
2025-02-24 11:49 ` Mathias Nyman [this message]
2025-02-24 21:01 ` Michał Pecio
2025-02-25 9:33 ` Mathias Nyman
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=91e9b2f6-d9f6-460e-965a-bf2d5b13878c@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=michal.pecio@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
all inboxes | Powered by JetHome®