linux-kernel - Re: [PATCH V3 2/4] of: Add binding document for MIPS GIC

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]

Message-ID: <20141029213431.GF30260@jhogan-linux.le.imgtec.org>
Date:	Wed, 29 Oct 2014 21:34:31 +0000
From:	James Hogan <james.hogan@...tec.com>
To:	Andrew Bresticker <abrestic@...omium.org>
CC:	Ralf Baechle <ralf@...ux-mips.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	"Ian Campbell" <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	John Crispin <blogic@...nwrt.org>,
	David Daney <ddaney.cavm@...il.com>,
	Qais Yousef <qais.yousef@...tec.com>,
	Linux-MIPS <linux-mips@...ux-mips.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Paul <Paul.Burton@...tec.com>
Subject: Re: [PATCH V3 2/4] of: Add binding document for MIPS GIC

Hi Andrew,

On Wed, Oct 29, 2014 at 10:25:27AM -0700, Andrew Bresticker wrote:
> On Wed, Oct 29, 2014 at 10:13 AM, James Hogan <james.hogan@...tec.com> wrote:
> > On 29/10/14 16:55, Andrew Bresticker wrote:
> >> On Wed, Oct 29, 2014 at 2:21 AM, James Hogan <james.hogan@...tec.com> wrote:
> >>> Please lets not do this unless it's actually necessary (which AFAICT it
> >>> really isn't).
> >>
> >> The point of this was to future-proof these bindings and I though that
> >> CPU type was the best way to indicate version in the compatible
> >> string.  This is also how it's done for the ARM GIC and arch timers.
> >> Perhaps the best thing to do is to require both a core-specific
> >> ("mti,interaptiv-gic") and generic ("mti,gic") compatible string and
> >> just match on the generic one for now until there's a need to use the
> >> core-specific one.  Thoughts?
> >
> > FPGA boards like Malta are something else to consider (when it is
> > eventually converted to DT - Paul on CC knows more than me). You might
> > load an interAptiv, or a proAptiv, or a P5600 bitstream, and the gic
> > setup will be pretty much the same I think, since e.g. the address
> > depends on where it is convenient to put it in the address space of the
> > platform.
> 
> Ah, I didn't realize that the CPU bitstream could be changed
> independently of the GIC.

To clarify, the GIC is still closely bound to the CPU and contained
within the FPGA bitstream. The register interface should I believe
always comply with some version of the GIC architecture specification,
and I don't think anybody wants per-bitstream DT files / kernels, so in
practice the way the GIC is set up for Malta (how interrupt lines are
connected up and where in address space GIC can go) is unlikely to
become incompatible.

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