Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support

[Grant Likely]

On Fri, Nov 9, 2012 at 3:11 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
> [+cc Greg, Peter, Tony since they acked the original patch [1]]
>
> On Thu, Nov 8, 2012 at 1:04 PM, Mika Westerberg
> <mika.westerberg@xxxxxxxxxxxxxxx> wrote:
>> On Thu, Nov 08, 2012 at 12:32:25PM -0700, Bjorn Helgaas wrote:
>>> 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.
>>
>> Yes, but in a sense the DT and ACPI are "generic". So that they are used to
>> describe the configuration of a machine.
>
> What I meant by "generic" was "useful across all architectures."  The
> new acpi_match_table and acpi_handle fields [1] are not generic in
> that sense because they're present on all architectures but used only
> on x86 and ia64.  The existing of_match_table and of_node are
> similarly unused on many architectures.  This doesn't seem like a
> scalable strategy to me.  Are we going to add a pnpbios_node for x86
> PNPBIOS machines without ACPI, a pdc_hpa for parisc machines with PDC,
> etc.?
>
> [1] https://patchwork.kernel.org/patch/1677221/

Ultimately yes, I think that is what we want to do, but there is first
the non-trivial problem to solve of figuring out how ACPI/DT/whatever
data maps into what the driver expects. For example, say a device uses
two GPIOs (A & B) and we have a generic get_gpio(int index) function
that works for both ACPI and DT. But what if the ACPI binding has the
gpios in the order A,B and DT orders them B,A? I do want to coordinate
between the DT and ACPI camps to avoid those situations as much as
possible, but they will happen. When they do the driver will still
need firmware specific data. It doesn't make any sense to put that
stuff outside the driver because only that specific driver needs the
extra information.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/