From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D0F183BE2E0; Sat, 28 Feb 2026 17:39:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300349; cv=none; b=UNSUt5BV5DPzgbmjv7sz7jA5OSIH2EMztLKqQ03TlQJt3iQgLYahZ/5AIPnb25xKDJ6QfhMYauK+RnaIcZSJPdCVXDhdphQ9Pwn2gDhSr9ooVOu8rFmQ3JHtEusb9hCtQY0tTQmmEeZ8xIA23JsuOnvClqDx32NjmNI3f/0ph2A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300349; c=relaxed/simple; bh=FtLPtrI0n80xUd47vPTSe/TrOI8y2V9Hv0qj46pAWpQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RYW+atiYK9CGRfSWFhpHUX2PDG0e7lN5ZSU4ILgSIsfP1IKmpvMmAJueAD3Ku60Ef/HzNDo01FhWwW1vA4ut/odbaMuoGdyZ+VUwZl4Nv2ltplg/q3Vo0ghb6aFzJvbT/UM7TbaDILdWJ0uczjc3kLLTytov028ORD/GEtDoBUM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HzUXjEWP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HzUXjEWP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22DCAC116D0; Sat, 28 Feb 2026 17:39:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300349; bh=FtLPtrI0n80xUd47vPTSe/TrOI8y2V9Hv0qj46pAWpQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HzUXjEWPidg5Ms0u6plunCLC775KG+YurFXSa3oqiTiuZ7f13LeFRESHcUWSWnvzo jZmOwXI7OvLw8NkiLaUHmf3a5SO6RvF6yToEOfj02Dp6H/HHzTuR45PspX6QGjN0jG WGA3msTR2XxgVurBkGBsjltMwVHNRvePAfwjo2sQsVzbZmGDA9L2CcrvWCYWsSnOTL wafbACKQ0vtSftOVAeHJW0zG/0/CyiO3u2PA74rVelc97FQM8pLcfycDuNuT0Xp95+ q1Zd68y8baN6B15tZXuOUhB8WbPgcRtBYXuLEceRqgq6PkQ2rqBe0dghipNxKiI/hu l2+Lc6u92hmjA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Cosmin Tanislav , Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.19 383/844] pinctrl: renesas: rzt2h: Allow .get_direction() for IRQ function GPIOs Date: Sat, 28 Feb 2026 12:24:56 -0500 Message-ID: <20260228173244.1509663-384-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit From: Cosmin Tanislav [ Upstream commit 49b039a61a314c18074c15a7047705399e1240e6 ] Setting up an IRQ would normally be done in the .activate() and .deactivate() ops of the IRQ domain, but for hierarchical IRQ domains the .activate() and .deactivate() ops are overridden in the gpiochip_hierarchy_setup_domain_ops() function. As such, activating and deactivating need to be done in the .translate() and .free() ops of the IRQ domain. For RZ/T2H and RZ/N2H, interrupts go through the pin controller, into the ICU, which level-translates them and forwards them to the GIC. To use a GPIO as an interrupt it needs to be put into peripheral function mode 0, which will connect it to the IRQ lines of the ICU. The IRQ chip .child_to_parent_hwirq() callback is called as part of the IRQ fwspec parsing logic (as part of irq_create_of_mapping()) which happens before the IRQ is requested (as part of gpiochip_lock_as_irq()). gpiochip_lock_as_irq() calls gpiod_get_direction() if the .get_direction() callback is provided to ensure that the GPIO line is set up as input. In our case, IRQ function is separate from GPIO, and both cannot be true at the same time. Return GPIO_LINE_DIRECTION_IN even if pin is in IRQ function to allow this setup to work. Hold the spinlock to ensure atomicity between reading the PMC register (which determines whether the pin is in GPIO mode or not) and reading the function of the pin when it is not in GPIO mode. Signed-off-by: Cosmin Tanislav Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251205150234.2958140-3-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin --- drivers/pinctrl/renesas/pinctrl-rzt2h.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/pinctrl/renesas/pinctrl-rzt2h.c b/drivers/pinctrl/renesas/pinctrl-rzt2h.c index 4826ff91cd906..40df706210119 100644 --- a/drivers/pinctrl/renesas/pinctrl-rzt2h.c +++ b/drivers/pinctrl/renesas/pinctrl-rzt2h.c @@ -51,6 +51,7 @@ #define PFC_MASK GENMASK_ULL(5, 0) #define PFC_PIN_MASK(pin) (PFC_MASK << ((pin) * 8)) +#define PFC_FUNC_INTERRUPT 0 /* * Use 16 lower bits [15:0] for pin identifier @@ -486,6 +487,7 @@ static int rzt2h_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) struct rzt2h_pinctrl *pctrl = gpiochip_get_data(chip); u8 port = RZT2H_PIN_ID_TO_PORT(offset); u8 bit = RZT2H_PIN_ID_TO_PIN(offset); + u64 reg64; u16 reg; int ret; @@ -493,8 +495,25 @@ static int rzt2h_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) if (ret) return ret; - if (rzt2h_pinctrl_readb(pctrl, port, PMC(port)) & BIT(bit)) + guard(spinlock_irqsave)(&pctrl->lock); + + if (rzt2h_pinctrl_readb(pctrl, port, PMC(port)) & BIT(bit)) { + /* + * When a GPIO is being requested as an IRQ, the pinctrl + * framework expects to be able to read the GPIO's direction. + * IRQ function is separate from GPIO, and enabling it takes the + * pin out of GPIO mode. + * At this point, .child_to_parent_hwirq() has already been + * called to enable the IRQ function. + * Default to input direction for IRQ function. + */ + reg64 = rzt2h_pinctrl_readq(pctrl, port, PFC(port)); + reg64 = (reg64 >> (bit * 8)) & PFC_MASK; + if (reg64 == PFC_FUNC_INTERRUPT) + return GPIO_LINE_DIRECTION_IN; + return -EINVAL; + } reg = rzt2h_pinctrl_readw(pctrl, port, PM(port)); reg = (reg >> (bit * 2)) & PM_MASK; -- 2.51.0