Re: [PATCH v1 1/3] Bluetooth: btnxpuart: fix recv_buf() return value

[Francesco Dolcini <francesco@dolcini.it>]

On Tue, Nov 28, 2023 at 06:23:21AM +0100, Jiri Slaby wrote:
> On 27. 11. 23, 20:14, Francesco Dolcini wrote:
> > From: Francesco Dolcini <francesco.dolcini@toradex.com>
> > 
> > Serdev recv_buf() callback is supposed to return the amount of bytes
> > consumed, therefore an int in between 0 and count.
> > 
> > Do not return negative number in case of issue, just print an error and
> > return count.  This fixes a WARN in ttyport_receive_buf().

...

> >   drivers/bluetooth/btnxpuart.c | 7 +++----
> >   1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> > index b7e66b7ac570..951fe3014a3f 100644
> > --- a/drivers/bluetooth/btnxpuart.c
> > +++ b/drivers/bluetooth/btnxpuart.c
> > @@ -1276,11 +1276,10 @@ static int btnxpuart_receive_buf(struct serdev_device *serdev, const u8 *data,
> >   	if (IS_ERR(nxpdev->rx_skb)) {
> >   		int err = PTR_ERR(nxpdev->rx_skb);
> >   		/* Safe to ignore out-of-sync bootloader signatures */
> > -		if (is_fw_downloading(nxpdev))
> > -			return count;
> > -		bt_dev_err(nxpdev->hdev, "Frame reassembly failed (%d)", err);
> > +		if (!is_fw_downloading(nxpdev))
> > +			bt_dev_err(nxpdev->hdev, "Frame reassembly failed (%d)", err);
> >   		nxpdev->rx_skb = NULL;
> 
> Is this NULLing not needed in the good case?
NULLing in the good case would be a bug, in addition to that NULLing is
not needed at all even in the bad case and it will be removed in the
last patch, as a cleanup. Here I just maintained the existing logic.

> > -		return err;
> > +		return count;
> 
> Should you return 0? I don't know, maybe not
My reasoning is that we have some corrupted data, so we should just
use it all and maybe we'll get something valid at a later point, this is
what was already done before this change in the is_fw_downloading()
branch.

In my specific case it makes no difference, it will never recover from
this state.

Any other opinion?

> but you should document it in the commit log.
Ack

Francesco