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@kernel.org (Rafael J. Wysocki)
Date: 2016-07-04 12:53:24
Also in: linux-acpi, lkml

On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki [off-list ref] wrote:
On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
quoted
On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
quoted
On 2016/6/30 21:27, Rafael J. Wysocki wrote:
quoted
On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
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/ ?
I'm fine to move it to other places such as arch/arm64/kernel/, but I
would like to ask ARM64 maintainer's suggestion for this.

Will, Catalin, what's your opinion on this?
We don't have any device-tree code for the architected timer under
arch/arm64, so I don't see why we should need anything for ACPI either.
And I don't see a reason for the GTDT code to be there in drivers/acpi/.

What gives?
Well, since there are things like acpi_lpss in there, my position here
is kind of weak. :-)

That said I'm not particularly happy with having them in
drivers/acpi/, so I definitely won't object against attempts to moving
them somewhere else.
Maybe it should go to the same place as the analogus DT code, then?
I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward, though.  I also think it should be made
clear that it is ARM64-only.

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