Hi Vinicius,
On Fri, Aug 24, 2012, Vinicius Costa Gomes wrote:
> With the HCI_SETUP patches, this is all that is needed to make the
> case when a adapter is added with Bluetooth blocked in rfkill to work.
>
> When rfkill is unblocked, the device will be powered on if the device
> is in HCI_SETUP state, meaning that it was never properly initialized.
> If the device is not used by userspace, the HCI_AUTO_OFF flag will
> take care of powering it off.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@xxxxxxxxxxxxx>
> ---
> net/bluetooth/hci_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index fa974a1..ef69d8b 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1061,8 +1061,10 @@ static int hci_rfkill_set_block(void *data, bool blocked)
>
> BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
>
> - if (!blocked)
> + if (!blocked && test_bit(HCI_SETUP, &hdev->dev_flags)) {
> + schedule_work(&hdev->power_on);
> return 0;
> + }
>
> hci_dev_do_close(hdev);
This still isn't right. Now you'd be calling hci_dev_do_close() when
unblocking a device that doesn't have HCI_SETUP set. The test_bit needs
to be inside the if-branch. Btw, this all implies that you're not
properly testing your patches. Please always do that.
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
