On Mon, 14 Oct 2024 06:52:45 -0700, Guenter Roeck wrote: > On 10/14/24 05:12, Jean Delvare wrote: > > 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? > > Sigh. I guess it would have been a miracle if vendors followed the standard. > Let's ignore all three bits, with explanation. Care to send a patch, or do > you want me to do it ? Working on it, I'll submit it later today. Thanks, -- Jean Delvare SUSE L3 Support
