LKML Archive on
help / color / mirror / Atom feed
From: Thomas Renninger <>
To: Len Brown <>
Cc: linux-kernel <>,
	linux-acpi <>,
	Bjorn Helgaas <>,
	Kay Sievers <>
Subject: [PATCH 0/3] ACPI autoloading
Date: Sun, 17 Jun 2007 22:22:04 +0200	[thread overview]
Message-ID: <1182111724.4204.0.camel@noname> (raw)

[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]

This patch series enables ACPI modules to get loaded automatically via
module aliases.

Thanks to Kay I got help with the udev strings and this got already some
testing and review.

There are some minor problems left, but this should be mm ready and it
would be great if you can add these to your acpi-test tree, Len (patches
clean against 2.6.22-rc4, the last patch has some offset/fuzz against
acpi-test, but should patch correctly without modifications).

The known problems are:

A) Cannot pass acpi_device_id through ops.add (probe equivalent func)

int acpi_match_device_ids(..)
should be:
const acpi_device_id *acpi_match_device_ids
and the matching device id should get passed to the acpi driver's .add
This would ease up the code in the ACPI driver a lot (e.g. see button.c,
it is compared again which device (HID) has been found. Theoretically
the drivers also needs to check CIDs...).

The problem is that in scan.c ACPI driver is abstracted to use .match
and .probe "struct bus_type" functions and I have no idea how the
matching acpi_device_id should get passed or stored from
acpi_match_device_ids (.match) to ops.add (invoked in .probe).
        kernel_ulong_t driver_data;
of acpi_device_id got added, but is not used at all atm.

B) Thermal module always gets loaded

This is because _TZ_ (scope?!?) always gets added, but is declared as a
device or at least pops up as a thermal device.
This is in drivers/acpi/utilities/utglobal.c:

 * Predefined ACPI Names (Built-in to the Interpreter)
 * 1) _SB_ is defined to be a device to allow \_SB_._INI to be run
 *    during the initialization sequence.
 * 2) _TZ_ is defined to be a thermal zone in order to allow ASL code to
 *    perform a Notify() operation on it.

Any idea how to get rid of that is very welcome.
Is this to be able to process buggy ASL code of this kind?:
"Notify ("_TZ_", 0x80)"
While _TZ_ is not a real device, but a scope operator and gets
statically declared as a device here to solve such things?

C) Renaming/Unifying of HID strings

This shouldn't be a problem. Consequence is that the new ACPI sysfs
structure will show other names, but as it got introduced recently this
shouldn't hurt anyone?

For better readability we could map all HIDs to a device name through a
HID <-> Device Name - enum and table. And then export "battery" again
through /sys instead of "PNP0C0A".
This was a bit mixed up. If, this should get implemented soon as the
sysfs structure should not get altered that often...
If wanted, I can send an on top patch later...

D) Why renaming struct acpi_device_id to struct __acpi_device_id

Not a problem, just for understanding why I have done this:
struct acpi_device_id already exists in ACPICA. The module aliasing
interface requires that struct "SUBSYSTEM"_device_id is used as name.
This is not that obvious (include/linux/module.h):
#define MODULE_GENERIC_TABLE(gtype,name) and
#define MODULE_DEVICE_TABLE(type,name)


For SUSE users who want to test this, you also need a minor change in
userspace (AFAIK this additionally abstraction vanishes soon...
hopefully), the change is attached. Theoretically ACPI modules should
now get autoloaded via udev out of the box...

Any comments, corrections, ideas, etc. very welcome.



[-- Attachment #2: acpi_autoload_userspace_suse.patch --]
[-- Type: text/x-patch, Size: 968 bytes --]

Index: /etc/udev/rules.d/80-sysconfig.rules
--- .orig/etc/udev/rules.d/80-sysconfig.rules
+++ /etc/udev/rules.d/80-sysconfig.rules
@@ -15,5 +15,6 @@ SUBSYSTEM=="pnp", ACTION=="add", RUN+="/
 SUBSYSTEM=="ide", ACTION=="add", RUN+="/sbin/hwup ide-devpath-%p -o hotplug"
 SUBSYSTEM=="input", KERNEL=="input[0-9]*", ACTION=="add", RUN+="/sbin/hwup input-devpath-%p -o hotplug"
 SUBSYSTEM=="platform", ACTION=="add", RUN+="/sbin/hwup platform-devpath-%p -o hotplug"
+SUBSYSTEM=="acpi", ACTION=="add", RUN+="/sbin/hwup acpi-devpath-%p -o hotplug"
Index: /sbin/hwup
--- .orig/sbin/hwup
+++ /sbin/hwup
@@ -65,6 +65,7 @@ get_config_getcfg() {
 is_known_subsystem() {
 	case "$1" in
+		acpi)             return 0 ;;
 		ccw)              return 0 ;;
 		ccwgroup)         return 0 ;;
 		iucv)             return 0 ;;

             reply	other threads:[~2007-06-17 20:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-17 20:22 Thomas Renninger [this message]
2007-07-03  7:40 ` [PATCH 0/3] ACPI autoloading Len Brown
2007-07-03 11:50   ` Thomas Renninger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1182111724.4204.0.camel@noname \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).