On 08/27/2015 04:16 PM, Gavin Shan wrote:
On Thu, Aug 27, 2015 at 04:01:16PM +1000, Alexey Kardashevskiy wrote:
"powerpc/iommu: Cleanup setting of DMA base/offset" expects that
the default DMA offset is set from pnv_ioda_setup_bus_dma() which
is correct unless it is SRIOV where the code flow is
Modify the OCC reset/load/active event message to make it clearer for
the user to understand the event and effect of the event.
Suggested-by: Stewart Smith
Signed-off-by: Shilpasri G Bhat
---
This patch is based on top of linux-next/master
drivers/cpufreq/powernv-cpufreq.c | 9 +
1 fil
Create a sysfs 'throttle' attribute per-chip(per-numa-node) to reflect
the throttle state of the chip. The usersapce programs can poll on
this attribute to keep an eye on the throttle state. Currently we
print a log message to notify the user of throttling event. The
performance-sensitive applicati
On Thu, 2015-08-27 at 14:43 +0530, Shilpasri G Bhat wrote:
> Create a sysfs 'throttle' attribute per-chip(per-numa-node) to reflect
> the throttle state of the chip. The usersapce programs can poll on
> this attribute to keep an eye on the throttle state. Currently we
> print a log message to notif
On Thu, 2015-27-08 at 06:01:16 UTC, Alexey Kardashevskiy wrote:
> "powerpc/iommu: Cleanup setting of DMA base/offset" expects that
This should be:
Commit e91c25111aa3 "powerpc/iommu: Cleanup setting of DMA base/offset" ...
> the default DMA offset is set from pnv_ioda_setup_bus_dma() which
> is
2015-08-26 11:54 GMT+03:00 Aneesh Kumar K.V :
>
> Missed to cherry-pick the updated version of this patch, before sending
> the series out.
>
> commit aeb324e09d95c189eda4ce03790da94b535d1dfc
> Author: Aneesh Kumar K.V
> Date: Fri Aug 14 12:28:58 2015 +0530
>
> kasan: Don't use kasan shadow
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> We add enable/disable callbacks in this patch which architecture
> can implemement. We will use this in the later patches for architecture
> like ppc64, that cannot have early zero page kasan shadow region for the
> entire virtual address space. Such
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> Some archs may want to provide kasan shadow memory as a constant
> offset from the address. Such arch even though cannot use inline kasan
> support, they can work with outofline kasan support.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> include/linu
From: Ian Munsie
If the cxl_context_alloc() call fails, we return immediately without
releasing the reference on the AFU device, allowing it to leak.
This patch switches to using goto style error handling so that the
device is released in common code for both error paths, and will also
simplify
From: Ian Munsie
The cxl user api uses the address_space associated with the file when we
need to force unmap all cxl mmap regions (e.g. on eeh, driver detach,
etc). Currently, contexts allocated through the kernel api do not do
this and instead skip the mmap invalidation, potentially allowing th
On 08/27/2015 03:01 PM, Michael Ellerman wrote:
> On Thu, 2015-08-27 at 14:43 +0530, Shilpasri G Bhat wrote:
>> Create a sysfs 'throttle' attribute per-chip(per-numa-node) to reflect
>> the throttle state of the chip. The usersapce programs can poll on
>> this attribute to keep an eye on the thro
On Thu, 2015-27-08 at 06:04:10 UTC, Vasant Hegde wrote:
> Commit 84ad6e5c added LEDS support for PowerNV platform. Lets
> update ppc64_defconfig to pick LEDS driver.
>
> PowerNV LEDS driver looks for "/ibm,opal/leds" node in device
> tree and loads if this node exists. Hence added it as 'm'.
>
>
On Thu, 27 Aug 2015 13:12:05 +1000
Michael Ellerman wrote:
> On Wed, 2015-08-26 at 14:44 +, Joseph Myers wrote:
> > On Thu, 20 Aug 2015, Michael Ellerman wrote:
> >
> > > On Wed, 2015-08-19 at 14:39 +, Joseph Myers wrote:
> > > > I'd like to ping this patch series, not having seen any co
On 08/27/2015 03:56 PM, Michael Ellerman wrote:
> On Thu, 2015-27-08 at 06:04:10 UTC, Vasant Hegde wrote:
>> Commit 84ad6e5c added LEDS support for PowerNV platform. Lets
>> update ppc64_defconfig to pick LEDS driver.
>>
>> PowerNV LEDS driver looks for "/ibm,opal/leds" node in device
>> tree and l
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> Some of the archs, may find it difficult to support inline KASan
> mode. Add HAVE_ARCH_KASAN_INLINE so that we can disable inline
> support at config time.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/x86/Kconfig | 1 +
> lib/Kconfig.kasa
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> We we end up calling kasan_report in real mode, our shadow mapping
> for even spinlock variable will show poisoned.
Generally I agree with this patch. We should disable reports when we
print report as early
as possible to prevent recursion in case of
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> + k_start = (unsigned long)kasan_mem_to_shadow(start);
> + k_end = (unsigned long)kasan_mem_to_shadow(end);
> + for (; k_start < k_end; k_start += page_size) {
> + p = vmemmap_alloc_block
On 27-08-15, 14:41, Shilpasri G Bhat wrote:
> Modify the OCC reset/load/active event message to make it clearer for
> the user to understand the event and effect of the event.
>
> Suggested-by: Stewart Smith
> Signed-off-by: Shilpasri G Bhat
> ---
> This patch is based on top of linux-next/maste
On 08/27/2015 07:37 PM, Michael Ellerman wrote:
On Thu, 2015-27-08 at 06:01:16 UTC, Alexey Kardashevskiy wrote:
"powerpc/iommu: Cleanup setting of DMA base/offset" expects that
This should be:
Commit e91c25111aa3 "powerpc/iommu: Cleanup setting of DMA base/offset" ...
Is not this format for
On Mon, Aug 17, 2015 at 10:06 AM, Christoph Hellwig wrote:
> Currently there are three valid implementations of dma_mapping_error:
>
> (1) call ->mapping_error
> (2) check for a hardcoded error code
> (3) always return 0
>
> This patch provides a common implementation that calls ->mapping_error
Hi,
Has anybody already used 'perf' tool on powerpc MPC83xx ?
I have been succesfully using perf on MPC8xx, but on MPC83xx I get
something strange.
perf record/report reports addresses on user stack, as if it was mixing
up D accesses and I accesses.
Any idea of what the problem can be ?
#
I've recently come into the possession of a PowerMac7,3 and have been
cross-compiling a chroot for it on my (x86_64) desktop. However
elfutils doesn't cross-compile for ppc64 due to its biarch m4 script
which tries to execute a built program, so I kicked off a build
locally and left for a few minut
Allow it to be used from SPU, since it should not have unwanted
side-effects.
[ Untested on this architecture. To try it out: fetch linux-next/akpm,
apply this patch, build/run a membarrier-enabled kernel, and do make
kselftest. ]
Signed-off-by: Mathieu Desnoyers
CC: Andrew Morton
CC: linux
On Thu, 2015-27-08 at 06:01:16 UTC, Alexey Kardashevskiy wrote:
> "powerpc/iommu: Cleanup setting of DMA base/offset" expects that
> the default DMA offset is set from pnv_ioda_setup_bus_dma() which
> is correct unless it is SRIOV where the code flow is different - at
> the moment when pnv_ioda_set
On Fri, 2015-21-08 at 07:25:15 UTC, Daniel Axtens wrote:
> cxl_reset currently PERSTs the slot, and then repeatedly tries to
> read MMIO space in order to kick off EEH.
>
> There are 2 problems with this: it's unnecessary, and it's racy.
>
> It's unnecessary because the PERST will bring down the
On Tue, 2015-25-08 at 05:34:48 UTC, Vaibhav Jain wrote:
> This minor patch plugs a potential irq leak in case of a memory
> allocation failure inside function the afu_allocate_irqs. Presently the
> irqs allocated to the context gets leaked if allocation of either
> one of context irq_bitmap or irq_
On Thu, 2015-27-08 at 06:04:10 UTC, Vasant Hegde wrote:
> Commit 84ad6e5c added LEDS support for PowerNV platform. Lets
> update ppc64_defconfig to pick LEDS driver.
>
> PowerNV LEDS driver looks for "/ibm,opal/leds" node in device
> tree and loads if this node exists. Hence added it as 'm'.
>
>
On Sun, 2015-19-07 at 17:23:52 UTC, Vaishali Thakkar wrote:
> Macro DEFINE_PCI_DEVICE_TABLE is deprecated. So, here use
> struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE with
> the goal of getting rid of this macro completely.
>
> The Coccinelle semantic patch that performs this transforma
Still just as acked as it was when it was first posted ;-)
Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Aug 27, 2015 at 4:35 AM, Scott Wood
wrote:
On Wed, Aug 26, 2015 at 08:09:45PM +0800, Chenhui Zhao wrote:
+#ifdef CONFIG_PPC_BOOK3E
+static void qoriq_disable_thread(int cpu)
+{
+ int hw_cpu = get_hard_smp_processor_id(cpu);
+ int thread = cpu_thread_in_core(hw_cpu);
+
Hi Linus,
Please pull one fix for powerpc for 4.2:
The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b:
Linux 4.2-rc8 (2015-08-23 20:52:59 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
tags/powerpc-4.
On Thu, 2015-27-08 at 04:12:36 UTC, Gavin Shan wrote:
> Commit cca87d30 ("powerpc/pci: Refactor pci_dn") introduced pdn
> list for SRIOV VFs. It means the pdn is be put into the child list
> of its parent pdn when the pdn is created. When doing PCI hot
> unplugging on pSeries, the PCI device node a
On Thu, Aug 27, 2015 at 4:55 AM, Scott Wood
wrote:
On Wed, Aug 26, 2015 at 08:09:47PM +0800, Chenhui Zhao wrote:
+int check_cpu_dead(unsigned int cpu)
+{
+ return per_cpu(cpu_state, cpu) == CPU_DEAD;
+}
I'm not sure this needs to be a function versus open-coded, but if
you do
wan
On Fri, Aug 28, 2015 at 10:55:35AM +1000, Michael Ellerman wrote:
>On Thu, 2015-27-08 at 04:12:36 UTC, Gavin Shan wrote:
>> Commit cca87d30 ("powerpc/pci: Refactor pci_dn") introduced pdn
>> list for SRIOV VFs. It means the pdn is be put into the child list
>> of its parent pdn when the pdn is crea
On Fri, 2015-08-28 at 11:09 +1000, Gavin Shan wrote:
> On Fri, Aug 28, 2015 at 10:55:35AM +1000, Michael Ellerman wrote:
> >On Thu, 2015-27-08 at 04:12:36 UTC, Gavin Shan wrote:
> >> Commit cca87d30 ("powerpc/pci: Refactor pci_dn") introduced pdn
> >> list for SRIOV VFs. It means the pdn is be put
On Thu, Aug 27, 2015 at 6:42 AM, Scott Wood
wrote:
On Wed, Aug 26, 2015 at 08:09:48PM +0800, Chenhui Zhao wrote:
+ .globl booting_thread_hwid
+booting_thread_hwid:
+ .long INVALID_THREAD_HWID
+ .align 3
The commit message goes into no detail about the changes you're
m
On Fri, Aug 28, 2015 at 11:32:40AM +1000, Michael Ellerman wrote:
>On Fri, 2015-08-28 at 11:09 +1000, Gavin Shan wrote:
>> On Fri, Aug 28, 2015 at 10:55:35AM +1000, Michael Ellerman wrote:
>> >On Thu, 2015-27-08 at 04:12:36 UTC, Gavin Shan wrote:
>> >> Commit cca87d30 ("powerpc/pci: Refactor pci_dn
On Thu, 2015-08-27 at 11:31 -0400, Ilia Mirkin wrote:
> I've recently come into the possession of a PowerMac7,3 and have been
> cross-compiling a chroot for it on my (x86_64) desktop. However
> elfutils doesn't cross-compile for ppc64 due to its biarch m4 script
> which tries to execute a built pro
The config space of some PCI devices can't be accessed when their
PEs are in frozen state. Otherwise, fenced PHB might be seen.
Those PEs are identified with flag EEH_PE_CFG_RESTRICTED, meaing
EEH_PE_CFG_BLOCKED is set automatically when the PE is put to
frozen state (EEH_PE_ISOLATED). eeh_slot_err
On Thu, 2015-08-27 at 23:07 +1000, Alexey Kardashevskiy wrote:
> On 08/27/2015 07:37 PM, Michael Ellerman wrote:
> > On Thu, 2015-27-08 at 06:01:16 UTC, Alexey Kardashevskiy wrote:
> >> "powerpc/iommu: Cleanup setting of DMA base/offset" expects that
> >
> > This should be:
> >
> > Commit e91c25111
On Thu, 2015-08-27 at 13:31 +0200, Martin Schwidefsky wrote:
> On Thu, 27 Aug 2015 13:12:05 +1000
> Michael Ellerman wrote:
> > On Wed, 2015-08-26 at 14:44 +, Joseph Myers wrote:
> > > On Thu, 20 Aug 2015, Michael Ellerman wrote:
> > > > I'm reluctant to proceed with merging them though until
On Fri, 2015-08-28 at 09:42 +0800, Chenhui Zhao wrote:
> On Thu, Aug 27, 2015 at 6:42 AM, Scott Wood
> wrote:
> > On Wed, Aug 26, 2015 at 08:09:48PM +0800, Chenhui Zhao wrote:
> > > +.globl booting_thread_hwid
> > > +booting_thread_hwid:
> > > +.long INVALID_THREAD_HWID
> > >
On Fri, 2015-08-28 at 08:40 +0800, Scott Wood wrote:
> On Thu, Aug 27, 2015 at 4:35 AM, Scott Wood
> wrote:
> > On Wed, Aug 26, 2015 at 08:09:45PM +0800, Chenhui Zhao wrote:
I didn't write this e-mail. Please fix your mail client.
> > > +static void rcpm_v1_cpu_up_prepare(int cpu)
> > > +{
>
On Thu, Aug 27, 2015 at 9:56 PM, Michael Ellerman wrote:
> On Thu, 2015-08-27 at 11:31 -0400, Ilia Mirkin wrote:
>> I've recently come into the possession of a PowerMac7,3 and have been
>> cross-compiling a chroot for it on my (x86_64) desktop. However
>> elfutils doesn't cross-compile for ppc64 d
Relaxed/acquire/release variants of atomic operations {add,sub}_return and
{cmp,}xchg are introduced by commit:
"atomics: add acquire/release/relaxed variants of some atomic operations"
which is now on locking/core branch of tip tree.
By default, the generic code will implement relaxed variants
Some atomic operations now have _{relaxed, acquire, release} variants,
this patch then adds some trivial tests for two purpose:
1. test the behavior of these new operations in single-CPU
environment.
2. make their code generated before we actually use them somewhere,
so t
Some architectures may have their special barriers for acquire, release
and fence semantics, general memory barriers(smp_mb__*_atomic()) in
__atomic_op_*() may be too strong, so arch_atomic_op_*() helpers are
introduced for architectures to provide their own version helpers to
build different varia
On powerpc, we don't need a general memory barrier to achieve acquire and
release semantics, so arch_atomic_op_{acquire,release} can be implemented
using "lwsync" and "isync".
For release semantics, since we only need to ensure all memory accesses
that issue before must take effects before the -st
Implement xchg_relaxed and define atomic{,64}_xchg_* as xchg_relaxed,
based on these _relaxed variants, release/acquire variants can be built.
Note that xchg_relaxed and atomic_{,64}_xchg_relaxed are not compiler
barriers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/atomic.h | 2 ++
Unlike other atomic operation variants, cmpxchg{,64}_acquire and
atomic{,64}_cmpxchg_acquire don't have acquire semantics if the cmp part
fails, so we need to implement these using assembly.
Note cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed are not
compiler barriers.
Signed-off-by: Boqun
50 matches
Mail list logo
