[PATCH v2] mailbox: qcom-cpucp: read mbox hardware register using readq()

Sivansh Gupta posted 1 patch 1 week, 2 days ago
drivers/mailbox/qcom-cpucp-mbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH v2] mailbox: qcom-cpucp: read mbox hardware register using readq()
Posted by Sivansh Gupta 1 week, 2 days ago
Mailbox hardware registers are 64 bit wide, but the interrupt handler
currently reads only 32 bits with readl() at 0x4 offset (upper 32
bits). This does not return the correct value expected by PDP log
driver. Reading the register with readq() at the base address
returns the correct value expected.

Use readq() to access the 64-bit register and pass the correct value
to the mailbox client.

Fixes: 0e2a9a03106c ("mailbox: Add support for QTI CPUCP mailbox controller")
Signed-off-by: Sivansh Gupta <sivansh.gupta@oss.qualcomm.com>
---
v2:
- Expanded the commit message to explain why this change is required.
 drivers/mailbox/qcom-cpucp-mbox.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mailbox/qcom-cpucp-mbox.c b/drivers/mailbox/qcom-cpucp-mbox.c
index 7ffc40acea9b..f56a05149281 100644
--- a/drivers/mailbox/qcom-cpucp-mbox.c
+++ b/drivers/mailbox/qcom-cpucp-mbox.c
@@ -61,7 +61,7 @@ static irqreturn_t qcom_cpucp_mbox_irq_fn(int irq, void *data)
 	status = readq(cpucp->rx_base + APSS_CPUCP_RX_MBOX_STAT);
 
 	for_each_set_bit(i, (unsigned long *)&status, cpucp->mbox.num_chans) {
-		u32 val = readl(cpucp->rx_base + APSS_CPUCP_RX_MBOX_CMD(i) + APSS_CPUCP_MBOX_CMD_OFF);
+		u64 val = readq(cpucp->rx_base + APSS_CPUCP_RX_MBOX_CMD(i));
 		struct mbox_chan *chan = &cpucp->chans[i];
 		unsigned long flags;
 
-- 
2.43.0
Re: [PATCH v2] mailbox: qcom-cpucp: read mbox hardware register using readq()
Posted by Konrad Dybcio 1 week ago
On 9/15/26 11:39 AM, Sivansh Gupta wrote:
> Mailbox hardware registers are 64 bit wide, but the interrupt handler
> currently reads only 32 bits with readl() at 0x4 offset (upper 32
> bits). This does not return the correct value expected by PDP log
> driver. Reading the register with readq() at the base address
> returns the correct value expected.

This is a valid reason, but that driver doesn't exist upstream..

If you believe it'd be beneficial, please upstream it. For now,
please focus the reasoning on the actual data being lost, not on
some out-of-tree driver having issues with that

Konrad