On Thu, Mar 31, 2016 at 03:20:03PM +0200, Ard Biesheuvel wrote: > On 31 March 2016 at 14:36, 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. > > Ack to that, but ... > > > 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. > > > > ... this patch will only affect those systems. DT-based systems, even > if they provide an ACPI description as well, will not invoke the ACPI > code unless you go out of your way to either boot without a DT or pass > 'acpi=force' on the command line. On the other hand, it will make > generic kernels (defconfig, etc) bootable on ACPI only systems, which > currently require special kernel builds. Another important reason for > this change is to get more build testing coverage for the arm64 ACPI > code that we had so much fuss about, e.g, by the kbuild test robot. I'd really like to get away from the concept of ACPI-only systems. Would we reject a .dtb contribution for such a machine? > > 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. > > > > The question is not about using it, the question is about > incorporating it into the default build. The runtime opt-in is not > going away with this patch. I understand that, but I still think that removing the dependency on EXPERT is indicative of saying "this stuff is good to be used by the masses", irrespective of a cmdline option. Maybe that's true, but it's not immediately obvious to me, with all the patches in flight. Will -- 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
