Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4687231yba; Wed, 8 May 2019 00:41:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqz3rjf9cMNXtH9wslxlR0UqFZp0dIj4JcNoCedctp5YKpU8VEIK1+nMeMPq8wiE9HvyOkOU X-Received: by 2002:a65:5687:: with SMTP id v7mr44954900pgs.299.1557301291901; Wed, 08 May 2019 00:41:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557301291; cv=none; d=google.com; s=arc-20160816; b=1Ixk31biMTuIRUYwe47CLEoihNOtT4ZW7GftB42Z60OTe8eqAnlr6B2a9LLSQF+tjj 9huzvji3nzIcfrl5vY7jpbhnmeg10R7Qzrhi4W/mXSTngY5PTi7tB1ZGO8I/Ot1Z27hm J5aD/t0a1sbjQUIJky07dMjGyAl7TdaLqkQnL5bC4wKaNULsuiJBr2kbrcK/4H6aDgNN Uvso7AQX5neHGx8zahOdROS2xtevyCRkINLJRDiX6QQd9UnJbCH/8LNidHW9ajfQjyEh tZOKFQocpY+ZdA2Krm+X5HsG30V/wNmAJw5TnVXSRIDRTHH0e1gq/Cdtt5LPXiSw+u8s 3qNw== 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 :in-reply-to:references:mime-version:dkim-signature; bh=kdzNGG6w8busuuDVf/UQqEgzyyAeZLA0QEhPPerzhfg=; b=rQXXWo0OimMVRrCddQaC7GnrwoddtUlORpdaNdnCC8LtnZgSg+thKU68IZksKo3iN8 PtTXMBFiNfAUyUcD5KL5ErI7CU0xyhFa/6YdCp46Fw0DJYP6QoDNy55y9OL0f6r67oyN Qv+h0PLh4xzcWl1d2wQjOUhFmwwctz0+N6DERdRt/SFq9zX4n+6lmYNQ63fee8x/buel dHtOJn1c27/0UCNLa3b41+m+WM8KRybz0v2YZyDz95TyqA/6eoLr9mnM2pjWn+DuAlvp 79ObQ5Xqq4KZ1XZs8wNH8+jqL0ImP0gmkHoQL/n6EQQgVbtJh5u21AV3wtWWdjZIeQdF c+tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=mGDwoD4U; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i1si20047844pgq.528.2019.05.08.00.41.16; Wed, 08 May 2019 00:41:31 -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=@chromium.org header.s=google header.b=mGDwoD4U; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727226AbfEHHkE (ORCPT + 99 others); Wed, 8 May 2019 03:40:04 -0400 Received: from mail-qk1-f193.google.com ([209.85.222.193]:35051 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726720AbfEHHkD (ORCPT ); Wed, 8 May 2019 03:40:03 -0400 Received: by mail-qk1-f193.google.com with SMTP id c15so2621915qkl.2 for ; Wed, 08 May 2019 00:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kdzNGG6w8busuuDVf/UQqEgzyyAeZLA0QEhPPerzhfg=; b=mGDwoD4U62ey6G7SruSx83RUQNe+cXi/7VIMvqL9+ahBUlgPNQwS98dYlXxeQxQ8Bk IFuhOGwxWtAVuqezODZivYfjrX+e6ntlFVnvGVkxIp8xa9mms3GEcgUcVyeOzSv2/dj5 /BZw0T/c0G6FkPHM4B0kzgTFXOIZmj9mSHFqo= 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; bh=kdzNGG6w8busuuDVf/UQqEgzyyAeZLA0QEhPPerzhfg=; b=Cconv0H3Q+/fktuA+gOf3V0G5AmAmxGK6YHxMStsgqs75YxhHSskpeZs/0pwQxNaM8 08usCjaNMCMrpcelcIreh/8EBq1p6jODPbmOEWhr96aiRRHGR8pQui+OoKli89uVjtFG NyWDAAqla1T0d8vv7jZeQlV0HETcQqwgIrfO6G6qBEU7sY5cWHgFTW0Mf7uAZuVdlvkH rvwuKi6xYtWAyoYgb2o1rNkM0BifAKdPOkB9m4B/JtBJErMls0V64riHU9OxGsOzpVNf vHNcPqEM+IldWNRLGtwNmImDxzGI9MBWHuQJf7Rllz86QNReAHlm03uhvFpSydxipxNZ rKmQ== X-Gm-Message-State: APjAAAX0yZSxSIqMHhSnBRKjYimWhNMwjx2ZM2VA7kPZHKekvoTdjV/U 5WDpWqxmqzj0Os1WT4Iwkd6ms9CakeUoQSvrc4aphg== X-Received: by 2002:a05:620a:1670:: with SMTP id d16mr15764186qko.288.1557301201879; Wed, 08 May 2019 00:40:01 -0700 (PDT) MIME-Version: 1.0 References: <20190429032551.65975-1-drinkcat@chromium.org> <20190429032551.65975-2-drinkcat@chromium.org> <1556804888.28808.6.camel@mtksdaap41> In-Reply-To: From: Nicolas Boichat Date: Wed, 8 May 2019 16:39:50 +0900 Message-ID: Subject: Re: [PATCH 1/2] pinctrl: mediatek: Add mtk_eint_pm_ops to common-v2 To: Sean Wang Cc: Yingjoe Chen , Chuanjia Liu , Linus Walleij , lkml , Evan Green , Stephen Boyd , linux-gpio@vger.kernel.org, "moderated list:ARM/Mediatek SoC support" , Matthias Brugger , linux-arm Mailing List 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 On Sat, May 4, 2019 at 2:09 AM Sean Wang wrote: > > Hi, Nicolas > > On Thu, May 2, 2019 at 5:53 PM Nicolas Boichat wrote: > > > > On Thu, May 2, 2019 at 9:48 PM Yingjoe Chen wrote: > > > > > > On Mon, 2019-04-29 at 11:25 +0800, Nicolas Boichat wrote: > > > > pinctrl variants that include pinctrl-mtk-common-v2.h (and not > > > > pinctrl-mtk-common.h) also need to use mtk_eint_pm_ops to setup > > > > wake mask properly, so copy over the pm_ops to v2. > > > > > > > > It is not easy to merge the 2 copies (or move > > > > mtk_eint_suspend/resume to mtk-eint.c), as we need to > > > > dereference pctrl->eint, and struct mtk_pinctrl *pctl has a > > > > different structure definition for v1 and v2. > > > > > > > > Signed-off-by: Nicolas Boichat > > > > Reviewed-by: Chuanjia Liu > > > > --- > > > > .../pinctrl/mediatek/pinctrl-mtk-common-v2.c | 19 +++++++++++++++++++ > > > > .../pinctrl/mediatek/pinctrl-mtk-common-v2.h | 1 + > > > > 2 files changed, 20 insertions(+) > > > > > > > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > > > > index 20e1c890e73b30c..7e19b5a4748eafe 100644 > > > > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > > > > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > > > > @@ -723,3 +723,22 @@ int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw, > > > > > > > > return 0; > > > > } > > > > + > > > > +static int mtk_eint_suspend(struct device *device) > > > > +{ > > > > + struct mtk_pinctrl *pctl = dev_get_drvdata(device); > > > > + > > > > + return mtk_eint_do_suspend(pctl->eint); > > > > +} > > > > + > > > > +static int mtk_eint_resume(struct device *device) > > > > +{ > > > > + struct mtk_pinctrl *pctl = dev_get_drvdata(device); > > > > + > > > > + return mtk_eint_do_resume(pctl->eint); > > > > +} > > > > + > > > > +const struct dev_pm_ops mtk_eint_pm_ops = { > > > > + .suspend_noirq = mtk_eint_suspend, > > > > + .resume_noirq = mtk_eint_resume, > > > > +}; > > > > > > This is identical to the one in pinctrl-mtk-common.c and will have name > > > clash if both pinctrl-mtk-common.c and pinctrl-mtk-common-v2.c are > > > built. > > > > > > It would be better if we try to merge both version into mtk-eint.c, this > > > way we could also remove some global functions. > > > > Argh, I didn't think about the name clash, you're right. I guess the > > easy way is to rename this one mtk_eint_pm_ops_v2 ... > > > > As highlighted in the commit message, it's tricky to merge the 2 sets > > of functions, they look identical, but they actually work on struct > > mtk_pinctrl that are defined differently (in > > pinctrl-mtk-common[-v2].h), so the ->eint member is at different > > addresses... > > > > I don't really see a way around this... Unless we want to change > > platform_set_drvdata(pdev, pctl); to pass another type of structure > > that could be shared (but I think that'll make the code fairly > > verbose, with another layer of indirection). Or just assign struct > > mtk_eint to that, since that contains pctl so we could get back the > > struct mtk_pinctrl from that, but that feels ugly as well... > > > > I agree on renaming would make the thing simple. but I wouldn't like > to rename to mtk_eint_pm_ops_v2 since this would make people > misunderstand that is mtk_eint_v2. > > How about renaming to mtk_paris_pinctrl_pm_ops and then place related > logic you added into pinctrl-paris.c? Because I prefer to keep pure > pinctrl hardware operations in pinctrl-mtk-common-v2.c, and for > relevant to other modules (mtk eint) or others subsystem (device tree > binding, GPIO subsytem, PM something like that) they should be moved > to pinctrl-paris.c or pinctrl-moore.c Sounds reasonable. I uploaded a v2 that does just that. Note that we'd still have to duplicate this code between paris and moore, if we wanted to implement pm_ops in moore as well, but maybe that's ok for now. > Sean > > > > > > > Joe.C > > > > > > > > > > > > _______________________________________________ > > > Linux-mediatek mailing list > > > Linux-mediatek@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek