[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210818175248.GH4177@sirena.org.uk>
Date: Wed, 18 Aug 2021 18:52:48 +0100
From: Mark Brown <broonie@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
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()
On Wed, Aug 18, 2021 at 06:49:51PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 18, 2021 at 10:53:07AM -0500, Pierre-Louis Bossart wrote:
> > 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.
> If it has been this way for so long, what has caused the sudden change
> to need to export this and call this function?
The usage predates the hardware that requires firmware downloads -
that's very new.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists