> The NM34W02 datasheet makes clear in Figure 5 what a byte write is, > it's what we call byte-write-data. > The ST M34C02 datasheet has the same thing in Figure 6. OK, good point. You're definitely better than me at readin datasheets ;) > You're right we can't guarantee it. But the datasheets I've seen > have been quite consistent. I take note. > Maybe it's a value to tell the user what it is. > But we've been telling them for years it's a "shadow", > maybe it doesn't add any value to tell them otherwise. Well you've documented it the way it has to be, I think it's enough if people need additional information. > We've been using quick write for years, and haven't ever had a report > that somebody saw something once at 30-37 and never again. > Of course who would notice such a thing? Nobody, especially since we were not actually detecting it, and also because write-protecting the eeprom would be harmless in most cases (SPD EEPROMS for example have no reason to be updated - write-protecting them could even be considered a good thing). > > I would suggest that we comment out the eeprom with $chip == 2 in > > @chips_id by default. We can leave it in if some people happen to > > need it, but not do it by default. > > If you wish. I did it as an experiment. OK, I've done that. > > BTW, at least one EEPROM model (Catalyst CAT34RC02) can also read > > byte from its write-protection address, so your detection method > > would miss it. > > Correct. We'd have to add it as yet another eeprom chip type. > Which stretches things even more. Feel free to add this in sensors-detect, I've not done it. Also feel free to add a "default eeprom" entry and rework eeprom_detect a little bit if you want. So sensors-detect is clear. I've retained ranges 0x30-0x37 and 0x50-0x5F for probe-with-reads. I'll do i2cdetect tomorrow. I plan to use the same ranges. Maybe we could provide command line flags to restore original probing (all quick writes) and all probe-with-reads (with all due warnings)? Then I'll submit a patch for the 2.6 kernels. i2c-core needs to be changed to issue reads instead of quick writes on the above-mentioned range. eeprom and ddcmon drivers lose their extra quick write. i2c-piix4 lose its IBM check. I don't know if we want to even remove the unsafe smbus check in dmi_scan, I'll see that later. As for the 2.4 kernel modules, there's a problem there. i2c-core and eeprom are distributed in different packages and not necessarily in sync, since there is no explicit version checking. Thus mixing a new i2c-core with an old eeprom would result in the extra quick write in eeprom actually corrupt the chip. Bad. There's still the IBM check in i2c-piix4 however. Maybe we don't want to change anything in 2.4 after all (except ensure that the extra quickwrites are consistently issued). Comments welcome. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
