Re: [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt

[Yongchao Wu <yongchao.wu@autochips.com>]

On 5/4/2026 5:15 PM, Pawel Laszczak wrote:
>>>
>>>>
>>>> On 26-04-27 09:01:47, Pawel Laszczak wrote:
>>>>>>
>>>>>>
>>>>>> On 26-04-24 00:06:01, Yongchao Wu wrote:
>>>>>>> According to the cdns3 datasheet, the EPRST (Endpoint Reset)
>>>>>>> command causes the DMA engine to reposition its internal pointer
>>>>>>> to the next Transfer Descriptor (TD) if it was already processing one.
>>>>>>>
>>>>>>> This issue is consistently observed during the ADB identification
>>>>>>> process on macOS hosts, where the host issues a Clear_Halt. Although
>>>>>>> commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before
>> reset
>>>>>>> reset endpoint") attempted to avoid DMA advance by toggling the
>>>>>>> cycle bit, trace logs show that on certain hosts like macOS, the
>>>>>>> DMA pointer
>>>>>>> (EP_TRADDR) still shifts after EPRST:
>>>>>>>
>>>>>>>    cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out)
>>>>>>>    cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030  <- Should be
>> f9c04000
>>>>>>>    cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384
>>>>>>>
>>>>>>> As shown above, the DMA pointer jumped to index 3 (offset 0x30),
>>>>>>> causing the controller to skip the initial TRBs of the request.
>>>>>>> This leads to data misalignment and ADB protocol hangs on macOS.
>>>>>>
>>>>>> Pawel, Is it a hardware issue? The cycle bit has already been
>>>>>> toggled before the endpoint has been reset, why the DMA pointer still
>> advances?
>>>>>
>>>>> Yongchao, could you confirm if the TD consists of three TRBs?
>>>> In our case, each TD consists of 4 TRBs.
>>>> The DMA pointer appears to advance within the same TD after EPRST.
>>>>
>>>> Each 16KB request is split into 4 TRBs (4KB each):
>>>> - TRB0 - TRB2: CHAIN
>>>> - TRB3: IOC (last TRB of the TD)
>>>>
>>>> After enqueue, the initial EP_TRADDR points to the first TRB:
>>>>    EP_TRADDR = 0xf9c04000 (TRB0)
>>>>
>>>> After Clear_Halt (EPRST), it becomes:
>>>>    EP_TRADDR = 0xf9c04030 (TRB3)
>>>>
>>>> Since each TRB is 12 bytes, the offset 0x30 corresponds to 4 TRBs.
>>>> This indicates that after EPRST, the DMA pointer skipped the entire
>>>> current Request and jumped directly to the start of the next Request
>>>> at 0xf9c04030
>>>>
>>>> Below is the relevant trace (trimmed):
>>>>
>>>> // enqueue request (16KB -> 4 TRBs)
>>>> cdns3_prepare_trb: dma buf: 0xf7abc000, size: 4096, ctrl: 0x00200415
>>>> cdns3_prepare_trb: dma buf: 0xf7abd000, size: 4096, ctrl: 0x00000415
>>>> cdns3_prepare_trb: dma buf: 0xf7abe000, size: 4096, ctrl: 0x00000415
>>>> cdns3_prepare_trb: dma buf: 0xf7abf000, size: 4096, ctrl: 0x00000425
>>>>
>>>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04000
>>>>
>>>> // Clear_Halt
>>>> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out)
>>>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030
>>>>
>>>
>>> Can you confirm whether the host had already sent some data for this
>>> TD prior to the endpoint reset operation?
>>>
>>
>> I confirm that the host sent no data prior to or during the EPRST operation.
> 
> According to the specification, the controller may fetch TRB descriptors after
> the endpoint has been initialized.
> In complex Transfer Descriptors (TDs) consisting of several TRBs with the CH=1
> bit set, the controller may fetch additional TRBs because it treats them as a
> single logical entity.
> 
> I have not been able to determine exactly how many TRBs can be prefetched
> in such a situation. 
> 
> According to the description of the EPRST bit:
> After endpoint reset the software is responsible for it to re-set the Endpoint
> TRADDR.
> 
> This fix looks correct to me, 
> 
> Can you confirm which version of controller do you have in usb_cap6 register?
> 
> Pawel

Thanks for the clarification.

I confirm that the version read from the usb_cap6 register is 0002450d.

Best regards,
Yongchao Wu

>>
>> TotalPhase Trace:
>> 0,HS,2700,0:06.078.671,2.057.666 ms,0 B,,13,00,Set
>> Configuration,Configuration=1
>> 0,HS,2710,0:06.080.811,1.125.266 ms,,,,,[10 SOF],[Frames: 1243.7 - 1245.0]
>> 0,HS,2711,0:06.080.955,992.550 us,2 B,,13,00,Get String Descriptor,Index=5
>> Length=2
>> 0,HS,2733,0:06.082.061,125.083 us,,,,,[2 SOF],[Frames: 1245.1 - 1245.2]
>> 0,HS,2734,0:06.082.119,104.566 us,28 B,,13,00,Get String Descriptor,Index=5
>> Length=28
>> 0,HS,2756,0:06.082.311,355.935.283 ms,,,,,[2848 SOF],[Frames: 1245.3 -
>> 1601.2]
>> 0,HS,2757,0:06.438.196,105.033 us,4 B,,13,00,Get String Descriptor,Index=0
>> Length=256
>> 0,HS,2778,0:06.438.371,875.233 us,,,,,[8 SOF],[Frames: 1601.3 - 1602.2] //1.
>> Host issues Clear_Halt
>> 0,HS,2779,0:06.439.278,51.433 us,0 B,,13,00,Clear Endpoint Feature,Halt
>> Endpoint 01 OUT
>> 0,HS,2789,0:06.439.371,500.150 us,,,,,[5 SOF],[Frames: 1602.3 - 1602.7]
>> 0,HS,2790,0:06.439.874,51.416 us,0 B,,13,00,Clear Endpoint Feature,Halt
>> Endpoint 01 IN
>> 0,HS,2800,0:06.439.996,250.116 us,,,,,[3 SOF],[Frames: 1603.0 - 1603.2] //2.
>> First OUT transaction happens
>> 0,HS,2801,0:06.440.350,1.066 us,24 B,,13,01,OUT txn,43 4E 58 4E 01 00 00 01
>> 00 00 10 00..
>> 0,HS,2805,0:06.440.371,66 ns,,,,,[1 SOF],[Frame: 1603.3]
>> 0,HS,2806,0:06.440.453,4.283 us,218 B,,13,01,OUT txn,68 6F 73 74 3A 3A 66 65
>> 61 74 75 72..
>>
>>> Pawel
>>>
>>>> Best regards,
>>>> Yongchao

>