Re: [PATCH] platform/x86: bitland-mifs-wmi: Fix profile handling on Redmi Book Pro 14 2022

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

On Fri, 25 Sep 2026, TuteMthCD wrote:

> On the TIMI Redmi Book Pro 14 2022 (board TM2107), the firmware returns
> the current platform profile at byte offset 2 of the WMI response.
> The driver instead reads offset 4, which remains zero in the observed
> responses. Consequently, profile reads report balanced even after
> selecting another mode.
> 
> The generic performance capability check also requires a barrel-jack
> power supply. This blocks performance selection on this USB-C-only
> machine.
> 
> Add an exact DMI match for this model to read the profile from offset 2
> and require external power without the barrel-jack restriction.
> 
> Tested on physical Redmi Book Pro 14 2022 hardware (TM2107),
> BIOS RMARB4B0P1010, running Linux 7.2.6-zen2-1-zen.
> 
> Assisted-by: Codex:GPT-6
> Signed-off-by: TuteMthCD <matias.civadda2342001@gmail.com>

Please see Documentation/process/submitting-patches.rst for how to 
properly sign off your submissions and what it means.

> ---
>  drivers/platform/x86/bitland-mifs-wmi.c | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/bitland-mifs-wmi.c b/drivers/platform/x86/bitland-mifs-wmi.c
> index 3a373184519d..c132902bc5f8 100644
> --- a/drivers/platform/x86/bitland-mifs-wmi.c
> +++ b/drivers/platform/x86/bitland-mifs-wmi.c
> @@ -14,6 +14,7 @@
>  #include <linux/dev_printk.h>
>  #include <linux/device.h>
>  #include <linux/device/devres.h>
> +#include <linux/dmi.h>
>  #include <linux/err.h>
>  #include <linux/hwmon.h>
>  #include <linux/init.h>
> @@ -38,6 +39,17 @@
>  #define BITLAND_MIFS_GUID	"B60BFB48-3E5B-49E4-A0E9-8CFFE1B3434B"
>  #define BITLAND_EVENT_GUID	"46C93E13-EE9B-4262-8488-563BCA757FEF"
>  
> +static const struct dmi_system_id bitland_tm2107_table[] = {
> +	{
> +		.matches = {
> +			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "TIMI"),
> +			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Redmi Book Pro 14 2022"),
> +			DMI_EXACT_MATCH(DMI_BOARD_NAME, "TM2107"),
> +		},
> +	},
> +	{}
> +};
> +
>  enum bitland_mifs_operation {
>  	WMI_METHOD_GET	= 250,
>  	WMI_METHOD_SET	= 251,
> @@ -195,13 +207,18 @@ static int laptop_profile_get(struct device *dev,
>  		.function = WMI_FN_SYSTEM_PER_MODE,
>  	};
>  	struct bitland_mifs_output result;
> +	u8 mode;
>  	int ret;
>  
>  	ret = bitland_mifs_wmi_call(data, &input, &result);
>  	if (ret)
>  		return ret;
>  
> -	switch (result.data[0]) {
> +	/* TM2107 returns the profile in byte 2 instead of byte 4. */
> +	mode = dmi_check_system(bitland_tm2107_table) ?
> +		result.reserved2 : result.data[0];

You claimed above you tested this patch but how is that possible as this 
patch will not even compile???

Did AI just make up the claim you've tested the patch? Letting AI make 
claims on your behalf that you did things which are not true is misusing 
community's goodwill and trust, and totally unwanted behavior! Please 
don't do that again.

Next time, please properly test the very patch you're sending and review 
it yourself before hitting the send button. Do not mindlessly send patches 
that are AI generated, we don't want unfiltered AI output to be sent to 
us.

In addition, any patch you're submitting to platform drivers list should 
be based on top of for-next or review-ilpo-next branch in the pdx86 repo, 
not some random other tree (if that's the explanation for the 
inconsistencies here).

> +
> +	switch (mode) {
>  	case WMI_PP_BALANCED:
>  		*profile = PLATFORM_PROFILE_BALANCED;
>  		break;
> @@ -229,6 +246,10 @@ static int bitland_check_performance_capability(struct bitland_mifs_wmi_data *da
>  	struct bitland_mifs_output output;
>  	int ret;
>  
> +	/* TM2107 only requires external power, including USB-C. */
> +	if (dmi_check_system(bitland_tm2107_table))
> +		return power_supply_is_system_supplied() > 0 ? 0 : -EOPNOTSUPP;
> +
>  	/* Full-speed/performance mode requires DC power (not USB-C) */
>  	if (!power_supply_is_system_supplied())
>  		return -EOPNOTSUPP;
> 
Variations like the ones you have in this patch should be covered using a 
struct in .driver_data in a generic dmi table, not some device specific 
table.

You probably should also add depends on DMI.

-- 
 i.