All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Daniel Baluta <daniel.baluta@nxp.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Fabio Estevam <festevam@gmail.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	YueHaibing <yuehaibing@huawei.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Takashi Iwai <tiwai@suse.com>, Mark Brown <broonie@kernel.org>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	sound-open-firmware@alsa-project.org,
	Shawn Guo <shawnguo@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	NXP Linux Team <linux-imx@nxp.com>
Subject: Re: [PATCH] ASoC: SOF: sort out Kconfig, again
Date: Wed, 29 Apr 2020 10:24:45 +0200	[thread overview]
Message-ID: <CAK8P3a3vri_-tdEy3x6tRGUjb_k-+Mc+Jt9bQpgFvqm2RN+cJA@mail.gmail.com> (raw)
In-Reply-To: <b784c008-7094-05cb-6200-6b246ff39bb8@linux.intel.com>

On Wed, Apr 29, 2020 at 1:00 AM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
> >>> Thanks Arnd, do you mind sharing your config?
> >>
> >> https://pastebin.com/HRX5xi3R
> >
> > will give it a try, thanks!
> >
> >>> We noticed last week that
> >>> there's a depend/select confusion might be simpler to fix, see
> >>> https://github.com/thesofproject/linux/pull/2047/commits
> >>>
> >>> If I look at the first line I see a IMX_DSP=n which looks exactly like
> >>> what we wanted to fix.
> >>
> >> Yes, I think that fix addresses the build warning as well, but looking
> >> more closely I don't think it's what you want: If you do this on
> >> a config that has the IMX_DSP disabled, it would appear to the
> >> user that you have enabled the drivers, but the actual code is still
> >> disabled.
> >
> > Are you sure? we added a select IMX_DSP, so not sure how it can be
> > disabled?
>
> I just tested Arnd's config with the patch we came up with for SOF
> (attached) and it makes the unmet dependency go away and builds fine.
> the problem is really using select IMX_DSP if it can be disabled by
> something else. My proposal looks simpler but I will agree it's not
> necessarily super elegant to move the dependency on IMX_BOX into SOF, so
> no sustained objection from me on Arnd's proposal.

Ok, thanks for testing!

I looked at the bigger picture again and found that the more fundamental
problem is the dependency reversal in sound/soc/sof/sof-of-dev.c, where
you have common code that knows about and links against a hardware
specific driver. This is something we try hard do avoid in general in the
kernel, as it causes all kinds of problems:

- Expressing the Kconfig dependencies is rather unnatural and error-prone,
  as you found

- Adding multiple new drivers at the same time leads to merge conflicts

- A kernel that supports multiple SoC families, like all general-purpose
  distros do, and Android is going to do in the future means that you have
  to load every hardware specific module in order to just use one of them.

- In Android's case, it also breaks the model of having one vendor provide
  support for a new SoC by enabling additional modules they ship in
  their vendor specific partition

I think this is all solved by moving the "module_platform_driver()"
and of_device_id array for each driver into the module that defines
the corresponding sof_dev_desc structure, and have those drivers
call the exported sof_of_probe() and sof_of_remove() functions.

      Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Takashi Iwai <tiwai@suse.com>, YueHaibing <yuehaibing@huawei.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	NXP Linux Team <linux-imx@nxp.com>,
	Mark Brown <broonie@kernel.org>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>,
	Fabio Estevam <festevam@gmail.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	sound-open-firmware@alsa-project.org
Subject: Re: [PATCH] ASoC: SOF: sort out Kconfig, again
Date: Wed, 29 Apr 2020 10:24:45 +0200	[thread overview]
Message-ID: <CAK8P3a3vri_-tdEy3x6tRGUjb_k-+Mc+Jt9bQpgFvqm2RN+cJA@mail.gmail.com> (raw)
In-Reply-To: <b784c008-7094-05cb-6200-6b246ff39bb8@linux.intel.com>

On Wed, Apr 29, 2020 at 1:00 AM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
> >>> Thanks Arnd, do you mind sharing your config?
> >>
> >> https://pastebin.com/HRX5xi3R
> >
> > will give it a try, thanks!
> >
> >>> We noticed last week that
> >>> there's a depend/select confusion might be simpler to fix, see
> >>> https://github.com/thesofproject/linux/pull/2047/commits
> >>>
> >>> If I look at the first line I see a IMX_DSP=n which looks exactly like
> >>> what we wanted to fix.
> >>
> >> Yes, I think that fix addresses the build warning as well, but looking
> >> more closely I don't think it's what you want: If you do this on
> >> a config that has the IMX_DSP disabled, it would appear to the
> >> user that you have enabled the drivers, but the actual code is still
> >> disabled.
> >
> > Are you sure? we added a select IMX_DSP, so not sure how it can be
> > disabled?
>
> I just tested Arnd's config with the patch we came up with for SOF
> (attached) and it makes the unmet dependency go away and builds fine.
> the problem is really using select IMX_DSP if it can be disabled by
> something else. My proposal looks simpler but I will agree it's not
> necessarily super elegant to move the dependency on IMX_BOX into SOF, so
> no sustained objection from me on Arnd's proposal.

Ok, thanks for testing!

I looked at the bigger picture again and found that the more fundamental
problem is the dependency reversal in sound/soc/sof/sof-of-dev.c, where
you have common code that knows about and links against a hardware
specific driver. This is something we try hard do avoid in general in the
kernel, as it causes all kinds of problems:

- Expressing the Kconfig dependencies is rather unnatural and error-prone,
  as you found

- Adding multiple new drivers at the same time leads to merge conflicts

