From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.mindbit.ro (xs1.mindbit.ro [80.86.107.70]) (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 E7C661A9F83 for ; Sat, 15 Aug 2026 14:19:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.86.107.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786803574; cv=none; b=fbwe+bIjmu9a1piiEmiNTAuimfpmzh5sqE/z208VeEV4Op10/U26oWd0wtMwcoHNh6G+cFNIvBUWPr4hiVMrco/GaHqIutgdNZuxxoffC9/7MVeQjk6piWG+Z+HLUGA7tyL2MVFWm82YL2V/NxI2EzYn1Rc2VJDeOJDRjGCmh5E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786803574; c=relaxed/simple; bh=gR7omYmcMf8FnjqViS2MNjkPk3Dwc0mIQcIOk0w2+78=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=U1MFNBt1wBSMEgrKk+izN4aQ7YELZFpCbCeSPXoqoIN+SRaJ09qqixHp66ChOoMzfPoMXmQbi4OHXtuHjrAFqQ9/CSz/o+2eVjBCPknJxOOpQuF6LNVtbXEH+4CjZbtGZToRmbo0qlW65tLyWN5i8uKW7JTLEBPag22grnWTyII= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=rendec.net; spf=pass smtp.mailfrom=rendec.net; dkim=pass (2048-bit key) header.d=rendec.net header.i=@rendec.net header.b=LR3+UsHb; arc=none smtp.client-ip=80.86.107.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=rendec.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rendec.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rendec.net header.i=@rendec.net header.b="LR3+UsHb" Received: from dog.kanata.rendec.net (pool-174-112-193-187.cpe.net.cable.rogers.com [174.112.193.187]) by mail.mindbit.ro (Postfix) with ESMTPSA id 247C9C366C; Sat, 15 Aug 2026 17:19:27 +0300 (EEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.mindbit.ro 247C9C366C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rendec.net; s=default; t=1786803569; bh=ebqxWaZEqKRkKJxOKbi5xPVzyiRrHaZdHEkKyvqD7Vs=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=LR3+UsHbae2GUWnAzjovQ8VKzWsUj7r5coZYjX8AVSCYj24/abW0RXrAAwgvKQDW4 o/aALiJaSLeMX3e3zzGbWYBzlDIDX5Gp+fz8OzVMYufTD6+B5uiZdWY32atBKVXcdq mUKr9XYcqOAeFx+7hgbAAxxHym/hE+bd4Xu78tkPOYMFk6L2gF0YrOWmlCScrteq7T UQwQyhPr01ppBI26uQLOLANvgScNa9M3DXldLSyuNS0x4C+8rOE/Z76d+z4OZvc8/1 Vxvh5h9VongRAniUjiw9L3KoJwpil/3nuFz+mdnTQKgfJ85LNhnYH8ytCkl6boK9u7 em6zDzaSwJw3w== Message-ID: Subject: Re: [PATCH] irqchip/stm32mp-exti: fix the unit of the hwspinlock timeout From: Radu Rendec To: Ju Nan , tglx@kernel.org, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com Cc: linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Date: Sat, 15 Aug 2026 10:19:26 -0400 In-Reply-To: <0748a117106e6ae41ae5361ba053af3e96feed40.camel@rendec.net> References: <20260805032139.35420-2-junan76@163.com> <0748a117106e6ae41ae5361ba053af3e96feed40.camel@rendec.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Sat, 2026-08-15 at 10:08 -0400, Radu Rendec wrote: > On Wed, 2026-08-05 at 11:21 +0800, Ju Nan wrote: > > HWSPNLCK_TIMEOUT is passed to hwspin_lock_timeout_in_atomic(), whose > > timeout argument is in milliseconds, not microseconds: > >=20 > > =C2=A0 atomic_delay +=3D HWSPINLOCK_RETRY_DELAY_US; > > =C2=A0 if (atomic_delay > to * 1000) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return -ETIMEDOU= T; > >=20 > > So stm32mp_exti_set_type() asks for a 1 second timeout where the commen= t > > next to the macro says it wants 1 millisecond. The semaphore is polled > > with udelay() from a section that holds chip_data->rlock, a > > raw_spinlock_t, so preemption stays disabled for the whole wait on ever= y > > configuration, PREEMPT_RT included. > >=20 > > The hwspinlock core documents this explicitly: > >=20 > > =C2=A0 If the mode is HWLOCK_IN_ATOMIC (called from an atomic context) = the > > =C2=A0 timeout is handled with busy-waiting delays, hence shall not exc= eed > > =C2=A0 few msecs. > >=20 > > Pass the value the comment always described. The core retries every > > HWSPINLOCK_RETRY_DELAY_US (100 us), so the semaphore is still polled te= n > > times before giving up, which is far longer than any plausible hold tim= e > > on the coprocessor side. A timeout is reported with pr_err() and fails > > the trigger type configuration, so shortening it degrades gracefully. > >=20 > > Signed-off-by: Ju Nan > > --- > > =C2=A0drivers/irqchip/irq-stm32mp-exti.c | 2 +- > > =C2=A01 file changed, 1 insertion(+), 1 deletion(-) > >=20 > > diff --git a/drivers/irqchip/irq-stm32mp-exti.c b/drivers/irqchip/irq-s= tm32mp-exti.c > > index a24f4f1a4..f5f0109bf 100644 > > --- a/drivers/irqchip/irq-stm32mp-exti.c > > +++ b/drivers/irqchip/irq-stm32mp-exti.c > > @@ -23,7 +23,7 @@ > > =C2=A0 > > =C2=A0#define IRQS_PER_BANK 32 > > =C2=A0 > > -#define HWSPNLCK_TIMEOUT 1000 /* usec */ > > +#define HWSPNLCK_TIMEOUT 1 /* msec */ > > =C2=A0 > > =C2=A0#define EXTI_EnCIDCFGR(n) (0x180 + (n) * 4) > > =C2=A0#define EXTI_HWCFGR1 0x3f0 >=20 > Reviewed-by: Radu Rendec Oops! Hit the "send" button too soon. The patch is OK, so the r-b tag stays. But it also needs this: Fixes: 5257169ade8c ("irqchip/stm32-exti: Use the hwspin_lock_timeout_in_at= omic() API")