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

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

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@xxxxxxxxxxxx> 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: signature.asc
Description: PGP signature