frudevice: Determine FRU write offset

This commit introduces the use of findFruHeader during the write
operation to accurately locate and set the correct offset for writing
FRU data. This ensures th

frudevice: Determine FRU write offset

This commit introduces the use of findFruHeader during the write
operation to accurately locate and set the correct offset for writing
FRU data. This ensures that the written FRU information is placed at
the correct location within the EEPROM, avoiding potential issues such
as overwriting unrelated data.

Change-Id: Ifd3a572420f59a9189fff39aaa2b8678bf8217a7
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>

show more ...

Detect how many address bytes needed for a given EEPROM memory

Introduce different modes to detect how many address byte(s) needed
for a given EEPROM device.

MODE_1:
-------
The existing upstream f

Detect how many address bytes needed for a given EEPROM memory

Introduce different modes to detect how many address byte(s) needed
for a given EEPROM device.

MODE_1:
-------
The existing upstream function isDevice16Bit() bases on sending
1-byte write operation (with a STOP condition) and 8 subsequent
1-byte read operations with SINGLE byte address.

1. This MODE_1 expects the following logic:
- if the device requires 1 address byte, it EXPECTS that the data
will be read from a single location so 8 bytes read will be the
same.
- if the device requires 2 address bytes, it EXPECTS that the data
will be read from 8 DIFFERENT LOCATIONS and at least one byte
read is different than 7 other reads.

2. Issue and potential issue with this MODE_1
- If any "2 address bytes" EEPROM from any vendor has the same data
in all memory locations (0-7) the existing upstream function read,
this device will be identified as "1 address byte" device.
- ONSEMI EEPROM (a 2 address bytes device) return the same data from
the same single byte address read --> therefore, existing function
wrongly identifies it as 1 byte address device.

MODE_2:
-------
The proposal MODE_2 changes to isDevice16Bit() sends 8 instructions
of 2-bytes write operation (WITHOUT a STOP condition ie. prohibited
STOP) followed by a 1-byte read operation. The proposed solution
fully complies with

IIC standard and should be applicable to any IIC EEPROM manufacturer.

| Start | SlaveAddr + W | 0x00 | 0x00 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
|-------|---------------|------|------|----------------------|-------|
--------------|-----------|------|
| Start | SlaveAddr + W | 0x00 | 0x01 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x02 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x03 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x04 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x05 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x06 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x07 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |

1. If the device requires a single data byte, then it will always
load address 0x00, so the subsequent read byte will be the same for
all 8 instructions. The second byte on the write would be interpreted
as data byte, thus not modifying the address pointer.

2. If two address bytes are required, then the device will interpret
both bytes as addresses, thus reading from different addresses every
time, similar with what the existing function is using now.

Notes & reasons:
-----------------
There is no STOP condition after the second (potential) address byte.
A START condition must be sent after the second byte.
If STOP condition is sent, then the 1-byte address devices will start
internal write cycle, altering the EEPROM content which is not good.

