Re: [PATCH v2 2/2] hwmon: add generic GPIO brownout support

[Trent Piepho <tpiepho@impinj.com>]

On Mon, 2018-10-29 at 18:12 -0700, Guenter Roeck wrote:
> On 10/29/18 2:16 PM, Trent Piepho wrote:
> > 
> > If we ignore the ability to stop other devices, how is this not a hwmon
> > device with just alarm features?
> > 
> 
> Possibly, but the ability to stop other devices is at the core of the driver
> as submitted.

I was thinking along the lines of a driver for gpio based hardware
alarms, that did not include the device stop feature.  Would that also
be quickly NACKed?

> > I2C/LPC/SPI interface was not connected as an appropriate master was
> > not available, and the default configuration of the chip was
> > acceptable.  The chip's alarm outputs are connected to GPIOs, as it
> > normal for a hwmon chip with alarm outputs.
> > 
> 
> "If we had" is theory. Do we ? We don't usually add code to the kernel
> just in case the hardware it supports might be out there.

What I was trying to do was reach the conclusion that a gpio hardware
alarm as a hwmon driver is appropriate via clear steps.

A classic hwmon chip should have a hwmon driver.  We all accept that.

Disconnect i2c interface, keep alarms, does the kernel interface need
to change?  Seems clear to me the answer is no, should still be hwmon.

Replace chip with discrete logic, e.g. an op amp and a few resistors
serving as a voltage comparator, which has the same behavior as the 
hwmon chip as far as the rest of the system is concerned.  Does the
kernel interface need to change now?  Again, seems like it shouldn't
change.

> 
> For voltage monitoring, that is not normally the case. It is much more likely
> that there is in fact a hardware monitoring or power control chip, the
> (or an) alarm output of that chip is connected to a gpio line, and its control
> interface is connected. If so, the driver for that chip should be enhanced
> to support interrupts, and to report the status with its own sysfs attributes.

I agree that writing a specialized driver that pretends a hwmon chip
with a control interface is just a gpio wouldn't be appropriate as an
upstreamable driver for the kernel.  It's more of a one off hack of
expediency.

But it's pretty easy to make a voltage alarm circuit with an op amp. 
Even a differential temperature sensor with hysteresis is just a few
components.

Would a hwmon driver for this be unacceptable?