linux-kernel - Re: The zero power level of the HID device in kernel 6.12 is not reported from the kernel to the upper layer.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <px5t2iedrrqhcrpdvmu5pznp53d3e5jp55dm72phlsti2rmt4j@rj2pajkavuir>
Date: Fri, 19 Sep 2025 08:04:53 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: José Expósito <jose.exposito89@...il.com>
Cc: 卢国宏 <luguohong@...omi.com>, 
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org, jikos@...nel.org, 
	bentiss@...nel.org, 李鹏 <lipeng43@...omi.com>, 
	Fei1 Jiang 蒋飞 <jiangfei1@...omi.com>, 宋密密 <songmimi@...omi.com>
Subject: Re: The zero power level of the HID device in kernel 6.12 is not
 reported from the kernel to the upper layer.

Hi,

On Fri, Sep 19, 2025 at 10:40:38AM +0200, José Expósito wrote:
> Hi 卢国宏,
> 
> Thanks for reporting this issue.
> 
> In the furure, when reporting bugs, it is prefered to send them to the
> mailing list (linux-input@...r.kernel.org and linux-kernel@...r.kernel.org)
> to discuss them in public.
> 
> Let me forward your email to the mailing list and also CC Dmitry, the
> author of that code, who might help us understand the problem.
> 
> On Tue, Sep 16, 2025 at 12:29:32PM +0000, 卢国宏 wrote:
> > Hi, jose!
> >
> > We encountered a problem where the zero battery level of the HID device
> > in kernel 6.12 was not reported from the kernel to the upper layer.
> > I checked the HID protocol and it doesn't say that there is no need to
> > report the zero power of the HID device. For details, see page 381 of
> > the HID protocol, 31.4 Battery Measures. "Absolute State Of Charge DV
> > The predicted remaining battery capacity expressed as a percentage of
> > design capacity. (Units are %. The value may be greater than 100%.)".
> > However, in the file hid-input.c in kernel 6.12, the following code：
> > 
> > static void hidinput_update_battery(struct hid_device *dev, unsigned int usage,
> >                                     int value)
> > {
> >         int capacity;
> > 
> >         if (!dev->battery)
> >                 return;
> > 
> >         if (hidinput_update_battery_charge_status(dev, usage, value)) {
> >                 power_supply_changed(dev->battery);
> >                 return;
> >         }
> > 
> >         if (value == 0 || value < dev->battery_min || value > dev->battery_max)
> >                 return;
> > 
> >         capacity = hidinput_scale_battery_capacity(dev, value);
> > 
> >          ......
> > 
> > }
> > 
> > The parameter value is the power level. When the value is 0, the above code
> > returns without reporting.
> > Is this a problem?
> > We're currently experiencing this issue on Android 16. The upper layer of
> > Android needs to receive a zero battery level before it can take appropriate
> > action.

What kind of action are we talking about? Section 31 of the HID
specification defines events for "Smart Battery" ("To comply with the
Smart Battery Specification, the Battery System must support the
functions defined in the Battery and Charger usage tables. For details,
see Section 4.2, “Battery System Page (x85).”) and is typically used for
"battery pack for cellular phones (principal source), the battery
pack(s) for notebook computers (auxiliary source), and the sealed
batteries in uninterruptible power supplies (auxiliary source)."

Is your use case main battery or battery in a stylus or some other
peripheral?

> > Could you please help me evaluate whether we should remove the behavior of
> > returning to zero battery?
> >
> > Thanks!
> > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
> 
> It indeed looks like it could be problematic.
> 
> Values are allowed ot be grater than 100, however, I didn't find
> any references to negative values. Since it is a percentage, it
> make sense to limit it to 0%, i.e., not allowing negative values.
> 
> I think that removing the "value == 0" check, or replacing it with
> "value < 0" should fix the issue.

If we are dealing with peripherals (stylus for example) - for which this
piece of code was written - how a battery powered peripheral that is
fully discharged can communicate it's battery state of 0?

I think we have observed bogus reports with 0 values (IIRC trying to
query battery strength when stylus is not in proximity would yield
responses with 0 strength).

Thanks.

-- 
Dmitry