All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 20 Apr 2026 18:08:16 +0900	[thread overview]
Message-ID: <20260420090816.GA11108@sakamocchi.jp> (raw)
In-Reply-To: <cover.1776579304.git.u.kleine-koenig@baylibre.com>

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

  parent reply	other threads:[~2026-04-20  9:08 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 ` Takashi Sakamoto [this message]
2026-04-20 17:39   ` [PATCH v1 0/2] firewire: Simplify storing pointers in device id struct 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
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=20260420090816.GA11108@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.