<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Sep 17, 2017 at 9:26 AM, Brad Bishop <span dir="ltr"><<a href="mailto:bradleyb@fuzziesquirrel.com" target="_blank">bradleyb@fuzziesquirrel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 2017-09-16 at 21:22 -0700, Patrick Venture wrote:<br>
> On Sat, Sep 16, 2017 at 3:12 PM, Brad Bishop<br>
> <<a href="mailto:bradleyb@fuzziesquirrel.com">bradleyb@fuzziesquirrel.com</a>> wrote:<br>
> > Hi Patrick<br>
> ><br>
> > On Thu, 2017-09-14 at 15:02 -0700, Patrick Venture wrote:<br>
> > > I apologize if this already exists or is in the works.<br>
> > ><br>
> > > I propose we create a daemon that centralizes userspace GPIO<br>
> > access.<br>
> > ><br>
> > > From a high level, the daemon will implement interfaces to export<br>
> > or<br>
> > > unexport GPIOs.  Each GPIO exported will exist on the dbus:<br>
> > ><br>
> > > /xyz/openbmc_project/gpio/53 and implement an interface with the<br>
> > > following properties:<br>
> > > value, direction, active_low, etc.<br>
> ><br>
> > Just thinking out loud...are we sure a gpio is a useful<br>
> > abstraction?<br>
> > If applications all just use the chardev API what is the benefit of<br>
> > having a dbus object, at the cost of API complexity.<br>
><br>
> As an alternative, perhaps a library would suffice.  My goal is to<br>
> avoid multiple in-application implementations.  However, I felt it<br>
<br>
</span>A good goal.<br>
<span class=""><br>
> might be helpful to have some centralized daemon serving this<br>
> information -- a simple dbus property access may be simpler than<br>
> either implementing the ioctl in each application.  However, a<br>
> library may also provide the necessary abstraction.<br>
<br>
</span>I think if you implement a library with API it becomes a wash.  There<br>
is also polling to consider - we have a number of applications using<br>
gpio-keys + libevdev.<br>
<span class=""><br>
>  <br>
> > ><br>
> > > Some doubts, should the gpio name on the dbus be the relative<br>
> > name<br>
> > > (53), should it be the system specific name (G5) or the absolute<br>
> > > name?  I'm thinking the relative name and let the daemon handle<br>
> > > internalizing the adjustment from relative to absolute.<br>
> > ><br>
> > > I'm working on adding GPIO support within phosphor-hwmon so that<br>
> > I<br>
> > > can access a voltage sensor that's gated by a GPIO, and I know<br>
> > there<br>
> ><br>
> > Can you elaborate on what gated means?  Is it you have to wiggle a<br>
> > GPIO<br>
> > before the hwmon driver for this voltage sensor can actually access<br>
> > the<br>
> > sensor hardware?<br>
> ><br>
> ><br>
><br>
> There is a GPIO that controls whether the battery sensor on the<br>
> quanta board (and I've heard of similar configurations on others)<br>
> that needs to be set high for the sensor to work.  I implemented a<br>
> bit of a hack in phosphor-hwmon to allow one to specify a GPIO that<br>
> needs to be flipped in this type of configuration.  I'd consider<br>
> submitting the patch, however it uses the sysfs interface -- as this<br>
> saved a little implementation time.<br>
<br>
</span>We have run into situations like this multiple times.  What we did was<br>
bind/unbind the driver in question when the hardware behind it becomes<br>
available.<br>
<br>
What do you think of this?<br>
<br>
1 - You simply wiggle the gpio from a script or small application at<br>
      the appropriate time.<br></blockquote><div><br></div><div>My thought here is -- the appropriate time is, right before phosphor-hwmon wants to read it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2 - An application other than phosphor-hwmon monitors this gpio and<br>
      binds the driver to it (or unbinds).<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3 - phosphor-hwmon works without modification.<br>
<br>
In fact, #2 is already done - Matt Spinler recently added code to<br>
phosphor-gpio-monitor to do exactly this.<br></blockquote><div><br></div><div>I haven't looked at gpio-monitor.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I prefer something like this for two reasons:<br>
<br>
1 - Consistency in how we handle things.  It becomes easier to write<br>
howtos or cookbooks to provide guidance in the future. <br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2 - We avoid one-offs in phosphor-hwmon.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> I'd be willing to fix it up to use the proper interface and submit it<br>
> upstream if that's something helpful -- or seek out a good library<br>
> for us to use -- I'm also open to suggestions on this.<br>
> > > have been conversations and implementations of this for IPMI OEM<br>
> > --<br>
> > > and I think it could easily be centralized.<br>
> > ><br>
> > > Thoughts?<br>
> > ><br>
> > > Patrick<br>
> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>