From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D302B3B583B for ; Tue, 7 Apr 2026 12:59:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775566782; cv=none; b=pv/vFnRDXnCrze3qnlwRKG6Sous5RlMJbhOB8NWRMrbAGFgXa0Xvr5OHzTJGFOvqh8vcLK8H7ACuAa90h/ELncepPI58J68pJAndpydK1eGw6yc/Km8tYgfc8y8Dz+7Fqit7Z5bX27jr8sugr5Txa0ZIbeeFJ8Ix0gwC4Qxf9Q8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775566782; c=relaxed/simple; bh=bOa02NyvW+eDw/e01zbZDNtwtQjDUSw9mOJereqrVDA=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Qve0LYGRiD5jc43yFviZRZFtkAY7TJAFPIMtrgyPsCWiFmJEzej9TgeUgdeQhI+AmN08Urf2IXZgKWaI4VoMV7T2DeTea28H6ffO7MA8IegI4ap9IxPMRmW8+awuwI5tVOA5bXpIck1QpbU1V05FPP8mSTiVxYcp5Zxgwk5CrjI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b=zjko2HmF; arc=none smtp.client-ip=209.85.218.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b="zjko2HmF" Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-b9c6680aaf8so562859666b.3 for ; Tue, 07 Apr 2026 05:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1775566778; x=1776171578; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:organization :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=bOa02NyvW+eDw/e01zbZDNtwtQjDUSw9mOJereqrVDA=; b=zjko2HmF091nOPJZMuByuRjTk9MnN5hFRkAoQW7Mix/Tk59Lu54EtB6CTi4SXCmdzE +7IEH3oiNSiG3vBrFlq44GTn3PxDtBZW4h/zP9RhfbtMIg6X2yN2aqHcJ/cuAUXDQbNT wLOAUOxSsImIYVWbqvP/Cx5laHwP55NYCLEvbwFBAKHMsqy8gEnvEvA3IvgnpUyeRUbh 4QK9cw5OEARSpcXS6lv4675+QtFQl1FgmgLvtU4UWex3q/q/n+SWjXHnYH10XmPCzdaJ g2i+mYZ9wRAGitjRbjdC6w08paoiGJoaNYOpBCq+DzVXoyRzL0CblRUbiC0P9yCx7Oer QyRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775566778; x=1776171578; h=mime-version:user-agent:content-transfer-encoding:organization :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bOa02NyvW+eDw/e01zbZDNtwtQjDUSw9mOJereqrVDA=; b=J9grvDaAHo3MRCZ5KsXPsJVre8jOw2GMJE9hQXucul8K3JVXXtIyzzuFK8b+0UUEv1 DqFbc4J7QU9nkToGz+bPyBBLq9KoV1yj7e8ilyIb7108ZyNQMoswUwHEVPPnr7vunNoa WqpeZ0SCWbdGb6KOFyvTAFF3ssGx6eTZKbpY2uCj5fkeI3I+KhnC/01R/YCsRnwVXt9n kcko7xU0qMkblk8DtNwS4ZK+AgsKobhd9y238p6hD7S3g7IHjISxlcwHRfTnsN0kd4BF yPGBluxZlRvRW+s34OLNaPKpW0okio6khV9Yj8mzcORzsDShrKgp96bsHk/elQDlPWyA C/8g== X-Forwarded-Encrypted: i=1; AJvYcCUx7sII8R/O38DJd3mnsjbKbo7zzRimtfO4uawdISvUT3eWmSr1bP+wTs6627Dn1XVuyLTp4r/K0YoNxUs=@vger.kernel.org X-Gm-Message-State: AOJu0YwgqQNX/REzcJrI2jiplEQXldNLSO4i4dej3MEKHW/Ws1dRDdgb Y3qHuRzk7TvnojIbVoFeTLjLecxvWUZ2AibaD4W23Ald/ZIYBa2HVY6zoIMpZ0lPDms= X-Gm-Gg: AeBDiesrTRy6wsJ7c2XXHvquRmjLA5ng+7AwWE9ieAdgaAxohqlaBYTEhmGWXoW/ost L6e/D7nj38xTYdl/4ziwQbZooC9C+RWrpay/BM41bl9pNj3mznGQEY9aGBKuX14U8NA1LazLCO7 000tXFNGqJ+CfgL5acKqFMhkki0Yn97BHdD7MJ2KJlpvBggMLFrETvr7UwTXOnMmPwq/durTBk7 +rDWe42dFw2iRUCwlNF99MdiLlvLjSTj0JamZaG5lrgFj1nV5qqUGXeH+UN3bDTLfvZijO9u9Dz ETmGEpog+usTQxkK/YIjQ1G/IkK+0T3jqF/tm4OlJCIBSZGyHvjE8e+zNybvmJOb5lw4Es8MqXz gv8u3RA0BJiJ0eNrDz1z75zk1dkVMhqR0j8G1Kba3uyBlNFC0tgrkJOjqADv6KjEg3iabb3Vx82 HVgeWMJ/9f9uZz7PHVRMeeWUjQJRr/3/YGcxvN06jirqt+PJ47ur3HdRo64yYmcnBWEQX9dSxh X-Received: by 2002:a17:907:960f:b0:b9b:38d4:2cea with SMTP id a640c23a62f3a-b9c676c8812mr795767766b.23.1775566777932; Tue, 07 Apr 2026 05:59:37 -0700 (PDT) Received: from [10.87.54.48] (mob-176-247-39-197.net.vodafone.it. [176.247.39.197]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b9c3c97219dsm548568966b.5.2026.04.07.05.59.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2026 05:59:37 -0700 (PDT) Message-ID: <80c917d828932a225e0a1a9fffb77d55d27241cb.camel@baylibre.com> Subject: Re: [PATCH] pinctrl: mcp23s08: Disable all pin interrupts during probe From: Francesco Lavra To: Mike Looijmans , Linus Walleij , Maksim Kiselev , Sander Vanheule , Andy Shevchenko , Dmitry Mastykin , Evgenii Shatokhin , Arturas Moskvinas , Uwe =?ISO-8859-1?Q?Kleine-K=F6nig?= , Andreas Kaessens , Radim Pavlik , Thomas Preston Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 07 Apr 2026 14:59:36 +0200 In-Reply-To: References: <20260330161914.1071118-1-flavra@baylibre.com> Organization: BayLibre Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-04-07 at 12:17 +0200, Mike Looijmans wrote: > On 07-04-2026 08:58, Linus Walleij wrote: > > On Mon, Mar 30, 2026 at 6:19=E2=80=AFPM Francesco Lavra > > wrote: > >=20 > > > A chip being probed may have the interrupt-on-change feature enabled > > > on > > > some of its pins, for example after a reboot. This can cause the chip > > > to > > > generate interrupts for pins that don't have a registered nested > > > handler, > > > which leads to a kernel crash such as below: > > >=20 > > > [=C2=A0=C2=A0=C2=A0 7.928897] Unable to handle kernel read from unrea= dable memory at > > > virtual address 00000000000000ac > > > [=C2=A0=C2=A0=C2=A0 7.932314] Mem abort info: > > > [=C2=A0=C2=A0=C2=A0 7.935081]=C2=A0=C2=A0 ESR =3D 0x0000000096000004 > > > [=C2=A0=C2=A0=C2=A0 7.938808]=C2=A0=C2=A0 EC =3D 0x25: DABT (current = EL), IL =3D 32 bits > > > [=C2=A0=C2=A0=C2=A0 7.944094]=C2=A0=C2=A0 SET =3D 0, FnV =3D 0 > > > [=C2=A0=C2=A0=C2=A0 7.947127]=C2=A0=C2=A0 EA =3D 0, S1PTW =3D 0 > > > [=C2=A0=C2=A0=C2=A0 7.950247]=C2=A0=C2=A0 FSC =3D 0x04: level 0 trans= lation fault > > > [=C2=A0=C2=A0=C2=A0 7.955101] Data abort info: > > > [=C2=A0=C2=A0=C2=A0 7.957961]=C2=A0=C2=A0 ISV =3D 0, ISS =3D 0x000000= 04, ISS2 =3D 0x00000000 > > > [=C2=A0=C2=A0=C2=A0 7.963421]=C2=A0=C2=A0 CM =3D 0, WnR =3D 0, TnD = =3D 0, TagAccess =3D 0 > > > [=C2=A0=C2=A0=C2=A0 7.968447]=C2=A0=C2=A0 GCS =3D 0, Overlay =3D 0, D= irtyBit =3D 0, Xs =3D 0 > > > [=C2=A0=C2=A0=C2=A0 7.973734] user pgtable: 4k pages, 48-bit VAs, > > > pgdp=3D00000000089b7000 > > > [=C2=A0=C2=A0=C2=A0 7.980148] [00000000000000ac] pgd=3D00000000000000= 00, > > > p4d=3D0000000000000000 > > > [=C2=A0=C2=A0=C2=A0 7.986913] Internal error: Oops: 0000000096000004 = [#1]=C2=A0 SMP > > > [=C2=A0=C2=A0=C2=A0 7.992545] Modules linked in: > > > [=C2=A0=C2=A0=C2=A0 8.073678] CPU: 0 UID: 0 PID: 81 Comm: irq/18-4-00= 25 Not tainted > > > 7.0.0-rc6-gd2b5a1f931c8-dirty #199 > > > [=C2=A0=C2=A0=C2=A0 8.073689] Hardware name: Khadas VIM3 (DT) > > > [=C2=A0=C2=A0=C2=A0 8.073692] pstate: 604000c5 (nZCv daIF +PAN -UAO -= TCO -DIT -SSBS > > > BTYPE=3D--) > > > [=C2=A0=C2=A0=C2=A0 8.094639] pc : _raw_spin_lock_irq+0x40/0x80 > > > [=C2=A0=C2=A0=C2=A0 8.098970] lr : handle_nested_irq+0x2c/0x168 > > > [=C2=A0=C2=A0=C2=A0 8.098979] sp : ffff800082b2bd20 > > > [=C2=A0=C2=A0=C2=A0 8.106599] x29: ffff800082b2bd20 x28: ffff80008010= 7920 x27: > > > ffff800080104d88 > > > [=C2=A0=C2=A0=C2=A0 8.106611] x26: ffff000003298080 x25: 000000000000= 0001 x24: > > > 000000000000ff00 > > > [=C2=A0=C2=A0=C2=A0 8.113707] x23: 0000000000000001 x22: 000000000000= 0000 x21: > > > 000000000000000e > > > [=C2=A0=C2=A0=C2=A0 8.120850] x20: 0000000000000000 x19: 000000000000= 00ac x18: > > > 0000000000000000 > > > [=C2=A0=C2=A0=C2=A0 8.135046] x17: 0000000000000000 x16: 000000000000= 0000 x15: > > > 0000000000000000 > > > [=C2=A0=C2=A0=C2=A0 8.135062] x14: ffff800081567ea8 x13: ffffffffffff= ffff x12: > > > 0000000000000000 > > > [=C2=A0=C2=A0=C2=A0 8.135070] x11: 00000000000000c0 x10: 000000000000= 0b60 x9 : > > > ffff800080109e0c > > > [=C2=A0=C2=A0=C2=A0 8.135078] x8 : 1fffe0000069dbc1 x7 : 000000000000= 0001 x6 : > > > ffff0000034ede00 > > > [=C2=A0=C2=A0=C2=A0 8.135086] x5 : 0000000000000000 x4 : ffff0000034e= de08 x3 : > > > 0000000000000001 > > > [=C2=A0=C2=A0=C2=A0 8.163460] x2 : 0000000000000000 x1 : 000000000000= 0001 x0 : > > > 00000000000000ac > > > [=C2=A0=C2=A0=C2=A0 8.170560] Call trace: > > > [=C2=A0=C2=A0=C2=A0 8.180094]=C2=A0 _raw_spin_lock_irq+0x40/0x80 (P) > > > [=C2=A0=C2=A0=C2=A0 8.184443]=C2=A0 mcp23s08_irq+0x248/0x358 > > > [=C2=A0=C2=A0=C2=A0 8.184462]=C2=A0 irq_thread_fn+0x34/0xb8 > > > [=C2=A0=C2=A0=C2=A0 8.184470]=C2=A0 irq_thread+0x1a4/0x310 > > > [=C2=A0=C2=A0=C2=A0 8.195093]=C2=A0 kthread+0x13c/0x150 > > > [=C2=A0=C2=A0=C2=A0 8.198309]=C2=A0 ret_from_fork+0x10/0x20 > > > [=C2=A0=C2=A0=C2=A0 8.201850] Code: d65f03c0 d2800002 52800023 f98000= 11 (885ffc01) > > > [=C2=A0=C2=A0=C2=A0 8.207931] ---[ end trace 0000000000000000 ]--- > > >=20 > > > This issue has always been present, but has been latent until commit > > > "f9f4fda15e72" ("pinctrl: mcp23s08: init reg_defaults from HW at > > > probe and > > > switch cache type"), which correctly removed reg_defaults from the > > > regmap > > > and as a side effect changed the behavior of the interrupt handler so > > > that > > > the real value of the MCP_GPINTEN register is now being read from the > > > chip > > > instead of using a bogus 0 default value; a non-zero value for this > > > register can trigger the invocation of a nested handler which may not > > > exist > > > (yet). > > > Fix this issue by disabling all pin interrupts during initialization. > > >=20 > > > Fixes: "f9f4fda15e72" ("pinctrl: mcp23s08: init reg_defaults from HW > > > at probe and switch cache type") > > > Signed-off-by: Francesco Lavra > > Patch applied for fixes since it's pretty urgent, and it also looks > > right to me. > >=20 > > However added some people using this to the CC so they > > get a chance to react before it goes upstream. > Looks okay to me too. >=20 > Maybe it'd be better to unconditionally write "0" to this register? No= =20 > need to exercise the interrupt logic and pins when no-one is listening... Not sure I understand, unconditionally writing "0" to this register is exactly what this patch does. > I was going to say "if the device doesn't have a reset GPIO", but=20 > looking at the code, the reset GPIO is never asserted by this driver. Right. In any case, the reset GPIO is optional, so we would still need to initialize the register manually if there is no reset GPIO.