linux-kernel - Re: [PATCH v2 RESEND 2/2] ARM: local timers: add timer support using IO mapped register

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:	Fri, 28 Sep 2012 18:15:53 +0100
From:	Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:	Dave Martin <dave.martin@...aro.org>
Cc:	Rohit Vaswani <rvaswani@...eaurora.org>,
	Mark Rutland <Mark.Rutland@....com>,
	Russell King <linux@....linux.org.uk>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Bryan Huntsman <bryanh@...eaurora.org>,
	Rob Landley <rob@...dley.net>,
	Daniel Walker <dwalker@...o99.com>,
	David Brown <davidb@...eaurora.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>
Subject: Re: [PATCH v2 RESEND 2/2] ARM: local timers: add timer support using
 IO mapped register

On Fri, Sep 28, 2012 at 04:57:46PM +0100, Dave Martin wrote:
> [ Note: please aim to CC devicetree-discuss@...ts.ozlabs.org with any
> patches or bindings relevant to device tree. ]
> 
> [ Lorenzo, there's a question for you further down this mail. ]

[...]

> > > > +  If using the memory mapped interface, list the interrupts for each core,
> > > > +  starting with core 0.
> > 
> > I take it that core 0 means physical cpu 0 (i.e. MPIDR.Aff{2,1,0} == 0)?
> 
> Lorenzo, should we have a standard way of referring to CPUs and topology
> nodes documented as part of the topology bindings?  We certainly need
> rules of some kind, since when the topology is non-trivial there is no
> well-defined "first" CPU, nor any single correct order in which to list
> CPUs.

I think, and that's just my opinion, that whatever solution we go for to
describe the topology must contain the information needed by all kernel
subsystems to retrieve HW information. I do not think we should document
how devices connect to CPU(s)/Cluster(s) in the topology bindings per-se,
since those are properties that belong to device nodes.

There must be a common way for all devices to link to the topology, though.

The topology must be descriptive enough to cater for all required cases
and that's what Mark with PMU and all of us are trying to come up with, a solid
way to represent with DT the topology of current and future ARM systems.

First idea I implemented and related LAK posting:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html

Are "cluster" nodes really needed or "cpu" nodes are enough ? I do not
know, let's get this discussion started, that's all I need.

But definitely declaring IRQs in physical CPU id order (and mind, as you say,
physical CPU ids, ie MPIDR, can be sparsely populated) and initializing them
*thinking* the order is the logical one is plainly broken.

> The topology may also be sparsely populated (e.g.,
> Aff[2,1,0] in { (0,0,0), (0,0,1), (0,1,0), (0,1,1), (0,1,2), (0,1,3) })
> 
> It would be bad if different driver bindings end up solving this in
> different ways (even non-broken ways)

Yes, I agree and code that relies on any temporary work-around to tackle
this problem should not be merged before we set in stone proper topology
bindings.

Lorenzo

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