| Message ID | 20250228170155.2623386-1-superm1@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for hidden choices to platform_profile | expand |
Hi Mario, On Fri, Feb 28, 2025, at 12:01 PM, Mario Limonciello wrote: > From: Mario Limonciello <mario.limonciello@amd.com> > > When two drivers provide platform profile handlers but use different > strings to mean (essentially) the same thing the legacy interface won't > export them because it only shows profiles common to multiple drivers. > > This causes an unexpected behavior to people who have upgraded from an > earlier kernel because if multiple drivers have bound platform profile > handlers they might not be able to access profiles they were expecting. > > Introduce a concept of a "hidden choice" that drivers can register and > the platform profile handler code will utilize when using the legacy > interface. > > There have been some other attempts at solving this issue in other ways. > This serves as an alternative to those attempts. > > Link: > https://lore.kernel.org/platform-driver-x86/e64b771e-3255-42ad-9257-5b8fc6c24ac9@gmx.de/T/#t > Link: > https://lore.kernel.org/platform-driver-x86/CAGwozwF-WVEgiAbWbRCiUaXf=BVa3KqmMJfs06trdMQHpTGmjQ@mail.gmail.com/T/#m2f3929e2d4f73cc0eedd14738170dad45232fd18 > Cc: Antheas Kapenekakis <lkml@antheas.dev> > Cc: "Luke D. Jones" <luke@ljones.dev> > > Mario Limonciello (3): > ACPI: platform_profile: Add support for hidden choices > platform/x86/amd: pmf: Add 'quiet' to hidden choices > platform/x86/amd: pmf: Add balanced-performance to hidden choices > > drivers/acpi/platform_profile.c | 94 +++++++++++++++++++++++------- > drivers/platform/x86/amd/pmf/sps.c | 11 ++++ > include/linux/platform_profile.h | 3 + > 3 files changed, 87 insertions(+), 21 deletions(-) > > -- > 2.43.0 The patches are all good - but my question is do we really need the whole hidden implementation bit? If the options are not hidden, and someone chooses quiet or balanced-performance for the amd-pmf driver - does it really matter that it's going to do the same as low-power or performance? So, same feedback as I had for Antheas's patches. I understand why this is being proposed but for me it is making things unnecessarily complicated. My personal vote remains that the amd_pmf driver carries the superset to keep everyone happy (sorry - it sucks to be the CPU vendor that has to play nice with everyone). Mark
On 2/28/2025 13:39, Mark Pearson wrote: > Hi Mario, > > On Fri, Feb 28, 2025, at 12:01 PM, Mario Limonciello wrote: >> From: Mario Limonciello <mario.limonciello@amd.com> >> >> When two drivers provide platform profile handlers but use different >> strings to mean (essentially) the same thing the legacy interface won't >> export them because it only shows profiles common to multiple drivers. >> >> This causes an unexpected behavior to people who have upgraded from an >> earlier kernel because if multiple drivers have bound platform profile >> handlers they might not be able to access profiles they were expecting. >> >> Introduce a concept of a "hidden choice" that drivers can register and >> the platform profile handler code will utilize when using the legacy >> interface. >> >> There have been some other attempts at solving this issue in other ways. >> This serves as an alternative to those attempts. >> >> Link: >> https://lore.kernel.org/platform-driver-x86/e64b771e-3255-42ad-9257-5b8fc6c24ac9@gmx.de/T/#t >> Link: >> https://lore.kernel.org/platform-driver-x86/CAGwozwF-WVEgiAbWbRCiUaXf=BVa3KqmMJfs06trdMQHpTGmjQ@mail.gmail.com/T/#m2f3929e2d4f73cc0eedd14738170dad45232fd18 >> Cc: Antheas Kapenekakis <lkml@antheas.dev> >> Cc: "Luke D. Jones" <luke@ljones.dev> >> >> Mario Limonciello (3): >> ACPI: platform_profile: Add support for hidden choices >> platform/x86/amd: pmf: Add 'quiet' to hidden choices >> platform/x86/amd: pmf: Add balanced-performance to hidden choices >> >> drivers/acpi/platform_profile.c | 94 +++++++++++++++++++++++------- >> drivers/platform/x86/amd/pmf/sps.c | 11 ++++ >> include/linux/platform_profile.h | 3 + >> 3 files changed, 87 insertions(+), 21 deletions(-) >> >> -- >> 2.43.0 > > The patches are all good - but my question is do we really need the whole hidden implementation bit? > > If the options are not hidden, and someone chooses quiet or balanced-performance for the amd-pmf driver - does it really matter that it's going to do the same as low-power or performance? > > So, same feedback as I had for Antheas's patches. I understand why this is being proposed but for me it is making things unnecessarily complicated. > > My personal vote remains that the amd_pmf driver carries the superset to keep everyone happy (sorry - it sucks to be the CPU vendor that has to play nice with everyone). > > Mark Well so the problem with having all of them is specifically what happens when "only" amd-pmf is bound? If you advertise both "low power" and "quiet" it's really confusing to userspace what the difference is. The fact that it's actually 100% the same brings me to my personal opinion on all of this. Although I spent time writing up this series to do it this way my "preference" is that we permanently alias "low power" and "quiet" to one another and update all drivers to use "low power" instead. Granted that doesn't help the case of balance-performance being hidden that Antheas mentioned for acer-wmi and legion-wmi but I don't know serious of a problem that actually is.
On Fri, 28 Feb 2025 at 20:45, Mario Limonciello <superm1@kernel.org> wrote: > > On 2/28/2025 13:39, Mark Pearson wrote: > > Hi Mario, > > > > On Fri, Feb 28, 2025, at 12:01 PM, Mario Limonciello wrote: > >> From: Mario Limonciello <mario.limonciello@amd.com> > >> > >> When two drivers provide platform profile handlers but use different > >> strings to mean (essentially) the same thing the legacy interface won't > >> export them because it only shows profiles common to multiple drivers. > >> > >> This causes an unexpected behavior to people who have upgraded from an > >> earlier kernel because if multiple drivers have bound platform profile > >> handlers they might not be able to access profiles they were expecting. > >> > >> Introduce a concept of a "hidden choice" that drivers can register and > >> the platform profile handler code will utilize when using the legacy > >> interface. > >> > >> There have been some other attempts at solving this issue in other ways. > >> This serves as an alternative to those attempts. > >> > >> Link: > >> https://lore.kernel.org/platform-driver-x86/e64b771e-3255-42ad-9257-5b8fc6c24ac9@gmx.de/T/#t > >> Link: > >> https://lore.kernel.org/platform-driver-x86/CAGwozwF-WVEgiAbWbRCiUaXf=BVa3KqmMJfs06trdMQHpTGmjQ@mail.gmail.com/T/#m2f3929e2d4f73cc0eedd14738170dad45232fd18 > >> Cc: Antheas Kapenekakis <lkml@antheas.dev> > >> Cc: "Luke D. Jones" <luke@ljones.dev> > >> > >> Mario Limonciello (3): > >> ACPI: platform_profile: Add support for hidden choices > >> platform/x86/amd: pmf: Add 'quiet' to hidden choices > >> platform/x86/amd: pmf: Add balanced-performance to hidden choices > >> > >> drivers/acpi/platform_profile.c | 94 +++++++++++++++++++++++------- > >> drivers/platform/x86/amd/pmf/sps.c | 11 ++++ > >> include/linux/platform_profile.h | 3 + > >> 3 files changed, 87 insertions(+), 21 deletions(-) > >> > >> -- > >> 2.43.0 > > > > The patches are all good - but my question is do we really need the whole hidden implementation bit? > > > > If the options are not hidden, and someone chooses quiet or balanced-performance for the amd-pmf driver - does it really matter that it's going to do the same as low-power or performance? > > > > So, same feedback as I had for Antheas's patches. I understand why this is being proposed but for me it is making things unnecessarily complicated. > > > > My personal vote remains that the amd_pmf driver carries the superset to keep everyone happy (sorry - it sucks to be the CPU vendor that has to play nice with everyone). > > > > Mark > > Well so the problem with having all of them is specifically what happens > when "only" amd-pmf is bound? > > If you advertise both "low power" and "quiet" it's really confusing to > userspace what the difference is. > > The fact that it's actually 100% the same brings me to my personal > opinion on all of this. Although I spent time writing up this series to > do it this way my "preference" is that we permanently alias "low power" > and "quiet" to one another and update all drivers to use "low power" > instead. > > Granted that doesn't help the case of balance-performance being hidden > that Antheas mentioned for acer-wmi and legion-wmi but I don't know > serious of a problem that actually is. Hi Mark, So I agree with Mario here on that. I actually made the patch you suggested last Sunday [1]. But then I looked at it and thought to myself that I can't ship this, so I did a v2, which is what I sent on Tuesday. My priority here is to not disrupt the existing ABI with 6.14. This would allow extending this discussion by a couple of weeks, so a more permanent solution can be found. If that would be the case, perhaps my patch series is more preferable as, since it is smaller, it would be cleaner to revert. Antheas [1] https://github.com/hhd-dev/patchwork/commit/aae724e8c90da3605bd131672fea07cd866af55f
On 2/28/2025 13:53, Antheas Kapenekakis wrote: > On Fri, 28 Feb 2025 at 20:45, Mario Limonciello <superm1@kernel.org> wrote: >> >> On 2/28/2025 13:39, Mark Pearson wrote: >>> Hi Mario, >>> >>> On Fri, Feb 28, 2025, at 12:01 PM, Mario Limonciello wrote: >>>> From: Mario Limonciello <mario.limonciello@amd.com> >>>> >>>> When two drivers provide platform profile handlers but use different >>>> strings to mean (essentially) the same thing the legacy interface won't >>>> export them because it only shows profiles common to multiple drivers. >>>> >>>> This causes an unexpected behavior to people who have upgraded from an >>>> earlier kernel because if multiple drivers have bound platform profile >>>> handlers they might not be able to access profiles they were expecting. >>>> >>>> Introduce a concept of a "hidden choice" that drivers can register and >>>> the platform profile handler code will utilize when using the legacy >>>> interface. >>>> >>>> There have been some other attempts at solving this issue in other ways. >>>> This serves as an alternative to those attempts. >>>> >>>> Link: >>>> https://lore.kernel.org/platform-driver-x86/e64b771e-3255-42ad-9257-5b8fc6c24ac9@gmx.de/T/#t >>>> Link: >>>> https://lore.kernel.org/platform-driver-x86/CAGwozwF-WVEgiAbWbRCiUaXf=BVa3KqmMJfs06trdMQHpTGmjQ@mail.gmail.com/T/#m2f3929e2d4f73cc0eedd14738170dad45232fd18 >>>> Cc: Antheas Kapenekakis <lkml@antheas.dev> >>>> Cc: "Luke D. Jones" <luke@ljones.dev> >>>> >>>> Mario Limonciello (3): >>>> ACPI: platform_profile: Add support for hidden choices >>>> platform/x86/amd: pmf: Add 'quiet' to hidden choices >>>> platform/x86/amd: pmf: Add balanced-performance to hidden choices >>>> >>>> drivers/acpi/platform_profile.c | 94 +++++++++++++++++++++++------- >>>> drivers/platform/x86/amd/pmf/sps.c | 11 ++++ >>>> include/linux/platform_profile.h | 3 + >>>> 3 files changed, 87 insertions(+), 21 deletions(-) >>>> >>>> -- >>>> 2.43.0 >>> >>> The patches are all good - but my question is do we really need the whole hidden implementation bit? >>> >>> If the options are not hidden, and someone chooses quiet or balanced-performance for the amd-pmf driver - does it really matter that it's going to do the same as low-power or performance? >>> >>> So, same feedback as I had for Antheas's patches. I understand why this is being proposed but for me it is making things unnecessarily complicated. >>> >>> My personal vote remains that the amd_pmf driver carries the superset to keep everyone happy (sorry - it sucks to be the CPU vendor that has to play nice with everyone). >>> >>> Mark >> >> Well so the problem with having all of them is specifically what happens >> when "only" amd-pmf is bound? >> >> If you advertise both "low power" and "quiet" it's really confusing to >> userspace what the difference is. >> >> The fact that it's actually 100% the same brings me to my personal >> opinion on all of this. Although I spent time writing up this series to >> do it this way my "preference" is that we permanently alias "low power" >> and "quiet" to one another and update all drivers to use "low power" >> instead. >> >> Granted that doesn't help the case of balance-performance being hidden >> that Antheas mentioned for acer-wmi and legion-wmi but I don't know >> serious of a problem that actually is. > > Hi Mark, > So I agree with Mario here on that. I actually made the patch you > suggested last Sunday [1]. My suggestion is actually more drastic than what you linked. It's that we make a change in the core to special case the aliased strings, and then adjust all in-tree drivers to pick one or the other. > > But then I looked at it and thought to myself that I can't ship this, > so I did a v2, which is what I sent on Tuesday. > > My priority here is to not disrupt the existing ABI with 6.14. This > would allow extending this discussion by a couple of weeks, so a more > permanent solution can be found. > > If that would be the case, perhaps my patch series is more preferable > as, since it is smaller, it would be cleaner to revert. > > Antheas > > [1] https://github.com/hhd-dev/patchwork/commit/aae724e8c90da3605bd131672fea07cd866af55f
On Fri, Feb 28, 2025, at 2:44 PM, Mario Limonciello wrote: > On 2/28/2025 13:39, Mark Pearson wrote: >> Hi Mario, >> >> On Fri, Feb 28, 2025, at 12:01 PM, Mario Limonciello wrote: >>> From: Mario Limonciello <mario.limonciello@amd.com> >>> >>> When two drivers provide platform profile handlers but use different >>> strings to mean (essentially) the same thing the legacy interface won't >>> export them because it only shows profiles common to multiple drivers. >>> >>> This causes an unexpected behavior to people who have upgraded from an >>> earlier kernel because if multiple drivers have bound platform profile >>> handlers they might not be able to access profiles they were expecting. >>> >>> Introduce a concept of a "hidden choice" that drivers can register and >>> the platform profile handler code will utilize when using the legacy >>> interface. >>> >>> There have been some other attempts at solving this issue in other ways. >>> This serves as an alternative to those attempts. >>> >>> Link: >>> https://lore.kernel.org/platform-driver-x86/e64b771e-3255-42ad-9257-5b8fc6c24ac9@gmx.de/T/#t >>> Link: >>> https://lore.kernel.org/platform-driver-x86/CAGwozwF-WVEgiAbWbRCiUaXf=BVa3KqmMJfs06trdMQHpTGmjQ@mail.gmail.com/T/#m2f3929e2d4f73cc0eedd14738170dad45232fd18 >>> Cc: Antheas Kapenekakis <lkml@antheas.dev> >>> Cc: "Luke D. Jones" <luke@ljones.dev> >>> >>> Mario Limonciello (3): >>> ACPI: platform_profile: Add support for hidden choices >>> platform/x86/amd: pmf: Add 'quiet' to hidden choices >>> platform/x86/amd: pmf: Add balanced-performance to hidden choices >>> >>> drivers/acpi/platform_profile.c | 94 +++++++++++++++++++++++------- >>> drivers/platform/x86/amd/pmf/sps.c | 11 ++++ >>> include/linux/platform_profile.h | 3 + >>> 3 files changed, 87 insertions(+), 21 deletions(-) >>> >>> -- >>> 2.43.0 >> >> The patches are all good - but my question is do we really need the whole hidden implementation bit? >> >> If the options are not hidden, and someone chooses quiet or balanced-performance for the amd-pmf driver - does it really matter that it's going to do the same as low-power or performance? >> >> So, same feedback as I had for Antheas's patches. I understand why this is being proposed but for me it is making things unnecessarily complicated. >> >> My personal vote remains that the amd_pmf driver carries the superset to keep everyone happy (sorry - it sucks to be the CPU vendor that has to play nice with everyone). >> >> Mark > > Well so the problem with having all of them is specifically what happens > when "only" amd-pmf is bound? > > If you advertise both "low power" and "quiet" it's really confusing to > userspace what the difference is. Ah - I guess you get platforms without profile support where amd-pmf is the only thing. I hadn't considered that. FWIW, I believe we (Lenovo) have both low power and quiet on Windows...and they really don't make much difference (which is why the thermal team didn't do them both on Linux). I don't know if Windows users are more or less confused (or maybe they've just abandoned all hope and are migrating to Linux...) You have a better feeling as to how many issues you'll get raised if they behave the same, and have to support a wider ecosystem, so I'm happy to be over-ruled. I just wanted to wave my flag that I think the driver is getting too complicated. I'm slightly dreading having to debug customer issues at this point. > > The fact that it's actually 100% the same brings me to my personal > opinion on all of this. Although I spent time writing up this series to > do it this way my "preference" is that we permanently alias "low power" > and "quiet" to one another and update all drivers to use "low power" > instead. > Guaranteed if you do that some vendor will have something that differentiates. I can see having a 'use as much power as possible without needing fans' for quiet, and 'make the battery last as long as humanely possible whilst keeping the system usable' mode for low-power. Don't think anyone has done it...but they could. > Granted that doesn't help the case of balance-performance being hidden > that Antheas mentioned for acer-wmi and legion-wmi but I don't know > serious of a problem that actually is. I really have to go play with this on the Legion-Go. I need a time-machine..... Mark
On Fri, Feb 28, 2025 at 9:02 AM Mario Limonciello <superm1@kernel.org> wrote: > > From: Mario Limonciello <mario.limonciello@amd.com> > > When two drivers provide platform profile handlers but use different > strings to mean (essentially) the same thing the legacy interface won't > export them because it only shows profiles common to multiple drivers. > > This causes an unexpected behavior to people who have upgraded from an > earlier kernel because if multiple drivers have bound platform profile > handlers they might not be able to access profiles they were expecting. > > Introduce a concept of a "hidden choice" that drivers can register and > the platform profile handler code will utilize when using the legacy > interface. > > There have been some other attempts at solving this issue in other ways. > This serves as an alternative to those attempts. > > Link: https://lore.kernel.org/platform-driver-x86/e64b771e-3255-42ad-9257-5b8fc6c24ac9@gmx.de/T/#t > Link: https://lore.kernel.org/platform-driver-x86/CAGwozwF-WVEgiAbWbRCiUaXf=BVa3KqmMJfs06trdMQHpTGmjQ@mail.gmail.com/T/#m2f3929e2d4f73cc0eedd14738170dad45232fd18 > Cc: Antheas Kapenekakis <lkml@antheas.dev> > Cc: "Luke D. Jones" <luke@ljones.dev> > > Mario Limonciello (3): > ACPI: platform_profile: Add support for hidden choices > platform/x86/amd: pmf: Add 'quiet' to hidden choices > platform/x86/amd: pmf: Add balanced-performance to hidden choices > > drivers/acpi/platform_profile.c | 94 +++++++++++++++++++++++------- > drivers/platform/x86/amd/pmf/sps.c | 11 ++++ > include/linux/platform_profile.h | 3 + > 3 files changed, 87 insertions(+), 21 deletions(-) > > -- > 2.43.0 > Everything seems to be working as intended. I applied these patches on top of my lenovo-wmi series modified to always show balanced-performance and with quiet as the lowest profile. Testing was done on the Legion Go. Results: $ cat /sys/firmware/acpi/platform_profile_choices quiet balanced balanced-performance performance $ for f in *; do cat $f/name; cat $f/choices; done; lenovo-wmi-gamezone quiet balanced balanced-performance performance custom amd-pmf low-power balanced performance $ echo quiet | sudo tee /sys/firmware/acpi/platform_profile quiet $ for f in *; do cat $f/name; cat $f/profile; done; lenovo-wmi-gamezone quiet amd-pmf quiet $ echo balanced-performance | sudo tee /sys/firmware/acpi/platform_profile balanced-performance $ for f in *; do cat $f/name; cat $f/profile; done; lenovo-wmi-gamezone balanced-performance amd-pmf balanced-performance $ echo low-power | sudo tee /sys/firmware/acpi/platform_profile low-power tee: /sys/firmware/acpi/platform_profile: Operation not supported $ for f in *; do cat $f/name; cat $f/profile; done; lenovo-wmi-gamezone balanced-performance amd-pmf balanced-performance Tested-by: Derek J. Clark <derekjohn.clark@gmail.com>
I just tested this. The behavior of this patch series matches mine 1-1. Feel free to add a tested-by. IMO it is a bit cleaner/thought through than my series, so I am fine with dropping mine. Should be as it is essentially a V3 Antheas On Fri, 28 Feb 2025 at 18:02, Mario Limonciello <superm1@kernel.org> wrote: > > From: Mario Limonciello <mario.limonciello@amd.com> > > When two drivers provide platform profile handlers but use different > strings to mean (essentially) the same thing the legacy interface won't > export them because it only shows profiles common to multiple drivers. > > This causes an unexpected behavior to people who have upgraded from an > earlier kernel because if multiple drivers have bound platform profile > handlers they might not be able to access profiles they were expecting. > > Introduce a concept of a "hidden choice" that drivers can register and > the platform profile handler code will utilize when using the legacy > interface. > > There have been some other attempts at solving this issue in other ways. > This serves as an alternative to those attempts. > > Link: https://lore.kernel.org/platform-driver-x86/e64b771e-3255-42ad-9257-5b8fc6c24ac9@gmx.de/T/#t > Link: https://lore.kernel.org/platform-driver-x86/CAGwozwF-WVEgiAbWbRCiUaXf=BVa3KqmMJfs06trdMQHpTGmjQ@mail.gmail.com/T/#m2f3929e2d4f73cc0eedd14738170dad45232fd18 > Cc: Antheas Kapenekakis <lkml@antheas.dev> > Cc: "Luke D. Jones" <luke@ljones.dev> > > Mario Limonciello (3): > ACPI: platform_profile: Add support for hidden choices > platform/x86/amd: pmf: Add 'quiet' to hidden choices > platform/x86/amd: pmf: Add balanced-performance to hidden choices > > drivers/acpi/platform_profile.c | 94 +++++++++++++++++++++++------- > drivers/platform/x86/amd/pmf/sps.c | 11 ++++ > include/linux/platform_profile.h | 3 + > 3 files changed, 87 insertions(+), 21 deletions(-) > > -- > 2.43.0 >
On 3/1/25 05:09, Antheas Kapenekakis wrote: > I just tested this. The behavior of this patch series matches mine > 1-1. Feel free to add a tested-by. I understand your intent, but can you please explicitly type out your tag? This is especially important because maintainers often use 'b4' to pull all tags out of an email thread when accepting patches. > > IMO it is a bit cleaner/thought through than my series, so I am fine > with dropping mine. Should be as it is essentially a V3 > > <strip> Also; Rafael mentioned this in another thread, but please refrain from top posting when possible [1]. [1] https://www.kernel.org/doc/html/v6.14-rc4/process/submitting-patches.html#use-trimmed-interleaved-replies-in-email-discussions
On Sat, 1 Mar 2025 at 14:44, Mario Limonciello <superm1@kernel.org> wrote: > > On 3/1/25 05:09, Antheas Kapenekakis wrote: > > I just tested this. The behavior of this patch series matches mine > > 1-1. Feel free to add a tested-by. > > I understand your intent, but can you please explicitly type out your > tag? This is especially important because maintainers often use 'b4' to > pull all tags out of an email thread when accepting patches. Tested-by: Antheas Kapenekakis <lkml@antheas.dev> > > > > IMO it is a bit cleaner/thought through than my series, so I am fine > > with dropping mine. Should be as it is essentially a V3 > > > > > > <strip> > > Also; Rafael mentioned this in another thread, but please refrain from > top posting when possible [1]. > > [1] > https://www.kernel.org/doc/html/v6.14-rc4/process/submitting-patches.html#use-trimmed-interleaved-replies-in-email-discussions Ack
From: Mario Limonciello <mario.limonciello@amd.com> When two drivers provide platform profile handlers but use different strings to mean (essentially) the same thing the legacy interface won't export them because it only shows profiles common to multiple drivers. This causes an unexpected behavior to people who have upgraded from an earlier kernel because if multiple drivers have bound platform profile handlers they might not be able to access profiles they were expecting. Introduce a concept of a "hidden choice" that drivers can register and the platform profile handler code will utilize when using the legacy interface. There have been some other attempts at solving this issue in other ways. This serves as an alternative to those attempts. Link: https://lore.kernel.org/platform-driver-x86/e64b771e-3255-42ad-9257-5b8fc6c24ac9@gmx.de/T/#t Link: https://lore.kernel.org/platform-driver-x86/CAGwozwF-WVEgiAbWbRCiUaXf=BVa3KqmMJfs06trdMQHpTGmjQ@mail.gmail.com/T/#m2f3929e2d4f73cc0eedd14738170dad45232fd18 Cc: Antheas Kapenekakis <lkml@antheas.dev> Cc: "Luke D. Jones" <luke@ljones.dev> Mario Limonciello (3): ACPI: platform_profile: Add support for hidden choices platform/x86/amd: pmf: Add 'quiet' to hidden choices platform/x86/amd: pmf: Add balanced-performance to hidden choices drivers/acpi/platform_profile.c | 94 +++++++++++++++++++++++------- drivers/platform/x86/amd/pmf/sps.c | 11 ++++ include/linux/platform_profile.h | 3 + 3 files changed, 87 insertions(+), 21 deletions(-)