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
