linux-kernel - Re: [PATCH v2] hwmon: max34451: Work around lost page

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: <e921d037-9be2-43f1-9469-4f27a0575a60@roeck-us.net>
Date: Thu, 10 Apr 2025 17:11:13 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: "Torreno, Alexis Czezar" <AlexisCzezar.Torreno@...log.com>,
 "William A. Kennington III" <william@...nnington.com>
Cc: Jean Delvare <jdelvare@...e.com>,
 "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] hwmon: max34451: Work around lost page

On 4/10/25 16:59, Torreno, Alexis Czezar wrote:
>>> [External]
>>>
>>> On Mon, Apr 07, 2025 at 06:10:06PM -0700, William A. Kennington III wrote:
>>>> When requesting new pages from the max34451 we sometimes see that
>>>> the firmware responds with stale or bad data to reads that happen
>>>> immediately after a page change. This is due to a lack of clock
>>>> stretching after page changing on the device side when it needs more
>>>> time to complete the operation.
>>>>
>>>> To remedy this, the manufacturer recommends we wait 50us until the
>>>> firmware should be ready with the new page.
>>>>
>>>> Signed-off-by: William A. Kennington III <william@...nnington.com>
>>>
>>> Applied to hwmon-next.
>>>
>>> Alexis: Do you happen to know if the new revision of MAX34451 still
>>> has this problem ? Also, it would be nice to get some feedback if the
>>> patch covers all affected devices.
>>>
>>
>> I unfortunately am not aware of this. Let me see if can get an answer from the
>> engr of the part.
> 
> To follow up, here's the exact response I got.
> 
> - This is not an issue with the part. As the fix mentions, "the manufacturer
> recommends we wait 50us until the firmware should be ready with the new page".
> Compliant with I2C/SMBus spec, some parts require a longer idle time for the
> bus to be free before receiving the next command, in this situation it is normal to
> recommend a longer idle time in between commands. It's more related to the
> part's inner timing and architecture.
> 
> So I guess no specific changes related to this was made for later versions so the
> patch here should cover all.
> 

Ok. Thanks a lot for looking into this!

Guenter