diff options
author | Hans de Goede <hdegoede@redhat.com> | 2012-07-04 09:18:02 +0200 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2012-07-06 10:53:19 -0700 |
commit | 19181bc50e1b8e92a7a3b3d78637c6dc5c0b5a1b (patch) | |
tree | 347b45182dd50d1237f24579628232ca3a04de97 /drivers | |
parent | 2102e06a5f2e414694921f23591f072a5ba7db9f (diff) | |
download | linux-3.10-19181bc50e1b8e92a7a3b3d78637c6dc5c0b5a1b.tar.gz linux-3.10-19181bc50e1b8e92a7a3b3d78637c6dc5c0b5a1b.tar.bz2 linux-3.10-19181bc50e1b8e92a7a3b3d78637c6dc5c0b5a1b.zip |
usbdevfs: Add a USBDEVFS_GET_CAPABILITIES ioctl
There are a few (new) usbdevfs capabilities which an application cannot
discover in any other way then checking the kernel version. There are 3
problems with this:
1) It is just not very pretty.
2) Given the tendency of enterprise distros to backport stuff it is not
reliable.
3) As discussed in length on the mailinglist, USBDEVFS_URB_BULK_CONTINUATION
does not work as it should when combined with USBDEVFS_URB_SHORT_NOT_OK
(which is its intended use) on devices attached to an XHCI controller.
So the availability of these features can be host controller dependent,
making depending on them based on the kernel version not a good idea.
This patch besides adding the new ioctl also adds flags for the following
existing capabilities:
USBDEVFS_CAP_ZERO_PACKET, available since 2.6.31
USBDEVFS_CAP_BULK_CONTINUATION, available since 2.6.32, except for XHCI
USBDEVFS_CAP_NO_PACKET_SIZE_LIM, available since 3.3
Note that this patch only does not advertise the USBDEVFS_URB_BULK_CONTINUATION
cap for XHCI controllers, bulk transfers with this flag set will still be
accepted when submitted to XHCI controllers.
Returning -EINVAL for them would break existing apps, and in most cases the
troublesome scenario wrt USBDEVFS_URB_SHORT_NOT_OK urbs on XHCI controllers
will never get hit, so this would break working use cases.
The disadvantage of not returning -EINVAL is that cases were it is causing
real trouble may go undetected / the cause of the trouble may be unclear,
but this is the best we can do.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers')
-rw-r--r-- | drivers/usb/core/devio.c | 17 | ||||
-rw-r--r-- | drivers/usb/host/xhci.c | 2 |
2 files changed, 19 insertions, 0 deletions
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 62679bc031f..0b387c1a8b7 100644 --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1824,6 +1824,20 @@ static int proc_release_port(struct dev_state *ps, void __user *arg) return usb_hub_release_port(ps->dev, portnum, ps); } +static int proc_get_capabilities(struct dev_state *ps, void __user *arg) +{ + __u32 caps; + + caps = USBDEVFS_CAP_ZERO_PACKET | USBDEVFS_CAP_NO_PACKET_SIZE_LIM; + if (!ps->dev->bus->no_stop_on_short) + caps |= USBDEVFS_CAP_BULK_CONTINUATION; + + if (put_user(caps, (__u32 __user *)arg)) + return -EFAULT; + + return 0; +} + /* * NOTE: All requests here that have interface numbers as parameters * are assuming that somehow the configuration has been prevented from @@ -1994,6 +2008,9 @@ static long usbdev_do_ioctl(struct file *file, unsigned int cmd, snoop(&dev->dev, "%s: RELEASE_PORT\n", __func__); ret = proc_release_port(ps, p); break; + case USBDEVFS_GET_CAPABILITIES: + ret = proc_get_capabilities(ps, p); + break; } usb_unlock_device(dev); if (ret >= 0) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index a979cd0dbe0..7648b2d4b26 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4450,6 +4450,8 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks) /* Accept arbitrarily long scatter-gather lists */ hcd->self.sg_tablesize = ~0; + /* XHCI controllers don't stop the ep queue on short packets :| */ + hcd->self.no_stop_on_short = 1; if (usb_hcd_is_primary_hcd(hcd)) { xhci = kzalloc(sizeof(struct xhci_hcd), GFP_KERNEL); |