Thread (43 messages) flat view 43 messages, 10 authors, 2016-07-10

[PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

From: Rafael J. Wysocki <hidden>
Date: 2016-07-01 20:57:29
Also in: linux-acpi, lkml

On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:

[ ... ]
quoted
quoted
GTDT is part of ACPI spec, drivers/acpi/ is for driver code of
ACPI spec, I think it can stay in drivers/acpi/ from this point
of view, am I right?
The question is not "Can it?", but "Does it need to?".

It is in the spec, but still there's only one architecture needing it.

There is no way to test it on any other architecture and no reason to build it
for any other architecture, so why does it need to be located in drivers/acpi/ ?
Hi Rafael,

what is the problem of having it in drivers/acpi ?
There's no reason for it to be there.
There are cpufreq-dt, speedstep*, tegra124-* in drivers/cpufreq.
Yes, they are, but for a reason.  Having them in there makes it easier to
rework and clean up the core.
clocksource-probe which is DT based with different drivers using it in 
drivers/clocksource with a pletore of different archs.
So maybe the GTDT code should be there too?
Cstate code which is only used by x86 is in drivers/acpi, it is only 
used by x86/ia64 and it isn't a problem.
It is a problem.  drivers/acpi/ is not the right place for arch-specific code.
There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the
comprehension of the code.

IMHO, having all ACPI code in the same directory will encourage the 
consolidation.
The consolidation of what exactly?

In particular, how does the GTDT code in drivers/acpi/ help to consolidate
anything?

Thanks,
Rafael
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help