Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1012057imm; Thu, 4 Oct 2018 06:59:28 -0700 (PDT) X-Google-Smtp-Source: ACcGV61D55DPb/xolfz4ciUnXEl5+zkb19IMwQuU6vSYYsh0keHEKJBhyZzmn6+hu4WDSZSkhnyY X-Received: by 2002:a17:902:8d94:: with SMTP id v20-v6mr6858759plo.20.1538661568594; Thu, 04 Oct 2018 06:59:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538661568; cv=none; d=google.com; s=arc-20160816; b=xnKGxl0klS7gF0eAn73G2RhG9V300HdganRbee4CJYvVW0JxjL/t6Y/3dUgvq+xEq5 FgCxnb3c8MFuzzppSp5SZVbNCBmRidVE1B7g2AzY1me4d3y2zWh+k9KCZGjJ0J6ch20M x2Ruz8Bhiw7sbi0ZXJ6vcbkzPHMjrNoNoMotqzLvss35AAcubN6H7GYrrHYQEz1UhpSc R/OG55l3sKV6iDwFpkrvRp7S8mxlVHZDMgtrbMejBIThR+KDorUZwObydqKVPA9EOSo+ ZuH0E2SadHYaWXwEMcSZXyJnuEISV4qjC5aICgMb5nc/aJpqt85LErjH4Hq1HNscy0l2 GnHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=/Gpg6ppGM3xKITzwKoBeKInKzfWBh9Kw9XXyghThCq0=; b=e7H+m47xT9vxWcO7Ra8QMWxJPpX6tKFS5Hw9zLtuycG+Gq9frA5yu1McbYGhuj5VGt 3dsxiVEFHY/J8el3A3zvnYxd1OAhfNOzRjqSAGhB+uYHoafSlBIJmqRaGDXXKj5Hykjr dhWoyO7GJ0WMaLdgYyNeH6HrYnPQJvgD75YbUjdwAM5KfcJ1U9ZeuAlPOVJBlsgi1njq JE7bsclZC+lumz1l2vwXO62QKP1VhBH3aYj+Af6xl8PIjMr6pWMOTHA+2qtguK2gsKUq 7rGKp5ZEvHetR0c8T7NXdtBpIhkhS2/eZJqmkaSjJyUr1XfuuzcyFvVCszadgvVEQyOV Q36g== 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 h17-v6si921035pfi.84.2018.10.04.06.59.12; Thu, 04 Oct 2018 06:59:28 -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 S1727581AbeJDUwU convert rfc822-to-8bit (ORCPT + 99 others); Thu, 4 Oct 2018 16:52:20 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:39696 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727354AbeJDUwT (ORCPT ); Thu, 4 Oct 2018 16:52:19 -0400 Received: by mail-qk1-f194.google.com with SMTP id q5-v6so5774718qki.6; Thu, 04 Oct 2018 06:58:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OwxIbrSa7/wCHrKfpuJEJ1buXU3clGTQHZffoxEVnkg=; b=Hg4SNUWpx8bNin6ibjS3COaSwnovNMJ3/Q7mKEm2vRdh5pHipB2Pp3ApVTER9K9/SV C577fDxVuYbOfG6J6ZAmDpzbNbvN5LEsMcd4pGIVzym3PQuLFXdTjNP+fLYx2f9TXiDz WJUmhpsTHKA31iBafXsa2DYNzMEOVrifxgysItp1OO6jk8D9HaM5RmKwwJXj9KVETTE7 jiw6MWMPZWF6EshJaeQV3+CTmekBjYhVX4Gjre/wAsTDNmaAaAXZ1NyK+UgTO5Sutubd j2IYhylFM0La+leuby+fpgcQPk5hYShS+baqvfzxymOd+VNnEXRzBnuL3KH8V/rjyRMu bTKA== X-Gm-Message-State: ABuFfohflh2gUagvQ1Db0TPKI5W3zaxee1cbT3spTOa3mwxaNdhFDkNK C1xp3W6VXaKcOWGYvF/vw9yFqh6mmYYloLVlQQo= X-Received: by 2002:a37:7347:: with SMTP id o68-v6mr5300016qkc.291.1538661532950; Thu, 04 Oct 2018 06:58:52 -0700 (PDT) MIME-Version: 1.0 References: <20180810080526.27207-1-brgl@bgdev.pl> <20180831194643.GA62862@ban.mtv.corp.google.com> In-Reply-To: From: Arnd Bergmann Date: Thu, 4 Oct 2018 15:58:36 +0200 Message-ID: Subject: Re: [PATCH v2 00/29] at24: remove at24_platform_data To: Bartosz Golaszewski Cc: Florian Fainelli , Brian Norris , David Miller , Jonathan Corbet , Sekhar Nori , Kevin Hilman , Russell King - ARM Linux , gregkh , David Woodhouse , Boris Brezillon , Marek Vasut , Richard Weinberger , Grygorii Strashko , Srinivas Kandagatla , naren.kernel@gmail.com, Mauro Carvalho Chehab , Andrew Morton , Lukas Wunner , Dan Carpenter , ivan.khoronzhuk@linaro.org, svendev@arcx.com, pabeni@redhat.com, Alban Bedel , Rob Herring , David Lechner , Andrew Lunn , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Linux ARM , Linux I2C , linux-mtd , linux-omap , Networking , Bartosz Golaszewski , Brian Norris , Sowmini Varadhan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 4, 2018 at 1:06 PM Bartosz Golaszewski wrote: > śr., 3 paź 2018 o 23:04 Florian Fainelli napisał(a): > > On 10/3/2018 1:15 PM, Bartosz Golaszewski wrote: > > > pt., 31 sie 2018 o 21:46 Brian Norris napisał(a): > > >> > > >> Hi, > > >> > > >> On Fri, Aug 10, 2018 at 10:04:57AM +0200, Bartosz Golaszewski wrote: > > >>> Most boards use the EEPROM to store the MAC address. This series adds > > >>> support for cell lookups to the nvmem framework, registers relevant > > >>> cells for all users, adds nvmem support to eth_platform_get_mac_address(), > > >>> converts davinci_emac driver to using it and replaces at24_platform_data > > >>> with device properties. > > >> > > >> We already have: > > >> > > >> of_get_nvmem_mac_address() (which does exactly what you're adding, > > >> except it's DT specific) > > >> of_get_mac_address() > > >> fwnode_get_mac_address() > > >> device_get_mac_address() > > >> > > >> and now you've taught me that this exists too: > > >> > > >> eth_platform_get_mac_address() > > >> > > >> These mostly don't share code, and with your series, they'll start to > > >> diverge even more as to what they support. Can you please help rectify > > >> that, instead of widening the gap? > > >> > > >> For instance, you can delete most of eth_platform_get_mac_address() and > > >> replace it with device_get_mac_address() [1]. And you could add your new > > >> stuff to fwnode_get_mac_address(). > > >> > > >> And important part to note here is that you code isn't just useful for > > >> ethernet -- it could be useful for Wifi devices too. So IMO, sticking it > > >> only in an "eth" function is the wrong move. > > >> > > >> Brian > > >> > > >> [1] arch_get_platform_mac_address() is the only part I wouldn't want to > > >> replicate into a truly generic helper. The following should be a no-op > > >> refactor, AIUI: > > >> > > > > > > The only user of arch_get_platform_mac_address() is sparc. It returns > > > an address that seems to be read from some kind of EEPROM. I'm not > > > familiar with this arch though. I'm wondering if we could somehow > > > seamlessly remove this call and then convert all users of > > > eth_platform_get_mac_address() to using device_get_mac_address()? > > > > > > David: I couldn't find a place in sparc code where any ethernet device > > > would be registered, so is there a chance that nobody is using it? > > > > SPARC uses a true Open Firmware implementation, so it would register > > drivers through the CONFIG_OF infrastructure. > > -- > > I'm seeing that there are only six callers of > eth_platform_get_mac_address() (the only function which calls > arch_get_platform_mac_address()). > > Of these six callers four are intel ethernet drivers and two are usb > ethernet adapter drivers. > > Is it even possible that sparc wants to get the mac address for a usb > adapter from some memory chip? Maybe we *can* safely remove that > function completely? That would allow us to simplify a lot of code. The calls are not even that old, and clearly added intentionally for sparc, see commit ba94272d08a7 ("i40e: use eth_platform_get_mac_address()") which added the first one. Before that commit, the driver did the same as a couple of sun specific ones that access the idprom directly: drivers/net/ethernet/aeroflex/greth.c: macaddr[i] = (unsigned int) idprom->id_ethaddr[i]; drivers/net/ethernet/amd/sun3lance.c: dev->dev_addr[i] = idprom->id_ethaddr[i]; drivers/net/ethernet/amd/sunlance.c: dev->dev_addr[i] = idprom->id_ethaddr[i]; drivers/net/ethernet/broadcom/tg3.c: memcpy(dev->dev_addr, idprom->id_ethaddr, ETH_ALEN); drivers/net/ethernet/i825xx/sun3_82586.c: dev->dev_addr[i] = idprom->id_ethaddr[i]; drivers/net/ethernet/sun/sunbmac.c: dev->dev_addr[i] = idprom->id_ethaddr[i]; drivers/net/ethernet/sun/sungem.c: addr = idprom->id_ethaddr; drivers/net/ethernet/sun/sunhme.c: memcpy(dev->dev_addr, idprom->id_ethaddr, ETH_ALEN); drivers/net/ethernet/sun/sunhme.c: memcpy(dev->dev_addr, idprom->id_ethaddr, ETH_ALEN); drivers/net/ethernet/sun/sunqe.c: memcpy(dev->dev_addr, idprom->id_ethaddr, ETH_ALEN); Arnd