From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Gavin Shan <gwshan@linux.vnet.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: linux-pci@vger.kernel.org, benh@kernel.crashing.org, bhelgaas@google.com
Subject: Re: [PATCH v4 02/21] powerpc/powernv: Enable M64 on P7IOC
Date: Sat, 09 May 2015 10:18:42 +1000 [thread overview]
Message-ID: <554D5262.2030109@ozlabs.ru> (raw)
In-Reply-To: <1430460188-31343-3-git-send-email-gwshan@linux.vnet.ibm.com>
On 05/01/2015 04:02 PM, Gavin Shan wrote:
> The patch enables M64 window on P7IOC, which has been enabled on
> PHB3. Comparing to PHB3, there are 16 M64 BARs and each of them
> are divided to 8 segments.
"compared to something" means you will tell about PHB3 too :)
Do I understand correctly that IODA==IODA1==P7IOC and P7IOC != IODA2? The
code does not use "PHB3" or "P7IOC" acronym so it is a bit confusing.
> So each PHB can support 128 M64 segments.
> Also, P7IOC has M64DT, which helps mapping one particular M64
> segment# to arbitrary PE#. However, we just provide 128 M64 (16 BARs)
> segments and fixed mapping between PE# and M64 segment# in order
> to keep same logic to support M64 for PHB3 and P7IOC. In turn, we
> just need different phb->init_m64() hooks for P7IOC and PHB3.
>
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 115 ++++++++++++++++++++++++++----
> 1 file changed, 103 insertions(+), 12 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index f8bc950..646962f 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -165,6 +165,67 @@ 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;
> + s64 rc;
Here @rc is of the "s64" type.
> +
> + /* Each PHB supports 16 separate M64 BARs, each of which are
> + * divided into 8 segments. So there are number of M64 segments
> + * as total PE#, which is 128.
> + */
"there are as many M64 segments as a maximum number of PEs which is 128"?
> + for (seg = 0; seg < phb->ioda.total_pe; seg += 8) {
> + unsigned long base;
> +
> + 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(" Failure %lld configuring M64 BAR#%d on PHB#%d\n",
> + rc, seg / 8, phb->hose->global_number);
> + 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(" Failure %lld enabling M64 BAR#%d on PHB#%d\n",
> + rc, seg / 8, phb->hose->global_number);
> + goto fail;
> + }
> + }
> +
> + /* Strip of the segment used by the reserved PE, which
> + * is expected to be 0 or last supported PE#
> + */
> + r = &phb->hose->mem_resources[1];
mem_resources[0] is IO, mem_resources[1] is MMIO, mem_resources[2] is for
what? Would be nice to have this commented somewhere.
> + 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);
Out of curiosity - is not there a counterpart for
opal_pci_set_phb_mem_window() for cleanup?
> +
> + return -EIO;
> +}
> +
> /* The default M64 BAR is shared by all PEs */
> static int pnv_ioda2_init_m64(struct pnv_phb *phb)
> {
> @@ -222,7 +283,7 @@ fail:
> return -EIO;
> }
>
> -static void pnv_ioda2_reserve_m64_pe(struct pnv_phb *phb)
> +static void pnv_ioda_reserve_m64_pe(struct pnv_phb *phb)
> {
> resource_size_t sgsz = phb->ioda.m64_segsize;
> struct pci_dev *pdev;
> @@ -248,8 +309,8 @@ static void pnv_ioda2_reserve_m64_pe(struct pnv_phb *phb)
> }
> }
>
> -static int pnv_ioda2_pick_m64_pe(struct pnv_phb *phb,
> - struct pci_bus *bus, int all)
> +static int pnv_ioda_pick_m64_pe(struct pnv_phb *phb,
> + struct pci_bus *bus, int all)
> {
> resource_size_t segsz = phb->ioda.m64_segsize;
> struct pci_dev *pdev;
> @@ -346,6 +407,28 @@ done:
> pe->master = master_pe;
> list_add_tail(&pe->list, &master_pe->slaves);
> }
> +
> + /* P7IOC supports M64DT, which helps mapping M64 segment
> + * to one particular PE#. Unfortunately, PHB3 has fixed
Why is it "Unfortunately"? This is just the way it is :)
> + * mapping between M64 segment and PE#. In order for 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;
Here @rc is of the "int64_t" type. And this one and the one above are used
for return code from OPAL API. Make them the same (int64_t or long, up to you).
> +
> + 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: Failure %lld mapping "
> + "M64 for PHB#%d-PE#%d\n",
> + __func__, rc,
> + phb->hose->global_number,
> + pe->pe_number);
> + }
> }
>
> kfree(pe_alloc);
> @@ -360,12 +443,6 @@ 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) {
> - pr_info(" Not support M64 window\n");
> - return;
> - }
> -
> if (!firmware_has_feature(FW_FEATURE_OPALv3)) {
> pr_info(" Firmware too old to support M64 window\n");
> return;
> @@ -394,9 +471,23 @@ 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;
reserve_m64_pe() is called once from pnv_pci_ioda_setup_PEs() so it is
IODA-only and in this case reserve_m64_pe != NULL and
pnv_ioda_reserve_m64_pe() will be called always.
In general, it feels like pnv_phb has too many callbacks while they could
be just direct calls.
> + 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:
> + phb->init_m64 = NULL;
> + phb->reserve_m64_pe = NULL;
> + phb->pick_m64_pe = NULL;
> + phb->ioda.m64_size = 0;
> + phb->ioda.m64_segsize = 0;
> + phb->ioda.m64_base = 0;
There are just 2 PHB types - IODA1 and IODA2, right? And the fields you
reset after "default" - they have to be zeroes already, no? And on what
hardware would the default branch actuall work? None?
> + }
> }
>
> static void pnv_ioda_freeze_pe(struct pnv_phb *phb, int pe_no)
>
--
Alexey
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Gavin Shan <gwshan@linux.vnet.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org
Subject: Re: [PATCH v4 02/21] powerpc/powernv: Enable M64 on P7IOC
Date: Sat, 09 May 2015 10:18:42 +1000 [thread overview]
Message-ID: <554D5262.2030109@ozlabs.ru> (raw)
In-Reply-To: <1430460188-31343-3-git-send-email-gwshan@linux.vnet.ibm.com>
On 05/01/2015 04:02 PM, Gavin Shan wrote:
> The patch enables M64 window on P7IOC, which has been enabled on
> PHB3. Comparing to PHB3, there are 16 M64 BARs and each of them
> are divided to 8 segments.
"compared to something" means you will tell about PHB3 too :)
Do I understand correctly that IODA==IODA1==P7IOC and P7IOC != IODA2? The
code does not use "PHB3" or "P7IOC" acronym so it is a bit confusing.
> So each PHB can support 128 M64 segments.
> Also, P7IOC has M64DT, which helps mapping one particular M64
> segment# to arbitrary PE#. However, we just provide 128 M64 (16 BARs)
> segments and fixed mapping between PE# and M64 segment# in order
> to keep same logic to support M64 for PHB3 and P7IOC. In turn, we
> just need different phb->init_m64() hooks for P7IOC and PHB3.
>
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 115 ++++++++++++++++++++++++++----
> 1 file changed, 103 insertions(+), 12 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index f8bc950..646962f 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -165,6 +165,67 @@ 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;
> + s64 rc;
Here @rc is of the "s64" type.
> +
> + /* Each PHB supports 16 separate M64 BARs, each of which are
> + * divided into 8 segments. So there are number of M64 segments
> + * as total PE#, which is 128.
> + */
"there are as many M64 segments as a maximum number of PEs which is 128"?
> + for (seg = 0; seg < phb->ioda.total_pe; seg += 8) {
> + unsigned long base;
> +
> + 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(" Failure %lld configuring M64 BAR#%d on PHB#%d\n",
> + rc, seg / 8, phb->hose->global_number);
> + 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(" Failure %lld enabling M64 BAR#%d on PHB#%d\n",
> + rc, seg / 8, phb->hose->global_number);
> + goto fail;
> + }
> + }
> +
> + /* Strip of the segment used by the reserved PE, which
> + * is expected to be 0 or last supported PE#
> + */
> + r = &phb->hose->mem_resources[1];
mem_resources[0] is IO, mem_resources[1] is MMIO, mem_resources[2] is for
what? Would be nice to have this commented somewhere.
> + 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);
Out of curiosity - is not there a counterpart for
opal_pci_set_phb_mem_window() for cleanup?
> +
> + return -EIO;
> +}
> +
> /* The default M64 BAR is shared by all PEs */
> static int pnv_ioda2_init_m64(struct pnv_phb *phb)
> {
> @@ -222,7 +283,7 @@ fail:
> return -EIO;
> }
>
> -static void pnv_ioda2_reserve_m64_pe(struct pnv_phb *phb)
> +static void pnv_ioda_reserve_m64_pe(struct pnv_phb *phb)
> {
> resource_size_t sgsz = phb->ioda.m64_segsize;
> struct pci_dev *pdev;
> @@ -248,8 +309,8 @@ static void pnv_ioda2_reserve_m64_pe(struct pnv_phb *phb)
> }
> }
>
> -static int pnv_ioda2_pick_m64_pe(struct pnv_phb *phb,
> - struct pci_bus *bus, int all)
> +static int pnv_ioda_pick_m64_pe(struct pnv_phb *phb,
> + struct pci_bus *bus, int all)
> {
> resource_size_t segsz = phb->ioda.m64_segsize;
> struct pci_dev *pdev;
> @@ -346,6 +407,28 @@ done:
> pe->master = master_pe;
> list_add_tail(&pe->list, &master_pe->slaves);
> }
> +
> + /* P7IOC supports M64DT, which helps mapping M64 segment
> + * to one particular PE#. Unfortunately, PHB3 has fixed
Why is it "Unfortunately"? This is just the way it is :)
> + * mapping between M64 segment and PE#. In order for 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;
Here @rc is of the "int64_t" type. And this one and the one above are used
for return code from OPAL API. Make them the same (int64_t or long, up to you).
> +
> + 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: Failure %lld mapping "
> + "M64 for PHB#%d-PE#%d\n",
> + __func__, rc,
> + phb->hose->global_number,
> + pe->pe_number);
> + }
> }
>
> kfree(pe_alloc);
> @@ -360,12 +443,6 @@ 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) {
> - pr_info(" Not support M64 window\n");
> - return;
> - }
> -
> if (!firmware_has_feature(FW_FEATURE_OPALv3)) {
> pr_info(" Firmware too old to support M64 window\n");
> return;
> @@ -394,9 +471,23 @@ 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;
reserve_m64_pe() is called once from pnv_pci_ioda_setup_PEs() so it is
IODA-only and in this case reserve_m64_pe != NULL and
pnv_ioda_reserve_m64_pe() will be called always.
In general, it feels like pnv_phb has too many callbacks while they could
be just direct calls.
> + 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:
> + phb->init_m64 = NULL;
> + phb->reserve_m64_pe = NULL;
> + phb->pick_m64_pe = NULL;
> + phb->ioda.m64_size = 0;
> + phb->ioda.m64_segsize = 0;
> + phb->ioda.m64_base = 0;
There are just 2 PHB types - IODA1 and IODA2, right? And the fields you
reset after "default" - they have to be zeroes already, no? And on what
hardware would the default branch actuall work? None?
> + }
> }
>
> static void pnv_ioda_freeze_pe(struct pnv_phb *phb, int pe_no)
>
--
Alexey
next prev parent reply other threads:[~2015-05-09 0:18 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 [this message]
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
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
2015-05-14 0:18 ` Rob Herring
2015-05-14 0:18 ` Rob Herring
2015-05-14 0:18 ` Rob Herring
2015-05-14 0:54 ` Benjamin Herrenschmidt
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
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
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
2015-05-14 7:34 ` Pantelis Antoniou
2015-05-14 7:34 ` Pantelis Antoniou
2015-05-14 7:34 ` Pantelis Antoniou
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
2015-06-07 7:54 ` Grant Likely
2015-06-07 7:54 ` Grant Likely
2015-06-08 20:57 ` Benjamin Herrenschmidt
2015-06-08 20:57 ` Benjamin Herrenschmidt
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=554D5262.2030109@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=gwshan@linux.vnet.ibm.com \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.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.