linux-kernel - Re: [PATCH RESEND v7 1/2] hwmon: add GPD devices sensor driver

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: <3bf7df79-7512-4372-9e37-8726d88a8f36@roeck-us.net>
Date: Wed, 3 Sep 2025 06:37:34 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Cryolitia PukNgae <cryolitia@...ontech.com>
Cc: Jean Delvare <jdelvare@...e.com>, Jonathan Corbet <corbet@....net>,
 linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org,
 linux-doc@...r.kernel.org, Celeste Liu <CoelacanthusHex@...il.com>,
 Yao Zi <ziyao@...root.org>, Derek John Clark <derekjohn.clark@...il.com>,
 WangYuli <wangyuli@...ontech.com>, Jun Zhan <zhanjun@...ontech.com>,
 niecheng1@...ontech.com, guanwentao@...ontech.com,
 Marcin Strągowski <marcin@...agowski.com>,
 someone5678 <someone5678.dev@...il.com>,
 Justin Weiss <justin@...tinweiss.com>, Antheas Kapenekakis
 <lkml@...heas.dev>, command_block <mtf@...me>, derjohn <himself@...john.de>,
 Crashdummyy <crashdummy1337@...ton.me>
Subject: Re: [PATCH RESEND v7 1/2] hwmon: add GPD devices sensor driver

On 9/3/25 01:33, Cryolitia PukNgae wrote:
> 
> On 02/09/2025 23.38, Guenter Roeck wrote:
>> On Wed, Aug 20, 2025 at 05:50:38PM +0800, Cryolitia PukNgae wrote:
>>> From: Cryolitia PukNgae <cryolitia@...ontech.com>
>>>
>>> Sensors driver for GPD Handhelds that expose fan reading and control via
>>> hwmon sysfs.
>>>
>>> Shenzhen GPD Technology Co., Ltd. manufactures a series of handheld
>>> devices. This driver implements these functions through x86 port-mapped
>>> IO.
>>>
>>> Signed-off-by: Cryolitia PukNgae <cryolitia@...ontech.com>
>>> ---

>>> +static int gpd_win_mini_set_pwm_enable(enum FAN_PWM_ENABLE pwm_enable)
>>> +{
>>> +	const struct gpd_fan_drvdata *drvdata;
>>> +
>>> +	switch (pwm_enable) {
>>> +	case DISABLE:
>>> +		return gpd_generic_write_pwm(255);
>>> +	case MANUAL:
>>> +		return gpd_generic_write_pwm(gpd_driver_priv.pwm_value);
>> This means setting the enable status to MANUAL will set the pwm
>> speed to the maximum unless a different speed is written first.
>> That includes win_max_2 even if the value was read before.
>> Is this really what is intended ?
> Thank you for raising this important question. After reconsidering the
> design, I believe this approach is indeed intentional and justified for
> this specific hardware platform.
> 
> GPD devices are extremely compact yet high-performance systems, and their
> gaming handheld form factor means they're often subjected to rapidly
> fluctuating workloads. The small thermal mass combined with high heat
> generation creates a scenario where even minor CPU load changes can cause
> temperature spikes of 10+ Kelvin within seconds—as I observed during
> testing when briefly stopping the fan.
> 
> This behavior is designed with a specific safety philosophy: when userspace
> announces it's taking manual control, we assume it has already prepared
> proper thermal monitoring and fan curves. The brief moment of max fan
> speed acts as a safety buffer until userspace writes its first intended
> value—which should happen almost immediately if the userspace controller
> is properly implemented. This prevents any gap in thermal protection or
> frame drops caused by throttling if userspace fails to write a value
> promptly after claiming control.

Please make sure to document this behavior.

Thanks,
Guenter