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 3DC9BC4332F for ; Thu, 3 Nov 2022 14:54:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231428AbiKCOyF (ORCPT ); Thu, 3 Nov 2022 10:54:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231757AbiKCOxk (ORCPT ); Thu, 3 Nov 2022 10:53:40 -0400 Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C1071928E for ; Thu, 3 Nov 2022 07:53:36 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id mi9so1265326qvb.8 for ; Thu, 03 Nov 2022 07:53:36 -0700 (PDT) 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=jrYaAHvMcvAgON2HJIoIE2IBvbz54WPBWq/9VlMTUN8=; b=xcBA91hGHInB4KTtVPZW2NQt5yB4tHUi+auIQ6aJYlat/DX9nRYEWLG9Ju6DkX7E2K 9K7S29pUk6u7a8H9r7lF/QBisDa55jpu6giSceDXlOJF/9E+QYs4tAUglvDUaot0WRCM m/BmMgMBcveJe63QYdIu3qRKbj+vqqfT6C7c7iLuulV/Q4QCWSANGqOhqinFzqDXS82c 0pmIhZRPXfhk3x3v1x2Mc/6FM+5r8Y9gqyeoDYjkibFZgqJCl9ZCDNiN1LDyNZOoTqCn 06ISmv0xruPzl9gWKgb6/6yqcHJ7wcUsHRIR85oVIA20GiSO+hRapVkziB2ab/mNIOEi NKbQ== 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=jrYaAHvMcvAgON2HJIoIE2IBvbz54WPBWq/9VlMTUN8=; b=LhEiYBBVLjrRMsSNQn9278FtPSv2PR8AgnL+WThmIX+MNTEAHh1xDsuBhT8SOk4t+d FY7W7EQEaPh1+eXB98p+GXbJk6bMRvAK/M8nEXB4k3HbGQ+imBvWgw0NZS2LjBU+CiOy BkjnrOY4Tqea9zIEv9gWPvcIXdvOsbPmmAMhpYrGH69fg6T1QqUNfhH8N2wokougayDG 9hED1WUnPQO8VQ5YfyBawLlKxd5NOA0gAAOhSghXuQeQbhktt23bkvwqfU3QAKDLS9Bs NNx2bv+wICQ0JfGMjY/diyEH6TRX7MgAIg5BT3Mg/fFxMstfD5wj+o6jWum/J7QFUwKJ gg/Q== X-Gm-Message-State: ACrzQf2jNTIcNxA3oADD9bKoYrFsH92iduMCwDoOZ93Irr8hUXy5yHjq Sk9rvv+kuv+EZgDK2UeeDAARoA== X-Google-Smtp-Source: AMsMyM4G+1DZEOjki9fpIe4QcPidcY8eOdH1TWlR9Lt+Oie2mvIlCmefsBFT1cU8J35Ccx3tvnphJw== X-Received: by 2002:a05:6214:258b:b0:4bc:246c:dd01 with SMTP id fq11-20020a056214258b00b004bc246cdd01mr7632303qvb.64.1667487215489; Thu, 03 Nov 2022 07:53:35 -0700 (PDT) Received: from ?IPV6:2601:586:5000:570:a35d:9f85:e3f7:d9fb? ([2601:586:5000:570:a35d:9f85:e3f7:d9fb]) by smtp.gmail.com with ESMTPSA id y12-20020a37f60c000000b006cfaee39ccesm833591qkj.114.2022.11.03.07.53.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Nov 2022 07:53:34 -0700 (PDT) Message-ID: <26249f27-dbea-c30e-a2ea-df5cb4290b3e@linaro.org> Date: Thu, 3 Nov 2022 10:53:33 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH] dt-bindings: pwm: tegra: Convert to json-schema Content-Language: en-US To: Thierry Reding Cc: Rob Herring , Krzysztof Kozlowski , =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= , Jon Hunter , devicetree@vger.kernel.org, linux-pwm@vger.kernel.org, linux-tegra@vger.kernel.org References: <20221103120137.1467905-1-thierry.reding@gmail.com> <18d66cce-64ae-aeaa-e9cf-9426c5d214f5@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: devicetree@vger.kernel.org On 03/11/2022 10:38, Thierry Reding wrote: >>> + >>> + clock-names: >>> + items: >>> + - const: pwm >> >> This wasn't in original binding and does not look needed. Mention >> changes from pure conversion. > > At some point (looks like with the switch to 64-bit ARM) we started > adding these for consistency because we were noticing that sometimes > either we were missing clock entries or newer SoC generations gained > additional clocks. Whenever that happened it would become somewhat > cumbersome to describe this in device tree bindings and/or driver > code, so consistently adding a clock-names property preventively > even if only a single clock was used in the first iteration seemed a > prudent thing to do. Adding undocumented properties "preventively" is not the correct approach. Either you document them, or you do not add them. The property with one item and name matching the function is not really a good approach, not helpful. Drop it. > > So these are not technically necessary, but many device tree files will > have these entries, so this is here for those to pass validation. Drop it from DTS then. > > Note that the property doesn't show up along the "clocks" property in > "required:" below. > >> Best regards, Krzysztof