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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171127075940.euvjgjf6t5rimltp@localhost.localdomain>
Date:   Mon, 27 Nov 2017 07:59:40 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Sanyog Kale <sanyog.r.kale@...el.com>
CC:     Vinod Koul <vinod.koul@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        ALSA <alsa-devel@...a-project.org>, Mark <broonie@...nel.org>,
        Takashi <tiwai@...e.de>,
        Pierre <pierre-louis.bossart@...ux.intel.com>,
        Shreyas NC <shreyas.nc@...el.com>, <patches.audio@...el.com>,
        <alan@...ux.intel.com>, Sagar Dharia <sdharia@...eaurora.org>,
        <srinivas.kandagatla@...aro.org>, <plai@...eaurora.org>,
        Sudheer Papothi <spapothi@...eaurora.org>
Subject: Re: [PATCH v2 04/14] soundwire: Add MIPI DisCo property helpers

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@...el.com>
> > > Signed-off-by: Vinod Koul <vinod.koul@...el.com>
> > > ---
> > 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