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

Matt Spinler mspinler at linux.ibm.com
Wed Apr 7 01:27:53 AEST 2021



On 4/6/2021 10:23 AM, Thu Nguyen OS wrote:
> 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.

Oh, what I meant here was still having a new daemon, but just putting it 
in the same phosphor-hwmon git repository that phosphor-hwmon-readd 
lives in.


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



More information about the openbmc mailing list