linux-kernel - Re: [PATCH V5 2/6] of/slimbus: OF helper for SLIMbus

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]

Date:	Tue, 03 May 2016 21:26:25 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Rob Herring <robh@...nel.org>
Cc:	Sagar Dharia <sdharia@...eaurora.org>, gregkh@...uxfoundation.org,
	bp@...e.de, poeschel@...onage.de, treding@...dia.com,
	broonie@...nel.org, gong.chen@...ux.intel.com,
	andreas.noever@...il.com, alan@...ux.intel.com,
	mathieu.poirier@...aro.org, daniel@...ll.ch, jkosina@...e.cz,
	sharon.dvir1@...l.huji.ac.il, joe@...ches.com, davem@...emloft.net,
	james.hogan@...tec.com, michael.opdenacker@...e-electrons.com,
	daniel.thompson@...aro.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, kheitke@...ience.com,
	mlocke@...eaurora.org, agross@...eaurora.org,
	sheetal.tigadoli@...il.com, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH V5 2/6] of/slimbus: OF helper for SLIMbus

On Tuesday 03 May 2016 11:11:56 Rob Herring wrote:
> > +
> > +Child nodes:
> > +Every SLIMbus controller node can contain zero or more child nodes
> > +representing slave devices on the bus. Every SLIMbus slave device is
> > +uniquely determined by the enumeration address containing 4 fields:
> > +Manufacturer ID, Product code, Device index, and Instance value for
> > +the device.
> > +If child node is not present and it is instantiated after device
> > +discovery (slave device reporting itself present),
> > +its name will be in this format: "217:60:1:0"
> > +
> > +However, the device may need additional non-standard way to power it
> > +up so that it can start functioning. In that case, child node will
> > +need to be present as slave of the slimbus-controller device.
> > +The compatible property will be necessary so that corresponding
> > +driver can probe and execute the required procedure to make it
> > +functional.
> > +
> > +Required property for SLIMbus child node if it is present:
> > +- reg                - enumeration address fields of the device
> > +
> > +- compatible - name of SLIMbus child node using practice typically
> > +             followed by discoverable buses:
> > +             "<manufacturer>,<product-model>", "slim"
> 
> Im most cases for compatible strings on discoverable buses, the VID and 
> PID (and perhaps more) are used to form the compatible string. See USB 
> binding for a recent example. This will save you from having to make up 
> strings for every device.

Actually it seems like the current binding puts the same manufacturer ID
and product ID pair into both address and compatible string. Is that
correct?

I would have expected the address to have only index and instance fields
and the compatible string match whatever we can detect by looking at
that device. This has probably been discussed 5 years ago when the
patches were first posted, but I don't remember the outcome.

	Arnd