Jean Delvare wrote: > On Thu, 5 Jun 2008 16:12:16 +0100, Ben Hutchings wrote: > > Jean Delvare wrote: > > > Same is true of every hardware monitoring in every system. If the user > > > doesn't care about the limits, why should you care for him/her? > > > > If I remember correctly, the lm-sensors drivers were written for sensors > > that were on PC motherboards and already used and initialised by the BIOS. > > It appears to me that the lm87 driver at least still assumes this as the > > normal cases. For example, it absolutely requires that the channel > > register is set correctly before it is bound to the device. > > That's partly correct. The drivers were originally written for > sensors on PC motherboards, and they assume some initialization done > by the BIOS, but also expect missing initialization. lm87_init_client() > clearly shows this, if the chip is already running we assume that the > limits are already set, if not, as we know that the LM87 doesn't > initialize these register to sane values, we reset them all (that's > what would happen in your case I guess.) > > For the channel register you are correct, and this one makes full sense > to have in platform_data in your case. > > > So usually there is little need for initialisation by the hardware monitor > > driver or the user. Advanced users can tweak the limits as they see fit, > > but most users will be happy with the firmware defaults. > > It really depends on the board. A few boards initialize the limits > properly, but in general the user really wants to set them, or he/she > gets either spurious alarms or no alarms at all. I have a hard time believing this because in my experience PCs normally shut down in case of an over-temperature alarm. > > But in the absence of firmware to initialise the limits, this falls apart. > > Why? In general, the limits and the alarms are informative only, and > nothing bad will happen if the limits aren't set immediately. So, > user-space has all the time to set the limits after the driver has been > loaded. All that matters is that the limits are set before the user > gets a chance to look at them. The way this is supposed to work is that in case of a fault the hardware is shut down to prevent (further) damage. For a PC motherboard the BIOS (possibly cooperating with the OS through ACPI) will do that. In the case of our reference boards, we depend on either hard-wiring (SFE4001) or the driver (all others) to do this. > > > The standard way of proceeding would be to provide libsensors > > > configuration files for your network adapters, and users who care about > > > proper sensor labelling and limits, will download and install them on > > > their systems. We plan to automatize the process a bit in the future > > > but this isn't done yet. > > > > We could probably provide these in driver RPMs, but that doesn't really > > help people getting the in-tree driver. It seems to me that platform_data > > is exactly the right place to put such information. > > You could make the configuration files available for download from your > web site directly (it really makes no sense to put these in RPMs), or > just ask for a wiki account on lm-sensors.org and upload them there. I was assuming - not having looked - that we could install a configuration fragment into a directory which would then be included. Now I see there is no support for that, either in the lm_sensors release nor Red Hat's packaging of it. Also I see no provision for hotplug - so if a NIC is hot- swapped the new NIC won't have its limits initialised. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job.
