On Fri, 29 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)
> +{
> + __u32 caps = 0;
> +
> + caps |= USBDEVFS_CAP_ZERO_PACKET | USBDEVFS_CAP_NO_PACKET_SIZE_LIM;
I'd still prefer to get rid of the "= 0" initializer and change this
"|=" to simply "=". It's not a big deal though; if the compiler is
smart enough it optimize away the first assignment anyhow.
> --- a/include/linux/usbdevice_fs.h
> +++ b/include/linux/usbdevice_fs.h
> @@ -125,6 +125,11 @@ struct usbdevfs_hub_portinfo {
> char port [127]; /* e.g. port 3 connects to device 27 */
> };
>
> +/* Device capability flags */
> +#define USBDEVFS_CAP_ZERO_PACKET 0x01
> +#define USBDEVFS_CAP_BULK_CONTINUATION 0x02
> +#define USBDEVFS_CAP_NO_PACKET_SIZE_LIM 0x04
This raises an interesting question. What happens if someone tries to
compile a program for an up-to-date kernel but under an old userspace?
These definitions won't be present in /usr/include/linux/.
But I guess the same sort of thing happens whenever the kernel's ABI is
updated...
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
