RE: [PATCH v5 4/7] i3c: Add support for mastership request to I3C subsystem

[Vitor Soares <Vitor.Soares@synopsys.com>]

Hi Boris,

From: Boris Brezillon <boris.brezillon@collabora.com>
Date: Mon, Aug 12, 2019 at 15:55:31

> > > > > > > > 
> > > > > > > > It is not clear to me what you expect with these functions. Do you want 
> > > > > > > > to enable MR from all devices? Just some of them? How do you decide which 
> > > > > > > > secondary masters are allow earn the bus ownership?
> > > > > > > >     
> > > > > > > 
> > > > > > > We discussed this also. For now, we enable ENEC for all masters on the bus, we
> > > > > > > can change it later if needed.     
> > > > > > 
> > > > > > I would say to expand the current ibi framework to accommodate MR and    
> > > > > 
> > > > > Can you tell something more here? What benefits you see    
> > > > 
> > > > Just starting with the name. IBI stands for In Band Interrupt which can 
> > > > be MR, HJ or SIR.
> > > > 
> > > > Also the concept is the same, let say you are registering a SIR w/out 
> > > > data but in fact it is a MR.  
> > > 
> > > No, it's not from a SW PoV. IBI are events I3C device drivers can
> > > register a handler for, MR and HJ events are things the HC drivers are
> > > expected to handle, and that's a big difference. While re-using the IBI
> > > API to handle them should be doable I don't think it will make things
> > > simpler.
> > >   
> > 
> > In that case we need to rename the functions with slave interrupt request 
> > (SIR) in mind.
> 
> I'm fine changing ibi for sir. Can you send a patch doing that?
> 

I address this topic on MIPI forum and it is correct to assume IBI as SIR 
and not MR.
With this clarification is not necessary to change the 
functions/structures/variables names.

Best regards,
Vitor Soares

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