Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6991621yba; Thu, 2 May 2019 02:06:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqzQQ76/eskWySdwvdQqvKZQo93cyzubb2Uyr22lqa7if0FkCqrDOqtBITIYgBwr8kpnUKTS X-Received: by 2002:a65:51c8:: with SMTP id i8mr2778860pgq.175.1556788017602; Thu, 02 May 2019 02:06:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556788017; cv=none; d=google.com; s=arc-20160816; b=VqvXSRJofH6puhDJE20VAN9RXzUTUWvbU7T7aCuRT296uUtFxXlVdDtO9YitebSW4c 16qQUuHyx8GjWi4PhuWmRaDHLP/GpE51frXP3pyGbecsTogGkJjG8WDTJ3Tr+5NjLFwy VXpUYFFBYmExvUxtD3D/O01KofwFXWXC2lrE4iQHR5iEuBqj3aRjLZJLmxqWnFo5SIm8 eTFiWUZSX7/U4QECXbnoYijix40Nj2G0VCOicGzrKX0JVy+yynYwjZRuAB9jYzCj/4Gb v9qs7vMfPWGja5PRDbN0W7vUwQKI/Ofc2FiBwiUguq3FKSKz+T2PTt36+0cgxoPtSB1W k/dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:reply-to:message-id:subject:cc:to:from:date; bh=6UJiM2C+N+j3SHBBloQqEV+PorV33mRMMHdnWLo7sdc=; b=fK0Av36Vi3t5HF3EBbH91HYT5KvnsOyijxnhjyRh/fFQtOlVhwBmMm3TNsa/a4wh8p ocOdJfm7I2AnFt681igkCSGEwmVEjJHf+t03f8Ggk9dNmcj9BlrGfBYsk2wk5z/+PYaJ fo3b/vFnO6YTROowQkh1MqkV7TPOMMIfrT8aOBKgJJXx5tjK5Ffz3e/cXSYyKrAu3Rmc xkJ563l/OZo4QBymD56XTg6+AyTSOGpK6j/MCIvYpkVOt5YowVpnw0CU5jwshObMn788 kLbn2rKLUzGnX7C8meQscSpPjB4xQMjkH7WASmjERWdkYXf794QDgiAlJKbjoxb9QvsO CHJw== 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 t14si43744729pfh.87.2019.05.02.02.06.42; Thu, 02 May 2019 02:06: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 S1726283AbfEBJFn (ORCPT + 99 others); Thu, 2 May 2019 05:05:43 -0400 Received: from smtp-out.xnet.cz ([178.217.244.18]:46782 "EHLO smtp-out.xnet.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726001AbfEBJFn (ORCPT ); Thu, 2 May 2019 05:05:43 -0400 Received: from meh.true.cz (meh.true.cz [108.61.167.218]) (Authenticated sender: petr@true.cz) by smtp-out.xnet.cz (Postfix) with ESMTPSA id 3720F4725; Thu, 2 May 2019 11:05:40 +0200 (CEST) Received: from localhost (meh.true.cz [local]) by meh.true.cz (OpenSMTPD) with ESMTPA id d6160ae8; Thu, 2 May 2019 11:05:38 +0200 (CEST) Date: Thu, 2 May 2019 11:05:38 +0200 From: Petr =?utf-8?Q?=C5=A0tetiar?= To: Rob Herring Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Lunn , Florian Fainelli , Heiner Kallweit , Frank Rowand , Srinivas Kandagatla , Maxime Ripard , Alban Bedel , Felix Fietkau , John Crispin Subject: Re: [PATCH v2 1/4] of_net: Add NVMEM support to of_get_mac_address Message-ID: <20190502090538.GD346@meh.true.cz> Reply-To: Petr =?utf-8?Q?=C5=A0tetiar?= References: <1556456002-13430-1-git-send-email-ynezz@true.cz> <1556456002-13430-2-git-send-email-ynezz@true.cz> <20190501201925.GA15495@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190501201925.GA15495@bogus> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rob Herring [2019-05-01 15:19:25]: Hi Rob, > > + struct property *pp; ... > > + pp = kzalloc(sizeof(*pp), GFP_KERNEL); > > + if (!pp) > > + return NULL; > > + > > + pp->name = "nvmem-mac-address"; > > + pp->length = ETH_ALEN; > > + pp->value = kmemdup(mac, ETH_ALEN, GFP_KERNEL); > > + if (!pp->value || of_add_property(np, pp)) > > + goto free; > > Why add this to the DT? I've just carried it over from v1 ("of_net: add mtd-mac-address support to of_get_mac_address()")[1] as nobody objected about this so far. Honestly I don't know if it's necessary to have it, but so far address, mac-address and local-mac-address properties provide this DT nodes, so I've simply thought, that it would be good to have it for MAC address from NVMEM as well in order to stay consistent. Just FYI, my testing ar9331_8dev_carambola2.dts[2] currently produces following runtime DT content: root@OpenWrt:/# find /sys/firmware/devicetree/ -name *nvmem* -o -name *addr@* /sys/firmware/devicetree/base/ahb/spi@1f000000/flash@0/partitions/partition@ff0000/nvmem-cells /sys/firmware/devicetree/base/ahb/spi@1f000000/flash@0/partitions/partition@ff0000/nvmem-cells/eth-mac-addr@0 /sys/firmware/devicetree/base/ahb/spi@1f000000/flash@0/partitions/partition@ff0000/nvmem-cells/eth-mac-addr@6 /sys/firmware/devicetree/base/ahb/spi@1f000000/flash@0/partitions/partition@ff0000/nvmem-cells/wifi-mac-addr@1002 /sys/firmware/devicetree/base/ahb/wmac@18100000/nvmem-cells /sys/firmware/devicetree/base/ahb/wmac@18100000/nvmem-mac-address /sys/firmware/devicetree/base/ahb/wmac@18100000/nvmem-cell-names /sys/firmware/devicetree/base/ahb/eth@1a000000/nvmem-cells /sys/firmware/devicetree/base/ahb/eth@1a000000/nvmem-mac-address /sys/firmware/devicetree/base/ahb/eth@1a000000/nvmem-cell-names /sys/firmware/devicetree/base/ahb/eth@19000000/nvmem-cells /sys/firmware/devicetree/base/ahb/eth@19000000/nvmem-mac-address /sys/firmware/devicetree/base/ahb/eth@19000000/nvmem-cell-names root@OpenWrt:/# hexdump -C /sys/firmware/devicetree/base/ahb/wmac@18100000/nvmem-mac-address 00000000 00 03 7f 11 52 da |....R.| 00000006 root@OpenWrt:/# ip addr show wlan0 4: wlan0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:03:7f:11:52:da brd ff:ff:ff:ff:ff:ff 1. https://patchwork.ozlabs.org/patch/1086628/ 2. https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=blob;f=target/linux/ath79/dts/ar9331_8dev_carambola2.dts;h=349c91e760ca5a56d65c587c949fed5fb6ea980e;hb=349c91e760ca5a56d65c587c949fed5fb6ea980e > You have the struct device ptr, so just use devm_kzalloc() if you need an > allocation. I'll address this in v3, thanks. -- ynezz