Return-Path: Date: Tue, 28 May 2013 10:49:06 +0300 From: Johan Hedberg To: Marcel Holtmann Cc: Vinicius Costa Gomes , BlueZ development Subject: Re: [BUG] Set Powered=true doesn't power up the adapter Message-ID: <20130528074906.GA32404@x220.ger.corp.intel.com> References: <61DC8CEB-C49A-466F-B5E3-F5B60D398157@holtmann.org> <20130522172213.GA12160@samus.indt.org> <1E509939-3804-43E0-A047-09CCD38A4713@holtmann.org> <20130528071306.GA31172@x220> <16EC52EF-CEB3-40B5-BDD3-6D6BE35FF177@holtmann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <16EC52EF-CEB3-40B5-BDD3-6D6BE35FF177@holtmann.org> Sender: linux-bluetooth-owner@vger.kernel.org List-ID: 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