GPIO Centralized Control Daemon

[Brad Bishop]

> > Is it just stuck behind a gpio for no reason?  If that is the case,
> > I
> > would think you just wiggle the gpio when the bmc boots.
> 
> In this particular case, it's behind a GPIO so it doesn't drain the
> battery -- or at least that's my understanding of the design.
> 
> The appropriate time would be -- when someone tries to read it from
> the host.  What you're suggesting is that, the ipmi daemon, when it
> receives a request for this sensor - that is then launches something
> that sets the gpio, and then waits for the dbus objects to exist from
> the launched phosphor-hwmon, before then requesting the sensor value
> in its normal course of action.  Because it's my understanding it's a
> gated sensor so that it doesn't drain the battery, which means
> leaving it open effectively permanently isn't an option.  If I'm
> misunderstanding the goal of the design, then obviously just
> unlocking the GPIO effectively permanently is a solution.

Aha!  Now I understand the motivation.  And yes the approach I've
outlined is quite painful.  In my defense I would not have suggested
that had I known :-)

> > 
> > I'm not arguing that there aren't several board setups where this
> > is
> > the case.  Rather, board designers are free to do whatever they
> > want,
> > and if we start putting the board specific logic in phosphor-hwmon
> > you
> > won't have "one nice package" for very long....
> 
> True-ish.  This is quite similar to dealing with GAIN and OFFSET.  

Those feel different to me.  They are needed for thermistor type
sensors regardless of board wiring.

> Those are particulars of a board that now get factored into the
> value.  I'm not suggesting something beyond the norms of hwmon.  It
> would be convenient however, if the ADC driver could be programmed to
> know that some sensor is gated by a GPIO and handled flipping, 

Can you reach out to Guenter or the relevant maintainer (is this an IIO
device?) for ideas here?  I hadn't mentioned it but in the back of my
head this whole time I've been wondering about a completely in-kernel
solution.

> waiting, reading, and flipping-back for someone -- quasi-similarly to
> i2c muxes that use gpios.  Except, obviously, the waiting and setting
> it back part are ... a bad plan to build into a driver, in that it 

It has to be done in one place or the other, does it not?  You mention
i2c muxes - managing those isn't delegated to userspace (there are
drivers for i2c muxes) so maybe this situation need not be any
different?

> could delay returning a value.  Although -- one could argue the fan
> speed controller driver does that -- takes time to respond.  It's
> just, one would then also want to configure the wait time, because 

In the very near future I intend to make all the wait/delay/retry
intervals runtime configurable to handle exactly these kinds of nuances
between devices and their drivers.

> some configurations will take longer for a sensor value to stabilize.
> 
> Patrick
>