Re: [PATCH] usb: dwc3: core: continue probe even if usb3 phy is not available
Hi, On Fri, Jun 28, 2013 at 10:06:01PM +0200, Michael Grzeschik wrote: right, but in DT you will define both instances and each instance will have a seaparate snps,maximum_speed attribute :-) I'm now considering if we should make maximum_speed a generic attribute, Kishon ? Alex ? Alan ? anyone else needs such thing ? We have a force-full-speed attibute for chipidea on the way. This maximum_speed looks like a more generic alternative. Michael, what say you? The maximum_speed attribute sounds more reasonable. I will change my patch to it. thanks, perhaps we can add a generic helper in udc-core or usb-common ? As this function is not only udc specific, this should go into usb-common. But right, we should go with a helper here. I will write one in addition to my full-speed patch as first user of it. alright, thanks :-) Michael, if you need any help with patching in maximum_speed attribute, let me know as I have some time to work on that part. Feel free to begin with anything. I am currently short on time. Do you need some pointers? not, really v1 will come on monday. -- balbi signature.asc Description: Digital signature
[PATCH] USB: OHCI: make ohci-nxp a separate driver
Separate the OHCI NXP host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Many place function name and struct name started with usb,
current scenario replaced usb with ohci for proper naming.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/Kconfig|8 +++
drivers/usb/host/Makefile |1 +
drivers/usb/host/ohci-hcd.c | 15 --
drivers/usb/host/ohci-nxp.c | 124 +--
4 files changed, 58 insertions(+), 90 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f19524f..002bf73 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -398,6 +398,14 @@ config USB_OHCI_HCD_S3C
Enables support for the on-chip OHCI controller on
S3C chips.
+config USB_OHCI_HCD_LPC32XX
+ tristate Support for LPC on-chip OHCI USB controller
+ depends on USB_OHCI_HCD ARCH_LPC32XX
+ default y
+ ---help---
+ Enables support for the on-chip OHCI controller on
+ NXP chips.
+
config USB_OHCI_HCD_AT91
tristate Support for Atmel on-chip OHCI USB controller
depends on USB_OHCI_HCD ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 9dffe81..edc0909 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o
obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o
obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o
obj-$(CONFIG_USB_OHCI_HCD_S3C) += ohci-s3c2410.o
+obj-$(CONFIG_USB_OHCI_HCD_LPC32XX) += ohci-nxp.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index f3dcaa2..9a0b023 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1194,11 +1194,6 @@ MODULE_LICENSE (GPL);
#define EP93XX_PLATFORM_DRIVER ohci_hcd_ep93xx_driver
#endif
-#ifdef CONFIG_ARCH_LPC32XX
-#include ohci-nxp.c
-#define NXP_PLATFORM_DRIVERusb_hcd_nxp_driver
-#endif
-
#ifdef CONFIG_ARCH_DAVINCI_DA8XX
#include ohci-da8xx.c
#define DAVINCI_PLATFORM_DRIVERohci_hcd_da8xx_driver
@@ -1301,12 +1296,6 @@ static int __init ohci_hcd_mod_init(void)
goto error_ep93xx;
#endif
-#ifdef NXP_PLATFORM_DRIVER
- retval = platform_driver_register(NXP_PLATFORM_DRIVER);
- if (retval 0)
- goto error_nxp;
-#endif
-
#ifdef DAVINCI_PLATFORM_DRIVER
retval = platform_driver_register(DAVINCI_PLATFORM_DRIVER);
if (retval 0)
@@ -1320,10 +1309,6 @@ static int __init ohci_hcd_mod_init(void)
platform_driver_unregister(DAVINCI_PLATFORM_DRIVER);
error_davinci:
#endif
-#ifdef NXP_PLATFORM_DRIVER
- platform_driver_unregister(NXP_PLATFORM_DRIVER);
- error_nxp:
-#endif
#ifdef EP93XX_PLATFORM_DRIVER
platform_driver_unregister(EP93XX_PLATFORM_DRIVER);
error_ep93xx:
diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index 7d7d507..8d6eecf 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -19,10 +19,19 @@
* or implied.
*/
#include linux/clk.h
-#include linux/platform_device.h
+#include linux/dma-mapping.h
+#include linux/io.h
#include linux/i2c.h
+#include linux/kernel.h
+#include linux/module.h
#include linux/of.h
+#include linux/platform_device.h
#include linux/usb/isp1301.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ohci.h
+
#include mach/hardware.h
#include asm/mach-types.h
@@ -57,6 +66,11 @@
#define start_int_umask(irq)
#endif
+#define DRIVER_DESC OHCI NXP driver
+
+static const char hcd_name[] = ohci-nxp;
+static struct hc_driver __read_mostly ohci_nxp_hc_driver;
+
static struct i2c_client *isp1301_i2c_client;
extern int usb_disabled(void);
@@ -132,14 +146,14 @@ static inline void isp1301_vbus_off(void)
OTG1_VBUS_DRV);
}
-static void nxp_start_hc(void)
+static void ohci_nxp_start_hc(void)
{
unsigned long tmp = __raw_readl(USB_OTG_STAT_CONTROL) | HOST_EN;
__raw_writel(tmp, USB_OTG_STAT_CONTROL);
isp1301_vbus_on();
}
-static void nxp_stop_hc(void)
+static void ohci_nxp_stop_hc(void)
{
unsigned long tmp;
isp1301_vbus_off();
@@ -147,68 +161,9 @@ static void nxp_stop_hc(void)
__raw_writel(tmp, USB_OTG_STAT_CONTROL);
}
-static int ohci_nxp_start(struct usb_hcd *hcd)
-{
- struct ohci_hcd *ohci = hcd_to_ohci(hcd);
- int ret;
-
- if ((ret = ohci_init(ohci)) 0)
- return ret;
-
- if ((ret = ohci_run(ohci)) 0) {
- dev_err(hcd-self.controller, can't start\n);
-
Re: [PATCH v3 3/4] USB: EHCI: improve interrupt qh unlink
On Sun, Jun 30, 2013 at 2:35 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 29 Jun 2013, Ming Lei wrote: The ehci_endpoint_disable() routine can be improved. In the QH_STATE_LINNKED or QH_STATE_COMPLETING case, we now need to handle interrupt QHs -- the comment about periodic qh self-unlinks on empty isn't entirely correct any more, because now the unlink doesn't occur until the QH has been empty for 5 ms. Actually, almost all interrupt URBs are resubmitted in its completion handler, that means they are basically stopped by unlinking before disabling endpoint, so I am wondering if we need to consider improving ehci_endpoint_disable() on interrupt endpoint. Come to think of it, we never should see an endpoint being disabled while there are active URBs. It might be a better idea to put a Right. WARN_ON there and simply return, without unlinking anything. If this ever triggers, it means there's a bug in usbcore. But that isn't always true, see below case: - the last URB in the endpoint completes without resubmitting in its completion handler - then the corresponding qh is kept in linked state, but wait for being unlinked - usb_disable_endpoint() is called before the qh is put into unlinked state, and no URBs are unlinked in usb_hcd_flush_endpoint() - ehci_endpoint_disable() still see qh in QH_STATE_LINKED state. So I think we should unlink here to speed up the procedure as suggested in your previous email. But I suggest to do the above on in another patch because most of the change is not much related with this patch. Okay. @@ -921,7 +966,7 @@ static void scan_intr(struct ehci_hcd *ehci) temp = qh_completions(ehci, qh); if (unlikely(temp || (list_empty(qh-qtd_list) qh-qh_state == QH_STATE_LINKED))) - start_unlink_intr(ehci, qh); + start_unlink_intr_wait(ehci, qh); This is not quite right. If temp is nonzero then we want to unlink the QH right away (because a fault occurred), so we should call It might depend on the fault type, looks we need to unlink qh immediately on SHUTDOWN and qh-dequeue_during_giveback, and Yes. for other non-unlink faults, drivers may not treat it as fault and continue to resubmit URB, such as hub_irq(). No. All faults have to cause the QH to be unlinked. That's another invariant of the driver. This is partly related to the silicon quirk present in some controllers (they perform the overlay even when the Halt bit is set in the qTD). In any case, whenever the QH is halted, the only safe way to recover is to unlink it and then relink. OK, got it, so we have to unlink the QH here as before to handle the fault. Thanks, -- Ming Lei -- 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 3/4] USB: EHCI: improve interrupt qh unlink
On Sun, 30 Jun 2013, Ming Lei wrote: Come to think of it, we never should see an endpoint being disabled while there are active URBs. It might be a better idea to put a Right. WARN_ON there and simply return, without unlinking anything. If this ever triggers, it means there's a bug in usbcore. But that isn't always true, see below case: - the last URB in the endpoint completes without resubmitting in its completion handler - then the corresponding qh is kept in linked state, but wait for being unlinked - usb_disable_endpoint() is called before the qh is put into unlinked state, and no URBs are unlinked in usb_hcd_flush_endpoint() - ehci_endpoint_disable() still see qh in QH_STATE_LINKED state. So I think we should unlink here to speed up the procedure as suggested in your previous email. You are right. If the QH's qtd_list isn't empty then we should WARN_ON and return without doing anything -- just leak the QH. Otherwise, start the unlink immediately. (By the way, in your suggested patch, I would not define the eptype variable. Simply calculate the value where it is used. Also, you removed all usages of tmp, so the declaration should be removed as well.) 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
How should we handle isochronous underruns?
Clement and Laurent: The two of you seem to be the people who make the most use of isochronous USB transfers. Since the ehci-hcd driver is being changed to use a tasklet for URB completion callbacks, it looks like I will need to reconsider how isochronous underruns get handled. The basic prolem is simple enough: What should the HCD do when an URB is submitted after an isochronous pipeline has emptied out? The problem will be more acute than in the past, because URB resubmissions will no longer be synchronous with URB completions, thanks to the tasklet. That is, in the current code, if the completion handler resubmits the URB, the resubmission occurs before the HCD finishes the completion callback. But in the new code, the HCD will simply hand the URB over to the tasklet, and the resubmission won't occur until some time later (when the tasklet wakes up and invokes the completion handler). As far as the HCD is concerned, the completion will already be finished. Thus, for example, even if the pipeline contains only a single URB, with the current code it will not become empty. But with the new code it will. If the load on the system is too high, the pipeline could empty out even if it normally contains two or more URBs. This means that the HCD will have trouble telling the difference between an underrun and a normal restart of a stopped I/O stream. In both cases it will see an URB being submitted to an empty queue. Here's where the URB_ISO_ASAP flag will be useful; if that flag is set then the URB is restarting a stopped stream, but if it isn't set then the pipeline experienced an underrun. Naturally, under normal circumstances this won't matter, because underruns shouldn't occur. But I know from experience that people try to push the latency as far down as they can, which increases the likelihood of underruns. There are several possible things the HCD could do when an underrun occurs: It could schedule the URB for the first time slot known to be available, even if that means skipping some time slots which the hardware might (or might not) be able to use. It could try to schedule the URB for the next time slot after the last one used by the preceding URB, even if that time slot has already expired. Something in between... What would be best for your purposes? Or do you have any different suggestions? 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 3/4] USB: EHCI: improve interrupt qh unlink
On Sun, Jun 30, 2013 at 10:05 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 30 Jun 2013, Ming Lei wrote: Come to think of it, we never should see an endpoint being disabled while there are active URBs. It might be a better idea to put a Right. WARN_ON there and simply return, without unlinking anything. If this ever triggers, it means there's a bug in usbcore. But that isn't always true, see below case: - the last URB in the endpoint completes without resubmitting in its completion handler - then the corresponding qh is kept in linked state, but wait for being unlinked - usb_disable_endpoint() is called before the qh is put into unlinked state, and no URBs are unlinked in usb_hcd_flush_endpoint() - ehci_endpoint_disable() still see qh in QH_STATE_LINKED state. So I think we should unlink here to speed up the procedure as suggested in your previous email. You are right. If the QH's qtd_list isn't empty then we should WARN_ON and return without doing anything -- just leak the QH. Otherwise, Yes, we can add the WARN_ON() because caller should have unlinked all requests, but looks we can handle the unlink here too without obvious side-effect. Currently, URB might be probably submitted to HCD too even after usb_hcd_flush_endpoint() completes since both accesses to dev-ep_in[epnum] and ep-enabled aren't protected by effective locks. So how about not adding the WARN_ON(!list_empty(qh-qtd_list) now when qh-qh_state is QH_STATE_LINKED? Also I am not sure if we should return without doing anything under the situation, at least when the QH is in IDLE and QH's qtd_list isn't empty, ep-hcpriv is cleared, then return. start the unlink immediately. (By the way, in your suggested patch, I would not define the eptype variable. Simply calculate the value where it is used. Also, you removed all usages of tmp, so the declaration should be removed as well.) OK, I will follow your suggest. Thanks, -- Ming Lei -- 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 3/4] USB: EHCI: improve interrupt qh unlink
On Mon, 1 Jul 2013, Ming Lei wrote: So I think we should unlink here to speed up the procedure as suggested in your previous email. You are right. If the QH's qtd_list isn't empty then we should WARN_ON and return without doing anything -- just leak the QH. Otherwise, Yes, we can add the WARN_ON() because caller should have unlinked all requests, but looks we can handle the unlink here too without obvious side-effect. Currently, URB might be probably submitted to HCD too even after usb_hcd_flush_endpoint() completes since both accesses to dev-ep_in[epnum] and ep-enabled aren't protected by effective locks. The urb_list_lock in hcd.c serves to synchronize changes to ep-enabled. An URB might be submitted after usb_hcd_flush_endpoint() completes, but the submission will fail in usb_hcd_link_urb_to_ep(). So how about not adding the WARN_ON(!list_empty(qh-qtd_list) now when qh-qh_state is QH_STATE_LINKED? I think we should add the WARN_ON. Or jump to the default case in that switch statement -- maybe the error message there should include a WARN_ON. Also I am not sure if we should return without doing anything under the situation, at least when the QH is in IDLE and QH's qtd_list isn't empty, ep-hcpriv is cleared, then return. The only way for a QH to be in the IDLE state with a non-empty qtd_list is if qh-clearing_tt is set. The code already checks for that. 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
[PATCH 3/3] USB: mos7840: fix race in led handling
Fix race in LED handling introduced by commit 0eafe4de (USB: serial:
mos7840: add support for MCS7810 devices) which reused the port control
urb for manipulating the LED without making sure that the urb is not
already in use. This could lead to the control urb being manipulated
while in flight.
Fix by adding a dedicated LED urb and ctrlrequest along with a LED-busy
flag to handle concurrency.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/mos7840.c | 60 +++-
1 file changed, 37 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 32e1c3f..1be3a60 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -185,6 +185,7 @@
enum mos7840_flag {
MOS7840_FLAG_CTRL_BUSY,
+ MOS7840_FLAG_LED_BUSY,
};
static const struct usb_device_id id_table[] = {
@@ -239,14 +240,14 @@ struct moschip_port {
/* For device(s) with LED indicator */
bool has_led;
- bool led_flag;
struct timer_list led_timer1; /* Timer for LED on */
struct timer_list led_timer2; /* Timer for LED off */
+ struct urb *led_urb;
+ struct usb_ctrlrequest *led_dr;
unsigned long flags;
};
-
/*
* mos7840_set_reg_sync
* To set the Control register by calling usb_fill_control_urb function
@@ -535,7 +536,7 @@ static void mos7840_set_led_async(struct moschip_port *mcs,
__u16 wval,
__u16 reg)
{
struct usb_device *dev = mcs-port-serial-dev;
- struct usb_ctrlrequest *dr = mcs-dr;
+ struct usb_ctrlrequest *dr = mcs-led_dr;
dr-bRequestType = MCS_WR_RTYPE;
dr-bRequest = MCS_WRREQ;
@@ -543,10 +544,10 @@ static void mos7840_set_led_async(struct moschip_port
*mcs, __u16 wval,
dr-wIndex = cpu_to_le16(reg);
dr-wLength = cpu_to_le16(0);
- usb_fill_control_urb(mcs-control_urb, dev, usb_sndctrlpipe(dev, 0),
+ usb_fill_control_urb(mcs-led_urb, dev, usb_sndctrlpipe(dev, 0),
(unsigned char *)dr, NULL, 0, mos7840_set_led_callback, NULL);
- usb_submit_urb(mcs-control_urb, GFP_ATOMIC);
+ usb_submit_urb(mcs-led_urb, GFP_ATOMIC);
}
static void mos7840_set_led_sync(struct usb_serial_port *port, __u16 reg,
@@ -572,7 +573,19 @@ static void mos7840_led_flag_off(unsigned long arg)
{
struct moschip_port *mcs = (struct moschip_port *) arg;
- mcs-led_flag = false;
+ clear_bit_unlock(MOS7840_FLAG_LED_BUSY, mcs-flags);
+}
+
+static void mos7840_led_activity(struct usb_serial_port *port)
+{
+ struct moschip_port *mos7840_port = usb_get_serial_port_data(port);
+
+ if (test_and_set_bit_lock(MOS7840_FLAG_LED_BUSY, mos7840_port-flags))
+ return;
+
+ mos7840_set_led_async(mos7840_port, 0x0301, MODEM_CONTROL_REGISTER);
+ mod_timer(mos7840_port-led_timer1,
+ jiffies + msecs_to_jiffies(LED_ON_MS));
}
/*
@@ -770,14 +783,8 @@ static void mos7840_bulk_in_callback(struct urb *urb)
return;
}
- /* Turn on LED */
- if (mos7840_port-has_led !mos7840_port-led_flag) {
- mos7840_port-led_flag = true;
- mos7840_set_led_async(mos7840_port, 0x0301,
- MODEM_CONTROL_REGISTER);
- mod_timer(mos7840_port-led_timer1,
- jiffies + msecs_to_jiffies(LED_ON_MS));
- }
+ if (mos7840_port-has_led)
+ mos7840_led_activity(port);
mos7840_port-read_urb_busy = true;
retval = usb_submit_urb(mos7840_port-read_urb, GFP_ATOMIC);
@@ -1398,13 +1405,8 @@ static int mos7840_write(struct tty_struct *tty, struct
usb_serial_port *port,
data1 = urb-transfer_buffer;
dev_dbg(port-dev, bulkout endpoint is %d\n,
port-bulk_out_endpointAddress);
- /* Turn on LED */
- if (mos7840_port-has_led !mos7840_port-led_flag) {
- mos7840_port-led_flag = true;
- mos7840_set_led_sync(port, MODEM_CONTROL_REGISTER, 0x0301);
- mod_timer(mos7840_port-led_timer1,
- jiffies + msecs_to_jiffies(LED_ON_MS));
- }
+ if (mos7840_port-has_led)
+ mos7840_led_activity(port);
/* send it down the pipe */
status = usb_submit_urb(urb, GFP_ATOMIC);
@@ -2356,6 +2358,14 @@ static int mos7840_port_probe(struct usb_serial_port
*port)
if (device_type == MOSCHIP_DEVICE_ID_7810) {
mos7840_port-has_led = true;
+ mos7840_port-led_urb = usb_alloc_urb(0, GFP_KERNEL);
+ mos7840_port-led_dr = kmalloc(sizeof(*mos7840_port-led_dr),
+ GFP_KERNEL);
+ if
[PATCH 1/3] USB: mos7840: fix race in register handling
Fix race in mos7840_get_reg which unconditionally manipulated the
control urb (which may already be in use) by adding a control-urb busy
flag.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/mos7840.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index dff27e6..64f9c22 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -183,6 +183,10 @@
#define LED_ON_MS 500
#define LED_OFF_MS 500
+enum mos7840_flag {
+ MOS7840_FLAG_CTRL_BUSY,
+};
+
static int device_type;
static const struct usb_device_id id_table[] = {
@@ -240,6 +244,8 @@ struct moschip_port {
bool led_flag;
struct timer_list led_timer1; /* Timer for LED on */
struct timer_list led_timer2; /* Timer for LED off */
+
+ unsigned long flags;
};
/*
@@ -459,10 +465,10 @@ static void mos7840_control_callback(struct urb *urb)
case -ESHUTDOWN:
/* this urb is terminated, clean up */
dev_dbg(dev, %s - urb shutting down with status: %d\n,
__func__, status);
- return;
+ goto out;
default:
dev_dbg(dev, %s - nonzero urb status received: %d\n,
__func__, status);
- return;
+ goto out;
}
dev_dbg(dev, %s urb buffer size is %d\n, __func__,
urb-actual_length);
@@ -475,6 +481,8 @@ static void mos7840_control_callback(struct urb *urb)
mos7840_handle_new_msr(mos7840_port, regval);
else if (mos7840_port-MsrLsr == 1)
mos7840_handle_new_lsr(mos7840_port, regval);
+out:
+ clear_bit_unlock(MOS7840_FLAG_CTRL_BUSY, mos7840_port-flags);
}
static int mos7840_get_reg(struct moschip_port *mcs, __u16 Wval, __u16 reg,
@@ -485,6 +493,9 @@ static int mos7840_get_reg(struct moschip_port *mcs, __u16
Wval, __u16 reg,
unsigned char *buffer = mcs-ctrl_buf;
int ret;
+ if (test_and_set_bit_lock(MOS7840_FLAG_CTRL_BUSY, mcs-flags))
+ return -EBUSY;
+
dr-bRequestType = MCS_RD_RTYPE;
dr-bRequest = MCS_RDREQ;
dr-wValue = cpu_to_le16(Wval); /* 0 */
@@ -496,6 +507,9 @@ static int mos7840_get_reg(struct moschip_port *mcs, __u16
Wval, __u16 reg,
mos7840_control_callback, mcs);
mcs-control_urb-transfer_buffer_length = 2;
ret = usb_submit_urb(mcs-control_urb, GFP_ATOMIC);
+ if (ret)
+ clear_bit_unlock(MOS7840_FLAG_CTRL_BUSY, mcs-flags);
+
return ret;
}
--
1.8.2.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
[PATCH 0/3] USB: mos7840: fixes for v3.11-rc1
These patches fix three (related) races in mos7840. Driver's a bit of mess... Tested using a mos7820 (and by faking a mos7810 with LED). Johan Johan Hovold (3): USB: mos7840: fix race in register handling USB: mos7840: fix device-type detection USB: mos7840: fix race in led handling drivers/usb/serial/mos7840.c | 150 +-- 1 file changed, 87 insertions(+), 63 deletions(-) -- 1.8.2.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
[PATCH 2/3] USB: mos7840: fix device-type detection
Fix race in device-type detection introduced by commit 0eafe4de (USB:
serial: mos7840: add support for MCS7810 devices) which used a static
variable to hold the device type.
Move type detection to probe and use serial data to store the device
type.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/mos7840.c | 76 +---
1 file changed, 36 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 64f9c22..32e1c3f 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -187,8 +187,6 @@ enum mos7840_flag {
MOS7840_FLAG_CTRL_BUSY,
};
-static int device_type;
-
static const struct usb_device_id id_table[] = {
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7840)},
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7820)},
@@ -248,6 +246,7 @@ struct moschip_port {
unsigned long flags;
};
+
/*
* mos7840_set_reg_sync
* To set the Control register by calling usb_fill_control_urb function
@@ -829,18 +828,6 @@ static void mos7840_bulk_out_data_callback(struct urb *urb)
//
/* D R I V E R T T Y I N T E R F A C E F U N C T I O N S */
//
-#ifdef MCSSerialProbe
-static int mos7840_serial_probe(struct usb_serial *serial,
- const struct usb_device_id *id)
-{
-
- /*need to implement the mode_reg reading and updating\
- structures usb_serial_ device_type\
- (i.e num_ports, num_bulkin,bulkout etc) */
- /* Also we can update the changes attach */
- return 1;
-}
-#endif
/*
* mos7840_open
@@ -2144,38 +2131,48 @@ static int mos7810_check(struct usb_serial *serial)
return 0;
}
-static int mos7840_calc_num_ports(struct usb_serial *serial)
+static int mos7840_probe(struct usb_serial *serial,
+ const struct usb_device_id *id)
{
- __u16 data = 0x00;
+ u16 product = serial-dev-descriptor.idProduct;
u8 *buf;
- int mos7840_num_ports;
+ int device_type;
+
+ if (product == MOSCHIP_DEVICE_ID_7810 ||
+ product == MOSCHIP_DEVICE_ID_7820) {
+ device_type = product;
+ goto out;
+ }
buf = kzalloc(VENDOR_READ_LENGTH, GFP_KERNEL);
- if (buf) {
- usb_control_msg(serial-dev, usb_rcvctrlpipe(serial-dev, 0),
+ if (!buf)
+ return -ENOMEM;
+
+ usb_control_msg(serial-dev, usb_rcvctrlpipe(serial-dev, 0),
MCS_RDREQ, MCS_RD_RTYPE, 0, GPIO_REGISTER, buf,
VENDOR_READ_LENGTH, MOS_WDR_TIMEOUT);
- data = *buf;
- kfree(buf);
- }
- if (serial-dev-descriptor.idProduct == MOSCHIP_DEVICE_ID_7810 ||
- serial-dev-descriptor.idProduct == MOSCHIP_DEVICE_ID_7820) {
- device_type = serial-dev-descriptor.idProduct;
- } else {
- /* For a MCS7840 device GPIO0 must be set to 1 */
- if ((data 0x01) == 1)
- device_type = MOSCHIP_DEVICE_ID_7840;
- else if (mos7810_check(serial))
- device_type = MOSCHIP_DEVICE_ID_7810;
- else
- device_type = MOSCHIP_DEVICE_ID_7820;
- }
+ /* For a MCS7840 device GPIO0 must be set to 1 */
+ if (buf[0] 0x01)
+ device_type = MOSCHIP_DEVICE_ID_7840;
+ else if (mos7810_check(serial))
+ device_type = MOSCHIP_DEVICE_ID_7810;
+ else
+ device_type = MOSCHIP_DEVICE_ID_7820;
+
+ kfree(buf);
+out:
+ usb_set_serial_data(serial, (void *)device_type);
+
+ return 0;
+}
+
+static int mos7840_calc_num_ports(struct usb_serial *serial)
+{
+ int device_type = (int)usb_get_serial_data(serial);
+ int mos7840_num_ports;
mos7840_num_ports = (device_type 4) 0x000F;
- serial-num_bulk_in = mos7840_num_ports;
- serial-num_bulk_out = mos7840_num_ports;
- serial-num_ports = mos7840_num_ports;
return mos7840_num_ports;
}
@@ -2183,6 +2180,7 @@ static int mos7840_calc_num_ports(struct usb_serial
*serial)
static int mos7840_port_probe(struct usb_serial_port *port)
{
struct usb_serial *serial = port-serial;
+ int device_type = (int)usb_get_serial_data(serial);
struct moschip_port *mos7840_port;
int status;
int pnum;
@@ -2439,9 +2437,7 @@ static struct usb_serial_driver moschip7840_4port_device
= {
.throttle = mos7840_throttle,
.unthrottle = mos7840_unthrottle,
.calc_num_ports = mos7840_calc_num_ports,
-#ifdef MCSSerialProbe
-
Re: Scanner fails on USB3 port
3.9.8 brought a tiny improvement! scanimage -L now succesfully reports the scanner, but then hangs. I still can not scan with xsane however (no scanner device found) $ scanimage -L device `plustek:libusb:001:004' is a Canon CanoScan N670U/N676U/LiDE20 flatbed scanner (hang, but eventually returns prompt after couple of minutes) Best regards Martin On Fri, May 24, 2013 at 2:49 PM, Martin van Es mrva...@gmail.com wrote: Is noone interested in taking this up with me? Martin On Mon, May 13, 2013 at 1:20 PM, Martin van Es mrva...@gmail.com wrote: Hi, I have exactly the same problem as described by Harald Judt in this mail: http://www.spinics.net/lists/linux-usb/msg58841.html The thread ends here, in mid conversation with Sarah Sharp: http://www.spinics.net/lists/linux-usb/msg69636.html ... so I'd like to take it up from there. The scanner is a Canoscan N670U (LiDE 20). sane-fine-scanner finds the scanner: found USB scanner (vendor=0x04a9 [Canon], product=0x220d [CanoScan]) at libusb:003:003 but scanimage -L fails (no output) The attached (3.9.2) kernel log is from boot, to supply all usb initialisation messages. Around 46.650933 I did the sane-find-scanner. Starting 60.438552 you see output of scanimage -L and 707.400622 again so it's isolated from possible noise. The scanner is fully functional on my old laptop with USB2 ports. Hope this helps resolving the bug. Best regards, Martin van Es -- If 'but' was any useful, it would be a logic operator -- If 'but' was any useful, it would be a logic operator -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: host: xhci-plat: Enable XHCI_SPURIOUS_SUCCESS quirk for xhci-plat
On Wed, Jun 26, 2013 at 09:53:34AM -0700, Sarah Sharp wrote: On Wed, Jun 26, 2013 at 02:28:57PM +0530, George Cherian wrote: Synopsis xhci controllers with hci_version 0.96 gives spurious success events on short packet completion. During webcam capture the ERROR Transfer event TRB DMA ptr not part of current TD was observed. The same application works fine with synopsis controllers hci_version 0.96. It's a known issue. The xHCI 1.0 spec changed how hardware handles short packets. The HW will notify SW of the TRB where the short packet, and it will also give a successful status for the last TRB in a TD (the one with the IOC flag set). On the second successful status, that warning will be triggered in the driver. Software is now supposed to not assume the TD as done until it gets that last successful status. That means we have a slight race condition, although it should have little practical impact. This patch papers over that issue. I will take this patch, but will add the note that is on my long-term to-do list to fix this issue. Actually, since it applies to both xhci-plat and xhci-pci hosts, can you move setting this quirk into xhci_gen_setup? Sarah Sharp Signed-off-by: George Cherian george.cher...@ti.com --- drivers/usb/host/xhci-plat.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 93ad67e..e63c6d3 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -25,6 +25,16 @@ static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci) * dev struct in order to setup MSI */ xhci-quirks |= XHCI_BROKEN_MSI; + + /* +* In some xhci controllers which follows xhci 1.0 spec gives a spurious +* success event after a short transfer. This quirk will ignore such +* spurious event. Hit this issue in synopsis xhci controllers with +* hci_version 0.96 +*/ + + if (xhci-hci_version 0x96) + xhci-quirks |= XHCI_SPURIOUS_SUCCESS; } /* called during probe() after chip reset completes */ -- 1.8.1.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 -- 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] xhci: Compute last_ctx from complete set of configured endpoints.
On Mon, Jun 24, 2013 at 09:24:28AM -0700, Reilly Grant wrote: On Mon, Jun 24, 2013 at 08:59AM -0700, Sarah Sharp wrote: On Tue, Jun 18, 2013 at 02:09:13PM -0700, Reilly Grant wrote: So, no, I can't accept this patch. If this fixes a real problem in some hardware, we'll add a quirk for that hardware. Thank you for the clarification. I was not aware of this addendum. Could you forward me a link to it? The last revision I can find on the Intel web site is from 05/2010. The xHCI architect hasn't done an official release on the Intel site for a while now. I think he's working on a bigger 1.1 release that includes all the errata over the past couple years. I think you can get the latest revision by emailing xhcisupp...@intel.com. If you don't hear back within a week or so, email me back and I'll send you a PDF. This fixed a problem on VMware's virtual hardware. Assuming changing behavior will not affect any other systems I will fix it based on this information. Yes, please fix this in VMware's virtual hardware. Thanks, Sarah Sharp -- 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
[RFC] xhci: remove USB_XHCI_HCD_DEBUGGING config option
CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
verbose debugging output for the xHCI host controller
driver.
In the current version of the xhci-hcd driver, this
option must be turned on, in order for the debugging
log messages to be displayed, and users may need to
recompile the linux kernel to obtain debugging
information that will help them track down problems.
This patch removes the above debug option to enable
debugging log messages at all times.
The aim of this is to rely on the debugfs and the
dynamic debugging feature for fine-grained management
of debugging messages and to not force users to set
the debug config option and compile the linux kernel
in order to have access in that information.
This patch, also, removes the XHCI_DEBUG symbol and the
functions dma_to_stream_ring(), xhci_test_radix_tree()
and xhci_event_ring_work() that are not useful anymore.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
---
drivers/usb/host/Kconfig| 9 --
drivers/usb/host/xhci-mem.c | 72
drivers/usb/host/xhci.c | 73 -
drivers/usb/host/xhci.h | 14 ++---
4 files changed, 2 insertions(+), 166 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 344d5e2..2d376e2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -30,15 +30,6 @@ if USB_XHCI_HCD
config USB_XHCI_PLATFORM
tristate
-config USB_XHCI_HCD_DEBUGGING
- bool Debugging for the xHCI host controller
- ---help---
- Say 'Y' to turn on debugging for the xHCI host controller driver.
- This will spew debugging output, even in interrupt context.
- This should only be used for debugging xHCI driver bugs.
-
- If unsure, say N.
-
endif # USB_XHCI_HCD
config USB_EHCI_HCD
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index fbf75e5..9387d36 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -471,17 +471,6 @@ struct xhci_ring *xhci_dma_to_transfer_ring(
return ep-ring;
}
-/* Only use this when you know stream_info is valid */
-#ifdef CONFIG_USB_XHCI_HCD_DEBUGGING
-static struct xhci_ring *dma_to_stream_ring(
- struct xhci_stream_info *stream_info,
- u64 address)
-{
- return radix_tree_lookup(stream_info-trb_address_map,
- address TRB_SEGMENT_SHIFT);
-}
-#endif /* CONFIG_USB_XHCI_HCD_DEBUGGING */
-
struct xhci_ring *xhci_stream_id_to_ring(
struct xhci_virt_device *dev,
unsigned int ep_index,
@@ -499,58 +488,6 @@ struct xhci_ring *xhci_stream_id_to_ring(
return ep-stream_info-stream_rings[stream_id];
}
-#ifdef CONFIG_USB_XHCI_HCD_DEBUGGING
-static int xhci_test_radix_tree(struct xhci_hcd *xhci,
- unsigned int num_streams,
- struct xhci_stream_info *stream_info)
-{
- u32 cur_stream;
- struct xhci_ring *cur_ring;
- u64 addr;
-
- for (cur_stream = 1; cur_stream num_streams; cur_stream++) {
- struct xhci_ring *mapped_ring;
- int trb_size = sizeof(union xhci_trb);
-
- cur_ring = stream_info-stream_rings[cur_stream];
- for (addr = cur_ring-first_seg-dma;
- addr cur_ring-first_seg-dma +
TRB_SEGMENT_SIZE;
- addr += trb_size) {
- mapped_ring = dma_to_stream_ring(stream_info, addr);
- if (cur_ring != mapped_ring) {
- xhci_warn(xhci, WARN: DMA address 0x%08llx
- didn't map to stream ID %u;
- mapped to ring %p\n,
- (unsigned long long) addr,
- cur_stream,
- mapped_ring);
- return -EINVAL;
- }
- }
- /* One TRB after the end of the ring segment shouldn't return a
-* pointer to the current ring (although it may be a part of a
-* different ring).
-*/
- mapped_ring = dma_to_stream_ring(stream_info, addr);
- if (mapped_ring != cur_ring) {
- /* One TRB before should also fail */
- addr = cur_ring-first_seg-dma - trb_size;
- mapped_ring = dma_to_stream_ring(stream_info, addr);
- }
- if (mapped_ring == cur_ring) {
- xhci_warn(xhci, WARN: Bad DMA address 0x%08llx
- mapped to valid stream ID %u;
- mapped ring = %p\n,
- (unsigned long long) addr,
-
Re: [RFC] xhci: remove USB_XHCI_HCD_DEBUGGING config option
On Mon, Jul 01, 2013 at 12:23:18AM +0300, Xenia Ragiadakou wrote:
CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
verbose debugging output for the xHCI host controller
driver.
In the current version of the xhci-hcd driver, this
option must be turned on, in order for the debugging
log messages to be displayed, and users may need to
recompile the linux kernel to obtain debugging
information that will help them track down problems.
This patch removes the above debug option to enable
debugging log messages at all times.
The aim of this is to rely on the debugfs and the
dynamic debugging feature for fine-grained management
of debugging messages and to not force users to set
the debug config option and compile the linux kernel
in order to have access in that information.
This patch, also, removes the XHCI_DEBUG symbol and the
functions dma_to_stream_ring(), xhci_test_radix_tree()
and xhci_event_ring_work() that are not useful anymore.
Those functions really aren't useful anymore? If so, great, but
wouldn't be nice to be able to enable them dynamically through debugfs
if someone wanted the information they provide?
#define xhci_dbg(xhci, fmt, args...) \
- do { if (XHCI_DEBUG) dev_dbg(xhci_to_hcd(xhci)-self.controller , fmt ,
## args); } while (0)
+ dev_dbg(xhci_to_hcd(xhci)-self.controller , fmt , ## args)
That's good.
#define xhci_info(xhci, fmt, args...) \
- do { if (XHCI_DEBUG) dev_info(xhci_to_hcd(xhci)-self.controller , fmt
, ## args); } while (0)
+ dev_info(xhci_to_hcd(xhci)-self.controller , fmt , ## args)
I think you might have just turned on a bunch more default information
here. Hm, it's only used twice anyway, in the same error, shouldn't
they be turned into xhci_dbg() calls instead?
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
Re: Scanner fails on USB3 port
On Sun, Jun 30, 2013 at 09:35:59PM +0200, Martin van Es wrote: 3.9.8 brought a tiny improvement! scanimage -L now succesfully reports the scanner, but then hangs. I still can not scan with xsane however (no scanner device found) $ scanimage -L device `plustek:libusb:001:004' is a Canon CanoScan N670U/N676U/LiDE20 flatbed scanner (hang, but eventually returns prompt after couple of minutes) Any chance you can try 3.10-rc7 to see if anything improved there? 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
Re: [PATCH] xhci: fix dma mask setup in xhci.c
On Wed, Jun 26, 2013 at 01:20:53AM +0300, Xenia Ragiadakou wrote:
On 06/26/2013 12:16 AM, Sarah Sharp wrote:
I'm a little bit confused by this patch, so I'm CC-ing the list.
On Tue, Jun 25, 2013 at 08:52:49AM +0300, Xenia Ragiadakou wrote:
This patch initializes the dma_mask pointer to point
to the coherent_dma_mask, since the same value will
be assigned to both, and adds a check on the value
returned by dma_set_mask().
dma_set_coherent_mask() is not called because it is
guaranteed that if dma_set_mask() succeeds, for a
given bitmask, dma_set_coherent_mask() will also
succeed for the same bitmask.
Did you mean to say The return value of dma_set_coherent_mask() is not
checked because... instead of dma_set_coherent_mask() is not called
because... ?
I believe the discussion was that dma_set_coherent_mask() is guaranteed
to succeed if dma_set_mask() succeeds. However, you still need to set
dev.coherent_dma_mask with a call to dma_set_coherent_mask(). I don't
see where in this patch you do that.
Since, now the dma_mask pointer points to the coherent_dma_mask,
the value of both will be set via dma_set_mask().
I do not know if that is more clear.
Ah, ok, I understand why you wrote the original code that way.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
---
drivers/usb/host/xhci.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d8f640b..b5db324 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4672,11 +4672,14 @@ int xhci_gen_setup(struct usb_hcd *hcd,
xhci_get_quirks_t get_quirks)
*/
xhci = hcd_to_xhci(hcd);
temp = xhci_readl(xhci, xhci-cap_regs-hcc_params);
- if (HCC_64BIT_ADDR(temp)) {
+ dev-dma_mask = dev-coherent_dma_mask;
This should be
if (!dev-dev.dma_mask)
dev-dma_mask = dev-coherent_dma_mask;
If the dma_mask pointer is already set (say by the PCI core), we don't
want to overwrite it. We just want to set the mask pointer if this is a
platform device without a DMA pointer.
I did not add, in purpose, this check because since both dma_mask
and coherent_dma_mask will be assigned the same bitmask,
I thought better to make the assignment once.
The fact that maybe there is problem when changing the address to
which points dma_mask in pci platforms didnot cross my mind at
that moment.
I looked at the PCI init code. Here's what happens in
drivers/pci/probe.c:
During PCI initialization, pci_dev-dma_mask gets set to 32-bits in
pci_setup_device(). Later, when the PCI device is added, the base
device structure's DMA mask is changed to point to pci_dev-dma_mask.
That means pci_device_add() sets pci_dev-dev.dma mask to point to
pci_dev-dma_mask. The pci_dev-dev.coherent_dma_mask is set to a
32-bit value.
If you change the dev-dma_mask pointer to point to
dev-coherent_dma_mask, that means the pci_dev-dma_mask won't get
updated when you call dma_set_mask(). That wouldn't be good, since the
underlying base device and pci_dev structures could end up with
different DMA masks.
The TLDR; version is that if dev-dma_mask is set, you shouldn't change
it. That means you'll need to add the additional if statement, and
call dma_set_coherent_mask() as well.
+ if (HCC_64BIT_ADDR(temp)
+ !dma_set_mask(dev, DMA_BIT_MASK(64))) {
xhci_dbg(xhci, Enabling 64-bit DMA addresses.\n);
- dma_set_mask(hcd-self.controller, DMA_BIT_MASK(64));
+ dma_set_mask(dev, DMA_BIT_MASK(64));
I believe you wanted to call dma_set_coherent_mask() in that last line
above, rather than calling dma_set_mask() again (you called it in the if
statement).
Sorry, about that! Actually I wanted to call just:
xhci_dbg(xhci, Enabling 64-bit DMA addresses.\n);
Ok, please fix that too.
} else {
- dma_set_mask(hcd-self.controller, DMA_BIT_MASK(32));
+ if (dma_set_mask(dev, DMA_BIT_MASK(32)))
+ goto error;
I think you need to call dma_set_coherent_mask(dev, DMA_BIT_MASK(32))
when that dma_set_mask() call succeeds. If we're dealing with a
platform device, it may not have the coherent mask set. Alan, Andy,
Felipe, does this sound correct?
As I said above, dma_set_mask() will set the DMA bitmask to both,
if this bitmask is supported. If it is supported, it is guaranteed
that the same bitmask will also be supported for consistent DMA
mappings so there is no need to call dma_set_coherent_mask()
(since now the coherent mask is already set via dma_set_mask()
and it is sure that it is supported).
Right, there was no need to call dma_set_coherent_mask() in your
original code, but in the next revision of the patch, you will need to
call it here.
Sarah Sharp
--
To unsubscribe from this list: send the line
Huawei E3131 wwan interface
Hi!
I'm trying to investigate on the Huawei E3131 wwan interface - like the E398,
this device ignores the at^ndisdup command.
I wanted to verify if my device was running a jungo firmware or not, since I
found contraddictory informations on the network.
To this end, I patched the cdc_ncm driver with a function was responsible for
the initializzation of jungo devices:
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 43afde8..79770ed 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -39,6 +39,7 @@
*/
#include linux/module.h
+#include linux/usbdevice_fs.h
#include linux/init.h
#include linux/netdevice.h
#include linux/ctype.h
@@ -352,6 +353,37 @@ static const struct ethtool_ops cdc_ncm_ethtool_ops = {
.nway_reset = usbnet_nway_reset,
};
+int hw_send_tlp_download_request(struct usb_interface *intf){
+ printk(Entering hw_send_tlp_download_request...\n);
+ struct usb_device *udev = interface_to_usbdev(intf);
+ struct usb_host_interface *interface = intf-cur_altsetting;
+ struct usbdevfs_ctrltransfer req = {0};
+//memset?
+ unsigned char buf[256] = {0};
+ int retval = 0;
+ req.bRequestType = 0xC0;
+ req.bRequest = 0x02;
+ req.wIndex = interface-desc.bInterfaceNumber;
+ req.wValue = 1;
+ req.wLength = 1;
+ req.data = buf;
+ req.timeout = 1000;
+ retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), req.bRequest,
req.bRequestType, req.wValue, req.wIndex, req.data, req.wLength, req.timeout);
+ /*
+ Check the TLP feature is activated or not, response value 0x01
+ indicates success
+ */
+ if (0 retval 0x01 == buf[0]){
+ printk(Success!\n);
+ return retval; /* succeeded */
+ }
+ else
+ {
+ printk(Failed...\n);
+ return 0; /* failed */
+ }
+}
+
int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8
data_altsetting)
{
struct cdc_ncm_ctx *ctx;
@@ -1142,7 +1174,10 @@ static int cdc_ncm_check_connect(struct usbnet *dev)
static int
cdc_ncm_probe(struct usb_interface *udev, const struct usb_device_id *prod)
{
- return usbnet_probe(udev, prod);
+ int retval;
+ retval = usbnet_probe(udev, prod);
+ hw_send_tlp_download_request(udev);
+ return retval;
}
static void cdc_ncm_disconnect(struct usb_interface *intf)
and I'm hitting the failed case. So, can I say I'm not running a jungo-based
firmware?
And - another note.
I never used ncm devices, so I don't know if there is a way to communicate with
the device directly via ncm protocol (i.e.: not using AT).
When I try to bring up the ncm interface, I always get a unexpected
notification message.
Looking at the VERY MESSY w_cdc_driver.c release from Huawei, I noticed there
are various functions to deal with ncm fixups, particularly:
- one for fixing up received packets
- the other for fixing up sent packets
So probably the ncm driver would need a substantial rewrite aniway, making it
more practical to create a new one.
Another thing - the w_cdc_driver.c driver, seems to be free software!
So - am I wrong or do we actually have all the hints we need to implement a
proper driver?
But - another quqestion is probably worthwhile: can someone confirm that the
w_cdc_driver.c can establish a connection, even with the device ignoring the
^ndisdup / ^ndisconn commands?
thank you all!!
On Sun, 30 Jun 2013, Bj?rn Mork wrote:
==Date: Sun, 30 Jun 2013 00:35:20 +0200
==From: Bj?rn Mork bj...@mork.no
==To: Enrico Mioso mrkiko...@gmail.com
==Cc: linux-usb@vger.kernel.org
==Subject: Re: Huawei E398 and at^ndisdup
==
==Enrico Mioso mrkiko...@gmail.com writes:
==
== Hi all guys!
== I came across one of the strangest devices ever, at least to me: a Huawei
E3131
== device:
== Model: E3131
== Revision: 21.157.41.01.1037
== But the usb id says a different story:
== Bus 003 Device 023: ID 12d1:1506 Huawei Technologies Co., Ltd. E398
== LTE/UMTS/GSM Modem/Networkcard
==
== But this hardware in particular doesn't support LTE.
==
==Huawei reuse device IDs. 12d1:1506 is used for E398, E392 and many
==other devices. So the descriptive text from the device ID database is
==meaningless. There is no way to know what device this is based on the
==USB descriptors only.
==
== the device is handled by option + cdc_ncm - and that sounds right.
== Now - the problem: with the
== at^ndisdup
== or
== at^ndisconn
== commands, it is not possible to establish a connection. How can this device
be
== used without PPP?
==
==If at^ndisdup doesn't work, then we do not know. You could try snooping
==on Windows and see what it does to connect this modem.
==
== I saw some patches in modemmanager, but can't understand exactly how things
== work.
==
== I know this is not the right list to post this question - but my hope is
that
== someone could help me understand.
Re: [PATCH 1/1] usb,uhci: add a new tag for virtual uhci devices
On 06/28/2013 10:22 PM, Alan Stern wrote: On Fri, 28 Jun 2013, Li, Zhen-Hua (USL-China) wrote: There was a problem, the warning Controller not stopped yet. And your last patch for this problem does a wrong thing: It prevents all HP uhci devices from auto-stop, which make HP uhci devices waste more power. Do they really waste more power? Have you measured this? Is CONFIG_PM enabled in the kernel configuration? This is another new problem. I think this should be corrected, so I want to apply it. In the last email, you said that your patch did not make the machine act different. Now you say that your patch makes the machine use less power. Which statement is correct? Alan Stern Let's make it clear: I said I don't have a machine that this makes action different, it does not mean my patch did not make the machine act different . There are many kinds of machines, I have never said my patch does not make ALL of them act different. -- 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: [RFC] xhci: remove USB_XHCI_HCD_DEBUGGING config option
On Sun, Jun 30, 2013 at 02:54:26PM -0700, Greg KH wrote:
On Mon, Jul 01, 2013 at 12:23:18AM +0300, Xenia Ragiadakou wrote:
CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
verbose debugging output for the xHCI host controller
driver.
In the current version of the xhci-hcd driver, this
option must be turned on, in order for the debugging
log messages to be displayed, and users may need to
recompile the linux kernel to obtain debugging
information that will help them track down problems.
This patch removes the above debug option to enable
debugging log messages at all times.
The aim of this is to rely on the debugfs and the
dynamic debugging feature for fine-grained management
of debugging messages and to not force users to set
the debug config option and compile the linux kernel
in order to have access in that information.
This patch, also, removes the XHCI_DEBUG symbol and the
functions dma_to_stream_ring(), xhci_test_radix_tree()
and xhci_event_ring_work() that are not useful anymore.
Those functions really aren't useful anymore? If so, great, but
wouldn't be nice to be able to enable them dynamically through debugfs
if someone wanted the information they provide?
They're really not useful.
The xhci_test_radix_tree() runs the same static test on the radix tree
whenever the xHCI module loads. I mostly wrote it to test my code, but
it's not useful anymore. dma_to_stream_ring() is only called from
xhci_test_radix_tree().
xhci_event_ring_work() spews the contents of the endpoint rings every
minute. It's really not useful to leave turned on, since the rings are
printed in the various places where interesting ring events occur. The
ring printing also doesn't scale as more and more devices are added.
I think it would be better if users could get the contents of the
rings through a debugfs file instead. I think the EHCI driver does
something similar for the frame list. But one thing at a time. I'll
save that item for Xenia in my 'future-tasks' file.
#define xhci_dbg(xhci, fmt, args...) \
- do { if (XHCI_DEBUG) dev_dbg(xhci_to_hcd(xhci)-self.controller , fmt ,
## args); } while (0)
+ dev_dbg(xhci_to_hcd(xhci)-self.controller , fmt , ## args)
That's good.
#define xhci_info(xhci, fmt, args...) \
- do { if (XHCI_DEBUG) dev_info(xhci_to_hcd(xhci)-self.controller , fmt
, ## args); } while (0)
+ dev_info(xhci_to_hcd(xhci)-self.controller , fmt , ## args)
I think you might have just turned on a bunch more default information
here. Hm, it's only used twice anyway, in the same error, shouldn't
they be turned into xhci_dbg() calls instead?
Yeah, they should just be turned into xhci_dbg(), and xhci_info should
be removed.
Sarah Sharp
--
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: [RFC] xhci: remove USB_XHCI_HCD_DEBUGGING config option
On 07/01/2013 04:24 AM, Sarah Sharp wrote:
On Sun, Jun 30, 2013 at 02:54:26PM -0700, Greg KH wrote:
On Mon, Jul 01, 2013 at 12:23:18AM +0300, Xenia Ragiadakou wrote:
CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
verbose debugging output for the xHCI host controller
driver.
In the current version of the xhci-hcd driver, this
option must be turned on, in order for the debugging
log messages to be displayed, and users may need to
recompile the linux kernel to obtain debugging
information that will help them track down problems.
This patch removes the above debug option to enable
debugging log messages at all times.
The aim of this is to rely on the debugfs and the
dynamic debugging feature for fine-grained management
of debugging messages and to not force users to set
the debug config option and compile the linux kernel
in order to have access in that information.
This patch, also, removes the XHCI_DEBUG symbol and the
functions dma_to_stream_ring(), xhci_test_radix_tree()
and xhci_event_ring_work() that are not useful anymore.
Those functions really aren't useful anymore? If so, great, but
wouldn't be nice to be able to enable them dynamically through debugfs
if someone wanted the information they provide?
They're really not useful.
The xhci_test_radix_tree() runs the same static test on the radix tree
whenever the xHCI module loads. I mostly wrote it to test my code, but
it's not useful anymore. dma_to_stream_ring() is only called from
xhci_test_radix_tree().
xhci_event_ring_work() spews the contents of the endpoint rings every
minute. It's really not useful to leave turned on, since the rings are
printed in the various places where interesting ring events occur. The
ring printing also doesn't scale as more and more devices are added.
I think it would be better if users could get the contents of the
rings through a debugfs file instead. I think the EHCI driver does
something similar for the frame list. But one thing at a time. I'll
save that item for Xenia in my 'future-tasks' file.
#define xhci_dbg(xhci, fmt, args...) \
- do { if (XHCI_DEBUG) dev_dbg(xhci_to_hcd(xhci)-self.controller , fmt ,
## args); } while (0)
+ dev_dbg(xhci_to_hcd(xhci)-self.controller , fmt , ## args)
That's good.
#define xhci_info(xhci, fmt, args...) \
- do { if (XHCI_DEBUG) dev_info(xhci_to_hcd(xhci)-self.controller , fmt
, ## args); } while (0)
+ dev_info(xhci_to_hcd(xhci)-self.controller , fmt , ## args)
I think you might have just turned on a bunch more default information
here. Hm, it's only used twice anyway, in the same error, shouldn't
they be turned into xhci_dbg() calls instead?
Yeah, they should just be turned into xhci_dbg(), and xhci_info should
be removed.
Sarah Sharp
I will replace xhci_info() and printk() calls with xhci_dbg()
in another patch. Because if I replace xhci_info() in this
patch it will look out of topic, I think.
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] xhci: fix dma mask setup in xhci.c
On 07/01/2013 01:29 AM, Sarah Sharp wrote:
On Wed, Jun 26, 2013 at 01:20:53AM +0300, Xenia Ragiadakou wrote:
On 06/26/2013 12:16 AM, Sarah Sharp wrote:
I'm a little bit confused by this patch, so I'm CC-ing the list.
On Tue, Jun 25, 2013 at 08:52:49AM +0300, Xenia Ragiadakou wrote:
This patch initializes the dma_mask pointer to point
to the coherent_dma_mask, since the same value will
be assigned to both, and adds a check on the value
returned by dma_set_mask().
dma_set_coherent_mask() is not called because it is
guaranteed that if dma_set_mask() succeeds, for a
given bitmask, dma_set_coherent_mask() will also
succeed for the same bitmask.
Did you mean to say The return value of dma_set_coherent_mask() is not
checked because... instead of dma_set_coherent_mask() is not called
because... ?
I believe the discussion was that dma_set_coherent_mask() is guaranteed
to succeed if dma_set_mask() succeeds. However, you still need to set
dev.coherent_dma_mask with a call to dma_set_coherent_mask(). I don't
see where in this patch you do that.
Since, now the dma_mask pointer points to the coherent_dma_mask,
the value of both will be set via dma_set_mask().
I do not know if that is more clear.
Ah, ok, I understand why you wrote the original code that way.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
---
drivers/usb/host/xhci.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d8f640b..b5db324 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4672,11 +4672,14 @@ int xhci_gen_setup(struct usb_hcd *hcd,
xhci_get_quirks_t get_quirks)
*/
xhci = hcd_to_xhci(hcd);
temp = xhci_readl(xhci, xhci-cap_regs-hcc_params);
- if (HCC_64BIT_ADDR(temp)) {
+ dev-dma_mask = dev-coherent_dma_mask;
This should be
if (!dev-dev.dma_mask)
dev-dma_mask = dev-coherent_dma_mask;
If the dma_mask pointer is already set (say by the PCI core), we don't
want to overwrite it. We just want to set the mask pointer if this is a
platform device without a DMA pointer.
I did not add, in purpose, this check because since both dma_mask
and coherent_dma_mask will be assigned the same bitmask,
I thought better to make the assignment once.
The fact that maybe there is problem when changing the address to
which points dma_mask in pci platforms didnot cross my mind at
that moment.
I looked at the PCI init code. Here's what happens in
drivers/pci/probe.c:
During PCI initialization, pci_dev-dma_mask gets set to 32-bits in
pci_setup_device(). Later, when the PCI device is added, the base
device structure's DMA mask is changed to point to pci_dev-dma_mask.
That means pci_device_add() sets pci_dev-dev.dma mask to point to
pci_dev-dma_mask. The pci_dev-dev.coherent_dma_mask is set to a
32-bit value.
If you change the dev-dma_mask pointer to point to
dev-coherent_dma_mask, that means the pci_dev-dma_mask won't get
updated when you call dma_set_mask(). That wouldn't be good, since the
underlying base device and pci_dev structures could end up with
different DMA masks.
The TLDR; version is that if dev-dma_mask is set, you shouldn't change
it. That means you'll need to add the additional if statement, and
call dma_set_coherent_mask() as well.
+ if (HCC_64BIT_ADDR(temp)
+ !dma_set_mask(dev, DMA_BIT_MASK(64))) {
xhci_dbg(xhci, Enabling 64-bit DMA addresses.\n);
- dma_set_mask(hcd-self.controller, DMA_BIT_MASK(64));
+ dma_set_mask(dev, DMA_BIT_MASK(64));
I believe you wanted to call dma_set_coherent_mask() in that last line
above, rather than calling dma_set_mask() again (you called it in the if
statement).
Sorry, about that! Actually I wanted to call just:
xhci_dbg(xhci, Enabling 64-bit DMA addresses.\n);
Ok, please fix that too.
} else {
- dma_set_mask(hcd-self.controller, DMA_BIT_MASK(32));
+ if (dma_set_mask(dev, DMA_BIT_MASK(32)))
+ goto error;
I think you need to call dma_set_coherent_mask(dev, DMA_BIT_MASK(32))
when that dma_set_mask() call succeeds. If we're dealing with a
platform device, it may not have the coherent mask set. Alan, Andy,
Felipe, does this sound correct?
As I said above, dma_set_mask() will set the DMA bitmask to both,
if this bitmask is supported. If it is supported, it is guaranteed
that the same bitmask will also be supported for consistent DMA
mappings so there is no need to call dma_set_coherent_mask()
(since now the coherent mask is already set via dma_set_mask()
and it is sure that it is supported).
Right, there was no need to call dma_set_coherent_mask() in your
original code, but in the next revision of the patch, you will need to
call it here.
Sarah Sharp
Yes, you are
RE: Chipidea usb otg support for IMX/MXS (device functionality)
You should see the voltage of vbus pin is less than 0.8v when
nothing is connected, we use B_SESSION_VALID (0.8v) to judge
it is connected or not.
You get 2.25 all the time or it is discharged very slowly?
On my mx28evk it discharges very very slowly. Any hints about it?
Due to some hardware limitations, the dual-role functions at OTG port
can't be used with host 1 port at the same time at mx28evk. Please follow
below to use USB ports at mx28evk.
When testing usb OTG port, please switch VDD 5V SOURCE SELECT to USB 5V
When testing usb host1 port, please switch VDD 5V SOURCE SELECT to WALL 5V
Best regards,
Peter
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [PATCH v3 3/4] USB: EHCI: improve interrupt qh unlink
On Mon, Jul 1, 2013 at 1:35 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 1 Jul 2013, Ming Lei wrote: So I think we should unlink here to speed up the procedure as suggested in your previous email. You are right. If the QH's qtd_list isn't empty then we should WARN_ON and return without doing anything -- just leak the QH. Otherwise, Yes, we can add the WARN_ON() because caller should have unlinked all requests, but looks we can handle the unlink here too without obvious side-effect. Currently, URB might be probably submitted to HCD too even after usb_hcd_flush_endpoint() completes since both accesses to dev-ep_in[epnum] and ep-enabled aren't protected by effective locks. The urb_list_lock in hcd.c serves to synchronize changes to ep-enabled. An URB might be submitted after usb_hcd_flush_endpoint() completes, but the submission will fail in usb_hcd_link_urb_to_ep(). But the lock isn't held when setting and clearing ep-enabled in usb_enable_endpoint and usb_disable_endpoint, is it? Also looks there is the similar problem about 'dev-can_submit' usage too. So how about not adding the WARN_ON(!list_empty(qh-qtd_list) now when qh-qh_state is QH_STATE_LINKED? I think we should add the WARN_ON. Or jump to the default case in that switch statement -- maybe the error message there should include a WARN_ON. How about just adding WARN_ON(!list_empty(qh-qtd_list) but continue unlinking the qh like current code, which should be harmless and avoid the QH leak? Also I am not sure if we should return without doing anything under the situation, at least when the QH is in IDLE and QH's qtd_list isn't empty, ep-hcpriv is cleared, then return. The only way for a QH to be in the IDLE state with a non-empty qtd_list is if qh-clearing_tt is set. The code already checks for that. OK. Thanks, -- Ming Lei -- 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: How should we handle isochronous underruns?
On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern st...@rowland.harvard.edu wrote: Clement and Laurent: The two of you seem to be the people who make the most use of isochronous USB transfers. Since the ehci-hcd driver is being changed to use a tasklet for URB completion callbacks, it looks like I will need to reconsider how isochronous underruns get handled. Without using tasklet, the hard interrupt handler still can be delayed for some time, and switching to tasklet doesn't change the fact of the probable delay of URB handling. The basic prolem is simple enough: What should the HCD do when an URB is submitted after an isochronous pipeline has emptied out? I think some time-related data should be helpful for the discussion, for example, how long the isochronous pipeline may become empty in current audio/video driver(application) without any URB resubmit during the period? The problem will be more acute than in the past, because URB resubmissions will no longer be synchronous with URB completions, thanks to the tasklet. That is, in the current code, if the completion handler resubmits the URB, the resubmission occurs before the HCD finishes the completion callback. But in the new code, the HCD will simply hand the URB over to the tasklet, and the resubmission won't occur until some time later (when the tasklet wakes up and invokes the completion handler). As far as the HCD is concerned, the completion The delay should be very small(generally several microseconds) since isochronous URBs are completed in high priority tasklet. I don't think the introduced tasklet delay is a problem for EHCI since per EHCI spec the maximum rate at which the host controller will issue interrupts is one microframe(125us), which means isochronous transfer completion can be reported to CPU with about 125us delay in hardware level. will already be finished. Thus, for example, even if the pipeline contains only a single URB, with the current code it will not become empty. But with the new code it will. If the load on the system is too high, the pipeline could empty out even if it normally contains two or more URBs. Single URB may not work well too when running complete() in hard irq context. In UVC driver, looks it may submit at most 5 URBs which can include max 32 packets, so it will take about 5*32*125us(20ms) to make isoc pipeline empty suppose the interval is 1uF. But I don't know how USB audio driver uses URBs, and could it submit only one isoc URB to playback/record audio data? This means that the HCD will have trouble telling the difference between an underrun and a normal restart of a stopped I/O stream. In both cases it will see an URB being submitted to an empty queue. IMO, we should try to avoid the situation, and in UVC cases looks it is impossible to see an URB being submitted to an empty queue except for at the moment of starting streaming or interrupt disabled for extremely long. Here's where the URB_ISO_ASAP flag will be useful; if that flag is set then the URB is restarting a stopped stream, but if it isn't set then the pipeline experienced an underrun. Naturally, under normal circumstances this won't matter, because underruns shouldn't occur. But I know from experience that people try to push the latency as far down as they can, which increases the likelihood of underruns. There are several possible things the HCD could do when an underrun occurs: It could schedule the URB for the first time slot known to be available, even if that means skipping some time slots which the hardware might (or might not) be able to use. It could try to schedule the URB for the next time slot after the last one used by the preceding URB, even if that time slot has already expired. Something in between... What would be best for your purposes? Or do you have any different suggestions? 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 Thanks, -- Ming Lei -- 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] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0
Xhci controllers with hci_version 0.96 gives spurious success
events on short packet completion. During webcam capture the
ERROR Transfer event TRB DMA ptr not part of current TD was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same Issue is seen with Intel Pantherpoint xhci controller. So enabling
this quirk in xhci_gen_setup if controller verion is greater than 0.96.
For xhci-pci move the quirk to much generic place xhci_gen_setup.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/host/xhci-pci.c | 1 -
drivers/usb/host/xhci.c | 7 +++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index cc24e39..f00cb20 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -93,7 +93,6 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
}
if (pdev-vendor == PCI_VENDOR_ID_INTEL
pdev-device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
- xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
xhci-quirks |= XHCI_EP_LIMIT_QUIRK;
xhci-limit_active_eps = 64;
xhci-quirks |= XHCI_SW_BW_CHECKING;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d8f640b..0f7be59 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4697,6 +4697,13 @@ int xhci_gen_setup(struct usb_hcd *hcd,
xhci_get_quirks_t get_quirks)
get_quirks(dev, xhci);
+ /* In xhci controllers which follow xhci 1.0 spec gives a spurious
+* success event after a short transfer. This quirk will ignore such
+* spurious event.
+*/
+ if (xhci-hci_version 0x96)
+ xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
+
/* Make sure the HC is halted. */
retval = xhci_halt(xhci);
if (retval)
--
1.8.1.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
