Re: Maintainer of ChipID

Re: Maintainer of ChipID

[Peter Chen (CIX)]

On 25-11-26 08:15:50, Uri.Trichter@nuvoton.com wrote:
> Hi Peter
> 
> Are you the maintainer for ChipID USB device driver ?
> If so, we would like a quick help from you

Hi Uri,

You could send your question, and see if we could help you.

-- 

Best regards,
Peter

RE: Maintainer of ChipID

[tomer.maimon]

Hi Peter,

Thanks for your prompt reply and appreciate your assistance.

We are using UDC Chipidea driver version 25 (ci_hdrc_npcm) in NPCM BMC SoC and we are facing UDC DMA synchronization issue
In the UDC Chipidea driver there is WA for version 22 and 24 that running reprime_dtd, not sure why
https://elixir.bootlin.com/linux/v6.18-rc7/source/drivers/usb/chipidea/udc.c#L840

Do you know if there are any errata list for in UDC Chipidea version25?
Does the UDC Chipidea driver covering version 25 as well?

Thanks,

Tomer

-----Original Message-----
From: Peter Chen (CIX) <peter.chen@kernel.org>
Sent: Thursday, 27 November 2025 4:46
To: IV00 Uri Trichter <Uri.Trichter@nuvoton.com>
Cc: IS20 Tomer Maimon <tomer.maimon@nuvoton.com>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org
Subject: Re: Maintainer of ChipID

CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.


On 25-11-26 08:15:50, Uri.Trichter@nuvoton.com wrote:
> Hi Peter
>
> Are you the maintainer for ChipID USB device driver ?
> If so, we would like a quick help from you

Hi Uri,

You could send your question, and see if we could help you.

--

Best regards,
Peter
________________________________
________________________________
 The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

Re: Maintainer of ChipID

[Peter Chen (CIX)]

On 25-11-27 17:13:40, tomer.maimon@nuvoton.com wrote:
> Hi Peter,
> 
> Thanks for your prompt reply and appreciate your assistance.
> 
> We are using UDC Chipidea driver version 25 (ci_hdrc_npcm) in NPCM BMC SoC and we are facing UDC DMA synchronization issue
> In the UDC Chipidea driver there is WA for version 22 and 24 that running reprime_dtd, not sure why
> https://elixir.bootlin.com/linux/v6.18-rc7/source/drivers/usb/chipidea/udc.c#L840
> 
> Do you know if there are any errata list for in UDC Chipidea version25?
> Does the UDC Chipidea driver covering version 25 as well?

Add Yang Xu who may use chipidea IP currently, and describes your
problems in detail please, we may has some ideas.

I think current chipidea driver has covered version 25, and Synopsys acquired
Chipidea IP more than 10 years ago, you may get errata list from
Synopsys.

Peter
> 
> -----Original Message-----
> From: Peter Chen (CIX) <peter.chen@kernel.org>
> Sent: Thursday, 27 November 2025 4:46
> To: IV00 Uri Trichter <Uri.Trichter@nuvoton.com>
> Cc: IS20 Tomer Maimon <tomer.maimon@nuvoton.com>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org
> Subject: Re: Maintainer of ChipID
> 
> CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.
> 
> 
> On 25-11-26 08:15:50, Uri.Trichter@nuvoton.com wrote:
> > Hi Peter
> >
> > Are you the maintainer for ChipID USB device driver ?
> > If so, we would like a quick help from you
> 
> Hi Uri,
> 
> You could send your question, and see if we could help you.
> 
> --
> 
> Best regards,
> Peter
> ________________________________
> ________________________________
>  The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

-- 

Best regards,
Peter

RE: Maintainer of ChipID

[tomer.maimon]

Hi Peter,

Thanks for your prompt reply.

In rare cases, during RX transactions, the UDC driver receives an interrupt that is supposed to indicate the completion of a DMA receive operation and that the data is now available in memory. However, the ACTION (or ACTIVE) bit still indicates that the DMA transfer is ongoing.
If the driver enters a loop waiting for this Active bit become zero and indicate the DAM action finish to the handler becomes stuck indefinitely..
Are you familiar with this behavior?

Besides the ACTIVE bit, are there any other status bits that reliably indicate the actual end of a DMA receive transaction?

Thanks,

Tomer

-----Original Message-----
From: Peter Chen (CIX) <peter.chen@kernel.org>
Sent: Friday, 28 November 2025 3:02
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com>
Cc: IV00 Uri Trichter <Uri.Trichter@nuvoton.com>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org; xu.yang_2@nxp.com
Subject: Re: Maintainer of ChipID

CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.


On 25-11-27 17:13:40, tomer.maimon@nuvoton.com wrote:
> Hi Peter,
>
> Thanks for your prompt reply and appreciate your assistance.
>
> We are using UDC Chipidea driver version 25 (ci_hdrc_npcm) in NPCM BMC
> SoC and we are facing UDC DMA synchronization issue In the UDC
> Chipidea driver there is WA for version 22 and 24 that running
> reprime_dtd, not sure why
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felix
> ir.bootlin.com%2Flinux%2Fv6.18-rc7%2Fsource%2Fdrivers%2Fusb%2Fchipidea
> %2Fudc.c%23L840&data=05%7C02%7Ctomer.maimon%40nuvoton.com%7Cfdcb3d6e98
> 844998ee2d08de2e19c219%7Ca3f24931d4034b4a94f17d83ac638e07%7C0%7C0%7C63
> 8998885355834139%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> %7C%7C&sdata=XVY3UIT%2B2ffESLp6Oor090sKjcTgYFRJBaNTqCAOCCs%3D&reserved
> =0
>
> Do you know if there are any errata list for in UDC Chipidea version25?
> Does the UDC Chipidea driver covering version 25 as well?

Add Yang Xu who may use chipidea IP currently, and describes your problems in detail please, we may has some ideas.

I think current chipidea driver has covered version 25, and Synopsys acquired Chipidea IP more than 10 years ago, you may get errata list from Synopsys.

Peter
>
> -----Original Message-----
> From: Peter Chen (CIX) <peter.chen@kernel.org>
> Sent: Thursday, 27 November 2025 4:46
> To: IV00 Uri Trichter <Uri.Trichter@nuvoton.com>
> Cc: IS20 Tomer Maimon <tomer.maimon@nuvoton.com>; IS20 Avi Fishman
> <Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org
> Subject: Re: Maintainer of ChipID
>
> CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.
>
>
> On 25-11-26 08:15:50, Uri.Trichter@nuvoton.com wrote:
> > Hi Peter
> >
> > Are you the maintainer for ChipID USB device driver ?
> > If so, we would like a quick help from you
>
> Hi Uri,
>
> You could send your question, and see if we could help you.
>
> --
>
> Best regards,
> Peter
> ________________________________
> ________________________________
>  The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

--

Best regards,
Peter
________________________________
________________________________
 The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

Re: Maintainer of ChipID

[Xu Yang]

