Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp936737rwb; Tue, 29 Nov 2022 07:07:59 -0800 (PST) X-Google-Smtp-Source: AA0mqf6105ZyHyT1Mpl5WwD8wklBuhNoFuWKTfk33WKwxNeeU9ygg9KO29FsyyjPtEd8KqZU8hYO X-Received: by 2002:a17:906:9246:b0:7af:da0:aebe with SMTP id c6-20020a170906924600b007af0da0aebemr34894901ejx.723.1669734479313; Tue, 29 Nov 2022 07:07:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669734479; cv=none; d=google.com; s=arc-20160816; b=o+XWB0Z4QkxCzVH0HWFUoDFShOg6vX9uztLYxeqPihCsjPSTVPY3Ul29zLrQ7ghT33 /tR5S9cIzb+iZVJtpDUUzKZfaaUF9Nxr2Pyk0HAW6xFtOVSMl++KFLfLTupZqnkT3hRa nzK61r0SBlBP5wyPFglMByizgCoUuuRDrNND9AOk/oab1y5MkUP5s01Ak+A9C2LT4isN 8g1KcjfRCaJ460Q9/1QPvpDaVwKKU3ri1leN2OkV2k+K9Bt3zc1brG0moM68Y6R+YRxZ 4k8MHZrI9SZX5aO/Bs8aBb9kM7u8hbjUypr+KzZJh33mj/DCafYv+YCzXOxfGSucBuex 9Guw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id; bh=gGMpwHV9+xIkn8q05En/7xQwkK7Njwt4FdfAUdD35Ds=; b=qNCuvHHnNZpZYfdgMAQEtR+z6hnyiOt4WaUBQI87DcfwhE7R9tdktCCooGxi0Ijs2R yQ8Dvp+NMdJEvnSlca1fKsnE5xpWmxSrul7nz/Oy4gZbcmFR/WHjtPk/X0dISjN3hpdg eyyRhr3d5Yaj48+rG8NbqgBcooDejQT82ZqgaL/V4jJsudAfwmWxoW7gacZ8Y1LKwzS1 kinlsVoXLmtf1WxN4SLI3W+ZZYg7OF8Kt8UxcbVbri/Ay3A2BboxQCi78795dLRwVcCA RuRKvdI00UM3CEn/A0rgEsm4LWjrhM8N6EFCVUm7ThN1xWobBVydWf3sQmoVi2zZZV8i 93Tw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s12-20020a05640217cc00b0046b0b4ee617si6205116edy.442.2022.11.29.07.07.33; Tue, 29 Nov 2022 07:07:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235367AbiK2Oqh (ORCPT + 84 others); Tue, 29 Nov 2022 09:46:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234670AbiK2Oqe (ORCPT ); Tue, 29 Nov 2022 09:46:34 -0500 Received: from fd01.gateway.ufhost.com (fd01.gateway.ufhost.com [61.152.239.71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20ABB4D5F9; Tue, 29 Nov 2022 06:46:27 -0800 (PST) Received: from EXMBX166.cuchost.com (unknown [175.102.18.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "EXMBX166", Issuer "EXMBX166" (not verified)) by fd01.gateway.ufhost.com (Postfix) with ESMTP id D4D5C24E06F; Tue, 29 Nov 2022 22:46:19 +0800 (CST) Received: from EXMBX065.cuchost.com (172.16.6.65) by EXMBX166.cuchost.com (172.16.6.76) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Tue, 29 Nov 2022 22:46:19 +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 22:46:17 +0800 Message-ID: <3db802d6-114f-097a-6c69-e7b40e4d2764@starfivetech.com> Date: Tue, 29 Nov 2022 22:46:54 +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> Content-Language: en-US From: Jianlong Huang In-Reply-To: <339be655-aee7-e1a4-51be-28ea20de6792@linaro.org> 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 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Do you mean we need to separate the macros, one for DTS and one for driver usage? Or you have any better suggestion? These macros are the value of register, not register addresses/offsets, except for with prefix of GPI. Drivers rarely reference macros directly, mostly parsing dts and writing them to registers. Best regards, Jianlong Huang