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 72EA9C433EF for ; Sat, 9 Apr 2022 13:10:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241925AbiDINM5 (ORCPT ); Sat, 9 Apr 2022 09:12:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241889AbiDINM0 (ORCPT ); Sat, 9 Apr 2022 09:12:26 -0400 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3DCF3FBD3 for ; Sat, 9 Apr 2022 06:10:15 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id d10so12994137edj.0 for ; Sat, 09 Apr 2022 06:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=r69gfmWYQUj3kQz0ytrjwX6d+x9monu97mTCKGNU34E=; b=h+m4IGpyhiTc9J83wjYFv4Kx2b+wzkpm/PX4pYzjtCA+MWKSO84kOXjbhukcjwIXBr yDoijQNRCyKwC+IYdJEUtamQyRrgNubKwPOoaA1NjNuq4IncZOVNytFr7LQct0O/UOQC UYhOFjInyOzKsk7/t9erLBRY56v3qTTI3jQ821CESpF0OUUCdu6ohTDMDrWimUwa7Lvl 1s6X0T+kCVcHQckTIuUWiQJiw7cF7fSENgeDDpag0Yc2OMyVv3z7rOUG/eKusSiQGysK lnMdJynsSY7QFidTYwmmFV7Z1C9OmebAwFuRI6sld8AOpe48dBByvRkLoaqug3kvUywL LqXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=r69gfmWYQUj3kQz0ytrjwX6d+x9monu97mTCKGNU34E=; b=8QHdbLIi+P/52TqhwPoHSHiVi29/Xyj+plaRUjhSFlrwRaEmVOBnj5R9a+EEJLUF0y CfUgJMJTPJs70iZKnamK6giDguB7Z4LGlhpYlUfaG2Vbfkpno/ep+nrbLIP7gBjB3T9/ SQB2hMB5buw8pihZxF8tspH7AXF5nmA0+BOWD6e5eG2iVZhNBNfHRF3vzsKWIYB1YveQ NK4Y40e0GLMbSqCHjkhMyLkOu8Iq06zoJDbA3lNgz8X8TWXiPI7ZvMLlhe6JsKZYEKyG 729MlcRleDUoYJH7pkZORIN5IUzpQ8J9dQMH/Bb8dIszxQkWDDD3kOshN1OnqG6PvDSB CEzw== X-Gm-Message-State: AOAM533aUw6j72mvcef6nUehBvjdsP8UbWfi9ifT+pjlu9TVwSsJxinA 76hcijffpki0CC8gUHEg7H4GzA== X-Google-Smtp-Source: ABdhPJx7msdh9mcbYUpr+/xvQ2lU6xwhmzQw8KoD510T6nd7WxDMx4rlZdWmCrcUJuIidGGR+PA0rQ== X-Received: by 2002:a05:6402:2747:b0:419:4817:ba22 with SMTP id z7-20020a056402274700b004194817ba22mr23622704edd.253.1649509814373; Sat, 09 Apr 2022 06:10:14 -0700 (PDT) Received: from [192.168.0.188] (xdsl-188-155-201-27.adslplus.ch. [188.155.201.27]) by smtp.gmail.com with ESMTPSA id j12-20020a50e0cc000000b0041cd813ac01sm7809179edl.28.2022.04.09.06.10.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Apr 2022 06:10:13 -0700 (PDT) Message-ID: Date: Sat, 9 Apr 2022 15:10:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH 01/18] MIPS: DTS: jz4780: remove cpu clock-names as reported by dtbscheck Content-Language: en-US To: "H. Nikolaus Schaller" Cc: Rob Herring , Paul Cercueil , Thomas Bogendoerfer , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-mips@vger.kernel.org, letux-kernel@openphoenux.org References: <064a1f029a82ea3895109efe8fb1f472581d4581.1649443080.git.hns@goldelico.com> <0a0cb08a-3992-7e20-61ca-7856ce273005@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-mips@vger.kernel.org On 09/04/2022 15:02, H. Nikolaus Schaller wrote: > Hi Krzysztof, > >> Am 09.04.2022 um 13:07 schrieb Krzysztof Kozlowski : >> >> On 08/04/2022 20:37, H. Nikolaus Schaller wrote: >>> arch/mips/boot/dts/ingenic/ci20.dtb: cpu@0: clock-names does not match any of the regexes: pinctrl-[0-9]+ >>> From schema: Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml >>> arch/mips/boot/dts/ingenic/ci20.dtb: cpu@1: clock-names does not match any of the regexes: pinctrl-[0-9]+ >>> From schema: Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml >> >> No need to put the same warning twice (cpu index really does not >> matter). One warning is enough. > > Well, how can you as a reviewer see immediately that dtbscheck > warns for both instances and that they are both really fixed by the > complete patch? > > Assume there were only the first one mentioned and the second one > forgotten to fix... > > If it is not included here (completely), you have to run dtbscheck > yourself to see that there are two instances involved. Or deduce it > from looking into the source file. > > In both cases much more work for you or other reviewers. > > This is why I have kept this redundancy. One commit hunk for every > warning line. > > And it may only look redundant in the commit message, not in code > where it would really hurt to have duplication. Sorry, but the second warning is obvious. It really does not bring any information and better to keep things simple and concise. Concise helps to read/understand the commit. > >> >> Fixing warnings is good, but what if the property should be there and >> the bindings are not correct? If you know the answer, please add it to >> the commit msg. > > It has of course been tested on real hardware. Good, but it's not everything. DTS is a description of hardware and we might want to have the extended description, e.g. with clock-names. > There was only one case where the bindings seem to be wrong (patch 13/18). > > And usually I simply assume such generic bindings are tested on many > other platforms and therefore the reference. What are bindings and > dtbscheck good for if we doubt them as DTS developers? You should always doubt, knowing how incompletely or poorly bindings were written or converted (including the ones I was doing myself). > >> This applies to all your patches. Blind fixing of DTS warnings my >> produce incorrect results. :( > > Every patch of this series has been tested on real hardware to have > no negative side-effects. Which is not everything. DTS might be used in other projects - did you test them as well? Best regards, Krzysztof