On Wed, Sep 23, 2026 at 7:32 PM Rafael J. Wysocki (Intel) <[email protected]> wrote: > > On Wed, Sep 23, 2026 at 7:06 PM Michael Kelley <[email protected]> wrote: > > > > From: Rafael J. Wysocki <[email protected]> Sent: Wednesday, September 9, > > 2026 9:41 AM > > > > > > 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 <[email protected]> > > > > 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). > > This patch doesn't affect anything except for bus registration and > driver addition and lookup for the ACPI bus type. > > > 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. > > No idea what's going on.
Actually, you may try to restore the stub .match() callback for acpi_bus_type because the lack of it causes 1 to be returned by driver_match_device(), so if any driver points to acpi_bus_type as its bus by mistake, the check will now succeed.
