From: Gavin Shan <gwshan@linux.vnet.ibm.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, benh@kernel.crashing.org,
mpe@ellerman.id.au, bhelgaas@google.com, grant.likely@linaro.org,
robherring2@gmail.com, panto@antoniou-consulting.com
Subject: Re: [PATCH v6 03/42] powerpc/powernv: Enable M64 on P7IOC
Date: Wed, 12 Aug 2015 20:28:58 +1000 [thread overview]
Message-ID: <20150812102858.GA7690@gwshan> (raw)
In-Reply-To: <55C958A2.5060708@ozlabs.ru>
On Tue, Aug 11, 2015 at 12:06:26PM +1000, Alexey Kardashevskiy wrote:
>On 08/11/2015 09:45 AM, Gavin Shan wrote:
>>On Mon, Aug 10, 2015 at 04:30:09PM +1000, Alexey Kardashevskiy wrote:
>>>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>>>The patch enables M64 window on P7IOC, which has been enabled on
>>>>PHB3. Different from PHB3 where 16 M64 BARs are supported and each
>>>>of them can be owned by one particular PE# exclusively or divided
>>>>evenly to 256 segments, each P7IOC PHB has 16 M64 BARs and each
>>>>of them are divided into 8 segments.
>>>
>>>Is this a limitation of POWER7 chip or it is from IODA1?
>>>
>>
>> From IODA1.
>>
>>>>So each P7IOC PHB can support
>>>>128 M64 segments only. Also, P7IOC has M64DT, which helps mapping
>>>>one particular M64 segment# to arbitrary PE#. PHB3 doesn't have
>>>>M64DT, indicating that one M64 segment can only be pinned to the
>>>>fixed PE#. In order to have similar logic to support M64 for PHB3
>>>>and P7IOC, we just provide 128 M64 (16 BARs) segments and fixed
>>>>mapping between PE# and M64 segment# on P7IOC. In turn, we just
>>>>need different phb->init_m64() hooks for P7IOC and PHB3 to support
>>>>M64.
>>>>
>>>>Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>>>>---
>>>> arch/powerpc/platforms/powernv/pci-ioda.c | 116 ++++++++++++++++++++++++++----
>>>> 1 file changed, 104 insertions(+), 12 deletions(-)
>>>>
>>>>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>>>>index 38b5405..e4ac703 100644
>>>>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>>>>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>>>>@@ -172,6 +172,69 @@ static void pnv_ioda_free_pe(struct pnv_phb *phb, int pe)
>>>> clear_bit(pe, phb->ioda.pe_alloc);
>>>> }
>>>>
>>>>+static int pnv_ioda1_init_m64(struct pnv_phb *phb)
>>>>+{
>>>>+ struct resource *r;
>>>>+ int seg;
>>>>+
>>>>+ /* There are as many M64 segments as the maximum number
>>>>+ * of PEs, which is 128.
>>>>+ */
>>>>+ for (seg = 0; seg < phb->ioda.total_pe; seg += 8) {
>>>
>>>
>>>This "8" is used a lot across the patch, please make it a macro
>>>(PNV_PHB_P7IOC_SEGNUM or PNV_PHB_IODA1_SEGNUM or whatever you think it is)
>>>with a short comment why it is "8". Or a pnv_phb member.
>>>
>>
>>I would like to use "8". When having a macro, you have to check
>>the definition of the macro to get the real value of that.
>
>Give it a good name then.
>
>
>>However,
>>it makes sense to add more comments explaining why it's 8 here.
>
>You cannot comment it everywhere and everywhere is exact place when you'll
>have to comment it as I believe sometime it is segments-per-M64 and sometime
>it is number of bits in a byte (or not? anyway, this is will always distract
>unless you use macro for segments-per-M64).
>
Ok. I will use PNV_PHB_IODA1_SEGNUM then.
>>
>>>
>>>>+ unsigned long base;
>>>>+ int64_t rc;
>>>>+
>>>>+ base = phb->ioda.m64_base + seg * phb->ioda.m64_segsize;
>>>>+ rc = opal_pci_set_phb_mem_window(phb->opal_id,
>>>>+ OPAL_M64_WINDOW_TYPE,
>>>>+ seg / 8,
>>>>+ base,
>>>>+ 0, /* unused */
>>>>+ 8 * phb->ioda.m64_segsize);
>>>>+ if (rc != OPAL_SUCCESS) {
>>>>+ pr_warn(" Error %lld setting M64 PHB#%d-BAR#%d\n",
>>>>+ rc, phb->hose->global_number, seg / 8);
>>>>+ goto fail;
>>>>+ }
>>>>+
>>>>+ rc = opal_pci_phb_mmio_enable(phb->opal_id,
>>>>+ OPAL_M64_WINDOW_TYPE,
>>>>+ seg / 8,
>>>>+ OPAL_ENABLE_M64_SPLIT);
>>>>+ if (rc != OPAL_SUCCESS) {
>>>>+ pr_warn(" Error %lld enabling M64 PHB#%d-BAR#%d\n",
>>>>+ rc, phb->hose->global_number, seg / 8);
>>>>+ goto fail;
>>>>+ }
>>>>+ }
>>>>+
>>>>+ /* Strip off the segment used by the reserved PE, which
>>>
>>>What is this reserved PE on P7IOC? "Strip off" means "exclude" here?
>>>
>>
>>127 that was exported from skiboot. "Strip off" means "exclude".
>
>I like "exclude" lot better.
>
Ok. Will use it.
>>
>>>
>>>>+ * is expected to be 0 or last supported PE#. The PHB's
>>>>+ * first memory window traces the 32-bits MMIO range
>>>
>>>s/traces/filters/ ? Or I did not understand this comment...
>>>
>>
>>It seems you didn't understand it: there are two memory windows
>>in every PHB. The first one is tracing M32 resource and the
>>second one is tracing M64 resource.
>
>
>Tracing means logging, pretty much. Is this what you mean here?
>
No, it means "recording", not "logging". So it would be appropriate
to replace it with "track"?
>>
>>>
>>>>+ * while the second one traces the 64-bits prefetchable
>>>>+ * MMIO range that the PHB supports.
>>>
>>>32/64 ranges comment seems irrelevant here.
>>>
>>
>>Maybe it's not so relevant, but still.
>
>Not relevant -> remove it. Put this text to the commit log.
>
Ok.
>>We're stripping off the
>>M64 segment from the 2nd resource (as above), not first one.
>
>
>2nd window (not _resource_), you mean?
>
I mean struct pci_controller::mem_resources[1].
>
>>
>>>
>>>>+ */
>>>>+ r = &phb->hose->mem_resources[1];
>>>>+ if (phb->ioda.reserved_pe == 0)
>>>>+ r->start += phb->ioda.m64_segsize;
>>>>+ else if (phb->ioda.reserved_pe == (phb->ioda.total_pe - 1))
>>>>+ r->end -= phb->ioda.m64_segsize;
>>>>+ else
>>>>+ pr_warn(" Cannot strip M64 segment for reserved PE#%d\n",
>>>>+ phb->ioda.reserved_pe);
>>>>+
>>>>+ return 0;
>>>>+
>>>>+fail:
>>>>+ for ( ; seg >= 0; seg -= 8)
>>>>+ opal_pci_phb_mmio_enable(phb->opal_id,
>>>>+ OPAL_M64_WINDOW_TYPE,
>>>>+ seg / 8,
>>>>+ OPAL_DISABLE_M64);
>>>>+
>>>>+ return -EIO;
>>>>+}
>>>>+
>>>> /* The default M64 BAR is shared by all PEs */
>>>> static int pnv_ioda2_init_m64(struct pnv_phb *phb)
>>>> {
>>>>@@ -256,9 +319,9 @@ static void pnv_ioda2_reserve_dev_m64_pe(struct pci_dev *pdev,
>>>> }
>>>> }
>>>>
>>>>-static void pnv_ioda2_reserve_m64_pe(struct pci_bus *bus,
>>>>- unsigned long *pe_bitmap,
>>>>- bool all)
>>>>+static void pnv_ioda_reserve_m64_pe(struct pci_bus *bus,
>>>>+ unsigned long *pe_bitmap,
>>>>+ bool all)
>>>> {
>>>> struct pci_dev *pdev;
>>>>
>>>>@@ -266,12 +329,12 @@ static void pnv_ioda2_reserve_m64_pe(struct pci_bus *bus,
>>>> pnv_ioda2_reserve_dev_m64_pe(pdev, pe_bitmap);
>>>>
>>>> if (all && pdev->subordinate)
>>>>- pnv_ioda2_reserve_m64_pe(pdev->subordinate,
>>>>- pe_bitmap, all);
>>>>+ pnv_ioda_reserve_m64_pe(pdev->subordinate,
>>>>+ pe_bitmap, all);
>>>> }
>>>> }
>>>>
>>>>-static int pnv_ioda2_pick_m64_pe(struct pci_bus *bus, bool all)
>>>>+static int pnv_ioda_pick_m64_pe(struct pci_bus *bus, bool all)
>>>> {
>>>> struct pci_controller *hose = pci_bus_to_host(bus);
>>>> struct pnv_phb *phb = hose->private_data;
>>>>@@ -293,7 +356,7 @@ static int pnv_ioda2_pick_m64_pe(struct pci_bus *bus, bool all)
>>>> }
>>>>
>>>> /* Figure out reserved PE numbers by the PE */
>>>>- pnv_ioda2_reserve_m64_pe(bus, pe_alloc, all);
>>>>+ pnv_ioda_reserve_m64_pe(bus, pe_alloc, all);
>>>>
>>>> /*
>>>> * the current bus might not own M64 window and that's all
>>>>@@ -324,6 +387,26 @@ static int pnv_ioda2_pick_m64_pe(struct pci_bus *bus, bool all)
>>>> pe->master = master_pe;
>>>> list_add_tail(&pe->list, &master_pe->slaves);
>>>> }
>>>>+
>>>>+ /* P7IOC supports M64DT, which helps mapping M64 segment
>>>>+ * to one particular PE#. However, PHB3 has fixed mapping
>>>>+ * between M64 segment and PE#. In order to have same logic
>>>>+ * for P7IOC and PHB3, we enforce fixed mapping between M64
>>>>+ * segment and PE# on P7IOC.
>>>>+ */
>>>>+ if (phb->type == PNV_PHB_IODA1) {
>>>>+ int64_t rc;
>>>>+
>>>>+ rc = opal_pci_map_pe_mmio_window(phb->opal_id,
>>>>+ pe->pe_number,
>>>>+ OPAL_M64_WINDOW_TYPE,
>>>>+ pe->pe_number / 8,
>>>>+ pe->pe_number % 8);
>>>>+ if (rc != OPAL_SUCCESS)
>>>>+ pr_warn("%s: Error %lld mapping M64 for PHB#%d-PE#%d\n",
>>>>+ __func__, rc, phb->hose->global_number,
>>>>+ pe->pe_number);
>>>>+ }
>>>> }
>>>>
>>>> kfree(pe_alloc);
>>>>@@ -338,8 +421,8 @@ static void __init pnv_ioda_parse_m64_window(struct pnv_phb *phb)
>>>> const u32 *r;
>>>> u64 pci_addr;
>>>>
>>>>- /* FIXME: Support M64 for P7IOC */
>>>>- if (phb->type != PNV_PHB_IODA2) {
>>>>+ if (phb->type != PNV_PHB_IODA1 &&
>>>>+ phb->type != PNV_PHB_IODA2) {
>>>> pr_info(" Not support M64 window\n");
>>>> return;
>>>
>>>
>>>You are adding P7IOC support so at least "fixme" should go. Also,
>>>pnv_ioda_parse_m64_window() is only called from pnv_pci_init_ioda_phb() which
>>>is called only with PNV_PHB_IODA1 and PNV_PHB_IODA2 (no other value is passed
>>>there a type) so the check above will never succeed, just remove it.
>>>
>>
>>The "fixme" is removed, isn't it?
>
>Ah, my bad.
>
>
>>As I explained last time, there will have another new type PHB and the function
>>will be called on the new type of PHB.
>
>Then a new patch adding new PHB should take care of this check too. This is
>not something which can possibly happen on a real machine, we support one of
>2 (later - 3) PHBs and if a machine got something else, we won't get that far
>anyway and we cannot gracefully fallback to some "generic PHB" (like 440fx on
>x86) as we do not have one.
>
>At least make it BUG_ON() to document it.
>
ok. I'll change accordingly.
>>The code has been there and it's not
>>in upstream yet. So it's reasonable to keep it, instead of removing it.
>
>No, not really.
>
>>
>>>> }
>>>>@@ -372,9 +455,18 @@ static void __init pnv_ioda_parse_m64_window(struct pnv_phb *phb)
>>>>
>>>> /* Use last M64 BAR to cover M64 window */
>>>> phb->ioda.m64_bar_idx = 15;
>>>>- phb->init_m64 = pnv_ioda2_init_m64;
>>>>- phb->reserve_m64_pe = pnv_ioda2_reserve_m64_pe;
>>>>- phb->pick_m64_pe = pnv_ioda2_pick_m64_pe;
>>>>+ phb->reserve_m64_pe = pnv_ioda_reserve_m64_pe;
>>>>+ phb->pick_m64_pe = pnv_ioda_pick_m64_pe;
>>>>+ switch (phb->type) {
>>>>+ case PNV_PHB_IODA1:
>>>>+ phb->init_m64 = pnv_ioda1_init_m64;
>>>>+ break;
>>>>+ case PNV_PHB_IODA2:
>>>>+ phb->init_m64 = pnv_ioda2_init_m64;
>>>>+ break;
>>>>+ default:
>>>>+ pr_debug(" M64 not supported\n");
>>>>+ }
>>>> }
>>>>
>>>> static void pnv_ioda_freeze_pe(struct pnv_phb *phb, int pe_no)
>>>>
Thanks,
Gavin
next prev parent reply other threads:[~2015-08-12 10:28 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-06 4:11 [PATCH v6 00/42] powerpc/powernv: PCI hotplug suppport Gavin Shan
2015-08-06 4:11 ` [PATCH v6 01/42] PCI: Add pcibios_setup_bridge() Gavin Shan
2015-08-06 4:11 ` [PATCH v6 02/42] powerpc/powernv: Drop pnv_ioda_setup_dev_PE() Gavin Shan
2015-08-06 4:11 ` [PATCH v6 03/42] powerpc/powernv: Enable M64 on P7IOC Gavin Shan
2015-08-10 6:30 ` Alexey Kardashevskiy
2015-08-10 23:45 ` Gavin Shan
2015-08-11 2:06 ` Alexey Kardashevskiy
2015-08-12 10:28 ` Gavin Shan [this message]
2015-08-06 4:11 ` [PATCH v6 04/42] powerpc/powernv: Reorder fields in struct pnv_phb Gavin Shan
2015-08-06 4:11 ` [PATCH v6 05/42] powerpc/powernv: Track IO/M32/M64 segments from PE Gavin Shan
2015-08-10 7:16 ` Alexey Kardashevskiy
2015-08-11 0:03 ` Gavin Shan
2015-08-11 2:23 ` Alexey Kardashevskiy
2015-08-12 10:45 ` Gavin Shan
2015-08-12 11:05 ` Alexey Kardashevskiy
2015-08-12 11:20 ` Gavin Shan
2015-08-12 12:57 ` Alexey Kardashevskiy
2015-08-12 23:34 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 06/42] powerpc/powernv: Simplify pnv_ioda_setup_pe_seg() Gavin Shan
2015-08-06 4:11 ` [PATCH v6 07/42] powerpc/powernv: Improve IO and M32 mapping Gavin Shan
[not found] ` <1438834307-26960-8-git-send-email-gwshan-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-08-10 7:40 ` Alexey Kardashevskiy
2015-08-11 0:12 ` Gavin Shan
2015-08-11 2:32 ` Alexey Kardashevskiy
2015-08-12 23:42 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 08/42] powerpc/powernv: Calculate PHB's DMA weight dynamically Gavin Shan
2015-08-10 7:48 ` Alexey Kardashevskiy
2015-08-10 9:21 ` Alexey Kardashevskiy
2015-08-12 23:57 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 09/42] powerpc/powernv: DMA32 cleanup Gavin Shan
2015-08-10 8:07 ` Alexey Kardashevskiy
2015-08-11 0:19 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 10/42] powerpc/powernv: pnv_ioda_setup_dma() configure one PE only Gavin Shan
2015-08-10 9:31 ` Alexey Kardashevskiy
2015-08-11 0:29 ` Gavin Shan
2015-08-11 2:39 ` Alexey Kardashevskiy
2015-08-12 23:59 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 11/42] powerpc/powernv: Trace DMA32 segments consumed by PE Gavin Shan
2015-08-10 9:43 ` Alexey Kardashevskiy
2015-08-11 0:33 ` Gavin Shan
2015-08-13 0:02 ` Gavin Shan
[not found] ` <1438834307-26960-1-git-send-email-gwshan-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-08-06 4:11 ` [PATCH v6 12/42] powerpc/powernv: Increase PE# capacity Gavin Shan
[not found] ` <1438834307-26960-13-git-send-email-gwshan-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-08-10 9:53 ` Alexey Kardashevskiy
2015-08-11 0:38 ` Gavin Shan
2015-08-11 2:47 ` Alexey Kardashevskiy
2015-08-13 0:23 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 17/42] powerpc/powernv: Rename PE# fields in PHB Gavin Shan
2015-08-10 14:21 ` Alexey Kardashevskiy
2015-08-11 0:40 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 28/42] powerpc/powernv: Fundamental reset in pnv_pci_reset_secondary_bus() Gavin Shan
2015-08-06 4:11 ` [PATCH v6 32/42] powerpc/powernv: Introduce pnv_pci_poll() Gavin Shan
2015-08-06 4:11 ` [PATCH v6 33/42] powerpc/powernv: Functions to get/reset PCI slot status Gavin Shan
2015-08-06 4:11 ` [PATCH v6 34/42] powerpc/pci: Delay creating pci_dn Gavin Shan
2015-08-06 4:11 ` [PATCH v6 37/42] powerpc/powernv: Select OF_DYNAMIC Gavin Shan
2015-08-06 4:11 ` [PATCH v6 13/42] powerpc/pci: Cleanup on pci_controller_ops Gavin Shan
2015-08-06 4:11 ` [PATCH v6 14/42] powerpc/pci: Override pcibios_setup_bridge() Gavin Shan
2015-08-06 4:11 ` [PATCH v6 15/42] powerpc/powernv: PE oriented during configuration Gavin Shan
2015-08-10 10:02 ` Alexey Kardashevskiy
2015-08-11 0:39 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 16/42] powerpc/powernv: Helper function pnv_ioda_init_pe() Gavin Shan
2015-08-06 4:11 ` [PATCH v6 18/42] powerpc/powernv: Allocate PE# in deasending order Gavin Shan
2015-08-10 14:39 ` Alexey Kardashevskiy
2015-08-11 0:43 ` Gavin Shan
2015-08-11 2:50 ` Alexey Kardashevskiy
2015-08-13 0:28 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 19/42] powerpc/powernv: Reserve PE# for root bus Gavin Shan
2015-08-06 4:11 ` [PATCH v6 20/42] powerpc/powernv: Create PEs dynamically Gavin Shan
2015-08-14 13:52 ` Alexey Kardashevskiy
2015-08-15 4:59 ` Gavin Shan
2015-08-15 9:23 ` Alexey Kardashevskiy
2015-08-06 4:11 ` [PATCH v6 21/42] powerpc/powernv: Remove DMA32 list of PEs Gavin Shan
2015-08-06 4:11 ` [PATCH v6 22/42] powerpc/powernv: Move functions around Gavin Shan
2015-08-06 4:11 ` [PATCH v6 23/42] powerpc/powernv: Release PEs dynamically Gavin Shan
2015-08-11 13:03 ` Alexey Kardashevskiy
2015-08-13 0:54 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 24/42] powerpc/powernv: Supports slot ID Gavin Shan
2015-08-06 4:11 ` [PATCH v6 25/42] powerpc/powernv: Use PCI slot reset infrastructure Gavin Shan
2015-08-06 4:11 ` [PATCH v6 26/42] powerpc/powernv: Simplify pnv_eeh_reset() Gavin Shan
2015-08-06 4:11 ` [PATCH v6 27/42] powerpc/powernv: Don't cover root bus in pnv_pci_reset_secondary_bus() Gavin Shan
2015-08-06 4:11 ` [PATCH v6 29/42] powerpc/pci: Don't scan empty slot Gavin Shan
2015-08-06 4:11 ` [PATCH v6 30/42] powerpc/pci: Move pcibios_find_pci_bus() around Gavin Shan
2015-08-06 4:11 ` [PATCH v6 31/42] powerpc/pci: Rename pcibios_{add,remove}_pci_devices Gavin Shan
2015-08-06 4:11 ` [PATCH v6 35/42] powerpc/pci: Export traverse_pci_device_nodes() Gavin Shan
2015-08-06 4:11 ` [PATCH v6 36/42] powerpc/pci: Update bridge windows on PCI plugging Gavin Shan
2015-08-06 4:11 ` [PATCH v6 38/42] drivers/of: Unflatten subordinate nodes after specified level Gavin Shan
2015-08-06 14:09 ` Rob Herring
2015-11-03 23:16 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 39/42] drivers/of: Allow to specify root node in of_fdt_unflatten_tree() Gavin Shan
2015-08-10 22:42 ` Frank Rowand
2015-08-11 0:52 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 40/42] drivers/of: Return allocated memory chunk from of_fdt_unflatten_tree() Gavin Shan
[not found] ` <1438834307-26960-41-git-send-email-gwshan-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-08-06 14:19 ` Rob Herring
2015-08-10 22:42 ` Frank Rowand
2015-08-11 0:52 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 41/42] drivers/of: Export OF changeset functions Gavin Shan
2015-08-06 13:48 ` Rob Herring
2015-08-07 1:43 ` Gavin Shan
2015-08-06 4:11 ` [PATCH v6 42/42] pci/hotplug: PowerPC PowerNV PCI hotplug driver Gavin Shan
2015-08-15 3:13 ` Alexey Kardashevskiy
2015-08-15 4:47 ` Gavin Shan
2015-08-15 9:15 ` Alexey Kardashevskiy
2015-08-10 6:05 ` [PATCH v6 00/42] powerpc/powernv: PCI hotplug suppport Alexey Kardashevskiy
2015-08-10 7:17 ` 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=20150812102858.GA7690@gwshan \
--to=gwshan@linux.vnet.ibm.com \
--cc=aik@ozlabs.ru \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=panto@antoniou-consulting.com \
--cc=robherring2@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).