Re: [PATCH 1/3] usb: octeon-hcd: fix the FIFO-flush timeout computation

[Orgad Shaneh]

On Tue, Sep 1, 2026 at 5:48 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> Should this series have an Assisted-by: tag?

Yes - my oversight, v2 will carry it on all three patches:

Assisted-by: Claude:claude-opus-5

I used Claude Code for the analysis, patches and commit texts. My
Signed-off-by stays as the DCO certification; I ran and reviewed it all on
hardware.

> How did you find and test it?

I'm updating the kernel on our Octeon boards from ancient 2.6 to 7.2, so I
walked into it. Bringing USB back up on an AudioCodes M800 (CN5020p1.1-300,
board type CN3010_EVB_HS5), modprobing octeon-hcd killed the board: watchdog
reset, nothing printed. Serial capture caught a soft lockup in __delay() under
cvmx_wait_tx_rx(), where the missing parens on octeon_get_clock_rate are right
there in the deadline; git blame lands on 3e195a80e096, and the cast hides it
from the compiler.

The flush never finished on my board because the driver got the DTS default
12MHz crystal instead of the board's 24MHz external reference, so the PHY never
came up and the USBC registers read all-ones. That is a board/arch problem I'm
handling separately, but it made a reliable reproducer: with the clock wrong,
probe never returns and the board dies; with 1/3 it times out after 100us and
returns an error; with 2/3 it bails earlier at GHWCFG3 and says why. With the
clock right, the root hub and on-board 4-port hub enumerate at high speed and
run without errors, so the timeout doesn't fire on healthy hardware - same
setup 3/3 was measured on (8200 -> 4 USB interrupts/s idle). Builds clean,
checkpatch is happy.

Untested: any part other than CN5020, and the HFNUM wrap path in 3/3 beyond
reasoning plus long idle runs with a hub attached.

- Orgad