linux-kernel - Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until

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]

Date:   Wed, 14 Nov 2018 11:59:52 +0530
From:   Balakrishna Godavarthi <bgodavar@...eaurora.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     marcel@...tmann.org, johan.hedberg@...il.com,
        linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org,
        hemantg@...eaurora.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for
 power pulses

Hi Matthias,

On 2018-11-14 05:47, Matthias Kaehlcke wrote:
> On Tue, Nov 06, 2018 at 05:35:25PM +0530, Balakrishna Godavarthi wrote:
>> wcn3990 requires a power pulse to turn ON/OFF along with
>> regulators. Sometimes we are observing the power pulses are sent
>> out with some time delay, due to queuing these commands. This is
>> causing synchronization issues with chip, which intern delay the
>> chip setup or may end up with communication issues.
>> 
>> Signed-off-by: Balakrishna Godavarthi <bgodavar@...eaurora.org>
>> ---
>>  drivers/bluetooth/hci_qca.c | 22 +++++++++-------------
>>  1 file changed, 9 insertions(+), 13 deletions(-)
>> 
>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> index f72ded4ec9ae..051f081d1835 100644
>> --- a/drivers/bluetooth/hci_qca.c
>> +++ b/drivers/bluetooth/hci_qca.c
>> @@ -1016,8 +1016,7 @@ static inline void host_set_baudrate(struct 
>> hci_uart *hu, unsigned int speed)
>>  static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
>>  {
>>  	struct hci_uart *hu = hci_get_drvdata(hdev);
>> -	struct qca_data *qca = hu->priv;
>> -	struct sk_buff *skb;
>> +	int ret;
>> 
>>  	/* These power pulses are single byte command which are sent
>>  	 * at required baudrate to wcn3990. On wcn3990, we have an external
>> @@ -1030,18 +1029,14 @@ static int qca_send_power_pulse(struct hci_dev 
>> *hdev, u8 cmd)
>>  	 * sending power pulses to SoC.
>>  	 */
>>  	bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
>> -
>> -	skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
>> -	if (!skb)
>> -		return -ENOMEM;
>> -
>>  	hci_uart_set_flow_control(hu, true);
>> +	ret = serdev_device_write(hu->serdev, &cmd, sizeof(cmd), 0);
>> +	if (ret < 0) {
>> +		bt_dev_err(hdev, "failed to send power pulse %02x to SoC", cmd);
>> +		return ret;
>> +	}
>> 
>> -	skb_put_u8(skb, cmd);
>> -	hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
>> -
>> -	skb_queue_tail(&qca->txq, skb);
>> -	hci_uart_tx_wakeup(hu);
>> +	serdev_device_wait_until_sent(hu->serdev, 0);
>> 
>>  	/* Wait for 100 uS for SoC to settle down */
>>  	usleep_range(100, 200);
> 
> Is the delay still needed now that we wait for the pulse to be sent? I
> didn't observe any problems without it in a few dozens of iterations.
> 
[Bala]: chip require some time to boot up
         so this delay will helps us to be in sync with the chip. for now
         we will go with this delay, if really required we can change 
100us to some where
         around 10us.

>> @@ -1283,7 +1278,8 @@ static void qca_power_shutdown(struct hci_uart 
>> *hu)
>> 
>>  	host_set_baudrate(hu, 2400);
>>  	hci_uart_set_flow_control(hu, true);
>> -	serdev_device_write_buf(serdev, &cmd, sizeof(cmd));
>> +	serdev_device_write(serdev, &cmd, sizeof(cmd), 0);
>> +	serdev_device_wait_until_sent(serdev, 0);
>>  	hci_uart_set_flow_control(hu, false);
> 
> You could call qca_send_power_pulse(hdev, QCA_WCN3990_POWEROFF_PULSE)
> instead, as an earlier patch set did before skbs were used to send the
> power pulse.
> 

[Bala]: will update.

> You can also consider to set the baudrate in qca_send_power_pulse()
> depending on the power pulse. On the plus side this would reduce a bit
> of clutter in the callers of qca_send_power_pulse(), on the negative
> side it would be harder to follow when baudrate changes occur (not
> sure this is a problem). Up to you, just an idea.
> 
[Bala]:  moving bd change request to power_pulse has both plus & minus 
side.
          but my opinion is let us we leave qca_send_power_pulse() to be 
generic
          might be feature chip will use the same function with an 
different bd.

> Thanks
> 
> Matthias

-- 
Regards
Balakrishna.