All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Li <Frank.li@oss.nxp.com>
To: Akhil R <akhilrajeev@nvidia.com>
Cc: 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: Thu, 25 Jun 2026 07:42:03 -0500	[thread overview]
Message-ID: <aj0iG5xplWPWc6m_@SMW015318> (raw)
In-Reply-To: <20260625093815.1794492-1-akhilrajeev@nvidia.com>

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.

Frank
>
> Best Regards,
> Akhil

-- 
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: Frank Li <Frank.li@oss.nxp.com>
To: Akhil R <akhilrajeev@nvidia.com>
Cc: 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: Thu, 25 Jun 2026 07:42:03 -0500	[thread overview]
Message-ID: <aj0iG5xplWPWc6m_@SMW015318> (raw)
In-Reply-To: <20260625093815.1794492-1-akhilrajeev@nvidia.com>

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.

Frank
>
> Best Regards,
> Akhil

  reply	other threads:[~2026-06-25 12:42 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 [this message]
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
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=aj0iG5xplWPWc6m_@SMW015318 \
    --to=frank.li@oss.nxp.com \
    --cc=Frank.Li@kernel.org \
    --cc=akhilrajeev@nvidia.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --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.