On Thu, Oct 21, 2021 at 11:46:56PM PDT, Greg Kroah-Hartman wrote:
On Thu, Oct 21, 2021 at 07:00:31PM -0700, Zev Weiss wrote:
Devices whose fwnodes are marked as reserved are instantiated, but
will not have a driver bound to them unless userspace explicitly
requests it by writing to a 'bind' sysfs file. This is to enable
devices that may require special (userspace-mediated) preparation
before a driver can safely probe them.
Signed-off-by: Zev Weiss <zev@xxxxxxxxxxxxxxxxx>
---
drivers/base/bus.c | 2 +-
drivers/base/dd.c | 13 ++++++++-----
drivers/dma/idxd/compat.c | 3 +--
drivers/vfio/mdev/mdev_core.c | 2 +-
include/linux/device.h | 14 +++++++++++++-
5 files changed, 24 insertions(+), 10 deletions(-)
Ugh, no, I don't really want to add yet-another-state to the driver core
like this. Why are these devices even in the kernel with a driver that
wants to bind to them registered if the driver somehow should NOT be
bound to it? Shouldn't all of that logic be in the crazy driver itself
as that is a very rare and odd thing to do that the driver core should
not care about at all.
And why does a device need userspace interaction at all? Again, why
would the driver not know about this and handle it all directly?
Let me expand a bit more on the details of the specific situation I'm
dealing with...
On a server motherboard we've got a host CPU (Xeon, Epyc, POWER, etc.)
and a baseboard management controller, or BMC (typically an ARM SoC, an
ASPEED AST2500 in my case). The host CPU's firmware (BIOS/UEFI, ME
firmware, etc.) lives in a SPI flash chip. Because it's the host's
firmware, that flash chip is connected to and generally (by default)
under the control of the host CPU.
But we also want the BMC to be able to perform out-of-band updates to
the host's firmware, so the flash is *also* connected to the BMC.
There's an external mux (controlled by a GPIO output driven by the BMC)
that switches which processor (host or BMC) is actually driving the SPI
signals to the flash chip, but there's a bunch of other stuff that's
also required before the BMC can flip that switch and take control of
the SPI interface:
- the BMC needs to track (and potentially alter) the host's power state
to ensure it's not running (in OpenBMC the existing logic for this is
an entire non-trivial userspace daemon unto itself)
- it needs to twiddle some other GPIOs to put the ME into recovery mode
- it needs to exchange some IPMI messages with the ME to confirm it got
into recovery mode
(Some of the details here are specific to the particular motherboard I'm
working with, but I'd guess other systems probably have broadly similar
requirements.)
The firmware flash (or at least the BMC's side of the mux in front of
it) is attached to a spi-nor controller that's well supported by an
existing MTD driver (aspeed-smc), but that driver can't safely probe the
chip until all the stuff described above has been done. In particular,
this means we can't reasonably bind the driver to that device during the
normal device-discovery/driver-binding done in the BMC's boot process
(nor do we want to, as that would pull the rug out from under the
running host). We basically only ever want to touch that SPI interface
when a user (sysadmin using the BMC, let's say) has explicitly initiated
an out-of-band firmware update.
So we want the kernel to be aware of the device's existence (so that we
*can* bind a driver to it when needed), but we don't want it touching
the device unless we really ask for it.
Does that help clarify the motivation for wanting this functionality?
Thanks,
Zev
