Received-SPF: pass (google.com: domain of linux-kernel+bounces-130674-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542
Precedence: bulk
MIME-Version: 1.0
Message-Id: <e5ebcbac-f445-4a48-a40f-7aa606c7d460@app.fastmail.com>
In-Reply-To: <Zg3GdUtBUKzB6NNZ@surfacebook.localdomain>
References: <20240403080702.3509288-1-arnd@kernel.org>
 <20240403080702.3509288-32-arnd@kernel.org>
 <b4418ac1-10ba-4932-be6e-93282707024f@sirena.org.uk>
 <5f3qvhasho4mfnf6f7i6djak3ankje375mt4fzvv3gqrlj242o@zdk2ajvha6hx>
 <Zg3GdUtBUKzB6NNZ@surfacebook.localdomain>
Date: Thu, 04 Apr 2024 00:19:41 +0200
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Andy Shevchenko" <andy.shevchenko@gmail.com>,
 =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>
Cc: "Mark Brown" <broonie@kernel.org>, "Arnd Bergmann" <arnd@kernel.org>,
 linux-kernel@vger.kernel.org,
 "Neil Armstrong" <neil.armstrong@linaro.org>,
 "Kevin Hilman" <khilman@baylibre.com>,
 =?UTF-8?Q?Heiko_St=C3=BCbner?= <heiko@sntech.de>,
 "Andi Shyti" <andi.shyti@kernel.org>,
 "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
 "Jerome Brunet" <jbrunet@baylibre.com>,
 "Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
 "Alim Akhtar" <alim.akhtar@samsung.com>,
 "Li Zetao" <lizetao1@huawei.com>,
 "Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
 "Rob Herring" <robh@kernel.org>,
 "Yang Yingliang" <yangyingliang@huawei.com>,
 "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
 "Luis de Arquer" <luis.dearquer@inertim.com>,
 "Tudor Ambarus" <tudor.ambarus@linaro.org>,
 "Sam Protsenko" <semen.protsenko@linaro.org>,
 "Peter Griffin" <peter.griffin@linaro.org>,
 "Jaewon Kim" <jaewon02.kim@samsung.com>, linux-spi@vger.kernel.org,
 linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org,
 linux-rockchip@lists.infradead.org, linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH 31/34] spi: remove incorrect of_match_ptr annotations
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 3, 2024, at 23:13, Andy Shevchenko wrote:
> Wed, Apr 03, 2024 at 11:05:51PM +0200, Uwe Kleine-K=C3=B6nig 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:
>> >=20
>> > > These appear to all be copied from the same original driver, so f=
ix 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 configurati=
ons that
>> > > have CONFIG_OF enabled.
>> >=20
>> > Why are we not fixing of_match_ptr() here, or at least adding the i=
fdefs
>> > in case someone does end up wanting to run without OF?
>>=20
>> Fixing of_match_ptr =3D
>>=20
>> 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_dat=
a(const struct device *dev)
>>  	return NULL;
>>  }
>> =20
>> -#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 */
>> =20
>> ?
>>=20
>> 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