All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed Tanous <edtanous@google.com>
To: Heyi Guo <guoheyi@linux.alibaba.com>
Cc: openbmc <openbmc@lists.ozlabs.org>
Subject: Re: Does it make sense to create a centralized fan control module?
Date: Wed, 16 Jun 2021 09:26:24 -0700	[thread overview]
Message-ID: <CAH2-KxBJkBA1G6J5iMJ8nPEaX6qbO0qQGQ4ujhZ-TrZPjAS7oQ@mail.gmail.com> (raw)
In-Reply-To: <f8e08249-d0e4-d632-c76b-495b8ce968d2@linux.alibaba.com>

[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]

On Thu, Jun 10, 2021 at 6:19 PM Heyi Guo <guoheyi@linux.alibaba.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2456 bytes --]

  parent reply	other threads:[~2021-06-16 16:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11  1:14 Heyi Guo
2021-06-11  1:23 ` Heyi Guo
2021-06-16  2:02   ` Heyi Guo
2021-06-16  2:49     ` [Phishing Risk] [External] " John Wang
2021-06-16 11:03       ` Heyi Guo
2021-06-16 16:26 ` Ed Tanous [this message]
2021-06-20  8:48   ` Heyi Guo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH2-KxBJkBA1G6J5iMJ8nPEaX6qbO0qQGQ4ujhZ-TrZPjAS7oQ@mail.gmail.com \
    --to=edtanous@google.com \
    --cc=guoheyi@linux.alibaba.com \
    --cc=openbmc@lists.ozlabs.org \
    --subject='Re: Does it make sense to create a centralized fan control module?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.