* Re: [PATCH v1] mediatek MT7925: update bluetooth firmware to 20260414153243
From: Sean Wang @ 2026-04-23 17:36 UTC (permalink / raw)
To: David Ruth
Cc: Chris Lu (陸稚泓), ben, dwmw2, johan.hedberg,
jwboyer, linux-bluetooth, linux-firmware, linux-kernel,
linux-mediatek, marcel, ss.wu, steve.lee, will-cy.Lee
In-Reply-To: <CAKHmtrSaDR4fBxN0mvEzYPHoOwr2rrtnOJW6fsrxzsBAeHTjQg@mail.gmail.com>
On Wed, Apr 22, 2026 at 5:19 PM David Ruth <druth@chromium.org> wrote:
>
> Tested-by: David Ruth <druth@chromium.org>
>
Merged
https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/1015
^ permalink raw reply
* Re: Bluetooth: Use AES-CMAC library API
From: Luiz Augusto von Dentz @ 2026-04-23 17:26 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-bluetooth
In-Reply-To: <20260422230256.GC2226@sol>
Hi Eric,
On Wed, Apr 22, 2026 at 7:04 PM Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Wed, Apr 22, 2026 at 11:11:25AM -0400, Luiz Augusto von Dentz wrote:
> > > net/bluetooth/smp.c:25:10: fatal error: crypto/aes-cbc-macs.h: No such file or directory
> > > 25 | #include <crypto/aes-cbc-macs.h>
> > > | ^~~~~~~~~~~~~~~~~~~~~~~
> >
> > I guess this is expected since rc1 wasn't tagged yet, right? In that
> > case we will probably need to rebase once rc1 is tagged to integrate
> > these changes.
>
> Well, the bluez.test.bot seems to have ignored the
> "base-commit: d46dd0d88341e45f8e0226fdef5462f5270898fc" and applied the
> series to something a bit older. In that case, yes this is expected.
I don't see that on pw:
https://patchwork.kernel.org/project/bluetooth/list/?series=1084071,
and even if we did support passing a base-commit that could create
other problems since the test cases (which comes from BlueZ userspace)
are only meant to be stable against trees other than bluetooth-next so
we might be able to build but fail test cases that were recently
introduced.
> Once the bluetooth branch has been updated to v7.1-rc1 or another commit
> that has the prerequisite, this can be applied. Thanks,
Ok, I think we are still in the merging window so tagging RC1 will
probably need a week or more.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ v2 1/3] audio: Add ability to force CIS transport Links property
From: Luiz Augusto von Dentz @ 2026-04-23 17:08 UTC (permalink / raw)
To: Frédéric Danis; +Cc: linux-bluetooth
In-Reply-To: <20260423075309.493820-1-frederic.danis@collabora.com>
Hi Frederic,
On Thu, Apr 23, 2026 at 3:53 AM Frédéric Danis
<frederic.danis@collabora.com> wrote:
>
> If bluetoothd is started in testing mode the Links property for CIS
> is readwrite and can be used to force transport objects Links.
> This can used to unlink transport objects by sending an empty array.
>
> For unlinked transport objects, each transports needs to be acquired
> separately.
>
> This allows to pass PTS tests BAP/UCL/STR/BV-543-C and BV-546-C.
> ---
> v1 -> v2:
> - Add testing mode check in bap_connect_io_cb()
> - Replace stream state check by checking that the stream is not linked
> before passing the connect event to all streams belonging to same
> CIG/CIS.
>
> profiles/audio/bap.c | 46 ++++++++++++++++++++++++++++++
> profiles/audio/transport.c | 57 +++++++++++++++++++++++++++++++-------
> 2 files changed, 95 insertions(+), 10 deletions(-)
>
> diff --git a/profiles/audio/bap.c b/profiles/audio/bap.c
> index 5333267f7..e20456436 100644
> --- a/profiles/audio/bap.c
> +++ b/profiles/audio/bap.c
> @@ -2655,13 +2655,61 @@ static void bap_connect_bcast_io_cb(GIOChannel *chan, GError *err,
> iso_connect_bcast_cb(chan, err, setup->stream);
> }
>
> +struct connect_io_data {
> + GIOChannel *chan;
> + GError *err;
> + uint8_t cig_id;
> + uint8_t cis_id;
> +};
> +
> +static void connect_stream(void *data, void *user_data)
> +{
> + struct bap_setup *setup = data;
> + struct connect_io_data *d = user_data;
> + uint8_t state;
> +
> + /* Check stream state to only pass the connect event managed
> + * by bap_stream_set_io() */
> + state = bt_bap_stream_get_state(setup->stream);
> + if ((state == BT_BAP_STREAM_STATE_ENABLING ||
> + state == BT_BAP_STREAM_STATE_DISABLING) &&
> + setup->qos.ucast.cig_id == d->cig_id &&
> + setup->qos.ucast.cis_id == d->cis_id)
> + iso_connect_cb(d->chan, d->err, setup->stream);
From the discussion we had Ive assume we wouldn't be checking the
state here, since we don't check on bap_connect_io_cb either.
> +}
> +
> +static void connect_ep(void *data, void *user_data)
> +{
> + struct bap_ep *ep = data;
> +
> + if (ep->setups)
> + queue_foreach(ep->setups, connect_stream, user_data);
> +}
> +
> static void bap_connect_io_cb(GIOChannel *chan, GError *err, gpointer user_data)
> {
> struct bap_setup *setup = user_data;
> + struct connect_io_data data;
>
> if (!setup->stream)
> return;
>
> + if (queue_isempty(bt_bap_stream_io_get_links(setup->stream)) &&
> + btd_opts.testing) {
> + /* The stream may have manually been unliked for PTS tests,
> + * e.g. BAP/UCL/STR/BV-543-C or BAP/UCL/STR/BV-546-C,
> + * in this case send the connect event to all streams
> + * belonging to the same CIG/CIS.
> + */
> + data.chan = chan;
> + data.err = err;
> + data.cig_id = setup->qos.ucast.cig_id;
> + data.cis_id = setup->qos.ucast.cis_id;
> + queue_foreach(setup->ep->data->snks, connect_ep, &data);
> + queue_foreach(setup->ep->data->srcs, connect_ep, &data);
> + return;
> + }
> +
> iso_connect_cb(chan, err, setup->stream);
> }
>
> diff --git a/profiles/audio/transport.c b/profiles/audio/transport.c
> index 5c2a2777e..b6a5dd1fd 100644
> --- a/profiles/audio/transport.c
> +++ b/profiles/audio/transport.c
> @@ -37,6 +37,7 @@
> #include "src/shared/bap.h"
> #include "src/shared/bass.h"
> #include "src/shared/io.h"
> +#include "src/btd.h"
>
> #ifdef HAVE_A2DP
> #include "avdtp.h"
> @@ -114,6 +115,7 @@ struct bap_transport {
> struct media_transport_ops {
> const char *uuid;
> const GDBusPropertyTable *properties;
> + const GDBusPropertyTable *test_properties;
> void (*set_owner)(struct media_transport *transport,
> struct media_owner *owner);
> void (*remove_owner)(struct media_transport *transport,
> @@ -1419,6 +1421,9 @@ static struct media_transport *find_transport_by_path(const char *path)
> return NULL;
> }
>
> +static void bap_update_links(const struct media_transport *transport);
> +static void transport_unlink(void *data, void *user_data);
> +
> static void set_links(const GDBusPropertyTable *property,
> DBusMessageIter *iter,
> GDBusPendingPropertySet id, void *user_data)
> @@ -1436,6 +1441,16 @@ static void set_links(const GDBusPropertyTable *property,
>
> dbus_message_iter_recurse(iter, &array);
>
> + if (dbus_message_iter_get_arg_type(&array) == DBUS_TYPE_INVALID) {
> + struct queue *links = bt_bap_stream_io_get_links(bap->stream);
> +
> + /* Unlink stream from all its links */
> + queue_foreach(links, transport_unlink, bap->stream);
> +
> + bt_bap_stream_io_unlink(bap->stream, NULL);
> + bap_update_links(transport);
> + }
> +
> while (dbus_message_iter_get_arg_type(&array) ==
> DBUS_TYPE_OBJECT_PATH) {
> struct media_transport *link;
> @@ -1486,6 +1501,21 @@ static const GDBusPropertyTable transport_bap_uc_properties[] = {
> { }
> };
>
> +static const GDBusPropertyTable transport_bap_uc_test_properties[] = {
> + { "Device", "o", get_device },
> + { "UUID", "s", get_uuid },
> + { "Codec", "y", get_codec },
> + { "Configuration", "ay", get_configuration },
> + { "State", "s", get_state },
> + { "QoS", "a{sv}", get_ucast_qos, NULL, qos_ucast_exists },
> + { "Endpoint", "o", get_endpoint, NULL, endpoint_exists },
> + { "Location", "u", get_location },
> + { "Metadata", "ay", get_metadata, set_metadata },
> + { "Links", "ao", get_links, set_links, links_exists },
> + { "Volume", "q", get_volume, set_volume, volume_exists },
> + { }
> +};
> +
> static gboolean get_bcast_qos(const GDBusPropertyTable *property,
> DBusMessageIter *iter, void *data)
> {
> @@ -1884,8 +1914,6 @@ static void bap_resume_complete(struct media_transport *transport)
> transport_set_state(transport, TRANSPORT_STATE_ACTIVE);
> }
>
> -static void bap_update_links(const struct media_transport *transport);
> -
> static bool match_link_transport(const void *data, const void *user_data)
> {
> const struct bt_bap_stream *stream = data;
> @@ -2540,10 +2568,11 @@ static void *transport_asha_init(struct media_transport *transport, void *data)
> #define TRANSPORT_OPS(_uuid, _props, _set_owner, _remove_owner, _init, \
> _resume, _suspend, _cancel, _set_state, _get_stream, \
> _get_volume, _set_volume, _set_delay, _update_links, \
> - _destroy) \
> + _destroy, _test_props) \
> { \
> .uuid = _uuid, \
> .properties = _props, \
> + .test_properties = _test_props, \
> .set_owner = _set_owner, \
> .remove_owner = _remove_owner, \
> .init = _init, \
> @@ -2565,26 +2594,28 @@ static void *transport_asha_init(struct media_transport *transport, void *data)
> transport_a2dp_resume, transport_a2dp_suspend, \
> transport_a2dp_cancel, NULL, \
> transport_a2dp_get_stream, transport_a2dp_get_volume, \
> - _set_volume, _set_delay, NULL, _destroy)
> + _set_volume, _set_delay, NULL, _destroy, NULL)
>
> #define BAP_OPS(_uuid, _props, _set_owner, _remove_owner, _update_links, \
> - _set_state) \
> + _set_state, _test_props) \
> TRANSPORT_OPS(_uuid, _props, _set_owner, _remove_owner,\
> transport_bap_init, \
> transport_bap_resume, transport_bap_suspend, \
> transport_bap_cancel, _set_state, \
> transport_bap_get_stream, transport_bap_get_volume, \
> transport_bap_set_volume, NULL, \
> - _update_links, transport_bap_destroy)
> + _update_links, transport_bap_destroy, _test_props)
>
> #define BAP_UC_OPS(_uuid) \
> BAP_OPS(_uuid, transport_bap_uc_properties, \
> transport_bap_set_owner, transport_bap_remove_owner, \
> - transport_bap_update_links_uc, transport_bap_set_state)
> + transport_bap_update_links_uc, \
> + transport_bap_set_state, \
> + transport_bap_uc_test_properties)
>
> #define BAP_BC_OPS(_uuid) \
> BAP_OPS(_uuid, transport_bap_bc_properties, NULL, NULL, \
> - transport_bap_update_links_bc, NULL)
> + transport_bap_update_links_bc, NULL, NULL)
>
> #define ASHA_OPS(_uuid) \
> TRANSPORT_OPS(_uuid, transport_asha_properties, NULL, NULL, \
> @@ -2592,7 +2623,7 @@ static void *transport_asha_init(struct media_transport *transport, void *data)
> transport_asha_resume, transport_asha_suspend, \
> transport_asha_cancel, NULL, NULL, \
> transport_asha_get_volume, transport_asha_set_volume, \
> - NULL, NULL, NULL)
> + NULL, NULL, NULL, NULL)
>
> static const struct media_transport_ops transport_ops[] = {
> #ifdef HAVE_A2DP
> @@ -2647,6 +2678,7 @@ struct media_transport *media_transport_create(struct btd_device *device,
> struct media_transport *transport;
> const struct media_transport_ops *ops;
> int fd;
> + const GDBusPropertyTable *properties;
>
> transport = g_new0(struct media_transport, 1);
> if (device)
> @@ -2701,9 +2733,14 @@ struct media_transport *media_transport_create(struct btd_device *device,
> goto fail;
> }
>
> + if (btd_opts.testing && ops->test_properties)
> + properties = ops->test_properties;
> + else
> + properties = ops->properties;
> +
> if (g_dbus_register_interface(btd_get_dbus_connection(),
> transport->path, MEDIA_TRANSPORT_INTERFACE,
> - transport_methods, NULL, ops->properties,
> + transport_methods, NULL, properties,
> transport, media_transport_free) == FALSE) {
> error("Could not register transport %s", transport->path);
> goto fail;
> --
> 2.43.0
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-04-23 16:52 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1083806
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-04-23 16:52 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1084336
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 928f2b: Add permissions for btsnoop-analyzer workflow
From: Luiz Augusto von Dentz @ 2026-04-23 16:51 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: 928f2b28c1c743a42802bacf8a341d25000147a8
https://github.com/bluez/bluez/commit/928f2b28c1c743a42802bacf8a341d25000147a8
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-04-22 (Wed, 22 Apr 2026)
Changed paths:
M profiles/input/device.c
Log Message:
-----------
Add permissions for btsnoop-analyzer workflow
Grant issues:write, contents:read, and models:read so the reusable
workflow can post comments and access the GitHub Models API via
actions/ai-inference. No secrets need to be forwarded.
Commit: d9da103fd1a23fca3cae5166fb170846919c1835
https://github.com/bluez/bluez/commit/d9da103fd1a23fca3cae5166fb170846919c1835
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-04-23 (Thu, 23 Apr 2026)
Changed paths:
M src/shared/hci.c
M src/shared/hci.h
M src/shared/rap.c
M src/shared/rap.h
Log Message:
-----------
shared: rap: Introduce Channel Sounding HCI raw interface support
Implement stub callbacks for Channel Sounding HCI events and add the
required protocol definitions for CS configuration, procedure control,
and subevent result parsing
Add data structures to support Channel Sounding Processing
Add helper function to get hci conn info list and integrate it with RAP
Commit: 55262e1a2ccf2eea18207abe5fdc1428d4aae345
https://github.com/bluez/bluez/commit/55262e1a2ccf2eea18207abe5fdc1428d4aae345
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-04-23 (Thu, 23 Apr 2026)
Changed paths:
M src/bluetooth.service.in
M src/btd.h
M src/main.c
M src/main.conf
Log Message:
-----------
main.conf: Add Channel Sounding config parsing support
Add support for parsing Channel Sounding (CS) configuration options
from the configuration file.
Add CAP_NET_RAW to CapabilityBoundingSet in bluetooth.service.
bluetoothd requires CAP_NET_RAW to receive and process HCI LE events
when running under a constrained systemd capability bounding set
Commit: 868b9e3745dcb7b99a00222c055ea5464e3be283
https://github.com/bluez/bluez/commit/868b9e3745dcb7b99a00222c055ea5464e3be283
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-04-23 (Thu, 23 Apr 2026)
Changed paths:
M Makefile.plugins
M profiles/ranging/rap.c
A profiles/ranging/rap_hci.c
Log Message:
-----------
profiles: ranging: Add HCI LE Event Handling in Reflector role
Open RAW HCI Channel for CS Event Handling
Parse the following HCI LE CS Events in reflector role
and route the events to RAP Profile.
1. HCI_EVT_LE_CS_READ_RMT_SUPP_CAP_COMPLETE
2. HCI_EVT_LE_CS_CONFIG_COMPLETE
3. HCI_EVT_LE_CS_SECURITY_ENABLE_COMPLETE
4. HCI_EVT_LE_CS_PROCEDURE_ENABLE_COMPLETE
5. HCI_EVT_LE_CS_SUBEVENT_RESULT
6. HCI_EVT_LE_CS_SUBEVENT_RESULT_CONTINUE
Send HCI_OP_LE_CS_SET_DEFAULT_SETTINGS to the controller
with default settings selected by the user.
Map connection handle received to device connection
Commit: bc87ee6b0c56cb0405e70271e4210a2560838c8b
https://github.com/bluez/bluez/commit/bc87ee6b0c56cb0405e70271e4210a2560838c8b
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-04-23 (Thu, 23 Apr 2026)
Changed paths:
M profiles/ranging/rap.c
M profiles/ranging/rap_hci.c
Log Message:
-----------
rap: Cleanup coding style and unnecessary code
Compare: https://github.com/bluez/bluez/compare/2c3961e3b0fa...bc87ee6b0c56
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [RFC PATCH] net: skb: on zero-copy formatted output to skb
From: Andrew Lunn @ 2026-04-23 16:46 UTC (permalink / raw)
To: Dmitry Antipov
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-bluetooth
In-Reply-To: <65872064c2ab5fbf47a743f2dcd72182ea8296a7.camel@yandex.ru>
> > So please add some kerneldoc describing what it actually does.
>
> OK, some more neutral name like 'skb_fmt(...)' may be better indeed.
Sure. Just document what it actually does, what the return value
means, etc.
> > Please also annotate the const char *fmt, so the compiler can do
> > format string checks, parameter counting etc.
>
> Surely '__printf(2, 3)' should be used here.
Yep.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH BlueZ v1] input: Fix checking LE bonding on HIDP
From: patchwork-bot+bluetooth @ 2026-04-23 16:40 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20260422150328.2062359-1-luiz.dentz@gmail.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Wed, 22 Apr 2026 11:03:28 -0400 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> HIDP is classic only, LE uses HOG, so there is no point in checking the
> bonding with the address type which in case the device supports
> dual-mode will map to LE random/public address.
>
> Fixes: https://github.com/bluez/bluez/issues/2034
>
> [...]
Here is the summary with links:
- [BlueZ,v1] input: Fix checking LE bonding on HIDP
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=928f2b28c1c7
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ v11 0/3] Add initial Channel Sounding support for
From: patchwork-bot+bluetooth @ 2026-04-23 16:40 UTC (permalink / raw)
To: Naga Bhavani Akella
Cc: linux-bluetooth, luiz.dentz, quic_mohamull, quic_hbandi,
quic_anubhavg, prathibha.madugonde
In-Reply-To: <20260421113148.3809176-1-naga.akella@oss.qualcomm.com>
Hello:
This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 21 Apr 2026 17:01:45 +0530 you wrote:
> This patch series introduces initial support for Bluetooth Channel
> Sounding (CS) using the raw HCI interface.
> This series lays the groundwork for CS support by adding commonly required
> protocol definitions, configuration parsing, and event handling for
> the reflector role.
>
> The changes include:
>
> [...]
Here is the summary with links:
- [BlueZ,v11,1/3] shared: rap: Introduce Channel Sounding HCI raw interface support
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=d9da103fd1a2
- [BlueZ,v11,2/3] main.conf: Add Channel Sounding config parsing support
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=55262e1a2ccf
- [BlueZ,v11,3/3] profiles: ranging: Add HCI LE Event Handling in Reflector role
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=868b9e3745dc
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 01/12] power: sequencing: Introduce an API to check whether the pwrseq is fixed or controllable
From: Bartosz Golaszewski @ 2026-04-23 16:24 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: Manivannan Sadhasivam via B4 Relay, linux-pm, linux-kernel,
linux-pci, linux-arm-msm, linux-bluetooth, Wei Deng,
Luiz Augusto von Dentz, Bartosz Golaszewski,
Manivannan Sadhasivam, Marcel Holtmann, Luiz Augusto von Dentz,
Shuai Zhang
In-Reply-To: <20260422-pwrseq-m2-bt-v1-1-720d02545a64@oss.qualcomm.com>
On Wed, 22 Apr 2026 13:24:42 +0200, Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> said:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> Introduce an API pwrseq_is_fixed() so that the consumers can check whether
> the given power sequencer is fixed or controllable. This will come handy
> in situations where the consumers need to know whether the specific power
> sequencer like 'Bluetooth' can be controllable using properties like BT_EN.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>
I have several concerns about this new function: its name is very vague and
doesn't really indicate its function (how is it "fixed" if you still control
it?), it can be used to expose all kinds of things because of this lack of
precision. I feel like it goes against the goal of pwrseq which is to abstract
these things away from consumers.
The problem we have here is for now a HW quirk affecting a single driver. I'm
thinking that we can live with this driver just checking the relevant property
of the provider device.
Many subsystems provide functions that allow accessing the struct device
associated with the provider. Could we introduce something like:
struct device *pwrseq_to_device(struct pwrseq_desc);
that would return the address of struct device associated with the provider of
the descriptor? It wouldn't even have to return a new reference as holding a
descriptor already implies also holding a reference to the pwrseq device
backing it.
Then in the bluetooth driver you could do:
struct pwrseq_desc *pwrseq = pwrseq_get(dev, "bluetooth");
struct device *dev = pwrseq_to_device(pwrseq);
// Big fat comment stating why you do this
if (!device_property_present(dev, "enable-gpios")) {
// do whatever quirk is required
}
Would that make sense?
Bart
^ permalink raw reply
* Re: [RFC PATCH] net: skb: on zero-copy formatted output to skb
From: Dmitry Antipov @ 2026-04-23 16:03 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-bluetooth
In-Reply-To: <8ed4f473-9c7b-4f77-911c-85cfb2fba2a5@lunn.ch>
On Thu, 2026-04-23 at 14:40 +0200, Andrew Lunn wrote:
>
> A quick look in drivers/bluetooth suggests that none of them care
> about truncation, at least they don't check the return code. Maybe it
> would be better to truncate than return an error?
Hm... I'm not a fan of (silent?) truncation and assume that user who wants to
detect it should be able to do so. If a (bluetooth) driver, or a subsystem,
or whatever else, doesn't care too much, it can wrap it with something like
#define bt_skb_printf(skb, fmt, ...) \
({ \
if (unlikely(skb_printf(skb, fmt, __VA_ARGS__) < 0) \
bt_warn("output to skb@%p truncated\n", skb)); \
})
> I would also try to make the behaviour consistent with the normal
> sprintf(), or snprintf(). You want to give users some idea what it is
> doing based on its name. It is well known that snprintf() will
> truncate, and does not return an error code. sprintf() will just
> overwrite the end of the buffer and not return an error code etc.
>
> However calling this skb_snprintf() would be odd, since you don't
> actually pass size. But it hints at what it does.
>
> So please add some kerneldoc describing what it actually does.
OK, some more neutral name like 'skb_fmt(...)' may be better indeed.
> Please also annotate the const char *fmt, so the compiler can do
> format string checks, parameter counting etc.
Surely '__printf(2, 3)' should be used here.
Dmitry
^ permalink raw reply
* RE: [BlueZ] src/shared: implement custom CCC callbacks for intercepting client notification subscriptions
From: bluez.test.bot @ 2026-04-23 16:08 UTC (permalink / raw)
To: linux-bluetooth, prathibha.madugonde
In-Reply-To: <20260423150454.1908352-1-prathm@qti.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1084770
---Test result---
Test Summary:
CheckPatch PASS 0.38 seconds
GitLint FAIL 0.23 seconds
BuildEll PASS 20.05 seconds
BluezMake PASS 648.61 seconds
MakeCheck PASS 0.99 seconds
MakeDistcheck PASS 245.41 seconds
CheckValgrind PASS 222.86 seconds
CheckSmatch PASS 346.42 seconds
bluezmakeextell PASS 180.81 seconds
IncrementalBuild PASS 656.03 seconds
ScanBuild PASS 1015.21 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ] src/shared: implement custom CCC callbacks for intercepting client notification subscriptions
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (101>80): "[BlueZ] src/shared: implement custom CCC callbacks for intercepting client notification subscriptions"
https://github.com/bluez/bluez/pull/2066
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez] 32ef84: src/shared: implement custom CCC callbacks for int...
From: prathibhamadugonde @ 2026-04-23 15:11 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1084770
Home: https://github.com/bluez/bluez
Commit: 32ef84ff9a295a75aa862c211be62ee6de640636
https://github.com/bluez/bluez/commit/32ef84ff9a295a75aa862c211be62ee6de640636
Author: Prathibha Madugonde <prathibha.madugonde@oss.qualcomm.com>
Date: 2026-04-23 (Thu, 23 Apr 2026)
Changed paths:
M src/shared/gatt-db.c
M src/shared/gatt-db.h
Log Message:
-----------
src/shared: implement custom CCC callbacks for intercepting client notification subscriptions
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH BlueZ] src/shared: implement custom CCC callbacks for intercepting client notification subscriptions
From: Prathibha Madugonde @ 2026-04-23 15:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg
From: Prathibha Madugonde <prathibha.madugonde@oss.qualcomm.com>
---
src/shared/gatt-db.c | 119 ++++++++++++++++++++++++++++++++++++++++++-
src/shared/gatt-db.h | 4 ++
2 files changed, 122 insertions(+), 1 deletion(-)
diff --git a/src/shared/gatt-db.c b/src/shared/gatt-db.c
index d0e149d6f..87cc61cf3 100644
--- a/src/shared/gatt-db.c
+++ b/src/shared/gatt-db.c
@@ -1214,6 +1214,112 @@ gatt_db_service_add_ccc(struct gatt_db_attribute *attrib, uint32_t permissions)
return ccc;
}
+static void ccc_custom_read(struct gatt_db_attribute *attrib,
+ unsigned int id, uint16_t offset,
+ uint8_t opcode, struct bt_att *att,
+ void *user_data)
+{
+ struct gatt_db *db = attrib->service->db;
+
+ db->ccc->read_func(attrib, id, offset, opcode, att, db->ccc->user_data);
+}
+
+static void custom_write_result(struct gatt_db_attribute *attr, int err,
+ void *user_data)
+{
+ int *result = user_data;
+
+ *result = err;
+}
+
+static void ccc_custom_write(struct gatt_db_attribute *attrib,
+ unsigned int id, uint16_t offset,
+ const uint8_t *value, size_t len,
+ uint8_t opcode, struct bt_att *att,
+ void *user_data)
+{
+ struct gatt_db_ccc *data = user_data;
+ struct gatt_db *db = attrib->service->db;
+ struct pending_write *p;
+ int err = 0;
+
+ /* Create another pending write to handle results from custom write
+ * function.
+ */
+ p = new0(struct pending_write, 1);
+ p->attrib = attrib;
+ p->id = ++attrib->write_id;
+ p->func = custom_write_result;
+ p->user_data = &err;
+
+ queue_push_tail(attrib->pending_writes, p);
+
+ /* Call custom write function first */
+ data->write_func(attrib, p->id, offset, value, len, opcode, att,
+ data->user_data);
+
+ if (err) {
+ gatt_db_attribute_write_result(attrib, id, err);
+ return;
+ }
+
+ /* If custom write function did not return error proceed to call the
+ * default CCC write function.
+ */
+ db->ccc->write_func(attrib, id, offset, value, len, opcode, att,
+ db->ccc->user_data);
+}
+
+struct gatt_db_attribute *
+gatt_db_service_add_ccc_custom(struct gatt_db_attribute *attrib,
+ uint32_t permissions,
+ gatt_db_write_t write_func, void *user_data)
+{
+ struct gatt_db *db;
+ struct gatt_db_attribute *ccc;
+ struct gatt_db_attribute *value;
+ uint16_t handle = 0;
+ struct gatt_db_ccc *data;
+
+ if (!attrib || !permissions)
+ return NULL;
+
+ db = attrib->service->db;
+
+ if (!db->ccc)
+ return NULL;
+
+ /* Locate value handle */
+ gatt_db_service_foreach_char(attrib, find_ccc_value, &handle);
+
+ if (!handle)
+ return NULL;
+
+ value = gatt_db_get_attribute(db, handle);
+ if (!value || value->notify_func)
+ return NULL;
+
+ data = new0(struct gatt_db_ccc, 1);
+ data->write_func = write_func;
+ data->user_data = user_data;
+
+ ccc = service_insert_descriptor(attrib->service, 0, &ccc_uuid,
+ permissions,
+ ccc_custom_read,
+ ccc_custom_write,
+ data);
+ if (!ccc) {
+ free(data);
+ return NULL;
+ }
+
+ gatt_db_attribute_set_fixed_length(ccc, 2);
+ ccc->notify_func = db->ccc->notify_func;
+ value->notify_func = db->ccc->notify_func;
+
+ return ccc;
+}
+
void gatt_db_ccc_register(struct gatt_db *db, gatt_db_read_t read_func,
gatt_db_write_t write_func,
gatt_db_notify_t notify_func,
@@ -2338,6 +2444,8 @@ bool gatt_db_attribute_notify(struct gatt_db_attribute *attrib,
struct bt_att *att)
{
struct gatt_db_attribute *ccc;
+ struct gatt_db *db;
+ void *notify_user_data;
if (!attrib || !attrib->notify_func)
return false;
@@ -2350,7 +2458,16 @@ bool gatt_db_attribute_notify(struct gatt_db_attribute *attrib,
if (!ccc)
return false;
- attrib->notify_func(attrib, ccc, value, len, att, ccc->user_data);
+ /* For custom CCC descriptors, use the database user_data for
+ * notify_func. For regular CCC descriptors, use the CCC's user_data.
+ */
+ db = attrib->service->db;
+ if (ccc->write_func == ccc_custom_write && db && db->ccc)
+ notify_user_data = db->ccc->user_data;
+ else
+ notify_user_data = ccc->user_data;
+
+ attrib->notify_func(attrib, ccc, value, len, att, notify_user_data);
return true;
}
diff --git a/src/shared/gatt-db.h b/src/shared/gatt-db.h
index dc2daf7fc..da0600c01 100644
--- a/src/shared/gatt-db.h
+++ b/src/shared/gatt-db.h
@@ -112,6 +112,10 @@ gatt_db_service_insert_descriptor(struct gatt_db_attribute *attrib,
struct gatt_db_attribute *
gatt_db_service_add_ccc(struct gatt_db_attribute *attrib, uint32_t permissions);
+struct gatt_db_attribute *
+gatt_db_service_add_ccc_custom(struct gatt_db_attribute *attrib,
+ uint32_t permissions,
+ gatt_db_write_t write_func, void *user_data);
struct gatt_db_attribute *
gatt_db_insert_included(struct gatt_db *db, uint16_t handle,
struct gatt_db_attribute *include);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 5.10.y 00/15] timers: Provide timer_shutdown[_sync]()
From: Jeongjun Park @ 2026-04-23 14:07 UTC (permalink / raw)
To: Greg KH
Cc: stable, tglx, Julia.Lawall, akpm, anna-maria, arnd,
linux-bluetooth, linux-kernel, linux, luiz.dentz, marcel, maz,
peterz, rostedt, sboyd, viresh.kumar, zouyipeng, linux-staging
In-Reply-To: <2026042327-wackiness-purify-09c2@gregkh>
Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > Ugh, I got the following build error for this series:
> > > ../drivers/misc/sgi-xp/xpc_partition.c: In function 'xpc_partition_disengaged':
> > > ../drivers/misc/sgi-xp/xpc_partition.c:294:25: error: implicit declaration of function 'del_singleshot_timer_sync' [-Werror=implicit-function-declaration]
> > > 294 | del_singleshot_timer_sync(&part->disengage_timer);
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> >
> > Oh dear. This issue occurred because commit 997754f114ef ("misc/sgi-xp:
> > Replace in_interrupt() usage") was merged into version 5.11-rc1 and was
> > therefore not backported to 5.10.y.
> >
> > Since this is a simple fix that only requires adding this commit to this
> > patch series, I will quickly write and send you the v2 patch.
> >
> > https://lore.kernel.org/all/20201119103151.ppo45mj53ulbxjx4@linutronix.de/
> >
> > >
> > > Don't know what happened, but I'll go and drop them all now.
> > >
> > > Do you _REALLY_ need these in the 5.10.y kernel? Who is going to use
> > > them?
> > >
> >
> > You might think it is unnecessary, but I have seen bug patches related to
> > timer_shutdown[_sync]() being backported after I backported it, and I
> > believe it is well worth backporting if this feature allows various
> > bug-fixing patches to be backported smoothly.
>
> So you don't have a specific issue you are hitting with this patch set
> that you want to have it here for? It can't be for android devices, as
> this patch series will be reverted from that tree, just like it was for
> the 5.15.y Android trees, so what systems require it?
>
I am not backporting because it is absolutely necessary for Android or a
specific system.
https://lore.kernel.org/all/20251007155808.438441-1-aha310510@gmail.com/T/#u
I simply started this in the hope that the same problem will not recur, as
I had to write a separate patch a few months ago when I backported a bug
fix patch I had written because the feature was missing.
> thanks,
>
> greg k-h
Regards,
Jeongjun Park
^ permalink raw reply
* Re: [PATCH 5.10.y 00/15] timers: Provide timer_shutdown[_sync]()
From: Greg KH @ 2026-04-23 13:43 UTC (permalink / raw)
To: Jeongjun Park
Cc: stable, tglx, Julia.Lawall, akpm, anna-maria, arnd,
linux-bluetooth, linux-kernel, linux, luiz.dentz, marcel, maz,
peterz, rostedt, sboyd, viresh.kumar, zouyipeng, linux-staging
In-Reply-To: <CAO9qdTE0NhB58hqK8_1=69bD7uG_vF-FfpQXGR8dqcuWV4H2Mw@mail.gmail.com>
On Thu, Apr 23, 2026 at 10:36:13PM +0900, Jeongjun Park wrote:
> Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Feb 20, 2026 at 02:12:55AM +0900, Jeongjun Park wrote:
> > > The "timers: Provide timer_shutdown[_sync]()" patch series implemented a
> > > useful feature that addresses various bugs caused by attempts to rearm
> > > shutdown timers.
> > >
> > > https://lore.kernel.org/all/20221123201306.823305113@linutronix.de/
> > >
> > > However, this patch series was not fully backported to versions prior to
> > > 6.2, requiring separate patches for older kernels if these bugs were
> > > encountered.
> > >
> > > The biggest problem with this is that even if these bugs were discovered
> > > and patched in the upstream kernel, if the maintainer or author didn't
> > > create a separate backport patch for versions prior to 6.2, the bugs would
> > > remain untouched in older kernels.
> > >
> > > Therefore, to reduce the hassle of having to write a separate patch, we
> > > should backport the remaining unbackported commits from the
> > > "timers: Provide timer_shutdown[_sync]()" patch series to versions prior
> > > to 6.2.
> > >
> > > ---
> > > Documentation/RCU/Design/Requirements/Requirements.rst | 2 +-
> > > Documentation/core-api/local_ops.rst | 2 +-
> > > Documentation/kernel-hacking/locking.rst | 17 ++---
> > > Documentation/timers/hrtimers.rst | 2 +-
> > > Documentation/translations/it_IT/kernel-hacking/locking.rst | 14 ++---
> > > arch/arm/mach-spear/time.c | 8 +--
> > > drivers/bluetooth/hci_qca.c | 10 ++-
> > > drivers/char/tpm/tpm-dev-common.c | 4 +-
> > > drivers/clocksource/arm_arch_timer.c | 12 ++--
> > > drivers/clocksource/timer-sp804.c | 6 +-
> > > drivers/staging/wlan-ng/hfa384x_usb.c | 4 +-
> > > drivers/staging/wlan-ng/prism2usb.c | 6 +-
> > > include/linux/timer.h | 17 ++++-
> > > kernel/time/timer.c | 316 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------
> > > net/sunrpc/xprt.c | 2 +-
> > > 15 files changed, 322 insertions(+), 100 deletions(-)
> > >
> >
> > Ugh, I got the following build error for this series:
> > ../drivers/misc/sgi-xp/xpc_partition.c: In function 'xpc_partition_disengaged':
> > ../drivers/misc/sgi-xp/xpc_partition.c:294:25: error: implicit declaration of function 'del_singleshot_timer_sync' [-Werror=implicit-function-declaration]
> > 294 | del_singleshot_timer_sync(&part->disengage_timer);
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~
> >
>
> Oh dear. This issue occurred because commit 997754f114ef ("misc/sgi-xp:
> Replace in_interrupt() usage") was merged into version 5.11-rc1 and was
> therefore not backported to 5.10.y.
>
> Since this is a simple fix that only requires adding this commit to this
> patch series, I will quickly write and send you the v2 patch.
>
> https://lore.kernel.org/all/20201119103151.ppo45mj53ulbxjx4@linutronix.de/
>
> >
> > Don't know what happened, but I'll go and drop them all now.
> >
> > Do you _REALLY_ need these in the 5.10.y kernel? Who is going to use
> > them?
> >
>
> You might think it is unnecessary, but I have seen bug patches related to
> timer_shutdown[_sync]() being backported after I backported it, and I
> believe it is well worth backporting if this feature allows various
> bug-fixing patches to be backported smoothly.
So you don't have a specific issue you are hitting with this patch set
that you want to have it here for? It can't be for android devices, as
this patch series will be reverted from that tree, just like it was for
the 5.15.y Android trees, so what systems require it?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 5.10.y 00/15] timers: Provide timer_shutdown[_sync]()
From: Jeongjun Park @ 2026-04-23 13:36 UTC (permalink / raw)
To: Greg KH
Cc: stable, tglx, Julia.Lawall, akpm, anna-maria, arnd,
linux-bluetooth, linux-kernel, linux, luiz.dentz, marcel, maz,
peterz, rostedt, sboyd, viresh.kumar, zouyipeng, linux-staging
In-Reply-To: <2026042355-blighted-chewing-5e50@gregkh>
Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Feb 20, 2026 at 02:12:55AM +0900, Jeongjun Park wrote:
> > The "timers: Provide timer_shutdown[_sync]()" patch series implemented a
> > useful feature that addresses various bugs caused by attempts to rearm
> > shutdown timers.
> >
> > https://lore.kernel.org/all/20221123201306.823305113@linutronix.de/
> >
> > However, this patch series was not fully backported to versions prior to
> > 6.2, requiring separate patches for older kernels if these bugs were
> > encountered.
> >
> > The biggest problem with this is that even if these bugs were discovered
> > and patched in the upstream kernel, if the maintainer or author didn't
> > create a separate backport patch for versions prior to 6.2, the bugs would
> > remain untouched in older kernels.
> >
> > Therefore, to reduce the hassle of having to write a separate patch, we
> > should backport the remaining unbackported commits from the
> > "timers: Provide timer_shutdown[_sync]()" patch series to versions prior
> > to 6.2.
> >
> > ---
> > Documentation/RCU/Design/Requirements/Requirements.rst | 2 +-
> > Documentation/core-api/local_ops.rst | 2 +-
> > Documentation/kernel-hacking/locking.rst | 17 ++---
> > Documentation/timers/hrtimers.rst | 2 +-
> > Documentation/translations/it_IT/kernel-hacking/locking.rst | 14 ++---
> > arch/arm/mach-spear/time.c | 8 +--
> > drivers/bluetooth/hci_qca.c | 10 ++-
> > drivers/char/tpm/tpm-dev-common.c | 4 +-
> > drivers/clocksource/arm_arch_timer.c | 12 ++--
> > drivers/clocksource/timer-sp804.c | 6 +-
> > drivers/staging/wlan-ng/hfa384x_usb.c | 4 +-
> > drivers/staging/wlan-ng/prism2usb.c | 6 +-
> > include/linux/timer.h | 17 ++++-
> > kernel/time/timer.c | 316 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------
> > net/sunrpc/xprt.c | 2 +-
> > 15 files changed, 322 insertions(+), 100 deletions(-)
> >
>
> Ugh, I got the following build error for this series:
> ../drivers/misc/sgi-xp/xpc_partition.c: In function 'xpc_partition_disengaged':
> ../drivers/misc/sgi-xp/xpc_partition.c:294:25: error: implicit declaration of function 'del_singleshot_timer_sync' [-Werror=implicit-function-declaration]
> 294 | del_singleshot_timer_sync(&part->disengage_timer);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
>
Oh dear. This issue occurred because commit 997754f114ef ("misc/sgi-xp:
Replace in_interrupt() usage") was merged into version 5.11-rc1 and was
therefore not backported to 5.10.y.
Since this is a simple fix that only requires adding this commit to this
patch series, I will quickly write and send you the v2 patch.
https://lore.kernel.org/all/20201119103151.ppo45mj53ulbxjx4@linutronix.de/
>
> Don't know what happened, but I'll go and drop them all now.
>
> Do you _REALLY_ need these in the 5.10.y kernel? Who is going to use
> them?
>
You might think it is unnecessary, but I have seen bug patches related to
timer_shutdown[_sync]() being backported after I backported it, and I
believe it is well worth backporting if this feature allows various
bug-fixing patches to be backported smoothly.
> thanks,
>
> greg k-h
Regards,
Jeongjun Park
^ permalink raw reply
* Re: [PATCH 5.10.y 00/15] timers: Provide timer_shutdown[_sync]()
From: Greg KH @ 2026-04-23 12:49 UTC (permalink / raw)
To: Jeongjun Park
Cc: stable, tglx, Julia.Lawall, akpm, anna-maria, arnd,
linux-bluetooth, linux-kernel, linux, luiz.dentz, marcel, maz,
peterz, rostedt, sboyd, viresh.kumar, zouyipeng, linux-staging
In-Reply-To: <20260219171310.118170-1-aha310510@gmail.com>
On Fri, Feb 20, 2026 at 02:12:55AM +0900, Jeongjun Park wrote:
> The "timers: Provide timer_shutdown[_sync]()" patch series implemented a
> useful feature that addresses various bugs caused by attempts to rearm
> shutdown timers.
>
> https://lore.kernel.org/all/20221123201306.823305113@linutronix.de/
>
> However, this patch series was not fully backported to versions prior to
> 6.2, requiring separate patches for older kernels if these bugs were
> encountered.
>
> The biggest problem with this is that even if these bugs were discovered
> and patched in the upstream kernel, if the maintainer or author didn't
> create a separate backport patch for versions prior to 6.2, the bugs would
> remain untouched in older kernels.
>
> Therefore, to reduce the hassle of having to write a separate patch, we
> should backport the remaining unbackported commits from the
> "timers: Provide timer_shutdown[_sync]()" patch series to versions prior
> to 6.2.
>
> ---
> Documentation/RCU/Design/Requirements/Requirements.rst | 2 +-
> Documentation/core-api/local_ops.rst | 2 +-
> Documentation/kernel-hacking/locking.rst | 17 ++---
> Documentation/timers/hrtimers.rst | 2 +-
> Documentation/translations/it_IT/kernel-hacking/locking.rst | 14 ++---
> arch/arm/mach-spear/time.c | 8 +--
> drivers/bluetooth/hci_qca.c | 10 ++-
> drivers/char/tpm/tpm-dev-common.c | 4 +-
> drivers/clocksource/arm_arch_timer.c | 12 ++--
> drivers/clocksource/timer-sp804.c | 6 +-
> drivers/staging/wlan-ng/hfa384x_usb.c | 4 +-
> drivers/staging/wlan-ng/prism2usb.c | 6 +-
> include/linux/timer.h | 17 ++++-
> kernel/time/timer.c | 316 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------
> net/sunrpc/xprt.c | 2 +-
> 15 files changed, 322 insertions(+), 100 deletions(-)
>
Ugh, I got the following build error for this series:
../drivers/misc/sgi-xp/xpc_partition.c: In function 'xpc_partition_disengaged':
../drivers/misc/sgi-xp/xpc_partition.c:294:25: error: implicit declaration of function 'del_singleshot_timer_sync' [-Werror=implicit-function-declaration]
294 | del_singleshot_timer_sync(&part->disengage_timer);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
Don't know what happened, but I'll go and drop them all now.
Do you _REALLY_ need these in the 5.10.y kernel? Who is going to use
them?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH BlueZ v2] sixaxis: Fix pairing Esperanza EGG109k controller
From: Bastien Nocera @ 2026-04-23 12:43 UTC (permalink / raw)
To: Marek Czerski; +Cc: linux-bluetooth
In-Reply-To: <20260422212045.1325603-1-ma.czerski@gmail.com>
Looks good to me
On Wed, 2026-04-22 at 23:20 +0200, Marek Czerski wrote:
> This change is required for Esperanza EGG109k ps controller clone.
> EGG109k looks like PS3 controller but presents itself to the system
> as PS4 controller. It does not respond to 0x81 command.
> Command 0x12 contains both the device bluetooth address as well as
> configured host bluetooth address, so it can be used to query
> both. Kernel driver hid-playstation also uses 0x12 command for that.
>
> Manufacturer link:
> https://esperanza.pl/esperanza-gamepad-bezprzewodowy-ps3-marine-czarny,176,1701.html
> ---
> plugins/sixaxis.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/plugins/sixaxis.c b/plugins/sixaxis.c
> index 27bc09815..a04a76d39 100644
> --- a/plugins/sixaxis.c
> +++ b/plugins/sixaxis.c
> @@ -39,6 +39,9 @@
> #include "profiles/input/server.h"
> #include "profiles/input/sixaxis.h"
>
> +#define DS4_FEATURE_REPORT_PAIRING_INFO 0x12
> +#define DS4_FEATURE_REPORT_PAIRING_INFO_SIZE 16
> +
> struct authentication_closure {
> guint auth_id;
> char *sysfs_path;
> @@ -111,12 +114,12 @@ static int sixaxis_get_device_bdaddr(int fd,
> bdaddr_t *bdaddr)
>
> static int ds4_get_device_bdaddr(int fd, bdaddr_t *bdaddr)
> {
> - uint8_t buf[7];
> + uint8_t buf[DS4_FEATURE_REPORT_PAIRING_INFO_SIZE];
> int ret;
>
> memset(buf, 0, sizeof(buf));
>
> - buf[0] = 0x81;
> + buf[0] = DS4_FEATURE_REPORT_PAIRING_INFO;
>
> ret = ioctl(fd, HIDIOCGFEATURE(sizeof(buf)), buf);
> if (ret < 0) {
> @@ -163,12 +166,12 @@ static int sixaxis_get_central_bdaddr(int fd,
> bdaddr_t *bdaddr)
>
> static int ds4_get_central_bdaddr(int fd, bdaddr_t *bdaddr)
> {
> - uint8_t buf[16];
> + uint8_t buf[DS4_FEATURE_REPORT_PAIRING_INFO_SIZE];
> int ret;
>
> memset(buf, 0, sizeof(buf));
>
> - buf[0] = 0x12;
> + buf[0] = DS4_FEATURE_REPORT_PAIRING_INFO;
>
> ret = ioctl(fd, HIDIOCGFEATURE(sizeof(buf)), buf);
> if (ret < 0) {
^ permalink raw reply
* Re: [RFC PATCH] net: skb: on zero-copy formatted output to skb
From: Andrew Lunn @ 2026-04-23 12:40 UTC (permalink / raw)
To: Dmitry Antipov
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-bluetooth
In-Reply-To: <20260423073638.778334-1-dmantipov@yandex.ru>
> +int skb_printf(struct sk_buff *skb, const char *fmt, ...)
> +{
> + int len, size = skb_availroom(skb);
> + va_list args;
> +
> + va_start(args, fmt);
> + len = vsnprintf(skb_tail_pointer(skb), size, fmt, args);
> + va_end(args);
> +
> + if (unlikely(len >= size))
> + return -ENOSPC;
A quick look in drivers/bluetooth suggests that none of them care
about truncation, at least they don't check the return code. Maybe it
would be better to truncate than return an error?
I would also try to make the behaviour consistent with the normal
sprintf(), or snprintf(). You want to give users some idea what it is
doing based on its name. It is well known that snprintf() will
truncate, and does not return an error code. sprintf() will just
overwrite the end of the buffer and not return an error code etc.
However calling this skb_snprintf() would be odd, since you don't
actually pass size. But it hints at what it does.
So please add some kerneldoc describing what it actually does.
Please also annotate the const char *fmt, so the compiler can do
format string checks, parameter counting etc.
Andrew
^ permalink raw reply
* Re: [RFC PATCH] net: skb: on zero-copy formatted output to skb
From: Andrew Lunn @ 2026-04-23 12:24 UTC (permalink / raw)
To: Dmitry Antipov
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-bluetooth
In-Reply-To: <20260423073638.778334-1-dmantipov@yandex.ru>
On Thu, Apr 23, 2026 at 10:36:38AM +0300, Dmitry Antipov wrote:
> Some code, most notably the Bluetooth drivers, uses something like
> the following:
>
> char buf[80];
> snprintf(buf, sizeof(buf), "Driver: %s\n", driver_name);
> skb_put_data(skb, buf, strlen(buf));
>
> This looks suboptimal at least because:
>
> 1) It yields in BUG() just in case the developer underestimates
> the size of an skb being used;
> 2) It requires extra data copy from an external buffer;
> 3) It uses 'strlen()' redundantly because actual data length
> is calculated by 'snprintf()' itself.
>
> So introduce 'skb_printf()' which aims to address all of these
> issues. As usual, thoughts and comments are highly appreciated.
Please always include at least one user of a new helper.
Do you plan to modify all the bluetooth drivers to use this?
Andrew
^ permalink raw reply
* RE: [BlueZ,v3,1/3] audio: Add ability to force CIS transport Links property
From: bluez.test.bot @ 2026-04-23 11:53 UTC (permalink / raw)
To: linux-bluetooth, frederic.danis
In-Reply-To: <20260423103934.22799-1-frederic.danis@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1084652
---Test result---
Test Summary:
CheckPatch PASS 1.62 seconds
GitLint PASS 0.99 seconds
BuildEll PASS 20.07 seconds
BluezMake PASS 607.25 seconds
MakeCheck PASS 19.20 seconds
MakeDistcheck PASS 235.07 seconds
CheckValgrind PASS 274.62 seconds
CheckSmatch PASS 321.53 seconds
bluezmakeextell PASS 165.35 seconds
IncrementalBuild PASS 619.37 seconds
ScanBuild PASS 926.27 seconds
https://github.com/bluez/bluez/pull/2065
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-04-23 10:59 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1084559
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 5d9d39: audio: Add ability to force CIS transport Links pr...
From: fdanis-oss @ 2026-04-23 10:59 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1084652
Home: https://github.com/bluez/bluez
Commit: 5d9d394b23b77074a7426dc86dc2738f0ac4a970
https://github.com/bluez/bluez/commit/5d9d394b23b77074a7426dc86dc2738f0ac4a970
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-04-23 (Thu, 23 Apr 2026)
Changed paths:
M profiles/audio/bap.c
M profiles/audio/transport.c
Log Message:
-----------
audio: Add ability to force CIS transport Links property
If bluetoothd is started in testing mode the Links property for CIS
is readwrite and can be used to force transport objects Links.
This can used to unlink transport objects by sending an empty array.
For unlinked transport objects, each transports needs to be acquired
separately.
This allows to pass PTS tests BAP/UCL/STR/BV-543-C and BV-546-C.
Commit: 5bb06b0f3ae0ede93d527685cfe02f35027a5b10
https://github.com/bluez/bluez/commit/5bb06b0f3ae0ede93d527685cfe02f35027a5b10
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-04-23 (Thu, 23 Apr 2026)
Changed paths:
M doc/org.bluez.MediaTransport.rst
Log Message:
-----------
doc: Add documentation for readwrite CIS transport Links property
This is only supported when bluetoothd is started in testing mode.
Commit: ed9b9a29eb03f91729ea5af221598fe257017d64
https://github.com/bluez/bluez/commit/ed9b9a29eb03f91729ea5af221598fe257017d64
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-04-23 (Thu, 23 Apr 2026)
Changed paths:
M client/player.c
Log Message:
-----------
client/player: Add support to unlink transports
This is used to pass PTS tests BAP/UCL/STR/BV-543-C and BV-546-C.
Compare: https://github.com/bluez/bluez/compare/5d9d394b23b7%5E...ed9b9a29eb03
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluetooth-next:master] BUILD SUCCESS 87151e363b7ef4c8b7e4e79ad5e718e69899ccb0
From: kernel test robot @ 2026-04-23 10:40 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git master
branch HEAD: 87151e363b7ef4c8b7e4e79ad5e718e69899ccb0 Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister
elapsed time: 1024m
configs tested: 60
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 randconfig-001-20260423 gcc-11.5.0
arm64 randconfig-002-20260423 clang-23
arm64 randconfig-003-20260423 gcc-14.3.0
arm64 randconfig-004-20260423 clang-16
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky randconfig-001-20260423 gcc-10.5.0
csky randconfig-002-20260423 gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-23
hexagon randconfig-001-20260423 clang-16
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
riscv allmodconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sparc allnoconfig gcc-15.2.0
sparc64 allmodconfig clang-23
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox