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 ACD74C05027 for ; Wed, 8 Feb 2023 11:57:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230475AbjBHL5z (ORCPT ); Wed, 8 Feb 2023 06:57:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230303AbjBHL5y (ORCPT ); Wed, 8 Feb 2023 06:57:54 -0500 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77DF449000 for ; Wed, 8 Feb 2023 03:57:53 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id f23-20020a05600c491700b003dff4480a17so2294957wmp.1 for ; Wed, 08 Feb 2023 03:57:53 -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:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Os5EeAhOwAZRzentDp9ToOzfsCfsH4W7jIuEYSHVgak=; b=y0KiKEAwymREB5G/oHcJbBjDEJTOmrJHi6PAYsrniCHSA8HuQ6Hgn660IKAQhdPKag wsIHNpH1I9ybpgaFbHTqNWDCne0XkDM9IAqrv2toi9mc1vroSeQwML80fHgjIcPHuQb9 lVRLnuofn0LZAaxho0ebZDd1AWIjanb/qRmSCKF8MYakyPy9cTPVteIJbwfrX1xzJFT2 ZL5JIoMe6JFHMedH6McYBF17gCmOfvk8kG1LMEIQ766wS/Hyus31/3RZ85CjC7gXIEzJ OfIFJ7Wfcx7lsk17BOv7No9/0m/edxLCw88rKhmrbKA6IUpdZO34VqiS89HT7em86dZR 8NBw== 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:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Os5EeAhOwAZRzentDp9ToOzfsCfsH4W7jIuEYSHVgak=; b=5NjEZ5IP1eIFaz/Keqn1n48BgAw5Rb4SpGp3pLUR0kqr9naKm5/hrz5i/rkHFqzobL Fr5knxyj1Q6Iry6jzd6LY6v/bib/BbHacH5/xZeZEUJqFgVR7yesmFJ9XnJcgX9McdCX No/Wjo90Ze2Etz/aUS+XO9k6JarBPPQsvP+HkGxgc8OAcGCv/gtQMe/4iFc9ZmvKaydX msxDAEohx/SGvWFooHEO47N3DZeIcvfCx4MieASOl8mVpoI0xoRdFMRvlqmn2T7yDBAk avzj4gvaHAybIFrVWR83p8LCG93x8tKdBYMdUWaOpnwIiwBUmBDX94INdWF/pJCcWCK7 nb/g== X-Gm-Message-State: AO0yUKU5j2sq+sgDV9SxpfZUM4NqGfXN+oT1+lKZ2nBU4gXYDg/PMwbl SCXewWPUfsW+s0Z4ufvrTki65g== X-Google-Smtp-Source: AK7set/ooFp2421xqMkR0fa63StmM5ni5yPRn4jighJqF3WIg0OE06QgA+hnr5NJpVuBQ9Rm6ayz6w== X-Received: by 2002:a05:600c:4496:b0:3dc:de85:5007 with SMTP id e22-20020a05600c449600b003dcde855007mr6258599wmo.21.1675857471998; Wed, 08 Feb 2023 03:57:51 -0800 (PST) Received: from [192.168.1.109] ([178.197.216.144]) by smtp.gmail.com with ESMTPSA id k21-20020a05600c1c9500b003dc43a10fa5sm1819426wms.13.2023.02.08.03.57.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Feb 2023 03:57:51 -0800 (PST) Message-ID: <9e7e1762-1c2e-28cd-c7a7-b0577addf51e@linaro.org> Date: Wed, 8 Feb 2023 12:57:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 1/3] dt-bindings: pinctrl: tegra234: Add DT binding doc To: Thierry Reding Cc: Prathamesh Shete , jonathanh@nvidia.com, linus.walleij@linaro.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, devicetree@vger.kernel.org, linux-tegra@vger.kernel.org, linux-gpio@vger.kernel.org, smangipudi@nvidia.com References: <20230207115617.12088-1-pshete@nvidia.com> Content-Language: en-US From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 08/02/2023 12:24, Thierry Reding wrote: > On Tue, Feb 07, 2023 at 04:33:08PM +0100, Krzysztof Kozlowski wrote: >>> + type: object >>> + additionalProperties: >>> + properties: >>> + nvidia,pins: >>> + description: An array of strings. Each string contains the name >>> + of a pin or group. Valid values for these names are listed >>> + below. >> >> Define properties in top level, which points to the complexity of your >> if-else, thus probably this should be split into two bindings. Dunno, >> your other bindings repeat this pattern :( > > The property itself is already defined in the common schema found in > nvidia,tegra-pinmux-common.yaml and we're overriding this here for each > instance since each has its own set of pins. > > This was a compromise to avoid too many bindings. Originally I attempted > to roll all Tegra pinctrl bindings into a single dt-schema, but that > turned out truly horrible =) Splitting this into per-SoC bindings is > already causing a lot of duplication in these files, What would be duplicated? Almost eveerything should be coming from shared binding, so you will have only compatible, patternProperties(pinmux) and nvidia,pins. And an example. Maybe I miss something but I would say this would create many but very easy to read bindings, referencing common pieces. > though splitting > off the common bits into nvidi,tegra-pinmux-common.yaml helps a bit with > that already. Splitting this into per-instance bindings would > effectively duplicate everything but the pin array here, so we kind of > settled on this compromise for Tegra194. OK, but are you sure it is now readable? You have if:then: with patternProperties: with additionalProperties: with properties: with nvidia,pins. > > We're taking a bit of a shortcut here already, since technically not all > pins support all the functions listed above. On the other hand, fully > accurately describing per-pin functions would make this a total mess, so > again, we use this simplified representation as a compromise. That's okay, many platforms do the same way. (...) >>> + >>> + pex_rst_c5_out_state: pinmux-pex-rst-c5-out { >>> + pex_rst { >> >> Underscores are not valid in node names. > > We have supported underscore in older bindings for historical reasons. > But I suppose for these newer bindings we could disallow them. > > Some of the older DTs have a large number of underscores, so I'm not > sure it makes sense to go back and fix those. Maybe something to keep in > mind for when we're done with all the conversions... I understand, up to you. I think that if such older platform is still supported/maintained/used, then such cleanups are positive. Underscores are reported by dtc at W=2, so it is not that critical. But many other nits like generic node names are being enforced by dtschema, thus if you want to achieve 0-warning state, at some point you will need to address these. Of course different question is on what tasks you want to spend your time. :) Best regards, Krzysztof