<div dir="ltr">When you do this, please use the gpio chardev interface instead of sysfs.  Ask me for details if you aren't familiar.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 14, 2017 at 3:02 PM, Patrick Venture <span dir="ltr"><<a href="mailto:venture@google.com" target="_blank">venture@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I apologize if this already exists or is in the works.<div><br></div><div>I propose we create a daemon that centralizes userspace GPIO access.</div><div><br></div><div>From a high level, the daemon will implement interfaces to export or unexport GPIOs.  Each GPIO exported will exist on the dbus:</div><div><br></div><div>/xyz/openbmc_project/gpio/53 and implement an interface with the following properties:</div><div>value, direction, active_low, etc.</div><div><br></div><div>Some doubts, should the gpio name on the dbus be the relative name (53), should it be the system specific name (G5) or the absolute name?  I'm thinking the relative name and let the daemon handle internalizing the adjustment from relative to absolute.</div><div><br></div><div>I'm working on adding GPIO support within phosphor-hwmon so that I can access a voltage sensor that's gated by a GPIO, and I know there have been conversations and implementations of this for IPMI OEM -- and I think it could easily be centralized.</div><div><br></div><div>Thoughts?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Patrick</div></font></span></div>
</blockquote></div><br></div>