| Message ID | 1614327697-1021-1-git-send-email-liulongfang@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] USB:XHCI:Modify XHCI driver for USB2.0 controller | expand |
On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: > Our current XHCI hardware controller has been customized to only > support USB 2.0 ports. That sounds like a spec violation, right? Why do you want to do this? greg k-h
On 26.2.2021 10.21, Longfang Liu wrote: > Our current XHCI hardware controller has been customized to only > support USB 2.0 ports. When using the current xhci driver, an xhci > controller device and an ehci controller device will be created > automatically. We want the driver to create only one ehci controller. > After modifying the driver as follows, an error will occur. > Is there any other modification method? The xhci driver relies on the existence of both a main and a shared hcd. One hcd for handing USB 2 (and slower) and the other for USB 3 devices. As one example xhci_run(hcd) needs to be called for both hcds, first call sets up things, second one calls xhci_start() that makes the controller run. It's probably possible to modify the driver to support xHCI hosts with only USB 2 ports, but requires a lot more work. > > Signed-off-by: Longfang Liu <liulongfang@huawei.com> > --- > drivers/usb/host/xhci-pci.c | 15 ++------------- > 1 file changed, 2 insertions(+), 13 deletions(-) > > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c > index ef513c2..7296aad 100644 > --- a/drivers/usb/host/xhci-pci.c > +++ b/drivers/usb/host/xhci-pci.c > @@ -364,26 +364,15 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) > /* USB 2.0 roothub is stored in the PCI device now. */ > hcd = dev_get_drvdata(&dev->dev); > xhci = hcd_to_xhci(hcd); > - xhci->shared_hcd = usb_create_shared_hcd(&xhci_pci_hc_driver, &dev->dev, > - pci_name(dev), hcd); > - if (!xhci->shared_hcd) { > - retval = -ENOMEM; > - goto dealloc_usb2_hcd; > - } > - > + xhci->shared_hcd = NULL; > retval = xhci_ext_cap_init(xhci); > if (retval) > goto put_usb3_hcd; > > - retval = usb_add_hcd(xhci->shared_hcd, dev->irq, > + retval = usb_add_hcd(xhci->main_hcd, dev->irq, > IRQF_SHARED); > if (retval) > goto put_usb3_hcd; > - /* Roothub already marked as USB 3.0 speed */ > - > - if (!(xhci->quirks & XHCI_BROKEN_STREAMS) && > - HCC_MAX_PSA(xhci->hcc_params) >= 4) > - xhci->shared_hcd->can_do_streams = 1; > > /* USB-2 and USB-3 roothubs initialized, allow runtime pm suspend */ > pm_runtime_put_noidle(&dev->dev); > Something like the above could of course not be accepted upstream. We can't break existing functionality to support one modified xHCI. Thanks Mathias
On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: > Our current XHCI hardware controller has been customized to only > support USB 2.0 ports. When using the current xhci driver, an xhci > controller device and an ehci controller device will be created > automatically. That sentence makes no sense at all. An EHCI controller device is a piece of hardware. How can an xHCI driver, which is a piece of software, create a piece of hardware? Alan Stern
On 2021/2/26 16:38, Greg KH wrote: > On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: >> Our current XHCI hardware controller has been customized to only >> support USB 2.0 ports. > > That sounds like a spec violation, right? Why do you want to do this? > > greg k-h > . > I hope to support a USB2.0-only mode on the XHCI controller through software configuration. Thanks. Longfang Liu
On 2021/2/26 17:22, Mathias Nyman wrote: > On 26.2.2021 10.21, Longfang Liu wrote: >> Our current XHCI hardware controller has been customized to only >> support USB 2.0 ports. When using the current xhci driver, an xhci >> controller device and an ehci controller device will be created >> automatically. We want the driver to create only one ehci controller. >> After modifying the driver as follows, an error will occur. >> Is there any other modification method? > > The xhci driver relies on the existence of both a main and a shared hcd. > One hcd for handing USB 2 (and slower) and the other for USB 3 devices. > > As one example xhci_run(hcd) needs to be called for both hcds, first call > sets up things, second one calls xhci_start() that makes the controller run. > > It's probably possible to modify the driver to support xHCI hosts with only > USB 2 ports, but requires a lot more work. > >> >> Signed-off-by: Longfang Liu <liulongfang@huawei.com> >> --- >> drivers/usb/host/xhci-pci.c | 15 ++------------- >> 1 file changed, 2 insertions(+), 13 deletions(-) >> >> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c >> index ef513c2..7296aad 100644 >> --- a/drivers/usb/host/xhci-pci.c >> +++ b/drivers/usb/host/xhci-pci.c >> @@ -364,26 +364,15 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) >> /* USB 2.0 roothub is stored in the PCI device now. */ >> hcd = dev_get_drvdata(&dev->dev); >> xhci = hcd_to_xhci(hcd); >> - xhci->shared_hcd = usb_create_shared_hcd(&xhci_pci_hc_driver, &dev->dev, >> - pci_name(dev), hcd); >> - if (!xhci->shared_hcd) { >> - retval = -ENOMEM; >> - goto dealloc_usb2_hcd; >> - } >> - >> + xhci->shared_hcd = NULL; >> retval = xhci_ext_cap_init(xhci); >> if (retval) >> goto put_usb3_hcd; >> >> - retval = usb_add_hcd(xhci->shared_hcd, dev->irq, >> + retval = usb_add_hcd(xhci->main_hcd, dev->irq, >> IRQF_SHARED); >> if (retval) >> goto put_usb3_hcd; >> - /* Roothub already marked as USB 3.0 speed */ >> - >> - if (!(xhci->quirks & XHCI_BROKEN_STREAMS) && >> - HCC_MAX_PSA(xhci->hcc_params) >= 4) >> - xhci->shared_hcd->can_do_streams = 1; >> >> /* USB-2 and USB-3 roothubs initialized, allow runtime pm suspend */ >> pm_runtime_put_noidle(&dev->dev); >> > > Something like the above could of course not be accepted upstream. We can't break existing > functionality to support one modified xHCI. > > Thanks > Mathias > . > Thanks very much. Longfang Liu
On 2021/2/27 0:30, Alan Stern wrote: > On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: >> Our current XHCI hardware controller has been customized to only >> support USB 2.0 ports. When using the current xhci driver, an xhci >> controller device and an ehci controller device will be created >> automatically. > > That sentence makes no sense at all. An EHCI controller device is a > piece of hardware. How can an xHCI driver, which is a piece of > software, create a piece of hardware? > > Alan Stern > . > The hardware device is a complete USB3.0 controller, but I hope to support a USB2.0-only mode through software configuration. Thanks. Longfang Liu
On 2021/2/27 11:38, liulongfang wrote: > On 2021/2/27 0:30, Alan Stern wrote: >> On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: >>> Our current XHCI hardware controller has been customized to only >>> support USB 2.0 ports. When using the current xhci driver, an xhci >>> controller device and an ehci controller device will be created >>> automatically. >> >> That sentence makes no sense at all. An EHCI controller device is a >> piece of hardware. How can an xHCI driver, which is a piece of >> software, create a piece of hardware? >> >> Alan Stern >> . >> > The hardware device is a complete USB3.0 controller, On the hardware, only the hardware connection of the USB2.0 port has been opened > but I hope to support a USB2.0-only mode through software configuration. > Thanks. > Longfang Liu > . > Thanks. Longfang Liu
On Sat, Feb 27, 2021 at 11:38:08AM +0800, liulongfang wrote: > On 2021/2/27 0:30, Alan Stern wrote: > > On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: > >> Our current XHCI hardware controller has been customized to only > >> support USB 2.0 ports. When using the current xhci driver, an xhci > >> controller device and an ehci controller device will be created > >> automatically. > > > > That sentence makes no sense at all. An EHCI controller device is a > > piece of hardware. How can an xHCI driver, which is a piece of > > software, create a piece of hardware? > > > > Alan Stern > > . > > > The hardware device is a complete USB3.0 controller, > but I hope to support a USB2.0-only mode through software configuration. Even if it only supports USB-2.0 connections, an xHCI controller is still an xHCI controller. It doesn't magically transform into an EHCI controller. You are not creating an EHCI controller device. Rather, you are trying to restrict an xHCI controller device to make it handle only USB-2.0 connections. If you run lsusb on a system that has an xHCI controller, you'll see that the controller is bound to two USB buses: a USB-2 bus and a USB-3 bus. But for both buses, the controller is xHCI -- not EHCI. Your patch description is inaccurate. Alan Stern
On 2021/2/28 0:27, Alan Stern Wrote: > On Sat, Feb 27, 2021 at 11:38:08AM +0800, liulongfang wrote: >> On 2021/2/27 0:30, Alan Stern wrote: >>> On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: >>>> Our current XHCI hardware controller has been customized to only >>>> support USB 2.0 ports. When using the current xhci driver, an xhci >>>> controller device and an ehci controller device will be created >>>> automatically. >>> >>> That sentence makes no sense at all. An EHCI controller device is a >>> piece of hardware. How can an xHCI driver, which is a piece of >>> software, create a piece of hardware? >>> >>> Alan Stern >>> . >>> >> The hardware device is a complete USB3.0 controller, >> but I hope to support a USB2.0-only mode through software configuration. > > Even if it only supports USB-2.0 connections, an xHCI controller is > still an xHCI controller. It doesn't magically transform into an EHCI > controller. > > You are not creating an EHCI controller device. Rather, you are trying > to restrict an xHCI controller device to make it handle only USB-2.0 > connections. If you run lsusb on a system that has an xHCI controller, > you'll see that the controller is bound to two USB buses: a USB-2 bus > and a USB-3 bus. But for both buses, the controller is xHCI -- not > EHCI. > > Your patch description is inaccurate. > > Alan Stern > . > Yes, you are right. when I run lsusb on a system that has this xHCI hardware, the system displays two USB buses: a USB-2 bus and a USB-3 bus. Both of these are xHCI host controllers, but USB-3 bus's roothub is zero. Thanks. Longfang Liu.
On 21-02-27 11:31:00, liulongfang wrote: > On 2021/2/26 16:38, Greg KH wrote: > > On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: > >> Our current XHCI hardware controller has been customized to only > >> support USB 2.0 ports. > > > > That sounds like a spec violation, right? Why do you want to do this? > > > > greg k-h > > . > > > I hope to support a USB2.0-only mode on the XHCI controller > through software configuration. > Thanks. If your hardware has disabled USB3 logic, when the USB3 device is plugged, since there are no RX signal on the bus, the device will not enable USB3 logic, and only USB2 signals will be on the bus, there are only USB devices on USB2 roothub later. So, any issues you have met?
On 2021/3/4 9:35, Peter Chen wrote: > On 21-02-27 11:31:00, liulongfang wrote: >> On 2021/2/26 16:38, Greg KH wrote: >>> On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: >>>> Our current XHCI hardware controller has been customized to only >>>> support USB 2.0 ports. >>> >>> That sounds like a spec violation, right? Why do you want to do this? >>> >>> greg k-h >>> . >>> >> I hope to support a USB2.0-only mode on the XHCI controller >> through software configuration. >> Thanks. > > If your hardware has disabled USB3 logic, when the USB3 device is plugged, > since there are no RX signal on the bus, the device will not enable USB3 > logic, and only USB2 signals will be on the bus, there are only USB devices on > USB2 roothub later. So, any issues you have met? > I don’t want to see the USB3 bus controller in the system, but it actually exists. Thanks. Longfang, Liu
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index ef513c2..7296aad 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -364,26 +364,15 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) /* USB 2.0 roothub is stored in the PCI device now. */ hcd = dev_get_drvdata(&dev->dev); xhci = hcd_to_xhci(hcd); - xhci->shared_hcd = usb_create_shared_hcd(&xhci_pci_hc_driver, &dev->dev, - pci_name(dev), hcd); - if (!xhci->shared_hcd) { - retval = -ENOMEM; - goto dealloc_usb2_hcd; - } - + xhci->shared_hcd = NULL; retval = xhci_ext_cap_init(xhci); if (retval) goto put_usb3_hcd; - retval = usb_add_hcd(xhci->shared_hcd, dev->irq, + retval = usb_add_hcd(xhci->main_hcd, dev->irq, IRQF_SHARED); if (retval) goto put_usb3_hcd; - /* Roothub already marked as USB 3.0 speed */ - - if (!(xhci->quirks & XHCI_BROKEN_STREAMS) && - HCC_MAX_PSA(xhci->hcc_params) >= 4) - xhci->shared_hcd->can_do_streams = 1; /* USB-2 and USB-3 roothubs initialized, allow runtime pm suspend */ pm_runtime_put_noidle(&dev->dev);
Our current XHCI hardware controller has been customized to only support USB 2.0 ports. When using the current xhci driver, an xhci controller device and an ehci controller device will be created automatically. We want the driver to create only one ehci controller. After modifying the driver as follows, an error will occur. Is there any other modification method? Signed-off-by: Longfang Liu <liulongfang@huawei.com> --- drivers/usb/host/xhci-pci.c | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-)