From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Frank Li <Frank.li@nxp.com>
Cc: linux-renesas-soc@vger.kernel.org,
Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Magnus Damm <magnus.damm@gmail.com>,
linux-i3c@lists.infradead.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH RFC 4/7] i3c: add driver for Renesas I3C IP
Date: Thu, 12 Jun 2025 16:55:31 +0200 [thread overview]
Message-ID: <aErqY0QWMRdC7Pvg@shikoro> (raw)
In-Reply-To: <aEmws+OtHirrUPUo@lizhi-Precision-Tower-5810>
[-- Attachment #1.1: Type: text/plain, Size: 3806 bytes --]
Hi Frank,
thanks again for the super-fast review.
> > - RENESAS_I3C_MAX_DEVS is a constant currently. So, we could get rid of
> > the 'maxdevs' variable. I tend to keep it this way in case future
> > controllers may use a different value, then we can change it easily.
>
> It is similar ADI version. Can you simple descript hardware behavor to show
> why need RENESAS_I3C_MAX_DEVS,
Yes, for example this register has basic status info per target:
> > +#define DATBAS(x) (0x224 + 0x8 * (x))
And there are only 8 of these registers. So, there is a maximum of 8 for
this controller. We could hardcode 8. But we could leave the handling as
is, just in case a future controller has more or less of these
registers.
> > - For accessing the FIFOs, this driver uses the same code as existing
> > upstream drivers or the recenlty submitted "ADI" driver. There, the
> > question came up, if this could be a helper function?
>
> Add common header in drivers/i3c/master/core.h implement inline helper
> function
Sure thing. I think I didn't get feedback on my original suggestion so
far. If I now know you are positive about it, I will give it a try.
> #define PRTS 0x00
> #define PRTS_PRTMD BIT(0)
>
> Add extra space help distinguish register and field define.
Okay.
>
> > +
> > +#define BCTL 0x14
> > +#define BCTL_HJACKCTL BIT(8)
> > +#define BCTL_ABT BIT(29)
> > +#define BCTL_BUSE BIT(31)
> > +
> > +#define MSDVAD 0x18
> > +#define MSDVAD_MDYAD(x) (((x) & 0x3f) << 16)
>
> Use GEN_MASK
Sigh, if you think this is more readable, then OK.
> > +#define STDBR 0x74
> > +#define STDBR_SBRLO(cond, x) ((((x) >> (cond)) & 0xff) << 0)
> > +#define STDBR_SBRHO(cond, x) ((((x) >> (cond)) & 0xff) << 8)
>
> FIELD_GET FIELD_PREP
Ditto.
> > +static inline void i3c_reg_update(u32 mask, u32 val, void __iomem *reg)
> > +{
> > + u32 data = readl(reg);
> > +
> > + data &= ~mask;
> > + data |= (val & mask);
> > + writel(data, reg);
> > +}
>
> can you move reg to first argument to align below help function?
Yup, coccinelle should make that easy.
> > +out:
> > + kfree(xfer);
>
> you can __free(kfree) xfer = NULL at declear to avoid this goto branch.
I'll give it a try...
> > + if (!i3c_xfers[i].rnw && i3c_xfers[i].len > 4) {
>
> Only pre fill fifo when len >4? what happen if only write 1 byte?
Ehrm, good catch. I will check this in more detail.
> > + renesas_i3c_write_to_tx_fifo(i3c, cmd->tx_buf, cmd->len);
> > + if (cmd->len > NTDTBP0_DEPTH * sizeof(u32))
> > + i3c_reg_set_bit(i3c->regs, NTIE, NTIE_TDBEIE0);
> > + }
> > +
> > + renesas_i3c_enqueue_xfer(i3c, xfer);
> > + if (!wait_for_completion_timeout(&xfer->comp, XFER_TIMEOUT))
> > + renesas_i3c_dequeue_xfer(i3c, xfer);
>
> This may common problem, I3C spec have 100us timeout, target side may
> timeout when driver wait for irq. So target side treat "repeat start" as
> "start" and issue address arbitration.
There is a specified timeout? I couldn't find one in the specs, can you
kindly point me to it? So, the solution is to use 100us as timeout?
> > + i3c->addrs[pos] = dev->info.dyn_addr ? : dev->info.static_addr;
>
> Are there extension of "?" operator in C ? I remember
>
> dev->info.dyn_addr ? dev->info.dyn_addr : dev->info.static_addr;
Dunno if it made it into the standard these days, but as a GCC extension
it is used in the kernel for ages. I encourage its use in I2C, other
maintainers don't like it much. Mileages vary.
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to request irq %s\n",
> > + renesas_i3c_irqs[i].desc);
> > + return ret;
>
> return dev_err_probe()
OK.
Thanks and happy hacking,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 111 bytes --]
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2025-06-24 0:30 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-11 9:39 [PATCH RFC 0/7] i3c: add driver for the Renesas IP and support RZ/G3S+G3E Wolfram Sang
2025-06-11 9:39 ` [PATCH RFC 3/7] dt-bindings: i3c: renesas,i3c: Add binding for Renesas I3C controller Wolfram Sang
2025-06-11 15:40 ` Frank Li
2025-06-12 14:31 ` Wolfram Sang
2025-06-12 14:51 ` Tommaso Merciai
2025-06-12 15:35 ` Frank Li
2025-06-25 20:04 ` Rob Herring
2025-06-26 1:37 ` Frank Li
2025-06-25 20:07 ` Rob Herring
2025-06-30 19:43 ` Wolfram Sang
2025-07-01 9:09 ` Tommaso Merciai
2025-07-03 7:18 ` Wolfram Sang
2025-06-11 9:39 ` [PATCH RFC 4/7] i3c: add driver for Renesas I3C IP Wolfram Sang
2025-06-11 16:37 ` Frank Li
2025-06-12 14:55 ` Wolfram Sang [this message]
2025-06-12 16:42 ` Frank Li
2025-06-13 9:42 ` Wolfram Sang
2025-06-13 12:23 ` Geert Uytterhoeven
2025-06-13 13:10 ` Wolfram Sang
2025-06-17 7:12 ` Geert Uytterhoeven
2025-06-17 11:22 ` Wolfram Sang
2025-06-25 10:00 ` Wolfram Sang
2025-06-24 20:34 ` Wolfram Sang
2025-06-13 14:41 ` Frank Li
2025-06-17 9:42 ` Wolfram Sang
2025-07-24 8:58 ` Wolfram Sang
2025-06-11 13:11 ` [PATCH RFC 0/7] i3c: add driver for the Renesas IP and support RZ/G3S+G3E Rob Herring (Arm)
2025-06-11 18:56 ` Wolfram Sang
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=aErqY0QWMRdC7Pvg@shikoro \
--to=wsa+renesas@sang-engineering.com \
--cc=Frank.li@nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=geert+renesas@glider.be \
--cc=gustavoars@kernel.org \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=p.zabel@pengutronix.de \
--cc=tommaso.merciai.xr@bp.renesas.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