From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 796DCC433EF for ; Tue, 7 Jun 2022 09:27:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239390AbiFGJ1O (ORCPT ); Tue, 7 Jun 2022 05:27:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239037AbiFGJ1N (ORCPT ); Tue, 7 Jun 2022 05:27:13 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 966011A058 for ; Tue, 7 Jun 2022 02:27:09 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id i29so10590453lfp.3 for ; Tue, 07 Jun 2022 02:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bycnujn+C+TNXArQgDaRYNKXnzzQ5tOqUsTDh+BoVXc=; b=t8p26q3E/L/TgZvfOS55JAOsz9xPuki8ovvsGEs+DFidMo0+nC5q87KialHMbXXUx2 NZBSPLKbAm5cIgCaNWSfYwSt4fnlLecR64L71ARiiI5CPS1aqqzrxJvXB6IKLY3WXNuu 5SHFPVTF0HSOWo8rE6sQ/WkS4a9ZCwX0/c1KlNkUzxFzcQXCYtwlIQpkRlh9O9h7hD2c lzKWKa/el8B4Cs+eVSyH6vN291VP71o6gwb8Ctk7TpGDvbmiVIQea1yApDwP5aGLX40A Z49d4wqGHGA6mOLOnxNUVdf0Mj1739Iv+QtyQf++UoZ8BECNUCN8dDbnFukVMBX5uYds kbDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bycnujn+C+TNXArQgDaRYNKXnzzQ5tOqUsTDh+BoVXc=; b=XQKqfT/Yast6G4oyNRYdL/k5k3r1YWcj/H3u+FLrTJwsezEF9sQ8cfTVPZTwbLP+nC 0gY22ZTeKH9oMkYAdEoP0KVKVMYF65BqhFYOVR9ZLiX7yboXFaphp7yjE+1j/mupue4G 5UVI20GVV2uw75TKVXk7rsk0ARndHfTd9ZD/zo2bf2iG0LvUK/xScPbZ6OWGZPcmgPWS M1gi1SBLUfQblQJLks+P55ZFXXQ7sZ48vqygKi5h+UVP/KDekK4w2xdhqoaQFRDiu7EF Ty85kjB86pO7lX3n5zVR+74JK7rvMjLFjCcqZTxCGk0gznyUuntTQ1dMdW9SADhwhdJa A3BA== X-Gm-Message-State: AOAM531gBeSFwSPKoieqr55r61svvgBMCWzKY+0mdcnNr1zFao8DVVYv ZIdMo0/wICcliGk5hXwqf6kOFYfmyfwlACW9NMIpbg== X-Google-Smtp-Source: ABdhPJxQISkP4fpMf2Tx4GQZOz5bRQyTzJ8vaUdWMeVJt9giKQNrG2uqpo97Sb9v8bOTq0hPO8Lyk67AS9Huf+RLHh4= X-Received: by 2002:a05:6512:403:b0:479:1627:a9b7 with SMTP id u3-20020a056512040300b004791627a9b7mr15454828lfk.233.1654594027813; Tue, 07 Jun 2022 02:27:07 -0700 (PDT) MIME-Version: 1.0 References: <20220525015140.384-1-axe.yang@mediatek.com> <20220525015140.384-2-axe.yang@mediatek.com> In-Reply-To: From: Ulf Hansson Date: Tue, 7 Jun 2022 11:26:31 +0200 Message-ID: Subject: Re: [RESEND v12 1/3] dt-bindings: mmc: mtk-sd: extend interrupts and pinctrls properties To: Axe Yang Cc: Rob Herring , Chaotian Jing , Matthias Brugger , Adrian Hunter , Yoshihiro Shimoda , Satya Tangirala , Andy Shevchenko , Wolfram Sang , Lucas Stach , Eric Biggers , Andrew Jeffery , Stephen Boyd , Kiwoong Kim , Yue Hu , Tian Tao , angelogioacchino.delregno@collabora.com, linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, 7 Jun 2022 at 10:24, Axe Yang wrote: > > On Fri, 2022-06-03 at 09:28 +0200, Ulf Hansson wrote: > > On Wed, 25 May 2022 at 03:51, Axe Yang wrote: > > > > > > Extend interrupts and pinctrls for SDIO wakeup interrupt feature. > > > This feature allow SDIO devices alarm asynchronous interrupt to > > > host > > > even when host stop providing clock to SDIO card. An extra wakeup > > > interrupt and pinctrl states for SDIO DAT1 pin state switching are > > > required in this scenario. > > > > > > Reviewed-by: AngeloGioacchino Del Regno < > > > angelogioacchino.delregno@collabora.com> > > > Signed-off-by: Axe Yang > > > --- > > > .../devicetree/bindings/mmc/mtk-sd.yaml | 50 > > > ++++++++++++++++++- > > > 1 file changed, 49 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml > > > b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml > > > index 2a2e9fa8c188..e83bf10281d6 100644 > > > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml > > > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml > > > @@ -72,12 +72,27 @@ properties: > > > - const: ahb_cg > > > > > > interrupts: > > > - maxItems: 1 > > > + description: > > > + Should at least contain MSDC GIC interrupt. To support SDIO > > > in-band wakeup, an extended > > > + interrupt is required and be configured as wakeup source > > > irq. > > > + minItems: 1 > > > + maxItems: 2 > > > + > > > + interrupt-names: > > > + items: > > > + - const: msdc > > > + - const: sdio_wakeup > > > > > > pinctrl-names: > > > + description: > > > + Should at least contain default and state_uhs. To support > > > SDIO in-band wakeup, dat1 pin > > > + will be switched between GPIO mode and SDIO DAT1 mode, > > > state_eint and state_dat1 are > > > + mandatory in this scenarios. > > > + minItems: 2 > > > items: > > > - const: default > > > - const: state_uhs > > > + - const: state_eint > > > > Don't you need something along the lines of the below instead? I mean > > the "state_eint" isn't always needed, right? > > > > oneOf: > > - items: > > - const: default > > - const: state_uhs > > - items: > > - const: default > > - const: state_uhs > > - const: state_eint > > > No, it is not always needed. > As Rob said, the 'minItems: 2' makes the 3rd item optional. > Combine 'minItems' and 'description' fields, it is easy for others to > understand how to set pinctrl related properities. Yes, I agree. > > Anyway, If you insist 'oneOf' is the better way, I can update that in > next version. What do you think? I am fine with it as is, sorry for the noise. > > And thanks to your comment, I found a mistake in 'description', I > should remove descriptions related to 'state_dat1', and I will update > that in next version. Okay. > > And do you have any comment on patch 2/3 and 3/3? Sorry for the delay, I will have a look asap. > > > Regards, > Axe > > Kind regards Uffe