From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D63B43B18A for ; Sat, 6 Jun 2026 20:50:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780779024; cv=none; b=qxLylWNlrgXac9qtwlwYPooJSeHCkwRLKQO0qI+luz9SIqo1FuxiS5R3a+oUcBI4j1pjal5oyf6X33/KMqzei9U/Y6I7M8dDn6pMG4DX0DBD36XshQxHPn6ijMp2NATZMyPynDLUwDhY4JgYFvAAdeEjgWYyTpJ49lV6Nbzzbc0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780779024; c=relaxed/simple; bh=ab89G/27l/5o7tuJPd46KvxXOp2HCBuR6xIqDz8zGn0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=scZzTdNxT0H7yo4Ds0OlELvxIJLTivLgG9jNDgvpP/mmC6lBpHXNycRJXeZlLPannekam73+9UBTJFyYE3Z/DVT+ntr4iPbg5CeY3sRF7aSe3dnArbnkIdW/JivyXp+zlvDLBpsvyVH/JtaJ7A1c/lR6i6KvbAPAVdodnZ/NjVE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YYQfggFB; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YYQfggFB" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-490b2b037d2so26198665e9.3 for ; Sat, 06 Jun 2026 13:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780779021; x=1781383821; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KICvSmr67GVRpflb7Bqnkr43eQwEX55VG2vB71Ne/XY=; b=YYQfggFBRnj/hmo8ymAFncLuqRxLm7FzmFwU9UlzoeBHbCom//18HGAKELMuX1q6Jq IqyYqtgw+OodhpoLbgR8O/1Kz8UaxrLqaYcSMmadETNDPHAbV5JM0dshIhyRYdkRrWBo uh47ss83wnGfjDAipzg3p1bEDoEhDO5mZMG2afSr17/P1VGQywP6t2DWzKMZpSD+vR9q W3qIIuP2TO6jznJPkzXII0DJKvvDrOkhrY+brN9SZ+fC5/Z8ssRwtAtVY0azhJ8f0+TW 6qbY8dkA5aA5Eawtq7SOzQjXVoPMl3LvcRMn2ejOmA9cXd/bsveFfnOgaw5VrWm5Ipv/ CMZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780779021; x=1781383821; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KICvSmr67GVRpflb7Bqnkr43eQwEX55VG2vB71Ne/XY=; b=cLYlIva76X/kyP14CjMFPkp8NTXEcpx8k0e6jpMl6suX780hOS2r4yjU2PPBkOUqEx EoNQM4VcXbhCkUtPt+9fyVTdQ3HTO2e97lUt9rVGIvx58/JrQe0tTKt0EvKgNbqtV3Up 4w21SDJE3NkstBTBb8mMCosQxDujYT8OrHHzxmUD+87q//mSflDX7n4bFwc7iJL558FQ NmYVhET1oBjhZOhLQQ/IUXXj9bSW0fRXXhUSqGhMJvuZUdxz1Rnqwg3d8m/EmtG9DEpb Sl7mv4UweqWwdKxwhA5xCs1aWhaNbQXooZUYRoLAJuw3ikyZfOpv3kJAfNDwjj/Z1F1z +Gqw== X-Forwarded-Encrypted: i=1; AFNElJ8P6MNNatdxoO96+LEfM1+lJ51jlMnARW4XfCB/Q3gfO4x4VBKvT7X4xbDzBaSiYHqD/vmf+zmFRifiPno=@vger.kernel.org X-Gm-Message-State: AOJu0Yz0L2bfXDK6ikFB26ACunQKJTo/+HV+D5s9JZylZ3pH+NSK+BSn 17vrkAL6iKuySYg1RGS4E0TGFQij2FiRmeGsI/bbHNaeqQEMMCMqRYZp X-Gm-Gg: Acq92OFkD3SPmdZJV2llEgaVXfsyXx4D5pm4MfaXybnFVjpE9rEoDNoFF0O/r9dQ3iI Ca+Z8BS0t658zeXfmzW3Ea57mn7TVKRZAkGSoZaT47DUb63ScYPM2wtJOO3syTW3MrlmAq5YwUA Nrj8ILlMPsextzBvrDfoI3rZ2i6izRPOinw2QZw1LLXHOK6ITdBN3du8oMdHhVWKF0hhVIudcei upIfw8cuo5THHyxoegySP1y1Ib/OTcz/bCVtLKDaJQ0cJJzn5AMWjBFlDkoYPlTOVZfz002tLam A6RY+cv0AHaHyQKkvzYCHzuq/IAVSRwAtYftC9bR5vctzp1zrxfW2E5vSRCbJoxMWPU5rmgIF7R xL97wVGc5DPdJu4lcUK4W/xaCBtmNuPxvoCeoK+H+GH6l3GS5Y8FD4T+uSwV2ZqPPq1nJbkC5II idwyCrpSlwPAhdKZBfbvHJtsvREvoYNSHjzIUBRIdyCkqhlgtfk0IxRRUut8BvRCwKFOmcW2LYS Y/5KxHncu+DeOZTkTELaY/qWlPfdrSsCPXLdM7v6An8tBsowrF8SVlafrmCTfsvL24JaHw= X-Received: by 2002:a05:600c:4708:b0:48a:6fd4:d3d3 with SMTP id 5b1f17b1804b1-490c2604735mr151296265e9.20.1780779020992; Sat, 06 Jun 2026 13:50:20 -0700 (PDT) Received: from ?IPV6:2003:ea:8f4a:1a00:ac2e:7640:d3:7bd5? (p200300ea8f4a1a00ac2e764000d37bd5.dip0.t-ipconnect.de. [2003:ea:8f4a:1a00:ac2e:7640:d3:7bd5]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490bc3cbfe4sm259925885e9.7.2026.06.06.13.50.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Jun 2026 13:50:20 -0700 (PDT) Message-ID: <667f64e0-2b3e-41bf-9c97-3562696d3af7@gmail.com> Date: Sat, 6 Jun 2026 22:50:19 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/3] dt-bindings: net: add Realtek r8169 family PCIe Ethernet To: Ricardo Pardini , nic_swsd@realtek.com, Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Heiko Stuebner Cc: Sebastian Reichel , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org References: <20260605-rk3588-dts-rtl-eth-describe-dt-alias-v3-0-8a8857b39daf@pardini.net> <20260605-rk3588-dts-rtl-eth-describe-dt-alias-v3-1-8a8857b39daf@pardini.net> <26da1dfa-3408-4654-9046-36ed6d57059c@pardini.net> Content-Language: en-US From: Heiner Kallweit In-Reply-To: <26da1dfa-3408-4654-9046-36ed6d57059c@pardini.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 >>> >>> 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 >