On Thu, Mar 31, 2016 at 2:36 PM, Will Deacon <will.deacon@xxxxxxx> wrote: > On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote: >> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@xxxxxxxxxx> wrote: >> > On 2016/3/31 1:58, Mark Brown wrote: >> >> When ACPI was originally merged for arm64 it had only been tested on >> >> emulators and not on real physical platforms and no platforms were >> >> relying on it. This meant that there were concerns that there might be >> >> serious issues attempting to use it on practical systems so it had a >> >> dependency on EXPERT added to warn people that it was in an early stage >> >> of development with very little practical testing. Since then things >> >> have moved on a bit. We have seen people testing on real hardware and >> >> now have people starting to produce some platforms (the most prominent >> >> being the 96boards Cello) which only have ACPI support and which build >> >> and run to some useful extent with mainline. >> >> >> >> This is not to say that ACPI support or support for these systems is >> >> completely done, there are still areas being worked on such as PCI, but >> >> at this point it seems that we can be reasonably sure that ACPI will be >> >> viable for use on ARM64 and that the already merged support works for >> >> the cases it handles. For the AMD Seattle based platforms support >> >> outside of PCI has been fairly complete in mainline a few releases now. >> >> >> >> This is also not to say that we don't have vendors working with ACPI who >> >> are trying do things that we would not consider optimal but it does not >> >> appear that the EXPERT dependency is having a substantial impact on >> >> these vendors. >> >> >> >> Given all this it seems that at this point the EXPERT dependency mainly >> >> creates inconvenience for users with systems that are doing the right >> >> thing and gets in the way of including the ACPI code in the testing that >> >> people are doing on mainline. Removing it should help our ongoing >> >> testing cover those platforms with only ACPI support and help ensure >> >> that when ACPI code is merged any problems it causes for other users are >> >> more easily discovered. >> >> >> >> Signed-off-by: Mark Brown <broonie@xxxxxxxxxx> >> > >> > Acked-by: Hanjun Guo <hanjun.guo@xxxxxxxxxx> >> > >> >> --- >> >> drivers/acpi/Kconfig | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig >> >> index 82b96ee8624c..bf5dc1ac3446 100644 >> >> --- a/drivers/acpi/Kconfig >> >> +++ b/drivers/acpi/Kconfig >> >> @@ -5,7 +5,7 @@ >> >> menuconfig ACPI >> >> bool "ACPI (Advanced Configuration and Power Interface) Support" >> >> depends on !IA64_HP_SIM >> >> - depends on IA64 || X86 || (ARM64 && EXPERT) >> >> + depends on IA64 || X86 || ARM64 >> >> depends on PCI >> >> select PNP >> >> default y >> >> OK >> >> What do the ARM64 maintainers think? > > I'm unsure about whether or not we want 'default y' here, but I'd like > to wait for Catalin to come back from his 2-week holiday before going > anywhere with this patch. It's only fair that his opinion should be > taken into account, and there's not a huge rush for this. I do consider > "ACPI-only platforms" as simply "platforms without a .dtb" (modulo > any significant AML code) and therefore don't view this as a blocking > issue. > > We should also take into account the large amount of ongoing ACPI work > (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work, > etc), and decide whether or not that's currently in a state where we want > to encourage people to start using this in their arm64 kernels. Fair enough. -- 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
