All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Akhil R <akhilrajeev@nvidia.com>
Cc: frank.li@oss.nxp.com, Frank.Li@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, linux-hwmon@vger.kernel.org,
	linux-i3c@lists.infradead.org, robh@kernel.org,
	sashiko-reviews@lists.linux.dev
Subject: Re: [PATCH v5 04/12] i3c: master: Add support for devices using SETAASA
Date: Mon, 20 Jul 2026 18:07:01 +0200	[thread overview]
Message-ID: <202607201607012c70129a@mail.local> (raw)
In-Reply-To: <20260703090855.1519255-1-akhilrajeev@nvidia.com>

On 03/07/2026 09:08:55+0000, Akhil R wrote:
> On Thu, 25 Jun 2026 07:42:03 -0500 Frank Li wrote:
> > On Thu, Jun 25, 2026 at 09:38:15AM +0000, Akhil R wrote:
> >> On Wed, 24 Jun 2026 13:57:46 -0400, Frank Li wrote:
> >> ...
> >> ...
> >> >> [Severity: High]
> >> >> Is it possible that sending the SETAASA broadcast before direct SETDASA
> >> >> assignments breaks initialization for devices that natively support SETAASA
> >> >> but are configured for SETDASA?
> >> >>
> >> >> According to the I3C specification, any device on the bus natively supporting
> >> >> SETAASA will respond to this broadcast by adopting its static address as its
> >> >> dynamic address.
> >> >>
> >> >> After this broadcast, the driver iterates through devices and attempts to
> >> >> assign custom dynamic addresses via direct SETDASA commands:
> >> >>
> >> >> drivers/i3c/master.c:i3c_master_early_i3c_dev_add() {
> >> >>     ...
> >> >> 	ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
> >> >> 					i3cdev->boardinfo->init_dyn_addr);
> >> >>     ...
> >> >> }
> >> >>
> >> >> Since the target device already adopted its dynamic address during the
> >> >> SETAASA broadcast, it is no longer in the unassigned state and will NACK
> >> >> the subsequent SETDASA command.
> >> >
> >> > Look like correct, but I am not sure if target will NACK SETDASA. Or should
> >> > use SETNEWDA for SETAASA method.
> >>
> >> Yes, this looks valid for mixed device buses. I can move
> >> i3c_master_setaasa_locked() after the SETDASA handling and before
> >> i3c_master_do_daa() in the same function, so SETDASA-assigned devices will
> >> ignore the later SETAASA broadcast. Does that sound good to you?
> > 
> > yes, try it to follow spec.
> 
> I just noticed that the specification says: if both bits 0 and 1 are set,
> meaning both SETDASA and SETAASA are supported, the I3C Bus Controller should
> use SETDASA first.
> 
> So moving i3c_master_setaasa_locked() after SETDASA handling follows the spec.
> 
> I will wait a few more days before sending v6, to see if there are any other
> concerns.

No other concerns on my side.

> 
> Best Regards,
> Akhil
> 
> -- 
> linux-i3c mailing list
> linux-i3c@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-i3c

-- 
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: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Akhil R <akhilrajeev@nvidia.com>
Cc: frank.li@oss.nxp.com, Frank.Li@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, linux-hwmon@vger.kernel.org,
	linux-i3c@lists.infradead.org, robh@kernel.org,
	sashiko-reviews@lists.linux.dev
Subject: Re: [PATCH v5 04/12] i3c: master: Add support for devices using SETAASA
Date: Mon, 20 Jul 2026 18:07:01 +0200	[thread overview]
Message-ID: <202607201607012c70129a@mail.local> (raw)
In-Reply-To: <20260703090855.1519255-1-akhilrajeev@nvidia.com>

On 03/07/2026 09:08:55+0000, Akhil R wrote:
> On Thu, 25 Jun 2026 07:42:03 -0500 Frank Li wrote:
> > On Thu, Jun 25, 2026 at 09:38:15AM +0000, Akhil R wrote:
> >> On Wed, 24 Jun 2026 13:57:46 -0400, Frank Li wrote:
> >> ...
> >> ...
> >> >> [Severity: High]
> >> >> Is it possible that sending the SETAASA broadcast before direct SETDASA
> >> >> assignments breaks initialization for devices that natively support SETAASA
> >> >> but are configured for SETDASA?
> >> >>
> >> >> According to the I3C specification, any device on the bus natively supporting
> >> >> SETAASA will respond to this broadcast by adopting its static address as its
> >> >> dynamic address.
> >> >>
> >> >> After this broadcast, the driver iterates through devices and attempts to
> >> >> assign custom dynamic addresses via direct SETDASA commands:
> >> >>
> >> >> drivers/i3c/master.c:i3c_master_early_i3c_dev_add() {
> >> >>     ...
> >> >> 	ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
> >> >> 					i3cdev->boardinfo->init_dyn_addr);
> >> >>     ...
> >> >> }
> >> >>
> >> >> Since the target device already adopted its dynamic address during the
> >> >> SETAASA broadcast, it is no longer in the unassigned state and will NACK
> >> >> the subsequent SETDASA command.
> >> >
> >> > Look like correct, but I am not sure if target will NACK SETDASA. Or should
> >> > use SETNEWDA for SETAASA method.
> >>
> >> Yes, this looks valid for mixed device buses. I can move
> >> i3c_master_setaasa_locked() after the SETDASA handling and before
> >> i3c_master_do_daa() in the same function, so SETDASA-assigned devices will
> >> ignore the later SETAASA broadcast. Does that sound good to you?
> > 
> > yes, try it to follow spec.
> 
> I just noticed that the specification says: if both bits 0 and 1 are set,
> meaning both SETDASA and SETAASA are supported, the I3C Bus Controller should
> use SETDASA first.
> 
> So moving i3c_master_setaasa_locked() after SETDASA handling follows the spec.
> 
> I will wait a few more days before sending v6, to see if there are any other
> concerns.

