On Tue, Feb 08, 2011 at 10:56:29AM -0500, Matthew Garrett wrote: > On Tue, Feb 08, 2011 at 07:49:16AM -0800, Guenter Roeck wrote: > > > Seems to me there is some hair splitting going on here. Core element of > > hwmon drivers is that there are reported temperatures, voltages, current, > > power, humidity, etc. I don't see any of those here. All I see is various > > current limits. Those are secondary attributes from hwmon perspective. > > So I don't really see how this can be made a hwmon driver. > > Ok, if the hardware has no mechanism for reporting the instantaneous > draw then I can see it not working well in an hwmon sense. But I'd > really prefer to see this look far more generic than it does - surely > other hardware has similar functionality? > Might well be. Just like thermal subsystem drivers act on thermal information and registers thermal drivers with the hwmon subsystem for reporting purposes, it might well be that there could at some point be a "current" subsystem doing something similar for currents. But that doesn't mean that it would make sense to provide such functionality from within the hwmon subsystem. I have no idea if your other question can be answered right now. Maybe a more generic interface is possible, but one would need to see multiple implementations to determine what can be generalized. I personally don't believe that it is possible to define a useful generic interface without knowledge of multiple pieces of HW using that interface. If someone volunteers to create a generic API, ABI, and possibly a new subsystem for current management, that person can go ahead and present that subsystem to the community for consideration. I am all for it. But it would not be appropriate to hold this driver hostage to the non-existence of such a subsystem. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
