Re: [PATCH v1 0/2] firewire: Simplify storing pointers in device id struct

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Apr 21, 2026 at 04:07:42PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> On Tue, Apr 21, 2026 at 09:53:57PM +0900, Takashi Sakamoto wrote:
> > On Mon, Apr 20, 2026 at 07:39:32PM +0200, Christian A. Ehrhardt wrote:
> > > On Mon, Apr 20, 2026 at 06:08:16PM +0900, Takashi Sakamoto wrote:

...

> > Thanks for the references. It looks like there is not much to consider
> > outside of mm subsystem. But I have some concerns if supporting
> > ARM/RISC-V adoptation of CHERI extension in Linux FireWire subsystem.
> > 
> > Any structures in UAPI header of this subsystem are defined with
> > an assumption that the size of pointer in the existing System V
> > architectures is up to 64 bits at most. We can see many usage of
> > '__u64' type member for pointers (e.g. 'rom' in fw_cdev_get_info
> > structure). I imagine to need defining specific structures for this kind
> > of 'fat' pointer. (The same assumption lays on compat ioctl.)
> 
> The Standard C answer to that is: The assumption that you can fit a
> pointer in an unsigned long or u64 is not generally justified. This is
> "only" given for all current Linux archtectures. And if you want an
> integer type to store a pointer, use uintptr_t.

No, please don't. Linus was clear about this. Use `unsigned long` in that case.

> (And my position is that
> you better try to keep pointers in pointer variables, though there are
> some situations where you don't come around the conversion to an integer
> type. That's why I introduced the union instead of converting to
> uintptr_t.)

-- 
With Best Regards,
Andy Shevchenko