Re: Not enough host controller resources for new device state
On Sat, 21 Nov 2015, Patrick Shirkey wrote: > On Sat, November 21, 2015 9:35 am, Peter Stuge wrote: > > Patrick Shirkey wrote: > >> > You essentially have to educate yourself on silicon level (ie. what > >> > hardware IP is being used in which consumer products) to sustain a > >> > dependency on 127 possible devices per bus. > >> > > >> > I guess you'll find that there are only very few xHCI IPs out there, > >> > probably just three or four. I wouldn't be surprised if they all have > >> > the same, or similar, limitations. > >> > >> Is there anything I can do at the system level to avoid disabling xHCI > >> at > >> the BIOS level? > > > > Unfortunately not. The number of supported devices is now very much > > hardwired in the host controller hardware. Each connected device > > requires its own set of registers in xHCI, so when there is a limit > > it is a hard limit. > > > > > > That's a bit of a let down as it seems to make it even more difficult to > rely on USB for my specific use case in the future. > > In case anyone else comes across this thread do you mind giving a little > more detail on why xHCI overrides EHCI and why it is not possible to > disable or work around xHCI at the system level? xHCI is the controller technology that supports SuperSpeed (5 Gb/s), as used by many USB-3 devices. EHCI is the controller technology that supports High Speed (480 Mb/s), used by many USB-2 devices. (Note that xHCI also supports High Speed, as well as Full Speed (12 Mb/s) and Low Speed (1.5 Mb/s) which date back to USB-1.1.) If you disable your xHCI controller, USB connections will not be able to run at SuperSpeed. Depending on how the motherboard is designed, they may fall back to High Speed (using an on-board EHCI controller) or they may not work at all (if the motherboard doesn't have any other USB controllers). This should explain why xHCI overrides EHCI. If you have a SuperSpeed-capable device, you generally want it to run as fast as possible, which means it should connect to the xHCI controller and not to the EHCI controller. It _is_ possible to disable xHCI at the system level. By sending the proper command to the appropriate sysfs file, you can unbind the xhci-hcd driver from the xHCI controller. This will disable the controller, and so all further USB communications will run no faster than High Speed. (Or if your computer doesn't have an EHCI controller, you won't get any further USB communications at all.) Actually it's a little more complicated than that. Some systems have a software-settable switch that determines whether devices will connect to the xHCI or the EHCI controller. On such systems, Linux sets the switch to use xHCI, unless the kernel was built without xHCI support. Therefore, although it is possible to force the use of EHCI on such systems, in order to do so you have to rebuild the kernel. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linux USB] enable/disable individual ports
On Sat, 21 Nov 2015, Patrick Shirkey wrote: > Hi, > > I have a libusb (USB-2.0_ tree with the following layout: > > HOST (USB 2.0) -> 5 port hub (master) -> 5 x 10 port hub -> 50 x USB devices > > It is a 50 unit mobile device charger and also enables USB data comms to > the individual devices. Each node is independently powered. The devices > are all the same model/make. I know this is a relative corner case for USB > 2.0 standard but that is another story. > > Is it possible to reset the ports on the 5 port hub (master) individually > with libusb or some other system level command? I have written a program (for Linux only; it doesn't use libusb) that issues a reset to a single device: http://marc.info/?l=linux-usb&m=126944503308931&w=2 You can use this to reset each of the 10-port hubs in turn. Or even to reset the 5-port hub. > Here's the scenario: > > When I insert usb devices with the entire chain connected I see varying > results for the number of devices detected by the HOST. Sometimes 15 are > detected, sometimes 34, 22, 5, etc... However If I disconnect the cables > for the 10 port hubs to the 5 port master hub before I insert all the > devices and then connect each 10 port hub one at a time with a delay to > ensure all the devices on that hub are detected all 50 devices are > detected on the host. It sounds like there may be something wrong with that 5-port hub. This sort of thing _should_ work reliably. > So I would like to know if there is a method to disable/enable the ports > on the 5 port master without resetting the entire bus or causing the sub > nodes/hubs to "bounce" their connections. I don't know of any way to disable an individual port on a hub. Note that disable is different from reset. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linux USB] enable/disable individual ports
Alan Stern writes: > I have written a program (for Linux only; it doesn't use libusb) that > issues a reset to a single device: > > http://marc.info/?l=linux-usb&m=126944503308931&w=2 > > You can use this to reset each of the 10-port hubs in turn. Or even to > reset the 5-port hub. This is a very useful tool in all it's simple elegance. For all us who never would have guessed that there was such an ioctl... I saved a copy when you first posted it and have used it on quite a few occasions. Maybe the tool should be added to the usbutils collection so it could reach a somewhat wider audience? Yes, I know the usecases are all weird, but that still doesn't mean than everyone with a usecase will read this list :) Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb-storage: Fix scsi-sd failure "Invalid field in cdb" for USB adapter JMicron
On 20/11/2015 17:08, Alan Stern wrote: > On Fri, 20 Nov 2015, Dmitry Katsubo wrote: > >> From: Dmitry Katsubo >> >> The patch extends the family of SATA-to-USB JMicron adapters that need >> FUA to be disabled and applies the same policy for uas driver. >> See details in http://unix.stackexchange.com/questions/237204/ >> >> Signed-off-by: Dmitry Katsubo >> Tested-by: Dmitry Katsubo >> --- >> The change is trivial, however it spans also to JMicron adapter with >> bcdDevice 1.15, which I haven't tested. Nevertheless it is very likely >> that it is buggy as well. Patch was applied and tested on Debian Jessie >> 4.2.5-1~bpo8+1. There is a checkpatch warning, but it is caused by original >> source code formatting. > > Acked-by: Alan Stern > > Greg, please apply this. > > Dmitry, do you want this be applied to the -stable kernels too? That is not necessary. I have working kernel which I am happy with -- many thanks for your guidance. What is the next lowest kernel version it will be applied to? -- With best regards, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linux USB] enable/disable individual ports
On Sat, Nov 21, 2015 at 08:32:10PM +0100, Bjørn Mork wrote: > Alan Stern writes: > > > I have written a program (for Linux only; it doesn't use libusb) that > > issues a reset to a single device: > > > > http://marc.info/?l=linux-usb&m=126944503308931&w=2 > > > > You can use this to reset each of the 10-port hubs in turn. Or even to > > reset the 5-port hub. > > This is a very useful tool in all it's simple elegance. For all us who > never would have guessed that there was such an ioctl... > > I saved a copy when you first posted it and have used it on quite a few > occasions. Maybe the tool should be added to the usbutils collection so > it could reach a somewhat wider audience? Yes, I know the usecases are > all weird, but that still doesn't mean than everyone with a usecase will > read this list :) I've considered it in the past, but didn't want to deal with all of the "this doesn't work on my hardware" emails. Maybe if the code prints out a big message when it's run it might help... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port
On Fri 20 Nov 15:47 PST 2015, Tim Bird wrote:
> Add support for async_irq to wake up driver from low power mode.
> Without this, the power management code never calls resume.
> Remove a spurious interrupt enable in the driver resume function.
>
> Signed-off-by: Tim Bird
Sorry Tim for missing these things and not jumping into the discussion
before.
> ---
> drivers/usb/phy/phy-msm-usb.c | 17 -
> include/linux/usb/msm_hsusb.h | 1 +
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
[..]
> @@ -1732,6 +1731,12 @@ static int msm_otg_probe(struct platform_device *pdev)
> return motg->irq;
> }
>
> + motg->async_irq = platform_get_irq_byname(pdev, "async");
> + if (motg->async_irq < 0) {
> + dev_err(&pdev->dev, "platform_get_irq for async irq failed\n");
This is optional, so I must object to this being dev_err(). Except for
development purposes logging this is useless, can't we make it a
dev_dbg?
> + motg->async_irq = 0;
> + }
> +
[..]
> diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
> index 8c8f685..08c67a3 100644
> --- a/include/linux/usb/msm_hsusb.h
> +++ b/include/linux/usb/msm_hsusb.h
> @@ -164,6 +164,7 @@ struct msm_otg {
> struct usb_phy phy;
> struct msm_otg_platform_data *pdata;
> int irq;
> + int async_irq;
This should be added to the kerneldoc above.
> struct clk *clk;
> struct clk *pclk;
> struct clk *core_clk;
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 01/12] usb: xhci: add sysfs file for xHCI debug port
On 11/20/2015 10:33 PM, Mathias Nyman wrote: On 17.11.2015 08:38, Lu Baolu wrote: This patch adds a sysfs file for users to check 1) whether the debug capability is implemented by hardware; 2) if supported, which state does it stay at. With a host that supports debug port, a file named "debug_port_state" will be created under the device sysfs directory. Reading this file will show users the state (disabled, enabled or configured) of the debug port. With a host that does NOT support debug port, "debug_port_state" file won't be created. Signed-off-by: Lu Baolu --- .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 23 +++ drivers/usb/host/Makefile | 2 +- drivers/usb/host/xhci-ext-caps.h | 14 +++- drivers/usb/host/xhci-sysfs.c | 80 ++ drivers/usb/host/xhci.c| 4 ++ drivers/usb/host/xhci.h| 4 ++ 6 files changed, 125 insertions(+), 2 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 drivers/usb/host/xhci-sysfs.c diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd new file mode 100644 index 000..dd3e722 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd @@ -0,0 +1,23 @@ +What:/sys/bus/pci/drivers/xhci_hcd/.../debug_port_state +Date:November 2015 +KernelVersion:4.3.0 +Contact:Lu Baolu +Description: +This file is designed for users to check the state of a +USB3 debug port. On a machine which supports USB3 debug +port, this file will be created. Reading this file will +show the state (disabled, enabled or configured) of the +debug port. On a machine that doesn't support USB3 debug +port, this file doesn't exist. + +The state of a debug port could be: +1) disabled: The debug port is not enabled and the root +port has been switched to xHCI host as a normal +root port. +2) enabled: The debug port is enabled. The debug port +has been assigned to debug capability. The debug +capability is able to handle the control requests +defined in USB3 spec. +3) configured: The debug port has been enumerated by the +debug host as a debug device. The debug port is +in use now. How much will this sysfs file be used, It looks more like debugging info needed while developing xhci debug port capability. Would it be enough to add something like "supports DbC" in one of the dev_info() lines at xhci driver load if capability is supported? This sysfs file will only be visible after xhci is loaded. I understood that we would like to use the debug port capability even if xhci driver is not used, or then for earlyprintk before xhci is loaded. One use case of this sysfs file is that user can check the DbC status when link disconnection happens during runtime. User then can recover the link with another sysfs file which I will implement later. Some test and debug tools might use DbC as well. Graphic might be an example. The test applications might want to check the DbC status during runtime. diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index e7558ab..810c304 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -12,7 +12,7 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o xhci-hcd-y := xhci.o xhci-mem.o xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o -xhci-hcd-y += xhci-trace.o +xhci-hcd-y += xhci-trace.o xhci-sysfs.o xhci-plat-hcd-y := xhci-plat.o ifneq ($(CONFIG_USB_XHCI_MVEBU), ) diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h index 9fe3225..12c87e5 100644 --- a/drivers/usb/host/xhci-ext-caps.h +++ b/drivers/usb/host/xhci-ext-caps.h @@ -49,8 +49,15 @@ #define XHCI_EXT_CAPS_PM3 #define XHCI_EXT_CAPS_VIRT4 #define XHCI_EXT_CAPS_ROUTE5 -/* IDs 6-9 reserved */ +#define XHCI_EXT_CAPS_LOCALMEM6 +/* IDs 7-9 reserved */ #define XHCI_EXT_CAPS_DEBUG10 +/* IDs 192-255 vendor specific */ +#define XHCI_EXT_CAPS_VEN_START192 +#define XHCI_EXT_CAPS_VEN_END255 The CAPS_VEN_END is probably not needed, all capabilities end at 255 (8 bit) Perhaps just use the EXT_MAX_CAPID defined later Yes. I forgot to remove it when refactoring the code. +#define XHCI_EXT_CAPS_VENDOR(p)(((p) >= XHCI_EXT_CAPS_VEN_START) && \ +((p) <= XHCI_EXT_CAPS_VEN_END)) +#define XHCI_EXT_MAX_CAPIDXHCI_EXT_CAPS_VEN_END /* USB Legacy Support Capability - section 7.1.1 */ #define XHCI_HC_BIOS_OWNED(1 << 16) #define XHCI_HC_OS_OWNED(1 << 24) @@ -73,6 +80,11 @@ #define XHCI_HLC (1 << 19) #define XHCI_BLC (1 << 20) +/* Debug capability - section 7.6.8 */ +#d
[PATCH] USB: quirks: Fix another ELAN touchscreen
Like other buggy models that had their fixes [1], the touchscreen with
id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier
quirk. Otherwise, it fails to respond, blocks the boot for a random
amount of time and pollutes dmesg with:
[ 2887.373196] usb 1-5: new full-speed USB device number 41 using xhci_hcd
[ 2889.502000] usb 1-5: unable to read config index 0 descriptor/start: -71
[ 2889.502005] usb 1-5: can't read configurations, error -71
[ 2889.654571] usb 1-5: new full-speed USB device number 42 using xhci_hcd
[ 2891.783438] usb 1-5: unable to read config index 0 descriptor/start: -71
[ 2891.783443] usb 1-5: can't read configurations, error -71
[1]: See commits c68929f, 876af5d, d749947, a32c99e and dc703ec.
Tested-by: Adrien Vergé
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
drivers/usb/core/quirks.c | 3 +++
3 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ac1feea..6b68408 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -321,6 +321,7 @@
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_01030x0103
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_010c0x010c
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_016F0x016f
+#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_21B80x21b8
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 94bb137..7a45942 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -77,6 +77,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_0103,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_010c,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_016F,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_21B8,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index f5a3819..fcd6ac0 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -125,6 +125,9 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x04f3, 0x016f), .driver_info =
USB_QUIRK_DEVICE_QUALIFIER },
+ { USB_DEVICE(0x04f3, 0x21b8), .driver_info =
+ USB_QUIRK_DEVICE_QUALIFIER },
+
/* Roland SC-8820 */
{ USB_DEVICE(0x0582, 0x0007), .driver_info = USB_QUIRK_RESET_RESUME },
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
