mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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®