On Fri, Apr 23, 2021 at 9:09 AM Daniel Axtens wrote:
>
> Hi Nick,
>
> > While looking at -Wundef warnings, the #if CONFIG_EEH stood out as a
> > possible candidate to convert to #ifdef CONFIG_EEH, but it seems that
> > based on Kconfig dependencies it's not possible to build this file
> > without
On Fri, May 7, 2021 at 3:43 AM Mahesh Salgaonkar wrote:
>
> When certain PHB HW failure causes phyp to recover PHB, it marks the PE
> state as temporarily unavailable. In this case, per PAPR, rtas call
> ibm,read-slot-reset-state2 returns a PE state as temporarily unavailable(5)
> and OS has to wa
On Fri, Jun 4, 2021 at 7:39 PM He Ying wrote:
>
> From "64-bit PowerPC ELF Application Binary Interface Supplement 1.9",
> we know that the value of a function pointer in a language like C is
> the address of the function descriptor and the first doubleword
> of the function descriptor contains th
On Tue, Jun 8, 2021 at 4:33 PM He Ying wrote:
>
> Hello,
>
> 在 2021/6/8 13:26, Oliver O'Halloran 写道:
> > On Fri, Jun 4, 2021 at 7:39 PM He Ying wrote:
> >> From "64-bit PowerPC ELF Application Binary Interface Supplement 1.9",
> >> we know that
The kernel test robot noticed these are non-static which causes Clang to
print some warnings. These are called via ppc_md function pointers so
there's no need for them to be non-static.
Reported-by: kernel test robot
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/p
pnv_ioda_setup_bus_dma() is only used when a passed through PE is
returned to the host. If the kernel is built without IOMMU support
this is dead code. Move it under the #ifdef with the rest of the
IOMMU API support.
Reported-by: kernel test robot
Signed-off-by: Oliver O'Halloran
---
eries platforms though.
There'll be a follow up to this which actually removes the use of pci_dn
from PowerNV entirely and we can start looking at properly supporting
native PCIe. At last.
Oliver
This function is a one line wrapper around eeh_phb_pe_create() and despite
the name it doesn't create any eeh_dev structures. Replace it with direct
calls to eeh_phb_pe_create() since that does what it says on the tin
and removes a layer of indirection.
Signed-off-by: Oliver O'Halloran
The only thing in this file is eeh_dev_init() which is allocates and
initialises an eeh_dev based on a pci_dn. This is only ever called from
pci_dn.c so move it into there and remove the file.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 6
arch/powerpc/k
the vf_index.
The easiest thing to do here is move the vf_index field out of pci_dn and
into eeh_dev. Currently pci_dn and eeh_dev are allocated and initialized
together so this is a fairly minimal change in preparation for splitting
pci_dn and eeh_dev in the future.
Signed-off-by: Oliver
The pci_dn->pe_number field is mainly used to track the IODA PE number of a
device on PowerNV. At some point it grew a user in the pseries SR-IOV
support which muddies the waters a bit, so remove it.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/eeh_pserie
This is used in precisely one place which is in pseries specific platform
code. There's no need to have the callback in eeh_ops since the platform
chooses the EEH PE addresses anyway. The PowerNV implementation has always
been a stub too so remove it.
Signed-off-by: Oliver O'Halloran
[]). This is
inadequate since it doesn't even consider saving and restoring the PCI
capability structures. However, this is a problem with EEH in general and
that needs to be fixed for non-VF devices too.
There's no real reason to keep around this around so delete it.
Signed-off-by: Oli
Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference
a specific device rather than pci_dn. No functional changes.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/powerpc/kernel/eeh.c| 5 ++---
arch/po
Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference
a specific device rather than pci_dn. No functional changes.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/powerpc/kernel/eeh_driver.c | 4 ++--
arch/po
Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference
a specific device rather than pci_dn. No functional changes.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 4 +-
arch/powerpc/kernel/eeh.c| 22 +
Retrieve the domain, bus, device, and function numbers from the edev.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 1a12c8b
The edev->class_code field is never referenced anywhere except for the
platform specific probe functions. The same information is available in
the pci_dev for PowerNV and in the pci_dn on pseries so we can remove
the field.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/a
e bulk of the implementation of eeh_add_to_parent_pe() covers that
second case. Similarly, most of eeh_remove_from_parent_pe() is
determining when it's safe to delete a PE.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 4 ++--
ar
hat what RTAS calls a
"config_addr" isn't the same as the bdfn. The config_addr is supposed to
be: with each field being an 8 bit number. Various parts
of the EEH code use BDFN and "config_addr" as interchangeable quantities
even though they aren't really.
Signed-off-by: O
ot remove it entirely
until we've had a chance to look at it more deeply.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/powerpc/kernel/eeh_pe.c | 70 ++--
arch/powerpc/platforms/powernv/eeh-powe
630
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=187688
Rebases cleanly on top of the first, but I haven't tested that one plus
this extensively.
Oliver
_controller inside the function. This is
hard to read since it requires you to memorise the contents of the
private data fields and kind of error prone since it involves blindly
assigning a void pointer. Add a helper to make it more concise and
explicit.
Signed-off-by: Oliver O'Halloran
-
kip a call to pnv_pci_ioda2_unset_window() unless
CONFIG_IOMMU_API=y is set. There's no real point in doing this so fold the
two together.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 30 +++
1 file changed, 3 insertions(+), 27 del
t up DMA on demand.
This also means the only remaining user of the old "DMA Weight" code is
the IODA1 DMA setup code that it was originally added for, which is good.
Cc: Alexey Kardashevskiy
Signed-off-by: Oliver O'Halloran
---
Alexey, do we need to have the IOMMU API stuff set/clea
We pre-configure the m64 window for IODA1 as a 1-1 segment-PE mapping,
similar to PHB3. Currently the actual mapping of segments occurs in
pnv_ioda_pick_m64_pe(), but we can move it into pnv_ioda1_init_m64() and
drop the IODA1 specific code paths in the PE setup / teardown.
Signed-off-by: Oliver
SR-IOV support on PowerNV is a byzantine maze of hooks. I have no idea
how anyone is supposed to know how it works except through a lot of
stuffering. Write up some docs about the overall story to help out
the next sucker^Wperson who needs to tinker with it.
Signed-off-by: Oliver O'Hal
specific structure. I'm not sure how they ended up in there
in the first place, but leaking platform specifics into common code has
proven to be a terrible idea so far so lets stop doing that.
Signed-off-by: Oliver O'Halloran
---
The pci_dn change and the pci-sriov.c changes originally separa
This prevents SR-IOV being used by making the SR-IOV BAR resources
unallocatable. Rename it to reflect what it actually does.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-sriov.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a
No need for the multi-dimensional arrays, just use a bitmap.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-sriov.c | 48 +++---
arch/powerpc/platforms/powernv/pci.h | 7 +++-
2 files changed, 20 insertions(+), 35 deletions(-)
diff --git a
the PE
For Single PE BARs the process is:
1. Set the PE for segment zero on a disabled window
2. Set the range
3. Enable the window
Move the OPAL calls into their own helper functions where the quirks can be
contained.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powern
Rework the PE allocation logic to allow allocating blocks of PEs rather
than individually. We'll use this to allocate contigious blocks of PEs for
the SR-IOVs.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 41 ++-
arch/powerpc
ode) {} .. else {} block scattered
through the SR-IOV code which is a nice clean up.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-sriov.c | 109 +
arch/powerpc/platforms/powernv/pci.h | 4 +-
2 files changed, 25 insertions(+), 88 deletions(-)
di
Remove the IODA2 PHB checks. We already assume IODA2 in several places so
there's not much point in wrapping most of the setup and teardown process
in an if block.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-sriov.c | 86 --
1 file c
I want to refactor the loop this code is currently inside of. Hoist it on
out.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-sriov.c | 31 ++
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-sr
Split up the logic so that we have one branch that handles setting up a
segmented window and another that handles setting up single PE windows for
each VF.
Signed-off-by: Oliver O'Halloran
---
This patch could be folded into the previous one. I've kept it
seperate mainly because t
apped
with a regular segmented window. Make the segmented vs single decision a
per-BAR setting and clean up the logic that decides which mode to use.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-sriov.c | 131 +++--
arch/powerpc/platforms/pow
On Fri, Jul 10, 2020 at 4:45 PM Christoph Hellwig wrote:
>
> On Fri, Jul 10, 2020 at 03:23:25PM +1000, Oliver O'Halloran wrote:
> > This is largely prep work for supporting VFs in the 32bit MMIO window.
> > This is an unfortunate necessity due to how the Linux BAR all
On Mon, Jul 13, 2020 at 6:56 PM Alexey Kardashevskiy wrote:
>
>
>
> On 06/07/2020 11:36, Oliver O'Halloran wrote:
> > Drivers that do not support the PCI error handling callbacks are handled by
> > tearing down the device and re-probing them. If the device to be remo
On Mon, Jul 13, 2020 at 8:32 PM Alexey Kardashevskiy wrote:
>
> > #ifdef CONFIG_PCI_IOV
> > int pseries_send_allow_unfreeze(struct pci_dn *pdn,
> > u16 *vf_pe_array, int cur_vfs)
> > @@ -848,7 +824,7 @@ static struct eeh_ops pseries_eeh_ops = {
> > .read_confi
On Mon, Jul 13, 2020 at 7:54 PM Alexey Kardashevskiy wrote:
>
>
>
> On 06/07/2020 11:36, Oliver O'Halloran wrote:
> > This is used in precisely one place which is in pseries specific platform
> > code. There's no need to have the callback in eeh_ops since t
On Tue, Jul 14, 2020 at 11:50 AM Alexey Kardashevskiy wrote:
>
> On 06/07/2020 11:36, Oliver O'Halloran wrote:
> > /**
> > * eeh_pe_tree_insert - Add EEH device to parent PE
> > * @edev: EEH device
> > + * @new_pe_parent: PE to create additional PEs unde
scheduler
requires child domains to be subsets of their parents. Why is this
necessary or a good idea?
> Cc: linuxppc-dev
> Cc: Michael Ellerman
> Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Sheno
On Tue, Jul 14, 2020 at 3:37 PM Alexey Kardashevskiy wrote:
>
> On 10/07/2020 15:23, Oliver O'Halloran wrote:
> > There's an optimisation in the PE setup which skips performing DMA
> > setup for a PE if we only have bridges in a PE. The assumption being
> > th
On Tue, Jul 14, 2020 at 5:21 PM Alexey Kardashevskiy wrote:
>
> On 14/07/2020 15:58, Oliver O'Halloran wrote:
> > On Tue, Jul 14, 2020 at 3:37 PM Alexey Kardashevskiy wrote:
> >>
> >> On 10/07/2020 15:23, Oliver O'Halloran wrote:
> >>> Thi
On Wed, Jul 15, 2020 at 11:34 AM Alexey Kardashevskiy wrote:
>
> On 10/07/2020 15:23, Oliver O'Halloran wrote:
> > diff --git a/arch/powerpc/platforms/powernv/pci.h
> > b/arch/powerpc/platforms/powernv/pci.h
> > index 0156d7d17f7d..58c97e60c3db 100644
> > -
On Wed, Jul 15, 2020 at 12:29 PM Alexey Kardashevskiy wrote:
>
>
>
> On 10/07/2020 15:23, Oliver O'Halloran wrote:
> > Rework the PE allocation logic to allow allocating blocks of PEs rather
> > than individually. We'll use this to allocate contigious blocks o
err.c. I think the latter could be
moved into the PCI core easily enough since there's not much about it
that's really specific to PCIe. Ideally we could drop the EEH specific
one too, but I'm not sure how to implement that without it devolving
into callback spaghetti.
Oliver
On Wed, Jul 15, 2020 at 2:00 PM Alexey Kardashevskiy wrote:
>
>
> or we could just skip setting
>
> ppc_md.pcibios_sriov_enable = pnv_pcibios_sriov_enable;
>
> for uninteresting platforms in pnv_pci_init_ioda_phb().
I don't think so. ppc_md is per-platform, not per-PHB andw e still
have to deal w
On Wed, Jul 15, 2020 at 2:41 PM Alexey Kardashevskiy wrote:
>
>
>
> On 15/07/2020 14:21, Oliver O'Halloran wrote:
> > On Wed, Jul 15, 2020 at 2:00 PM Alexey Kardashevskiy wrote:
> >>
> >>
> >> or we could just skip setting
> >>
On Wed, Jul 15, 2020 at 3:24 PM Alexey Kardashevskiy wrote:
>
>
> > @@ -158,9 +157,9 @@ static void pnv_pci_ioda_fixup_iov_resources(struct
> > pci_dev *pdev)
> > goto disable_iov;
> > pdev->dev.archdata.iov_data = iov;
> >
> > + /* FIXME: totalvfs > phb->ioda.total_pe_num
On Wed, Jul 15, 2020 at 5:05 PM Cédric Le Goater wrote:
>
> I could but can we fix the issue below before I reboot ? I don't have a
> console anymore on these boxes.
>
> Firmware is :
> *snip*
Do you know when that started happening? I don't think anything
console related has changed in a very l
pass trick above works, what you really need to do is
have the driver report that it can't address all 64bits by setting its
DMA mask accordingly. For the xhci driver it looks like this is done
in xhci_gen_setup(), there might be a quirks-style interface for
working around bugs in specific controllers that you can use. Have a
poke around and see what you can find :)
Oliver
as so
> simple, but the time savings alone more than makes up for it. I'll
> submit the patch to the USB ML shortly.
It might be only three lines, but it doesn't mean it's trivial. Most
bugs like that require a lot of context to understand, let alone fix.
Thanks for looking into it!
Oliver
On Sun, Jul 19, 2020 at 5:13 AM Greg Thelen wrote:
>
> Oliver O'Halloran wrote:
>
> > On Mon, Jun 15, 2020 at 9:33 AM Greg Thelen wrote:
> >>
> >> Commit dc3d8f85bb57 ("powerpc/powernv/pci: Re-work bus PE
> >> configuration") remove
This function is a one line wrapper around eeh_phb_pe_create() and despite
the name it doesn't create any eeh_dev structures. Replace it with direct
calls to eeh_phb_pe_create() since that does what it says on the tin
and removes a layer of indirection.
Signed-off-by: Oliver O'Hallor
The only thing in this file is eeh_dev_init() which is allocates and
initialises an eeh_dev based on a pci_dn. This is only ever called from
pci_dn.c so move it into there and remove the file.
Signed-off-by: Oliver O'Halloran
---
v2: no change
---
arch/powerpc/include/asm/eeh.h | 6
easiest thing to do here is move the vf_index field out of pci_dn and
into eeh_dev. Currently pci_dn and eeh_dev are allocated and initialized
together so this is a fairly minimal change in preparation for splitting
pci_dn and eeh_dev in the future.
Signed-off-by: Oliver O'Halloran
Review
The pci_dn->pe_number field is mainly used to track the IODA PE number of a
device on PowerNV. At some point it grew a user in the pseries SR-IOV
support which muddies the waters a bit, so remove it.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: no change
-
This is used in precisely one place which is in pseries specific platform
code. There's no need to have the callback in eeh_ops since the platform
chooses the EEH PE addresses anyway. The PowerNV implementation has always
been a stub too so remove it.
Signed-off-by: Oliver O'Halloran
[]). This is
inadequate since it doesn't even consider saving and restoring the PCI
capability structures. However, this is a problem with EEH in general and
that needs to be fixed for non-VF devices too.
There's no real reason to keep around this around so delete it.
Signed-off-b
Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference
a specific device rather than pci_dn. No functional changes.
Signed-off-by: Oliver O'Halloran
---
v2: no changes
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/powerpc/kernel/eeh.c
Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference
a specific device rather than pci_dn. No functional changes.
Signed-off-by: Oliver O'Halloran
---
v2: no changes
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/powerpc/kernel/eeh_driver.c
Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference
a specific device rather than pci_dn. No functional changes.
Signed-off-by: Oliver O'Halloran
---
v2: no change
---
arch/powerpc/include/asm/eeh.h | 4 +-
arch/powerpc/kernel/eeh.c
Retrieve the domain, bus, device, and function numbers from the edev.
Signed-off-by: Oliver O'Halloran
---
v2: no change
---
arch/powerpc/kernel/eeh.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
The edev->class_code field is never referenced anywhere except for the
platform specific probe functions. The same information is available in
the pci_dev for PowerNV and in the pci_dn on pseries so we can remove
the field.
Signed-off-by: Oliver O'Halloran
---
v2: no changes
---
arch
e bulk of the implementation of eeh_add_to_parent_pe() covers that
second case. Similarly, most of eeh_remove_from_parent_pe() is
determining when it's safe to delete a PE.
Signed-off-by: Oliver O'Halloran
---
v2: no changes
---
arch/powerpc/include/asm/eeh.h | 4 ++--
ar
hat what RTAS calls a
"config_addr" isn't the same as the bdfn. The config_addr is supposed to
be: with each field being an 8 bit number. Various parts
of the EEH code use BDFN and "config_addr" as interchangeable quantities
even though they aren't really.
Signed-off-
ot remove it entirely
until we've had a chance to look at it more deeply.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: Reworked pseries PE setup slightly. NOT DONE YET. mostly done needs test
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/p
On Tue, Jul 14, 2020 at 7:16 PM Alexey Kardashevskiy wrote:
>
> On 10/07/2020 15:23, Oliver O'Halloran wrote:
> > + align = pci_iov_resource_size(pdev, resno);
> > +
> > + /*
> > + * iov can be null if we have an SR-IOV device with IOV BAR that can&
On Wed, Jul 15, 2020 at 6:00 PM Alexey Kardashevskiy wrote:
>
> >>>*
> >>> - * Generally, one M64 BAR maps one IOV BAR. To avoid
> >>> conflict
> >>> - * with other devices, IOV BAR size is expanded to be
> >>> - * (total_pe * VF_BAR_size).
_controller inside the function. This is
hard to read since it requires you to memorise the contents of the
private data fields and kind of error prone since it involves blindly
assigning a void pointer. Add a helper to make it more concise and
explicit.
Signed-off-by: Oliver O'Halloran
-
kip a call to pnv_pci_ioda2_unset_window() unless
CONFIG_IOMMU_API=y is set. There's no real point in doing this so fold the
two together.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: no change
---
arch/powerpc/platforms/powernv/pci-ioda.c | 30 +++
t up DMA on demand.
This also means the only remaining user of the old "DMA Weight" code is
the IODA1 DMA setup code that it was originally added for, which is good.
Cc: Alexey Kardashevskiy
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: no changes
---
a
We pre-configure the m64 window for IODA1 as a 1-1 segment-PE mapping,
similar to PHB3. Currently the actual mapping of segments occurs in
pnv_ioda_pick_m64_pe(), but we can move it into pnv_ioda1_init_m64() and
drop the IODA1 specific code paths in the PE setup / teardown.
Signed-off-by: Oliver
specific structure. I'm not sure how they ended
up in there in the first place, but leaking platform specifics into common
code has proven to be a terrible idea so far so lets stop doing that.
Signed-off-by: Oliver O'Halloran
---
v2: no changes
---
arch/powerpc/include/asm/device.h
SR-IOV support on PowerNV is a byzantine maze of hooks. I have no idea
how anyone is supposed to know how it works except through a lot of
stuffering. Write up some docs about the overall story to help out
the next sucker^Wperson who needs to tinker with it.
Signed-off-by: Oliver O'Hal
This prevents SR-IOV being used by making the SR-IOV BAR resources
unallocatable. Rename it to reflect what it actually does.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: no changes
---
arch/powerpc/platforms/powernv/pci-sriov.c | 11 ++-
1 file chang
No need for the multi-dimensional arrays, just use a bitmap.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: Fixed license to GPL-2.0-or-later
Added MAX_M64_BARS for the size of the M64 allocation bitmap rather than
open coding 64.
---
arch/powerpc/plat
the PE
For Single PE BARs the process is:
1. Set the PE for segment zero on a disabled window
2. Set the range
3. Enable the window
Move the OPAL calls into their own helper functions where the quirks can be
contained.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
-
oc_mutex. Currently these functions
use atomic bit ops to release a currently allocated PE number. However,
the pnv_ioda_alloc_pe() wants to have exclusive access to the bit map while
scanning for hole large enough to accomodate the allocation size.
Signed-off-by: Oliver O'Halloran
---
v2: Add some
ode) {} .. else {} block scattered
through the SR-IOV code which is a nice clean up.
This also fixes a bug in pnv_pci_sriov_disable() which is the non-atomic
bitmap_clear() to manipulate the PE allocation map. Other users of the map
assume it will be accessed with atomic ops.
Signed-off-by: Oliver O'
Remove the IODA2 PHB checks. We already assume IODA2 in several places so
there's not much point in wrapping most of the setup and teardown process
in an if block.
Signed-off-by: Oliver O'Halloran
---
v2: Added a note that iov->vf_pe_arr is a pointer into the PHB's PE arr
I want to refactor the loop this code is currently inside of. Hoist it on
out.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: no change
---
arch/powerpc/platforms/powernv/pci-sriov.c | 31 ++
1 file changed, 20 insertions(+), 11 dele
Split up the logic so that we have one branch that handles setting up a
segmented window and another that handles setting up single PE windows for
each VF.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: no changes
---
arch/powerpc/platforms/powernv/pci-sriov.c
apped
with a regular segmented window. Make the segmented vs single decision a
per-BAR setting and clean up the logic that decides which mode to use.
Signed-off-by: Oliver O'Halloran
---
v2: Dropped unused total_vfs variables in pnv_pci_ioda_fixup_iov_resources()
Dropped b
ield for either since the multiple in 1) is
always the number PEs supported by the PHB. Similarly, we don't really need
it in 2) either since the IOV data field will be NULL if we can't use IOV
with the device.
Signed-off-by: Oliver O'Halloran
---
v2: New
---
arch/powerpc/platforms/
On Wed, Jul 22, 2020 at 8:06 PM Alexey Kardashevskiy wrote:
>
> >> Well, realistically the segment size should be 8MB to make this matter
> >> (or the whole window 2GB) which does not seem to happen so it does not
> >> matter.
> >
> > I'm not sure what you mean.
>
> I mean how can we possibly hit
On Fri, Jul 24, 2020 at 3:01 PM Alexey Kardashevskiy wrote:
>
>
>
> On 22/07/2020 14:26, Oliver O'Halloran wrote:
> > The EEH core has a concept of a "PE tree" to support PowerNV. The PE tree
> > follows the PCI bus structures because a reset asserted on an
This function is a one line wrapper around eeh_phb_pe_create() and despite
the name it doesn't create any eeh_dev structures. Replace it with direct
calls to eeh_phb_pe_create() since that does what it says on the tin
and removes a layer of indirection.
Signed-off-by: Oliver O'Hallor
The only thing in this file is eeh_dev_init() which is allocates and
initialises an eeh_dev based on a pci_dn. This is only ever called from
pci_dn.c so move it into there and remove the file.
Signed-off-by: Oliver O'Halloran
---
v2: no change
v3: no change
---
arch/powerpc/include/asm/
easiest thing to do here is move the vf_index field out of pci_dn and
into eeh_dev. Currently pci_dn and eeh_dev are allocated and initialized
together so this is a fairly minimal change in preparation for splitting
pci_dn and eeh_dev in the future.
Signed-off-by: Oliver O'Halloran
Review
The pci_dn->pe_number field is mainly used to track the IODA PE number of a
device on PowerNV. At some point it grew a user in the pseries SR-IOV
support which muddies the waters a bit, so remove it.
Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
---
v2: no chang
This is used in precisely one place which is in pseries specific platform
code. There's no need to have the callback in eeh_ops since the platform
chooses the EEH PE addresses anyway. The PowerNV implementation has always
been a stub too so remove it.
Signed-off-by: Oliver O'Halloran
[]). This is
inadequate since it doesn't even consider saving and restoring the PCI
capability structures. However, this is a problem with EEH in general and
that needs to be fixed for non-VF devices too.
There's no real reason to keep around this around so delete it.
Signed-off-b
Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference
a specific device rather than pci_dn. No functional changes.
Signed-off-by: Oliver O'Halloran
---
v2: no changes
v3: no changes
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/powerpc/kernel/
Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference
a specific device rather than pci_dn. No functional changes.
Signed-off-by: Oliver O'Halloran
---
v2: no changes
v3: no changes
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/powerpc/kernel/eeh_dri
Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference
a specific device rather than pci_dn. No functional changes.
Signed-off-by: Oliver O'Halloran
---
v2: no change
v3: no change
---
arch/powerpc/include/asm/eeh.h | 4 +-
arch/powerpc/kernel/
Retrieve the domain, bus, device, and function numbers from the edev.
Signed-off-by: Oliver O'Halloran
---
v2: no change
v3: no change
---
arch/powerpc/kernel/eeh.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/po
The edev->class_code field is never referenced anywhere except for the
platform specific probe functions. The same information is available in
the pci_dev for PowerNV and in the pci_dn on pseries so we can remove
the field.
Signed-off-by: Oliver O'Halloran
---
v2: no changes
v3: no
501 - 600 of 831 matches
Mail list logo
