From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
Shengjiu Wang <shengjiu.wang@nxp.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>, Takashi Iwai <tiwai@suse.com>
Subject: Re: [PATCH 01/38] ASoC: ak5558: drop of_match_ptr from of_device_id table
Date: Mon, 23 Nov 2020 15:42:25 +0200 [thread overview]
Message-ID: <20201123134225.GF4077@smile.fi.intel.com> (raw)
In-Reply-To: <20201123124129.GA170000@kozik-lap>
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:
> > On Mon, Nov 23, 2020 at 12:48:32PM +0200, Andy Shevchenko wrote:
> > > On Sun, Nov 22, 2020 at 11:59:20AM +0100, Krzysztof Kozlowski wrote:
> > > > On Fri, Nov 20, 2020 at 08:04:29PM +0000, Mark Brown wrote:
> >
> > > > > Surely if that's the desired outcome the fix is to change the definition
> > > > > of of_match_ptr() such that it leaves the reference with CONFIG_ACPI,
> > > > > perhaps hidden behind a config option for PRP0001? That seems better
> > > > > than going through the entire tree like this.
> >
> > > > That could be indeed an easier way to achieve this.
> >
> > > ...easier and wrong in my opinion. Not all drivers need that.
> > > What the point to touch it in the driver which is OF-only?
> > > (For IP which will quite unlikely to be present in ACPI world)
> > > Or if the device will get the correct ACPI ID?
> >
> > 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.
I'm on the same page here.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2020-11-23 13:42 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-20 16:16 [PATCH 01/38] ASoC: ak5558: drop of_match_ptr from of_device_id table Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 02/38] ASoC: gtm601: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 03/38] ASoC: inno_rk3036: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 04/38] ASoC: rk3328: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 05/38] ASoC: tas571x: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 06/38] ASoC: kirkwood: armada-370-db: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 07/38] ASoC: meson: t9015: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 08/38] ASoC: qcom: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 09/38] ASoC: samsung: smdk_wm8994: " Krzysztof Kozlowski
2020-11-20 16:43 ` Sylwester Nawrocki
2020-11-20 16:16 ` [PATCH 10/38] ASoC: rockchip: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 11/38] ASoC: ti: davinci: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 12/38] ASoC: uniphier: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 13/38] ASoC: ak4118: skip of_device_id table when !CONFIG_OF Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 14/38] ASoC: alc5623: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 15/38] ASoC: alc5632: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 16/38] ASoC: da7218: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 17/38] ASoC: da7219: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 18/38] ASoC: da9055: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 19/38] ASoC: es8316: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 20/38] ASoC: max98090: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 21/38] ASoC: max98095: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 22/38] ASoC: max98371: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 23/38] ASoC: max9867: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 24/38] ASoC: max98925: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 25/38] ASoC: max98926: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 26/38] ASoC: pcm1789: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 27/38] ASoC: pcm179x: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 28/38] ASoC: rt5660: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 29/38] ASoC: tas2562: " Krzysztof Kozlowski
2020-11-20 16:21 ` Dan Murphy
2020-11-20 16:36 ` Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 30/38] ASoC: tlv320: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 31/38] ASoC: ts3a227e: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 32/38] ASoC: es7134: mark OF related data as maybe unused Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 33/38] ASoC: es7241: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 34/38] ASoC: samsung: i2s: " Krzysztof Kozlowski
2020-11-20 16:41 ` Sylwester Nawrocki
2020-11-20 16:16 ` [PATCH 35/38] ASoC: max98371: drop driver pm=NULL assignment Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 36/38] ASoC: max98925: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 37/38] ASoC: max98926: " Krzysztof Kozlowski
2020-11-20 16:16 ` [PATCH 38/38] ASoC: samsung: smdk_wm8994: remove redundant of_match_ptr() Krzysztof Kozlowski
2020-11-20 16:47 ` Sylwester Nawrocki
2020-11-20 16:56 ` [PATCH 01/38] ASoC: ak5558: drop of_match_ptr from of_device_id table Mark Brown
2020-11-20 19:42 ` Krzysztof Kozlowski
2020-11-20 20:04 ` Mark Brown
2020-11-22 10:59 ` Krzysztof Kozlowski
2020-11-23 10:48 ` Andy Shevchenko
2020-11-23 12:37 ` Mark Brown
2020-11-23 12:41 ` Krzysztof Kozlowski
2020-11-23 13:42 ` Andy Shevchenko [this message]
2020-11-23 13:45 ` Andy Shevchenko
2020-11-23 13:50 ` Mark Brown
2020-11-23 14:58 ` Krzysztof Kozlowski
2020-11-23 16:43 ` Mark Brown
2020-11-23 16:45 ` Krzysztof Kozlowski
2020-11-23 13:41 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201123134225.GF4077@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=krzk@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=shengjiu.wang@nxp.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).