Re: [PATCH] device property: Make modifications of fwnode "flags" thread safe

[Andy Shevchenko]

On Wed, Mar 18, 2026 at 09:41:44AM +0100, Geert Uytterhoeven wrote:
> On Tue, 17 Mar 2026 at 08:34, Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > On Tue, Mar 17, 2026 at 08:26:53AM +0100, Wolfram Sang wrote:

...

> > > Thanks for tackling this issue! I agree it should be fixed, just
> > > wondered about one thing:
> > >
> > > > While flags are often modified while under the "fwnode_link_lock",
> > > > this is not universally true.
> > >
> > > Is it a possibility to use the lock in all code paths instead?
> > > Because...
> > >
> > > >     struct list_head consumers;
> > > > -   u8 flags;
> > > > +   unsigned long flags;
> > >
> > > ... this change costs some memory on every system. Maybe it can be
> > > avoided?
> >
> > How much memory does it cost? On most 64-bit architectures is +4 bytes,
> > rarely +0 bytes, on m68k it might be +2bytes. On 32-bit it most likely
> > +0 bytes. I expect that 64-bit machines will cope with this bump.
> 
> On all architectures with natural alignment of pointers and longs,
> it won't cost a thing: struct list_head contains pointers, so the
> struct must be padded to a multiple of 4 or 8 bytes anyway.
> On m68k[*],  it will cost 2 bytes, as the existing padding is just a
> single byte.
> 
> [*] Iff m68k ever switches to 32-bit alignment, there won't be an
>     additional cost due to the change of flags here, but of course
>     there would be a cost all over the place.

Thanks!

Yes, the worst case is 64-bit architecture with 4-byte alignment. This
will cost +4 bytes.

But I think we are really wasting time on this part of the discussion
(and any similar) as long as nobody targets struct device or any other
BIG FAT data type, that will bring much more benefit than saving 4 bytes
in some struct fwnode_handle.

-- 
With Best Regards,
Andy Shevchenko