[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZgK4I32LHbmqrhCN@pluto>
Date: Tue, 26 Mar 2024 11:57:23 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 3/5] firmware: arm_scmi: Add message dump traces for
bad and unexpected replies
On Tue, Mar 26, 2024 at 11:24:38AM +0000, Sudeep Holla wrote:
> On Mon, Mar 25, 2024 at 08:46:18PM +0000, Cristian Marussi wrote:
> > Trace also late-timed-out, out-of-order and unexpected/spurious messages.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@....com>
> > ---
> > drivers/firmware/arm_scmi/driver.c | 10 ++++++++++
> > drivers/firmware/arm_scmi/mailbox.c | 4 +++-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > index 7fc1c5b1a2a4..207ed1a52d69 100644
> > --- a/drivers/firmware/arm_scmi/driver.c
> > +++ b/drivers/firmware/arm_scmi/driver.c
> > @@ -861,6 +861,9 @@ scmi_xfer_command_acquire(struct scmi_chan_info *cinfo, u32 msg_hdr)
> > "Message for %d type %d is not expected!\n",
> > xfer_id, msg_type);
> > spin_unlock_irqrestore(&minfo->xfer_lock, flags);
> > +
> > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_UNEXPECTED);
> > +
> > return xfer;
> > }
> > refcount_inc(&xfer->users);
> > @@ -885,6 +888,9 @@ scmi_xfer_command_acquire(struct scmi_chan_info *cinfo, u32 msg_hdr)
> > dev_err(cinfo->dev,
> > "Invalid message type:%d for %d - HDR:0x%X state:%d\n",
> > msg_type, xfer_id, msg_hdr, xfer->state);
> > +
> > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_INVALID);
> > +
> > /* On error the refcount incremented above has to be dropped */
> > __scmi_xfer_put(minfo, xfer);
> > xfer = ERR_PTR(-EINVAL);
> > @@ -921,6 +927,9 @@ static void scmi_handle_notification(struct scmi_chan_info *cinfo,
> > if (IS_ERR(xfer)) {
> > dev_err(dev, "failed to get free message slot (%ld)\n",
> > PTR_ERR(xfer));
> > +
> > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_NOMEM);
> > +
> > scmi_clear_channel(info, cinfo);
> > return;
> > }
> > @@ -1040,6 +1049,7 @@ void scmi_rx_callback(struct scmi_chan_info *cinfo, u32 msg_hdr, void *priv)
> > break;
> > default:
> > WARN_ONCE(1, "received unknown msg_type:%d\n", msg_type);
> > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_UNKNOWN);
> > break;
> > }
> > }
> > diff --git a/drivers/firmware/arm_scmi/mailbox.c b/drivers/firmware/arm_scmi/mailbox.c
> > index b8d470417e8f..fb0824af7180 100644
> > --- a/drivers/firmware/arm_scmi/mailbox.c
> > +++ b/drivers/firmware/arm_scmi/mailbox.c
> > @@ -56,7 +56,9 @@ static void rx_callback(struct mbox_client *cl, void *m)
> > */
> > if (cl->knows_txdone && !shmem_channel_free(smbox->shmem)) {
> > dev_warn(smbox->cinfo->dev, "Ignoring spurious A2P IRQ !\n");
> > - return;
> > + return scmi_bad_message_trace(smbox->cinfo,
> > + shmem_read_header(smbox->shmem),
> > + MSG_MBOX_SPURIOUS);
>
> From previous patch, IIUC scmi_bad_message_trace is a void func and doesn't
> return anything. Did you not get any build error/warning for this ?
>
No...I am building with W=1....but note that the caller itself here
rx_callback() is supposed to return a void...
..in V3 I may just split this into 2 lines and leave the return; alone on its
own line to avoid any confusion...
Thanks,
Cristian
Powered by blists - more mailing lists