Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200525184343.8532-1-alainm@chromium.org> <31E0FE7F-34A6-4819-AE06-C9F0B49D7C11@holtmann.org>
In-Reply-To: <31E0FE7F-34A6-4819-AE06-C9F0B49D7C11@holtmann.org>
From:   Alain Michaud <alainmichaud@google.com>
Date:   Thu, 28 May 2020 09:27:51 -0400
Message-ID: <CALWDO_XZLjFR1WheNogehz-STe+8wRpi2SSPb3Bscb2eKsPDmw@mail.gmail.com>
Subject: Re: [PATCH v2] sco:Add support for BT_PKT_STATUS CMSG data
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     Alain Michaud <alainm@chromium.org>,
        BlueZ <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

On Thu, May 28, 2020 at 4:26 AM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Alain,
>
> > This change adds support for reporting the BT_PKT_STATUS to the socket
> > CMSG data to allow the implementation of a packet loss correction on
> > erronous data received on the SCO socket.
> >
> > The patch was partially developed by Marcel Holtmann and validated by
> > Hsin-yu Chao
> >
> > Signed-off-by: Alain Michaud <alainm@chromium.org>
> >
> > ---
> >
> > include/net/bluetooth/bluetooth.h |  8 ++++++++
> > include/net/bluetooth/sco.h       |  3 +++
> > net/bluetooth/af_bluetooth.c      |  3 +++
> > net/bluetooth/hci_core.c          |  1 +
> > net/bluetooth/sco.c               | 28 ++++++++++++++++++++++++++++
> > 5 files changed, 43 insertions(+)
> >
> > diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > index 3fa7b1e3c5d9..85e6c5754448 100644
> > --- a/include/net/bluetooth/bluetooth.h
> > +++ b/include/net/bluetooth/bluetooth.h
> > @@ -147,6 +147,8 @@ struct bt_voice {
> > #define BT_MODE_LE_FLOWCTL    0x03
> > #define BT_MODE_EXT_FLOWCTL   0x04
> >
> > +#define BT_PKT_STATUS          16
> > +
>
> we need to agree on if this is an int or u8 value. Otherwise this looks good.
Since doing anything beyond a u8 value would require a core spec
change and likely a new definition for what the packet flags are, I
think it is likely safe to keep as u8.  Do you have a different
perspective?
>
> Regards
>
> Marcel
>