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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDA25C433E7 for ; Fri, 9 Oct 2020 11:14:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8739922269 for ; Fri, 9 Oct 2020 11:14:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b="XNpqmPvR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387992AbgJILOU (ORCPT ); Fri, 9 Oct 2020 07:14:20 -0400 Received: from esa6.microchip.iphmx.com ([216.71.154.253]:38309 "EHLO esa6.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727181AbgJILOU (ORCPT ); Fri, 9 Oct 2020 07:14:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1602242059; x=1633778059; h=references:from:to:cc:subject:in-reply-to:date: message-id:mime-version; bh=vjKYfbc9s5PmZNG8hn4fzkf70oXwnDet2wCdajG+jWc=; b=XNpqmPvRIkioT5HxPELU9cHjNN10TDXPgYpUvkvSb0avdXn/unpOmNIl FULIIl+t84D4BZbgYF0aJt52teLzAjKbRm1IBLzXpJOPzsSSo96NcSgFj jLy0Qta8FQRi/1Yln+biBHNJ3b+3t1cFGQ1aRBRWlMpESI3fR/t+2tEsd nIeUMMilaERh5uip+R8Slcb3mHSTNGqSa6StGSjqf/3bUkNKiEXED7iOz FJ4VtYng39GbZFK0C8haDHGUFuwQaIWFtHo0D329eVmB1Rsq/mEqosYqS moDNagGjtpIM7fOA83bDO6QkMn4xNoMgV9F46uholvL/9CnwEZN6xP7n9 Q==; IronPort-SDR: Ifxxhy0xAWh2KaxW2iYDKqG+/gC0f0xqoVn69/hoK+fBjpiQabnargewF3GPamd7kMyunjKO5f 2xnkVWrljLfzh4O31eJOKRJw7rsGQ6hqrOWpofV1Q/Eb4EbTrfGrt5s8cLPT060E7HssZN836u 74nLMRrqzrnQxyEKdoVH7YSi0rIUKgITbXwUuvf+w3uwpnV1N3EvclXw6GuQwnBwIvKrd7eLnP jReMy6MXx0hVeFBnqQd5fOqjpBO9LNHc5QwjSxwdH6PfbUTPva8AKOgBzk+vjZpYsL0e5ZcbdT 7tU= X-IronPort-AV: E=Sophos;i="5.77,354,1596524400"; d="scan'208";a="29330444" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 09 Oct 2020 04:14:18 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Fri, 9 Oct 2020 04:13:45 -0700 Received: from soft-dev15.microsemi.net.microchip.com (10.10.115.15) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3 via Frontend Transport; Fri, 9 Oct 2020 04:14:16 -0700 References: <20201006142532.2247515-1-lars.povlsen@microchip.com> <20201006142532.2247515-3-lars.povlsen@microchip.com> <87ft6px9wc.fsf@soft-dev15.microsemi.net> From: Lars Povlsen To: Linus Walleij CC: Lars Povlsen , Microchip Linux Driver Support , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "open list:GPIO SUBSYSTEM" , Linux ARM , "linux-kernel@vger.kernel.org" , Alexandre Belloni Subject: Re: [RESEND PATCH v3 2/3] pinctrl: pinctrl-mchp-sgpio: Add pinctrl driver for Microsemi Serial GPIO In-Reply-To: Date: Fri, 9 Oct 2020 13:14:15 +0200 Message-ID: <87a6wvy7lk.fsf@soft-dev15.microsemi.net> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org Linus Walleij writes: > Hi Lars, > > I'm overall mostly happy with the latest posting (not the one I respond to here) I'm glad we're getting there :-) > > On Thu, Oct 8, 2020 at 12:57 PM Lars Povlsen wrote: >> > On Tue, Oct 6, 2020 at 4:25 PM Lars Povlsen wrote: > >> >> + gc->of_xlate = microchip_sgpio_of_xlate; >> >> + gc->of_gpio_n_cells = 3; >> > >> > So I'm sceptical to this. >> > >> > Why can't you just use the pin index in cell 0 directly >> > and avoid cell 1? >> > >> >> You scepticism has surfaced before :-). The (now) 2 indices relates to >> how the hardware address signals. >> >> Each signal/pin is addressed by port, bit number and direction. We now >> have the direction encoded in the bank/phandle. > > I'm sorry but I just don't get it, I suppose. To me it is pretty > straight-forward > that the cells indicate the pin and then the flags. I do understand you > need the port at all, since this is implicit from the reg property > of the DT node. Are these two different things? I responded to this in your comments to the DT bindings. I just for got to offer to add a description for "#gpio-cells", I see that's missing. That should make it "crystal clear" - I hope! Something like: --- a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml @@ -86,10 +86,17 @@ patternProperties: gpio-controller: true '#gpio-cells': + description: | + Specifies the pin (port and bit) and flags. Note that the + SGIO pin is defined by *2* numbers, a port number between 0 + and 31, and a bit index, 0 to 3. The maximum bit number is + controlled indirectly by the "ngpios" property: (ngpios/32). const: 3 ngpios: - minimum: 1 + description: The numbers of GPIO's exposed. This must be a + multiple of 32. + minimum: 32 maximum: 128 required: Would that be adequate, or should this also be added as a comment in microchip_sgpio_of_xlate()? Like: + /* Note that the SGIO pin is defined by *2* numbers, a port + * number between 0 and 31, and a bit index, 0 to 3. + */ if (gpiospec->args[0] > SGPIO_BITS_PER_WORD || gpiospec->args[1] > priv->bitcount) return -EINVAL; I hope we can put this one to bed... ---Lars > > Yours, > Linus Walleij -- Lars Povlsen, Microchip 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66419C433DF for ; Fri, 9 Oct 2020 11:15:51 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D0A2B22269 for ; Fri, 9 Oct 2020 11:15:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="US8gNCFU"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b="TpzaN4J1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0A2B22269 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=microchip.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:In-Reply-To:Subject:To: From:References:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=97xau8/Uyr4ZzmtZqUKpxuyFFnBKr7jgKlwyVx63szA=; b=US8gNCFUfFbOqfIvHK6Bp0Su/ 800B+UVnVy745SM1Km/3hCF5UxpciILoRc9qcfWeubdSEI0pHn0PhzH9CGAWo1RxzN0SMs9hEuNLp uDczIw1lcYhJbII9j3fs6SC+LXjRZd5O4MwOnqziIhbLJ3pnsC5A5vteClQrfWtXRUHVc7y1TlpIF 2cE9w6aLniK5Z69YKT+xxK8MIxE+0bSjOQjOvB5m+mm45DYTBcyUYp6FG7rqmLj/bUxxRffre16k9 6n11VYwWvI9+p/H7sOALb2i493BVuPgP2gAExnVnrPZ9dOk0XF3aEGR0qugEc0S4y8FSAdiFmmkDS P/ut1gGjw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQqLw-0000Rq-Be; Fri, 09 Oct 2020 11:14:24 +0000 Received: from esa6.microchip.iphmx.com ([216.71.154.253]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQqLu-0000Ql-34 for linux-arm-kernel@lists.infradead.org; Fri, 09 Oct 2020 11:14:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1602242062; x=1633778062; h=references:from:to:cc:subject:in-reply-to:date: message-id:mime-version; bh=vjKYfbc9s5PmZNG8hn4fzkf70oXwnDet2wCdajG+jWc=; b=TpzaN4J1vw6ALMexYia65iIQA9n9Wzxk26SNILXTpadvK1RgDKAkXWbv c8kqL/7Xe4iRo3P4GcNNdsWjMinNen35wLQgWtgXrcXJmAW3LS4EcdRZU kqCS1ceGaEEmgaLRejLf24gj/UC3+yM2Sd4aR9Z96yufn8mKPevVP4+gB NPVGFt+lFvZ5tXOOwz2liPnJ1Ceitt73RPc6I8oK+fIgRvWsPf9WNFey4 oACOMb1iJ3uDUxADy5zvnCyy8xNItA2HuG5qbXJN2X5BrpHKabTlmdKHx dLr3oxiYiBBsLSVxyTrLqSzl1Fe8AvfEiB7e+NSFa6+5RcKyCWF63UXHP A==; IronPort-SDR: Ifxxhy0xAWh2KaxW2iYDKqG+/gC0f0xqoVn69/hoK+fBjpiQabnargewF3GPamd7kMyunjKO5f 2xnkVWrljLfzh4O31eJOKRJw7rsGQ6hqrOWpofV1Q/Eb4EbTrfGrt5s8cLPT060E7HssZN836u 74nLMRrqzrnQxyEKdoVH7YSi0rIUKgITbXwUuvf+w3uwpnV1N3EvclXw6GuQwnBwIvKrd7eLnP jReMy6MXx0hVeFBnqQd5fOqjpBO9LNHc5QwjSxwdH6PfbUTPva8AKOgBzk+vjZpYsL0e5ZcbdT 7tU= X-IronPort-AV: E=Sophos;i="5.77,354,1596524400"; d="scan'208";a="29330444" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 09 Oct 2020 04:14:18 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Fri, 9 Oct 2020 04:13:45 -0700 Received: from soft-dev15.microsemi.net.microchip.com (10.10.115.15) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3 via Frontend Transport; Fri, 9 Oct 2020 04:14:16 -0700 References: <20201006142532.2247515-1-lars.povlsen@microchip.com> <20201006142532.2247515-3-lars.povlsen@microchip.com> <87ft6px9wc.fsf@soft-dev15.microsemi.net> From: Lars Povlsen To: Linus Walleij Subject: Re: [RESEND PATCH v3 2/3] pinctrl: pinctrl-mchp-sgpio: Add pinctrl driver for Microsemi Serial GPIO In-Reply-To: Date: Fri, 9 Oct 2020 13:14:15 +0200 Message-ID: <87a6wvy7lk.fsf@soft-dev15.microsemi.net> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201009_071422_276355_D586C357 X-CRM114-Status: GOOD ( 20.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Alexandre Belloni , "linux-kernel@vger.kernel.org" , Microchip Linux Driver Support , "open list:GPIO SUBSYSTEM" , Lars Povlsen , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Linus Walleij writes: > Hi Lars, > > I'm overall mostly happy with the latest posting (not the one I respond to here) I'm glad we're getting there :-) > > On Thu, Oct 8, 2020 at 12:57 PM Lars Povlsen wrote: >> > On Tue, Oct 6, 2020 at 4:25 PM Lars Povlsen wrote: > >> >> + gc->of_xlate = microchip_sgpio_of_xlate; >> >> + gc->of_gpio_n_cells = 3; >> > >> > So I'm sceptical to this. >> > >> > Why can't you just use the pin index in cell 0 directly >> > and avoid cell 1? >> > >> >> You scepticism has surfaced before :-). The (now) 2 indices relates to >> how the hardware address signals. >> >> Each signal/pin is addressed by port, bit number and direction. We now >> have the direction encoded in the bank/phandle. > > I'm sorry but I just don't get it, I suppose. To me it is pretty > straight-forward > that the cells indicate the pin and then the flags. I do understand you > need the port at all, since this is implicit from the reg property > of the DT node. Are these two different things? I responded to this in your comments to the DT bindings. I just for got to offer to add a description for "#gpio-cells", I see that's missing. That should make it "crystal clear" - I hope! Something like: --- a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml @@ -86,10 +86,17 @@ patternProperties: gpio-controller: true '#gpio-cells': + description: | + Specifies the pin (port and bit) and flags. Note that the + SGIO pin is defined by *2* numbers, a port number between 0 + and 31, and a bit index, 0 to 3. The maximum bit number is + controlled indirectly by the "ngpios" property: (ngpios/32). const: 3 ngpios: - minimum: 1 + description: The numbers of GPIO's exposed. This must be a + multiple of 32. + minimum: 32 maximum: 128 required: Would that be adequate, or should this also be added as a comment in microchip_sgpio_of_xlate()? Like: + /* Note that the SGIO pin is defined by *2* numbers, a port + * number between 0 and 31, and a bit index, 0 to 3. + */ if (gpiospec->args[0] > SGPIO_BITS_PER_WORD || gpiospec->args[1] > priv->bitcount) return -EINVAL; I hope we can put this one to bed... ---Lars > > Yours, > Linus Walleij -- Lars Povlsen, Microchip _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel