From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Pantelis Antoniou
<panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>,
Gavin Shan
<gwshan-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
linuxppc-dev
<linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree
Date: Thu, 14 May 2015 10:54:31 +1000 [thread overview]
Message-ID: <1431564871.4160.8.camel@kernel.crashing.org> (raw)
In-Reply-To: <CAL_JsqKqTa5eg3eOqx3bkeNdO_920WwDiRbQaxwWLEWpCypFmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2015-05-13 at 19:18 -0500, Rob Herring wrote:
> I haven't decided really.
>
> The main thing with the current patch is I don't really like the added
> complexity to unflatten_dt_node. It is already a fairly complex
> function. Perhaps removing of "hybrid" as discussed will help?
I agree, we should be able to make that much simpler, I was planning on
sorting that out with Gavin.
> If there are things we can do to make overlays easier to use in your
> use case, I'd like to hear ideas. I don't really buy that being more
> complex than needed is an obstacle. That is very often the case to
> have common, scale-able solutions. I want to see a simple case be
> simple to support.
Well, it's a LOT more complex from the FW perspective for a bunch of
features we don't really need, in a way because the DT update in our
case is just purely informational to avoid keeping wrong/outdated DT
bits, it has little functional impact (it might have a bit for interrupt
routing through bridges though).
However, I am also pursuing an approach on FW side using a generation
count in our nodes and properties which we could use to generate
arbitrary overlays if we know what generation linux has.
There might actual be a usage scenario for a generic way for our
firwmare to convey DT updates to Linux for other reasons.
A few things that I don't find in the overlay code (but maybe I haven't
looked at it hard enough):
- Can it remove nodes/properties ?
- Can it "commit" a changeset so it's permanently part of the main DT ?
We will never have a concept of "revertable" changesets, if we need a
subsequent update, we will get a new overlay from FW that will remove
what needs to be removed and add what needs to be added.
IE, our current mechanism without overlay is fairly simple:
- On PCI unplug, we remove all nodes below the slot (from linux),
the FW does the equivalent internally.
- On PCI re-plug, the FW internally builds new nodes and sends a
new subtree as an FDT that we can expand/attach.
Now we could consider that subtree as a changeset that can be undone,
but that wouldn't work for boot time. And subsequent updates wouldn't
have that concept of "undoing" anyway.
IE. conceptually, what overlays do today is quite rooted around the idea
of having a fixed "base" DT and some pre-compiled DTB overlays that
get added/removed. The design completely ignore the idea of a FW that
maintains a "live" tree which we want to keep in sync, which is what we
want to do here, or what we could do with a "live" open firmware
implementation.
Now we might be able to reconcile them, but it feels to me that the
overlay/changeset stuff is too rooted in the first concept...
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Rob Herring <robherring2@gmail.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>,
Gavin Shan <gwshan@linux.vnet.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Grant Likely <grant.likely@linaro.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree
Date: Thu, 14 May 2015 10:54:31 +1000 [thread overview]
Message-ID: <1431564871.4160.8.camel@kernel.crashing.org> (raw)
In-Reply-To: <CAL_JsqKqTa5eg3eOqx3bkeNdO_920WwDiRbQaxwWLEWpCypFmA@mail.gmail.com>
On Wed, 2015-05-13 at 19:18 -0500, Rob Herring wrote:
> I haven't decided really.
>
> The main thing with the current patch is I don't really like the added
> complexity to unflatten_dt_node. It is already a fairly complex
> function. Perhaps removing of "hybrid" as discussed will help?
I agree, we should be able to make that much simpler, I was planning on
sorting that out with Gavin.
> If there are things we can do to make overlays easier to use in your
> use case, I'd like to hear ideas. I don't really buy that being more
> complex than needed is an obstacle. That is very often the case to
> have common, scale-able solutions. I want to see a simple case be
> simple to support.
Well, it's a LOT more complex from the FW perspective for a bunch of
features we don't really need, in a way because the DT update in our
case is just purely informational to avoid keeping wrong/outdated DT
bits, it has little functional impact (it might have a bit for interrupt
routing through bridges though).
However, I am also pursuing an approach on FW side using a generation
count in our nodes and properties which we could use to generate
arbitrary overlays if we know what generation linux has.
There might actual be a usage scenario for a generic way for our
firwmare to convey DT updates to Linux for other reasons.
A few things that I don't find in the overlay code (but maybe I haven't
looked at it hard enough):
- Can it remove nodes/properties ?
- Can it "commit" a changeset so it's permanently part of the main DT ?
We will never have a concept of "revertable" changesets, if we need a
subsequent update, we will get a new overlay from FW that will remove
what needs to be removed and add what needs to be added.
IE, our current mechanism without overlay is fairly simple:
- On PCI unplug, we remove all nodes below the slot (from linux),
the FW does the equivalent internally.
- On PCI re-plug, the FW internally builds new nodes and sends a
new subtree as an FDT that we can expand/attach.
Now we could consider that subtree as a changeset that can be undone,
but that wouldn't work for boot time. And subsequent updates wouldn't
have that concept of "undoing" anyway.
IE. conceptually, what overlays do today is quite rooted around the idea
of having a fixed "base" DT and some pre-compiled DTB overlays that
get added/removed. The design completely ignore the idea of a FW that
maintains a "live" tree which we want to keep in sync, which is what we
want to do here, or what we could do with a "live" open firmware
implementation.
Now we might be able to reconcile them, but it feels to me that the
overlay/changeset stuff is too rooted in the first concept...
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Rob Herring <robherring2@gmail.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Pantelis Antoniou <panto@antoniou-consulting.com>,
Gavin Shan <gwshan@linux.vnet.ibm.com>,
Grant Likely <grant.likely@linaro.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree
Date: Thu, 14 May 2015 10:54:31 +1000 [thread overview]
Message-ID: <1431564871.4160.8.camel@kernel.crashing.org> (raw)
In-Reply-To: <CAL_JsqKqTa5eg3eOqx3bkeNdO_920WwDiRbQaxwWLEWpCypFmA@mail.gmail.com>
On Wed, 2015-05-13 at 19:18 -0500, Rob Herring wrote:
> I haven't decided really.
>
> The main thing with the current patch is I don't really like the added
> complexity to unflatten_dt_node. It is already a fairly complex
> function. Perhaps removing of "hybrid" as discussed will help?
I agree, we should be able to make that much simpler, I was planning on
sorting that out with Gavin.
> If there are things we can do to make overlays easier to use in your
> use case, I'd like to hear ideas. I don't really buy that being more
> complex than needed is an obstacle. That is very often the case to
> have common, scale-able solutions. I want to see a simple case be
> simple to support.
Well, it's a LOT more complex from the FW perspective for a bunch of
features we don't really need, in a way because the DT update in our
case is just purely informational to avoid keeping wrong/outdated DT
bits, it has little functional impact (it might have a bit for interrupt
routing through bridges though).
However, I am also pursuing an approach on FW side using a generation
count in our nodes and properties which we could use to generate
arbitrary overlays if we know what generation linux has.
There might actual be a usage scenario for a generic way for our
firwmare to convey DT updates to Linux for other reasons.
A few things that I don't find in the overlay code (but maybe I haven't
looked at it hard enough):
- Can it remove nodes/properties ?
- Can it "commit" a changeset so it's permanently part of the main DT ?
We will never have a concept of "revertable" changesets, if we need a
subsequent update, we will get a new overlay from FW that will remove
what needs to be removed and add what needs to be added.
IE, our current mechanism without overlay is fairly simple:
- On PCI unplug, we remove all nodes below the slot (from linux),
the FW does the equivalent internally.
- On PCI re-plug, the FW internally builds new nodes and sends a
new subtree as an FDT that we can expand/attach.
Now we could consider that subtree as a changeset that can be undone,
but that wouldn't work for boot time. And subsequent updates wouldn't
have that concept of "undoing" anyway.
IE. conceptually, what overlays do today is quite rooted around the idea
of having a fixed "base" DT and some pre-compiled DTB overlays that
get added/removed. The design completely ignore the idea of a FW that
maintains a "live" tree which we want to keep in sync, which is what we
want to do here, or what we could do with a "live" open firmware
implementation.
Now we might be able to reconcile them, but it feels to me that the
overlay/changeset stuff is too rooted in the first concept...
Ben.
next prev parent reply other threads:[~2015-05-14 0:54 UTC|newest]
Thread overview: 184+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-01 6:02 [PATCH v4 00/21] PowerPC/PowerNV: PCI Slot Management Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-01 6:02 ` [PATCH v4 01/21] pci: Add pcibios_setup_bridge() Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-07 22:12 ` Bjorn Helgaas
2015-05-07 22:12 ` Bjorn Helgaas
2015-05-11 1:59 ` Gavin Shan
2015-05-11 1:59 ` Gavin Shan
2015-05-01 6:02 ` [PATCH v4 02/21] powerpc/powernv: Enable M64 on P7IOC Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-09 0:18 ` Alexey Kardashevskiy
2015-05-09 0:18 ` Alexey Kardashevskiy
2015-05-11 4:37 ` Gavin Shan
2015-05-11 4:37 ` Gavin Shan
2015-05-01 6:02 ` [PATCH v4 03/21] powerpc/powernv: M64 support improvement Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-09 10:24 ` Alexey Kardashevskiy
2015-05-09 10:24 ` Alexey Kardashevskiy
2015-05-11 4:47 ` Gavin Shan
2015-05-11 4:47 ` Gavin Shan
2015-05-01 6:02 ` [PATCH v4 04/21] powerpc/powernv: Improve IO and M32 mapping Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-09 10:53 ` Alexey Kardashevskiy
2015-05-09 10:53 ` Alexey Kardashevskiy
2015-05-11 4:52 ` Gavin Shan
2015-05-11 4:52 ` Gavin Shan
2015-05-01 6:02 ` [PATCH v4 05/21] powerpc/powernv: Improve DMA32 segment assignment Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-01 6:02 ` [PATCH v4 06/21] powerpc/powernv: Create PEs dynamically Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-09 11:43 ` Alexey Kardashevskiy
2015-05-09 11:43 ` Alexey Kardashevskiy
2015-05-11 4:55 ` Gavin Shan
2015-05-11 4:55 ` Gavin Shan
2015-05-01 6:02 ` [PATCH v4 07/21] powerpc/powernv: Release " Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-09 12:43 ` Alexey Kardashevskiy
2015-05-09 12:43 ` Alexey Kardashevskiy
2015-05-11 6:25 ` Gavin Shan
2015-05-11 6:25 ` Gavin Shan
2015-05-11 7:02 ` Alexey Kardashevskiy
2015-05-11 7:02 ` Alexey Kardashevskiy
2015-05-12 0:03 ` Gavin Shan
2015-05-12 0:03 ` Gavin Shan
2015-05-12 0:53 ` Alexey Kardashevskiy
2015-05-12 0:53 ` Alexey Kardashevskiy
2015-05-12 1:25 ` Gavin Shan
2015-05-12 1:25 ` Gavin Shan
2015-05-01 6:02 ` [PATCH v4 08/21] powerpc/powernv: Drop pnv_ioda_setup_dev_PE() Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-09 12:45 ` Alexey Kardashevskiy
2015-05-09 12:45 ` Alexey Kardashevskiy
2015-05-01 6:02 ` [PATCH v4 09/21] powerpc/powernv: Use PCI slot reset infrastructure Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-09 13:41 ` Alexey Kardashevskiy
2015-05-09 13:41 ` Alexey Kardashevskiy
2015-05-11 6:45 ` Gavin Shan
2015-05-11 6:45 ` Gavin Shan
2015-05-11 7:16 ` Alexey Kardashevskiy
2015-05-11 7:16 ` Alexey Kardashevskiy
2015-05-01 6:02 ` [PATCH v4 10/21] powerpc/powernv: Fundamental reset for PCI bus reset Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-09 14:12 ` Alexey Kardashevskiy
2015-05-09 14:12 ` Alexey Kardashevskiy
2015-05-11 6:47 ` Gavin Shan
2015-05-11 6:47 ` Gavin Shan
2015-05-11 7:17 ` Alexey Kardashevskiy
2015-05-11 7:17 ` Alexey Kardashevskiy
2015-05-12 0:04 ` Gavin Shan
2015-05-12 0:04 ` Gavin Shan
2015-05-01 6:02 ` [PATCH v4 11/21] powerpc/pci: Don't scan empty slot Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-01 6:02 ` [PATCH v4 12/21] powerpc/pci: Move pcibios_find_pci_bus() around Gavin Shan
2015-05-01 6:02 ` Gavin Shan
2015-05-01 6:03 ` [PATCH v4 13/21] powerpc/powernv: Introduce pnv_pci_poll() Gavin Shan
2015-05-01 6:03 ` Gavin Shan
2015-05-09 14:30 ` Alexey Kardashevskiy
2015-05-09 14:30 ` Alexey Kardashevskiy
2015-05-11 7:19 ` Gavin Shan
2015-05-11 7:19 ` Gavin Shan
2015-05-01 6:03 ` [PATCH v4 14/21] powerpc/powernv: Functions to get/reset PCI slot status Gavin Shan
2015-05-01 6:03 ` Gavin Shan
2015-05-09 14:44 ` Alexey Kardashevskiy
2015-05-09 14:44 ` Alexey Kardashevskiy
2015-05-01 6:03 ` [PATCH v4 15/21] powerpc/pci: Delay creating pci_dn Gavin Shan
2015-05-01 6:03 ` Gavin Shan
2015-05-09 14:55 ` Alexey Kardashevskiy
2015-05-09 14:55 ` Alexey Kardashevskiy
2015-05-11 7:21 ` Gavin Shan
2015-05-11 7:21 ` Gavin Shan
2015-05-01 6:03 ` [PATCH v4 16/21] powerpc/pci: Create eeh_dev while " Gavin Shan
2015-05-01 6:03 ` Gavin Shan
2015-05-09 15:08 ` Alexey Kardashevskiy
2015-05-09 15:08 ` Alexey Kardashevskiy
2015-05-11 7:24 ` Gavin Shan
2015-05-11 7:24 ` Gavin Shan
2015-05-01 6:03 ` [PATCH v4 17/21] powerpc/pci: Export traverse_pci_device_nodes() Gavin Shan
2015-05-01 6:03 ` Gavin Shan
2015-05-01 6:03 ` [PATCH v4 18/21] powerpc/pci: Update bridge windows on PCI plugging Gavin Shan
2015-05-01 6:03 ` Gavin Shan
2015-05-01 6:03 ` [PATCH v4 19/21] drivers/of: Support adding sub-tree Gavin Shan
2015-05-01 6:03 ` Gavin Shan
2015-05-01 12:54 ` Rob Herring
2015-05-01 12:54 ` Rob Herring
2015-05-01 15:22 ` Benjamin Herrenschmidt
2015-05-01 15:22 ` Benjamin Herrenschmidt
2015-05-01 18:46 ` Rob Herring
2015-05-01 18:46 ` Rob Herring
2015-05-01 22:57 ` Benjamin Herrenschmidt
2015-05-01 22:57 ` Benjamin Herrenschmidt
2015-05-01 23:29 ` Benjamin Herrenschmidt
2015-05-01 23:29 ` Benjamin Herrenschmidt
2015-05-02 2:48 ` Benjamin Herrenschmidt
2015-05-02 2:48 ` Benjamin Herrenschmidt
2015-05-04 1:30 ` Gavin Shan
2015-05-04 1:30 ` Gavin Shan
2015-05-04 4:51 ` Benjamin Herrenschmidt
2015-05-04 4:51 ` Benjamin Herrenschmidt
2015-05-04 0:23 ` Gavin Shan
2015-05-04 0:23 ` Gavin Shan
[not found] ` <1430521038.7979.70.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2015-05-04 16:41 ` Pantelis Antoniou
2015-05-04 16:41 ` Pantelis Antoniou
2015-05-04 16:41 ` Pantelis Antoniou
2015-05-04 21:14 ` Benjamin Herrenschmidt
2015-05-04 21:14 ` Benjamin Herrenschmidt
2015-05-13 23:35 ` Benjamin Herrenschmidt
2015-05-13 23:35 ` Benjamin Herrenschmidt
[not found] ` <1431560124.20218.91.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2015-05-14 0:18 ` Rob Herring
2015-05-14 0:18 ` Rob Herring
2015-05-14 0:18 ` Rob Herring
[not found] ` <CAL_JsqKqTa5eg3eOqx3bkeNdO_920WwDiRbQaxwWLEWpCypFmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-05-14 0:54 ` Benjamin Herrenschmidt [this message]
2015-05-14 0:54 ` Benjamin Herrenschmidt
2015-05-14 0:54 ` Benjamin Herrenschmidt
2015-05-14 6:23 ` Pantelis Antoniou
2015-05-14 6:23 ` Pantelis Antoniou
2015-05-14 6:46 ` Benjamin Herrenschmidt
2015-05-14 6:46 ` Benjamin Herrenschmidt
2015-05-14 7:04 ` Pantelis Antoniou
2015-05-14 7:04 ` Pantelis Antoniou
[not found] ` <3988EABE-3DE9-4E1C-9778-22E35138E359-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2015-05-14 7:14 ` Benjamin Herrenschmidt
2015-05-14 7:14 ` Benjamin Herrenschmidt
2015-05-14 7:14 ` Benjamin Herrenschmidt
2015-05-14 7:19 ` Pantelis Antoniou
2015-05-14 7:19 ` Pantelis Antoniou
2015-05-14 7:19 ` Pantelis Antoniou
[not found] ` <75F026CA-5AC1-4106-B2F0-AB0D006DEF5A-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2015-05-14 7:25 ` Benjamin Herrenschmidt
2015-05-14 7:25 ` Benjamin Herrenschmidt
2015-05-14 7:25 ` Benjamin Herrenschmidt
2015-05-14 7:29 ` Benjamin Herrenschmidt
2015-05-14 7:29 ` Benjamin Herrenschmidt
[not found] ` <1431588358.4160.42.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2015-05-14 7:34 ` Pantelis Antoniou
2015-05-14 7:34 ` Pantelis Antoniou
2015-05-14 7:34 ` Pantelis Antoniou
[not found] ` <D7FC0542-DD1A-428F-8E75-81620C6D83DC-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2015-05-14 7:47 ` Benjamin Herrenschmidt
2015-05-14 7:47 ` Benjamin Herrenschmidt
2015-05-14 7:47 ` Benjamin Herrenschmidt
2015-05-14 11:02 ` Pantelis Antoniou
2015-05-14 11:02 ` Pantelis Antoniou
2015-05-14 11:02 ` Pantelis Antoniou
2015-05-14 23:25 ` Benjamin Herrenschmidt
2015-05-14 23:25 ` Benjamin Herrenschmidt
[not found] ` <1431564871.4160.8.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2015-06-07 7:54 ` Grant Likely
2015-06-07 7:54 ` Grant Likely
[not found] ` <20150607075422.6ECE9C40A12-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2015-06-08 20:57 ` Benjamin Herrenschmidt
2015-06-08 20:57 ` Benjamin Herrenschmidt
[not found] ` <1433797073.4526.163.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2015-06-08 21:34 ` Grant Likely
2015-06-08 21:34 ` Grant Likely
2015-06-10 6:55 ` Gavin Shan
2015-05-03 23:28 ` Gavin Shan
2015-05-03 23:28 ` Gavin Shan
2015-05-15 1:27 ` Gavin Shan
2015-05-15 1:27 ` Gavin Shan
2015-05-01 6:03 ` [PATCH v4 20/21] powerpc/powernv: Select OF_DYNAMIC Gavin Shan
2015-05-01 6:03 ` Gavin Shan
2015-05-01 6:03 ` [PATCH v4 21/21] pci/hotplug: PowerPC PowerNV PCI hotplug driver Gavin Shan
2015-05-01 6:03 ` Gavin Shan
2015-05-09 15:54 ` Alexey Kardashevskiy
2015-05-09 15:54 ` Alexey Kardashevskiy
2015-05-11 7:38 ` Gavin Shan
2015-05-11 7:38 ` Gavin Shan
2015-05-08 23:59 ` [PATCH v4 00/21] PowerPC/PowerNV: PCI Slot Management Alexey Kardashevskiy
2015-05-08 23:59 ` Alexey Kardashevskiy
2015-05-11 7:40 ` Gavin Shan
2015-05-11 7:40 ` Gavin Shan
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=1431564871.4160.8.camel@kernel.crashing.org \
--to=benh-xvmvhmargas8u2djnn8i7kb+6bgklq7r@public.gmane.org \
--cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=gwshan-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org \
--cc=robherring2-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.