All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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: 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.