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 7BDABC54EBE for ; Mon, 16 Jan 2023 14:22:31 +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-Type: Content-Transfer-Encoding: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=BWBfyLTrtQnAOCWWe9C3rgxbHl2bOINZR8yCz7ezKGQ=; b=pkalz1Ef3uEgel VD6653sgk7sUZmUerCTA0tH3Udg4J7v62tfygAZncU9vtkZQiUnkx2625N9W/ksovdG+8dG8+w3I3 JH0OTfVuVRzfpwjp8T73vQiBfHiNY52JniniM1I0d3MUYeTp3VYvRTLtibSVzey0NYhd+FTVno5yf aQQUFbkUCzDvJNMqsgm2LkkRfnJ1uutNm8MKei/a+Zj9KM/hVoyFxn+UKucnAOhEJ4ndtA3ePKFN7 2A7Bfukh/khz7Q+aSGs+fZnTp7n9Ft8ix9MM1inVMhtnC3454t17BKAopmcwkHttgrBKO0dXhuF5h 9ghXqKY1Yc0uww1uxleg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pHQMR-00AqeF-4V; Mon, 16 Jan 2023 14:21:19 +0000 Received: from mx07-00178001.pphosted.com ([185.132.182.106]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pHQ8e-00AjAK-6a for linux-arm-kernel@lists.infradead.org; Mon, 16 Jan 2023 14:07:06 +0000 Received: from pps.filterd (m0241204.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30G9eUvf000401; Mon, 16 Jan 2023 15:06:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=selector1; bh=ZUFiwmuXUVXgB50AexCJ2aYXXaHlJR5y5ppvtTRfE5M=; b=Ynb3g2gvkWCA3S6BQnWw+9IsEdYk6PRDDSoS5+Ixdvlq4gNMlHpP6Vi91He0GXFybI0c PKgmKzxS/BJlagpQyZVjPRqAe/6+93YzeYUMmNluKe2K7w1PpT/+mUKvV2pEMR62c+Lt xr0Rj1il4tHdOpSIDJy1U9kVdOZcRoXyNorvmZ+O6CRzzgBwia9i870GAUl1Rn00JSon 40PDQRyxmp7JebhBwlbfMlYArt8i237IBpOvSYKtMB9Sje6BjPylSmZjFbqXV8mfgcEm MubhEpSbkiZvUakCwF6cwjf8/SShJ0UinfSkUy3kIbaWBE3RuzX+TWeVSSC8xh909/da gg== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3n3mm6a9vm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Jan 2023 15:06:40 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E994010002A; Mon, 16 Jan 2023 15:06:38 +0100 (CET) Received: from Webmail-eu.st.com (shfdag1node1.st.com [10.75.129.69]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id D66472194F2; Mon, 16 Jan 2023 15:06:38 +0100 (CET) Received: from [10.201.21.177] (10.201.21.177) by SHFDAG1NODE1.st.com (10.75.129.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.13; Mon, 16 Jan 2023 15:06:38 +0100 Message-ID: Date: Mon, 16 Jan 2023 15:06:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [RFC PATCH 3/7] dt-bindings: bus: add STM32MP15 ETZPC firewall bus bindings Content-Language: en-US To: Krzysztof Kozlowski , , , , , CC: , , , , , , 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: Gatien CHEVALLIER In-Reply-To: X-Originating-IP: [10.201.21.177] X-ClientProxiedBy: SHFCAS1NODE2.st.com (10.75.129.73) To SHFDAG1NODE1.st.com (10.75.129.69) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-16_11,2023-01-13_02,2022-06-22_01 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230116_060704_759808_567719CA X-CRM114-Status: GOOD ( 33.24 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Krzysztof, On 1/11/23 13:32, Krzysztof Kozlowski wrote: > 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. I see what you want to avoid, These bindings are indeed presented as pure helpers here. They are not used by the firewall bus driver on Linux except for the value that they represent, thus your comment. However, they will be shared between different boot chain components. I do not have an upstreamed example to give but please see that we might use them in OP-TEE: [1] https://github.com/STMicroelectronics/optee_os/blob/3.16.0-stm32mp/core/include/dt-bindings/soc/stm32mp13-etzpc.h They could be used and used differently depending on the software component (e.g: lock of secure configuration for a particular peripheral, ...). This change is here for consistency between those. > > Best regards, > Krzysztof > Best regards, Gatien _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel