Jean Delvare wrote: > On Thu, 5 Jun 2008 15:04:16 +0100, Ben Hutchings wrote: > > Jean Delvare wrote: > > > On Thu, 5 Jun 2008 13:14:01 +0100, Ben Hutchings wrote: > > > > The point is to allow platform_data to provide all the settings and to > > > > allow polling of the values, without exposing any of the implementation > > > > variables. > > > > > > The question is: why do you want to provide the "settings" (I think you > > > mean the high and low limits of each sensor?) and allow polling of the > > > values inside the kernel, when we have a standard user-space interface > > > and library that takes care of this, with a dozen applications that can > > > be used on top of it? It makes sense to pass _some_ settings as > > > platform data (e.g. fan polarity) but passing all the limits doesn't > > > make any sense to me. > > > > We know what the limits should be for our boards and those should be set as > > the defaults. AFAIK there's no user-space infrastructure for initialising > > these things at hotplug time, so we must specify them in the kernel. > > What bad will happen if the limits are only initialized a few seconds > or minutes after the driver is loaded? My point is that I don't see that they are ever likely to be initialised. They can be set through sysfs, but unless this is automated in some standard way then almost no-one will actually go to the trouble of doing it. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job.
