>-----Original Message-----
>From: Lebedev, Vladimir P
>Sent: Monday, July 10, 2006 2:08 PM
>To: Brown, Len; 'Pavel Machek'; 'kernel list'; 'Andrew Morton'
>Cc: '[email protected]'
>Subject: RE: [patch] fix boot with acpi=off
>
>> 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 is fragment from SBS patch.
>-----------------------------------------
> ACPI_FUNCTION_TRACE("acpi_ac_init");
>
>- acpi_ac_dir = proc_mkdir(ACPI_AC_CLASS, acpi_root_dir);
>+ acpi_ac_dir = acpi_lock_ac_dir();
> if (!acpi_ac_dir)
> return_VALUE(-ENODEV);
>- acpi_ac_dir->owner = THIS_MODULE;
>
> result = acpi_bus_register_driver(&acpi_ac_driver);
> if (result < 0) {
>- remove_proc_entry(ACPI_AC_CLASS, acpi_root_dir);
>+ acpi_unlock_ac_dir(acpi_ac_dir);
> return_VALUE(-ENODEV);
> }
>------------------------------------------
>Order of proc_mkdir and acpi_bus_register_driver is the same
>as order of acpi_lock_ac_dir. Could you explain what you meant?
>
>>Vladimir,
>>Any reason that the procfs stuff can't be after the
>>acpi_bus_register_driver()
>>calls?
>
>If we move it after acpi_bus_register_driver(), calls to
>create files inside battery/ac directories (called from
>acpi_bus_register_driver via acpi_{battery,ac}_add()) will fail.
ic.
Dunno why acpi_lock_ac_dir() makes pavel's box fail w/ acpi=off.
maybe we should simply extend his patch to cover sbs.c and
check acpi_disabled at the start of init of these drivers?
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]