Hi Sukumar, > BT-Controller connected as platform non-root-hub device and > usb-driver initialize such device with wakeup disabled, > Ref. usb_new_device(). > > At present wakeup-capability get enabled by hid-input device from usb > function driver(e.g. BT HID device) at runtime. Again some functional > driver does not set usb-wakeup capability(e.g LE HID device implement > as HID-over-GATT), and can't wakeup the host on USB. > > Hence usb-wakeup capability enable form btusc driver as a generic > solution for multiple profile usecase and required for USB remote > wakeup (in-bus wakeup) while host is suspended. > > Signed-off-by: Sukumar Ghorai <sukumar.ghorai@xxxxxxxxx> > Signed-off-by: Amit K Bag <amit.k.bag@xxxxxxxxx># > --- > drivers/bluetooth/btusb.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c > index e1124ba44154..7eeeeb6ffae6 100644 > --- a/drivers/bluetooth/btusb.c > +++ b/drivers/bluetooth/btusb.c > @@ -1083,6 +1083,10 @@ static int btusb_open(struct hci_dev *hdev) > } > > data->intf->needs_remote_wakeup = 1; > + /* device specific wakeup source enabled and required for USB > + * remote wakeup while host is suspended > + */ > + device_init_wakeup(&data->udev->dev, true); > is this the right location? Are we repeating this on every hciconfig up / btmgmt poweron operation? Or is this something that should be actually happen only once during USB probe callback? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
