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