[PATCH v1 0/6] sdio: About pointers in sdio_device_id::driver_data

[PATCH v1 0/6] sdio: About pointers in sdio_device_id::driver_data

[Uwe Kleine-König (The Capable Hub)]

<linux/mod_devicetable.h> contains several device_id structs for various
device types.

Most of them have one of:

 - kernel_ulong_t driver_data (sometimes called "driver_info")
 - unsigned long driver_data
 - const void *data (sometimes called "driver_data" or "context", sometimes not const)

Taking sdio_device_id as an arbitrary[1] example (which has
kernel_ulong_t driver_data), there are drivers that store integer values
in it (e.g.  drivers/media/mmc/siano/smssdio.c) and others use pointers
(e.g.  drivers/net/wireless/realtek/rtw88/rtw8723ds.c). The latter
involves explicit casting, both for initialisation and for usage.

In the past I tried to address this using i2c as discussion case[2].
Back then the motivation was just to get rid of the ugly casts. Today
I'm working on CHERI which is an architecture extension (currently for
arm and riscv) that uses 128 bit pointers to store additional
information, implementing e.g. read-only pointers and preventing out of
bounds access on the hardware level.

The complication here is that a kernel_ulong_t (which is still 64 bit with
CHERI) cannot store a pointer.

The obvious way to fix that is to replace the kernel_ulong_t by an anonymous
union that contains the original unsigned long and a pointer. This doesn't 
change the size (or layout) of the device id struct for archs where 
sizeof(long) >= sizeof(void *) [3] and gets rid of the casting. On CHERI archs 
this is an ABI change, but as a new architecture changing ABI isn't an
issue there.

I was surprised that changing struct sdio_device_id didn't require
preparation in the various drivers as they all already use named
initializers.

So the first patch expands struct sdio_device_id and the 5 following
patches implement cleanups that can be done then.

Patches 2 to 6 all depend on the first patch (only). This is not urgent
and thus merge window material. I guess merging of this series has to
happen in 3 steps:

 1) patch #1 via mmc
 2) patches #2 and #3 via bluetooth
 3) patches #4 - #6 via wireless

(where 2) and 3) are independent).

The series was build tested on arm64.

[1] well, one that isn't used as much as spi_device_id or i2c_device_id to have  get a manageable POC.
[2] https://lore.kernel.org/lkml/20240426213832.915485-2-u.kleine-koenig@pengutronix.de
[3] As of now this is true on all architectures running Linux even with s/>=/==/


Uwe Kleine-König (The Capable Hub) (6):
  sdio: Add syntactic sugar to store a pointer in sdio_driver_id
  Bluetooth: btmrvl_sdio: Make use of driver data pointer in
    sdio_device_id
  Bluetooth: btmtksdio: Make use of driver data pointer in
    sdio_device_id
  wifi: rtw88: Benefit from sdio_device_id::driver_data_ptr
  wifi: mt76: mt7921-sdio: Make use of driver data pointer in
    sdio_device_id
  wifi: mwifiex: Make use of driver data pointer in sdio_device_id

 drivers/bluetooth/btmrvl_sdio.c               | 22 ++++++++---------
 drivers/bluetooth/btmtksdio.c                 |  8 +++----
 drivers/net/wireless/marvell/mwifiex/sdio.c   | 24 +++++++++----------
 .../net/wireless/mediatek/mt76/mt7921/sdio.c  |  4 ++--
 drivers/net/wireless/mediatek/mt76/mt792x.h   |  2 +-
 .../net/wireless/mediatek/mt76/mt792x_core.c  |  2 +-
 .../net/wireless/realtek/rtw88/rtw8723cs.c    |  2 +-
 .../net/wireless/realtek/rtw88/rtw8723ds.c    |  4 ++--
 .../net/wireless/realtek/rtw88/rtw8821cs.c    |  2 +-
 .../net/wireless/realtek/rtw88/rtw8822bs.c    |  2 +-
 .../net/wireless/realtek/rtw88/rtw8822cs.c    |  2 +-
 drivers/net/wireless/realtek/rtw88/sdio.c     |  2 +-
 include/linux/mod_devicetable.h               |  5 +++-
 13 files changed, 42 insertions(+), 39 deletions(-)


base-commit: 028ef9c96e96197026887c0f092424679298aae8
-- 
2.47.3

[PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id

[Uwe Kleine-König (The Capable Hub)]

On all current Linux architectures sizeof(long) == sizeof(void *) and
this is used a lot through the kernel. For example it enables the usual
practice to store pointers in sdio_driver_id's .driver_data member.

This works fine, but involves casting and thus isn't type-safe.
Additionally with the CHERI architecture extension there are machines
with sizeof(void *) > sizeof(long) for with the traditional approach of
storing a pointer in .driver_data doesn't work.

By replacing the plain unsigned long .driver_data by an anonymous union,
most of the casting can be dropped and it yields a working solution for
CHERI.

All users of struct sdio_driver_id are initialized in a way that is
compatible with the new definition, so no adaptions are needed there.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
 include/linux/mod_devicetable.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 5b1725fe9707..0eb5d196f5b5 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -414,7 +414,10 @@ struct sdio_device_id {
 	__u8	class;			/* Standard interface or SDIO_ANY_ID */
 	__u16	vendor;			/* Vendor or SDIO_ANY_ID */
 	__u16	device;			/* Device ID or SDIO_ANY_ID */
-	kernel_ulong_t driver_data;	/* Data private to the driver */
+	union {				/* Data private to the driver */
+		kernel_ulong_t driver_data;
+		const void *driver_data_ptr;
+	};
 };
 
 /* SSB core, see drivers/ssb/ */
-- 
2.47.3

[PATCH v1 2/6] Bluetooth: btmrvl_sdio: Make use of driver data pointer in sdio_device_id

[Uwe Kleine-König (The Capable Hub)]

Recently struct sdio_device_id gained a new member to store a pointer to
driver data. Make use of that to get rid of a bunch of casts.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
 drivers/bluetooth/btmrvl_sdio.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 93932a0d8625..ad28bee56961 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -301,31 +301,31 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8997 = {
 static const struct sdio_device_id btmrvl_sdio_ids[] = {
 	/* Marvell SD8688 Bluetooth device */
 	{ SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8688_BT),
-			.driver_data = (unsigned long)&btmrvl_sdio_sd8688 },
+			.driver_data_ptr = &btmrvl_sdio_sd8688 },
 	/* Marvell SD8787 Bluetooth device */
 	{ SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8787_BT),
-			.driver_data = (unsigned long)&btmrvl_sdio_sd8787 },
+			.driver_data_ptr = &btmrvl_sdio_sd8787 },
 	/* Marvell SD8787 Bluetooth AMP device */
 	{ SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8787_BT_AMP),
-			.driver_data = (unsigned long)&btmrvl_sdio_sd8787 },
+			.driver_data_ptr = &btmrvl_sdio_sd8787 },
 	/* Marvell SD8797 Bluetooth device */
 	{ SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8797_BT),
-			.driver_data = (unsigned long)&btmrvl_sdio_sd8797 },
+			.driver_data_ptr = &btmrvl_sdio_sd8797 },
 	/* Marvell SD8887 Bluetooth device */
 	{ SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8887_BT),
-			.driver_data = (unsigned long)&btmrvl_sdio_sd8887 },
+			.driver_data_ptr = &btmrvl_sdio_sd8887 },
 	/* Marvell SD8897 Bluetooth device */
 	{ SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8897_BT),
-			.driver_data = (unsigned long)&btmrvl_sdio_sd8897 },
+			.driver_data_ptr = &btmrvl_sdio_sd8897 },
 	/* Marvell SD8977 Bluetooth device */
 	{ SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8977_BT),
-			.driver_data = (unsigned long)&btmrvl_sdio_sd8977 },
+			.driver_data_ptr = &btmrvl_sdio_sd8977 },
 	/* Marvell SD8987 Bluetooth device */
 	{ SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8987_BT),
-			.driver_data = (unsigned long)&btmrvl_sdio_sd8987 },
+			.driver_data_ptr = &btmrvl_sdio_sd8987 },
 	/* Marvell SD8997 Bluetooth device */
 	{ SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8997_BT),
-			.driver_data = (unsigned long)&btmrvl_sdio_sd8997 },
+			.driver_data_ptr = &btmrvl_sdio_sd8997 },
 
 	{ }	/* Terminating entry */
 };
@@ -1523,8 +1523,8 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
 
 	card->func = func;
 
