- 18 8月, 2014 7 次提交
-
-
由 Greg KH 提交于
This adds a new device id to the pl2303 driver for the ZTEK device. Reported-by: NMike Chu <Mike-Chu@prolific.com.tw> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Add device id for Basic Micro ATOM Nano USB2Serial adapters. Reported-by: NNicolas Alt <n.alt@mytum.de> Tested-by: NNicolas Alt <n.alt@mytum.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Remove dublicate Qualcom PID 0x3197 which is already handled by the moto-modem driver since commit 6986a978 ("USB: add new moto_modem driver for some Morotola phones"). Fixes: 799ee924 ("USB: serial: add zte_ev.c driver") Cc: <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Remove dublicate Gobi PID 0x9008 which is already handled by the qcserial driver since commit f05932c0 ("USB: qcserial: Add extra device IDs"). Fixes: 799ee924 ("USB: serial: add zte_ev.c driver") Cc: <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
This reverts commit 73228a05 ("USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"). Move the IDs of the devices that were previously driven by the option driver back to that driver. As several users have reported, the zte_ev driver is causing random disconnects as well as reconnect failures. A closer analysis of the zte_ev setup code reveals that it consists of standard CDC requests (SET/GET_LINE_CODING and SET_CONTROL_LINE_STATE) but unfortunately fails to get some of those right. In particular, as reported by Liu Lei, it fails to lower DTR/RTS on close. It also appears that the control requests lack the interface argument. Note that the zte_ev driver is based on code (once) distributed by ZTE that still appears to originally have been reverse-engineered and bolted onto the generic driver. Since line control is already handled properly by the option driver, and the SET/GET_LINE_CODING requests appears to be redundant (amounts to a SET 9600 8N1), this is a first step in ultimately removing the redundant zte_ev driver. Note that AC2726 had already been moved back to option, and that some IDs were in the device table of both drivers prior to the commit being reverted. Reported-by: NLei Liu <liu.lei78@zte.com.cn> Cc: <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Brennan Ashton 提交于
This VIA Telecom baseband processor is used is used by by u-blox in both the FW2770 and FW2760 products and may be used in others as well. This patch has been tested on both of these modem versions. Signed-off-by: NBrennan Ashton <bashton@brennanashton.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Do not log normal interrupt-urb shutdowns as errors. The option driver has always been logging any nonzero interrupt-urb status as an error, including when the urb is killed during normal operation. Commit 9096f1fb ("USB: usb_wwan: fix potential NULL-deref at resume") moved the interrupt urb submission from port probe and release to open and close, thus potentially increasing the number of these false-positive error messages dramatically. Reported-by: NEd Butler <ressy66@ausics.net> Tested-by: NEd Butler <ressy66@ausics.net> Cc: <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 02 8月, 2014 10 次提交
-
-
由 Oliver Neukum 提交于
usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK for output URBs. That causes usbcore to log messages without limit for a nonsensical disallowed combination. The fix is to silently drop the attribute in usbfs. The problem is reported to exist since 3.14 https://www.virtualbox.org/ticket/13085Signed-off-by: NOliver Neukum <oneukum@suse.de> CC: stable@vger.kernel.org Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
So that an user who wants to use uas can see why he is not getting uas. Also move the check down so that we don't warn if there are other reasons why uas cannot work. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Don't complain about controllers without sg support if there are other reasons why uas cannot be used anyways. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
The 7023 product id is the generic product id for the Etron EJ168, it is not specific to the version found on the Asrock P67 motherboard. The same id is e.g. also used on Gigabyte motherboards and on no-name pci-e usb-3 addon cards. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Streams on the EJ168 do not work as they should. I've spend 2 days trying to get them to work, but without success. The first problem is that when ever you ring the stream-ring doorbell, the controller starts executing trbs at the beginning of the first ring segment, event if it ended somewhere else previously. This can be worked around by allowing enqueing only one td (not a problem with how streams are typically used) and then resetting our copies of the enqueueing en dequeueing pointers on a td completion to match what the controller seems to be doing. This way things seem to start working with uas and instead of being able to complete only the very first scsi command, the scsi core can probe the disk. But then things break later on when td-s get enqueued with more then one trb. The controller does seem to increase its dequeue pointer while executing a stream-ring (data transfer events I inserted for debugging do trigger). However execution seems to stop at the final normal trb of a multi trb td, even if there is a data transfer event inserted after the final trb. The first problem alone is a serious deviation from the spec, and esp. dealing with cancellation would have been very tricky if not outright impossible, but the second problem simply is a deal breaker altogether, so this patch simply disables streams. Note this will cause the usb-storage + uas driver pair to automatically switch to using usb-storage instead of uas on these devices, essentially reverting to the 3.14 and earlier behavior when uas was marked CONFIG_BROKEN. https://bugzilla.redhat.com/show_bug.cgi?id=1121288 https://bugzilla.kernel.org/show_bug.cgi?id=80101 Cc: stable@vger.kernel.org # 3.15 Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Some jmicron uas chipsets act up (they disconnect from the bus) when sending more then 32 commands to them at once. Rather then building an ever growing list with usb-id based quirks for devices using this chipset, simply reduce the qdepth to 32 when connected over usb-2. 32 should be plenty to keep things close to maximum possible throughput on usb-2. Cc: stable@vger.kernel.org Tested-and-reported-by: NLaszlo T. <tlacix@gmail.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 James P Michels III 提交于
This patch adds a usb quirk to support devices with interupt endpoints and bInterval values expressed as microframes. The quirk causes the parse endpoint function to modify the reported bInterval to a standards conforming value. There is currently code in the endpoint parser that checks for bIntervals that are outside of the valid range (1-16 for USB 2+ high speed and super speed interupt endpoints). In this case, the code assumes the bInterval is being reported in 1ms frames. As well, the correction is only applied if the original bInterval value is out of the 1-16 range. With this quirk applied to the device, the bInterval will be accurately adjusted from microframes to an exponent. Signed-off-by: NJames P Michels III <james.p.michels@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Patrick Riphagen 提交于
This adds support for new Xsens devices, using Xsens' own Vendor ID. Signed-off-by: NPatrick Riphagen <patrick.riphagen@xsens.com> Signed-off-by: NFrans Klaver <frans.klaver@xsens.com> Cc: Johan Hovold <johan@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Patrick Riphagen 提交于
The converters are used in specific products. It can be useful to know which they are exactly. Signed-off-by: NPatrick Riphagen <patrick.riphagen@xsens.com> Signed-off-by: NFrans Klaver <frans.klaver@xsens.com> Cc: Johan Hovold <johan@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 24 7月, 2014 1 次提交
-
-
由 Kristina Martšenko 提交于
The driver hasn't been fully cleaned up and it doesn't look like anyone is working on it anymore (including the original author). So remove the driver and all references to it. If someone wants to finish cleaning the driver up and moving it out of staging, this commit can be reverted. Signed-off-by: NKristina Martšenko <kristina.martsenko@gmail.com> Cc: Cho, Yu-Chen <acho@novell.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 23 7月, 2014 5 次提交
-
-
由 Wei Yongjun 提交于
Fixes the following sparse warnings: drivers/usb/chipidea/debug.c:211:5: warning: symbol 'ci_otg_show' was not declared. Should it be static? drivers/usb/chipidea/debug.c:334:5: warning: symbol 'ci_registers_show' was not declared. Should it be static? Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NPeter Chen <peter.chen@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Markus Pargmann 提交于
-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: NMarkus Pargmann <mpa@pengutronix.de> Signed-off-by: NPeter Chen <peter.chen@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Amit Virdi 提交于
Section 4.4.7.2 "Interrupt Transfer Bandwidth Requirements" of the USB3.0 spec says: A zero-length data payload is a valid transfer and may be useful for some implementations. So, extend the logic of allowing URB_ZERO_PACKET to interrupt urbs too. Otherwise, the kernel throws warning of BOGUS transfer flags. Signed-off-by: NAmit Virdi <amit.virdi@st.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Pratyush Anand 提交于
Following sparse warnings were reported by kbuild test bot drivers/usb/misc/lvstest.c:314:28: sparse: incorrect type in assignment (different base types) drivers/usb/misc/lvstest.c:314:28: expected unsigned short [unsigned] [usertype] portchange drivers/usb/misc/lvstest.c:314:28: got restricted __le16 [usertype] wPortChange drivers/usb/misc/lvstest.c:332:40: sparse: restricted __le16 degrades to integer This patch fixes above warnings. Reported-by: Nkbuild test robot <fengguang.wu@intel.com> Signed-off-by: NPratyush Anand <pratyush.anand@st.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jiang Liu 提交于
The assigned IRQ should be freed before calling pci_disable_device() when shutting down system, otherwise it will cause following warning. [ 568.879482] ------------[ cut here ]------------ [ 568.884236] WARNING: CPU: 1 PID: 3300 at /home/konrad/ssd/konrad/xtt-i386/bootstrap/linux-usb/fs/proc/generic.c:521 remove_proc_entry+0x165/0x170() [ 568.897846] remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'ohci_hcd:usb4' [ 568.907430] Modules linked in: dm_multipath dm_mod iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c_generic sg sd_mod crct10dif_generic crc_t10dif crct10dif_common radeon fbcon tileblit ttm font bitblit softcursor ata_generic ahci libahci drm_kms_helper skge r8169 libata mii scsi_mod wmi acpi_cpufreq [ 568.938539] CPU: 1 PID: 3300 Comm: init Tainted: G W 3.16.0-rc5upstream-01651-g03b9189 #1 [ 568.947946] Hardware name: ECS A780GM-A Ultra/A780GM-A Ultra, BIOS 080015 04/01/2010 [ 568.956008] 00000209 ed0f1cd0 c1617946 c175403c ed0f1d00 c1090c3f c1754084 ed0f1d2c [ 568.964068] 00000ce4 c175403c 00000209 c11f22a5 c11f22a5 f755e8c0 ed0f1d78 f755e90d [ 568.972128] ed0f1d18 c1090cde 00000009 ed0f1d10 c1754084 ed0f1d2c ed0f1d60 c11f22a5 [ 568.980194] Call Trace: [ 568.982715] [<c1617946>] dump_stack+0x48/0x60 [ 568.987294] [<c1090c3f>] warn_slowpath_common+0x7f/0xa0 [ 569.003887] [<c1090cde>] warn_slowpath_fmt+0x2e/0x30 [ 569.009092] [<c11f22a5>] remove_proc_entry+0x165/0x170 [ 569.014476] [<c10da6ca>] unregister_irq_proc+0xaa/0xc0 [ 569.019858] [<c10d582f>] free_desc+0x1f/0x60 [ 569.024346] [<c10d58aa>] irq_free_descs+0x3a/0x80 [ 569.029283] [<c10d9e9d>] irq_dispose_mapping+0x2d/0x50 [ 569.034666] [<c1078fd3>] mp_unmap_irq+0x73/0xa0 [ 569.039423] [<c107196b>] acpi_unregister_gsi_ioapic+0x2b/0x40 [ 569.045431] [<c107180f>] acpi_unregister_gsi+0xf/0x20 [ 569.050725] [<c1339cad>] acpi_pci_irq_disable+0x4b/0x50 [ 569.056196] [<c14daa38>] pcibios_disable_device+0x18/0x20 [ 569.061848] [<c130123d>] do_pci_disable_device+0x4d/0x60 [ 569.067410] [<c13012b7>] pci_disable_device+0x47/0xb0 [ 569.077814] [<c14800b1>] usb_hcd_pci_shutdown+0x31/0x40 [ 569.083285] [<c1304b19>] pci_device_shutdown+0x19/0x50 [ 569.088667] [<c13fda64>] device_shutdown+0x14/0x120 [ 569.093777] [<c10ac29d>] kernel_restart_prepare+0x2d/0x30 [ 569.099429] [<c10ac41e>] kernel_restart+0xe/0x60 [ 569.109028] [<c10ac611>] SYSC_reboot+0x191/0x220 [ 569.159269] [<c10ac6ba>] SyS_reboot+0x1a/0x20 [ 569.163843] [<c161c718>] sysenter_do_call+0x12/0x16 [ 569.168951] ---[ end trace ccc1ec4471c289c9 ]--- Tested-by: NAaron Lu <aaron.lu@intel.com> Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 7月, 2014 9 次提交
-
-
由 Alan Stern 提交于
This patch adds an extra check to ohci-hcd's I/O watchdog routine. If the controller stops updating the frame counter, we will assume it is dead. But there has to be an exception: Some controllers stop the frame counter when no ports are connected. Check to make sure there is at least one active port before deciding the controller is dead. (This test may appear racy, but it isn't. Enabling a newly connected port takes several milliseconds, during which time the frame counter must advance.) Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Tested-by: NDennis New <dennisn@dennisn.linuxd.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
Some OHCI controllers have a bug: They fail to add completed TDs to the done queue. Examining this queue is the only method ohci-hcd has for telling when a transfer is complete; failure to add a TD can result in an URB that never completes and cannot be unlinked. This patch adds a watchdog routine to ohci-hcd. The routine periodically scans the active ED and TD lists, looking for TDs which are finished but not on the done queue. When one is found, and it is certain that the controller hardware will never add the TD to the done queue, the watchdog routine manually puts the TD on the done list so that it can be handled normally. The watchdog routine also checks for a condition indicating the controller has died. If the done queue is non-empty but the HccaDoneHead pointer hasn't been updated for a few hundred milliseconds, we assume the controller will never update it and therefore is dead. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
URBs for a particular endpoint should complete sequentially. That is, we shouldn't call the completion handler for one URB until the handler for the previous URB has returned. When the OHCI watchdog routine is added, there will be two paths for completing URBs: interrupt handler and watchdog routine. Their activities have to be synchronized so that completions don't occur in multiple threads concurrently. For that purpose, this patch creates an ohci_work() routine which will be responsible for calling process_done_list() and finish_unlinks(), the two routines that detect when an URB is complete. Everything will funnel through ohci_work(), and it will be careful not to run in more than one thread at a time. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
This patch changes the way ohci-hcd handles the TD done list. In addition to relying on the TD pointers stored by the controller hardware, we need to handle TDs that the hardware has forgotten about. This means the list has to exist even while the dl_done_list() routine isn't running. That function essentially gets split in two: update_done_list() reads the TD pointers stored by the hardware and adds the TDs to the done list, and process_done_list() scans through the list to handle URB completions. When we detect a TD that the hardware forgot about, we will be able to add it to the done list manually and then process it normally. Since the list is really a queue, and because there can be a lot of TDs, keep the existing singly linked implementation. To insure that URBs are given back in order of submission, whenever a TD is added to the done list, all the preceding TDs for the same endpoint must be added as well (going back to the first one that isn't already on the done list). The done list manipulations must all be protected by the private lock. The scope of the lock is expanded in preparation for the watchdog routine to be added in a later patch. We have to be more careful about giving back unlinked URBs. Since TDs may be added to the done list by the watchdog routine and not in response to a controller interrupt, we have to check explicitly to make sure all the URB's TDs that were added to the done list have been processed before giving back the URB. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
When an URB is unlinked from a dead controller, ohci-hcd gives back the URB with no regard for cleaning up the internal data structures. This won't play nicely with the upcoming changes to the TD done list. Therefore make ohci_urb_dequeue() call finish_unlinks(), which uses td_done() to do a proper cleanup, rather than calling finish_urb() directly. Also, remove the checks that urb_priv is non-NULL; the driver guarantees that urb_priv will never be NULL for a valid URB. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
This patch reverts the important parts of commit 89a0fd18 (USB: OHCI handles more ZFMicro quirks), namely, the parts related to handling orphan TDs for interrupt endpoints. A later patch in this series will introduce a more general mechanism that applies to all endpoint types and all controllers. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Pratyush Anand 提交于
Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Cc: <stable@vger.kernel.org> Signed-off-by: NPratyush Anand <pratyush.anand@st.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Nicholas Krause 提交于
I am removing two fix mes in this file as after dicussing then it seems there is no reason to check against Null for usb_device as it can never be NULL and this is check is therefore not needed. Signed-off-by: NNicholas Krause <xerofoify@gmail.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oliver Neukum 提交于
Some laptops have an internal port for a BT device which picks up noise when the kill switch is used, but not enough to trigger printk_rlimit(). So we shouldn't log consecutive faults of this kind. Signed-off-by: NOliver Neukum <oneukum@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 18 7月, 2014 8 次提交
-
-
由 Gavin Guo 提交于
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 41e7e056 (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: 41e7e056 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by: NGavin Guo <gavin.guo@canonical.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Preston Fick 提交于
This `usb_reset_device` command has been around since the driver was originally reverse engineered. It doesn't cause much issue on single interface CP210x devices, but on the CP2105 and CP2108 with 2 and 4 interfaces respectively it will cause instability on enumeration and delays enumeration noticably. There should be no reason to reset a device at startup, per the CP210x AN571 spec. Signed-off-by: NPreston Fick <preston.fick@silabs.com> Cc: Johan Hovold <johan@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Pratyush Anand 提交于
OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification system (SS-OVS) which consists of an excersizer and analyzer. USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for Link Layer Validation (LVS). Some modifications are needed for an embedded Linux USB host to pass all these tests. Most of these tests require just Link to be in U0. They do not work with default Linux USB stack since, default stack does port reset and then starts sending setup packet, which is not expected by Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then, There are many Link Layer Tests which need host to generate specific traffic. This patch supports specific traffic generation cases. As of now all the host Lecroy Link Layer-USBIF tests (except TD7.26) passes with this patch for single run using Lecroy USB Compliance Suite Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80 Build 1603. Therefore patch seems to be a good candidate for inclusion. Further modification can be done on top of it. lvstest driver will not bind to any device by default. It can bind manually to a super speed USB host controller root hub. Therefore, regular hub driver must be unbound before this driver is bound. For example, if 2-0:1.0 is the xhci root hub, then execute following to unbind hub driver. echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind Then write Linux Foundation's vendor ID which is used by root hubs and SS root hub's device ID into new_id file. Writing IDs into new_id file will also bind the lvs driver with any available SS root hub interfaces. echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id Now connect LVS device with root hub port. Test case specific traffic can be generated as follows whenever needed: 1. To issue "Get Device descriptor" command for TD.7.06: echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc 2. To set U1 timeout to 127 for TD.7.18 echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout 3. To set U2 timeout to 0 for TD.7.18 echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout 4. To issue "Hot Reset" for TD.7.29 echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset 5. To issue "U3 Entry" for TD.7.35 echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry 6. To issue "U3 Exit" for TD.7.36 echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit Signed-off-by: NPratyush Anand <pratyush.anand@st.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Pratyush Anand 提交于
usb_alloc_dev is used by lvstest driver now which can be built as module. Therefore export usb_alloc_dev symbol. Signed-off-by: NPratyush Anand <pratyush.anand@st.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
This patch fixes a bug in ohci-hcd. When an URB is unlinked, the corresponding Endpoint Descriptor is added to the ed_rm_list and taken off the hardware schedule. Once the ED is no longer visible to the hardware, finish_unlinks() handles the URBs that were unlinked or have completed. If any URBs remain attached to the ED, the ED is added back to the hardware schedule -- but only if the controller is running. This fails when a controller dies. A non-empty ED does not get added back to the hardware schedule and does not remain on the ed_rm_list; ohci-hcd loses track of it. The remaining URBs cannot be unlinked, which causes the USB stack to hang. The patch changes finish_unlinks() so that non-empty EDs remain on the ed_rm_list if the controller isn't running. This requires moving some of the existing code around, to avoid modifying the ED's hardware fields more than once. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
The debug routine fill_async_buffer() in ohci-hcd is buggy: It never produces any output because it forgets to initialize the output buffer size. Also, the debug routine ohci_dump() has an unused argument. This patch adds the correct initialization and removes the unused argument. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
Apparently nobody ever remembered to add Scatter-Gather support to ohci-hcd. This patch adds it. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
When a host controller dies, we don't need to wait for a driver to time out. We can shut down its URBs immediately. Without this change, we can end up waiting 30 seconds for a mass-storage transfer to time out. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-