>>>> +static int xhci_map_temp_buffer(struct usb_hcd *hcd, struct urb *urb)
>>>> +{
>>>> + void *temp;
>>>> + int ret = 0;
>>>> + unsigned int len;
>>>> + unsigned int buf_len;
>>>> + enum dma_data_direction dir;
>>>> + struct xhci_hcd *xhci;
>>>> +
>>>> + xhci = hcd_to_xhci(hcd);
>>>> + dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
>>>> + buf_len = urb->transfer_buffer_length;
>>>> +
>>>> + temp = kzalloc_node(buf_len, GFP_ATOMIC,
>>>> + dev_to_node(hcd->self.sysdev));
>>>> + if (!temp) {
>>>> + xhci_warn(xhci, "Failed to create temp buffer, HC may fail\n");
>>>
>>> Didn't kzalloc just warn before this?
>>>
>> Yes, It should.
>
> Then do not spit out another message please.
>
>>> And isn't this whole thing going to cause a lot more memory allocations
>>> per submission than before?
>>>
>> If buffer sizes for SG list are very small (less than MPS size per TRB_CACHE_SIZE)
>> yes, it will have more memory allocations.
>
> That's not good :(
>
I actually recommended this after looking at the real numbers.
It was explained to me that the Synopsis xHC has a flaw that it will hang if its
TRB cache contains 16 chained TRBs (no ending TRB), and the combined TRB size
is _less_ than 1024 bytes.
So this only happens if a URB has a sg list with more than 16 entries whose
total size is less than 1024 bytes.
I was told this has not been seen ever in real life usage.
So in the unlikey case this is ever triggered we will end up allocating a small
bounce buffer, probably around 1024 bytes, and copy the data over from the sg-list.
(for HS speeds limits are 8 chained TRBs and 512 bytes)
- Mathias
