| Message ID | 20200802042138.9149-1-hui.wang@canonical.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Bluetooth: btusb: Add a module parameter ignore_id for debugging | expand |
Hi Hui, > There is always an on-board usb bluetooth hci on the laptops, if > the bluetooth function doesn't work well like a bt headset can't work > with HSP/HFP mode, we often plug an external usb BT hci to verify if > that headset could work with the exteral BT hci or not, in this > situation, there will be 2 hcis (hci0 and hci1) in the system, and > so far, the gnome can't handle the hci1 well so we met lots of > problems when debugging with hci1 under gnome. > > After adding this new module parameter, we could ban the on-board > usb hci by putting btusb.ignore_id=idVendor,idProduct to the bootargs, > then the external usb hci will be hci0 and there is only one hci > in the system. We could easily debug with the external usb bluetooth > hci after this change. > > Signed-off-by: Hui Wang <hui.wang@canonical.com> > --- > drivers/bluetooth/btusb.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) please use this instead. echo “vvvv pppp 0 08fd 0002" > /sys/bus/usb/drivers/foo/new_id Regards Marcel
On 2020/8/2 下午10:58, Marcel Holtmann wrote: > Hi Hui, > >> There is always an on-board usb bluetooth hci on the laptops, if >> the bluetooth function doesn't work well like a bt headset can't work >> with HSP/HFP mode, we often plug an external usb BT hci to verify if >> that headset could work with the exteral BT hci or not, in this >> situation, there will be 2 hcis (hci0 and hci1) in the system, and >> so far, the gnome can't handle the hci1 well so we met lots of >> problems when debugging with hci1 under gnome. >> >> After adding this new module parameter, we could ban the on-board >> usb hci by putting btusb.ignore_id=idVendor,idProduct to the bootargs, >> then the external usb hci will be hci0 and there is only one hci >> in the system. We could easily debug with the external usb bluetooth >> hci after this change. >> >> Signed-off-by: Hui Wang <hui.wang@canonical.com> >> --- >> drivers/bluetooth/btusb.c | 11 +++++++++++ >> 1 file changed, 11 insertions(+) > please use this instead. > > echo “vvvv pppp 0 08fd 0002" > /sys/bus/usb/drivers/foo/new_id Thanks, but to run the command above, the system should boot up first. After the system boot up, the btusb is already loaded and and the on-board hci is already driven by btusb. looks like it is too late to run that command for on-board hci. Thanks, Hui. > > Regards > > Marcel >
Hi Hui, >>> There is always an on-board usb bluetooth hci on the laptops, if >>> the bluetooth function doesn't work well like a bt headset can't work >>> with HSP/HFP mode, we often plug an external usb BT hci to verify if >>> that headset could work with the exteral BT hci or not, in this >>> situation, there will be 2 hcis (hci0 and hci1) in the system, and >>> so far, the gnome can't handle the hci1 well so we met lots of >>> problems when debugging with hci1 under gnome. >>> >>> After adding this new module parameter, we could ban the on-board >>> usb hci by putting btusb.ignore_id=idVendor,idProduct to the bootargs, >>> then the external usb hci will be hci0 and there is only one hci >>> in the system. We could easily debug with the external usb bluetooth >>> hci after this change. >>> >>> Signed-off-by: Hui Wang <hui.wang@canonical.com> >>> --- >>> drivers/bluetooth/btusb.c | 11 +++++++++++ >>> 1 file changed, 11 insertions(+) >> please use this instead. >> >> echo “vvvv pppp 0 08fd 0002" > /sys/bus/usb/drivers/foo/new_id > > Thanks, but to run the command above, the system should boot up first. After the system boot up, the btusb is already loaded and and the on-board hci is already driven by btusb. looks like it is too late to run that command for on-board hci. then unload the module first or blacklist the module. Regards Marcel
On 2020/8/3 下午2:45, Marcel Holtmann wrote: > Hi Hui, > >>>> There is always an on-board usb bluetooth hci on the laptops, if >>>> the bluetooth function doesn't work well like a bt headset can't work >>>> with HSP/HFP mode, we often plug an external usb BT hci to verify if >>>> that headset could work with the exteral BT hci or not, in this >>>> situation, there will be 2 hcis (hci0 and hci1) in the system, and >>>> so far, the gnome can't handle the hci1 well so we met lots of >>>> problems when debugging with hci1 under gnome. >>>> >>>> After adding this new module parameter, we could ban the on-board >>>> usb hci by putting btusb.ignore_id=idVendor,idProduct to the bootargs, >>>> then the external usb hci will be hci0 and there is only one hci >>>> in the system. We could easily debug with the external usb bluetooth >>>> hci after this change. >>>> >>>> Signed-off-by: Hui Wang <hui.wang@canonical.com> >>>> --- >>>> drivers/bluetooth/btusb.c | 11 +++++++++++ >>>> 1 file changed, 11 insertions(+) >>> please use this instead. >>> >>> echo “vvvv pppp 0 08fd 0002" > /sys/bus/usb/drivers/foo/new_id >> Thanks, but to run the command above, the system should boot up first. After the system boot up, the btusb is already loaded and and the on-board hci is already driven by btusb. looks like it is too late to run that command for on-board hci. > then unload the module first or blacklist the module. Sorry, still don't understand. After unload/blacklist the module, there will be no /sys/bus/usb/drivers/foo/new_id. Once we load the module, the on-board hci will be driven by the module immediately. Looks like setting new_id is only useful for USB dongles, for on-board usb devices, I have no idea how to use the new_id. Thanks, Hui. > > Regards > > Marcel >
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 5f022e9cf667..f6ab0cb313ed 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -32,6 +32,7 @@ static bool force_scofix; static bool enable_autosuspend = IS_ENABLED(CONFIG_BT_HCIBTUSB_AUTOSUSPEND); static bool reset = true; +static u16 ignore_id[2]; static struct usb_driver btusb_driver; @@ -3714,11 +3715,17 @@ static int btusb_probe(struct usb_interface *intf, struct gpio_desc *reset_gpio; struct btusb_data *data; struct hci_dev *hdev; + struct usb_device *dev; unsigned ifnum_base; int i, err; BT_DBG("intf %p id %p", intf, id); + dev = interface_to_usbdev(intf); + if (ignore_id[0] == le16_to_cpu(dev->descriptor.idVendor) && + ignore_id[1] == le16_to_cpu(dev->descriptor.idProduct)) + return -ENODEV; + /* interface numbers are hardcoded in the spec */ if (intf->cur_altsetting->desc.bInterfaceNumber != 0) { if (!(id->driver_info & BTUSB_IFNUM_2)) @@ -4273,6 +4280,10 @@ MODULE_PARM_DESC(enable_autosuspend, "Enable USB autosuspend by default"); module_param(reset, bool, 0644); MODULE_PARM_DESC(reset, "Send HCI reset command on initialization"); +module_param_array(ignore_id, ushort, NULL, 0644); +MODULE_PARM_DESC(ignore_id, "btusb will ignore this device if the id matches." + " e.g. ignore_id=idVendor,idProduct"); + MODULE_AUTHOR("Marcel Holtmann <marcel@holtmann.org>"); MODULE_DESCRIPTION("Generic Bluetooth USB driver ver " VERSION); MODULE_VERSION(VERSION);
There is always an on-board usb bluetooth hci on the laptops, if the bluetooth function doesn't work well like a bt headset can't work with HSP/HFP mode, we often plug an external usb BT hci to verify if that headset could work with the exteral BT hci or not, in this situation, there will be 2 hcis (hci0 and hci1) in the system, and so far, the gnome can't handle the hci1 well so we met lots of problems when debugging with hci1 under gnome. After adding this new module parameter, we could ban the on-board usb hci by putting btusb.ignore_id=idVendor,idProduct to the bootargs, then the external usb hci will be hci0 and there is only one hci in the system. We could easily debug with the external usb bluetooth hci after this change. Signed-off-by: Hui Wang <hui.wang@canonical.com> --- drivers/bluetooth/btusb.c | 11 +++++++++++ 1 file changed, 11 insertions(+)