[PATCH 31/34] spi: remove incorrect of_match_ptr annotations

Arnd Bergmann arnd at arndb.de
Wed Apr 3 15:19:41 PDT 2024


On Wed, Apr 3, 2024, at 23:13, Andy Shevchenko wrote:
> Wed, Apr 03, 2024 at 11:05:51PM +0200, Uwe Kleine-König kirjoitti:
>> On Wed, Apr 03, 2024 at 10:56:58AM +0100, Mark Brown wrote:
>> > On Wed, Apr 03, 2024 at 10:06:49AM +0200, Arnd Bergmann wrote:
>> > 
>> > > These appear to all be copied from the same original driver, so fix them at the
>> > > same time by removing the unnecessary of_match_ptr() annotation. As far as I
>> > > can tell, all these drivers are only actually used on configurations that
>> > > have CONFIG_OF enabled.
>> > 
>> > Why are we not fixing of_match_ptr() here, or at least adding the ifdefs
>> > in case someone does end up wanting to run without OF?
>> 
>> Fixing of_match_ptr =
>> 
>> diff --git a/include/linux/of.h b/include/linux/of.h
>> index a0bedd038a05..d980bccffda0 100644
>> --- a/include/linux/of.h
>> +++ b/include/linux/of.h
>> @@ -890,7 +890,7 @@ static inline const void *of_device_get_match_data(const struct device *dev)
>>  	return NULL;
>>  }
>>  
>> -#define of_match_ptr(_ptr)	NULL
>> +#define of_match_ptr(_ptr)	(0 ? (_ptr) : NULL)

This would require removing several hundred "#ifdef CONFIG_OF"
checks around the of_device_id tables at the same time
unfortunately. Most of those are completely unnecessary, so
if we wanted to remove those, we should remove the of_match_ptr()
instances at the same time.

>>  #define of_match_node(_matches, _node)	NULL
>>  #endif /* CONFIG_OF */
>>  
>> ?
>> 
>> Assuming this helps, I agree this would be the better fix.
>
> Why? I mean why do we need to even have this API? It's always
> good to know which devices are supported by the module even
> if you have no need in such support or it's not compiled in.
> One of the reasons why is to be able to google for compatible hardware,
> for example.

As far as I can tell, the of_match_ptr() helper was a historic
mistake, it makes pretty much no sense in its current form.

The version that Uwe proposes would have made sense but we
can't change it now.

      Arnd



More information about the linux-arm-kernel mailing list