From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Frank Li <Frank.li@nxp.com>
Cc: linux-renesas-soc@vger.kernel.org,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-i3c@lists.infradead.org
Subject: Re: [PATCH v4 2/4] i3c: Add more parameters for controllers to the header
Date: Thu, 24 Jul 2025 11:09:58 +0200 [thread overview]
Message-ID: <aIH4ZmqVcYhOT8xT@shikoro> (raw)
In-Reply-To: <aIEg-qyGhb8B2Rep@shikoro>
On Wed, Jul 23, 2025 at 07:50:50PM +0200, Wolfram Sang wrote:
>
> > > +/* TODO: Document a reason for this value */
> >
> > Todo? Can you finish it?
>
> Yes, but in a seperate patch series where the value is to be changed.
>
> This needs additional testing because I want to update the other I3C
> controller drivers as well.
So, I started the research [1] with the conclusion:
---
The above completion is for the *whole transfer*, though, including the
target response time. Like I2C, it is not specified for I3C. At least, I
couldn't find it and I recall no one at the I3C plugfest could point me
to one as well.
So, this completion timeout is more than just 5.1.2.5. It might make
sense to investigate a more reasonable value. But I don't think this
should be imposed on someone submitting a new driver. It is a dedicated
task. And I am not even sure the result will be a subsystem-wide static
value. It might be a calculated value. Maybe even a driver-specific
calculated value.
So, I think the best we can do until we have this investigation is to
keep drivers consistent with the historically grown value.
---
Based on this, I will send V5 and move XFER_TIMEOUT back into the
driver. We don't know yet if a subsystem-wide static default value is
actually the right way.
[1] https://lore.kernel.org/r/aIH1zUb8tyIlyC3S@shikoro
--
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: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Frank Li <Frank.li@nxp.com>
Cc: linux-renesas-soc@vger.kernel.org,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-i3c@lists.infradead.org
Subject: Re: [PATCH v4 2/4] i3c: Add more parameters for controllers to the header
Date: Thu, 24 Jul 2025 11:09:58 +0200 [thread overview]
Message-ID: <aIH4ZmqVcYhOT8xT@shikoro> (raw)
In-Reply-To: <aIEg-qyGhb8B2Rep@shikoro>
On Wed, Jul 23, 2025 at 07:50:50PM +0200, Wolfram Sang wrote:
>
> > > +/* TODO: Document a reason for this value */
> >
> > Todo? Can you finish it?
>
> Yes, but in a seperate patch series where the value is to be changed.
>
> This needs additional testing because I want to update the other I3C
> controller drivers as well.
So, I started the research [1] with the conclusion:
---
The above completion is for the *whole transfer*, though, including the
target response time. Like I2C, it is not specified for I3C. At least, I
couldn't find it and I recall no one at the I3C plugfest could point me
to one as well.
So, this completion timeout is more than just 5.1.2.5. It might make
sense to investigate a more reasonable value. But I don't think this
should be imposed on someone submitting a new driver. It is a dedicated
task. And I am not even sure the result will be a subsystem-wide static
value. It might be a calculated value. Maybe even a driver-specific
calculated value.
So, I think the best we can do until we have this investigation is to
keep drivers consistent with the historically grown value.
---
Based on this, I will send V5 and move XFER_TIMEOUT back into the
driver. We don't know yet if a subsystem-wide static default value is
actually the right way.
[1] https://lore.kernel.org/r/aIH1zUb8tyIlyC3S@shikoro
next prev parent reply other threads:[~2025-07-24 10:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 19:07 [PATCH v4 0/4] i3c: add support for the Renesas controller Wolfram Sang
2025-07-22 19:07 ` Wolfram Sang
2025-07-22 19:07 ` [PATCH v4 1/4] i3c: Standardize defines for specification parameters Wolfram Sang
2025-07-22 19:07 ` Wolfram Sang
2025-07-23 15:30 ` Frank Li
2025-07-23 15:30 ` Frank Li
2025-07-22 19:07 ` [PATCH v4 2/4] i3c: Add more parameters for controllers to the header Wolfram Sang
2025-07-22 19:07 ` Wolfram Sang
2025-07-23 15:32 ` Frank Li
2025-07-23 15:32 ` Frank Li
2025-07-23 17:50 ` Wolfram Sang
2025-07-23 17:50 ` Wolfram Sang
2025-07-24 9:09 ` Wolfram Sang [this message]
2025-07-24 9:09 ` Wolfram Sang
2025-07-22 19:07 ` [PATCH v4 3/4] dt-bindings: i3c: Add Renesas I3C controller Wolfram Sang
2025-07-22 19:07 ` Wolfram Sang
2025-07-22 19:07 ` [PATCH v4 4/4] i3c: master: Add basic driver for the " Wolfram Sang
2025-07-22 19:07 ` Wolfram Sang
2025-07-23 15:33 ` Frank Li
2025-07-23 15:33 ` Frank Li
2025-07-23 9:35 ` [PATCH v4 0/4] i3c: add support for the Renesas controller Tommaso Merciai
2025-07-23 9:35 ` Tommaso Merciai
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=aIH4ZmqVcYhOT8xT@shikoro \
--to=wsa+renesas@sang-engineering.com \
--cc=Frank.li@nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
/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.