clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda forma

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda formatting also changed, so we have made changes to the
organization default style format to better handle lambda formatting.

See I5e08687e696dd240402a2780158664b7113def0e for updated style.
See Iea0776aaa7edd483fa395e23de25ebf5a6288f71 for clang-18 enablement.

Change-Id: I0f105c3310e87172c65a09a8787a2db5a4041cc0
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

Modified the naming to get the value of checkhysterwithsetpt

Modified the naming to get the value of checkhysterwithsetpt in dbus
configuration and json configuration.

Change-Id: Ic9cc6a6bfd0da69ac

Modified the naming to get the value of checkhysterwithsetpt

Modified the naming to get the value of checkhysterwithsetpt in dbus
configuration and json configuration.

Change-Id: Ic9cc6a6bfd0da69acc1638ca7ebd6712211e2984
Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>

show more ...

Support to accumulate PWM of different controllers for same sensor

Description:
1. Add one property: accumulateSetPoint in zone of fan table that could
be used to enable accumulation of output PW

Support to accumulate PWM of different controllers for same sensor

Description:
1. Add one property: accumulateSetPoint in zone of fan table that could
be used to enable accumulation of output PWM of different controllers
with same sensor.

2. Add one property: checkHysterWithSetpt in pid info of fan table to
select to compare current input and setpoint to check hysteresis.

3. The purpose of accumulate the stepwise output and PID output for
one sensor is that the setting of stepwise could use to prevent
the fan speed from suddenly increasing from a very low speed to a
very high speed due to reaching the setpoint.

Use stepwise before setpoint could also keep the PWM steady at
low ambient temperature.

Design:
1. Search "accumulateSetPoint" field in fan table.
If the value was true, accumulate the output PWM of different
controllers with same profile name.

2. Support two method to calculate PID output that could be chosen by
setting the "checkHysterWithSetpt" to true in pid info of fan table.

If the flag was set to true, it won't calculate PWM output if the
input lower than setpoint.

Test Case:
1. Check the output PWM of different controllers with same profile
name could be accumulated - pass.

2. Set "checkHysterWithSetpt" to true and check PID output would not be
calculated if the input temperature was lower than setpoint - pass.

Please see more details in gist:
https://gist.github.com/DelphineCCChiu/a6170d3e1a12fc4ee76fad324382fba3

Change-Id: I9f38f250d72545784c6c11be2fde7d45f0b385c4
Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>

show more ...

Add MissingIsAcceptable feature to avoid failsafe

This is a partial implementation of the ideas here:
https://github.com/openbmc/phosphor-pid-control/issues/31

A new configuration item is supported

Add MissingIsAcceptable feature to avoid failsafe

This is a partial implementation of the ideas here:
https://github.com/openbmc/phosphor-pid-control/issues/31

A new configuration item is supported in the PID object, named
"MissingIsAcceptable" (for D-Bus) or "missingIsAcceptable" (for the old
config.json). The value is an array of strings. If these strings match
sensor names, those sensors will be flagged as "missing is acceptable",
that is, they can go missing and the zone will not be thrown into
failsafe mode as a result.

This can be handy for sensors that are not always available on your
particular machine. It is independent of the existing Availability
interface, because the decision to go into failsafe mode or not is a
property of the PID loop, not of the sensor itself.

If a PID loop consists of all sensors that are missing, the output
will be deemed to be the setpoint, thus essentially making the PID
loop a no-op. Now initializing sensor values to NaN, not zero, as zero
is not a good default if PID loop is margin, undoing a bug I made:
https://gerrit.openbmc.org/c/openbmc/phosphor-pid-control/+/38228

Tested: It worked for me. Also, added a unit test case.

Change-Id: Idc7978ab06fcc9ed8c6c9df9483101376e5df4d1
Signed-off-by: Josh Lehan <krellan@google.com>

show more ...

Implementing the TempToMargin feature

Wrapping the input name std::string in a new structure SensorInput, so
that the TempToMargin information can be cleanly carried along with
it, all the way down

Implementing the TempToMargin feature

Wrapping the input name std::string in a new structure SensorInput, so
that the TempToMargin information can be cleanly carried along with
it, all the way down to the PID input processing layer where it is
needed. This allows the conversion to be done just-in-time before the
temperature reading is interpreted, minimizing the blast radius of
this change. Nonetheless, because of the type change, there was a
somewhat large blast radius to implement this feature.

