Received: by 10.192.165.156 with SMTP id m28csp1755079imm; Tue, 17 Apr 2018 05:07:36 -0700 (PDT) X-Google-Smtp-Source: AIpwx49Zk4rLDcoSyo2NU8KtjuRVa/jnkiTEi6wXq8hAazavw5VddovHHhQmrbuUlspeztGDb9+0 X-Received: by 2002:a17:902:5a88:: with SMTP id r8-v6mr1844347pli.78.1523966856852; Tue, 17 Apr 2018 05:07:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523966856; cv=none; d=google.com; s=arc-20160816; b=VgYjng6AFuRcbULeQ1nLTb8rKwmSCSJSga+imrPDH2RYl394wQOyRMwNhS7aAtItWB uNvQW/yg4Uys8KdO8BiCJeunBx/UpzbtWzY2wI4nyKzUf/fr5e6cPOcF7gLcZf57vLKE EN8fnvdisN/a6OrxuKc3ceOpdmz1Y2VdSlWoGNTe9oP8OIUF+hX0nxyRV9XPr5ac+2cE tF+ffPPYboIklMzOyQ1tYb6pcL2PCjQgHliyeRQ8niUotTifsbvWgaN750UEii9bnWsm 0SA2mDS4xJrBUheMj/YZNDJV4wESRnIeOHJuWxfmMSQr5tHuhzbV20eW6bDhZGN4sdYA oSfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to:date :arc-authentication-results; bh=i3wRrrYZs7mTxK2/c7maAHJMg7ldcFOw7B1FvM0VA+0=; b=SXBJMx2pU5jA4CKK5vai9D1OP74rR1oLyoa1XJAR0a4EJAv1q9JPnaLdsZU1VT0zD9 3Ae2Jw70hRHunyTze5dJhhNzWnZtLRHu1ubMiIQxypvtqn1y9m0ev3Pt9fg97LwW1a+5 xSRIk4du1USbCgOiA2EElhZ6ig6ac/JwS9N1q2LBKICdlA5RhYCK/vpEQkvl6RKDRUy8 lVEcfEWfpVIG/jWBramyguKKNGLRCccX3nXOqbGyu2F7OEP8aVnJfUX3KilmrT/AEI3C 3qM0p9nxg5zHMebmDrlANRMXC7M57OzXXKm2KyO4fCbuxgr+v3ioPuaFTxpEFSRyeehZ 4Peg== 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.07.22; Tue, 17 Apr 2018 05:07:36 -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 S1753099AbeDQMGO convert rfc822-to-8bit (ORCPT + 99 others); Tue, 17 Apr 2018 08:06:14 -0400 Received: from hermes.aosc.io ([199.195.250.187]:43989 "EHLO hermes.aosc.io" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752655AbeDQMGM (ORCPT ); Tue, 17 Apr 2018 08:06:12 -0400 Received: from localhost (localhost [127.0.0.1]) (Authenticated sender: icenowy@aosc.io) by hermes.aosc.io (Postfix) with ESMTPSA id BA1535B222; Tue, 17 Apr 2018 12:06:04 +0000 (UTC) Date: Tue, 17 Apr 2018 20:06:00 +0800 In-Reply-To: References: <20180411141641.14675-1-icenowy@aosc.io> <20180411141641.14675-4-icenowy@aosc.io> <20180412145628.iaaeue2imiijwx5d@flea> <20180416143130.tls6xtcq3hsv7u7f@flea> <20180417115243.x42s7ygdpdbhtys2@flea> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [linux-sunxi] Re: [PATCH 3/5] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from device To: linux-arm-kernel@lists.infradead.org, Chen-Yu Tsai , Maxime Ripard CC: devicetree , netdev , linux-kernel , linux-sunxi , Rob Herring , Corentin Labbe , Giuseppe Cavallaro , linux-arm-kernel From: Icenowy Zheng Message-ID: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 于 2018年4月17日 GMT+08:00 下午7:59:38, Chen-Yu Tsai 写到: >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. In this situation maybe I should send newer revision of A64 drivers to you? > >ChenYu > >_______________________________________________ >linux-arm-kernel mailing list >linux-arm-kernel@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel