On Tue, Feb 18, 2025 at 12:24:07PM +0800, Hsin-chen Chuang wrote:

Hi Greg,

On Mon, Feb 17, 2025 at 4:53 PM Greg KH [off-list ref] wrote:

quoted

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

quoted

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!)

I think changing the alternate setting should work using usbfs as you
would send that command to the device, not the interface, so the driver
bound to the existing interface would not need to be removed.

I thought USBDEVFS_SETINTERFACE was the right command to begin with,
but it seems not working in this case.
The command itself attempts to claim the interface, but the interface
is already claimed by btusb so it failed with Device or resource busy

drivers/usb/core/devio.c:
  USBDEVFS_SETINTERFACE -> proc_setintf -> checkintf -> claimintf

Ah, ok, thanks for checking.  So as you control this device, why not
just disconnect it, change the setting, and then reconnect it?

Also, see my other review comment, how does BlueZ do this today?

thanks,

greg k-h