linux-kernel - Re: [PATCH v3] bluetooth: hci_qca: Fix qca6390 enable failure after warm reboot

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: <20200528154426.GJ4525@google.com>
Date:   Thu, 28 May 2020 08:44:26 -0700
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Zijun Hu <zijuhu@...eaurora.org>
Cc:     marcel@...tmann.org, johan.hedberg@...il.com,
        linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, bgodavar@...eaurora.org,
        c-hbandi@...eaurora.org, hemantg@...eaurora.org,
        rjliao@...eaurora.org
Subject: Re: [PATCH v3] bluetooth: hci_qca: Fix qca6390 enable failure after
 warm reboot

On Thu, May 28, 2020 at 01:04:25PM +0800, Zijun Hu wrote:
> 
> 
> On 5/28/2020 12:48 AM, Matthias Kaehlcke wrote:
> > Hi Zijun,
> > 
> > On Wed, May 27, 2020 at 10:32:39AM +0800, Zijun Hu wrote:
> >> Warm reboot can not restore qca6390 controller baudrate
> >> to default due to lack of controllable BT_EN pin or power
> >> supply, so fails to download firmware after warm reboot.
> >>
> >> Fixed by sending EDL_SOC_RESET VSC to reset controller
> >> within added device shutdown implementation.
> >>
> >> Signed-off-by: Zijun Hu <zijuhu@...eaurora.org>
> >> ---
> >>  drivers/bluetooth/hci_qca.c | 29 +++++++++++++++++++++++++++++
> >>  1 file changed, 29 insertions(+)
> >>
> >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> >> index e4a6823..4b6f8b6 100644
> >> --- a/drivers/bluetooth/hci_qca.c
> >> +++ b/drivers/bluetooth/hci_qca.c
> >> @@ -1975,6 +1975,34 @@ static void qca_serdev_remove(struct serdev_device *serdev)
> >>  	hci_uart_unregister_device(&qcadev->serdev_hu);
> >>  }
> >>  
> >> +static void qca_serdev_shutdown(struct device *dev)
> >> +{
> >> +	int ret;
> >> +	int timeout = msecs_to_jiffies(CMD_TRANS_TIMEOUT_MS);
> >> +	struct serdev_device *serdev = to_serdev_device(dev);
> >> +	struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev);
> >> +	const u8 ibs_wake_cmd[] = { 0xFD };
> >> +	const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 };
> >> +
> >> +	if (qcadev->btsoc_type == QCA_QCA6390) {
> >> +		serdev_device_write_flush(serdev);
> >> +		serdev_device_write_buf(serdev,
> >> +				ibs_wake_cmd, sizeof(ibs_wake_cmd));
> >> +		serdev_device_wait_until_sent(serdev, timeout);
> > 
> > Why no check of the return value of serdev_device_write_buf() here,
> > does it make sense to continue if sending the wakeup command failed?
> > 
> i will correct it at v4 patch
> > Couldn't serdev_device_write() be used instead of the _write_buf() +
> > _wait_until_sent() combo?
> > 
> i don't think so, serdev_device_write() is not appropriate at here.
> serdev_device_write_wakeup() should be used to release completion hold
> by serdev_device_write(), however @hci_serdev_client_ops doesn't use
> serdev_device_write_wakeup() to implement its write_wakeup operation.
> we don't want to touch common hci_serdev.c code.

Thanks for the clarification!

> >> +		usleep_range(8000, 10000);
> >> +
> >> +		serdev_device_write_flush(serdev);
> > 
> > I suppose the flush is done because _wait_until_sent() could have timed out.
> > Another reason to use _device_write() (if suitable), since it returns
> > -ETIMEDOUT in that case?
> >
> flush is prefixed at write operation to speed up
> shutdown procedure in case of unexpected data injected
> during waiting for controller wakeup.

hm, wouldn't it be a bug if unexpected data is injected during shutdown? It
seems it would be better to detect such a problem and fix the root cause,
rather than papering over it.

Also, a flush doesn't really guarantee that there is no unexpected data when
serdev_device_write_buf() is called, it could be injected just after returning
from _flush().