Messages in this thread | | | Date | Tue, 06 Nov 2018 18:14:41 +0530 | From | Balakrishna Godavarthi <> | Subject | Re: [PATCH v1 3/4] Bluetooth: hci_qca: clear HCI_QUIRK_RESET_ON_CLOSE flag |
| |
Hi Marcel,
On 2018-11-06 18:03, Marcel Holtmann wrote: > Hi Balakrishna, > >> During hci down we are sending reset command to chip, which >> is not required for wcn3990, as hdev->shutdown() will turn off the >> regulators. >> >> Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> >> --- >> drivers/bluetooth/hci_qca.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >> index 8301663f0004..97b57e0f4725 100644 >> --- a/drivers/bluetooth/hci_qca.c >> +++ b/drivers/bluetooth/hci_qca.c >> @@ -1190,6 +1190,7 @@ static int qca_setup(struct hci_uart *hu) >> */ >> set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks); >> set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks); >> + clear_bit(HCI_QUIRK_RESET_ON_CLOSE, &hdev->quirks); >> hu->hdev->shutdown = qca_power_off; >> ret = qca_wcn3990_init(hu); >> if (ret) > > I am pretty certain that you didn’t want this quirk: > > /* When this quirk is set, the HCI Reset command is send when > > * closing the transport instead of when opening it. > > This quirk is for Bluetooth 1.0b devices where the HCI_Reset behavior > was not clear or for devices that actually misbehave with the initial > HCI_Reset. > > In addition, you commit message is totally misleading. That is not > what is happening with this quirk. > > Regards > > Marcel
My intention was reset command is not required when we do an hci down. this is because of hdev->shutdown will turn off the regulators. It is like turning off the chip. sending reset command after turning off the chip is not required.
I understand the usage of the quirk, will update the commit text.
-- Regards Balakrishna.
| |