On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote: > On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote: > > [ ... ] > > >> 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 -- 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
