From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Dave P Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Cho KyongHo <pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org>,
Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TbrhsbdSgBK9A@public.gmane.org>
Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Tue, 17 Jun 2014 13:18:11 +0100 [thread overview]
Message-ID: <20140617121811.GG13808@arm.com> (raw)
In-Reply-To: <20140617115829.GB18816@ulmo>
On Tue, Jun 17, 2014 at 12:58:30PM +0100, Thierry Reding wrote:
> On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote:
> > On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
> > > It can easily be argued that if the algorithm used to remap the ID
> > > varies, the compatibility of the device changes. Therefore I would
> > > expect any variant of the GICv3 that deviates from the "standard"
> > > mapping (if there is such a thing) to have its own compatible string.
> >
> > There is no standard mapping; it's a property defined at system integration
> > time. I fully expect different SoCs to do different things here.
>
> My point was that the mapping itself seems to be fundamental enough to
> make devices with different mappings "incompatible". Therefore I think
> this could probably be handled by using different compatible values,
> something along the lines of this:
>
> compatible = "vendor,soc-gicv3", "arm,gicv3";
>
> Then the mapping can be described in code, which should be a whole lot
> easier and more flexible than a more or less generic notation in device
> tree.
I don't think that scales well beyond a handful of unique mappings, and I
really anticipate everybody doing something different based on their
integration constraints.
You'd very quickly end up with sets of tables for each SoC, describing the
topology and associated IDs in the kernel source, which feels like a giant
step backwards from where we are today with device tree.
If, for example, the GIC architecture prescribed a fixed set of Device IDs
and an algorithm for converting from Stream IDs then your approach may have
some merits, but that's not where we are today (and I also don't think it's
practical to try and enforce such system-wide properties into an interrupt
controller architecture).
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Dave P Martin <Dave.Martin@arm.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <Pawel.Moll@arm.com>,
Mark Rutland <Mark.Rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Cho KyongHo <pullip.cho@samsung.com>,
Grant Grundler <grundler@chromium.org>,
Marc Zyngier <Marc.Zyngier@arm.com>,
Joerg Roedel <joro@8bytes.org>, Hiroshi Doyu <hdoyu@nvidia.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Tue, 17 Jun 2014 13:18:11 +0100 [thread overview]
Message-ID: <20140617121811.GG13808@arm.com> (raw)
In-Reply-To: <20140617115829.GB18816@ulmo>
On Tue, Jun 17, 2014 at 12:58:30PM +0100, Thierry Reding wrote:
> On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote:
> > On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
> > > It can easily be argued that if the algorithm used to remap the ID
> > > varies, the compatibility of the device changes. Therefore I would
> > > expect any variant of the GICv3 that deviates from the "standard"
> > > mapping (if there is such a thing) to have its own compatible string.
> >
> > There is no standard mapping; it's a property defined at system integration
> > time. I fully expect different SoCs to do different things here.
>
> My point was that the mapping itself seems to be fundamental enough to
> make devices with different mappings "incompatible". Therefore I think
> this could probably be handled by using different compatible values,
> something along the lines of this:
>
> compatible = "vendor,soc-gicv3", "arm,gicv3";
>
> Then the mapping can be described in code, which should be a whole lot
> easier and more flexible than a more or less generic notation in device
> tree.
I don't think that scales well beyond a handful of unique mappings, and I
really anticipate everybody doing something different based on their
integration constraints.
You'd very quickly end up with sets of tables for each SoC, describing the
topology and associated IDs in the kernel source, which feels like a giant
step backwards from where we are today with device tree.
If, for example, the GIC architecture prescribed a fixed set of Device IDs
and an algorithm for converting from Stream IDs then your approach may have
some merits, but that's not where we are today (and I also don't think it's
practical to try and enforce such system-wide properties into an interrupt
controller architecture).
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Tue, 17 Jun 2014 13:18:11 +0100 [thread overview]
Message-ID: <20140617121811.GG13808@arm.com> (raw)
In-Reply-To: <20140617115829.GB18816@ulmo>
On Tue, Jun 17, 2014 at 12:58:30PM +0100, Thierry Reding wrote:
> On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote:
> > On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
> > > It can easily be argued that if the algorithm used to remap the ID
> > > varies, the compatibility of the device changes. Therefore I would
> > > expect any variant of the GICv3 that deviates from the "standard"
> > > mapping (if there is such a thing) to have its own compatible string.
> >
> > There is no standard mapping; it's a property defined at system integration
> > time. I fully expect different SoCs to do different things here.
>
> My point was that the mapping itself seems to be fundamental enough to
> make devices with different mappings "incompatible". Therefore I think
> this could probably be handled by using different compatible values,
> something along the lines of this:
>
> compatible = "vendor,soc-gicv3", "arm,gicv3";
>
> Then the mapping can be described in code, which should be a whole lot
> easier and more flexible than a more or less generic notation in device
> tree.
I don't think that scales well beyond a handful of unique mappings, and I
really anticipate everybody doing something different based on their
integration constraints.
You'd very quickly end up with sets of tables for each SoC, describing the
topology and associated IDs in the kernel source, which feels like a giant
step backwards from where we are today with device tree.
If, for example, the GIC architecture prescribed a fixed set of Device IDs
and an algorithm for converting from Stream IDs then your approach may have
some merits, but that's not where we are today (and I also don't think it's
practical to try and enforce such system-wide properties into an interrupt
controller architecture).
Will
next prev parent reply other threads:[~2014-06-17 12:18 UTC|newest]
Thread overview: 215+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 20:36 [PATCH v2] devicetree: Add generic IOMMU device tree bindings Thierry Reding
2014-05-23 20:36 ` Thierry Reding
2014-05-23 20:36 ` Thierry Reding
[not found] ` <1400877395-4235-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-29 15:52 ` Stephen Warren
2014-05-29 15:52 ` Stephen Warren
2014-05-29 15:52 ` Stephen Warren
2014-05-30 7:30 ` Thierry Reding
2014-05-30 7:30 ` Thierry Reding
2014-05-30 11:27 ` Dave Martin
2014-05-30 11:27 ` Dave Martin
2014-05-30 11:27 ` Dave Martin
[not found] ` <20140530112728.GB3949-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-30 19:11 ` Arnd Bergmann
2014-05-30 19:11 ` Arnd Bergmann
2014-05-30 19:11 ` Arnd Bergmann
2014-06-02 10:56 ` Dave Martin
2014-06-02 10:56 ` Dave Martin
2014-06-02 10:56 ` Dave Martin
2014-06-04 21:12 ` Thierry Reding
2014-06-04 21:12 ` Thierry Reding
2014-06-04 21:12 ` Thierry Reding
2014-06-16 12:57 ` Will Deacon
2014-06-16 12:57 ` Will Deacon
2014-06-16 12:57 ` Will Deacon
2014-06-17 11:58 ` Thierry Reding
2014-06-17 11:58 ` Thierry Reding
2014-06-17 11:58 ` Thierry Reding
2014-06-17 12:18 ` Will Deacon [this message]
2014-06-17 12:18 ` Will Deacon
2014-06-17 12:18 ` Will Deacon
2014-06-17 23:37 ` Thierry Reding
2014-06-17 23:37 ` Thierry Reding
2014-06-17 23:37 ` Thierry Reding
2014-06-18 10:14 ` Will Deacon
2014-06-18 10:14 ` Will Deacon
2014-06-18 10:14 ` Will Deacon
[not found] ` <20140618101439.GF32699-5wv7dgnIgG8@public.gmane.org>
2014-06-20 15:53 ` Arnd Bergmann
2014-06-20 15:53 ` Arnd Bergmann
2014-06-20 15:53 ` Arnd Bergmann
2014-06-20 17:50 ` Will Deacon
2014-06-20 17:50 ` Will Deacon
2014-06-20 17:50 ` Will Deacon
2014-06-20 18:55 ` Arnd Bergmann
2014-06-20 18:55 ` Arnd Bergmann
2014-06-20 18:55 ` Arnd Bergmann
2014-05-30 11:22 ` Dave Martin
2014-05-30 11:22 ` Dave Martin
2014-05-30 11:22 ` Dave Martin
[not found] ` <20140530112226.GA3949-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-30 19:01 ` Arnd Bergmann
2014-05-30 19:01 ` Arnd Bergmann
2014-05-30 19:01 ` Arnd Bergmann
2014-06-02 11:44 ` Dave Martin
2014-06-02 11:44 ` Dave Martin
2014-06-02 11:44 ` Dave Martin
2014-06-04 21:32 ` Thierry Reding
2014-06-04 21:32 ` Thierry Reding
2014-06-04 21:32 ` Thierry Reding
2014-06-05 9:42 ` Arnd Bergmann
2014-06-05 9:42 ` Arnd Bergmann
2014-06-05 9:42 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2014-06-06 22:45 Thierry Reding
2014-06-06 22:45 ` Thierry Reding
2014-06-07 13:22 ` Arnd Bergmann
2014-06-07 13:22 ` Arnd Bergmann
2014-06-07 13:22 ` Arnd Bergmann
2014-06-09 10:49 ` Thierry Reding
2014-06-09 10:49 ` Thierry Reding
2014-06-09 10:49 ` Thierry Reding
2014-05-23 20:33 Thierry Reding
[not found] ` <1400877218-4113-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-30 13:16 ` Rob Herring
2014-05-30 13:16 ` Rob Herring
2014-05-30 13:16 ` Rob Herring
[not found] ` <CAL_JsqKumG1PSFoVfeGpLLG+MjXFeF4aUjun=vv1BJpaxk0Byg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-30 19:06 ` Arnd Bergmann
2014-05-30 19:06 ` Arnd Bergmann
2014-05-30 19:06 ` Arnd Bergmann
2014-05-30 19:29 ` Hiroshi Doyu
2014-05-30 19:29 ` Hiroshi Doyu
2014-05-30 19:29 ` Hiroshi Doyu
2014-05-30 19:54 ` Arnd Bergmann
2014-05-30 19:54 ` Arnd Bergmann
2014-05-30 19:54 ` Arnd Bergmann
2014-06-01 9:55 ` Will Deacon
2014-06-01 9:55 ` Will Deacon
2014-06-01 9:55 ` Will Deacon
[not found] ` <20140601095546.GA8625-5wv7dgnIgG8@public.gmane.org>
2014-06-04 13:39 ` Thierry Reding
2014-06-04 13:39 ` Thierry Reding
2014-06-04 13:39 ` Thierry Reding
2014-06-04 13:44 ` Thierry Reding
2014-06-04 13:44 ` Thierry Reding
2014-06-04 13:44 ` Thierry Reding
2014-06-04 13:53 ` Arnd Bergmann
2014-06-04 13:53 ` Arnd Bergmann
2014-06-04 13:53 ` Arnd Bergmann
2014-06-04 13:56 ` Will Deacon
2014-06-04 13:56 ` Will Deacon
2014-06-04 13:56 ` Will Deacon
[not found] ` <20140604135600.GD6644-5wv7dgnIgG8@public.gmane.org>
2014-06-04 14:01 ` Arnd Bergmann
2014-06-04 14:01 ` Arnd Bergmann
2014-06-04 14:01 ` Arnd Bergmann
2014-06-04 16:39 ` Will Deacon
2014-06-04 16:39 ` Will Deacon
2014-06-04 16:39 ` Will Deacon
2014-05-30 19:31 ` Rob Herring
2014-05-30 19:31 ` Rob Herring
2014-05-30 19:31 ` Rob Herring
[not found] ` <CAL_Jsq+tkFNpjSEZboT+o69B_Z3a8e-ZVKaYDmLwtkyYoPy6VQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-30 19:49 ` Arnd Bergmann
2014-05-30 19:49 ` Arnd Bergmann
2014-05-30 19:49 ` Arnd Bergmann
2014-06-02 10:41 ` Dave Martin
2014-06-02 10:41 ` Dave Martin
2014-06-02 10:41 ` Dave Martin
[not found] ` <20140602104104.GD3855-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-06-04 14:35 ` Thierry Reding
2014-06-04 14:35 ` Thierry Reding
2014-06-04 14:35 ` Thierry Reding
2014-06-04 16:41 ` Will Deacon
2014-06-04 16:41 ` Will Deacon
2014-06-04 16:41 ` Will Deacon
[not found] ` <20140604164132.GF6644-5wv7dgnIgG8@public.gmane.org>
2014-06-04 21:00 ` Thierry Reding
2014-06-04 21:00 ` Thierry Reding
2014-06-04 21:00 ` Thierry Reding
2014-06-05 19:10 ` Varun Sethi
2014-06-05 19:10 ` Varun Sethi
2014-06-05 19:10 ` Varun Sethi
2014-06-16 15:27 ` Will Deacon
2014-06-16 15:27 ` Will Deacon
2014-06-16 15:27 ` Will Deacon
[not found] ` <20140616152739.GS16758-5wv7dgnIgG8@public.gmane.org>
2014-06-16 16:56 ` Stuart Yoder
2014-06-16 16:56 ` Stuart Yoder
2014-06-16 16:56 ` Stuart Yoder
[not found] ` <8b0492b4697943a0b1f276ef42cc8223-ufbTtyGzTTT8GZusEWM6WuO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-16 17:04 ` Will Deacon
2014-06-16 17:04 ` Will Deacon
2014-06-16 17:04 ` Will Deacon
[not found] ` <20140616170416.GA16758-5wv7dgnIgG8@public.gmane.org>
2014-06-16 17:30 ` Arnd Bergmann
2014-06-16 17:30 ` Arnd Bergmann
2014-06-16 17:30 ` Arnd Bergmann
2014-06-16 18:53 ` Stuart Yoder
2014-06-16 18:53 ` Stuart Yoder
2014-06-16 18:53 ` Stuart Yoder
[not found] ` <419e67f783524d208ab3be16bcd94bd9-ufbTtyGzTTT8GZusEWM6WuO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-17 10:26 ` Varun Sethi
2014-06-17 10:26 ` Varun Sethi
2014-06-17 10:26 ` Varun Sethi
[not found] ` <0587e1f4894546398be0798d2bc2c84f-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-17 10:43 ` Will Deacon
2014-06-17 10:43 ` Will Deacon
2014-06-17 10:43 ` Will Deacon
[not found] ` <20140617104304.GD13808-5wv7dgnIgG8@public.gmane.org>
2014-06-17 11:21 ` Varun Sethi
2014-06-17 11:21 ` Varun Sethi
2014-06-17 11:21 ` Varun Sethi
[not found] ` <32165315f0b84be9948f489fd87bf6a9-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-17 14:50 ` Stuart Yoder
2014-06-17 14:50 ` Stuart Yoder
2014-06-17 14:50 ` Stuart Yoder
2014-06-18 9:29 ` Will Deacon
2014-06-18 9:29 ` Will Deacon
2014-06-18 9:29 ` Will Deacon
2014-06-17 14:39 ` Stuart Yoder
2014-06-17 14:39 ` Stuart Yoder
2014-06-17 14:39 ` Stuart Yoder
2014-06-20 23:16 ` Olav Haugan
2014-06-20 23:16 ` Olav Haugan
2014-06-20 23:16 ` Olav Haugan
2014-06-24 9:18 ` Will Deacon
2014-06-24 9:18 ` Will Deacon
2014-06-24 9:18 ` Will Deacon
[not found] ` <20140624091808.GC26013-5wv7dgnIgG8@public.gmane.org>
2014-06-24 17:57 ` Olav Haugan
2014-06-24 17:57 ` Olav Haugan
2014-06-24 17:57 ` Olav Haugan
2014-06-24 18:11 ` Will Deacon
2014-06-24 18:11 ` Will Deacon
2014-06-24 18:11 ` Will Deacon
[not found] ` <20140624181150.GB4067-5wv7dgnIgG8@public.gmane.org>
2014-06-24 18:20 ` Arnd Bergmann
2014-06-24 18:20 ` Arnd Bergmann
2014-06-24 18:20 ` Arnd Bergmann
2014-06-25 9:17 ` Will Deacon
2014-06-25 9:17 ` Will Deacon
2014-06-25 9:17 ` Will Deacon
2014-06-25 9:27 ` Arnd Bergmann
2014-06-25 9:27 ` Arnd Bergmann
2014-06-25 9:27 ` Arnd Bergmann
2014-06-25 9:38 ` Will Deacon
2014-06-25 9:38 ` Will Deacon
2014-06-25 9:38 ` Will Deacon
2014-06-25 9:48 ` Arnd Bergmann
2014-06-25 9:48 ` Arnd Bergmann
2014-06-25 9:48 ` Arnd Bergmann
2014-06-25 9:57 ` Will Deacon
2014-06-25 9:57 ` Will Deacon
2014-06-25 9:57 ` Will Deacon
[not found] ` <20140625095735.GI6153-5wv7dgnIgG8@public.gmane.org>
2014-06-25 10:12 ` Arnd Bergmann
2014-06-25 10:12 ` Arnd Bergmann
2014-06-25 10:12 ` Arnd Bergmann
2014-06-25 10:14 ` Will Deacon
2014-06-25 10:14 ` Will Deacon
2014-06-25 10:14 ` Will Deacon
2014-06-24 21:35 ` Olav Haugan
2014-06-24 21:35 ` Olav Haugan
2014-06-24 21:35 ` Olav Haugan
[not found] ` <53A9EF3A.2070704-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-06-25 9:18 ` Will Deacon
2014-06-25 9:18 ` Will Deacon
2014-06-25 9:18 ` Will Deacon
[not found] ` <20140625091858.GG6153-5wv7dgnIgG8@public.gmane.org>
2014-06-27 22:23 ` Olav Haugan
2014-06-27 22:23 ` Olav Haugan
2014-06-27 22:23 ` Olav Haugan
[not found] ` <53ADEEDF.7060902-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-06-30 9:52 ` Will Deacon
2014-06-30 9:52 ` Will Deacon
2014-06-30 9:52 ` Will Deacon
2014-07-09 1:07 ` Olav Haugan
2014-07-09 1:07 ` Olav Haugan
2014-07-09 1:07 ` Olav Haugan
[not found] ` <53BC95DA.1010500-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-07-09 10:54 ` Will Deacon
2014-07-09 10:54 ` Will Deacon
2014-07-09 10:54 ` Will Deacon
[not found] ` <20140709105441.GE9485-5wv7dgnIgG8@public.gmane.org>
2014-07-10 22:32 ` Olav Haugan
2014-07-10 22:32 ` Olav Haugan
2014-07-10 22:32 ` Olav Haugan
2014-07-11 12:24 ` Will Deacon
2014-07-11 12:24 ` Will Deacon
2014-07-11 12:24 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140617121811.GG13808@arm.com \
--to=will.deacon-5wv7dgnigg8@public.gmane.org \
--cc=Dave.Martin-5wv7dgnIgG8@public.gmane.org \
--cc=Marc.Zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=Mark.Rutland-5wv7dgnIgG8@public.gmane.org \
--cc=Pawel.Moll-5wv7dgnIgG8@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TbrhsbdSgBK9A@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.