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

[Guenter Roeck]

On 10/20/22 15:22, Martin Blumenstingl wrote:
> Hi Guenter,
>
> On Fri, Oct 21, 2022 at 12:14 AM Guenter Roeck <linux@xxxxxxxxxxxx> 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