The common solution to support bind/unbind the hwmon driver base on the host state.

[Ed Tanous]

On Tue, Mar 30, 2021 at 7:14 PM Thu Nguyen OS
<thu at 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.
>
>
>
>