Return-Path: Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [BUG] Set Powered=true doesn't power up the adapter From: Marcel Holtmann In-Reply-To: <20130528074906.GA32404@x220.ger.corp.intel.com> Date: Tue, 28 May 2013 17:09:56 +0900 Cc: Vinicius Costa Gomes , BlueZ development Message-Id: <9A028387-F030-4C5C-B1AE-5B50221E18B2@holtmann.org> 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> <20130528074906.GA32404@x220.ger.corp.intel.com> To: Johan Hedberg Sender: linux-bluetooth-owner@vger.kernel.org List-ID: 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