drivers/acpi/acpi_pcc.c | 78 ++++++++++++++++++++++++++++------------- drivers/mailbox/pcc.c | 12 ++++++- 2 files changed, 64 insertions(+), 26 deletions(-)
The goal is to allow clients to submit a message in both irq and polling
mode of the pcc mailbox. The ACPI specification does not require a
platform irq for pcc channels. Let's implement the case where it is not
available.
peek_data is mapped to pcc_mbox_error_check_and_clear, so that it
returns true if no error occurred while the platform processed last
message, and therefore clients can fetch response data provided by the
platform.
Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/
---
v2: Fix issues reported by the kernel test robot
- sparse: incorrect type in argument 2 (different address spaces)
- acpi_pcc.c:(.text+0x69): undefined reference to `__udivdi3'
drivers/acpi/acpi_pcc.c | 78 ++++++++++++++++++++++++++++-------------
drivers/mailbox/pcc.c | 12 ++++++-
2 files changed, 64 insertions(+), 26 deletions(-)
diff --git a/drivers/acpi/acpi_pcc.c b/drivers/acpi/acpi_pcc.c
index 97064e943768..37f94fa4c424 100644
--- a/drivers/acpi/acpi_pcc.c
+++ b/drivers/acpi/acpi_pcc.c
@@ -51,7 +51,6 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
{
struct pcc_data *data;
struct acpi_pcc_info *ctx = handler_context;
- struct pcc_mbox_chan *pcc_chan;
static acpi_status ret;
data = kzalloc(sizeof(*data), GFP_KERNEL);
@@ -59,7 +58,7 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
return AE_NO_MEMORY;
data->cl.rx_callback = pcc_rx_callback;
- data->cl.knows_txdone = true;
+ data->cl.knows_txdone = false;
data->ctx.length = ctx->length;
data->ctx.subspace_id = ctx->subspace_id;
data->ctx.internal_buffer = ctx->internal_buffer;
@@ -73,61 +72,90 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
goto err_free_data;
}
- pcc_chan = data->pcc_chan;
- if (!pcc_chan->mchan->mbox->txdone_irq) {
- pr_err("This channel-%d does not support interrupt.\n",
- ctx->subspace_id);
- ret = AE_SUPPORT;
- goto err_free_channel;
- }
-
*region_context = data;
return AE_OK;
-err_free_channel:
- pcc_mbox_free_channel(data->pcc_chan);
err_free_data:
kfree(data);
return ret;
}
+static acpi_status
+acpi_pcc_send_msg_polling(struct pcc_data *data)
+{
+ int ret;
+
+ ret = mbox_send_message(data->pcc_chan->mchan,
+ (__force void *)data->pcc_chan->shmem);
+ if (ret == -ETIME) {
+ pr_err("PCC command executed timeout!\n");
+ return AE_TIME;
+ }
+
+ if (ret < 0)
+ return AE_ERROR;
+
+ if (!mbox_client_peek_data(data->pcc_chan->mchan))
+ return AE_ERROR;
+
+ return AE_OK;
+}
+
+static acpi_status
+acpi_pcc_send_msg_irq(struct pcc_data *data)
+{
+ int ret;
+
+ ret = mbox_send_message(data->pcc_chan->mchan, NULL);
+ if (ret < 0)
+ return AE_ERROR;
+
+ ret = wait_for_completion_timeout(&data->done,
+ usecs_to_jiffies(data->cl.tx_tout * USEC_PER_MSEC));
+ if (ret == 0) {
+ pr_err("PCC command executed timeout!\n");
+ return AE_TIME;
+ }
+
+ mbox_chan_txdone(data->pcc_chan->mchan, ret);
+
+ return AE_OK;
+}
+
static acpi_status
acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr,
u32 bits, acpi_integer *value,
void *handler_context, void *region_context)
{
- int ret;
+ acpi_status ret;
struct pcc_data *data = region_context;
u64 usecs_lat;
+ bool use_polling = data->pcc_chan->mchan->mbox->txdone_poll;
reinit_completion(&data->done);
/* Write to Shared Memory */
memcpy_toio(data->pcc_chan->shmem, (void *)value, data->ctx.length);
- ret = mbox_send_message(data->pcc_chan->mchan, NULL);
- if (ret < 0)
- return AE_ERROR;
-
/*
* pcc_chan->latency is just a Nominal value. In reality the remote
* processor could be much slower to reply. So add an arbitrary
* amount of wait on top of Nominal.
*/
usecs_lat = PCC_CMD_WAIT_RETRIES_NUM * data->pcc_chan->latency;
- ret = wait_for_completion_timeout(&data->done,
- usecs_to_jiffies(usecs_lat));
- if (ret == 0) {
- pr_err("PCC command executed timeout!\n");
- return AE_TIME;
- }
- mbox_chan_txdone(data->pcc_chan->mchan, ret);
+ data->cl.tx_block = use_polling;
+ data->cl.tx_tout = div_u64(usecs_lat, USEC_PER_MSEC);
+
+ if (use_polling)
+ ret = acpi_pcc_send_msg_polling(data);
+ else
+ ret = acpi_pcc_send_msg_irq(data);
memcpy_fromio(value, data->pcc_chan->shmem, data->ctx.length);
- return AE_OK;
+ return ret;
}
void __init acpi_init_pcc(void)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 0a00719b2482..e4e744669f81 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -579,11 +579,17 @@ static void pcc_shutdown(struct mbox_chan *chan)
devm_free_irq(chan->mbox->dev, pchan->plat_irq, chan);
}
+static bool pcc_peek_data(struct mbox_chan *chan)
+{
+ return pcc_mbox_error_check_and_clear(chan->con_priv) == 0;
+}
+
static const struct mbox_chan_ops pcc_chan_ops = {
.send_data = pcc_send_data,
.startup = pcc_startup,
.shutdown = pcc_shutdown,
.last_tx_done = pcc_last_tx_done,
+ .peek_data = pcc_peek_data,
};
/**
@@ -877,8 +883,12 @@ static int pcc_mbox_probe(struct platform_device *pdev)
(unsigned long) pcct_tbl + sizeof(struct acpi_table_pcct));
acpi_pcct_tbl = (struct acpi_table_pcct *) pcct_tbl;
- if (acpi_pcct_tbl->flags & ACPI_PCCT_DOORBELL)
+ if (acpi_pcct_tbl->flags & ACPI_PCCT_DOORBELL) {
pcc_mbox_ctrl->txdone_irq = true;
+ } else {
+ pcc_mbox_ctrl->txdone_poll = true;
+ pcc_mbox_ctrl->txpoll_period = 1;
+ }
for (i = 0; i < count; i++) {
struct pcc_chan_info *pchan = chan_info + i;
base-commit: 8b690556d8fe074b4f9835075050fba3fb180e93
--
2.51.2On Wed, Nov 19, 2025 at 10:01:18AM +0100, Andrea Tomassetti wrote: > The goal is to allow clients to submit a message in both irq and polling > mode of the pcc mailbox. The ACPI specification does not require a > platform irq for pcc channels. Let's implement the case where it is not > available. > > peek_data is mapped to pcc_mbox_error_check_and_clear, so that it > returns true if no error occurred while the platform processed last > message, and therefore clients can fetch response data provided by the > platform. > > Tested-by: Thibault Cantori <thibault.cantori@sipearl.com> > Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com> > Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com> > Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com> > Reported-by: kernel test robot <lkp@intel.com> > Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/ > Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/ > Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/ > --- > v2: Fix issues reported by the kernel test robot > - sparse: incorrect type in argument 2 (different address spaces) > - acpi_pcc.c:(.text+0x69): undefined reference to `__udivdi3' > > drivers/acpi/acpi_pcc.c | 78 ++++++++++++++++++++++++++++------------- > drivers/mailbox/pcc.c | 12 ++++++- Please separate the changes to the PCC OpRegion handler and the PCC mailbox driver into individual patches. I’ve also done some cleanup work [1], which has been tested and resolves part of the polling vs. IRQ flag initialization issue. I’d appreciate it if you could rebase your changes on top of those updates to make the review process smoother and help us move forward more quickly. -- Regards, Sudeep [1] https://lore.kernel.org/all/20251016-pcc_mb_updates-v1-0-0fba69616f69@arm.com/
The goal is to allow clients to submit a message in both irq and polling
mode of the pcc mailbox. The ACPI specification does not require a
platform irq for pcc channels. Let's implement the case where it is not
available.
Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/
---
v3: Thank you very much for the feedback Sudeep! Here there are the changes
implemented in this latest version:
- separate the changes to the PCC OpRegion handler and the PCC mailbox
driver into individual patches
- rebased the changes on top of the ongoing cleanup work
v2: Fix issues reported by the kernel test robot
- sparse: incorrect type in argument 2 (different address spaces)
- acpi_pcc.c:(.text+0x69): undefined reference to `__udivdi3'
drivers/acpi/acpi_pcc.c | 78 ++++++++++++++++++++++++++++-------------
1 file changed, 53 insertions(+), 25 deletions(-)
diff --git a/drivers/acpi/acpi_pcc.c b/drivers/acpi/acpi_pcc.c
index 97064e943768..37f94fa4c424 100644
--- a/drivers/acpi/acpi_pcc.c
+++ b/drivers/acpi/acpi_pcc.c
@@ -51,7 +51,6 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
{
struct pcc_data *data;
struct acpi_pcc_info *ctx = handler_context;
- struct pcc_mbox_chan *pcc_chan;
static acpi_status ret;
data = kzalloc(sizeof(*data), GFP_KERNEL);
@@ -59,7 +58,7 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
return AE_NO_MEMORY;
data->cl.rx_callback = pcc_rx_callback;
- data->cl.knows_txdone = true;
+ data->cl.knows_txdone = false;
data->ctx.length = ctx->length;
data->ctx.subspace_id = ctx->subspace_id;
data->ctx.internal_buffer = ctx->internal_buffer;
@@ -73,61 +72,90 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
goto err_free_data;
}
- pcc_chan = data->pcc_chan;
- if (!pcc_chan->mchan->mbox->txdone_irq) {
- pr_err("This channel-%d does not support interrupt.\n",
- ctx->subspace_id);
- ret = AE_SUPPORT;
- goto err_free_channel;
- }
-
*region_context = data;
return AE_OK;
-err_free_channel:
- pcc_mbox_free_channel(data->pcc_chan);
err_free_data:
kfree(data);
return ret;
}
+static acpi_status
+acpi_pcc_send_msg_polling(struct pcc_data *data)
+{
+ int ret;
+
+ ret = mbox_send_message(data->pcc_chan->mchan,
+ (__force void *)data->pcc_chan->shmem);
+ if (ret == -ETIME) {
+ pr_err("PCC command executed timeout!\n");
+ return AE_TIME;
+ }
+
+ if (ret < 0)
+ return AE_ERROR;
+
+ if (!mbox_client_peek_data(data->pcc_chan->mchan))
+ return AE_ERROR;
+
+ return AE_OK;
+}
+
+static acpi_status
+acpi_pcc_send_msg_irq(struct pcc_data *data)
+{
+ int ret;
+
+ ret = mbox_send_message(data->pcc_chan->mchan, NULL);
+ if (ret < 0)
+ return AE_ERROR;
+
+ ret = wait_for_completion_timeout(&data->done,
+ usecs_to_jiffies(data->cl.tx_tout * USEC_PER_MSEC));
+ if (ret == 0) {
+ pr_err("PCC command executed timeout!\n");
+ return AE_TIME;
+ }
+
+ mbox_chan_txdone(data->pcc_chan->mchan, ret);
+
+ return AE_OK;
+}
+
static acpi_status
acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr,
u32 bits, acpi_integer *value,
void *handler_context, void *region_context)
{
- int ret;
+ acpi_status ret;
struct pcc_data *data = region_context;
u64 usecs_lat;
+ bool use_polling = data->pcc_chan->mchan->mbox->txdone_poll;
reinit_completion(&data->done);
/* Write to Shared Memory */
memcpy_toio(data->pcc_chan->shmem, (void *)value, data->ctx.length);
- ret = mbox_send_message(data->pcc_chan->mchan, NULL);
- if (ret < 0)
- return AE_ERROR;
-
/*
* pcc_chan->latency is just a Nominal value. In reality the remote
* processor could be much slower to reply. So add an arbitrary
* amount of wait on top of Nominal.
*/
usecs_lat = PCC_CMD_WAIT_RETRIES_NUM * data->pcc_chan->latency;
- ret = wait_for_completion_timeout(&data->done,
- usecs_to_jiffies(usecs_lat));
- if (ret == 0) {
- pr_err("PCC command executed timeout!\n");
- return AE_TIME;
- }
- mbox_chan_txdone(data->pcc_chan->mchan, ret);
+ data->cl.tx_block = use_polling;
+ data->cl.tx_tout = div_u64(usecs_lat, USEC_PER_MSEC);
+
+ if (use_polling)
+ ret = acpi_pcc_send_msg_polling(data);
+ else
+ ret = acpi_pcc_send_msg_irq(data);
memcpy_fromio(value, data->pcc_chan->shmem, data->ctx.length);
- return AE_OK;
+ return ret;
}
void __init acpi_init_pcc(void)
--
2.51.2On Tue, Dec 02, 2025 at 11:12:14AM +0100, Andrea Tomassetti wrote: > The goal is to allow clients to submit a message in both irq and polling > mode of the pcc mailbox. The ACPI specification does not require a > platform irq for pcc channels. Let's implement the case where it is not > available. > Just curious if you have a real use case for this polling mode on your platforms or ... > Tested-by: Thibault Cantori <thibault.cantori@sipearl.com> > Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com> > Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com> > Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com> > Reported-by: kernel test robot <lkp@intel.com> > Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/ > Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/ > Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/ You are just trying to fix these warnings. If it is latter, we don't have to add support for polling mode especially if it can't be tested on real platforms. -- Regards, Sudeep
On 25/12/03 10:28AM, Sudeep Holla wrote: > On Tue, Dec 02, 2025 at 11:12:14AM +0100, Andrea Tomassetti wrote: > > The goal is to allow clients to submit a message in both irq and polling > > mode of the pcc mailbox. The ACPI specification does not require a > > platform irq for pcc channels. Let's implement the case where it is not > > available. > > > > Just curious if you have a real use case for this polling mode on your > platforms or ... > > > Tested-by: Thibault Cantori <thibault.cantori@sipearl.com> > > Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com> > > Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com> > > Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com> > > Reported-by: kernel test robot <lkp@intel.com> > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/ > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/ > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/ > > You are just trying to fix these warnings. If it is latter, we don't have to > add support for polling mode especially if it can't be tested on real > platforms. > In our target product, we're still investigating if PCC-based SCMI communication will rely on interrupts or polling. When we started looking into it we realized that polling wasn't supported and that's why we decided to work on and send this patch. We thought it could have been beneficial to other members of the community and it brings the driver a bit closer to the ACPI specifications. We're using ARM Fast Models for prototyping and that's how we validated and tested this patch. Best regards, Andrea > -- > Regards, > Sudeep
On Thu, Dec 04, 2025 at 01:59:38PM +0100, Andrea Tomassetti wrote: > On 25/12/03 10:28AM, Sudeep Holla wrote: > > On Tue, Dec 02, 2025 at 11:12:14AM +0100, Andrea Tomassetti wrote: > > > The goal is to allow clients to submit a message in both irq and polling > > > mode of the pcc mailbox. The ACPI specification does not require a > > > platform irq for pcc channels. Let's implement the case where it is not > > > available. > > > > > > > Just curious if you have a real use case for this polling mode on your > > platforms or ... > > > > > Tested-by: Thibault Cantori <thibault.cantori@sipearl.com> > > > Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com> > > > Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com> > > > Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com> > > > Reported-by: kernel test robot <lkp@intel.com> > > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/ > > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/ > > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/ > > > > You are just trying to fix these warnings. If it is latter, we don't have to > > add support for polling mode especially if it can't be tested on real > > platforms. > > > In our target product, we're still investigating if PCC-based SCMI communication will > rely on interrupts or polling. When we started looking into it we realized that polling > wasn't supported and that's why we decided to work on and send this patch. We thought it > could have been beneficial to other members of the community and it brings the driver a > bit closer to the ACPI specifications. > > We're using ARM Fast Models for prototyping and that's how we validated and tested this patch. > I wouldn't consider that as real platform especially if it is not std. AEM models that are well maintained. Many Fast models are short lived and never maintained long term, so I don't want to push any feature based on that alone unless you have a real platform with missing or broken interrupt that needs this polling feature. It is burden for long term maintenance if there is no regular way to test this polling mode feature. -- Regards, Sudeep
On 25/12/04 01:14PM, Sudeep Holla wrote: > On Thu, Dec 04, 2025 at 01:59:38PM +0100, Andrea Tomassetti wrote: > > On 25/12/03 10:28AM, Sudeep Holla wrote: > > > On Tue, Dec 02, 2025 at 11:12:14AM +0100, Andrea Tomassetti wrote: > > > > The goal is to allow clients to submit a message in both irq and polling > > > > mode of the pcc mailbox. The ACPI specification does not require a > > > > platform irq for pcc channels. Let's implement the case where it is not > > > > available. > > > > > > > > > > Just curious if you have a real use case for this polling mode on your > > > platforms or ... > > > > > > > Tested-by: Thibault Cantori <thibault.cantori@sipearl.com> > > > > Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com> > > > > Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com> > > > > Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com> > > > > Reported-by: kernel test robot <lkp@intel.com> > > > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/ > > > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/ > > > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/ > > > > > > You are just trying to fix these warnings. If it is latter, we don't have to > > > add support for polling mode especially if it can't be tested on real > > > platforms. > > > > > In our target product, we're still investigating if PCC-based SCMI communication will > > rely on interrupts or polling. When we started looking into it we realized that polling > > wasn't supported and that's why we decided to work on and send this patch. We thought it > > could have been beneficial to other members of the community and it brings the driver a > > bit closer to the ACPI specifications. > > > > We're using ARM Fast Models for prototyping and that's how we validated and tested this patch. > > > > I wouldn't consider that as real platform especially if it is not std. AEM > models that are well maintained. Many Fast models are short lived and never > maintained long term, so I don't want to push any feature based on that alone > unless you have a real platform with missing or broken interrupt that needs > this polling feature. > > It is burden for long term maintenance if there is no regular way to test this > polling mode feature. > Fair, I totally get your point. Thank you very much for your time. Regards, Andrea > -- > Regards, > Sudeep
On Tue, Dec 09, 2025 at 10:39:53AM +0000, Andrea Tomassetti wrote: > On 25/12/04 01:14PM, Sudeep Holla wrote: > > > > I wouldn't consider that as real platform especially if it is not std. AEM > > models that are well maintained. Many Fast models are short lived and never > > maintained long term, so I don't want to push any feature based on that alone > > unless you have a real platform with missing or broken interrupt that needs > > this polling feature. > > > > It is burden for long term maintenance if there is no regular way to test this > > polling mode feature. > > > Fair, I totally get your point. Thank you very much for your time. > Thanks for understanding. We can always revisit this if this becomes a requirement on a real platform in the future. I am not against that just FYI. -- Regards, Sudeep
peek_data is mapped to pcc_mbox_error_check_and_clear, so that it
returns true if no error occurred while the platform processed last
message, and therefore clients can fetch response data provided by the
platform.
Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
---
drivers/mailbox/pcc.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 418007020439..ccd50b33409b 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -502,11 +502,17 @@ static void pcc_shutdown(struct mbox_chan *chan)
devm_free_irq(chan->mbox->dev, pchan->plat_irq, chan);
}
+static bool pcc_peek_data(struct mbox_chan *chan)
+{
+ return pcc_mbox_error_check_and_clear(chan->con_priv) == 0;
+}
+
static const struct mbox_chan_ops pcc_chan_ops = {
.send_data = pcc_send_data,
.startup = pcc_startup,
.shutdown = pcc_shutdown,
.last_tx_done = pcc_last_tx_done,
+ .peek_data = pcc_peek_data,
};
/**
--
2.51.2© 2016 - 2026 Red Hat, Inc.