Re: [BUG] Set Powered=true doesn't power up the adapter

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Marcel,

On Tue, May 28, 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)
> 
> 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.

Johan