| Message ID | 1459360718-24125-1-git-send-email-broonie@kernel.org (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On 30 March 2016 at 18:58, Mark Brown <broonie@kernel.org> 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. > I agree, Acked-by: Graeme Gregory <graeme.gregory@linaro.org> Thanks G > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > 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 > -- > 2.8.0.rc3 > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 30 March 2016 at 19:58, Mark Brown <broonie@kernel.org> 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@kernel.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > --- > 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 > -- > 2.8.0.rc3 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/30/2016 11:58 AM, 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@kernel.org> > --- > 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 > Yes, please. Reviewed-by: Al Stone <ahs3@redhat.com> Thanks.
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@kernel.org> Acked-by: Hanjun Guo <hanjun.guo@linaro.org> > --- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> 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@kernel.org> > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org> > >> --- >> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@huawei.com> 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@kernel.org> > > > > Acked-by: Hanjun Guo <hanjun.guo@linaro.org> > > > >> --- > >> 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. Will -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 31, 2016 at 2:36 PM, Will Deacon <will.deacon@arm.com> 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@huawei.com> 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@kernel.org> >> > >> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org> >> > >> >> --- >> >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 31 March 2016 at 14:36, Will Deacon <will.deacon@arm.com> 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@huawei.com> 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@kernel.org> >> > >> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org> >> > >> >> --- >> >> 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. > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 31, 2016 at 03:20:03PM +0200, Ard Biesheuvel wrote: > On 31 March 2016 at 14:36, Will Deacon <will.deacon@arm.com> 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@huawei.com> 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@kernel.org> > >> > > >> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org> > >> > > >> >> --- > >> >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 31 March 2016 at 15:38, Will Deacon <will.deacon@arm.com> wrote: > On Thu, Mar 31, 2016 at 03:20:03PM +0200, Ard Biesheuvel wrote: >> On 31 March 2016 at 14:36, Will Deacon <will.deacon@arm.com> 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@huawei.com> 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@kernel.org> >> >> > >> >> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org> >> >> > >> >> >> --- >> >> >> 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? > Absolutely not, and I expect such contributions will appear sooner rather than later. But the point of ACPI is the abstraction, and the ridiculous churn in DTB's carried in mainline clearly shows the need for that*. So there will be ACPI-only systems because the drivers are coded against the abstracted interface, and DT is simply not a drop-in replacement in that case. * of course, with the whole DSD debacle and the heterogeneity of the ARM ecosystem compared to the standardized PC, it remains to be seen if these systems require firmware upgrades less often than there are DT changes in the upstream tree, but at least the patches are applied on the correct [hardware] side in this case. >> > 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. > Well, we are not cc'ing to stable, are we? Or do you think the current stuff is so broken that we should even protect users of the upstream HEAD branch against it? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 31, 2016 at 01:36:50PM +0100, Will Deacon wrote: > I'm unsure about whether or not we want 'default y' here, but I'd like I can easily do followup patches which change that to be "default y if !ARM64" (or default y if $OTHER_ARCHES) and adding CONFIG_ACPI to defconfig (for the test coverage) if that helps? I think that's perfectly reasonable. As Ard says if both DT and ACPI are built in then the kernel will continue to prefer DT if it finds one. > 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 It definitely makes sense to get Catalin's input. I do think that this is something we don't want to defer indefinitely though, I think we're hurting ourselves more than we're helping. > "ACPI-only platforms" as simply "platforms without a .dtb" (modulo > any significant AML code) and therefore don't view this as a blocking > issue. I think people with a system with no DT provided might disagree on that one, and that this isn't really about end users or even distros but rather about the people working upstream and especially doing test and QA work upstream. > 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. My perception is that the EXPERT dependency is not having a meaningful impact on people who want to use ACPI, they're just going ahead and doing it anyway and expecting that distros will ship kernels which enable ACPI (which realistically the ones that don't currently are going to do as they start encountering these platforms). There doesn't seem to be much sign that decisions about shipping systems are being guided by this and the work that's happening on ACPI is going on regardless, some of it x86 focused. The kernel will still continue to prefer DT on arm64 systems so it's still the default upstream.
On Thu, Mar 31, 2016 at 04:48:44PM +0200, Ard Biesheuvel wrote: > On 31 March 2016 at 15:38, Will Deacon <will.deacon@arm.com> wrote: > > I'd really like to get away from the concept of ACPI-only systems. Would > > we reject a .dtb contribution for such a machine? > Absolutely not, and I expect such contributions will appear sooner > rather than later. > But the point of ACPI is the abstraction, and the ridiculous churn in > DTB's carried in mainline clearly shows the need for that*. So there > will be ACPI-only systems because the drivers are coded against the > abstracted interface, and DT is simply not a drop-in replacement in > that case. It's also worth remembering that just because we have a DT in tree that doesn't mean that people running actual systems are going to use it. For some systems there will be a user community that wants to do that but that won't be universal, there are going to be people who just use the default firmware. > > 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. > Well, we are not cc'ing to stable, are we? Or do you think the current > stuff is so broken that we should even protect users of the upstream > HEAD branch against it? Like I said in the other mail I'm also just not sure that this is something that people deciding what firmware to ship on their systems are paying much attention to. People are coming to their own assessment based on their own testing and other factors. Where I see this having an impact is more on having the rest of the upstream community keeping an eye on what the ACPI people are doing.
On Wed, Mar 30, 2016 at 10:58:38AM -0700, 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@kernel.org> I'm fine with dropping the EXPERT dependency (of course, not a cc stable). While arm64 ACPI is not "done" yet (nor is DT; there are important ongoing developments like PCIe, IORT), I think the core arm64 ACPI support passed the EXPERT stage. I also don't think a default y would imply any maintainer endorsement; vendors targeting ACPI are already doing this for various reasons (distro requirement, certain ACPI features like RAS). But, hopefully, it will encourage more vendors to start upstreaming their ACPI-related patches. However, building ACPI by default on arm64 doesn't mean that we can ignore potential misuses like PRP0001+_DSD blindly following DT (mis)concepts, breaking compatibility with older/newer firmware (this goes in both directions) or using ACPI for SoCs where it is clearly not suitable (e.g. non-SBSA). Such patches should be NAK'ed accordingly. > 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 Acked-by: Catalin Marinas <catalin.marinas@arm.com> That said, I'd like to see an opinion from the arm-soc maintainers since they were active on the original arm64 ACPI threads introducing this dependency (and I think they have the right to veto ;)).
On Tue, Apr 12, 2016 at 06:23:15PM +0100, Catalin Marinas wrote: > I'm fine with dropping the EXPERT dependency (of course, not a cc > stable). While arm64 ACPI is not "done" yet (nor is DT; there are > important ongoing developments like PCIe, IORT), I think the core arm64 > ACPI support passed the EXPERT stage. I also don't think a default y > would imply any maintainer endorsement; vendors targeting ACPI are > already doing this for various reasons (distro requirement, certain ACPI So you're OK with the current patch? > features like RAS). But, hopefully, it will encourage more vendors to > start upstreaming their ACPI-related patches. Yes, and also help include ACPI systems in the work we're doing testing things upstream. > However, building ACPI by default on arm64 doesn't mean that we can > ignore potential misuses like PRP0001+_DSD blindly following DT > (mis)concepts, breaking compatibility with older/newer firmware (this > goes in both directions) or using ACPI for SoCs where it is clearly not > suitable (e.g. non-SBSA). Such patches should be NAK'ed accordingly. Yes, I'm very concerned about some of the activity I'm seeing there myself - it does seem likely that we're going to have to extend ACPI for arm64 SoCs simply because things like SBSA are so bare bones but we need to pay attention to what's going on there to promote best practices and try to get people producing firmwares that make well thought through decisions regarding their ACPI usage.
On Wed, Apr 13, 2016 at 06:25:53AM +0100, Mark Brown wrote: > On Tue, Apr 12, 2016 at 06:23:15PM +0100, Catalin Marinas wrote: > > I'm fine with dropping the EXPERT dependency (of course, not a cc > > stable). While arm64 ACPI is not "done" yet (nor is DT; there are > > important ongoing developments like PCIe, IORT), I think the core arm64 > > ACPI support passed the EXPERT stage. I also don't think a default y > > would imply any maintainer endorsement; vendors targeting ACPI are > > already doing this for various reasons (distro requirement, certain ACPI > > So you're OK with the current patch? Yes, I posted an ack in the previous reply (with a note that Will and the arm-soc maintainers still have a right to veto this change).
On Wed, Apr 13, 2016 at 09:51:39AM +0100, Catalin Marinas wrote: > On Wed, Apr 13, 2016 at 06:25:53AM +0100, Mark Brown wrote: > > So you're OK with the current patch? > Yes, I posted an ack in the previous reply (with a note that Will and > the arm-soc maintainers still have a right to veto this change). Oh, sorry - I missed that somehow.
On Tue, Apr 12, 2016 at 10:23 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Wed, Mar 30, 2016 at 10:58:38AM -0700, 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@kernel.org> > > I'm fine with dropping the EXPERT dependency (of course, not a cc > stable). While arm64 ACPI is not "done" yet (nor is DT; there are > important ongoing developments like PCIe, IORT), I think the core arm64 > ACPI support passed the EXPERT stage. I also don't think a default y > would imply any maintainer endorsement; vendors targeting ACPI are > already doing this for various reasons (distro requirement, certain ACPI > features like RAS). But, hopefully, it will encourage more vendors to > start upstreaming their ACPI-related patches. > > However, building ACPI by default on arm64 doesn't mean that we can > ignore potential misuses like PRP0001+_DSD blindly following DT > (mis)concepts, breaking compatibility with older/newer firmware (this > goes in both directions) or using ACPI for SoCs where it is clearly not > suitable (e.g. non-SBSA). Such patches should be NAK'ed accordingly. > >> 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 > > Acked-by: Catalin Marinas <catalin.marinas@arm.com> > > That said, I'd like to see an opinion from the arm-soc maintainers since > they were active on the original arm64 ACPI threads introducing this > dependency (and I think they have the right to veto ;)). Switch the default from y to n on ARM64 (or default !ARM64) and I'll be happy to ack it. Mostly because it doesn't make sense for people building their own configs for embedded systems to get it turned on by default. Anyone running on a server is likely to clone an existing distro config in the first place. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 14, 2016 at 11:02:15AM -0700, Olof Johansson wrote: > Switch the default from y to n on ARM64 (or default !ARM64) and I'll > be happy to ack it. > Mostly because it doesn't make sense for people building their own > configs for embedded systems to get it turned on by default. Anyone > running on a server is likely to clone an existing distro config in > the first place. I can send a followup patch for that (I actually already wrote that after the discussion with Will), but I do think we should enable it in defconfig for the testing.
On Thu, Apr 14, 2016 at 11:25 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Apr 14, 2016 at 11:02:15AM -0700, Olof Johansson wrote: > >> Switch the default from y to n on ARM64 (or default !ARM64) and I'll >> be happy to ack it. > >> Mostly because it doesn't make sense for people building their own >> configs for embedded systems to get it turned on by default. Anyone >> running on a server is likely to clone an existing distro config in >> the first place. > > I can send a followup patch for that (I actually already wrote that > after the discussion with Will), but I do think we should enable it in > defconfig for the testing. That sounds good. So, to clarify: a follow-up patch (to arm@kernel.org) to turn on ACPI in arm64 defconfig, and a respin of this patch to change the default. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 14, 2016 at 11:49:11AM -0700, Olof Johansson wrote: > So, to clarify: a follow-up patch (to arm@kernel.org) to turn on ACPI > in arm64 defconfig, and a respin of this patch to change the default. Yes. Well, I actually had and additional patch to change the default to be y only for x86 and IA-64 separately to this one remove the EXPERT dependency but that's just bikeshedding. Will send tomorrow unless there's other comments.
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
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@kernel.org> --- drivers/acpi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)