On Mon, Dec 01, 2025 at 01:59:21PM +0000, tomer.maimon@nuvoton.com wrote:
> Hi Peter,
> 
> Thanks for your prompt reply.
> 
> In rare cases, during RX transactions, the UDC driver receives an interrupt that is supposed to indicate the completion of a DMA receive operation and that the data is now available in memory. However, the ACTION (or ACTIVE) bit still indicates that the DMA transfer is ongoing.

Which interrupt? Do you mean USBSTS.UI? What about ENDPTCOMPLETE?
How do you sure that the dTD is still doing DMA transfer rather than
has not start transfer yet? Do you know the contents before and after
this dTD transfer?

> If the driver enters a loop waiting for this Active bit become zero and indicate the DAM action finish to the handler becomes stuck indefinitely..
> Are you familiar with this behavior?

What is the behavior of the host in this case?

> 
> Besides the ACTIVE bit, are there any other status bits that reliably indicate the actual end of a DMA receive transaction?

Maybe no other status bit for DMA operation. 

Thanks,
Xu Yang

> 
> Thanks,
> 
> Tomer

RE: [EXT] RE: Maintainer of ChipID

[tomer.maimon]

[-- Attachment #1.1.1: Type: text/plain, Size: 51721 bytes --]

Hi Xu,



I have also attached another test case that reproduces the issue; I would appreciate it if you could run it on your end.



Use these 3 scripts:



SoC:

  1.  Login to soc – run socstress_soc.sh at the background twice or multiple times to increase the net traffic (( each run will have 3 threads, normally I run 4 times give 12 threads which will be enough ping traffic)
  2.  Change the mode to executable: chmod +x socstress_soc.sh



root@localhost:/vol/data/persistent#./socstress_soc.sh<mailto:root@localhost:/vol/data/persistent#./socstress_soc.sh> & (for stos)

root@localhost:/vol/data/persistent#./socstress_soc.sh<mailto:root@localhost:/vol/data/persistent#./socstress_soc.sh> & (for stos)

root@localhost:/vol/data/persistent#./socstress_soc.sh<mailto:root@localhost:/vol/data/persistent#./socstress_soc.sh> & (for stos)

root@localhost:/vol/data/persistent#./socstress_soc.sh<mailto:root@localhost:/vol/data/persistent#./socstress_soc.sh> & (for stos)





BMC:



  1.  Login to the bmc – run socstress_bmc.sh at the background twice or multiple times ( each run will have 3 threads, normally I run 4 times give 12 threads) to increase the net traffic

admin@:~$./socstress_bmc.sh<mailto:admin@:~$./socstress_bmc.sh> &

admin@:~$./socstress_bmc.sh<mailto:admin@:~$./socstress_bmc.sh> &

admin@:~$./socstress_bmc.sh<mailto:admin@:~$./socstress_bmc.sh> &

admin@:~$./socstress_bmc.sh<mailto:admin@:~$./socstress_bmc.sh> &





  1.  Run ddrstress.sh only once, if you run twice, there will be no space left and the previous run will also fail

admin@:~$./ddrstress.sh<mailto:admin@:~$./ddrstress.sh> &



BTW, can you share on which boards you are running the tests.



Thanks,



Tomer

From: IS20 Tomer Maimon
Sent: Monday, January 12, 2026 6:42 PM
To: 'Xu Yang' <xu.yang_2@nxp.com>
Cc: Peter Chen (CIX) <peter.chen@kernel.org>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org
Subject: RE: [EXT] RE: Maintainer of ChipID

Hi Xu,

Thanks for running the test, can I ask which Chipidea revision you have tested?

Tomer

From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Monday, January 12, 2026 7:49 AM
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID

CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.

Hi Tomer,

I tried the test for more than 4 hours with kernel version v5.10, v5.15, v6.6 and v6.12 respectively, but I don’t see any issue on my side. iperf3 are still running and printing report on two boards.

Thanks,
Xu Yang

From: tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Sent: Friday, January 2, 2026 3:05 AM
To: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>; Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

Hi Xu,

Sorry for the late reply and HAPPY NEW YEAR!

We are setting two EVB boards

  1.  EVB1 – UDC
  2.  EVB2 – Host

On EVB1
Setting RNDIS CDC ethernet gadget + ip address
mount -t configfs none /sys/kernel/config
mkdir -p /sys/kernel/config/usb_gadget/g1
cd /sys/kernel/config/usb_gadget/g1
echo "0x1d6b" > idVendor
echo "0x0104" > idProduct
mkdir strings/0x409
echo "My Manufacturer" > strings/0x409/manufacturer
echo "ECM Gadget" > strings/0x409/product
mkdir configs/c.1
mkdir functions/ecm.usb0
ln -s functions/ecm.usb0 configs/c.1/
echo "ci_hdrc.0" > UDC
ifconfig usb0 192.168.7.2 netmask 255.255.255.0 up

On EVB2
Set usb0 IP address.
ifconfig usb0 192.168.7.1 netmask 255.255.255.0 up

To reproduce the failure where UDC QH and TD are allocating memory from DDR, please follow these steps run in iperf3:
EVB1 On the UDC side (192.168.7.2):
iperf3 -s --port 5022 &
iperf3 -s --port 5021 &
iperf3 -c 127.0.0.1 -t 0 --port 5021 > /dev/null &

EVB2 On the Host side (192.168.7.1):
iperf3 -c 192.168.7.2 --bidir -t 86400 -i 1 --port 5022

The failure typically occurs within 1–2 hours.

Thanks,

Tomer

From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Tuesday, 23 December 2025 5:26
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID

CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.

Hi Tomer,

For your issue, please check the state of ENDPTPRIME, ENDPTSTAT while HW req #10 and #11 are enqueued.
It seems like both ENDPTPRIME and ENDPTSTAT are cleared so that req #11 is force set as queue head. If so, you need to check why endpoint becomes not ready.

For your questions:
1.  The following picture shows the detail steps to add a TD, and the driver follows these rules.
The ATDTW bit can’t be read as 1 (after write 1) during the device controller finishing current dTD and switch to next dTD. Otherwise, ATDTW bit can be read as 1 at other times.
Based on this, we need check ENDPTSTAT bit to decide if the new dTD should be set as queue head or keep at the tail of the list.

[cid:image001.png@01DC83FC.8CBFF5A0]
2. For the “Remark” in ENDPSTAT register, we confirm that it can’t be cleared during the HW re-priming operation unless the current dTD is the last one. Therefore, the “Remark” seems like a legacy thing.
3. When you flush the endpoint, the device controller will update the queue head as usual. If the dTD set IOC, the irq will be fired. To resume it, you need to prime the endpoint again.
4. If the endpoint is already primed and executing a dTD, the controller will continue to execute the current dTD and the prime operation should be invalid in HW. But in SW, if you call reprime_dtd() the
next link pointer will be updated based on the input parameter.

Could you share your test steps? And how do you do stress on the USB interface? Just want to check if I can reproduce the issue.

Thanks,
Xu Yang

From: tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Sent: Thursday, December 18, 2025 7:49 PM
To: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>; Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID

Hi Xu,



We suspect the TX stalls happens because one of the TD did not get transferred and the Queue Head move passed it. Thus, it did in fact got skipped.



Let's start with the latest debug dump of requests node after all my debug additions:



root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3#<mailto:root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3>  cat requests

RX Endpoint 0 Information Dump:



-------------------------------------------------

RX Endpoint 1 Information Dump:



HW Req #0 (ptr=0xffffff8023bc7100):

  struct usb_request (ptr=0xffffff8023bc7100) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1534

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841400 RX Length=1534 Buffer=0x12AE9740

   0000:    7B841280

   0001:    05FE8080

   0002:    12AE9740

   0003:    12AEA000

   0004:    12AEB000

   0005:    12AEC000

   0006:    12AED000



HW Req #1 (ptr=0xffffff8023bc7000):

  struct usb_request (ptr=0xffffff8023bc7000) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1534

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841280 RX Length=1534 Buffer=0x12AE8FC0

   0000:    7B841300

   0001:    05FE8080

   0002:    12AE8FC0

   0003:    12AE9000

   0004:    12AEA000

   0005:    12AEB000

   0006:    12AEC000



HW Req #2 (ptr=0xffffff8025c48e00):

  struct usb_request (ptr=0xffffff8025c48e00) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1534

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841300 RX Length=1534 Buffer=0x12AE8840

   0000:    7B841040

   0001:    05FE8080

   0002:    12AE8840

   0003:    12AE9000

   0004:    12AEA000

   0005:    12AEB000

   0006:    12AEC000



HW Req #3 (ptr=0xffffff8023bc7800):

  struct usb_request (ptr=0xffffff8023bc7800) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1534

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841040 RX Length=1534 Buffer=0x12AE80C0

   0000:    7B841080

   0001:    05FE8080

   0002:    12AE80C0

   0003:    12AE9000

   0004:    12AEA000

   0005:    12AEB000

   0006:    12AEC000



HW Req #4 (ptr=0xffffff8023bc7700):

  struct usb_request (ptr=0xffffff8023bc7700) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1534

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841080 RX Length=1534 Buffer=0x2C0D78C0

   0000:    7B8410C0

   0001:    05FE8080

   0002:    2C0D78C0

   0003:    2C0D8000

   0004:    2C0D9000

   0005:    2C0DA000

   0006:    2C0DB000



HW Req #5 (ptr=0xffffff8023bc7600):

  struct usb_request (ptr=0xffffff8023bc7600) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1534

      .num_mapped_sqs=0

  };



  EP=01: TD=7B8410C0 RX Length=1534 Buffer=0x2C0D7140

   0000:    7B841100

   0001:    05FE8080

   0002:    2C0D7140

   0003:    2C0D8000

   0004:    2C0D9000

   0005:    2C0DA000

   0006:    2C0DB000



HW Req #6 (ptr=0xffffff8023bc7500):

  struct usb_request (ptr=0xffffff8023bc7500) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1534

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841100 RX Length=1534 Buffer=0x2C0D69C0

   0000:    7B841140

   0001:    05FE8080

   0002:    2C0D69C0

   0003:    2C0D7000

   0004:    2C0D8000

   0005:    2C0D9000

   0006:    2C0DA000



HW Req #7 (ptr=0xffffff8023bc7400):

  struct usb_request (ptr=0xffffff8023bc7400) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1534

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841140 RX Length=1534 Buffer=0x2C0D6240

   0000:    7B841180

   0001:    05FE8080

   0002:    2C0D6240

   0003:    2C0D7000

   0004:    2C0D8000

   0005:    2C0D9000

   0006:    2C0DA000



HW Req #8 (ptr=0xffffff8023bc7300):

  struct usb_request (ptr=0xffffff8023bc7300) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1534

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841180 RX Length=1534 Buffer=0x2C0D5AC0

   0000:    7B8411C0

   0001:    05FE8080

   0002:    2C0D5AC0

   0003:    2C0D6000

   0004:    2C0D7000

   0005:    2C0D8000

   0006:    2C0D9000



HW Req #9 (ptr=0xffffff8023bc7200):

  struct usb_request (ptr=0xffffff8023bc7200) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1534

      .num_mapped_sqs=0

  };



  EP=01: TD=7B8411C0 RX Length=1534 Buffer=0x2C0D5340

   0000:    00000001

   0001:    05FE8080

   0002:    2C0D5340

   0003:    2C0D6000

   0004:    2C0D7000

   0005:    2C0D8000

   0006:    2C0D9000



