LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Pierre-Louis Bossart <firstname.lastname@example.org>
To: Greg Kroah-Hartman <email@example.com>
"Rafael J . Wysocki" <firstname.lastname@example.org>,
Mark Brown <email@example.com>,
Geert Uytterhoeven <firstname.lastname@example.org>,
Jason Gunthorpe <email@example.com>,
Dan Williams <firstname.lastname@example.org>,
Andy Shevchenko <email@example.com>,
Christoph Hellwig <firstname.lastname@example.org>
Subject: Re: [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger()
Date: Wed, 18 Aug 2021 13:09:44 -0500 [thread overview]
Message-ID: <email@example.com> (raw)
>>>> 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.
> If it has been this way for so long, what has caused the sudden change
> to need to export this and call this function?
Fair question, I did not provide all the context with a cover letter
that was already quite long. Here are more details:
In the existing Intel audio drivers, we have a PCI device that first get
probed. The PCI driver initializes the DSP and exposes what the audio
DSP can do, but the platform-specific configuration for a given board is
handled by a child device . We have all kinds of hard-coded lookup
tables to figure out what the board is and what machine driver should be
used based on the presence of other ACPI devices and/or DMI quirks
. We must have used this solution since 2010, mainly because 'the
other OS' does not rely on platform firmware for a description of the
In the 'soon' future, that machine driver will probed with its own ACPI
ID and become generic, with all the information related to the board
described in platform firmware and parsed by the driver. This is how the
'simple card' works today in Device Tree environments, platform firmware
describes how host-provided components are connected to 3rd-party
components. I cannot provide more details at this time since this is a
not yet a publicly-available specification (this specification work does
take place in a standardization body).
That change in how the machine driver gets probed creates a new problem
we didn't have before: this generic machine driver will probe in the
early stages of the boot, long before the DSP and audio codecs are
I initially looked at the component framework to try to express
dependencies. It's really not clear to me if this is the 'right'
direction, for ASoC-based solutions we already have components that
register with a core.
I also started looking at other proposals that were made over the years,
this problem of expressing dependencies is not new. No real luck.
In the end, since the DeviceTree-based solutions based on deferred
probes work fine for the same type of usages, I tried to reuse the same
deferred probe mechanism. The only reason why I needed to export this
function is to work-around the request_module() use.
I am not claiming any award for architecture, this is clearly a
domain-specific corner case. I did try the async probe, I consulted with
Marc Brown, had an internal review with Dan Williams and Andy
Shevchenko. While nobody cheered, it seemed like this export was
'reasonable' compared to a re-architecture of the HDaudio/HDMI support -
which is a really scary proposition.
There is no immediate rush to make this change in this kernel cycle or
the next, I am open to alternatives, but I wanted to make sure we don't
have any Linux plumbing issues by the time the specification becomes
public and is used by 'the other OS'.
Does this help get more context?
next prev parent reply other threads:[~2021-08-18 18:09 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
2021-08-18 16:49 ` Greg Kroah-Hartman
2021-08-18 17:52 ` Mark Brown
2021-08-18 18:09 ` Pierre-Louis Bossart [this message]
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger()' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).