openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Williams <patrick@stwcx.xyz>
To: Andrew Jeffery <andrew@aj.id.au>
Cc: Zhikui Ren <zhikui.ren@intel.com>,
	Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>,
	Vernon Mauery <vernon.mauery@linux.intel.com>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	Ed Tanous <ed@tanous.net>,
	naveen moses <naveen.moses@outlook.com>,
	naveen moses <naveen.moses@hotmail.com>
Subject: Re: support for gpio  as ipmb sensor
Date: Wed, 6 Oct 2021 09:40:48 -0500	[thread overview]
Message-ID: <YV21cD3HOOGi7K2f@heinlein> (raw)
In-Reply-To: <ef4d5ac6-49e8-40d6-9e6b-1fe030f3909a@www.fastmail.com>

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-10-06 14:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 13:16 support for gpio as ipmb sensor naveen moses
2021-10-06  0:16 ` Andrew Jeffery
2021-10-06 14:40   ` Patrick Williams [this message]
2021-10-07  6:12   ` naveen moses
2021-10-07  7:45     ` naveen moses
2021-10-07 10:01       ` Andrei Kartashev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YV21cD3HOOGi7K2f@heinlein \
    --to=patrick@stwcx.xyz \
    --cc=andrew@aj.id.au \
    --cc=ed@tanous.net \
    --cc=jae.hyun.yoo@linux.intel.com \
    --cc=naveen.moses@hotmail.com \
    --cc=naveen.moses@outlook.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=vernon.mauery@linux.intel.com \
    --cc=zhikui.ren@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).