Re: [PATCH v2 06/17] i3c: renesas: Perform Dynamic Address Assignment on resume

[Frank Li <Frank.li@nxp.com>]

On Thu, Jun 04, 2026 at 04:04:52PM +0300, Claudiu Beznea wrote:
> Hi, Frank,
>
> On 6/3/26 22:26, Frank Li wrote:
> > On Wed, Jun 03, 2026 at 05:23:06PM +0300, Claudiu Beznea wrote:
> > > Hi, Frank, I3C maintainers,
> > >
...
> > >
> > > As I don't have a real setup to test this, would it be OK to restore the
> > > approach in this patch as proposed in v1?
> > This case is quite complex, and many people try to resolve simialar
> > problems, you may want to reattach device because controller lost state.
> >
> > hub have similar requirement, which need reattach devices.
> >
> > https://lore.kernel.org/linux-i3c/20260525064209.2263045-1-
> > lakshay.piplani@nxp.com/T/#ma99fa92cb3aac770995350e0fc22c144b974a038
> >
> > controller lost state, but may i3c devices still alive and they dynamtic
> > address during suspend. Does reattach to the old address help your case?
> Yes, re-attaching works and I also need to update the subsystem data
> structures. Something like the following works for me:
>
...
> +                               old_dyn_addr = dev->info.dyn_addr;
> +                               dev->info.dyn_addr = i3c->addrs[pos].addr;
> +
> +                               i3c_master_reattach_i3c_dev_locked(dev,
> old_dyn_addr);
...
>
> To me, this looks OK but I don't think it is yet completed. If I'm not
> wrong, even with this adjustment the problem may still persist when running
> DAA on a full ocupied bus at runtime (e.g. after devices are
> removed/inserted). This driver don't support hotplug but I noticed the ones
> that supports it do DAA on hotplug events.
>
> Could you please let me know what's the procedure to go forward with this
> series? The approach proposed in the above diff depends on the series
> exporting i3c_master_reattach_i3c_dev_locked(), which is in progress.

Two patch already was acked by me. I supposed alex will pick my acked before
your patch, you can send out update and cover later said depend on first two
patches of hubs.

Recently there are more people involve i3c work and create some cross
dependency.

Alex:
	Do you expect me to temp land these patches to one branch in
git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git? so you can double
check before send pull-request to linus?

Frank

>
> If all good with the rest of the patches in this series, as I don't have a
> real setup to test this, would it be OK to switch this patch as it was in v1
> and return with the adjustments in the above diff once the
> i3c_master_reattach_i3c_dev_locked() is integrated?
>
> --
> Thank you,
> Claudiu