- 26 Sep, 2011 12 commits
-
-
Andiry Xu authored
This patch tests USB2 software LPM for a USB2 LPM-capable device. When a lpm-capable device is addressed, if the host also supports software LPM, apply a test by putting the device into L1 state and resume it to see if the device can do L1 suspend/resume successfully. If the device fails to enter L1 or resume from L1 state, it may not function normally and usbcore may disconnect and re-enumerate it. In this case, store the device's Vid and Pid information, make sure the host will not test LPM for it twice. The test result is per device/host. Some devices claim to be lpm-capable, but fail to enter L1 or resume. So the test is necessary. The xHCI 1.0 errata has modified the USB2.0 LPM implementation. It redefines the HIRD field to BESL, and adds another register Port Hardware LPM Control (PORTHLPMC). However, this should not affect the LPM behavior on xHC which does not implement 1.0 errata. USB2.0 LPM errata defines a new bit BESL in the device's USB 2.0 extension descriptor. If the device reports it uses BESL, driver should use BESL instead of HIRD for it. Signed-off-by:
Andiry Xu <andiry.xu@amd.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Andiry Xu authored
Check the host's USB2 LPM capability. USB2 software LPM support is optional for xHCI 0.96 hosts. xHCI 1.0 hosts should support software LPM, and may support hardware LPM. Signed-off-by:
-
Andiry Xu authored
When the link state changes, xHC will report a port status change event and set the PORT_PLC bit, for both USB3 and USB2 root hub ports. The PLC will be cleared by usbcore for USB3 root hub ports, but not for USB2 ports, because they do not report USB_PORT_STAT_C_LINK_STATE in wPortChange. Clear it for USB2 root hub ports in handle_port_status(). Signed-off-by:
-
Andiry Xu authored
Introduce xhci_test_and_clear_bit() to clear RWC bit in PORTSC register. Signed-off-by:
-
Andiry Xu authored
Introduce xhci_set_link_state() to remove redundant codes. Signed-off-by:
-
Andiry Xu authored
Check device's LPM capability by examining the bmAttibutes field of the USB2.0 Extension Descriptor. Signed-off-by:
-
Andiry Xu authored
This commit gets BOS(Binary Device Object Store) descriptor set for Super Speed devices and High Speed devices which support BOS descriptor. BOS descriptor is used to report additional USB device-level capabilities that are not reported via the Device descriptor. By getting BOS descriptor set, driver can check device's device-level capability such as LPM capability. Signed-off-by:
-
Shaun Silk authored
Signed-off-by:
Shaun Silk <g0del@bigpond.com> Signed-off-by:
-
Matthieu CASTET authored
This allow to clean duplicated code in most of SOC driver. Signed-off-by:
Matthieu CASTET <castet.matthieu@free.fr> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> # fixes 3.1 build error Signed-off-by:
-
Johannes Stezenbach authored
Report the number of dropped packets instead of zero when using the binary usbmon interface with tcpdump. # tcpdump -i usbmon1 -w dump tcpdump: listening on usbmon1, link-type USB_LINUX_MMAPPED (USB with padded Linux header), capture size 65535 bytes ^C2155 packets captured 2155 packets received by filter 1019 packets dropped by kernel Signed-off-by:
Johannes Stezenbach <js@sig21.net> Cc: stable <stable@kernel.org> Signed-off-by:
-
Felipe Balbi authored
We should not be using dev_get_drvdata() because we never call dev_set_drvdata(). Let's use container_of() as all other sysfs attributes. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Eric Benoit authored
Add vendor and product ID for the SMART USB to serial adapter. These were meant to be used with their SMART Board whiteboards, but can be re-purposed for other tasks. Tested and working (at at least 9600 bps). Signed-off-by:
Eric Benoit <eric@ecks.ca> Cc: stable <stable@kernel.org> Signed-off-by:
-
- 20 Sep, 2011 8 commits
-
-
Richard Hartmann authored
Simple patch to make qcserial recognize the USB id of the Sierra Wireless MC8355 which is based on the Gobi 3000 chip. Both UMTS and GPS work fine. Signed-off-by:
Richard Hartmann <richih.mailinglist@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Kautuk Consul authored
The seg argument to xhci_segment_free is never passed as NULL, so no need to check for this in xhci_segment_free. Signed-off-by:
Kautuk Consul <consul.kautuk@gmail.com> Signed-off-by:
-
Kautuk Consul authored
There are 2 situations wherein the xhci_ring* might not get freed: - When xhci_ring_alloc() -> xhci_segment_alloc() returns NULL and we goto the fail: label in xhci_ring_alloc. In this case, the ring will not get kfreed. - When the num_segs argument to xhci_ring_alloc is passed as 0 and we try to free the rung after that. ( This doesn't really happen as of now in the code but we seem to be entertaining num_segs=0 in xhci_ring_alloc ) This should be backported to kernels as old as 2.6.31. Signed-off-by: -
Sarah Sharp authored
When a hot reset (standard USB port reset) fails on a USB 3.0 port, the host controller transitions to the "Error" state. It reports the port link state as "Inactive", sets the link state change flag, and (if the device disconnects) also reports the disconnect and connect change status. It's also supposed to transition the link state to "RxDetect", but the NEC µPD720200 xHCI host does not. Unfortunately, Harald found that the combination of the NEC µPD720200 and a LogiLink USB 3.0 to SATA adapter triggered this issue. The USB core would reset the device, the port would go into this error state, and the device would never be enumerated. This combination works under Windows, but not under Linux. When a hot reset fails on a USB 3.0 port, and the link state is reported as Inactive, fall back to a warm port reset instead. Harald confirms that with a warm port reset (along with all the change bits being correctly cleared), the USB 3.0 device will successfully enumerate. Harald also had to add two other patches ("xhci: Set change bit when warm reset change is set." and "usbcore: refine warm reset logic") to make this setup work. Since the warm reset refinement patch is not destined for the stable kernels (it's too big), this patch should not be backported either. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=41752Signed-off-by:Harald Brennich <harald.brennich@gmx.de> Signed-off-by:
-
Sarah Sharp authored
The Intel Panther Point xHCI host tracks SuperSpeed endpoints in a different way than USB 2.0/1.1 endpoints. The bandwidth interval tables are not used, and instead the bandwidth is calculated in a very simple way. Bandwidth for SuperSpeed endpoints is tracked individually in each direction, since each direction has the full USB 3.0 bandwidth available. 10% of the bus bandwidth is reserved for non-periodic transfers. This checking would be more complex if we had USB 3.0 LPM enabled, because an additional latency for isochronous ping times need to be taken into account. However, we don't have USB 3.0 LPM support in Linux yet. Signed-off-by:
-
Sarah Sharp authored
The "Mult" bits in the SuperSpeed Endpoint Companion Descriptor are zero-based, and the xHCI host controller wants them to be zero-based in the input context. However, for the bandwidth math, we want them to be one-based. Fix this. Fix the documentation about the endpoint bandwidth mult variable in the xhci.h file, which says it is zero-based. Also fix the documentation about num_packets, which is also one-based, not zero-based. Signed-off-by:
-
Andiry Xu authored
Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by:
-
Sebastian Andrzej Siewior authored
instead of reading the xhci interface version each time _even_ if the quirk is not required, simply check if the quirk flag is set. This flag is only set of the module parameter is set and here is where I moved the version check to. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
- 18 Sep, 2011 18 commits
-
-
edwin_rong authored
After auto-delink command is triggered, the CSW won't be sent back to host side, in which scenario, the USB Mass Storage driver will wait for the completion of the URB for MAX_SCHEDULE_TIMEOUT. Signed-off-by:
edwin_rong <edwin_rong@realsil.com.cn> Signed-off-by:
-
Oliver Neukum authored
The new runtime PM code has shown that many webcams suffer from a race condition that may crash them upon resume. Runtime PM is especially prone to show the problem because it retains power to the cameras at all times. However system suspension may also crash the devices and retain power to the devices. The only way to solve this problem without races is in usbcore with the RESET_RESUME quirk. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
stable <stable@kernel.org> Signed-off-by:
-
Alan Stern authored
This patch (as1484) adds documentation for ehci-hcd's "companion" sysfs attribute, which was added to the kernel over four years ago but never documented. Signed-off-by:
-
git://gitorious.org/usb/usbGreg Kroah-Hartman authored
* 'for-next' of git://gitorious.org/usb/usb: (47 commits) usb: musb: Enable DMA mode1 RX for transfers without short packets usb: musb: fix build breakage usb: gadget: audio: queue wLength-sized requests usb: gadget: audio: actually support both speeds usb: gadget: storage: make FSG_NUM_BUFFERS variable size USB: gadget: storage: remove alignment assumption usb: gadget: storage: adapt logic block size to bound block devices usb: dwc3: gadget: improve debug on link state change usb: dwc3: omap: set idle and standby modes usb: dwc3: ep0: introduce ep0_expect_in flag usb: dwc3: ep0: giveback requests on stall_and_restart usb: dwc3: gadget: drop the useless dma_sync_single* calls usb: dwc3: gadget: fix GCTL programming usb: dwc3: define ScaleDown macro helper usb: dwc3: Fix definition of DWC3_GCTL_U2RSTECN usb: dwc3: gadget: do not map/unmap ZLP transfers usb: dwc3: omap: fix IRQ handling usb: dwc3: omap: change IRQ name to dwc3-omap usb: dwc3: add module.h to dwc3-omap.c and core.c usb: dwc3: omap: distinguish between SW and HW modes ...
-
Yong Zhang authored
This flag is a NOOP and can be removed now. Signed-off-by:
Yong Zhang <yong.zhang0@gmail.com> Signed-off-by:
-
Ming Lei authored
According to ehci spec 4.10.2, Advance Queue If the fetched qTD has its Active bit set to a zero, the host controller aborts the queue advance and follows the queue head's horizontal pointer to the next schedule data structure. the 'qtd' will be linked into qh hardware queue after the line below *dummy = *qtd; is executed and observed by EHCI HC, but EHCI HC won't have chance to fetch the qtd descriptor pointed by 'qtd' in qh_append_tds until the line below dummy->hw_token = token; #set Active bit here is executed by CPU and observed by EHCI HC. There is already one 'wmb' to order writing to 'dummy'/'qtd' descriptors and writing 'token' to 'dummy' descriptor(set Active bit), so the 1st wmb is not needed and can be removed. Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
-
Ming Lei authored
EHCI_SHRINK_JIFFIES should be 5ms, which was just used originally, and not 200ms, so fix it. Signed-off-by:
-
Ming Lei authored
Obviously, ZLP is only required for transfer of OUT direction, so just take same policy with UHCI for ZLP packet. Signed-off-by:
-
Ming Lei authored
qh_refresh is always called when the qh is idle and has not been linked into hardware queue, so EHCI will not access overlay of the qh at this time. Just before linking qh into hardware queue, there has already one wmb to order writing qh descriptor and writing dma address of the qh into hardware queue, so HC can always see up-to-date qh descriptor once the qh is fetched with its dma address by EHCI. Signed-off-by:
-
Denis Pershin authored
here is the patch to support Owen SI-30 device. This is a pulse counter controller. http://www.owen.ru/en/catalog/93788515 usb-drivers output: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=03eb ProdID=0030 Rev=01.01 C: #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=00 Driver=cdc_acm I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm This patch is installed on my home system which receives data from this controller connected to cold water counter. Signed-off-by:
Denis Pershin <dyp@perchine.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Vincent Palatin authored
A typo in the configuration variable name prevents from activating the USB autosuspend on the device. Signed-off-by:
Vincent Palatin <vpalatin@chromium.org> Cc: stable <stable@kernel.org> Signed-off-by:
-
Fabian Godehardt authored
The allocated chardevice region range is only 1 device but on unregister it currently tries to deregister 2. Found this while doing a insmod/rmmod/insmod/rm... of the module which seemed to eat major numbers. Signed-off-by:
Fabian Godehardt <fg@emlix.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Heiko Stübner authored
When a transceiver is available use otg_set_power to submit the target current to it. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Michal Nazarewicz authored
In a few places in the kernel, the code prints a human-readable USB device speed (eg. "high speed"). This involves a switch statement sometimes wrapped around in ({ ... }) block leading to code repetition. To mitigate this issue, this commit introduces usb_speed_string() function, which returns a human-readable name of provided speed. It also changes a few places switch was used to use this new function. This changes a bit the way the speed is printed in few instances at the same time standardising it. Signed-off-by:Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
-
Dan Williams authored
IDs found in the Windows driver's ZTEusbnet.inf file from the ZTE MF100 drivers (O2 UK). Also fixes the ZTE MF626 device since it really is distinct from the 4G Systems stick and apparently needs the net interface blacklisted too, while there's no indication (yet) that the 4G Systems stick does. Signed-off-by:
Dan Williams <dcbw@redhat.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
That's what the blacklist is for... Signed-off-by:
-
Dan Williams authored
It's cleaner than the array stuff, and we're about to add a bunch more blacklist entries. Second, there are devices that need both the sendsetup and the reserved interface blacklists, which the current code can't accommodate. Signed-off-by:
-
- 09 Sep, 2011 2 commits
-
-
Klaus Schwarzkopf authored
remove the following two paragraphs as they are not needed: This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc.,59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. Signed-off-by:
Klaus Schwarzkopf <schwarzkopf@sensortherm.de> Signed-off-by:
-
Hans Petter Selasky authored
There is a multi-year old bug in the MUSB hardware which is not documented. It causes spurious interrupts and have various symptoms, like endless "SetupEnd came in a wrong ep0stage" messages. The fix is taken from the FreeBSD's musb driver. How to reproduce: For example issue clear-stall on a couple of endpoints very fast, like one request per 125us. After a while the bug triggers and the musb-chip becomes unusable until next re-enumeration. Signed-off-by:
Hans Petter Selasky <hps@bitfrost.no> Signed-off-by:
-
