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 2C02F419FD4 for ; Sat, 15 Aug 2026 14:13:42 +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=1786803226; cv=none; b=Qz+dSCz98PAE2J9d87L80Qfjv82JPi5k/4e9wMKcddZmmPCf/6oI8m7x/XvCAqImhkiyQKSo1ILmCcOl4WweEHWGqXy1dkMDq9VlkgXM3CPm3MWTxrIZ1LLluAMtViqa1ObX2EWtpInuSOEdQcHrJDbHAYB4D0obyGFqZ+4czLY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786803226; c=relaxed/simple; bh=bwNtkzjwmOZDOWNW+ZcR6qC8uu4XgAyDd3S6A7PfOtI=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=OEMAdHxNlcdsXCFZj+/1XPfTQ/uaROQlwJWPiinPEkjD440c8TN+kBN6AD1HVo2vLpm1jtdqM0LY8CT+b99KzdxL5TakNc9hACmyWy0VUv5NxrscfYUSQvdSzMuDquPSXAUoCi1C73O2syXOXnc9CZdJfNw5ACB4wxHp3Bd4S68= 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=RiSXPrcF; 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="RiSXPrcF" 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 83C52C366C; Sat, 15 Aug 2026 17:08:22 +0300 (EEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.mindbit.ro 83C52C366C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rendec.net; s=default; t=1786802903; bh=QbHMIsoCRlNfajLWOuMVJl4LohBIc8gg9TOwM7bibzs=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=RiSXPrcFeAWgwP1fYOAjdWvKw0HkZBirsJqLerREW/twRGajpLwUevBXg7pUgkXmf 6bKIKbLyOD9BDoH3KZ/bwCbBfqc3jtMX3bM1lJtSPKAIl9VAPchyVTPUY6JNaL4s7k lwa4x+CC+Ng5C9Mm523JTcW8WDndznvvkihpkzJej+1Hq7DioCV6Gkf8nLtmRh9dM+ nKnUiC1g/lbtU2DI/MiFIGTBtgsZ7R+6yPvSVYy0MlRjVDK7SDbvj3TpQCsMV15c6q VnIKZ+WjNT0J0H9nqVeUGaUFzmgWWdUQPGgszcgkuW0kEYGSMCRORba1fYbUvnLAyO 3sSLHkMXK4qAA== Message-ID: <0748a117106e6ae41ae5361ba053af3e96feed40.camel@rendec.net> 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:08:20 -0400 In-Reply-To: <20260805032139.35420-2-junan76@163.com> References: <20260805032139.35420-2-junan76@163.com> 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 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 -ETIMEDOUT; >=20 > So stm32mp_exti_set_type() asks for a 1 second timeout where the comment > 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 every > 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) th= e > =C2=A0 timeout is handled with busy-waiting delays, hence shall not excee= d > =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 ten > times before giving up, which is far longer than any plausible hold time > 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-stm= 32mp-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 Reviewed-by: Radu Rendec