The common solution to support bind/unbind the hwmon driver base on the host state.
Matt Spinler
mspinler at linux.ibm.com
Tue Apr 6 02:20:31 AEST 2021
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