From: Ed Tanous <edtanous@google.com>
To: Thu Nguyen OS <thu@os.amperecomputing.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: The common solution to support bind/unbind the hwmon driver base on the host state.
Date: Mon, 5 Apr 2021 09:32:48 -0700 [thread overview]
Message-ID: <CAH2-KxDCK4P5jsPxCfa3cS962SOoDfoeM0XVpAqVRjE_VGiJ_Q@mail.gmail.com> (raw)
In-Reply-To: <7252DA19-35E9-4A14-A7DF-7BBC54A312C2@amperemail.onmicrosoft.com>
On Tue, Mar 30, 2021 at 7:14 PM Thu Nguyen OS
<thu@os.amperecomputing.com> wrote:
>
> Hi All,
>
>
>
> Currently, In Mtjade platform of Ampere, we have SMPro mdf drivers (SMPro hwmon, SMPro errmon, SMPro misc driver).
>
> The drivers will be loaded by kernel when the BMC boot up. But they are only binded when the host is already On.
Assuming you're using dbus-sensors, you'd normally just write an app
that's capable of unloading the modules and watching the power states.
Experience seems to show that very few true "rules" exist with regards
to this kind of enabling/disabling, and as hardware gets used more,
more odd error handling seems to pop up, so as a matter of design we
pushed this into the individual sensor daemons early on to try to keep
it somewhat sane to manage. dbus-sensors somewhat takes the position
that once all hardware is debugged, there is no "common" solution to
reset, and we've proven that on several occasions with other simple
sensors.
Overall, I'd recommend just writing an AMDCpuSensor application, as I
suspect this is the first of many special cases that the processor
will need.
>
> They are also unbinded when the host is Off.
>
> To support binding/unbinding the SMPro drivesr, we have one service name driver-binder.
>
> When the Dbus property CurrentHostState of service xyz.openbmc_project.State.Host changes to “not Off”, we will bind the drivers.
> When the Dbus property RequestedHostTransition of service xyz.openbmc_project.State.Host OR Dbus property RequestedPowerTransition of xyz.openbmc_project.State.Chassis
>
> change to Off, we will unbind the drivers.
>
>
>
> The driver-binder is working as expected, it have the configuration file to configure which drivers will be binded/unbinded.
>
> But that is our solution.
>
>
>
> Do we have any common solution to do that job?
>
>
>
> Regards.
>
> Thu Nguyen.
>
>
>
>
next prev parent reply other threads:[~2021-04-05 16:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-31 2:14 The common solution to support bind/unbind the hwmon driver base on the host state Thu Nguyen OS
2021-03-31 16:14 ` Joseph Reynolds
2021-04-02 7:52 ` Thu Nguyen OS
2021-04-05 15:06 ` Matt Spinler
2021-04-05 15:17 ` Thu Nguyen OS
2021-04-05 16:20 ` Matt Spinler
2021-04-06 15:23 ` Thu Nguyen OS
2021-04-06 15:27 ` Matt Spinler
2021-04-05 16:32 ` Ed Tanous [this message]
2021-04-06 15:15 ` Thu Nguyen OS
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=CAH2-KxDCK4P5jsPxCfa3cS962SOoDfoeM0XVpAqVRjE_VGiJ_Q@mail.gmail.com \
--to=edtanous@google.com \
--cc=openbmc@lists.ozlabs.org \
--cc=thu@os.amperecomputing.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).