On Tue, Nov 06, 2012 at 11:18:11PM +0100, Rafael J. Wysocki wrote: > > How is the SPI controller different than this? Is there some logical > > difference that requires a different framework? Or are you proposing > > that we get rid of acpi_bus_register_driver() and migrate everything > > to this new framework? > > Yes, I do, but let's just do it gradually. Bjorn, here is a concrete example how this is supposed to be used. Lets say we have an existing SPI slave driver that we want to extend to support enumeration from ACPI. Instead of writing acpi_driver glue for that (and registering it using acpi_bus_register_driver()) what we do is simple add these to the existing SPI driver: #ifdef CONFIG_ACPI static struct acpi_device_id my_spidrv_match[] = { /* ACPI IDs here */ { } }; MODULE_DEVICE_TABLE(acpi, my_spidrv_match); #endif static struct spi_driver my_spidrv = { ... .driver = { .acpi_match_table = ACPI_PTR(my_spidrv_match), }, }; The same thing works with platform, I2c and SPI drivers and can be extented to others as well. If the driver needs to do some ACPI specific configuration it can get the ACPI handle using its dev->acpi_handle. The above example now supports both, normal SPI (where the devices are enumerated by populating spi_board_info()) and ACPI. Adding support for Device Tree is similar than ACPI so a single driver can support all three easily at the same time. -- 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