From: Vitor Soares <Vitor.Soares@synopsys.com>
To: Przemyslaw Gaj <pgaj@cadence.com>,
Vitor Soares <Vitor.Soares@synopsys.com>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"Joao.Pinto@synopsys.com" <Joao.Pinto@synopsys.com>,
Rafal Ciepiela <rafalc@cadence.com>,
"bbrezillon@kernel.org" <bbrezillon@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>
Subject: RE: [PATCH v2 1/5] i3c: master: detach and free device if pre_assign_dyn_addr() fails
Date: Wed, 4 Sep 2019 09:06:40 +0000 [thread overview]
Message-ID: <SN6PR12MB26554483310EE0BC00E87EF3AEB80@SN6PR12MB2655.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20190904044718.GB23588@global.cadence.com>
From: Przemyslaw Gaj <pgaj@cadence.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@cadence.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
_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2019-09-10 6:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 10:35 [PATCH v2 0/5] i3c: remove device if failed on pre_assign_dyn_addr() Vitor Soares
2019-09-03 10:35 ` [PATCH v2 1/5] i3c: master: detach and free device if pre_assign_dyn_addr() fails Vitor Soares
2019-09-03 10:52 ` Boris Brezillon
2019-09-03 11:10 ` Vitor Soares
2019-09-03 11:13 ` Przemyslaw Gaj
2019-09-03 11:57 ` Vitor Soares
2019-09-04 4:47 ` Przemyslaw Gaj
2019-09-04 9:06 ` Vitor Soares [this message]
2019-09-03 10:35 ` [PATCH v2 2/5] i3c: master: make sure ->boardinfo is initialized in add_i3c_dev_locked() Vitor Soares
2019-09-03 10:35 ` [PATCH v2 3/5] dt-bindings: i3c: Make 'assigned-address' valid if static address == 0 Vitor Soares
2019-09-03 17:40 ` Rob Herring
2019-09-03 10:35 ` [PATCH v2 4/5] dt-bindings: i3c: add a note for no guarantee of 'assigned-address' use Vitor Soares
2019-09-03 17:41 ` Rob Herring
2019-09-03 10:35 ` [PATCH v2 5/5] i3c: master: dw: reattach device on first available location of address table Vitor Soares
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=SN6PR12MB26554483310EE0BC00E87EF3AEB80@SN6PR12MB2655.namprd12.prod.outlook.com \
--to=vitor.soares@synopsys.com \
--cc=Joao.Pinto@synopsys.com \
--cc=bbrezillon@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pgaj@cadence.com \
--cc=rafalc@cadence.com \
--cc=robh+dt@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).