Messages in this thread | | | From | Grant Likely <> | Date | Thu, 8 Nov 2012 21:34:01 +0000 | Subject | Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support |
| |
On Thu, Nov 8, 2012 at 9:06 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Thursday, November 08, 2012 06:05:23 PM Grant Likely wrote: >> On Wed, Nov 7, 2012 at 9:58 AM, Mika Westerberg >> <mika.westerberg@linux.intel.com> 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? > > Not exactly. The idea is to execute _CRS in the core and attach the result > as a list of resources the struct acpi_device object representing the given > device node. > >> > 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. > > No, it is not. If anything, struct acpi_device is a counterpart of struct > device_node. :-) > > Yes, the name is misleading and it should be something like struct acpi_dev_node. > Yes, these objects _are_ registered as devices with the driver model and there > are drivers that bind to some of them. Yes, this is a mistake, but fixing it > will take quite some time, because it involves converting the drivers in > question.
Okay, fair enough. I was indeed thrown off by the fact that it embeds a struct device and there are drivers that bind against it. At least that is the sort of thing that can be fixed over the long haul without undue pain.
I can certainly see the advantage of having acpi nodes appear in sysfs. Interestingly enough I'm currently playing with a patch set that makes struct device_node a kobject so it can do the same. It is quite nice to get a back symlink from a struct device to a struct device_node when the pointer is populated.
>> Plus individual drivers can call the same functions if (and only if) the >> needed resources cannot fit into the bus type's native format. > > I'm kind of cautious about this particular thing.
I've seen enough cases where something doesn't quite fit into the model provided by a subsystem and it requires the driver to go asking for something specific. But I completely agree that caution is absolutely required and it shouldn't be done casually.
g.
| |