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

[Thu Nguyen OS]

On 05/04/2021, 23:33, "Ed Tanous" <edtanous at google.com> wrote:

    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.

[Thu] I'm using the phosphor-hwmon, to create the sensor dbus object.
I don't use entity-manager and also dbus-sensor.
With phosphor-hwmon, when the driver is binded, all of the configured sensors will be read and update the value to dbus by phosphor-hwmon.
It seem the phosphor-hwmon is working as expected.
The problem is currently kernel don't support auto bind/unbind mechanism, so I have to do that manually. As my opinion, We can add binding/unbinding the driver as separated daemons or integrate it to phosphor-hwmon.

    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.
    >
    >
    >
    >