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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 23 Aug 2013 15:58:36 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Josh Cartwright <joshc@...eaurora.org>
CC:	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

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.

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.

--
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/