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 97595C4321E for ; Mon, 5 Dec 2022 13:27:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232249AbiLEN1E (ORCPT ); Mon, 5 Dec 2022 08:27:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232216AbiLEN1E (ORCPT ); Mon, 5 Dec 2022 08:27:04 -0500 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1B441C91B for ; Mon, 5 Dec 2022 05:27:02 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id b3so18533378lfv.2 for ; Mon, 05 Dec 2022 05:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ZEi78HiNqFu1GIW9u8amVgxX/62kZk14mkEDDfKjOlw=; b=wULoWNjWdPEj015yU7ZjIaleb6j0cazdL0S5zb2z9XwLgDDk+pvyBEDf7xnBNQOhmU SqWC09iRraTtFbthsqu2Htgivb5dL/P+aFyy/5IhfgIz3njpam02ClcjyOF76OUvpzAZ z58JwiW+aKvjEeDeeRcJt7N3sQxVUInqP6gq8R7lgRERdR4QEEXJFxuCsiR0D84BfMCM XKc/SoTlbuVY8LGMO++uA2Vv9Tbw7etSTLjgUHt5A+yX9O3AsDiy85ucwDVerCaV8Po6 iQYJdIJ9U8o/K6McA3PxGO9E+odbTxdfp4aW3/sc73mK3HkFkZyH/5MTF+5E0Ucff2TB S8Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZEi78HiNqFu1GIW9u8amVgxX/62kZk14mkEDDfKjOlw=; b=ndhpPCios8tSCmj3+97fNPXOnk87RsCb1y7gMiRBFnVpNnqXelF6kuVjbUebIE2NJ7 Kxxs62iwQV03LE0WVuvka35M0sIOd57NKFeIW1aMDjgWLpG5PViOm4Up7a1b1RZXWyut MbZaMUETMjyVDhcdfQHCdQfjHJnYcMQPtw0cKnpkTWUalJKgMGQCNFsxv1kfMPxpOXJQ NdPHZ0NbUHYm6BmhDiL95/rtJ2+fcC9oOrUrCuCZio4S9OatCq5fwRdQ+/4BJ34e77FO b44V4fDs9hLPbhsOhH02DqpCZxGxwn3WUg6IMMcOTZbxtRH2Gg2o91mZIgltKDckJakI tRaQ== X-Gm-Message-State: ANoB5plw3KZrgKnBUV4FreFclwbXwhQ2c6itUwBqa5zn/cgKz2zuMtTu Oxdx2eDF3xlegixNtlaQx+qWww== X-Google-Smtp-Source: AA0mqf66sPDMG05cHXegksgvrRpbkt97pW9nIcGQHTSWPQQ8qIruQpc5+4gvNdjbwE4Ix5RJxC9sQg== X-Received: by 2002:a19:ee07:0:b0:4b5:2830:8998 with SMTP id g7-20020a19ee07000000b004b528308998mr8514983lfb.267.1670246820897; Mon, 05 Dec 2022 05:27:00 -0800 (PST) Received: from [192.168.0.20] (088156142067.dynamic-2-waw-k-3-2-0.vectranet.pl. [88.156.142.67]) by smtp.gmail.com with ESMTPSA id d23-20020ac244d7000000b004b5748fa3afsm441063lfm.107.2022.12.05.05.26.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Dec 2022 05:27:00 -0800 (PST) Message-ID: Date: Mon, 5 Dec 2022 14:26:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH v2 1/2] dt-bindings: pinctrl: add schema for NXP S32 SoCs Content-Language: en-US To: Chester Lin Cc: Rob Herring , Linus Walleij , Krzysztof Kozlowski , s32@nxp.com, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Larisa Grigore , Ghennadi Procopciuc , Andrei Stefanescu , =?UTF-8?Q?Andreas_F=c3=a4rber?= , Matthias Brugger , ghennadi.procopciuc@oss.nxp.com References: <20221128054820.1771-1-clin@suse.com> <20221128054820.1771-2-clin@suse.com> <6ad95ce3-887d-48fd-3c08-f50d4e666ded@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On 05/12/2022 12:05, Chester Lin wrote: > On Mon, Dec 05, 2022 at 10:02:14AM +0100, Krzysztof Kozlowski wrote: >> On 05/12/2022 07:16, Chester Lin wrote: >>> Hi Krzysztof, >>> >>> On Wed, Nov 30, 2022 at 03:58:52PM +0100, Krzysztof Kozlowski wrote: >>>> On 28/11/2022 06:48, Chester Lin wrote: >>>>> Add DT schema for the pinctrl driver of NXP S32 SoC family. >>>>> >>>>> Signed-off-by: Larisa Grigore >>>>> Signed-off-by: Ghennadi Procopciuc >>>>> Signed-off-by: Andrei Stefanescu >>>>> Signed-off-by: Chester Lin >>>>> --- >>>>> >>>>> Changes in v2: >>>>> - Remove the "nxp,pins" property since it has been moved into the driver. >>>>> - Add descriptions for reg entries. >>>>> - Refine the compatible name from "nxp,s32g-..." to "nxp,s32g2-...". >>>>> - Fix schema issues and revise the example. >>>>> - Fix the copyright format suggested by NXP. >>>>> >>>>> .../pinctrl/nxp,s32cc-siul2-pinctrl.yaml | 125 ++++++++++++++++++ >>>>> 1 file changed, 125 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,s32cc-siul2-pinctrl.yaml >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/nxp,s32cc-siul2-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nxp,s32cc-siul2-pinctrl.yaml >>>>> new file mode 100644 >>>>> index 000000000000..2fc25a9362af >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/pinctrl/nxp,s32cc-siul2-pinctrl.yaml >>>> >>>> Usually filename matches the compatible (or family name), so any reason >>>> why compatible is "nxp,s32g2" but filename is "nxp,s32cc"? >>>> >>> >>> According to NXP, the S32CC is a microarch which is adapted by different S32 SoCs, >>> such as S32G2/G3 and S32R45. Some common IPs are implemented in S32CC, such as >>> serial, pinctrl, mmc, gmac and some other peripheral interfaces. S32R45 has >>> different pinouts compared to S32G2, which means that there would not be just >>> "s32g2-siul2-pinctrl" but also "s32r45-siul2-pinctrl" in the compatible enum if >>> S32R45 has to be upstreamed in the future. For this case, it seems to be >>> inappropriate that adding a compatible name without any "s32g" keyword in the >>> filename "nxp,s32g2-.." unless creating a new yaml for each platform, such as >>> nxp,s32r45-siul2-pinctl.yaml. >> >> First, you can always rename a file if such need arises. Maybe new SoCs >> will come, maybe not. >> >> Second, when you actually upstream new SoC it might anyway require new >> bindings file, because pinctrls are quite specific and it is usually >> difficult to support multiple devices in a nice, readable way in one >> file. Therefore anyway another file is quite likely. >> > > Thanks for your guidance. Will fix it. > >> (...) >> >>>>> + >>>>> +patternProperties: >>>>> + '-pins$': >>>>> + type: object >>>>> + additionalProperties: false >>>>> + >>>>> + patternProperties: >>>>> + '-grp[0-9]$': >>>>> + type: object >>>>> + allOf: >>>>> + - $ref: pinmux-node.yaml# >>>>> + - $ref: pincfg-node.yaml# >>>>> + unevaluatedProperties: false >>>>> + description: >>>>> + Pinctrl node's client devices specify pin muxes using subnodes, >>>>> + which in turn use the standard properties. >>>> >>>> All properties are accepted? What about values, e.g. for drive strength? >>> >>> For those unsupported properties such as drive-strength, the s32g2 pinctrl driver >>> returns -EOPNOTSUPP. >> >> I don't care what the driver is doing, we do not discuss the driver. You >> need to describe properly the hardware and I doubt that hardware accepts >> all drive-strengths, all forms of pull resistors (so any Ohm value). >> >> Add constrains. >> > > Thanks for the suggestion. IIUC, I should specifically described the supported > pinmux and pincfg properties in this schema and then add an "additionalProperties: false" Yes. > in the end in order to constrain unsupported properties listed in the pattern > pin groups. You mean functions? or node names? The node names can be anything, can't they? If your drive strengths or slew rates have some limits, then I expect them here. Best regards, Krzysztof