linux-kernel - Re: [PATCH RFC v2 3/5] spmi: add generic SPMI controller binding documentation

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: <20130827170120.GR4035@joshc.qualcomm.com>
Date:	Tue, 27 Aug 2013 12:01:20 -0500
From:	Josh Cartwright <joshc@...eaurora.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Josh Cartwright <joshc@...eaurora.org>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ian.campbell@...rix.com>,
	Kumar Gala <galak@...eaurora.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-arm-msm@...r.kernel.org,
	Sagar Dharia <sdharia@...eaurora.org>,
	Gilad Avidov <gavidov@...eaurora.org>,
	Michael Bohan <mbohan@...eaurora.org>,
	devicetree@...r.kernel.org
Subject: Re: [PATCH RFC v2 3/5] spmi: add generic SPMI controller binding
 documentation

Hey Stephen-

Thanks for the comments.

On Fri, Aug 23, 2013 at 03:58:36PM -0600, Stephen Warren wrote:
> On 08/22/2013 01:59 PM, Josh Cartwright wrote:
> > Signed-off-by: Josh Cartwright <joshc@...eaurora.org>
> > ---
> > I'm introducing this as an RFC, because there are set of assumptions
> > made in this binding spec, that currently hold true for the supported
> > controller/addressing scheme for the Snapdragon 800 series, but don't
> > necessarily hold true for SPMI in general.
> > 
> >   1. No use of Group Slave Identifiers (GSIDs)
> >      (SPMI allows for a slave to belong to zero or more groups specified
> >      by GSID, however this feature isn't currently implemented)
> > 
> >   2. No specification of Master Identifier (MID)
> >      (A "system integrator" allocates to each master a 2-bit MID, this
> >      currently isn't being specified, as it isn't needed by software for
> >      the PMIC Arb; not sure if this is of use to other SPMI controllers)
> > 
> >   3. Single SPMI master per controller
> > 
> > Effectively, only a subset of possible SPMI configurations are specified
> > in this document.
> > 
> > So, if it's considered necessary to provide a generic SPMI binding
> > specification, is it acceptable to only define a subset at this time,
> > expanding only when necessary, or shall I expand the definition to at
> > least address 1 & 2, even though they are of no use in the current
> > implementation?
> 
> It's best to define the whole thing from the start if possible. It's
> easier to ensure the whole binding is consistent, and nothing has been
> left out.

That makes sense.  I think I'll go down this route for v3 of this
patchset:

For #1 above, extend the 'reg' property of a slave node to include the
group slave ID's in which the slave is a member.  The first 'reg' entry
will remain the slave's Unique Slave Identifier (USID) as before.

For #2, add additional required 'spmi-mid' property in the
controller/master node that describes the 2-bit Master Identifier (MID).

For #3, rename the SPMI API's s/controller/master/.  The current
controller/master terminology difference is confusing and unnecessary.

> However, it's probably OK to define a subset binding initially and then
> expand it later, as long as some thought it put into how it can be
> expanded in a way that is 100% compatible: old DTs will still operate
> with new kernels and perhaps even new DTs will still operate with old
> kernels.
>
> That said, if the thought is put in to ensure that's possible, it's
> probably just as easy to define the whole binding from the start.

That all makes sense.

If we want to ensure for the generic bindings that we are fulling
characterizing/describing the SPMI bus, then we'll additionally need to
tackle an additional identified assumption:

  4. One master per SPMI bus.  (The SPMI spec allows for up to 4
     masters)

On the Snapdragon 800 series, there exists only one software-controlled
master, but it is conceivably possible to have a setup with two
software-controlled masters on the same SPMI bus.

This necessarily means that the description of the slaves and the
masters will need to be decoupled; I'm imagining a generic binding
supporting multiple masters would look something like this:

	master0: master@0 {
		compatible = "...";
		#spmi-master-cells = <0>;
		spmi-mid = <0>;

		...
	};

	master2: master@2 {
		compatible = "...";
		#spmi-master-cells = <0>;
		spmi-mid = <2>;

		...
	};

	spmi_bus {
		compatible = "...";

		spmi-masters = <&master0 &master2>;

		foo@0 {
			compatible = "...";
			reg = <0 ...>;
		};

		foo@8 {
			compatible = "...";
			reg = <8 ...>;
		};
	};

(This will also necessitate a change in the underlying SPMI driver
model, in the current implementation, a SPMI master 'owns' a particular
device.  This is not a valid assumption to make.)

Would this property-containing-phandle-vector be considered the
canonical way of representing nodes with multiple parents in the device
tree?

Thanks,
  Josh

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/