Autoload acpi modules via uevent and pnpacpi
Hi, I tried out the patch Bjorn sent some days ago to autoload ACPI modules via udev. The attached patch is based on latest test tree and includes Bjorn's code. This works, but is not nice. I had to tweak pnp to: - also register ACPI devices which have no _CRS func - allow (one byte longer) ACPI _HIDs to be used as PNP ids. Now I got the following modules autoloaded (without the need of any userspace adjustments): battery, asus_acpi, button, ac (tested) fan, ibm_acpi, acpi_memhotplug, container, sbs,.. (should also work, but untested) I also wanted to use the suspend/resume stuff from there to point to the acpi_driver-suspend/resume funcs, but this does not work as pnp_driver-suspend/resume is used there, no idea whether this could be mapped somehow, I didn't see an easy way. Another problem is that e.g. thermal_zones do not have a PNP id. We could add a dummy _HID like ACPI for that one? Is it intended to pass all ACPI devices to pnpacpi in future? Not sure whether this is such a good idea. IMO it's better to let the stuff stay or be added to drivers/acpi. There already is suspend/resume for acpi devices there now, the uevent stuff should also go there? Comments? Thomas drivers/acpi/ac.c |2 + drivers/acpi/acpi_memhotplug.c |2 + drivers/acpi/asus_acpi.c|2 + drivers/acpi/battery.c |2 + drivers/acpi/button.c |4 ++ drivers/acpi/fan.c |2 + drivers/acpi/ibm_acpi.c |3 ++ drivers/acpi/sbs.c |2 + drivers/acpi/scan.c | 15 ++ drivers/pnp/driver.c| 56 drivers/pnp/pnpacpi/core.c | 48 ++ include/acpi/acpi_bus.h | 30 +++-- include/linux/mod_devicetable.h |4 +- 13 files changed, 140 insertions(+), 32 deletions(-) Index: linux-acpi-2.6.git_i386/drivers/acpi/ac.c === --- linux-acpi-2.6.git_i386.orig/drivers/acpi/ac.c +++ linux-acpi-2.6.git_i386/drivers/acpi/ac.c @@ -50,6 +50,8 @@ ACPI_MODULE_NAME(acpi_ac) MODULE_DESCRIPTION(ACPI_AC_DRIVER_NAME); MODULE_LICENSE(GPL); +MODULE_ALIAS(pnp:dACPI0003); + extern struct proc_dir_entry *acpi_lock_ac_dir(void); extern void *acpi_unlock_ac_dir(struct proc_dir_entry *acpi_ac_dir); Index: linux-acpi-2.6.git_i386/drivers/acpi/acpi_memhotplug.c === --- linux-acpi-2.6.git_i386.orig/drivers/acpi/acpi_memhotplug.c +++ linux-acpi-2.6.git_i386/drivers/acpi/acpi_memhotplug.c @@ -45,6 +45,8 @@ ACPI_MODULE_NAME(acpi_memory) MODULE_DESCRIPTION(ACPI_MEMORY_DEVICE_DRIVER_NAME); MODULE_LICENSE(GPL); +MODULE_ALIAS(pnp:dPNP0c80); + /* ACPI _STA method values */ #define ACPI_MEMORY_STA_PRESENT(0x0001UL) #define ACPI_MEMORY_STA_ENABLED(0x0002UL) Index: linux-acpi-2.6.git_i386/drivers/acpi/asus_acpi.c === --- linux-acpi-2.6.git_i386.orig/drivers/acpi/asus_acpi.c +++ linux-acpi-2.6.git_i386/drivers/acpi/asus_acpi.c @@ -75,6 +75,8 @@ MODULE_AUTHOR(Julien Lerouge, Karol Koz MODULE_DESCRIPTION(ACPI_HOTK_NAME); MODULE_LICENSE(GPL); +MODULE_ALIAS(pnp:dATK0100); + static uid_t asus_uid; static gid_t asus_gid; module_param(asus_uid, uint, 0); Index: linux-acpi-2.6.git_i386/drivers/acpi/battery.c === --- linux-acpi-2.6.git_i386.orig/drivers/acpi/battery.c +++ linux-acpi-2.6.git_i386/drivers/acpi/battery.c @@ -59,6 +59,8 @@ ACPI_MODULE_NAME(acpi_battery) MODULE_DESCRIPTION(ACPI_BATTERY_DRIVER_NAME); MODULE_LICENSE(GPL); +MODULE_ALIAS(pnp:dPNP0c0a); + extern struct proc_dir_entry *acpi_lock_battery_dir(void); extern void *acpi_unlock_battery_dir(struct proc_dir_entry *acpi_battery_dir); Index: linux-acpi-2.6.git_i386/drivers/acpi/button.c === --- linux-acpi-2.6.git_i386.orig/drivers/acpi/button.c +++ linux-acpi-2.6.git_i386/drivers/acpi/button.c @@ -66,6 +66,10 @@ ACPI_MODULE_NAME(acpi_button) MODULE_DESCRIPTION(ACPI_BUTTON_DRIVER_NAME); MODULE_LICENSE(GPL); +MODULE_ALIAS(pnp:dPNP0c0c); +MODULE_ALIAS(pnp:dPNP0c0d); +MODULE_ALIAS(pnp:dPNP0c0e); + static int acpi_button_add(struct acpi_device *device); static int acpi_button_remove(struct acpi_device *device, int type); static int acpi_button_info_open_fs(struct inode *inode, struct file *file); Index: linux-acpi-2.6.git_i386/drivers/acpi/fan.c === --- linux-acpi-2.6.git_i386.orig/drivers/acpi/fan.c +++ linux-acpi-2.6.git_i386/drivers/acpi/fan.c @@ -46,6 +46,8 @@ ACPI_MODULE_NAME(acpi_fan) MODULE_DESCRIPTION(ACPI_FAN_DRIVER_NAME); MODULE_LICENSE(GPL); +MODULE_ALIAS(pnp:dPNP0c0b); + static int acpi_fan_add(struct
Re: Autoload acpi modules via uevent and pnpacpi
On Thursday 03 August 2006 09:25, Thomas Renninger wrote: I tried out the patch Bjorn sent some days ago to autoload ACPI modules via udev. The attached patch is based on latest test tree and includes Bjorn's code. This works, but is not nice. I had to tweak pnp to: - also register ACPI devices which have no _CRS func - allow (one byte longer) ACPI _HIDs to be used as PNP ids. Right. Now I got the following modules autoloaded (without the need of any userspace adjustments): battery, asus_acpi, button, ac (tested) fan, ibm_acpi, acpi_memhotplug, container, sbs,.. (should also work, but untested) Cool. That seems like a nice result, though as you point out, there are still plenty of issues to be resolved. I also wanted to use the suspend/resume stuff from there to point to the acpi_driver-suspend/resume funcs, but this does not work as pnp_driver-suspend/resume is used there, no idea whether this could be mapped somehow, I didn't see an easy way. Another problem is that e.g. thermal_zones do not have a PNP id. We could add a dummy _HID like ACPI for that one? I don't know anything about thermal zones. But it looks like acpi_device_set_id() and drivers/acpi/thermal.c conspire to use ACPI_THM already. Is it intended to pass all ACPI devices to pnpacpi in future? Not sure whether this is such a good idea. I don't know either. I don't like the current situation, where some devices are claimed by pnp_register_driver() and others are claimed with acpi_bus_register_driver(). There's (mostly) a single namespace, so it seem like there should be a single driver registration mechanism. Both struct acpi_device and struct pnp_dev contain a struct device. So for PNPACPI devices, we have two struct devices for the same thing, which feels wrong. And I thought someone said once upon a time that PNP and ACPI devices should really be connected to a platform_device, and I don't see that happening anywhere. And PNPACPI doesn't integrate at all with ACPI hot-plug, so hot-added ACPI devices won't show up via PNPACPI, even if they would be eligible. Obviously we have to retain the additional ACPI functionality. But I wonder whether we could make PNP the primary way of exposing things, with ACPI stuff as an optional capability. IMO it's better to let the stuff stay or be added to drivers/acpi. There already is suspend/resume for acpi devices there now, the uevent stuff should also go there? ACPI was obviously intended to replace and extend PNPBIOS. As such, I think we should try to use the same kernel and user-level interfaces, with some extensions as required to support the new functionality. Sorry I have so many questions and so little code. Sigh. I actually do have some half-baked patches to: - initialize PNP before ACPI - have acpi_device_register() call pnpacpi_add_device(), so almost all ACPI devices appear as PNP - remove most of the PNPACPI exclusions - add a pnp_acpi_device() to get struct acpi_device * back from a struct pnp_dev - convert drivers/acpi/fan.c to use pnp_register_driver() and pnp_acpi_device() (just as a proof-of-concept) But I haven't had time to do anything more with them. Thanks for playing with this stuff. Bjorn + /* Presence of _DIS indicates 'suprise_removal_ok' */ + status = acpi_get_handle(device-handle, _DIS, temp); + if (ACPI_SUCCESS(status)) + device-flags.suprise_removal_ok = 1; Are these changes related to the rest of your patch? And since you're touching this anyway, maybe you can fix this typo (suprise should be surprise)? Also below resourses should be resources. + /* Presence of _DIS indicates 'suprise_removal_ok' */ + status = acpi_get_handle(device-handle, _SRS, temp); + if (ACPI_SUCCESS(status)) + device-flags.set_resourses = 1; + /* Presence of _DIS indicates 'suprise_removal_ok' */ + status = acpi_get_handle(device-handle, _CRS, temp); + if (ACPI_SUCCESS(status)) + device-flags.current_resourses = 1; - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
