Hi Marcel,
On Wed, May 22, 2013, Marcel Holtmann wrote:
> > If I send any Set Powered command after the controller is unblocked, while
> > there's still one pending command in the queue, this command will fail, and I
> > won't be able to bring the controller up, unless I force a HCI_RESET command.
> >
> > So it seems that we need a way to mark an hdev as rfkill blocked.
> >
> > Does anyone else have any other ideas?
>
> my wild guess right now is that this is the problem:
>
> static void hci_power_on(struct work_struct *work)
> {
> struct hci_dev *hdev = container_of(work, struct hci_dev, power_on);
>
> BT_DBG("%s", hdev->name);
>
> if (hci_dev_open(hdev->id) < 0)
> return;
>
> if (test_bit(HCI_AUTO_OFF, &hdev->dev_flags))
> queue_delayed_work(hdev->req_workqueue, &hdev->power_off,
> HCI_AUTO_OFF_TIMEOUT);
>
> if (test_and_clear_bit(HCI_SETUP, &hdev->dev_flags))
> mgmt_index_added(hdev);
> }
>
> In case hci_dev_open() fails and rfkill would be one example for that,
> we do not return an error back to the mgmt command that originates
> this power on.
>
> Of course there is the initial adapter power on and there is the mgmt
> triggered power on. And my guess is that these two are racing against
> each other.
It seems you're right about the cause. I just sent a patch to fix it.
With the patch I get this behavior:
jh@qemu~/src/bluez{master}$ sudo rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
jh@qemu~/src/bluez{master}$ sudo rfkill block 0
jh@qemu~/src/bluez{master}$ sudo tools/btmgmt power on
Set Powered for hci0 failed with status 0x03 (Failed)
Johan
--
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
