Re: [PATCH v1 0/2] firewire: Simplify storing pointers in device id struct
Takashi Sakamoto <[email protected]> Mon, 20 Apr 2026 18:08:16 +0900
| Newsgroups | gmane.linux.kernel.firewire.devel,gmane.linux.sound |
|---|---|
| Message-ID | <[email protected]> |
Hi, Thanks for the patches. As far as I can see, they can be applied neither any compilation failures and running regressions. We are in the middle of merge window for v7.2. I had not planned to send any changes to upstream for firewire subsystem, but there is still some time before it closes. If the sound subsystem maintainer does not mind, I would like to proceed. Just out of curiosity, what does the CHERI extension adopted to RISC-V architecture require in terms of kernel programming? Is taking extra care when storing pointer values in long-type variables sufficient in driver code? Thanks Takashi Sakamoto On Sun, Apr 19, 2026 at 08:42:12AM +0200, Uwe Kleine-K=F6nig (The Capable H= ub) wrote: > Hello, > = > <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", sometimes = > the type is plain unsigned long) > - const void *data (sometimes called "driver_data" or "context", sometim= es not const) > = > A considerable amount of drivers for the first category uses the > unsigned long variable to store a pointer. This involves casting both > for assignment and usage. > = > An additional complication exists for the CHERI hardware extension > where sizeof(void *) > sizeof(unsigned long). So with that an unsigned > long variable cannot be used to store a pointer. > = > To address both issues this series replaces the unsigned long variable > by an anonymous union containing both an unsigned long and a pointer. > = > For all non-CHERI architectures this isn't an ABI change because all > have sizeof(void *) =3D=3D sizeof(unsigned long). > = > The first patch changes the definition of struct ieee1394_device_id. The > second drops some casts in sound drivers. (There are no other firewire > drivers that could benefit.) I adapted all sound drivers in a single > patch, tell me if I should split per driver. > = > For merging I suggest to take the whole series via the ALSA tree in the > next merge window, as there are no modified files that are specific to > firewire only and the second patch depends on the first. > = > Best regards > Uwe > = > Uwe Kleine-K=F6nig (The Capable Hub) (2): > firewire: Simplify storing pointers in device id struct > ALSA: firewire: Make use of ieee1394's .driver_data_ptr > = > include/linux/mod_devicetable.h | 5 ++++- > sound/firewire/dice/dice.c | 34 ++++++++++++++++----------------- > sound/firewire/fireface/ff.c | 12 ++++++------ > sound/firewire/motu/motu.c | 6 +++--- > sound/firewire/oxfw/oxfw.c | 4 ++-- > 5 files changed, 32 insertions(+), 29 deletions(-) > = > = > base-commit: 028ef9c96e96197026887c0f092424679298aae8 > -- = > 2.47.3 > =