linux-kernel - Re: [PATCH v2] hwmon: corsair-psu: add reporting of rail mode via debugfs

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 11 Aug 2022 08:02:26 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Wilken Gottwalt <wilken.gottwalt@...teo.net>
Cc:     linux-kernel@...r.kernel.org, Jean Delvare <jdelvare@...e.com>,
        Jonathan Corbet <corbet@....net>, linux-hwmon@...r.kernel.org
Subject: Re: [PATCH v2] hwmon: corsair-psu: add reporting of rail mode via
 debugfs

On 8/11/22 01:05, Wilken Gottwalt wrote:
> On Wed, 10 Aug 2022 11:21:36 -0700
> Guenter Roeck <linux@...ck-us.net> wrote:
> 
>> On 8/10/22 10:48, Wilken Gottwalt wrote:
>>> On Wed, 10 Aug 2022 10:29:08 -0700
>>> Guenter Roeck <linux@...ck-us.net> wrote:
>>>
>>>> On 8/10/22 09:56, Wilken Gottwalt wrote:
>>>>> On Wed, 10 Aug 2022 09:31:21 -0700
>>>>> Guenter Roeck <linux@...ck-us.net> wrote:
>>>>>
>>>>>> On 8/10/22 06:53, Wilken Gottwalt wrote:
>>>>>>> Add reporting if the PSU is running in single or multi rail mode via
>>>>>>> ocpmode debugfs entry. Also update the documentation accordingly.
>>>>>>>
>>>>>>> Signed-off-by: Wilken Gottwalt <wilken.gottwalt@...teo.net>
>>>>>>> ---
>>>>>>> Changes in v2:
>>>>>>>       - fixed spelling issues in commit message
>>>>>>
>>>>>> You did not address or even provide feedback on my second comment.
>>>>>
>>>>> Oh darn ... sorry, I was quite busy and didn't really pay attention. I will
>>>>> answer the earlier mail and think about it.
>>>>>
>>>>> Though, maybe you can help me with that what keeps me so busy. Would it be okay
>>>>> to use a kthread in a hwmon driver to do sampling (500ms - 10s) in conjunction
>>>>> with HWMON_C_UPDATE_INTERVAL, or is this a strict no-no? I know it is actually
>>>>> used to set a sample/update rate in a sensor (-register), but this USB-HID
>>>>> approach is a pure polling thing. It seems to work quite and enables the driver
>>>>> to collect data quite early in the boot process.
>>>>>
>>>>
>>>> It really depends. Is it _necessary_ ? The pwm-fan driver uses a timer for
>>>> periodic polling, but that is because it has to. We should not do it purely
>>>> for convenience, and from the code I don't immediately see why it would
>>>> be necessary.
>>>
>>> Together with the polling I would add encountered lowest and highest values and
>>> the average of basically all available sensors (kind of session statistics). I
>>> know it is a bit odd, but currently these power supplies are sold again in a
>>> newer version and people really like to use them in their servers/workstations
>>> because of the "realtime" data and this driver. No joke, but I really got
>>> several requests to add this and I must admit I have quite some fun implementing
>>> it.
>>>
>>
>> That is out of scope for a kernel driver. If desired, a user space application
>> should do the polling and calculate statistics such as lowest/highest or averages.
> 
> That is exactly what I told the requesting people. Now it is in the public
> record and I hope that kind of requests go down a bit, at least for pushing
> this in the mainline kernel.
> 

 From Documentation/hwmon/sysfs-interface.rst:

"
All entries (except name) are optional, and should only be created in a
given driver if the chip has the feature.
"

Think about it - having the kernel collect statistics like this would only
make sense if it was added for all drivers, ie in the hwmon core. That would
end up burdening everyone, not just the few people who want it.

Guenter