linux-kernel - Re: [alsa-devel] [PATCH 01/14] Documentation: Add SoundWire summary

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: <20171023111813.GF936@localhost>
Date:   Mon, 23 Oct 2017 16:48:13 +0530
From:   Vinod Koul <vinod.koul@...el.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     ALSA <alsa-devel@...a-project.org>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Sudheer Papothi <spapothi@...eaurora.org>,
        Takashi <tiwai@...e.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        plai@...eaurora.org, LKML <linux-kernel@...r.kernel.org>,
        Pierre <pierre-louis.bossart@...ux.intel.com>,
        patches.audio@...el.com, srinivas.kandagatla@...aro.org,
        Shreyas NC <shreyas.nc@...el.com>,
        Sanyog Kale <sanyog.r.kale@...el.com>,
        Sagar Dharia <sdharia@...eaurora.org>, alan@...ux.intel.com
Subject: Re: [alsa-devel] [PATCH 01/14] Documentation: Add SoundWire summary

On Mon, Oct 23, 2017 at 08:50:50AM +0100, Mark Brown wrote:
> On Sat, Oct 21, 2017 at 04:58:40PM +0530, Vinod Koul wrote:
> > On Sat, Oct 21, 2017 at 09:57:44AM +0100, Mark Brown wrote:
> 
> > > There's lots of perfectly normal nouns in this document like Slave here
> > > which are randomly capitalized.  Is there some great reason for this?
> > > It makes the document pretty distracting to read.
> 
> > Slave, SoundWire etc are MIPI definitions hence capitalized.
> 
> Slave?  Really?
> 
> > > > +provides capabilities information. DT support is not implemented at this
> > > > +time but should be trivial to add since capabilities are enabled with the
> > > > +device_property_ API.
> 
> > > Since we're making this up from whole cloth rather than following an
> > > existing standard let's get a DT binding document together and review
> > > the properties that are getting defined.
> 
> > I don't have a DT to test, but looking at Slimbus code I guess assumptions
> > are fair and we seem to have similar concepts and implementation.
> 
> That's fine, we can still review binding documents.

I am not really sure about that part, let me see if I can come up or worst
case not talk about DT at all.

> > > > +The MIPI specification requires each Slave interface to expose a unique
> > > > +48-bit identifier, stored in 6 read only dev_id registers. This dev_id
> > > > +identifier contains vendor and part information, as well as a field enabling
> > > > +to differentiate between identical components. An additional class field is
> > > > +currently unused. Slave driver is written for the specific 48-bit
> > > > +identifier, Bus enumerates the Slave device based on the 48-bit identifier.
> 
> > > So this says that the instance identifer is part of the device
> > > identifier but the driver should bind to the whole device identifer?
> > > I'd expect the driver to bind to everything except the instance
> > > identifer.
> 
> > Other parts are still TBD and not really used, like Device Class, Spec
> > version. We are using only mfg id and part id for binding.
> 
> That's not what the document claims.

Sorry about that fixed now. Thanks for pointing

-- 
~Vinod