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

["Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>]

<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