On Wed, Nov 7, 2012 at 9:58 AM, Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > On Tue, Nov 06, 2012 at 11:36:08PM +0100, Rafael J. Wysocki wrote: >> > >> > OK, but then we need to pass the information obtained from _CRS >> > (presumably after some adjustments through _SRS) to drivers, or rather to >> > things like the SPI core, I2C core etc. so that they can create device >> > objects for drivers to bind to and quite frankly I don't see why not to use >> > ACPI resources for that. >> >> Nevertheless, the routines for parsing those resources should belong >> to the ACPI core, mostly to avoid code duplication. > > Rafael, > > So is the idea now that the ACPI core parses the resources and passes them > forward via struct acpi_device? I'm just wondering how to proceed with > these I2C and SPI enumeration patches. >From my experience with device tree, that seems the wrong way around. Device Tree used to have a separate "of_device" which is analogous to an acpi_device. The problem was always that of_devices never fit into the view that Linux has of the system. That would mean having both an of_device and and spi_device in completely separate parts of the driver model tree to support an spi device. Same for platform, i2c and onewire and others. Blech. So, yes I agree that ACPI core should have the tools for parsing the resources, but it makes sense for those functions to be helpers that the spi core acpi support and the i2c core acpi support use to populate the native spi_device and i2c_client structures. Plus individual drivers can call the same functions if (and only if) the needed resources cannot fit into the bus type's native format. We really could also use more common code between bus types for storing various kinds of resources, but that's a separate issue and doesn't affect this discussion. g. -- 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
