Hi Francesco, Thankyou for the review comment. > > diff --git a/drivers/bluetooth/btnxpuart.c > > b/drivers/bluetooth/btnxpuart.c index 7f88b6f52f26..20a3a5bd5529 > > 100644 > > --- a/drivers/bluetooth/btnxpuart.c > > +++ b/drivers/bluetooth/btnxpuart.c > > @@ -1036,6 +1048,13 @@ static int nxp_setup(struct hci_dev *hdev) > > err = nxp_download_firmware(hdev); > > if (err < 0) > > return err; > > + } else if (!serdev_device_get_cts(nxpdev->serdev)) { > > + /* CTS is high and no bootloader signatures detected */ > > + bt_dev_dbg(hdev, "Controller not detected. Will check again in %d > msec", > > + NXP_SETUP_RETRY_TIME_MS); > > + schedule_delayed_work(&nxpdev->setup_retry_work, > > + msecs_to_jiffies(NXP_SETUP_RETRY_TIME_MS)); > > + return -ENODEV; > why not just > > return -EPROBE_DEFER; > > and remove everything else, no need for any kind of retry or delayed work if > the driver core takes care of it. > Wouldn't returning -EPROBE_DEFER make more sense in driver probe context? Here, the driver probe registers an hci interface (hci_register_dev()), and returns success to kernel. The hci_register_dev() queues hdev->power_on work at the end, which opens the hci dev, and ultimately calls this setup function. In this patch, we are queueing the same work from the delayed setup_retry_work(). Returning -ENODEV (or -EPROBE_DEFER) would only affect hci_dev_open(), which is in power_on work context, and not driver probe context. Perhaps, we should call it hci_retry_power_on() work or something similar? Please let me know your thoughts on this. Thanks, Neeraj