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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A7008C3DA42 for ; Wed, 10 Jul 2024 09:02:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oTf49SxRwa0sB5NhRrrNqZ5Ar5BKL5T7cMNJ6/9vxDE=; b=LO4fHN3PYbpoLudEwrWbXxE4uH GLHDGjb71aYJj0oO5l7uCS6aYbLcFHjUgi3SGUN3UxFJr1zd40SIQAsaOkuDnnDcvD3AfSSdiVPoc uYpvfo2Q6HnQhmtFQHLkcGHkQP5UV6Z5/jzByrtjD0Z6B7ROXgYNI/pPcFdelgV2eAJlazVmbfCx5 J5gidKraR/J62SrJ9zCMsMwlo7Nl5rM+lywLRhrOPFIyalLHX/ZHoTyy9ipW/fRtB0eA717mIn48Q Xa+eEcvZg97n3zgErPNXJLIXywOGb//Hto9uOpaH/pKu9hoKOXCERdjX7gmqVTZahkSuQk5aJ2o/j p45YEI9g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRTD4-0000000A0Xa-3PCf; Wed, 10 Jul 2024 09:01:58 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRTCo-0000000A0TA-1rUd for linux-arm-kernel@lists.infradead.org; Wed, 10 Jul 2024 09:01:43 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E09B361741; Wed, 10 Jul 2024 09:01:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C80DC32781; Wed, 10 Jul 2024 09:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720602101; bh=B/XFMfWU5ZqXj0qnN6nB10B5m+mTj+wFKvLPsFSnbUs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=V5KUlUsWia4ujO5KlNShozP/c4sSt7QYPzm6VZw9+thhlVm3JcN0YCzAwi29KvUGq 58s0kauuUjYAVx7unbeUIg/8bOPbKUUUgkf26iux1CHEUL9I42eQGqi6YfHJPu6K60 XRj1IYbBdXFqUMd7QbPM9R53sWADw0c52KtU5mb+xImQenML3KYHM2h2rTtubk+iyk awa7hxg4iUG9KK7Zy5L57RikY7esWe233SB1nZk1Xzy4wG7qhp+rz15IM7ZuKrIinH c766z5kFEYlZkQQyeshRWZVqKuimDBpFwKf8SDg5fo40do9sSCI8p/zyeDvMmahxdf XHcdJAbD0RvUg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1sRTCV-00BAQB-8t; Wed, 10 Jul 2024 10:01:39 +0100 Date: Wed, 10 Jul 2024 10:01:22 +0100 Message-ID: <86y16939jx.wl-maz@kernel.org> From: Marc Zyngier To: Cc: , , , , , , , , , , , Subject: Re: [PATCH v5 15/27] dt-bindings: interrupt-controller: Document the property microchip,nr-irqs In-Reply-To: <82ca4f3d-fa78-4617-823e-69f16a2c3319@microchip.com> References: <20240703102011.193343-1-varshini.rajendran@microchip.com> <20240703102814.196063-1-varshini.rajendran@microchip.com> <20240703-dentist-wired-bdb063522ef7@spud> <82ca4f3d-fa78-4617-823e-69f16a2c3319@microchip.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.3 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: Nicolas.Ferre@microchip.com, Varshini.Rajendran@microchip.com, conor@kernel.org, tglx@linutronix.de, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, alexandre.belloni@bootlin.com, claudiu.beznea@tuxon.dev, Dharma.B@microchip.com, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240710_020142_594948_C92D3095 X-CRM114-Status: GOOD ( 33.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 09 Jul 2024 15:06:29 +0100, wrote: > > On 09/07/2024 at 08:13, Varshini Rajendran - I67070 wrote: > > On 03/07/24 9:11 pm, Conor Dooley wrote: > >> On Wed, Jul 03, 2024 at 03:58:14PM +0530, Varshini Rajendran wrote: > >>> Add the description and conditions to the device tree documentation > >>> for the property microchip,nr-irqs. > >>> > >>> Signed-off-by: Varshini Rajendran > >> This needs to be part of patch 14. > >> > >>> --- > >>> .../bindings/interrupt-controller/atmel,aic.yaml | 12 ++++++++++++ > >>> 1 file changed, 12 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.yaml > >>> index 9c5af9dbcb6e..06e5f92e7d53 100644 > >>> --- a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.yaml > >>> +++ b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.yaml > >>> @@ -54,6 +54,10 @@ properties: > >>> $ref: /schemas/types.yaml#/definitions/uint32-array > >>> description: u32 array of external irqs. > >>> > >>> + microchip,nr-irqs: > >>> + $ref: /schemas/types.yaml#/definitions/uint32-array > >>> + description: u32 array of nr_irqs. > >> This makes no sense, did you just copy from above? Why would the number > >> of irqs be an array? Why can't you determine this from the compatble? > >> > > Sorry for the bad description. I will correct it in the next version. > > > > For the second part of the question, this change was done as a step to > > resolve having a new compatible while having practically the same IP > > pointed out in the v3 of the series [1]. It is kind of looping back to > > the initial idea now. Even if this is added as a driver data, it > > overrides the expectation from the comment in [1]. Please suggest. I > > In your v3 patch, indeed you were extracting the number of IRQs from the > compatibility string (aka, from device tree...). It's my preferred > solution as well. > > So, come back to v3 [1] and address what Conor said in v4 "...having > specific $soc_aic5_of_init() functions for each SoC seems silly when > usually only the number of interrupts changes. The number of IRQs could > be in the match data and you could use aic5_of_init in your > IRQCHIP_DECLARE directly" > > I think that we can convince Marc/Thomas that it's the best option as it > prevents introducing another non-standard property to the DT, break the > ABI (and was used happily for years). In general, the least cruft we add to the DT after the facts, the better. If the compatible string is good enough to identify the device, I don't think we need to overthink it, specially as there is no upside to non-standard properties here -- from what I understand, the number of available interrupts is a property of the HW, and not something that can be configured, making it part of the programming model, just like the layout of registers. But I'm not in a deciding position anymore, and this is only my (educated) opinion. Thanks, M. -- Without deviation from the norm, progress is not possible.