From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ssl.serverraum.org (ssl.serverraum.org [176.9.125.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B16D2F80 for ; Wed, 28 Apr 2021 08:09:39 +0000 (UTC) Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 3392E2224F; Wed, 28 Apr 2021 10:09:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1619597371; 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=M9NlOCpW1MZNsl/vA/TRzY5PiytDAsgS7p11KntpwDc=; b=TeuOHOIozerVUFBEq+kXl+E4fsEw1MWqgROl2oA8Sc/xKOT0oXpynCQIkw1papfFwz22RM ZqopdTbGj/RRv3+sDFrM+3v84W6DRuM04o8XbE5Tyx09iWpSYtyaTodlAwmk1PVwQpm/hS zB6aEh6Z4dXpMFJB4kyQVt3Zk/Jvibs= X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 28 Apr 2021 10:09:17 +0200 From: Michael Walle To: Benjamin Herrenschmidt Cc: Rob Herring , QCA ath9k Development , Microchip Linux Driver Support , linux-arm-kernel , linux-kernel@vger.kernel.org, linuxppc-dev , netdev , "moderated list:ARM/Mediatek SoC support" , "open list:MEDIA DRIVERS FOR RENESAS - FCP" , "moderated list:ARM/STM32 ARCHITECTURE" , "open list:ARM/Amlogic Meson..." , linux-oxnas@groups.io, linux-omap , linux-wireless , devicetree@vger.kernel.org, linux-staging@lists.linux.dev, Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Russell King , Michael Ellerman , Paul Mackerras , Andreas Larsson , "David S . Miller" , Jakub Kicinski , Maxime Ripard , Chen-Yu Tsai , Jernej Skrabec , Joyce Ooi , Chris Snook , =?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?= , "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" , Florian Fainelli , Nicolas Ferre , Claudiu Beznea , Sunil Goutham , Fugang Duan , Madalin Bucur , Pantelis Antoniou , Claudiu Manoil , Li Yang , Yisen Zhuang , Salil Mehta , Hauke Mehrtens , Thomas Petazzoni , Vadym Kochan , Taras Chornyi , Mirko Lindner , Stephen Hemminger , Felix Fietkau , John Crispin , Sean Wang , Mark Lee , Matthias Brugger , Bryan Whitehead , Vladimir Zapolskiy , Sergei Shtylyov , Byungho An , Kunihiko Hayashi , Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , Maxime Coquelin , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Kevin Hilman , Neil Armstrong , Jerome Brunet , Martin Blumenstingl , Vinod Koul , Nobuhiro Iwamatsu , Grygorii Strashko , Wingman Kwok , Murali Karicheri , Michal Simek , Radhey Shyam Pandey , Kalle Valo , Lorenzo Bianconi , Ryder Lee , Stanislaw Gruszka , Helmut Schaa , Heiner Kallweit , Frank Rowand , Greg Kroah-Hartman , =?UTF-8?Q?J=C3=A9r=C3=B4me_Pouiller?= , Vivien Didelot , Vladimir Oltean Subject: Re: [PATCH net-next v4 2/2] of: net: fix of_get_mac_addr_nvmem() for non-platform devices In-Reply-To: <3677398ebb77f334abb4899770db633d9658fe82.camel@kernel.crashing.org> References: <20210412174718.17382-1-michael@walle.cc> <20210412174718.17382-3-michael@walle.cc> <730d603b12e590c56770309b4df2bd668f7afbe3.camel@kernel.crashing.org> <8157eba9317609294da80472622deb28@walle.cc> <108f268a35843368466004f7fe5f9f88@walle.cc> <3677398ebb77f334abb4899770db633d9658fe82.camel@kernel.crashing.org> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <452795c5254b65cfba6e52cfc94d92bd@walle.cc> X-Sender: michael@walle.cc Am 2021-04-27 01:44, schrieb Benjamin Herrenschmidt: > On Mon, 2021-04-26 at 12:54 +0200, Michael Walle wrote: >> (2) What do you think of eth_get_mac_address(ndev). That is, the > > Not sure what you mean, eth_platform_get_mac_address() takes the > address as an argument. I think what you want is a consolidated > nvmem_get_mac_address + eth_platform_get_mac_address that takes a > device, which would have no requirement of the bus_type at all. Sure. What I meant was the following: eth_get_mac_address(struct net_device *ndev) vs. eth_get_mac_address(struct device *dev, u8 *mac_buf) The first would assume the destination is ndev->dev_addr (which is true for most of the calls, but not all). -michael