linux-kernel - Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu

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: <20130828194638.AB78E3E0A6F@localhost>
Date:	Wed, 28 Aug 2013 20:46:38 +0100
From:	Grant Likely <grant.likely@...aro.org>
To:	Mark Rutland <mark.rutland@....com>,
	Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@....com>
Cc:	Rob Herring <robherring2@...il.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jonas Bonn <jonas@...thpole.se>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Michal Simek <monstr@...str.eu>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Tomasz Figa <tomasz.figa@...il.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>
Subject: Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures

On Thu, 22 Aug 2013 14:59:30 +0100, Mark Rutland <mark.rutland@....com> wrote:
> On Mon, Aug 19, 2013 at 02:56:10PM +0100, Sudeep KarkadaNagesha wrote:
> > On 19/08/13 14:02, Rob Herring wrote:
> > > On 08/19/2013 05:19 AM, Mark Rutland wrote:
> > >> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote:
> > >>> On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
> > >>>> I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
> > >>>> which 
> > >>>> the updated bindings[1] define #address-cells = <0> and so no reg 
> > >>>> property.
> > >>>>
> > >>>> [1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795
> > >>>
> > >>> Why did you do that in the binding ? That sounds like looking to create
> > >>> problems ... 
> > >>>
> > >>> Traditionally, UP setups just used "0" as the "reg" property on other
> > >>> architectures, why do differently ?
> > >>
> > >> The decision was taken because we defined our reg property to refer to
> > >> the MPIDR register's Aff{2,1,0} bitfields, and on UP cores before v7
> > >> there's no MPIDR register at all. Given there can only be a single CPU
> > >> in that case, describing a register that wasn't present didn't seem
> > >> necessary or helpful.
> > > 
> > > What exactly reg represents is up to the binding definition, but it
> > > still should be present IMO. I don't see any issue with it being
> > > different for pre-v7.
> > > 
> > Yes it's better to have 'reg' with value 0 than not having it.
> > Otherwise this generic of_get_cpu_node implementation would need some
> > _hack_ to handle that case.
> 
> I'm not sure that having some code to handle a difference in standard
> between two architectures is a hack. If anything, I'd argue encoding a
> reg of 0 that corresponds to a nonexistent MPIDR value (given that's
> what the reg property is defined to map to on ARM) is more of a hack ;)
> 
> I'm not averse to having a reg value of 0 for this case, but given that
> there are existing devicetrees without it, requiring a reg property will
> break compatibility with them.

Then special cases those device trees, but you changing existing
convention really needs to be avoided. The referenced documentation
change is brand new, so we're not stuck with it.

g.

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