Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1460853imm; Thu, 19 Jul 2018 01:58:20 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf4oNdoshXg9114W6Aj2eo+0kIJXGpBDefgDN6l5xtjGUSEESuXaw4kOBNPUN8ah2WWRSzV X-Received: by 2002:a17:902:bb05:: with SMTP id l5-v6mr9323263pls.246.1531990700737; Thu, 19 Jul 2018 01:58:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531990700; cv=none; d=google.com; s=arc-20160816; b=aNvyPmiwUNCB2uZCR2NUsbGPujE0y+dkELLxtQZpffO9kO8O7ZDXyp5umU3fzPzpvG 9F8tMlpIk8eH3cvYBuQaj/Ip9W2e1td0k9tvOUBNyACrhQ5BncQ+GAEvcbhV6cK9sbws Xp/45dkWkNY6+o8U4nt7R5nZa1ERh1X2O/6yx+aVXl05/fLbAOZmV0U+5sJgRh/vk/15 R+xpXBUk9fLLcEr1SvJFHiaLkAkJ4d0j765TTYFCSAACOwXG6xOCgrg5YcLkG7GVHRrJ rzpf8O15KxMX2zxMyJtsTZQB0YzzDX3RHivsld02GlCEDUlJKJJX8I3Va/un7s4rtfvX j/dA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=I+JK3renuCFlAw9ZwiTA11KqBcnC3e0sol3C3ZezJ+o=; b=X9E0V7xtbjekJv/nqb4q0SeUYyH2Gru/iqDUtxyqUZXTPNQmtyEn8ahvrcG+pcZthL yHK6u0NqjLgMwPo5XFX0aICvOmfECkWY3lgQaKTv2eHaO2Hqw5PYofKVESYOaF/9YDm6 Ps0ekNJaCGs5MLdw+G4lpadKZTwnyYXBokJ0NKxj+JvSxs2eGXOXfqyeLAYEyDhTaWc+ cwNnmdbcQ3nkk/1WWVdcFfNkc8DxJk2pImhz/3GktAG6+vMh38I2YIUMVzpaCz2JEVdH k+wg6A1u2fDZ9NWcJF9qk0iebZcfYpyhi7e6qUZyb6Ukffqo/TSrNzx7b0CFvdPrQ9nn XxCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=T2rirjU6; 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 s15-v6si5081305pgm.56.2018.07.19.01.58.04; Thu, 19 Jul 2018 01:58:20 -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; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=T2rirjU6; 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 S1727485AbeGSJjh (ORCPT + 99 others); Thu, 19 Jul 2018 05:39:37 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:35792 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726704AbeGSJjh (ORCPT ); Thu, 19 Jul 2018 05:39:37 -0400 Received: by mail-oi0-f68.google.com with SMTP id i12-v6so14157574oik.2 for ; Thu, 19 Jul 2018 01:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I+JK3renuCFlAw9ZwiTA11KqBcnC3e0sol3C3ZezJ+o=; b=T2rirjU6q3CKuHa5dXHfF+NfX6/lPiGsqX3NQ34Jf3AxfMRDprAhJRYP7cdhkGczI5 xgrQ3QP3QpA+TdQgoxj8AQsKuZ6qhyXh73VJEvBw+iFNg26MOra53oD6JIVCnujZfovF H5R0XtvHabOd8nVpwYisq5+UPv/AVBFFgYjB+Qk7qTF/cZhENMzOIjCBGyeGaU1AUGnK Hbm8QCGH99wKSF8qaX94xpdb6idH8lvmDvpht+PBq4TGloVpL7uf50SRKAWH3TnbTM2G zvzoUNCNGBC2RgBeSfqy3OQhRlN03aF1rcbGtkbbTQXR5qhKnOgYPwBTUzXJk14u84DY u77w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I+JK3renuCFlAw9ZwiTA11KqBcnC3e0sol3C3ZezJ+o=; b=UR3t2x4VXLjvJWudK/dLvB3ztw7ZXsoUCQ6UNYaMWMbRN11nddDXSzr61eNxIu2Htl VfW65H6VbhZWXBIved3OOzwRXasMzYjZMLJof2CzSSlQaCfVPoML5K0tiTAMKQtw/YbH AjkZChomIJVP/e17sc9ucKFDIbLgjHgWWBVvYy9vKjX17v4b2rKvcASSbw53yH2y9gxu ocrbDdK2uMyLtOm2s2RYDM01aGFxG7yWpuarbz+C/muIXyIgXEVdIWVEA5QPlLKNpdZr kcuDfuRnvGqvuJ3D9SMBg4OruqOe20KHdDf+XOvpEtYT/SPJ9x/woFPzHg1LXaA9vBnr lL7Q== X-Gm-Message-State: AOUpUlHgN6uADD7RRAiWv+EmMrqhSjaKZs/6aHdLYlPUO3P4GzMinMPv zwLZlakqa5zfnC6CZNQbcT10/83uNNeqSv0jAq1j5Q== X-Received: by 2002:aca:6b51:: with SMTP id g78-v6mr10491248oic.290.1531990647882; Thu, 19 Jul 2018 01:57:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:2c15:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 01:57:27 -0700 (PDT) In-Reply-To: <20180719084503.tfv6jllsukk2zv3f@mwanda> References: <20180719082028.26116-1-brgl@bgdev.pl> <20180719082028.26116-3-brgl@bgdev.pl> <20180719084503.tfv6jllsukk2zv3f@mwanda> From: Bartosz Golaszewski Date: Thu, 19 Jul 2018 10:57:27 +0200 Message-ID: Subject: Re: [PATCH v2 2/3] net: add support for nvmem to eth_platform_get_mac_address() To: Dan Carpenter Cc: Bartosz Golaszewski , Sekhar Nori , Kevin Hilman , Russell King , Grygorii Strashko , "David S . Miller" , Srinivas Kandagatla , Lukas Wunner , Rob Herring , Florian Fainelli , Ivan Khoronzhuk , David Lechner , Greg Kroah-Hartman , Andrew Lunn , arm-soc , LKML , Linux-OMAP , netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-07-19 10:48 GMT+02:00 Dan Carpenter : > On Thu, Jul 19, 2018 at 10:20:27AM +0200, Bartosz Golaszewski wrote: >> From: Bartosz Golaszewski >> >> Many non-DT platforms read the MAC address from EEPROM. Usually it's >> either done with callbacks defined in board files or from SoC-specific >> ethernet drivers. >> >> In order to generalize this, try to read the MAC from nvmem in >> eth_platform_get_mac_address() using a standard lookup name: >> "mac-address". >> >> Signed-off-by: Bartosz Golaszewski >> --- >> net/ethernet/eth.c | 27 +++++++++++++++++++++++++++ >> 1 file changed, 27 insertions(+) >> >> diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c >> index 39af03894598..af3b4b1b77eb 100644 >> --- a/net/ethernet/eth.c >> +++ b/net/ethernet/eth.c >> @@ -54,6 +54,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -527,8 +528,11 @@ unsigned char * __weak arch_get_platform_mac_address(void) >> >> int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr) >> { >> + unsigned char addrbuf[ETH_ALEN]; >> const unsigned char *addr; >> + struct nvmem_cell *nvmem; >> struct device_node *dp; >> + size_t alen; >> >> if (dev_is_pci(dev)) >> dp = pci_device_to_OF_node(to_pci_dev(dev)); >> @@ -541,6 +545,29 @@ int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr) >> if (!addr) >> addr = arch_get_platform_mac_address(); >> >> + if (!addr) { >> + nvmem = nvmem_cell_get(dev, "mac-address"); >> + if (IS_ERR(nvmem) && PTR_ERR(nvmem) == -EPROBE_DEFER) >> + /* We may have a lookup registered for MAC address but >> + * the corresponding nvmem provider hasn't been >> + * registered yet. >> + */ >> + return -EPROBE_DEFER; >> + >> + if (!IS_ERR(nvmem)) { >> + addr = nvmem_cell_read(nvmem, &alen); >> + if (!IS_ERR(addr)) { > ^^^^ > Never do success handling. Always error handling. Otherwise the code > is indent a lot and the error handling is far from the call. > >> + if (alen == ETH_ALEN) >> + ether_addr_copy(addrbuf, addr); >> + >> + kfree(addr); >> + addr = alen == ETH_ALEN ? addrbuf : NULL; >> + } >> + >> + nvmem_cell_put(nvmem); >> + } >> + } >> + >> if (!addr || !is_valid_ether_addr(addr)) > ^^^^ > Instead of handling the error we dereference the error pointer here. > True - we should add a check for IS_ERR(addr) here. > *frowny face* > >> return -ENODEV; >> >> -- > > Maybe this? > > if (!addr) { > nvmem = nvmem_cell_get(dev, "mac-address"); > if (PTR_ERR(nvmem) == -EPROBE_DEFER) > return -EPROBE_DEFER; > if (IS_ERR(nvmem)) > return -ENODEV; > addr = nvmem_cell_read(nvmem, &alen); > if (IS_ERR(addr)) > return PTR_ERR(addr); > if (alen != ETH_ALEN) { > kfree(addr); > return -ENODEV; > } > ether_addr_copy(addrbuf, addr); > kfree(addr); > addr = addrbuf; > } > if (!is_valid_ether_addr(addr)) > return -ENODEV; > ether_addr_copy(mac_addr, addr); > return 0; > I would normally go this way but here we don't want to bail out when we encounter an error but rather continue on to the next possible source of a MAC address. We'll get -ENODEV from nvmem_cell_get() if the lookup fails for "mac-address" but instead of returning an error code we should then check if we can read the MAC from MTD. Bart