Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2359093imu; Mon, 17 Dec 2018 00:02:11 -0800 (PST) X-Google-Smtp-Source: AFSGD/VOFI5Bk3f+WiCecQlT5Y4q+CGi+2SadCCijLkMELbVzNhQIDzyNCwwoB0eE9cpqQbTidWU X-Received: by 2002:a17:902:6a8c:: with SMTP id n12mr11890123plk.85.1545033731848; Mon, 17 Dec 2018 00:02:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545033731; cv=none; d=google.com; s=arc-20160816; b=1D3xPKkrJIN+Djq/gQkIYy07jZMZLQiAq4WI9abgB9nPdXhGFxuR1+f/HuDSC+WIXC uUP4NogaTkpSoXzH30hKjmP+etvtVh1TQ5TydK8PLfMqgntyxFwO9wMh9elZHTX9ZMNt 7iz8LGrkAZ8vPSrpnzxbOMDipfVuhtHEMrMep9Eqbjf7Sgb8XTamz9/R8SFYUtQDBK/3 S3zoIfim0TNkFoCCRyXPj3sf8QJDCQ/ZaEO1uG61rqoD26nleb+sPJMAfkbooLr4FU9E wZIBa6nJdespuoXVMMRdtUiPF7nIiRAqQiw5Ndh2m9b/ueQearzFb+enGnlI47Fvx9ce cCMg== 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=CvJPcISBcJHzsOvy2YpDZecxjOrj5NOSiC7WNR/r1hk=; b=wvAFt8Lh+i7avqIbLZ1aMWSdnsNWThrlcAh7xTE/VfSH85tLlKP2lG4HLjf5fPDvaH G5Wja3WO5fIB6s+C8N3K2SJ8TzFaoh7HntIPsvML7+KxqV9LUQ3oshUiM+C0WiLerF0e L2J+tkY81uf53s7dWXC0a9z4u64Gev3rk1ei+hmArkKW0XtVt4bBaJoGVgbwt9eoxbiy l3HxAEjtjxVVy+3mWDpsUqY4fpL/pCH2PG9g2Ajwx88eQ1H/6giBF5AEiKLsXQ1lbVt+ daaK0ldGmtn/i7YcOJjvdJ5qevb1v1uqECDnPMNRxBYOz/253BlbmG4JoT/sP9BxIEn1 1AYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qeaCyJ47; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 64si10904598pfe.74.2018.12.17.00.01.56; Mon, 17 Dec 2018 00:02:11 -0800 (PST) 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=@kernel.org header.s=default header.b=qeaCyJ47; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731595AbeLQH74 (ORCPT + 99 others); Mon, 17 Dec 2018 02:59:56 -0500 Received: from mail.kernel.org ([198.145.29.99]:43012 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726660AbeLQH74 (ORCPT ); Mon, 17 Dec 2018 02:59:56 -0500 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4114A217F5 for ; Mon, 17 Dec 2018 07:59:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1545033594; bh=4E0nw7zHo+hT4FOivCKZFno0wGpLhHdHPlV05qNtUDA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qeaCyJ47aSLL3TuGQD6QGsXBwltLvX7S94dqSxpSRc0wb7i9V3+iLNB95ccADcGEM i0Yujt5arBQvY5vAXAf9HXL0KaV9+lTtruDcTRM1IgVvo1DL35aMUxGrd0GovAVnO5 buOhzAX3WLNyQx1a0Brrhm4biyYGpwISrb6SSHOU= Received: by mail-wm1-f45.google.com with SMTP id m1so11324376wml.2 for ; Sun, 16 Dec 2018 23:59:54 -0800 (PST) X-Gm-Message-State: AA+aEWYyIawAl3G11sGuzGiKnKRcFh/xhyjWQHeEhMHUpOLWYABC5Qij YWpCXJZ99HWb9uYNmQPXFFUFplk5VLIklNkleAg= X-Received: by 2002:a1c:66c5:: with SMTP id a188mr10215259wmc.129.1545033592704; Sun, 16 Dec 2018 23:59:52 -0800 (PST) MIME-Version: 1.0 References: <1544693783-25079-1-git-send-email-chuanjia.liu@mediatek.com> <1545016504.29293.10.camel@mhfsdcap03> In-Reply-To: <1545016504.29293.10.camel@mhfsdcap03> From: Sean Wang Date: Sun, 16 Dec 2018 23:59:20 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] eint: add gpio vritual number select To: Chuanjia.Liu@mediatek.com Cc: Linus Walleij , Matthias Brugger , linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, hongkun.cao@mediatek.com, youlin.pei@mediatek.com, eddie.huang@mediatek.com, zhiyong.tao@mediatek.com, hailong.fan@mediatek.com 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 Sun, Dec 16, 2018 at 7:15 PM Chuanjia Liu wrote: > > On Thu, 2018-12-13 at 11:33 -0800, Sean Wang wrote: > > On Thu, Dec 13, 2018 at 1:36 AM wrote: > > > > > > From: Chuanjia Liu > > > > > > This patch add gpio vritual number select,avoid virtual gpio set SMT. > > > > s/gpio/GPIO/ > > s/vritual/virtual/ > > > > Virtual GPIOs you said here that means these pins only used inside SoC > > and not being exported to outside SoC, right? It seems this kind of > > pins doesn't need SMT. > > > Yes,virtual gpio only used inside SOC and these pins doesn't need set > SMT > > > > > > Signed-off-by: Chuanjia Liu > > > --- > > > drivers/pinctrl/mediatek/mtk-eint.h | 1 + > > > drivers/pinctrl/mediatek/pinctrl-mt8183.c | 1 + > > > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 9 ++++++--- > > > 3 files changed, 8 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/pinctrl/mediatek/mtk-eint.h b/drivers/pinctrl/mediatek/mtk-eint.h > > > index 48468d0..c16beaf 100644 > > > --- a/drivers/pinctrl/mediatek/mtk-eint.h > > > +++ b/drivers/pinctrl/mediatek/mtk-eint.h > > > @@ -37,6 +37,7 @@ struct mtk_eint_hw { > > > u8 ports; > > > unsigned int ap_num; > > > unsigned int db_cnt; > > > + unsigned int vir_start; > > > }; > > > > > > struct mtk_eint; > > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8183.c b/drivers/pinctrl/mediatek/pinctrl-mt8183.c > > > index 6262fd3..bbeafd3 100644 > > > --- a/drivers/pinctrl/mediatek/pinctrl-mt8183.c > > > +++ b/drivers/pinctrl/mediatek/pinctrl-mt8183.c > > > @@ -497,6 +497,7 @@ > > > .ports = 6, > > > .ap_num = 212, > > > .db_cnt = 13, > > > + .vir_start = 180, > > > }; > > > > > > static const struct mtk_pin_soc mt8183_data = { > > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > > > index 4a9e0d4..ca3bae1 100644 > > > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > > > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c > > > @@ -289,9 +289,12 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned long eint_n) > > > if (err) > > > return err; > > > > > > - err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, MTK_ENABLE); > > > - if (err) > > > - return err; > > > + if (gpio_n < hw->eint->hw->vir_start) { > > > + err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, > > > + MTK_ENABLE); > > > + if (err) > > > + return err; > > > + } > > > > The changes will break these SoCs without a properly configured vir_start. > > > > If SMT seems unnecessary for these kinds of virtual GPIOs pin in the > > path, we can do it as > > > > err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, > > MTK_ENABLE); > > /* please add comments for the exclusion condition */ > > if (err && err != -ENOTSUPP) > > return err; > > > > If there is getting much special on certain pins between SoCs, and > > then we can consider creating a desc->flag to split logic. > > Yes,SMT unnecessary for these kinds of virtual GPIOS pin in the path,if > do it as > err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, > MTK_ENABLE); > if (err && err != -ENOTSUPP) > return err; > I wonder if system will lose -ENOTSUPP information when smt was not > successfully set by real gpio? -ENOTSUPP shouldn't happen in a real pin as SMT is supposed to be supported by every real pin. If it is not true or there are more special on certain pins, and then we consider to add a flag to struct mtk_pin_desc to group these pins with their characteristics and to split and reuse the common code flow with the extra flag. So for now, I thought it's enough to handle your case with adding a few well self-explained comments for the exclusion condition. These words help us remember we should add adding an extra flag to pin description as one of TODO if more needs like you come out. > > > > > > > > return 0; > > > } > > > -- > > > 1.7.9.5 > >