-------------------------------------------------

RX Endpoint 2 Information Dump:



-------------------------------------------------

TX Endpoint 0 Information Dump:



-------------------------------------------------

TX Endpoint 1 Information Dump:



HW Req #10 (ptr=0xffffff8025c44d00):

  struct usb_request (ptr=0xffffff8025c44d00) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=98

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841380 TX Length=98 Buffer=0x0F6E9300

   0000:    7B841240

   0001:    00628080

   0002:    0F6E9300 <--- Notice this value is the same af the buffer address. This means the TD got skipped.

   0003:    0F6EA000

   0004:    0F6EB000

   0005:    0F6EC000

   0006:    0F6ED000



HW Req #11 (ptr=0xffffff8025c44c00):

  struct usb_request (ptr=0xffffff8025c44c00) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=98

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841240 TX Length=98 Buffer=0x19CAFD00

   0000:    7B841340

   0001:    00008000

   0002:    19CAFD62

   0003:    19CB055F

   0004:    19CB1000

   0005:    19CB2000

   0006:    19CB3000



HW Req #12 (ptr=0xffffff8025c44f00):

  struct usb_request (ptr=0xffffff8025c44f00) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=98

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841340 TX Length=98 Buffer=0x216BEB80

   0000:    7B8413C0

   0001:    00008000

   0002:    216BEBE2

   0003:    216BF55F

   0004:    216C0000

   0005:    216C1000

   0006:    216C2000



HW Req #13 (ptr=0xffffff8025c44e00):

  struct usb_request (ptr=0xffffff8025c44e00) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=98

      .num_mapped_sqs=0

  };



  EP=01: TD=7B8413C0 TX Length=98 Buffer=0x216F3100

   0000:    7B841480

   0001:    00008000

   0002:    216F3162

   0003:    216F456B

   0004:    216F5000

   0005:    216F6000

   0006:    216F7000



HW Req #14 (ptr=0xffffff8025c44b00):

  struct usb_request (ptr=0xffffff8025c44b00) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1514

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841480 TX Length=1514 Buffer=0x2AC74000

   0000:    7B8414C0

   0001:    00008000

   0002:    2AC745EA

   0003:    2AC7556B

   0004:    2AC76000

   0005:    2AC77000

   0006:    2AC78000



HW Req #15 (ptr=0xffffff8025c44a00):

  struct usb_request (ptr=0xffffff8025c44a00) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1514

      .num_mapped_sqs=0

  };



  EP=01: TD=7B8414C0 TX Length=1514 Buffer=0x2AC77800

   0000:    7B841500

   0001:    00008000

   0002:    2AC77DEA

   0003:    2AC78583

   0004:    2AC79000

   0005:    2AC7A000

   0006:    2AC7B000



HW Req #16 (ptr=0xffffff8025c44900):

  struct usb_request (ptr=0xffffff8025c44900) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1514

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841500 TX Length=1514 Buffer=0x2AC73800

   0000:    7B841540

   0001:    00008000

   0002:    2AC73DEA

   0003:    2AC74590

   0004:    2AC75000

   0005:    2AC76000

   0006:    2AC77000



HW Req #17 (ptr=0xffffff8025c44800):

  struct usb_request (ptr=0xffffff8025c44800) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1514

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841540 TX Length=1514 Buffer=0x2AC73000

   0000:    7B841580

   0001:    00008000

   0002:    2AC735EA

   0003:    2AC7459C

   0004:    2AC75000

   0005:    2AC76000

   0006:    2AC77000



HW Req #18 (ptr=0xffffff8025c44700):

  struct usb_request (ptr=0xffffff8025c44700) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=1514

      .num_mapped_sqs=0

  };



  EP=01: TD=7B841580 TX Length=1514 Buffer=0x2AC75000

   0000:    7B8415C0

   0001:    00008000

   0002:    2AC755EA

   0003:    2AC765A8

   0004:    2AC77000

   0005:    2AC78000

   0006:    2AC79000



HW Req #19 (ptr=0xffffff8025c44600):

  struct usb_request (ptr=0xffffff8025c44600) = {

      .status=-114

      .complete=(Registered)

      .actual=0

      .length=98

      .num_mapped_sqs=0

  };



  EP=01: TD=7B8415C0 TX Length=98 Buffer=0x216F3980

   0000:    00000001

   0001:    00008000

   0002:    216F39E2

   0003:    216F45B5

   0004:    216F5000

   0005:    216F6000

   0006:    216F7000



-------------------------------------------------

TX Endpoint 2 Information Dump:



-------------------------------------------------



Hardware request #10 (highlighted in yellow above) reflects a single USB request (gadget level) from the higher layers. All Hardware request reflect a single USB request (i.e., the enqueue endpoint function call from higher layer). In this case, it's the USB gadget ethernet. The USB gadget ethernet makes a single USB request per ethernet packet. This is why you see a single TD per request since the size of a standard ethernet packet will always fit in a single TD. You need more than 20KB in size for a USB request to have more than one dTD.



Hardware request #10 is the one that got skipped.



To understand how, let's look at ChipIdea's driver's s core enqueue function:



static int _hardware_enqueue(struct ci_hw_ep *hwep, struct ci_hw_req *hwreq)

{

      struct ci_hdrc *ci = hwep->ci;

      int ret = 0;

      struct td_node *firstnode, *lastnode;



      /* don't queue twice */

      if (hwreq->req.status == -EALREADY)

            return -EALREADY;



      hwreq->req.status = -EALREADY;



      ret = usb_gadget_map_request_by_dev(ci->dev->parent,

                                  &hwreq->req, hwep->dir);

      if (ret)

            return ret;



      if (((u32) hwreq->req.buf) & 0x3) {

            hwep->usb_request_buf_unaligned++;

      }



      if (hwreq->req.num_mapped_sgs)

            ret = prepare_td_for_sg(hwep, hwreq);

      else

            ret = prepare_td_for_non_sg(hwep, hwreq);



      if (ret)

            return ret;



      lastnode = list_entry(hwreq->tds.prev,

            struct td_node, td);



      lastnode->ptr->next = cpu_to_le32(TD_TERMINATE);

      if (!hwreq->req.no_interrupt)

            lastnode->ptr->token |= cpu_to_le32(TD_IOC);



      list_for_each_entry_safe(firstnode, lastnode, &hwreq->tds, td)

            trace_ci_prepare_td(hwep, hwreq, firstnode);



      firstnode = list_first_entry(&hwreq->tds, struct td_node, td);   ---------> Ref-A-Code



      wmb();



      hwreq->req.actual = 0;

      if (!list_empty(&hwep->qh.queue)) {

            struct ci_hw_req *hwreqprev;

            int n = hw_ep_bit(hwep->num, hwep->dir);

            int tmp_stat;

            struct td_node *prevlastnode;

            u32 next = firstnode->dma & TD_ADDR_MASK;



            hwreqprev = list_entry(hwep->qh.queue.prev, -----> Ref-D-code-body

                        struct ci_hw_req, queue);                   ^

            prevlastnode = list_entry(hwreqprev->tds.prev,--------|

                        struct td_node, td);

                                                                |

            prevlastnode->ptr->next = cpu_to_le32(next);  --------|

            wmb();



            if (ci->rev == CI_REVISION_22) {

                  if (!hw_read(ci, OP_ENDPTSTAT, BIT(n)))

                        reprime_dtd(ci, hwep, prevlastnode);

            }



            if (hw_read(ci, OP_ENDPTPRIME, BIT(n))) -------> Rev-B-0-code

                  goto done;

            do {

                  hw_write(ci, OP_USBCMD, USBCMD_ATDTW, USBCMD_ATDTW);

                  tmp_stat = hw_read(ci, OP_ENDPTSTAT, BIT(n));

            } while (!hw_read(ci, OP_USBCMD, USBCMD_ATDTW));

            hw_write(ci, OP_USBCMD, USBCMD_ATDTW, 0);

            if (tmp_stat)

                  goto done;   Rev-B-1-Code

      }



      /*  QH configuration */

      hwep->qh.ptr->td.next = cpu_to_le32(firstnode->dma);  ----> Ref-C-Code

      hwep->qh.ptr->td.token &=

            cpu_to_le32(~(TD_STATUS_HALTED|TD_STATUS_ACTIVE));



      if (hwep->type == USB_ENDPOINT_XFER_ISOC && hwep->dir == RX) {

            u32 mul = hwreq->req.length / hwep->ep.maxpacket;



            if (hwreq->req.length == 0

                        || hwreq->req.length % hwep->ep.maxpacket)

                  mul++;

            hwep->qh.ptr->cap |= cpu_to_le32(mul << __ffs(QH_MULT));

      }



      ret = hw_ep_prime(ci, hwep, hwep->num, hwep->dir,

                     hwep->type == USB_ENDPOINT_XFER_CONTROL);

done:

      return ret;

}

The bug happens when more than one USB request (i.e., a gadget level function request ... in this case, it's ethernet) gets added via the enqueue function. And there are already other TDs in progress or active and "timing" of other events have to occur just right need to happen for this scenario to spell out the way I described. So, doing a stress on the USB interface will bring this out more frequently as one of my counters told me. Yes, it happens more frequently than I thought but not every time. So timing of the scheduler and hardware state changes do need to happen at the correct moment.



In the scenario, the first request is HW req #10 and then followed by HW req #11. HW req #10 gets stitched into the dTD chain and may or may not get put into QH by the Ref-C-code line depending on whether the list is empty or whether Rev-B-0-code or Rev-B-1 code makes it jump to the done label. When HW req #11 comes in next, Rev-B-0-code and Rev-B-1-code line do not jump to done. This then makes it go to Ref-C-code.



And the problem is at Ref-C-code.



Note!!!!!!! what the firstnode points to. It points to the first TD of this new HW request that is passed into the enqueue function. It is NOT necessarily the first TD of the first HW request already in the queue that has not yet or is in progress of being transmitted. In other words, Rev-C-code allows the current/new hardware request to jump the line.



Look at Rev-D-code-body. These lines of code link all TDs **across** all HW request so that it is a single linked dTD chain. I believe this is done as an optimization so when there are more than one USB request in the queue, there is minimal performance loss when crossing USB request boundaries. But if you are going to do this, you have to ensure Ref-C-code is done correctly without skipping a hardware request (that can have one or more TDs) as well as ensuring that you append correctly.



Ref-C-code and the line after that violates the above highlighted text. We suspect ATDTW and ENDPTPRIME and ENDPSTAT plays here somehow but it's not clear how exactly to me. The "handshaking" between the hardware and software between QH, TD, ATDTW, ENDPTPRIME and ENDPSTAT is not clear to me when existing TDs are in progress/active.

Appreciate if you (or one of the HW engineers) can answer this questions:

  1.  How does ATDTW (bit 14) of the USBCMD register work for adding new descriptors? I know what the document says. But it's not clear how that affects the queue head that could already be in progress. Do we do add the TD while the bit is set?

  1.  For Endpoint priming (ENDPTPRIME) and endpoint status register (ENDPTSTAT), there is a statement in the document "Remark: These bits will be momentarily cleared by hardware during hardware endpoint
re-priming operations when a dTD is retired and the dQH is updated", how does the code know upon reading these registers that it being momentarily cleared by hardware or that the all TD transfers are complete? How long is a "moment"? This blimp in time can make Ref-B-1-code or Ref-B-0-code take the wrong path and ultimately lead to a skipped request.

  1.  When flushing an endpoint via ENDPTFLUSH, the current transfer completes. I assume this means the current TD in the queue head. But how does the queue head status get updated and how should we resume it?

  1.  What happens if I reprime an already primed endpoint and the TD in the QH is active?


Thanks a lot,

Tomer

From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Monday, 15 December 2025 13:33
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID

CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.

Hi Tomer,

Please refer to the below dTD structure.

EP=01: TD=7B8424C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842340
 0001:    00628080
 0002:    2126AA02
 0003:    2126B000
 0004:    2126C000
 0005:    2126D000
 0006:    2126E000

#0001 describe Total Bytes + Status + others.
#0002 describe Buffer Pointer 0 + Current Offset.

So, we can’t get conclusion from #0002 that transfer did start. But we can compare #0001 before and after the transfer to see if something changes.

[cid:image002.png@01DC83FC.8CBFF5A0]

Thanks,
Xu Yang

From: tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Sent: Sunday, December 14, 2025 11:54 PM
To: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>; Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

Hi Xu,

Could I know if TD 7B8424C0 is the very first one of the entire transfers on EP01TX?
Yes, it is the first TD in the link list.

If the queue head has already executed other TDs before 7B8424C0?
It is very likely the device controller have executed other TDs before this one because we see network
activity successfully completely. Those TD got completed successfully and removed from the list. That
is why you don't see anything before this TD.

Just wondering again about the first TD in the list, I don't think it was skipped too the more I looked at it.
I now think that the device controller did not perform the last update to the status field. So, when we dump it, it looks like the device
controller partially sent out the data and "moved on" to the next TD. Given a similar RX stall issue that saw earlier, the status field did not reflect what the CPU saw at time of ISR execution.
Therefore, I suspect that the device controller has a corner case where there is one more update to the status field that it should do but did not do or did do but should not have done.
In short, I think the status field is not consistent with actual hardware state.

You can see even in the below TD that in row 0002, that transfer did indeed start. Therefore, it was
not skipped. I suspect that the data get transmitted but a final update to the status field (marked in yellow)
did not occur.

EP=01: TD=7B8424C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842340
 0001:    00628080
 0002:    2126AA02
 0003:    2126B000
 0004:    2126C000
 0005:    2126D000
 0006:    2126E000

Do you agree with this theory?

Also, in failure scenarios, we observe that the QH is pointing to a TD that has the T (terminate) bit set (i.e., no Next pointer), making it the last entry in the BD chain.
When the IOC bit is set, an interrupt is triggered. In the interrupt handler, upon detecting the T (terminate) bit, the driver iterates over the entire list—from the Head (software pointer) to the Tail (current pointer)—to verify that the buffers were successfully transmitted.

Questions:


  1.  Why does the driver operate this way, iterating over the list upon encountering the Terminate bit? What is the rationale?
  2.  Is it possible that the Upper Layer has already begun writing the new chain?

Thanks a lot,

Tomer

From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Thursday, 11 December 2025 4:52
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID

CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.

Hi Tomer,

Please note: the TD active bit is set by software and cleared by device controller once it completes the transfer.
If you provide the first TD contents before and after the transfer, we can have more clear understanding of the process. Such as if the Total byte fields are updated by device controller.

Could I know if TD 7B8424C0 is the very first one of the entire transfers on EP01TX? If the queue head has already executed other TDs before 7B8424C0?

For your wondering:
It’s also what I guess as I said before. But if the device controller is executing an old TD, it will continue to do that until this TD is completed.

BTW, can you try latest kernel?

Thanks,
Xu Yang

From: tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Sent: Thursday, December 11, 2025 5:09 AM
To: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>; Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID

Hi Xu,

Thank you very much for the quick response.
I'm not entirely convinced that the first TD was actually skipped. From my understanding, before priming, the very first TD in the queue should be in the Non-Active state (while all subsequent TDs in the chain are already marked Active).
Once the endpoint is primed, the hardware should start the DMA engine, which sets that first TD to Active and begins processing it.
If that's correct, then in this case the first TD was successfully primed (we can see the status changed to Active), but for some reason the DMA transfer either never started or started but didn't update the token bits / Actual Bytes / Status as expected.

EP=01: TD=7B8424C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842340
 0001:    00628080
 0002:    2126AA02
 0003:    2126B000
 0004:    2126C000
 0005:    2126D000
 0006:    2126E000

One thing I'm wondering: is it possible that, while the DMA is processing the current queue, a new TD gets inserted at the head of the queue (i.e., a new "first" TD is added in front of the one that was just primed)?
If that happened, would the hardware continue with the original TD or could it cause the behaviour we're seeing (Active bit set, but Actual Bytes remains 0 and the transfer appears stalled)?

Thanks again for your help!

Tomer

From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Wednesday, 10 December 2025 8:07
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID

CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.

Hi Tomer,

Based on your info, the device controller has skipped dTD 7B8424C0 but still executed dTD 7B842340, 7B842280 - 7B842540. Finally, queue head stops at the last dTD.

I don’t think add CI_REVISION_25 check will cause reprime_dtd() be called when the device controller is executing the following dTDs. Because the endpoint is still in ready state, so “if (!hw_read(ci, OP_ENDPTSTAT, BIT(n)))” check will be false.
If the endpoint becomes not ready, then reprime the endpoint at dTD 7B8424C0 seems not also like a correct way. Because the data packet order will be corrupted.

So, for your issue, it seems like the queue head be force reset to 7B842340 when queue a new request which caused 7B8424C0 be skipped. I’m not sure for this.
I notice that you are using an old kernel version, can you try latest kernel, such as v6.18? Because the udc driver has some fix or improved patches.

Thanks,
Xu Yang

From: tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Sent: Wednesday, December 10, 2025 12:47 AM
To: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>; Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: [EXT] RE: Maintainer of ChipID


Hi Xu,


Appreciate your assistance in the following issue,
The data below explains why the request queue did not complete and why the TX is stalled.
First, notice in the data below, highlighted text in red  and yellow to point out the critical points.
Notice how the qeue head points to the ___end___ of the request list (It's highlighted in yellow).
However, the first request is NOT complete. The active bit (bit 7) is still set. But yet, the queue head has moved on.

They are dump of qhead and requests.
root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3#<mailto:root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3> cat requests
EP=01: TD=7B842480 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
 0000:    7B842300
 0001:    05FE8080
 0002:    0826A640
 0003:    0826B000
 0004:    0826C000
 0005:    0826D000
 0006:    0826E000
EP=01: TD=7B842300 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
 0000:    7B842200
 0001:    05FE8080
 0002:    08269EC0
 0003:    0826A000
 0004:    0826B000
 0005:    0826C000
 0006:    0826D000
EP=01: TD=7B842200 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
 0000:    7B842240
 0001:    05FE8080
 0002:    08269740
 0003:    0826A000
 0004:    0826B000
 0005:    0826C000
 0006:    0826D000
EP=01: TD=7B842240 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
 0000:    7B8421C0
 0001:    05FE8080
 0002:    08268FC0
 0003:    08269000
 0004:    0826A000
 0005:    0826B000
 0006:    0826C000
EP=01: TD=7B8421C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
 0000:    7B842140
 0001:    05FE8080
 0002:    08268840
 0003:    08269000
 0004:    0826A000
 0005:    0826B000
 0006:    0826C000
EP=01: TD=7B842140 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
 0000:    7B842580
 0001:    05FE8080
 0002:    082680C0
 0003:    08269000
 0004:    0826A000
 0005:    0826B000
 0006:    0826C000
EP=01: TD=7B842580 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
 0000:    7B8420C0
 0001:    05FE8080
 0002:    082178C0
 0003:    08218000
 0004:    08219000
 0005:    0821A000
 0006:    0821B000
EP=01: TD=7B8420C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
 0000:    7B8425C0
 0001:    05FE8080
 0002:    08217140
 0003:    08218000
 0004:    08219000
 0005:    0821A000
 0006:    0821B000
EP=01: TD=7B8425C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
 0000:    7B842040
 0001:    05FE8080
 0002:    082169C0
 0003:    08217000
 0004:    08218000
 0005:    08219000
 0006:    0821A000
EP=01: TD=7B842040 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
 0000:    00000001
 0001:    05FE8080
 0002:    08216240
 0003:    08217000
 0004:    08218000
 0005:    08219000
 0006:    0821A000
EP=01: TD=7B8424C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842340
 0001:    00628080
 0002:    2126AA02
 0003:    2126B000
 0004:    2126C000
 0005:    2126D000
 0006:    2126E000
EP=01: TD=7B842340 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842280
 0001:    00008000
 0002:    2126A064
 0003:    2126B360
 0004:    2126C000
 0005:    2126D000
 0006:    2126E000
EP=01: TD=7B842280 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842000
 0001:    00008000
 0002:    2126A264
 0003:    2126B360
 0004:    2126C000
 0005:    2126D000
 0006:    2126E000
EP=01: TD=7B842000 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842100
 0001:    00008000
 0002:    2126B864
 0003:    2126C360
 0004:    2126D000
 0005:    2126E000
 0006:    2126F000
EP=01: TD=7B842100 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842440
 0001:    00008000
 0002:    27F185EC
 0003:    27F19361
 0004:    27F1A000
 0005:    27F1B000
 0006:    27F1C000
EP=01: TD=7B842440 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842380
 0001:    00008000
 0002:    2126AC64
 0003:    2126B361
 0004:    2126C000
 0005:    2126D000
 0006:    2126E000
EP=01: TD=7B842380 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B8423C0
 0001:    00008000
 0002:    2126A864
 0003:    2126B361
 0004:    2126C000
 0005:    2126D000
 0006:    2126E000
EP=01: TD=7B8423C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842400
 0001:    00008000
 0002:    2126AE64
 0003:    2126B361
 0004:    2126C000
 0005:    2126D000
 0006:    2126E000
EP=01: TD=7B842400 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    7B842540
 0001:    00008000
 0002:    2126B664
 0003:    2126C362
 0004:    2126D000
 0005:    2126E000
 0006:    2126F000
EP=01: TD=7B842540 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
 0000:    00000001
 0001:    00008000
 0002:    2126BC64
 0003:    2126C362
 0004:    2126D000
 0005:    2126E000
 0006:    2126F000
root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3#<mailto:root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3> cat qheads
EP=00: RX=0E12E000 TX=0E12E040
 0000:    20408000    20408000
 0001:    7B842040    7B842080
 0002:    00000001    00000001
 0003:    00008000    00008000
 0004:    00000000    00000000
 0005:    000005A1    000005C2
 0006:    00000000    00000000
 0007:    00000000    00000000
 0008:    00000000    00000000
 0009:    00000000    00000000
 000A:    000E4321    00000000
 000B:    00000000    00000000
Last 16 RXs and TXs Completed (Most Recent First):
RX[0]=7B842040 TX[0]=7B842080
RX[1]=7B842040 TX[1]=7B842080
RX[2]=7B842000 TX[2]=7B842080
RX[3]=7B842000 TX[3]=7B842080
RX[4]=7B842300 TX[4]=7B842080
RX[5]=7B842300 TX[5]=7B842080
RX[6]=7B842300 TX[6]=7B842300
RX[7]=7B842300 TX[7]=7B842300
RX[8]=7B842300 TX[8]=7B8422C0
RX[9]=7B842300 TX[9]=7B8422C0
RX[10]=7B842300 TX[10]=7B8422C0
RX[11]=7B842300 TX[11]=7B8422C0
RX[12]=7B842300 TX[12]=7B8422C0
RX[13]=7B842300 TX[13]=7B8422C0
RX[14]=7B842080 TX[14]=7B8422C0
RX[15]=7B842080 TX[15]=7B8422C0
EP=01: RX=0E12E080 TX=0E12E0C0
 0000:    22000000    22000000
 0001:    7B8420C0    7B842540
 0002:    7B8425C0    00000001
 0003:    05FE8080    00008000
 0004:    08211EC0    2126BC64
 0005:    082125EC    2126C362
 0006:    08213000    2126D000
 0007:    08214000    2126E000
 0008:    08215000    2126F000
 0009:    00000000    00000000
 000A:    00000000    00000000
 000B:    00000000    00000000
Last 16 RXs and TXs Completed (Most Recent First):
RX[0]=7B842580 TX[0]=7B842500
RX[1]=7B842140 TX[1]=7B842340
RX[2]=7B8421C0 TX[2]=7B8424C0
RX[3]=7B842240 TX[3]=7B842340
RX[4]=7B842200 TX[4]=7B8424C0
RX[5]=7B842300 TX[5]=7B842340
RX[6]=7B842480 TX[6]=7B8424C0
RX[7]=7B842180 TX[7]=7B842340
RX[8]=7B842040 TX[8]=7B8424C0
RX[9]=7B8425C0 TX[9]=7B842500
RX[10]=7B8420C0 TX[10]=7B842280
RX[11]=7B842580 TX[11]=7B842000
RX[12]=7B842140 TX[12]=7B842100
RX[13]=7B8421C0 TX[13]=7B842440
RX[14]=7B842240 TX[14]=7B842100
RX[15]=7B842200 TX[15]=7B842000
EP=02: RX=0E12E100 TX=0E12E140
 0000:    00000000    20100000
 0001:    00000000    7B8422C0
 0002:    00000000    00000001
 0003:    00000000    00008000
 0004:    00000000    213A4090
 0005:    00000000    213A5620
 0006:    00000000    213A6000
 0007:    00000000    213A7000
 0008:    00000000    213A8000
 0009:    00000000    00000000
 000A:    00000000    00000000
 000B:    00000000    00000000
Last 16 RXs and TXs Completed (Most Recent First):
RX[0]=00000000 TX[0]=7B8422C0
RX[1]=00000000 TX[1]=7B842040
RX[2]=00000000 TX[2]=7B8422C0
RX[3]=00000000 TX[3]=00000000
RX[4]=00000000 TX[4]=00000000
RX[5]=00000000 TX[5]=00000000
RX[6]=00000000 TX[6]=00000000
RX[7]=00000000 TX[7]=00000000
RX[8]=00000000 TX[8]=00000000
RX[9]=00000000 TX[9]=00000000
RX[10]=00000000 TX[10]=00000000
RX[11]=00000000 TX[11]=00000000
RX[12]=00000000 TX[12]=00000000
RX[13]=00000000 TX[13]=00000000
RX[14]=00000000 TX[14]=00000000
RX[15]=00000000 TX[15]=00000000

We believe the completion interrupt did happen but if you look at the ISR code, it does this in _hardware_dequeue() function:

[cid:image003.png@01DC83FC.8CBFF5A0]

It enters the if-body at line 756 because the first request is still active and returns immediately. Nuvoton hardware is not CI_REVISION_24. However, if it could call reprime_dtd(), the queue head pointer would be updated to point to this "missed" or "unfinished" request and retried.

Could you explain why CI_REVISION_24 need to call reprime_dtd() at line 761?

But since the queue head points to the end and the ISR just returns at line 763 but does not go into the if-body of line 760 and 761, the USB device TX is stalled. That request won't ever be fulfilled because the Queue head pointer has moved beyond that. It's at the tail.

Should we add this WA in line 759 with the version we use CI_REVISION_25?


Thanks,

Tomer



-----Original Message-----
From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Tuesday, 2 December 2025 5:29
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: Re: Maintainer of ChipID



CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.





On Mon, Dec 01, 2025 at 01:59:21PM +0000, tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> wrote:

> Hi Peter,

>

> Thanks for your prompt reply.

>

> In rare cases, during RX transactions, the UDC driver receives an interrupt that is supposed to indicate the completion of a DMA receive operation and that the data is now available in memory. However, the ACTION (or ACTIVE) bit still indicates that the DMA transfer is ongoing.



Which interrupt? Do you mean USBSTS.UI? What about ENDPTCOMPLETE?

How do you sure that the dTD is still doing DMA transfer rather than has not start transfer yet? Do you know the contents before and after this dTD transfer?



> If the driver enters a loop waiting for this Active bit become zero and indicate the DAM action finish to the handler becomes stuck indefinitely..

> Are you familiar with this behavior?



What is the behavior of the host in this case?



>

> Besides the ACTIVE bit, are there any other status bits that reliably indicate the actual end of a DMA receive transaction?



Maybe no other status bit for DMA operation.



Thanks,

Xu Yang



>

> Thanks,

>

> Tomer

________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

[-- Attachment #1.1.2: Type: text/html, Size: 200162 bytes --]

[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 143263 bytes --]

[-- Attachment #1.3: image002.png --]
[-- Type: image/png, Size: 184502 bytes --]

[-- Attachment #1.4: image003.png --]
[-- Type: image/png, Size: 249265 bytes --]

[-- Attachment #2: ddrstress.sh --]
[-- Type: application/octet-stream, Size: 2914 bytes --]

#!/bin/sh

# Local DDR/memory stress using dd — no SSH/SFTP.
# Run this on the BMC/device.

BASE_DIR="/var/wcs_home"
STRESS_DIR="ddr_stress"
LOG_DIR="/tmp/ddr_logs"
FILE_SIZE_MB=512        # 512 MB file (4M * 128)
BS=4M
COUNT=128               # 4M * 128 = 512M

mkdir -p "$STRESS_DIR" "$LOG_DIR"

echo "== Local DDR/memory stress =="
echo "Stress dir: $STRESS_DIR"
echo "File size: ${FILE_SIZE_MB}MB"
echo

#############################################
# THREAD 1 — repeatedly create big file
#############################################
(
    LOGFILE="$LOG_DIR/thread1_write_$(date +%s).log"
    echo "[Thread1] Starting write loop at $(date)" >> "$LOGFILE"

    while true; do
        TS=$(date +%s)
        FILE="$STRESS_DIR/test-write-$TS.bin"

        echo "[Thread1] $(date): dd if=/dev/zero of=$FILE bs=$BS count=$COUNT" >> "$LOGFILE"
        dd if=/dev/zero of="$FILE" bs="$BS" count="$COUNT" >> "$LOGFILE" 2>&1

        echo "[Thread1] $(date): sync + rm $FILE" >> "$LOGFILE"
        sync
        rm -f "$FILE"
    done
) &
PID1=$!

#############################################
# THREAD 2 — repeatedly read file into /dev/null
# (creates one base file first, then loops reads)
#############################################
BASE_FILE="$STRESS_DIR/test-read-base.bin"
echo "[Main] Creating base read file $BASE_FILE (${FILE_SIZE_MB}MB)..."
dd if=/dev/zero of="$BASE_FILE" bs="$BS" count="$COUNT" >/dev/null 2>&1
sync
echo "[Main] Base read file created."

(
    LOGFILE="$LOG_DIR/thread2_read_$(date +%s).log"
    echo "[Thread2] Starting read loop at $(date)" >> "$LOGFILE"

    while true; do
        echo "[Thread2] $(date): dd if=$BASE_FILE of=/dev/null bs=$BS" >> "$LOGFILE"
        dd if="$BASE_FILE" of=/dev/null bs="$BS" >> "$LOGFILE" 2>&1
    done
) &
PID2=$!

#############################################
# THREAD 3 — copy + checksum loop
#############################################
(
    LOGFILE="$LOG_DIR/thread3_copy_$(date +%s).log"
    echo "[Thread3] Starting copy/checksum loop at $(date)" >> "$LOGFILE"

    while true; do
        TS=$(date +%s)
        COPY_FILE="$STRESS_DIR/test-copy-$TS.bin"

        echo "[Thread3] $(date): cp $BASE_FILE $COPY_FILE" >> "$LOGFILE"
        cp "$BASE_FILE" "$COPY_FILE" >> "$LOGFILE" 2>&1

        echo "[Thread3] $(date): md5sum $COPY_FILE" >> "$LOGFILE"
        md5sum "$COPY_FILE" >> "$LOGFILE" 2>&1

        echo "[Thread3] $(date): rm $COPY_FILE" >> "$LOGFILE"
        rm -f "$COPY_FILE"
    done
) &
PID3=$!

#############################################
# PRINT THREAD PIDs
#############################################
echo "DDR/memory stress threads started:"
echo "  Thread1 PID = $PID1  (write 512MB, sync, delete)"
echo "  Thread2 PID = $PID2  (read 512MB -> /dev/null)"
echo "  Thread3 PID = $PID3  (copy + md5sum, delete)"
echo
echo "Logs in: $LOG_DIR"
echo
echo "To stop all threads:"
echo "  kill $PID1 $PID2 $PID3"
echo


[-- Attachment #3: socstress_bmc.sh --]
[-- Type: application/octet-stream, Size: 1823 bytes --]

#!/bin/sh

TARGET="10.235.100.1"
LOGDIR="/tmp/pingstress"
mkdir -p "$LOGDIR"

echo "Starting multi-thread ping stress to $TARGET"
echo "Logs stored in $LOGDIR"

#############################################
# THREAD 1 — ping flood with max-sized packet
#############################################
(
    LOGFILE="$LOGDIR/thread1_pingf_$(date +%s).log"
    echo "[Thread1] Starting: ping -f -s 1472 $TARGET" >> "$LOGFILE"
    while true; do
        ping -i 0.01 -s 1472 "$TARGET" >> "$LOGFILE" 2>&1
        echo "[Thread1] ping exited — restarting" >> "$LOGFILE"
        sleep 1
    done
) &
PID1=$!

#############################################
# THREAD 2 — adaptive ping (can be very fast!)
#############################################
(
    LOGFILE="$LOGDIR/thread2_pingA_$(date +%s).log"
    echo "[Thread2] Starting: ping -A $TARGET" >> "$LOGFILE"
    while true; do
        ping -A "$TARGET" >> "$LOGFILE" 2>&1
        echo "[Thread2] ping exited — restarting" >> "$LOGFILE"
        sleep 1
    done
) &
PID2=$!

#############################################
# THREAD 3 — normal ping, max size, steady load
#############################################
(
    LOGFILE="$LOGDIR/thread3_ping1472_$(date +%s).log"
    echo "[Thread3] Starting: ping -s 1472 $TARGET" >> "$LOGFILE"
    while true; do
        ping -i 0.1 -s 1472 "$TARGET" >> "$LOGFILE" 2>&1
        echo "[Thread3] ping exited — restarting" >> "$LOGFILE"
        sleep 1
    done
) &
PID3=$!

#############################################
# PRINT THREAD PIDs
#############################################
echo "Ping stress threads started:"
echo "  Thread1 PID = $PID1  (ping -f 1472)"
echo "  Thread2 PID = $PID2  (ping -A)"
echo "  Thread3 PID = $PID3  (ping -s 1472)"
echo
echo "To stop all threads:"
echo "  kill $PID1 $PID2 $PID3"
echo


[-- Attachment #4: socstress_soc.sh --]
[-- Type: application/octet-stream, Size: 1818 bytes --]

#!/bin/sh

TARGET="10.235.100.0"
LOGDIR="pingstress"
mkdir -p "$LOGDIR"

echo "Starting multi-thread ping stress to $TARGET"
echo "Logs stored in $LOGDIR"

#############################################
# THREAD 1 — ping flood with max-sized packet
#############################################
(
    LOGFILE="$LOGDIR/thread1_pingf_$(date +%s).log"
    echo "[Thread1] Starting: ping -f -s 1472 $TARGET" >> "$LOGFILE"
    while true; do
        ping -i 0.01 -s 1472 "$TARGET" >> "$LOGFILE" 2>&1
        echo "[Thread1] ping exited — restarting" >> "$LOGFILE"
        sleep 1
    done
) &
PID1=$!

#############################################
# THREAD 2 — adaptive ping (can be very fast!)
#############################################
(
    LOGFILE="$LOGDIR/thread2_pingA_$(date +%s).log"
    echo "[Thread2] Starting: ping -A $TARGET" >> "$LOGFILE"
    while true; do
        ping -A "$TARGET" >> "$LOGFILE" 2>&1
        echo "[Thread2] ping exited — restarting" >> "$LOGFILE"
        sleep 1
    done
) &
PID2=$!

#############################################
# THREAD 3 — normal ping, max size, steady load
#############################################
(
    LOGFILE="$LOGDIR/thread3_ping1472_$(date +%s).log"
    echo "[Thread3] Starting: ping -s 1472 $TARGET" >> "$LOGFILE"
    while true; do
        ping -i 0.1 -s 1472 "$TARGET" >> "$LOGFILE" 2>&1
        echo "[Thread3] ping exited — restarting" >> "$LOGFILE"
        sleep 1
    done
) &
PID3=$!

#############################################
# PRINT THREAD PIDs
#############################################
echo "Ping stress threads started:"
echo "  Thread1 PID = $PID1  (ping -f 1472)"
echo "  Thread2 PID = $PID2  (ping -A)"
echo "  Thread3 PID = $PID3  (ping -s 1472)"
echo
echo "To stop all threads:"
echo "  kill $PID1 $PID2 $PID3"
echo