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: <vkm32giijggtzv7hudsvqg34utpqvw4nnccfi7d4txj5tlzstp@4bu2ox2lmtm5>
Date: Wed, 24 Sep 2025 21:26:24 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: 卢国宏 <luguohong@...omi.com>
Cc: José Expósito <jose.exposito89@...il.com>, 
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"jikos@...nel.org" <jikos@...nel.org>, "bentiss@...nel.org" <bentiss@...nel.org>, 
	李鹏 <lipeng43@...omi.com>, Fei1 Jiang 蒋飞 <jiangfei1@...omi.com>, 
	宋密密 <songmimi@...omi.com>
Subject: Re: 答复: [External Mail]Re: The zero power level of the HID device in kernel 6.12 is not
 reported from the kernel to the upper layer.

On Mon, Sep 22, 2025 at 09:29:20AM +0000, 卢国宏 wrote:
> 
> 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?
> 
> 
> --->>>
> What we are discussing is the code implementation of Section 31 of the
> HID protocol: 31 Battery System Page (0x85). Our scenario is: an
> Android phone is connected to a handle via USB. The handle is a HID
> device with a battery. The power of the battery in the handle is sent
> to the bottom layer (kernel) of the phone via USB. The bottom layer of
> the phone then reports this power to the upper layer of Android
> through the HID driver.

I see. I guess we can try only filtering out 0 reports for the
digitizers, leaving other devices with batteries alone. Something like
this:


diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index ff1784b5c2a4..ba3f6655af9e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -595,14 +595,18 @@ static void hidinput_cleanup_battery(struct hid_device *dev)
 	dev->battery = NULL;
 }
 
-static void hidinput_update_battery(struct hid_device *dev, int value)
+static void hidinput_update_battery(struct hid_device *dev,
+				    unsigned int usage, int value)
 {
 	int capacity;
 
 	if (!dev->battery)
 		return;
 
-	if (value == 0 || value < dev->battery_min || value > dev->battery_max)
+	if ((usage & HID_USAGE_PAGE) == HID_UP_DIGITIZER && value == 0)
+		return;
+
+	if (value < dev->battery_min || value > dev->battery_max)
 		return;
 
 	capacity = hidinput_scale_battery_capacity(dev, value);
@@ -1518,7 +1522,7 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
 		bool handled = hidinput_set_battery_charge_status(hid, usage->hid, value);
 
 		if (!handled)
-			hidinput_update_battery(hid, value);
+			hidinput_update_battery(hid, usage->hid, value);
 
 		return;
 	}


Thanks.

-- 
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