On Wed, Sep 23, 2026 at 8:31 PM Rafael J. Wysocki (Intel) <[email protected]> wrote: > > 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.
Which shouldn't matter though because driver_match_device() is only called in 3 places and none of them is reachable for acpi_bus_type after the $subject patch AFAICS. So still no idea what can be going on, sorry.