No other concerns on my side.

> 
> Best Regards,
> Akhil
> 
> -- 
> linux-i3c mailing list
> linux-i3c@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-i3c

  reply	other threads:[~2026-07-20 16:07 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-24 10:20 [PATCH v5 00/12] Support ACPI and SETAASA device discovery Akhil R
2026-06-24 10:20 ` Akhil R
2026-06-24 10:20 ` [PATCH v5 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA Akhil R
2026-06-24 10:20   ` Akhil R
2026-06-24 10:30   ` sashiko-bot
2026-06-24 10:30     ` sashiko-bot
2026-06-30 16:15   ` Rob Herring (Arm)
2026-06-30 16:15     ` Rob Herring (Arm)
2026-06-24 10:20 ` [PATCH v5 02/12] i3c: master: Use unified device property interface Akhil R
2026-06-24 10:20   ` Akhil R
2026-06-24 10:48   ` sashiko-bot
2026-06-24 10:48     ` sashiko-bot
2026-06-24 10:20 ` [PATCH v5 03/12] i3c: master: Support ACPI enumeration of child devices Akhil R
2026-06-24 10:20   ` Akhil R
2026-06-24 10:38   ` sashiko-bot
2026-06-24 10:38     ` sashiko-bot
2026-06-24 10:20 ` [PATCH v5 04/12] i3c: master: Add support for devices using SETAASA Akhil R
2026-06-24 10:20   ` Akhil R
2026-06-24 10:43   ` sashiko-bot
2026-06-24 10:43     ` sashiko-bot
2026-06-24 17:57     ` Frank Li
2026-06-24 17:57       ` Frank Li
2026-06-25  9:38       ` Akhil R
2026-06-25  9:38         ` Akhil R
2026-06-25 12:42         ` Frank Li
2026-06-25 12:42           ` Frank Li
2026-07-03  9:08           ` Akhil R
2026-07-03  9:08             ` Akhil R
2026-07-20 16:07             ` Alexandre Belloni [this message]
2026-07-20 16:07               ` Alexandre Belloni
2026-06-24 10:20 ` [PATCH v5 05/12] i3c: master: Add support for devices without PID Akhil R
2026-06-24 10:20   ` Akhil R
2026-06-24 10:45   ` sashiko-bot
2026-06-24 10:45     ` sashiko-bot
2026-06-24 10:21 ` [PATCH v5 06/12] i3c: master: match I3C device through DT and ACPI Akhil R
2026-06-24 10:21   ` Akhil R
2026-06-24 10:42   ` sashiko-bot
2026-06-24 10:42     ` sashiko-bot
2026-06-24 10:21 ` [PATCH v5 07/12] i3c: dw-i3c-master: Add SETAASA as supported CCC Akhil R
2026-06-24 10:21   ` Akhil R
2026-06-24 10:34   ` sashiko-bot
2026-06-24 10:34     ` sashiko-bot
2026-06-24 10:21 ` [PATCH v5 08/12] i3c: dw-i3c-master: Add ACPI core clock frequency quirk Akhil R
2026-06-24 10:21   ` Akhil R
2026-06-24 10:45   ` sashiko-bot
2026-06-24 10:45     ` sashiko-bot
2026-06-24 18:09   ` Frank Li
2026-06-24 18:09     ` Frank Li
2026-06-24 10:21 ` [PATCH v5 09/12] i3c: dw-i3c-master: Add ACPI ID for Tegra410 Akhil R
2026-06-24 10:21   ` Akhil R
2026-06-24 10:32   ` sashiko-bot
2026-06-24 10:32     ` sashiko-bot
2026-06-24 10:21 ` [PATCH v5 10/12] hwmon: spd5118: Remove 16-bit addressing Akhil R
2026-06-24 10:21   ` Akhil R
2026-06-24 10:33   ` sashiko-bot
2026-06-24 10:33     ` sashiko-bot
2026-06-24 10:21 ` [PATCH v5 11/12] hwmon: spd5118: Add I3C support Akhil R
2026-06-24 10:21   ` Akhil R
2026-06-24 10:49   ` sashiko-bot
2026-06-24 10:49     ` sashiko-bot
2026-06-24 10:21 ` [PATCH v5 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon Akhil R
2026-06-24 10:21   ` Akhil R
2026-06-24 10:40   ` sashiko-bot
2026-06-24 10:40     ` sashiko-bot

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=202607201607012c70129a@mail.local \
    --to=alexandre.belloni@bootlin.com \
    --cc=Frank.Li@kernel.org \
    --cc=akhilrajeev@nvidia.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frank.li@oss.nxp.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-i3c@lists.infradead.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.