From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Joseph Hwang <josephsih@chromium.org>
Cc: "linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>,
Marcel Holtmann <marcel@holtmann.org>,
Joseph Hwang <josephsih@google.com>,
ChromeOS Bluetooth Upstreaming
<chromeos-bluetooth-upstreaming@chromium.org>,
Alain Michaud <alainm@chromium.org>,
Abhishek Pandit-Subedi <abhishekpandit@chromium.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:NETWORKING [GENERAL]" <netdev@vger.kernel.org>
Subject: Re: [PATCH v1 1/2] Bluetooth: btusb: define HCI packet sizes of USB Alts
Date: Fri, 14 Aug 2020 13:07:25 -0700 [thread overview]
Message-ID: <CABBYNZ+GPmHuVe_TCUwCVYuOzH8m0=Nmwv48Tn-by_5PnqqwOg@mail.gmail.com> (raw)
In-Reply-To: <20200813164059.v1.1.I56de28ec171134cb9f97062e2c304a72822ca38b@changeid>
Hi Joseph,
On Thu, Aug 13, 2020 at 1:42 AM Joseph Hwang <josephsih@chromium.org> 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@chromium.org>
> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
> Signed-off-by: Joseph Hwang <josephsih@chromium.org>
> ---
>
> drivers/bluetooth/btusb.c | 43 ++++++++++++++++++++++++--------
> include/net/bluetooth/hci_core.h | 1 +
> 2 files changed, 33 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 8d2608ddfd0875..df7cadf6385868 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -459,6 +459,22 @@ 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)
> + */
> +static const int hci_packet_size_usb_alt[] = { 0, 24, 48, 72, 96, 144, 60 };
> +
> struct btusb_data {
> struct hci_dev *hdev;
> struct usb_device *udev;
> @@ -3958,6 +3974,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)
> @@ -4021,6 +4046,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_pkt_len = hci_packet_size_usb_alt[6];
> +
> 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);
> @@ -4062,15 +4091,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;
> @@ -4082,9 +4102,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_pkt_len = hci_packet_size_usb_alt[1];
> + } else
> bt_dev_err(hdev, "Device does not support ALT setting 1");
> }
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 8caac20556b499..0624496328fc09 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -417,6 +417,7 @@ struct hci_dev {
> unsigned int acl_pkts;
> unsigned int sco_pkts;
> unsigned int le_pkts;
> + unsigned int sco_pkt_len;
Id use sco_mtu to so the following check actually does what it intended to do:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/sco.c#n283
Right now it seems we are using the buffer length as MTU but I think
we should actually use the packet length if it is lower than the
buffer length, actually it doesn't seems SCO packets can be fragmented
so the buffer length must always be big enough to carry a full packet
so I assume setting the packet length as conn->mtu will always be
correct.
>
> __u16 block_len;
> __u16 block_mtu;
> --
> 2.28.0.236.gb10cc79966-goog
>
--
Luiz Augusto von Dentz
next prev parent reply other threads:[~2020-08-14 20:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 8:41 [PATCH v1 0/2] To support the HFP WBS, a chip vendor may choose a particular Joseph Hwang
2020-08-13 8:41 ` [PATCH v1 1/2] Bluetooth: btusb: define HCI packet sizes of USB Alts Joseph Hwang
2020-08-14 20:07 ` Luiz Augusto von Dentz [this message]
2020-08-19 14:38 ` Pali Rohár
2020-08-13 8:41 ` [PATCH v1 2/2] Bluetooth: sco: expose WBS packet length in socket option Joseph Hwang
2020-08-14 19:56 ` Luiz Augusto von Dentz
2020-08-19 14:37 ` Pali Rohár
2020-08-19 18:21 ` Luiz Augusto von Dentz
2020-08-19 18:23 ` Pali Rohár
2020-08-19 18:25 ` Luiz Augusto von Dentz
2020-08-19 2:48 ` [PATCH v1 0/2] To support the HFP WBS, a chip vendor may choose a particular Shyh-In Hwang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABBYNZ+GPmHuVe_TCUwCVYuOzH8m0=Nmwv48Tn-by_5PnqqwOg@mail.gmail.com' \
--to=luiz.dentz@gmail.com \
--cc=abhishekpandit@chromium.org \
--cc=alainm@chromium.org \
--cc=chromeos-bluetooth-upstreaming@chromium.org \
--cc=davem@davemloft.net \
--cc=johan.hedberg@gmail.com \
--cc=josephsih@chromium.org \
--cc=josephsih@google.com \
--cc=kuba@kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).