-	if (id->driver_data) {
-		struct btmrvl_sdio_device *data = (void *) id->driver_data;
+	if (id->driver_data_ptr) {
+		const struct btmrvl_sdio_device *data = id->driver_data_ptr;
 		card->helper = data->helper;
 		card->firmware = data->firmware;
 		card->reg = data->reg;
-- 
2.47.3

[PATCH v1 3/6] Bluetooth: btmtksdio: Make use of driver data pointer in sdio_device_id

[Uwe Kleine-König (The Capable Hub)]

Recently struct sdio_device_id gained a new member to store a pointer to
driver data. Make use of that to get rid of a bunch of casts.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
 drivers/bluetooth/btmtksdio.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
index e986e5af51ae..ee886dcada63 100644
--- a/drivers/bluetooth/btmtksdio.c
+++ b/drivers/bluetooth/btmtksdio.c
@@ -64,11 +64,11 @@ static const struct btmtksdio_data mt7921_data = {
 
 static const struct sdio_device_id btmtksdio_table[] = {
 	{SDIO_DEVICE(SDIO_VENDOR_ID_MEDIATEK, SDIO_DEVICE_ID_MEDIATEK_MT7663),
-	 .driver_data = (kernel_ulong_t)&mt7663_data },
+	 .driver_data_ptr = &mt7663_data },
 	{SDIO_DEVICE(SDIO_VENDOR_ID_MEDIATEK, SDIO_DEVICE_ID_MEDIATEK_MT7668),
-	 .driver_data = (kernel_ulong_t)&mt7668_data },
+	 .driver_data_ptr = &mt7668_data },
 	{SDIO_DEVICE(SDIO_VENDOR_ID_MEDIATEK, SDIO_DEVICE_ID_MEDIATEK_MT7961),
-	 .driver_data = (kernel_ulong_t)&mt7921_data },
+	 .driver_data_ptr = &mt7921_data },
 	{ }	/* Terminating entry */
 };
 MODULE_DEVICE_TABLE(sdio, btmtksdio_table);
