Hi Johan,
>>>>> 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)
>>
>> we could be a bit smarter about the error code here. At least when
>> ERFKILL we should return a more descriptive error via mgmt.
>
> I'm fine with that, and I actually left room for it by passing the exact
> error to the new mgmt_set_powered_failed function. Would you prefer a
> completely new error only used for rfkill or reuse one of our existing
> errors. We've e.g. got MGMT_STATUS_REJECTED which could be used for
> rfkill and MGMT_STATUS_FAILED for anything else.
I think a brand new error might be a good idea. RFKILL has always been special.
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
