On 2014年01月22日 19:45, Mark Rutland wrote:
On Wed, Jan 22, 2014 at 08:26:50AM +0000, Linus Walleij wrote:
On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@xxxxxxxxxx> wrote:
From: Amit Daniel Kachhap <amit.daniel@xxxxxxxxxxx>
This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
name from the ACPI timer table is matched with all the registered
timer controllers and matching initialisation routine is invoked.
Signed-off-by: Amit Daniel Kachhap <amit.daniel@xxxxxxxxxxx>
Signed-off-by: Hanjun Guo <hanjun.guo@xxxxxxxxxx>
Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
to TIMER_OF_DECLARE() and I think this macro, if needed, should
be named TIMER_ACPI_DECLARE().
The reason is that "clocksource" is a Linux-internal name and this
macro pertains to the hardware name in respective system
description type.
+#ifdef CONFIG_ACPI
+#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
+ static const struct acpi_device_id __clksrc_acpi_table_##name \
+ __used __section(__clksrc_acpi_table) \
+ = { .id = compat, \
+ .driver_data = (kernel_ulong_t)fn }
+#else
+#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
+#endif
This hammers down the world to compile one binary for ACPI
and one binary for device tree. Maybe that's fine, I don't know.
How does it do that?
As far as I could tell CONFIG_ACPI and CONFIG_OF are not mutually
exclusive, and this just means that we only build the datastructures for
matching from ACPI when CONFIG_ACPI is enabled.
Have I missed something?
I definitely don't want to see mutually exclusive ACPI and DT support.
ACPI and DT did the same job so I think they should mutually exclusive.
if we enable both DT and ACPI in one system, this will leading confusions.
Further more, firmware guys will be happy to present all the devices
in one way, not both of them.
Thanks
Hanjun
--
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
