linux-kernel - Re: [RFC PATCH v2 4/4] hwmon: (jc42) Don't cache the temperature register

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: <e2fadcfa-aedc-ded4-8867-5f2525852af6@roeck-us.net>
Date:   Thu, 20 Oct 2022 15:37:46 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc:     linux-hwmon@...r.kernel.org, jdelvare@...e.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 4/4] hwmon: (jc42) Don't cache the temperature
 register

On 10/20/22 15:22, Martin Blumenstingl wrote:
> Hi Guenter,
> 
> On Fri, Oct 21, 2022 at 12:14 AM Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> On Thu, Oct 20, 2022 at 11:03:20PM +0200, Martin Blumenstingl wrote:
>>> Now that we're utilizing regmap and it's regcache for the
>>> minimum/maximum/critical temperature registers the only cached register
>>> that's left is the actual temperature register. Drop the custom cache
>>> implementation as it just complicates things.
>>>
>>
>> Ah, you got there eventually. Just combine this patch into the first
>> patch of the series. No need to keep separate patches, especially since
>> a lot of the code changed in patch 1 and 2 is just thrown away here.
> Thanks again for the quick response and for the great feedback. I'll
> combine the patches tomorrow and send a v3!
> 
>> That reminds me, though: Make sure that the alarm bits are not dropped
>> after reading the temperature (running the 'sensors' command with
>> alarms active should do). I have some JC42 chips here and will do the
>> same.
> I configured below ambient high and crit temperatures:
>    jc42-i2c-0-1a
>    Adapter: SMBus PIIX4 adapter port 0 at 0b00
>    temp1:        +35.0°C  (low  =  +0.0°C)                  ALARM (HIGH, CRIT)
>                          (high = +25.0°C, hyst = +25.0°C)
>                          (crit = +30.0°C, hyst = +30.0°C)
> 
> Then I ran "sensors" three times in a row.
> The output of all "sensors" commands is the same, meaning all of them
> show the ALARM (HIGH, CRIT) part.
> 

Excellent!

> Do you want me to mention this somewhere (for example in the
> cover-letter or the new patch #1)?
> 
Yes, please mention it in the cover letter.

Background for the question: Some older sensor chips (granted, typically
20+ years old) tend to reset the alarm status after reading it, only
to set it again after the next measurement cycle.

Thanks,
Guenter