From: Greg KH <gregkh@linuxfoundation.org>
To: Hsin-chen Chuang <chharry@google.com>
Cc: linux-bluetooth@vger.kernel.org, luiz.dentz@gmail.com,
chromeos-bluetooth-upstreaming@chromium.org,
Hsin-chen Chuang <chharry@chromium.org>,
Marcel Holtmann <marcel@holtmann.org>,
Ying Hsu <yinghsu@chromium.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] Bluetooth: btusb: Configure altsetting for USER_CHANNEL
Date: Mon, 24 Feb 2025 07:44:34 +0100 [thread overview]
Message-ID: <2025022407-polo-disgrace-9655@gregkh> (raw)
In-Reply-To: <CADg1FFeW5EXOJTqTS+jwBphGnDSCreNwM8hcFOhB1Tatdti6QA@mail.gmail.com>
On Mon, Feb 24, 2025 at 02:25:52PM +0800, Hsin-chen Chuang wrote:
> Hi Greg,
>
> On Mon, Feb 24, 2025 at 2:10 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Feb 24, 2025 at 12:52:32PM +0800, Hsin-chen Chuang wrote:
> > > From: Hsin-chen Chuang <chharry@chromium.org>
> > >
> > > Automatically configure the altsetting for USER_CHANNEL when a SCO is
> > > connected. This adds support for the USER_CHANNEL to transfer SCO data
> > > over USB transport.
> > >
> > > Fixes: b16b327edb4d ("Bluetooth: btusb: add sysfs attribute to control USB alt setting")
> > > Signed-off-by: Hsin-chen Chuang <chharry@chromium.org>
> > > ---
> > >
> > > Changes in v2:
> > > - Give up tracking the SCO handles. Only configure the altsetting when
> > > SCO connected.
> > > - Put the change behind Kconfig/module parameter
> > >
> > > drivers/bluetooth/Kconfig | 11 ++++++++++
> > > drivers/bluetooth/btusb.c | 46 +++++++++++++++++++++++++++++++++++++++
> > > 2 files changed, 57 insertions(+)
> > >
> > > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > > index 4ab32abf0f48..7c497f878732 100644
> > > --- a/drivers/bluetooth/Kconfig
> > > +++ b/drivers/bluetooth/Kconfig
> > > @@ -56,6 +56,17 @@ config BT_HCIBTUSB_POLL_SYNC
> > > Say Y here to enable USB poll_sync for Bluetooth USB devices by
> > > default.
> > >
> > > +config BT_HCIBTUSB_AUTO_SET_ISOC_ALT
> > > + bool "Auto set isoc_altsetting for USER_CHANNEL when SCO connected"
> > > + depends on BT_HCIBTUSB
> > > + default n
> > > + help
> > > + Say Y here to enable auto set isoc_altsetting for USER_CHANNEL
> > > + when SCO connected
> > > +
> > > + This can be overridden by passing btusb.auto_set_isoc_alt=[y|n]
> > > + on the kernel commandline.
> > > +
> > > config BT_HCIBTUSB_BCM
> > > bool "Broadcom protocol support"
> > > depends on BT_HCIBTUSB
> > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > > index de3fa725d210..af93d757911b 100644
> > > --- a/drivers/bluetooth/btusb.c
> > > +++ b/drivers/bluetooth/btusb.c
> > > @@ -34,6 +34,8 @@ static bool force_scofix;
> > > static bool enable_autosuspend = IS_ENABLED(CONFIG_BT_HCIBTUSB_AUTOSUSPEND);
> > > static bool enable_poll_sync = IS_ENABLED(CONFIG_BT_HCIBTUSB_POLL_SYNC);
> > > static bool reset = true;
> > > +static bool auto_set_isoc_alt =
> > > + IS_ENABLED(CONFIG_BT_HCIBTUSB_AUTO_SET_ISOC_ALT);
> > >
> > > static struct usb_driver btusb_driver;
> > >
> > > @@ -1113,6 +1115,42 @@ static inline void btusb_free_frags(struct btusb_data *data)
> > > spin_unlock_irqrestore(&data->rxlock, flags);
> > > }
> > >
> > > +static void btusb_sco_connected(struct btusb_data *data, struct sk_buff *skb)
> > > +{
> > > + struct hci_event_hdr *hdr = (void *) skb->data;
> > > + struct hci_ev_sync_conn_complete *ev =
> > > + (void *) skb->data + sizeof(*hdr);
> > > + struct hci_dev *hdev = data->hdev;
> > > + unsigned int notify_air_mode;
> > > +
> > > + if (hci_skb_pkt_type(skb) != HCI_EVENT_PKT)
> > > + return;
> > > +
> > > + if (skb->len < sizeof(*hdr) || hdr->evt != HCI_EV_SYNC_CONN_COMPLETE)
> > > + return;
> > > +
> > > + if (skb->len != sizeof(*hdr) + sizeof(*ev) || ev->status)
> > > + return;
> > > +
> > > + switch (ev->air_mode) {
> > > + case BT_CODEC_CVSD:
> > > + notify_air_mode = HCI_NOTIFY_ENABLE_SCO_CVSD;
> > > + break;
> > > +
> > > + case BT_CODEC_TRANSPARENT:
> > > + notify_air_mode = HCI_NOTIFY_ENABLE_SCO_TRANSP;
> > > + break;
> > > +
> > > + default:
> > > + return;
> > > + }
> > > +
> > > + bt_dev_info(hdev, "enabling SCO with air mode %u", ev->air_mode);
> > > + data->sco_num = 1;
> > > + data->air_mode = notify_air_mode;
> > > + schedule_work(&data->work);
> > > +}
> > > +
> > > static int btusb_recv_event(struct btusb_data *data, struct sk_buff *skb)
> > > {
> > > if (data->intr_interval) {
> > > @@ -1120,6 +1158,11 @@ static int btusb_recv_event(struct btusb_data *data, struct sk_buff *skb)
> > > schedule_delayed_work(&data->rx_work, 0);
> > > }
> > >
> > > + /* Configure altsetting for HCI_USER_CHANNEL on SCO connected */
> > > + if (auto_set_isoc_alt &&
> > > + hci_dev_test_flag(data->hdev, HCI_USER_CHANNEL))
> > > + btusb_sco_connected(data, skb);
> > > +
> > > return data->recv_event(data->hdev, skb);
> > > }
> > >
> > > @@ -4354,6 +4397,9 @@ MODULE_PARM_DESC(enable_autosuspend, "Enable USB autosuspend by default");
> > > module_param(reset, bool, 0644);
> > > MODULE_PARM_DESC(reset, "Send HCI reset command on initialization");
> > >
> > > +module_param(auto_set_isoc_alt, bool, 0644);
> > > +MODULE_PARM_DESC(auto_set_isoc_alt, "Auto set isoc_altsetting for USER_CHANNEL when SCO connected");
> >
> > This is not the 1990's, why are you adding new module parameters when we
> > have so many other more proper ways to do this? And really, this would
>
> Sorry but could you please provide an example to guard a feature like this.
Depends on what you want to do with this configuration. Why is it an
option at all? Why can't it "just work"? Module parameters are a pain
to configure, we have loads of other ways to do this now (configfs,
debugfs for debugging stuff, sysfs for device-specific things, etc.)
> > not work at all for multiple controllers in teh same system, right?
>
> Do you mean we can't have separate parameters for different
> controllers? Yes that's true, but why would a user want the different
> behavior on the same machine?
Why would you prevent them from allowing this to happen for a
device-specific option?
thanks,
greg k-h
next prev parent reply other threads:[~2025-02-24 6:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 4:52 [PATCH v2] Bluetooth: btusb: Configure altsetting for USER_CHANNEL Hsin-chen Chuang
2025-02-24 5:32 ` [v2] " bluez.test.bot
2025-02-24 6:10 ` [PATCH v2] " Greg KH
2025-02-24 6:25 ` Hsin-chen Chuang
2025-02-24 6:44 ` Greg KH [this message]
2025-02-24 7:13 ` Hsin-chen Chuang
2025-02-26 20:54 ` Luiz Augusto von Dentz
2025-02-27 2:22 ` Hsin-chen Chuang
2025-02-27 14:37 ` Luiz Augusto von Dentz
2025-02-27 15:36 ` Hsin-chen Chuang
2025-02-27 15:58 ` Luiz Augusto von Dentz
2025-02-27 16:44 ` Hsin-chen Chuang
2025-02-28 4:47 ` Ying Hsu
2025-03-03 2:08 ` Hsin-chen Chuang
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=2025022407-polo-disgrace-9655@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=chharry@chromium.org \
--cc=chharry@google.com \
--cc=chromeos-bluetooth-upstreaming@chromium.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=yinghsu@chromium.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