linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>,
	alsa-devel@alsa-project.org, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>,
	Shengjiu Wang <shengjiu.wang@nxp.com>
Subject: Re: [PATCH 01/38] ASoC: ak5558: drop of_match_ptr from of_device_id table
Date: Mon, 23 Nov 2020 13:41:29 +0100	[thread overview]
Message-ID: <20201123124129.GA170000@kozik-lap> (raw)
In-Reply-To: <20201123123731.GA6322@sirena.org.uk>

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.

Best regards,
Krzysztof


  reply	other threads:[~2020-11-23 13:17 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 [this message]
2020-11-23 13:42               ` Andy Shevchenko
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=20201123124129.GA170000@kozik-lap \
    --to=krzk@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --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).