On Wed, Sep 23, 2026 at 8:50 PM Rafael J. Wysocki (Intel) <[email protected]> wrote: > > 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.
Well, not quite. If a driver with an incorrect bus is passed to driver_attach(), it will iterate over devices on that bus and call __driver_attach() for each of them. If driver_match_device() succeeds then, the device will be passed to driver_probe_device() and it will not be good. So it may be worth checking after all.
