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
