- 23 Sep, 2009 40 commits
-
-
Oliver Neukum authored
usb: full runtime PM support for idmouse driver - add suspend/resume support - add reset_resume support - add support for autosuspend Signed-off-by:
Oliver Neukum <oliver@neukum.org> Tested-by:
Andreas Deresch <aderesch@fs.tum.de>
-
Roel Kluin authored
Add missing parentheses Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> CC: Ben Dooks <ben@simtec.co.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Julia Lawall authored
list_entry, which is an alias for container_of, cannot return NULL, as there is no way to add a NULL value to a doubly linked list. A simplified version of the semantic match that findds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r@ expression x,E; statement S1,S2; position p,p1; @@ *x = list_entry@p(...) ... when != x = E *if@p1 (x == NULL) S1 else S2 // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
-
Oliver Neukum authored
poll() should test for a disconnection of the device. Signed-off-by:
-
Oliver Neukum authored
poll needs to return an error if a device is disconnected - make poll check for device's presence - wake all waiters in disconnect Signed-off-by:
-
Oliver Neukum authored
a class driver should have suspend/resume. This makes sure we don't see a virtual disconnect unnecessarily. Signed-off-by:
-
Oliver Neukum authored
usbtmc will happily complete read/write requests even after disconnect has returned. The fix is to introduce a flag. Signed-off-by:
-
Jiri Slaby authored
There are some unused variables in serial_do_down. Remove them. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Oliver Neukum authored
this adds autosupport usable even in an always online mode. - enables remote wakeup on open - autoresume for sending - timeout based autosuspend if nothing is sent or recieved - autosuspend without remote wakeup support on open/close Signed-off-by:
Zhao Ming <zhao.ming9@zte.com.cn> Signed-off-by:
-
Philipp Zabel authored
This adds very basic otg_transceiver support, with vbus_session and vbus_draw callbacks. Now VBUS sensing can be handled by an external driver which registers the otg_transceiver interface. It also allows gadget drivers to configure the current drawn from VBUS. The UDC driver just passes their requests along to the transceiver driver. Signed-off-by:
Philipp Zabel <philipp.zabel@gmail.com> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Alan Stern authored
This patch (as1261) reduces the amount of detailed URB information logged by usbfs when the usbfs_snoop parameter is enabled. Currently we don't display the final status value for a completed URB. But we do display the entire data buffer twice: both before submission and after completion. The after-completion display doesn't limit itself to the actual_length value. But since usbmon is readily available in virtually all distributions, there's no reason for usbfs to print out any buffer contents at all! So this patch restricts the information to: userspace buffer pointer, endpoint number, type, and direction, length or actual_length, and timeout value or status. Now everything fits neatly into a single line. Along with those changes, the patch also fixes the snoop output for the REAPURBNDELAY and REAPURBNDELAY32 ioctls. The current version omits the 'N' from the names. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
This patch (as1260) changes the pm_usage_cnt field in struct usb_interface from an int to an atomic_t. This is so that drivers can invoke the usb_autopm_get_interface_async() and usb_autopm_put_interface_async() routines without locking and without fear of corrupting the pm_usage_cnt value. Signed-off-by:
-
Alan Stern authored
This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by:
-
David Vrabel authored
usb_hcd_endpoint_reset() may be called in atomic context and must not sleep. So make whci-hcd's endpoint_reset() asynchronous. URBs submitted while the reset is in progress will be queued (on the std list) and transfers will resume once the reset is complete. Signed-off-by:
David Vrabel <david.vrabel@csr.com> Signed-off-by:
-
Wan ZongShun authored
Add ehci support for w90p910 platform. Signed-off-by:
Wan ZongShun <mcuos.com@gmail.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Laurent Pinchart authored
Those functions are used only used to fill the set/get members of usb_audio_control. It doesn't make much sense to inline them. Signed-off-by:
Laurent Pinchart <laurent.pinchart@skynet.be> Signed-off-by:
-
Laurent Pinchart authored
linux/usb/audio.h is a public header file that includes definitions exported to userspace. To avoid namespace clashes, prefix all macro definitions with UAC_. Existing macros and structures prefixed with USB_AC_ and USB_AS_ are renamed for consistency. Signed-off-by:
-
Laurent Pinchart authored
USB_SUBCLASS_VENDOR_SPEC is common to several USB classes and as such belongs to usb/ch9.h. Signed-off-by:
-
Laurent Pinchart authored
And use the new definitions in the USB Audio Class gadget driver. Signed-off-by:
-
Pete Zaitcev authored
This fix permits the "new" usbmon to access usb-storage's data buffer without DMA remapping tricks. It should be compatible with PIO controllers and not add any new crashes. Note that from now on PIO controllers and usbmon are uniform in their access pattern and if one crashes then the other will too. Hopefuly neither does. As a side effect, we get rid for #ifdefs, which were a little ugly. Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Pete Zaitcev authored
This patch fixes crashes when usbmon attempts to access GART aperture. The old code attempted to take a bus address and convert it into a virtual address, which clearly was impossible on systems with actual IOMMUs. Let us not persist in this foolishness, and use transfer_buffer in all cases instead. I think downsides are negligible. The ones I see are: - A driver may pass an address of one buffer down as transfer_buffer, and entirely different entity mapped for DMA, resulting in misleading output of usbmon. Note, however, that PIO based controllers would do transfer the same data that usbmon sees here. - Out of tree drivers may crash usbmon if they store garbage in transfer_buffer. I inspected the in-tree drivers, and clarified the documentation in comments. - Drivers that use get_user_pages will not be possible to monitor. I only found one driver with this problem (drivers/staging/rspiusb). - Same happens with with usb_storage transferring from highmem, but it works fine on 64-bit systems, so I think it's not a concern. At least we don't crash anymore. Why didn't we do this in 2.6.10? That's because back in those days it was popular not to fill in transfer_buffer, so almost all traffic would be invisible (e.g. all of HID was like that). But now, the tree is almost 100% PIO friendly, so we can do the right thing at last. Signed-off-by:
-
Pete Zaitcev authored
I think this sentence was confusing regarding the possible size of the data area. Signed-off-by:
-
Pete Zaitcev authored
These statements seem to be unnecessary. No idea why, but I built all possible configurations and everything gets built just as before. It's an old patch that popped from discussion with Paul in November 2008. Obviously not a very high priority but better late than never. Signed-off-by:
-
Pete Zaitcev authored
This patch falls out of my work to fix usbmon so it uses virtual addresses. It is not necessary, the "new" usbmon should work just fine with sisusbvga. However, it seems ridiculous that anyone would use uncached memory to transfer bulk data. Dropping the unnecessary use of usb_buffer_alloc should be beneficial here, in case anyone ever uses the dongle on anything beyond x86. I had no success in raising the author of the driver by e-mail, so the patch is not actually tested. Signed-off-by:
-
Figo.zhang authored
vfree() does it's own NULL checking,so no need for check before calling it. Signed-off-by:
Figo.zhang <figo1802@gmail.com> Signed-off-by:
-
Sarah Sharp authored
When there's a descriptor after the SuperSpeed endpoint companion descriptor, the previous code would have skipped over twice the length it was supposed to. This code fixes crashes seen with UASP devices (which have a UASP descriptor after the SS endpoint companion descriptor). Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Sarah Sharp authored
Interrupt transfers are submitted to the xHCI hardware using the same TRB type as bulk transfers. Re-use the bulk transfer enqueueing code to enqueue interrupt transfers. Interrupt transfers are a bit different than bulk transfers. When the interrupt endpoint is to be serviced, the xHC will consume (at most) one TD. A TD (comprised of sg list entries) can take several service intervals to transmit. The important thing for device drivers to note is that if they use the scatter gather interface to submit interrupt requests, they will not get data sent from two different scatter gather lists in the same service interval. For now, the xHCI driver will use the service interval from the endpoint's descriptor (bInterval). Drivers will need a hook to poll at a more frequent interval. Set urb->interval to the interval that the xHCI hardware will use. Signed-off-by:
-
Sarah Sharp authored
The xHCI hardware reports the number of bytes untransferred for a given transfer buffer. If the hardware reports a bytes untransferred value greater than the submitted buffer size, we want to play it safe and say no data was transferred. If the driver considers a short packet to be an error, remember to set -EREMOTEIO. Signed-off-by:
-
Sarah Sharp authored
Make sure that the driver that submitted the URB considers a short packet an error before setting -EREMOTEIO during a short control transfer. Signed-off-by:
-
Sarah Sharp authored
Make sure that the amount of data the xHC says was transmitted is less than or equal to the size of the requested transfer buffer. Before, if the host controller erroneously reported that the number of bytes untransferred was bigger than the buffer in the URB, urb->actual_length could be set to a very large size. Make sure urb->actual_length <= urb->transfer_buffer_length. Signed-off-by:
-
Sarah Sharp authored
On a successful transfer, urb->td is freed before the URB is ready to be given back to the driver. Don't touch urb->td after it's freed. This bug would have only shown up when xHCI debugging was turned on, and the freed memory was quickly reused for something else. Signed-off-by:
-
Sarah Sharp authored
The 0.95 xHCI spec says that non-control endpoints will be halted if a babble is detected on a transfer. The 0.96 xHCI spec says all types of endpoints will be halted when a babble is detected. Some hardware that claims to be 0.95 compliant halts the control endpoint anyway. When a babble is detected on a control endpoint, check the hardware's output endpoint context to see if the endpoint is marked as halted. If the control endpoint is halted, a reset endpoint command must be issued and the transfer ring dequeue pointer needs to be moved past the stopped transfer. Basically, we treat it as if the control endpoint had stalled. Handle bulk babbling endpoints as if we got a completion event with a stall completion code. Signed-off-by:
-
Sarah Sharp authored
Use trb_comp_code instead of getting the completion code from the transfer event every time. Signed-off-by:
-
Sarah Sharp authored
This Fresco Logic xHCI host controller chip revision puts bad data into the output endpoint context after a Reset Endpoint command. It needs a Configure Endpoint command (instead of a Set TR Dequeue Pointer command) after the reset endpoint command. Set up the input context before issuing the Reset Endpoint command so we don't copy bad data from the output endpoint context. The HW also can't handle two commands queued at once, so submit the TRB for the Configure Endpoint command in the event handler for the Reset Endpoint command. Devices that stall on control endpoints before a configuration is selected will not work under this Fresco Logic xHCI host controller revision. This patch is for prototype hardware that will be given to other companies for evaluation purposes only, and should not reach consumer hands. Fresco Logic's next chip rev should have this bug fixed. Signed-off-by:
-
Sarah Sharp authored
When a control endpoint stalls, the next control transfer will clear the stall. The USB core doesn't call down to the host controller driver's endpoint_reset() method when control endpoints stall, so the xHCI driver has to do all its stall handling for internal state in its interrupt handler. When the host stalls on a control endpoint, it may stop on the data phase or status phase of the control transfer. Like other stalled endpoints, the xHCI driver needs to queue a Reset Endpoint command and move the hardware's control endpoint ring dequeue pointer past the failed control transfer (with a Set TR Dequeue Pointer or a Configure Endpoint command). Since the USB core doesn't call usb_hcd_reset_endpoint() for control endpoints, we need to do this in interrupt context when we get notified of the stalled transfer. URBs may be queued to the hardware before these two commands complete. The endpoint queue will be restarted once both commands complete. Signed-off-by:
-
Sarah Sharp authored
Full speed devices have varying max packet sizes (8, 16, 32, or 64) for endpoint 0. The xHCI hardware needs to know the real max packet size that the USB core discovers after it fetches the first 8 bytes of the device descriptor. In order to fix this without adding a new hook to host controller drivers, the xHCI driver looks for an updated max packet size for control endpoints. If it finds an updated size, it issues an evaluate context command and waits for that command to finish. This should only happen in the initialization and device descriptor fetching steps in the khubd thread, so blocking should be fine. Signed-off-by:
-
Sarah Sharp authored
Set the max packet size for the default control endpoint on high speed devices to be 64 bytes. High speed devices always have a max packet size of 64 bytes. There's no use setting it to eight for the initial 8 byte descriptor fetch and then issuing (and waiting for) an evaluate context command to update it to 64 bytes for the subsequent control transfers. The USB core guesses that the max packet size on a full speed control endpoint is 64 bytes, and then updates it after the first 8-byte descriptor fetch. Change the initial setup for the xHCI internal representation of the full speed device to have a 64 byte max packet size. Signed-off-by:
-
Sarah Sharp authored
Refactor out the code issue, wait for, and parse the event completion code for a configure endpoint command. Modify it to support the evaluate context command, which has a very similar submission process. Add functions to copy parts of the output context into the input context (which will be used in the evaluate context command). Signed-off-by:
-
Sarah Sharp authored
Use the virtual address of the memory hardware uses, not the address for the container of that memory. Signed-off-by:
-
Sarah Sharp authored
Different sections of the xHCI 0.95 specification had opposing requirements for the chain bit in a link transaction request buffer (TRB). The chain bit is used to designate that adjacent TRBs are all part of the same scatter gather list that should be sent to the device. Link TRBs can be in the middle, or at the beginning or end of these chained TRBs. Sections 4.11.5.1 and 6.4.4.1 both stated the link TRB "shall have the chain bit set to 1", meaning it is always chained to the next TRB. However, section 4.6.9 on the stop endpoint command has specific cases for what the hardware must do for a link TRB with the chain bit set to 0. The 0.96 specification errata later cleared up this issue by fixing the 4.11.5.1 and 6.4.4.1 sections to state that a link TRB can have the chain bit set to 1 or 0. The problem is that the xHCI cancellation code depends on the chain bit of the link TRB being cleared when it's at the end of a TD, and some 0.95 xHCI hardware simply stops processing the ring when it encounters a link TRB with the chain bit cleared. Allow users who are testing 0.95 xHCI prototypes to set a module parameter (link_quirk) to turn on this link TRB work around. Cancellation may not work if the ring is stopped exactly on a link TRB with chain bit set, but cancellation should be a relatively uncommon case. Signed-off-by:
-
