[PATCH 1/1] ofpathname: Could not retrieve pci logical device name

[Tyrel Datwyler]

From: Seeteena Thoufeek <s1se...@linux.ibm.com>

Could not retrieve logical device name for pci device type from OF path.

without patch :

ofpathname -l /pci@800000020000048/pci15b3,1003@0

ofpathname: Could not retrieve logical device name for
Open Firmware path "/pci@800000020000021/pci15b3,1003@0".

with patch :

ofpathname -l /pci@800000020000048/pci15b3,1003@0

enP72p1s0

ofpathname enP72p1s0

/pci@800000020000048/pci15b3,1003@0

Signed-off-by: Seeteena Thoufeek <s1se...@linux.vnet.ibm.com>
---
scripts/ofpathname | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)

diff --git a/scripts/ofpathname b/scripts/ofpathname
index 711ab621b5d1..bf7d2fc6c666 100755
--- a/scripts/ofpathname
+++ b/scripts/ofpathname
@@ -1206,6 +1206,7 @@ ofpathname_to_logical()
usb ) of2l_usb ;;
nvme ) of2l_nvme ;;
nvmf ) of2l_nvmf ;;
+ pci* ) of2l_pci ;;
esac

if [[ -z $LOGICAL_DEVNAME ]]; then
@@ -1227,6 +1228,51 @@ ofpathname_to_logical()
echo $LOGICAL_DEVNAME
}

