Re: [PATCH v3 1/3] dt-bindings: net: add Realtek r8169 family PCIe Ethernet
From: Ricardo Pardini
Date: Sat Jun 06 2026 - 21:04:10 EST
On 06/06/2026 22:50, Heiner Kallweit wrote:
On 06.06.2026 07:03, Ricardo Pardini wrote:
On 05/06/2026 17:48, Heiner Kallweit wrote:I see, thanks. If the matching is done based on the reg property, then I just wonder
On 05.06.2026 13:49, Ricardo Pardini via B4 Relay wrote:
From: Ricardo Pardini <ricardo@xxxxxxxxxxx>
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?
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.
if and where the compatible string is used. Or would the logic also work with a
random compatible string?
Thanks, Heiner. It seems the compatible is not involved in the kernel runtime matching at all (and u-boot simply patches DT via the ethernetN alias).
I guess DT-wise, specifying compatible (although not strictly required) makes sense since DT describes the hardware; "there's an RTL8125 at 0x410000" sounds better than "there's a PCIe device that needs a MAC address at 0x410000", and having the binding opens up usages of non-generic properties, although that would be future-looking.
At this stage I've to ask the devicetree folks: should I simply drop the compatible from the DT patches (and the whole binding)? dtbs_check passes without it, and it also avoids the checkpatch.pl vendor-prefix-undocumented warning. There's precedent: at least on some Apple Silicon (2022, t600x-j375) and NVIDIA (2019, tegra210-p3450-0000). On Rockchip there's quite a few (10?) boards using the same RTL chip we might want to describe.
[...]The Tegra Jetson Nano has an RTL8111 described in DT for this exact use case (without compatible) for about 7 years now -- I just couldn't find it until now.
Yes, I'd prefer this approach. Considering that RTL8168 has been supported forThis list reflects just some of the PCI id's handled by r8169.I went for "chips likely to be soldered down on an SBC", but that was indeed speculative.
Any specific reason for this exact selection?
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)
about 20yrs now, your use case seems to be exotic. Otherwise I would have
such a patch much earlier.
I'll wait for people to chime in, and later send a v4 either dropping the binding, or trimming it to only the 8125. Sashiko seems to have nice suggestions [1] on the YAML too, in case we decide to keep the binding.
--
Regards,
Ricardo
[1] https://sashiko.dev/#/patchset/20260605-rk3588-dts-rtl-eth-describe-dt-alias-v3-0-8a8857b39daf%40pardini.net