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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64FB9C433ED for ; Fri, 16 Apr 2021 07:49:05 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D36FD6113D for ; Fri, 16 Apr 2021 07:49:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D36FD6113D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=1YkH1gvcTMGxjypOKCxwh4hYJM1HakrrKm2TyPAXCeo=; b=X+s4FWypGhedzBeja3LDS/S+d 30w9ts/ljZCWyCAsxeiZ7ltv/jGpnB2iBPn4nQcdCH+4AQ0g2CtZiquUAemtEfZF3vHKlJZB5cg5K KRdH/3stsSIWW54p4O0Z6FOfMwSjaMcqQv5+upfSPt+N+Lccq9Y6JmWCEIRsBgIiQzqgCYL2nkyIO xnH/xbvDtrvlR+5uFSuzxtP9J07MuIN+wKdPtcO7X6j/5nbZrR1YeewzA70QKfAfCWjyR+ZHg+om8 9LKSXh9oZ3nNlc9vhkCYp0VVKqXS5F0UOFyK2hVWq5C9e3feThCyJkTvRnpkUslceflLLzLjjL/55 atGZPkxng==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lXJDm-001ExB-9X; Fri, 16 Apr 2021 07:48:58 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lXIvq-001CHr-0E; Fri, 16 Apr 2021 07:30:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Message-ID:References:In-Reply-To: Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version: Sender:Reply-To:Content-ID:Content-Description; bh=PbMduC+y8U2TnYB1yFy6DIbM598uMx2+jq28dZXHweQ=; b=QcTvMgxq0L1BwAk/ouREIuC+2+ 9VnI+oqWfwRlnZOEVThWO6wcwOzkwv26gy1sve647MJecVRoAzIF7P17Eq2V7mU7nqhxjcL5o5Jkl C845iFgZr3Seez7KnyvA/3wlJ4mBSS65Tirui4F1PXmREKavhWu5UqaXCB5FbaMsaShhYHfMIcEjO GIcGEX8XURhQ3ckhhUl6a1SvVBJiHc3PdABOyDyzbMm0He2toeHT05kis82KIBlVP7u02h+CNHLiI kwUUk8HBKSptqrT/VHgKOs49wYwfhGK1hcBadRWsUqwifnLoybySjgNvSa2qG8fSW7EgmRkaEZIzR wgK/hrVw==; Received: from ssl.serverraum.org ([2a01:4f8:151:8464::1:2]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lXIvl-0099Sj-Ki; Fri, 16 Apr 2021 07:30:24 +0000 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 49EE022172; Fri, 16 Apr 2021 09:29:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1618558211; 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=PbMduC+y8U2TnYB1yFy6DIbM598uMx2+jq28dZXHweQ=; b=EUtjzMP9GqVLqpUQjKAWkwn0o1sw8EWtxSv8YMRSVD0469vqt05Io1/SVJgobjz7HB/r6y Vjk/Jn7gR9cbQkm/qxqSnOY+yQWCWcha3iHS/TQBkEhMmvcdPKJxGg9UyvHCIIkZANcb/g 63rLgVagJ+mEmiydqQVNecyvEgF/m50= MIME-Version: 1.0 Date: Fri, 16 Apr 2021 09:29:59 +0200 From: Michael Walle To: Benjamin Herrenschmidt Cc: ath9k-devel@qca.qualcomm.com, UNGLinuxDriver@microchip.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-renesas-soc@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-amlogic@lists.infradead.org, linux-oxnas@groups.io, linux-omap@vger.kernel.org, linux-wireless@vger.kernel.org, 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?= , bcm-kernel-feedback-list@broadcom.com, 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 , Rob Herring , Frank Rowand , Greg Kroah-Hartman , =?UTF-8?Q?J=C3=A9r=C3=B4me?= =?UTF-8?Q?_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: <730d603b12e590c56770309b4df2bd668f7afbe3.camel@kernel.crashing.org> References: <20210412174718.17382-1-michael@walle.cc> <20210412174718.17382-3-michael@walle.cc> <730d603b12e590c56770309b4df2bd668f7afbe3.camel@kernel.crashing.org> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <8157eba9317609294da80472622deb28@walle.cc> X-Sender: michael@walle.cc X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210416_003022_032590_275B2B78 X-CRM114-Status: GOOD ( 28.16 ) X-BeenThere: linux-amlogic@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-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org Am 2021-04-16 05:24, schrieb Benjamin Herrenschmidt: > On Mon, 2021-04-12 at 19:47 +0200, Michael Walle wrote: >> >> /** >> * of_get_phy_mode - Get phy mode for given device_node >> @@ -59,15 +60,39 @@ static int of_get_mac_addr(struct device_node *np, >> const char *name, u8 *addr) >> static int of_get_mac_addr_nvmem(struct device_node *np, u8 *addr) >> { >> struct platform_device *pdev = of_find_device_by_node(np); >> + struct nvmem_cell *cell; >> + const void *mac; >> + size_t len; >> int ret; >> >> - if (!pdev) >> - return -ENODEV; >> + /* Try lookup by device first, there might be a >> nvmem_cell_lookup >> + * associated with a given device. >> + */ >> + if (pdev) { >> + ret = nvmem_get_mac_address(&pdev->dev, addr); >> + put_device(&pdev->dev); >> + return ret; >> + } >> + > > This smells like the wrong band aid :) > > Any struct device can contain an OF node pointer these days. But not all nodes might have an associated device, see DSA for example. And as the name suggests of_get_mac_address() operates on a node. So if a driver calls of_get_mac_address() it should work on the node. What is wrong IMHO, is that the ethernet drivers where the corresponding board has a nvmem_cell_lookup registered is calling of_get_mac_address(node). It should rather call eth_get_mac_address(dev) in the first place. One would need to figure out if there is an actual device (with an assiciated of_node), then call eth_get_mac_address(dev) and if there isn't a device call of_get_mac_address(node). But I don't know if that is easy to figure out. Well, one could start with just the device where nvmem_cell_lookup is used. Then we could drop the workaround above. > This seems all backwards. I think we are dealing with bad evolution. > > We need to do a lookup for the device because we get passed an of_node. > We should just get passed a device here... or rather stop calling > of_get_mac_addr() from all those drivers and instead call > eth_platform_get_mac_address() which in turns calls of_get_mac_addr(). > > Then the nvmem stuff gets put in eth_platform_get_mac_address(). > > of_get_mac_addr() becomes a low-level thingy that most drivers don't > care about. The NVMEM thing is just another (optional) way how the MAC address is fetched from the device tree. Thus, if the drivers have the of_get_mac_address() call they should automatically get the NVMEM method, too. -michael _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic