linux-kernel - Re: [PATCH v6 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <B751D49737DD10DC+00a0ff95-476a-4d0a-9bc6-40e77012a554@uniontech.com>
Date: Wed, 30 Jul 2025 17:24:29 +0800
From: Cryolitia <liziyao@...ontech.com>
To: Antheas Kapenekakis <lkml@...heas.dev>, Guenter Roeck <linux@...ck-us.net>
Cc: Cryolitia@...il.com, 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>,
 Marcin Strągowski <marcin@...agowski.com>,
 someone5678 <someone5678.dev@...il.com>,
 Justin Weiss <justin@...tinweiss.com>, command_block <mtf@...me>
Subject: Re: [PATCH v6 1/2] hwmon: add GPD devices sensor driver

Thank you for raising this valid concern. We've closely monitored GPD's
development plans and currently see no indication of EC functionality
expansion beyond thermal sensors in the foreseeable future. Given this
observation, we believe placing the driver in hwmon remains appropriate
for now.

That said, we fully respect your maintainer perspective on
future-proofing. If you feel strongly that platform/x86 would be a safer
long-term home despite the current scope, we're happy to move the driver
there immediately. We're committed to finding the most sustainable
solution for upstream.

------
Apologies for mistakenly replying to Antheas Kapenekakis instead of the 
mailing list.

I am Cryolitia <cryolitia@...il.com> that previously sending the patch. 
Due to work, I changed my email address. GPG can verify it's the same 
person: 
https://keyserver.ubuntu.com/pks/lookup?op=vindex&search=0x84dd0c0130a54df7
------

在 2025/7/19 00:38, Antheas Kapenekakis 写道:
> On Thu, 17 Jul 2025 at 04:32, Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> On 3/13/25 13:58, Antheas Kapenekakis wrote:
>>> On Thu, 13 Mar 2025 at 21:10, Cryolitia PukNgae via B4 Relay
>>> <devnull+Cryolitia.gmail.com@...nel.org> wrote:
>>>>
>>>> From: Cryolitia PukNgae <Cryolitia@...il.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@...il.com>
>>>> ---
>>>>    MAINTAINERS             |   6 +
>>>>    drivers/hwmon/Kconfig   |  10 +
>>>>    drivers/hwmon/Makefile  |   1 +
>>>>    drivers/hwmon/gpd-fan.c | 681 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>    4 files changed, 698 insertions(+)
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 0fa7c5728f1e64d031f4a47b6fce1db484ce0fc2..777ba74ccb07ccc0840c3cd34e7b4d98d726f964 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -9762,6 +9762,12 @@ F:       drivers/phy/samsung/phy-gs101-ufs.c
>>>>    F:     include/dt-bindings/clock/google,gs101.h
>>>>    K:     [gG]oogle.?[tT]ensor
>>>>
>>>> +GPD FAN DRIVER
>>>> +M:     Cryolitia PukNgae <Cryolitia@...il.com>
>>>> +L:     linux-hwmon@...r.kernel.org
>>>> +S:     Maintained
>>>> +F:     drivers/hwmon/gpd-fan.c
>>>
>>> A problem we had with oxp sensors is that once OneXPlayer expanded
>>> their EC to include e.g., battery capacity limits, it was no longer
>>> appropriate for it to reside in hwmon. I expect GPD to do the same
>>> sometime in the near future. If that is the case, should we
>>> futureproof the driver by moving it to platform-x86 right away?
>>>
>>
>> My problem with platform drivers, especially with x86 platform drivers,
>> including the OneXPlayer driver, is that the developers responsible for
>> those drivers refrain from implementing the client drivers as auxiliary
>> drivers but instead like to bundle everything into a non-subsystem
>> directory. I have always wondered why that is the case. My best guess
>> is that it is to limit and/or avoid subsystem maintainer oversight.
>> Does that work out for you ?
> 
> Particularly for simple ECs such as OneXPlayer and GPD boards I think
> keeping all the addresses in the same file makes sense. E.g., I just
> sent a Fixes for the OneXPlayer G1 AMD variant and it was one commit
> instead of 2 or 3. At least for me it was practical, I did not
> consider having a lesser oversight as a benefit when making that
> choice.
> 
> But I do understand the concern.
> 
> Antheas
> 
>> Not objecting, I am just curious.
>>
>> Guenter
>>
>>
>