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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
