P8 needs to shove four GPUs into three PEs for $reasons. Remove the
pdn->pe_assignment done there since we just use the pe_rmap[] now.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --gi
:toot:
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index 0eeea8652426..6383dcfec606 100644
--- a/arch/powerpc/plat
Not-Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/pci_dn.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc/kernel/pci_dn.c
index f790a8d06f50..0e05c1d7633a 100644
--- a/arch/powerpc/kernel/pci_dn.c
+++ b/arch/powerpc/kernel/pci
On Thu, Nov 21, 2019 at 3:02 PM Alexey Kardashevskiy wrote:
>
>
>
> On 20/11/2019 12:28, Oliver O'Halloran wrote:
> > These functions are only used from pci-ioda.c. Move them in there and remove
> > the prototypes from the header files.
>
>
> Make them stat
On Thu, Nov 21, 2019 at 2:38 PM Alexey Kardashevskiy wrote:
>
>
>
> On 20/11/2019 12:28, Oliver O'Halloran wrote:
> > After resetting a VF we call eeh_restore_vf_config() to restore several
> > registers in the VFs config space. For physical functions this i
On Mon, Nov 25, 2019 at 2:20 PM Alexey Kardashevskiy wrote:
>
>
>
> On 20/11/2019 12:28, Oliver O'Halloran wrote:
> > Use the pnv_eeh_find_edev() helper to look up the eeh_dev for a device
> > rather than doing it via the pci_dn.
>
> This is not what the patch d
On Mon, Nov 25, 2019 at 2:27 PM Alexey Kardashevskiy wrote:
>
>
>
> On 20/11/2019 12:28, Oliver O'Halloran wrote:
> > Have the PowerNV EEH backend allocate the eeh_dev if needed rather than
> > using
> > the one attached to the pci_dn.
>
> So that pci_dn
On Thu, Nov 21, 2019 at 6:48 PM Christoph Hellwig wrote:
>
> On Wed, Nov 20, 2019 at 12:28:19PM +1100, Oliver O'Halloran wrote:
> > Move this out of the PHB's dma_dev_setup() callback and into the
> > ppc_md.pcibios_fixup_iov callback. This ensures that the VF PE&
On Thu, Nov 21, 2019 at 3:34 PM Alexey Kardashevskiy wrote:
>
>
>
> On 20/11/2019 12:28, Oliver O'Halloran wrote:
> > Move this out of the PHB's dma_dev_setup() callback and into the
> > ppc_md.pcibios_fixup_iov callback. This ensures that the VF PE's
&
On Wed, Nov 27, 2019 at 8:34 PM Greg Kurz wrote:
>
>
> If everyone is ok with leaking a reference in the NPU case, I guess
> this isn't a problem. But if we move forward with Oliver's patch, a
> pci_dev_put() would be needed for OpenCAPI, correct ?
Yes, but I think that's fair enough. By conventi
On Wed, Nov 27, 2019 at 4:24 PM Alexey Kardashevskiy wrote:
>
>
>
> On 20/11/2019 12:28, Oliver O'Halloran wrote:
> > Signed-off-by: Oliver O'Halloran
> > ---
> > arch/powerpc/platforms/powernv/pci-ioda.c | 5 ++---
> > 1 file changed, 2 insertion
On Mon, Dec 2, 2019 at 2:08 PM Jordan Niethe wrote:
>
> Commit a25bd72badfa ("powerpc/mm/radix: Workaround prefetch issue with
> KVM") introduced a number of workarounds as coming out of a guest with
> the mmu enabled would make the cpu would start running in hypervisor
> state with the PID value
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
> > > rele
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
evice() 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
ind
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
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/powern
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 do
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
depends 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/platform
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 th
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/pow
e devices in that PE it 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 inse
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(+
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'Hal
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 l
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:
> > > > +#def
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
depends 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 b
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 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 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() anywhere.
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 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
Currently when we get an unknown RTAS event it prints the type as
"Unknown" and no other useful information. Add the raw type code to the
log message so that we have something to work off.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/rtasd.c | 6 --
1 file change
This series adds support for the para-virtualised storage class memory
interface defined by the Power Architecture Platform Reference.
Patch 1 implements the pseries device discovery (via DT) and hotplug
support (via RTAS hotplug interrupt).
Patch 2 implements a driver that binds to the platform
This patch implements support for discovering storage class memory
devices at boot and for handling hotplug of new regions via RTAS
hotplug events.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/firmware.h | 3 ++-
arch/powerpc/include/asm/hvcall.h
s physical address space, and
b) There is currently no mechanism for relating a bare of_pmem region
to the backing DIMM (or not-a-DIMM for our case).
Both of these are easily handled by rolling the functionality into a
seperate driver so here we are...
Signed-off-by: Oliver O'Halloran
---
This patch implements support for discovering storage class memory
devices at boot and for handling hotplug of new regions via RTAS
hotplug events.
Signed-off-by: Oliver O'Halloran
---
v2: Added missing pmem.c file
---
arch/powerpc/include/asm/firmware.h | 3 +-
arch/powerpc/includ
s physical address space, and
b) There is currently no mechanism for relating a bare of_pmem region
to the backing DIMM (or not-a-DIMM for our case).
Both of these are easily handled by rolling the functionality into a
seperate driver so here we are...
Signed-off-by: Oliver O'Halloran
---
This patch implements support for discovering storage class memory
devices at boot and for handling hotplug of new regions via RTAS
hotplug events.
Signed-off-by: Oliver O'Halloran
---
v2: Added missing pmem.c
v3: no changes
---
arch/powerpc/include/asm/firmware.h | 3 +-
arch/po
s physical address space, and
b) There is currently no mechanism for relating a bare of_pmem region
to the backing DIMM (or not-a-DIMM for our case).
Both of these are easily handled by rolling the functionality into a
seperate driver so here we are...
Acked-by: Dan Williams
Signed-off-
On Fri, 2018-11-09 at 08:11 +0100, Lukas Wunner wrote:
> On Thu, Nov 08, 2018 at 02:09:17PM -0600, Bjorn Helgaas wrote:
> > + /*
> > +* If an MMIO read from the device returns ~0 data, that data may
> > +* be valid, or it may indicate a bus error. If config space is
> > +* readable,
On Thu, 2018-11-08 at 23:06 +, alex_gagn...@dellteam.com wrote:
> On 11/08/2018 04:51 PM, Greg KH wrote:
> > On Thu, Nov 08, 2018 at 10:49:08PM +, alex_gagn...@dellteam.com wrote:
> > > In the case that we're trying to fix, this code executing is a result of
> > > the device being gone, so
CONFIG_PCI_MSI was made mandatory by commit a311e738b6d8
("powerpc/powernv: Make PCI non-optional") so the #ifdef
checks around CONFIG_PCI_MSI here can be removed entirely.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 13 -
arch/po
Various bug fixes for the papr_scm driver that were found while bringing
up the PowerVM implementation of the interface. There's a few minor bugs
there were a result of bugs in the original QEMU implementation, a few
due to the memory layouts being different and one due to a change to the
DT bindin
Making PAPR_SCM select LIBNVDIMM results in circular dependencies in
Kconfig when another symbol depends on it. Fix this by replacing the
select with a depends.
Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions")
Reported-by: Alastair D'Silva
Signed-off-by: Ol
resulting in the entire hot-plug failing.
Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions")
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/papr_scm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pse
ibm,number-of-blocks that convey the same
information. No firmware / hypervisor that emitted the ibm,unit-size
property ever appeared in the wild.
Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions")
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pse
qemu and
the returned values were byte swapped unnecessarily in both the
hypervisor and in the driver so this was only noticed when bringing up
the PowerVM implementation.
Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions")
Signed-off-by: Oliver O'Halloran
--
() function which synchronises with
the async domain and verifies that the dimm was successfully registered
with the bus.
If either of these does not occur then we bail.
Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions")
Signed-off-by: Oliver O'Halloran
---
arch/po
rpose.
Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions")
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/papr_scm.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
b/arch/power
f we cannot allocate from the altmap. This
fallback should only ever be used for the first vmemmap block so it
should not cause excess memory consumption.
Fixes: 7b73d978a5d0 ("mm: pass the vmem_altmap to vmemmap_populate")
Signed-off-by: Oliver O'Halloran
---
The Fixes here is a littl
On Thu, Jun 20, 2019 at 12:40 PM Alexey Kardashevskiy wrote:
>
> On 19/06/2019 14:27, Sam Bobroff wrote:
> > On Tue, Jun 11, 2019 at 03:47:58PM +1000, Alexey Kardashevskiy wrote:
> >>
> >> On 07/05/2019 14:30, Sam Bobroff wrote:
> >>> Also remove useless comment.
> >>>
> >>> Signed-off-by: Sam Bob
On Thu, May 23, 2019 at 5:56 PM Christoph Hellwig wrote:
>
> These two function have never been used since they were added to the
> kernel.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/include/asm/vas.h | 10 --
> arch/powerpc/platforms/powernv/vas-window.c | 19
On Thu, May 23, 2019 at 5:51 PM Christoph Hellwig wrote:
>
> These have been unused ever since they've been added to the kernel.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/include/asm/pnv-pci.h| 4 --
> arch/powerpc/platforms/powernv/pci-ioda.c | 4 +-
> arch/powerpc/pla
On Tue, Jun 25, 2019 at 1:03 AM Vaibhav Jain wrote:
>
> The new hcall named H_SCM_UNBIND_ALL has been introduce that can
> unbind all the memory drc memory-blocks assigned to an lpar. This is
> more efficient than using H_SCM_UNBIND_MEM as currently we don't
> support partial unbind of drc memory-
On Tue, Jun 25, 2019 at 12:59 AM Vaibhav Jain wrote:
>
> In some cases initial bind of scm memory for an lpar can fail if
> previously it wasn't released using a scm-unbind hcall. This situation
> can arise due to panic of the previous kernel or forced lpar reset. In
> such cases the H_SCM_BIND_ME
On Tue, Jun 25, 2019 at 10:27 PM Vaibhav Jain wrote:
>
> Update the hvcalls.h to include op-codes for new hcalls introduce to
> manage SCM memory. Also update existing hcall definitions to reflect
> current papr specification for SCM.
>
> Signed-off-by: Vaibhav Jain
> ---
> Change-log:
>
> v2:
>
d then we follow the existing error path. We also
> update drc_pmem_bind() to handle the H_OVERLAP error returned by phyp
> and indicate it as a EBUSY error back to the caller.
>
> Suggested-by: "Oliver O'Halloran"
> Signed-off-by: Vaibhav Jain
> ---
&g
#x27;rc' to int64_t [Oliver]
> * Removed the code that was logging a warning in case bind operation
> takes >1-seconds [Oliver]
> * Spinned off changes to hvcall.h as a separate patch. [Oliver]
Looks good otherwise, when you respin feel free to add:
Reviewed-by: Oliver O'Halloran
Single logical
change per patch and all that.
Reviewed-by: Oliver O'Halloran
On Thu, Jun 27, 2019 at 2:58 AM Aneesh Kumar K.V
wrote:
>
> Vaibhav Jain writes:
> > *snip*
> > + /* If phyp says drc memory still bound then force unbound and retry */
> > + if (rc == -EBUSY) {
> > + dev_warn(&pdev->dev, "Retrying bind after unbinding\n");
> > + d
On Thu, Jun 27, 2019 at 12:58 PM Aneesh Kumar K.V
wrote:
>
> "Oliver O'Halloran" writes:
>
> >> > + rc = drc_pmem_bind(p);
> >> > + }
> >> > +
> >> > if (rc)
> >> > goto err;
On Fri, Jun 28, 2019 at 1:39 PM Michael Ellerman wrote:
>
> Vaibhav Jain writes:
> > *snip*
>
> How can we be changing the meaning of HCALL numbers without breaking all
> existing usages?
The changed one being changed here were never used by linux or
implemented by either hypervisor.
> Where ar
On Sat, Jun 29, 2019 at 5:39 PM Aneesh Kumar K.V
wrote:
>
> Allocation from altmap area can fail based on vmemmap page size used. Add
> kernel
> info message to indicate the failure. That allows the user to identify
> whether they
> are really using persistent memory reserved space for per-page
if (!p)
> p = vmemmap_alloc_block_buf(page_size, node);
> if (!p)
> --
> 2.21.0
>
I'll let mpe decide if he cares about the split line thing :)
Reviewed-by: Oliver O'Halloran
On Wed, 2019-06-26 at 02:15 +0530, Hari Bathini wrote:
> Refactoring fadump code means internal fadump code is referenced from
> different places. For ease, move internal code to a new file.
Can you elaborate a bit? I don't really get what the difference between
fadump and fadump-internal code is
On Wed, 2019-06-26 at 02:16 +0530, Hari Bathini wrote:
> Introduce callbacks for platform specific operations like register,
> unregister, invalidate & such, and move pseries specific code into
> platform code.
Please don't move around large blocks of code *and* change the code in
a single patch.
On Tue, Jul 9, 2019 at 12:22 AM Aneesh Kumar K.V
wrote:
>
> Christophe Leroy writes:
>
> > *snip*
> > + if (IS_ENABLED(CONFIG_PPC64))
> > + isync();
> > }
>
>
> Was checking with Michael about why we need that extra isync. Michael
> pointed this came via
>
> https://github.com/mp
On Tue, Jul 9, 2019 at 6:12 AM Claudio Carvalho wrote:
>
> From: Madhavan Srinivasan
>
> Ultravisor provides an in-memory circular buffer containing a message
> log populated with various runtime message produced by firmware.
>
> Based on "powernv/opal-msglog.c", this patch provides a sysfs inter
On Tue, Jul 9, 2019 at 12:52 PM Aneesh Kumar K.V
wrote:
>
> On 7/9/19 7:50 AM, Oliver O'Halloran wrote:
> > On Tue, Jul 9, 2019 at 12:22 AM Aneesh Kumar K.V
> > wrote:
> >>
> >> Christophe Leroy writes:
> >>
> >>> *snip*
>
ause it's too busy printing WARN_ON()s.
There's no real reason to assume huge pages can't be present and we're
prefectly capable of handling them, so do that.
Cc: Nicholas Piggin
Fixes: 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap space")
Reported-by: Sa
On Mon, Jul 15, 2019 at 4:49 PM Michael Ellerman wrote:
>
> Christophe Leroy writes:
> > PPC32 also have flush_dcache_range() so it can also support
> > ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE without changes.
> >
> > Signed-off-by: Christophe Leroy
> > ---
> > arch/powerpc/Kconfig |
Fixes of no particular importance. I just wanted to cut down the pile of
patches I've got hanging around.
At the point where we start inserting ranges into the EEH address cache the
binding between pci_dev and eeh_dev has already been set up. Instead of
consulting the pci_dn tree we can retrieve the eeh_dev directly using
pci_dev_to_eeh_dev().
Signed-off-by: Oliver O'Halloran
---
arch/po
The EEH_ATTR_SHOW() helper is used to display fields from struct eeh_dev
not struct pci_dn.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh_sysfs.c b/arch/powerpc/kernel/eeh_sy
uires
some handshaking between the guest, hypervisor and userspace when a VF is
EEH frozen which is why these properties exist.
This is all dead code on non-pseries platforms so wrap it in an #ifdef
CONFIG_PPC_PSERIES to make the dependency clearer.
Signed-off-by: Oliver O'Halloran
---
arch
In eeh_notify_resume_show() the pci_dn for the device is looked up once in
the declaration block and then once after checking for a NULL eeh_dev.
Remove the second lookup since it's pointless.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh_sysfs.c | 1 -
1 file changed,
s setup for the device
for the device in the first place so hitting this warning
indicates a programming error.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh.c | 30 +-
arch/powerpc/kernel/eeh_sysfs.c | 15 ---
2 files changed,
On Tue, 2019-07-16 at 16:48 +1000, Sam Bobroff wrote:
> On Thu, Jun 20, 2019 at 01:45:24PM +1000, Oliver O'Halloran wrote:
> > On Thu, Jun 20, 2019 at 12:40 PM Alexey Kardashevskiy
> > wrote:
> > > On 19/06/2019 14:27, Sam Bobroff wrote:
> > > > On Tue,
On Tue, Jul 16, 2019 at 7:08 PM Aneesh Kumar K.V
wrote:
>
> This is similar to what ACPI does. Nvdimm layer doesn't bring the SCM device
> numa node online. Hence we need to make sure we always use an online node
> as ndr_desc.numa_node. Otherwise this result in kernel crashes. The target
> node i
On Thu, Jul 18, 2019 at 1:16 PM Shawn Anastasio wrote:
>
> On 7/17/19 9:59 PM, Alexey Kardashevskiy wrote:
> >
> > On 18/07/2019 09:54, Shawn Anastasio wrote:
> >> The refactor of powerpc DMA functions in commit cc17d780
> >> ("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
> >> cha
On Thu, 2019-06-13 at 16:50 -0400, Nayna Jain wrote:
> As part of PowerNV secure boot support, OS verification keys are stored
> and controlled by OPAL as secure variables. These need to be exposed to
> the userspace so that sysadmins can perform key management tasks.
>
> This patch adds the suppo
On Wed, Jul 24, 2019 at 7:17 PM Laurent Dufour
wrote:
>
> Le 23/07/2019 à 18:13, Vaibhav Jain a écrit :
> > *snip*
> > @@ -404,6 +409,14 @@ static int papr_scm_probe(struct platform_device *pdev)
> >
> > /* request the hypervisor to bind this region to somewhere in memory
> > */
> > r
On Wed, Jul 24, 2019 at 7:27 PM Laurent Dufour
wrote:
>
> Le 24/07/2019 à 11:24, Oliver O'Halloran a écrit :
> > On Wed, Jul 24, 2019 at 7:17 PM Laurent Dufour
> > wrote:
> >>
> >> Le 23/07/2019 à 18:13, Vaibhav Jain a écrit :
> >>> *snip*
On Wed, Jul 24, 2019 at 7:24 PM kbuild test robot wrote:
>
> Hi Sam,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v5.3-rc1 next-20190724]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help
On Wed, Jul 24, 2019 at 12:35 AM Nayna wrote:
>
> On 07/05/2019 02:05 AM, Michael Ellerman wrote:
> > Hi Nayna,
>
> Hi Michael, Oliver,
>
> > Nayna Jain writes:
> >> As part of PowerNV secure boot support, OS verification keys are stored
> >> and controlled by OPAL as secure variables. These need
On Thu, Aug 8, 2019 at 5:05 PM Jordan Niethe wrote:
>
> On Wed, 2019-08-07 at 13:44 +1000, Sam Bobroff wrote:
> > From: Oliver O'Halloran
> >
> > Preparation for removing pci_dn from the powernv EEH code. The only
> > thing we really use pci_dn for is to get th
On Wed, Aug 14, 2019 at 6:25 PM Santosh Sivaraj wrote:
>
> Subscribe to the MCE notification and add the physical address which
> generated a memory error to nvdimm bad range.
>
> Signed-off-by: Santosh Sivaraj
> ---
> arch/powerpc/platforms/pseries/papr_scm.c | 65 +++
> 1 f
firmware when doing
the IODA reset.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 1d6406a..53
ot;powerpc/pseries: Add driver for PAPR SCM regions")
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/papr_scm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
b/arch/powerpc/platforms/pseries/papr_scm.
reset if firmware reports an error when performing the IODA reset.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/po
There's no need to the custom getter/setter functions so we should remove
them in favour of using the generic one. While we're here, change the type
of eeh_max_freeze to uint32_t and print the value in decimal rather than
hex because printing it in hex makes no sense.
Signed-off-
a pr_debug()
for the remove case too.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh_cache.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_cache.c b/arch/powerpc/kernel/eeh_cache.c
index 201943d54a6e..b2c320e0fcef 100644
---
l log.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 3 +++
arch/powerpc/kernel/eeh.c | 2 +-
arch/powerpc/kernel/eeh_cache.c | 34 +
3 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/ar
-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh_cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh_cache.c b/arch/powerpc/kernel/eeh_cache.c
index dba421a577e7..7de278f88e3d 100644
--- a/arch/powerpc/kernel/eeh_cache.c
+++ b/arch/powerpc/k
Add a helper to find the pci_controller structure based on the domain
number / phb id.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/pci-bridge.h | 2 ++
arch/powerpc/kernel/pci-common.c | 11 +++
2 files changed, 13 insertions(+)
diff --git a/arch/powerpc/in
: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/kernel/eeh.c | 11 +++
arch/powerpc/kernel/eeh_event.c | 9 +
3 files changed, 21 insertions(+)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index fc21b6e
x27; > /sys/kernel/debug/powerpc/eeh_force_recover
To force a scan broken PHBs:
echo 'null' > /sys/kernel/debug/powerpc/eeh_force_recover
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh_event.h | 1 +
arch/powerpc/kernel/eeh.c| 60 ++
101 - 200 of 692 matches
Mail list logo
