[adding linux-acpi@xxxxxxxxxxxxxxx to cc] acpi=off used to be handled by acpi_bus_register_driver() for these drivers. But now acpi_lock_ac_dir() and acpi_lock_battery_dir() for procfs are inserted before that in the _init functions. This will be a problem for sbs.c also. Vladimir, Any reason that the procfs stuff can't be after the acpi_bus_register_driver() calls? Under what conditions could these lock functions fail? -Len >-----Original Message----- >From: Pavel Machek [mailto:pavel@xxxxxx] >Sent: Saturday, July 08, 2006 8:44 AM >To: kernel list; Andrew Morton; Brown, Len >Subject: [patch] fix boot with acpi=off > >With acpi=off and acpi_ac/battery compiled into kernel, acpi breaks >boot. This fixes it. > >Signed-off-by: Pavel Machek <pavel@xxxxxxx> > >--- >commit 30b8ecda788b096fbd7088808f9af65c41c3a83d >tree 3c28088018932f9ceb18bcf980507474d4a50c4e >parent 05f70501240c6ad5f852f13c187ee55579ad7bb8 >author <pavel@xxxxxxxxxx> Sat, 08 Jul 2006 14:43:13 +0200 >committer <pavel@xxxxxxxxxx> Sat, 08 Jul 2006 14:43:13 +0200 > > drivers/acpi/ac.c | 2 ++ > drivers/acpi/battery.c | 3 +++ > 2 files changed, 5 insertions(+), 0 deletions(-) > >diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c >index 24ccf81..432b6b7 100644 >--- a/drivers/acpi/ac.c >+++ b/drivers/acpi/ac.c >@@ -285,6 +285,8 @@ static int __init acpi_ac_init(void) > { > int result; > >+ if (acpi_disabled) >+ return -ENODEV; > > acpi_ac_dir = acpi_lock_ac_dir(); > if (!acpi_ac_dir) >diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c >index 2ce9b35..5af1f64 100644 >--- a/drivers/acpi/battery.c >+++ b/drivers/acpi/battery.c >@@ -764,6 +764,9 @@ static int __init acpi_battery_init(void > { > int result; > >+ if (acpi_disabled) >+ return -ENODEV; >+ > acpi_battery_dir = acpi_lock_battery_dir(); > if (!acpi_battery_dir) > return -ENODEV; > >-- >(english) http://www.livejournal.com/~pavelmachek >(cesky, pictures) >http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
