[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

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 --]

[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

[PATCH v1 5/6] wifi: mt76: mt7921-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.

The pointer is declared as const, which requires the addition of another
const for mt792x_get_mac80211_ops() to make the compiler happy which is
a nice side effect.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
 drivers/net/wireless/mediatek/mt76/mt7921/sdio.c | 4 ++--
 drivers/net/wireless/mediatek/mt76/mt792x.h      | 2 +-
 drivers/net/wireless/mediatek/mt76/mt792x_core.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/sdio.c b/drivers/net/wireless/mediatek/mt76/mt7921/sdio.c
index 3421e53dc948..284529fe6282 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/sdio.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/sdio.c
@@ -18,7 +18,7 @@
 
 static const struct sdio_device_id mt7921s_table[] = {
 	{ SDIO_DEVICE(SDIO_VENDOR_ID_MEDIATEK, 0x7901),
-		.driver_data = (kernel_ulong_t)MT7921_FIRMWARE_WM },
+		.driver_data_ptr = MT7921_FIRMWARE_WM },
 	{ }	/* Terminating entry */
 };
 
@@ -129,7 +129,7 @@ static int mt7921s_probe(struct sdio_func *func,
 	int ret;
 
 	ops = mt792x_get_mac80211_ops(&func->dev, &mt7921_ops,
-				      (void *)id->driver_data, &features);
+				      id->driver_data_ptr, &features);
 	if (!ops)
 		return -ENOMEM;
 
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x.h b/drivers/net/wireless/mediatek/mt76/mt792x.h
index 8388638ed550..51c36ef4084e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x.h
+++ b/drivers/net/wireless/mediatek/mt76/mt792x.h
@@ -436,7 +436,7 @@ int mt792x_init_wiphy(struct ieee80211_hw *hw);
 struct ieee80211_ops *
 mt792x_get_mac80211_ops(struct device *dev,
 			const struct ieee80211_ops *mac80211_ops,
-			void *drv_data, u8 *fw_features);
+			const void *drv_data, u8 *fw_features);
 int mt792x_init_wcid(struct mt792x_dev *dev);
 int mt792x_mcu_drv_pmctrl(struct mt792x_dev *dev);
 int mt792x_mcu_fw_pmctrl(struct mt792x_dev *dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_core.c b/drivers/net/wireless/mediatek/mt76/mt792x_core.c
index f2ed16feb6c1..b92bae3f2151 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_core.c
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_core.c
@@ -763,7 +763,7 @@ mt792x_get_offload_capability(struct device *dev, const char *fw_wm)
 struct ieee80211_ops *
 mt792x_get_mac80211_ops(struct device *dev,
 			const struct ieee80211_ops *mac80211_ops,
-			void *drv_data, u8 *fw_features)
+			const void *drv_data, u8 *fw_features)
 {
 	struct ieee80211_ops *ops;
 
-- 
2.47.3