From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>,
alsa-devel@alsa-project.org,
"Rafael J . Wysocki" <rafael@kernel.org>,
tiwai@suse.de, linux-kernel@vger.kernel.org,
liam.r.girdwood@linux.intel.com, vkoul@kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Jason Gunthorpe <jgg@nvidia.com>,
Dan Williams <dan.j.williams@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger()
Date: Wed, 18 Aug 2021 10:53:07 -0500 [thread overview]
Message-ID: <be1ea414-b2ad-162d-192a-7b55e40b3754@linux.intel.com> (raw)
In-Reply-To: <YR0nAcC3wJd3b4Vu@kroah.com>
>> a) we have to use request_module()
>
> Wait, why?
>
> module loading is async, use auto-loading when the hardware/device is
> found and reported to userspace. Forcing a module to load by the kernel
> is not always wise as the module is not always present in the filesystem
> at that point in time at boot (think modules on the filesystem, not in
> the initramfs).
>
> Try fixing this issue and maybe it will resolve itself as you should be
> working async.
It's been that way for a very long time (2015?) for HDAudio support, see
sound/pci/hda/hda_bind.c. It's my understanding that it was a conscious
design decision to use vendor-specific modules, if available, and
fallback to generic modules if the first pass failed.
Takashi, you may want to chime in...
next prev parent reply other threads:[~2021-08-18 15:53 UTC|newest]
Thread overview: 17+ 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 ` [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger() Pierre-Louis Bossart
2021-08-18 5:44 ` Greg Kroah-Hartman
2021-08-18 11:57 ` Mark Brown
2021-08-18 13:22 ` Greg Kroah-Hartman
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 15:28 ` Greg Kroah-Hartman
2021-08-18 15:53 ` Pierre-Louis Bossart [this message]
2021-08-18 16:49 ` Greg Kroah-Hartman
2021-08-18 17:52 ` Mark Brown
2021-08-18 18:09 ` Pierre-Louis Bossart
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-18 12:07 ` Mark Brown
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=be1ea414-b2ad-162d-192a-7b55e40b3754@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=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=jgg@nvidia.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--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 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).