From: "NG, TZE YEE" <tze.yee.ng@altera.com>
To: Frank Li <Frank.li@oss.nxp.com>
Cc: "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Frank Li" <Frank.Li@nxp.com>,
"NG, ADRIAN HO YIN" <adrian.ho.yin.ng@altera.com>,
"Felix Gu" <ustc.gu@gmail.com>,
"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
"Manikanta Guntupalli" <manikanta.guntupalli@amd.com>,
"Jorge Marques" <jorge.marques@analog.com>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Przemysław Gaj" <pgaj@cadence.com>,
"Tommaso Merciai" <tommaso.merciai.xr@bp.renesas.com>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Jarkko Nikula" <jarkko.nikula@linux.intel.com>,
"imx@lists.linux.dev" <imx@lists.linux.dev>
Subject: Re: [PATCH v4 3/3] i3c: master: Validate GET CCC payload length and retry Direct GET once
Date: Fri, 3 Jul 2026 08:58:21 +0000 [thread overview]
Message-ID: <653f239d-746d-4c47-9a30-4088bdf4da3e@altera.com> (raw)
In-Reply-To: <akQPfmc-9p88Un7z@lizhi-Precision-Tower-5810>
On 1/7/2026 2:48 am, Frank Li wrote:
> On Tue, Jun 30, 2026 at 06:20:27AM -0700, tze.yee.ng@altera.com wrote:
>> From: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
>>
>> Add optional_bytes to struct i3c_ccc_cmd_payload so callers describe
>> variable-length GET CCC responses. GETMRL and GETMXDS set optional_bytes
>> at the call site.
>>
>> Validate GET payload length in i3c_master_send_ccc_cmd_locked() using
>> actual_len and optional_bytes. Retry failed Direct GET CCCs up to
>> cmd->retries times (default I3C_CCC_RETRIES) on any error; SET CCCs are
>> not retried by default.
>>
>> Add i3c_ccc_cmd_init_retries() and set actual_len in I3C master drivers
>> on successful GET transfers.
>>
>> Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
>> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
>> ---
>> drivers/i3c/master.c | 92 ++++++++++++++++++++++----
>> drivers/i3c/master/adi-i3c-master.c | 2 +
>> drivers/i3c/master/i3c-master-cdns.c | 2 +
>> drivers/i3c/master/mipi-i3c-hci/core.c | 5 +-
>> drivers/i3c/master/renesas-i3c.c | 2 +
>> drivers/i3c/master/svc-i3c-master.c | 4 +-
>> include/linux/i3c/ccc.h | 7 ++
>
> Can you spit ccc.h and master.c to one patch, other driver change to
> anthoer patche.
>
Hi Frank,
Sure, I will split them in v5.
>> 7 files changed, 98 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
>> index 5cd4e5da2233..29dc0793a5a4 100644
>> --- a/drivers/i3c/master.c
>> +++ b/drivers/i3c/master.c
>> @@ -901,6 +901,8 @@ static void *i3c_ccc_cmd_dest_init(struct i3c_ccc_cmd_dest *dest, u8 addr,
>> {
>> dest->addr = addr;
>> dest->payload.len = payloadlen;
>> + dest->payload.actual_len = 0;
>> + dest->payload.optional_bytes = 0;
>> if (payloadlen)
>> dest->payload.data = kzalloc(payloadlen, GFP_KERNEL);
>> else
>> @@ -914,17 +916,55 @@ static void i3c_ccc_cmd_dest_cleanup(struct i3c_ccc_cmd_dest *dest)
>> kfree(dest->payload.data);
>> }
>>
> ...
>>
>> +static void i3c_ccc_cmd_init(struct i3c_ccc_cmd *cmd, bool rnw, u8 id,
>> + struct i3c_ccc_cmd_dest *dests,
>> + unsigned int ndests)
>> +{
>> + i3c_ccc_cmd_init_retries(cmd, rnw, id, dests, ndests,
>> + rnw ? I3C_CCC_RETRIES : 0);
>
> why only read need retry?
>
>> +}
>> +
> ...
Retry is required for Direct GET CCC per section 5.1.9.2.3 (section
5.2.1.2.3 in HDR): if a target cannot respond to a Direct GET CCC on the
first attempt, the master shall follow the SDR Direct GET retry model
(typically one retry); the target should generally respond on the second
attempt. Section 5.2.1.2.3 states the same for HDR Direct GET CCC. For
Direct SET CCC, decline may mean the CCC/defining byte is unsupported,
so the retry model does not necessarily apply, that's why we don't apply
auto-retry SET.
>>
>> @@ -953,7 +996,24 @@ static int i3c_master_send_ccc_cmd_locked(struct i3c_master_controller *master,
>> !master->ops->supports_ccc_cmd(master, cmd))
>> return -EOPNOTSUPP;
>>
>> - return master->ops->send_ccc_cmd(master, cmd);
>> + max_attempts = cmd->retries + 1;
>> + ret = -EIO;
>> + for (attempt = 0; attempt < max_attempts; attempt++) {
>> + unsigned int i;
>> +
>> + if (cmd->rnw)
>> + for (i = 0; i < cmd->ndests; i++)
>> + cmd->dests[i].payload.actual_len = 0;
>> +
>> + cmd->err = I3C_ERROR_UNKNOWN;
>> + ret = master->ops->send_ccc_cmd(master, cmd);
>> + if (!ret && cmd->rnw)
>
> i3c_ccc_validate_payload_len() already checked cmd->rnw, needn't check here
> again.
>
Agree. I will drop this cmd->rnw check in v5.
>> + ret = i3c_ccc_validate_payload_len(cmd);
>> + if (!ret && cmd->err == I3C_ERROR_UNKNOWN)
>> + break;
>
> if i3c_ccc_validate_payload_len() return failure, why need try here.
> suppose only need retry when target NACK request.
>
The I3C spec retry rules in §5.1.9.2.3 (Direct GET) and §5.1.10.2.x
(M0/M2) apply to bus-level transfer failures detected during the CCC —
frame errors, broadcast NACK, command not completing — not to software
payload-length validation after a successful transfer.
Therefore, i3c_ccc_validate_payload_len() failures should not trigger
retry; retry should be limited to send_ccc_cmd() driver/HW failures.
v4 will be updated so the retry loop only re-issues send_ccc_cmd() on
driver/HW failure. Validation runs after a successful transfer and is
not retried.
>> + }
>> +
>> + return ret;
>> }
>>
>> static struct i2c_dev_desc *
> ...
>> @@ -1363,6 +1427,8 @@ static int i3c_master_getmxds_locked(struct i3c_master_controller *master,
>> if (!getmaxds)
>> return -ENOMEM;
>>
>> + dest.payload.optional_bytes = 3;
>> +
>
> move these set optional_bytes to new patch
>
>> i3c_ccc_cmd_init(&cmd, true, I3C_CCC_GETMXDS, &dest, 1);
>> ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
>> if (ret) {
> ...
>> diff --git a/drivers/i3c/master/renesas-i3c.c b/drivers/i3c/master/renesas-i3c.c
>> index f39c449922ca..fec614700843 100644
>> --- a/drivers/i3c/master/renesas-i3c.c
>> +++ b/drivers/i3c/master/renesas-i3c.c
>> @@ -805,6 +805,8 @@ static int renesas_i3c_send_ccc_cmd(struct i3c_master_controller *m,
>> ret = xfer->ret;
>> if (ret)
>> ccc->err = I3C_ERROR_M2;
>> + else if (ccc->rnw)
>> + ccc->dests[0].payload.actual_len = cmd->rx_count;
>
> update actual_len's patch should just flow add field actual_len's patch
>
Will fix in v5.
Thanks,
Tze Yee
>>
>> return ret;
>> }
> ...
>> +
>> /**
>> * struct i3c_ccc_cmd_payload - CCC payload
>> *
>> * @len: requested payload length
>> * @actual_len: number of bytes received on a GET CCC (filled by the driver)
>> + * @optional_bytes: GET CCCs may return up to this many fewer bytes than @len
>
> up to @len - @optional_bytes
>
> Frank
>> * @data: payload data. This buffer must be DMA-able
>> */
>> struct i3c_ccc_cmd_payload {
>> u16 len;
>> u16 actual_len;
>> + u16 optional_bytes;
>> void *data;
>> };
>>
>> @@ -374,12 +378,15 @@ struct i3c_ccc_cmd_dest {
>> * @ndests: number of destinations. Should always be one for broadcast commands
>> * @dests: array of destinations and associated payload for this CCC. Most of
>> * the time, only one destination is provided
>> + * @retries: number of times to retry a failed Direct GET CCC (see
>> + * &I3C_CCC_RETRIES)
>> * @err: I3C error code
>> */
>> struct i3c_ccc_cmd {
>> u8 rnw;
>> u8 id;
>> unsigned int ndests;
>> + unsigned int retries;
>> struct i3c_ccc_cmd_dest *dests;
>> enum i3c_error_code err;
>> };
>> --
>> 2.43.7
>>
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2026-07-03 8:58 UTC|newest]
Thread overview: 18+ 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 ` [PATCH v4 1/3] i3c: master: dw: Report actual GET CCC payload length on success tze.yee.ng
2026-06-30 13:31 ` sashiko-bot
2026-06-30 17:03 ` Frank Li
2026-07-01 2:46 ` NG, TZE YEE
2026-07-01 10:37 ` Alexandre Mergnat
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:32 ` sashiko-bot
2026-06-30 17:06 ` Frank Li
2026-07-01 2:45 ` NG, TZE YEE
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:41 ` sashiko-bot
2026-06-30 18:48 ` Frank Li
2026-07-03 8:58 ` NG, TZE YEE [this message]
2026-07-01 10:37 ` Alexandre Mergnat
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=653f239d-746d-4c47-9a30-4088bdf4da3e@altera.com \
--to=tze.yee.ng@altera.com \
--cc=Frank.Li@nxp.com \
--cc=Frank.li@oss.nxp.com \
--cc=adrian.ho.yin.ng@altera.com \
--cc=adrian.hunter@intel.com \
--cc=alexandre.belloni@bootlin.com \
--cc=imx@lists.linux.dev \
--cc=jarkko.nikula@linux.intel.com \
--cc=jorge.marques@analog.com \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manikanta.guntupalli@amd.com \
--cc=miquel.raynal@bootlin.com \
--cc=pgaj@cadence.com \
--cc=sakari.ailus@linux.intel.com \
--cc=tommaso.merciai.xr@bp.renesas.com \
--cc=ustc.gu@gmail.com \
--cc=wsa+renesas@sang-engineering.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox