Re: [PATCH] iio:accel:dmard06: Optimize when CONFIG_OF isn't set

[Jonathan Cameron]

On Fri, 26 Aug 2022 19:10:33 +0300
Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:

> On Fri, Aug 26, 2022 at 7:06 PM Jean Delvare <jdelvare@xxxxxxx> wrote:
> > On Fri, 26 Aug 2022 18:18:20 +0300, Andy Shevchenko wrote:  
> > > On Fri, Aug 26, 2022 at 1:46 PM Jean Delvare <jdelvare@xxxxxxx> wrote:  
> > > > therefore of_match_ptr() should be
> > > > removed from the kernel entirely?  
> > >
> > > (...) But for some cases it still
> > > makes sense: platform is known to never be non-OF, component is known
> > > to be used only on such platforms, etc.  
> >
> > Well, I can't see the value of of_match_ptr() in such case either. In
> > fact I've submitted a couple patches to remove such occurrences lately:
> >
> > https://patchwork.kernel.org/project/linux-mediatek/patch/20220730144833.0a0d9825@endymion.delvare/
> > https://patchwork.kernel.org/project/linux-pm/patch/20220804135938.7f69f5d9@endymion.delvare/  
> 
> They are different to what we are discussing here, but yes, in common
> denominator the of_match_ptr() is useless in almost 100% cases.
> 

Agreed. Ever since PRP0001 came in, it's made little to no sense to have
an of_match_ptr() but it's perhaps also not worth the noise of generally
removing 1588 cases of it!

As a side note, of_match_ptr() did make sense, then moving to trickery along the lines
of what was recently done for pm_ptr() to get rid of the need for __maybe_unused
would be good.

#define pm_ptr(_ptr) PTR_IF(IS_ENABLED(CONFIG_PM), (_ptr))

I 'think' the same trick could be used to make the use of the array visible
to the compiler but still allow it to remove the array. Not actually tried
it though...

Jonathan