On Wed, Nov 06, 2024 at 03:33:30PM -0500, Liang, Kan wrote:
> On 2024-11-06 3:02 p.m., Oliver Upton wrote:
> > On Wed, Nov 06, 2024 at 11:03:10AM -0500, Liang, Kan wrote:
> >>> +static unsigned long common_misc_flags(struct pt_regs *regs)
> >>> +{
> >&
e current code, the GUEST_KERNEL flag is set for !PERF_GUEST_USER,
> which include both guest_in_kernel and guest_in_NMI.
Where is the "guest_in_NMI" state coming from? KVM only reports user v.
kernel mode.
--
Thanks
Oliver
ng guest_state = perf_guest_state();
if (!(guest_state & PERF_GUEST_ACTIVE))
return 0;
return (guest_state & PERF_GUEST_USER) ? PERF_RECORD_MISC_GUEST_USER :
PERF_RECORD_MISC_GUEST_KERNEL;
}
--
Thanks,
Oliver
hi, Al Viro,
On Sun, Oct 06, 2024 at 03:59:04PM +0100, Al Viro wrote:
> On Sun, Oct 06, 2024 at 10:20:57PM +0800, kernel test robot wrote:
>
> > xfs/046 - output mismatch (see
> > /lkp/benchmarks/xfstests/results//xfs/046.out.bad)
> > --- tests/xfs/046.out 2024-09-30 21:13:44.000
With that corrected, for the series:
Reviewed-by: Oliver Upton
A nice follow-up on the arm64 side would be to further constrain
kvm_arch_pmi_in_guest() to return true iff we exited the guest due to an
IRQ.
--
Thanks,
Oliver
On Thu, Aug 8, 2024 at 12:08 PM Matthew W Carlis wrote:
>
> On Wed, 7 Aug 2024 22:29:35 +1000 Oliver O'Halloran Wrote
> > My read was that Matt is essentially doing a surprise hot-unplug by
> > removing power to the card without notifying the OS. I thought the
> > LBM
On Wed, Aug 7, 2024 at 9:14 PM Maciej W. Rozycki wrote:
>
> On Wed, 7 Aug 2024, Matthew W Carlis wrote:
>
> > > it does seem like this series made wASMedia ASM2824 work better but
> > > caused regressions elsewhere, so maybe we just need to accept that
> > > ASM2824 is slightly broken and doesn't
On Mon, Aug 05, 2024 at 04:53:01PM -0700, Sean Christopherson wrote:
> On Mon, Aug 05, 2024, Oliver Upton wrote:
> > > > ---
> > > > arch/arm64/kvm/mmu.c | 10 ++
> > > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > > >
> &g
On Mon, Aug 05, 2024 at 11:26:03PM +, Oliver Upton wrote:
> [+cc Fuad]
Take 2!
> Fuad, you mentioned in commit 9c30fc615daa ("KVM: arm64: Move setting
> the page as dirty out of the critical section") that restructuring
> around the MMU lock was helpful for reuse (presu
; !ret) {
> - kvm_set_pfn_dirty(pfn);
> + if (writable && !ret)
> mark_page_dirty_in_slot(kvm, memslot, gfn);
> - }
>
> - kvm_release_pfn_clean(pfn);
> return ret != -EAGAIN ? ret : 0;
> }
>
> --
> 2.46.0.rc1.232.g9752f9e123-goog
>
--
Thanks,
Oliver
hi, Christoph Hellwig,
On Wed, Jun 26, 2024 at 09:54:05PM -0700, Christoph Hellwig wrote:
> On Thu, Jun 27, 2024 at 10:35:38AM +0800, Oliver Sang wrote:
> >
> > I failed to apply patch in your previous reply to 1122c0c1cc or current tip
> > of axboe-block/for-next:
> >
hi, Christoph Hellwig,
On Tue, Jun 25, 2024 at 08:39:50PM -0700, Christoph Hellwig wrote:
> On Wed, Jun 26, 2024 at 10:10:49AM +0800, Oliver Sang wrote:
> > I'm not sure I understand this test request. as in title, we see a good
> > improvement of aim7 for 1122c0c1cc, and we
hi, Christoph Hellwig,
On Mon, Jun 24, 2024 at 10:35:37AM +0200, Christoph Hellwig wrote:
> This is odd to say at least. Any chance you can check the value
> of /sys/block/$DEVICE/queue/rotational for the relevant device before
> and after this commit? And is this an ATA or NVMe SSD?
>
yeah, a
hi, Christoph Hellwig,
On Tue, Jun 25, 2024 at 01:57:35AM -0700, Christoph Hellwig wrote:
> Hi Oliver,
>
> can you test the patch below? It restores the previous behavior if
> the device did not have a volatile write cache. I think at least
> for raid0 and raid1 without bitmap t
On Tue, Jun 04, 2024 at 03:20:20PM -0700, James Houghton wrote:
> On Fri, May 31, 2024 at 12:18 PM Oliver Upton wrote:
> >
> > On Fri, May 31, 2024 at 12:11:33PM -0700, Oliver Upton wrote:
> > > On Wed, May 29, 2024 at 06:05:09PM +, James Houghton wrote:
> > &g
On Fri, May 31, 2024 at 02:31:17PM -0600, Yu Zhao wrote:
> On Fri, May 31, 2024 at 1:24 AM Oliver Upton wrote:
[...]
> > Grabbing the MMU lock for write to scan sucks, no argument there. But
> > can you please be specific about the impact of read lock v. RCU in the
> >
On Fri, May 31, 2024 at 12:11:33PM -0700, Oliver Upton wrote:
> On Wed, May 29, 2024 at 06:05:09PM +, James Houghton wrote:
>
> [...]
>
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 9e2bbee77491..eabb07c66a07 100644
>
if (data->mkold && !stage2_try_set_pte(ctx, new))
> return -EAGAIN;
It is probably worth mentioning that if there was a race to update the
PTE then the GFN is most likely young, so failing to clear AF probably
isn't even consequential.
--
Thanks,
Oliver
On Fri, May 31, 2024 at 10:45:04AM -0600, Yu Zhao wrote:
> On Fri, May 31, 2024 at 1:03 AM Oliver Upton wrote:
> >
> > On Fri, May 31, 2024 at 12:05:48AM -0600, Yu Zhao wrote:
>
> Let me add back what I said earlier:
>
> I'm not convinced, but it doesn't m
ires more work than just deferring
the deallocation to an RCU callback. Walkers that previously assumed
'exclusive' access while holding the MMU lock for write must now cope
with volatile PTEs.
Yes, this problem already exists when hardware sets the AF, but the
lock-free walker implementation needs to be generic so it can be applied
for other PTE bits.
--
Thanks,
Oliver
the time on v4.
You seriously cannot fault a contributor for respinning their work based
on the provided feedback.
--
Thanks,
Oliver
_arch_sched_in(), just being able to remove all of the arch stubs makes
> it worth adding the flag.
>
> Link: https://lore.kernel.org/all/20240430224431.490139-1-sea...@google.com
> Cc: Oliver Upton
> Signed-off-by: Sean Christopherson
Reviewed-by: Oliver Upton
--
Thanks,
Oliver
ain text inline quoting which makes your messages annoying to reply
to. Some linux development lists will also silently drop HTML emails.
Please talk to the other LTC engineers about how to set up your mail
client to send plain text emails to avoid these problems in the
future.
Oliver
On Tue, May 14, 2024 at 11:54 PM Krishna Kumar wrote:
>
> There is an issue with the hotplug operation when it's done on the
> bridge/switch slot. The bridge-port and devices behind the bridge, which
> become offline by hot-unplug operation, don't get hot-plugged/enabled by
> doing hot-plug operat
On Wed, May 01, 2024 at 07:28:21AM -0700, Sean Christopherson wrote:
> On Wed, May 01, 2024, Oliver Upton wrote:
> > On Tue, Apr 30, 2024 at 12:31:53PM -0700, Sean Christopherson wrote:
> > > Drop kvm_arch_sched_in() and instead pass a @sched_in boolean to
> &
to do that, but I couldn't
> convince myself it was necessary).
Needing to pass @sched_in for other usage of kvm_arch_vcpu_load() hurts
readability, especially when no other architecture besides x86 cares
about it.
--
Thanks,
Oliver
On Fri, 16 Feb 2024 15:59:41 +, Oliver Upton wrote:
> The general expectation with debugfs is that any initialization failure
> is nonfatal. Nevertheless, kvm_arch_create_vm_debugfs() allows
> implementations to return an error and kvm_create_vm_debugfs() allows
> that to fail
debugfs
failures fatal for the VM. Seems like everyone already had the right
idea, as all implementations already return 0 unconditionally.
Signed-off-by: Oliver Upton
---
Compile-tested on arm64, powerpc, and x86 since I don't trust myself to
even get this simple patch right.
arch/powerp
On Thu, Dec 28, 2023 at 4:49 PM Timothy Pearson
wrote:
>
> Hrmm, potentially related, I'm getting a kernel oops when I try to hot unplug
> the entire PCIe switch from the PHB4:
IIRC there's hard to fix races in the pci core around removal of pci
slot devices. Maybe someone fixed those since I tr
On Thu, Dec 28, 2023 at 3:16 PM Timothy Pearson
wrote:
>
> I've been evaluating some new options for our POWER9-based hardware in the
> NVMe space, and would like some clarification on the current status of PCIe
> hotplug for the PowerNV platforms.
>
> From what I understand, the pnv_php driver
hi, Linus,
On Sun, Nov 26, 2023 at 03:20:58PM -0800, Linus Torvalds wrote:
> On Sun, 26 Nov 2023 at 12:23, Linus Torvalds
> wrote:
> >
> > IOW, I might have messed up some "trivial cleanup" when prepping for
> > sending it out...
>
> Bah. Famous last words. One of the "trivial cleanups" made the
device errors are nothing major
and can be resolved by just restarting the device. However, there's no
way for generic kernel code to make that assessment and we probably
shouldn't have the kernel guess. I'd say the safest option would be to
punt that decision to userspace and provide some way to whitelist
devices that we can ignore errors from. I'm not familiar enough with
the ACPI to know if we have enough details in the notification it
sends to actually implement that though.
Oliver
you can handle it in userspace?
> (Or because the TDM board's fpga has decided it isn't going to respond
> to any accesses until the BARs are setup again...)
>
> The system can carry on with some TDM connections disabled - but that
> is ok because they are all duplicated in case a cable gets cuit.
Well that's a relief :)
Oliver
r = vgic_present;
> > break;
> > case KVM_CAP_IOEVENTFD:
> > - case KVM_CAP_DEVICE_CTRL:
> > case KVM_CAP_USER_MEMORY:
> > case KVM_CAP_SYNC_MMU:
> > case KVM_CAP_DESTROY_MEMORY_REGION_WORKS:
for arm64:
Reviewed-by: Oliver Upton
--
Thanks,
Oliver
On Tue, Jun 13, 2023 at 11:44 AM Ganesh Goudar wrote:
>
> Hi,
>
> EEH recovery is currently serialized and these patches shorten
> the time taken for EEH recovery by making the recovery to run
> in parallel. The original author of these patches is Sam Bobroff,
> I have rebased and tested these pat
On Wed, May 31, 2023 at 05:10:52PM -0600, Yu Zhao wrote:
> On Wed, May 31, 2023 at 1:28 PM Oliver Upton wrote:
> > On Tue, May 30, 2023 at 02:06:55PM -0600, Yu Zhao wrote:
> > > On Tue, May 30, 2023 at 1:37 PM Oliver Upton
> > > wrote:
> > > > As it is c
(is_hyp_code());
Delete this assertion.
> + kvm_pgtable_walk(kvm->arch.mmu.pgt, start, end - start, &walker);
> +
> + return false;
> +}
> +
> phys_addr_t kvm_mmu_get_httbr(void)
> {
> return __pa(hyp_pgtable->pgd);
> --
> 2.41.0.rc0.172.g3f132b7071-goog
>
--
Thanks,
Oliver
On Tue, May 30, 2023 at 02:06:55PM -0600, Yu Zhao wrote:
> On Tue, May 30, 2023 at 1:37 PM Oliver Upton wrote:
> >
> > Hi Yu,
> >
> > On Sat, May 27, 2023 at 02:13:07PM -0600, Yu Zhao wrote:
> > > On Sat, May 27, 2023 at 12:08 PM Oliver Upton
> > > w
Hi Yu,
On Sat, May 27, 2023 at 02:13:07PM -0600, Yu Zhao wrote:
> On Sat, May 27, 2023 at 12:08 PM Oliver Upton wrote:
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 3d61bd3e591d..bfbebdcb4ef0 100644
> > --- a/arch/arm64/kvm/hyp/pgt
automatically
> * freed.
> + * @put_page_rcu:RCU variant of the above.
You don't need to add yet another hook to implement this. I was working
on lock-free walks in a separate context and arrived at the following:
commit f82d264a37745e07ee28e116
l out-of-tree stats that use arrays. Custom name
> support is something we added internally and it reduces our technical
> debt to get the support merged upstream.
For the series:
Reviewed-by: Oliver Upton
--
Thanks,
Oliver
(kvm->arch.mmu.pgt, start, end - start, &walker);
> +
> + rcu_read_unlock();
The rcu_read_{lock,unlock}() is entirely superfluous.
Of course, it is somewhat hidden by the fact that we must use
abstractions to support host and EL2 use of the page table code, but we
already make use of RCU to protect the stage-2 of a 'regular' VM.
> + return true;
> +}
> +
> bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
> {
> if (!kvm->arch.mmu.pgt)
> @@ -1848,7 +1924,6 @@ void kvm_arch_memslots_updated(struct kvm *kvm, u64 gen)
>
> void kvm_arch_flush_shadow_all(struct kvm *kvm)
> {
> - kvm_free_stage2_pgd(&kvm->arch.mmu);
> }
Doesn't this become a blatant correctness issue? This entirely fails to
uphold the exact expectations of the call.
--
Thanks,
Oliver
r
space talking to removed devices by returning an error and keeping
the resources association with the open file allocated until
user space calls close()
Regards
Oliver
every case,
not just this corner case. It basically means that user space can stall
the kernel for an arbitrary amount of time. And we cannot have that.
Regards
Oliver
ould get
you most of the benefit without needing to turn the already
complicated recovery path into an async trainwreck. IIRC Sam's
motivation for that patch was to make recovery faster for powernv
systems when an error was injected on a PF with a lot of child VFs.
Certain drivers took forever to recover each VF (might have been mlx5)
so doing it in parallel would have sped things up considerably.
Oliver
t; Thank you for your service.
>
> > I remain grateful to Oliver for picking up my slack over the years.
>
> Ack.
>
> But I wonder if he is still happy being listed as the only maintainer.
> Given the status is "Supported" that means "Someone is actually paid t
On Fri, Jul 29, 2022 at 12:21 PM Alexey Kardashevskiy wrote:
>
> *snip*
>
> About this. If a platform has a concept of explicit DMA windows (2 or
> more), is it one domain with 2 windows or 2 domains with one window each?
>
> If it is 2 windows, iommu_domain_ops misses windows manipulation
> callb
On Thu, May 19, 2022 at 10:38 PM Michael Ellerman wrote:
>
> Christophe Leroy writes:
> > Le 02/09/2020 à 05:51, Oliver O'Halloran a écrit :
> >> The MPS field in the VF config space is marked as reserved in current
> >> versions of the SR-IOV spec. In
On Wed, Nov 24, 2021 at 12:05 AM Mahesh Salgaonkar wrote:
>
> *snip*
>
> This causes the EEH handler to get stuck for ~6
> seconds before it could notify that the pci error has been detected and
> stop any active operations. Hence with running I/O traffic, during this 6
> seconds, the network driv
On Wed, Nov 24, 2021 at 7:45 PM Mahesh J Salgaonkar
wrote:
>
> No it doesn't. We will still do a presence check before the recovery
> process starts. This patch moves the check after notifying the driver to
> stop active I/O operations. If a presence check finds the device isn't
> present, we will
f the microblaze version. The only caller
must be compiled as a built-in so there's no reason for the export.
Signed-off-by: Oliver O'Halloran
---
arch/microblaze/pci/pci-common.c | 3 +--
arch/powerpc/kernel/pci-common.c | 2 +-
arch/powerpc/platforms/powernv/pci-sriov
a PCI device is scanned.
>
> Thanks for cleaning this up for us.
>
> > Now pci_dev_assign_added() is called in pci_bus_add_device() which is
> > only called after scanning the device. Thus pci_dev_is_added() is always
> > false and can be dropped.
>
> My only query
On Tue, Sep 7, 2021 at 10:21 PM Niklas Schnelle wrote:
>
> On Tue, 2021-09-07 at 10:45 +0200, Niklas Schnelle wrote:
> > On Tue, 2021-09-07 at 12:04 +1000, Oliver O'Halloran wrote:
> > > On Mon, Sep 6, 2021 at 7:49 PM Niklas Schnelle
> > > wrote:
> &
On Wed, Sep 8, 2021 at 8:02 AM Tyrel Datwyler wrote:
>
> On 9/7/21 1:59 AM, Xu Wang wrote:
> > Device node iterators put the previous value of the index variable,
> > so an explicit put causes a double put.
> >
> > Signed-off-by: Xu Wang
> > ---
> > drivers/pci/hotplug/pnv_php.c | 1 -
> > 1 fil
On Mon, Sep 6, 2021 at 7:49 PM Niklas Schnelle wrote:
>
> Patch 3 I already sent separately resulting in the discussion below but
> without
> a final conclusion.
>
> https://lore.kernel.org/lkml/20210720150145.640727-1-schne...@linux.ibm.com/
>
> I believe even though there were some doubts about
On Sun, Jul 18, 2021 at 2:14 AM Guenter Roeck wrote:
>
> On Sun, Jul 18, 2021 at 01:54:23AM +1000, Oliver O'Halloran wrote:
> > On Sat, Jul 17, 2021 at 8:12 AM Guenter Roeck wrote:
> > >
> > > This patch reverts commit 407d418f2fd4 ("powerpc/chr
boots with the latest Linux kernel.
> I personally don't care too much if ppc/chrp support is broken in the
> upstream kernel or not. Please take this patch as problem report,
> and feel free to do with it whatever you like, including ignoring it.
Problem reports are fine and appreciated. I'd be less cranky if you
included the kernel config you used in the initial report since I
wasted an hour of my saturday trying to replicate it with various
kernel configs that had SMP enabled since that's what the
chrp_defconfig uses.
Oliver
CI init before the kernel has setup the page
allocator. You need to either debug the problem fully, or provide
enough replication details so that someone who isn't invested in
emulating ancient hardware (i.e. me) with enough information to
actually replicate the problem.
Oliver
On Fri, Jun 18, 2021 at 4:05 PM Wesley Sheng wrote:
>
> Reset_link() callback function was called before mmio_enabled() in
> pcie_do_recovery() function actually, so rearrange the general
> sequence betwen step 2 and step 3 accordingly.
I don't think this is true in all cases. If pcie_do_recovery
On Tue, Jun 8, 2021 at 4:33 PM He Ying wrote:
>
> Hello,
>
> 在 2021/6/8 13:26, Oliver O'Halloran 写道:
> > On Fri, Jun 4, 2021 at 7:39 PM He Ying wrote:
> >> From "64-bit PowerPC ELF Application Binary Interface Supplement 1.9",
> >> we know that
On Fri, Jun 4, 2021 at 7:39 PM He Ying wrote:
>
> From "64-bit PowerPC ELF Application Binary Interface Supplement 1.9",
> we know that the value of a function pointer in a language like C is
> the address of the function descriptor and the first doubleword
> of the function descriptor contains th
On Fri, May 7, 2021 at 3:43 AM Mahesh Salgaonkar wrote:
>
> When certain PHB HW failure causes phyp to recover PHB, it marks the PE
> state as temporarily unavailable. In this case, per PAPR, rtas call
> ibm,read-slot-reset-state2 returns a PE state as temporarily unavailable(5)
> and OS has to wa
On Fri, Apr 23, 2021 at 9:09 AM Daniel Axtens wrote:
>
> Hi Nick,
>
> > While looking at -Wundef warnings, the #if CONFIG_EEH stood out as a
> > possible candidate to convert to #ifdef CONFIG_EEH, but it seems that
> > based on Kconfig dependencies it's not possible to build this file
> > without
pa |= token & ((1ul << hugepage_shift) - 1);
> + }
I think I vaguely remember thinking "is this right?" at the time.
Apparently not!
Reviewed-by: Oliver O'Halloran
It would probably be a good idea to add a debugfs interface to help
with testi
On Wed, Feb 24, 2021 at 11:55 AM Michael Ellerman wrote:
>
> Olof Johansson writes:
> > Hi,
> >
> > On Tue, Feb 23, 2021 at 1:43 PM Christian Zigotzky
> > wrote:
> >>
> >> Hello,
> >>
> >> The Nemo board [1] with a P.A. Semi PA6T SoC doesn't boot anymore
> >> because of moving "pas_pci_init" to
On Tue, Feb 23, 2021 at 9:44 AM Linus Torvalds
wrote:
>
> On Mon, Feb 22, 2021 at 4:06 AM Michael Ellerman wrote:
> >
> > Please pull powerpc updates for 5.12.
>
> Pulled. However:
>
> > mode change 100755 => 100644
> > tools/testing/selftests/powerpc/eeh/eeh-functions.sh
> > create mode 10075
On Fri, Feb 5, 2021 at 5:17 AM Mayank Suman wrote:
>
> Signed-off-by: Mayank Suman
commit messages aren't optional
> ---
> arch/powerpc/kernel/eeh.c| 8
> arch/powerpc/platforms/powernv/eeh-powernv.c | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
>
On Tue, Feb 2, 2021 at 2:21 PM Yang Li wrote:
>
> Eliminate the following coccicheck warning:
> ./arch/powerpc/kernel/eeh.c:782:2-3: Unneeded semicolon
Doesn't appear to be a load-bearing semicolon. It's hard to tell with EEH.
Reviewed-by: Oliver O'Halloran
>
ises about implementing
support for guest managed SRIOV in pseries qemu, but I'm not sure what
ever happened to that.
Oliver
good
state.
Currently there's no way for userspace to determine if the driver supports
recovery or not which makes it difficult to write automated tests for EEH.
This patch addressing that by adding a debugfs interface for querying if
a specific device can be recovered or not.
Signed-off-
Pull the string -> pci_dev lookup stuff into a helper function. No functional
change.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh.c | 71 ---
1 file changed, 37 insertions(+), 34 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.
capable devices and
enabling / disabling VFs so we can exercise the VF specific EEH recovery
paths. Two new tests are added, one for testing EEH aware devices and one
for EEH un-aware VFs.
Signed-off-by: Oliver O'Halloran
---
.../selftests/powerpc/eeh/eeh-functions.sh
We want to use stdout to return lists of devices, etc so log debug / status
messages to stderr rather than stdout.
Signed-off-by: Oliver O'Halloran
---
.../selftests/powerpc/eeh/eeh-functions.sh| 20 +++
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/
Hoist some of the useful test environment checking and prep code into
eeh-functions.sh so they can be reused in other tests.
Signed-off-by: Oliver O'Halloran
---
.../selftests/powerpc/eeh/eeh-basic.sh| 39 ++-
.../selftests/powerpc/eeh/eeh-functions.sh
On Tue, Nov 3, 2020 at 1:39 AM Cédric Le Goater wrote:
>
> On 10/14/20 4:55 AM, Alexey Kardashevskiy wrote:
> >
> > How do you remove PHBs exactly? There is no such thing in the powernv
> > platform, I thought someone added this and you are fixing it but no. PHBs
> > on powernv are created at th
Signed-off-by: Oliver O'Halloran
---
compile tested with pmac32_defconfig and g5_defconfig
---
arch/powerpc/platforms/powermac/setup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/setup.c
b/arch/powerpc/platforms/powermac/setup.c
Signed-off-by: Oliver O'Halloran
---
compile tested with pasemi_defconfig
---
arch/powerpc/platforms/pasemi/setup.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/setup.c
b/arch/powerpc/platforms/pasemi/setup.c
index b612474
Signed-off-by: Oliver O'Halloran
---
compile tested with mvme5100_defconfig
---
arch/powerpc/platforms/embedded6xx/mvme5100.c | 13 -
arch/powerpc/platforms/embedded6xx/storcenter.c | 8 ++--
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/po
Signed-off-by: Oliver O'Halloran
---
compile tested with mpc7448_hpc2_defconfig
---
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
b/arch/powerpc/plat
Signed-off-by: Oliver O'Halloran
---
compile tested with linkstation_defconfig
---
arch/powerpc/platforms/embedded6xx/linkstation.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/linkstation.c
b/arch/powerpc/plat
Signed-off-by: Oliver O'Halloran
---
compile tested with holly_defconfig
---
arch/powerpc/platforms/embedded6xx/holly.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/holly.c
b/arch/powerpc/platforms/embedded6xx/holly.c
Signed-off-by: Oliver O'Halloran
---
compile tested with chrp32_defconfig
---
arch/powerpc/platforms/chrp/pci.c | 8
arch/powerpc/platforms/chrp/setup.c | 12 +---
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/pci.c
b
Signed-off-by: Oliver O'Halloran
---
compile tested with amigaone_defconfig
---
arch/powerpc/platforms/amigaone/setup.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/amigaone/setup.c
b/arch/powerpc/platforms/amigaone/setup.c
Signed-off-by: Oliver O'Halloran
---
compile tested with mpc83xx_defconfig
---
arch/powerpc/platforms/83xx/asp834x.c | 1 +
arch/powerpc/platforms/83xx/km83xx.c | 1 +
arch/powerpc/platforms/83xx/misc.c| 2 --
arch/powerpc/platforms/83xx/mpc830x_rdb.c | 1 +
arch/po
Signed-off-by: Oliver O'Halloran
---
compile tested with pq2fads_defconfig
---
arch/powerpc/platforms/82xx/mpc8272_ads.c | 2 +-
arch/powerpc/platforms/82xx/pq2fads.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c
b
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/52xx/mpc5200_simple.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c
b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index 2d01e9b2e779..b9f5675b0a1d 100644
--- a
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/52xx/media5200.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/media5200.c
b/arch/powerpc/platforms/52xx/media5200.c
index 07c5bc4ed0b5..efb8bdecbcc7 100644
--- a/arch/po
Signed-off-by: Oliver O'Halloran
---
compile tested with 52xx/lite5200b_defconfig
---
arch/powerpc/platforms/52xx/lite5200.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/lite5200.c
b/arch/powerpc/platforms/52xx/lite5200.c
index 3181aac
Signed-off-by: Oliver O'Halloran
---
compile tested with mpc5200_defconfig
---
arch/powerpc/platforms/52xx/efika.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/efika.c
b/arch/powerpc/platforms/52xx/efika.c
index 4514a6f7458a..3b7d70d
Signed-off-by: Oliver O'Halloran
---
only compile tested
---
arch/powerpc/platforms/512x/mpc5121_ads.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c
b/arch/powerpc/platforms/512x/mpc5121_ads.c
index 6303fbf
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/maple/setup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/maple/setup.c
b/arch/powerpc/platforms/maple/setup.c
index f7e66a2005b4..4e9ad5bf3efb 100644
--- a/arch/powerpc/platforms/
just move the
pci_dn setup into the per-PHB inits which occur inside of .discover_phb()
for these platforms. This brings the boot-time path in line with the PHB
hotplug path that is used for pseries DLPAR operations too.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/p
't just an
academic issue either since on pseries and PowerNV EEH init occurs in an
arch_initcall and depends on the pci_controllers being available, similarly
the creation of pci_dns occurs at core_initcall_sync (i.e. between core and
postcore initcalls). These problems need to be addressed sepera
8/0x1d0
> system_call_common+0xe8/0x218
>
> Fixes: 5ca85ae6318d ("powerpc/eeh_cache: Add a way to dump the EEH address
> cache")
> Signed-off-by: Qian Cai
Good catch,
Reviewed-by: Oliver O'Halloran
pc/eeh
which means it's technically ABI. We could make it hard-coded, but that's
a change for another patch.
Fixes: 269e583357df ("powerpc/eeh: Delete eeh_pe->config_addr")
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh.c | 5 -
1 file changed
On Thu, Oct 15, 2020 at 5:28 AM Qian Cai wrote:
>
> This reverts commit 3a3181e16fbde752007759f8759d25e0ff1fc425 which
> causes memory corruptions on POWER9 NV.
I was going to post this along with a fix for Cedric's original bug,
but I can do that separately so:
Acked-by: Oliver O'Halloran
ix this by checking if the return code is non-zero and report success
and failure by returning 0 or 1 respectively. For the cases where should
actually skip return 4.
Fixes: 85d86c8aa52e ("selftests/powerpc: Add basic EEH selftest")
Signed-off-by: Oliver O'Halloran
---
tools/test
On Fri, Sep 25, 2020 at 7:23 PM Cédric Le Goater wrote:
>
> To fix an issue with PHB hotplug on pSeries machine (HPT/XIVE), commit
> 3a3181e16fbd introduced a PPC specific pcibios_remove_bus() routine to
> clear all interrupt mappings when the bus is removed. This routine
> frees an array allocate
uot; instead. Fix this by
consistently using the "ret" variable for the result of the RTAS call
helpers an dropping the "addr" local variable"
Fixes: 98ba956f6a38 ("powerpc/pseries/eeh: Rework device EEH PE determination")
Signed-off-by: Oliver O'Halloran
---
a
The eeh_pe->config_addr field was supposed to be removed in
commit 35d64734b643 ("powerpc/eeh: Clean up PE addressing") which made it
largely unused. Finish the job.
Signed-off-by: Oliver O'Halloran
---
mpe: the Fixes SHA is from ppc/next, fold it into that if you want.
---
ar
1 - 100 of 829 matches
Mail list logo
