On Thu, Sep 10, 2020 at 4:18 PM Pali Rohár <pali@xxxxxxxxxx> wrote:
>
> On Thursday 10 September 2020 14:04:01 Joseph Hwang wrote:
> > It is desirable to define the HCI packet payload sizes of
> > USB alternate settings so that they can be exposed to user
> > space.
> >
> > Reviewed-by: Alain Michaud <alainm@xxxxxxxxxxxx>
> > Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@xxxxxxxxxxxx>
> > Signed-off-by: Joseph Hwang <josephsih@xxxxxxxxxxxx>
> > ---
> >
> > Changes in v3:
> > - Set hdev->sco_mtu to rp->sco_mtu if the latter is smaller.
> >
> > Changes in v2:
> > - Used sco_mtu instead of a new sco_pkt_len member in hdev.
> > - Do not overwrite hdev->sco_mtu in hci_cc_read_buffer_size
> > if it has been set in the USB interface.
> >
> > drivers/bluetooth/btusb.c | 45 +++++++++++++++++++++++++++++----------
> > net/bluetooth/hci_event.c | 14 +++++++++++-
> > 2 files changed, 47 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index fe80588c7bd3a8..651d5731a6c6cf 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -459,6 +459,24 @@ static const struct dmi_system_id btusb_needs_reset_resume_table[] = {
> > #define BTUSB_WAKEUP_DISABLE 14
> > #define BTUSB_USE_ALT1_FOR_WBS 15
> >
> > +/* Per core spec 5, vol 4, part B, table 2.1,
> > + * list the hci packet payload sizes for various ALT settings.
> > + * This is used to set the packet length for the wideband speech.
> > + * If a controller does not probe its usb alt setting, the default
> > + * value will be 0. Any clients at upper layers should interpret it
> > + * as a default value and set a proper packet length accordingly.
> > + *
> > + * To calculate the HCI packet payload length:
> > + * for alternate settings 1 - 5:
> > + * hci_packet_size = suggested_max_packet_size * 3 (packets) -
> > + * 3 (HCI header octets)
> > + * for alternate setting 6:
> > + * hci_packet_size = suggested_max_packet_size - 3 (HCI header octets)
> > + * where suggested_max_packet_size is {9, 17, 25, 33, 49, 63}
> > + * for alt settings 1 - 6.
>
> Thank you for update, now I see what you mean!
>
> > + */
> > +static const int hci_packet_size_usb_alt[] = { 0, 24, 48, 72, 96, 144, 60 };
>
> Now the another question, why you are using hci_packet_size_usb_alt[1]
> and hci_packet_size_usb_alt[6] values from this array?
Will answer it per the spec in the next patch series.
>
> > +
> > struct btusb_data {
> > struct hci_dev *hdev;
> > struct usb_device *udev;
> > @@ -3959,6 +3977,15 @@ static int btusb_probe(struct usb_interface *intf,
> > hdev->notify = btusb_notify;
> > hdev->prevent_wake = btusb_prevent_wake;
> >
> > + if (id->driver_info & BTUSB_AMP) {
> > + /* AMP controllers do not support SCO packets */
> > + data->isoc = NULL;
> > + } else {
> > + /* Interface orders are hardcoded in the specification */
> > + data->isoc = usb_ifnum_to_if(data->udev, ifnum_base + 1);
> > + data->isoc_ifnum = ifnum_base + 1;
> > + }
> > +
> > #ifdef CONFIG_PM
> > err = btusb_config_oob_wake(hdev);
> > if (err)
> > @@ -4022,6 +4049,10 @@ static int btusb_probe(struct usb_interface *intf,
> > hdev->set_diag = btintel_set_diag;
> > hdev->set_bdaddr = btintel_set_bdaddr;
> > hdev->cmd_timeout = btusb_intel_cmd_timeout;
> > +
> > + if (btusb_find_altsetting(data, 6))
> > + hdev->sco_mtu = hci_packet_size_usb_alt[6];
>
> Why you are setting this sco_mtu only for Intel adapter? Is not this
> whole code generic to USB?
Please refer to the answer to the Realtek adapter below. Thanks.
>
> > +
> > set_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks);
> > set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks);
> > set_bit(HCI_QUIRK_NON_PERSISTENT_DIAG, &hdev->quirks);
> > @@ -4063,15 +4094,6 @@ static int btusb_probe(struct usb_interface *intf,
> > btusb_check_needs_reset_resume(intf);
> > }
> >
> > - if (id->driver_info & BTUSB_AMP) {
> > - /* AMP controllers do not support SCO packets */
> > - data->isoc = NULL;
> > - } else {
> > - /* Interface orders are hardcoded in the specification */
> > - data->isoc = usb_ifnum_to_if(data->udev, ifnum_base + 1);
> > - data->isoc_ifnum = ifnum_base + 1;
> > - }
> > -
> > if (IS_ENABLED(CONFIG_BT_HCIBTUSB_RTL) &&
> > (id->driver_info & BTUSB_REALTEK)) {
> > hdev->setup = btrtl_setup_realtek;
> > @@ -4083,9 +4105,10 @@ static int btusb_probe(struct usb_interface *intf,
> > * (DEVICE_REMOTE_WAKEUP)
> > */
> > set_bit(BTUSB_WAKEUP_DISABLE, &data->flags);
> > - if (btusb_find_altsetting(data, 1))
> > + if (btusb_find_altsetting(data, 1)) {
> > set_bit(BTUSB_USE_ALT1_FOR_WBS, &data->flags);
> > - else
> > + hdev->sco_mtu = hci_packet_size_usb_alt[1];
>
> And this part of code which you write is Realtek specific.
We currently only have Intel and Realtek platforms to test with. If
making it generic without proper testing platforms is fine, I will
make it generic. Or do you think it might be better to make it
customized with particular vendors for now; and make it generic later
when it works well with sufficient vendors?
>
> I thought that this is something generic to bluetooth usb as you pointed
> to bluetooth documentation "core spec 5, vol 4, part B, table 2.1".
>
> > + } else
> > bt_dev_err(hdev, "Device does not support ALT setting 1");
> > }
>
> Also this patch seems to be for me incomplete or not fully correct as
> USB altsetting is chosen in function btusb_work() and it depends on
> selected AIR mode (which is configured by another setsockopt).
>
> So despite what is written in commit message, this patch looks for me
> like some hack for Intel and Realtek bluetooth adapters and does not
> solve problems in vendor independent manner.
You are right that sco_mtu should be changed according to the air
mode. Here are some issues to handle and what I plan to do. I would
like to solicit your comments before I submit the next series.
[Issue 1] The air mode is determined in btusb_work() which is
triggered by hci_sync_conn_complete_evt(). So “conn->mtu =
hdev->sco_mtu” should not be done in sco_conn_add() in the early
connecting stage. Instead, it will be moved to near the end of
hci_sync_conn_complete_evt().
[Issue 2] The btusb_work() is performed by a worker. There would be a
timing issue here if we let btusb_work() to do “hdev->sco_mtu =
hci_packet_size_usb_alt[i]” because there is no guarantee how soon the
btusb_work() can be finished and get “hdev->sco_mtu” value set
correctly. In order to avoid the potential race condition, I suggest
to determine air_mode in btusb_notify() before
schedule_work(&data->work) is executed so that “hdev->sco_mtu =
hci_packet_size_usb_alt[i]” is guaranteed to be performed when
btusb_notify() finished. In this way, hci_sync_conn_complete_evt() can
set conn->mtu correctly as described in [Issue 1] above.
[Issue 3] Concerning CVSD: The above flow is good when the transparent
mode is selected. When it is the CVSD mode, we should set
hdev->sco_mtu and conn->mtu back to the original mtu size returned by
hci_cc_read_buffer_size(). This is because we do not have a reliable
way to determine what size is used with CVSD. AFAIK, controllers
connected through USB use 48 bytes; and controllers connected through
UART use 60 bytes. It seems to me that these numbers are not recorded
in the kernel(?). It seems beyond the scope of this patch to set the
proper value for CVSD. So we will let hdev->sco_mtu and conn->mtu go
back to their original values and are not affected by this patch.
I am wondering if such directions of fixing this patch look good to you?
Thanks and regards!
Joseph
--
Joseph Shyh-In Hwang
Email: josephsih@xxxxxxxxxx
