Message ID | 20240216094758.916722-3-antonio.borneo@foss.st.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-68359-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:c619:b0:108:e6aa:91d0 with SMTP id hn25csp403959dyb; Fri, 16 Feb 2024 01:51:09 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWilgTS/lygrYvGj6sB2UcTs3Ap5detAVzd16ShaTuE8cjwIFsqSChAq/wKUpT2Q1FxC6Hpzm+jIh82a1YBNoktSpXa0w== X-Google-Smtp-Source: AGHT+IFEHahYJSOYQVrKcdea0weZgaqQ3xRDs1P4tHtQlO7E9C7MWBwsjm144GMqa/OFssfONjLL X-Received: by 2002:a17:902:eaca:b0:1d7:4353:aba5 with SMTP id p10-20020a170902eaca00b001d74353aba5mr3999606pld.58.1708077069528; Fri, 16 Feb 2024 01:51:09 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708077069; cv=pass; d=google.com; s=arc-20160816; b=i6hDaUV7H1acQ8ChaEduSj+8UPuM2IU+qeffvVDh70D2ARWnvRHDHnvDrRcOYS+RQL o9P/tNssUt+mS+Y3pDltPgKdewEqaqEmjbFlZf5ZY2ZvI2E7yAocLJqmG2IXOopa6vWI 9vEz9tjP9aJenT6Gy3zl2h+vrYC85Txr8uUGugZazF/xy2IJIrEgHIWR+UdtOA9KLkuR j6fV/LWs34mOm8IkgxvXgcNmNUyL0PZKKxr/WEv2IBRPdLIDmMZw1YN8Z8gAXJ6xi2UM SIUULRrHNtN03WYN/CLtbBe6ja7kyzLOBdPZC2k4MkOlHmH0gkqxgJeRvlYGgGjos+/+ FH5Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=6oy4aiUMKITAZcOmFqBjM6ZnhYNqhJFyPyPaNACQD3I=; fh=zaA9bUHoUhiJg2MlubcoK2u7vo9XLyUWHzXlN8LwtMY=; b=CIbt3WdIr1x3+R3NR0GGkT/x1HPSeMHT06lCW+OIyr9AWN+TvhPVKRBbaIO17T3Vh1 5IO8SuS2tOwLwPuDmQHsq4ipopM2ISJsRhjjB96knwSxazPddtIIeoTPC2wD7SwbsTht whEOIcKLvgz4nSTRafwzoB5tyxJddzolFDm4XAAGRCFIHLNeEYmiK/DtZEOkIosd3Xl5 vBJLc/D2qYO5PA/kvZrW3piWj3i+M//ppSE8Iiy7zBHdZhVKxsBzRZTe8MsUci4GRlSJ H5ZQUfO87mqhkD3L2dX7oUi2S0mdpIPoGde57shwbB/vjUyUfn43M4jD0SgCtn9FyXXN Eo8Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=RbZppuBS; arc=pass (i=1 spf=pass spfdomain=foss.st.com dkim=pass dkdomain=foss.st.com dmarc=pass fromdomain=foss.st.com); spf=pass (google.com: domain of linux-kernel+bounces-68359-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-68359-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id b10-20020a170902d50a00b001d9aa5d0a5dsi2709489plg.364.2024.02.16.01.51.09 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Feb 2024 01:51:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-68359-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=RbZppuBS; arc=pass (i=1 spf=pass spfdomain=foss.st.com dkim=pass dkdomain=foss.st.com dmarc=pass fromdomain=foss.st.com); spf=pass (google.com: domain of linux-kernel+bounces-68359-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-68359-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id BD010282DB4 for <ouuuleilei@gmail.com>; Fri, 16 Feb 2024 09:50:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 62ED91CF94; Fri, 16 Feb 2024 09:49:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=foss.st.com header.i=@foss.st.com header.b="RbZppuBS" Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 739AD1BC36; Fri, 16 Feb 2024 09:49:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.207.212.93 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708076974; cv=none; b=B2cilENocmaO7jzwkmCdyAaAFD0kGyoJWRRWbQwj4CwUFotCfn0LPAoEVC7gu/nvqCUC/JjxnTn2aSkHHJtc8AIwqohzttmoh2xFuaozUclGbwoFldn+OGLyMXGsRVwnNkxpVt/Bnno0wzFcLX7qkKWqk291+R0ofzr9L6NQTy4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708076974; c=relaxed/simple; bh=PbKiPm65AQhzwm7LxGporlmFUt0BSmqJq6j8SVwUHjs=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Az02lW1Pz0lgtUgmCvQHYGGz1d6tjQgL8iNjFS3oj2R5OPN+TMvY3CDeJpLUEmjO3R0p+kysdQKp/095m4msC1X9KRAlA0toCL2LdQYqCXHDaer0DZ9zkRMlCZZe266lI8B+QXP2PKnXfn68omh4KdupoTbxjIoGcW2c6heZQM8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=foss.st.com; spf=pass smtp.mailfrom=foss.st.com; dkim=pass (2048-bit key) header.d=foss.st.com header.i=@foss.st.com header.b=RbZppuBS; arc=none smtp.client-ip=91.207.212.93 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 41G4qHJU024968; Fri, 16 Feb 2024 10:49:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s= selector1; bh=6oy4aiUMKITAZcOmFqBjM6ZnhYNqhJFyPyPaNACQD3I=; b=Rb ZppuBSKRCfE/AbEaqxNqIA71yVxaQPb2Z5/M+GS+P4mUIe+YW02k722ObMuEbe9T EKAdxPvUcNWa4tPtIBTF7CBh2yzARnlJgrDLsnjy58nbPJEfaqaUStz/Gxcph/oW SbcFLnG1bKeK/5lESmWN61uv1VPCAi5hAk8Oavo4xDdpll5hX3jxhLoXJyQewWMb RdBiP6f2X7UVqApIaYeP18BxT5e/zbFYdYZattcrl9a1ykHP/cZMl5hA1Y0+Y7kC 168z3S1YxlIx7xPs7QeYXnfPcr1zT1GbDFIwFv9CwH+y7Jem0gytKix2lkHFkl+I yp0MrKV+veearNGx3GuA== Received: from beta.dmz-ap.st.com (beta.dmz-ap.st.com [138.198.100.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3wa126gy3k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Feb 2024 10:49:06 +0100 (CET) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-ap.st.com (STMicroelectronics) with ESMTP id 89DB340048; Fri, 16 Feb 2024 10:49:03 +0100 (CET) Received: from Webmail-eu.st.com (shfdag1node1.st.com [10.75.129.69]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 3D0A8237D75; Fri, 16 Feb 2024 10:48:18 +0100 (CET) Received: from localhost (10.201.20.114) 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.27; Fri, 16 Feb 2024 10:48:17 +0100 From: Antonio Borneo <antonio.borneo@foss.st.com> To: Thomas Gleixner <tglx@linutronix.de>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org> CC: Antonio Borneo <antonio.borneo@foss.st.com>, <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, <linux-arm-kernel@lists.infradead.org>, Fabrice Gasnier <fabrice.gasnier@foss.st.com> Subject: [PATCH 02/12] dt-bindings: interrupt-controller: stm32-exti: Add irq nexus child node Date: Fri, 16 Feb 2024 10:47:47 +0100 Message-ID: <20240216094758.916722-3-antonio.borneo@foss.st.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240216094758.916722-1-antonio.borneo@foss.st.com> References: <20240216094758.916722-1-antonio.borneo@foss.st.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SAFCAS1NODE2.st.com (10.75.90.13) To SHFDAG1NODE1.st.com (10.75.129.69) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-16_08,2024-02-14_01,2023-05-22_02 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791048621300571835 X-GMAIL-MSGID: 1791048621300571835 |
Series |
irqchip/stm32-exti: add irq-map and STM32MP25 support
|
|
Commit Message
Antonio Borneo
Feb. 16, 2024, 9:47 a.m. UTC
The mapping of EXTI interrupts to its parent interrupt controller is both SoC and instance dependent. The current implementation requires adding a new table to the driver's code and a new compatible for each new EXTI instance. Add to the binding an interrupt nexus child node that will be used on the new EXTI instances and can be optionally used on the existing instances. The property 'interrupt-map' in the nexus node maps each EXTI interrupt to the parent interrupt. Align #address-cells and #interrupt-cells between the EXTI node and its nexus node. Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> --- .../interrupt-controller/st,stm32-exti.yaml | 42 ++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-)
Comments
On Fri, Feb 16 2024 at 10:47, Antonio Borneo wrote: > The mapping of EXTI interrupts to its parent interrupt controller > is both SoC and instance dependent. > The current implementation requires adding a new table to the > driver's code and a new compatible for each new EXTI instance. > > Add to the binding an interrupt nexus child node that will be > used on the new EXTI instances and can be optionally used on the > existing instances. > The property 'interrupt-map' in the nexus node maps each EXTI > interrupt to the parent interrupt. > Align #address-cells and #interrupt-cells between the EXTI node > and its nexus node. > > Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com> > Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> This S-O-B chain is broken as it suggests that you wrote the patch and Fabrice relayed it. https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin But that's not the case. If you co-developed this with Fabrice then please use Co-developed-by. See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by Thanks, tglx
On Fri, Feb 16, 2024 at 10:47:47AM +0100, Antonio Borneo wrote: > The mapping of EXTI interrupts to its parent interrupt controller > is both SoC and instance dependent. > The current implementation requires adding a new table to the > driver's code and a new compatible for each new EXTI instance. > > Add to the binding an interrupt nexus child node that will be > used on the new EXTI instances and can be optionally used on the > existing instances. > The property 'interrupt-map' in the nexus node maps each EXTI > interrupt to the parent interrupt. > Align #address-cells and #interrupt-cells between the EXTI node > and its nexus node. Looks like an abuse of interrupt-map. You avoid adding yourself to the abuser list by putting it in a child node. Clever. (See list in drivers/of/irq.c if you don't know what I'm talking about) I assume the EXTI has 0..N interrupts. Just define 'interrupts' with N entries with each entry mapping EXTI interrupt N to 'interrupts' entry N. Rob
On Thu, 2024-02-22 at 16:43 -0700, Rob Herring wrote: > On Fri, Feb 16, 2024 at 10:47:47AM +0100, Antonio Borneo wrote: > > The mapping of EXTI interrupts to its parent interrupt controller > > is both SoC and instance dependent. > > The current implementation requires adding a new table to the > > driver's code and a new compatible for each new EXTI instance. > > > > Add to the binding an interrupt nexus child node that will be > > used on the new EXTI instances and can be optionally used on the > > existing instances. > > The property 'interrupt-map' in the nexus node maps each EXTI > > interrupt to the parent interrupt. > > Align #address-cells and #interrupt-cells between the EXTI node > > and its nexus node. > > Looks like an abuse of interrupt-map. You avoid adding yourself to the > abuser list by putting it in a child node. Clever. (See list in > drivers/of/irq.c if you don't know what I'm talking about) Hi Rob, thanks for the review. Yes, I know already about the abuser list but, from the commit message and the associated comment, I interpret it as an incorrect use of the property interrupt-map with custom syntax thus relying on custom parsing code. The child nexus node in this series allows using the default parser in kernel. From your reply, looks like my interpretation is incorrect and I missed the real concern about the abuser list. Could you please explain why this use of interrupt-map is incorrect and/or which are the correct use cases? > I assume the EXTI has 0..N interrupts. Just define 'interrupts' with N > entries with each entry mapping EXTI interrupt N to 'interrupts' entry > N. Yes, EXTI has 0..N interrupts that can be mapped to multiple parent interrupt controllers and the mapping table has holes. While the DT in this series only use one interrupt parent, a second parent will follow. So 'interrupts-extended' property would be a better matching than 'interrupts' to handle the multiple parents. But how to code the missing entries in an 'interrupts-extended' list? As in the example in Documentation/devicetree/bindings/dma/apple,admac.yaml ? The 'interrupt-map' contains the matching EXTI index, thus allowing a 'sparse' map where holes are simply ignored. Best Regards, Antonio
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml index 00c10a8258f1..1a4cf9537b9e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml @@ -26,6 +26,9 @@ properties: "#interrupt-cells": const: 2 + "#address-cells": + const: 0 + reg: maxItems: 1 @@ -42,6 +45,24 @@ properties: description: Interrupts references to primary interrupt controller + exti-interrupt-map: + type: object + properties: + interrupt-map: true + + interrupt-map-mask: true + + "#interrupt-cells": + const: 2 + + "#address-cells": + const: 0 + + required: + - interrupt-map + - "#interrupt-cells" + - "#address-cells" + required: - "#interrupt-cells" - compatible @@ -89,8 +110,27 @@ examples: reg = <0x5000d000 0x400>; }; + - | //Example 2 - exti2: interrupt-controller@40013c00 { + #include <dt-bindings/interrupt-controller/arm-gic.h> + exti2: interrupt-controller@5000d000 { + compatible = "st,stm32mp1-exti", "syscon"; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0x5000d000 0x400>; + exti-interrupt-map { + #address-cells = <0>; + #interrupt-cells = <2>; + interrupt-map-mask = <0xffffffff 0>; + interrupt-map = + <0 0 &intc GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <3 0 &intc GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>; + }; + }; + + - | + //Example 3 + exti3: interrupt-controller@40013c00 { compatible = "st,stm32-exti"; interrupt-controller; #interrupt-cells = <2>;