From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>
Cc: Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@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>,
Will Deacon <Will.Deacon-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@vge>
Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Fri, 30 May 2014 21:11:07 +0200 [thread overview]
Message-ID: <4663172.oXIylQOrlk@wuerfel> (raw)
In-Reply-To: <20140530112728.GB3949-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
On Friday 30 May 2014 12:27:28 Dave Martin wrote:
> On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
> > On Thu, May 29, 2014 at 09:52:22AM -0600, Stephen Warren wrote:
> > > On 05/23/2014 02:36 PM, Thierry Reding wrote:
> > > I think this is a mistake. address-cells/size-cells are for transactions
> > > flowing down the bus (from the CPU to date). Describing a connection
> > > from a device to an IOMMU is something completely different, and should
> > > therefore simply use an iommu-cells property to describe any necessary
> > > information. If we start re-using properties for different things in
> > > different contexts, how is anyone going to know what they mean, and how
> > > will conflicts be resolved. For example, what if there's a single HW
> > > module that both acts as a regular register bus with children (where
> > > address-cells/size-cells defines how transactions reach the children
> > > from the parent), and is also an IOMMU (where according to this binding
> > > proposal, address-cells/size-cells represent some aspect of the IOMMU
> > > feature). Using different properties for different things is the only
> > > sane way to keep different concepts separate. Another alternative would
> > > be to represent the single HW module as separate nodes in DT, but I
> > > think that will only make our lives harder, and where I've done that in
> > > the past, I've regretted it.
> >
> > There was some back-and-forth on this topic and the latest concensus
> > when I wrote the second version was that #address-cells and #size-cells
> > were to be used.
> >
> > But there was some bore back-and-forth after that, and it seems like
> > Arnd no longer thinks that using #address-cells and #size-cells is a
> > good idea either[0].
>
> Mistake or not, ePAPR already (ab)uses the address concept for PCI.
> Unless ePAPR is wrong, I don't think it makes sense to argue that
> the address concept cannot be repurposed.
>
> The reason why this is abused for PCI is the same as our reason here:
> different masters really are treated as distinct even when accessing
> the same destination address, and DT has no general native way to
> describe that.
>
> One clear advantage of using #address-cells etc. is that ePAPR already
> has very clear and well-defined ways of how to specify range mappings.
> This gives us a ready-made way to describe windowed IOMMUs and 1:1
> remappings of whole blocks of master IDs, which are the most obvious
> cases other than having a small-integer set of explicit IDs.
>
> That said, the PCI pseudo-address thing is not something we _necessarily_
> want to repeat.
I'm really impartial to the question of whether to use #address-cells
or #iommus now. It's possible that we can use the addresses in some
meaningful way, but it's not clear to me that this will help make the
representation cleaner or that we will actually want it for SMMU.
> > Arnd, can you take another look at this binding and see if there's
> > anything else missing? If not I'll go through the document again and
> > update all #address-cells/#size-cells references with #iommu-cells as
> > appropriate and submit v3.
>
> How do you envisage propagation of the master ID bits downstream of the
> IOMMU would be described?
>
> We will definitely need a way to describe this for GICv3. How those
> values are propagated is likely to vary between related SoCs and doesn't
> feel like it should be baked into a driver, especially for the ARM SMMU
> which may get reused in radically different SoC families from different
> vendors.
>
> The most likely types of remapping are the adding of a base offset or
> some extra bits to the ID -- because not all MSIs to the GIC will
> necessarily pass through the IOMMU. It's also possible that we might
> see ID squashing or folding in some systems.
>
>
> For types of remapping which mix the ID and address together, I now
> do tend to agree that any flexibility arising from describing that
> in a general way that is unlikely to repay the cost of trying to
> interpret and analyse the DT. Defining a few sterotypical kinds
> of mapping explicitly, as needed, looks more sensible for now. The
> windowed-IOMMU case is one example.
For MSI, my feeling is that we'd just be best off doing an end-to-end
description. Any device using an MSI would have an interrupt specifier
that is sufficient for the interrupt controller to understand where
the IRQ comes from, and return an address/value pair back to the driver
to program into some register.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Stephen Warren <swarren@wwwdotorg.org>,
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>,
Will Deacon <Will.Deacon@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: Fri, 30 May 2014 21:11:07 +0200 [thread overview]
Message-ID: <4663172.oXIylQOrlk@wuerfel> (raw)
In-Reply-To: <20140530112728.GB3949@e103592.cambridge.arm.com>
On Friday 30 May 2014 12:27:28 Dave Martin wrote:
> On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
> > On Thu, May 29, 2014 at 09:52:22AM -0600, Stephen Warren wrote:
> > > On 05/23/2014 02:36 PM, Thierry Reding wrote:
> > > I think this is a mistake. address-cells/size-cells are for transactions
> > > flowing down the bus (from the CPU to date). Describing a connection
> > > from a device to an IOMMU is something completely different, and should
> > > therefore simply use an iommu-cells property to describe any necessary
> > > information. If we start re-using properties for different things in
> > > different contexts, how is anyone going to know what they mean, and how
> > > will conflicts be resolved. For example, what if there's a single HW
> > > module that both acts as a regular register bus with children (where
> > > address-cells/size-cells defines how transactions reach the children
> > > from the parent), and is also an IOMMU (where according to this binding
> > > proposal, address-cells/size-cells represent some aspect of the IOMMU
> > > feature). Using different properties for different things is the only
> > > sane way to keep different concepts separate. Another alternative would
> > > be to represent the single HW module as separate nodes in DT, but I
> > > think that will only make our lives harder, and where I've done that in
> > > the past, I've regretted it.
> >
> > There was some back-and-forth on this topic and the latest concensus
> > when I wrote the second version was that #address-cells and #size-cells
> > were to be used.
> >
> > But there was some bore back-and-forth after that, and it seems like
> > Arnd no longer thinks that using #address-cells and #size-cells is a
> > good idea either[0].
>
> Mistake or not, ePAPR already (ab)uses the address concept for PCI.
> Unless ePAPR is wrong, I don't think it makes sense to argue that
> the address concept cannot be repurposed.
>
> The reason why this is abused for PCI is the same as our reason here:
> different masters really are treated as distinct even when accessing
> the same destination address, and DT has no general native way to
> describe that.
>
> One clear advantage of using #address-cells etc. is that ePAPR already
> has very clear and well-defined ways of how to specify range mappings.
> This gives us a ready-made way to describe windowed IOMMUs and 1:1
> remappings of whole blocks of master IDs, which are the most obvious
> cases other than having a small-integer set of explicit IDs.
>
> That said, the PCI pseudo-address thing is not something we _necessarily_
> want to repeat.
I'm really impartial to the question of whether to use #address-cells
or #iommus now. It's possible that we can use the addresses in some
meaningful way, but it's not clear to me that this will help make the
representation cleaner or that we will actually want it for SMMU.
> > Arnd, can you take another look at this binding and see if there's
> > anything else missing? If not I'll go through the document again and
> > update all #address-cells/#size-cells references with #iommu-cells as
> > appropriate and submit v3.
>
> How do you envisage propagation of the master ID bits downstream of the
> IOMMU would be described?
>
> We will definitely need a way to describe this for GICv3. How those
> values are propagated is likely to vary between related SoCs and doesn't
> feel like it should be baked into a driver, especially for the ARM SMMU
> which may get reused in radically different SoC families from different
> vendors.
>
> The most likely types of remapping are the adding of a base offset or
> some extra bits to the ID -- because not all MSIs to the GIC will
> necessarily pass through the IOMMU. It's also possible that we might
> see ID squashing or folding in some systems.
>
>
> For types of remapping which mix the ID and address together, I now
> do tend to agree that any flexibility arising from describing that
> in a general way that is unlikely to repay the cost of trying to
> interpret and analyse the DT. Defining a few sterotypical kinds
> of mapping explicitly, as needed, looks more sensible for now. The
> windowed-IOMMU case is one example.
For MSI, my feeling is that we'd just be best off doing an end-to-end
description. Any device using an MSI would have an interrupt specifier
that is sufficient for the interrupt controller to understand where
the IRQ comes from, and return an address/value pair back to the driver
to program into some register.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Fri, 30 May 2014 21:11:07 +0200 [thread overview]
Message-ID: <4663172.oXIylQOrlk@wuerfel> (raw)
In-Reply-To: <20140530112728.GB3949@e103592.cambridge.arm.com>
On Friday 30 May 2014 12:27:28 Dave Martin wrote:
> On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
> > On Thu, May 29, 2014 at 09:52:22AM -0600, Stephen Warren wrote:
> > > On 05/23/2014 02:36 PM, Thierry Reding wrote:
> > > I think this is a mistake. address-cells/size-cells are for transactions
> > > flowing down the bus (from the CPU to date). Describing a connection
> > > from a device to an IOMMU is something completely different, and should
> > > therefore simply use an iommu-cells property to describe any necessary
> > > information. If we start re-using properties for different things in
> > > different contexts, how is anyone going to know what they mean, and how
> > > will conflicts be resolved. For example, what if there's a single HW
> > > module that both acts as a regular register bus with children (where
> > > address-cells/size-cells defines how transactions reach the children
> > > from the parent), and is also an IOMMU (where according to this binding
> > > proposal, address-cells/size-cells represent some aspect of the IOMMU
> > > feature). Using different properties for different things is the only
> > > sane way to keep different concepts separate. Another alternative would
> > > be to represent the single HW module as separate nodes in DT, but I
> > > think that will only make our lives harder, and where I've done that in
> > > the past, I've regretted it.
> >
> > There was some back-and-forth on this topic and the latest concensus
> > when I wrote the second version was that #address-cells and #size-cells
> > were to be used.
> >
> > But there was some bore back-and-forth after that, and it seems like
> > Arnd no longer thinks that using #address-cells and #size-cells is a
> > good idea either[0].
>
> Mistake or not, ePAPR already (ab)uses the address concept for PCI.
> Unless ePAPR is wrong, I don't think it makes sense to argue that
> the address concept cannot be repurposed.
>
> The reason why this is abused for PCI is the same as our reason here:
> different masters really are treated as distinct even when accessing
> the same destination address, and DT has no general native way to
> describe that.
>
> One clear advantage of using #address-cells etc. is that ePAPR already
> has very clear and well-defined ways of how to specify range mappings.
> This gives us a ready-made way to describe windowed IOMMUs and 1:1
> remappings of whole blocks of master IDs, which are the most obvious
> cases other than having a small-integer set of explicit IDs.
>
> That said, the PCI pseudo-address thing is not something we _necessarily_
> want to repeat.
I'm really impartial to the question of whether to use #address-cells
or #iommus now. It's possible that we can use the addresses in some
meaningful way, but it's not clear to me that this will help make the
representation cleaner or that we will actually want it for SMMU.
> > Arnd, can you take another look at this binding and see if there's
> > anything else missing? If not I'll go through the document again and
> > update all #address-cells/#size-cells references with #iommu-cells as
> > appropriate and submit v3.
>
> How do you envisage propagation of the master ID bits downstream of the
> IOMMU would be described?
>
> We will definitely need a way to describe this for GICv3. How those
> values are propagated is likely to vary between related SoCs and doesn't
> feel like it should be baked into a driver, especially for the ARM SMMU
> which may get reused in radically different SoC families from different
> vendors.
>
> The most likely types of remapping are the adding of a base offset or
> some extra bits to the ID -- because not all MSIs to the GIC will
> necessarily pass through the IOMMU. It's also possible that we might
> see ID squashing or folding in some systems.
>
>
> For types of remapping which mix the ID and address together, I now
> do tend to agree that any flexibility arising from describing that
> in a general way that is unlikely to repay the cost of trying to
> interpret and analyse the DT. Defining a few sterotypical kinds
> of mapping explicitly, as needed, looks more sensible for now. The
> windowed-IOMMU case is one example.
For MSI, my feeling is that we'd just be best off doing an end-to-end
description. Any device using an MSI would have an interrupt specifier
that is sufficient for the interrupt controller to understand where
the IRQ comes from, and return an address/value pair back to the driver
to program into some register.
Arnd
next prev parent reply other threads:[~2014-05-30 19:11 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 [this message]
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
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=4663172.oXIylQOrlk@wuerfel \
--to=arnd-r2ngtmty4d4@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=Will.Deacon-5wv7dgnIgG8@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@vge \
--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.