Opened 6 years ago
Last modified 6 years ago
#14350 new bug
ACPI Embedded Controller driver is not loaded
Reported by: | mmu_man | Owned by: | tqh |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/ACPI | Version: | R1/Development |
Keywords: | acpi, embedded controller | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
The EC driver is part of the ACPI bus_manager module binary, but exports itself as "drivers/power/acpi_embedded_controller/driver_v1", which does not start with "bus_managers/acpi", hence the kernel will never actually see it when walking module lists.
Adding a symlink makes it load but is not really clean.
Changing its name to "bus_managers/acpi/embedded_controller/driver_v1" and alike for the device module seems to make it forgotten, at least it's only loaded after the ACPI enumeration is done, so it never has a chance to see devices it could support.
Change History (5)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
Well I can say that it works with "drivers/misc" in the case of the virtio balloon driver: https://git.haiku-os.org/haiku/commit/src/add-ons/kernel/bus_managers/virtio?id=fe11711026bb1bb38d2de97237d89398184cde34
The problem might reside elsewhere.
comment:3 by , 6 years ago
And looking at the balloon code it seems to me there's an oversight in the device module export, it uses a driver_module_info instead of a device_module_info struct !?
comment:4 by , 6 years ago
Oh, ok, actually the balloon driver is different: it creates a subnode in the device tree, and passes register_node() a different module name which also points to a driver_module_info. While the EC driver calls publish_device() to add a devfs entry, which wants a device_module_info. So I guess both are correct, but somehow the later doesn't work.
comment:5 by , 6 years ago
After testing with virtualbox, it seems it also isn't loaded when acpi is from ~/config/non-packaged/… while it actually is loaded (even though VB doesn't seem to have an EC in its ACPI table but at least the trace shows up) from the system package.
This was the patch I suggested for mmu_man to try which didn't work, because it does not get called with all the ACPI child devices properly (but does get farther than presently):