From: Shawn Anastasio
Move PCI device setup from pcibios_add_device() and pcibios_fixup_bus() to
pcibios_bus_add_device(). This ensures that platform-specific DMA and IOMMU
setup occurs after the device has been registered in sysfs, which is a
requirement for IOMMU group assignment to work
This
ever, this comment appears to have no basis in
reality so just delete it.
Signed-off-by: Oliver O'Halloran
---
Can't get rid of the fixup entirely since we need it to set the
ioda_pe->pdev back-pointer. I'll look at killing that another time.
---
arch/powerpc/kernel/eeh_driver
A couple of extra patches on top of Shawn's existing re-ordering patch.
This seems to fix the problem Alexey noted with Shawn's change causing
VFs to lose their IOMMU group. I've tried pretty hard to make this a
minimal fix it's still a bit large.
If mpe is happy to take this as a fix for 5.4 then
Whoops.
Fixes: bd6461cc7b3c ("powerpc/eeh: Add a eeh_dev_break debugfs interface")
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
ind
On Fri, Sep 20, 2019 at 6:28 AM Nathan Lynch wrote:
>
> Hello Sam,
>
> Sam Bobroff writes:
>
> With this change, I get a crash (use after free by the looks of it) when
> I remove and then add a pci device in qemu:
>
> $ qemu-system-ppc64 -M pseries -append 'debug console=hvc0' \
> -nographic -v
On Tue, Sep 17, 2019 at 11:15 AM Sam Bobroff wrote:
>
> On Tue, Sep 03, 2019 at 08:15:58PM +1000, Oliver O'Halloran wrote:
> > When we reset PCI devices managed by a hotplug driver the reset may
> > generate spurious hotplug events that cause the PCI device we're r
On Tue, Sep 10, 2019 at 4:29 PM Aneesh Kumar K.V
wrote:
>
> With commit: 7cc7867fb061 ("mm/devm_memremap_pages: enable sub-section remap")
> pmem namespaces are remapped in 2M chunks. On architectures like ppc64 we
> can map the memmap area using 16MB hugepage size and that can cover
> a memory ra
On Tue, Sep 17, 2019 at 1:36 PM Oliver O'Halloran wrote:
>
> On Tue, Sep 17, 2019 at 1:16 PM Sam Bobroff wrote:
> >
> > On Tue, Sep 03, 2019 at 08:16:03PM +1000, Oliver O'Halloran wrote:
> > > Detecting an frozen EEH PE usually occurs when an MMIO load return
On Tue, Sep 17, 2019 at 11:01 AM Sam Bobroff wrote:
>
> On Tue, Sep 03, 2019 at 08:15:55PM +1000, Oliver O'Halloran wrote:
> > When a device is surprise removed while undergoing IO we will probably
> > get an EEH PE freeze due to MMIO timeouts and other errors. When a fr
On Tue, Sep 17, 2019 at 1:35 PM Sam Bobroff wrote:
>
> On Tue, Sep 17, 2019 at 11:45:14AM +1000, Oliver O'Halloran wrote:
> >
> > Two reasons:
> >
> > 1) the eeh_event structures are allocated with GFP_ATOMIC since
> > eeh_dev_check_failure() can b
On Tue, Sep 17, 2019 at 1:16 PM Sam Bobroff wrote:
>
> On Tue, Sep 03, 2019 at 08:16:03PM +1000, Oliver O'Halloran wrote:
> > Detecting an frozen EEH PE usually occurs when an MMIO load returns a 0xFFs
> > response. When performing EEH testing using the EEH error injectio
On Tue, Sep 17, 2019 at 11:04 AM Sam Bobroff wrote:
>
> On Tue, Sep 03, 2019 at 08:15:56PM +1000, Oliver O'Halloran wrote:
> > Currently we print a stack trace in the event handler to help with
> > debugging EEH issues. In the case of suprise hot-unplug this is unneeded,
&g
Add a debugfs entry to dump the state of the active IODA PEs. The IODA PE
state reflects how the PHB's internal concept of a PE is configured. This
is separate to the EEH PE state and is managed power the PowerNV PCI
backend rather than the EEH core.
Signed-off-by: Oliver O'Halloran
Make the dump trigger off any input rather than just '1'. This allows you
to write "echo 1> dump_diag_data" and it'll do what you want rather than
erroring out pointlessly.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 3
Use the pnv_phb structure as the private data pointer for the debugfs
files. This lets us delete some code and an open-coded use of
hose->private_data.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 11 ++-
1 file changed, 2 insertions(+), 9 d
On Mon, Sep 9, 2019 at 11:23 PM Hari Bathini wrote:
>
> On 04/09/19 5:50 PM, Michael Ellerman wrote:
> > Hari Bathini writes:
> >
>
> [...]
>
> >> +/*
> >> + * CPU state data is provided by f/w. Below are the definitions
> >> + * provided in HDAT spec. Refer to latest HDAT specification for
> >>
On Sat, Sep 7, 2019 at 2:25 AM Sergey Miroshnichenko
wrote:
>
> Hi Oliver,
>
> On 9/4/19 8:37 AM, Oliver O'Halloran wrote:
> > On Fri, 2019-08-16 at 19:50 +0300, Sergey Miroshnichenko wrote:
> >> Add pcibios_rescan_prepare()/_done() hooks for the powerpc platform.
On Wed, Sep 4, 2019 at 9:51 PM Michael Ellerman wrote:
>
> Hari Bathini writes:
> > With FADump support now available on both pseries and OPAL platforms,
> > update FADump documentation with these details.
> >
> > Signed-off-by: Hari Bathini
> > ---
> > Documentation/powerpc/firmware-assisted-d
On Fri, 2019-08-16 at 19:50 +0300, Sergey Miroshnichenko wrote:
> A hotplugged bridge with many hotplug-capable ports may request
> reserving more IO space than the machine has. This could be overridden
> with the "hpiosize=" kernel argument though.
>
> But when BARs are movable, there are no need
() - before it
> resumes. There are no memory requests to this device between the hooks, so
> it it safe to rebuild the EEH address cache during that.
>
> CC: Oliver O'Halloran
> Signed-off-by: Sergey Miroshnichenko
> ---
> arch/powerpc/kernel/pci-hotplug.c | 10 +++
tion to
recover before the function of interest is recovered. The platform specific
error injection facilities are finer-grained and allow this capability, but
doing that requires working out how to use those facilities first.
Basicly, it's better than nothing and it's a base to build o
makes sense and provides a sane, cross-platform interface for
userspace so we can write more generic testing scripts.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh.c | 139 +-
1 file changed, 138 insertions(+), 1 deletion(-)
diff --git a/ar
27;s done when the
kernel gets a 0xFF result from an config or MMIO read with the added
benifit that it can be reliably triggered from userspace.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh.c | 61 +++
1 file changed, 61 insertions(+)
dif
I am the RAS team. Hear me roar.
Roar.
On a more serious note, being able to locate failed devices can be helpful.
Set the attention indicator if the slot supports it once we've determined
the device is present and only clear it if the device is fully recovered.
Signed-off-by: Oliver O
pnv_php is generally used with PCIe bridges which provide a native
interface for setting the attention and power indicator LEDs. Wire up
those interfaces even if firmware does not have support for them (yet...)
Signed-off-by: Oliver O'Halloran
---
drivers/pci/hotplug/pnv_php.c
Currently we check that an IODA2 compatible PHB is upstream of this slot.
This is mainly to avoid pnv_php creating slots for the various "virtual
PHBs" that we create for NVLink. There's no real need for this restriction
so allow it on IODA3.
Signed-off-by: Oliver O'Hallora
pnv_php managed slots.
Signed-off-by: Oliver O'Halloran
---
drivers/pci/hotplug/pnv_php.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
index 6758fd7c382e..b0e243dabf77 100644
--- a/driver
core has
requested a hot reset (common case) without tripping over the hotplug
driver.
Signed-off-by: Oliver O'Halloran
---
I know that include is a bit gross, but:
a) We're already doing it in pci-ioda.c, and in pseries/pci.
b) It's pci_bus_error_reset() isn't really a f
Support for switching CAPI cards into and out of CAPI mode was removed a
while ago. Drop the comment since it's no longer relevant.
Cc: Andrew Donnellan
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 7 ---
1 file changed, 7 deletions(-)
di
from the eeh_check_dev_failure()
if they want.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 11 +
arch/powerpc/kernel/eeh.c| 15 -
arch/powerpc/kernel/eeh_driver.c | 38 +++-
arch/powerpc/kernel/eeh_eve
don't have the EEH recovery thread
remove any of the devices since it's assumed that the hotplug driver
will handle tearing down the slot state.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh_driver.c | 60
1 file changed, 60 inserti
If a device is torn down by a hotplug slot driver it's marked as removed
and marked as permaantly failed. There's no point in trying to recover a
permernantly failed device so it should be considered un-actionable.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/ee
torn down and
the kernel may crash as a result.
To fix this, don't free the pci_dn unless the corresponding pci_dev has
been released. If the pci_dev is still live, then we mark the pci_dn with
a flag that indicates the pci_dev's release function should free it.
Signed-off-by: O
is no
longer valid.
Crashing is generally considered poor form. Instead of doing that use
the fact PEs are marked as EEH_PE_INVALID to keep them around until the
end of the recovery cycle, at which point we can safely prune any empty
PEs.
Signed-off-by: Oliver O'Halloran
---
Sam Bobro
Fixes various random crashes and other bad behaviour when hot
pluggable slots are used with EEH, namely:
1) Random crashes due to eeh_pe and pci_dn lifecycle mis-management
2) Hotplug slots tearing down devices you are trying to recover due
to the reset that occurs while recovering a PE / bus.
On Thu, Aug 29, 2019 at 6:21 PM Aneesh Kumar K.V
wrote:
>
> On 8/29/19 1:29 PM, Oliver O'Halloran wrote:
> > On Thu, Aug 29, 2019 at 4:34 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> Right now we force an unbind of SCM memory at drcindex on H_OVERLAP erro
On Thu, Aug 29, 2019 at 4:34 PM Aneesh Kumar K.V
wrote:
>
> Right now we force an unbind of SCM memory at drcindex on H_OVERLAP error.
> This really slows down operations like kexec where we get the H_OVERLAP
> error because we don't go through a full hypervisor re init.
Maybe we should be unbind
On Wed, 2019-08-21 at 13:43 +0530, Vasant Hegde wrote:
> Use "opal-msg-size" device tree property to allocate memory for "opal_msg".
>
> Cc: Mahesh Salgaonkar
> Cc: Jeremy Kerr
> Signed-off-by: Vasant Hegde
> ---
> Changes in v3:
> - Call BUG_ON, if we fail to allocate memory during init.
>
On Thu, Aug 22, 2019 at 3:02 PM Oliver O'Halloran wrote:
>
> On Wed, 2019-08-21 at 11:08 -0400, Nayna Jain wrote:
> > diff --git a/arch/powerpc/platforms/powernv/opal.c
> > b/arch/powerpc/platforms/powernv/opal.c
> > index aba443be7daa..ffe6f1cf0830 100644
>
On Wed, 2019-08-21 at 11:08 -0400, Nayna Jain wrote:
> PowerNV secure variables, which store the keys used for OS kernel
> verification, are managed by the firmware. These secure variables need to
> be accessed by the userspace for addition/deletion of the certificates.
>
> This patch adds the sys
On Wed, 2019-08-21 at 11:08 -0400, Nayna Jain wrote:
> The X.509 certificates trusted by the platform and required to secure boot
> the OS kernel are wrapped in secure variables, which are controlled by
> OPAL.
>
> This patch adds firmware/kernel interface to read and write OPAL secure
> variables
These functions can only be used on a SR-IOV capable physical function and
they're only called in pcibios_sriov_enable / disable. Make them emit a
warning in the future if they're used incorrectly and remove the dead
code that checks if the device is a VF.
Signed-off-by: Oliver
) and remove_pci_dev_data(). The entire body of these
functions is #ifdef`ed around CONFIG_PCI_IOV and they cannot be used
in any other context, so make them only available when CONFIG_PCI_IOV
is selected, and rename them to reflect their actual usage rather than
having them masquerade as generic cod
of the eeh_pe that contained it. This can result in crashes due to the
use-after-free.
Signed-off-by: Oliver O'Halloran
---
No Fixes: here since I'm not sure if the commit that added this actually
introduced the bug. EEH is amazing.
I suspect backporting this would cause more proble
On Wed, Aug 21, 2019 at 3:37 PM Anju T Sudhakar wrote:
>
> Hi,
>
> On 8/21/19 10:16 AM, Oliver O'Halloran wrote:
> > Is there a reason why we create the debugfs directory here and not in
> > opal_imc_counters_probe()? There's logic to remove the debugfs
>
On Wed, Aug 21, 2019 at 2:10 PM Anju T Sudhakar wrote:
>
> export_imc_mode_and_cmd() function which creates the debugfs interface for
> imc-mode and imc-command, is invoked when each nest pmu units is
> registered.
> When the first nest pmu unit is registered, export_imc_mode_and_cmd()
> creates '
On Tue, Aug 20, 2019 at 12:30 PM Santosh Sivaraj wrote:
>
> Subscribe to the MCE notification and add the physical address which
> generated a memory error to nvdimm bad range.
Uh... I should have looked a bit closer at this on v1.
a) of_pmem.c isn't part of the powerpc tree. You should have CCe
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
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, 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 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 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: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 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 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 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 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,
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,
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,
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
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
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
Fixes of no particular importance. I just wanted to cut down the pile of
patches I've got hanging around.
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 |
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 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*
>
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: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 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 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
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 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
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 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 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
Single logical
change per patch and all that.
Reviewed-by: Oliver O'Halloran
#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
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
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:
>
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 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 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 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, 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 Wed, Jun 12, 2019 at 4:53 PM Christoph Hellwig wrote:
>
> On Wed, Jun 12, 2019 at 04:35:22PM +1000, Oliver O'Halloran wrote:
> > Setting a 48 bit DMA mask doesn't work today because we only allocate
> > IOMMU tables to cover the 0..2GB range of PCI bus addresses.
&g
On Wed, Jun 12, 2019 at 3:25 AM Oded Gabbay wrote:
>
> On Tue, Jun 11, 2019 at 8:03 PM Oded Gabbay wrote:
> >
> > On Tue, Jun 11, 2019 at 6:26 PM Greg KH wrote:
> > > *snip*
> >
> > Now, when I tried to integrate Goya into a POWER9 machine, I got a
> > reject from the call to pci_set_dma_mask(pd
On Wed, Jun 12, 2019 at 3:06 PM Shawn Anastasio wrote:
>
> On 6/5/19 11:11 PM, Shawn Anastasio wrote:
> > On 5/30/19 2:03 AM, Alexey Kardashevskiy wrote:
> >> This is an attempt to allow DMA masks between 32..59 which are not large
> >> enough to use either a PHB3 bypass mode or a sketchy bypass.
On Wed, Jun 12, 2019 at 8:54 AM Benjamin Herrenschmidt
wrote:
>
> On Tue, 2019-06-11 at 20:22 +0300, Oded Gabbay wrote:
> >
> > > So, to summarize:
> > > If I call pci_set_dma_mask with 48, then it fails on POWER9. However,
> > > in runtime, I don't know if its POWER9 or not, so upon failure I wil
On Mon, 2019-03-11 at 14:52 +0300, Sergey Miroshnichenko wrote:
> When called within pcibios_sriov_enable(), the pci_sriov_get_totalvfs(pdev)
> returns zero, because the device is yet preparing to enable the VFs.
I don't think this is correct. The earliest pcibios_sriov_enable() can
be called is
On Wed, 2019-03-20 at 13:58 +1100, Sam Bobroff wrote:
> The EEH address cache is currently initialized and populated by a
> single function: eeh_addr_cache_build(). While the initial population
> of the cache can only be done once resources are allocated,
> initialization (just setting up a spinlo
On Wed, 2019-03-20 at 13:58 +1100, Sam Bobroff wrote:
> Move the EEH enabled message into it's own function so that future
> work can call it from multiple places.
>
> Signed-off-by: Sam Bobroff
> ---
> arch/powerpc/include/asm/eeh.h | 3 +++
> arch/powerpc/kernel/eeh.c | 16 +++---
On Wed, 2019-03-20 at 13:58 +1100, Sam Bobroff wrote:
> The PHB flag, PNV_PHB_FLAG_EEH, is set (on PowerNV) individually on
> each PHB once the EEH subsystem is ready. It is the only use of the
> flags member of the phb struct.
>
> However there is no need to store this separately on each PHB, so
The PowerNV platform depends on CONFIG_PPC64 so this #ifdef in the middle
of platforms/powernv/pci.c really doesn't need to be there.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/platfor
x27; > /sys/kernel/debug/powerpc/eeh_force_recover
To force a scan for broken PHBs:
echo 'hwcheck' > /sys/kernel/debug/powerpc/eeh_force_recover
Signed-off-by: Oliver O'Halloran
---
v2: Rename from pci_find_hose_for_domain() to
pci_find_controller_for_domain()
Use the more des
: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/kernel/eeh.c | 10 ++
arch/powerpc/kernel/eeh_event.c | 9 +
3 files changed, 20 insertions(+)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 478f199
Add a helper to find the pci_controller structure based on the domain
number / phb id.
Signed-off-by: Oliver O'Halloran
---
v2: Renamed pci_find_hose_for_domain() to
pci_find_controller_for_domain()
---
arch/powerpc/include/asm/pci-bridge.h | 2 ++
arch/powerpc/kernel/pci-com
-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 5c5697cced41..9c68f0837385 100644
--- a/arch/powerpc/kernel/eeh_cache.c
+++ b/arch/powerpc/k
l log.
Signed-off-by: Oliver O'Halloran
---
v2: Added missing #endif
Replaced while loop with a for
---
arch/powerpc/include/asm/eeh.h | 3 +++
arch/powerpc/kernel/eeh.c | 1 +
arch/powerpc/kernel/eeh_cache.c | 30 ++
3 files changed, 30 insertions(+), 4
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
---
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 u32 and print the value in decimal rather than
hex because printing it in hex makes no sense.
Signed-off-by: Oliver
401 - 500 of 692 matches
Mail list logo