[PATCH v3] platform/x86: thinkpad-acpi: Add error check for tpacpi_check_quirks

[PATCH v3] platform/x86: thinkpad-acpi: Add error check for tpacpi_check_quirks

[Wentao Liang]

In tpacpi_battery_init(), the return value of tpacpi_check_quirks() needs
to be checked. The battery should not be hooked if there is no matched
battery information in quirk table.

Add an error check and return -ENODEV immediately if the device fail
the check.

Fixes: 1a32ebb26ba9 ("platform/x86: thinkpad_acpi: Support battery quirk")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
v3: Fix error code
v2: Fix double assignment error

 drivers/platform/x86/thinkpad_acpi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 2cfb2ac3f465..ab538bf53716 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9974,6 +9974,8 @@ static int __init tpacpi_battery_init(struct ibm_init_struct *ibm)
 	tp_features.battery_force_primary = tpacpi_check_quirks(
 					battery_quirk_table,
 					ARRAY_SIZE(battery_quirk_table));
+	if (!tp_features.battery_force_primary)
+		return -ENODEV;
 
 	battery_hook_register(&battery_hook);
 	return 0;
-- 
2.42.0.windows.2

Re: [PATCH v3] platform/x86: thinkpad-acpi: Add error check for tpacpi_check_quirks

[Kurt Borja]

Hi Wentao,

On Mon Apr 7, 2025 at 10:39 PM -03, Wentao Liang wrote:
> In tpacpi_battery_init(), the return value of tpacpi_check_quirks() needs
> to be checked. The battery should not be hooked if there is no matched
> battery information in quirk table.

Why is this the case? What problem is this fixing?

It seems only a few devices are listed in battery_quirk_table, and the
comment above it suggests it is just a fixup:

	/*
	 * Individual addressing is broken on models that expose the
	 * primary battery as BAT1.
	 */

Furthermore, I looked at uses of this quirk in the code and it's absence
doesn't seem critical.

>
> Add an error check and return -ENODEV immediately if the device fail
> the check.

I bring this up because it has the potential to cause a regression on a
lot of devices.

-- 
 ~ Kurt