ry
pass will never see that device so the saving the BARs is pointless.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 57
1 file changed, 22 insertions(+), 35 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c
De-duplicate, and fix up the comments, and make the prototype just take a
pci_dn since the job of the function is to return the pe_config_addr of the
PE which contains a given device.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 80 +++---
flow a bit by moving the platform EEH
inititalisation to an arch_initcall so we can fold the bus notifier
registration into eeh_init().
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh.c| 64 ++--
arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-
a
No longer used since the platforms perform their EEH initialisation before
calling eeh_init().
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 1 -
arch/powerpc/kernel/eeh.c | 8
2 files changed, 9 deletions(-)
diff --git a/arch/powerpc/include/asm/ee
Fold pseries_eeh_init() into eeh_pseries_init() rather than having
eeh_init() call it via eeh_ops->init(). It's simpler and it'll let us
delete eeh_ops.init.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 155 +--
Fold pnv_eeh_init() into eeh_powernv_init() rather than having eeh_init()
call it via eeh_ops->init(). It's simpler and it'll let us delete
eeh_ops.init.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 94 ++--
1 file chan
easier to
follow.
No functional changes.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 3 +-
arch/powerpc/kernel/eeh.c| 87
arch/powerpc/platforms/powernv/eeh-powernv.c | 4 +-
arch/powerpc/platforms/pseries/eeh
This is really two series joined together since they end up conflicting
with each other lighty slightly and I figured this is easier for all
involved.
Patches 1-5 streamline how the generic and platform specfic parts of EEH
are initialised at boot so more of the setup process happens in linear cod
The MPS field in the VF config space is marked as reserved in current
versions of the SR-IOV spec. In other words, this fixup doesn't do
anything.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 18 --
1 file changed, 18 deletion
The corresponding definitions were deleted in commit 3d5134ee8341
("[POWERPC] Rewrite IO allocation & mapping on powerpc64") which
was merged a mere 13 years ago.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/ppc-pci.h | 4
1 file changed, 4 deletions(-)
Nothing uses it.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/ppc-pci.h | 3 ---
arch/powerpc/kernel/pci_dn.c | 40 --
2 files changed, 43 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-pci.h
b/arch/powerpc/include/asm/ppc-
bgfs(). That function has its entire body wrapped
in #ifdef CONFIG_DEBUG_FS. As a result, for kernels built without debugfs
(i.e. petitboot) the other checks in pnv_pci_enable_device_hook() are
bypassed entirely.
Signed-off-by: Oliver O'Halloran
---
v2: reword commit message a bit
---
worth pointing out that ->initialized flag is set in
pnv_pci_ioda_create_dbgfs() which has the entire function body wrapped in
flag. That has the fun side effect of bypassing any other checks in
pnv_pci_enable_device_hook() which is probably not what anybody wants.
Signed-off-by: Oliver O'
On Mon, Aug 31, 2020 at 10:08 AM Alexey Kardashevskiy wrote:
>
> On 29/08/2020 05:55, Leonardo Bras wrote:
> > On Fri, 2020-08-28 at 12:27 +1000, Alexey Kardashevskiy wrote:
> >>
> >> On 28/08/2020 01:32, Leonardo Bras wrote:
> >>> Hello Alexey, thank you for this feedback!
> >>>
> >>> On Sat, 202
On Sat, Aug 22, 2020 at 6:51 AM Shawn Anastasio wrote:
>
> Implement pcibios_default_alignment for pseries so that
> resources are page-aligned. The main benefit of this is being
> able to map any resource from userspace via mechanisms like VFIO.
Reviewed-by: Oliver O'Hal
ack
trace is helpful for avoiding this sort of problem in the future.
Anyway,
Reviewed-by: Oliver O'Halloran
> Only impacts ioda2, the code path for ioda1 is correct.
yeah but no ones uses ioda1
> Fixes: 01e12629af4e ("powerpc/powernv/pci: Add explicit tracking of the DMA
>
These annoy me every time I see them. Why are they here? They're not even
needed for 80cols compliance.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc
On Tue, Aug 4, 2020 at 12:07 PM Joel Stanley wrote:
>
> Messy:
>
> $ git grep "define DBG(" arch/powerpc/ |grep -v print
> arch/powerpc/kernel/crash_dump.c:#define DBG(fmt...)
> arch/powerpc/kernel/iommu.c:#define DBG(...)
> arch/powerpc/kernel/legacy_serial.c:#define DBG(fmt...) do { } while(0)
>
c: Haren Myneni
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/icswx.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/icswx.h b/arch/powerpc/include/asm/icswx.h
index b0c70a35fd0e..f6599ccb3012 100644
--- a/arch/powerpc/inclu
The "parent" variable in pnv_pci_ioda_configure_pe() isn't used for
anything anymore and can be dropped.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/powerpc/platforms/powern
ernal data structure so there's no real
need for it to be documented at all. Fix up the comment to squash the
warning.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/opal-prd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/p
There's a few scattered in the powernv platform.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 4 ++--
arch/powerpc/platforms/powernv/rng.c | 2 +-
arch/powerpc/platforms/powernv/vas-window.c | 9 -
3 files changed, 7 insert
opal-memcons.c since it has the
prototypes for the memcons wrangling functions which are used for the opal
and ultravisor msglog.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/opal-msglog.c | 2 ++
arch/powerpc/platforms/powernv/powernv.h | 7 +++
2 files
d DBG() expands to nothing and GCC emits
the warning due to the lack of braces around an empty statement.
Signed-off-by: Oliver O'Halloran
---
We could add the braces too. That might even be better since it's a multi-line
if block even though it's only a single statement.
---
arch/po
Fixes the (mostly) suprious errors we get when building powernv with
W=1. More work is required to build all of powerpc with W=1, let alone
W=2.
Initialising the value before using it is generally regarded as a good
idea so do that.
Fixes: 4c51f3e1e870 ("powerpc/powernv/sriov: Make single PE mode a per-BAR
setting")
Reported-by: Nathan Chancellor
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/
On Thu, Apr 30, 2020 at 11:15 PM Max Gurtovoy wrote:
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 57d3a6a..9ecc576 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -370
ould be imposed in platform code.
I'd like to fix that, but I'd prefer to do it as a follow up change
since I need to have a think about how to fix the firmware bits.
Reviewed-by: Oliver O'Halloran
On Tue, Jul 21, 2020 at 3:51 PM Forest Crossman wrote:
>
> Hello, again!
>
> After fixing the issue in my previous thread using this patch[1], I
> decided to do some stress-testing of the controller to make sure it
> could handle my intended workloads and that there were no further DMA
> address i
On Wed, Jul 29, 2020 at 8:35 AM Gustavo Romero wrote:
>
> Currently pnv_ioda_setup_bus_dma() is outside of a CONFIG_IOMMU_API guard
> and if CONFIG_IOMMU_API=n the build can fail if the compiler sets
> -Werror=unused-function, because pnv_ioda_setup_bus_dma() is only used in
> functions guarded by
t; iov = pnv_iov_get(pdev);
> num_vfs = iov->num_vfs;
> base_pe = iov->vf_pe_arr[0].pe_number;
>
Acked-by: Oliver O'Halloran
ng.
Fixes: 85d86c8aa52e ("selftests/powerpc: Add basic EEH selftest")
Signed-off-by: Oliver O'Halloran
---
tools/testing/selftests/powerpc/eeh/eeh-functions.sh | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/powerpc/eeh/
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
v3: no changes
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/powerpc/kernel/eeh_
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
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
v3: no changes
---
arch/powerpc/include/asm/eeh.h
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
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
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/
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 changes
v3: no changes
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/powerpc/kernel/
[]). 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
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
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
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 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/
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
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
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
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/
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
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
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
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
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'
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
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
-
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
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
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
---
v2: no changes
---
arch/powerpc/include/asm/device.h
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
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
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 +++
_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
-
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).
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&
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
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-
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
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
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
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
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 changes
---
arch/powerpc/include/asm/eeh.h | 2 +-
arch/powerpc/kernel/eeh.c
[]). 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
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
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
-
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 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
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
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
On Fri, Jul 17, 2020 at 8:10 PM Forest Crossman wrote:
>
> > From word 2 of the PEST entry the faulting DMA address is:
> > 0x203974c0. That address is interesting since it looks a lot
> > like a memory address on the 2nd chip, but it doesn't have bit 59 set
> > so TVE#0 is used to validat
On Fri, Jul 17, 2020 at 2:14 PM Forest Crossman wrote:
>
> Hi, all,
>
> I have several ASMedia USB 3.x host controllers (ASM2142 and ASM3142,
> both share the same Vendor ID/Device ID pair) that I'd like to use
> with a POWER9 system (a Raptor Computing Systems Talos II).
> Unfortunately, while th
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
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 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 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 8:03 AM Arnd Bergmann wrote:
>
> - Most error checking is static: PCIBIOS_BAD_REGISTER_NUMBER
> only happens if you pass an invalid register number, but most
> callers pass a compile-time constant register number that is
> known to be correct, or the driver would neve
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
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 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 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 2:45 PM Srikar Dronamraju
wrote:
>
> Current code assumes that cpumask of cpus sharing a l2-cache mask will
> always be a superset of cpu_sibling_mask.
>
> Lets stop that assumption.
It's been a while since I looked, but I'm pretty sure the scheduler
requires child domains
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
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 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 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 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
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
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
101 - 200 of 692 matches
Mail list logo
