| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAL_JsqKbxY5sCJ_8F7iF0hFr52cwRsSc2bu48H7cqcNeWytDpA@mail.gmail.com>
Date: Tue, 6 Apr 2021 20:13:15 -0500
From: Rob Herring <robh+dt@...nel.org>
To: Michael Walle <michael@...le.cc>
Cc: QCA ath9k Development <ath9k-devel@....qualcomm.com>,
Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
netdev <netdev@...r.kernel.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@...ts.infradead.org>,
"open list:MEDIA DRIVERS FOR RENESAS - FCP"
<linux-renesas-soc@...r.kernel.org>,
"moderated list:ARM/STM32 ARCHITECTURE"
<linux-stm32@...md-mailman.stormreply.com>,
"open list:ARM/Amlogic Meson..." <linux-amlogic@...ts.infradead.org>,
linux-oxnas@...ups.io, linux-omap <linux-omap@...r.kernel.org>,
linux-wireless <linux-wireless@...r.kernel.org>,
devicetree@...r.kernel.org, linux-staging@...ts.linux.dev,
Andrew Lunn <andrew@...n.ch>,
Gregory Clement <gregory.clement@...tlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Russell King <linux@...linux.org.uk>,
Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Andreas Larsson <andreas@...sler.com>,
"David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Maxime Ripard <mripard@...nel.org>,
Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...l.net>,
Joyce Ooi <joyce.ooi@...el.com>,
Chris Snook <chris.snook@...il.com>,
Rafał Miłecki <rafal@...ecki.pl>,
"maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE"
<bcm-kernel-feedback-list@...adcom.com>,
Florian Fainelli <f.fainelli@...il.com>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Claudiu Beznea <claudiu.beznea@...rochip.com>,
Sunil Goutham <sgoutham@...vell.com>,
Fugang Duan <fugang.duan@....com>,
Madalin Bucur <madalin.bucur@....com>,
Pantelis Antoniou <pantelis.antoniou@...il.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Li Yang <leoyang.li@....com>,
Yisen Zhuang <yisen.zhuang@...wei.com>,
Salil Mehta <salil.mehta@...wei.com>,
Hauke Mehrtens <hauke@...ke-m.de>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Vadym Kochan <vkochan@...vell.com>,
Taras Chornyi <tchornyi@...vell.com>,
Mirko Lindner <mlindner@...vell.com>,
Stephen Hemminger <stephen@...workplumber.org>,
Felix Fietkau <nbd@....name>, John Crispin <john@...ozen.org>,
Sean Wang <sean.wang@...iatek.com>,
Mark Lee <Mark-MC.Lee@...iatek.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Bryan Whitehead <bryan.whitehead@...rochip.com>,
Vladimir Zapolskiy <vz@...ia.com>,
Sergei Shtylyov <sergei.shtylyov@...il.com>,
Byungho An <bh74.an@...sung.com>,
Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...com>,
Jose Abreu <joabreu@...opsys.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Kevin Hilman <khilman@...libre.com>,
Neil Armstrong <narmstrong@...libre.com>,
Jerome Brunet <jbrunet@...libre.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Vinod Koul <vkoul@...nel.org>,
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
Grygorii Strashko <grygorii.strashko@...com>,
Wingman Kwok <w-kwok2@...com>,
Murali Karicheri <m-karicheri2@...com>,
Michal Simek <michal.simek@...inx.com>,
Radhey Shyam Pandey <radhey.shyam.pandey@...inx.com>,
Kalle Valo <kvalo@...eaurora.org>,
Lorenzo Bianconi <lorenzo.bianconi83@...il.com>,
Ryder Lee <ryder.lee@...iatek.com>,
Stanislaw Gruszka <stf_xl@...pl>,
Helmut Schaa <helmut.schaa@...glemail.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Frank Rowand <frowand.list@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jérôme Pouiller <jerome.pouiller@...abs.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH 2/2] of: net: fix of_get_mac_addr_nvmem() for PCI and DSA nodes
On Mon, Apr 5, 2021 at 11:47 AM Michael Walle <michael@...le.cc> wrote:
>
> of_get_mac_address() already supports fetching the MAC address by an
> nvmem provider. But until now, it was just working for platform devices.
> Esp. it was not working for DSA ports and PCI devices. It gets more
> common that PCI devices have a device tree binding since SoCs contain
> integrated root complexes.
>
> Use the nvmem of_* binding to fetch the nvmem cells by a struct
> device_node. We still have to try to read the cell by device first
> because there might be a nvmem_cell_lookup associated with that device.
>
> Signed-off-by: Michael Walle <michael@...le.cc>
> ---
> Please note, that I've kept the nvmem_get_mac_address() which operates
> on a device. The new of_get_mac_addr_nvmem() is almost identical and
> there are no users of the former function right now, but it seems to be
> the "newer" version to get the MAC address for a "struct device". Thus
> I've kept it. Please advise, if I should kill it though.
It seems kind of backwards from how we normally design this type of
API where the API with a struct device will call a firmware specific
version if there's a firmware handle. But certainly, I don't think we
should be operating on platform device if we can help it.
> drivers/of/of_net.c | 37 +++++++++++++++++++++++++++++++------
> 1 file changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
> index 2344ad7fff5e..2323c6063eaf 100644
> --- a/drivers/of/of_net.c
> +++ b/drivers/of/of_net.c
> @@ -11,6 +11,7 @@
> #include <linux/phy.h>
> #include <linux/export.h>
> #include <linux/device.h>
> +#include <linux/nvmem-consumer.h>
>
> /**
> * of_get_phy_mode - Get phy mode for given device_node
> @@ -56,18 +57,42 @@ static int of_get_mac_addr(struct device_node *np, const char *name, u8 *addr)
> return -ENODEV;
> }
>
> -static int of_get_mac_addr_nvmem(struct device_node *np, 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;
> + }
> +
> + cell = of_nvmem_cell_get(np, "mac-address");
> + if (IS_ERR(cell))
> + return PTR_ERR(cell);
> +
> + mac = nvmem_cell_read(cell, &len);
> + nvmem_cell_put(cell);
> +
> + if (IS_ERR(mac))
> + return PTR_ERR(mac);
> +
> + if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
> + kfree(mac);
> + return -EINVAL;
> + }
>
> - ret = nvmem_get_mac_address(&pdev->dev, addr);
> - put_device(&pdev->dev);
> + ether_addr_copy(addr, mac);
> + kfree(mac);
>
> - return ret;
> + return 0;
> }
>
> /**
> --
> 2.20.1
>
Powered by blists - more mailing lists