- 11 Dec, 2009 40 commits
-
-
H Hartley Sweeten authored
Quiet the following sparse noise: warning: Using plain integer as NULL pointer Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Zhang Le authored
Add D-Link DWM-162-U5 device id 1e0e:ce16 into option driver. The device has 4 interfaces, of which 1 is handled by storage and the other 3 by option driver. The device appears first as CD-only 05c6:2100 device and must be switched to 1e0e:ce16 mode either by using "eject CD" or usb_modeswitch. The MessageContent for usb_modeswitch.conf is: "55534243e0c26a85000000000000061b000000020000000000000000000000" Signed-off-by:
Zhang Le <r0bertz@gentoo.org> Signed-off-by:
-
bart.hartgers@gmail.com authored
Signed-off-by:
Bart Hartgers <bart.hartgers@gmail.com> Cc: Mike McCormack <mikem@ring3k.org> Signed-off-by:
-
bart.hartgers@gmail.com authored
Signed-off-by:
-
bart.hartgers@gmail.com authored
Signed-off-by:
-
bart.hartgers@gmail.com authored
Signed-off-by:
-
bart.hartgers@gmail.com authored
Signed-off-by:
-
bart.hartgers@gmail.com authored
Signed-off-by:
-
Russ Dill authored
USB drivers that create character devices call usb_register_dev in their probe function. This associates the usb_interface device with that minor number and creates the character device and announces it to the world. However, the driver's probe function is called before the new usb_interface is added to the driver's klist_devices. This is a problem because userspace will respond to the character device creation announcement by opening the character device. The driver's open function will the call usb_find_interface to find the usb_interface associated with that minor number. usb_find_interface will walk the driver's list of devices and find the usb_interface with the matching minor number. Because the announcement happens before the usb_interface is added to the driver's klist_devices, a race condition exists. A straightforward fix is to walk the list of devices on usb_bus_type instead since the device is added to that list before the announcement occurs. bus_find_device calls get_device to bump the reference count on the found device. It is arguable that the reference count should be dropped by the caller of usb_find_interface instead of usb_find_interface, however, the current users of usb_find_interface do not expect this. Signed-off-by:
Russ Dill <Russ.Dill@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Roel Kluin authored
istl_flip is a signed bitfield of one bit so it can be -1 or 0. However in drivers/usb/host/isp1362-hcd.c:1103: finish_iso_transfers(isp1362_hcd, &isp1362_hcd->istl_queue[isp1362_hcd->istl_flip]); So if isp1362_hcd->istl_flip is set, the 2nd argument becomes &isp1362_hcd->istl_queue[-1], which is invalid. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Acked-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Nathaniel McCallum authored
This patch fixes a bug when incrementing/decrementing on a BCD formatted integer (i.e. 0x09++ should be 0x10 not 0x0A). It just adds a function for incrementing/decrementing BCD integers by converting to decimal, doing the increment/decrement and then converting back to BCD. Signed-off-by:
Nathaniel McCallum <nathaniel@natemccallum.com> Signed-off-by:
-
Nathaniel McCallum authored
The current code to generate usb modaliases from usb_device_id assumes that the device's bcdDevice descriptor will actually be in BCD format. While this should be a sane assumption, some devices don't follow spec and just use plain old hex. This causes drivers for these devices to generate invalid modalias lines which will never actually match for the hardware. The following patch adds hex support for bcdDevice in file2alias.c by detecting when a driver uses a hex formatted bcdDevice_(lo|hi) and adjusts the output to hex format accordingly. Drivers for devices which have bcdDevice conforming to BCD will have no change in modalias output. Drivers for devices which don't conform (i.e. ibmcam) should now generate valid modaliases. EXAMPLE OUTPUT (ibmcam; space added to highlight change) Old: usb:v0545p800D d030[10-9] dc*dsc*dp*ic*isc*ip* New: usb:v0545p800D d030a dc*dsc*dp*ic*isc*ip* Signed-off-by: -
Adrian Taylor authored
Nokia S60 phones expose two ACM channels. The first is a modem and is picked up by the standard AT-command interface information in the CDC-ACM driver. The second is marked as having a vendor-specific protocol. Normally, we don't expose those as ttys. (On some other devices, they may be claimed by the rndis_host driver and used as a network interface). But on S60 this second ACM channel is the way that third-party S60 application developers are expected to communicate over USB. It acts as a serial device at the S60 end, and so it should on Linux too. The list of devices is largely derived from: http://wiki.forum.nokia.com/index.php/S60_Platform_and_device_identification_codes http://wiki.forum.nokia.com/index.php/Nokia_USB_Product_IDs and includes only the S60 3rd Edition+ devices documented there. There are many devices for which the USB device ID is not documented, including: Nokia 6290 Nokia E63 Nokia 5630 XpressMusic Nokia 5730 XpressMusic Nokia 6710 Navigator Nokia 6720 classic Nokia 6730 Classic Nokia 6760 slide Nokia 6790 slide Nokia 6790 Surge Nokia E52 Nokia E55 Nokia E71x (AT&T) Nokia E72 Nokia E75 Nokia E75 US+LTA variant Nokia N79 Nokia N86 8MP Nokia 5230 (RM-588) Nokia 5230 (RM-594) Nokia 5530 XpressMusic Nokia 5530 XpressMusic (china) Nokia 5800 XM Nokia N97 (RM-506) Nokia N97 mini Nokia X6 It would be good to add those subsequently. Signed-off-by:
Adrian Taylor <aat@realvnc.com> Acked-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Larry Finger authored
In map_urb_for_dma(), the DMA address returned by dma_map_single() is not checked to determine if it is legal. This lack of checking contributed to a problem with the libertas wireless driver (http://marc.info/?l=linux-wireless&m=125695331205062&w=2). The difficulty was not detected until the buffer was unmapped. By this time memory corruption had occurred. The situation is fixed by testing the returned DMA address, and returning -EAGAIN if the address is invalid. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Anand Gadiyar authored
usb: ehci: Allow EHCI to be built on OMAP3 OMAP3 chips have a built-in EHCI controller. The recently introduced omap ehci-hcd driver missed out on selecting USB_ARCH_HAS_EHCI in Kconfig. Without this, the driver cannot be built. Signed-off-by:
Anand Gadiyar <gadiyar@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Ajay Kumar Gupta <ajay.gupta@ti.com> Acked-by:
Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by:
-
Alan Stern authored
This patch (as1301) adds support to usbmon for scatter-gather URBs. The text interface looks at only the first scatterlist element, since it never copies more than 32 bytes of data anyway. The binary interface copies as much data as possible up to the first non-addressable buffer. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Alan Stern authored
This patch (as1300) adds native scatter-gather support to ehci-hcd. Signed-off-by:
-
Elina Pasheva authored
This patch deals with reducing the memory footprint for sierra driver. This optimization is aimed for embedded software customers. Some sierra modems can expose upwards of 7 USB interfaces, each possibly offering different services. In general, interfaces used for the exchange of wireless data require much higher throughput, hence require more memory (i.e. more URBs) than lower performance interfaces. URBs used for the IN direction are pre-allocated by the driver and this patch introduces a way to configure the number of IN URBs allocated on a per-interface basis. Interfaces with lower throughput requirements receive fewer URBs, thereby reducing the RAM memory consumed by the driver. NOTE1: This driver has always pre-allocated URBs for the IN direction. NOTE2: The number of URBs pre-allocated for the low-performance interfaces has already been extensively tested in previous versions of this driver. We also added the capability to log function calls by adding DEBUG flag. Please note that this flag is commented out because this is the default state for it. Signed-off-by:
Elina Pasheva <epasheva@sierrawireless.com> Signed-off-by:
-
Michal Nazarewicz authored
Without Interface Association Descriptor, the CDC serial and RNDIS functions did not work correctly when added to a composite gadget with other functions. This is because, it defined two interfaces and some hosts tried to treat each interface separatelly. Signed-off-by:
Michal Nazarewicz <m.nazarewicz@samsung.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Michal Nazarewicz authored
Moved code initialising fsg_common structure to fsg_common_init() function which is called from fsg_bind(). Moreover, changed reference counting mechanism: fsg_common has a reference counter which counts how many fsg_dev structures uses it. When this reaches zero fsg_common_release() is run which unregisters LUN devices and frees memory. fsg_common_init() takes pointer to fsg_common structure as an argument. If it is NULL function allocates storage otherwise uses pointed to memory (handy if fsg_common is a field of another structure or a static variable). fsg_common_release() will free storage only if free_storage_on_release is set -- it is initialised by fsg_common_init(): set if allocation was done, unset otherwise (one may overwrite it of course). Signed-off-by:
-
Michal Nazarewicz authored
Using version of fsg_buffhd structure with buf field being an array of characters with predefined size. Since mass storage function does not define changing buffer size on run-time it is not required for the field to be a pointer to void and allocating space dynamically. Signed-off-by:
-
Michal Nazarewicz authored
In the final version, many fsg_dev structures will (be able to) refer to a single fsg_common structure and so it is required to move common data to another object which can be shared. Situation where many fsg_dev structures refer single fsg_common structure is when a single instance of MSF is used in several USB configurations. Signed-off-by:
-
Michal Nazarewicz authored
Removed code that was included when CONFIG_USB_FILE_STORAGE_TEST was defined. If this functionality is required one may still use the original File-backed Storage Gadget. It has been agreed that testing functionality is not required in the composite function. Also removed fsg_suspend() and fsg_resume() which were no operations. Moreover, storage_common.c has been modified in such a way that defining certain macros skips parts of the file. Those macros are: * FSG_NO_INTR_EP -- skips interrupt endpoint descriptors * FSG_NO_DEVICE_STRINGS -- skips certain strings * FSG_NO_OTG -- skips OTG descriptor Signed-off-by:
-
Michal Nazarewicz authored
Copied file_storage.c to f_mass_storage.c which will be used as template for the Mass Storage composite Function. Signed-off-by:
-
Michal Nazarewicz authored
Since storage_common.c no longer references mod_data object it is now possible to include it before mod_data object is defined. This makes it possible to move some defines that are used as default values of mod_data fields to be defined in storage_common.c file (where they should be set from the beginning). Also, show_ro(), show_file(), store_ro() and store_file() have been moved to storage_common.c with LUN's device's drvdata changed from pointing to fsg_dev to pointing to rw_semaphore (&fsg->filesem). Signed-off-by:
-
Michal Nazarewicz authored
removable and cdrom flag has been added to the fsg_lun structure removing any references to mod_data object from storage_common.c. As of read-only flag, previously it was set if a read-only backing file was specified (which is good) and remained set even after the file has been closed (which may be considered an issue). Currently, the initial read-only flag is preserved so if it was unset each time file is opened code will try to open it read-write even if previous file was opened read-only. Signed-off-by:
-
Michal Nazarewicz authored
Prefixed some identifiers that were defined in storage_common.c file with "fsg_". Not all identifiers were prefixed but the ones that are most likely to produce conflicts when used with other USB functions. Signed-off-by:
-
Michal Nazarewicz authored
Moved parts of the file_storage.c file which do not reference fsg_dev structure to newly created storage_common.c file. dump_msg() and dump_cdb() have been changed to macros to remove fsg_dev reference. Signed-off-by:
-
Daniel Mack authored
The Freescale MX27 and MX31 SoCs have a EHCI controller onboard. The controller is capable of USB on the go. This patch adds a driver to support all three of them. Users have to pass details about serial interface configuration in the platform data. The USB OTG core used here is the ARC core, so the driver should be renamed and probably be merged with ehci-fsl.c eventually. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Daniel Mack <daniel@caiaq.de> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Alan Stern authored
This patch (as1298) fixes a bug in the new scatter-gather URB facility. If an URB uses a scatterlist then it should not have the URB_NO_INTERRUPT flag set; otherwise the system won't be notified when the transfer completes. Signed-off-by:
David Vrabel <david.vrabel@csr.com> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Alan Stern authored
This patch (as1297) adds a "remove" attribute to each USB device's directory in sysfs. Writing to this attribute causes the device to be deconfigured (the same as writing 0 to the "bConfigurationValue" attribute) and then tells the hub driver to disable the device's upstream port. The device remains locked during these activities so there is no possibility of it getting reconfigured in between. The port will remain disabled until after the device is unplugged. The purpose of this is to provide a means for user programs to imitate the "Safely remove hardware" applet in Windows. Some devices do expect their ports to be disabled before they are unplugged, and they provide visual feedback to users indicating when they can safely be unplugged. The security implications are minimal. Writing to the "remove" attribute is no more dangerous than writing to the "bConfigurationValue" attribute. Signed-off-by:
-
Alan Stern authored
This patch (as1296) gets rid of the fixed DMA-buffer mapping used by the hub driver for its status URB. This URB doesn't get used much -- mainly when a device is plugged in or unplugged -- so the dynamic mapping overhead is minimal. And most systems have many fewer external hubs than root hubs, which don't need a mapped buffer anyway. Signed-off-by:
-
Sarah Sharp authored
The EHCI specification says that an EHCI host controller may cache part of the isochronous schedule. The EHCI controller must advertise how much it caches in the schedule through the HCCPARAMS register isochronous scheduling threshold (IST) bits. In theory, adding new iTDs within the IST should be harmless. The HW will follow the old cached linked list and miss the new iTD. SW will notice HW missed the iTD and return 0 for the transfer length. However, Intel ICH9 chipsets (and some later chipsets) have issues when SW attempts to schedule a split transaction within the IST. All transfers will cease being sent out that port, and the drivers will see isochronous packets complete with a length of zero. Start of frames may or may not also disappear, causing the device to go into auto-suspend. This "bus stall" will continue until a control or bulk transfer is queued to a device under that roothub. Most drivers will never cause this behavior, because they use multiple URBs with multiple packets to keep the bus busy. If you limit the number of URBs to one, you may be able to hit this bug. Make sure the EHCI driver does not schedule full-speed transfers within the IST under an Intel chipset. Make sure that when we fall behind the current microframe plus IST, we schedule the new transfer at the next periodic interval after the IST. Don't change the scheduling for new transfers, since the schedule slop will always be greater than the IST. Allow high speed isochronous transfers to be scheduled within the IST, since this doesn't trigger the Intel chipset bug. Make sure that if the host caches the full frame, the EHCI driver's internal isochronous threshold (ehci->i_thresh) is set to 8 microframes + 2 microframes wiggle room. This is similar to what is done in the case where the host caches less than the full frame. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Sarah Sharp authored
Change the constant SCHEDULE_SLOP to be 80 microframes, instead of 10 frames. It was always multiplied by 8 to convert frames to microframes. SCHEDULE_SLOP is only used in ehci-sched.c. Signed-off-by:
-
Sarah Sharp authored
CONFIG_USB_HCD_STAT was used in an abandoned patch to track host controller throughput statistics. Since CONFIG_USB_HCD_STAT will never be defined, remove code that can never run. Signed-off-by:
-
Sarah Sharp authored
In order to giveback a canceled URB, we must ensure that the xHCI hardware will not access the buffer in an URB. We can't modify the buffer pointers on endpoint rings without issuing and waiting for a stop endpoint command. Since URBs can be canceled in interrupt context, we can't wait on that command. The old code trusted that the host controller would respond to the command, and would giveback the URBs in the event handler. If the hardware never responds to the stop endpoint command, the URBs will never be completed, and we might hang the USB subsystem. Implement a watchdog timer that is spawned whenever a stop endpoint command is queued. If a stop endpoint command event is found on the event ring during an interrupt, we need to stop the watchdog timer with del_timer(). Since del_timer() can fail if the timer is running and waiting on the xHCI lock, we need a way to signal to the timer that everything is fine and it should exit. If we simply clear EP_HALT_PENDING, a new stop endpoint command could sneak in and set it before the watchdog timer can grab the lock. Instead we use a combination of the EP_HALT_PENDING flag and a counter for the number of pending stop endpoint commands (xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog timer and del_timer() succeeds, we decrement the number of pending stop endpoint commands. If del_timer() fails, we leave the number of pending stop endpoint commands alone. In either case, we clear the EP_HALT_PENDING flag. The timer will decrement the number of pending stop endpoint commands once it obtains the lock. If the timer is the tail end of the last stop endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the endpoint's command is still pending (EP_HALT_PENDING is set), we assume the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to halt the xHCI host, and give back all pending URBs. Various other places in the driver need to check whether the xHCI host is dying. If the interrupt handler ever notices, it should immediately stop processing events. The URB enqueue function should also return -ESHUTDOWN. The URB dequeue function should simply return the value of usb_hcd_check_unlink_urb() and the watchdog timer will take care of giving the URB back. When a device is disconnected, the xHCI hardware structures should be freed without issuing a disable slot command (since the hardware probably won't respond to it anyway). The debugging polling loop should stop polling if the host is dying. When a device is disconnected, any pending watchdog timers are killed with del_timer_sync(). It must be synchronous so that the watchdog timer doesn't attempt to access the freed endpoint structures. Signed-off-by:
-
Sarah Sharp authored
xhci_quiesce() is basically a no-op right now. It's only called if HC_IS_RUNNING() is true, and the body of the function consists of a BUG_ON if HC_IS_RUNNING() is false. For the new xHCI watchdog timer, we need a new function that clears the xHCI running bit in the command register, but doesn't wait for the halt status to show up in the status register. Re-purpose xhci_quiesce() to do that. Signed-off-by:
-
Sarah Sharp authored
In the old code, there was a race condition between the stop endpoint command and the URB submission process. When the stop endpoint command is handled by the event handler, the endpoint ring is assumed to be stopped. When a stop endpoint command is queued, URB submissions are to not ring the doorbell. The old code would check the number of pending URBs to be canceled, and would not ring the doorbell if it was non-zero. However, the following race condition could occur with the old code: 1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop endpoint command, and increment ep->cancels_pending to 1. 2. The URB finishes on the HW, and an event is enqueued to the event ring (at the same time as 1). 3. The stop endpoint command finishes, and the endpoint is halted. An event is queued to the event ring. 4. The event handler sees the finished URB, notices it was to be canceled, decrements ep->cancels_pending to 0, and removes it from the to be canceled list. 5. The event handler drops the lock and gives back the URB. The completion handler requeues the URB (or a different driver enqueues a new URB). This causes the endpoint's doorbell to be rung, since ep->cancels_pending == 0. The endpoint is now running. 6. A second URB is canceled, and it's added to the canceled list. Since ep->cancels_pending == 0, a new stop endpoint command is queued, and ep->cancels_pending is incremented to 1. 7. The event handler then sees the completed stop endpoint command. The handler assumes the endpoint is stopped, but it isn't. It attempts to move the dequeue pointer or change TDs to cancel the second URB, while the hardware is actively accessing the endpoint ring. To eliminate this race condition, a new endpoint state bit is introduced, EP_HALT_PENDING. When this bit is set, a stop endpoint command has been queued, and the command handler has not begun to process the URB cancellation list yet. The endpoint doorbell should not be rung when this is set. Set this when a stop endpoint command is queued, clear it when the handler for that command runs, and check if it's set before ringing a doorbell. ep->cancels_pending is eliminated, because it is no longer used. Make sure to ring the doorbell for an endpoint when the stop endpoint command handler runs, even if the canceled URB list is empty. All canceled URBs could have completed and new URBs could have been enqueued without the doorbell being rung before the command was handled. Signed-off-by:
-
Oliver Neukum authored
usb: better error handling in usb_port_suspend - disable remote wakeup only if it was enabled - refuse to autosuspend if remote wakeup fails to be enabled Signed-off-by:
-
Felipe Balbi authored
this driver has been sitting in linux-omap tree for quite some time. It adds support for omap's ehci controller. Signed-off-by:
Vikram Pandita <vikram.pandita@ti.com> Signed-off-by:
Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by:
-
