[PATCH 1/6] i3c: master: svc: fix race condition in ibi work thread

[Miquel Raynal]

Hi Frank,

Frank.li at nxp.com wrote on Tue, 17 Oct 2023 11:10:54 -0400:

> On Tue, Oct 17, 2023 at 04:49:46PM +0200, Miquel Raynal wrote:
> > Hi Frank,
> > 
> > Frank.li at nxp.com wrote on Tue, 17 Oct 2023 10:37:57 -0400:
> >   
> > > On Tue, Oct 17, 2023 at 04:16:58PM +0200, Miquel Raynal wrote:  
> > > > Hi Frank,
> > > > 
> > > > Frank.Li at nxp.com wrote on Mon, 16 Oct 2023 11:32:27 -0400:
> > > >     
> > > > > The ibi work thread operates asynchronously with other transfers, such as
> > > > > svc_i3c_master_priv_xfers(). Introduces mutex protection to ensure the    
> > > > 
> > > > Introduce
> > > >     
> > > > > completion of the entire i3c/i2c transaction.    
> > > > 
> > > > Did you experience faulty conditions or was it reported thanks to
> > > > static analysis?    
> > > 
> > > Yes, I met. But it needs my slave part patches, which will be ready sent
> > > out review soon.  
> > 
> > I believe several of the "fixes" in this series are related to newer
> > uses (typically your i3c slave support) which were not in the scope of
> > the original submission. As these new features are not supposed to be
> > backported in stable kernels and because these are new corner cases,you
> > may drop the CC:/Fixes tags to avoid useless backports.  
> 
> I don't think so. The issue exists. Just difficult to find it. If there are
> i3c device that use IBI frequently. The problem should be trigger. My case
> just make it easy to trigger the problem.
> 
> In previous existed code, IBI is supported.
> 
> I think it is typical case, which need CC/Fixes.

I am not talking about this patch in particular.

> 
> Frank
> 
> > 
> > Some of them however are real fixes for situations we may happen with
> > the current level of support, please keep the tags in these, and move
> > them all to the beginning of your series.
> > 
> > Thanks,
> > Miquèl  


Thanks,
Miquèl