From: Sudeep Holla <sudeep.holla@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>,
linux-acpi@vger.kernel.org,
Sudeep Holla <sudeep.holla@kernel.org>,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
stable@vger.kernel.org,
Michael van der Westhuizen <rmikey@meta.com>
Subject: Re: [PATCH] mailbox: pcc: Complete the transfer when the platform flags an error
Date: Tue, 27 Oct 2026 16:47:39 +0000 [thread overview]
Message-ID: <20261027-impartial-nano-sheep-5ccf53@sudeepholla> (raw)
In-Reply-To: <20261027-pcc_error_txdone-v1-1-2f8cfbb36d90@debian.org>
On Tue, Oct 27, 2026 at 08:19:14AM -0700, Breno Leitao wrote:
> A single error reported by the platform stops all later traffic on a
> PCC channel whose client relies on the controller to complete
> transfers, such as the SCMI PCC transport. Every later request on the
> channel times out.
>
> When the platform completes a command and sets a bit in the Error
> Status register, pcc_mbox_irq() acks the platform interrupt, clears the
> error and returns IRQ_NONE without calling mbox_chan_txdone().
>
> No other interrupt arrives for that transfer, so the mailbox core keeps
> it as the active request and holds back every later message.
>
> The chan_in_use flag also stays set, so on a shared interrupt line the
> next interrupt raised for another subspace passes the checks in
> pcc_mbox_irq(), since Command Complete is still set, and runs the
> success path on the failed transfer.
>
> Log the error and complete the transfer with -EIO instead, clearing
> chan_in_use first as the success path does. Skip
> mbox_chan_received_data(), as the shared memory holds no valid response.
> Use -EIO rather than the helper's return value, which is a positive
> acpi_status when the register read fails.
>
> Clients that wait for the rx callback still time out on the failed
> transfer, but the channel works again afterwards.
>
Nice, finally good to see this driver and various error paths being tested
on real platforms. Thanks for finding the issues and the fix.
> Fixes: 9c753f7c953c ("mailbox: pcc: Mark Tx as complete in PCC IRQ handler")
> Cc: stable@vger.kernel.org
> Suggested-by: Michael van der Westhuizen <rmikey@meta.com>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> drivers/mailbox/pcc.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 14dc4a187bfc67..e5df604b367a4a 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -315,6 +315,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> {
> struct pcc_chan_info *pchan;
> struct mbox_chan *chan = p;
> + int ret;
>
> pchan = chan->con_priv;
>
> @@ -333,8 +334,20 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> if (!pcc_mbox_cmd_complete_check(pchan))
> return IRQ_NONE;
>
> - if (pcc_mbox_error_check_and_clear(pchan))
> - return IRQ_NONE;
> + ret = pcc_mbox_error_check_and_clear(pchan);
> + if (ret) {
> + /*
> + * No other interrupt arrives for this transfer, so complete
> + * it here or the channel stalls. Skip the rx callback, as the
> + * shared memory holds no valid response.
> + */
> + dev_err_ratelimited(chan->mbox->dev,
> + "PCC subspace %td: transfer error %d\n",
> + pchan - chan_info, ret);
> + WRITE_ONCE(pchan->chan_in_use, false);
> + mbox_chan_txdone(chan, -EIO);
> + return IRQ_HANDLED;
Since we are returning IRQ_HANDLED, can we merge this path with the code
below ?
if (ret)
dev_err_...
..
if(!ret)
mbox_chan_received_data();
That should work right ? The reason I prefer this way is the comment for
WRITE_ONCE() applies above as well. Instead we can reuse the path. Let me
know what you think.
--
Regards,
Sudeep
next prev parent reply other threads:[~2026-10-27 16:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 15:19 [PATCH] mailbox: pcc: Complete the transfer when the platform flags an error Breno Leitao
2026-10-27 16:47 ` Sudeep Holla [this message]
2026-10-28 13:11 ` Breno Leitao
2026-10-28 13:19 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261027-impartial-nano-sheep-5ccf53@sudeepholla \
--to=sudeep.holla@kernel.org \
--cc=jassisinghbrar@gmail.com \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rmikey@meta.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.