The design, and the documentation, is already here:
https://github.com/openbmc/phosphor-pid-control/issues/23

Tested: Added unit tests for JSON parsing and for proper execution
of the TempToMargin feature. They pass. Ran it locally, on our
appropriately-configured system, and it seems to work for me.

Change-Id: I598ba485195aaa70c26e91a1da3ab88fff8c3a4c
Signed-off-by: Josh Lehan <krellan@google.com>

show more ...

Set failsafePwm by pid configuration

<motivation>
Current phosphor-pid-control service supports one zone with
one failsafepwm. However, for some platforms there are
different pluggable cards in a zo

Set failsafePwm by pid configuration

<motivation>
Current phosphor-pid-control service supports one zone with
one failsafepwm. However, for some platforms there are
different pluggable cards in a zone. Different combinations
may require different failsafe pwm settings. Why not just
use one zone failsafepwm for all the combinations? because if
we take power consumption or acoustic into consideration,
we will find that not all the cases need the same high
failsafepwm. Each case just need high enough failsafepwm
to cool down the system in that condition.

For example
case1: zone0 : gpuA card + motherboard in zone0
=>requires failsafepwm = 80

case2: zone1 : gpuB card + motherboard in zone0
=>requires failsafepwm = 60

In order to solve the problem described above , we propose
the design that. Each pidloop has its own failsafepwm.
The final failsafepwm will be calculated during building
zone process. The detailed design concept is described in
design concept section.

<design concept>
a zone has several pid loops, each one has its own pid
failsafe pwm defined in its configuration.

The calculation flow goes as below:
1.Take failsafepwm of the pidloops and the zone from the configuration
files, if any is missing , set it to zero.
2.Take max value of (zone failsafepwm and pid loops failsafepwm).
3.If the max value from 'step 2' is zero indicates none of failsafepwm
is configured, set it to default setting 100%.

<note>
1.this is intended for dbus configuration method, since one zone
may have different pidloops from different pluggable boards
entity json, but this design also works for static configuration
method, therefore, the zone with different boards will need
different failsafepwm.
2.keep it back compatible with original design , also take zone
failsafepwm into calculation.

Working example as below

Case1
Zone0:
zone0 pidloop failsafepwm = 60
gpuA pidloop failsafepwm = 70
Motherboard failsafepwm = 40

=>final failsafepwm = 70

Case2
Zone0:
zone0 pidloop failsafepwm = 60
gpuB pidloop failsafepwm = 80
Motherboard failsafepwm = 40

=>final failsafepwm = 80

Change-Id: I5aa1c6a7108f4520f41de5d8eba3075d021bbe79
Signed-off-by: ykchiu <Chiu.YK@inventec.com>

show more ...

Allow disabling PID loops at runtime

<design concept>
Add the map of object enable interface to pid loops
in the zone then we can disable/enable each pid loop
process in a zone by dbus command.

