linux-kernel - Re: [PATCH V2] usb: chipidea: udc: Add revision check of 2.20[CI_REVISION

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <274e6669-adf1-4bb3-9237-2313b0d7fe09@amd.com>
Date: Thu, 6 Mar 2025 15:22:16 +0100
From: Michal Simek <michal.simek@....com>
To: Junzhong Pan <panjunzhong@...look.com>,
 Radhey Shyam Pandey <radhey.shyam.pandey@....com>
Cc: gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
 linux-usb@...r.kernel.org, peter.chen@...nel.org,
 radhey.shyam.pandey@....com, siva.durga.prasad.paladugu@....com
Subject: Re: [PATCH V2] usb: chipidea: udc: Add revision check of
 2.20[CI_REVISION_22]

+ Radhey.

On 3/6/25 15:12, Junzhong Pan wrote:
> Hi Piyush,
> 
>> Issue: Adding a dTD to a Primed Endpoint May Not Get Recognized with
>> revision 2.20a.
>>
>> There is an issue with the add dTD tripwire semaphore (ATDTW bit in
>> USBCMD register) that can cause the controller to ignore a dTD that is
>> added to a primed endpoint. When this happens, the software can read
>> the tripwire bit and the status bit at '1' even though the endpoint is
>> unprimed.
>> This issue observed with the Windows host machine.
> 
> Sorry to dig through this old patch email.
> 
> May I ask what does **the scene look like (bus condition/dtd status)**
> when this issue observed with the Windows host machine occurs?
> 
> I want to know if it's relevant to an issue I encountered recently.
> 
> I met this a tricky issue with an soc have a marvel udc (driven by
> mv_udc_core.c, it's a same chipidea IP accordingly) when running rndis
> gadget with the Windows host machine.
> 
> When the rndis gadget running for a long time (randomly), the udc would
> suddenly stopped and no longger response to IN token sent from the host.
> 
> The bus trace looks like this:
> 
> BULK IN:
> 	IN
> 	DATA0 120 Bytes
> 	ACK
> BULK OUT:
> 	OUT
> 	DATA1 98 Bytes
> 	NYET
> BULK IN	??
> 	IN NAK
> 	IN NAK
> 	IN NAK
> 	.....
> 	IN !!Propagated Error!!(Turnaround/Timeout Error)
> 
> 
> 
> The driver doesn't receive any further interrupts when it stopped,
> though the IN 102 Bytes transaction is finished on the bus, but the
> TD_TOTAL_BYTES of that dTd is never updated.
> 
>   ep num: 1 dir: 1(in)
>    qh of current ep: 1 dir: 1(in)
>      qh maxpacklen: 0x22000000, token: 0x668080
>      qh td_dma curr_dtd_ptr: 0x658403c0, next_dtd_ptr: 0x1
>      qh buf p0: 0x672dcde, p1: 0x672e378, p2: 0x672f000, p3: 0x6730000, p4: 0x6731000
>    req 0xd81e245540 len: **102**, first_dtd: 0x658403c0, last_dtd: 0x658403c0, dtd_count: 1, actual: 102
>       [qh->curr_dtd_ptr]dtd dma 0x658403c0, token: 0x668080, err: 0x0, dtd_nxt: 0x65840540
>           buf p0:0x672dcde p1:0x672e000 p2:0x672f000 p3:0x6730000 p4:0x6731000 scr: 0x0
>    req 0xd81e245b40 len: 1558, first_dtd: 0x65840540, last_dtd: 0x65840540, dtd_count: 1, actual: 1558
>       [---]dtd dma 0x65840540, token: 0x6168080, err: 0x0, dtd_nxt: 0x65840080
>           buf p0:0x20ce50de p1:0x20ce6000 p2:0x20ce7000 p3:0x20ce8000 p4:0x20ce9000 scr: 0x0
> ......
> 
> epnak: 0x00070003
> epsetupstat: 0x00000000
> epprime: 0x00000000
> epflush: 0x00000000
> epstatus: 0x00020002
> 

Piyush is no longer with us but Radhey will take care about this.

Thanks,
Michal