Re: [PATCH RESEND] x86,mrst: Intel Medfield over-current detection patch

[Guenter Roeck <guenter.roeck@ericsson.com>]

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