Occasional resume delays, possibly related to failure to resume internal USB devices?
I've had this problem now and then for a couple of months: On system resume, my laptop will appear frozen for more than 30 seconds before finally responding. No keypress or other external input seems to have any effect. Pressing e.g. CapsLock will not lit the LED. But when the laptop finally comes to life, every keypress is replayed. I have tried to find out how to reliably trigger this, but haven't been successful. It happens too infrequently for bisect to be effective. But what I have discovered is that it is related to problems with the internal USB webcam. Whenever there is one of these delays, I also see this in the kernel log, always from the webcam device: Sep 1 12:32:39 nemi kernel: [174042.120072] usb 1-6: device descriptor read/64, error -110 Sep 1 12:32:39 nemi kernel: [174057.336066] usb 1-6: device descriptor read/64, error -110 Sep 1 12:32:39 nemi kernel: [174057.552069] usb 1-6: reset high-speed USB device number 11 using ehci-pci Sep 1 12:32:39 nemi kernel: [174072.664067] usb 1-6: device descriptor read/64, error -110 Sep 1 12:32:39 nemi kernel: [174087.880154] usb 1-6: device descriptor read/64, error -110 Sep 1 12:32:39 nemi kernel: [174088.096131] usb 1-6: reset high-speed USB device number 11 using ehci-pci Sep 1 12:32:39 nemi kernel: [174093.116266] usb 1-6: device descriptor read/8, error -110 Sep 1 12:32:39 nemi kernel: [174098.236333] usb 1-6: device descriptor read/8, error -110 Sep 1 12:32:39 nemi kernel: [174098.452066] usb 1-6: reset high-speed USB device number 11 using ehci-pci Sep 1 12:32:39 nemi kernel: [174103.472272] usb 1-6: device descriptor read/8, error -110 Sep 1 12:32:39 nemi kernel: [174108.592328] usb 1-6: device descriptor read/8, error -110 Sep 1 12:32:39 nemi kernel: [174108.808090] usb 4-2: reset full-speed USB device number 2 using uhci_hcd Sep 1 12:32:39 nemi kernel: [174109.052051] usb 7-1: reset full-speed USB device number 2 using uhci_hcd Sep 1 12:32:39 nemi kernel: [174109.204966] PM: resume of devices complete after 82555.697 msecs As you can see from the last line, resuming devices takes ridiculously long time. Normally it would take approximately on second on this old laptop. The device connected to 1-6 is a Lenovo UVC webcam, and it seems the problem is related to this device somehow. As can be seen above, the webcam fails completely when this happens and just disappears - as expected when you cannot read the device descriptor. But simply suspending and resuming again will always(?) fix the problem, so it is not a major issue. The real annoyance is the delay. I did two changes which I guess could be important in the days before this problem started: 1) upgraded from v3.10-rc6 to v3.10-rc7 2) installed an Intel wlan card with a USB bluetooth device in one of the internal mini-PCIe slots I have never had any USB device in that mini-PCIe slot before, so the last change can potentionally reveal USB wiring problems which has always been there. AFAIK the slot is not documented or officially supported as USB capable, although the bluetooth device seems to work fine. This is how my bus layout normally looks when the webcam is working (the mini-PCIe bluetooth device is the one on bus 7): bjorn@nemi:~$ lsusb -t /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 1: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 2: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 2: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 2: Dev 2, If 2, Class=Vendor Specific Class, Driver=, 12M |__ Port 2: Dev 2, If 3, Class=Application Specific Interface, Driver=, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 4: Dev 46, If 12, Class=Communications, Driver=cdc_mbim, 480M |__ Port 4: Dev 46, If 13, Class=CDC Data, Driver=cdc_mbim, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 6: Dev 13, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 6: Dev 13, If 1, Class=Video, Driver=uvcvideo, 480M Is there any smart way to find out how the UHCI and EHCI ports are related to each other? Unloading ehci-pci results in this tree, which seems to imply that the two mini-PCIe slots are connected to one port each on the same UHCI bus, while the webcam seems unrelated on another controller: bjorn@nemi:~$ lsusb -t /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 1:
[PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support
From: Liu Junliang
Signed-off-by: Liu Junliang
---
drivers/net/usb/Kconfig |8 +
drivers/net/usb/Makefile |1 +
drivers/net/usb/sr9700.c | 560 ++
drivers/net/usb/sr9700.h | 173 ++
4 files changed, 742 insertions(+)
create mode 100644 drivers/net/usb/sr9700.c
create mode 100644 drivers/net/usb/sr9700.h
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 287cc62..a94b196 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -272,6 +272,14 @@ config USB_NET_DM9601
This option adds support for Davicom DM9601 based USB 1.1
10/100 Ethernet adapters.
+config USB_NET_SR9700
+ tristate "CoreChip-sz SR9700 based USB 1.1 10/100 ethernet devices"
+ depends on USB_USBNET
+ select CRC32
+ help
+ This option adds support for CoreChip-sz SR9700 based USB 1.1
+ 10/100 Ethernet adapters.
+
config USB_NET_SMSC75XX
tristate "SMSC LAN75XX based USB 2.0 gigabit ethernet devices"
depends on USB_USBNET
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 9ab5c9d..bba87a2 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_USB_NET_AX88179_178A) += ax88179_178a.o
obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o
obj-$(CONFIG_USB_NET_CDC_EEM) += cdc_eem.o
obj-$(CONFIG_USB_NET_DM9601) += dm9601.o
+obj-$(CONFIG_USB_NET_SR9700) += sr9700.o
obj-$(CONFIG_USB_NET_SMSC75XX) += smsc75xx.o
obj-$(CONFIG_USB_NET_SMSC95XX) += smsc95xx.o
obj-$(CONFIG_USB_NET_GL620A) += gl620a.o
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
new file mode 100644
index 000..7ec3e0e
--- /dev/null
+++ b/drivers/net/usb/sr9700.c
@@ -0,0 +1,560 @@
+/*
+ * CoreChip-sz SR9700 one chip USB 1.1 Ethernet Devices
+ *
+ * Author : Liu Junliang
+ *
+ * Based on dm9601.c
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sr9700.h"
+
+static int sr_read(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+ int err;
+
+ err = usbnet_read_cmd(dev, SR_RD_REGS, SR_REQ_RD_REG, 0, reg, data,
+ length);
+ if ((err != length) && (err >= 0))
+ err = -EINVAL;
+ return err;
+}
+
+static int sr_write(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+ int err;
+
+ err = usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG, 0, reg, data,
+ length);
+ if ((err >= 0) && (err < length))
+ err = -EINVAL;
+ return err;
+}
+
+static int sr_read_reg(struct usbnet *dev, u8 reg, u8 *value)
+{
+ return sr_read(dev, reg, 1, value);
+}
+
+static int sr_write_reg(struct usbnet *dev, u8 reg, u8 value)
+{
+ return usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
+ value, reg, NULL, 0);
+}
+
+static void sr_write_async(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+ usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
+ 0, reg, data, length);
+}
+
+static void sr_write_reg_async(struct usbnet *dev, u8 reg, u8 value)
+{
+ usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
+ value, reg, NULL, 0);
+}
+
+static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
+{
+ int i;
+
+ for (i = 0; i < SR_SHARE_TIMEOUT; i++) {
+ u8 tmp = 0;
+ int ret;
+
+ udelay(1);
+ ret = sr_read_reg(dev, EPCR, &tmp);
+ if (ret < 0)
+ return ret;
+
+ /* ready */
+ if (!(tmp & EPCR_ERRE))
+ return 0;
+ }
+
+ netdev_err(dev->net, "%s write timed out!\n", phy ? "phy" : "eeprom");
+
+ return -EIO;
+}
+
+static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg,
+ __le16 *value)
+{
+ int ret;
+
+ mutex_lock(&dev->phy_mutex);
+
+ sr_write_reg(dev, EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
+ sr_write_reg(dev, EPCR, phy ? (EPCR_EPOS | EPCR_ERPRR) : EPCR_ERPRR);
+
+ ret = wait_phy_eeprom_ready(dev, phy);
+ if (ret < 0)
+ goto out_unlock;
+
+ sr_write_reg(dev, EPCR, 0x0);
+ ret = sr_read(dev, EPDR, 2, value);
+
+ netdev_dbg(dev->net, "read shared %d 0x%02x returned 0x%04x, %d\n",
+ phy, reg, *value, ret);
+
+out_unlock:
+ mutex_unlock(&dev->phy_mutex);
+ return ret;
+}
+
+static int sr_share_write_word(struct usbnet *dev, int phy, u8 reg,
+ __le16 value)
+{
+ int ret;
+
+ mutex_
Re: Bug report: 045e:0721 Microsoft LifeCam NX-3000 not detected
Your new patch get back the bug. Then I have decrease the delay in steps of 25. With delay 100 camera still fails. With delay 75 camera works sometimes. Some plug in failes, some other works. With delay 50 camera always work okay! Am 31.08.2013 20:12, schrieb Alan Stern: On Sat, 31 Aug 2013, Jürgen Liebmann wrote: Hi Alan, thank you for your help. This patch fixed this problem! Now the camera works fine. Then I download the newest kernel (3.11.0-rc7), this contain the same error. I checked out this kernel, inserted your patch and the camera works fine! This place is therefore definitely the cause of my problem. We're not finished yet. Let's see what happens with an additional delay added in, same as if the patch wasn't present. Try this patch instead of the previous one. Alan Stern Index: 3.10/drivers/usb/host/ehci-q.c === --- 3.10.orig/drivers/usb/host/ehci-q.c +++ 3.10/drivers/usb/host/ehci-q.c @@ -1170,7 +1170,7 @@ static void single_unlink_async(struct e struct ehci_qh *prev; /* Add to the end of the list of QHs waiting for the next IAAD */ - qh->qh_state = QH_STATE_UNLINK_WAIT; + qh->qh_state = QH_STATE_UNLINK; if (ehci->async_unlink) ehci->async_unlink_last->unlink_next = qh; else @@ -1186,6 +1186,7 @@ static void single_unlink_async(struct e prev->qh_next = qh->qh_next; if (ehci->qh_scan_next == qh) ehci->qh_scan_next = qh->qh_next.qh; + udelay(125); } static void start_iaa_cycle(struct ehci_hcd *ehci, bool nested) -- Jürgen Liebmann Erich-Schütze-Weg 6 01796 Pirna Tel.: 03501-445273 Email: i...@pirna-esw6.de -- 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
[PATCH 0/2 v3] Various fixes for the dummy_hcd driver
These two patches fix some minor issues in the dummy_hcd driver. Both errors were detected with the help of coverity analysis. These patches have been updated based on Alan Sterns comments. For the first patch I have harmonized both occurences of the different clean-up routine as suggested. And the correct one this time. The second patch should now finally have the correct test. Thank you Alan for your patience, I should really not make patches late at night. Philippe De Swert (2): usb:gadget:dummy_hcd : Avoid infinite loop usb:gadget:dummy_hcd : Detect port and link state correctly to avoid unreachable code drivers/usb/gadget/dummy_hcd.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) -- 1.8.1.2 -- 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
[PATCH 1/2 v3] usb:gadget:dummy_hcd : Avoid infinite loop
When an error occurs adding a udc platform device there is a risk of an
infinite loop.
If more than one platform device was added i will remain >= than 0. The
intention seems
to clean up all the different already added platform devices before the failure
occurs,
so fixed the code to actually do so. We need to decrement first because the
adding at the current
index of i is the one that failed.
At the same time the code is harmonized for hcd platform adding.
Found with coverity : CID 751073
Signed-off-by: Philippe De Swert
---
drivers/usb/gadget/dummy_hcd.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index c588e8e..03a2300 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -2684,9 +2684,8 @@ static int __init init(void)
for (i = 0; i < mod_data.num; i++) {
retval = platform_device_add(the_hcd_pdev[i]);
if (retval < 0) {
- i--;
- while (i >= 0)
- platform_device_del(the_hcd_pdev[i--]);
+ while (--i >= 0)
+ platform_device_del(the_hcd_pdev[i]);
goto err_add_hcd;
}
}
@@ -2705,8 +2704,7 @@ static int __init init(void)
for (i = 0; i < mod_data.num; i++) {
retval = platform_device_add(the_udc_pdev[i]);
if (retval < 0) {
- i--;
- while (i >= 0)
+ while (--i >= 0)
platform_device_del(the_udc_pdev[i]);
goto err_add_udc;
}
--
1.8.1.2
--
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
[PATCH 2/2 v3] usb:gadget:dummy_hcd : Detect port and link state correctly to avoid unreachable code
Since USB_SS_PORT_LS_U0 is 0x the & operation with the port state would always be 0. Thus the if would never be true. Moreover USB_PORT_STAT_ENABLE is 0x0002 and as such would never equal to 1. What we actually look for is a port that is enabled and in U0/link active state. Thanks to Alan Stern for suggesting the correct test in this case. Found with coverity: CID 744367, CID 145679 Signed-off-by: Philippe De Swert --- drivers/usb/gadget/dummy_hcd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c index 03a2300..ea191d4 100644 --- a/drivers/usb/gadget/dummy_hcd.c +++ b/drivers/usb/gadget/dummy_hcd.c @@ -312,9 +312,9 @@ static void set_link_state_by_speed(struct dummy_hcd *dum_hcd) dum_hcd->port_status |= (USB_PORT_STAT_C_CONNECTION << 16); if ((dum_hcd->port_status & -USB_PORT_STAT_ENABLE) == 1 && - (dum_hcd->port_status & -USB_SS_PORT_LS_U0) == 1 && +USB_PORT_STAT_ENABLE) != 0 && + (dum_hcd->port_status & USB_PORT_STAT_LINK_STATE) + == USB_SS_PORT_LS_U0 && dum_hcd->rh_state != DUMMY_RH_SUSPENDED) dum_hcd->active = 1; } -- 1.8.1.2 -- 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 1/2 v3] usb:gadget:dummy_hcd : Avoid infinite loop
On Sun, 1 Sep 2013, Philippe De Swert wrote: > When an error occurs adding a udc platform device there is a risk of an > infinite loop. > If more than one platform device was added i will remain >= than 0. The > intention seems > to clean up all the different already added platform devices before the > failure occurs, > so fixed the code to actually do so. We need to decrement first because the > adding at the current > index of i is the one that failed. > > At the same time the code is harmonized for hcd platform adding. > > Found with coverity : CID 751073 > > Signed-off-by: Philippe De Swert Acked-by: 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: [PATCH 2/2 v3] usb:gadget:dummy_hcd : Detect port and link state correctly to avoid unreachable code
On Sun, 1 Sep 2013, Philippe De Swert wrote: > Since USB_SS_PORT_LS_U0 is 0x the & operation with the port state would > always be 0. Thus the if would never be true. Moreover USB_PORT_STAT_ENABLE > is 0x0002 and as such would never equal to 1. What we actually look for is a > port that is enabled and in U0/link active state. > > Thanks to Alan Stern for suggesting the correct test in this case. > > Found with coverity: CID 744367, CID 145679 > > Signed-off-by: Philippe De Swert Acked-by: 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: Occasional resume delays, possibly related to failure to resume internal USB devices?
On Sun, 1 Sep 2013, Bjørn Mork wrote: > I've had this problem now and then for a couple of months: On system > resume, my laptop will appear frozen for more than 30 seconds before > finally responding. No keypress or other external input seems to have > any effect. Pressing e.g. CapsLock will not lit the LED. But when the > laptop finally comes to life, every keypress is replayed. > > I have tried to find out how to reliably trigger this, but haven't been > successful. It happens too infrequently for bisect to be effective. > But what I have discovered is that it is related to problems with the > internal USB webcam. Whenever there is one of these delays, I also see > this in the kernel log, always from the webcam device: Clearly this results from a failure to put the webcam back to full power. > Sep 1 12:32:39 nemi kernel: [174042.120072] usb 1-6: device descriptor > read/64, error -110 > Sep 1 12:32:39 nemi kernel: [174057.336066] usb 1-6: device descriptor > read/64, error -110 > Sep 1 12:32:39 nemi kernel: [174057.552069] usb 1-6: reset high-speed USB > device number 11 using ehci-pci > Sep 1 12:32:39 nemi kernel: [174072.664067] usb 1-6: device descriptor > read/64, error -110 > Sep 1 12:32:39 nemi kernel: [174087.880154] usb 1-6: device descriptor > read/64, error -110 > Sep 1 12:32:39 nemi kernel: [174088.096131] usb 1-6: reset high-speed USB > device number 11 using ehci-pci > Sep 1 12:32:39 nemi kernel: [174093.116266] usb 1-6: device descriptor > read/8, error -110 > Sep 1 12:32:39 nemi kernel: [174098.236333] usb 1-6: device descriptor > read/8, error -110 > Sep 1 12:32:39 nemi kernel: [174098.452066] usb 1-6: reset high-speed USB > device number 11 using ehci-pci > Sep 1 12:32:39 nemi kernel: [174103.472272] usb 1-6: device descriptor > read/8, error -110 > Sep 1 12:32:39 nemi kernel: [174108.592328] usb 1-6: device descriptor > read/8, error -110 > Sep 1 12:32:39 nemi kernel: [174108.808090] usb 4-2: reset full-speed USB > device number 2 using uhci_hcd > Sep 1 12:32:39 nemi kernel: [174109.052051] usb 7-1: reset full-speed USB > device number 2 using uhci_hcd > Sep 1 12:32:39 nemi kernel: [174109.204966] PM: resume of devices complete > after 82555.697 msecs > > As you can see from the last line, resuming devices takes ridiculously > long time. Normally it would take approximately on second on this old > laptop. This is a problem we have known about for many years, but nobody has complained loudly enough for any changes to be made. When initializing or resetting a device, the USB core tries too hard and takes too long. It uses two different initialization algorithms, with various nested retry loops and long timeouts. If you want to look through the code and try making your own changes, the guilty parties are hub_port_init() and hub_port_connect_change() (which calls hub_port_init in a loop) in drivers/usb/core/hub.c. Normally this doesn't matter, because it happens more or less transparently in the background. But during system resume it can be annoying, and during system suspend it can result in a freezer timeout and failure to suspend. > The device connected to 1-6 is a Lenovo UVC webcam, and it seems the > problem is related to this device somehow. As can be seen above, the > webcam fails completely when this happens and just disappears - as > expected when you cannot read the device descriptor. But simply > suspending and resuming again will always(?) fix the problem, so it is > not a major issue. The real annoyance is the delay. > > I did two changes which I guess could be important in the days before > this problem started: > 1) upgraded from v3.10-rc6 to v3.10-rc7 > 2) installed an Intel wlan card with a USB bluetooth device in one of > the internal mini-PCIe slots > > I have never had any USB device in that mini-PCIe slot before, so the > last change can potentionally reveal USB wiring problems which has > always been there. AFAIK the slot is not documented or officially > supported as USB capable, although the bluetooth device seems to work > fine. It's possible that adding the new card could create enough interference to mess up the webcam during resume. > This is how my bus layout normally looks when the webcam is working (the > mini-PCIe bluetooth device is the one on bus 7): > > bjorn@nemi:~$ lsusb -t > /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M > /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M > |__ Port 1: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M > |__ Port 1: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M > |__ Port 2: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M > |__ Port 2: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M > |__ Port 2: Dev 2, If
Re: Bug report: 045e:0721 Microsoft LifeCam NX-3000 not detected
On Sun, 1 Sep 2013, Jürgen Liebmann wrote: > Your new patch get back the bug. > > Then I have decrease the delay in steps of 25. > With delay 100 camera still fails. > With delay 75 camera works sometimes. Some plug in failes, some other works. > With delay 50 camera always work okay! This proves it isn't a software problem. The software does exactly the same thing each time, just with a different delay. Either the camera or the computer's USB hardware is malfunctioning. The easiest way to tell which would be to try the camera with a different computer. (Or maybe try using a different LifeCam with the same computer, but that might not prove anything -- both cameras may have the same bug.) It might be possible to work around the problem by changing the uvcvideo driver, as Laurent suggested. 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: Bug report: 045e:0721 Microsoft LifeCam NX-3000 not detected
Hi Jürgen, On Sunday 01 September 2013 08:06:18 Jürgen Liebmann wrote: > Laurent, how can I set the UVC_QUIRK_PROBE_DEF quirk? > I'm only a user, not a expert or programmer! 1. Unplug your webcam 2. Unload the uvcvideo module (rmmod uvcvideo) 3. Reload the module with the quirks parameter set to 0x100 (modprobe uvcvideo quirks=0x100) 4. Replug your webcam 5. Enjoy :-) -- Regards, Laurent Pinchart -- 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
xhci usb issues
Hello, I am not able to figure out how to connect a 1.11 usb full speed device to a USB 3.0 port. This is the output in syslog when I rmmod xhci_hcd and modprobe xhci-hcd: http://codepad.org/8mc0tABX These are the messages that seem to be causing the issue: Sep 1 15:57:03 master kernel: [ 1182.014895] usb 6-1: device not accepting address 2, error -62 Sep 1 15:57:03 master kernel: [ 1182.014942] xhci_hcd :03:00.0: Bad Slot ID 1 Sep 1 15:57:03 master kernel: [ 1182.014945] xhci_hcd :03:00.0: Could not allocate xHCI USB device data structures Sep 1 15:57:03 master kernel: [ 1182.014950] hub 6-0:1.0: couldn't allocate port 1 usb_device When I plug in the USB full speed device, these are the messages: Sep 1 16:00:17 master kernel: [ 1376.248867] usb usb6: usb wakeup-resume Sep 1 16:00:17 master kernel: [ 1376.248875] usb usb6: usb auto-resume Sep 1 16:00:17 master kernel: [ 1376.248894] hub 6-0:1.0: hub_resume Sep 1 16:00:17 master kernel: [ 1376.248905] hub 6-0:1.0: port 1: status 0101 change Sep 1 16:00:17 master kernel: [ 1376.248910] hub 6-0:1.0: port 2: status 0101 change 0001 Sep 1 16:00:17 master kernel: [ 1376.349888] hub 6-0:1.0: state 7 ports 2 chg 0006 evt Sep 1 16:00:17 master kernel: [ 1376.349898] hub 6-0:1.0: port 1, status 0101, change , 12 Mb/s Sep 1 16:00:17 master kernel: [ 1376.451953] usb 6-1: new full-speed USB device number 3 using xhci_hcd Sep 1 16:00:22 master kernel: [ 1381.455764] xhci_hcd :03:00.0: Timeout while waiting for address device command Sep 1 16:00:27 master kernel: [ 1386.660767] xhci_hcd :03:00.0: Timeout while waiting for address device command Sep 1 16:00:27 master kernel: [ 1386.861922] usb 6-1: device not accepting address 3, error -62 Sep 1 16:00:27 master kernel: [ 1386.861977] xhci_hcd :03:00.0: Bad Slot ID 2 Sep 1 16:00:27 master kernel: [ 1386.861980] xhci_hcd :03:00.0: Could not allocate xHCI USB device data structures Sep 1 16:00:27 master kernel: [ 1386.861985] hub 6-0:1.0: couldn't allocate port 1 usb_device Sep 1 16:00:27 master kernel: [ 1386.862006] hub 6-0:1.0: port 2, status 0101, change , 12 Mb/s Sep 1 16:00:27 master kernel: [ 1386.964011] usb 6-2: new full-speed USB device number 4 using xhci_hcd Sep 1 16:00:32 master kernel: [ 1391.967825] xhci_hcd :03:00.0: Timeout while waiting for address device command Sep 1 16:00:38 master kernel: [ 1397.172814] xhci_hcd :03:00.0: Timeout while waiting for address device command Sep 1 16:00:38 master kernel: [ 1397.373975] usb 6-2: device not accepting address 4, error -62 Sep 1 16:00:38 master kernel: [ 1397.374027] xhci_hcd :03:00.0: Bad Slot ID 3 Sep 1 16:00:38 master kernel: [ 1397.374030] xhci_hcd :03:00.0: Could not allocate xHCI USB device data structures Sep 1 16:00:38 master kernel: [ 1397.374035] hub 6-0:1.0: couldn't allocate port 2 usb_device Sep 1 16:00:38 master kernel: [ 1397.374052] hub 6-0:1.0: hub_suspend Sep 1 16:00:38 master kernel: [ 1397.374077] usb usb6: bus auto-suspend, wakeup 1 With the USB 2.0 hub, I could use usbmon to check out why the device does not work. Using usbmon on a USB 3.0 hub does not seem to show any valuable output. I tried both usbmon client and 'cat 6u' (where 6 is the bus id) to check usbmon output. I am the developer for this usb device and the device works fine on a 1.11 and a 2.0 hub. With the kernel xhci debugging option, there is a lot of output, I am wondering if there is a usbmon-like debugging mechanism for xhci. Any thoughts, please? Thanks Joe Complete syslog message on modprobe xhci-hcd and pluggin in the usb 1.11 full speed device: Sep 1 15:56:33 master kernel: [ 1152.169082] xhci_hcd :03:00.0: remove, state 4 Sep 1 15:56:33 master kernel: [ 1152.169087] xhci_hcd :03:00.0: roothub graceful disconnect Sep 1 15:56:33 master kernel: [ 1152.169091] usb usb7: USB disconnect, device number 1 Sep 1 15:56:33 master kernel: [ 1152.169092] usb usb7: unregistering device Sep 1 15:56:33 master kernel: [ 1152.169094] usb usb7: unregistering interface 7-0:1.0 Sep 1 15:56:33 master kernel: [ 1152.169152] usb usb7: usb_disable_device nuking all URBs Sep 1 15:56:33 master kernel: [ 1152.169154] xHCI xhci_drop_endpoint called for root hub Sep 1 15:56:33 master kernel: [ 1152.169155] xHCI xhci_check_bandwidth called for root hub Sep 1 15:56:33 master kernel: [ 1152.169224] xhci_hcd :03:00.0: USB bus 7 deregistered Sep 1 15:56:33 master kernel: [ 1152.169256] xhci_hcd :03:00.0: remove, state 4 Sep 1 15:56:33 master kernel: [ 1152.169258] xhci_hcd :03:00.0: roothub graceful disconnect Sep 1 15:56:33 master kernel: [ 1152.169260] usb usb6: USB disconnect, device number 1 Sep 1 15:56:33 master kernel: [ 1152.169262] usb usb6: unregistering device Sep 1 15:56:33 master kernel: [ 1152.169263] usb usb6: unregistering interface 6-0:1.0 Sep 1 15:56:33 master kernel: [ 1152.169297] usb usb6: usb_disable_device nuking all URBs Sep 1 15:56:33 master kerne
Re: xhci usb issues
Hello, Thought this might be of some help too. sudo lspci -vvv 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [88] Subsystem: Giga-byte Technology Device 5000 Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: Capabilities: [a0] Express (v2) Root Port (Slot+), MSI 00 DevCap:MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta:CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap:Port #2, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <4us ClockPM- Surprise- LLActRep- BwNot+ LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta:Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt+ SltCap:AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #1, PowerLimit 0.000W; Interlock- NoCompl+ SltCtl:Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta:Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet+ LinkState- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR+, OBFF Not Supported ARIFwd- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [100 v1] Virtual Channel Caps:LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl:ArbSelect=Fixed Status:InProgress- VC0:Caps:PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl:Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status:NegoPending- InProgress- Capabilities: [140 v1] Root Complex Link Desc:PortNumber=02 ComponentID=01 EltType=Config Link0:Desc:TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped LinkValid+ Addr:9000 Kernel driver in use: pcieport 00:02.0 Display controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) Subsystem: Giga-byte Technology Device d000 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 DevCap:MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta:CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap:Port #1, Speed 5GT/s, Width x1, ASPM L0s, Latency L0 <1us, L1 <4us ClockPM- Surprise- LLActRep+ BwNot- LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDi
Re: [PATCH 1/3] usbcore: set lpm_capable field for LPM capable root hubs
On 09/01/2013 06:04 AM, Greg KH wrote: On Sun, Sep 01, 2013 at 02:56:42AM +0200, Martin MOKREJŠ wrote: Martin MOKREJŠ wrote: Hi Xenia, I tried these 3 patches and ... I will rather leave it up to you to decide if everything went right. Attached is a diff of dmesg from unpatched and patched 3.10.9 kernel. USB3 devices were connected before cold bootup, sadly in latter test the ordering changed a bit so that added to the length of the diff. Can't say what those Prolific-related messages mean. Just in case you need more info I attach "lsub -v" as well. One more addition. When I disconnected the external hard drives from the external HUB I got: [ 1677.615301] usb 4-1.1: USB disconnect, device number 4 [ 1677.619345] usb 4-1.1: Set SEL for device-initiated U1 failed. [ 1677.619369] usb 4-1.1: Set SEL for device-initiated U2 failed. I'm seeing these on the 3.10 kernels, and it's really starting to annoy me... greg k-h I think this message is generated because usb_disable_device() calls usb_enable_lpm() (through a call to usb_disable_lpm()) that submits a USB_REQ_SET_SEL request to the device which fails since the device state has been already set (before the call to usb_disable_device()) to the NOTATTACHED state. So maybe we should not call usb_disable_lpm() if the device is not attached. ksenia -- 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 1/3] usbcore: set lpm_capable field for LPM capable root hubs
On Mon, Sep 02, 2013 at 12:25:30AM +0300, Xenia Ragiadakou wrote: > On 09/01/2013 06:04 AM, Greg KH wrote: > >On Sun, Sep 01, 2013 at 02:56:42AM +0200, Martin MOKREJŠ wrote: > >> > >>Martin MOKREJŠ wrote: > >>>Hi Xenia, > >>> I tried these 3 patches and ... I will rather leave it up to you to > >>> decide > >>>if everything went right. Attached is a diff of dmesg from unpatched and > >>>patched > >>>3.10.9 kernel. USB3 devices were connected before cold bootup, sadly in > >>>latter test > >>>the ordering changed a bit so that added to the length of the diff. Can't > >>>say > >>>what those Prolific-related messages mean. Just in case you need more info > >>>I attach "lsub -v" as well. > >>One more addition. When I disconnected the external hard drives from the > >>external > >>HUB I got: > >> > >>[ 1677.615301] usb 4-1.1: USB disconnect, device number 4 > >>[ 1677.619345] usb 4-1.1: Set SEL for device-initiated U1 failed. > >>[ 1677.619369] usb 4-1.1: Set SEL for device-initiated U2 failed. > >I'm seeing these on the 3.10 kernels, and it's really starting to annoy > >me... > > > >greg k-h > > I think this message is generated because usb_disable_device() calls > usb_enable_lpm() (through a call to usb_disable_lpm()) that submits > a USB_REQ_SET_SEL request to the device which fails since the device > state has been already set (before the call to usb_disable_device()) > to the NOTATTACHED state. So maybe we should not call > usb_disable_lpm() if the device is not attached. That makes sense to me or have the function itself test if the device is connected or not. thanks, 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
[PATCH] usbcore: add check on usb device's state before trying to disable lpm
This patch adds a check to ensure that the device's state is not NOTATTACHED,
ATTACHED, POWERED or RECONNECTING before trying to disable lpm, because if
the device is in one of those states the control transfer to disable
device-initiated LPM will fail (as well as any transfer, since usb_submit_urb()
will fail).
Signed-off-by: Xenia Ragiadakou
---
drivers/usb/core/hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index fe8d95d..a6c10f0 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3716,7 +3716,7 @@ int usb_disable_lpm(struct usb_device *udev)
{
struct usb_hcd *hcd;
- if (!udev || !udev->parent ||
+ if (!udev || udev->state < USB_STATE_UNAUTHENTICATED || !udev->parent ||
udev->speed != USB_SPEED_SUPER ||
!udev->lpm_capable)
return 0;
--
1.8.3.4
--
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
[PATCH v2] usbcore: add check on usb device's state before trying to disable lpm
This patch adds a check to ensure that the device's state is not NOTATTACHED,
ATTACHED, POWERED or RECONNECTING before trying to disable lpm, because if
the device is in one of those states the control transfer to disable
device-initiated LPM will fail (as well as any transfer, since usb_submit_urb()
will fail).
Signed-off-by: Xenia Ragiadakou
Reported-by: Martin MOKREJS
---
drivers/usb/core/hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index fe8d95d..a6c10f0 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3716,7 +3716,7 @@ int usb_disable_lpm(struct usb_device *udev)
{
struct usb_hcd *hcd;
- if (!udev || !udev->parent ||
+ if (!udev || udev->state < USB_STATE_UNAUTHENTICATED || !udev->parent ||
udev->speed != USB_SPEED_SUPER ||
!udev->lpm_capable)
return 0;
--
1.8.3.4
--
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 v2] usbcore: add check on usb device's state before trying to disable lpm
On Mon, 2 Sep 2013, Xenia Ragiadakou wrote:
> This patch adds a check to ensure that the device's state is not NOTATTACHED,
> ATTACHED, POWERED or RECONNECTING before trying to disable lpm, because if
> the device is in one of those states the control transfer to disable
> device-initiated LPM will fail (as well as any transfer, since
> usb_submit_urb()
> will fail).
>
> Signed-off-by: Xenia Ragiadakou
> Reported-by: Martin MOKREJS
> ---
> drivers/usb/core/hub.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index fe8d95d..a6c10f0 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -3716,7 +3716,7 @@ int usb_disable_lpm(struct usb_device *udev)
> {
> struct usb_hcd *hcd;
>
> - if (!udev || !udev->parent ||
> + if (!udev || udev->state < USB_STATE_UNAUTHENTICATED || !udev->parent ||
> udev->speed != USB_SPEED_SUPER ||
> !udev->lpm_capable)
> return 0;
You should ask Sarah to check this out, because link power management
is used only with USB-3 devices.
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: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
On 8/30/2013 12:23 PM, Chanwoo Choi wrote:
Hi George,
On 08/30/2013 03:15 PM, George Cherian wrote:
Hi Chanwoo,
On 8/30/2013 5:41 AM, Chanwoo Choi wrote:
Hi George,
On 08/29/2013 10:45 PM, George Cherian wrote:
Hi Chanwoo,
On 8/29/2013 5:42 PM, Chanwoo Choi wrote:
[big snip ]
I tested various development board based on Samsung Exynos series SoC.
Although some gpio of Exynos series SoC set high state(non zero, 1) as default
value,
this gpio state could mean off state, disconnected or un-powered state
according to gpio.
Of course, above explanation about specific gpio don't include all gpios.
This is meaning that there is possibility.
okay then how about adding a flag for inverted logic too. something like this
if(of_property_read_bool(np,"inverted_gpio))
gpio_usbvid->gpio_inv = 1;
And always check on this before deciding?
Is this fine ?
OK.
But, as Stephen commented on other mail, you should use proper DT helper
function.
okay
Second,
gpio_usbvid_set_initial_state() dertermine both "USB-HOST" and "USB" cable
state at same time
in 'case ID_DETCT' according to 'gpio_usbvid->id_gpio'. But, I think that other
extcon devices
would not control both "USB-HOST" and "USB" cable state at same time.
Other extcon devices would support either "USB-HOST" or "USB" cable.
The driver has 2 configurations.
1) supports implementations with both VBUS and ID pin are routed via gpio's for
swicthing roles(compatible gpio-usb-vid).
As you explained about case 1, it is only used on dra7x SoC.
No gpio-usb-id is used in dra7xx. dra7xx has got only ID pin routed via gpio.
Other SoC could not wish to control both "USB-HOST" and "USB" cable at same
time.
I could'nt actually parse this. You meant since the id_irq_handler handles both
USB and USB-HOST cable
its not proper?
It's not proper in general case. The generic driver must guarantee all of
extcon device using gpio.
As far as I know, the generic driver cannot direclty control gpio pin and get
value from gpio pin.
Almost device driver including in kernel/drivers control gpio pin on specific
device driver
instead of generic driver.
But without reading the gpio value how can we set the cable states? for this
driver the assumption is the dedicated gpio
is always DIR_IN and in the driver we just read the value.
I need your answer about above my opinion for other SoC.
So how about this, I have removed the dra7x specific stuffs (gpio-usb-id)
static void gpio_usbvid_set_initial_state(struct gpio_usbvid *gpio_usbvid)
{
int id_current, vbus_current;
id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
if (!!id_current == ID_FLOAT)
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", false);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", true);
vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
if (!!vbus_current == VBUS_ON)
extcon_set_cable_state(&gpio_usbvid->edev, "USB", true);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB", false);
}
and the irq handlers like this
static irqreturn_t id_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int id_current;
id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
if (id_current == ID_GND)
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", true);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", false);
return IRQ_HANDLED;
}
static irqreturn_t vbus_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int vbus_current;
vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
if (vbus_current == VBUS_OFF)
extcon_set_cable_state(&gpio_usbvid->edev, "USB", false);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB", true);
return IRQ_HANDLED;
}
I know your intention dividing interrupt handler for each cable.
But I don't think this driver must guarantee all of extcon device using gpio.
For example,
below three SoC wish to detect USB/USB-HOST cable with each different methods.
"SoC A" wish to detect USB/USB-HOST cable through only one gpio pin.
You mean to say that both USB ID pin and VBUS are connected to same gpio?
If so that is a really bad h/w design and it will not fly.
Or, you meant that only USB ID pin is connected to single gpio and it controls
the state of the USB/USB-HOST cables?
If so thats what exactly the v3 driver did with compatible gpio-usb-id.
My original question intention,
I'd like you to answer that this driver can support all case of "SoC A"/"SoC B"/"SoC
C" without othe implementation?
Definitely supports SoC A and SoC C. this is neither a generic extcon
driver nor a generic gpio driver.
This is a generic driver for USB VBUS-ID detection
Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
On 8/30/2013 12:44 PM, Chanwoo Choi wrote:
Hi George,
In addition, I add answer about that device driver control gpio pin directly.
On 08/30/2013 03:15 PM, George Cherian wrote:
Hi Chanwoo,
On 8/30/2013 5:41 AM, Chanwoo Choi wrote:
Hi George,
On 08/29/2013 10:45 PM, George Cherian wrote:
Hi Chanwoo,
On 8/29/2013 5:42 PM, Chanwoo Choi wrote:
[big snip ]
I tested various development board based on Samsung Exynos series SoC.
Although some gpio of Exynos series SoC set high state(non zero, 1) as default
value,
this gpio state could mean off state, disconnected or un-powered state
according to gpio.
Of course, above explanation about specific gpio don't include all gpios.
This is meaning that there is possibility.
okay then how about adding a flag for inverted logic too. something like this
if(of_property_read_bool(np,"inverted_gpio))
gpio_usbvid->gpio_inv = 1;
And always check on this before deciding?
Is this fine ?
OK.
But, as Stephen commented on other mail, you should use proper DT helper
function.
okay
Second,
gpio_usbvid_set_initial_state() dertermine both "USB-HOST" and "USB" cable
state at same time
in 'case ID_DETCT' according to 'gpio_usbvid->id_gpio'. But, I think that other
extcon devices
would not control both "USB-HOST" and "USB" cable state at same time.
Other extcon devices would support either "USB-HOST" or "USB" cable.
The driver has 2 configurations.
1) supports implementations with both VBUS and ID pin are routed via gpio's for
swicthing roles(compatible gpio-usb-vid).
As you explained about case 1, it is only used on dra7x SoC.
No gpio-usb-id is used in dra7xx. dra7xx has got only ID pin routed via gpio.
Other SoC could not wish to control both "USB-HOST" and "USB" cable at same
time.
I could'nt actually parse this. You meant since the id_irq_handler handles both
USB and USB-HOST cable
its not proper?
It's not proper in general case. The generic driver must guarantee all of
extcon device using gpio.
As far as I know, the generic driver cannot direclty control gpio pin and get
value from gpio pin.
Almost device driver including in kernel/drivers control gpio pin on specific
device driver
instead of generic driver.
But without reading the gpio value how can we set the cable states?
hmm. I mentioned above my answer as following:
>> As far as I know, the generic driver cannot direclty control gpio
pin and get value from gpio pin.
>> Almost device driver including in kernel/drivers control gpio pin on
specific device driver
Because your extcon driver directly control gpio pin so I think your extcon
driver isn't generic.
for this driver the assumption is the dedicated gpio
Obviously when I am writing a generic driver for USB VBUS-ID detetction
which is via gpio then i assume I have a dedicated gpio.
what is wrong in that assumption? How else can you detect ID pin change
and VBUS change via gpio if not you have them dedicated?
is always DIR_IN and in the driver we just read the value.
What is DIR_IN?
Direction IN gpio.
I need your answer about above my opinion for other SoC.
So how about this, I have removed the dra7x specific stuffs (gpio-usb-id)
static void gpio_usbvid_set_initial_state(struct gpio_usbvid *gpio_usbvid)
{
int id_current, vbus_current;
id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
if (!!id_current == ID_FLOAT)
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", false);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", true);
vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
if (!!vbus_current == VBUS_ON)
extcon_set_cable_state(&gpio_usbvid->edev, "USB", true);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB", false);
}
and the irq handlers like this
static irqreturn_t id_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int id_current;
id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
if (id_current == ID_GND)
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", true);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", false);
return IRQ_HANDLED;
}
static irqreturn_t vbus_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int vbus_current;
vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
if (vbus_current == VBUS_OFF)
extcon_set_cable_state(&gpio_usbvid->edev, "USB", false);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB", true);
return IRQ_HANDLED;
}
I know your intention dividing interrupt handler for each cable.
But I don't think this driver must guarantee all of extcon device using gpio.
For example,
below three SoC wish to detect USB/USB-HOST
Re: Bug report: 045e:0721 Microsoft LifeCam NX-3000 not detected
Thanks Laurent, this resolves the problem. The camera now works fine. But how can I load uvcvideo module with quirks parameter permanent? Am 01.09.2013 22:59, schrieb Laurent Pinchart: Hi Jürgen, On Sunday 01 September 2013 08:06:18 Jürgen Liebmann wrote: Laurent, how can I set the UVC_QUIRK_PROBE_DEF quirk? I'm only a user, not a expert or programmer! 1. Unplug your webcam 2. Unload the uvcvideo module (rmmod uvcvideo) 3. Reload the module with the quirks parameter set to 0x100 (modprobe uvcvideo quirks=0x100) 4. Replug your webcam 5. Enjoy :-) -- Jürgen Liebmann Erich-Schütze-Weg 6 01796 Pirna Tel.: 03501-445273 Email: i...@pirna-esw6.de -- 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: "Set SEL for device-initiated U1 failed." errors
On Fri, Aug 30, 2013 at 02:58:25AM +0800, Alan Stern wrote:
> On Thu, 29 Aug 2013, Sarah Sharp wrote:
>
> > On Thu, Aug 29, 2013 at 10:06:16AM -0700, Greg Kroah-Hartman wrote:
> > > Hi Sarah,
> > >
> > > I'm getting the following warnings from the 3.10.9 kernel all the time
> > > when I unplug a USB 3 storage device from my laptop:
> > > [203282.987687] usb 4-1: USB disconnect, device number 21
> > > [203282.992904] usb 4-1: Set SEL for device-initiated U1 failed.
> > > [203282.992909] usb 4-1: Set SEL for device-initiated U2 failed.
> > >
> > > What can a "normal" user do with these "failed" messages? If nothing,
> > > shouldn't we just turn them into debug messages instead?
> >
> > Yes, those messages should probably be toned down to debug level instead
> > of warning level. If a device doesn't respond to the Set SEL request
> > when USB 3.0 LPM is enabled, the user has a buggy device. Of course, I
> > doubt anyone is going to return a drive based on those messages.
> >
> > That error message happens because the USB core is attempting to disable
disable LPM or in case of enable LPM? Is n't this warning message
coming from usb_enable_lpm -> usb_enable_link_state
3600 ret = usb_req_set_sel(udev, state);
3601 if (ret < 0) {
3602 dev_warn(&udev->dev, "Set SEL for
device-initiated %s failed.\n",
3603 usb3_lpm_names[state]);
3604 return;
3605 }
> > LPM for a disconnected device. The control transfer to set SEL fails,
> > resulting in those messages. The xHCI driver still needs to disable the
> > U1 and U2 timeouts for the port, so the core still needs to call into
> > usb_set_lpm_timeout. However, we could skip the control transfer to the
> > device.
> >
> > The problem is that the USB core doesn't mark the device as DISCONNECTED
> > until after it attempts to disable LPM.
>
> Are you certain? Look at the order of the lines in the log above.
>
> > The device is still marked as
> > being in the configured state, because we don't return early in this
> > function:
> >
> > static int usb_set_device_initiated_lpm(struct usb_device *udev,
> > enum usb3_link_state state, bool enable)
> > {
> ...
> > }
> >
> > So I don't know how the LPM code can know the device is disconnected, and
> > thus
> > it should skip the control transfer. Do we get an -ENODEV in that case?
>
> That doesn't sound right at all. This function is called from
> usb_disable_link_state, which is called from usb_disable_lpm, which is
> called from usb_unlocked_disable_lpm, which is called from
> usb_disable_device, which is called from usb_disconnect.
>
> The first thing usb_disconnect does is change udev->state to
> STATE_NOTATTACHED. Therefore you can test for that in
> usb_set_device_initiated_lpm, and avoid trying to send messages that
In fact it has been tested in usb_set_device_initiated_lpm.
3490 if (udev->state != USB_STATE_CONFIGURED) {
3491 dev_dbg(&udev->dev, "%s: Can't %s %s state "
3492 "for unconfigured device.\n",
3493 __func__, enable ? "enable" :
"disable",
3494 usb3_lpm_names[state]);
3495 return 0;
3496 }
So, may be problem is somewhere else which need to be tracked down.
Regards
Pratyush
> will never be received. Or if you prefer, avoid writing anything to
> the log when the transfer fails with -ENODEV.
>
> 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
--
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
[PATCH] fsl/ehci: fix failure of checking PHY_CLK_VALID during reinitialization
In case of usb phy reinitialization:
e.g. insmod usb-module(usb works well) -> rmmod usb-module -> insmod usb-module
It found the PHY_CLK_VALID bit didn't work if it's not with the power-on reset.
So we just check PHY_CLK_VALID bit during the stage with POR, this can be met
by the tricky of checking FSL_SOC_USB_PRICTRL register.
Signed-off-by: Shengzhou Liu
---
based on master branch of upstream, from sdk1.4
drivers/usb/host/ehci-fsl.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index bd831ec..3156e12 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -270,8 +270,9 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
if (pdata->have_sysif_regs && pdata->controller_ver &&
(phy_mode == FSL_USB2_PHY_ULPI)) {
/* check PHY_CLK_VALID to get phy clk valid */
- if (!spin_event_timeout(in_be32(non_ehci + FSL_SOC_USB_CTRL) &
- PHY_CLK_VALID, FSL_USB_PHY_CLK_TIMEOUT, 0)) {
+ if (!(spin_event_timeout(in_be32(non_ehci + FSL_SOC_USB_CTRL) &
+ PHY_CLK_VALID, FSL_USB_PHY_CLK_TIMEOUT, 0) ||
+ in_be32(non_ehci + FSL_SOC_USB_PRICTRL))) {
printk(KERN_WARNING "fsl-ehci: USB PHY clock
invalid\n");
return -EINVAL;
}
--
1.7.0.4
--
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
