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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <ME0P300MB05533B11B123B7C9188B699EA6CA2@ME0P300MB0553.AUSP300.PROD.OUTLOOK.COM>
Date: Thu, 6 Mar 2025 22:12:50 +0800
From: Junzhong Pan <panjunzhong@...look.com>
To: piyush.mehta@....com
Cc: gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
 linux-usb@...r.kernel.org, michal.simek@....com, 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]

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


Thanks!