From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> To: Mark Brown <broonie@kernel.org> Cc: alsa-devel@alsa-project.org, Kai Vehmanen <kai.vehmanen@linux.intel.com>, "Rafael J . Wysocki" <rafael@kernel.org>, tiwai@suse.de, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Takashi Iwai <tiwai@suse.com>, linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>, liam.r.girdwood@linux.intel.com, vkoul@kernel.org, Ranjani Sridharan <ranjani.sridharan@linux.intel.com>, Jason Gunthorpe <jgg@nvidia.com>, Dan Williams <dan.j.williams@intel.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Daniel Baluta <daniel.baluta@nxp.com>, Christoph Hellwig <hch@lst.de>, "moderated list:SOUND - SOUND OPEN FIRMWARE (SOF) DRIVERS" <sound-open-firmware@alsa-project.org> Subject: Re: [RFC PATCH 2/2] ASoC: SOF: trigger re-probing of deferred devices from workqueue Date: Wed, 18 Aug 2021 10:25:19 -0500 [thread overview] Message-ID: <3985f754-a0a2-92f7-1585-3b177c172664@linux.intel.com> (raw) In-Reply-To: <20210818120700.GB4177@sirena.org.uk> On 8/18/21 7:07 AM, Mark Brown wrote: > On Tue, Aug 17, 2021 at 02:00:57PM -0500, Pierre-Louis Bossart wrote: > >> +++ b/sound/soc/sof/core.c >> @@ -251,6 +251,9 @@ static int sof_probe_continue(struct snd_sof_dev *sdev) >> >> sdev->probe_completed = true; >> >> + /* kick-off re-probing of deferred devices */ >> + driver_deferred_probe_trigger(); >> + > > I think we should move this into snd_soc_register_component() - the same > issue could occur with any other component, the only other thing I can > see kicking in here is the machine driver registration but that ought to > kick probe itself anyway. Or is there some other case here? Thanks for the suggestion Mark, it would be more consistent indeed to kick a re-evaluation of the deferred probe list when ASoC components are successfully registered with something like this: diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index c830e96afba2..9d6feea7719c 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2677,7 +2677,14 @@ int snd_soc_register_component(struct device *dev, if (ret < 0) return ret; - return snd_soc_add_component(component, dai_drv, num_dai); + ret = snd_soc_add_component(component, dai_drv, num_dai); + if (ret < 0) + return ret; + + /* kick-off re-probing of deferred devices */ + driver_deferred_probe_trigger(); + + return 0; } EXPORT_SYMBOL_GPL(snd_soc_register_component); In the case of this SOF driver, it'd be completely equivalent to what this patch suggested, the snd_soc_register_component() is what we do last in the workqueue. In the case of 'regular' drivers, the component registration is typically done last as well before the end of the probe. This would result in 2 evaluations (one on successful ASoC component registration and one on successful probe), and maybe on the second evaluation there's nothing to do. I can't think of any negative side-effects.
WARNING: multiple messages have this Message-ID (diff)
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> To: Mark Brown <broonie@kernel.org> Cc: alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>, Kai Vehmanen <kai.vehmanen@linux.intel.com>, "Rafael J . Wysocki" <rafael@kernel.org>, tiwai@suse.de, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Takashi Iwai <tiwai@suse.com>, linux-kernel@vger.kernel.org, liam.r.girdwood@linux.intel.com, vkoul@kernel.org, Ranjani Sridharan <ranjani.sridharan@linux.intel.com>, Jason Gunthorpe <jgg@nvidia.com>, Dan Williams <dan.j.williams@intel.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Daniel Baluta <daniel.baluta@nxp.com>, Christoph Hellwig <hch@lst.de>, "moderated list:SOUND - SOUND OPEN FIRMWARE \(SOF\) DRIVERS" <sound-open-firmware@alsa-project.org> Subject: Re: [RFC PATCH 2/2] ASoC: SOF: trigger re-probing of deferred devices from workqueue Date: Wed, 18 Aug 2021 10:25:19 -0500 [thread overview] Message-ID: <3985f754-a0a2-92f7-1585-3b177c172664@linux.intel.com> (raw) In-Reply-To: <20210818120700.GB4177@sirena.org.uk> On 8/18/21 7:07 AM, Mark Brown wrote: > On Tue, Aug 17, 2021 at 02:00:57PM -0500, Pierre-Louis Bossart wrote: > >> +++ b/sound/soc/sof/core.c >> @@ -251,6 +251,9 @@ static int sof_probe_continue(struct snd_sof_dev *sdev) >> >> sdev->probe_completed = true; >> >> + /* kick-off re-probing of deferred devices */ >> + driver_deferred_probe_trigger(); >> + > > I think we should move this into snd_soc_register_component() - the same > issue could occur with any other component, the only other thing I can > see kicking in here is the machine driver registration but that ought to > kick probe itself anyway. Or is there some other case here? Thanks for the suggestion Mark, it would be more consistent indeed to kick a re-evaluation of the deferred probe list when ASoC components are successfully registered with something like this: diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index c830e96afba2..9d6feea7719c 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2677,7 +2677,14 @@ int snd_soc_register_component(struct device *dev, if (ret < 0) return ret; - return snd_soc_add_component(component, dai_drv, num_dai); + ret = snd_soc_add_component(component, dai_drv, num_dai); + if (ret < 0) + return ret; + + /* kick-off re-probing of deferred devices */ + driver_deferred_probe_trigger(); + + return 0; } EXPORT_SYMBOL_GPL(snd_soc_register_component); In the case of this SOF driver, it'd be completely equivalent to what this patch suggested, the snd_soc_register_component() is what we do last in the workqueue. In the case of 'regular' drivers, the component registration is typically done last as well before the end of the probe. This would result in 2 evaluations (one on successful ASoC component registration and one on successful probe), and maybe on the second evaluation there's nothing to do. I can't think of any negative side-effects.
next prev parent reply other threads:[~2021-08-18 15:28 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-17 19:00 [RFC PATCH 0/2] driver core: kick deferred probe from delayed context Pierre-Louis Bossart 2021-08-17 19:00 ` Pierre-Louis Bossart 2021-08-17 19:00 ` [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger() Pierre-Louis Bossart 2021-08-17 19:00 ` Pierre-Louis Bossart 2021-08-18 5:44 ` Greg Kroah-Hartman 2021-08-18 5:44 ` Greg Kroah-Hartman 2021-08-18 11:57 ` Mark Brown 2021-08-18 11:57 ` Mark Brown 2021-08-18 13:22 ` Greg Kroah-Hartman 2021-08-18 13:22 ` Greg Kroah-Hartman 2021-08-18 13:48 ` Mark Brown 2021-08-18 13:48 ` Mark Brown 2021-08-18 14:51 ` Pierre-Louis Bossart 2021-08-18 14:59 ` Dan Williams 2021-08-18 14:59 ` Dan Williams 2021-08-18 15:28 ` Greg Kroah-Hartman 2021-08-18 15:28 ` Greg Kroah-Hartman 2021-08-18 15:53 ` Pierre-Louis Bossart 2021-08-18 15:53 ` Pierre-Louis Bossart 2021-08-18 16:49 ` Greg Kroah-Hartman 2021-08-18 16:49 ` Greg Kroah-Hartman 2021-08-18 17:52 ` Mark Brown 2021-08-18 17:52 ` Mark Brown 2021-08-18 18:09 ` Pierre-Louis Bossart 2021-08-18 18:28 ` Mark Brown 2021-08-18 18:28 ` Mark Brown 2021-08-17 19:00 ` [RFC PATCH 2/2] ASoC: SOF: trigger re-probing of deferred devices from workqueue Pierre-Louis Bossart 2021-08-17 19:00 ` Pierre-Louis Bossart 2021-08-18 12:07 ` Mark Brown 2021-08-18 12:07 ` Mark Brown 2021-08-18 15:25 ` Pierre-Louis Bossart [this message] 2021-08-18 15:25 ` Pierre-Louis Bossart
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=3985f754-a0a2-92f7-1585-3b177c172664@linux.intel.com \ --to=pierre-louis.bossart@linux.intel.com \ --cc=alsa-devel@alsa-project.org \ --cc=andriy.shevchenko@linux.intel.com \ --cc=broonie@kernel.org \ --cc=dan.j.williams@intel.com \ --cc=daniel.baluta@nxp.com \ --cc=gregkh@linuxfoundation.org \ --cc=hch@lst.de \ --cc=jgg@nvidia.com \ --cc=kai.vehmanen@linux.intel.com \ --cc=lgirdwood@gmail.com \ --cc=liam.r.girdwood@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=rafael@kernel.org \ --cc=ranjani.sridharan@linux.intel.com \ --cc=sound-open-firmware@alsa-project.org \ --cc=tiwai@suse.com \ --cc=tiwai@suse.de \ --cc=vkoul@kernel.org \ /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: linkBe 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.