linux-hardening.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Tue, 17 Jun 2025 11:42:39 +0200	[thread overview]
Message-ID: <aFE4j86NaZcMvxBF@shikoro> (raw)
In-Reply-To: <aEmws+OtHirrUPUo@lizhi-Precision-Tower-5810>

[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]

Hi,

some status updates...

> It is similar ADI version. Can you simple descript hardware behavor to show
> why need RENESAS_I3C_MAX_DEVS,

I hope the documentation links I sent were helpful.

> Add common header in drivers/i3c/master/core.h implement inline helper
> function

I decided to handle this incrementally. I need to work on the real show
stoppers first, I'd say.

> #define PRTS                 0x00
> #define  PRTS_PRTMD          BIT(0)
> 
> Add extra space help distinguish register and field define.

Done.

> > +#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
> 
> check other define

Done. Also with GETMASK

> > +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?

Done.

> > +out:
> > +	kfree(xfer);
> 
> you can __free(kfree) xfer = NULL at declear to avoid this goto branch.

Do you insist on this? It makes the driver less consistent because there
are other 'out'-branches with kfree() in them which we need to keep
anyhow, because there are more instructions needed. I can do the change
if you want but I personally would prefer to leave the code as is.

> > +		if (!i3c_xfers[i].rnw && i3c_xfers[i].len > 4) {
> 
> Only pre fill fifo when len >4? what happen if only write 1 byte?

That was a really good catch, thank you! I think the code is completely
redundant because we fill the FIFO again at a later time. Then, also
handling the case of < 4 bytes correctly. Sadly, I can't test this with
my current setup right now. I hope to have tested this by next week.

> > +		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.

As said, I will try to discuss this at the I3C plugfest.

> > +	i3c->addrs[pos] = dev->info.dyn_addr ? : dev->info.static_addr;
> 
> Are there extension of "?" operator in C ? I remember

As agreed, I will keep this.

> > +		ret = devm_request_irq(&pdev->dev, ret, renesas_i3c_irqs[i].isr,
> > +				       0, renesas_i3c_irqs[i].desc, i3c);
> > +		if (ret) {
> > +			dev_err(&pdev->dev, "failed to request irq %s\n",
> > +				renesas_i3c_irqs[i].desc);
> > +			return ret;

I removed the printout comepletely. No need to do it for irqs.

I plan to resubmit the non-RFC version next week after the plugfest.
Fingers crossed.

Thanks and all the best,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2025-06-17  9:42 UTC|newest]

Thread overview: 17+ 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 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
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 [this message]
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=aFE4j86NaZcMvxBF@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;
as well as URLs for NNTP newsgroup(s).