Received: by 10.192.165.156 with SMTP id m28csp1747885imm; Tue, 17 Apr 2018 05:01:36 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+gGGXrZnfLq1qzpGlFWkO/vlvMBABSAPqNjJxmsymJ0yVQD+7ECcHHO0TefXxHhpXQW78e X-Received: by 10.101.96.10 with SMTP id m10mr1529726pgu.281.1523966495951; Tue, 17 Apr 2018 05:01:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523966495; cv=none; d=google.com; s=arc-20160816; b=D4i8PSuG358+estnjjuqaHKxDNTmuKkkcQ1otTYF+fzattfFIXWs3U9+e1zriX0q8j kwDOz62ZlBSHaiDJ129BxiIx833BcQBJlL3+hF7uq+LkFuO/9QRewFDJ05MisPZLJaGF c8kbLsizNfZg8TN6P1HhkoeHI2GC3ZgDM41NkakXER4NyCZlvDmwof4x4w34NCDlLvtv u3ZPQ5WfRbbzq2PeBDuI/VBynnE57lZphR4UIDg7Jq+tL4eXrGaN0Qc4iffyMpJKQRnm 9SOpUxTse6U7EUhmivfoVmYJcfxdHAlT87NRK2aCHlaSfoHoSwPiQML14FVLpo1+gzY8 Mfrw== 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:references:in-reply-to:mime-version :arc-authentication-results; bh=bPul4xC+ojBCOarTzMQMvC5UKN+Kv4+PacshPqJCoDQ=; b=vhbTF4hJVj89iehd2V1gluresKOnWB7DZG+in9UQO8SulX3K6y4nTBdA1u9oQAxD6s moM8Sn019ZTju0Qa+HwrK5xECeZn2mhAkMGDSIlCC1VIkjhhMYrdkc4yRAsQX5PHhAES oA3FNcscyO1aX5z/+DeynDgn6izl+d8c72ljY0m+ZEi4rYyKamkZRS7kbKzVLk0mv/xC 97XRqspen85clcdJy4/Jq1VbemvNENhtqP1/Ppzoq6FA0E5Hhosndg3/ATP3+aID92R5 cmYfFknfVvZ//T6eA8296d7H1UrOcin9GZiJ2Mhww0uTZmNpfOyr9hsUmTY8c0zYG6Cx yk5A== 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 r17si12278466pfh.15.2018.04.17.05.01.15; Tue, 17 Apr 2018 05:01:35 -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 S1752916AbeDQMAE convert rfc822-to-8bit (ORCPT + 99 others); Tue, 17 Apr 2018 08:00:04 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:46157 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752546AbeDQMAC (ORCPT ); Tue, 17 Apr 2018 08:00:02 -0400 Received: by mail-wr0-f193.google.com with SMTP id d1so34740724wrj.13; Tue, 17 Apr 2018 05:00:01 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=C281/VzgnQYHdR9KIQEzz5eQZkgrMxEOhvrJcqAVsHo=; b=trXNPxHRG9k+oSnjbH4Lft430yplz8BgrNtXeK0dAzkgkTSc9LjQnVlQRKYRiltZi6 hSxxJOnqMNKbbruXycEVKJRRUwU+O/bNUc+o3r95JnHWUxtnG4bdguKYP750CKsjny2R dEqOq54o+ovjADEQhJuD+GZcXsTPm3is4JiDOlIwVcDtZPTYP2zqMeDUY3Vt7D5H9yUP 2JFlv5O2fg8Qy9R6GpFhEtmXLOkfrVzYG6NcWkScW5g9f/DFExGiSdhq+wLZFTWGvIJ6 eLHabvoNhJEvOV5KFr+WZeQZLXja0LpcQ4w2fqNAmvxK/2XVUiOlVPCc02TezIvM8//D 3JUQ== X-Gm-Message-State: ALQs6tAOumuWYVVpqn9J6GglxrYFEQTuttUW7p94tvIj6f01T2+Dft43 0DdXXWdruRupZ21TCdZqcb7GhpcF X-Received: by 10.80.145.41 with SMTP id e38mr2721515eda.191.1523966400454; Tue, 17 Apr 2018 05:00:00 -0700 (PDT) Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com. [209.85.128.169]) by smtp.gmail.com with ESMTPSA id g24sm8986854edj.87.2018.04.17.04.59.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 04:59:59 -0700 (PDT) Received: by mail-wr0-f169.google.com with SMTP id d19so34768038wre.1; Tue, 17 Apr 2018 04:59:58 -0700 (PDT) X-Received: by 10.223.131.162 with SMTP id 31mr1466150wre.19.1523966398745; Tue, 17 Apr 2018 04:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.142.19 with HTTP; Tue, 17 Apr 2018 04:59:38 -0700 (PDT) In-Reply-To: <20180417115243.x42s7ygdpdbhtys2@flea> References: <20180411141641.14675-1-icenowy@aosc.io> <20180411141641.14675-4-icenowy@aosc.io> <20180412145628.iaaeue2imiijwx5d@flea> <20180416143130.tls6xtcq3hsv7u7f@flea> <20180417115243.x42s7ygdpdbhtys2@flea> From: Chen-Yu Tsai Date: Tue, 17 Apr 2018 19:59:38 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [linux-sunxi] Re: [PATCH 3/5] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from device To: Maxime Ripard , Icenowy Zheng Cc: Rob Herring , Giuseppe Cavallaro , Corentin Labbe , netdev , devicetree , linux-arm-kernel , linux-kernel , linux-sunxi 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 Tue, Apr 17, 2018 at 7:52 PM, Maxime Ripard wrote: > On Mon, Apr 16, 2018 at 10:51:55PM +0800, Chen-Yu Tsai wrote: >> On Mon, Apr 16, 2018 at 10:31 PM, Maxime Ripard >> wrote: >> > On Thu, Apr 12, 2018 at 11:23:30PM +0800, Chen-Yu Tsai wrote: >> >> On Thu, Apr 12, 2018 at 11:11 PM, Icenowy Zheng wrote: >> >> > 于 2018年4月12日 GMT+08:00 下午10:56:28, Maxime Ripard 写到: >> >> >>On Wed, Apr 11, 2018 at 10:16:39PM +0800, Icenowy Zheng wrote: >> >> >>> From: Chen-Yu Tsai >> >> >>> >> >> >>> On the Allwinner R40 SoC, the "GMAC clock" register is in the CCU >> >> >>> address space; on the A64 SoC this register is in the SRAM controller >> >> >>> address space, and with a different offset. >> >> >>> >> >> >>> To access the register from another device and hide the internal >> >> >>> difference between the device, let it register a regmap named >> >> >>> "emac-clock". We can then get the device from the phandle, and >> >> >>> retrieve the regmap with dev_get_regmap(); in this situation the >> >> >>> regmap_field will be set up to access the only register in the >> >> >>regmap. >> >> >>> >> >> >>> Signed-off-by: Chen-Yu Tsai >> >> >>> [Icenowy: change to use regmaps with single register, change commit >> >> >>> message] >> >> >>> Signed-off-by: Icenowy Zheng >> >> >>> --- >> >> >>> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 48 >> >> >>++++++++++++++++++++++- >> >> >>> 1 file changed, 46 insertions(+), 2 deletions(-) >> >> >>> >> >> >>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c >> >> >>b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c >> >> >>> index 1037f6c78bca..b61210c0d415 100644 >> >> >>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c >> >> >>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c >> >> >>> @@ -85,6 +85,13 @@ const struct reg_field old_syscon_reg_field = { >> >> >>> .msb = 31, >> >> >>> }; >> >> >>> >> >> >>> +/* Specially exported regmap which contains only EMAC register */ >> >> >>> +const struct reg_field single_reg_field = { >> >> >>> + .reg = 0, >> >> >>> + .lsb = 0, >> >> >>> + .msb = 31, >> >> >>> +}; >> >> >>> + >> >> >> >> >> >>I'm not sure this would be wise. If we ever need some other register >> >> >>exported through the regmap, will have to change all the calling sites >> >> >>everywhere in the kernel, which will be a pain and will break >> >> >>bisectability. >> >> > >> >> > In this situation the register can be exported as another >> >> > regmap. Currently the code will access a regmap with name >> >> > "emac-clock" for this register. >> >> > >> >> >> >> >> >>Chen-Yu's (or was it yours?) initial solution with a custom writeable >> >> >>hook only allowing a single register seemed like a better one. >> >> > >> >> > But I remember you mentioned that you want it to hide the >> >> > difference inside the device. >> >> >> >> The idea is that a device can export multiple regmaps. This one, >> >> the one named "gmac" (in my soon to come v2) or "emac-clock" here, >> >> is but one of many possible regmaps, and it only exports the register >> >> needed by the GMAC/EMAC. >> > >> > I'm not sure this would be wise either. There's a single register map, >> > and as far as I know we don't have a binding to express this in the >> > DT. This means that the customer and provider would have to use the >> > same name, but without anything actually enforcing it aside from >> > "someone in the community knows it". >> > >> > This is not a really good design, and I was actually preferring your >> > first option. We shouldn't rely on any undocumented rule. This will be >> > easy to break and hard to maintain. >> >> So, one regmap per device covering the whole register range, and the >> consumer knows which register to poke by looking at its own compatible. >> >> That sound right? > > Yep. And ideally, sending a single serie for both the A64 and the R40 > cases, in order to provide the big picture. OK. I'll incorporate Icenowy's stuff into my series. ChenYu