- 22 Oct, 2010 40 commits
-
-
Eric Bénard authored
this patch gives the possibility to workaround bug ENGcm09152 on i.MX35 when the hardware workaround is also implemented on the board. It covers the workaround described on page 25 of the following Errata : http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdfSigned-off-by:
Eric Bénard <eric@eukrea.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
This adds the requested device ids to the ftdi_sio driver. Reported-by:
Ewan Bingham <ewan@auc.co.uk> Cc: Kuba Ober <kuba@mareimbrium.org> Cc: stable <stable@kernel.org> Signed-off-by:
-
Ajay Kumar Gupta authored
AM35x supports only 32bit read operations so we need to have workaround for 8bit and 16bit read operations. Signed-off-by:
Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Ajay Kumar Gupta authored
AM35x has musb interface and uses CPPI4.1 DMA engine. Current patch supports only PIO mode. DMA support can be added later once basic CPPI4.1 DMA patch is accepted. Also added USB_MUSB_AM35X which is required to differentiate musb ips between OMAP3x and AM35x. This config would be used to for below purposes, - Select am35x.c instead of omap2430.c for compilation at drivers/usb/musb directory. Please note there are significant differneces in these two files as musb ip in quite different on AM35x. Please note that in multi omap configuration only omap2430.c file will get compiled and we would require to select only AM35x based board config to compile am35x.c - Select workaround codes applicable for AM35x musb issues. one such workaround is for bytewise read issue on AM35x. Signed-off-by: -
Ajay Kumar Gupta authored
AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine. It has USB phy built inside the IP itself. Signed-off-by:
Tony Lindgren <tony@atomide.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux-omap@vger.kernel.org Signed-off-by:
-
Sarah Sharp authored
Fix these linker errors when CONFIG_PM=n: ERROR: "xhci_bus_resume" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "xhci_bus_suspend" [drivers/usb/host/xhci-hcd.ko] undefined! Reported-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by:
-
Axel Lin authored
Signed-off-by:
Axel Lin <axel.lin@gmail.com> Acked-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Axel Lin authored
Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Axel Lin authored
Signed-off-by:
-
Sarah Sharp authored
Fix this error when CONFIG_PM is not enabled: drivers/usb/host/xhci.c:675: error: implicit declaration of function 'usb_root_hub_lost_power' Wrap xhci_suspend() and xhci_resume() into an ifdef CONFIG_PM, along with the functions that only they call -- xhci_save_registers() and xhci_restore_registers(). Reported-by:
-
Alan Stern authored
A few devices (such as the RCA VR5220 voice recorder) are so non-compliant with the USB spec that they have invalid maxpacket sizes for endpoint 0. Nevertheless, as long as we can safely use them, we may as well do so. This patch (as1432) softens our acceptance criterion by allowing high-speed devices to have ep0-maxpacket sizes other than 64. A warning is printed in the system log when this happens, and the existing error message is clarified. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
James <bjlockie@lockie.ca> Cc: stable <stable@kernel.org> Signed-off-by:
-
Andiry Xu authored
This patch implements the PCI suspend/resume. Please refer to xHCI spec for doing the suspend/resume operation. For S3, CSS/SRS in USBCMD is used to save/restore the internal state. However, an error maybe occurs while restoring the internal state. In this case, it means that HC internal state is wrong and HC will be re-initialized. Signed-off-by:
Libin Yang <libin.yang@amd.com> Signed-off-by:
Dong Nguyen <dong.nguyen@amd.com> Signed-off-by:
Andiry Xu <andiry.xu@amd.com> Signed-off-by:
-
Andiry Xu authored
This patch implements xHCI bus suspend/resume function hook. In the patch it goes through all the ports and suspend/resume the ports if needed. If any port is in remote wakeup, abort bus suspend as what ehci/ohci do. Signed-off-by:
Crane Cai <crane.cai@amd.com> Signed-off-by:
-
Andiry Xu authored
This commit implements port remote wakeup. When a port is in U3 state and resume signaling is detected from a device, the port transitions to the Resume state, and the xHC generates a Port Status Change Event. For USB3 port, software write a '0' to the PLS field to complete the resume signaling. For USB2 port, the resume should be signaling for at least 20ms, irq handler set a timer for port remote wakeup, and then finishes process in hub_control GetPortStatus. Some codes are borrowed from EHCI code. Signed-off-by:
-
Andiry Xu authored
Add software trigger USB device suspend resume function hook. Do port suspend & resume in terms of xHCI spec. Port Suspend: Stop all endpoints via Stop Endpoint Command with Suspend (SP) flag set. Place individual ports into suspend mode by writing '3' for Port Link State (PLS) field into PORTSC register. This can only be done when the port is in Enabled state. When writing, the Port Link State Write Strobe (LWS) bit shall be set to '1'. Allocate an xhci_command and stash it in xhci_virt_device to wait completion for the last Stop Endpoint Command. Use the Suspend bit in TRB to indicate the Stop Endpoint Command is for port suspend. Based on Sarah's suggestion. Port Resume: Write '0' in PLS field, device will transition to running state. Ring an endpoints' doorbell to restart it. Ref: USB device remote wake need another patch to implement. For details of how USB subsystem do power management, please see: Documentation/usb/power-management.txt Signed-off-by: -
Sarah Sharp authored
When the system suspends and a host controller's power is lost, the USB core attempts to revive any USB devices that had the persist_enabled flag set. For non-SuperSpeed devices, it will disable the port, and then set the udev->reset_resume flag. This will cause the USB core to reset the device, verify the device descriptors to make sure it's the same device, and re-install any non-default configurations or alternate interface settings. However, we can't disable SuperSpeed root hub ports because that turns off SuperSpeed terminations, which will inhibit any devices connecting at USB 3.0 speeds. (Plus external hubs don't allow SuperSpeed ports to be disabled.) Because of this logic in hub_activate(): /* We can forget about a "removed" device when there's a * physical disconnect or the connect status changes. */ if (!(portstatus & USB_PORT_STAT_CONNECTION) || (portchange & USB_PORT_STAT_C_CONNECTION)) clear_bit(port1, hub->removed_bits); if (!udev || udev->state == USB_STATE_NOTATTACHED) { /* Tell khubd to disconnect the device or * check for a new connection */ if (udev || (portstatus & USB_PORT_STAT_CONNECTION)) set_bit(port1, hub->change_bits); } else if (portstatus & USB_PORT_STAT_ENABLE) { /* The power session apparently survived the resume. * If there was an overcurrent or suspend change * (i.e., remote wakeup request), have khubd * take care of it. */ if (portchange) set_bit(port1, hub->change_bits); } else if (udev->persist_enabled) { udev->reset_resume = 1; set_bit(port1, hub->change_bits); } else { /* The power session is gone; tell khubd */ usb_set_device_state(udev, USB_STATE_NOTATTACHED); set_bit(port1, hub->change_bits); } a SuperSpeed device after a resume with a loss of power will never get the reset_resume flag set. Instead the core will assume the power session survived and that the device still has the same address, configuration, and alternate interface settings. The xHCI host controller will have no knowledge of the device (since all xhci_virt_devices were destroyed when power loss was discovered, and xhci_discover_or_reset_device() has not been called), and all URBs to the device will fail. If the device driver responds by resetting the device, everything will continue smoothly. However, if lsusb is used before the device driver resets the device (or there is no driver), then all lsusb descriptor fetches will fail. The quick fix is to pretend the port is disabled in hub_activate(), by clearing the local variable. But I'm not sure what other parts of the hub driver need to be changed because they have assumptions about when ports will be disabled. Signed-off-by: -
Andiry Xu authored
xHCI driver uses hardware assigned device address. This may cause device address conflict in certain cases. Use kernel assigned address for devices under xHCI. Store the xHC assigned address locally in xHCI driver. Signed-off-by:
-
Andiry Xu authored
Rename xhci_reset_device() to xhci_discover_or_reset_device(). If xhci_discover_or_reset_device() is called to reset a device which does not exist or does not match the udev, it calls xhci_alloc_dev() to re-allocate the device. This would prevent the reset device failure, possibly due to the xHC restore error during S3/S4 resume. Signed-off-by:
-
Andiry Xu authored
Add a pointer to udev in struct xhci_virt_device. When allocate a new virt_device, make the pointer point to the corresponding udev. Modify xhci_check_args(), check if virt_dev->udev matches the target udev, to make sure command is issued to the right device. Signed-off-by:
-
Nobuhiro Iwamatsu authored
Some functions changed by 1c98347e. However, There was a change mistake of the function (outsw). Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> CC: Paul Mundt <lethal@linux-sh.org> Cc: stable <stable@kernel.org> [.35 & .36] Acked-by:
-
Igor Grinberg authored
Extend id's table to have ulpi phy names in it. Report if the known phy is found. Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
-
Igor Grinberg authored
Improve ulpi phy detection by utilizing the "scratch" register. Allow unknown ulpi phy work without the need to hard-code the id. Signed-off-by:
-
Alon Ziv authored
Signed-off-by:
Alon Ziv <alon-git@nolaviz.org> Signed-off-by:
-
Alon Ziv authored
OPN2001 expects write operations to arrive as a vendor-specific command through the control pipe (instead of using a separate bulk-out pipe). Signed-off-by:
-
Alon Ziv authored
The bulk-read callback had two bugs: a) The bulk-in packet's leading two zeros were returned (and the two last bytes truncated) b) The wrong URB was transmitted for the second (and later) read requests, causing further reads to return the entire packet (including leading zeros) Signed-off-by:
-
Johan Hovold authored
No need to set latency timeout at every open. This also fixes an issue with the read latency being as high as 250ms (instead of 1ms) for the first read after port probe. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Kees Cook authored
If the iowarrior devices in this case statement support more than 8 bytes per report, it is possible to write past the end of a kernel heap allocation. This will probably never be possible, but change the allocation to be more defensive anyway. Signed-off-by:
Kees Cook <kees.cook@canonical.com> Signed-off-by:
-
Johan Hovold authored
Fix regression introduced by commit 214916f2 (USB: visor: reimplement using generic framework) which broke initialisation of UX50/TH55 devices that used re-mapped bulk-out endpoint addresses. Reported-by:
Robert Gadsdon <rgadsdon@bayarea.net> Tested-by:
-
Daniel Suchy authored
This patch for FTDI USB serial driver ads new VID/PIDs used on various devices manufactured by Papouch (http://www.papouch.com). These devices have their own VID/PID, although they're using standard FTDI chip. In ftdi_sio.c, I also made small cleanup to have declarations for all Papouch devices together. Signed-off-by:
Daniel Suchy <danny@danysek.cz> Cc: stable <stable@kernel.org> Signed-off-by:
-
Tatyana Brokhman authored
Adding SuperSpeed usb definitions as defined by ch9 of the USB3.0 spec. This patch is a preparation for adding SuperSpeed support to the gadget framework. Signed-off-by:
Tatyana Brokhman <tlinder@codeaurora.org> Signed-off-by:
-
Michal Nazarewicz authored
This commit changes storage_common.h, file_storage.c and f_mass_storage.c to use definitions of SCSI commands from scsi/scsi.h file instead of redefining the commands in storage_common.c. scsi/scsi.h header file was missing READ_FORMAT_CAPACITIES and READ_HEADER so this commit also add those to the header. Signed-off-by:
Michal Nazarewicz <mina86@mina86.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
matt mooney authored
For all modules, change <module>-objs to <module>-y; remove if-statements and replace with lists using the kbuild idiom; move flags to the top of the file; and fix alignment while trying to maintain the original scheme in each file. None of the dependencies are modified. Signed-off-by:
matt mooney <mfm@muteddisk.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
Rahul Ruikar authored
In function dummy_udc_probe() call put_device() when device_register() fails. also usb_get_hcd() put before device_register() after review comment from Alan Stern. Signed-off-by:
Rahul Ruikar <rahul.ruikar@gmail.com> Signed-off-by:
-
Rahul Ruikar authored
In function usb_create_ep_devs() call put_device() when device_register() fails. Signed-off-by:
-
Anders Larsen authored
The WAGO 750-923 USB Service Cable is used for configuration and firmware updates of several industrial automation products from WAGO Kontakttechnik GmbH. Bus 004 Device 002: ID 1be3:07a6 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1be3 idProduct 0x07a6 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 WAGO USB Service Cable iSerial 3 1277796751 . . . Signed-off-by:
Anders Larsen <al@alarsen.net> Cc: stable <stable@kernel.org> Signed-off-by:
-
Peter Chen authored
At otg device mode, the otg host resume should do no-op during system resume, otherwise, the otg device will be treated as a host for enumeration. So, the otg host driver returns -ESHUTDOWN if it detects the current usb mode is device mode. The host driver has to return -ESHUTDOWN, otherwise, the usb_hc_died will be called. Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Hans de Goede authored
Some Rockbox based mp4 players will crash when ever they see a read_capacity_16 scsi command. So add a new US_FL which tells the scsi sd driver to not issue any read_capacity_16 scsi commands. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Hans de Goede authored
I seem to have a knack for digging up buggy usb devices which don't work with Linux, and I'm crazy enough to try to make them work. So this time a friend of mine asked me to get an mp4 player (an mp3 player which can play videos on a small screen) to work with Linux. It is based on the well known rockbox chipset for which we already have an unusual devs entries to work around some of its bugs. But this model comes with an additional twist. This model chokes on read_capacity_16 calls. Now normally we don't make those calls, but this model comes with an sdcard slot and when there is no card in there (and shipped from the factory there is none), it reports a size of 0. However this time the programmers actually got the read_capacity_10 response right! So they substract one from the size as stored internally in the mp3 player before reporting it back, resulting in an answer of ... 0xffffffff sectors, causing sd.c to try a read_capacity_16, on which the device crashes. This patch adds a flag to scsi_device to indicate that a a device cannot handle read_capacity_16, and when this flag is set if a device reports an lba of 0xffffffff as answer to a read_capacity_10, assumes it tries to report a size of 0. Signed-off-by:
-
Hans de Goede authored
Appotech ax3003 (the larger brother of the ax203) based devices are even more buggy then the ax203. They will go of into lala land when ever they see a READ_DISC_INFO scsi command. So add a new US_FL which tells the scsi sr driver to not issue any READ_DISC_INFO scsi commands. [akpm@linux-foundation.org: fix build] Signed-off-by:
-
Hans de Goede authored
Some USB devices emulate a usb-mass-storage attached (scsi) cdrom device, usually this fake cdrom contains the windows software for the device. While working on supporting Appotech ax3003 based photoframes, which do this I discovered that they will go of into lala land when ever they see a READ_DISC_INFO scsi command. Thus this patch adds a scsi_device flag (which can then be set by the usb-storage driver through an unsual-devs entry), to indicate this, and makes the sr driver honor this flag. I know this sucks, but as discussed on linux-scsi list there is no other way to make this device work properly. Looking at usb traces made under windows, windows never sends a READ_DISC_INFO during normal interactions with a usb cdrom device. So as this cdrom emulation thingie becomes more common we might see more of this problem. Signed-off-by:
-
