PEL: Update check for identifying I2C dev paths

Due to changes in the kernel, I2C device paths changed slightly and so
the code that identifies if a device path passed in for a callout is for
an I2C

PEL: Update check for identifying I2C dev paths

Due to changes in the kernel, I2C device paths changed slightly and so
the code that identifies if a device path passed in for a callout is for
an I2C device needs an update.

An example of a new canonical device path is:
```
/sys/devices/platform/ahb/1e780000.apb/1e780000.apb:bus@1e78a000/1e78a200.i2c/i2c-3/3-006d
```

Tested:
Creating a PEL with CALLOUT_DEVICE_PATH=/sys/bus/i2c/devices/3-006d on
an IBM Everest system generates a proper callout, as shown in this
captured PEL debug UserData section:

```
"I2C: bus: 3 address: 109 dest: /sys-0/node-0/bellavista-0/Power-riser-conn-0/Fansipan-0/power-supply-conn-2/power-supply-0/power-supply-blackbox-0"
```

Change-Id: I4efb9135982f417560172df99dfe36f98e3a9696
Signed-off-by: Matt Spinler <spinler@us.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: I21d2ca8065f24fd73509229c517f5caf48934b60
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

clang-format: update with latest

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

PEL: Support a default device callouts file

Normally, the device callouts code, which finds the callouts to use for
FRUs along a specific device path, will look for a JSON file to use by
looping thr

PEL: Support a default device callouts file

Normally, the device callouts code, which finds the callouts to use for
FRUs along a specific device path, will look for a JSON file to use by
looping through the list of compatible system names and adding
'_dev_callouts.json' to the name.

However at this point in time, the code that is supposed to populate
that list isn't done yet, so it will always be empty. In order to still
be able find a file, have it look for a default file called just
_dev_callouts.json after it tries and fails to find one based on system
name.

This file will be installed into the flash image from a bitbake recipe,
and eventually when that list of names field is populated, it can be
renamed in the recipe without having to make a code change here.

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

show more ...

PEL: devcallouts: Get callouts from the JSON

Using the functions that extract search keys from the device path, look
up the callouts in the appriopriate JSON entry and return them as a
vector of Cal

PEL: devcallouts: Get callouts from the JSON

Using the functions that extract search keys from the device path, look
up the callouts in the appriopriate JSON entry and return them as a
vector of Callout objects.

The first callout will have the 'debug' field filled in with the search
keys used and the MRW target name of the destination device. In the
future this will be added into a UserData section of a PEL with these
callouts to make debugging easier - i.e. making it easier to know what
device it was that failed when looking at the PEL.

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

show more ...

PEL: devcallouts: Extract search keys

In order to find the callouts for a device path, the search keys need to
be pulled out of the device path.

The keys are:
* I2C - bus and address
* FSI - link n

PEL: devcallouts: Extract search keys

In order to find the callouts for a device path, the search keys need to
be pulled out of the device path.

The keys are:
* I2C - bus and address
* FSI - link numbers
- Multiple link hops separated by dashes like "0-1"
* SPI - bus
* FSI-I2C - link numbers and I2C bus and address
* FSI-SPI - link numbers and SPI bus number

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

show more ...

PEL: devcallouts: Determine access type

Add a function to determine if the device path represents an I2C, FSI,
FSI-I2C, or FSI-SPI attached device.

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

PEL: devcallouts: Determine access type

Add a function to determine if the device path represents an I2C, FSI,
FSI-I2C, or FSI-SPI attached device.

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

show more ...

PEL: Add APIs to look up device path callouts

This commit adds the interfaces device_callouts::getCallouts() and
device_callouts::getI2CCallouts() that will be used to look up the FRU
callouts to ad

PEL: Add APIs to look up device path callouts

This commit adds the interfaces device_callouts::getCallouts() and
device_callouts::getI2CCallouts() that will be used to look up the FRU
callouts to add to PELs for errors stemming from accessing devices,
either by a sysfs path, or in the case of the latter interface an I2C
bus and address.

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

show more ...