Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
usb: xhci: Unify duplicate inc_enq() code
Extract a block of code copied from inc_enq() into a separate function
and call it from inc_enq() and the other function which used this code.
Remove the pointless 'next' variable which only aliases ring->enqueue.
Note: I don't know if any 0.95 xHC ever reached series production, but
"AMD 0.96 host" appears to be the "Llano" family APU. Example dmesg at
https://linux-hardware.org/?probe=79d5cfd4fd&log=dmesg
pci 0000:00:10.0: [1022:7812] type 00 class 0x0c0330
hcc params 0x014042c3 hci version 0x96 quirks 0x0000000000000608
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20250306144954.3507700-15-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
authored by
Michal Pecio
and committed by
Greg Kroah-Hartman
118abe03
bb0ba4cb
+56
-76
+56
-76
drivers/usb/host/xhci-ring.c
+56
-76
drivers/usb/host/xhci-ring.c
···
204
204
}
205
205
206
206
/*
207
+
* If enqueue points at a link TRB, follow links until an ordinary TRB is reached.
208
+
* Toggle the cycle bit of passed link TRBs and optionally chain them.
209
+
*/
210
+
static void inc_enq_past_link(struct xhci_hcd *xhci, struct xhci_ring *ring, u32 chain)
211
+
{
212
+
unsigned int link_trb_count = 0;
213
+
214
+
while (trb_is_link(ring->enqueue)) {
215
+
216
+
/*
217
+
* Section 6.4.4.1 of the 0.95 spec says link TRBs cannot have the chain bit
218
+
* set, but other sections talk about dealing with the chain bit set. This was
219
+
* fixed in the 0.96 specification errata, but we have to assume that all 0.95
220
+
* xHCI hardware can't handle the chain bit being cleared on a link TRB.
221
+
*
222
+
* On 0.95 and some 0.96 HCs the chain bit is set once at segment initalization
223
+
* and never changed here. On all others, modify it as requested by the caller.
224
+
*/
225
+
if (!xhci_link_chain_quirk(xhci, ring->type)) {
226
+
ring->enqueue->link.control &= cpu_to_le32(~TRB_CHAIN);
227
+
ring->enqueue->link.control |= cpu_to_le32(chain);
228
+
}
229
+
230
+
/* Give this link TRB to the hardware */
231
+
wmb();
232
+
ring->enqueue->link.control ^= cpu_to_le32(TRB_CYCLE);
233
+
234
+
/* Toggle the cycle bit after the last ring segment. */
235
+
if (link_trb_toggles_cycle(ring->enqueue))
236
+
ring->cycle_state ^= 1;
237
+
238
+
ring->enq_seg = ring->enq_seg->next;
239
+
ring->enqueue = ring->enq_seg->trbs;
240
+
241
+
trace_xhci_inc_enq(ring);
242
+
243
+
if (link_trb_count++ > ring->num_segs) {
244
+
xhci_warn(xhci, "Link TRB loop at enqueue\n");
245
+
break;
246
+
}
247
+
}
248
+
}
249
+
250
+
/*
207
251
* See Cycle bit rules. SW is the consumer for the event ring only.
208
252
*
209
253
* If we've just enqueued a TRB that is in the middle of a TD (meaning the
210
254
* chain bit is set), then set the chain bit in all the following link TRBs.
211
255
* If we've enqueued the last TRB in a TD, make sure the following link TRBs
212
256
* have their chain bit cleared (so that each Link TRB is a separate TD).
213
-
*
214
-
* Section 6.4.4.1 of the 0.95 spec says link TRBs cannot have the chain bit
215
-
* set, but other sections talk about dealing with the chain bit set. This was
216
-
* fixed in the 0.96 specification errata, but we have to assume that all 0.95
217
-
* xHCI hardware can't handle the chain bit being cleared on a link TRB.
218
257
*
219
258
* @more_trbs_coming: Will you enqueue more TRBs before calling
220
259
* prepare_transfer()?
···
262
223
bool more_trbs_coming)
263
224
{
264
225
u32 chain;
265
-
union xhci_trb *next;
266
-
unsigned int link_trb_count = 0;
267
226
268
227
chain = le32_to_cpu(ring->enqueue->generic.field[3]) & TRB_CHAIN;
269
228
···
270
233
return;
271
234
}
272
235
273
-
next = ++(ring->enqueue);
236
+
ring->enqueue++;
274
237
275
-
/* Update the dequeue pointer further if that was a link TRB */
276
-
while (trb_is_link(next)) {
277
-
278
-
/*
279
-
* If the caller doesn't plan on enqueueing more TDs before
280
-
* ringing the doorbell, then we don't want to give the link TRB
281
-
* to the hardware just yet. We'll give the link TRB back in
282
-
* prepare_ring() just before we enqueue the TD at the top of
283
-
* the ring.
284
-
*/
285
-
if (!chain && !more_trbs_coming)
286
-
break;
287
-
288
-
/* If we're not dealing with 0.95 hardware or isoc rings on
289
-
* AMD 0.96 host, carry over the chain bit of the previous TRB
290
-
* (which may mean the chain bit is cleared).
291
-
*/
292
-
if (!xhci_link_chain_quirk(xhci, ring->type)) {
293
-
next->link.control &= cpu_to_le32(~TRB_CHAIN);
294
-
next->link.control |= cpu_to_le32(chain);
295
-
}
296
-
/* Give this link TRB to the hardware */
297
-
wmb();
298
-
next->link.control ^= cpu_to_le32(TRB_CYCLE);
299
-
300
-
/* Toggle the cycle bit after the last ring segment. */
301
-
if (link_trb_toggles_cycle(next))
302
-
ring->cycle_state ^= 1;
303
-
304
-
ring->enq_seg = ring->enq_seg->next;
305
-
ring->enqueue = ring->enq_seg->trbs;
306
-
next = ring->enqueue;
307
-
308
-
trace_xhci_inc_enq(ring);
309
-
310
-
if (link_trb_count++ > ring->num_segs) {
311
-
xhci_warn(xhci, "%s: Ring link TRB loop\n", __func__);
312
-
break;
313
-
}
314
-
}
238
+
/*
239
+
* If we are in the middle of a TD or the caller plans to enqueue more
240
+
* TDs as one transfer (eg. control), traverse any link TRBs right now.
241
+
* Otherwise, enqueue can stay on a link until the next prepare_ring().
242
+
* This avoids enqueue entering deq_seg and simplifies ring expansion.
243
+
*/
244
+
if (trb_is_link(ring->enqueue) && (chain || more_trbs_coming))
245
+
inc_enq_past_link(xhci, ring, chain);
315
246
}
316
247
317
248
/*
···
3218
3213
static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
3219
3214
u32 ep_state, unsigned int num_trbs, gfp_t mem_flags)
3220
3215
{
3221
-
unsigned int link_trb_count = 0;
3222
3216
unsigned int new_segs = 0;
3223
3217
3224
3218
/* Make sure the endpoint has been added to xHC schedule */
···
3265
3261
}
3266
3262
}
3267
3263
3268
-
while (trb_is_link(ep_ring->enqueue)) {
3269
-
/* If we're not dealing with 0.95 hardware or isoc rings
3270
-
* on AMD 0.96 host, clear the chain bit.
3271
-
*/
3272
-
if (!xhci_link_chain_quirk(xhci, ep_ring->type))
3273
-
ep_ring->enqueue->link.control &=
3274
-
cpu_to_le32(~TRB_CHAIN);
3275
-
else
3276
-
ep_ring->enqueue->link.control |=
3277
-
cpu_to_le32(TRB_CHAIN);
3278
-
3279
-
wmb();
3280
-
ep_ring->enqueue->link.control ^= cpu_to_le32(TRB_CYCLE);
3281
-
3282
-
/* Toggle the cycle bit after the last ring segment. */
3283
-
if (link_trb_toggles_cycle(ep_ring->enqueue))
3284
-
ep_ring->cycle_state ^= 1;
3285
-
3286
-
ep_ring->enq_seg = ep_ring->enq_seg->next;
3287
-
ep_ring->enqueue = ep_ring->enq_seg->trbs;
3288
-
3289
-
/* prevent infinite loop if all first trbs are link trbs */
3290
-
if (link_trb_count++ > ep_ring->num_segs) {
3291
-
xhci_warn(xhci, "Ring is an endless link TRB loop\n");
3292
-
return -EINVAL;
3293
-
}
3294
-
}
3264
+
/* Ensure that new TRBs won't overwrite a link */
3265
+
if (trb_is_link(ep_ring->enqueue))
3266
+
inc_enq_past_link(xhci, ep_ring, 0);
3295
3267
3296
3268
if (last_trb_on_seg(ep_ring->enq_seg, ep_ring->enqueue)) {
3297
3269
xhci_warn(xhci, "Missing link TRB at end of ring segment\n");