[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201123135006.GE6322@sirena.org.uk>
Date: Mon, 23 Nov 2020 13:50:06 +0000
From: Mark Brown <broonie@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
linux-kernel@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
alsa-devel@...a-project.org, Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Shengjiu Wang <shengjiu.wang@....com>
Subject: Re: [PATCH 01/38] ASoC: ak5558: drop of_match_ptr from of_device_id
table
On Mon, Nov 23, 2020 at 01:41:29PM +0100, Krzysztof Kozlowski wrote:
> On Mon, Nov 23, 2020 at 12:37:31PM +0000, Mark Brown wrote:
> > That feels like something that should be done with Kconfig dependencies
> > like a direct OF dependency (possibly a !PRP0001 dependency?) for the
> > driver or possibly with having a variant of_match_ptr() for things that
> > really don't want to support PRP0001. Just removing all the use of
> > of_match_ptr() is both noisy and confusing in that it looks like it's
> > creating issues to fix, it makes it hard to understand when and why one
> > should use the macro.
> For the OF-only drivers (without other ID table), there is no point to
> use the macro. Driver can bind only with DT, so what is the point of
> of_match_ptr? To skip the OF table when building without OF? Driver
> won't be usable at all in such case. So maybe for compile testing?
> There is no need to remove OF table for simple build tests.
If nothing else it means you don't have to check if the driver is OF
only or not. I can see not bothering to add it but actively going round
removing some instances of it doesn't seem great, and it seems like
people will constantly be adding new uses on the basis that it's just
such an obviously correct thing to do.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists