From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 640E5ECAAA1 for ; Mon, 5 Sep 2022 22:18:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:Cc:To:From :Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JQOKnnxa2ZbvQGM4rpcieF38QP2xPA+jgVlJwMhOBno=; b=ZK79eBzHlXmAj4BT9JFPh3GqWP UQXPGz9ct/kf/Y56Bq8Dume9AmpwNdmVIif8sioxc7hmq2dW8+zLmyMaXvpp3Gr6xvigymtfg2Xn8 Ezv6kpcV3TXhf42Z42kxBlMEipoPPFdsEN6gdAT57Uc+pfH5O/CIlGSGsd6lQMqePXDfvhxTeU4fE CE4zUpVPHKogFc4WKQIZQvHxhJezGcVAZq+azHnFKvbTQO2sB6o9EpeXv6Wa9xaMmVTB014wmIslY tK4TJFGkxpDYDAbyvmPNKKXbZOLKq/odRNOgC6ZRkusalYnfkPMEDSKdHOToru6uxyAVbd1UHMYGb WxGP0qcA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVKPT-00H9kF-Gt; Mon, 05 Sep 2022 22:17:39 +0000 Received: from 0001.3ffe.de ([2a01:4f8:c0c:9d57::1] helo=mail.3ffe.de) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVKPQ-00H9hJ-Af for linux-arm-kernel@lists.infradead.org; Mon, 05 Sep 2022 22:17:38 +0000 Received: from 3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id CC0F41237; Tue, 6 Sep 2022 00:17:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1662416249; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IHqwoI5OJwucKGse+LfR+Krmr6ZZMdVFsaeSkgDsr3o=; b=is7h4uz/R+0PDgRskheOgM5/6YA8uxXysj7m5fcncfbA4cy5K/7OjT1IGXWgLOOqwOR2gn d40Bz2CE1pF0xzmCgwIsKeC7F9vfOeT5+3SlOnm9a2uAQh/T6h2fzFh5nqx54JXDWiVLFB mrt9qVCalRIpRQVMx8Jd35O++/WVXFj4SzXS/DDG13hF3CriYXLfWJx2bC1tvvSxoJwk1V fCDXxkqyFvq5cNucvdAstNyUoGlGAYcTeP4EPc2ae9VsEj4tFkmmx5C7FZy82uVqyEFi7S vycjrzhHZ8dZM67AGgDgcAQCblpO5yGdxB0qCeV8Jh8u+9/qT98sdPd+ngfPNw== MIME-Version: 1.0 Date: Tue, 06 Sep 2022 00:17:29 +0200 From: Michael Walle To: Vladimir Oltean Cc: devicetree@vger.kernel.org, netdev@vger.kernel.org, Shawn Guo , Li Yang , Rob Herring , Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH devicetree] arm64: dts: ls1028a-rdb: add more ethernet aliases In-Reply-To: <20220905212458.1549179-1-vladimir.oltean@nxp.com> References: <20220905212458.1549179-1-vladimir.oltean@nxp.com> User-Agent: Roundcube Webmail/1.4.13 Message-ID: X-Sender: michael@walle.cc X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220905_151736_568047_5E906F75 X-CRM114-Status: GOOD ( 20.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am 2022-09-05 23:24, schrieb Vladimir Oltean: > Commit "arm64: dts: ls1028a: enable swp5 and eno3 for all boards" which > Shawn declared as applied, but for which I can't find a sha1sum, has > enabled a new Ethernet port on the LS1028A-RDB (&enetc_port3), but > U-Boot, which passes a MAC address to Linux' device tree through the > /aliases node, fails to do this for this newly enabled port. > > Fix that by adding more ethernet aliases in the only > backwards-compatible way possible: at the end of the current list. > > And since it is possible to very easily convert either swp4 or swp5 to > DSA user ports now (which have a MAC address of their own), using these > U-Boot commands: > > => fdt addr $fdt_addr_r > => fdt rm /soc/pcie@1f0000000/ethernet-switch@0,5/ports/port@4 ethernet > > it would be good if those DSA user ports (swp4, swp5) gained a valid > MAC > address from U-Boot as well. In order for that to work properly, > provision two more ethernet aliases for &mscc_felix_port{4,5} as well. First, let me say, I'm fine with this patch. But I'm not sure, how many MAC addresses are actually reserved on your RDB/QDS boards? I guess, they being evaluation boards you don't care? ;) On the Kontron sl28 boards we reserve just 8 and that is already a lot for a board with max 6 out facing ports. 4 of these ports used to be a switch, so in theory it should work with 3 MAC addresses, right? Or even just 2 if there is no need to terminate any traffic on the switch interfaces. Anyway, do we really need so many addresses? What are the configurations here? For what is the address of the internal ports used? Let's say we are in the "port extender mode" and use the second internal port as an actual switch port, that would then be: 2x external enetc 1x internal enetc 4x external switch ports in port extender mode Which makes 7 addresses. The internal enetc port doesn't really make sense in a port extender mode, because there is no switching going on. So uhm, 6 addresses are the maximum? This is the MAC address distribution for now on the sl28 boards: https://lore.kernel.org/linux-devicetree/20220901221857.2600340-19-michael@walle.cc/ Please tell me if I'm missing something here. -michael > The resulting ordering is slightly unusual, but to me looks more > natural > than eno0, eno2, swp0, swp1, swp2, swp3, eno3, swp4, swp5. > > Signed-off-by: Vladimir Oltean _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98ED4ECAAD3 for ; Mon, 5 Sep 2022 22:17:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231440AbiIEWRe (ORCPT ); Mon, 5 Sep 2022 18:17:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38804 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229577AbiIEWRd (ORCPT ); Mon, 5 Sep 2022 18:17:33 -0400 Received: from mail.3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE20359267; Mon, 5 Sep 2022 15:17:31 -0700 (PDT) Received: from 3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id CC0F41237; Tue, 6 Sep 2022 00:17:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1662416249; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IHqwoI5OJwucKGse+LfR+Krmr6ZZMdVFsaeSkgDsr3o=; b=is7h4uz/R+0PDgRskheOgM5/6YA8uxXysj7m5fcncfbA4cy5K/7OjT1IGXWgLOOqwOR2gn d40Bz2CE1pF0xzmCgwIsKeC7F9vfOeT5+3SlOnm9a2uAQh/T6h2fzFh5nqx54JXDWiVLFB mrt9qVCalRIpRQVMx8Jd35O++/WVXFj4SzXS/DDG13hF3CriYXLfWJx2bC1tvvSxoJwk1V fCDXxkqyFvq5cNucvdAstNyUoGlGAYcTeP4EPc2ae9VsEj4tFkmmx5C7FZy82uVqyEFi7S vycjrzhHZ8dZM67AGgDgcAQCblpO5yGdxB0qCeV8Jh8u+9/qT98sdPd+ngfPNw== MIME-Version: 1.0 Date: Tue, 06 Sep 2022 00:17:29 +0200 From: Michael Walle To: Vladimir Oltean Cc: devicetree@vger.kernel.org, netdev@vger.kernel.org, Shawn Guo , Li Yang , Rob Herring , Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH devicetree] arm64: dts: ls1028a-rdb: add more ethernet aliases In-Reply-To: <20220905212458.1549179-1-vladimir.oltean@nxp.com> References: <20220905212458.1549179-1-vladimir.oltean@nxp.com> User-Agent: Roundcube Webmail/1.4.13 Message-ID: X-Sender: michael@walle.cc Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Am 2022-09-05 23:24, schrieb Vladimir Oltean: > Commit "arm64: dts: ls1028a: enable swp5 and eno3 for all boards" which > Shawn declared as applied, but for which I can't find a sha1sum, has > enabled a new Ethernet port on the LS1028A-RDB (&enetc_port3), but > U-Boot, which passes a MAC address to Linux' device tree through the > /aliases node, fails to do this for this newly enabled port. > > Fix that by adding more ethernet aliases in the only > backwards-compatible way possible: at the end of the current list. > > And since it is possible to very easily convert either swp4 or swp5 to > DSA user ports now (which have a MAC address of their own), using these > U-Boot commands: > > => fdt addr $fdt_addr_r > => fdt rm /soc/pcie@1f0000000/ethernet-switch@0,5/ports/port@4 ethernet > > it would be good if those DSA user ports (swp4, swp5) gained a valid > MAC > address from U-Boot as well. In order for that to work properly, > provision two more ethernet aliases for &mscc_felix_port{4,5} as well. First, let me say, I'm fine with this patch. But I'm not sure, how many MAC addresses are actually reserved on your RDB/QDS boards? I guess, they being evaluation boards you don't care? ;) On the Kontron sl28 boards we reserve just 8 and that is already a lot for a board with max 6 out facing ports. 4 of these ports used to be a switch, so in theory it should work with 3 MAC addresses, right? Or even just 2 if there is no need to terminate any traffic on the switch interfaces. Anyway, do we really need so many addresses? What are the configurations here? For what is the address of the internal ports used? Let's say we are in the "port extender mode" and use the second internal port as an actual switch port, that would then be: 2x external enetc 1x internal enetc 4x external switch ports in port extender mode Which makes 7 addresses. The internal enetc port doesn't really make sense in a port extender mode, because there is no switching going on. So uhm, 6 addresses are the maximum? This is the MAC address distribution for now on the sl28 boards: https://lore.kernel.org/linux-devicetree/20220901221857.2600340-19-michael@walle.cc/ Please tell me if I'm missing something here. -michael > The resulting ordering is slightly unusual, but to me looks more > natural > than eno0, eno2, swp0, swp1, swp2, swp3, eno3, swp4, swp5. > > Signed-off-by: Vladimir Oltean