There are no users of the early-out return value from
eeh_pe_dev_traverse(), so remove it.
Signed-off-by: Sam Bobroff
---
arch/powerpc/include/asm/eeh.h | 6 +++---
arch/powerpc/kernel/eeh.c| 16 +---
arch/powerpc/kernel/eeh_driver.c | 26 +++---
arch/p
Hello Everyone,
Here are three small fixes to the upper level EEH code: two small cleanups
and a fix for a crash when PCI device removal races with EEH recovery.
(They are based on my last (unnamed) set of EEH fixes, which are not yet
upstream, but they should apply fairly easily without them if
Simplify some needlessly complicated boolean logic in
eeh_add_to_parent_pe().
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh_pe.c | 52 +++-
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/
If a PCI device is removed during eeh_pe_report_edev(), between the
calls to device_lock() and device_unlock(), edev->pdev will change and
cause a crash as the wrong mutex is released.
To correct this, hold the PCI rescan/remove lock while taking a copy
of edev->pdev and performing a get_device()
Le 02/08/2019 à 07:02, Chris Packham a écrit :
Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef mess")
CONFIG_CMDLINE has always had a value regardless of CONNIG_CMDLINE_BOOL.
s/CONNIG/CONFIG/
For example:
$ make ARCH=powerpc defconfig
$ cat .config
# CONFIG_CMDLIN
Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef mess")
CONFIG_CMDLINE has always had a value regardless of CONNIG_CMDLINE_BOOL.
For example:
$ make ARCH=powerpc defconfig
$ cat .config
# CONFIG_CMDLINE_BOOL is not set
CONFIG_CMDLINE=""
When enabling CONNIG_CMDLINE_BOOL this
On Thu, Jul 25, 2019 at 04:01:55PM +0800, Chuhong Yuan wrote:
> Use devm_hwrng_register to simplify the implementation.
> Manual unregistration and some remove functions can be
> removed now.
>
> Signed-off-by: Chuhong Yuan
> ---
> drivers/char/hw_random/atmel-rng.c | 3 +--
> drivers/char/
On Wed, Jul 24, 2019 at 01:24:33PM +0530, Nishka Dasgupta wrote:
> Each iteration of for_each_compatible_node puts the previous node, but
> in the case of a return from the middle of the loop, there is no put,
> thus causing a memory leak. Add an of_node_put before the return.
> Issue found with Co
Le 02/08/2019 à 00:50, Chris Packham a écrit :
Bring powerpc in line with other architectures that support extending or
overriding the bootloader provided command line.
The current behaviour is most like CMDLINE_FROM_BOOTLOADER where the
bootloader command line is preferred but the kernel con
Le 02/08/2019 à 00:32, Chris Packham a écrit :
On Thu, 2019-08-01 at 08:14 +0200, Christophe Leroy wrote:
Le 01/08/2019 à 04:12, Chris Packham a écrit :
Bring powerpc in line with other architectures that support
extending or
overriding the bootloader provided command line.
The current be
Booting w/ ppc64le_defconfig + CONFIG_PREEMPT results in the attached
kernel trace due to calling shared-processor spinlocks while not running
in an SPLPAR. Previously, the out-of-line spinlocks implementations were
selected based on CONFIG_PPC_SPLPAR at compile time without a runtime
shared-proces
Determining if a processor is in shared processor mode is not a constant
so don't hide it behind a #define.
Signed-off-by: Christopher M. Riedl
Reviewed-by: Andrew Donnellan
---
arch/powerpc/include/asm/spinlock.h | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
The __rw_yield and __spin_yield locks only pertain to SPLPAR mode.
Rename them to make this relationship obvious.
Signed-off-by: Christopher M. Riedl
Reviewed-by: Andrew Donnellan
---
arch/powerpc/include/asm/spinlock.h | 6 --
arch/powerpc/lib/locks.c| 6 +++---
2 files changed
Fixes an oops when calling the shared-processor spinlock implementation
from a non-SP LPAR. Also take this opportunity to refactor
SHARED_PROCESSOR a bit.
Reference: https://github.com/linuxppc/issues/issues/229
Changes since v1:
- Improve comment wording to make it clear why the BOOK3S #ifdef
On Wed, 2019-07-31 at 06:01:42 UTC, Christophe Leroy wrote:
> Due to commit 4a6d8cf90017 ("powerpc/mm: don't use pte_alloc_kernel()
> until slab is available on PPC32"), pte_alloc_kernel() cannot be used
> during early KASAN init.
>
> Fix it by using memblock_alloc() instead.
>
> Reported-by: Erh
On Tue, 2019-07-30 at 14:19:17 UTC, Michael Ellerman wrote:
> Mark switch cases where we are expecting to fall through.
>
> Fixes errors such as below, seen with mpc85xx_defconfig:
>
> arch/powerpc/kernel/align.c: In function 'emulate_spe':
> arch/powerpc/kernel/align.c:178:8: error: this sta
On Tue, 2019-07-30 at 04:37:04 UTC, Stephen Rothwell wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning (Building: powerpc):
>
> drivers/macintosh/smu.c: In function 'smu_queue_i2c':
> drivers/macintosh/smu.c:854:21: warning: this stateme
On 2019/8/1 22:36, Diana Madalina Craciun wrote:
Hi Jason,
I have tested these series on a P4080 platform.
Regards,
Diana
Diana, thank you so much.
So can you take a look at the code of this version and give a
Reviewed-by or Tested-by?
Thanks,
Jason
Jordan Niethe writes:
> The comment above xive_esb_read() references magic loads from an ESB as
> described xive.h. This has been inaccurate since commit 12c1f339cd49
> ("powerpc/xive: Move definition of ESB bits") which moved the
> description. Update the comment to reference the new location of
On Mon, Jul 22, 2019 at 02:05:12PM +1000, Michael Ellerman wrote:
> Nathan Chancellor writes:
> > On Mon, Jun 03, 2019 at 03:11:58PM -0700, Nathan Chancellor wrote:
> >> When building with -Wsometimes-uninitialized, clang warns:
> >>
> >> drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variabl
The comment above xive_esb_read() references magic loads from an ESB as
described xive.h. This has been inaccurate since commit 12c1f339cd49
("powerpc/xive: Move definition of ESB bits") which moved the
description. Update the comment to reference the new location of the
description in xive-regs.h
Changes the return variable to bool (as the return value) and
avoids doing a ternary operation before returning.
Also, since rc will always be true, there is no need to do
rc &= bool, as (true && X) will result in X.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/hotplug-memory
I noticed these nested ifs can be easily replaced by switch-cases,
which can improve readability.
Signed-off-by: Leonardo Bras
---
.../platforms/pseries/hotplug-memory.c| 26 +--
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/pseries
Bring powerpc in line with other architectures that support extending or
overriding the bootloader provided command line.
The current behaviour is most like CMDLINE_FROM_BOOTLOADER where the
bootloader command line is preferred but the kernel config can provide a
fallback so CMDLINE_FROM_BOOTLOADE
On Thu, 2019-08-01 at 08:14 +0200, Christophe Leroy wrote:
>
> Le 01/08/2019 à 04:12, Chris Packham a écrit :
> >
> > Bring powerpc in line with other architectures that support
> > extending or
> > overriding the bootloader provided command line.
> >
> > The current behaviour is most like CMDLI
When using the reserved memory node in the device tree there are
two options - dynamic or static. If a dynamic allocation was
selected (where the kernel selects the address for the allocation)
convert it to a static allocation by inserting the reg property.
This will ensure the same memory is reuse
When shutting down a FQ on a dedicated channel only the
SW portal associated with that channel can dequeue from it.
Make sure the correct portal is use.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 53 +++-
1 file changed, 42 insertions(+),
Disable the QBMan interrupts during recovery.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 22 +++---
drivers/soc/fsl/qbman/qman_ccsr.c | 1 +
drivers/soc/fsl/qbman/qman_priv.h | 1 +
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/s
The drain_mr_fqni() function may be called fron uninterruptable
context so convert the msleep() to an mdelay(). Also ensure that
the valid bit is updated while polling.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --gi
If the QMan device was previously initialized make sure all the
frame queues are out of service once all the portals are probed.
This handles the case where the kernel is restarted without the
SoC being reset (kexec for example)
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c|
Clean the BMan buffer pools if the device had been initialized
previously. This will ensure a consistent state if the kernel
was soft restarted (kexec for example)
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/bman.c| 17 +
drivers/soc/fsl/qbman/bman_ccsr.c | 10
Rework QBMan private memory setup so that the areas are not
zeroed if the device was previously initialized
If the QMan private memory was already initialized skip the PFDR
initialization.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/bman_ccsr.c | 26 +--
drivers/soc/fsl/
Most DPAA1 devices do not support a soft reset which is an issue if
Kexec starts a new kernel. This patch series allows Kexec to function
by detecting that the QBMan device was previously initialized.
The patches fix some issues with device cleanup as well as ensuring
that the location of the QBMa
On Thu, Aug 01, 2019 at 10:26:28PM +1000, Michael Ellerman wrote:
> GCC 9 fails to build some of the ptrace TM tests, with errors such as:
>
> ptrace-tm-spd-vsx.c: In function 'tm_spd_vsx':
> ptrace-tm-spd-vsx.c:51:2: error: listing the stack pointer register 'r1' in
> a clobber list is depre
On Thu, Aug 01, 2019 at 06:34:57PM +0200, Christoph Hellwig wrote:
> On Thu, Aug 01, 2019 at 05:23:06PM +0100, Will Deacon wrote:
> > > - if (!dev_is_dma_coherent(dev) || (attrs & DMA_ATTR_WRITE_COMBINE))
> > > - return pgprot_writecombine(prot);
> > > - return prot;
> > > + return pgprot_w
On Thu, Aug 01, 2019 at 05:23:06PM +0100, Will Deacon wrote:
> > - if (!dev_is_dma_coherent(dev) || (attrs & DMA_ATTR_WRITE_COMBINE))
> > - return pgprot_writecombine(prot);
> > - return prot;
> > + return pgprot_writecombine(prot);
> > }
>
> Seems like a sensible cleanup to me:
>
On Thu, Aug 01, 2019 at 05:21:18PM +0300, Christoph Hellwig wrote:
> All the way back to introducing dma_common_mmap we've defaulyed to mark
> the pages as uncached. But this is wrong for DMA coherent devices or
> if using DMA_ATTR_NON_CONSISTENT. Later on DMA_ATTR_WRITE_COMBINE
> also got incorr
Hi Christoph, thanks for the review.
On Thu, 2019-08-01 at 16:04 +0200, Christoph Hellwig wrote:
> A few nitpicks, otherwise this looks great:
>
> > @@ -201,7 +202,7 @@ static int __init mark_nonram_nosave(void)
> > * everything else. GFP_DMA32 page allocations automatically fall back to
> >
Hi Jason,
I have tested these series on a P4080 platform.
Regards,
Diana
On 7/31/2019 12:26 PM, Jason Yan wrote:
> This series implements KASLR for powerpc/fsl_booke/32, as a security
> feature that deters exploit attempts relying on knowledge of the location
> of kernel internals.
>
> Since CO
All the way back to introducing dma_common_mmap we've defaulyed to mark
the pages as uncached. But this is wrong for DMA coherent devices or
if using DMA_ATTR_NON_CONSISTENT. Later on DMA_ATTR_WRITE_COMBINE
also got incorrect treatment as that flag is only treated special on
the alloc side for no
Hi all,
As Shawn pointed out we've had issues with the dma mmap pgprots ever
since the dma_common_mmap helper was added beyong the initial
architectures - we default to uncached mappings, but for devices that
are DMA coherent, or if the DMA_ATTR_NON_CONSISTENT is set (and
supported) this can lead
A few nitpicks, otherwise this looks great:
> @@ -201,7 +202,7 @@ static int __init mark_nonram_nosave(void)
> * everything else. GFP_DMA32 page allocations automatically fall back to
> * ZONE_DMA.
> *
> - * By using 31-bit unconditionally, we can exploit ARCH_ZONE_DMA_BITS to
> + * By using
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
On Wed, 31 Jul 2019 12:09:54 +
bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
>
> --- Comment #4 from m...@ellerman.id.au ---
>
> > I s
GCC 9 fails to build some of the ptrace TM tests, with errors such as:
ptrace-tm-spd-vsx.c: In function 'tm_spd_vsx':
ptrace-tm-spd-vsx.c:51:2: error: listing the stack pointer register 'r1' in a
clobber list is deprecated [-Werror=deprecated]
51 | asm __volatile__(
| ^~~
ptr
https://bugzilla.kernel.org/show_bug.cgi?id=204375
--- Comment #13 from Erhard F. (erhar...@mailbox.org) ---
Thanks for the hint! But adding KASAN_SANITIZE := n to lib/mpi/Makefile did not
make a change in this case.
However I had the idea to disable btrfs (at all) and boot from my other ext4
par
On 01/08/2019 13:09, Christophe JAILLET wrote:
> 'xive_irq_bitmap_add()' can return -ENOMEM.
> In this case, we should free the memory already allocated and return
> 'false' to the caller.
>
> Also add an error path which undoes the 'tima = ioremap(...)'
>
> Signed-off-by: Christophe JAILLET
> -
schedule_work() cannot be called from MCE exception context as MCE can
interrupt even in interrupt disabled context.
fixes: 733e4a4c ("powerpc/mce: hookup memory_failure for UE errors")
Signed-off-by: Santosh Sivaraj
---
arch/powerpc/kernel/mce.c | 8 +---
1 file changed, 5 insertions(+), 3
'xive_irq_bitmap_add()' can return -ENOMEM.
In this case, we should free the memory already allocated and return
'false' to the caller.
Also add an error path which undoes the 'tima = ioremap(...)'
Signed-off-by: Christophe JAILLET
---
NOT compile tested (I don't have a cross compiler and won't
On Thu, 1 Aug 2019 10:32:42 +0200
Christophe JAILLET wrote:
> The result of this kzalloc is not checked. Add a check and corresponding
> error handling code.
>
> Signed-off-by: Christophe JAILLET
> ---
Reviewed-by: Greg Kurz
> Note that 'xive_irq_bitmap_add()' failures are not handled in
>
On Thu, 1 Aug 2019 10:32:31 +0200
Christophe JAILLET wrote:
> There is no need to use GFP_ATOMIC here. GFP_KERNEL should be enough.
> GFP_KERNEL is also already used for another allocation just a few lines
> below.
>
> Signed-off-by: Christophe JAILLET
> ---
Good catch.
Reviewed-by: Greg Kur
On 01/08/2019 07:16, Joel Stanley wrote:
> Often the firmware will guard out cores after a crash. This often
> undesirable, and is not immediately noticeable.
>
> This adds an informative message when a CPU device tree nodes are marked
> bad in the device tree.
>
> Signed-off-by: Joel Stanley
>
On 01/08/2019 10:32, Christophe JAILLET wrote:
> There is no need to use GFP_ATOMIC here. GFP_KERNEL should be enough.
> GFP_KERNEL is also already used for another allocation just a few lines
> below.
This is correct.
> Signed-off-by: Christophe JAILLET
Reviewed-by: Cédric Le Goater
Thanks
The result of this kzalloc is not checked. Add a check and corresponding
error handling code.
Signed-off-by: Christophe JAILLET
---
Note that 'xive_irq_bitmap_add()' failures are not handled in
'xive_spapr_init()'
I guess that it is not really an issue. This function is _init, so if a
memory allo
There is no need to use GFP_ATOMIC here. GFP_KERNEL should be enough.
GFP_KERNEL is also already used for another allocation just a few lines
below.
Signed-off-by: Christophe JAILLET
---
arch/powerpc/sysdev/xive/spapr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/pow
The first patch uses GFP_KERNEL instead of GFP_ATOMIC.
The 2nd adds a check for memory allocation failure.
Christophe JAILLET (2):
powerpc/xive: Use GFP_KERNEL instead of GFP_ATOMIC in
'xive_irq_bitmap_add()'
powerpc/xive: Add a check for memory allocation failure
arch/powerpc/sysdev/xiv
55 matches
Mail list logo
