linux-kernel - Re: [PATCH] hwmon: max34451: Workaround for 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5a602ffc-5cbb-4f39-b815-545f3f1f4c98@roeck-us.net>
Date: Tue, 1 Apr 2025 15:52:01 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: "William A. Kennington III" <william@...nnington.com>,
 Jean Delvare <jdelvare@...e.com>
Cc: linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
 openbmc@...ts.ozlabs.org
Subject: Re: [PATCH] hwmon: max34451: Workaround for lost page

On 4/1/25 15:08, William A. Kennington III wrote:
> When requesting new pages from the max34451 we sometimes see that the
> firmware doesn't update the page on the max34451 side fast enough. This
> results in the kernel receiving data for a different page than what it
> expects.
> 
> To remedy this, the manufacturer recommends we wait 50-100us until
> the firmware should be ready with the new page.
> 
> Signed-off-by: William A. Kennington III <william@...nnington.com>
> ---
>   drivers/hwmon/pmbus/max34440.c | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/hwmon/pmbus/max34440.c b/drivers/hwmon/pmbus/max34440.c
> index c9dda33831ff..ac3a26f7cff3 100644
> --- a/drivers/hwmon/pmbus/max34440.c
> +++ b/drivers/hwmon/pmbus/max34440.c
> @@ -12,6 +12,7 @@
>   #include <linux/init.h>
>   #include <linux/err.h>
>   #include <linux/i2c.h>
> +#include <linux/delay.h>
>   #include "pmbus.h"
>   
>   enum chips { max34440, max34441, max34446, max34451, max34460, max34461 };
> @@ -241,6 +242,12 @@ static int max34451_set_supported_funcs(struct i2c_client *client,
>   		if (rv < 0)
>   			return rv;
>   
> +		/* Firmware is sometimes not ready if we try and read the

This is not the networking subsystem. Standard multi-line comments, please.

> +		 * data from the page immediately after setting. Maxim
> +		 * recommends 50-100us delay.
> +		 */
> +		fsleep(50);

I would suggest to wait 100uS to be safe. The function is only called during probe,
so that should be ok.

Is this a generic problem with this chip when changing pages ?

Thanks,
Guenter