Hi Lennart, On Tue, 22 Feb 2011 13:27:13 -0500, Lennart Sorensen wrote: > On Tue, Feb 22, 2011 at 06:28:33PM +0100, Jean Delvare wrote: > > My point was that you should say "National Semiconductor LM75A" and not > > just LM75A, to avoid confusion with other brands. > > Ah, I see. I thought the LMxx was always National Semiconductor and > that others used different letters. This is generally true, so much that we did not bother including the vendor name in i2c device IDs (matching is done on the name string alone.) But apparently the LM75 is such a popular device that is has more clones than any other I2C device I know of, including, sadly, some with the exact same name, but not 100% compatible, from other vendors. > > My experience with ID registers in I2C devices is that the revision > > rarely changes, and when it does, it often requires other driver > > changes to properly support the new device revision. So it is > > preferable to only support the known revisions, and add new revisions > > as they spotted in the wild or datasheets are updated to mention them. > > Well I can do that. Either way it is more accurate detection than the > older style LM75 detection ever had. I beg to disagree. I would say that both detections are comparable. The LM75-specific behavior of "registers" (or lack thereof) 0x04-0x07, coupled with their cycling, is an almost unique characteristic (which is why we decided to use it for detection purpose.) If you ask me, I would say that a random chip at an LM75-compatible address is less likely to implement this characteristic than to have value 0xA as the high nibble of register 0x07. > Once detected the new one is > completely compatible with the old one. Thankfully, yes :) > > Please keep in mind that there is no standard ID registers in I2C > > devices, neither address nor values. So it is perfectly possible for > > other devices to match your detection routine if you aren't strict > > enough. It is preferable to miss a detection than to have a false > > positive and accidentally bind to a totally different device. This is > > what I want to avoid. > > Of course. I am amazed how the old detection code has managed to not > be a problem. It has been problematic, and was improved over time. You can see the first version of the detection code here: http://www.lm-sensors.org/browser/lm-sensors/trunk/kernel/chips/lm75.c?rev=338 > > If you still disagree, a middle ground would be to reject revision == 0 > > and only accept reasonable revisions (that is revision == 2 may happen > > in the future, but I don't expect say revision == 10 any time soon.) > > Well I will just match on the current revision for now then. OK, fine with me. > > This is certainly annoying, but you can't blame National Semiconductor > > for this. Instead, blame yourself for still relying on automatic device > > detection in 2011 when mechanisms to cleanly instantiate I2C devices > > exist since mid-2008. The original LM75 was never meant to be detected, > > it doesn't even have an ID register. > > Well at least the LM75A does have an ID register, so supporting detection > of it seems fair enough. Yes and no. 4 bits for the device ID is weak, especially when in a random register (which is why I insisted in using the whole 8 bits, including the revision.) "Good" devices have 8 bits of vendor ID + 8 bits of device ID at semi-standard addresses, and even this is not bullet proof. -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
