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 X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F04CAC388F9 for ; Mon, 23 Nov 2020 04:16:38 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4C618207FF for ; Mon, 23 Nov 2020 04:16:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nU5yZByG"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ti.com header.i=@ti.com header.b="QecnT0m3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C618207FF Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=NjXTT4pbX355V1/Sl7Hjel6pva86G3ynGGhtiyh2BLc=; b=nU5yZByGlaqxB+6J5YUqgD9El QoBM7ZXkSztWlRz3qncQws4E8RhM/9O8ui7dmAZFnW0x1bR3MaXevUFUiwBy6Mfi/hO34KZW3ZwpO HuFk/Gq+bwqXA6QDZu4wU/EMefnLt7OEvz5PeK2x2mQMSwXqKQz7B3R0LWfP/Vbk3H6RlDerL3eDz Rg6fckEU5Tw6FCsOLBJUs2Flh2RzKxhCz0pkypXxO4Y8hxg3bSS3z+r8NB8y0V6CKvt3vM/x/bgEF v9B5R7eJImYytH+NUuQew0CKTN7OYX5cNecpjX0YijqWI/ez31PZnaFWOUUUySUEFfxXjdwJAMayH KOCHKk2NA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kh3Gk-00060X-8k; Mon, 23 Nov 2020 04:16:02 +0000 Received: from fllv0015.ext.ti.com ([198.47.19.141]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kh3Gg-000602-Tw for linux-arm-kernel@lists.infradead.org; Mon, 23 Nov 2020 04:16:00 +0000 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 0AN4Fpjt047525; Sun, 22 Nov 2020 22:15:51 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1606104951; bh=p8pCdEaf0BGLKH/LQGUp332RXVKuhGq0a2886p63br8=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=QecnT0m3mgKUJlnubLsJMnTAxA5tMqD0yjG8brB4gizpc0pdXNzR/QIFfBIetghTV hPab+0+EQiPpv3IPEKRQrEFWUOO6nT1CPgfAyPUpqeEBDczNWVujmN5sCdPBY7/wxM P5qQVgvetpgo5mToc6MwMLS2aqEZ8hhIc54ln8XM= Received: from DFLE112.ent.ti.com (dfle112.ent.ti.com [10.64.6.33]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 0AN4FpxN088558 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 22 Nov 2020 22:15:51 -0600 Received: from DFLE112.ent.ti.com (10.64.6.33) by DFLE112.ent.ti.com (10.64.6.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Sun, 22 Nov 2020 22:15:51 -0600 Received: from fllv0040.itg.ti.com (10.64.41.20) by DFLE112.ent.ti.com (10.64.6.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Sun, 22 Nov 2020 22:15:51 -0600 Received: from [10.24.69.198] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 0AN4FgL6075871; Sun, 22 Nov 2020 22:15:47 -0600 Subject: Re: [PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller To: Nishanth Menon , Grygorii Strashko References: <20201117161942.38754-1-nsekhar@ti.com> <20201117161942.38754-3-nsekhar@ti.com> <20201118151259.kpag44djji4ssiup@eldest> <18e41dba-a3dd-308a-605e-63b76ca638e5@ti.com> <20201119132829.sr435jf6s4275q4i@boxlike> From: Sekhar Nori Message-ID: <313a9cd5-7411-4ae1-cde4-42a2c18d11e6@ti.com> Date: Mon, 23 Nov 2020 09:45:42 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20201119132829.sr435jf6s4275q4i@boxlike> Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201122_231559_151626_E1655993 X-CRM114-Status: GOOD ( 21.90 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Device Tree Mailing List , Lokesh Vutla , Andre Przywara , linux-kernel@vger.kernel.org, Faiz Abbas , Tero Kristo , Rob Herring , Linux ARM Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 19/11/20 6:58 PM, Nishanth Menon wrote: > Punting over to Rob and DT team's wisdom.. > > On 13:17-20201119, Grygorii Strashko wrote: >> >> >> On 18/11/2020 17:12, Nishanth Menon wrote: >>> On 13:38-20201118, Grygorii Strashko wrote: >>>> Hi Rob, >>>> >>>> On 17/11/2020 18:19, Sekhar Nori wrote: >>>>> With dtc 1.6.0, building TI device-tree files with W=2 results in warnings >>>>> like below for all interrupt controllers. >>>>> >>>>> /bus@100000/bus@30000000/interrupt-controller1: Missing #address-cells in interrupt provider >>>>> >>>>> Fix these by adding #address-cells = <0>; for all interrupt controllers in >>>>> TI device-tree files. Any other #address-cells value is really only needed >>>>> if interrupt-map property is being used (which is not the case for existing >>>>> TI device-tree files) >>>>> >>>>> Signed-off-by: Sekhar Nori >>>>> --- >>>>> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++++ >>>>> arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 2 ++ >>>>> arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 1 + >>>>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 3 +++ >>>>> arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 1 + >>>>> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 1 + >>>>> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 11 +++++++++++ >>>>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 3 +++ >>>>> 8 files changed, 27 insertions(+) >>>>> >>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >>>>> index aa8725db0187..55aaa1404d7d 100644 >>>>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >>>>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >>>>> @@ -440,6 +440,7 @@ >>>>> interrupt-controller; >>>>> interrupt-parent = <&gic500>; >>>>> #interrupt-cells = <1>; >>>>> + #address-cells = <0>; >>>> Does it really required or mandatory to have #address-cells = <0>; defined for interrupt-controller DT nodes which >>>> do not have child nodes and no "interrupt-map"? >>> >>> Just to help clarify (I could be mistaken as well): is'nt the >>> interrupt map for user interrupt map nodes that refer to this >>> interrupt controller node to state they dont need a parent address >>> specifier - so are we claiming none of the users will have an >>> interrupt-map (now and never in the future as well) - we we might want >>> to explain why we think that is the case, and if we are expecting dtc >>> to deduce that (if so how?)? >>> >> >> The main reason I commented - is hope to get some clarification from DT maintainers. >> 90% of interrupt-controller nodes do not have #address-cells and I never seen in in GPIO nodes >> (most often is present in PCI and GIC nodes). >> and nobody seems fixing it. So, if we are going to move this direction it's reasonable to get clarification to be sure. >> >> And there is no "never" here - #address-cells always can be added if really required. > > > OK - as a GPIO node, but as an interrupt-controller node, I was > looking at [1] and wondering if that was the precedence. > > Yes, will be good to get direction from the DT maintainers on this > topic. Shall I respin this series with 2/4 dropped while we wait for decision on this? #address-cells warnings on interrupt controller can perhaps be handled all at once (there are many of those in existing DT anyway). GPIO is basic support and holds up many other modules (like MMC/SD). Thanks, Sekhar _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel