| Message ID | 20240716051612.64842-1-luke@ljones.dev (mailing list archive) |
|---|---|
| Headers | show |
| Series | platform/x86: introduce asus-bioscfg | expand |
Hi Luke, Mario, On 7/16/24 7:16 AM, Luke D. Jones wrote: > This is the first major patch I've ever done with the intention of > introducing a new module, so it's highly likely I've made some mistakes > or misunderstood something. > > TL;DR: > 1. introduce new module to contain bios attributes, using fw_attributes_class > 2. deprecate all possible attributes from asus-wmi that were added ad-hoc > 3. remove those in the next LTS cycle > > The idea for this originates from a conversation with Mario Limonciello > https://lore.kernel.org/platform-driver-x86/371d4109-a3bb-4c3b-802f-4ec27a945c99@amd.com/ > > It is without a doubt much cleaner to use, easier to discover, and the > API is well defined as opposed to the random clutter of attributes I had > been placing in the platform sysfs. This is a bit of a novel use of the fw_attributes_class and I'm not entirely sure of what to think of this. The fw_attributes_class API was designed for (mostly enterprise) x86 machines where it is possible to change all BIOS settings directly from the OS without entering the BIOS. Here some ACPI or WMI function is present to actually enumerate all the BIOS options (which can be set this way) and get there type. IOW there is not a static list of options inside the driver, nor is there special handling in the driver other then handling differences per type. And if a new BIOS version has new options or a different machine model has different options then these are discovered automatically. This new use is quite different from this. Although I do see that at least for the attributes using WMI_STORE_INT() + WMI_SHOW_INT() that there is quite some commonality between some of the attributes. I see how using the existing firmware-attributes class API definition for this, including allow tweaking this with some of the fwupd firmware-attributes class commandline util work Mario did is a useful thing to have. I guess using the firmware-attributes class for this is ok, but this _must_ not be named bioscfg, since the existing hp-bioscfg driver is a "classic" firmware-attributes drivers enumerating all the options through BIOS provided enumeration functions and I want the name to make it clear that this is not that. And the Dell implementation is called dell-wmi-sysman so lets also avoid sysman as name. Maybe call it "asus-bios-tunables" ? And then if Asus actually implements some more classic firmware-attributes enumerable interface we can use "asus-bioscfg" for that. Mario, Ilpo what is your opinion on this ? Regards, Hans
On Tue, 16 Jul 2024, Hans de Goede wrote: > On 7/16/24 7:16 AM, Luke D. Jones wrote: > > This is the first major patch I've ever done with the intention of > > introducing a new module, so it's highly likely I've made some mistakes > > or misunderstood something. > > > > TL;DR: > > 1. introduce new module to contain bios attributes, using fw_attributes_class > > 2. deprecate all possible attributes from asus-wmi that were added ad-hoc > > 3. remove those in the next LTS cycle > > > > The idea for this originates from a conversation with Mario Limonciello > > https://lore.kernel.org/platform-driver-x86/371d4109-a3bb-4c3b-802f-4ec27a945c99@amd.com/ > > > > It is without a doubt much cleaner to use, easier to discover, and the > > API is well defined as opposed to the random clutter of attributes I had > > been placing in the platform sysfs. > > This is a bit of a novel use of the fw_attributes_class and I'm not > entirely sure of what to think of this. > > The fw_attributes_class API was designed for (mostly enterprise) > x86 machines where it is possible to change all BIOS settings directly > from the OS without entering the BIOS. > > Here some ACPI or WMI function is present to actually enumerate all > the BIOS options (which can be set this way) and get there type. > > IOW there is not a static list of options inside the driver, nor > is there special handling in the driver other then handling differences > per type. > > And if a new BIOS version has new options or a different machine model > has different options then these are discovered automatically. > > This new use is quite different from this. Although I do see that > at least for the attributes using WMI_STORE_INT() + WMI_SHOW_INT() > that there is quite some commonality between some of the attributes. > > I see how using the existing firmware-attributes class API definition > for this, including allow tweaking this with some of the fwupd > firmware-attributes class commandline util work Mario did is a useful > thing to have. > > I guess using the firmware-attributes class for this is ok, but > this _must_ not be named bioscfg, since the existing hp-bioscfg > driver is a "classic" firmware-attributes drivers enumerating all > the options through BIOS provided enumeration functions and I want > the name to make it clear that this is not that. And the Dell > implementation is called dell-wmi-sysman so lets also avoid sysman > as name. > > Maybe call it "asus-bios-tunables" ? And then if Asus actually > implements some more classic firmware-attributes enumerable interface > we can use "asus-bioscfg" for that. > > Mario, Ilpo what is your opinion on this ? What you suggested sounds good to me.
On Wed, 17 Jul 2024, at 3:11 AM, Ilpo Järvinen wrote: > On Tue, 16 Jul 2024, Hans de Goede wrote: > > On 7/16/24 7:16 AM, Luke D. Jones wrote: > > > This is the first major patch I've ever done with the intention of > > > introducing a new module, so it's highly likely I've made some mistakes > > > or misunderstood something. > > > > > > TL;DR: > > > 1. introduce new module to contain bios attributes, using fw_attributes_class > > > 2. deprecate all possible attributes from asus-wmi that were added ad-hoc > > > 3. remove those in the next LTS cycle > > > > > > The idea for this originates from a conversation with Mario Limonciello > > > https://lore.kernel.org/platform-driver-x86/371d4109-a3bb-4c3b-802f-4ec27a945c99@amd.com/ > > > > > > It is without a doubt much cleaner to use, easier to discover, and the > > > API is well defined as opposed to the random clutter of attributes I had > > > been placing in the platform sysfs. > > > > This is a bit of a novel use of the fw_attributes_class and I'm not > > entirely sure of what to think of this. > > > > The fw_attributes_class API was designed for (mostly enterprise) > > x86 machines where it is possible to change all BIOS settings directly > > from the OS without entering the BIOS. > > > > Here some ACPI or WMI function is present to actually enumerate all > > the BIOS options (which can be set this way) and get there type. > > > > IOW there is not a static list of options inside the driver, nor > > is there special handling in the driver other then handling differences > > per type. > > > > And if a new BIOS version has new options or a different machine model > > has different options then these are discovered automatically. > > > > This new use is quite different from this. Although I do see that > > at least for the attributes using WMI_STORE_INT() + WMI_SHOW_INT() > > that there is quite some commonality between some of the attributes. > > > > I see how using the existing firmware-attributes class API definition > > for this, including allow tweaking this with some of the fwupd > > firmware-attributes class commandline util work Mario did is a useful > > thing to have. > > > > I guess using the firmware-attributes class for this is ok, but > > this _must_ not be named bioscfg, since the existing hp-bioscfg > > driver is a "classic" firmware-attributes drivers enumerating all > > the options through BIOS provided enumeration functions and I want > > the name to make it clear that this is not that. And the Dell > > implementation is called dell-wmi-sysman so lets also avoid sysman > > as name. > > > > Maybe call it "asus-bios-tunables" ? And then if Asus actually > > implements some more classic firmware-attributes enumerable interface > > we can use "asus-bioscfg" for that. > > > > Mario, Ilpo what is your opinion on this ? > > What you suggested sounds good to me. Thanks guys. I think there might be a few names that could be suitable 1. asus_bios_tuning/tunables 2. asus_fw_tuning/tunables 3. asus_fw_settings 4. asus_armoury I'm shying away from the "tuning/tunables" label since there are also a lot of settings which are just toggles for various features rather than actual tunable things. It makes sense in some contexts at least. Armoury Crate is the software collection that Asus uses for the gaming laptops, and they tend to lump these settings under that label. Personally I'm leaning towards "asus_fw_settings" as it more accurately describes what the module does.
Hi Luke, On 7/17/24 4:34 AM, Luke Jones wrote: > On Wed, 17 Jul 2024, at 3:11 AM, Ilpo Järvinen wrote: >> On Tue, 16 Jul 2024, Hans de Goede wrote: >>> On 7/16/24 7:16 AM, Luke D. Jones wrote: >>>> This is the first major patch I've ever done with the intention of >>>> introducing a new module, so it's highly likely I've made some mistakes >>>> or misunderstood something. >>>> >>>> TL;DR: >>>> 1. introduce new module to contain bios attributes, using fw_attributes_class >>>> 2. deprecate all possible attributes from asus-wmi that were added ad-hoc >>>> 3. remove those in the next LTS cycle >>>> >>>> The idea for this originates from a conversation with Mario Limonciello >>>> https://lore.kernel.org/platform-driver-x86/371d4109-a3bb-4c3b-802f-4ec27a945c99@amd.com/ >>>> >>>> It is without a doubt much cleaner to use, easier to discover, and the >>>> API is well defined as opposed to the random clutter of attributes I had >>>> been placing in the platform sysfs. >>> >>> This is a bit of a novel use of the fw_attributes_class and I'm not >>> entirely sure of what to think of this. >>> >>> The fw_attributes_class API was designed for (mostly enterprise) >>> x86 machines where it is possible to change all BIOS settings directly >>> from the OS without entering the BIOS. >>> >>> Here some ACPI or WMI function is present to actually enumerate all >>> the BIOS options (which can be set this way) and get there type. >>> >>> IOW there is not a static list of options inside the driver, nor >>> is there special handling in the driver other then handling differences >>> per type. >>> >>> And if a new BIOS version has new options or a different machine model >>> has different options then these are discovered automatically. >>> >>> This new use is quite different from this. Although I do see that >>> at least for the attributes using WMI_STORE_INT() + WMI_SHOW_INT() >>> that there is quite some commonality between some of the attributes. >>> >>> I see how using the existing firmware-attributes class API definition >>> for this, including allow tweaking this with some of the fwupd >>> firmware-attributes class commandline util work Mario did is a useful >>> thing to have. >>> >>> I guess using the firmware-attributes class for this is ok, but >>> this _must_ not be named bioscfg, since the existing hp-bioscfg >>> driver is a "classic" firmware-attributes drivers enumerating all >>> the options through BIOS provided enumeration functions and I want >>> the name to make it clear that this is not that. And the Dell >>> implementation is called dell-wmi-sysman so lets also avoid sysman >>> as name. >>> >>> Maybe call it "asus-bios-tunables" ? And then if Asus actually >>> implements some more classic firmware-attributes enumerable interface >>> we can use "asus-bioscfg" for that. >>> >>> Mario, Ilpo what is your opinion on this ? >> >> What you suggested sounds good to me. > > Thanks guys. I think there might be a few names that could be suitable > > 1. asus_bios_tuning/tunables > 2. asus_fw_tuning/tunables > 3. asus_fw_settings > 4. asus_armoury > > I'm shying away from the "tuning/tunables" label since there are also a lot of settings which are just toggles for various features rather than actual tunable things. It makes sense in some contexts at least. > > Armoury Crate is the software collection that Asus uses for the gaming laptops, and they tend to lump these settings under that label. > > Personally I'm leaning towards "asus_fw_settings" as it more accurately describes what the module does. "asus_fw_settings" sounds good to me. I'm looking forward to v2 of this series. Regards, Hans
On Tue, 6 Aug 2024, at 3:18 AM, Hans de Goede wrote: > Hi Luke, > > On 7/17/24 4:34 AM, Luke Jones wrote: > > On Wed, 17 Jul 2024, at 3:11 AM, Ilpo Järvinen wrote: > >> On Tue, 16 Jul 2024, Hans de Goede wrote: > >>> On 7/16/24 7:16 AM, Luke D. Jones wrote: > >>>> This is the first major patch I've ever done with the intention of > >>>> introducing a new module, so it's highly likely I've made some mistakes > >>>> or misunderstood something. > >>>> > >>>> TL;DR: > >>>> 1. introduce new module to contain bios attributes, using fw_attributes_class > >>>> 2. deprecate all possible attributes from asus-wmi that were added ad-hoc > >>>> 3. remove those in the next LTS cycle > >>>> > >>>> The idea for this originates from a conversation with Mario Limonciello > >>>> https://lore.kernel.org/platform-driver-x86/371d4109-a3bb-4c3b-802f-4ec27a945c99@amd.com/ > >>>> > >>>> It is without a doubt much cleaner to use, easier to discover, and the > >>>> API is well defined as opposed to the random clutter of attributes I had > >>>> been placing in the platform sysfs. > >>> > >>> This is a bit of a novel use of the fw_attributes_class and I'm not > >>> entirely sure of what to think of this. > >>> > >>> The fw_attributes_class API was designed for (mostly enterprise) > >>> x86 machines where it is possible to change all BIOS settings directly > >>> from the OS without entering the BIOS. > >>> > >>> Here some ACPI or WMI function is present to actually enumerate all > >>> the BIOS options (which can be set this way) and get there type. > >>> > >>> IOW there is not a static list of options inside the driver, nor > >>> is there special handling in the driver other then handling differences > >>> per type. > >>> > >>> And if a new BIOS version has new options or a different machine model > >>> has different options then these are discovered automatically. > >>> > >>> This new use is quite different from this. Although I do see that > >>> at least for the attributes using WMI_STORE_INT() + WMI_SHOW_INT() > >>> that there is quite some commonality between some of the attributes. > >>> > >>> I see how using the existing firmware-attributes class API definition > >>> for this, including allow tweaking this with some of the fwupd > >>> firmware-attributes class commandline util work Mario did is a useful > >>> thing to have. > >>> > >>> I guess using the firmware-attributes class for this is ok, but > >>> this _must_ not be named bioscfg, since the existing hp-bioscfg > >>> driver is a "classic" firmware-attributes drivers enumerating all > >>> the options through BIOS provided enumeration functions and I want > >>> the name to make it clear that this is not that. And the Dell > >>> implementation is called dell-wmi-sysman so lets also avoid sysman > >>> as name. > >>> > >>> Maybe call it "asus-bios-tunables" ? And then if Asus actually > >>> implements some more classic firmware-attributes enumerable interface > >>> we can use "asus-bioscfg" for that. > >>> > >>> Mario, Ilpo what is your opinion on this ? > >> > >> What you suggested sounds good to me. > > > > Thanks guys. I think there might be a few names that could be suitable > > > > 1. asus_bios_tuning/tunables > > 2. asus_fw_tuning/tunables > > 3. asus_fw_settings > > 4. asus_armoury > > > > I'm shying away from the "tuning/tunables" label since there are also a lot of settings which are just toggles for various features rather than actual tunable things. It makes sense in some contexts at least. > > > > Armoury Crate is the software collection that Asus uses for the gaming laptops, and they tend to lump these settings under that label. > > > > Personally I'm leaning towards "asus_fw_settings" as it more accurately describes what the module does. > > "asus_fw_settings" sounds good to me. I'm looking forward to v2 of this series. I've actually done a poll on my discord, folks voted overwhelmingly for `asus-armoury` and I went with this before your response. The reasoning here is that many of these users are coming from windows where Armoury Crate is an app that exposes all the same functions and so that's what they look for on linux. If you don't think this is suitable I'm happy to change. > Regards, > > Hans > > >
Hi, On 8/5/24 11:41 PM, Luke Jones wrote: > On Tue, 6 Aug 2024, at 3:18 AM, Hans de Goede wrote: >> Hi Luke, >> >> On 7/17/24 4:34 AM, Luke Jones wrote: >>> On Wed, 17 Jul 2024, at 3:11 AM, Ilpo Järvinen wrote: >>>> On Tue, 16 Jul 2024, Hans de Goede wrote: >>>>> On 7/16/24 7:16 AM, Luke D. Jones wrote: >>>>>> This is the first major patch I've ever done with the intention of >>>>>> introducing a new module, so it's highly likely I've made some mistakes >>>>>> or misunderstood something. >>>>>> >>>>>> TL;DR: >>>>>> 1. introduce new module to contain bios attributes, using fw_attributes_class >>>>>> 2. deprecate all possible attributes from asus-wmi that were added ad-hoc >>>>>> 3. remove those in the next LTS cycle >>>>>> >>>>>> The idea for this originates from a conversation with Mario Limonciello >>>>>> https://lore.kernel.org/platform-driver-x86/371d4109-a3bb-4c3b-802f-4ec27a945c99@amd.com/ >>>>>> >>>>>> It is without a doubt much cleaner to use, easier to discover, and the >>>>>> API is well defined as opposed to the random clutter of attributes I had >>>>>> been placing in the platform sysfs. >>>>> >>>>> This is a bit of a novel use of the fw_attributes_class and I'm not >>>>> entirely sure of what to think of this. >>>>> >>>>> The fw_attributes_class API was designed for (mostly enterprise) >>>>> x86 machines where it is possible to change all BIOS settings directly >>>>> from the OS without entering the BIOS. >>>>> >>>>> Here some ACPI or WMI function is present to actually enumerate all >>>>> the BIOS options (which can be set this way) and get there type. >>>>> >>>>> IOW there is not a static list of options inside the driver, nor >>>>> is there special handling in the driver other then handling differences >>>>> per type. >>>>> >>>>> And if a new BIOS version has new options or a different machine model >>>>> has different options then these are discovered automatically. >>>>> >>>>> This new use is quite different from this. Although I do see that >>>>> at least for the attributes using WMI_STORE_INT() + WMI_SHOW_INT() >>>>> that there is quite some commonality between some of the attributes. >>>>> >>>>> I see how using the existing firmware-attributes class API definition >>>>> for this, including allow tweaking this with some of the fwupd >>>>> firmware-attributes class commandline util work Mario did is a useful >>>>> thing to have. >>>>> >>>>> I guess using the firmware-attributes class for this is ok, but >>>>> this _must_ not be named bioscfg, since the existing hp-bioscfg >>>>> driver is a "classic" firmware-attributes drivers enumerating all >>>>> the options through BIOS provided enumeration functions and I want >>>>> the name to make it clear that this is not that. And the Dell >>>>> implementation is called dell-wmi-sysman so lets also avoid sysman >>>>> as name. >>>>> >>>>> Maybe call it "asus-bios-tunables" ? And then if Asus actually >>>>> implements some more classic firmware-attributes enumerable interface >>>>> we can use "asus-bioscfg" for that. >>>>> >>>>> Mario, Ilpo what is your opinion on this ? >>>> >>>> What you suggested sounds good to me. >>> >>> Thanks guys. I think there might be a few names that could be suitable >>> >>> 1. asus_bios_tuning/tunables >>> 2. asus_fw_tuning/tunables >>> 3. asus_fw_settings >>> 4. asus_armoury >>> >>> I'm shying away from the "tuning/tunables" label since there are also a lot of settings which are just toggles for various features rather than actual tunable things. It makes sense in some contexts at least. >>> >>> Armoury Crate is the software collection that Asus uses for the gaming laptops, and they tend to lump these settings under that label. >>> >>> Personally I'm leaning towards "asus_fw_settings" as it more accurately describes what the module does. >> >> "asus_fw_settings" sounds good to me. I'm looking forward to v2 of this series. > > I've actually done a poll on my discord, folks voted overwhelmingly for `asus-armoury` and I went with this before your response. The reasoning here is that many of these users are coming from windows where Armoury Crate is an app that exposes all the same functions and so that's what they look for on linux. > > If you don't think this is suitable I'm happy to change. asus-armoury works for me, I like that that name makes it clear that this is not changing BIOS settings like other firmware_attributes class devices are doing. So asus-armoury it is. Regards, Hans > >> Regards, >> >> Hans >> >> >> >
On 8/6/2024 04:34, Hans de Goede wrote: > Hi, > > On 8/5/24 11:41 PM, Luke Jones wrote: >> On Tue, 6 Aug 2024, at 3:18 AM, Hans de Goede wrote: >>> Hi Luke, >>> >>> On 7/17/24 4:34 AM, Luke Jones wrote: >>>> On Wed, 17 Jul 2024, at 3:11 AM, Ilpo Järvinen wrote: >>>>> On Tue, 16 Jul 2024, Hans de Goede wrote: >>>>>> On 7/16/24 7:16 AM, Luke D. Jones wrote: >>>>>>> This is the first major patch I've ever done with the intention of >>>>>>> introducing a new module, so it's highly likely I've made some mistakes >>>>>>> or misunderstood something. >>>>>>> >>>>>>> TL;DR: >>>>>>> 1. introduce new module to contain bios attributes, using fw_attributes_class >>>>>>> 2. deprecate all possible attributes from asus-wmi that were added ad-hoc >>>>>>> 3. remove those in the next LTS cycle >>>>>>> >>>>>>> The idea for this originates from a conversation with Mario Limonciello >>>>>>> https://lore.kernel.org/platform-driver-x86/371d4109-a3bb-4c3b-802f-4ec27a945c99@amd.com/ >>>>>>> >>>>>>> It is without a doubt much cleaner to use, easier to discover, and the >>>>>>> API is well defined as opposed to the random clutter of attributes I had >>>>>>> been placing in the platform sysfs. >>>>>> >>>>>> This is a bit of a novel use of the fw_attributes_class and I'm not >>>>>> entirely sure of what to think of this. >>>>>> >>>>>> The fw_attributes_class API was designed for (mostly enterprise) >>>>>> x86 machines where it is possible to change all BIOS settings directly >>>>>> from the OS without entering the BIOS. >>>>>> >>>>>> Here some ACPI or WMI function is present to actually enumerate all >>>>>> the BIOS options (which can be set this way) and get there type. >>>>>> >>>>>> IOW there is not a static list of options inside the driver, nor >>>>>> is there special handling in the driver other then handling differences >>>>>> per type. >>>>>> >>>>>> And if a new BIOS version has new options or a different machine model >>>>>> has different options then these are discovered automatically. >>>>>> >>>>>> This new use is quite different from this. Although I do see that >>>>>> at least for the attributes using WMI_STORE_INT() + WMI_SHOW_INT() >>>>>> that there is quite some commonality between some of the attributes. >>>>>> >>>>>> I see how using the existing firmware-attributes class API definition >>>>>> for this, including allow tweaking this with some of the fwupd >>>>>> firmware-attributes class commandline util work Mario did is a useful >>>>>> thing to have. >>>>>> >>>>>> I guess using the firmware-attributes class for this is ok, but >>>>>> this _must_ not be named bioscfg, since the existing hp-bioscfg >>>>>> driver is a "classic" firmware-attributes drivers enumerating all >>>>>> the options through BIOS provided enumeration functions and I want >>>>>> the name to make it clear that this is not that. And the Dell >>>>>> implementation is called dell-wmi-sysman so lets also avoid sysman >>>>>> as name. >>>>>> >>>>>> Maybe call it "asus-bios-tunables" ? And then if Asus actually >>>>>> implements some more classic firmware-attributes enumerable interface >>>>>> we can use "asus-bioscfg" for that. >>>>>> >>>>>> Mario, Ilpo what is your opinion on this ? >>>>> >>>>> What you suggested sounds good to me. >>>> >>>> Thanks guys. I think there might be a few names that could be suitable >>>> >>>> 1. asus_bios_tuning/tunables >>>> 2. asus_fw_tuning/tunables >>>> 3. asus_fw_settings >>>> 4. asus_armoury >>>> >>>> I'm shying away from the "tuning/tunables" label since there are also a lot of settings which are just toggles for various features rather than actual tunable things. It makes sense in some contexts at least. >>>> >>>> Armoury Crate is the software collection that Asus uses for the gaming laptops, and they tend to lump these settings under that label. >>>> >>>> Personally I'm leaning towards "asus_fw_settings" as it more accurately describes what the module does. >>> >>> "asus_fw_settings" sounds good to me. I'm looking forward to v2 of this series. >> >> I've actually done a poll on my discord, folks voted overwhelmingly for `asus-armoury` and I went with this before your response. The reasoning here is that many of these users are coming from windows where Armoury Crate is an app that exposes all the same functions and so that's what they look for on linux. >> >> If you don't think this is suitable I'm happy to change. > > asus-armoury works for me, I like that that name makes it clear that this > is not changing BIOS settings like other firmware_attributes class devices > are doing. > > So asus-armoury it is. > I have been OOO so I'm late to the party, but yes I agree with adding a prefix and the proposal for asus-armoury makes sense to me. And I had suggested Luke in this direction of this API in use by this series with fwupd's use of BIOS settings on other laptops in mind. It feels like a really good pairing to me. Luke also mentioned to me (and maybe somewhere else in this patch series?) that the ASUS tools will be converted to use this interface. I think standardized interfaces are the way to go, and that way if we ever end up with GNOME or KDE GUI that changes firmware settings we cover all the laptops and handhelds at the exact same time.
This is the first major patch I've ever done with the intention of introducing a new module, so it's highly likely I've made some mistakes or misunderstood something. TL;DR: 1. introduce new module to contain bios attributes, using fw_attributes_class 2. deprecate all possible attributes from asus-wmi that were added ad-hoc 3. remove those in the next LTS cycle The idea for this originates from a conversation with Mario Limonciello https://lore.kernel.org/platform-driver-x86/371d4109-a3bb-4c3b-802f-4ec27a945c99@amd.com/ It is without a doubt much cleaner to use, easier to discover, and the API is well defined as opposed to the random clutter of attributes I had been placing in the platform sysfs. The review of this patch series will also affect my next patch set which is for the ROG Ally (2k LOC) as I've used a similar strategy for the macros to reduce LOC as much as possible. In regards to *this* patch series though, I think the critical areas might be the use of the mutex, the macros, possibly the way I've setup the module to load/depend on asus-wmi (I had to read other code to try and define the way). I am unsure of how best to handle the deprecation of attributes. There's also some attributes that are obviously boolean but are using 0/1. I'm unsure if I should change that. And would it be best to move the asus stuff to a subdir now? Akin to the Dell platform stuff. All guidance deeply appreciated to get this over the line. Regards, Luke Luke D. Jones (5): platform/x86 asus-bioscfg: move existing tunings to asus-bioscfg module platform/x86: asus-bioscfg: add dgpu tgp control platform/x86: asus-bioscfg: add apu-mem control support platform/x86: asus-bios: add core count control asus-wmi: deprecate bios features .../ABI/testing/sysfs-platform-asus-wmi | 17 + drivers/platform/x86/Kconfig | 22 + drivers/platform/x86/Makefile | 1 + drivers/platform/x86/asus-bioscfg.c | 997 ++++++++++++++++++ drivers/platform/x86/asus-bioscfg.h | 302 ++++++ drivers/platform/x86/asus-wmi.c | 144 ++- include/linux/platform_data/x86/asus-wmi.h | 19 + 7 files changed, 1473 insertions(+), 29 deletions(-) create mode 100644 drivers/platform/x86/asus-bioscfg.c create mode 100644 drivers/platform/x86/asus-bioscfg.h