linux-kernel - Re: [PATCH v1 1/1] Bluetooth: hci_qca: Add poweroff support during hci down for wcn3990

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c9dd1f73c513a676738a47dd65ffce8@codeaurora.org>
Date:   Fri, 24 Aug 2018 16:11:26 +0530
From:   Balakrishna Godavarthi <bgodavar@...eaurora.org>
To:     Stephen Boyd <swboyd@...omium.org>
Cc:     johan.hedberg@...il.com, marcel@...tmann.org, mka@...omium.org,
        linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org,
        hemantg@...eaurora.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v1 1/1] Bluetooth: hci_qca: Add poweroff support during
 hci down for wcn3990

Hi Stephen,

On 2018-08-24 12:17, Stephen Boyd wrote:
> Quoting Balakrishna Godavarthi (2018-08-23 04:29:35)
>> This patch enables power off support for hci down and power on support
>> for hci up. As wcn3990 power sources are ignited by regulators, we 
>> will
>> turn off them during hci down, i.e. an complete power off of wcn3990.
>> So while hci up, we will call vendor specific open/close and setup 
>> which
>> will turn on the regulators, requests BT chip version and download the
>> firmware.
>> 
>> Signed-off-by: Balakrishna Godavarthi <bgodavar@...eaurora.org>
>> ---
>>  drivers/bluetooth/hci_qca.c | 34 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 34 insertions(+)
>> 
>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> index e182f6019f68..98d33c6b8909 100644
>> --- a/drivers/bluetooth/hci_qca.c
>> +++ b/drivers/bluetooth/hci_qca.c
>> @@ -595,6 +595,9 @@ static int qca_close(struct hci_uart *hu)
>>         struct qca_serdev *qcadev;
>>         struct qca_data *qca = hu->priv;
>> 
>> +       if (!qca)
>> +               return 0;
> 
> Does this happen? If it does it seems like a failure in the caller to
> know what's going on.

[Bala]: yes qca_close() function will execute twice i.e. when we remove 
the BT module.

         while we remove the module,hci_dev_doc_close() will call 
hdev->close() i.e. hci_uart_close() which is Qualcomm specific close.
         in hci_uart_close() we will call qca_close() which will free the 
memory.
         after that proto close will also call qca_close().
         Here hci_uart_close and proto close are assigned to same 
function pointer i.e. qca_close().

-- 
Regards
Balakrishna.