Re: [PATCH v2 04/14] soundwire: Add MIPI DisCo property helpers

[Charles Keepax]

On Fri, Nov 24, 2017 at 09:34:49PM +0530, Sanyog Kale wrote:
> On Thu, Nov 23, 2017 at 02:38:12PM +0000, Charles Keepax wrote:
> > On Fri, Nov 10, 2017 at 05:19:06PM +0530, Vinod Koul wrote:
> 
> > > MIPI Discovery And Configuration (DisCo) Specification for SoundWire
> > > specifies properties to be implemented for SoundWire Masters and
> > > Slaves. The DisCo spec doesn't mandate these properties. However,
> > > SDW bus cannot work without knowing these values.
> > > 
> > > The helper functions read the Master and Slave properties.
> > > Implementers of Master or Slave drivers can use any of the below
> > > three mechanisms:
> > >    a) Use these APIs here as .read_prop() callback for Master
> > >       and Slave
> > >    b) Implement own methods and set those as .read_prop(), but invoke
> > >       APIs in this file for generic read and override the values with
> > >       platform specific data
> > >    c) Implement ones own methods which do not use anything provided
> > >       here
> > > 
> > > Signed-off-by: Sanyog Kale <sanyog.r.kale@xxxxxxxxx>
> > > Signed-off-by: Vinod Koul <vinod.koul@xxxxxxxxx>
> > > ---
> > Apologies for the long and slightly vague comment, but I guess my
> > question is do you have a thought on how drivers should know when
> > it is safe to communicate with a SoundWire device?
> 
> IMO it is safe to communicate with SoundWire device when the Slave
> status is ATTACHED. In any case bus will report error if it is not able
> to communicate with SoundWire device.
> 

Yeah I guess my point here is that there is currently no way in
this SoundWire framework for the slave driver to know if the
device is attached or not, unless I am missing something?  There
are calls by which the master can inform the framework, but
nothing to pass that on to the slave driver.

I would indeed imagine the comms would fail if the slave isn't
attached but that doesn't seem like a particularly robust way of
determining that.

Thanks,
Charles