@@ -1352,7 +1352,7 @@ static int btmtksdio_probe(struct sdio_func *func,
 	if (!bdev)
 		return -ENOMEM;
 
-	bdev->data = (void *)id->driver_data;
+	bdev->data = id->driver_data_ptr;
 	if (!bdev->data)
 		return -ENODEV;
 
-- 
2.47.3

RE: sdio: About pointers in sdio_device_id::driver_data

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

This is an automated email and please do not reply to this email.

Dear Submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.

----- Output -----

error: patch failed: drivers/bluetooth/btmtksdio.c:64
error: drivers/bluetooth/btmtksdio.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch

Please resolve the issue and submit the patches again.


---
Regards,
Linux Bluetooth

Re: sdio: About pointers in sdio_device_id::driver_data

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

Hello,

some feedback for this mail:

On Fri, Apr 17, 2026 at 07:11:42AM -0700, bluez.test.bot@gmail.com wrote:
> This is an automated email and please do not reply to this email.

I hope it's ok to ignore this request here :-)

> While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.

It would be great to point out the URL and commit hash of this current
HEAD to simplify acting on that and also be able to understand the
details of the mail in a few weeks when the repository probably got a
few more commits.

Having said that, the patch series fits on top of
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git's
HEAD currently at bc39a094730c ("Bluetooth: hci_sync: fix stack buffer
overflow in hci_le_big_create_sync"). But I guess "the repository" is
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
that indeed contains a conflicting commit.

Assuming that the series being applicable to the bluetooth HEAD isn't
the only test done here, a great way to make the bot reply more useful
would be to honor

	base-commit: 028ef9c96e96197026887c0f092424679298aae8

from the cover letter and then provide more test results (after pointing
out that the wrong base was chosen).

> ----- Output -----
> 
> error: patch failed: drivers/bluetooth/btmtksdio.c:64
> error: drivers/bluetooth/btmtksdio.c: patch does not apply
> hint: Use 'git am --show-current-patch' to see the failed patch
> 
> Please resolve the issue and submit the patches again.

Given that the bluetooth parts are not ready for application now without
the first patch in the series, I won't do that now.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id

[Uwe Kleine-König (The Capable Hub)]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

Hello,

On Fri, Apr 17, 2026 at 03:10:47PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> On all current Linux architectures sizeof(long) == sizeof(void *) and
> this is used a lot through the kernel. For example it enables the usual
> practice to store pointers in sdio_driver_id's .driver_data member.
> 
> This works fine, but involves casting and thus isn't type-safe.
> Additionally with the CHERI architecture extension there are machines
> with sizeof(void *) > sizeof(long) for with the traditional approach of
> storing a pointer in .driver_data doesn't work.
> 
> By replacing the plain unsigned long .driver_data by an anonymous union,
> most of the casting can be dropped and it yields a working solution for
> CHERI.
> 
> All users of struct sdio_driver_id are initialized in a way that is
> compatible with the new definition, so no adaptions are needed there.

sashiko.dev found s/sdio_driver_id/sdio_device_id/ twice in the commit
log and once in the short log. If you consider applying this patch
please adapt the commit message accordingly.

Many thanks to those who created sashiko.dev!

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id

[Luiz Augusto von Dentz]

Hi Uwe,

On Mon, Apr 20, 2026 at 4:31 PM Uwe Kleine-König (The Capable Hub)
<u.kleine-koenig@baylibre.com> wrote:
>
> Hello,
>
> On Fri, Apr 17, 2026 at 03:10:47PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > On all current Linux architectures sizeof(long) == sizeof(void *) and
> > this is used a lot through the kernel. For example it enables the usual
> > practice to store pointers in sdio_driver_id's .driver_data member.
> >
> > This works fine, but involves casting and thus isn't type-safe.
> > Additionally with the CHERI architecture extension there are machines
> > with sizeof(void *) > sizeof(long) for with the traditional approach of
> > storing a pointer in .driver_data doesn't work.
> >
> > By replacing the plain unsigned long .driver_data by an anonymous union,
> > most of the casting can be dropped and it yields a working solution for
> > CHERI.
> >
> > All users of struct sdio_driver_id are initialized in a way that is
> > compatible with the new definition, so no adaptions are needed there.
>
> sashiko.dev found s/sdio_driver_id/sdio_device_id/ twice in the commit
> log and once in the short log. If you consider applying this patch
> please adapt the commit message accordingly.

No problem I can fix them up once applying.

> Many thanks to those who created sashiko.dev!
>
> Best regards
> Uwe

We only received 1-3 of the 6:

https://patchwork.kernel.org/project/bluetooth/list/?series=1082520

Or is this on purpose, and we should consider the set complete?

-- 
Luiz Augusto von Dentz

Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id

[Uwe Kleine-König (The Capable Hub)]

[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]

Hello Luiz,

On Mon, Apr 20, 2026 at 04:46:56PM -0400, Luiz Augusto von Dentz wrote:
> On Mon, Apr 20, 2026 at 4:31 PM Uwe Kleine-König (The Capable Hub)
> <u.kleine-koenig@baylibre.com> wrote:
> > On Fri, Apr 17, 2026 at 03:10:47PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > On all current Linux architectures sizeof(long) == sizeof(void *) and
> > > this is used a lot through the kernel. For example it enables the usual
> > > practice to store pointers in sdio_driver_id's .driver_data member.
> > >
> > > This works fine, but involves casting and thus isn't type-safe.

To be honest, with the involved void* this isn't really type-safe
either, but at least the data keeps being a pointer which is really
helpful on CHERI. FTR: The alternative would be to use uintptr_t instead
of unsigned long, which also has proponents in the CHERI community and
which is used in the current vendor patch stack.

> > > Additionally with the CHERI architecture extension there are machines
> > > with sizeof(void *) > sizeof(long) for with the traditional approach of
> > > storing a pointer in .driver_data doesn't work.
> > >
> > > By replacing the plain unsigned long .driver_data by an anonymous union,
> > > most of the casting can be dropped and it yields a working solution for
> > > CHERI.
> > >
> > > All users of struct sdio_driver_id are initialized in a way that is
> > > compatible with the new definition, so no adaptions are needed there.
> >
> > sashiko.dev found s/sdio_driver_id/sdio_device_id/ twice in the commit
> > log and once in the short log. If you consider applying this patch
> > please adapt the commit message accordingly.
> 
> No problem I can fix them up once applying.

Thanks! If a new revision should be needed, of course I'll fix that,
too.

> > Many thanks to those who created sashiko.dev!
> >
> > Best regards
> > Uwe
> 
> We only received 1-3 of the 6:
> 
> https://patchwork.kernel.org/project/bluetooth/list/?series=1082520
> 
> Or is this on purpose, and we should consider the set complete?

The remaining patches are for wifi. My expectation was that they go in
via wifi+netdev once the first patch is in their base. But of course I'm
open for maintainer coordination to let the series go in in less steps
than I expected. If that helps I can also create an immutable branch,
but I have no urge here, so if only the first patch goes in during the
next merge window, I won't have problems to keep track of the remaining
bits.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id

[Johannes Berg]

On Tue, 2026-04-21 at 10:12 +0200, Uwe Kleine-König (The Capable Hub)
wrote:
> > 
> > We only received 1-3 of the 6:
> > 
> > https://patchwork.kernel.org/project/bluetooth/list/?series=1082520
> > 
> > Or is this on purpose, and we should consider the set complete?
> 
> The remaining patches are for wifi. My expectation was that they go in
> via wifi+netdev once the first patch is in their base. But of course I'm
> open for maintainer coordination to let the series go in in less steps
> than I expected. If that helps I can also create an immutable branch,
> but I have no urge here, so if only the first patch goes in during the
> next merge window, I won't have problems to keep track of the remaining
> bits.

It's probably better for everything all around, including the various
automations that test patch series, if you just flip a coin, send these
to either BT or WiFi, and then resend the others later :)

All assuming we get an ACK from whoever is responsible for patch 1 to
merge it through some other tree :)

