From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
Cc: Clemens Ladisch <clemens@ladisch.de>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
"Christian A. Ehrhardt" <lk@c--e.de>,
"Christian A. Ehrhardt" <christian.ehrhardt@codasip.com>,
linux1394-devel@lists.sourceforge.net,
linux-sound@vger.kernel.org,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH v1 0/2] firewire: Simplify storing pointers in device id struct
Date: Thu, 23 Apr 2026 23:19:59 +0900 [thread overview]
Message-ID: <20260423141959.GA268626@sakamocchi.jp> (raw)
In-Reply-To: <cover.1776579304.git.u.kleine-koenig@baylibre.com>
Hi,
It is unclear who is responsible for maintaining the 'ieee1394_device_id'
structure in include/linux/mod_devicetable.h, but if it falls under my
responsibility (which seems likely), I would prefer to postpone applying
these patches, or at least exclude them from this merge window.
After reading the discussions around the UAPI, I am not fully convinced
that your patches appear to provide clear benefits to existing
IEEE 1394 bus users or their software. From my perspective, the motivation
appears to be primarily related to the CHERI extension work.
As you know, this subsystem is quite marginal in the Linux kernel
codebase. Given that, it might be worth considering whether this
subsystem should be excluded from the build target when capability
pointers are enabled (e.g. via Kconfig, if available), since it does not
appear to work outside the ILP32 or LP64 data models. It may be worth
carefully considering where effort is best spent. I can understand the
merits of CHERI extensions, but changes related to this subsystem would
likely be acceptable only after the kernel core functions have been
updated.
That said, this is just my current view. I would welcome any feedback or
objections. Besides, it is still one of my tasks to figure out how to
adapt the UAPI structures and the firewire core implementations to
non-ILP32/LP64 data models.
Thanks
Takashi Sakamoto
On Sun, Apr 19, 2026 at 08:42:12AM +0200, Uwe Kleine-König (The Capable Hub) 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", sometimes 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 *) == 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önig (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
>
next prev parent reply other threads:[~2026-04-23 14:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-19 6:42 [PATCH v1 0/2] firewire: Simplify storing pointers in device id struct Uwe Kleine-König (The Capable Hub)
2026-04-19 6:42 ` [PATCH v1 1/2] " Uwe Kleine-König (The Capable Hub)
2026-04-19 6:42 ` [PATCH v1 2/2] ALSA: firewire: Make use of ieee1394's .driver_data_ptr Uwe Kleine-König (The Capable Hub)
2026-04-20 8:48 ` Andy Shevchenko
2026-04-20 9:08 ` [PATCH v1 0/2] firewire: Simplify storing pointers in device id struct Takashi Sakamoto
2026-04-20 17:39 ` Christian A. Ehrhardt
2026-04-21 12:53 ` Takashi Sakamoto
2026-04-21 14:07 ` Uwe Kleine-König (The Capable Hub)
2026-04-22 7:19 ` Andy Shevchenko
2026-04-22 8:30 ` Uwe Kleine-König (The Capable Hub)
2026-04-22 8:40 ` Uwe Kleine-König (The Capable Hub)
2026-04-22 9:40 ` Andy Shevchenko
2026-04-22 10:10 ` Uwe Kleine-König (The Capable Hub)
2026-04-21 16:20 ` Christian A. Ehrhardt
2026-04-23 14:19 ` Takashi Sakamoto [this message]
2026-04-23 16:53 ` Uwe Kleine-König (The Capable Hub)
2026-04-27 6:37 ` Takashi Sakamoto
2026-04-27 8:07 ` Uwe Kleine-König (The Capable Hub)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260423141959.GA268626@sakamocchi.jp \
--to=o-takashi@sakamocchi.jp \
--cc=andriy.shevchenko@linux.intel.com \
--cc=christian.ehrhardt@codasip.com \
--cc=clemens@ladisch.de \
--cc=linux-sound@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=lk@c--e.de \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=u.kleine-koenig@baylibre.com \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox