> > To get the MAX6626 to work the attached patch is required > > I think this is a general error: > > snip ... > > /* Now, we do the remaining detection. There is no > > identification- > > dedicated register so we have to rely on several tricks: > > unused bits, registers cycling over 8-address boundaries, > > addresses 0x04-0x07 returning the last read value. > > The cycling+unused addresses combination is not tested, > > since it would significantly slow the detection down and > > would hardly add any value. */ > > ... snip > > "so addresses 0x04-0x07 returning the last read value" > > I think the idea behind checking against co and os is following: > > there must be one and only one of the register read back equal to them > > (isn't it?) > > In the original driver the exit was forced when one of them was not > > equal. > > No, the original code is exact. On the LM75, addresses 0x04-0x07 are > non-registers, thus the chip returns the last read register value when > these addresses are queries, whatever the register was. In our detection > code it happens that the last read value is hyst, so we check all > 0x04-0x07 addresses against this value. o.k., I see. > > We generally avoid relying on such tricks but the LM75 is otherwise hard > do detect. > > If the MAX6626 behaves differently we may be more tolerant, at least for > addresses where the MAX6626 is known to live. Could you please provide > the output of i2cdump for your MAX6626 chip? Feel also free to add some > printks in the driver code to see which values are returned for > addresses 0x04-0x07. I have done this, and i have read back the shadowed register values. The max6626 data sheet says: Pointer Register - D7 to D2: Will read all zeros, cannot be written. Because the D2..D7 cannot be written, the leaving pinter register bits are 0..1 which shows the register shadow effect. > > > On my wishlist there would be further extension to the driver: > > - the name lm75 -> max6626 > > How that? There is no way to differenciate between both chips as far as > I can see (other than chips at addresses 0x4C-0x4F cannot be MAX6626 > chips). You may also rely on the extra temperature bits but there's an > obvious 1/8 failure, plus not only the MAX6626 clone has 12-bit > resolution if I remember correctly. > > I don't think it's worth the pain trying to label the chips properly > since we will have an obviously non-neglectable failure rate (actually > the failure would more likely be the rule than the exception). > > > - the register names found in /sys directory > > for example temp1_max_hyst should be renamed to tlow > > Certainly not. We had a very hard time agreeing on what would be a good > standard name scheme, and we're not changing that now. See > Documentation/i2c/sysfs-interface. Basically we want the names to > reflect the function in a standard way, regardless of how the datasheets > names the feature. > > > - support for the additional three bits of resolution in temp1_input > > Fair enough, should be quite straightforward. > > > What would you propose? > > - reuse the lm75.c > > may be you can give me some hints in doing that > > Open, edit, save, compile, test :) > > I see only two locations requiring changes: > > 1* Detection code if the MAX6626 behaves slightly differently from the > LM75. > > 2* Temperature conversion. The functions are in lm75.h and used by other > drivers so don't edit them directly, instead duplicate them with a > different name and use them in the lm75 driver. > O.k. I aggree, but the problem I currently see is, that I have to distinguish between the LM75 and MAX6626 to select the appropriate conversion and detection functions. Because both chips use the same addresses I think it is not possible to do this in automated way. What do you think? > > - add new dedicated driver max6626.c > > I don't think this would make much sense since both devices are 90% > compatible. > > Thanks. > > -- > Jean Delvare > http://khali.linux-fr.org/ > > Thanks Ralf