johannes

Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id

[Uwe Kleine-König (The Capable Hub)]

[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

Hello Johannes,

On Tue, Apr 21, 2026 at 10:59:04AM +0200, Johannes Berg wrote:
> On Tue, 2026-04-21 at 10:12 +0200, Uwe Kleine-König (The Capable Hub)
> wrote:
> > > 
> > > We only received 1-3 of the 6:
> > > 
> > > https://patchwork.kernel.org/project/bluetooth/list/?series=1082520
> > > 
> > > Or is this on purpose, and we should consider the set complete?
> > 
> > The remaining patches are for wifi. My expectation was that they go in
> > via wifi+netdev once the first patch is in their base. But of course I'm
> > open for maintainer coordination to let the series go in in less steps
> > than I expected. If that helps I can also create an immutable branch,
> > but I have no urge here, so if only the first patch goes in during the
> > next merge window, I won't have problems to keep track of the remaining
> > bits.
> 
> It's probably better for everything all around, including the various
> automations that test patch series, if you just flip a coin, send these
> to either BT or WiFi, and then resend the others later :)

The first patch of this series adapting sdio_device_id is technically
mmc material. However to demonstrate the upside of this patch you also
have to look at at least one of bluetooth and wifi. So even if I drop
one of those there are still two subsystems involved. And then in my
subjective view it doesn't matter much if I involve two or three
subsystems. Regarding test automations I would assume that if the
bluetooth bot sees patches #1-#4 of this series it can do something
already (involving either testing the series only partially or finding
all 6 patches on lore). And then this isn't worse than just sending the
first four patches of the series and delaying wifi until later.

But I agree that's a trade-off.

Having said that, I'm happy if the first patch is merged and patches #2
to #6 are discarded by the bluetooth and wifi people. I'll come back to
them once the first patch is in a release.

> All assuming we get an ACK from whoever is responsible for patch 1 to
> merge it through some other tree :)

To make this more explicit: That would be Ulf as MMC maintainer.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id

[Johannes Berg]

Hi Uwe,

> > It's probably better for everything all around, including the various
> > automations that test patch series, if you just flip a coin, send these
> > to either BT or WiFi, and then resend the others later :)
> 
> The first patch of this series adapting sdio_device_id is technically
> mmc material. 

Right.

> However to demonstrate the upside of this patch you also
> have to look at at least one of bluetooth and wifi. So even if I drop
> one of those there are still two subsystems involved.

Sure, that's fair.

> And then in my
> subjective view it doesn't matter much if I involve two or three
> subsystems. Regarding test automations I would assume that if the
> bluetooth bot sees patches #1-#4 of this series it can do something
> already (involving either testing the series only partially or finding
> all 6 patches on lore).

Yeah, that's a fair assumption, except at least for wifi, the
automations (like netdev, the nipa software) only ever runs on series
that it receives completely, since everyone gets CC'ed on random things
too much and having the full series is a proxy for "should be applied
here."

> Having said that, I'm happy if the first patch is merged and patches #2
> to #6 are discarded by the bluetooth and wifi people. I'll come back to
> them once the first patch is in a release.
> 
> > All assuming we get an ACK from whoever is responsible for patch 1 to
> > merge it through some other tree :)
> 
> To make this more explicit: That would be Ulf as MMC maintainer.

I'm also happy to merge the MMC (with Ulf's ACK) and WiFi parts, though
that's even scattered with my sub-maintainers, but that just needs some
coordination... I'd just like to then have a complete series on the list
so I don't have to all the (build) testing manually.

If either BT or WiFi merge the relevant patches then we can sync via
net-next pretty quickly and get all of it done soon, if the first patch
is via MMC then it'll probably take a whole other release cycle ...

johannes