GPIO Centralized Control Daemon

[Brad Bishop]

> > 
> > What do you think of this?
> > 
> > 1 - You simply wiggle the gpio from a script or small application
> > at
> >       the appropriate time.
> 
> My thought here is -- the appropriate time is, right before phosphor-
> hwmon wants to read it.

phosphor-hwmon shouldn't be providing an interface for something
that isn't accessible.  And it shouldn't concern itself with
making something accessible because there could be any number of
ways to do that, based on the wiring of the board.

What I meant was why is the sensor gated by a gpio?  For example, is it
because the sensor is only available when some power domain is actually
powered on?  In that example, the appropriate time would be when
the power domain is turned on and off.

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.

>  
> > 2 - An application other than phosphor-hwmon monitors this gpio and
> >       binds the driver to it (or unbinds).
> 
> In this case, won't the device be removed/added to the hwmon sysfs on
> demand?  I don't believe phosphor-hwmon picks up new devices
> automatically.

Yes, on demand, but he phosphor-layer has a udev rule that launches
(and terminates) a phosphor-hwmon instance along with it.

>  
> > 3 - phosphor-hwmon works without modification.
> > 
> > In fact, #2 is already done - Matt Spinler recently added code to
> > phosphor-gpio-monitor to do exactly this.
> 
> I haven't looked at gpio-monitor.
>  
> > I prefer something like this for two reasons:
> > 
> > 1 - Consistency in how we handle things.  It becomes easier to
> > write
> > howtos or cookbooks to provide guidance in the future. 
> 
>  
> > 2 - We avoid one-offs in phosphor-hwmon.
> 
> I wouldn't necessarily consider it a one-off, as I can immediately
> think of at least one other motherboard that would benefit from such
> an opportunity.  Also, in this case it would all fit into one nice
> package -- one thing to configure by adding the corresponding line to
> a configuration file.

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....