[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <MN2PR02MB67038B3F8DF699BD0C462C458D780@MN2PR02MB6703.namprd02.prod.outlook.com>
Date: Thu, 7 Nov 2019 06:18:01 +0000
From: Rain Wang <Rain_Wang@...il.com>
To: Guenter Roeck <linux@...ck-us.net>, Jean Delvare <jdelvare@...e.de>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>
Subject: Re: [PATCH] lm75: add lm75b detection
Sorry for my late reply,
>FWIW, I don't think there is anything to implement; I don't see any
>differences in functionality.
Yes, no functional difference but the detection
>I am much more concerned about weakening the already weak detection even further:
>As written, each chip with register 0x07 != 0xa1 will be identified as LM75B.
>Even if that was strengthened to actually check if the register value is 0xff,
>we have no idea what other vendors might implement in those registers. it would
>most certainly mis-identify LM75C as LM75B. Not that it really matters if
>the chip _is_ a LM75C, but who knows if other chips fit that identification
>pattern.
Yes, that's also my concern on the code of detection. I don't have any other sensors as
LM75C to try, so thinking maybe some other guys can help extend it if needed in future.
>Overall, my suggestion is to add a small startup script to affected systems
>to instantiate the chip directly, and avoid weakening the detect function.
Understood, we can have the instantiating script but just don't want limit the detection.
Thanks!
Powered by blists - more mailing lists