On Thu, 28 Jun 2012, Hans de Goede wrote:
> 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) Some of these features turn out to not work with certain host controllers,
> making depending on them based on the kernel version not a good idea
>
> This patch besides adding the new ioctl also adds flags 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
>
> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> +static int proc_get_capabilities(struct dev_state *ps, void __user *arg)
> +{
> + __u64 caps = 0;
Does these need to be 64 bits? Yes, you want to provide room for
future expansion... but we've added capabilities at a rate of about one
per year. I doubt usbfs will survive the next 30 years.
> +
> + caps |= USBDEVFS_CAP_ZERO_PACKET | USBDEVFS_CAP_NO_PACKET_SIZE_LIM;
> + caps |= USBDEVFS_CAP_BULK_CONTINUATION;
Formatting nit: How about
caps = USBDEVFS_CAP_ZERO_PACKET |
USBDEVFS_CAP_NO_PACKET_SIZE_LIM |
USBDEVFS_CAP_BULK_CONTINUATION |
0;
> +/* Device capability flags */
> +#define USBDEVFS_CAP_ZERO_PACKET 0x01
> +#define USBDEVFS_CAP_BULK_CONTINUATION 0x02 /* Not available on all devs! */
> +#define USBDEVFS_CAP_NO_PACKET_SIZE_LIM 0x04
If there really are going to be 64 bits worth of these things,
shouldn't they be defined like
0x0000000000000001
and so on? Or maybe a little easier to read:
(1ull << 0)
etc.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
