Re: [PATCH v4 1/2] iio: imu: inv_icm42600: add WoM support

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

On Fri, Jun 13, 2025 at 05:41:47PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 13, 2025 at 01:43:58PM +0000, Jean-Baptiste Maneyrol wrote:
> > >From: Andy Shevchenko <andriy.shevchenko@intel.com>
> > >Sent: Friday, June 13, 2025 14:54
> > >On Fri, Jun 13, 2025 at 03:53:36PM +0300, Andy Shevchenko wrote:
> > >> On Fri, Jun 13, 2025 at 12:46:46PM +0000, Jean-Baptiste Maneyrol wrote:
> > >> > >From: Andy Shevchenko <andriy.shevchenko@intel.com>
> > >> > >Sent: Friday, June 13, 2025 10:29
> > >> > >On Fri, Jun 13, 2025 at 09:34:26AM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:

...

> > >> > >Overall, looking to this patch again, I think it would be better to prepend it
> > >> > >by replacing *int*_t types by the respective uXX ones. Because in this patch
> > >> > >we add dozens of new ones which increases an unneeded churn in the future.
> > >> > >
> > >> > In my opinion, to respect the rule don't mix *int*_t and uXX types, it is better
> > >> > to keep *int*_t types. If it need to be changed, we can change afterward the
> > >> > whole driver types with a replace tool and send it in a separate patch.
> > >> 
> > >> It will be never ending story, sorry. We need someone to solve this tech debt.
> > >> And since this patch adds more than 3 new users of it, I think it's a candidate
> > >> to embrace the burden.
> > >
> > >For your convenience I can mock-up a change...
> > 
> > It looks like there's something I don't understand in the kernel Documentation about
> > types then.
> > Quoting Documentation/process/coding-style.rst, section 5.d:
> > ---
> > New types which are identical to standard C99 types, in certain exceptional circumstances.
> > 
> > Although it would only take a short amount of time for the eyes and brain to become accustomed
> > to the standard types like uint32_t, some people object to their use anyway.
> > 
> > Therefore, the Linux-specific u8/u16/u32/u64 types and their signed equivalents which are
> > identical to standard types are permitted -- although they are not mandatory in new code
> > of your own.
> > 
> > When editing existing code which already uses one or the other set of types, you should
> > conform to the existing choices in that code.
> > ---
> > 
> > My understanding is that uXX are not mandatory for new code. You can use types like *int*_t.
> > But you need to conform afterward to the existing choice. That's why this driver was
> > done initially with *int*_t types, and that patches are conforming to this choice.
> 
> This part of the documentation has a lot of room for different interpretations.
> One [1] may consider this as uXX superior, another, like you, that it's okay
> to use.  In any case Greg KH prefers uXX over uintXX_t. And he is also in
> the chain of maintainers here. Feel free to amend the Documentation. But
> be sure all stakeholders will see your proposal (like Greg KH and other
> key maintainers).
> 
> > By looking at all Linux drivers, there are plenty of them using *int*_t, even
> > inside iio:
> 
> $ git grep -l 'u\?int[0-9][0-9]\?_t' -- drivers/iio/ | wc -l
> 59
> 
> $ git ls-files drivers/iio*.c | wc -l
> 640
> 
> Less than 10%.
> 
> > Then, why it is mandatory to change this driver to use uXX instead?
> 
> TO be consistent. With the above wording in the documentation I may argue that
> entire subsystem should be consistent and at least in IIO we have tons of patch
> series that are against the whole subsystem to do one style change or another
> (look at the recent memset() vs. {} for initialisation).
> 
> [1] https://lore.kernel.org/all/20250409180953.398686-1-matchstick@neverthere.org/

Oh, this [2] is golden!
YUou may found support for your arguments and for mine in that thread, but the
bottom line is: what do maintainers of IIO prefer? (Taking into account that it
goes via Greg KH)


[2]: https://lore.kernel.org/all/20210423230609.13519-1-alx.manpages@gmail.com/

-- 
With Best Regards,
Andy Shevchenko