> > You seem to suggest that each CPU type can only work with one VRM > > version. Are you sure? > > Well, I wasn't sure at first. But later, I looked at some Intel docs > which say that the VID signals come right from the processor package > itself (1). So now I'm sure. A CPU vs VRM version table would be welcome then. > > The CPU type information is also available in kernel-space, maybe > > even more easily (no parsing required), and I believe that setting > > the VRM from the CPU type belongs to the driver (once, at init > > time). I don't see how you are going to do that in "sensors". > > Actually, "sensors -s". It wouldn't be hard - I mean, it already sets > the VRM based on /etc/sensors.conf. My point isn't about how to do it, I can imagine that you'll parse /proc/cpuinfo and issue the correct libsensors action. My point is about when you will do it. So far, only "set" lines of sensors.conf do trigger a write action, and in a very generic way. You would have to do something very specific for vrm, possibly conflicting with sensors.conf set lines. This is why I'm skeptical about your proposal. > But you're probably right that it belongs in the driver; perhaps > another shared function of the i2c-sensors module. It would even belong to i2c-vid.h (in which case we may need to create i2c-vid.c and build the i2c_sensor module from i2c-vid.c and i2c_sensor.c). > Does anyone know how to read CPU id info from kernel space? I have no clue and not much time to check right now. Grepping the sources for "cpuid" could help. Or you may try to locate where /proc/cpuinfo gets it from. One may wonder if the change would allow us to get rid of the vrm sysfs file entirely. This would be great, but I'm not 100% sure. There are a few corner cases I can think of that may require our attention. 1* Evaluation boards (or more generaly, cases where the chip doesn't belong to the monitoring system). This is uncommon and people doing this are expected to know their stuff. VID readings are for comfort, you can live without them, especially in experimental context. 2* Multi-cpu systems. I'd expect such systems to use a single family of chips, and so a single VRM version for all CPUs. All in all I'm quite confident that we could get rid of the additional interface (if and only if you hypothesis that we can know the VRM version from the CPUID is correct). But comments are welcome. Thanks. -- Jean Delvare http://khali.linux-fr.org/
