linux-kernel - Re: [PATCH v3 3/3] Bluetooth: Add ABI doc for sysfs isoc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABBYNZK8-8k5eZ8TZLM-g4KC_wt8VQ+jx_iryS9_xGxHt+u=1g@mail.gmail.com>
Date: Tue, 11 Feb 2025 17:00:49 -0500
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Hsin-chen Chuang <chharry@...gle.com>
Cc: linux-bluetooth@...r.kernel.org, 
	chromeos-bluetooth-upstreaming@...omium.org, 
	Hsin-chen Chuang <chharry@...omium.org>, Johan Hedberg <johan.hedberg@...il.com>, 
	Marcel Holtmann <marcel@...tmann.org>, linux-kernel@...r.kernel.org, 
	Ying Hsu <yinghsu@...omium.org>
Subject: Re: [PATCH v3 3/3] Bluetooth: Add ABI doc for sysfs isoc_alt

Hi Hsin-chen,

On Mon, Feb 10, 2025 at 11:23 PM Hsin-chen Chuang <chharry@...gle.com> wrote:
>
> Hi Luiz,
>
> Thanks for the feedback.
>
> On Tue, Feb 11, 2025 at 2:17 AM Luiz Augusto von Dentz
> <luiz.dentz@...il.com> wrote:
> >
> > Hi Hsin-chen,
> >
> > On Mon, Feb 10, 2025 at 5:32 AM Hsin-chen Chuang <chharry@...gle.com> wrote:
> > >
> > > From: Hsin-chen Chuang <chharry@...omium.org>
> > >
> > > The functionality was completed in commit 5e5c3898ef49 ("Bluetooth: Fix
> > > possible race with userspace of sysfs isoc_alt")
> > >
> > > Fixes: 5e5c3898ef49 ("Bluetooth: Fix possible race with userspace of sysfs isoc_alt")
> > > Signed-off-by: Hsin-chen Chuang <chharry@...omium.org>
> > > ---
> > >
> > > (no changes since v1)
> > >
> > >  Documentation/ABI/stable/sysfs-class-bluetooth | 12 ++++++++++++
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/Documentation/ABI/stable/sysfs-class-bluetooth b/Documentation/ABI/stable/sysfs-class-bluetooth
> > > index 36be02471174..1168e0318e35 100644
> > > --- a/Documentation/ABI/stable/sysfs-class-bluetooth
> > > +++ b/Documentation/ABI/stable/sysfs-class-bluetooth
> > > @@ -7,3 +7,15 @@ Description:   This write-only attribute allows users to trigger the vendor reset
> > >                 The reset may or may not be done through the device transport
> > >                 (e.g., UART/USB), and can also be done through an out-of-band
> > >                 approach such as GPIO.
> > > +
> > > +What:          /sys/class/bluetooth/hci<index>/isoc_alt
> > > +Date:          10-Feb-2025
> > > +KernelVersion: 6.13
> > > +Contact:       linux-bluetooth@...r.kernel.org
> > > +Description:   This attribute allows users to configure the USB Alternate setting
> > > +               for the specific HCI device. Reading this attribute returns the
> > > +               current setting, and writing any supported numbers would change
> > > +               the setting. See the USB Alternate setting definition in Bluetooth
> > > +               core spec 5, vol 4, part B, table 2.1.
> > > +               If the data is not a valid number, the write fails with -EINVAL.
> > > +               The other failures are vendor specific.
> >
> > Still not really convinced this is the right way to expose it, it is
> > not an HCI attribute to begin with, not sure if we couldn't perhaps
>
> Could you tell more about why this is not an HCI attr to begin with?
> The alt setting is bonded to the USB device which is now under btusb's
> control, and btusb creates a sysfs node for this. This attr location
> decision seems natural to me.

Well alt setting is (obviously) not covered as part of HCI
specification, USB is one possible transport bus of HCI, but that
itself is already saying that we would be mixing the transport with
actual HCI protocol.

> > add another node to control it or add via USB device?
>
> I feel allowing this in the USB sysfs API might be an overkill as that
> makes all USB devices' alt settings be controllable from the user
> space. Limiting this usage in the scope of BT makes more sense to me.

Not all, just btusb ones, that said what we could add another level to
control transport specific attribute e.g
/sys/class/bluetooth/usb#/isoc_alt than that becomes the parent of
/sys/class/bluetooth/hci<index>

> >
> > --
> > Luiz Augusto von Dentz
>
> --
> Best Regards,
> Hsin-chen



-- 
Luiz Augusto von Dentz