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@xxxxxxxxxxx> > > > > 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