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: Ica590f8613f1fb89ab1ca676ac51c1cc7e38d67f
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

clang-format: copy latest and re-format

clang-format-17 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-17 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: I3e9e6350864ac267819a4b8d670bef7d3746976e
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

Remove remaining fmt::format use

The only remaining use of the fmt::format library was for something
std::format can't yet handle, printing ranges. This was only used
twice, in the same file, so ju

Remove remaining fmt::format use

The only remaining use of the fmt::format library was for something
std::format can't yet handle, printing ranges. This was only used
twice, in the same file, so just manually build up the vectors in
question into a string and use std::format. This was already being done
in other places anyway.

Now the fmt::format subproject and dependencies can be completely
removed.

An added benefit is that those two fmt::format calls were failing to
build on my system when I was trying to build using subprojects, and
without them everything works.

Tested:
Can still see the traces, though I only have a 1 element vector to test
with:
Adding fan target lock of 11300 on fans [fan0] zone 0",

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I90055e9d1c8d0b79b151e1cfd0af2052005cef3c

show more ...

control: Trace which fan gets target locked

The override_fan_target action is used to lock a fan to a target in
certain cases. It was already tracing when this was occurring, but it
didn't say whic

control: Trace which fan gets target locked

The override_fan_target action is used to lock a fan to a target in
certain cases. It was already tracing when this was occurring, but it
didn't say which fan it was happening to. Add that information.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I074ddcbab32ff5606b7a1c7b3ceb03076a49ce30

show more ...

control: action to override a single fan in a zone - Action class

This change contains the OverrideFanTarget class to create the Action
from a json config. A very basic events.json would look like t

control: action to override a single fan in a zone - Action class

This change contains the OverrideFanTarget class to create the Action
from a json config. A very basic events.json would look like this:

[
{
"name": "test",
"groups": [
{ "name": "fan0 sensor inventory", "interface": "xyz.openbmc_project.State.Decorator.OperationalStatus",
"property": { "name": "Functional" } }
],
"triggers": [
{ "class": "init", "method": "get_properties" },
{ "class": "signal", "signal": "properties_changed" }
],
"actions": [ {
"name": "override_fan_target",
"count": 1,
"state": false,
"fans": [ "fan0", "fan2" ],
"target": 9999
} ]
}
]

When the tach sensor for fan0 is set to non-funtional:

root@p10bmc:~# busctl set-property xyz.openbmc_project.Inventory.Manager
/xyz/openbmc_project/inventory/system/chassis/motherboard/fan0/fan0_0
xyz.openbmc_project.State.Decorator.OperationalStatus Functional b false

the run() method for the Action is called and all registered fans will
be locked at the "target" value given in the json "actions" section.

...
<output trimmed>
...
FAN TARGET(RPM) FEEDBACKS(RPMS) PRESENT FUNCTIONAL
===============================================================
fan0 9999 7019/9999 true true
fan1 10000 7020/10000 true true
fan2 9999 7019/9999 true true
...

When the inventory registers the sensor back to functional, the override
lock is lifted and the fan is restored to its zone's current target.

Signed-off-by: Mike Capps <mikepcapps@gmail.com>
Change-Id: I6bf5bd55fd6eac2131aec02775a64ad287d3b3b0

show more ...