From: Przemyslaw Gaj <pgaj@xxxxxxxxxxx> Date: Wed, Sep 04, 2019 at 05:47:18 > The 09/03/2019 11:57, Vitor Soares wrote: > > EXTERNAL MAIL > > > > > > From: Przemyslaw Gaj <pgaj@xxxxxxxxxxx> > > Date: Tue, Sep 03, 2019 at 12:13:57 > > > > > Hi Vitor, > > > > > > I'm sorry for the delay. > > > > > > The 09/03/2019 12:35, Vitor Soares wrote: > > > > EXTERNAL MAIL > > > > > > > > > > > > On pre_assing_dyn_addr() the devices that fail: > > > > i3c_master_setdasa_locked() > > > > i3c_master_reattach_i3c_dev() > > > > i3c_master_retrieve_dev_info() > > > > > > > > are kept in memory and master->bus.devs list. This makes the i3c devices > > > > without a dynamic address are sent on DEFSLVS CCC command. Fix this by > > > > detaching and freeing the devices that fail on pre_assign_dyn_addr(). > > > > > > What is the problem with sending devices without dynamic address in DEFSLVS? > > > > How do you address them? > > For the DA field in DEFSLVS frame, the spec says: "shall contain the > > current value of the Slave's assigned 7-bit Dynamic address". If the > > device doesn't have the dynamic address assigned yet why send it? > > > > What stops us from operating with this device in I2C mode using his SA? So, send it as an I2C device as spec says. > > > > Shouldn't we still inform rest of the devices about that? About fact that > > > device with SA without DA exists on the bus? > > > > I would like to understand what is the use case for this? > > Look above. I2C mode still should be possible IMO. Just consider the case when > you really need some information from that device, main master can assign > dynamic address later but you can make some transfers. It is true, but again it is a I2C device and not I3C device. It won't reply to I3C commands until has a DA. How will you know that the DA sent in DEFSLVS is not assigned yet? > I know our framework > does not support that case but secondary master can be different system which > should know that this device exists and don't have DA yet, so I2C mode is > available. If the HJ happen in secondary master side, there is a change to describe in DT what should be DA. Please check 2nd patch. > > > > > On I3C spec table "I3C Devices Roles vs Responsibilities", Secondary > > Master is not responsible to do Dynamic Address Assignment but it is > > optional to do Hot-Join Dynamic Address Assignment. > > > > Yes, we discussed that few times during the review of Mastership patch series. Hence, based on that table, secondary master won't do DAA just because he want, It needs a HJ to trigger DAA. Sorry, but for me based on what spec says this use case is not feasible. Best regards, Vitor Soares
