lm_sensors2/prog/detect sensors-detect

[mds4@verizon.net (Mark Studebaker)]

Jean Delvare wrote:
>>Modified Files:
>>	sensors-detect 
>>Log Message:
>>(mds) support detection of eeprom shadows we now know are
>>      software write-protect registers.
> 
> 
> I'm not sure we want to do that. According to a number of datasheets
> Rudolf pointed me to yesterday, some EEPROMs will "not care" about what
> data you write to their write-protection address. "Any write" will
> write-protect the EEPROM. It's not very clear whether it means "any
> write byte data" or just any write, which could include quick command 0.
> 
> This is the reason why I proposed to scan the 0x30-0x37 range with read
> bytes instad of quick command 0. Of course, if we do that, we cannot
> detect page protection addresses. But actually, we cannot read from them
> and do not want to write to them, so what's the point detecting them?
> 
> 


the point is that we tell people what's at 0x30, that it's associated
with what's at 0x50.

I went through the datasheets of the Microchip and ST parts pretty
carefully yesterday, it's clear that it's a byte-write-data that
does the write-protect.



>>      prevent Vaio detection from running more than once.
> 
> 
> Mmm, was there a bug before? I can't see what it was. Actually the fact
> that I was testing the Vaio EEPROM in all cases was wanted, it was
> preventing Vaio EEPROMS from being first announced as SPD EEPROMs, then
> Vaio ones. I agree that the second would have had a higher confidence
> value anyway, but this reduced the noise for the end user, so it's the
> right thing to do IMHO. (Also, there used to be a problem with
> conflicting detections implying the same driver twice; sensors-detect
> would recommend to exclude the "conflicting" address when loading the
> module, while this address was correct and would have worked! I believe
> it's now fixed for I2C addresses (but probably not ISA) but this also
> explains some places where extra checks were done just to workaround
> this issue.) I also agree that this approach reveals that the underlying
> detection method is not the best it could be. For now, detection
> functions only answer the question "what are the chances that the chip
> at address X is Y?" while most of the time the question we would like to
> answer to is "if the chip at X is of type Z, which subtype Y is it the
> more likely to be?" However I guess it would require too much work to
> change sensors-detect in that way now, which is why I had to use tricks
> to achieve the same objective.
> 

Clearly the Vaio detection in eeprom_detect() was being called
both for chip=0 and chip=1, so I changed it so it was only called
for chip=1. I didn't realize that you did it for both to
reduce "noise". IMO not doing things twice is better than
reducing "noise".

Perhaps a better long-term solution is to call a detection
routine once and allow it to return different names,
rather than calling it multiple times, one for each chip name.


> The fact that we default to SPD EEPROMs is probably not correct, BTW. It
> used to be the only EEPROM type found in PCs, but now you have eeprom on
> Xeons, Vaios, network adapters and more... I think we should have a
> "generic EEPROM" entry and use that if none of the other test worked.
> 
> Thanks.
> 

agreed