Re: [PATCH] i3c: make sure the PID is set before registering the device

["Przemysław Gaj" <pgaj@cadence.com>]

Hi Vitor,

The 12/10/2019 14:28, Vitor Soares wrote:
> 
> Hi Boris,
> 
> From: Boris Brezillon <boris.brezillon@collabora.com>
> Date: Mon, Dec 09, 2019 at 12:26:16
> 
> > On Mon, 9 Dec 2019 12:20:03 +0000
> > Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> > 
> > > Hi Boris,
> > > 
> > > From: Boris Brezillon <boris.brezillon@collabora.com>
> > > Date: Mon, Dec 09, 2019 at 09:47:11
> > > 
> > > > On Sun, 8 Dec 2019 15:18:34 +0100
> > > > Przemysław Gaj <pgaj@cadence.com> wrote:
> > > >   
> > > > > From: Przemyslaw Gaj <pgaj@cadence.com>
> > > > > 
> > > > > Provisioned ID (PID) is the value with which device drivers are
> > > > > matched. I check the value before registering the device.
> > > > >   
> > > > 
> > > > Can this situation (having a device with a DA but without a valid PID)
> > > > happen right now or is this something you need to support secondary
> > > > masters who receive device DA (through DEFSVLS) without being able to
> > > > query extra information until they own the bus?  
> > > 
> > > This is the use case where a device fails the 
> > > i3c_master_pre_assign_dyn_addr() and I already mention it on [1].
> > > I still think the best way is to detach/free the devices that fails 
> > > during i3c_master_pre_assign_dyn_addr().
> > 
> > And I disagree (I gave my arguments already, so won't repeat them
> > here).
> 
> Sorry Boris, did you give? I ask you several times why to keep non DA 
> devices attached to the bus, yet you wasn't able to give me a technical 
> reason. Even from device model you should kept them.

I think we should keep them because framework should still have the
information about all the devices. We already discussed that, right?
Especially, when we have to deal with group addresses soon, it's better
to keep them.

> Honestly, I'm starting ask myself if this is something against because 
> every time that I'm trying to improve something I just see difficulty 
> from your side.

Don't forget that my patches are accepted after 6th, 7th versions. I
think that it just should work like that. This makes things better :)

> 
> > Can we move on please?
> 
> I think you should start learning to listen the other and have the 
> greatness to accept the others experience and opinions. With your 
> experience you should already learn that.
> The previous patch makes all the sense yet your response was - I am not 
> convinced. Could you please give a proper justification? At least test 
> what I spend time to do?
> 
> > Can you send a new version that does what
> > I suggest, or should I ask Przemek to do it?
> 
> Does the ethics approve such attitude? Don't you see with kind of 
> attitude you are just putting people away of this subsystem?
> 
> > 
> > _______________________________________________
> > linux-i3c mailing list
> > linux-i3c@lists.infradead.org
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Di3c&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=cXyPCHO2vhcyD3aN-LnqOqzodbB9g-utJXeWOQRkJmk&s=odrtYhb-IaK-dfTzi1p7TwH2YJcnZ3RSdNNrKJjXFdM&e= 
> 
> Best regards,
> Vitor Soares
> 

-- 
-- 
Regards,
Przemek

_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c