On Tue, Jun 23, 2009 at 1:32 AM, Bjorn Helgaas<bjorn.helgaas@xxxxxx> wrote: > [Sorry for the duplicate; I meant to CC: linux-acpi, so I added it here.] > > Why do we have ACPI device drivers evaluating _INI? That seems > like something that should be done by Linux/ACPI, not by the driver. > > I see the following drivers using _INI: > drivers/hwmon/hp_accel.c > drivers/platform/x86/fujitsu-laptop.c > drivers/platform/x86/sony-laptop.c > > I looked at the git logs where the _INI usage was introduced in > these drivers, but none gives enough information for me to understand > why. > > If running _INI in the driver makes a difference, I think it's > really telling us about a problem in Linux/ACPI, and we should > fix that problem rather than sprinkling _INI evaluation around > in drivers. > > I do see _INI evaluation in this path: > > acpi_init > acpi_bus_init > acpi_initialize_objects(ACPI_FULL_INITIALIZATION) > acpi_ns_initialize_devices > acpi_ns_walk_namespace .. acpi_ns_init_one_device > > The spec (section 6.5.1) says OSPM should run _INI when a > description table is loaded. I assume the above path does > this for the DSDT, at least, but I'm not smart enough about > the ACPI CA to know whether we also handle SSDTs and dynamic > LoadTables correctly. > > Bjorn > > P.S. I'm about to go on vacation for a couple weeks, so I'll > be slow in responding to any discussion here. > -- > 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 > Hi, I don't know if it's related, but: eeepc-laptop is calling "INIT" for device ASUS010 asus-laptop is calling "INIT" for device ATK0100 But for eeepc-laptop we provide some flags special to INIT, and in asus-laptop it returns the model name. So I don't think we can move INIT for these. -- Corentin Chary http://xf.iksaif.net - http://uffs.org -- 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