- A kernel that supports multiple SoC families, like all general-purpose
  distros do, and Android is going to do in the future means that you have
  to load every hardware specific module in order to just use one of them.

- In Android's case, it also breaks the model of having one vendor provide
  support for a new SoC by enabling additional modules they ship in
  their vendor specific partition

I think this is all solved by moving the "module_platform_driver()"
and of_device_id array for each driver into the module that defines
the corresponding sof_dev_desc structure, and have those drivers
call the exported sof_of_probe() and sof_of_remove() functions.

      Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Takashi Iwai <tiwai@suse.com>, YueHaibing <yuehaibing@huawei.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	NXP Linux Team <linux-imx@nxp.com>,
	Mark Brown <broonie@kernel.org>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>,
	Fabio Estevam <festevam@gmail.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	sound-open-firmware@alsa-project.org
Subject: Re: [PATCH] ASoC: SOF: sort out Kconfig, again
Date: Wed, 29 Apr 2020 10:24:45 +0200	[thread overview]
Message-ID: <CAK8P3a3vri_-tdEy3x6tRGUjb_k-+Mc+Jt9bQpgFvqm2RN+cJA@mail.gmail.com> (raw)
In-Reply-To: <b784c008-7094-05cb-6200-6b246ff39bb8@linux.intel.com>

On Wed, Apr 29, 2020 at 1:00 AM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
> >>> Thanks Arnd, do you mind sharing your config?
> >>
> >> https://pastebin.com/HRX5xi3R
> >
> > will give it a try, thanks!
> >
> >>> We noticed last week that
> >>> there's a depend/select confusion might be simpler to fix, see
> >>> https://github.com/thesofproject/linux/pull/2047/commits
> >>>
> >>> If I look at the first line I see a IMX_DSP=n which looks exactly like
> >>> what we wanted to fix.
> >>
> >> Yes, I think that fix addresses the build warning as well, but looking
> >> more closely I don't think it's what you want: If you do this on
> >> a config that has the IMX_DSP disabled, it would appear to the
> >> user that you have enabled the drivers, but the actual code is still
> >> disabled.
> >
> > Are you sure? we added a select IMX_DSP, so not sure how it can be
> > disabled?
>
> I just tested Arnd's config with the patch we came up with for SOF
> (attached) and it makes the unmet dependency go away and builds fine.
> the problem is really using select IMX_DSP if it can be disabled by
> something else. My proposal looks simpler but I will agree it's not
> necessarily super elegant to move the dependency on IMX_BOX into SOF, so
> no sustained objection from me on Arnd's proposal.

Ok, thanks for testing!

I looked at the bigger picture again and found that the more fundamental
problem is the dependency reversal in sound/soc/sof/sof-of-dev.c, where
you have common code that knows about and links against a hardware
specific driver. This is something we try hard do avoid in general in the
kernel, as it causes all kinds of problems:

- Expressing the Kconfig dependencies is rather unnatural and error-prone,
  as you found

- Adding multiple new drivers at the same time leads to merge conflicts

- A kernel that supports multiple SoC families, like all general-purpose
  distros do, and Android is going to do in the future means that you have
  to load every hardware specific module in order to just use one of them.

- In Android's case, it also breaks the model of having one vendor provide
  support for a new SoC by enabling additional modules they ship in
  their vendor specific partition

I think this is all solved by moving the "module_platform_driver()"
and of_device_id array for each driver into the module that defines
the corresponding sof_dev_desc structure, and have those drivers
call the exported sof_of_probe() and sof_of_remove() functions.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-04-29  8:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 21:27 [PATCH] ASoC: SOF: sort out Kconfig, again Arnd Bergmann
2020-04-28 21:27 ` Arnd Bergmann
2020-04-28 21:27 ` Arnd Bergmann
2020-04-28 21:43 ` Pierre-Louis Bossart
2020-04-28 21:43   ` Pierre-Louis Bossart
2020-04-28 21:43   ` Pierre-Louis Bossart
2020-04-28 22:01   ` Arnd Bergmann
2020-04-28 22:01     ` Arnd Bergmann
2020-04-28 22:01     ` Arnd Bergmann
2020-04-28 22:15     ` Pierre-Louis Bossart
2020-04-28 22:15       ` Pierre-Louis Bossart
2020-04-28 22:15       ` Pierre-Louis Bossart
2020-04-28 23:00       ` Pierre-Louis Bossart
2020-04-28 23:00         ` Pierre-Louis Bossart
2020-04-28 23:00         ` Pierre-Louis Bossart
2020-04-29  8:21         ` Daniel Baluta
2020-04-29  8:21           ` Daniel Baluta
2020-04-29  8:21           ` Daniel Baluta
2020-04-29  8:24         ` Arnd Bergmann [this message]
2020-04-29  8:24           ` Arnd Bergmann
2020-04-29  8:24           ` Arnd Bergmann
2020-04-29 12:58           ` Mark Brown
2020-04-29 12:58             ` Mark Brown
2020-04-29 12:58             ` Mark Brown
2020-04-30 13:40 ` Mark Brown
2020-04-30 13:40   ` Mark Brown
2020-04-30 13:40   ` Mark Brown

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=CAK8P3a3vri_-tdEy3x6tRGUjb_k-+Mc+Jt9bQpgFvqm2RN+cJA@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=daniel.baluta@nxp.com \
    --cc=festevam@gmail.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=kernel@pengutronix.de \
    --cc=krzk@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sfr@canb.auug.org.au \
    --cc=shawnguo@kernel.org \
    --cc=sound-open-firmware@alsa-project.org \
    --cc=tiwai@suse.com \
    --cc=yuehaibing@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.