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 64392C46467 for ; Wed, 11 Jan 2023 12:34:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=71dPxCZ0Pu8AItLzr/aRxsB7fQtkna2FP3iIaOMpMKU=; b=ogREv/OvmUQk8+ XAHR0BXFiAHRkKZ50nDjfg3tJ0yeBVS4Y1Jv2r0ontENPISch0cEkut3l0q07ivOxRboAfOjdk93q /WOmGs80KJsj8hD1ol69gGJjJnptacmTddyHFNsJPWwH6wVAGZB7GxJlvZADz+X+c+j43Lu578kKH fEe2sctuIu3Luf2Z0VQ0v/UM5JUs0mG7gYUg3/tDrO3gK5Z4F9OJvtt44WlEA/IdYUKhzq4efDOhP fbpnPw1IdUawp3Sik0rXAVRp3sU9f+V83qI/L+h/AKaGD2iqH1l7uqXwHtib0nDqY6tcSoAm2CzKe 1mE+PGieJIIPZbhL8Y6g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFaI6-00BH7Y-V9; Wed, 11 Jan 2023 12:33:15 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFaI3-00BH6i-Uy for linux-arm-kernel@lists.infradead.org; Wed, 11 Jan 2023 12:33:13 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 29ADDB81A6B; Wed, 11 Jan 2023 12:33:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4F8EC433D2; Wed, 11 Jan 2023 12:33:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673440386; bh=6W/sprcBudgz8eSbOqZAoynmDsVr5n+AmKEg6gnvo7E=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=iNT+x5ovfUERKQKn0QCi2Hr6v1mc7OiOcp6FQWt55TXInjq9T7CaIw11ND7C5K6ZT qrEZ7E3sqmJKzPFVmXFT/Dwd+jckngmq17h0qOdHtAhtAOa6FseN9c0fgoPKqXiP4a yjqB+ITh1XrU3EA61z774v29nYdIAo76DcGTTgrHXRmxgCU9BwkfWP9Y8MsqvrLHO/ XWB4TpvaGXUcGljISgvuKfCUcmis1KaMB+7QA1ul4ZpeKCnZjKlzNmHw1Z7AptcCiu M26Li5Hk/rrhHH8ew/GEO62iVArAjy0ZIA5pSknU6M7DIehshw8AlKfbin3S/yEJFi L/v4Ma3Fu4+YQ== Message-ID: Date: Wed, 11 Jan 2023 13:32:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [RFC PATCH 3/7] dt-bindings: bus: add STM32MP15 ETZPC firewall bus bindings Content-Language: en-US To: Gatien CHEVALLIER , alexandre.torgue@foss.st.com, robh+dt@kernel.org, Oleksii_Moisieiev@epam.com, linus.walleij@linaro.org, gregkh@linuxfoundation.org Cc: linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loic.pallardy@st.com, devicetree@vger.kernel.org, mark.rutland@arm.com, arnd@arndb.de References: <20221221173055.11719-1-gatien.chevallier@foss.st.com> <20221221173055.11719-4-gatien.chevallier@foss.st.com> <879325d2-4b2d-bc1d-310c-ece4c449ad8f@kernel.org> <8357d887-c8ab-39bc-4ef0-62e9225fb2a6@foss.st.com> <118e7f0c-bf5d-4bda-ee70-92eb2b71649c@kernel.org> <8f022dc8-d728-ba91-35ed-8a4006855f0d@foss.st.com> <19157c67-fa83-e598-d7ee-c313f3d4b198@foss.st.com> From: Krzysztof Kozlowski In-Reply-To: <19157c67-fa83-e598-d7ee-c313f3d4b198@foss.st.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230111_043312_333913_95D6611B X-CRM114-Status: GOOD ( 28.38 ) 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: , 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 09/01/2023 12:54, Gatien CHEVALLIER wrote: >>>> Then why do you define them in bindings? Use raw numbers. Do you see >>>> anywhere in arm/arm64 bindings for GIC_SPI interrupt numbers? >>>> >>> >>> What would you think of simply removing the comments that state that IDs >>> are reserved, mimicking the way it is for qcom bindings? Fundamentally, >>> they are indeed only IDs and could be raw numbers. >> >> If these are IDs then there are no reserved numbers and they are >> continuous from 0 to X. Without gaps. >> >>> IMO, this makes reading the device tree harder. Because you'd have to >>> look what the raw number corresponds to. >> >> Sure, but that's not the reason to put numbers to the bindings... You >> mix defines with bindings. >> >>> To take an example, it has already been done for SCMI clocks and I find >>> it eases comprehension. >> >> You need to be a bit more specific... > > Please see include/dt-bindings/clock/stm32mp1-clks.h, where there are > various clock IDs defined, some of them not contiguous. These are pretty often added to accommodate space for exposing these clocks in the future. IOW, these might be IDs just not all are shared via header. There are such platforms and it is OK. > > Errata: for SCMI clocks they are indeed contiguous but not clock IDs. > >> >> Anyway, IDs should be placed in bindings. Some mapping of >> internal/hardware ports, registers, offsets, values - usually not. >> >> I don't know where exactly your case fits, but when some IDs are >> reserved it is a clear sign that these are not IDs (again - IDs start >> from 0 and go incrementally by one, without gaps). >> > > I do agree with your statement that IDs should not be reserved. > > I think I've missed something to better highlight my point of view: It > would be perfectly fine using numbers that are not described in this > bindings file. It would just not correspond to an ID of a peripheral > described in the SoC reference manual, thus making no sense to use them. > Stating that they are reserved was incorrect, it's just that peripherals > get a firewall ID, depending on the platform. Why peripheral ID should be put into the bindings? Why bindings is a place for it? Interrupt numbers, GPIO indices/numbers, register offsets, IOMMU ports - none of these are suitable for bindings. > > I think it should be okay not describing IDs that are not relevant, what > do you think? I found that in include/dt-bindings/arm/qcom,ids.h, IDs > are not continuous. Not mentioning an ID could be used for deprecation. These are not IDs of clocks. These are unique identifiers assigned by vendor and used by different pieces: firmware/bootloaders, DTS and Linux driver. We have no control of them but they exist. They also do not represent any hardware number. You bring some examples as an argument, but these examples are not always related to your case. To be clear - we talk here about bindings, so they bind different interfaces of software components (e.g. Linux kernel with DTS). Now, what is the different interface here in your case? If you say your peripheral hardware ID, then answer is no - this is not software interface. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel