From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: "Jose Villaseñor Montfort" <pepemontfort@gmail.com>,
"Alec Hall" <signshop.alec@gmail.com>,
"Jiri Kosina" <jkosina@suse.com>,
"Sasha Levin" <sashal@kernel.org>
Subject: [PATCH 5.15.y] HID: input: read battery capacity from its actual report offset
Date: Thu, 27 Aug 2026 00:40:12 -0400 [thread overview]
Message-ID: <20260827044012.3636019-1-sashal@kernel.org> (raw)
In-Reply-To: <2026082544-profusely-glaucoma-4d1e@gregkh>
From: Jose Villaseñor Montfort <pepemontfort@gmail.com>
[ Upstream commit d07644524b6511b622ee7b0e2e68c9ee43d522a4 ]
hidinput_query_battery_capacity() assumes the state-of-charge value is
the first byte following the report ID (buf[1]) and ignores where the
battery field actually sits within the report.
An Apple Magic Trackpad 2 precedes the AbsoluteStateOfCharge byte with a
byte of status flags in its battery reports, so this query returns the
flags byte instead of the charge level.
The device happens to make that easy to observe, because it exposes the
same cell twice: its report descriptor declares AbsoluteStateOfCharge in
two reports (0x90 and 0x9b), so hidinput_setup_battery() registers two
power supplies. Only the first one is refreshed by hid-magicmouse -- it
uses hid_get_battery(), which returns the first battery of the list --
and that refresh goes through the report event path, which parses the
field correctly. Nothing ever reports the second one, so every read of
its capacity takes the query path above. On a USB-C Magic Trackpad over
USB, on an unpatched 7.1.5:
hid-<serial>-battery-144 = 100% (Charging) <- report event path
hid-<serial>-battery-155 = 3% (Discharging) <- query path
Both are the same physical battery. A raw HIDIOCGINPUT of the two
reports at that same moment:
report 0x90 -> [90 03 64]
report 0x9b -> [9b 03 64 64 00 00 10 00 00 00 00 00 00 00]
^flags ^SoC = 0x64 = 100%
The device answers correctly in both cases; only the offset the kernel
reads the capacity from is wrong. 0x03 is the flags byte (present,
charging), reported as "3%".
Bluetooth takes the same query path for its capacity, where the trackpad
reported a bogus near-constant ~4% -- 0b100, the FullyCharged flag --
regardless of the real charge.
Store the battery field's offset within the report at setup time and use
it when querying, so the capacity is read from its real position. The
report event path already parses the field correctly through the HID
core; only the explicit GET_REPORT query was wrong.
Devices whose capacity field is the first field in the report have a
report_offset of 0 and are unaffected (buf[1 + 0] == buf[1]).
Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
Cc: stable@vger.kernel.org
Signed-off-by: Jose Villaseñor Montfort <pepemontfort@gmail.com>
Reviewed-by: Alec Hall <signshop.alec@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
[ Adapted `bat->report_offset` and other `struct hid_battery` accessors to the flat `dev->battery_*` fields on `struct hid_device` and replaced `__free(kfree)` with manual `kfree(buf)` calls. ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-input.c | 17 +++++++++++++----
include/linux/hid.h | 1 +
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index d03a447dbe6b8..12b94ea3b64df 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -367,19 +367,27 @@ static int hidinput_query_battery_capacity(struct hid_device *dev)
{
u8 *buf;
int ret;
+ /*
+ * The capacity field may not be the first field in the report: some
+ * devices (e.g. the Apple Magic Trackpad 2 over Bluetooth) precede it
+ * with status flags. Read it from its actual byte offset in the report
+ * (report_offset is in bits; the leading byte is the report id).
+ */
+ int offset = 1 + dev->battery_report_offset / 8;
+ int len = offset + 1;
- buf = kmalloc(4, GFP_KERNEL);
+ buf = kmalloc(max(len, 4), GFP_KERNEL);
if (!buf)
return -ENOMEM;
- ret = hid_hw_raw_request(dev, dev->battery_report_id, buf, 4,
+ ret = hid_hw_raw_request(dev, dev->battery_report_id, buf, max(len, 4),
dev->battery_report_type, HID_REQ_GET_REPORT);
- if (ret < 2) {
+ if (ret < len) {
kfree(buf);
return -ENODATA;
}
- ret = hidinput_scale_battery_capacity(dev, buf[1]);
+ ret = hidinput_scale_battery_capacity(dev, buf[offset]);
kfree(buf);
return ret;
}
@@ -497,6 +505,7 @@ static int hidinput_setup_battery(struct hid_device *dev, unsigned report_type,
dev->battery_max = max;
dev->battery_report_type = report_type;
dev->battery_report_id = field->report->id;
+ dev->battery_report_offset = field->report_offset;
/*
* Stylus is normally not connected to the device and thus we
diff --git a/include/linux/hid.h b/include/linux/hid.h
index a321d4c293a94..515b645f7abc8 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -620,6 +620,7 @@ struct hid_device { /* device report descriptor */
__s32 battery_max;
__s32 battery_report_type;
__s32 battery_report_id;
+ __s32 battery_report_offset; /* bit offset of the capacity field within its report */
enum hid_battery_status battery_status;
bool battery_avoid_query;
ktime_t battery_ratelimit_time;
--
2.53.0
prev parent reply other threads:[~2026-08-27 4:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 13:16 FAILED: patch "[PATCH] HID: input: read battery capacity from its actual report" failed to apply to 5.15-stable tree gregkh
2026-08-27 4:40 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260827044012.3636019-1-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=jkosina@suse.com \
--cc=pepemontfort@gmail.com \
--cc=signshop.alec@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox