[PATCH 1/1] usb: Check if port status is equal to RxDetect
When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
[1022:7814], the second hotplugging will experience the USB 3.0 pen
drive is recognized as high-speed device. After bisecting the kernel,
I found the commit number 41e7e056cdc662f704fa9262e5c6e213b4ab45dd
(USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
some experiments, the bug can be fixed by avoiding executing the function
hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
XHCI Controlleris [1022:7814] is already in RxDetect
(I tried printing out the port status before setting to Disabled state),
it's reasonable to check the port status before really executing
hub_usb3_port_disable().
Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.)
Signed-off-by: Gavin Guo gavin@canonical.com
---
drivers/usb/core/hub.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 21b99b4..e02ab62 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -889,6 +889,25 @@ static int hub_usb3_port_disable(struct usb_hub *hub, int
port1)
if (!hub_is_superspeed(hub-hdev))
return -EINVAL;
+ ret = hub_port_status(hub, port1, portstatus, portchange);
+ if (ret 0)
+ return ret;
+
+ /*
+* USB controller Advanced Micro Devices,
+* Inc. [AMD] FCH USB XHCI Controller [1022:7814] will have spurious
result
+* making the following usb 3.0 device hotplugging route to the 2.0
root hub
+* and recognized as high-speed device if we set the usb 3.0 port link
state
+* to Disabled. Since it's already in USB_SS_PORT_LS_RX_DETECT state,
we
+* check the state here to avoid the bug.
+*/
+ if ((portstatus USB_PORT_STAT_LINK_STATE) ==
+ USB_SS_PORT_LS_RX_DETECT) {
+ dev_dbg(hub-ports[port1 - 1]-dev,
+The link state is already in
USB_SS_PORT_LS_RX_DETECT\n);
+ return ret;
+ }
+
ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
if (ret)
return ret;
--
2.0.0
--
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/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform
Hi Sarah and Mathias, As the discussion in http://comments.gmane.org/gmane.linux.usb.general/107011, I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk can't work in SuperSpeed after several times of hotplug. After doing some experiments and bisection, I found the bug is caused by 41e7e056cdc662f704fa9262e5c6e213b4ab45dd (USB: Allow USB 3.0 ports to be disabled.). And the bug can be fixed by not executing the hub_usb3_port_disable() function. I also found that the port status is already in RxDetect before setting the port to Disabled in hub_usb3_port_disable() function. So, there are 2 ways to fix the bug: 1) Check if the Vendor/Device id is [1022:7814] at the beginning of hub_usb3_port_disable() function. If yes, return without executing the remaining code. 2) Check if the port status is already in RxDetect, if yes, return without executing the remaining code. The second method seems more reasonable, so the patch is the implementation of the second one. But it will affect more platforms and I don't know if there'll be any negative result. Otherwise, if the first one is correct, I can reimplement a new one. I'm appreciated if you can give me some advice, or if there is any thing I missed. Thanks, Gavin Gavin Guo (1): usb: Check if port status is equal to RxDetect drivers/usb/core/hub.c | 19 +++ 1 file changed, 19 insertions(+) -- 2.0.0 -- 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
I have a proposal for you. -- 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] usb: host: st-hcd: Add USB HCD support for STi SoCs
Hi Alan, Thanks for reviewing. On Thu, 10 Jul 2014, Alan Stern wrote: On Thu, 10 Jul 2014, Peter Griffin wrote: This driver adds support for the USB HCD present in STi SoC's from STMicroelectronics. It has been tested on the stih416-b2020 board. This driver file, along with the Kconfig changes, belongs in the arch/platform-specific source directory. Not in drivers/usb/host/. It is, after all, a platform driver that registers two platform devices. Why do think that? AFAIK certainly for ARM we are trying NOT to add code under the arch/platform directorys and get the code into the relevant subsystems. In order to prove the above if you look in drivers/usb/host/ there are many other similar platform drivers for other SoC families: - bcma-hcd.c ehci-atmel.c ssb-hcd.c ehci-exynos.c ehci-fsl.c ehci-mxc.c ehci-omap.c ehci-orion.c ohci-nxp.c and more, but you get the idea. In short I believe this to be the correct directory :-) +++ b/drivers/usb/host/Kconfig @@ -753,6 +753,23 @@ config USB_HCD_SSB If unsure, say N. +config USB_HCD_ST + tristate STMicroelectronics STi family HCD support Why does this need to be tristate? Why not always build it into the kernel? Or at least make it boolean rather than tristate. Building as a module is useful on these embedded SoCs usually as a mechanism for speeding up boot time. Anything which isn't critical to getting the core functionality of the device going (in this case decoding TV and outputting on HDMI), can be deffered to a later point. Things like USB drivers, can then be loaded in after that point (deffered module loading), to give the appearence of 'instant on' (which in consumer electronics is what everyone wishes to achieve). Going back to my examples above, most of these platforms are also defined as tristate. + depends on ARCH_STI + select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD + select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD + select MFD_SYSCON + select GENERIC_PHY + help + Enable support for the EHCI and OCHI host controller on ST s/OCHI/OHCI/ Good spot, will fix in V2 + consumer electronics SoCs. + + It converts the ST driver into two platform device drivers It converts the ST driver? That doesn't sound right at all. You could eliminate this paragraph completely and nobody would miss it. I agree the wording is a little off there, I can remove or re-phrase it. What it is trying to express is that it is slightly different to some other platform drivers, in that it creates two platform drivers one for the ehci controller and the other for the OHCI controller. From looking at other drivers in this directory this driver is quite similar to USB_HCD_BCMA, which also deemed it noteworthy to mention in the help, although phrased somewhat more succinctly. regards, Peter. -- 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] sierra: Added USB id for Sierra Wirelss MC7304.
Signed-off-by: Søren Holm s...@sgh.dk
Cc: sta...@vger.kernel.org
---
drivers/usb/serial/sierra.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c
index 6f7f01e..c55548a 100644
--- a/drivers/usb/serial/sierra.c
+++ b/drivers/usb/serial/sierra.c
@@ -265,6 +265,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1199, 0x683D) }, /* Sierra Wireless MC8791 Composite */
/* Sierra Wireless MC8790, MC8791, MC8792 */
{ USB_DEVICE(0x1199, 0x683E) },
+ { USB_DEVICE(0x1199, 0x68c0) }, /* Sierra Wireless MC7304 */
{ USB_DEVICE(0x1199, 0x6850) }, /* Sierra Wireless AirCard 880 */
{ USB_DEVICE(0x1199, 0x6851) }, /* Sierra Wireless AirCard 881 */
{ USB_DEVICE(0x1199, 0x6852) }, /* Sierra Wireless AirCard 880 E */
--
1.9.1
--
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 3/3] MAINTAINERS: Add st-hcd to ARCH/STI architecture
On Thu, 10 Jul 2014, Peter Griffin wrote: Signed-off-by: Peter Griffin peter.grif...@linaro.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) Acked-by: Lee Jones lee.jo...@linaro.org diff --git a/MAINTAINERS b/MAINTAINERS index 702ca10..359a64e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1325,6 +1325,7 @@ F: drivers/pinctrl/pinctrl-st.c F: drivers/media/rc/st_rc.c F: drivers/i2c/busses/i2c-st.c F: drivers/tty/serial/st-asc.c +F: drivers/usb/host/st-hcd.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M: Lennert Buytenhek ker...@wantstofly.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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] usb: host: st-hcd: Add USB HCD support for STi SoCs
On Thu, 10 Jul 2014, Peter Griffin wrote:
This driver adds support for the USB HCD present in STi
SoC's from STMicroelectronics. It has been tested on the
stih416-b2020 board.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/usb/host/Kconfig | 17 ++
drivers/usb/host/Makefile | 1 +
drivers/usb/host/st-hcd.c | 471
++
3 files changed, 489 insertions(+)
create mode 100644 drivers/usb/host/st-hcd.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 61b7817..dc0358e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -753,6 +753,23 @@ config USB_HCD_SSB
If unsure, say N.
+config USB_HCD_ST
+ tristate STMicroelectronics STi family HCD support
+ depends on ARCH_STI
+ select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
+ select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
+ select MFD_SYSCON
Are you still using Syscon? If not, this and the header file can be
removed.
+ select GENERIC_PHY
+ help
+ Enable support for the EHCI and OCHI host controller on ST
+ consumer electronics SoCs.
+
+ It converts the ST driver into two platform device drivers
+ for EHCI and OHCI and provides bus configuration, clock and power
+ management for the combined hardware block.
+
+ If unsure, say N.
+
config USB_HCD_TEST_MODE
bool HCD test mode support
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index af89a90..af0b81d 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_USB_HCD_SSB) += ssb-hcd.o
obj-$(CONFIG_USB_FUSBH200_HCD) += fusbh200-hcd.o
obj-$(CONFIG_USB_FOTG210_HCD)+= fotg210-hcd.o
obj-$(CONFIG_USB_MAX3421_HCD)+= max3421-hcd.o
+obj-$(CONFIG_USB_HCD_ST) += st-hcd.o
diff --git a/drivers/usb/host/st-hcd.c b/drivers/usb/host/st-hcd.c
new file mode 100644
index 000..8a9636c
--- /dev/null
+++ b/drivers/usb/host/st-hcd.c
@@ -0,0 +1,471 @@
+/*
+ * STMicroelectronics HCD (Host Controller Driver) for USB 2.0 and 1.1.
+ *
+ * Copyright (c) 2013 STMicroelectronics (RD) Ltd.
+ * Authors: Stephen Gallimore stephen.gallim...@st.com
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/dma-mapping.h
+#include linux/of.h
+#include linux/pm_runtime.h
+#include linux/pm_clock.h
+#include linux/delay.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/module.h
+#include linux/reset.h
+#include linux/regmap.h
Is this used?
+#include linux/phy/phy.h
+#include linux/mfd/syscon.h
Is this used?
+#include linux/usb/ohci_pdriver.h
+#include linux/usb/ehci_pdriver.h
+
+#include ohci.h
+
+#define EHCI_CAPS_SIZE 0x10
+#define AHB2STBUS_INSREG01 (EHCI_CAPS_SIZE + 0x84)
+
+struct st_hcd_dev {
+ int port_nr;
+ struct platform_device *ehci_device;
+ struct platform_device *ohci_device;
+ struct clk *ic_clk; /* Interconnect clock to the controller block */
+ struct clk *ohci_clk; /* 48MHz clock for OHCI */
+ struct reset_control *pwr;
+ struct reset_control *rst;
+ struct phy *phy;
+};
As there are comments, consider using kerneldoc instead.
+static inline void st_ehci_configure_bus(void __iomem *regs)
+{
+ /* Set EHCI packet buffer IN/OUT threshold to 128 bytes */
+ u32 threshold = 128 | (128 16);
+
+ writel(threshold, regs + AHB2STBUS_INSREG01);
+}
+
+static int st_hcd_enable_clocks(struct device *dev,
+ struct st_hcd_dev *hcd_dev)
+{
+ int err;
Separate code (and comments) from declaration.
+ /*
+ * The interconnect input clock have either fixed
s/have either/has either a/
+ * rate or the rate is defined on boot, so we are only concerned about
+ * enabling any gates for this clock.
+ */
+ err = clk_prepare_enable(hcd_dev-ic_clk);
+ if (err) {
+ dev_err(dev, can't enable ic clock\n);
+ return err;
+ }
Nit: '\n'
+ /*
+ * The 48MHz OHCI clock is usually provided by a programmable
+ * frequency synthesizer, which is often not programmed on boot/chip
+ * reset, so we set its rate here to ensure it is correct.
+ *
+ * However not all SoC's have a dedicated ohci clock so it isn't fatal
s/ohci/OHCI
+ * for this not to exist.
--^
+ */
+ if (!IS_ERR(hcd_dev-ohci_clk)) {
This is ugly. If it's not found NULL it, then check for:
if (hcd_dev-ohci_clk) {
Or, even better, do:
if
Re: [PATCH 2/3] usb: host: st-hcd: Add st-hcd devicetree bindings documentation.
On Thu, 10 Jul 2014, Peter Griffin wrote:
This patch documents the device tree documentation required for
the ST HCD controller found in STMicroelectronics SoCs.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
Documentation/devicetree/bindings/usb/st-hcd.txt | 51
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/st-hcd.txt
Just some nits:
+Example:
+
+usb0: usb@fe10 {
+ compatible = st,usb-300x;
+ reg = 0xfe1ffc00 0x100,
+ 0xfe1ffe00 0x100;
+ reg-names = ohci, ehci;
+
+ interrupts = GIC_SPI 148 IRQ_TYPE_NONE,
+GIC_SPI 149 IRQ_TYPE_NONE;
+ interrupt-names = ehci,ohci;
s/,/,
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_usb0;
+ clocks = clk_s_a1_ls CLK_ICN_IF_2,
+ clockgen_b0 0;
+ clock-names = ic, ohci;
+
+ resets = powerdown STIH416_USB0_POWERDOWN,
+ softreset STIH416_USB0_SOFTRESET;
+ reset-names = power, softreset;
+
+ phys = usb2_phy;
+ phy-names = usb2-phy;
Tabbing of the '='s not consistent.
+};
+
+
Too many '\n' at EOF.
Nothing controversial here, so once this nits are rectified:
Acked-by: Lee Jones lee.jo...@linaro.org
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] sierra: Added USB id for Sierra Wirelss MC7304.
oh...
I just noticed that qcserial.c also handles this exact same USB-id.
Will that pose a problem or is this the way things should be?
Fredag den 11. juli 2014 09:53:53 skrev Søren Holm:
Signed-off-by: Søren Holm s...@sgh.dk
Cc: sta...@vger.kernel.org
---
drivers/usb/serial/sierra.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c
index 6f7f01e..c55548a 100644
--- a/drivers/usb/serial/sierra.c
+++ b/drivers/usb/serial/sierra.c
@@ -265,6 +265,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1199, 0x683D) }, /* Sierra Wireless MC8791 Composite */
/* Sierra Wireless MC8790, MC8791, MC8792 */
{ USB_DEVICE(0x1199, 0x683E) },
+ { USB_DEVICE(0x1199, 0x68c0) }, /* Sierra Wireless MC7304 */
{ USB_DEVICE(0x1199, 0x6850) }, /* Sierra Wireless AirCard 880 */
{ USB_DEVICE(0x1199, 0x6851) }, /* Sierra Wireless AirCard 881 */
{ USB_DEVICE(0x1199, 0x6852) }, /* Sierra Wireless AirCard 880 E */
--
Søren Holm
--
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] sierra: Added USB id for Sierra Wirelss MC7304.
Søren Holm s...@sgh.dk writes: oh... I just noticed that qcserial.c also handles this exact same USB-id. Will that pose a problem or is this the way things should be? The device should be handled by only one of the drivers. If it is going to be handled by sierra driver then we should remove the entry from the qcserial driver. My memory is on vacation... Was it so that the qcserial driver fails on these devices? 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
[PATCH net] r8152: fix r8152_csum_workaround function
The transport offset of the IPv4 packet should be fixed and wouldn't be out of the hw limitation, so the r8152_csum_workaround() should be used for IPv6 packets. Signed-off-by: Hayes Wang hayesw...@realtek.com --- drivers/net/usb/r8152.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index a795ecf..7bad2d3 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -1359,7 +1359,7 @@ static void r8152_csum_workaround(struct r8152 *tp, struct sk_buff *skb, struct sk_buff_head seg_list; struct sk_buff *segs, *nskb; - features = ~(NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO); + features = ~(NETIF_F_SG | NETIF_F_IPV6_CSUM | NETIF_F_TSO6); segs = skb_gso_segment(skb, features); if (IS_ERR(segs) || !segs) goto drop; -- 1.9.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
Re: [PATCH] sierra: Added USB id for Sierra Wirelss MC7304.
Fredag den 11. juli 2014 10:47:50 skrev Bjørn Mork: The device should be handled by only one of the drivers. If it is going to be handled by sierra driver then we should remove the entry from the qcserial driver. My memory is on vacation... Was it so that the qcserial driver fails on these devices? I don't know becuse the ID is not in any of them in v3.14 which I run. So my change have to go into v3.14.x to make that kernel pick up the device. But for master it might be the case that qcserial actually works. I can problably check that. Sorry for me not checking up on that prior to submitting my patch. I did not expect another driver to handle a sierra wireless device. -- Søren Holm -- 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] hso: fix deadlock when receiving bursts of data
Hi Alan and Davids, On Thu, Jul 10, 2014 at 04:50:03PM +0100, One Thousand Gnomes wrote: On Thu, 10 Jul 2014 14:37:37 + David Laight david.lai...@aculab.com wrote: From: Olivier Sobrie ... The function put_rxbuf_data() is called from the urb completion handler. It puts the data of the urb transfer in the tty buffer with tty_insert_flip_string_flags() and schedules a work queue in order to push the data to the ldisc. Problem is that we are in a urb completion handler so we can't wait until there is room in the tty buffer. The tty provides the input queue, if the queue is full then just chuck the data in the bitbucket. hso is trying to be far too clever. If hso is fast enough that the buffering isn't sufficient on the tty side then we need to fix the tty buffer size. Ok I'll adapt the patch to drop the data that can't be put in the tty buffer. I test this and resend a new patch. Thanks for your help! -- Olivier -- 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] hso: fix deadlock when receiving bursts of data
From: Olivier Sobrie Olivier Sobrie Hi Alan and Davids, On Thu, Jul 10, 2014 at 04:50:03PM +0100, One Thousand Gnomes wrote: On Thu, 10 Jul 2014 14:37:37 + David Laight david.lai...@aculab.com wrote: From: Olivier Sobrie ... The function put_rxbuf_data() is called from the urb completion handler. It puts the data of the urb transfer in the tty buffer with tty_insert_flip_string_flags() and schedules a work queue in order to push the data to the ldisc. Problem is that we are in a urb completion handler so we can't wait until there is room in the tty buffer. The tty provides the input queue, if the queue is full then just chuck the data in the bitbucket. hso is trying to be far too clever. If hso is fast enough that the buffering isn't sufficient on the tty side then we need to fix the tty buffer size. Ok I'll adapt the patch to drop the data that can't be put in the tty buffer. I test this and resend a new patch. If you are going to drop data, then ideally you want to discard entire ppp packets. Depending on exactly how the interface works it might be that urb are likely to contain complete packets. So discarding entire urb might work better than discarding a few bytes. (But don't even think of scanning the data stream in the usb driver - except for experiments.) David -- 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] sierra: Added USB id for Sierra Wirelss MC7304.
qcserial from master on top of v3.14 works. I applied this patch on 3.14.5 $ git diff v3.14..ba2c0922f74a57d794c10646c3a70ee5a5e14668 -- drivers/usb/serial/qcserial.c In total that sums up to these commits : 0ce5fb5 usb: qcserial: add additional Sierra Wireless QMI devices ff1fcd5 usb: qcserial: add Netgear AirCard 341U 48292d8 usb: qcserial: remove interface number matching 8bc7a06 usb: qcserial: define and use Sierra Wireless layout d712ca9 usb: qcserial: refactor device layout selection ce1b066 usb: qcserial: fix multiline comment coding style 4d7c013 usb: qcserial: add a number of Dell devices bce4f58 usb: qcserial: add Sierra Wireless MC7305/MC7355 70a3615 usb: qcserial: add Sierra Wireless MC73xx a00986f usb: qcserial: add Sierra Wireless EM7355 I guess adding using the qcserial.c changes would be the correct way to go? Fredag den 11. juli 2014 10:47:50 skrev Bjørn Mork: The device should be handled by only one of the drivers. If it is going to be handled by sierra driver then we should remove the entry from the qcserial driver. My memory is on vacation... Was it so that the qcserial driver fails on these devices? -- Søren Holm -- 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] sierra: Added USB id for Sierra Wirelss MC7304.
Søren Holm s...@sgh.dk writes: Fredag den 11. juli 2014 10:47:50 skrev Bjørn Mork: The device should be handled by only one of the drivers. If it is going to be handled by sierra driver then we should remove the entry from the qcserial driver. My memory is on vacation... Was it so that the qcserial driver fails on these devices? I don't know becuse the ID is not in any of them in v3.14 which I run. So my change have to go into v3.14.x to make that kernel pick up the device. But for master it might be the case that qcserial actually works. I can problably check that. Sorry for me not checking up on that prior to submitting my patch. I did not expect another driver to handle a sierra wireless device. The reason behind that is that for the MC77xx generation there was an important difference between the DirectIP mode and QMI mode: The Sierra vendor specific control messages SWIMS_USB_REQUEST_SetPower and SWIMS_USB_REQUEST_SetNmea were only supported in DirectIP mode. This might have changed with the MC73xx generation devices. I've just learned that the AT!SCACT command is supported in QMI mode for these devices (it was not for the MC77xx), and there is a possibility that Sierra has ported more of their earlier DirectIP related vendor specific features as well. And if the MC73xx devices require SWIMS_USB_REQUEST_SetPower then we should move them to the sierra driver. 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] sierra: Added USB id for Sierra Wirelss MC7304.
Søren Holm s...@sgh.dk writes: qcserial from master on top of v3.14 works. Thanks for verifying. You did ensure that you can actually talk to the serial ports? I applied this patch on 3.14.5 $ git diff v3.14..ba2c0922f74a57d794c10646c3a70ee5a5e14668 -- drivers/usb/serial/qcserial.c In total that sums up to these commits : 0ce5fb5 usb: qcserial: add additional Sierra Wireless QMI devices ff1fcd5 usb: qcserial: add Netgear AirCard 341U 48292d8 usb: qcserial: remove interface number matching 8bc7a06 usb: qcserial: define and use Sierra Wireless layout d712ca9 usb: qcserial: refactor device layout selection ce1b066 usb: qcserial: fix multiline comment coding style 4d7c013 usb: qcserial: add a number of Dell devices bce4f58 usb: qcserial: add Sierra Wireless MC7305/MC7355 70a3615 usb: qcserial: add Sierra Wireless MC73xx a00986f usb: qcserial: add Sierra Wireless EM7355 I guess adding using the qcserial.c changes would be the correct way to go? Actually, commit 51b9a752fa1c (usb: qcserial: add Sierra Wireless MC73xx), which is already present in v3.14.5 and newer, should already have added the necessary entries for the 1199:68c0 device if that's what vou've got. Did it fail somehow? 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] sierra: Added USB id for Sierra Wirelss MC7304.
Fredag den 11. juli 2014 11:57:30 skrev Bjørn Mork: Søren Holm s...@sgh.dk writes: qcserial from master on top of v3.14 works. Thanks for verifying. You did ensure that you can actually talk to the serial ports? I beleive so. wvdial where able to connect. Actually, commit 51b9a752fa1c (usb: qcserial: add Sierra Wireless MC73xx), which is already present in v3.14.5 and newer, should already have added the necessary entries for the 1199:68c0 device if that's what vou've got. Did it fail somehow? Yes no ttyUSB was created and lsusb -v said som stuff about UNRECOGNIZED interface or something like that. -- Søren Holm -- 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] sierra: Added USB id for Sierra Wirelss MC7304.
Søren Holm s...@sgh.dk writes: Fredag den 11. juli 2014 11:57:30 skrev Bjørn Mork: Søren Holm s...@sgh.dk writes: qcserial from master on top of v3.14 works. Thanks for verifying. You did ensure that you can actually talk to the serial ports? I beleive so. wvdial where able to connect. Actually, commit 51b9a752fa1c (usb: qcserial: add Sierra Wireless MC73xx), which is already present in v3.14.5 and newer, should already have added the necessary entries for the 1199:68c0 device if that's what vou've got. Did it fail somehow? Yes no ttyUSB was created and lsusb -v said som stuff about UNRECOGNIZED interface or something like that. That's odd. What does lsusb -vd 1199:68c0 look like? And could you run a modinfo qcserial.ko | grep 1199p68 or similar against the original v3.14.5 qcserial driver? I really do not understand how the stable backport version can fail if the mainline patches works. 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 02/10] xhci: 'noxhci_port_switch' kernel parameter
On Sat, May 24, 2014 at 07:13:12AM -0700, Dan Williams wrote: Good Afternoon, Let me see if I can achieve this with a debugfs interface so that 'noxhci_port_switch' does not become a permanent ABI per Greg's concern. I wonder if there is another non-ABI option? Couldn't the ports be unconditionall switched back to EHCI when unloading the xhci module? I know it is just a workaround (but then again I don't have any usb 3.0 devices). :) cheers holger -- 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] sierra: Added USB id for Sierra Wirelss MC7304.
First I notice that I don't even have qcserial on the target ... doh lsusb gives this - so problably getting qcserial on the target will problably solve it. Bus 001 Device 003: ID 1199:68c0 Sierra Wireless, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1199 Sierra Wireless, Inc. idProduct 0x68c0 bcdDevice0.06 iManufacturer 1 Sierra Wireless, Incorporated iProduct2 MC7304 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 220 bNumInterfaces 6 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000c 1x 12 bytes bInterval 9 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000c 1x 12 bytes bInterval 9 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes
Re: [PATCH] sierra: Added USB id for Sierra Wirelss MC7304.
Oh dear it's friday # modinfo qcserial | grep 1199p68 alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in03* alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in02* alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in00* alias: usb:v1199p68A9d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v1199p68A8d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v1199p68A5d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v1199p68A4d*dc*dsc*dp*ic*isc*ip*in* Fredag den 11. juli 2014 12:13:09 skrev Bjørn Mork: Søren Holm s...@sgh.dk writes: Fredag den 11. juli 2014 11:57:30 skrev Bjørn Mork: Søren Holm s...@sgh.dk writes: qcserial from master on top of v3.14 works. Thanks for verifying. You did ensure that you can actually talk to the serial ports? I beleive so. wvdial where able to connect. Actually, commit 51b9a752fa1c (usb: qcserial: add Sierra Wireless MC73xx), which is already present in v3.14.5 and newer, should already have added the necessary entries for the 1199:68c0 device if that's what vou've got. Did it fail somehow? Yes no ttyUSB was created and lsusb -v said som stuff about UNRECOGNIZED interface or something like that. That's odd. What does lsusb -vd 1199:68c0 look like? And could you run a modinfo qcserial.ko | grep 1199p68 or similar against the original v3.14.5 qcserial driver? I really do not understand how the stable backport version can fail if the mainline patches works. Bjørn -- Søren Holm -- 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] sierra: Added USB id for Sierra Wirelss MC7304.
Søren Holm s...@sgh.dk writes: Oh dear it's friday # modinfo qcserial | grep 1199p68 alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in03* alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in02* alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in00* alias: usb:v1199p68A9d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v1199p68A8d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v1199p68A5d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v1199p68A4d*dc*dsc*dp*ic*isc*ip*in* Hmm, is that from a v3.14.5 kernel? I was expecting to see alias: usb:v1199p68C0d*dc*dsc*dp*ic*isc*ip*in03* alias: usb:v1199p68C0d*dc*dsc*dp*ic*isc*ip*in02* alias: usb:v1199p68C0d*dc*dsc*dp*ic*isc*ip*in00* there as well (I deliberately made the grep match more than this to make sure that we would see something). BTW, if you were worrying about the 'UNRECOGNIZED' messages from lsusb then please do not :-) Those messages are expected. The descriptors are interface specific functional descriptors. And lsusb cannot decode such descriptors attached to a Vendor Specific interface, because the interpretation of those descriptors is class specific. I.e. vendor specific. In this case, all of them are actually proper CDC descriptors. But there is just no way lsusb can know that when the vendor claims otherwise. This doesn't matter to the drivers like sierra or qcserial. They will know how to interpret such descriptors, if necessary, for any vendor specific function they support. Here we just ignore them because they don't tell us anything we don't already know (or might even be misleading because the Windows driver doesn't use them either). 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 2/2] hso: fix deadlock when receiving bursts of data
On Fri, Jul 11, 2014 at 09:28:47AM +, David Laight wrote: From: Olivier Sobrie Olivier Sobrie Hi Alan and Davids, On Thu, Jul 10, 2014 at 04:50:03PM +0100, One Thousand Gnomes wrote: On Thu, 10 Jul 2014 14:37:37 + David Laight david.lai...@aculab.com wrote: From: Olivier Sobrie ... The function put_rxbuf_data() is called from the urb completion handler. It puts the data of the urb transfer in the tty buffer with tty_insert_flip_string_flags() and schedules a work queue in order to push the data to the ldisc. Problem is that we are in a urb completion handler so we can't wait until there is room in the tty buffer. The tty provides the input queue, if the queue is full then just chuck the data in the bitbucket. hso is trying to be far too clever. If hso is fast enough that the buffering isn't sufficient on the tty side then we need to fix the tty buffer size. Ok I'll adapt the patch to drop the data that can't be put in the tty buffer. I test this and resend a new patch. If you are going to drop data, then ideally you want to discard entire ppp packets. Depending on exactly how the interface works it might be that urb are likely to contain complete packets. Indeed, urbs contains complete ppp packets. I see that the first and last byte are equal to 0x7e. So discarding entire urb might work better than discarding a few bytes. (But don't even think of scanning the data stream in the usb driver - except for experiments.) I will check with tty_buffer_request_room() that there is enough room to receive the frame before inserting the data in the tty buffer with tty_insert_flip_string(). -- Olivier -- 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 1/2] usb: ci_hdrc_imx: Return -EINVAL for missing USB PHY
-ENODEV is interpreted by the generic driver probing function as a
non-matching driver. This leads to a missing probe failure message.
Also a missing USB PHY is more of an invalid configuration of the usb
driver because it is necessary.
This patch returns -EINVAL if devm_usb_get_phy_by_phandle() returned -ENODEV.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/chipidea/ci_hdrc_imx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 2e58f8dfd311..65444b02bd68 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -133,6 +133,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
data-phy = devm_usb_get_phy_by_phandle(pdev-dev, fsl,usbphy, 0);
if (IS_ERR(data-phy)) {
ret = PTR_ERR(data-phy);
+ /* Return -EINVAL if no usbphy is available */
+ if (ret == -ENODEV)
+ ret = -EINVAL;
goto err_clk;
}
--
2.0.0
--
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 2/2] usb: ci_hdrc_imx doc: fsl,usbphy is required
fsl,usbphy is no optional property. This patch moves it to the list of required properties. Signed-off-by: Markus Pargmann m...@pengutronix.de --- Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt index a6a32cb7f777..1bae71e9ad47 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt @@ -4,6 +4,7 @@ Required properties: - compatible: Should be fsl,imx27-usb - reg: Should contain registers location and length - interrupts: Should contain controller interrupt +- fsl,usbphy: phandle of usb phy that connects to the port Recommended properies: - phy_type: the type of the phy connected to the core. Should be one @@ -12,7 +13,6 @@ Recommended properies: - dr_mode: One of host, peripheral or otg. Defaults to otg Optional properties: -- fsl,usbphy: phandler of usb phy that connects to the only one port - fsl,usbmisc: phandler of non-core register device, with one argument that indicate usb controller index - vbus-supply: regulator for vbus -- 2.0.0 -- 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
Iso trbs for xhci arrangement
hi all: when I trace xhci_queue_isoc_tx, I found ISO TD should look like ISO TRB -- Normal TRB -- Normal TRB But when I dump ep segment during Iso transfer I get below result 1. Why most of them are ISO TRBs? 2. Why there is only 1 normal TRB appreciate your help in advance, ep ring segment: platform-xhci platform-xhci.0: @2796e000 279c 0bf4 80021625 platform-xhci platform-xhci.0: @2796e010 279c0bf4 0bf4 80021625 platform-xhci platform-xhci.0: @2796e020 279c17e8 0bf4 80021625 platform-xhci platform-xhci.0: @2796e030 279c23dc 0bf4 80021625 platform-xhci platform-xhci.0: @2796e040 279c2fd0 0bf4 80021625 platform-xhci platform-xhci.0: @2796e050 279c3bc4 0bf4 80021625 platform-xhci platform-xhci.0: @2796e060 279c47b8 0bf4 80021625 platform-xhci platform-xhci.0: @2796e070 279c53ac 0bf4 80021625 platform-xhci platform-xhci.0: @2796e080 279c5fa0 0bf4 80021625 platform-xhci platform-xhci.0: @2796e090 279c6b94 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0a0 279c7788 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0b0 279c837c 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0c0 279c8f70 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0d0 279c9b64 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0e0 279ca758 0bf4 80021625 platform-xhci platform-xhci.0: @2796e0f0 279cb34c 0bf4 80021625 platform-xhci platform-xhci.0: @2796e100 279cbf40 0bf4 80021625 platform-xhci platform-xhci.0: @2796e110 279ccb34 0bf4 80021625 platform-xhci platform-xhci.0: @2796e120 279cd728 0bf4 80021625 platform-xhci platform-xhci.0: @2796e130 279ce31c 0bf4 80021625 platform-xhci platform-xhci.0: @2796e140 279cef10 0bf4 80021625 //ISO TRB platform-xhci platform-xhci.0: @2796e150 279cfb04 000404fc 80021415 //ISO TRB platform-xhci platform-xhci.0: @2796e160 279d 06f8 0625 //Normal TRB platform-xhci platform-xhci.0: @2796e170 279d06f8 0bf4 80021625 platform-xhci platform-xhci.0: @2796e180 279d12ec 0bf4 80021625 platform-xhci platform-xhci.0: @2796e190 279d1ee0 0bf4 80021625 -- 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 2/2] hso: fix deadlock when receiving bursts of data
When the module sends bursts of data, sometimes a deadlock happens in
the hso driver when the tty buffer doesn't get the chance to be flushed
quickly enough.
Remove the endless while loop in function put_rxbuf_data() which is
called by the urb completion handler.
If there isn't enough room in the tty buffer, discards all the data
received in the URB.
Cc: David Miller da...@davemloft.net
Cc: David Laight david.lai...@aculab.com
Cc: One Thousand Gnomes gno...@lxorguk.ukuu.org.uk
Cc: Dan Williams d...@redhat.com
Cc: Jan Dumon j.du...@option.com
Signed-off-by: Olivier Sobrie oliv...@sobrie.be
---
Changes in v2:
- remove the unthrottle timer added in the previous patch version
- drop entire rx urb data if there is not enough space in tty buffer
- remove variable curr_rx_urb_offset from hso_serial structure
drivers/net/usb/hso.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 9ca2b41..a4272ed 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -258,7 +258,6 @@ struct hso_serial {
* so as not to drop characters on the floor.
*/
int curr_rx_urb_idx;
- u16 curr_rx_urb_offset;
u8 rx_urb_filled[MAX_RX_URBS];
struct tasklet_struct unthrottle_tasklet;
};
@@ -2001,8 +2000,7 @@ static void ctrl_callback(struct urb *urb)
static int put_rxbuf_data(struct urb *urb, struct hso_serial *serial)
{
struct tty_struct *tty;
- int write_length_remaining = 0;
- int curr_write_len;
+ int count;
/* Sanity check */
if (urb == NULL || serial == NULL) {
@@ -2012,29 +2010,28 @@ static int put_rxbuf_data(struct urb *urb, struct
hso_serial *serial)
tty = tty_port_tty_get(serial-port);
+ if (tty test_bit(TTY_THROTTLED, tty-flags)) {
+ tty_kref_put(tty);
+ return -1;
+ }
+
/* Push data to tty */
- write_length_remaining = urb-actual_length -
- serial-curr_rx_urb_offset;
D1(data to push to tty);
- while (write_length_remaining) {
- if (tty test_bit(TTY_THROTTLED, tty-flags)) {
- tty_kref_put(tty);
- return -1;
- }
- curr_write_len = tty_insert_flip_string(serial-port,
- urb-transfer_buffer + serial-curr_rx_urb_offset,
- write_length_remaining);
- serial-curr_rx_urb_offset += curr_write_len;
- write_length_remaining -= curr_write_len;
+ count = tty_buffer_request_room(serial-port, urb-actual_length);
+ if (count = urb-actual_length) {
+ tty_insert_flip_string(serial-port, urb-transfer_buffer,
+ urb-actual_length);
tty_flip_buffer_push(serial-port);
+ } else {
+ dev_warn(serial-parent-usb-dev,
+dropping data, %d bytes lost\n, urb-actual_length);
}
+
tty_kref_put(tty);
- if (write_length_remaining == 0) {
- serial-curr_rx_urb_offset = 0;
- serial-rx_urb_filled[hso_urb_to_index(serial, urb)] = 0;
- }
- return write_length_remaining;
+ serial-rx_urb_filled[hso_urb_to_index(serial, urb)] = 0;
+
+ return 0;
}
@@ -2205,7 +2202,6 @@ static int hso_stop_serial_device(struct hso_device
*hso_dev)
}
}
serial-curr_rx_urb_idx = 0;
- serial-curr_rx_urb_offset = 0;
if (serial-tx_urb)
usb_kill_urb(serial-tx_urb);
--
1.7.9.5
--
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: [PATCHv2] usb: gadget: composite: Provide a list of available functions
On 07/10/2014 04:17 PM, Krzysztof Opasiak wrote: another class ? Please don't, we already have the udc class, we could find a way to just use that instead. Using udc clas is not a good idea. This may cause failures in userspace. failures? like what? How would you like to tell that this is not really a udc? Only type of Adding a new class for one file does not look right. Try to add a file if you have to but without creating a new class for it. It looks like it would fit best in the configfs root directory. However, I am not sure this is required at all. I would rather prefer having a userland tool (like target has) which helps you assembling a gadget instead of having users poking at files and then eh look! lets see what this can do…. Sebastian -- 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 0/2] ARM: shmobile: lager: USBHS callback elimination
[Cc Felipe Balbi] On Thu, Jul 10, 2014 at 01:20:34AM -0700, Kuninori Morimoto wrote: Hi Changes in v2: - move phy handle to struct usbhs_priv - add new default pipe type to driver - remove pipe type from Lager board code Ulrich Hecht (2): usb: renesas_usbhs: add R-Car Gen. 2 init and power control ARM: shmobile: lager: remove USBHS callbacks arch/arm/mach-shmobile/board-lager.c | 126 --- drivers/usb/renesas_usbhs/Makefile | 2 +- drivers/usb/renesas_usbhs/common.c | 66 -- drivers/usb/renesas_usbhs/common.h | 2 + drivers/usb/renesas_usbhs/rcar2.c| 76 + drivers/usb/renesas_usbhs/rcar2.h| 4 ++ include/linux/usb/renesas_usbhs.h| 6 ++ 7 files changed, 163 insertions(+), 119 deletions(-) create mode 100644 drivers/usb/renesas_usbhs/rcar2.c create mode 100644 drivers/usb/renesas_usbhs/rcar2.h For all patches Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com [snip] I tested these patches on Lager legacy, and these patches worked correctly. Tested-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Hi, it seems that the 2nd patch should go through my renesas tree but it depends on the first patch which should be taken by Felipe Balbi (Cced). Felipe, is there any chance that you could take this for v3.16? I am quite happy to make a branch for you to pull for renesas_usbhs if this would make your life easier. -- 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 0/2] ARM: shmobile: lager: USBHS callback elimination
On Fri, Jul 11, 2014 at 11:00:07AM +0200, Simon Horman wrote: [Cc Felipe Balbi] On Thu, Jul 10, 2014 at 01:20:34AM -0700, Kuninori Morimoto wrote: Hi Changes in v2: - move phy handle to struct usbhs_priv - add new default pipe type to driver - remove pipe type from Lager board code Ulrich Hecht (2): usb: renesas_usbhs: add R-Car Gen. 2 init and power control ARM: shmobile: lager: remove USBHS callbacks arch/arm/mach-shmobile/board-lager.c | 126 --- drivers/usb/renesas_usbhs/Makefile | 2 +- drivers/usb/renesas_usbhs/common.c | 66 -- drivers/usb/renesas_usbhs/common.h | 2 + drivers/usb/renesas_usbhs/rcar2.c| 76 + drivers/usb/renesas_usbhs/rcar2.h| 4 ++ include/linux/usb/renesas_usbhs.h| 6 ++ 7 files changed, 163 insertions(+), 119 deletions(-) create mode 100644 drivers/usb/renesas_usbhs/rcar2.c create mode 100644 drivers/usb/renesas_usbhs/rcar2.h For all patches Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com [snip] I tested these patches on Lager legacy, and these patches worked correctly. Tested-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Hi, it seems that the 2nd patch should go through my renesas tree but it depends on the first patch which should be taken by Felipe Balbi (Cced). Felipe, is there any chance that you could take this for v3.16? I am quite happy to make a branch for you to pull for renesas_usbhs if this would make your life easier. you need to take both patches or just patch 1 ? -- balbi signature.asc Description: Digital signature
Re: Kernel 3.15.2-1.gfb7c781 + USB3 (xhci_hcd) card throws CALL TRACE, completes boot
fix confirmed uname -rm 3.15.5-1.g01d2774-desktop x86_64 journalctl -b | grep kernel | egrep -i xhci|trace Jul 11 08:09:16 localhost kernel: ftrace: allocating 24222 entries in 95 pages Jul 11 08:09:17 localhost kernel: xhci_hcd :02:00.0: xHCI Host Controller Jul 11 08:09:17 localhost kernel: xhci_hcd :02:00.0: new USB bus registered, assigned bus number 3 Jul 11 08:09:17 localhost kernel: xhci_hcd :02:00.0: irq 46 for MSI/MSI-X Jul 11 08:09:17 localhost kernel: usb usb3: Product: xHCI Host Controller Jul 11 08:09:17 localhost kernel: usb usb3: Manufacturer: Linux 3.15.5-1.g01d2774-desktop xhci_hcd Jul 11 08:09:17 localhost kernel: xhci_hcd :02:00.0: xHCI Host Controller Jul 11 08:09:17 localhost kernel: xhci_hcd :02:00.0: new USB bus registered, assigned bus number 4 Jul 11 08:09:17 localhost kernel: usb usb4: Product: xHCI Host Controller Jul 11 08:09:17 localhost kernel: usb usb4: Manufacturer: Linux 3.15.5-1.g01d2774-desktop xhci_hcd Jul 11 08:09:18 localhost kernel: usb 3-1: new high-speed USB device number 2 using xhci_hcd Jul 11 08:09:18 localhost kernel: usb 3-1.3: new high-speed USB device number 3 using xhci_hcd Jul 11 08:09:18 localhost kernel: usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd thanks! -- 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 0/2] ARM: shmobile: lager: USBHS callback elimination
On Fri, Jul 11, 2014 at 10:12:37AM -0500, Felipe Balbi wrote: On Fri, Jul 11, 2014 at 11:00:07AM +0200, Simon Horman wrote: [Cc Felipe Balbi] On Thu, Jul 10, 2014 at 01:20:34AM -0700, Kuninori Morimoto wrote: Hi Changes in v2: - move phy handle to struct usbhs_priv - add new default pipe type to driver - remove pipe type from Lager board code Ulrich Hecht (2): usb: renesas_usbhs: add R-Car Gen. 2 init and power control ARM: shmobile: lager: remove USBHS callbacks arch/arm/mach-shmobile/board-lager.c | 126 --- drivers/usb/renesas_usbhs/Makefile | 2 +- drivers/usb/renesas_usbhs/common.c | 66 -- drivers/usb/renesas_usbhs/common.h | 2 + drivers/usb/renesas_usbhs/rcar2.c| 76 + drivers/usb/renesas_usbhs/rcar2.h| 4 ++ include/linux/usb/renesas_usbhs.h| 6 ++ 7 files changed, 163 insertions(+), 119 deletions(-) create mode 100644 drivers/usb/renesas_usbhs/rcar2.c create mode 100644 drivers/usb/renesas_usbhs/rcar2.h For all patches Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com [snip] I tested these patches on Lager legacy, and these patches worked correctly. Tested-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Hi, it seems that the 2nd patch should go through my renesas tree but it depends on the first patch which should be taken by Felipe Balbi (Cced). Felipe, is there any chance that you could take this for v3.16? I am quite happy to make a branch for you to pull for renesas_usbhs if this would make your life easier. you need to take both patches or just patch 1 ? Please just take patch 1. Thanks -- 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 0/2] ARM: shmobile: lager: USBHS callback elimination
On Fri, Jul 11, 2014 at 05:41:52PM +0200, Simon Horman wrote: On Fri, Jul 11, 2014 at 10:12:37AM -0500, Felipe Balbi wrote: On Fri, Jul 11, 2014 at 11:00:07AM +0200, Simon Horman wrote: [Cc Felipe Balbi] On Thu, Jul 10, 2014 at 01:20:34AM -0700, Kuninori Morimoto wrote: Hi Changes in v2: - move phy handle to struct usbhs_priv - add new default pipe type to driver - remove pipe type from Lager board code Ulrich Hecht (2): usb: renesas_usbhs: add R-Car Gen. 2 init and power control ARM: shmobile: lager: remove USBHS callbacks arch/arm/mach-shmobile/board-lager.c | 126 --- drivers/usb/renesas_usbhs/Makefile | 2 +- drivers/usb/renesas_usbhs/common.c | 66 -- drivers/usb/renesas_usbhs/common.h | 2 + drivers/usb/renesas_usbhs/rcar2.c| 76 + drivers/usb/renesas_usbhs/rcar2.h| 4 ++ include/linux/usb/renesas_usbhs.h| 6 ++ 7 files changed, 163 insertions(+), 119 deletions(-) create mode 100644 drivers/usb/renesas_usbhs/rcar2.c create mode 100644 drivers/usb/renesas_usbhs/rcar2.h For all patches Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com [snip] I tested these patches on Lager legacy, and these patches worked correctly. Tested-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Hi, it seems that the 2nd patch should go through my renesas tree but it depends on the first patch which should be taken by Felipe Balbi (Cced). Felipe, is there any chance that you could take this for v3.16? I am quite happy to make a branch for you to pull for renesas_usbhs if this would make your life easier. you need to take both patches or just patch 1 ? Please just take patch 1. will do. -- balbi signature.asc Description: Digital signature
Re: [PATCH] sierra: Added USB id for Sierra Wirelss MC7304.
Ok, then maybe it's not 3.14.5 It's a little bit unclean since the kernel is from this repo : git://git.yoctoproject.org/linux-yocto-3.14.git commit 144595ef6215a0febfb8ee7d0c9e4eb2eaf93d61 Fact is that master supports the MC73xx, and I seem to be running a kernel that does not. Does it make any difference whether I chose patching sierra.c og qcserial.c ? Fredag den 11. juli 2014 14:03:41 skrev Bjørn Mork: Hmm, is that from a v3.14.5 kernel? I was expecting to see alias: usb:v1199p68C0d*dc*dsc*dp*ic*isc*ip*in03* alias: usb:v1199p68C0d*dc*dsc*dp*ic*isc*ip*in02* alias: usb:v1199p68C0d*dc*dsc*dp*ic*isc*ip*in00* there as well (I deliberately made the grep match more than this to make sure that we would see something). BTW, if you were worrying about the 'UNRECOGNIZED' messages from lsusb then please do not :-) Those messages are expected. The descriptors are interface specific functional descriptors. And lsusb cannot decode such descriptors attached to a Vendor Specific interface, because the interpretation of those descriptors is class specific. I.e. vendor specific. In this case, all of them are actually proper CDC descriptors. But there is just no way lsusb can know that when the vendor claims otherwise. This doesn't matter to the drivers like sierra or qcserial. They will know how to interpret such descriptors, if necessary, for any vendor specific function they support. Here we just ignore them because they don't tell us anything we don't already know (or might even be misleading because the Windows driver doesn't use them either). -- Søren Holm -- 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 2/2] hso: fix deadlock when receiving bursts of data
When posting new versions of patches, you must resubmit the entire series, not just the patch which is changing. Thank you. -- 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] usb: host: st-hcd: Add USB HCD support for STi SoCs
On Fri, 11 Jul 2014, Peter Griffin wrote: Hi Alan, Thanks for reviewing. On Thu, 10 Jul 2014, Alan Stern wrote: On Thu, 10 Jul 2014, Peter Griffin wrote: This driver adds support for the USB HCD present in STi SoC's from STMicroelectronics. It has been tested on the stih416-b2020 board. This driver file, along with the Kconfig changes, belongs in the arch/platform-specific source directory. Not in drivers/usb/host/. It is, after all, a platform driver that registers two platform devices. Why do think that? Because it is true. One can easily see that st-hcd.c is a platform driver: It contains a module_platform_driver() line and a struct platform_driver definition near the end. And it registers a platform device by calling platform_device_add() in st_hcd_device_create(), which is called twice by st_hcd_probe(). AFAIK certainly for ARM we are trying NOT to add code under the arch/platform directorys and get the code into the relevant subsystems. This does not agree with my experiences. In order to prove the above if you look in drivers/usb/host/ there are many other similar platform drivers for other SoC families: - bcma-hcd.c ehci-atmel.c ssb-hcd.c ehci-exynos.c ehci-fsl.c ehci-mxc.c ehci-omap.c ehci-orion.c ohci-nxp.c and more, but you get the idea. In short I believe this to be the correct directory :-) No. bcma-hcd.c and ssb-hcd.c are similar to your st-hcd.c, but the others aren't. Take ehci-atmel.c as a typical example. It does not define any ehci_pdata structure and does not call platform_device_add(); instead it calls usb_add_hcd(). The others work the same way. I would suggest that bcma-hcd.c and ssb-hcd.c don't belong in drivers/usb/host either. For examples of drivers that _do_ resemble st-hcd.c, look in: arch/arm/mach-cns3xxx/cns3420vb.c arch/arm/mach-cns3xxx/core.c arch/arm/mach-shmobile/setup-r8a7778.c arch/arm/mach-shmobile/setup-r8a7779.c arch/arm/mach-omap2/board-cm-t3517.c arch/mips/netlogic/xlr/platform.c arch/mips/ath79/dev-usb.c arch/mips/loongson1/common/platform.c arch/mips/alchemy/common/platform.c These files all define ehci_pdata structures and register platform devices. And they obviously are all located in arch/platform-specific directories. +++ b/drivers/usb/host/Kconfig @@ -753,6 +753,23 @@ config USB_HCD_SSB If unsure, say N. +config USB_HCD_ST + tristate STMicroelectronics STi family HCD support Why does this need to be tristate? Why not always build it into the kernel? Or at least make it boolean rather than tristate. Building as a module is useful on these embedded SoCs usually as a mechanism for speeding up boot time. Anything which isn't critical to getting the core functionality of the device going (in this case decoding TV and outputting on HDMI), can be deffered to a later point. Things like USB drivers, can then be loaded in after that point (deffered module loading), to give the appearence of 'instant on' (which in consumer electronics is what everyone wishes to achieve). But st-hcd.c takes very little time to run. ehci-platform will cause a delay, so it makes sense for ehci-platform to be a module. But there's no reason for st-hcd to be a module. Going back to my examples above, most of these platforms are also defined as tristate. Probably for historical reasons. They don't need to be tristate now. + consumer electronics SoCs. + + It converts the ST driver into two platform device drivers It converts the ST driver? That doesn't sound right at all. You could eliminate this paragraph completely and nobody would miss it. I agree the wording is a little off there, I can remove or re-phrase it. What it is trying to express is that it is slightly different to some other platform drivers, in that it creates two platform drivers one It creates two platform _devices_, not two platform _drivers_. for the ehci controller and the other for the OHCI controller. In that respect it is very similar to the drivers I listed above. From looking at other drivers in this directory this driver is quite similar to USB_HCD_BCMA, which also deemed it noteworthy to mention in the help, although phrased somewhat more succinctly. People reading the Kconfig help text don't care what other drivers are similar to yours. All they want to know is whether or not they should enable your driver. 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 net] r8152: fix r8152_csum_workaround function
From: Hayes Wang hayesw...@realtek.com Date: Fri, 11 Jul 2014 16:48:27 +0800 The transport offset of the IPv4 packet should be fixed and wouldn't be out of the hw limitation, so the r8152_csum_workaround() should be used for IPv6 packets. Signed-off-by: Hayes Wang hayesw...@realtek.com Applied and queued up for -stable, but this patch was harder to review than it needed to be... - features = ~(NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO); + features = ~(NETIF_F_SG | NETIF_F_IPV6_CSUM | NETIF_F_TSO6); because you changed the order of the flags unnecessarily. -- 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: Bluetooth device AR3012 [0cf3:e005] sometimes can't work on XHCI host controller
Hi all, On Mon, Jun 30, 2014 at 10:38 AM, Gavin Guo gavin@canonical.com wrote: Hi all, Recently, I found that the AR3012 bluetooth sometimes can't work with the 00:14.0 USB controller [0c03]: Intel Corporation Lynx Point USB xHCI Host Controller [8086:8c31] (rev 05). The dmesg is attached, and following is how I tested: The port which AR3012 uses on the platform is default routed to XHCI controller. So, when booting up the machine, I found those messages in dmesg: [ 18.128566] Bluetooth: Error in firmware loading err = -110,len = 448, size = 4096 [ 18.128574] Bluetooth: Loading patch file failed [ 18.128583] ath3k: probe of 3-6:1.0 failed with error -110 Obviously, there is firmware loading error with the XHCI host controller, and there are also XHCI debugging messages showing before these ones. Because we found that the AR3012 works fine with EHCI host controller, so we wrote a module, xhci_quirk, to change the port to bind to EHCI host controller, which changes the USB_INTEL_XUSB2PR register. After insmoding the xhci_quirk module, we see the following lines: [ 199.248468] xhci_quirk: module verification failed: signature and/or required key missing - tainting kernel [ 199.255687] old = 0x3fff, new = 0x3cdf [ 199.255689] Planted return probe at usb_enable_intel_xhci_ports: 815950c0 After that the port disconnected from the XHCI host controller, and then the AR3012 is attached to the EHCI host controller: [ 199.936571] usb 1-1.2: new full-speed USB device number 4 using ehci-pci [ 215.026596] usb 1-1.2: device descriptor read/64, error -110 [ 230.220811] usb 1-1.2: device descriptor read/64, error -110 [ 230.396975] usb 1-1.2: new full-speed USB device number 5 using ehci-pci [ 235.495101] usb 1-1.2: unable to read config index 0 descriptor/all [ 235.495105] usb 1-1.2: can't read configurations, error -110 [ 235.571216] usb 1-1.2: new full-speed USB device number 6 using ehci-pci [ 235.592617] usb 1-1.2: New USB device found, idVendor=0cf3, idProduct=e005 [ 235.592621] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 235.705440] usb 1-1.2: USB disconnect, device number 6 [ 235.903613] usb 1-1.2: new full-speed USB device number 7 using ehci-pci [ 241.002841] usb 1-1.2: New USB device found, idVendor=0cf3, idProduct=e005 [ 241.002844] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 After a while, the Bluetooth icon shows up in the right-upper corner (Ubuntu 12.04). I can use normal Bluetooth operations such as file transfer, headset, and mouse. Next, I did an experiment to remove the xhci_quirk module and the port will be routed to the XHCI host controller again. And something strange happened, I found that the Bluetooth device AR3012 _WORKS_ on XHCI host controller. Summary: * The ath3k.c firwmare loading error doesn't always happen on the XHCI host controller, it succeed sometimes. After the successful loading firmware, AR3012 works fine. * After sucessful loading the firmware through the EHCI controller, I found that the firmware status still remained and can work with XHCI host controller through dynamic changing the port routing. If there is any restriction that Bluetooth device AR3012 can't work on XHCI host controller? Thanks, Gavin Guo Add Mathias and Dan to the list, Mathias is now the XHCI driver maintainer. -- 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 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform
Hi all, On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote: Hi Sarah and Mathias, As the discussion in http://comments.gmane.org/gmane.linux.usb.general/107011, I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk can't work in SuperSpeed after several times of hotplug. After doing some experiments and bisection, I found the bug is caused by 41e7e056cdc662f704fa9262e5c6e213b4ab45dd (USB: Allow USB 3.0 ports to be disabled.). And the bug can be fixed by not executing the hub_usb3_port_disable() function. I also found that the port status is already in RxDetect before setting the port to Disabled in hub_usb3_port_disable() function. So, there are 2 ways to fix the bug: 1) Check if the Vendor/Device id is [1022:7814] at the beginning of hub_usb3_port_disable() function. If yes, return without executing the remaining code. 2) Check if the port status is already in RxDetect, if yes, return without executing the remaining code. The second method seems more reasonable, so the patch is the implementation of the second one. But it will affect more platforms and I don't know if there'll be any negative result. Otherwise, if the first one is correct, I can reimplement a new one. I'm appreciated if you can give me some advice, or if there is any thing I missed. Thanks, Gavin Gavin Guo (1): usb: Check if port status is equal to RxDetect drivers/usb/core/hub.c | 19 +++ 1 file changed, 19 insertions(+) -- 2.0.0 Add Greg k-h to the list. -- 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/1] usb: Check if port status is equal to RxDetect
Hi all,
On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote:
When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
[1022:7814], the second hotplugging will experience the USB 3.0 pen
drive is recognized as high-speed device. After bisecting the kernel,
I found the commit number 41e7e056cdc662f704fa9262e5c6e213b4ab45dd
(USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
some experiments, the bug can be fixed by avoiding executing the function
hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
XHCI Controlleris [1022:7814] is already in RxDetect
(I tried printing out the port status before setting to Disabled state),
it's reasonable to check the port status before really executing
hub_usb3_port_disable().
Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.)
Signed-off-by: Gavin Guo gavin@canonical.com
---
drivers/usb/core/hub.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 21b99b4..e02ab62 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -889,6 +889,25 @@ static int hub_usb3_port_disable(struct usb_hub *hub,
int port1)
if (!hub_is_superspeed(hub-hdev))
return -EINVAL;
+ ret = hub_port_status(hub, port1, portstatus, portchange);
+ if (ret 0)
+ return ret;
+
+ /*
+* USB controller Advanced Micro Devices,
+* Inc. [AMD] FCH USB XHCI Controller [1022:7814] will have spurious
result
+* making the following usb 3.0 device hotplugging route to the 2.0
root hub
+* and recognized as high-speed device if we set the usb 3.0 port
link state
+* to Disabled. Since it's already in USB_SS_PORT_LS_RX_DETECT
state, we
+* check the state here to avoid the bug.
+*/
+ if ((portstatus USB_PORT_STAT_LINK_STATE) ==
+ USB_SS_PORT_LS_RX_DETECT) {
+ dev_dbg(hub-ports[port1 - 1]-dev,
+The link state is already in
USB_SS_PORT_LS_RX_DETECT\n);
+ return ret;
+ }
+
ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
if (ret)
return ret;
--
2.0.0
Add Greg k-h to the list.
--
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: Iso trbs for xhci arrangement
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of vichy
hi all:
when I trace xhci_queue_isoc_tx, I found ISO TD should look like
ISO TRB -- Normal TRB -- Normal TRB
But when I dump ep segment during Iso transfer I get below result
1. Why most of them are ISO TRBs?
2. Why there is only 1 normal TRB
appreciate your help in advance,
Please read section 3.2.11 in the xHCI spec, which is freely available on
the web.
--
Paul
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [PATCH 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform
On Sat, Jul 12, 2014 at 07:32:34AM +0800, Gavin Guo wrote: Hi all, On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote: Hi Sarah and Mathias, As the discussion in http://comments.gmane.org/gmane.linux.usb.general/107011, I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk can't work in SuperSpeed after several times of hotplug. After doing some experiments and bisection, I found the bug is caused by 41e7e056cdc662f704fa9262e5c6e213b4ab45dd (USB: Allow USB 3.0 ports to be disabled.). And the bug can be fixed by not executing the hub_usb3_port_disable() function. I also found that the port status is already in RxDetect before setting the port to Disabled in hub_usb3_port_disable() function. So, there are 2 ways to fix the bug: 1) Check if the Vendor/Device id is [1022:7814] at the beginning of hub_usb3_port_disable() function. If yes, return without executing the remaining code. 2) Check if the port status is already in RxDetect, if yes, return without executing the remaining code. The second method seems more reasonable, so the patch is the implementation of the second one. But it will affect more platforms and I don't know if there'll be any negative result. Otherwise, if the first one is correct, I can reimplement a new one. I'm appreciated if you can give me some advice, or if there is any thing I missed. Thanks, Gavin Gavin Guo (1): usb: Check if port status is equal to RxDetect drivers/usb/core/hub.c | 19 +++ 1 file changed, 19 insertions(+) -- 2.0.0 Add Greg k-h to the list. Why? Mathias can handle this just fine, right? And I read all linux-usb@vger email anyway... 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 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform
Hi Greg, On Sat, Jul 12, 2014 at 8:04 AM, Greg KH gre...@linuxfoundation.org wrote: On Sat, Jul 12, 2014 at 07:32:34AM +0800, Gavin Guo wrote: Hi all, On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote: Hi Sarah and Mathias, As the discussion in http://comments.gmane.org/gmane.linux.usb.general/107011, I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk can't work in SuperSpeed after several times of hotplug. After doing some experiments and bisection, I found the bug is caused by 41e7e056cdc662f704fa9262e5c6e213b4ab45dd (USB: Allow USB 3.0 ports to be disabled.). And the bug can be fixed by not executing the hub_usb3_port_disable() function. I also found that the port status is already in RxDetect before setting the port to Disabled in hub_usb3_port_disable() function. So, there are 2 ways to fix the bug: 1) Check if the Vendor/Device id is [1022:7814] at the beginning of hub_usb3_port_disable() function. If yes, return without executing the remaining code. 2) Check if the port status is already in RxDetect, if yes, return without executing the remaining code. The second method seems more reasonable, so the patch is the implementation of the second one. But it will affect more platforms and I don't know if there'll be any negative result. Otherwise, if the first one is correct, I can reimplement a new one. I'm appreciated if you can give me some advice, or if there is any thing I missed. Thanks, Gavin Gavin Guo (1): usb: Check if port status is equal to RxDetect drivers/usb/core/hub.c | 19 +++ 1 file changed, 19 insertions(+) -- 2.0.0 Add Greg k-h to the list. Why? Mathias can handle this just fine, right? And I read all linux-usb@vger email anyway... greg k-h I'm sorry if there is any misunderstanding. Because the code is under drivers/usb/core/hub.c, I found that in MAINTAINERS you are the maintainer of drivers/usb/*. so I think it's better to let you know the change. Thanks, Gavin Guo -- 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
