On Saturday, November 24, 2012 11:01:56 PM Rafael J. Wysocki wrote: > On Thursday, November 08, 2012 01:23:44 PM Toshi Kani wrote: > > Added a new .sys_notify interface, which allows ACPI drivers to > > register their system-level (ex. hotplug) notify handlers through > > their acpi_driver table. This removes redundant ACPI namespace > > walks from ACPI drivers for faster booting. > > > > The global notify handler acpi_bus_notify() is called for all > > system-level ACPI notifications, which then calls an appropriate > > driver's handler if any. ACPI drivers no longer need to register > > or unregister driver's handler to each ACPI device object. It also > > supports dynamic ACPI namespace with LoadTable & Unload opcode > > without any modification in ACPI drivers. > > > > Added a common system notify handler acpi_bus_sys_notify(), which > > allows ACPI drivers to set it to .sys_notify when this function is > > fully implemented. > > I don't really understand this. > > > It removes functional conflict between driver's > > notify handler and the global notify handler acpi_bus_notify(). > > > > Note that the changes maintain backward compatibility for ACPI > > drivers. Any drivers registered their hotplug handler through the > > existing interfaces, such as acpi_install_notify_handler() and > > register_acpi_bus_notifier(), will continue to work as before. > > I really wouldn't like to add new callbacks to struct acpi_device_ops, because > I'd like that whole thing to go away entirely eventually, along with struct > acpi_driver. > > Moreover, in this particular case, it really is not useful to have to define > a struct acpi_driver so that one can register for receiving system > notifications from ACPI. It would be really nice if non-ACPI drivers, such > as PCI or platform, could do that too. Which they do by using acpi_install_notify_handler() directly. > Besides, acpi_os_execute_deferred() is always run on CPU0, because of some > SMI-related peculiarity, which is not very efficient as far as the events > handling is concerned, but we can improve the situation a bit by queing the > execution of the registered handlers in a different workqueue. Maybe it's > worth considering if we're going to change this code anyway? Well, perhaps we really don't need to change it after all? Maybe we can just switch everyone to using acpi_install_notify_handler() and then we can just drop that code entirely? Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
