On Mon, Feb 17, 2025 at 04:44:35PM +0800, Hsin-chen Chuang wrote:

On Fri, Feb 14, 2025 at 7:37 PM Greg KH [off-list ref] wrote:

quoted

On Fri, Feb 14, 2025 at 07:16:17PM +0800, Hsin-chen Chuang wrote:

quoted

From: Hsin-chen Chuang <redacted>

Expose the isoc_alt attr with device group to avoid the racing.

Now we create a dev node for btusb. The isoc_alt attr belongs to it and
it also becomes the parent device of hci dev.

Fixes: b16b327edb4d ("Bluetooth: btusb: add sysfs attribute to control USB alt setting")

Wait, step back, why is this commit needed if you can change the alt
setting already today through usbfs/libusb without needing to mess with
the bluetooth stack at all?

In short: We want to configure the alternate settings without
detaching the btusb driver, while detaching seems necessary for
libusb_set_interface_alt_setting to work (Please correct me if I'm
wrong!)

Background:
The Bluetooth Core Specification defines a protocol for the operating
system to communicate with a Bluetooth chipset, called HCI (Host
Controller Interface) (Host=OS, Controller=chipset).
We could say the main purpose of the Linux Bluetooth drivers is to set
up and get the HCI ready for the "upper layer" to use.

Who could be the "upper layer" then? There are mainly 2: "Control" and
"User" channels.
Linux has its default Bluetooth stack, BlueZ, which is splitted into 2
parts: the kernel space and the user space. The kernel space part
provides an abstracted Bluetooth API called MGMT, and is exposed
through the Bluetooth HCI socket "Control" channel.
On the other hand Linux also exposes the Bluetooth HCI socket "User"
channel, allowing the user space APPs to send/receive the HCI packets
directly to/from the chipset. Google's products (Android, ChromeOS,
etc) use this channel.

Now why this patch?
It's because the Bluetooth spec defines something specific to USB
transport: A USB Bluetooth chipset must/should support these alternate
settings; When transferring this type of the Audio data this alt must
be used, bla bla bla...
The Control channel handles this in the kernel part. However, the
applications built on top of the User channel are unable to configure
the alt setting, and I'd like to add the support through sysfs.

So the "problem" is that Google doesn't want to use BlueZ, which is
fine, you do you :)

But how does BlueZ handle this same problem today?  What api to the
kernel does it use to change the interface that you can't also do with
your "BlueZ replacement"?

Surely this isn't a new issue suddenly, but if it is, it needs to be
solved so BOTH userspace stacks can handle it.

thanks,

greg k-h