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 161D9C433FE for ; Mon, 21 Nov 2022 09:29:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229715AbiKUJ3h (ORCPT ); Mon, 21 Nov 2022 04:29:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229650AbiKUJ3h (ORCPT ); Mon, 21 Nov 2022 04:29:37 -0500 Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::225]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36B6D26139; Mon, 21 Nov 2022 01:29:35 -0800 (PST) Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id C20D01C0006; Mon, 21 Nov 2022 09:29:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1669022973; 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=c/Vnj6MPjUKIBDRhrj8ixFI/juf2n4PkKcGC0BhMOmA=; b=ngrxWGtv0zVvk4sWmRJqaVEY8vjSErYieuuHoJBEcDxkLetxG+O/372w40aGiHEMcU8fHB tlncjX8G3cA/+qA95MCrxOpGbYpidkbdQltOZudwxNpYEnjU/OAz0Y/6RTZwylvVsaRPAq C3QVw196EX0DWK4OzNMFyMTzuSaGLIavSVq/1l8Xh5dAnE1+JW/nA/KLtDDunhamMXfKwM Cp4UkZ/59bsZp5BLHgtBKlxoDVTMbZnNmKXAAeUS2x/zq79tIesKT1IgsF74defA3WedcU A47FXXAxSRK1Zqnz9jjOCGk/iIHKjHfBGG3I5ENDFFKMcbDoTqNWieTKv6/U7w== Date: Mon, 21 Nov 2022 10:29:28 +0100 From: Miquel Raynal To: Marcin Wojtas Cc: Rob Herring , Krzysztof Kozlowski , devicetree@vger.kernel.org, "David S. Miller" , Jakub Kicinski , Paolo Abeni , Eric Dumazet , netdev@vger.kernel.org, Russell King , Taras Chornyi , linux-kernel@vger.kernel.org, Robert Marko , Luka Perkov , Thomas Petazzoni , Michael Walle Subject: Re: [PATCH net-next 6/6] net: mvpp2: Consider NVMEM cells as possible MAC address source Message-ID: <20221121102928.7b190296@xps-13> In-Reply-To: References: <20221117215557.1277033-1-miquel.raynal@bootlin.com> <20221117215557.1277033-7-miquel.raynal@bootlin.com> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Marcin, mw@semihalf.com wrote on Sat, 19 Nov 2022 09:18:34 +0100: > Hi Miquel, >=20 >=20 > czw., 17 lis 2022 o 22:56 Miquel Raynal napis= a=C5=82(a): > > > > The ONIE standard describes the organization of tlv (type-length-value) > > arrays commonly stored within NVMEM devices on common networking > > hardware. > > > > Several drivers already make use of NVMEM cells for purposes like > > retrieving a default MAC address provided by the manufacturer. > > > > What made ONIE tables unusable so far was the fact that the information > > where "dynamically" located within the table depending on the > > manufacturer wishes, while Linux NVMEM support only allowed statically > > defined NVMEM cells. Fortunately, this limitation was eventually tackled > > with the introduction of discoverable cells through the use of NVMEM > > layouts, making it possible to extract and consistently use the content > > of tables like ONIE's tlv arrays. > > > > Parsing this table at runtime in order to get various information is now > > possible. So, because many Marvell networking switches already follow > > this standard, let's consider using NVMEM cells as a new valid source of > > information when looking for a base MAC address, which is one of the > > primary uses of these new fields. Indeed, manufacturers following the > > ONIE standard are encouraged to provide a default MAC address there, so > > let's eventually use it if no other MAC address has been found using the > > existing methods. > > > > Link: https://opencomputeproject.github.io/onie/design-spec/hw_requirem= ents.html =20 >=20 > Thanks for the patch. Did you manage to test in on a real HW? I am curiou= s about Yes, I have a Replica switch on which the commercial ports use the replica PCI IP while the config "OOB" port is running with mvpp2: [ 16.737759] mvpp2 f2000000.ethernet eth52: Using nvmem cell mac address = 18:be:92:13:9a:00 > > Signed-off-by: Miquel Raynal > > --- > > drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/= net/ethernet/marvell/mvpp2/mvpp2_main.c > > index eb0fb8128096..7c8c323f4411 100644 > > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c > > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c > > @@ -6104,6 +6104,12 @@ static void mvpp2_port_copy_mac_addr(struct net_= device *dev, struct mvpp2 *priv, > > } > > } > > > > + if (!of_get_mac_address(to_of_node(fwnode), hw_mac_addr)) { =20 >=20 > Unfortunately, nvmem cells seem to be not supported with ACPI yet, so > we cannot extend fwnode_get_mac_address - I think it should be, > however, an end solution. Agreed. > As of now, I'd prefer to use of_get_mac_addr_nvmem directly, to avoid > parsing the DT again (after fwnode_get_mac_address) and relying > implicitly on falling back to nvmem stuff (currently, without any > comment it is not obvious). I did not do that in the first place because of_get_mac_addr_nvmem() was not exported, but I agree it would be the cleanest (and quickest) approach, so I'll attempt to export the function first, and then use it directly from the driver. > Best regards, > Marcin >=20 > > + *mac_from =3D "nvmem cell"; > > + eth_hw_addr_set(dev, hw_mac_addr); > > + return; > > + } > > + > > *mac_from =3D "random"; > > eth_hw_addr_random(dev); > > } > > -- > > 2.34.1 > > =20 Thanks a lot, Miqu=C3=A8l