[PATCH] usb: ehci-pci: Set has_hostpc for TDI EHCI on Intel CE5300/CE2600

[PATCH] usb: ehci-pci: Set has_hostpc for TDI EHCI on Intel CE5300/CE2600

[Joseph Telaak via B4 Relay]

From: Joseph Telaak <joseph@telaak.dev>

The TransDimension EHCI core in the Intel CE5300 and CE2600 SoCs
(192e:0101, revision >= 6) has the Moorestown-style register
extensions: host mode is selected in USBMODE_EX rather than USBMODE,
and the port speed is reported in HOSTPC.

Without has_hostpc, ehci_reset() never programs USBMODE_EX, so the
core stays in idle mode: USBMODE_EX reads back 0, USBCMD.RS never
sets and no device is ever reported as connected, even though the
probe itself succeeds. With it, USBMODE_EX reads back 0x23 and
devices enumerate.

Intel's CE5300 BSP applies the same quirk for device 0x0101,
revision >= 6.

Tested on a Control4 EA-3 (Intel Atom CE5310) with v7.3-rc6: a
full-speed CP2104 USB-UART bridge (10c4:ea60) and a high-speed USB
flash drive (0781:5575) enumerate with this change.

Assisted-by: LLM
Signed-off-by: Joseph Telaak <joseph@telaak.dev>
---
Notes:
- CONFIG_USB_EHCI_ROOT_HUB_TT=y is still required, as for any TDI
  core; without it ehci_halt() times out (-110) on the idle core
  before this code runs.
- has_tdi_phy_lpm is left at 0 on this path, matching Intel's BSP.
- This is a device quirk rather than a regression fix, so there is
  no Fixes: tag; it may be suitable for stable if you think so.
---
 drivers/usb/host/ehci-pci.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index bd3a635555..8c71c3de30 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -145,8 +145,16 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
 			hcd->has_tt = 1;
 		break;
 	case PCI_VENDOR_ID_TDI:
-		if (pdev->device == PCI_DEVICE_ID_TDI_EHCI)
+		if (pdev->device == PCI_DEVICE_ID_TDI_EHCI) {
 			hcd->has_tt = 1;
+			/*
+			 * The TDI core in the Intel CE5300/CE2600 (rev >= 6)
+			 * selects host mode in USBMODE_EX and reports port
+			 * speed in HOSTPC, as on Moorestown.
+			 */
+			if (pdev->revision >= 0x6)
+				ehci->has_hostpc = 1;
+		}
 		break;
 	case PCI_VENDOR_ID_AMD:
 		/* AMD PLL quirk */

---
base-commit: bbf6b99a57b2479bf51c3c8ad0946f4b8c33ed69
change-id: 20261015-ehci-ce5300-hostpc-8722cf06fc88

Best regards,
--  
Joseph Telaak <joseph@telaak.dev>

Re: [PATCH] usb: ehci-pci: Set has_hostpc for TDI EHCI on Intel CE5300/CE2600

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] usb: ehci: tdi_in_host_mode() fails to check USBMODE_EX
--

commit 493a630291d0b5961a888e40fa36840fea16fbf5
Author: Joseph Telaak <joseph@telaak.dev>
    usb: ehci-pci: Set has_hostpc for TDI EHCI on Intel CE5300/CE2600

The TransDimension EHCI core in the Intel CE5300 and CE2600 SoCs
(192e:0101, revision >= 6) has the Moorestown-style register extensions:
host mode is selected in USBMODE_EX rather than USBMODE. This commit sets
has_hostpc so that USBMODE_EX reads back 0x23 and devices enumerate.

> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
> index bd3a635555942..8c71c3de3082e 100644
> --- a/drivers/usb/host/ehci-pci.c
> +++ b/drivers/usb/host/ehci-pci.c
> @@ -145,8 +145,16 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
>  			hcd->has_tt = 1;
>  		break;
>  	case PCI_VENDOR_ID_TDI:
> -		if (pdev->device == PCI_DEVICE_ID_TDI_EHCI)
> +		if (pdev->device == PCI_DEVICE_ID_TDI_EHCI) {
>  			hcd->has_tt = 1;
> +			/*
> +			 * The TDI core in the Intel CE5300/CE2600 (rev >= 6)
> +			 * selects host mode in USBMODE_EX and reports port
> +			 * speed in HOSTPC, as on Moorestown.
> +			 */
> +			if (pdev->revision >= 0x6)
> +				ehci->has_hostpc = 1;
> +		}

[Severity: High]
Since this hardware selects host mode via USBMODE_EX (offset 0xc8), the
standard USBMODE register (offset 0x68) may read as 0. If it does, will
tdi_in_host_mode() falsely return 0?

drivers/usb/host/ehci-hcd.c:tdi_in_host_mode() {
    ...
    tmp = ehci_readl(ehci, &ehci->regs->usbmode);
    return (tmp & 3) == USBMODE_CM_HC;
}

During driver unbind or system suspend, ehci_halt() relies on
tdi_in_host_mode(). A false 0 return causes ehci_halt() to exit
immediately and completely bypass the teardown sequence (clearing
CMD_RUN and waiting for STS_HALT):

drivers/usb/host/ehci-hcd.c:ehci_halt() {
    ...
    if (ehci_is_TDI(ehci) && !ehci->no_tdi_mode &&
        !tdi_in_host_mode(ehci)) {
        spin_unlock_irq(&ehci->lock);
        return 0;
    }
    ...
}

Can this bypassed teardown sequence leave DMA and IRQs active on the
newly enabled core, potentially leading to memory corruption or a system
panic? Does tdi_in_host_mode() need to check USBMODE_EX if has_hostpc
is set?

>  		break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015-ehci-ce5300-hostpc-v1-1-3cae67c11946@telaak.dev?part=1

Re: [PATCH] usb: ehci-pci: Set has_hostpc for TDI EHCI on Intel CE5300/CE2600

[Joseph Telaak]

On Fri, 16 Oct 2026 01:22:42 +0000, sashiko-bot@kernel.org wrote:
> Since this hardware selects host mode via USBMODE_EX (offset 0xc8), the
> standard USBMODE register (offset 0x68) may read as 0. If it does, will
> tdi_in_host_mode() falsely return 0?

Yes. USBMODE reads back 0 on this core even while it is running, so
tdi_in_host_mode() returns 0 and ehci_halt() returns without stopping
the controller. I confirmed it on hardware: after ehci_shutdown(),
USBCMD.RS is still set. v2 will read host mode back from USBMODE_EX
for this core only, via a new flag set by the CE5300 quirk, so other
has_hostpc users such as ChipIdea are unaffected.

Testing this also turned up a second problem: ehci-pci reads SBRN and
the port-wake bits from PCI config 0x60-0x62, which this core doesn't
have (those bytes shadow a BAR). SBRN reads as 0, so the controller
reports "USB 0.0" and ehci_shutdown() returns early, which hid the
issue above. v2 will skip those reads for this core as well.

Thanks,
Joseph

On Thu, Oct 15, 2026 at 9:22 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] usb: ehci: tdi_in_host_mode() fails to check USBMODE_EX
> --
>
> commit 493a630291d0b5961a888e40fa36840fea16fbf5
> Author: Joseph Telaak <joseph@telaak.dev>
>     usb: ehci-pci: Set has_hostpc for TDI EHCI on Intel CE5300/CE2600
>
> The TransDimension EHCI core in the Intel CE5300 and CE2600 SoCs
> (192e:0101, revision >= 6) has the Moorestown-style register extensions:
> host mode is selected in USBMODE_EX rather than USBMODE. This commit sets
> has_hostpc so that USBMODE_EX reads back 0x23 and devices enumerate.
>
> > diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
> > index bd3a635555942..8c71c3de3082e 100644
> > --- a/drivers/usb/host/ehci-pci.c
> > +++ b/drivers/usb/host/ehci-pci.c
> > @@ -145,8 +145,16 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
> >                       hcd->has_tt = 1;
> >               break;
> >       case PCI_VENDOR_ID_TDI:
> > -             if (pdev->device == PCI_DEVICE_ID_TDI_EHCI)
> > +             if (pdev->device == PCI_DEVICE_ID_TDI_EHCI) {
> >                       hcd->has_tt = 1;
> > +                     /*
> > +                      * The TDI core in the Intel CE5300/CE2600 (rev >= 6)
> > +                      * selects host mode in USBMODE_EX and reports port
> > +                      * speed in HOSTPC, as on Moorestown.
> > +                      */
> > +                     if (pdev->revision >= 0x6)
> > +                             ehci->has_hostpc = 1;
> > +             }
>
> [Severity: High]
> Since this hardware selects host mode via USBMODE_EX (offset 0xc8), the
> standard USBMODE register (offset 0x68) may read as 0. If it does, will
> tdi_in_host_mode() falsely return 0?
>
> drivers/usb/host/ehci-hcd.c:tdi_in_host_mode() {
>     ...
>     tmp = ehci_readl(ehci, &ehci->regs->usbmode);
>     return (tmp & 3) == USBMODE_CM_HC;
> }
>
> During driver unbind or system suspend, ehci_halt() relies on
> tdi_in_host_mode(). A false 0 return causes ehci_halt() to exit
> immediately and completely bypass the teardown sequence (clearing
> CMD_RUN and waiting for STS_HALT):
>
> drivers/usb/host/ehci-hcd.c:ehci_halt() {
>     ...
>     if (ehci_is_TDI(ehci) && !ehci->no_tdi_mode &&
>         !tdi_in_host_mode(ehci)) {
>         spin_unlock_irq(&ehci->lock);
>         return 0;
>     }
>     ...
> }
>
> Can this bypassed teardown sequence leave DMA and IRQs active on the
> newly enabled core, potentially leading to memory corruption or a system
> panic? Does tdi_in_host_mode() need to check USBMODE_EX if has_hostpc
> is set?
>
> >               break;
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20261015-ehci-ce5300-hostpc-v1-1-3cae67c11946@telaak.dev?part=1
>