Re: [PATCH v2] driver core/ACPI: Introduce companion_bus_register()

On Thu, Sep 24, 2026 at 8:23 PM Michael Kelley [off-list ref] wrote:

From: Michael Kelley <redacted> Sent: Wednesday, September 23, 2026 10:06 AM

quoted

From: Rafael J. Wysocki <rafael@kernel.org> Sent: Wednesday, September 9, 2026 9:41 AM

quoted

The ACPI bus type does not allow drivers to be registered, so the sysfs
attributes related to drivers created for it and its devices are
useless, and its drivers/ directory is always empty.  All of that is
confusing and wasteful.

To allow skipping the creation of those sysfs attributes, introduce a
"companion" bus type concept and add a special registration function for
registering "companion" bus types, companion_bus_register().

Signed-off-by: Rafael J. Wysocki <redacted>

As a heads up, this patch breaks Linux guests booting on Hyper-V.
Something goes wrong in the VMBus driver getting loaded and
initialized (drivers/hv/vmbus_drv.c). It may be that the VMBus
driver is doing something wrong or making an invalid assumption.
I'll debug the problem today or tomorrow, but any insight you can
offer would be appreciated. I'm working with linux-next20260921.

Here's what I've learned so far:

1) The problem is apparently due to systemd-udevd being unable
to load modules with the VMBus bus driver or any of the
individual drivers for VMBus devices.

2) I'm testing on Ubuntu 20.04 with systemd version 245. The
problem reproduces on a different 20.04 instance. But everything
works correctly on Ubuntu 24.04 with systemd version 255.

3) If the VMBus bus driver and key VMBus device drivers are
compiled as built-in instead of as modules, the Ubuntu 20.04 system
will boot.

4) If I keep your patch, but change companion_bus_register() to
pass "true" as the second argument instead of "false", then the
/sys/bus/acpi/drivers directory is created as before, and everything
works. Also, only adding back the .match function as you suggested
does not make any difference.

5) The VMBus bus is enumerated in the ACPI DSDT. The individual
synthetic devices that are logically on VMBus are not -- they are
"offered" by Hyper-V to the guest at runtime via a custom protocol.
The synthetic devices end up with paths like:

/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/MSFT1000:00/<some GUID>

Which is rather unfortunate.

They should appear under the MSFT1000:00 platform device corresponding
to the ACPI device with the same name.

Anyway, it looks like older systemd may be thinking that they are ACPI
devices and may be looking for drivers in /sys/bus/acpi/drivers/.

To kind of check that this is the case, can you replace "use_drivers"
with "true" in the first check in bus_register_internal() only (with
the $subject patch applied, of course)?  That would leave the
"drivers" directory in place, but it would skip the creation of the
probe files.

My conclusion is that for some reason, the older system-udevd has
a dependency on the /sys/bus/acpi/drivers directory being present.
This isn't a kernel problem per se, but there's an implicit ABI of sorts
that assumes the existence of the "drivers" directory.

To confirm all this more precisely, I'm trying to find a clever way
to get an strace of systemd-udevd when it errors out due to the
missing "drivers" directory, and somehow relate that back to the
git history of systemd-udevd.

Thoughts?

Well, the fact of life is that it can't cope with the changes made by
the $subject patch, but maybe we can get away with a simpler one, so
please check the above.

I'll drop the $subject patch from linux-next at least for now.

BTW, do you know why vmbus_acpi_add() does this:

ACPI_COMPANION_SET(&device->dev, device);

which essentially attempts to make an ACPI device become an ACPI
companion of itself and is useless and broken?

If this is done to work around something, there may be a design issue
in that driver.

Thanks!