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

[Thu Nguyen OS]

Let me think about "putting it into phosphor-hwmon".
There are two problem with this:
1. Currently phosphor-hwmon start before phosphor-state-manager create CurrentHostState dbus property. So there is the short time which we can't access this property to know the host state.
2. We need add one or some options in sensor configuration file to difference the binded/unbinded  drivers with the normal one.

Regards.
Thu Nguyen. 

On 05/04/2021, 23:20, "Matt Spinler" <mspinler at linux.ibm.com> wrote:



    On 4/5/2021 10:17 AM, Thu Nguyen OS wrote:
    > Sure, I will prepare the code.
    >
    > 1. Do you suggest the name of repo? I though we can use phosphor-driver-binder.

    At one point, there was going to be an official way to ask where new 
    functionality should go - 
    https://lore.kernel.org/openbmc/20210111220919.zwc727vbwc4itm7h@thinkpad.fuzziesquirrel.com/. 
    I can't remember seeing a way to make these requests though.  Maybe Brad 
    can chime in.

    How about just put it into the the phosphor-hwmon repo?

    > 2. Below is format of the configuration file which I'm using.
    > {
    >         "hostDrivers" :
    >         {
    >                "bindDelay" : 0,
    >                "unbindDelay" : 0,
    >                "drivers" :
    >                [
    >                       {
    >                              "name" : "",
    >                              "path" : ""
    >                       },
    >                       {
    >                              "name" : "",
    >                              "path" : ""
    >                       }
    >                ]
    >         },
    >         "powerDrivers" :
    >         {
    >                "bindDelay" : 0,
    >                "unbindDelay" : 0,
    >                "drivers" :
    >                [
    >                       {
    >                              "name" : "",
    >                              "path" : ""
    >                       },
    >                       {
    >                              "name" : "",
    >                              "path" : ""
    >                       }
    >                ]
    >          }
    > }
    > Where:
    > * hostDrivers: Json entry to define the drivers which bind/unbind when the host change state.
    > * bindDelay: The delay will be applied before start binding the drivers in the list.
    > * unbindDelay: The delay will be applied before start unbinding the drivers in the list.
    > * drivers: Define the list of drivers in one driver type.
    > * name: define driver name.
    > * path: is the path of that driver which have bind and unbind binary.
    >
    > * powerDrivers: Json entry to define the drivers which bind/unbind when the power change state.
    >
    > Do you think the json format is ok?

    Looks pretty good to me.

    > Regards.
    > Thu Nguyen.
    >
    > On 05/04/2021, 22:06, "Matt Spinler" <mspinler at linux.ibm.com> wrote:
    >
    >
    >
    >      On 4/2/2021 2:52 AM, Thu Nguyen OS wrote:
    >      > I thought that OpenBmc community have to have the solution for this.
    >      > I can propose my solution but I don't think it is common enough.
    >
    >      I haven't seen any code that does a bind/unbind on power on, so I would
    >      welcome your solution being upstreamed.  We put similar functionality
    >      into phosphor-gpio-presence that can bind/unbind around presence
    >      detection where the drivers are also listed in a config file.
    >
    >
    >      >
    >      > Regards,
    >      > Thu Nguyen.
    >      >
    >      > On 31/03/2021, 23:14, "Joseph Reynolds" <jrey at linux.ibm.com> wrote:
    >      >
    >      >      On 3/30/21 9:14 PM, Thu Nguyen OS 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. ‍ ‍ ‍ ‍
    >      >      >
    >      >      > 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.
    >      >      >
    >      >      > They are also unbinded when the host is Off.
    >      >      >
    >      >      > To support binding/unbinding the SMPro drivesr, we have one service
    >      >      > name driver-binder.
    >      >      >
    >      >      >  1. When the Dbus property CurrentHostState of service
    >      >      >     xyz.openbmc_project.State.Host changes to “not Off”, we will bind
    >      >      >     the drivers.
    >      >      >  2. 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?
    >      >      >
    >      >
    >      >      Thu,
    >      >
    >      >      I don't have a solution.  But I do want to be able to bind and unbind
    >      >      drivers for the BMC-attached USB ports (as the underlying mechanism when
    >      >      the BMC admin disables the ports), so I think it would be good to have a
    >      >      common solution or understand the best practices.
    >      >
    >      >      Joseph
    >      >
    >      >      > Regards.
    >      >      >
    >      >      > Thu Nguyen.
    >      >      >
    >      >
    >      >
    >
    >