+#
+# of2l_pci
+# Conversion routine for OF path => logical name for pci devices
+#
+
+of2l_pci() {
+ # Example: DEVNAME=/pci@800000020000048/pci15b3,1003@0
+ # You may want to extract the PCI address and try to find a matching device
+
+ # Extract PCI address.
+ local pci_addr
+ pci_addr=$(echo "$DEVICE" | grep -o '[0-9a-fA-F]\{4\},[0-9a-fA-F]\{4\}@[0-9]\+')
+
+ if [[ -z "$pci_addr" ]]; then
+ # Could not extract PCI address
+ LOGICAL_DEVNAME=""
+ return
+ fi
+
+ # Try to find the corresponding device in /sys/bus/pci/devices
+ for sysdev in /sys/bus/pci/devices/*; do
+ if grep -qi "$pci_addr" "$sysdev/uevent" 2>/dev/null; then
+ # Try to find a block device under this PCI device
+ for blockdev in "$sysdev"/block/*; do
+ if [[ -b "/dev/$(basename "$blockdev")" ]]; then
+ LOGICAL_DEVNAME="/dev/$(basename "$blockdev")"
+ return
+ fi
+ done
+ # Or try to find a network device
+ for netdev in "$sysdev"/net/*; do
+ if [[ -d "$netdev" ]]; then
+ LOGICAL_DEVNAME="$(basename "$netdev")"
+ return
+ fi
+ done
+ fi
+ done
+
+ # If nothing found
+ LOGICAL_DEVNAME=""
+
+ echo $LOGICAL_DEVNAME
+}
+
#
# of2l_ide
# Conversion routine for OF path => logical name for ide devices
--
2.50.0

[Tyrel Datwyler]

So, this basically becomes some sort of pci fall through for unrecognized
devices. I am curious since this is an ethernet device in question, and I don't
have the immediate ability to go check on actual hardware, if instead matching
the DEVTYPE to "enP*" and using the of2l_ethernet() function would have
correctly mapped to the network device.

-Tyrel

[Tyrel Datwyler]

Actually, disregard that train of thought I'm thinking in the wrong direction.
Logical ==> OF Path. Seeing as this is a network device it is curious that there
is no network info in the path, but only the pci address info. Have you verified
from the SMS menu what is shows as the full OF path for this device?

I ask because I'm curious if we are doing a bad logicl ==> ofpath translation
and then sticking that in bootlist, and then failing the reverse ofpath ==>
logical translation later because we didn't get the ofpath correct.

-Tyrel

[seeteena thoufeek]

lspci

0048:01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family
[ConnectX-3]

~]# lspci -Dnvmm -s 0048:01:00
Slot: 0048:01:00.0
Class: 0200
Vendor: 15b3
Device: 1003
SVendor: 1014
SDevice: 04b5
NUMANode: 3
DTNode: /sys/firmware/devicetree/base/pci@800000020000048/pci15b3,1003@0
IOMMUGroup: 0

In SMS menu,

I can see it as

Type menu item number and press Enter or select Navigation key:1


Device Information
IBM,FW-ADAPTER-NAME : PCIe3 40 GbE NIC RoCE QSFP+ Adapter
: /pci@800000020000048/pci15b3,1003@0/ethernet@0
: (Bootable)
DEVICE : PCIe3 40 GbE NIC RoCE QSFP+ Adapter
( loc=U78D4.ND1.CSS10EK-P1-C2-T1 )
NAME : ethernet
DEVICE-TYPE : network
VERIFY UDP CHECKSUM : Enabled
SUPPORTED-NETWORK-TYPES:
: ethernet,auto,null,auto
MAC-ADDRESS : f452142771c0


PCIe3 40 GbE NIC RoCE QSFP+ Adapter
( loc=U78D4.ND1.CSS10EK-P1-C2-T2 )


will share you the machine information for detail check.

[Tyrel Datwyler]

On 7/8/25 11:19 PM, seeteena thoufeek wrote:
>
>
> On 07/09/2025 03:07 AM, Tyrel Datwyler wrote:
>> On 7/8/25 2:26 PM, Tyrel Datwyler wrote:
>>> On 7/8/25 2:07 PM, Tyrel Datwyler wrote:
>>>> From: Seeteena Thoufeek <s1se...@linux.ibm.com>
>>>>

...snip...

>>
>> I ask because I'm curious if we are doing a bad logicl ==> ofpath translation
>> and then sticking that in bootlist, and then failing the reverse ofpath ==>
>> logical translation later because we didn't get the ofpath correct.
>>
>> -Tyrel
>
>  lspci
>
> 0048:01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
>
>  ~]# lspci -Dnvmm -s 0048:01:00
> Slot:    0048:01:00.0
> Class:    0200
> Vendor:    15b3
> Device:    1003
> SVendor:    1014
> SDevice:    04b5
> NUMANode:    3
> DTNode: /sys/firmware/devicetree/base/pci@800000020000048/pci15b3,1003@0
> IOMMUGroup:    0
>
> In SMS menu,
>
> I can see it as
>
>  Type menu item number and press Enter or select Navigation key:1
>
>
> Device Information
> IBM,FW-ADAPTER-NAME  : PCIe3 40 GbE NIC RoCE QSFP+ Adapter
>                      : /pci@800000020000048/pci15b3,1003@0/ethernet@0

Ok, this is pretty much what I expected Open Firmware to show as the full OF
path. Which is not what we see in boot list or from the output of lspci. This is
likely because the devspec entry in /sys for the device only points to the root
pci device node and not the ethernet@0 child node.

Your patch works to catch an incomplete OF path for pci ethernet devices, but
the real problem I think that still needs to be fixed is that ofpathname should
correctly translate the logical device to a correct OF path binding.

So, in this case:

/pci@800000020000048/pci15b3,1003@0/ethernet@0

and not simply,

/pci@800000020000048/pci15b3,1003@0

-Tyrel

[Tyrel Datwyler]

On 7/8/25 2:07 PM, Tyrel Datwyler wrote:

> From: Seeteena Thoufeek <s1se...@linux.ibm.com>
>
> Could not retrieve logical device name for pci device type from OF path.
>
> without patch :
>
> ofpathname -l /pci@800000020000048/pci15b3,1003@0
>
> ofpathname: Could not retrieve logical device name for
> Open Firmware path "/pci@800000020000021/pci15b3,1003@0".
>
> with patch :
>
> ofpathname -l /pci@800000020000048/pci15b3,1003@0
>
> enP72p1s0
>
> ofpathname enP72p1s0
>
> /pci@800000020000048/pci15b3,1003@0
>
> Signed-off-by: Seeteena Thoufeek <s1se...@linux.vnet.ibm.com>
> ---
> scripts/ofpathname | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)

After taking a look at the machine and adapter in question its clear to me now
that this patch is only functional as a bandaid, and even then there are other
issues it misses which I'll address below.

The problem as a whole is that, as I mentioned in a previous reply, ofpathname
fails to translate the logical ethernet device to a valid OF path when storing
it in bootlist. Further, I'm not even sure how SMS/OpenFirmware would even treat
the abridged OF path in the bootlist. Might be worth testing if
/pci@800000020000048/pci15b3,1003@0 would event boot.

In a different thread of the discussion it was identified that OpenFirmware
treats the OF device path we are trying to work with as:

/pci@800000020000048/pci15b3,1003@0/ethernet@0

This makes sense especially since the pci device in question has 2 ethernet
ports each with a distinct mac address. As such the second port of this network
device would be identified as:

/pci@800000020000048/pci15b3,1003@0/ethernet@1

Looking at the machine in question we can see two different ethernet interfaces
with different addresses:

[root@ltczep6-lp7 ~]# ifconfig | grep "enP72" -A1
enP72p1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether f4:52:14:27:71:c0 txqueuelen 1000 (Ethernet)
--
enP72p1s0d1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether f4:52:14:27:71:c1 txqueuelen 1000 (Ethernet)

Further, we can see how the mac addresses of each correspond to the OF path in
our device tree for each port on this pci device.

[root@ltczep6-lp7 ~]# lsprop
/proc/device-tree/pci@800000020000048/pci15b3\,1003@0/ethernet@*/mac-address
/proc/device-tree/pci@800000020000048/pci15b3,1003@0/ethernet@0/mac-address
f4 52 14 27 71 c0
/proc/device-tree/pci@800000020000048/pci15b3,1003@0/ethernet@1/mac-address
f4 52 14 27 71 c1

So, now we can see the overall problem of properly identifying the correct
device since using ofpathname to map either logical network device only gets us
the pci device and not the actual ethernet port in question on that pci device.

As an example both enP72* devices map to the pci device, but in reverse with
just the pci device we will only ever map to the first logical ethernet device.

[root@ltczep6-lp7 ~]# ofpathname -r enP72p1s0
/pci@800000020000048/pci15b3,1003@0
[root@ltczep6-lp7 ~]# ofpathname -r enP72p1s0d1
/pci@800000020000048/pci15b3,1003@0

[root@ltczep6-lp7 ~]# ofpathname -l /pci@800000020000048/pci15b3,1003@0
enP72p1s0

I think we need to go back and fix ofpathname to correctly map in both
directions to/from a valid OF path name.

-Tyrel