Does it make sense to create a centralized fan control module?

Ed Tanous edtanous at
Thu Jun 17 02:26:24 AEST 2021

On Thu, Jun 10, 2021 at 6:19 PM Heyi Guo <guoheyi at> wrote:

> Hi All,
> Right now fan related data like tacho and PWM is fetched in
> dbus-sensors, and published to d-bus as sensor data, while fan control
> is made in another module like pid-control, which can fetch data and set
> value via d-bus.
> In some common sense, we may think about putting all fan related work
> into one single module (which may be based on pid-control), i.e. it can
> read tacho and PWM from hardware directly, calculate the required PWM by
> some algorithm like PID, and then write to PWM hardware directly; the
> data will also be published to d-bus for other modules to consume, like
> fansensor from dbus-sensors.

To some extent, this design revolves around flexibility.  Fans aren't
necessarily tacho devices, and sensors aren't necessarily hwmon devices, so
dbus is used as an abstraction to be able to make them all look the same.
For example, an NCSI NIC might have both a temperature and a fan that
phosphor-pid-control might want to control, but we don't want
phosphor-pid-control to take a dependency on NCSI.  While we could put all
code for all possible sensor types into one daemon, that opens us up to the
possibility that crashes could take down all of fan and thermal control,
including the failsafe behavior.  That would be an issue.

It might be possible to handle these issues in a single daemon, but I
haven't really seen a design that covered all the cases;  Most
implementations tend to take the simple approach (hwmon sensor + tacho
device) and ignore the more complex setups.

> Does it make sense to do that? Or is there any reason for the current
> design?
> I'm new to OpenBMC and some of my understanding may be totally wrong.
> Looking forward to your expert advice.
> Thanks,
> Heyi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openbmc mailing list