On Wed, Nov 7, 2012 at 2:56 AM, Mika Westerberg
<mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> 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.
Thanks for the concrete example; that helps me a lot.
Struct device_driver is a generic structure, so it seems strange to
have to include non-generic things like of_device_id and now
acpi_match_table there.
I'm actually interested in the details you didn't include above, too.
For example, I don't know of a generic way to get resource information
from a "struct device *", so I assume you need to figure out what sort
of device it is and then do the appropriate PCI/ACPI/OF/DT/etc
operations to learn the resources?
I think it would be cool if there *were* a generic way to get "struct
device" resources. Then you could imagine a mechanism where a driver
supplied a list of identifiers it could claim, e.g.,
PCI_VEN_DEV(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_CE4100_UART),
ACPI_ID("PNP0501"), etc., and it might not need to know anything more
than what the identifier is.
--
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