This proposal MODE_2 suffers the same 1st issue (#2a) as before (what
if the EEPROM has the same data at all those addresses).
However, this proposal MODE_2 addresses the 2nd issue (#2b)
where existing MODE_1 upstream function EXPECTS that the data will
be read from 8 DIFFERENT LOCATIONS if the device requires 2 address
bytes. This expectation is the ambiguity (not standard defined) in
the IIC spec
(https://www.nxp.com/docs/en/user-guide/UM10204.pdf)

1. Section 3.1.10, Note 2 -> "All decisions on auto-increment or
decrement of previously accessed memory locations, etc., are taken by
the designer of the device."
Based on this note, the designer of every EEPROM has the "freedom"
to use whatever architecture considers appropriate and suitable to
process everyone of the two address bytes. There are no restrictions
on this.

Based on this, the others EEPROM (not ONSEMI EEPROM) auto-increment -
observed with one address byte sent instead of two - is a
manufacturer-specific behavior, and not standard defined.

2. Section 3.1.10, Note 1 -> "Combined formats can be used, for
example, to control a serial memory. The internal memory location
must be written during the first data byte. After the START
condition and slave address is repeated, data can be transferred."

This proposal MODE_2 implements this note. The memory location
referred herein is the address pointer, as being the first data
byte in I2C communication. Based on this note, EEPROM must update
this pointer immediately following this first address byte.

Tested:
--------
1. With ONSEMI I2C eeprom memory on Nvidia Bluefield-3 HCA
a. Without this patch or with this patch MODE_1

root@dpu-bmc:~# ipmitool fru
FRU Device Description : Builtin FRU Device (ID 0)
Device not present (Requested sensor, data, or record not found)

FRU Device Description : Nvidia-BMCMezz (ID 169)
Board Mfg Date : Thu May 11 13:00:00 2023 UTC
Board Mfg : Nvidia
Board Product : Nvidia-BMCMezz
Board Serial : MT2319XZ04K6
Board Part Number : 900-9D3B6-00CV-AA0

b. With this patch MODE_2

root@dpu-bmc:~# ipmitool fru
FRU Device Description : Builtin FRU Device (ID 0)
Chassis Type : Main Server Chassis
Chassis Part Number : 900-9D3B6-00CV-AA0
Chassis Serial : MT2319XZ04K6
Chassis Extra : N/A
Chassis Extra : N/A
Chassis Extra : N/A
Chassis Area Checksum : OK
Board Mfg Date : Thu May 11 13:00:00 2023 UTC
Board Mfg : N/A
Board Product : N/A
Board Serial : MT2319XZ04K6
Board Part Number : 900-9D3B6-00CV-AA0
Board Extra : N/A
Board Area Checksum : OK
Product Manufacturer : N/A
Product Name : N/A
Product Part Number : 900-9D3B6-00CV-AA0
Product Serial : MT2319XZ04K6
Product Asset Tag : N/A
Product Extra : N/A
Product Area Checksum : OK

FRU Device Description : Nvidia-BMCMezz (ID 169)
Board Mfg Date : Thu May 11 13:00:00 2023 UTC
Board Mfg : Nvidia
Board Product : Nvidia-BMCMezz
Board Serial : MT2319XZ04K6
Board Part Number : 900-9D3B6-00CV-AA0
Board Area Checksum : OK

2. With other I2C eeprom memory on Nvidia Bluefield-3 HCA, and
without this patch or with this patch on both MODE_1/MODE_2

root@dpu-bmc:~# ipmitool fru
FRU Device Description : Builtin FRU Device (ID 0)
Chassis Type : Main Server Chassis
Chassis Part Number : 900-9D3B4-00EN-EAA
Chassis Serial : MT2315XZ0599
Chassis Extra : N/A
Chassis Extra : N/A
Chassis Extra : N/A
Chassis Area Checksum : OK
Board Mfg Date : Tue Apr 18 10:25:00 2023 UTC
Board Mfg : N/A
Board Product : N/A
Board Serial : MT2315XZ0599
Board Part Number : 900-9D3B4-00EN-EAA
Board Extra : N/A
Board Area Checksum : OK
Product Manufacturer : N/A
Product Name : N/A
Product Part Number : 900-9D3B4-00EN-EAA
Product Version : N/A
Product Serial : MT2315XZ0599
Product Asset Tag : N/A
Product Extra : N/A
Product Area Checksum : OK

FRU Device Description : Nvidia-BMCMezz (ID 169)
Board Mfg Date : Tue Apr 18 10:25:00 2023 UTC
Board Mfg : Nvidia
Board Product : Nvidia-BMCMezz
Board Serial : MT2315XZ0599
Board Part Number : 900-9D3B4-00EN-EAA
Board Area Checksum : OK

Change-Id: I296c22334c919f4248fb3a7f19e384ce802cba17
Signed-off-by: Vu Pham <vuhuong@nvidia.com>

show more ...

clang-format: re-format for clang-19

clang-format-19 isn't compatible with the clang-format-18 output, so we
need to reformat the code with the latest version. A few parameters
in clang-tidy have b

clang-format: re-format for clang-19

clang-format-19 isn't compatible with the clang-format-18 output, so we
need to reformat the code with the latest version. A few parameters
in clang-tidy have been deprecated, so adjust the style file
accordingly.

See Ie2f6eb3b043f2d655c9df806815afd7971fd0947 for updated style.
See I88192b41ab7a95599a90915013579608af7bc56f for clang-19 enablement.

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

show more ...

Strip extra spaces from fru

Trailing spaces were discovered in the FRU EEPROM of some SSDs, which
should not originally appear in the device. Strip the trailing spaces
in case that one gets the prop

Strip extra spaces from fru

Trailing spaces were discovered in the FRU EEPROM of some SSDs, which
should not originally appear in the device. Strip the trailing spaces
in case that one gets the properties about FRU with unnecessary spaces.

Tested:
before the CL added:

curl http://localhost/redfish/v1/Chassis/SSD_NVMe_2/ | \
grep -E "PartNumber|SerialNumber"
% Total % Received % Xferd Average Speed Time Time Time
Dload Upload Total Spent Left
100 1661 100 1661 0 0 104k 0 --:--:-- --:--:-- --:--:--
"PartNumber": "MZWLO7T6HBLA-01AGG ",
"SerialNumber": "S7BVNE0W900253 ",

After after CL added :

curl http://localhost/redfish/v1/Chassis/SSD_NVMe_2/ | \
grep -E "PartNumber|SerialNumber"
% Total % Received % Xferd Average Speed Time Time Time
Dload Upload Total Spent Left
100 1661 100 1661 0 0 98739 0 --:--:-- --:--:-- --:--:--
"PartNumber": "MZWLO7T6HBLA-01AGG",
"SerialNumber": "S7BVNE0W900253"

Change-Id: I4faf5b4fa62f2330ed0d12f41b552af41ce7dd9a
Signed-off-by: Brian Chiang <chiang.brian@inventec.com>

show more ...

Fix threshold probability loss

During bmc reset stress testing, some sensors occasionally lose
thresholds, and the lost thresholds are not created on DBus.

This is because when EM loads the json fi

Fix threshold probability loss

During bmc reset stress testing, some sensors occasionally lose
thresholds, and the lost thresholds are not created on DBus.

This is because when EM loads the json file and creates interface,
dbus-sensors may have listened and started to create the sensor just
after the `Type` interface is created but before the threshold
interface is created. This is the sensor interface obtained from EM
and does not include the threshold interface. Therefore, the sensor
displayed on DBus does not have a threshold interface.

This commit changes the order of creating interfaces in EM. The Type
interface should be created after the Threshold interface is created.
This is because for the callback method of dbus-sensors, when the
Type interface is created, it is considered that all configurations
of this sensor have been loaded.

Tested:
The bmc reset stress test did not reproduce this issue.

Signed-off-by: George Liu <liuxiwei@ieisystem.com>
Change-Id: Ia8d9e24a8697992cab13aecb35438f142ed29e67

show more ...

service: device-tree node vpd to d-bus hw id data

A daemon for transferring Viable Product Data (VPD) from device-tree
nodes to D-Bus as described in the design doc @
https://gerrit.openbmc.org/c/op

service: device-tree node vpd to d-bus hw id data

A daemon for transferring Viable Product Data (VPD) from device-tree
nodes to D-Bus as described in the design doc @
https://gerrit.openbmc.org/c/openbmc/docs/+/66369

and discussed in this Technical Oversight Forum topic @
https://github.com/openbmc/technical-oversight-forum/issues/38

Tested:
Ensure 'model' and/or 'serial-number' nodes are populated in
/proc/device-tree. Can be hardcoded into platform DTS via
linux-kernel recipe if needed.

'''
After OBMC boot, calling
> busctl introspect xyz.openbmc_project.MachineContext /xyz/openbmc_project/MachineContext

produces the following output:

NAME TYPE SIGNATURE RESULT/VALUE FLAGS
...
xyz.openbmc_project.Inventory.Decorator.Asset interface - - -
.BuildDate property s "" emits-change writable
.Manufacturer property s "" emits-change writable
.Model property s "hpe,dl360" emits-change writable
.PartNumber property s "" emits-change writable
.SerialNumber property s "t5texpl" emits-change writable
...

Note: Writing to one of these properties will update the property on D-Bus without affecting the
underlying device-tree node. An 'updated' event will be fired, so Entity-Manager probes monitoring
a given property would recognize the new value and key off it.
'''

Change-Id: Id52d1fc3b26010c864c7e64d3dfdf0a2b5de9294
Signed-off-by: Chris Sides <Christopher.Sides@hpe.com>

show more ...

meson: use phosphor-logging for debug statements

There is no need to individually patch each file to enable debug
logging.

All the different definitions of 'bool debug' are removed in favor of
usin

meson: use phosphor-logging for debug statements

There is no need to individually patch each file to enable debug
logging.

All the different definitions of 'bool debug' are removed in favor of
using phosphor-logging.

Change-Id: Ia9a8ecfa4ea220f588d7cf2d291b14067e0391e7
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

Reducing expire time in propertiesChangedCallback

This code change is related to the code review,
https://gerrit.openbmc.org/c/openbmc/phosphor-led-manager/+/66774

Where “Phosphor LED Manager” app

Reducing expire time in propertiesChangedCallback

This code change is related to the code review,
https://gerrit.openbmc.org/c/openbmc/phosphor-led-manager/+/66774

Where “Phosphor LED Manager” app was waiting to read interface
value from DBus hosted by EntityManager to find out its system type.
It caused more delay in loading appropriate system JSON file, hence
“Phosphor LED Manager” app missing early faulty FRU notifications.

To fix this issue, reading system type from device tree is introduced.
For this, code reviewer asked to check what was causing delay in
EntityManager and asked to improve efficiency of EM if possible.

For this suggestion, tested EntityManager with varying delays in
propertiesChangedCallback api, ranging from 5 seconds to
500 milliseconds on IBM systems.
Observed improved performance in creating interfaces for matching
probes with a 500 millisecond delay.

Decided to retain the 500 millisecond delay to avoid altering the
system's behavior significantly. This delay should not impact
other systems. The choice of 500 milliseconds is arbitrary but based
on observed performance improvements.

Testing:
With the change observed EM is starting fine, observed no error on log
and publishes all its matched interfaces on DBus. And all other system
services are up and running on reboot.

Change-Id: I2e1528e408686d80476b9c834d6c2735dcadff22
Signed-off-by: Anupama B R <anupama.b.r1@ibm.com>

show more ...

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

show more ...

fru_reader: add header for off_t

GCC-14 with the latest Yocto refresh give the following compile
failure:

```
| ../git/src/fru_reader.hpp:36:27: error: 'off_t' was not declared in this scope
| 3

fru_reader: add header for off_t

GCC-14 with the latest Yocto refresh give the following compile
failure:

```
| ../git/src/fru_reader.hpp:36:27: error: 'off_t' was not declared in this scope
| 36 | std::function<int64_t(off_t offset, size_t len, uint8_t* outbuf)>;
```

This appears to be defined in `stdio.h`, so include `<cstdio>`.

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

show more ...

meson: change install_dir to /usr/libexec/entity-manager

We notice a issue that if user accidentally execute fru-device and
terminate it after few second, the xyz.openbmc_project.FruDevice
busname w

meson: change install_dir to /usr/libexec/entity-manager

We notice a issue that if user accidentally execute fru-device and
terminate it after few second, the xyz.openbmc_project.FruDevice
busname will not exist on dbus, but the status of FruDevice.service is
still active running.

It because sdbusplus changes the behavior of request_name() and it
allows the busname can be replaced by new service. [1]

In order to avoid unexpected behavior by running service binary
accidentally, move the install_dir to /usr/libexec/entity-manager.

Tested result:
- EntityManager is still running normally after the change
```
root@bmc:~# systemctl status xyz.openbmc_project.EntityManager.service
● xyz.openbmc_project.EntityManager.service - Entity Manager
Loaded: loaded (/usr/lib/systemd/system/xyz.openbmc_project.EntityManager.service; enabled; preset: enabled)
Active: active (running) since Wed 2024-03-20 23:25:44 PDT; 27min ago
Process: 596 ExecStartPre=/bin/mkdir -p /var/configuration (code=exited, status=0/SUCCESS)
Process: 679 ExecStartPre=/bin/mkdir -p /tmp/overlays (code=exited, status=0/SUCCESS)
Main PID: 687 (entity-manager)
CPU: 7.203s
CGroup: /system.slice/xyz.openbmc_project.EntityManager.service
└─687 /usr/libexec/entity-manager/entity-manager
```
- FruDevice is still running normally after the change
```
root@bmc:~# systemctl status xyz.openbmc_project.FruDevice.service
● xyz.openbmc_project.FruDevice.service - Fru Device
Loaded: loaded (/usr/lib/systemd/system/xyz.openbmc_project.FruDevice.service; enabled; preset: enabled)
Active: active (running) since Wed 2024-03-20 23:25:40 PDT; 28min ago
Main PID: 598 (fru-device)
CPU: 729ms
CGroup: /system.slice/xyz.openbmc_project.FruDevice.service
└─598 /usr/libexec/entity-manager/fru-device
```

[1] https://github.com/openbmc/sdbusplus/commit/946c940434a7d5403f469ce2ab56f9136293ff38

Signed-off-by: Potin Lai <potin.lai@quantatw.com>
Change-Id: I01c1f0fe7a1bdbaf74ec4d080b62450f4a90a057

show more ...

Make fru-device produce Mfg date in ISO8601 format

Modify the time format of BOARD_MANUFACTURE_DATE in fru-device to
ISO8601 format.

Tested:
```
root@bmc:~# busctl introspect xyz.openbmc_project.Fr

Make fru-device produce Mfg date in ISO8601 format

Modify the time format of BOARD_MANUFACTURE_DATE in fru-device to
ISO8601 format.

Tested:
```
root@bmc:~# busctl introspect xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/Minerva_CMM_EVT2
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
...
xyz.openbmc_project.FruDevice interface - - -
.ADDRESS property u 84 emits-change
.BOARD_FRU_VERSION_ID property s "FRU Ver 0.01" emits-change
.BOARD_INFO_AM1 property s "19-100140" emits-change
.BOARD_INFO_AM2 property s "TOD-TDT" emits-change
.BOARD_INFO_AM3 property s "D1KI6" emits-change
.BOARD_LANGUAGE_CODE property s "25" emits-change
.BOARD_MANUFACTURER property s "Quanta" emits-change
.BOARD_MANUFACTURE_DATE property s "20240509T053800Z" emits-change
...

```

Change-Id: Ie2bcd60e4973ada81885df299fdfe132fe242828
Signed-off-by: Yi-Shum <EasonChen1@quantatw.com>

show more ...

Update clang-tidy

Fix a bunch of minor issues, ignore others. We use a lot of global
variables. Enabling a check will hopefully make sure we don't add more.

Change-Id: Ie76053d4afc95a5372b70b2fb7

Update clang-tidy

Fix a bunch of minor issues, ignore others. We use a lot of global
variables. Enabling a check will hopefully make sure we don't add more.

Change-Id: Ie76053d4afc95a5372b70b2fb768be464468cec0
Signed-off-by: Ed Tanous <ed@tanous.net>

show more ...

Add clang tidy check

Change-Id: I1c9f03e95aa0ca1977ddef84ea765222d2281b4f

topology: Add powered_by topology

bmcweb already support the power supply command, refer to
https://gerrit.openbmc.org/c/openbmc/bmcweb/+/57668

Use "PowerPort" to add the powered_by association for

topology: Add powered_by topology

bmcweb already support the power supply command, refer to
https://gerrit.openbmc.org/c/openbmc/bmcweb/+/57668

Use "PowerPort" to add the powered_by association for upstream port, so
that the PowerSupplyCollection in redfish can get the power supply
information.

Tested:
Add the following config in mobo.json:
```
{
"Name": "Mobo Upstream Port",
"Type": "Mobo Upstream Port"
},
```
Add the following config in PSU.json:
```
{
"ConnectsToType": "Mobo Upstream Port",
"Name": "PSU $BUS Downstream Port",
"Type": "DownstreamPort",
"PowerPort": true
},
```
Result for association:
```
{
"type" : "as",
"data" : [
[
"/xyz/openbmc_project/inventory/system/board/PSU_1"
]
]
}
```
Result in bmcweb:
```
$ curl -s -k -H "X-Auth-Token: $token" http://${bmc}/redfish/v1/Chassis/Mobo | jq .Links.Contains
[
{
"@odata.id": "/redfish/v1/Chassis/PSU_1"
}
]
$ curl -k -H "X-Auth-Token: $token" http://${bmc}/redfish/v1/Chassis/Mobo/PowerSubsystem/PowerSupplies/PSU_1
{
"@odata.id": "/redfish/v1/Chassis/Mobo/PowerSubsystem/PowerSupplies/PSU_1",
"@odata.type": "#PowerSupply.v1_5_0.PowerSupply",
...
}
```

Run unitest for test_topology is PASSED.

Change-Id: Iad10e61417437a41628cf311cdd7893725a5dcde
Signed-off-by: Jeff Lin <JeffLin2@quantatw.com>

show more ...

Call linkMux after async buildDevice

linkMux is supposed to only be called after buildDevice returns
successfully, but the latter function may return success even when it
fails and retries asynchron

Call linkMux after async buildDevice

linkMux is supposed to only be called after buildDevice returns
successfully, but the latter function may return success even when it
fails and retries asynchronously. We need to move the linkMux call into
buildDevice to always be called at the right time.

Tested: Confirmed channel name links were created for a mux device.

Change-Id: I67657250e392e0db92e562eac130ca85e5a022e7
Signed-off-by: Jonathan Doman <jonathan.doman@intel.com>

show more ...

Support C-style comments for configuration JSON parsing

1. Add and set ignore_comment to true to all nlohmann::json::parse().
2. Add remove_c_comments() in `validate_configs.py` to remove C-style

Support C-style comments for configuration JSON parsing

1. Add and set ignore_comment to true to all nlohmann::json::parse().
2. Add remove_c_comments() in `validate_configs.py` to remove C-style
comments before loading.
3. Attempt to reformat comments in the `autojson.py` taking liberal
short-cuts which are documented in the script.

Supported comment examples:

- Single-line style comments
```
{
// Single-line style comment (new line)
"Key": "Value" // Single-line comment (end of content)
}
```

- Multi-line style comments
```
{
/* Multi-line style comment */
/*
* Multi-line style comments
*/
}
```

Tested on harma system with manual applied patch below, which contains
a c-style comment in harma-pttv.json file.
Link: https://gerrit.openbmc.org/c/openbmc/entity-manager/+/67469/25

- scripts/autojson.py
Run autojson.py on harma-pttv.json, the output as same as original file.

- scripts/validate_configs.py
Run validate_configs.py passed.

- EntityManager service
EntityManager service loads and probes harma-pttv.json successfully.
```
root@harma:~# busctl introspect xyz.openbmc_project.EntityManager \
> /xyz/openbmc_project/inventory/system/board/Harma_PTTV \
> xyz.openbmc_project.Inventory.Item.Board
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
.Name property s "Harma PTTV" emits-change
.Probe property s "xyz.openbmc_project.FruDevice({\'BOA... emits-change
.Type property s "Board" emits-change
```

Signed-off-by: Potin Lai <potin.lai@quantatw.com>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ib235f2aa6a724615dc4c8184577f57abda8e17a6

show more ...

Update terminology used within repo

Change terms to more inclusive language. This update is only for
variables that are internal.

Change-Id: I91c44d1f9513c9a4ef52352d5842e1fe9e8f4f8d
Signed-off-by

Update terminology used within repo

Change terms to more inclusive language. This update is only for
variables that are internal.

Change-Id: I91c44d1f9513c9a4ef52352d5842e1fe9e8f4f8d
Signed-off-by: Matt Simmering <matthew.simmering@intel.com>

show more ...

Remove the old dbus interfaces for one i2c bus rescan

During the one bus re-scanning,
the previous found bus interfaces should be removed too.

Tested:
Trigger the one i2c bus re-scan dbus call, no

Remove the old dbus interfaces for one i2c bus rescan

During the one bus re-scanning,
the previous found bus interfaces should be removed too.

Tested:
Trigger the one i2c bus re-scan dbus call, no errors,
and ipmitool fru print still works.

Change-Id: If33a34e98fe634d30f1867bf02877ac268797ef4
Signed-off-by: Yong Li <yong.b.li@linux.intel.com>

show more ...

Add error handling wrapper for sdbusplus init

There are several places that (sdbusplus::asio::dbus_interface) iface
throws an unhandled expeciton. This change adds a wrapper to handle
these expectio

Add error handling wrapper for sdbusplus init

There are several places that (sdbusplus::asio::dbus_interface) iface
throws an unhandled expeciton. This change adds a wrapper to handle
these expection, and cerr a message.

Change-Id: I2964b43844a754c7aba7de40241faf730f908972
Signed-off-by: John Edward Broadbent <jebr@google.com>

show more ...

perform_probe: fix clang-tidy modernize-use-emplace warning

Fix the following warning with clang-tidy-17:

```
../src/perform_probe.cpp:207:19: error: use emplace_back instead of push_back [moderniz

perform_probe: fix clang-tidy modernize-use-emplace warning

Fix the following warning with clang-tidy-17:

```
../src/perform_probe.cpp:207:19: error: use emplace_back instead of push_back [modernize-use-emplace,-warnings-as-errors]
207 | foundDevs.push_back(
| ^~~~~~~~~~
| emplace_back(
208 | {boost::container::flat_map<std::string, DBusValueVariant>{},
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
209 | std::string{}});
| ~~~~~~~~~~~~~~
```

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

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

show more ...

Extend blacklist function for address.

Currently, blacklist only support for blocking a entire bus from
scanning by FruDevice. This extension makes user can specify certain
addresses on i2c bus.

Ex

Extend blacklist function for address.

Currently, blacklist only support for blocking a entire bus from
scanning by FruDevice. This extension makes user can specify certain
addresses on i2c bus.

Example :
{
"buses": [
10,
12,
{
"bus": 11,
"addresses": ["0x40", "0x44"]
}
]
}

User can put in number for blocking i2c buses and addresses on
certain bus.

Tested: Tested and verified systemd journal for function.
Change-Id: Ibdb8dd8c3b9593a0c5e0d60e9e765dbf82938dd7
Signed-off-by: Bonnie Lo <Bonnie_Lo@wiwynn.com>

show more ...

Refactor unnecessary shared_ptr usage

No need to use shared_ptr for a uint64_t. Instead just use optional to
check whether it was loaded from the JSON.

For devices without a Bus+Address specified,

Refactor unnecessary shared_ptr usage

No need to use shared_ptr for a uint64_t. Instead just use optional to
check whether it was loaded from the JSON.

For devices without a Bus+Address specified, skip the deviceIsCreated()
check and 5x retry, since there is no point to that for non-I2C devices.

Tested: Confirmed EM still creates/probes an i2c device exposed in an
active config. For a test INA219 device exposed without an Address,
confirmed that the kernel error message (i2c i2c-x: new_device: Can't
parse I2C address) is only output once instead of 5 times.

Change-Id: Ib3778559235b19d9846b3bb973a795e82e37b123
Signed-off-by: Jonathan Doman <jonathan.doman@intel.com>

show more ...

fru-device: Remove the use of mktime

mktime get the time in localtime and will mess up the time if the
timezone != UTC. The FRU data should be the raw data in UTC and the
reader will convert to loca

fru-device: Remove the use of mktime

mktime get the time in localtime and will mess up the time if the
timezone != UTC. The FRU data should be the raw data in UTC and the
reader will convert to localtime at their end.

This issue is detected when we change the timezone to PST/PDT with
https://gerrit.openbmc.org/c/openbmc/openbmc/+/58293
and the FRU EEPROM time does not match the expected Mfg Date anymore.

Used the timestamp of 1/1/1996 UTC directly.

Data Reader:
https://gerrit.openbmc.org/c/openbmc/phosphor-host-ipmid/+/58466

Tested:
Fru EEPROM Mfg Time now is in the same (after timezone conversion)
between the raw data and FRU output.

Change-Id: I48f9233ee96b676428ba9e9f9f6b34d3da74e612
Signed-off-by: Willy Tu <wltu@google.com>

show more ...