Hi Bing,
>> You're right that we're missing the clearing of the HCI_SETUP flag for
>> such a scenario. Could you try the attached patch. It should fix the
>
> We have tested your patch. Yes, it fixes the problem. Thanks!
then lets get a proper version with full commit message explaining the issue merged upstream. As I said, this is a real bug we need to fix.
>> issue. One problem that it does have is that if the HCIDEVUP ioctl path
>> goes through before hci_power_on gets called we will never notify mgmt
>> of the adapter. However, that might be acceptable here since if you're
>> using HCIDEVUP like this it seems it's not a mgmt based system anyway.
>
> Do you think the following change helps?
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 3d9f02b..24814b0 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1665,7 +1665,7 @@ static void hci_power_on(struct work_struct *work)
> BT_DBG("%s", hdev->name);
>
> err = hci_dev_open(hdev->id);
> - if (err < 0) {
> + if (err < 0 && err != -EALREADY) {
> mgmt_set_powered_failed(hdev, err);
> return;
> }
I am more and more convinced that we might just need to disable certain ioctl in case there is a mgmt socket/client present and HCI_MGMT is set. Trying to be graceful with legacy ioctl that BlueZ 5 will never use anymore seems to come at a too high cost. I rather fail on the legacy commands with a proper error than having mgmt interface behave inconsistent.
We might actually be able to keep HCIDEVUP and HCIDEVDOWN around, but then they need to behave like mgmt set powered command. So both commands need to go through the same mgmt engine for this.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
