Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1824472imm; Thu, 19 Jul 2018 08:26:01 -0700 (PDT) X-Google-Smtp-Source: AAOMgpddIhGtP96Ju3y9cotAR4XR/epeKkLZ1FH48pIwUgZI89sX0lV9R7AcZDSprvYp1i/QA89u X-Received: by 2002:a17:902:3f81:: with SMTP id a1-v6mr10541523pld.29.1532013961929; Thu, 19 Jul 2018 08:26:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532013961; cv=none; d=google.com; s=arc-20160816; b=SjHyP5LT2WDtd39rk9nwrxkq/10/7252WpzsgZNTcOWVni738+L/6kPevcYTZHU8vJ M21dNuSFbCZ9m0T5B6lEsGiemqlaERjI68JG5bGtygi1ecM0Ux8pSu00AusQ3AtdQ16Z qxQ+qX99/iDfkIcrNAmwm/vCPUq+5TfIbm30p8mBcdeOTvy31ushplSiXET6E+mXatbV OQDUkOuW9aD9YtMP28kXb3oKbRj1TnH6FBsls0Y2b4A8DBTnBs3rn9DbVHd/Yw37gePt 7jD4NFZS2gEfztTgeUsD7ylqceha9JvrJGKBLbgrkXehPdDc2mYe8LZj2J1WMk0tuKS6 O92A== 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=sdGWK01zvDzSx7or2ETxkSK3GK8/l38qM2g0wM3HV0w=; b=IoyGBkAc3s2/kzisajtLvJuDNrBdVf5Rrx98H5j0YWtY5DGHmkfX4fZYVJK7kQk+lf GPtUPIPgHieGLelaDSQXyZ7MqBAUp1rKK9v0fvXhYh3j3AUCqmHF5Eqjz98cydw1Fn6V pq+/XUZWcMyewLouNaZC+2GsURwtbp2NSm0Xani6vgfO+6A/9amTOw1O58unCFJLobJt t7b9qpP85/hwsRB07PZ4aukEkD14E4ItGbG58MzuAJDo31e02fZpPyZ/hTJpU0L/FabY HYmxvVyclov/RRZBCgjv6HSLI5Mnf+yv6lYCAoqQ5+NlR7gKfcbqC/cSqEEq7aborcof fw6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=RWpZ+PLC; 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 d33-v6si6241754pgd.245.2018.07.19.08.25.46; Thu, 19 Jul 2018 08:26:01 -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=RWpZ+PLC; 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 S1731914AbeGSQIo (ORCPT + 99 others); Thu, 19 Jul 2018 12:08:44 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:44258 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731810AbeGSQIn (ORCPT ); Thu, 19 Jul 2018 12:08:43 -0400 Received: by mail-oi0-f66.google.com with SMTP id s198-v6so15644793oih.11 for ; Thu, 19 Jul 2018 08:25:03 -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=sdGWK01zvDzSx7or2ETxkSK3GK8/l38qM2g0wM3HV0w=; b=RWpZ+PLCdS7gPW7P6crbIuLuU0moifnx5+qG8btHzrIMO9KyC4LIQ4C43hdsCSaiX4 3TnzYvmDBhAgO35RYQs7kxqkz2IQu1iDojud5zUlj8KXVQp1DeEGGKcVHFanO3A2+N07 iXAeZBnu1Y4OzNquLZES1/cpmb3pGXnxPOPkKylo6mbT1x+0q3AFYPgRItdQ+7Rek15c rF3LKW6PFsqUMOcsSn+n2XdserimB0AvHTMHPbUhj9tIcU2X8xcb9l2sF6MgU/2Vgw7o 4QVTJltK+HU1WpwFEbl7NrLMlAn785zQcUFYVzBOiIgoGVffAuTz5vnniNiAjW3yaW2+ Fy+Q== 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=sdGWK01zvDzSx7or2ETxkSK3GK8/l38qM2g0wM3HV0w=; b=i65n62NpKx2xpQO+hl7Kbd31E8xJLvmZ/UBhaKygJUvpXwGhApxOUvg79qWNMXtg2h 0g1Euk3AIV/hWXw4diaQqrPF0iQ58WRwstYZEZ1KJMX1xWfN7p+6BVUMb2CSnqx6UQOi dSbHU8C4ME1pOL6Q1LFEfps6QqQ6biW1UUOt9On/Htzw8BlbkvA7F1pQ+cChpEQnVwWB pLiRbXnpqYpUzwjbdetfOF9tO2GKWaCMy9OghCRDILgBw0Dy8FKYQhoRuQTz8LiJ3Bl5 wmhOQ35rjwcmUd4yzi1cifyjupn1rcPQwkDbZlDmiNpronCHm3R77qASh9wDpmcQyb3X MuBA== X-Gm-Message-State: AOUpUlH2ohaBzTjfgHwVUXntYqMR5CzDlXlrGdQK9/3E0nS5MpLcfd7Q 5huoKsbCQPO7wmWM3Kapc3D/M2CocJtDfKtSI3PQYQ== X-Received: by 2002:aca:310b:: with SMTP id x11-v6mr11793311oix.74.1532013902774; Thu, 19 Jul 2018 08:25:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:2c15:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 08:25:02 -0700 (PDT) In-Reply-To: <20180719152222.GD9119@lunn.ch> References: <20180718161035.7005-1-brgl@bgdev.pl> <20180718161035.7005-5-brgl@bgdev.pl> <20180719152222.GD9119@lunn.ch> From: Bartosz Golaszewski Date: Thu, 19 Jul 2018 17:25:02 +0200 Message-ID: Subject: Re: [PATCH 4/5] net: add support for nvmem to eth_platform_get_mac_address() To: Andrew Lunn Cc: Bartosz Golaszewski , Sekhar Nori , Kevin Hilman , Russell King , Grygorii Strashko , "David S . Miller" , Srinivas Kandagatla , Lukas Wunner , Rob Herring , Florian Fainelli , Dan Carpenter , Ivan Khoronzhuk , David Lechner , Greg Kroah-Hartman , 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 17:22 GMT+02:00 Andrew Lunn : > On Wed, Jul 18, 2018 at 06:10:34PM +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 | 29 +++++++++++++++++++++++++++++ >> 1 file changed, 29 insertions(+) >> >> diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c >> index 6b64586fd2af..adf5bd03851f 100644 >> --- a/net/ethernet/eth.c >> +++ b/net/ethernet/eth.c >> @@ -54,6 +54,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -530,7 +531,10 @@ int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr) >> struct device_node *dp = dev_is_pci(dev) ? >> pci_device_to_OF_node(to_pci_dev(dev)) : dev->of_node; >> const unsigned char *addr = NULL; >> + unsigned char addrbuf[ETH_ALEN]; >> + struct nvmem_cell *nvmem; >> const char *from = NULL; >> + size_t alen; >> >> if (dp) { >> addr = of_get_mac_address(dp); >> @@ -544,6 +548,31 @@ int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr) >> from = "arch callback"; >> } >> >> + if (!addr) { >> + nvmem = nvmem_cell_get(dev, "mac-address"); >> + if (IS_ERR(nvmem) && PTR_ERR(nvmem) == -EPROBE_DEFER) > > How does EPROBE_DEFER work here? You say the use case is > Non-DT. Without having DT, how do you know the cell should exist, but > does not yet exist? I might be looking at old code, but i only see > -EPROBE_DEFER inside the if (np) case. > >> + /* We may have a lookup registered for MAC address but >> + * the corresponding nvmem provider hasn't been >> + * registered yet. >> + */ >> + return -EPROBE_DEFER; > > You really should return real errors. If i'm reading > __nvmem_device_get() right, it will return a NULL pointer when the > cell does not exist. NULL is not an error, so IS_ERR() will return > false. So you should return all errors from nvmem_cell_get(). > > Andrew We have a patch queued for nvmem for 4.19 which adds a notion of nvmem cell lookups similar to gpio lookups: https://patchwork.kernel.org/patch/10496045/ This will work fine with probe deferral. Bart