From: sashiko-bot@kernel.org
To: tze.yee.ng@altera.com
Cc: imx@lists.linux.dev, Frank.Li@kernel.org, linux-i3c@lists.infradead.org
Subject: Re: [PATCH v4 2/3] i3c: master: dw: Map CCC hardware errors to I3C M0/M2
Date: Tue, 30 Jun 2026 13:32:38 +0000 [thread overview]
Message-ID: <20260630133239.42C2F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <56a59c5ac9a09692f9ac8a74d1d3afdce553a7d1.1782824628.git.tze.yee.ng@altera.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Undocumented behavioral change and silent bug fix
--
commit 5afd5fbee8dc926110284bae98310b5970134131
Author: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
i3c: master: dw: Map CCC hardware errors to I3C M0/M2
This commit updates the DesignWare I3C master driver to map specific
response queue errors to standard I3C error codes M0 and M2. It also returns
-EIO for address NACKs and introduces dw_i3c_ccc_map_err() to centralize
error mapping.
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index e659ede79fc03..27d2025fcf041 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
[ ... ]
> @@ -743,10 +760,7 @@ static int dw_i3c_ccc_set(struct dw_i3c_master *master,
>
> ret = xfer->ret;
> cmd = &xfer->cmds[0];
> - if (!ret)
> - ccc->dests[0].payload.actual_len = cmd->rx_len;
> - if (cmd->error == RESPONSE_ERROR_IBA_NACK)
> - ccc->err = I3C_ERROR_M2;
> + ccc->err = dw_i3c_ccc_map_err(cmd->error);
[Severity: Medium]
Is this an unrelated bug fix? The commit message mentions mapping hardware
errors to I3C M0/M2, but it does not mention removing the assignment of
actual_len from the transmit operation here.
>
> return ret;
> }
[ ... ]
> @@ -783,8 +799,10 @@ static int dw_i3c_ccc_get(struct dw_i3c_master *master, struct i3c_ccc_cmd *ccc)
> dw_i3c_master_dequeue_xfer(master, xfer);
>
> ret = xfer->ret;
> - if (xfer->cmds[0].error == RESPONSE_ERROR_IBA_NACK)
> - ccc->err = I3C_ERROR_M2;
> + cmd = &xfer->cmds[0];
> + ccc->err = dw_i3c_ccc_map_err(cmd->error);
> + if (!ret)
> + ccc->dests[0].payload.actual_len = cmd->rx_len;
[Severity: Medium]
Does this silently add the actual_len assignment to the receive operation?
Since moving this assignment from dw_i3c_ccc_set() to dw_i3c_ccc_get() is
not documented in the commit message, should it be split into a separate
fix or explicitly explained?
>
> return ret;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782824628.git.tze.yee.ng@altera.com?part=2
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: tze.yee.ng@altera.com
Cc: imx@lists.linux.dev, Frank.Li@kernel.org, linux-i3c@lists.infradead.org
Subject: Re: [PATCH v4 2/3] i3c: master: dw: Map CCC hardware errors to I3C M0/M2
Date: Tue, 30 Jun 2026 13:32:38 +0000 [thread overview]
Message-ID: <20260630133239.42C2F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <56a59c5ac9a09692f9ac8a74d1d3afdce553a7d1.1782824628.git.tze.yee.ng@altera.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Undocumented behavioral change and silent bug fix
--
commit 5afd5fbee8dc926110284bae98310b5970134131
Author: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
i3c: master: dw: Map CCC hardware errors to I3C M0/M2
This commit updates the DesignWare I3C master driver to map specific
response queue errors to standard I3C error codes M0 and M2. It also returns
-EIO for address NACKs and introduces dw_i3c_ccc_map_err() to centralize
error mapping.
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index e659ede79fc03..27d2025fcf041 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
[ ... ]
> @@ -743,10 +760,7 @@ static int dw_i3c_ccc_set(struct dw_i3c_master *master,
>
> ret = xfer->ret;
> cmd = &xfer->cmds[0];
> - if (!ret)
> - ccc->dests[0].payload.actual_len = cmd->rx_len;
> - if (cmd->error == RESPONSE_ERROR_IBA_NACK)
> - ccc->err = I3C_ERROR_M2;
> + ccc->err = dw_i3c_ccc_map_err(cmd->error);
[Severity: Medium]
Is this an unrelated bug fix? The commit message mentions mapping hardware
errors to I3C M0/M2, but it does not mention removing the assignment of
actual_len from the transmit operation here.
>
> return ret;
> }
[ ... ]
> @@ -783,8 +799,10 @@ static int dw_i3c_ccc_get(struct dw_i3c_master *master, struct i3c_ccc_cmd *ccc)
> dw_i3c_master_dequeue_xfer(master, xfer);
>
> ret = xfer->ret;
> - if (xfer->cmds[0].error == RESPONSE_ERROR_IBA_NACK)
> - ccc->err = I3C_ERROR_M2;
> + cmd = &xfer->cmds[0];
> + ccc->err = dw_i3c_ccc_map_err(cmd->error);
> + if (!ret)
> + ccc->dests[0].payload.actual_len = cmd->rx_len;
[Severity: Medium]
Does this silently add the actual_len assignment to the receive operation?
Since moving this assignment from dw_i3c_ccc_set() to dw_i3c_ccc_get() is
not documented in the commit message, should it be split into a separate
fix or explicitly explained?
>
> return ret;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782824628.git.tze.yee.ng@altera.com?part=2
next prev parent reply other threads:[~2026-06-30 13:32 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 13:20 [PATCH v4 0/3] i3c: Improve CCC reliability for DesignWare master tze.yee.ng
2026-06-30 13:20 ` tze.yee.ng
2026-06-30 13:20 ` [PATCH v4 1/3] i3c: master: dw: Report actual GET CCC payload length on success tze.yee.ng
2026-06-30 13:20 ` tze.yee.ng
2026-06-30 13:31 ` sashiko-bot
2026-06-30 13:31 ` sashiko-bot
2026-06-30 17:03 ` Frank Li
2026-06-30 17:03 ` Frank Li
2026-07-01 2:46 ` NG, TZE YEE
2026-07-01 2:46 ` NG, TZE YEE
2026-07-01 10:37 ` Alexandre Mergnat
2026-07-01 10:37 ` Alexandre Mergnat
2026-07-03 9:09 ` NG, TZE YEE
2026-07-03 9:09 ` NG, TZE YEE
2026-06-30 13:20 ` [PATCH v4 2/3] i3c: master: dw: Map CCC hardware errors to I3C M0/M2 tze.yee.ng
2026-06-30 13:20 ` tze.yee.ng
2026-06-30 13:32 ` sashiko-bot [this message]
2026-06-30 13:32 ` sashiko-bot
2026-06-30 17:06 ` Frank Li
2026-06-30 17:06 ` Frank Li
2026-07-01 2:45 ` NG, TZE YEE
2026-07-01 2:45 ` NG, TZE YEE
2026-07-01 10:37 ` Alexandre Mergnat
2026-07-01 10:37 ` Alexandre Mergnat
2026-06-30 13:20 ` [PATCH v4 3/3] i3c: master: Validate GET CCC payload length and retry Direct GET once tze.yee.ng
2026-06-30 13:20 ` tze.yee.ng
2026-06-30 13:41 ` sashiko-bot
2026-06-30 13:41 ` sashiko-bot
2026-06-30 18:48 ` Frank Li
2026-06-30 18:48 ` Frank Li
2026-07-03 8:58 ` NG, TZE YEE
2026-07-03 8:58 ` NG, TZE YEE
2026-07-01 10:37 ` Alexandre Mergnat
2026-07-01 10:37 ` Alexandre Mergnat
2026-07-03 9:16 ` NG, TZE YEE
2026-07-03 9:16 ` NG, TZE YEE
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=20260630133239.42C2F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=imx@lists.linux.dev \
--cc=linux-i3c@lists.infradead.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tze.yee.ng@altera.com \
/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.