Hi Juerg, > > For this reason, we do not assume the register values to be constant > > over time, in any driver. I agree it has a performance cost, but we > > decided it was better than hiding strange phenomenons when they happen. > > Well in that case I fail to see the purpose of the register cache at > all. It gets refreshed every time a read callback is executed (...) No, it is refreshed if and only if it is older than 1 or 2 seconds. > (...) and in a > write callback we're assuming it's stale and refresh it as well. We > never use the cached values for anything so why bother? We do use it. When running "sensors", the first read value will trigger the cache refresh, then all the other values will be read from the cache. > Wouldn't it be > simpler to split up the vt1211_refresh_device function and just read > the registers that we're interested in in the individual read > callbacks as oposed to calling vt1211_refresh_device and read > everything? Again, there are reasons why we wrote the drivers that way, mind you ;) First reason, some hardware monitoring chips stop updating when they are queried for register values. The idea of the cache was to group all bus accesses, and then guarantee a period of tranquility to the chip so that it can update the register values with fresh data. Second reason, if reading from a sysfs file was triggering a physical access to the chip unconditionally, it means every user of the system could saturate the bus this chip is connected to. With the cache, we guarantee this can't happen. Writing can only be done by root, which is why we are not worried about unconditional reads and writes in "set" sysfs callbacks. Third reason, or rather benefit, is to avoid duplicate reads when a register contains more than one "logical value". For example, if a register contains the fan clock dividers for all three fans, it's more efficient to read it once and cache it, than to read it three times. -- Jean Delvare
