Message-ID: <20141029174611.GB26471@leverpostej>
Date:	Wed, 29 Oct 2014 17:46:12 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Qais Yousef <qais.yousef@...tec.com>
Cc:	Andrew Bresticker <abrestic@...omium.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <Pawel.Moll@....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>,
	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>
Subject: Re: [PATCH V3 2/4] of: Add binding document for MIPS GIC

On Wed, Oct 29, 2014 at 05:23:59PM +0000, Qais Yousef wrote:
> On 10/29/2014 05:08 PM, Andrew Bresticker wrote:
> > On Wed, Oct 29, 2014 at 4:09 AM, Qais Yousef <qais.yousef@...tec.com> wrote:
> >> On 10/29/2014 12:12 AM, Andrew Bresticker wrote:
> >>> +- reg : Base address and length of the GIC registers.
> >>>
> >> Also except for sead3, the base address should be properly reported by the
> >> hardware. The size is fixed (for a specific version of GIC at least - which
> >> is also reported by the hardware). So it would be nice to make this
> >> optional.
> > Even though this is usually probable, I'd prefer to leave this as
> > required, or at least "optional, but recommended".  I don't have a
> > very strong opinion on it though, but perhaps the device-tree folks
> > do?

It boils down to how reliable the values you can read out of the HW are.
If it can always be probed reliably, then the property isn't strictly
necessary. However, the fact that you can probe it now doesn't mean you
can always probe it reliably (e.g. a future CPU's reporting mechanism
might be different, or values might be plain wrong). It depends on what
you expect in future in that regard.

As an example, for a while on ARM we thought we could probe the number
of CPUs present from the HW, but new CPUs and multi-cluster designs
broke our assumptions there. Now we just rely on the /cpus node
containing the appropriate cpu sub-nodes (regardless of whether this
could be probed for a particular CPU/SoC). Luckily we were able to
change that as we were still in the early days of DT conversion.

So consider the possible ways your current probing mechanism is
realistically likely to be broken. If there are clear ways of working
around that, you're probably fine with an optional property. If it looks
like things could change substantially, require the property for now --
you can always ignore it in future if things turn out to be reliably
probeable through other means.

> The biggest advantage I can think of is that it can potentially make GIC 
> DT definition more shareable across for instance multiple revisions of 
> an SoC that might have the GIC at different base addresses.

For the different revisions of an SoC, I would expect that if your
interrupt controller moved other elements would also? A layer or two of
dtsi files can keep all the common stuff common while allowing
per-revision changes.

> I won't insist too much though.

Similarly, I don't really have a strong opinion either way. There's no
single answer on this.

Thanks,
Mark.
--
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/

Powered by blists - more mailing lists