Re: [PATCH v3 1/3] dt-bindings: net: add Realtek r8169 family PCIe Ethernet

[Heiner Kallweit <hkallweit1@gmail.com>]

On 06.06.2026 07:03, Ricardo Pardini wrote:
> On 05/06/2026 17:48, Heiner Kallweit wrote:
>> On 05.06.2026 13:49, Ricardo Pardini via B4 Relay wrote:
>>> From: Ricardo Pardini <ricardo@pardini.net>
>>>
>>> Add a binding for fixed/soldered Realtek PCIe Ethernet controllers
>>> driven by the r8169 driver (RTL8125/8126/8127/8168 and variants).
>>>
>>> The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
>>> spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
>>> need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
>>> compatibles documented in their own bindings (e.g. microchip,lan95xx)
>>> so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
>>> these PCI function nodes can be validated.
>>>
>>
>> The of node seems to be created by of_pci_make_dev_node(). But this
>> function is called for bridges only in pci_bus_add_device().
>> So where is the node created in your case? Did you test node creation?
>>
> 
> Hi Heiner,
> 
> Seems to me of_pci_make_dev_node() is not at play here - that's the DT-synthesis path. For nodes already present in DT, the of_node is bound earlier, during pci_setup_device() -> pci_set_of_node() -> of_pci_find_child_device() via the 5-cell reg.
> 
I see, thanks. If the matching is done based on the reg property, then I just wonder
if and where the compatible string is used. Or would the logic also work with a
random compatible string?

> Ref testing: yes; with this series on a NanoPC-T6 I get, for example:
> /sys/bus/pci/devices/0004:41:00.0/of_node -> /sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0 and u-boot correctly adds local-mac-address property there which is correctly picked up kernel-side:
> 
> => setenv eth1addr 8e:b4:90:66:66:66
> => boot
> 
> ...
> 
> # readlink -f /sys/bus/pci/devices/0004:41:00.0/of_node
> /sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0
> 
> # xxd /sys/bus/pci/devices/0004:41:00.0/of_node/local-mac-address
> 00000000: 8eb4 9066 6666                           ...fff
> 
> # ip link show dev end1 | grep ether
>     link/ether 8e:b4:90:66:66:66 brd ff:ff:ff:ff:ff:ff
> 
> 
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - pci10ec,8125  # RTL8125 2.5GbE
>>> +      - pci10ec,8126  # RTL8126 5GbE
>>> +      - pci10ec,8127  # RTL8127
>>> +      - pci10ec,8161  # RTL8168 variant
>>> +      - pci10ec,8162  # RTL8168 variant
>>> +      - pci10ec,8168  # RTL8168/8111 GbE
>>
>> This list reflects just some of the PCI id's handled by r8169.
>> Any specific reason for this exact selection?
> I went for "chips likely to be soldered down on an SBC", but that was indeed speculative.
> 
> I guess I should trim to pci10ec,8125, which is all this series describes? (further IDs can be added by the patches that introduce boards using them)
> 
Yes, I'd prefer this approach. Considering that RTL8168 has been supported for
about 20yrs now, your use case seems to be exotic. Otherwise I would have
such a patch much earlier.

> -- 
> Regards,
> Ricardo
>