linux-kernel - RE: [PATCH v2 1/5] i3c: master: detach and free device if pre_assign_dyn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 4 Sep 2019 09:06:40 +0000
From:   Vitor Soares <Vitor.Soares@...opsys.com>
To:     Przemyslaw Gaj <pgaj@...ence.com>,
        Vitor Soares <Vitor.Soares@...opsys.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-i3c@...ts.infradead.org" <linux-i3c@...ts.infradead.org>,
        "bbrezillon@...nel.org" <bbrezillon@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "Joao.Pinto@...opsys.com" <Joao.Pinto@...opsys.com>,
        Rafal Ciepiela <rafalc@...ence.com>
Subject: RE: [PATCH v2 1/5] i3c: master: detach and free device if
 pre_assign_dyn_addr() fails

From: Przemyslaw Gaj <pgaj@...ence.com>
Date: Wed, Sep 04, 2019 at 05:47:18

> The 09/03/2019 11:57, Vitor Soares wrote:
> > EXTERNAL MAIL
> > 
> > 
> > From: Przemyslaw Gaj <pgaj@...ence.com>
> > 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