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(-)
diff --
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/platforms
to 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/powernv/pci
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/arch
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/arch
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 separate patches
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'Halloran
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
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/clear this flag?
---
ar
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 deletions(-)
diff
roller 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
---
arch/p
Finally bit the bullet and learned how all the MMIO->PE mapping setup
actually works. As a side effect I found a bunch of oddities in how
PowerNV SR-IOV support is implemented. This series mostly sorts that
out with a few more generic cleanups along the way.
This is largely prep work for
til 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-powernv.c | 27 +++-
arch/powerpc/platfo
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: Oliver O'Hallora
ulk 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 ++--
arch/powerpc/kernel/ee
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/asm/ee
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 1a12c8bdf61e
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 +
arch
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/powerpc
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/powerpc
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: Oliver O'Halloran
---
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
---
arch
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_pseries.c |
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 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/kernel
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
---
arch
Removes most of the uses of pci_dn in the EEH core. There's a few
stragglers remaining in pseries specific bits of kernel/eeh*.c mainly
the the support for "open sriov" where the hypervisor allows the guest
to manage SR-IOV physical functions. We can largely ignore that on
non-pseries platforms
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
---
arch
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/powernv/pci
On Mon, 2020-03-30 at 17:39 +1100, Sam Bobroff wrote:
> There is currently little synchronization between EEH error detection
> (eeh_dev_check_failure()), EEH error recovery
> (eeh_handle_{normal,special}_event()) and the PCI subsystem (device
> addition and removal), and so there are race
On Wed, Jun 24, 2020 at 3:20 PM Sam Bobroff wrote:
>
> Give a unique ID to each recovery event, to ease log parsing and
> prepare for parallel recovery.
>
> Also add some new messages with a very simple format that may be
> useful to log-parsers.
>
> Signed-off-by: Sam Bobroff
> ---
> This patch
On Tue, Jun 23, 2020 at 11:12 AM Alexey Kardashevskiy wrote:
>
> On 23/06/2020 04:59, Leonardo Bras wrote:
> >
> >> Also, despite this particular file, the "pdn" name is usually used for
> >> struct pci_dn (not device_node), let's keep it that way.
> >
> > Sure, I got confused for some time about
On Wed, Jun 17, 2020 at 4:29 PM Michael Ellerman wrote:
>
> "Oliver O'Halloran" writes:
> > On Tue, Jun 16, 2020 at 9:55 PM Michael Ellerman
> > wrote:
> >> wenxi...@linux.vnet.ibm.com writes:
> >> > From: Wen Xiong
> >> >
> &
On Tue, Jun 16, 2020 at 9:55 PM Michael Ellerman wrote:
>
> wenxi...@linux.vnet.ibm.com writes:
> > From: Wen Xiong
> >
> > Several device drivers hit EEH(Extended Error handling) when triggering
> > kdump on Pseries PowerVM. This patch implemented a reset of the PHBs
> > in pci general code
G_IOMMU_API see:
> arch/powerpc/platforms/powernv/pci-ioda.c:1888:13: error:
> 'pnv_ioda_setup_bus_dma' defined but not used
>
> Move pnv_ioda_setup_bus_dma() under CONFIG_IOMMU_API to avoid dead code.
Doh! Thanks for the fix.
Reviewed-by: Oliver O'Halloran
n future. It's helpful to see what
we need to look at specificly when you post a new revision of a patch.
Looks good to me otherwise.
Reviewed-by: Oliver O'Halloran
ally in the Linux interrupt number space if they
> are presented in the device tree node describing the IO adapter. These
> interrupts are not un-mapped automatically and in case of an hot-plug
> adapter, the PCI hot-plug layer needs to handle the cleanup to make
> sure that all the page table entries
On Fri, May 8, 2020 at 12:36 AM wrote:
>
> From: Wen Xiong
>
> Several device drivers hit EEH(Extended Error handling) when triggering
> kdump on Pseries PowerVM. This patch implemented a reset of the PHBs
> in pci general code. PHB reset stop all PCI transactions from previous
> kernel. We have
On Sun, May 10, 2020 at 1:51 AM Christophe Leroy
wrote:
>
>
>
> Le 08/05/2020 à 19:41, Qian Cai a écrit :
> >
> >
> >> On May 8, 2020, at 10:39 AM, Qian Cai wrote:
> >>
> >> Booting POWER9 PowerNV has this message,
> >>
> >> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
>
On Sat, May 9, 2020 at 12:41 AM Qian Cai wrote:
>
> Booting POWER9 PowerNV has this message,
>
> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
> early_ioremap() instead”
>
> but use the patch below will result in leaks because it will never call
> early_iounmap()
On Wed, Apr 22, 2020 at 4:49 PM Alexey Kardashevskiy wrote:
>
> 32bit MMIO is what puzzles me in this picture, how does it work?
For devices with no m64 we allocate a PE number as described above. In
the 32bit MMIO window we have a segment-to-PE remapping table so any
m32 segment can be assigned
On Tue, Apr 21, 2020 at 11:37 PM Michael Ellerman wrote:
>
> Hi Laurent,
>
> Laurent Dufour writes:
> > The newly introduced ibm,secure-memory nodes supersede the
> > ibm,uv-firmware's property secure-memory-ranges.
>
> Is either documented in a device tree binding document anywhere?
>
> cheers
on
!CONFIG_LITTLE_ENDIAN.
This patch squashes those by switching to using machine_*_initcall() so the bus
type is only registered when the kernel is running on a pseries machine.
Reviewed-by: Tyrel Datwyler
Signed-off-by: Oliver O'Halloran
--
v2: Added explicit include for machdep.h to fix building ibmebus
On Tue, Apr 21, 2020 at 3:11 PM Alexey Kardashevskiy wrote:
>
> One example of a problem device is AMD GPU with 64bit video PCI function
> and 32bit audio, no?
>
> What PEs will they get assigned to now? Where will audio's MMIO go? It
> cannot be the same 64bit MMIO segment, right? If so, it is a
On Tue, Apr 21, 2020 at 11:53 AM Alistair Popple wrote:
>
> On Tuesday, 21 April 2020 11:30:52 AM AEST Alistair Popple wrote:
> > On Saturday, 4 April 2020 2:32:08 AM AEST Segher Boessenkool wrote:
> > > Hi!
> > >
> > > On Fri, Apr 03, 2020 at 03:10:54PM +1100, Alistair Popple wrote:
> > > >
On Fri, 2020-04-17 at 15:47 +1000, Alexey Kardashevskiy wrote:
>
> On 17/04/2020 11:26, Russell Currey wrote:
> >
> > For what it's worth this sounds like a good idea to me, it just sounds
> > tricky to implement. You're adding another layer of complexity on top
> > of EEH (well, making things
pnv_pci_ioda_configure_bus() should now only ever be called when a device is
added to the bus so add a WARN_ON() to the empty bus check. Similarly,
pnv_pci_ioda_setup_bus_PE() should only ever be called for an unconfigured PE,
so add a WARN_ON() for that case too.
Signed-off-by: Oliver O'Halloran
Doing it once during boot rather than doing it on the fly and drop the janky
populated logic.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 26 +-
arch/powerpc/platforms/powernv/pci.h | 1 -
2 files changed, 9 insertions(+), 18
t will
now be reconfigured when a new device is added since there's no
dependecy on the bridge_setup() hook being called.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 81 ---
1 file changed, 30 insertions(+), 51 deletions(-)
diff --
For each PHB we maintain a reverse-map that can be used to find the
PE that a BDFN is currently mapped to. Add a helper for doing this
lookup so we can check if a PE has been configured without looking
at pdn->pe_number.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/
This series is based on top of my previously posted series which reworks
how devices are added to their IOMMU groups. The two series are largely
orthogonal to each other, but they both touch pnv_pci_ioda_dma_dev_setup()
so there's a minor merge conflict if they aren't applied together. I can
fix
on
!CONFIG_LITTLE_ENDIAN.
This patch squashes those by switching to using machine_*_initcall() so the bus
type is only registered when the kernel is running on a pseries machine.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/ibmebus.c | 2 +-
arch/powerpc/platforms/pseries/vio.c
On Thu, Apr 16, 2020 at 12:34 PM Oliver O'Halloran wrote:
>
> On Thu, Apr 16, 2020 at 11:27 AM Alexey Kardashevskiy wrote:
> >
> > Anyone? Is it totally useless or wrong approach? Thanks,
>
> I wouldn't say it's either, but I still hate it.
>
> The 4GB mode be
On Thu, Apr 16, 2020 at 11:27 AM Alexey Kardashevskiy wrote:
>
> Anyone? Is it totally useless or wrong approach? Thanks,
I wouldn't say it's either, but I still hate it.
The 4GB mode being per-PHB makes it difficult to use unless we force
that mode on 100% of the time which I'd prefer not to
It's pretty obsecure and confused me for a long time so I figured it's
worth documenting properly.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci.h
b/arch
On Thu, Apr 9, 2020 at 4:13 PM Oliver O'Halloran wrote:
>
> If the platform decides to block enabling the device nothing is printed
> currently. This can lead to some confusion since the dmesg output will
> usually print an error with no context e.g.
>
> e1000e: pro
() already prints a
messages when it succeeds.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index cda0933
Quite useful to know in some cases.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 3d81c01..82e5098 100644
On Wed, Apr 8, 2020 at 4:22 PM Sam Bobroff wrote:
>
> On Fri, Apr 03, 2020 at 05:08:32PM +1100, Oliver O'Halloran wrote:
> > On Mon, 2020-03-30 at 15:56 +1100, Sam Bobroff wrote:
> > > When EEH device state was released asynchronously by the device
> > > re
nt of a changelog is to tell a
reader doing git archeology why a change happened and this is
sufficent for that.
Reviewed-by: Oliver O'Halloran
The NVlink IOMMU group setup is only relevant to NVLink devices so move
it into the NPU containment zone. This let us remove some prototypes in
pci.h and staticfy some function definitions.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/npu-dma.c | 54
Move it in with the rest of the TCE wrangling rather than carting around
a static prototype in pci-ioda.c
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 28 +
arch/powerpc/platforms/powernv/pci-ioda.c | 30 ---
arch
No longer used.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 32 ---
1 file changed, 32 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 9198b7882b57..8b45b8e561e9
iommu
group via a common path rather than relying on the bus notifier hack
in pnv_tce_iommu_bus_notifier() to handle the adding VFs and
hotplugged devices to their group.
Cc: Alexey Kardashevskiy
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/npu-dma.c | 8
arch/powerpc/p
that contains it. We need to ensure that group is
removed before we add the PE to the compound group that's used to keep
the translations see by the PCIe and NVLink buses the same.
No functional changes. Probably.
Cc: Alexey Kardashevskiy
Cc: Reza Arbab
Cc: Alistair Popple
Signed-off-by: Oliver
In pnv_ioda_setup_vf_PE() we register an iommu group for the VF PE
then call pnv_ioda_setup_bus_iommu_group() to add devices to that group.
However, this function is called before the VFs are scanned so there's
no devices to add.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms
Currently on PowerNV the IOMMU group of a device is initialised in
boot-time fixup which runs after devices are probed. Because this is
only run at boot time hotplugged devices do not recieve an iommu group
assignment which prevents them from being passed through to a guest.
This series fixes
: Alexey Kardashevskiy
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/npu-dma.c | 46 +++-
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index b95b9e3c4c98
On Mon, 2020-03-30 at 15:56 +1100, Sam Bobroff wrote:
> When EEH device state was released asynchronously by the device
> release handler, it was possible for an outstanding reference to
> prevent it's release and it was necessary to work around that if a
> device was re-discovered at the same PCI
On Mon, 2020-03-30 at 15:56 +1100, Sam Bobroff wrote:
> Because the bus notifier calls eeh_rmv_from_parent_pe() (via
> eeh_remove_device()) when a VF is removed, the call in
> remove_sriov_vf_pdns() is redundant.
eeh_rmv_from_parent_pe() won't actually remove the device if the
recovering flag is
switch (action) {
> + case BUS_NOTIFY_DEL_DEVICE:
> + eeh_remove_device(to_pci_dev(dev));
> + break;
> + default:
> + break;
> + }
A comment briefly explaining why we're not doing anything in the add
case might be nice.
Reviewed-by: Oliver O'
d this leads to an infinite loop.
>
> Fix this by correctly bailing out on negative values.
>
This should probably be a standalone patch. Looks fine otherwise.
Reviewed-by: Oliver O'Halloran
> Signed-off-by: Sam Bobroff
> ---
> arch/powerpc/platforms/pseries/eeh_pseries.c | 2 +-
On Fri, Apr 3, 2020 at 10:07 AM Leonardo Bras wrote:
>
> Hello Oliver, thank you for the feedback.
> Comments inline:
>
> On Fri, 2020-04-03 at 09:46 +1100, Oliver O'Halloran wrote:
> >
> > I don't really understand why the flag is needed at all. According to
&
On Fri, Apr 3, 2020 at 6:55 AM Leonardo Bras wrote:
>
> While providing guests, it's desirable to resize it's memory on demand.
>
> By now, it's possible to do so by creating a guest with a small base
> memory, hot-plugging all the rest, and using 'movable_node' kernel
> command-line parameter,
On Thu, Apr 2, 2020 at 2:42 PM Michael Ellerman wrote:
>
> "Alastair D'Silva" writes:
> >> -Original Message-
> >> From: Dan Williams
> >>
> >> On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva
> >> wrote:
> >> >
> >> > *snip*
> >> Are OPAL calls similar to ACPI DSMs? I.e. methods for
On Mon, Mar 23, 2020 at 8:28 PM Cédric Le Goater wrote:
>
> On 3/23/20 10:06 AM, Cédric Le Goater wrote:
> > On 3/19/20 7:14 AM, Haren Myneni wrote:
> >>
> >> Alloc IRQ and get trigger port address for each VAS instance. Kernel
> >> register this IRQ per VAS instance and sets this port for each
ough a dynamic added property "bound-addr" in
> dt node 'ibm,pmemory'.
>
> Signed-off-by: Pingfan Liu
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Hari Bathini
> Cc: Aneesh Kumar K.V
dev for a given pci_dev which also removes a use of pci_dn in
generic EEH code.
This patch also renames eeh_device_add_late() to eeh_device_probe(). This
better reflects what it does does and removes the last vestiges of the
early/late EEH probe split.
Reviewed-by: Sam Bobroff
Signed-off-by: Oli
ructure since there's no real requirement for them on PowerNV. To
help both goals move the early probe into the pseries containment zone
so the platform depedence is more explicit.
Reviewed-by: Sam Bobroff
Signed-off-by: Oliver O'Halloran
---
v2: s/set set/we set/ in the commit message
---
arch/powerp
pci_dn structures for DT nodes that correspond to PCI devices so
there's not much point in doing this check in the eeh_probe path.
Reviewed-by: Sam Bobroff
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/powerpc/kernel
the early EEH probe pseries specific.
Reviewed-by: Sam Bobroff
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/pci-hotplug.c | 2 --
drivers/pci/hotplug/rpaphp_core.c | 2 ++
drivers/pci/hotplug/rpaphp_pci.c | 4 +++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch
On pseries and PowerNV pcibios_bus_add_device() calls eeh_add_device_late()
so there's no need to do a separate tree traversal to bind the eeh_dev and
pci_dev together setting up the PHB at boot. As a result we can remove
eeh_add_device_tree_late().
Reviewed-by: Sam Bobroff
Signed-off-by: Oliver
off
Signed-off-by: Oliver O'Halloran
---
v2: Reworded commit message based on Sam Bobroff's comments. About the
current behaviour being broken.
---
arch/powerpc/include/asm/eeh.h | 3 ---
arch/powerpc/kernel/eeh.c| 24 +---
arch/powerpc/ker
On Fri, Feb 28, 2020 at 2:09 PM Nicholas Piggin wrote:
>
> These calls can be used by Linux to annotate BUG addresses with symbols,
> look up symbol addresses in xmon, etc.
>
> This is preferable over having Linux parse the OPAL symbol map itself,
> because OPAL's parsing code already exists for
On Mon, Feb 24, 2020 at 3:43 PM Alastair D'Silva wrote:
>
> On Sun, 2020-02-23 at 20:37 -0800, Matthew Wilcox wrote:
> > On Mon, Feb 24, 2020 at 03:34:07PM +1100, Alastair D'Silva wrote:
> > > V3:
> > > - Rebase against next/next-20200220
> > > - Move driver to arch/powerpc/platforms/powernv,
bol '' not found.
Fixes: 2d9b332d99b ("powerpc/xmon: Allow passing an argument to
ppc_md.restart()")
Reported-by: Michael Ellerman
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/xmon/xmon.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/pow
to use the feature.
Signed-off-by: Oliver O'Halloran
---
Companion skiboot patch:
http://lists.ozlabs.org/pipermail/skiboot/2020-February/016420.html
---
arch/powerpc/include/asm/opal-api.h| 1 +
arch/powerpc/platforms/powernv/setup.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch
Treat an empty reboot cmd string the same as a NULL string. This squashes a
spurious unsupported reboot message that sometimes gets out when using
xmon.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
the only way to actually use the feature. It'd
be nice if it still printed out *something* if it failed to create the
files rather than just being mysteriously absent, but maybe debugfs
itself does that. Looks fine otherwise.
Reviewed-by: Oliver O'Halloran
> Cc: Benjamin Herrenschmidt
> Cc: Pa
On Fri, Feb 7, 2020 at 2:35 PM Oliver O'Halloran wrote:
>
> On Fri, Feb 7, 2020 at 1:24 PM Sam Bobroff wrote:
> >
> > On Mon, Feb 03, 2020 at 07:35:20PM +1100, Oliver O'Halloran wrote:
> > > The eeh_ops->probe() function is called from two different contexts:
> &
On Fri, Feb 7, 2020 at 1:24 PM Sam Bobroff wrote:
>
> On Mon, Feb 03, 2020 at 07:35:20PM +1100, Oliver O'Halloran wrote:
> > The eeh_ops->probe() function is called from two different contexts:
> >
> > 1. On pseries, where set set EEH_PROBE_MODE_DEVTREE, it's calle
On Thu, Feb 6, 2020 at 3:13 PM Sam Bobroff wrote:
>
> On Mon, Feb 03, 2020 at 07:35:16PM +1100, Oliver O'Halloran wrote:
> > Move creating the EEH specific sysfs files into eeh_add_device_late()
> > rather than being open-coded all over the place. Calling the function is
.
Right now we register both notifiers before we've initialised the driver.
This seems to work, but we should head off any protential problems by
registering the notifiers after the driver is initialised.
Cc: Vaidyanathan Srinivasan
Signed-off-by: Oliver O'Halloran
---
drivers/cpufreq/powernv
is located on chips[].throttle and when b)
happens we clean up by freeing the array. Once we get to the (now free)
queued item and the kernel crashes.
Cc: Vaidyanathan Srinivasan
Fixes: c5e29ea ("cpufreq: powernv: Fix bugs in powernv_cpufreq_{init/exit}")
Signed-off-by: Oliver O'Halloran
--
dev for a given pci_dev which also removes a use of pci_dn in
generic EEH code.
This patch also renames eeh_device_add_late() to eeh_device_probe(). This
better reflects what it does does and removes the last vestiges of the
early/late EEH probe split.
Signed-off-by: Oliver O'Halloran
---
arch/powe
ructure since there's no real requirement for them on PowerNV. To
help both goals move the early probe into the pseries containment zone
so the platform depedence is more explicit.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 14 +++---
arch/powerpc
pci_dn structures for DT nodes that correspond to PCI devices so
there's not much point in doing this check in the eeh_probe path.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel
the early EEH probe pseries specific.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/pci-hotplug.c | 2 --
drivers/pci/hotplug/rpaphp_core.c | 2 ++
drivers/pci/hotplug/rpaphp_pci.c | 4 +++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/pci-hotplug.c
b
On pseries and PowerNV pcibios_bus_add_device() calls eeh_add_device_late()
so there's no need to do a separate tree traversal to bind the eeh_dev and
pci_dev together setting up the PHB at boot. As a result we can remove
eeh_add_device_tree_late().
Signed-off-by: Oliver O'Halloran
---
arch
) don't seem to have any issues with the re-ordering.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 3 ---
arch/powerpc/kernel/eeh.c| 24 +---
arch/powerpc/kernel/of_platform.c| 3 ---
arch/powerpc/kernel/pci
201 - 300 of 690 matches
Mail list logo