[no

Allow disabling PID loops at runtime

<design concept>
Add the map of object enable interface to pid loops
in the zone then we can disable/enable each pid loop
process in a zone by dbus command.

[note]
Enable = true : enable process (default)
Enable = false : disable process

Tested:
In this case: we set Enable = false to disable
pidloop:Zone_Temp_0, and see how it affects
the zone final pwm, when pidloop: Zone_Temp_0
in zone 0 is disabled.

then even we are trying to heat up the temperature
of a sensor: Temp_0 in pidloop: Zone_Temp_0, this
set point of the pidloop will not be taken into the
calculation for the final set point of the whole zone.

```
<service object>
root@openbmc:/tmp# busctl tree xyz.openbmc_project.State.FanCtrl
`-/xyz
`-/xyz/openbmc_project
`-/xyz/openbmc_project/settings
`-/xyz/openbmc_project/settings/fanctrl
|-/xyz/openbmc_project/settings/fanctrl/zone0
| |-/xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp
| |-/xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp_0
| `-/xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp_1

====Enable process for pidloop:Zone_Temp_0 with p-switch temperature sensor:Temp_0 at runtime====
root@openbmc:~# busctl introspect xyz.openbmc_project.State.FanCtrl /xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp_0
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
xyz.openbmc_project.Object.Enable interface - - -
.Enabled property b true emits-change writable

====Disable process for pidloop:Zone_Temp_0 with p-switch temperature sensor: Temp_0====
root@openbmc:~# busctl set-property xyz.openbmc_project.State.FanCtrl /xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp_0 xyz.openbmc_project.Object.Enable Enabled b false
root@openbmc:~# busctl introspect xyz.openbmc_project.State.FanCtrl /xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp_0
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
xyz.openbmc_project.Object.Enable interface - - -
.Enabled property b false emits-change writable
```

when Disable the process of the pidloop: Zone_Temp_0,
the requester switches from Zone_Temp_0 to the others,
when you enable the pidloop: Zone_Temp_0, the setpoint
of Zone_Temp_0 will be take into consideration again

Change-Id: I95ae700144f0d16049fff8b309f05ae690a7ef72
Signed-off-by: ykchiu <Chiu.YK@inventec.com>

show more ...

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

Change-Id: Icbc50d46e84ee7ef756705e2b19741439a325074
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

Handle InterfacesRemoved signal under /xyz/openbmc_project/sensor path

Listen for InterfacesRemoved signal and restart control loops. Without
this, the pid loop may run with staled sensor value if t

Handle InterfacesRemoved signal under /xyz/openbmc_project/sensor path

Listen for InterfacesRemoved signal and restart control loops. Without
this, the pid loop may run with staled sensor value if the corresponding
object or interface is removed.

Tested:
...
PID Zone 0 max SetPoint 16800 requested by ...
PID Zone 0 max SetPoint 16800 requested by ...
<- systemctl stop xyz.openbmc_project.nvmesensor here ->
New configuration detected, reloading
.1 Failed during restartControlLoops, try again: wait for count back to 1
Zone Zone 1 is at ZoneIndex 1
Zone Zone 0 is at ZoneIndex 0
Zone Zone 2 is at ZoneIndex 2
...

Change-Id: I900edda48b71dc7b6ae79a4b51f4088aea69183a
Signed-off-by: Jinliang Wang <jinliangw@google.com>

show more ...

Skipping over Association Definitions messages

These incoming messages cause problems, for the same reason Assocation
is skipped over. They are not relevant to PID control, because they
are maintain

Skipping over Association Definitions messages

These incoming messages cause problems, for the same reason Assocation
is skipped over. They are not relevant to PID control, because they
are maintained by Object Mapper for another purpose. Treating
Association Definitions similarly to Associations, namely, skipping
them over. It looks like this was simply omitted in the past, perhaps
Definitions did not exist then, only Associations.
Also adding some optional logging.

Thanks to Chu Lin for originally discovering this bug and creating
this fix.

Tested: It works, and avoids the problem of unwanted messages causing
swampd to needlessly restart itself internally.

Change-Id: I2f9cb123990d240b515d08138dd919312aac5a30
Signed-off-by: Josh Lehan <krellan@google.com>

show more ...

Replace some duplicate codes about time setting

- Replace duplicate codes in pid/buildjson.cpp and dbusconfiguration.cpp

TEST:
D-Bus config =>
{
"FailSafePercent": 90.0,

Replace some duplicate codes about time setting

- Replace duplicate codes in pid/buildjson.cpp and dbusconfiguration.cpp

TEST:
D-Bus config =>
{
"FailSafePercent": 90.0,
"MinThermalOutput": 0.0,
"CycleIntervalTimeMS": 101,
"UpdateThermalsTimeMS": 1000,
"Name": "Zone 0",
"Type": "Pid.Zone",
"ZoneIndex": 0
},
{
"FailSafePercent": 90.0,
"MinThermalOutput": 0.0,
"CycleIntervalTimeMS": 100,
"Name": "Zone 1",
"Type": "Pid.Zone",
"ZoneIndex": 1
},
{
"FailSafePercent": 100.0,
"MinThermalOutput": 0.0,
"UpdateThermalsTimeMS": -1000,
"Name": "Zone 2",
"Type": "Pid.Zone",
"ZoneIndex": 2
},

pid journal log =>
Mar 09 04:49:23 qbmc swampd[4823]: Zone 1: UpdateThermalsTimeMS cannot
find setting. Use default 1000 ms
Mar 09 04:49:24 qbmc swampd[4823]: Zone 2: CycleIntervalTimeMS cannot
find setting. Use default 100 ms
Mar 09 04:49:24 qbmc swampd[4823]: Zone 2: UpdateThermalsTimeMS is
invalid. Use default 1000 ms

Static JSON =>
{
"id": 0,
"minThermalOutput": 0.0,
"failsafePercent": 100.0,
"cycleIntervalTimeMS": 100,
"updateThermalsTimeMS": 1000,
...
...
{
"id": 1,
"minThermalOutput": 0.0,
"failsafePercent": 100.0,
"updateThermalsTimeMS": 0,

pid journal log =>
Mar 09 04:38:44 qbmc swampd[10646]: Zone 1: cycleIntervalTimeMS cannot
find setting. Use default 100 ms
Mar 09 04:38:44 qbmc swampd[10646]: Zone 1: updateThermalsTimeMS is
invalid. Use default 1000 ms

Change-Id: I75d272d9458978790d2b8fe2def35a0e6ba126b0
Signed-off-by: Harvey Wu <Harvey.Wu@quantatw.com>

show more ...

Fix interval calculation bug and D-Bus init

The new timing parameters were not settable from the D-Bus code path,
only from the old static JSON code path. Also, the divison would not
occur, causing

Fix interval calculation bug and D-Bus init

The new timing parameters were not settable from the D-Bus code path,
only from the old static JSON code path. Also, the divison would not
occur, causing the variable to remain at 1000 by default, not 10,
causing the thermal intervals to run 100 times slower than intended!

I fixed the algorithm used to calculate when the thermal intervals
should be inserted amongst the fan intervals. Now, the division is
not necessary, and any value should work, so long as the thermal
interval is greater than or equal to the fan interval.

I also fixed a subtle bug regarding the timer scheduling. It was
reinitializing the timer expiration time from "now" each interval,
instead of cleanly incrementing from the original expiration. This
caused the timer to run slower than intended, as the execution time
of each interval would not be subtracted out from the remaining time
that needs to be waited for, as it should have been.

Tested: Default values, for timing parameters, now work as intended

Signed-off-by: Josh Lehan <krellan@google.com>
Change-Id: I759387b97af3ce93a76459faf5e9e7be3474016e

show more ...

Allow derivativeCoeff and DCoefficient optional

To avoid breaking existing configurations in the field, treat the
new "derivativeCoeff" parameter as optional, not mandatory.

This affects both the o

Allow derivativeCoeff and DCoefficient optional

To avoid breaking existing configurations in the field, treat the
new "derivativeCoeff" parameter as optional, not mandatory.

This affects both the old JSON parser, and the new D-Bus
entity-manager parser (it's called "DCoefficient" there).

Signed-off-by: Josh Lehan <krellan@google.com>
Change-Id: Ifcaf47d66e009b48e41b510a2ef1686b8860ad35

show more ...

Add new PID Class types "power" and "powersum"

Implements this feature:
https://github.com/openbmc/phosphor-pid-control/issues/24

In addition to the existing "temp" and "margin" classes, adding
new

Add new PID Class types "power" and "powersum"

Implements this feature:
https://github.com/openbmc/phosphor-pid-control/issues/24

In addition to the existing "temp" and "margin" classes, adding
new "power" and "powersum" Class types.

The "power" class is the same as "temp", but expects D-Bus power
sensors, instead of D-Bus temperature sensors.

The "powersum" class is the same as "power", but sums together all of
the given inputs, instead of finding the maximum.

Signed-off-by: Josh Lehan <krellan@google.com>
Change-Id: I11d8ad8385632658ed061671134be87a560cd02a

show more ...

dbusconfiguration: Init margin similar to temp

Adding "margin" PID class to the same initialization block that is
used by "temp", so they initialize similarly.

This patch used to do a lot more, now

dbusconfiguration: Init margin similar to temp

Adding "margin" PID class to the same initialization block that is
used by "temp", so they initialize similarly.

This patch used to do a lot more, now it is simplified. The other
changes, to the "timeout" and "ignoreDbusMinMax" settings, are no
longer necessary to make here, as they were quietly already made by
other patches since this was originally written, as the same bugs they
would fix were already noticed and fixed by other people as well.

Tested: Correct behavior (no timeout at all, because these are D-Bus
passive sensors, which operate on a push model, not being polled by a
timer). Without this fix, margin PID class wrongly still had timeout.

Signed-off-by: Josh Lehan <krellan@google.com>
Change-Id: Ibbf9294c249de9bc13a6449ea936ab0be4910dcc

show more ...

fix compile warning when meson build

- Fix compile warning:
[-Werror=unused-variable], [-Werror=sign-compare] and
deprecated INSTANTIATE_TEST_CASE_P

Signed-off-by: Harvey.Wu <Harvey.Wu@quantatw

fix compile warning when meson build

- Fix compile warning:
[-Werror=unused-variable], [-Werror=sign-compare] and
deprecated INSTANTIATE_TEST_CASE_P

Signed-off-by: Harvey.Wu <Harvey.Wu@quantatw.com>
Change-Id: If8713f0b938cd5306bbe19a9078731db0c3667dc

show more ...

Modified sensorConfig map index name about fan

- Like the phosphor-pid-control github issue #19,
if a fan is set as input sensor and has multiple output setting,
there are some problems when bui

Modified sensorConfig map index name about fan

- Like the phosphor-pid-control github issue #19,
if a fan is set as input sensor and has multiple output setting,
there are some problems when building sensorConfig map that
only have the last setting in sensorConfig map.

TEST:
https://gist.github.com/harveyquta/e2d3c91bf86299e5301bfb080711dbb4

Signed-off-by: Harvey.Wu <Harvey.Wu@quantatw.com>
Change-Id: I4f070888ce64c45a420467c6a07fcbd8312aa7a0

show more ...

sdbusplus: use shorter type aliases

The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are

sdbusplus: use shorter type aliases

The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are for:
* bus_t
* exception_t
* manager_t
* match_t
* message_t
* object_t
* slot_t

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ie36d234f4580029a7832a0cd179f3bb78a1a403f

show more ...

Make specific UNA sensors not trigger failsafe

By convention, sensors at some states like 'not present',
'power state not matching' are marked as 'unavailable' on dbus.
At such states, some specific

Make specific UNA sensors not trigger failsafe

By convention, sensors at some states like 'not present',
'power state not matching' are marked as 'unavailable' on dbus.
At such states, some specific sensors should not be considered as
failed and trigger pid 'failsafe'.

A typical example is when a system is powered-off, its CPU/DIMM temp
sensors are 'unavailable', these sensors should not be treated as
'failed' and trigger pid 'failsafe'. This is necessary for systems
whose Fans will keep working when the CPU is off.

This feature is configurable per sensor (valid on thermal sensors). It
can be enabled by setting the Pid controller option
"InputUnavailableAsFailed" to 'false' when one configuring the PID module
via entity-manager, or by setting the sensor option "unavailableAsFailed"
to 'false' when one configuring the PID module via JSON. (These options are
optional and default to 'true')

Tested:
1. On a Fan 'always-on' system, enabale this feature on CPU temp sensors,
poweroff the system, 'unavailable' CPU temp sensors do not trigger the
failsafe mode.
2. 'Unavailable' Fans still trigger the failsafe mode.
3. 'Unfunctional' or 'failed' sensors still trigger the failsafe mode.

Signed-off-by: Zheng Song <zheng.song@intel.com>
Change-Id: I1dd1d76466f43e7dcf51c161c96714f1bcfae88d

show more ...

catch exceptions as const

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Icea9b76115b6c3c7856574605ead3fedc0eca5d6

exception: switch to public sdbus exception

SdBusError was intended to be a private error type inside sdbusplus.
Switch all catch locations to use the general sdbusplus::exception type.

exception: switch to public sdbus exception

SdBusError was intended to be a private error type inside sdbusplus.
Switch all catch locations to use the general sdbusplus::exception type.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I16eeca31de290221c7a9184ee0c48cc923466832

show more ...

drop struct keyword for non-packed objects

As a style decision, struct is often used with packed structures to
indicate they are used like C-structs. Cleanup this codebase to not use

drop struct keyword for non-packed objects

As a style decision, struct is often used with packed structures to
indicate they are used like C-structs. Cleanup this codebase to not use
the extra struct keyword throughout.

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: I2f83bb1989e4d1f2f843ba3e45fb82e04f0fa61c

show more ...

dbus: parameterize dbusconfiguration init

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: I9cb6c0a19d4625d79da8613bd6eea13d6cc04220

dbus: move debugPrint to util

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: Idbea54f13527a4ca3108cc4dccbee07b7b3a7d34

dbus: move zone indexing to util

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: Ia6560a0e0f976dcf9f05004de68f74f5e313950b