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 1E413C433EF for ; Wed, 20 Jul 2022 07:31:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231461AbiGTHbg (ORCPT ); Wed, 20 Jul 2022 03:31:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231174AbiGTHbe (ORCPT ); Wed, 20 Jul 2022 03:31:34 -0400 Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A51946554F for ; Wed, 20 Jul 2022 00:31:32 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id c3so14878920pfb.13 for ; Wed, 20 Jul 2022 00:31:32 -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:from:to:subject:references :in-reply-to:content-transfer-encoding; bh=OlI5K6hu0PIeIC5kQr6NxkHuZecsOQMdSETH93bObWI=; b=JlLadA0btMp8/Wt2su+XdXo3jJ6NeFh8YCR6NPg7ELulYq4egINo2hjtIavkawWNYa zxdCfZgQ5GuIdiiJ8NkXVPqO221C6D7ncIO5EPDun5BURqITg2gV5ceKG7cp5shLswyq 44joKw4hb5KXLTX3Ku8wmzwws2TJdn5h2RBXDB4cdW4dbl/cpEqveU6b2RZ1jOE44Za+ VGY82r1xeqd8KOT380+UcgMSdSbef/BOQmgnvGqg8hA30xeKqWkMJoT80AkmdVHZCwb1 8uEBStlxEBHFD1wj5cGdvnnhRsG6o+0hJAtQg3sVsrS2rwSQMQoj8GdllKQHl3v32ks4 3fbQ== 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:from:to :subject:references:in-reply-to:content-transfer-encoding; bh=OlI5K6hu0PIeIC5kQr6NxkHuZecsOQMdSETH93bObWI=; b=QleJa/t6lMKta7M827p2agsjQCPTYDNM6QmeAN3R/ajNqulx93uArnVC/22UGYD558 c8KKkhjv5Q1j/QVtALrT8hlXeigwGt++h4j9ZLc+G9RiqK9lzhJu/F8705Yw16PFU4xH Zc5pEtS1FXE3Fq0IbcCcAZRH1Cf8AOfXMO3qo7xKBSKlqJ4tPangwHd+t38iQZpj0gvy jl6aJXO6GlrEE3nLK6Mks7EFvKWJXwsKu4Txox/D4jGARDaThrO9f99cs08WfApVW0DG HkjRLL7Mw5J8FwAio6Lk0mC2w2y7126KudHQXCENYRs1Rzkmx+VNZ6BAoPTqWYZ0TC1t FZ8Q== X-Gm-Message-State: AJIora9MvZLXwXXyg8e4ctjRPJs9c9l8+apsKbpZVTmCzdjMLBp67VSl JzoWxJokg8xbF15aUSzomZ188A== X-Google-Smtp-Source: AGRyM1uyvRWCfiAYoI2uRyF7TOSUjHofkF+4bMoix38rm0MUBTo+VbC92LtKHDUz2f5ngGhfoSd5TA== X-Received: by 2002:a05:6a00:24cc:b0:50d:58bf:5104 with SMTP id d12-20020a056a0024cc00b0050d58bf5104mr37881853pfv.36.1658302292028; Wed, 20 Jul 2022 00:31:32 -0700 (PDT) Received: from ?IPV6:2401:4900:1f3b:709e:6fec:df37:6562:5a80? ([2401:4900:1f3b:709e:6fec:df37:6562:5a80]) by smtp.gmail.com with ESMTPSA id s12-20020a17090a948c00b001f21f7821e0sm543535pjo.2.2022.07.20.00.31.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Jul 2022 00:31:31 -0700 (PDT) Message-ID: <60483c44-bc24-2b18-f93d-b67e437b5b72@linaro.org> Date: Wed, 20 Jul 2022 13:01:26 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 From: bhupesh.sharma@linaro.org To: Bjorn Andersson , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, robh@kernel.org, linux-leds@vger.kernel.org, pavel@ucw.cz, bhupesh.linux@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] arm64: dts: qcom: Fix 'dtbs_check' errors for pm8350c & sc8280xp pwm nodes References: <20220719205058.1004942-1-bhupesh.sharma@linaro.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Bjorn, On 7/20/22 3:49 AM, Bjorn Andersson wrote: > On Tue 19 Jul 15:50 CDT 2022, Bhupesh Sharma wrote: > > > make dtbs_check currently reports the following errors > > with pm8350c & sc8280xp pwm nodes: > > > > arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dtb: > > pwm@e800: 'reg' does not match any of the regexes: > > '^led@[0-9a-f]$', 'pinctrl-[0-9]+' > > > > Fix the same. > > > > Cc: Bjorn Andersson > > Signed-off-by: Bhupesh Sharma > > --- > > arch/arm64/boot/dts/qcom/pm8350c.dtsi | 1 - > > arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi | 1 - > > 2 files changed, 2 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/qcom/pm8350c.dtsi b/arch/arm64/boot/dts/qcom/pm8350c.dtsi > > index e0bbb67717fe..33f939132571 100644 > > --- a/arch/arm64/boot/dts/qcom/pm8350c.dtsi > > +++ b/arch/arm64/boot/dts/qcom/pm8350c.dtsi > > @@ -32,7 +32,6 @@ pm8350c_gpios: gpio@8800 { > > > > pm8350c_pwm: pwm@e800 { > > You need to also drop the unit address. > > That said, looking at the dts it's quite nice to have the address of > these nodes. So perhaps we should fix up the binding and populate reg > instead? Well, leaving the unit address in the node label was done to preserve the address information which might be needed later (for better readibility). However, fixing up the binding and populating reg property would make more sense if the driver actually needs it. Looking at the qcom led driver in its current form, it doesn't seem to require the same. Please correct me if I am wrong (as I just had a quick look at the same). However, if we still want to have the unit addresses and the reg property for better readibility in the dts, may be we can mark reg as an optional property in the binding and leave it up to the driver to use it (with a future update) optionally. Please let me know your views. Regards, Bhupesh > > compatible = "qcom,pm8350c-pwm"; > > - reg = <0xe800>; > > #pwm-cells = <2>; > > status = "disabled"; > > }; > > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi > > index ae90b97aecb8..69f5bc8127b2 100644 > > --- a/arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sc8280xp-pmics.dtsi > > @@ -62,7 +62,6 @@ pmc8280c_gpios: gpio@8800 { > > > > pmc8280c_lpg: lpg@e800 { > > compatible = "qcom,pm8350c-pwm"; > > - reg = <0xe800>; > > > > #address-cells = <1>; > > #size-cells = <0>; > > -- > > 2.35.3 > > >