From: Jean Delvare <jdelvare@suse.de>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Hardware Monitoring <linux-hwmon@vger.kernel.org>
Subject: Re: [PATCH] hwmon: (jc42) Strengthen detect function
Date: Mon, 14 Oct 2024 14:12:04 +0200 [thread overview]
Message-ID: <20241014141204.026f4641@endymion.delvare> (raw)
In-Reply-To: <20240630202028.1874325-1-linux@roeck-us.net>
Hi Guenter,
On Sun, 30 Jun 2024 13:20:28 -0700, Guenter Roeck wrote:
> Configuration register bit 5 must read 0 for all JC42.4 compliant chips.
> Several capability register bits must be set for all TSE2004 compliant
> chips. Use that information to strengthen the detect function.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/hwmon/jc42.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/jc42.c b/drivers/hwmon/jc42.c
> index 1180af1b1638..a260cff750a5 100644
> --- a/drivers/hwmon/jc42.c
> +++ b/drivers/hwmon/jc42.c
> @@ -413,7 +413,11 @@ static int jc42_detect(struct i2c_client *client, struct i2c_board_info *info)
> if (cap < 0 || config < 0 || manid < 0 || devid < 0)
> return -ENODEV;
>
> - if ((cap & 0xff00) || (config & 0xf800))
> + if ((cap & 0xff00) || (config & 0xf820))
> + return -ENODEV;
> +
> + if ((devid & TSE2004_DEVID_MASK) == TSE2004_DEVID &&
> + (cap & 0x00e7) != 0x00e7)
> return -ENODEV;
>
> for (i = 0; i < ARRAY_SIZE(jc42_chips); i++) {
I have a user reporting that this change is causing the jc42 driver to
no longer bind to his memory module temperature sensor devices after
updating to kernel v6.11. I asked for a register dump:
0,8 1,9 2,a 3,b 4,c 5,d 6,e 7,f
00: 7f00 0000 0000 0000 0000 6ac2 091b 3022
After swapping the bytes, I see that this is a TSE2004-compliant device
(devid = 0x2230) and the capabilities register reads 0x007f. This
doesn't pass the 0x00e7 mask test you added, as bit 7 isn't set in his
case.
The JEDEC standard indeed says that bit 7 should be set, but apparently
this isn't always the case in the real world.
Also note that I looked at the Renesas TSE2004GB2B0 datasheet and it
shows bit 2 (RANGE) as not always set. The ST STTS2004 datasheet shows
bits 0 (EVENT) and 2 (RANGE) as possibly reading 0. So I wonder how
much we can rely on these capability bits being set in the detect
function. Unfortunately I don't have any TS2004-compliant device at
hand to verify, nor do I own register dumps of such devices. Would it
be OK with you if we relax the check to at least ignore bit 7, and
possibly also bits 0 and 2?
Thanks,
--
Jean Delvare
SUSE L3 Support
next prev parent reply other threads:[~2024-10-14 12:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-30 20:20 [PATCH] hwmon: (jc42) Strengthen detect function Guenter Roeck
2024-10-14 12:12 ` Jean Delvare [this message]
2024-10-14 13:52 ` Guenter Roeck
2024-10-14 14:01 ` Jean Delvare
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=20241014141204.026f4641@endymion.delvare \
--to=jdelvare@suse.de \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux@roeck-us.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