On Sat, Nov 03, 2012 at 10:13:10PM +0200, Mika Westerberg wrote: > On Sat, Nov 03, 2012 at 01:42:02PM -0600, Bjorn Helgaas wrote: > > > + case ACPI_RESOURCE_TYPE_IRQ: > > > + info->gsi = res->data.irq.interrupts[0]; > > > + info->triggering = res->data.irq.triggering; > > > + info->polarity = res->data.irq.polarity; > > > + break; > > > + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ: > > > + info->gsi = res->data.extended_irq.interrupts[0]; > > > + info->triggering = res->data.extended_irq.triggering; > > > + info->polarity = res->data.extended_irq.polarity; > > A driver doesn't seem like the right place for _CRS parsing code. I > > think the intent of _CRS is to describe resources that need to be > > coordinated across all devices, e.g., MMIO space, I/O port space, and > > IRQs. Since these resources require system-wide coordination, even > > when we don't have drivers for some devices, the ACPI core should be > > able to parse _CRS without needing any device-specific knowledge. > I think the driver is the only one who really knows the resources it needs > in order to talk the hardware. Generic SPI drivers expect the subsystem to supply them with an interrupt number; if there is a single interrupt it seems reasonable for the generic code to continue to do that for them when they're instantiated from ACPI. On the other hand if there are muliple interrupts it should probably give up and punt to the driver. > The purpose of the above code is to extract the resources in a suitable > form so that we can create a struct spi_device out of them automatically, > in a similar way than the Device Tree does. Definitely agreed. -- 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
