Re: [PATCH] usb: Export BOS descriptor to sysfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-03-01 06:18, Greg KH wrote:
On Thu, Feb 29, 2024 at 03:59:05PM -0800, Elbert Mai wrote:
Motivation
----------

The kernel already retrieves and caches the binary device object store
(BOS) descriptor from USB devices it enumerates. Export this descriptor to userspace via sysfs, so users do not need to open the USB device with the
correct permissions and requesting the descriptor themselves.

A BOS descriptor contains a set of device capability descriptors. One that is of interest to users is the platform descriptor. This contains a 128-bit UUID and arbitrary data. The descriptor allows parties outside of USB-IF to add additional metadata about a device in a standards-compliant manner.

Notable examples include the WebUSB and Microsoft OS 2.0 descriptors. Of course, there could be more. By exporting the entire BOS descriptor we can handle these and all future device capabilities. In addition, tools like udev can match rules on device capabilities in the BOS without requiring
additional I/O with the USB device.

But this requires that userspace parse the raw descriptor, right?  Why
not also export the descriptor information in simpler form through
different sysfs files as well so that scripts can read this information
easily?

That's not to say we don't also want this binary file, just maybe add
more?

I've thought about this for a while, but IMHO it doesn't seem possible to
present the BOS in a simpler form like how it's done for the device and
configuration descriptors. The BOS was explicitly designed to be flexible and extensible, and it's hard to make a "rich" sysfs interface around that.

We could have a platform_uuids file that lists all platform UUIDs in the BOS. These could be presented in RFC 4122 string format, each separated by some delimiter. This would make it possible to write a udev rule that matches a particular UUID via a glob pattern. This seems like a rather inelegant way
of handling this, IMHO.

With regards to parsing raw descriptors in userspace, this already happens at least with udev. About a dozen files in /usr/lib/udev/rules.d invoke a built-in program called "usb_id", which opens the descriptors binary file
(among other files in sysfs) and parses it for interface information.

I think users and scripts interested in reading the BOS are best served with userspace tools that can parse the BOS and present it in a convenient textual format of their choosing. Having bos_descriptor in sysfs makes this possible without needing elevated permissions or USB I/O. But I could be mistaken in
this regard.

Implementation
--------------

Add bos_descriptor file to sysfs. This is a binary file and it works the same way as the existing descriptors file. The file exists even if a device does not have a BOS descriptor (the file will be empty in this case). This allows users to detect if the kernel supports reading the BOS via sysfs and
fall back to direct USB I/O if needed.

This is nice, but can you only create the file if it actually is
present?  Use the is_visible callback to determine this, having an
"empty" binary sysfs file isn't that nice.

Of course, I can make that happen.

Other tiny review comments below:

Signed-off-by: Elbert Mai <code@xxxxxxxxxxxxx>
---
 Documentation/ABI/testing/sysfs-bus-usb |  9 +++++++
drivers/usb/core/sysfs.c | 35 ++++++++++++++++++++++++-
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index 614d216dff1d..bfffaa752a13 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -293,3 +293,12 @@ Description:
 		USB 3.2 adds Dual-lane support, 2 rx and 2 tx -lanes over Type-C.
 		Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes per
 		direction. Devices before USB 3.2 are single lane (tx_lanes = 1)
+
+What:		/sys/bus/usb/devices/.../bos_descriptor
+Date:		March 2024
+Contact:	Elbert Mai <code@xxxxxxxxxxxxx>
+Description:
+		Binary file containing the cached binary device object store (BOS)
+		descriptor of the device. This file is empty if the BOS descriptor
+		is not present. The kernel will not request a BOS descriptor from
+		the device if its bcdUSB value is less than 0x0201.
diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index a2ca38e25e0c..208d2f8cde2d 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -901,7 +901,7 @@ read_descriptors(struct file *filp, struct kobject *kobj,
 			srclen = sizeof(struct usb_device_descriptor);
 		} else {
 			src = udev->rawdescriptors[cfgno];
-			srclen = __le16_to_cpu(udev->config[cfgno].desc.
+			srclen = le16_to_cpu(udev->config[cfgno].desc.

Why is this line changed?

Consistency with the rest of the file. This was the only instance of __le16_to_cpu,
other lines used le16_to_cpu (no underscores).

 					wTotalLength);
 		}
 		if (off < srclen) {
@@ -923,6 +923,34 @@ static struct bin_attribute dev_bin_attr_descriptors = {
 	.size = 18 + 65535,	/* dev descr + max-size raw descriptor */
 };

+static ssize_t
+read_bos_descriptor(struct file *filp, struct kobject *kobj,
+		struct bin_attribute *attr,
+		char *buf, loff_t off, size_t count)
+{
+	struct device *dev = kobj_to_dev(kobj);
+	struct usb_device *udev = to_usb_device(dev);
+	struct usb_host_bos *bos = udev->bos;
+	struct usb_bos_descriptor *desc;
+	size_t desclen, n = 0;
+
+	if (bos) {
+		desc = bos->desc;
+		desclen = le16_to_cpu(desc->wTotalLength);
+		if (off < desclen) {
+			n = min(count, desclen - (size_t) off);
+			memcpy(buf, (void *) desc + off, n);
+		}
+	}
+	return n;

If bos is not present an error should return, not 0, right?

The interface_show function in sysfs.c returns 0 if the string describing
the interface is not present, so I did it the same way. Should I instead
return -ENOENT or some other specific error code?

+}
+
+static struct bin_attribute dev_bin_attr_bos_descriptor = {
+	.attr = {.name = "bos_descriptor", .mode = 0444},
+	.read = read_bos_descriptor,

Isn't there a mscro for all of this?

It turns out there is, called BIN_ATTR_RO in in linux/sysfs.h. I'm not sure
why the original code didn't use it for read_descriptors. I can change
both instances to shorten the code.

+	.size = 65535,	/* max-size BOS descriptor */

Do we know the size of the descriptor at runtime?  Ideally we would set
it to be that, not an unknown size that way userspace knows what needs
to be read.  But that's not really a big deal, if it's not possible, as
the other USB binary descriptor does much the same.

We do know the size via wTotalLength, but that varies between USB devices and dev_bin_attr_bos_descriptor is a static variable. So not really possible
unless we dynamically allocate all the attribute structs.

+};

This should go into an attribute group with the other descriptor, making
the rest of the patch not needed and simpler.

Will do. I'm in favor of simpler patches.

+
 /*
  * Show & store the current value of authorized_default
  */
@@ -1042,6 +1070,10 @@ int usb_create_sysfs_dev_files(struct usb_device *udev)
 	if (retval)
 		goto error;

+	retval = device_create_bin_file(dev, &dev_bin_attr_bos_descriptor);
+	if (retval)
+		goto error;
+

long-term I'd like to get rid of the individual "add and remove" sysfs
files in this function, and just use the default groups instead so the
driver core handles it.  It's not an issue here for this change, but if
you can find a way to work on that as part of a patch series here, I
think that would be really good (if possible, not a requirement.)

I'll see what I can do. I'll go for at least the low-hanging fruit.

thanks!

greg k-h

And thank you for taking the time to review this patch!

-Elbert




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux