public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Yongchao Wu <yongchao.wu@autochips.com>
To: Pawel Laszczak <pawell@cadence.com>,
	"Peter Chen (CIX)" <peter.chen@kernel.org>
Cc: "rogerq@kernel.org" <rogerq@kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt
Date: Tue, 28 Apr 2026 22:48:57 +0800	[thread overview]
Message-ID: <49e3cff9-9ace-4eed-aa2c-7f83825c44ee@autochips.com> (raw)
In-Reply-To: <PH7PR07MB95388984DB7A5265770CEE58DD372@PH7PR07MB9538.namprd07.prod.outlook.com>

On 4/28/2026 5:58 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.

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
>> Best regards,
>> Yongchao


      reply	other threads:[~2026-04-28 14:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23 16:06 [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt Yongchao Wu
2026-04-27  1:22 ` Peter Chen (CIX)
2026-04-27  9:01   ` Pawel Laszczak
2026-04-27 22:59     ` Peter Chen (CIX)
2026-04-27 23:59       ` Yongchao Wu
2026-04-28  9:58         ` Pawel Laszczak
2026-04-28 14:48           ` Yongchao Wu [this message]

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=49e3cff9-9ace-4eed-aa2c-7f83825c44ee@autochips.com \
    --to=yongchao.wu@autochips.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=pawell@cadence.com \
    --cc=peter.chen@kernel.org \
    --cc=rogerq@kernel.org \
    --cc=stable@vger.kernel.org \
    /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