On Wed, Oct 06, 2021 at 10:46:40AM +1030, Andrew Jeffery wrote:
> On Tue, 5 Oct 2021, at 23:46, naveen moses wrote:

> > So is this acceptable to create a new interface for gpio state under 
> > xyz/openbmc_project/sensors :
> > interface name : gpioState
> > which has a property named value whose possible values are boolean 
> > (true or false).
> 
> What about modelling the behaviour the GPIO state represents rather 
> than just providing a DBus interface to the GPIO values?

Agreed.  In general we've tried to refrain from exposing raw GPIOs on the dbus
and instead tried to model some behavior out of those GPIOs.  Your use case
(wanting to use gpio-monitor) doesn't really seem strong enough to me to warrant
a change of this direction.  You'd have to add support in `gpio-monitor` to
watch dbus signals, in addition to gpio-lines, and create a new program that
exposes those gpio objects.  And, at the same time you're introducing a poorly
documented API between two dbus providers because you're expecting very specific
name matching.  Why not just have the original program do whatever you intended
gpio-monitor to do?

-- 
Patrick Williams