From: Guenter Roeck <linux@roeck-us.net>
To: Wilken Gottwalt <wilken.gottwalt@posteo.net>
Cc: linux-kernel@vger.kernel.org, Jean Delvare <jdelvare@suse.com>,
Jonathan Corbet <corbet@lwn.net>,
linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v2] hwmon: corsair-psu: add support for critical values
Date: Tue, 16 Mar 2021 13:06:48 -0700 [thread overview]
Message-ID: <3141c950-7764-4285-0e60-eef093ba3513@roeck-us.net> (raw)
In-Reply-To: <20210316152150.5a712927@monster.powergraphx.local>
On 3/16/21 7:21 AM, Wilken Gottwalt wrote:
> On Mon, 15 Mar 2021 11:00:53 -0700
> Guenter Roeck <linux@roeck-us.net> wrote:
>
>> On 3/15/21 9:55 AM, Wilken Gottwalt wrote:
>>> On Mon, 15 Mar 2021 08:53:25 -0700
>>> Guenter Roeck <linux@roeck-us.net> wrote:
>>>
>>>> On 3/15/21 8:02 AM, Wilken Gottwalt wrote:
>>>>> Adds support for reading the critical values of the temperature sensors
>>>>> and the rail sensors (voltage and current) once and caches them. Updates
>>>>> the naming of the constants following a more clear scheme. Also updates
>>>>> the documentation and fixes a typo.
>>>>>
>>>>> The new sensors output of a Corsair HX850i will look like this:
>>>>> corsairpsu-hid-3-1
>>>>> Adapter: HID adapter
>>>>> v_in: 230.00 V
>>>>> v_out +12v: 12.14 V (crit min = +8.41 V, crit max = +15.59 V)
>>>>> v_out +5v: 5.03 V (crit min = +3.50 V, crit max = +6.50 V)
>>>>> v_out +3.3v: 3.30 V (crit min = +2.31 V, crit max = +4.30 V)
>>>>> psu fan: 0 RPM
>>>>> vrm temp: +46.2°C (crit = +70.0°C)
>>>>> case temp: +39.8°C (crit = +70.0°C)
>>>>> power total: 152.00 W
>>>>> power +12v: 108.00 W
>>>>> power +5v: 41.00 W
>>>>> power +3.3v: 5.00 W
>>>>> curr in: N/A
>>>>
>>>> What does that mean ? If it isn't supported by the power supply,
>>>> should we drop that entirely ? Maybe drop it via the is_visible
>>>> function if it is available for some variants, but always displaying
>>>> N/A doesn't add value.
>>>>
>>>> This is a bit odd, though, since I would assume it translates
>>>> to the PSU_CMD_IN_AMPS command. Any chance to track down what is
>>>> happening here ?
>>>
>>> I have one of the earliest PSUs of this series, it is just not supported on
>>> mine. I'm not sure if it would be worth the trouble to catch that and turn
>>> it off dynamically.
>>>
>>
>> I think so, because otherwise we'll get complaints about it (people
>> are really picky abut such things lately). Better not display it at all
>> if it is not supported on a given PSU version. This should be relatively
>> easy to catch in the is_visible function.
>
> So do you have any idea how to do it? The PSU does not tell you what is
> supported or not, you only find out by running the commands. I mean the
> only thing I think of is like I did it for the critical values, but only
> keeping the *_support bits. But if I do it that way, I actually should do
> it for all the commands. This is the point which I ment with "worth the
> trouble."
>
It is not really necessary to do it for all commands; only for those known
to not be supported on all power supplies.
>> Nice PS, anyway. Too bad it is so expensive (and large). Do you know
>> if the HX750i uses the same protocol ?
>
> All HX_num_i and RM_num_i PSUs support the same protocol. There are only
> small differences in supported commands based on release version. What do
> you mean by "large"? The size of the case? All HXi and RMi should have
> the same size (standard ATX). Maybe you looked at one of the AXi series,
They don't fit into my small mini-ATX chassis, and the "i" series all
seem to be full-size ATX.
[ ... ]
>>
>> Making the code less readable to meet a line limit isn't really that desirable.
>> If you want to stick with one line, you could drop the "hwmon_" from function prefixes
>> instead. Those don't really add any value.
>
> I know I know, it's a personal taste. I really dislike splitting functions
> headers about serveral lines, especially if indenting is tab based.
>
Fortunately you can get there by dropping 'hwmon_' from the function names.
Thanks,
Guenter
prev parent reply other threads:[~2021-03-16 20:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 15:02 Wilken Gottwalt
2021-03-15 15:53 ` Guenter Roeck
2021-03-15 16:55 ` Wilken Gottwalt
2021-03-15 18:00 ` Guenter Roeck
2021-03-16 14:21 ` Wilken Gottwalt
2021-03-16 20:06 ` Guenter Roeck [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3141c950-7764-4285-0e60-eef093ba3513@roeck-us.net \
--to=linux@roeck-us.net \
--cc=corbet@lwn.net \
--cc=jdelvare@suse.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wilken.gottwalt@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®