Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp610142yba; Fri, 3 May 2019 07:39:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqwL9K/+5yRA0PXf9lD8mb1PKGwj8dpn5/o2nrki9TQ6JOrIEsPniGD1xyoxiKTqqFG+o/aJ X-Received: by 2002:aa7:8208:: with SMTP id k8mr11284354pfi.69.1556894397842; Fri, 03 May 2019 07:39:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556894397; cv=none; d=google.com; s=arc-20160816; b=WQ4U2VXjbXQl5/UKIFspC7rdQlzzPog2i5uYdX6MCEjKmUmuvUDf4cNyPWYVuJ0pPh 3YxEsXRBb2BvdVFEc4n7YII6Owmzyk6/i4EVdlxZMF8VAh9aCBNCwp4mpSl0MA48osf6 9tKRFdDo/uvVOoVlzJkmoSXlt4GhWAaA1B5jh6RushOfr0rQCljwjNdBptgAlx3pWhry XJys0tQJsl1rxyJaRr5+SNB4x0qHT0nf5VHMotGhZmgNN4uIKJ3j+DJPrsWIZEPjlph8 d+vdg1a/AGbu4T3XuMYKSy8FiCQSw8SXuUnnzZLgwE/ryGmdOsiFGLHOD77UZZcgdX/c jHvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=6YMvpp7wqRnnL3WNsG8Po2XToqGF7h1Bj82YZGJi+Ic=; b=jsp1cERih1FtjDyw5hnGVRQldT4vVGmIFCl7pGxgX6n7wzVdI8A/nnrfFnrQIiv74K XRJRJuz4rhSpuDcb2a4ijqxclS3XEyI90x9rXBX0tJzR18GmXF7gbkAWdT9Nl1O1JBse ngTBjxiZwcqZNpguyWqAZJzHo1c0sU3g0UzGMuXD+5nNcjyQw/JeLSKhCIRRDLuJ+ttn XSlO5dMP4qKrfhGSO5MYl5EikBF6z52zyPhWkfQcXPQW7bGoO++W2aiMglc6XywlPYP1 n8PUwmQp02ODoWm4bJgCaoamjVR+SYgPuYwwjCKOpxC/cIwiq1qZEEp8UvNpQslJ8A16 Ns4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 39si2625894pla.437.2019.05.03.07.39.40; Fri, 03 May 2019 07:39:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728332AbfECOgt (ORCPT + 99 others); Fri, 3 May 2019 10:36:49 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:51423 "EHLO relay12.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726267AbfECOgs (ORCPT ); Fri, 3 May 2019 10:36:48 -0400 Received: from localhost (aaubervilliers-681-1-29-145.w90-88.abo.wanadoo.fr [90.88.149.145]) (Authenticated sender: maxime.ripard@bootlin.com) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 563FE200020; Fri, 3 May 2019 14:36:44 +0000 (UTC) Date: Fri, 3 May 2019 16:36:43 +0200 From: Maxime Ripard To: Petr =?utf-8?Q?=C5=A0tetiar?= Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org, Andrew Lunn , Florian Fainelli , Heiner Kallweit , Rob Herring , Frank Rowand , Srinivas Kandagatla , Alban Bedel , Felix Fietkau , John Crispin , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 01/10] of_net: add NVMEM support to of_get_mac_address Message-ID: <20190503143643.hhfamnptcuriav4k@flea> References: <1556893635-18549-1-git-send-email-ynezz@true.cz> <1556893635-18549-2-git-send-email-ynezz@true.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="w5grxr2nn7x6p3l6" Content-Disposition: inline In-Reply-To: <1556893635-18549-2-git-send-email-ynezz@true.cz> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --w5grxr2nn7x6p3l6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 03, 2019 at 04:27:06PM +0200, Petr =C5=A0tetiar wrote: > Many embedded devices have information such as MAC addresses stored > inside NVMEMs like EEPROMs and so on. Currently there are only two > drivers in the tree which benefit from NVMEM bindings. > > Adding support for NVMEM into every other driver would mean adding a lot > of repetitive code. This patch allows us to configure MAC addresses in > various devices like ethernet and wireless adapters directly from > of_get_mac_address, which is already used by almost every driver in the > tree. > > Predecessor of this patch which used directly MTD layer has originated > in OpenWrt some time ago and supports already about 497 use cases in 357 > device tree files. > > Cc: Alban Bedel > Signed-off-by: Felix Fietkau > Signed-off-by: John Crispin > Signed-off-by: Petr =C5=A0tetiar > --- > > Changes since v1: > > * moved handling of nvmem after mac-address and local-mac-address prope= rties > > Changes since v2: > > * moved of_get_mac_addr_nvmem after of_get_mac_addr(np, "address") call > * replaced kzalloc, kmemdup and kfree with it's devm variants > * introduced of_has_nvmem_mac_addr helper which checks if DT node has n= vmem > cell with `mac-address` > * of_get_mac_address now returns ERR_PTR encoded error value > > Changes since v3: > > * removed of_has_nvmem_mac_addr helper as it's not needed now > * of_get_mac_address now returns only valid pointer or ERR_PTR encoded = error value > > drivers/of/of_net.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++= +++--- > 1 file changed, 51 insertions(+), 3 deletions(-) > > diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c > index d820f3e..9649cd5 100644 > --- a/drivers/of/of_net.c > +++ b/drivers/of/of_net.c > @@ -8,8 +8,10 @@ > #include > #include > #include > +#include > #include > #include > +#include > > /** > * of_get_phy_mode - Get phy mode for given device_node > @@ -47,12 +49,52 @@ static const void *of_get_mac_addr(struct device_node= *np, const char *name) > return NULL; > } > > +static const void *of_get_mac_addr_nvmem(struct device_node *np) > +{ > + int ret; > + u8 mac[ETH_ALEN]; > + struct property *pp; > + struct platform_device *pdev =3D of_find_device_by_node(np); > + > + if (!pdev) > + return ERR_PTR(-ENODEV); > + > + ret =3D nvmem_get_mac_address(&pdev->dev, &mac); > + if (ret) > + return ERR_PTR(ret); > + > + pp =3D devm_kzalloc(&pdev->dev, sizeof(*pp), GFP_KERNEL); > + if (!pp) > + return ERR_PTR(-ENOMEM); > + > + pp->name =3D "nvmem-mac-address"; > + pp->length =3D ETH_ALEN; > + pp->value =3D devm_kmemdup(&pdev->dev, mac, ETH_ALEN, GFP_KERNEL); > + if (!pp->value) { > + ret =3D -ENOMEM; > + goto free; > + } > + > + ret =3D of_add_property(np, pp); > + if (ret) > + goto free; > + > + return pp->value; I'm not sure why you need to do that allocation here, and why you need to modify the DT? can't you just return the mac address directly since it's what the of_get_mac_address caller will expect anyway? maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --w5grxr2nn7x6p3l6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXMxR8gAKCRDj7w1vZxhR xbqcAP49YjJI7V+9AD9J0n1SEWgqSDf1RN9dCqV6WDaspNX5cAEA4l11UjhuTwp3 bsOoNNlu5yGF+MU5kr8sKmJYaWx7cAg= =mHTC -----END PGP SIGNATURE----- --w5grxr2nn7x6p3l6--