From nobody Mon Jun 15 01:41:47 2026 Received: from mail.zeus03.de (zeus03.de [194.117.254.33]) (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 109A13A7F57 for ; Tue, 7 Apr 2026 10:17:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=194.117.254.33 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775557044; cv=none; b=VfHmcJB0jGt8t5dx8Dywao6l1Aqf+aKdpBzRRTAujNgj7ZHJhZu5q01NODW5HiWeY2ulkl2nN6yFOgeyJqaiDpPfyN08aKAxx8HrPw9UyUsFxTPhRJJU6SHf/k4NRHmyhpoOINjYgYl1xB5JRgVFpCooiFsOR0Ooizjq/6G7yD8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775557044; c=relaxed/simple; bh=WzMTSA4hOrD9ewg7rAEHEJVvmQbWLf0BpIxMrdbzANQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=h+46Xf2fCgww9y6JUXVDRHNr0LmEC23CssuIFrrfyArUdr9jf43ZPC4WbNNG2ufOeZgA1E0b7tEZbOExr6Sna5+kErU6pXaBa4nemG7UTvk6ubFJFEtkgkchaqrXHvTjhR3RxdI4/6H4I3XPGKGMuCF6USc4kosLLqmWX0qB3L8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sang-engineering.com; spf=pass smtp.mailfrom=sang-engineering.com; dkim=pass (2048-bit key) header.d=sang-engineering.com header.i=@sang-engineering.com header.b=Y4wLqoo9; arc=none smtp.client-ip=194.117.254.33 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sang-engineering.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sang-engineering.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sang-engineering.com header.i=@sang-engineering.com header.b="Y4wLqoo9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= sang-engineering.com; h=from:to:cc:subject:date:message-id :mime-version:content-transfer-encoding; s=k1; bh=OGq+odBcPRpZvx ss1wi9faG05mqpWlKOElOyjMSQX6U=; b=Y4wLqoo90qoPyqK4le3/AMXzO9ykbt jvAeDwN2AIQ0gXl3cIezGHUBWkrilbb4iSwnjFngehnIycyGSP3Mki5Yeze4ZB50 Nt5pBTY2THD7Q7eRk3jM8QFX6IrgdsXSaW/ElOIuPDFFAqmm37ewBVoeOFIqC90T 4pCLpraVNbn+AULLr8nh+T7kB9ffGuUje/Z6/WDGWbwL/6AXFVE6Vb1Fu6famUTA 0VdQmk9UARtgbo3gg2f8gcpFDdsWlrNF25KXeS1YG+JI2aliQEe/3U/WfpvS9oa3 /gdNVjlSVWNF/tTPJM80uU4wnaKdnKP4FBad4kFCAsAPU8ZHdrKB5VXg== Received: (qmail 4189844 invoked from network); 7 Apr 2026 12:17:17 +0200 Received: by mail.zeus03.de with UTF8SMTPSA (TLS_AES_256_GCM_SHA384 encrypted, authenticated); 7 Apr 2026 12:17:17 +0200 X-UD-Smtp-Session: l3s3148p1@pmh0FtxOhroujns2 From: Wolfram Sang To: linux-renesas-soc@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Wolfram Sang , Jassi Brar , Mark Brown Subject: [RFC PATCH] mailbox: don't free the channel if the startup callback failed Date: Tue, 7 Apr 2026 12:13:11 +0200 Message-ID: <20260407101714.39990-2-wsa+renesas@sang-engineering.com> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" If the optional startup callbacks fails, we need to clear some states. Currently, this is done by freeing the channel. This does, however, much more than needed which creates problems. One thing is calling the shutdown callback. This is totally not intuitive. No user expects that shutdown() is called when startup() fails. E.g. quite some mailbox users register the IRQ in startup() and free them in shutdown(). These drivers will get a WARN about freeing an already free IRQ. A second thing is that module_put is called. This should also not be done when startup() fails. It breaks the expected symmetry that request_channel() gets the module and only free_channel() puts it again. To solve these problems, do only the required cleanups manually when startup() fails and do not use free_channel() as a helper. Link: https://sashiko.dev/#/patchset/20260402112709.13002-1-wsa%2Brenesas%4= 0sang-engineering.com # second issue Fixes: 2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox") Signed-off-by: Wolfram Sang --- This patch is RFC because I am still somewhat new to the mailbox subsystem and might miss something. However, I think the Sashiko comment in the above Link-tag is correct. I could reproduce the WARN with the Renesas MFIS driver and injecting an error when obtaining the irq. Looking at other drivers, I see this problem as well. drivers/mailbox/mailbox.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c index a7a690acd90d..dcde4efa5be8 100644 --- a/drivers/mailbox/mailbox.c +++ b/drivers/mailbox/mailbox.c @@ -353,7 +353,11 @@ static int __mbox_bind_client(struct mbox_chan *chan, = struct mbox_client *cl) =20 if (ret) { dev_err(dev, "Unable to startup the chan (%d)\n", ret); - mbox_free_channel(chan); + scoped_guard(spinlock_irqsave, &chan->lock) { + chan->cl =3D NULL; + if (chan->txdone_method =3D=3D TXDONE_BY_ACK) + chan->txdone_method =3D TXDONE_BY_POLL; + } return ret; } } --=20 2.47.3