From: Matt Spinler <mspinler@linux.ibm.com>
To: Patrick Williams <patrick@stwcx.xyz>
Cc: openbmc@lists.ozlabs.org, Thu Ba Nguyen <tbnguyen1985@gmail.com>
Subject: Re: Enable/Disable some sensors when Host On/Off
Date: Tue, 20 Oct 2020 16:26:33 -0500 [thread overview]
Message-ID: <6c8df4cb-2b22-97bb-9ba6-f9dece0e14e5@linux.ibm.com> (raw)
In-Reply-To: <20201020141804.GA5030@patrickw3-mbp.lan.stwcx.xyz>
On 10/20/2020 9:18 AM, Patrick Williams wrote:
> On Tue, Oct 20, 2020 at 08:46:30AM -0500, Matt Spinler wrote:
>>
>> On 10/19/2020 10:23 AM, Thu Ba Nguyen wrote:
>>> I also thought about the solution for that features:
>>> In the current hwmon we support GPIOCHIP + GPIO option which used to
>>> enable sensors to read. In the hwmon code, we just set that pin and wait
>>> before reading.
>>> I think we can support a similar option named GPIOENABLE + GPIOV. When
>>> the status of Gpio pin defind in GPIOEANBLE match with GPIOV.
>>> That sensors will be read and update to Dbus.
>>> If not it will be removed from DBus until the GPIO pin math GPIOV.
>>> Maybe we can have many different solutions.
> ...
>>> If you don't mind, can you tell me how IBM supports that features?
>> We lucked out out in that the driver was only loaded when power was on.
>>
> Hi Thu,
>
> Is this something you could do similarly? Rather than have the driver
> understand the GPIO directly you can trigger a phosphor-gpio-monitor
> service that does a 'bind' / 'unbind' to dynamically enable and disable
> the hwmon driver?
>
> Matt, is that how you have the driver configured to load / unload (I
> assume your case is for the OCC).
We use a slightly different mechanism since we need to wait for the host
to tell us the device is running (yea it's the OCC), but same general idea.
>
next prev parent reply other threads:[~2020-10-20 21:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-18 13:58 Enable/Disable some sensors when Host On/Off Thu Ba Nguyen
2020-10-19 14:16 ` Matt Spinler
2020-10-19 15:23 ` Thu Ba Nguyen
2020-10-20 13:46 ` Matt Spinler
2020-10-20 14:18 ` Patrick Williams
2020-10-20 21:26 ` Matt Spinler [this message]
2020-10-20 23:21 ` Thu Ba Nguyen
2020-10-20 23:39 ` Thu Ba Nguyen
2020-10-20 23:16 ` Thu Ba Nguyen
2020-10-19 17:31 ` Ed Tanous
2020-10-19 18:22 ` Thu Ba Nguyen
2020-10-19 18:31 ` Ed Tanous
2020-10-20 23:05 ` Thu Ba Nguyen
2020-10-21 0:15 ` Vijay Khemka
2020-10-21 16:54 ` Thu Ba Nguyen
2020-10-22 14:49 ` Thu Ba Nguyen
2020-10-22 15:51 ` Matt Spinler
2020-10-22 22:45 ` Thu Ba Nguyen
2020-11-04 9:15 ` Thu Ba Nguyen
2020-11-04 16:31 ` Matt Spinler
2020-11-04 22:18 ` Thu Ba Nguyen
2020-11-05 20:52 ` Matt Spinler
2020-11-05 23:16 ` Thu Ba Nguyen
2020-11-05 23:24 ` Matt Spinler
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=6c8df4cb-2b22-97bb-9ba6-f9dece0e14e5@linux.ibm.com \
--to=mspinler@linux.ibm.com \
--cc=openbmc@lists.ozlabs.org \
--cc=patrick@stwcx.xyz \
--cc=tbnguyen1985@gmail.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).