[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <be1ea414-b2ad-162d-192a-7b55e40b3754@linux.intel.com>
Date: Wed, 18 Aug 2021 10:53:07 -0500
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Mark Brown <broonie@...nel.org>, alsa-devel@...a-project.org,
"Rafael J . Wysocki" <rafael@...nel.org>, tiwai@...e.de,
linux-kernel@...r.kernel.org, liam.r.girdwood@...ux.intel.com,
vkoul@...nel.org, Geert Uytterhoeven <geert@...ux-m68k.org>,
Jason Gunthorpe <jgg@...dia.com>,
Dan Williams <dan.j.williams@...el.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Christoph Hellwig <hch@....de>
Subject: Re: [RFC PATCH 1/2] driver core: export
driver_deferred_probe_trigger()
>> 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...
Powered by blists - more mailing lists