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 67CE1C4167B for ; Tue, 29 Nov 2022 15:59:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235645AbiK2P7U (ORCPT ); Tue, 29 Nov 2022 10:59:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235803AbiK2P65 (ORCPT ); Tue, 29 Nov 2022 10:58:57 -0500 Received: from ex01.ufhost.com (ex01.ufhost.com [61.152.239.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21F946930A; Tue, 29 Nov 2022 07:57:56 -0800 (PST) Received: from EXMBX165.cuchost.com (unknown [175.102.18.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "EXMBX165", Issuer "EXMBX165" (not verified)) by ex01.ufhost.com (Postfix) with ESMTP id D4F4224E023; Tue, 29 Nov 2022 23:57:52 +0800 (CST) Received: from EXMBX065.cuchost.com (172.16.6.65) by EXMBX165.cuchost.com (172.16.6.75) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Tue, 29 Nov 2022 23:57:52 +0800 Received: from [192.168.0.104] (219.128.233.15) by EXMBX065.cuchost.com (172.16.6.65) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Tue, 29 Nov 2022 23:57:51 +0800 Message-ID: <8677051a-604a-210c-066c-75db444d6f09@starfivetech.com> Date: Tue, 29 Nov 2022 23:58:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v2 1/5] dt-bindings: pinctrl: Add StarFive JH7110 pinctrl definitions To: Krzysztof Kozlowski , Hal Feng , , , CC: Conor Dooley , Palmer Dabbelt , "Rob Herring" , Krzysztof Kozlowski , Linus Walleij , Emil Renner Berthing , References: <20221118011108.70715-1-hal.feng@starfivetech.com> <20221118011108.70715-2-hal.feng@starfivetech.com> <08db0f3b-5222-9460-26ba-0e6380d16583@linaro.org> <0ceba170-f844-e733-a49e-e67746f9f836@starfivetech.com> <093ea507-4c42-1af9-4896-64c1a918432e@linaro.org> <30c21787-0c48-ff50-1d63-8e69bdcdbe30@starfivetech.com> <339be655-aee7-e1a4-51be-28ea20de6792@linaro.org> <3db802d6-114f-097a-6c69-e7b40e4d2764@starfivetech.com> Content-Language: en-US From: Jianlong Huang In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [219.128.233.15] X-ClientProxiedBy: EXCAS066.cuchost.com (172.16.6.26) To EXMBX065.cuchost.com (172.16.6.65) X-YovoleRuleAgent: yovoleflag Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Tue, 29 Nov 2022 15:58:12 +0100, Krzysztof Kozlowski wrote: > On 29/11/2022 15:46, Jianlong Huang wrote: >> On Tue, 29 Nov 2022 08:49:49 +0100, Krzysztof Kozlowski wrote: >>> On 29/11/2022 02:47, Jianlong Huang wrote: >>>> On Mon, 28 Nov 2022 09:32:45 +0100, Krzysztof Kozlowski wrote: >>>>> On 28/11/2022 01:48, Jianlong Huang wrote: >>>>> >>>>>>>>> +/* aon_iomux doen */ >>>>>>>>> +#define GPOEN_AON_PTC0_OE_N_4 2 >>>>>>>>> +#define GPOEN_AON_PTC0_OE_N_5 3 >>>>>>>>> +#define GPOEN_AON_PTC0_OE_N_6 4 >>>>>>>>> +#define GPOEN_AON_PTC0_OE_N_7 5 >>>>>>>>> + >>>>>>>> >>>>>>>> It looks like you add register constants to the bindings. Why? The >>>>>>>> bindings are not the place to represent hardware programming model. Not >>>>>>>> mentioning that there is no benefit in this. >>>>>>> >>>>>>> Also: this entire file should be dropped, but if it stays, you have to >>>>>>> name it matching bindings or compatible (vendor,device.h). >>>>>> >>>>>> Thanks your comments. >>>>>> These macros are used to configure pinctrl in dts, so the file should stay, >>>>> >>>>> Why they should stay? What's the reason? If it is not a constant used by >>>>> driver, then register values should not be placed in the bindings, so >>>>> drop it. >>>>> >>>> >>>> Thanks. >>>> >>>> These macros in binding header(example, DOUT, DOEN etc) will be used in DTS, >>>> and driver will parse the DT for pinctrl configuration. >>>> >>>> Example in dts: >>>> uart0_pins: uart0-0 { >>>> tx-pins { >>>> pinmux = ; >>> >>> This is usage in DTS and is not an argument to store register >>> addresses/offsets as bindings. What is the usage (of define, not value) >>> in the driver? >>> >> >> The existing implementation reuse the macros for DTS and driver. > > Where in the driver? Grep gives zero results. > >> Do you mean we need to separate the macros, one for DTS and one for driver usage? > > No, if driver uses them it is fine. The problem is I cannot find it > anywhere. > >> Or you have any better suggestion? >> >> These macros are the value of register, not register addresses/offsets, >> except for with prefix of GPI. > > Still, values are not usually part of bindings. > >> >> Drivers rarely reference macros directly, mostly parsing dts and writing them to registers. > > So drivers do not use macros? Then there is no reason to store them in > bindings? What do you "bind" if there is no usage (and we do not talk > about DTS...)? > Where do you suggest to store these macros used in DTS? Best regards, Jianlong Huang