- 04 Mar, 2014 40 commits
-
-
Hans de Goede authored
If streams are still allocated on device-reset or set-interface then the hcd code implictly frees the streams. Clear host_endpoint->streams in this case so that if a driver later tries to re-allocate them it won't run afoul of the device already having streams check in usb_alloc_streams(). Note normally streams still being allocated at reset / set-intf would be a driver bug, but this can happen without it being a driver bug on reset-resume. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com>
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
If we align segment dma pool memory to 64 bytes, then a segment can be located at 0x10000040 - 0x1000043f, and a segment from another ring at 0x10000440 - 0x1000083f. The last trb in the first segment at 0x10000430 will then translate to the same radix tree key as the first trb of the second segment, while they are in different rings! This patches fixes this by changing the alignment of the dma pool to be 1KB rather then 64 bytes. An alternative fix would be to reduce the shift used to calculate the radix tree keys, but that would (slighlty) grow the radix trees so I believe this is the better fix. Note this patch is mostly theoretical since in practice I've not seen the dma_pool actually return not 1KB aligned memory. Signed-off-by:
-
Hans de Goede authored
cmd_ring_reserved_trbs gets decremented by xhci_free_stream_info(), so set it to 0 after freeing all rings, otherwise it wraps around to a very large value when rings with streams are free-ed. Before this patch the wrap-around could be triggered when xhci_resume calls xhci_mem_cleanup if the controller resume fails. Signed-off-by:
-
Hans de Goede authored
This is a preparation patch for teaching usb-storage to not bind to uas devices. Signed-off-by:
-
Hans de Goede authored
This is a preparation patch for teaching usb-storage to not bind to uas devices. Signed-off-by:
-
Hans de Goede authored
If we get ie 16 streams we can use stream-id 1-16, not 1-15. Signed-off-by:
-
Hans de Goede authored
The iu struct definitions are usb packet definitions, so no alignment should happen. Notice that assuming 32 bit alignment this does not make any difference at all. Signed-off-by:
-
Hans de Goede authored
The response iu struct before this patch has a size of 7 bytes (discounting padding), which is weird since all other iu-s are explictly padded to a multiple of 4 bytes. More over submitting a 7 byte bulk transfer to the status endpoint when expecting a response iu results in an USB babble error, as the device actually sends 8 bytes. Up on closer reading of the UAS spec: http://www.t10.org/cgi-bin/ac.pl?t=f&f=uas2r00.pdf The reason for this becomes clear, the 2 entries in "Table 17 — RESPONSE IU" are numbered 4 and 6, looking at other iu definitions in the spec, esp. multi-byte fields, this indicates that the ADDITIONAL RESPONSE INFORMATION field is not a 2 byte field as one might assume at a first look, but is a multi-byte field containing 3 bytes. This also aligns with the SCSI Architecture Model 4 spec, which UAS is based on which states in paragraph "7.1 Task management function procedure calls" that the "Additional Response Information" output argument for a Task management function procedure call is 3 bytes. Last but not least I've verified this by sending a logical unit reset task management call with an invalid lun to an actual uasp device, and received back a response-iu with byte 6 being 0, and byte 7 being 9, which is the responce code for an invalid iu, which confirms that the response code is being reported in byte 7 of the response iu rather then in byte 6. Things were working before despite this error in the response iu struct definition because the additional response info field is normally filled with zeros, and 0 is the response code value for success. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
Handle usb-device resets not triggered from uas_eh_bus_reset_handler(), when this happens, disable cmd queuing during the reset, and wait for existing requests to finish in pre_reset. Signed-off-by:
-
Hans de Goede authored
Fix the uas_eh_bus_reset_handler not properly taking the usbdev lock before calling usb_device_reset, the usb-core expects this lock to be taken when usb_device_reset is called. Signed-off-by:
-
Hans de Goede authored
I thought it would be a good idea to also test uas with usb-2, and it turns out it was, as it did not work. The problem is that the uas driver was passing the bEndpointAddress' direction bit to usb_rcvbulkpipe, the xhci code seems to not care about this, but with the ehci code this causes usb_submit_urb failure. With this fixed the uas code works nicely with an uas device plugged into an ehci port. Signed-off-by:
-
Hans de Goede authored
The cmd endpoint never has streams, so the stream_id parameter is unused. Signed-off-by:
-
Hans de Goede authored
All callers of unlink_data_urbs drop devinfo->lock before calling it, and then immediately take it again after the call. And the first thing unlink_data_urbs does is take the lock again, and the last thing it does is drop it. This commit removes all the unnecessary lock dropping and taking. Signed-off-by:
-
Hans de Goede authored
- Rename labels to properly reflect this - Don't skip free-ing the streams when scsi_init_shared_tag_map fails Signed-off-by:
-
Hans de Goede authored
Otherwise they may complete before they get anchored and thus never get unanchored (as the unanchoring is done by the usb core on completion). This commit also remove the usb_get_urb / usb_put_urb around cmd submission + anchoring, since if done in the proper order this is not necessary. Signed-off-by:
-
Gerd Hoffmann authored
Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Gerd Hoffmann authored
This patch adds a new list where all requests which are canceled are added to, so we don't loose them. Then, after killing all inflight urbs on bus reset (and disconnect) we'll walk over the list and clean them up. Without this we can end up with aborted requests lingering around in case of status pipe transfer errors. Signed-off-by:
-
Gerd Hoffmann authored
Simplifies locking, we'll protect the list with the device spin lock. Also plugs races which can happen when two devices operate on the global list. While being at it rename the list head from "list" to "work", preparing for the addition of a second list. Signed-off-by:
-
Gerd Hoffmann authored
Signed-off-by:
-
Hans de Goede authored
This allows userspace to use bulk-streams, just like in kernel drivers, see Documentation/usb/bulk-streams.txt for details on the in kernel API. This is exported pretty much one on one to userspace. To use streams an app must first make a USBDEVFS_ALLOC_STREAMS ioctl, on success this will return the number of streams available (which may be less then requested). If there are n streams the app can then submit usbdevfs_urb-s with their stream_id member set to 1-n to use a specific stream. IE if USBDEVFS_ALLOC_STREAMS returns 4 then stream_id 1-4 can be used. When the app is done using streams it should call USBDEVFS_FREE_STREAMS Note applications are advised to use libusb rather then using the usbdevfs api directly. The latest version of libusb has support for streams. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
This patch makes it possible to specify a bulk stream id when submitting an urb using the async usbfs API. It overloads the number_of_packets usbdevfs_urb field for this. This is not pretty, but given other constraints it is the best we can do. The reasoning leading to this goes as follows: 1) We want to support bulk streams in the usbfs API 2) We do not want to extend the usbdevfs_urb struct with a new member, as that would mean defining new ioctl numbers for all async API ioctls + adding compat versions for the old ones (times 2 for 32 bit support) 3) 1 + 2 means we need to re-use an existing field 4) number_of_packets is only used for isoc urbs, and streams are bulk only so it is the best (and only) candidate for re-using Note that: 1) This patch only uses number_of_packets as stream_id if the app has actually allocated streams on the ep, so that old apps which may have garbage in there (as it was unused until now in the bulk case), will not break 2) This patch does not add support for allocating / freeing bulk-streams, that is done in a follow up patch Signed-off-by:
-
Hans de Goede authored
This is a preparation patch for adding support for bulk streams. Signed-off-by:
-
Hans de Goede authored
The usb_set_interface documentation says: * Also, drivers must not change altsettings while urbs are scheduled for * endpoints in that interface; all such urbs must first be completed * (perhaps forced by unlinking). For in kernel drivers we trust the drivers to get this right, but we cannot trust userspace to get this right, so enforce it by killing any urbs still pending on the interface. Signed-off-by:
-
Hans de Goede authored
Documentation/usb/bulk-streams.txt says: All stream IDs will be deallocated when the driver releases the interface, to ensure that drivers that don't support streams will be able to use the endpoint This commit actually implements this. Signed-off-by:
-
Hans de Goede authored
This is a preparation patch for adding support for bulk streams to usbfs. Signed-off-by:
-
Hans de Goede authored
So that it can be used in other places too. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Sarah Sharp authored
If we're expanding a stream ring, we want to make sure we can add those ring segments to the radix tree that maps segments to ring pointers. Try the radix tree insert after the new ring segments have been allocated (the last segment in the new ring chunk will point to the first newly allocated segment), but before the new ring segments are linked into the old ring. If insert fails on any one segment, remove each segment from the radix tree, deallocate the new segments, and return. Otherwise, link the new segments into the tree. HdG: Add a check to only update stream mappings in xhci_ring_expansion when the ring is a stream ring. Signed-off-by:
-
Hans de Goede authored
The ss_ep_comp bmAttributes filed can contain more info then just the streams, use usb_ss_max_streams to properly get max streams. Signed-off-by:
-
Hans de Goede authored
This fixes TR dequeue validation failing on Intel XHCI controllers with the following warning: Mismatch between completed Set TR Deq Ptr command & xHCI internal state. Interestingly enough reading the deq ptr from the ep ctx after a TR Deq Ptr command does work on a Nec XHCI controller, it seems the Nec writes the ptr to both the ep and stream contexts when streams are used. Signed-off-by:
-
Hans de Goede authored
Nec XHCI controllers don't seem to care, but without this Intel XHCI controllers reject Set TR dequeue commands with a COMP_TRB_ERR, leading to the following warning: WARN Set TR Deq Ptr cmd invalid because of stream ID configuration And very shortly after this the system completely freezes. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
Before this a device needing ie 32 stream ctxs would end up with an entry from the small_streams_pool which has 256 bytes entries, where as 32 stream ctxs need 512 bytes. Things actually keep running for a surprisingly long time before crashing because of this. Signed-off-by:
-
Hans de Goede authored
And warn about this, as that would be a driver bug. Like wise drivers should ensure that streams are properly free-ed before a device is reset. So lets warn about that too. This already causes warnings in the form of: [ 96.982398] xhci_hcd 0000:01:00.0: WARN Can't disable streams for endpoint 0x81 , streams are already disabled! [ 96.982400] xhci_hcd 0000:01:00.0: WARN xhci_free_streams() called with non-streams endpoint But it is better to also warn about the actual cause of this later warnings. Signed-off-by:
-
Gerd Hoffmann authored
xhci maintains a radix tree for each stream endpoint because it must be able to map a trb address to the stream ring. Each ring segment must be added to the ring for this to work. Currently xhci sticks only the first segment of each stream ring into the radix tree. Result is that things work initially, but as soon as the first segment is full xhci can't map the trb address from the completion event to the stream ring any more -> BOOM. You'll find this message in the logs: ERROR Transfer event for disabled endpoint or incorrect stream ring This patch adds a helper function to update the radix tree, and a function to remove ring segments from the tree. Both functions loop over the segment list and handles all segments instead of just the first. [Note: Sarah changed this patch to add radix_tree_maybe_preload() and radix_tree_preload_end() calls around the radix tree insert, since we can now insert entries in interrupt context. There are now two helper functions to make the code cleaner, and those functions are moved to make them static.] Signed-off-by:
-
Oliver Neukum authored
This changes debug messages and warnings in xhci-ring.c to be on a single line so grep can find them. grep must have precedence over the 80 column limit. [Sarah fixed two checkpatch.pl issues with split lines introduced by this commit.] Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Sarah Sharp authored
The xHCI driver currently uses a USB core internal field, udev->lpm_capable, to indicate the xHCI driver knows how to calculate the LPM timeout values. If this value is set for the host controller udev, it means Link PM can be enabled for child devices under that host. Change the code so the xHCI driver isn't mucking with USB core internal fields. Instead, indicate the xHCI driver doesn't support Link PM on this host by clearing the U1 and U2 exit latencies in the roothub SuperSpeed Extended Capabilities BOS descriptor. The code to check for the roothub setting U1 and U2 exit latencies to zero will also disable LPM for external devices that do that same. This was already effectively done with commit ae8963ad "usb: Don't enable LPM if the exit latency is zero." Leave that code in place, so that if a device sets one exit latency value to zero, but the other is set to a valid value, LPM is only enabled for the U1 or U2 state that had the valid value. This is the same behavior the code had before. Also, change messages about missing Link PM information from warning level to info level. Only print a warning about the first device that doesn't support LPM, to avoid log spam. Further, cleanup some unnecessary line breaks to help people to grep for the error messages. Signed-off-by:
-
