RE: [PATCH] dmaengine: fsldma: Add 64-bit I/O accessors for powerpc64

2018-12-23 Thread Peng Ma
Hi Scott,

Oh, I did not see the in_XX64/out_XX64 supported only __powerpc64__ just now.
Thanks for your reminder.

#ifdef __powerpc64__

#ifdef __BIG_ENDIAN__
DEF_MMIO_OUT_D(out_be64, 64, std);
DEF_MMIO_IN_D(in_be64, 64, ld);

/* There is no asm instructions for 64 bits reverse loads and stores */
static inline u64 in_le64(const volatile u64 __iomem *addr)
{
return swab64(in_be64(addr));
}

static inline void out_le64(volatile u64 __iomem *addr, u64 val)
{
out_be64(addr, swab64(val));
}
#else
DEF_MMIO_OUT_D(out_le64, 64, std);
DEF_MMIO_IN_D(in_le64, 64, ld);

/* There is no asm instructions for 64 bits reverse loads and stores */
static inline u64 in_be64(const volatile u64 __iomem *addr)
{
return swab64(in_le64(addr));
}

static inline void out_be64(volatile u64 __iomem *addr, u64 val)
{
out_le64(addr, swab64(val));
}

#endif
#endif /* __powerpc64__ */

Best Regards,
Peng
>-Original Message-
>From: Scott Wood 
>Sent: 2018年12月24日 12:46
>To: Peng Ma ; Leo Li ; Zhang Wei
>
>Cc: linuxppc-dev@lists.ozlabs.org; dmaeng...@vger.kernel.org; Wen He
>
>Subject: Re: [PATCH] dmaengine: fsldma: Add 64-bit I/O accessors for
>powerpc64
>
>On Mon, 2018-12-24 at 03:42 +, Peng Ma wrote:
>> Hi Scott,
>>
>> You are right, we should support powerpc64, so could I changed it as
>> fallows:
>>
>> diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h index
>> 88db939..057babf 100644
>> --- a/drivers/dma/fsldma.h
>> +++ b/drivers/dma/fsldma.h
>> @@ -202,35 +202,10 @@ struct fsldma_chan {
>>  #define fsl_iowrite32(v, p)out_le32(p, v)
>>  #define fsl_iowrite32be(v, p)  out_be32(p, v)
>>
>> -#ifndef __powerpc64__
>> -static u64 fsl_ioread64(const u64 __iomem *addr) -{
>> -   u32 fsl_addr = lower_32_bits(addr);
>> -   u64 fsl_addr_hi = (u64)in_le32((u32 *)(fsl_addr + 1)) << 32;
>> -
>> -   return fsl_addr_hi | in_le32((u32 *)fsl_addr);
>> -}
>> -
>> -static void fsl_iowrite64(u64 val, u64 __iomem *addr) -{
>> -   out_le32((u32 __iomem *)addr + 1, val >> 32);
>> -   out_le32((u32 __iomem *)addr, (u32)val);
>> -}
>> -
>> -static u64 fsl_ioread64be(const u64 __iomem *addr) -{
>> -   u32 fsl_addr = lower_32_bits(addr);
>> -   u64 fsl_addr_hi = (u64)in_be32((u32 *)fsl_addr) << 32;
>> -
>> -   return fsl_addr_hi | in_be32((u32 *)(fsl_addr + 1));
>> -}
>> -
>> -static void fsl_iowrite64be(u64 val, u64 __iomem *addr) -{
>> -   out_be32((u32 __iomem *)addr, val >> 32);
>> -   out_be32((u32 __iomem *)addr + 1, (u32)val);
>> -}
>> -#endif
>> +#define fsl_ioread64(p)in_le64(p)
>> +#define fsl_ioread64be(p)  in_be64(p)
>> +#define fsl_iowrite64(v, p)out_le64(p, v)
>> +#define fsl_iowrite64be(v, p)  out_be64(p, v)
>>  #endif
>
>Then you'll break 32-bit, assuming those fake-it-with-two-32-bit-accesses
>were actually needed.
>
>-Scott
>



Re: [v6,1/5] powerpc: add __NR_syscalls along with NR_syscalls

2018-12-23 Thread Firoz Khan
On Sun, 23 Dec 2018 at 18:58, Michael Ellerman
 wrote:
>
> On Mon, 2018-12-17 at 10:40:32 UTC, Firoz Khan wrote:
> > NR_syscalls macro holds the number of system call exist
> > in powerpc architecture. We have to change the value of
> > NR_syscalls, if we add or delete a system call.
> >
> > One of the patch in this patch series has a script which
> > will generate a uapi header based on syscall.tbl file.
> > The syscall.tbl file contains the number of system call
> > information. So we have two option to update NR_syscalls
> > value.
> >
> > 1. Update NR_syscalls in asm/unistd.h manually by count-
> >ing the no.of system calls. No need to update NR_sys-
> >calls until we either add a new system call or delete
> >existing system call.
> >
> > 2. We can keep this feature in above mentioned script,
> >that will count the number of syscalls and keep it in
> >a generated file. In this case we don't need to expli-
> >citly update NR_syscalls in asm/unistd.h file.
> >
> > The 2nd option will be the recommended one. For that, I
> > added the __NR_syscalls macro in uapi/asm/unistd.h along
> > with NR_syscalls asm/unistd.h. The macro __NR_syscalls
> > also added for making the name convention same across all
> > architecture. While __NR_syscalls isn't strictly part of
> > the uapi, having it as part of the generated header to
> > simplifies the implementation. We also need to enclose
> > this macro with #ifdef __KERNEL__ to avoid side effects.
> >
> > Signed-off-by: Firoz Khan 
>
> Series applied to powerpc next, thanks.

Thanks Micheal!

Firoz

>
> https://git.kernel.org/powerpc/c/8a19eeeab66dfdd7c67bc8e3048ac0
>
> cheers


linux-next: manual merge of the iommu tree with the powerpc tree

2018-12-23 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the iommu tree got a conflict in:

  arch/powerpc/kernel/iommu.c

between commit:

  c4e9d3c1e65a ("powerpc/powernv/pseries: Rework device adding to IOMMU groups")

from the powerpc tree and commit:

  bf8763d8f837 ("powerpc/iommu: Use device_iommu_mapped()")

from the iommu tree.

I fixed it up (I just used the powerpc tree version which removed the
code modified by the latter) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your
tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpbieIvkvp5X.pgp
Description: OpenPGP digital signature


Re: [PATCH] dmaengine: fsldma: Add 64-bit I/O accessors for powerpc64

2018-12-23 Thread Scott Wood
On Mon, 2018-12-24 at 03:42 +, Peng Ma wrote:
> Hi Scott,
> 
> You are right, we should support powerpc64, so could I changed it as
> fallows:
> 
> diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
> index 88db939..057babf 100644
> --- a/drivers/dma/fsldma.h
> +++ b/drivers/dma/fsldma.h
> @@ -202,35 +202,10 @@ struct fsldma_chan {
>  #define fsl_iowrite32(v, p)out_le32(p, v)
>  #define fsl_iowrite32be(v, p)  out_be32(p, v)
>  
> -#ifndef __powerpc64__
> -static u64 fsl_ioread64(const u64 __iomem *addr)
> -{
> -   u32 fsl_addr = lower_32_bits(addr);
> -   u64 fsl_addr_hi = (u64)in_le32((u32 *)(fsl_addr + 1)) << 32;
> -
> -   return fsl_addr_hi | in_le32((u32 *)fsl_addr);
> -}
> -
> -static void fsl_iowrite64(u64 val, u64 __iomem *addr)
> -{
> -   out_le32((u32 __iomem *)addr + 1, val >> 32);
> -   out_le32((u32 __iomem *)addr, (u32)val);
> -}
> -
> -static u64 fsl_ioread64be(const u64 __iomem *addr)
> -{
> -   u32 fsl_addr = lower_32_bits(addr);
> -   u64 fsl_addr_hi = (u64)in_be32((u32 *)fsl_addr) << 32;
> -
> -   return fsl_addr_hi | in_be32((u32 *)(fsl_addr + 1));
> -}
> -
> -static void fsl_iowrite64be(u64 val, u64 __iomem *addr)
> -{
> -   out_be32((u32 __iomem *)addr, val >> 32);
> -   out_be32((u32 __iomem *)addr + 1, (u32)val);
> -}
> -#endif
> +#define fsl_ioread64(p)in_le64(p)
> +#define fsl_ioread64be(p)  in_be64(p)
> +#define fsl_iowrite64(v, p)out_le64(p, v)
> +#define fsl_iowrite64be(v, p)  out_be64(p, v)
>  #endif

Then you'll break 32-bit, assuming those fake-it-with-two-32-bit-accesses were
actually needed.

-Scott




RE: [PATCH] dmaengine: fsldma: Add 64-bit I/O accessors for powerpc64

2018-12-23 Thread Peng Ma
Hi Scott,

You are right, we should support powerpc64, so could I changed it as fallows:

diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index 88db939..057babf 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -202,35 +202,10 @@ struct fsldma_chan {
 #define fsl_iowrite32(v, p)out_le32(p, v)
 #define fsl_iowrite32be(v, p)  out_be32(p, v)
 
-#ifndef __powerpc64__
-static u64 fsl_ioread64(const u64 __iomem *addr)
-{
-   u32 fsl_addr = lower_32_bits(addr);
-   u64 fsl_addr_hi = (u64)in_le32((u32 *)(fsl_addr + 1)) << 32;
-
-   return fsl_addr_hi | in_le32((u32 *)fsl_addr);
-}
-
-static void fsl_iowrite64(u64 val, u64 __iomem *addr)
-{
-   out_le32((u32 __iomem *)addr + 1, val >> 32);
-   out_le32((u32 __iomem *)addr, (u32)val);
-}
-
-static u64 fsl_ioread64be(const u64 __iomem *addr)
-{
-   u32 fsl_addr = lower_32_bits(addr);
-   u64 fsl_addr_hi = (u64)in_be32((u32 *)fsl_addr) << 32;
-
-   return fsl_addr_hi | in_be32((u32 *)(fsl_addr + 1));
-}
-
-static void fsl_iowrite64be(u64 val, u64 __iomem *addr)
-{
-   out_be32((u32 __iomem *)addr, val >> 32);
-   out_be32((u32 __iomem *)addr + 1, (u32)val);
-}
-#endif
+#define fsl_ioread64(p)in_le64(p)
+#define fsl_ioread64be(p)  in_be64(p)
+#define fsl_iowrite64(v, p)out_le64(p, v)
+#define fsl_iowrite64be(v, p)  out_be64(p, v)
 #endif

Best Regards,
Peng
>-Original Message-
>From: Scott Wood 
>Sent: 2018年12月22日 12:35
>To: Leo Li ; Zhang Wei 
>Cc: linuxppc-dev@lists.ozlabs.org; dmaeng...@vger.kernel.org; Peng Ma
>; Wen He 
>Subject: [PATCH] dmaengine: fsldma: Add 64-bit I/O accessors for powerpc64
>
>Otherwise 64-bit PPC builds fail with undefined references to these accessors.
>
>Cc: Peng Ma 
>Cc: Wen He 
>Fixes: 68997fff94afa (" dmaengine: fsldma: Adding macro FSL_DMA_IN/OUT
>implement for ARM platform")
>Signed-off-by: Scott Wood 
>---
>Is there any reason why ioreadXXbe() etc can't be used on PPC as well?
>
> drivers/dma/fsldma.h | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h index
>88db939c04a1..a9b12f82b5c3 100644
>--- a/drivers/dma/fsldma.h
>+++ b/drivers/dma/fsldma.h
>@@ -202,7 +202,12 @@ struct fsldma_chan {
> #define fsl_iowrite32(v, p)   out_le32(p, v)
> #define fsl_iowrite32be(v, p) out_be32(p, v)
>
>-#ifndef __powerpc64__
>+#ifdef __powerpc64__
>+#define fsl_ioread64(p)   in_le64(p)
>+#define fsl_ioread64be(p) in_be64(p)
>+#define fsl_iowrite64(v, p)   out_le64(p, v)
>+#define fsl_iowrite64be(v, p) out_be64(p, v)
>+#else
> static u64 fsl_ioread64(const u64 __iomem *addr)  {
>   u32 fsl_addr = lower_32_bits(addr);
>--
>2.17.1


Pull request v2: scottwood/linux.git next

2018-12-23 Thread Scott Wood
Highlights include elimination of legacy clock bindings use from dts
files, an 83xx watchdog handler, fixes to old dts interrupt errors, and
some minor cleanup.

v2: Reverted the fsl_pci_dma_set_mask patch

The following changes since commit 8c6c942d33f2a79439e86f8f406afae40a5bc767:

  powerpc/eeh: Fix debugfs_simple_attr.cocci warnings (2018-12-20 22:59:03 
+1100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next

for you to fetch changes up to 63d86876f32440a45b6f9d42ab2fb7f68b3a8bf7:

  Revert "powerpc/fsl_pci: simplify fsl_pci_dma_set_mask" (2018-12-23 20:11:20 
-0600)


Alexandre Belloni (1):
  powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"

Christoph Hellwig (1):
  powerpc/fsl_pci: simplify fsl_pci_dma_set_mask

Christophe Leroy (1):
  powerpc/83xx: handle machine check caused by watchdog timer

Sabyasachi Gupta (1):
  arch/powerpc/fsl_rmu: Use dma_zalloc_coherent

Scott Wood (4):
  powerpc/fsl: Use new clockgen binding
  powerpc/dts/fsl: Fix dtc-flagged interrupt errors
  powerpc/configs/85xx: Enable CONFIG_DEBUG_KERNEL
  Revert "powerpc/fsl_pci: simplify fsl_pci_dma_set_mask"

Yuantian Tang (1):
  clk: qoriq: add more compatibles strings

 .../devicetree/bindings/clock/qoriq-clock.txt  |   6 +
 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi |   4 +-
 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi |   8 +-
 arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |  15 ---
 arch/powerpc/boot/dts/fsl/mpc8641_hpcn.dts | 128 ++---
 arch/powerpc/boot/dts/fsl/mpc8641_hpcn_36b.dts | 128 ++---
 arch/powerpc/boot/dts/fsl/mpc8641si-post.dtsi  |   2 +
 arch/powerpc/boot/dts/fsl/p1020rdb-pc.dtsi |   4 +-
 arch/powerpc/boot/dts/fsl/p2041si-post.dtsi|  18 ---
 arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi |   8 +-
 arch/powerpc/boot/dts/fsl/p3041si-post.dtsi|  18 ---
 arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi |   8 +-
 arch/powerpc/boot/dts/fsl/p4080si-post.dtsi|  70 ---
 arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi |  16 +--
 arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi |   4 +-
 arch/powerpc/boot/dts/fsl/p5040si-post.dtsi|  18 ---
 arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi |   8 +-
 arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi |  47 
 arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi |  30 -
 arch/powerpc/boot/dts/fsl/t1023si-post.dtsi|  16 ---
 arch/powerpc/boot/dts/fsl/t102xsi-pre.dtsi |   4 +-
 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi|  44 ---
 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi |   8 +-
 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi|  22 
 arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi |   8 +-
 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|  61 --
 arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi |  24 ++--
 arch/powerpc/boot/dts/mpc832x_rdb.dts  |   4 -
 arch/powerpc/configs/fsl-emb-nonhw.config  |   1 +
 arch/powerpc/include/asm/cputable.h|   1 +
 arch/powerpc/include/asm/reg.h |   2 +
 arch/powerpc/kernel/cputable.c |  10 +-
 arch/powerpc/platforms/83xx/misc.c |  17 +++
 arch/powerpc/sysdev/fsl_rio.h  |   2 +-
 arch/powerpc/sysdev/fsl_rmu.c  |   4 +-
 35 files changed, 217 insertions(+), 551 deletions(-)


Re: Pull request: scottwood/linux.git next

2018-12-23 Thread Scott Wood
On Mon, 2018-12-24 at 00:13 +1100, Michael Ellerman wrote:
> Hi Scott,
> 
> Scott Wood  writes:
> > Highlights include elimination of legacy clock bindings use from dts
> > files, an 83xx watchdog handler, fixes to old dts interrupt errors, and
> > some minor cleanup.
> > 
> > The following changes since commit
> > 8c6c942d33f2a79439e86f8f406afae40a5bc767:
> > 
> >   powerpc/eeh: Fix debugfs_simple_attr.cocci warnings (2018-12-20 22:59:03
> > +1100)
> > 
> > are available in the Git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
> > 
> > for you to fetch changes up to 5f470b3638a4ed03df79b993ece819cac2f4ca7e:
> > 
> >   powerpc/configs/85xx: Enable CONFIG_DEBUG_KERNEL (2018-12-21 22:07:54
> > -0600)
> > 
> > 
> > Alexandre Belloni (1):
> >   powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"
> > 
> > Christoph Hellwig (1):
> >   powerpc/fsl_pci: simplify fsl_pci_dma_set_mask
> 
> This one breaks networking on my p5020ds.
> 
> dmesg is just full of:
> 
>   e1000e 2000:01:00.0: Tx DMA map failed
> 
> Haven't had time to dig any further.

OK, I'll revert.  My t4240rdb doesn't have PCI devices, so I wasn't able to
test it.

-Scott




[PATCH] powerpc/fsl: Fixed warning: orphan section `__btb_flush_fixup'

2018-12-23 Thread Diana Craciun
Fixed the following build warning:
powerpc-linux-gnu-ld: warning: orphan section `__btb_flush_fixup' from
`arch/powerpc/kernel/head_44x.o' being placed in section
`__btb_flush_fixup'.

Signed-off-by: Diana Craciun 
---
 arch/powerpc/kernel/head_booke.h | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index 15ac510..306e26c 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -32,6 +32,16 @@
  */
 #define THREAD_NORMSAVE(offset)(THREAD_NORMSAVES + (offset * 4))
 
+#ifdef CONFIG_PPC_FSL_BOOK3E
+#define BOOKE_CLEAR_BTB(reg)   
\
+START_BTB_FLUSH_SECTION
\
+   BTB_FLUSH(reg)  
\
+END_BTB_FLUSH_SECTION
+#else
+#define BOOKE_CLEAR_BTB(reg)
+#endif
+
+
 #define NORMAL_EXCEPTION_PROLOG(intno) 
 \
mtspr   SPRN_SPRG_WSCRATCH0, r10;   /* save one register */  \
mfspr   r10, SPRN_SPRG_THREAD;   \
@@ -43,9 +53,7 @@
andi.   r11, r11, MSR_PR;   /* check whether user or kernel*/\
mr  r11, r1; \
beq 1f;  \
-START_BTB_FLUSH_SECTION\
-   BTB_FLUSH(r11)  \
-END_BTB_FLUSH_SECTION  \
+   BOOKE_CLEAR_BTB(r11)\
/* if from user, start at top of this thread's kernel stack */   \
lwz r11, THREAD_INFO-THREAD(r10);\
ALLOC_STACK_FRAME(r11, THREAD_SIZE); \
@@ -131,9 +139,7 @@ END_BTB_FLUSH_SECTION   
\
stw r9,_CCR(r8);/* save CR on stack*/\
mfspr   r11,exc_level_srr1; /* check whether user or kernel*/\
DO_KVM  BOOKE_INTERRUPT_##intno exc_level_srr1;  \
-START_BTB_FLUSH_SECTION
\
-   BTB_FLUSH(r10)  
\
-END_BTB_FLUSH_SECTION  
\
+   BOOKE_CLEAR_BTB(r10)\
andi.   r11,r11,MSR_PR;  \
mfspr   r11,SPRN_SPRG_THREAD;   /* if from user, start at top of   */\
lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
-- 
2.5.5



Re: [kernel] powerpc/powernv/eeh/npu: Fix uninitialized variables in opal_pci_eeh_freeze_status

2018-12-23 Thread Michael Ellerman
On Mon, 2018-11-19 at 04:25:17 UTC, Alexey Kardashevskiy wrote:
> The current implementation of the OPAL_PCI_EEH_FREEZE_STATUS call in
> skiboot's NPU driver does not touch the pci_error_type parameter so
> it might have garbage but the powernv code analyzes it nevertheless.
> 
> This initializes pcierr and fstate to zero in all call sites.
> 
> Signed-off-by: Alexey Kardashevskiy 
> Reviewed-by: Sam Bobroff 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/c20577014f85f36d4e137d3d52a1f6

cheers


Re: powerpc/powernv: Remove PCI_MSI ifdef checks

2018-12-23 Thread Michael Ellerman
On Wed, 2018-11-14 at 06:19:58 UTC, Oliver O'Halloran wrote:
> 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 
> Reviewed-by: Joel Stanley 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/5f639e5fad18f2673f1788cb04bde2

cheers


Re: [kernel] powerpc/powernv/ioda: Reduce a number of hooks in pnv_phb

2018-12-23 Thread Michael Ellerman
On Tue, 2018-10-16 at 02:34:09 UTC, Alexey Kardashevskiy wrote:
> fixup_phb() is never used, this removes it.
> 
> pick_m64_pe() and reserve_m64_pe() are always defined for all powernv
> PHBs: they are initialized by pnv_ioda_parse_m64_window() which is
> called unconditionally from pnv_pci_init_ioda_phb() which initializes
> all known PHB types on powernv so we can open code them.
> 
> Signed-off-by: Alexey Kardashevskiy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a25de7af340fcd19a59978ded2ff04

cheers


Re: [kernel] powerpc/powernv/ioda1: Remove dead code for a single device PE

2018-12-23 Thread Michael Ellerman
On Tue, 2018-10-16 at 02:30:03 UTC, Alexey Kardashevskiy wrote:
> At the moment PNV_IODA_PE_DEV is only used for NPU PEs which are not
> present on IODA1 machines (i.e. POWER7) so let's remove a piece of
> dead code.
> 
> Signed-off-by: Alexey Kardashevskiy 
> Reviewed-by: Sam Bobroff 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/f21b0a45e4e48eafca38f11612244c

cheers


Re: powerpc: Fix HMIs on big-endian with CONFIG_RELOCATABLE=y

2018-12-23 Thread Michael Ellerman
On Mon, 2018-10-08 at 04:08:31 UTC, Benjamin Herrenschmidt wrote:
> HMIs will crash the kernel due to
> 
>   BRANCH_LINK_TO_FAR(hmi_exception_realmode)
> 
> Calling into the OPD instead of the actual code.
> 
> Signed-off-by: Benjamin Herrenschmidt 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/505a314fb28ce122091691c51426fa

cheers


Re: [RFC,kernel] vfio/spapr_tce: Get rid of possible infinite loop

2018-12-23 Thread Michael Ellerman
On Tue, 2018-10-02 at 03:22:31 UTC, Alexey Kardashevskiy wrote:
> As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered
> memory. If there is a bug in memory release, the loop in
> tce_iommu_release() becomes infinite; this actually happened to me.
> 
> This makes the loop finite and prints a warning on every failure to make
> the code more bug prone.
> 
> Signed-off-by: Alexey Kardashevskiy 
> Reviewed-by: David Gibson 
> Acked-by: Alex Williamson 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/517ad4ae8aa93dccdb9a88c27257ec

cheers


Re: [kernel] powerpc/powernv/npu: Remove unused headers and a macro.

2018-12-23 Thread Michael Ellerman
On Fri, 2018-09-28 at 06:48:25 UTC, Alexey Kardashevskiy wrote:
> The macro and few headers are not used so remove them.
> 
> Signed-off-by: Alexey Kardashevskiy 
> Acked-by: Alistair Popple 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/fa1ada78897f282917594ba8eba220

cheers


Re: [kernel] powerpc/powernv/ioda: Allocate indirect TCE levels of cached userspace addresses on demand

2018-12-23 Thread Michael Ellerman
On Fri, 2018-09-28 at 06:45:39 UTC, Alexey Kardashevskiy wrote:
> The powernv platform maintains 2 TCE tables for VFIO - a hardware TCE
> table and a table with userspace addresses; the latter is used for
> marking pages dirty when corresponging TCEs are unmapped from
> the hardware table.
> 
> a68bd1267b72 ("powerpc/powernv/ioda: Allocate indirect TCE levels
> on demand") enabled on-demand allocation of the hardware table,
> however it missed the other table so it has still been fully allocated
> at the boot time. This fixes the issue by allocating a single level,
> just like we do for the hardware table.
> 
> Fixes: a68bd1267b72 ("powerpc/powernv/ioda: Allocate indirect TCE levels on 
> demand")
> Signed-off-by: Alexey Kardashevskiy 
> Reviewed-by: David Gibson 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/bdbf649efe21173cae63b4b71db841

cheers


Re: [v7,1/3] powerpc/fadump: Reservationless firmware assisted dump

2018-12-23 Thread Michael Ellerman
On Mon, 2018-08-20 at 08:17:17 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar 
> 
> One of the primary issues with Firmware Assisted Dump (fadump) on Power
> is that it needs a large amount of memory to be reserved. On large
> systems with TeraBytes of memory, this reservation can be quite
> significant.
> 
> In some cases, fadump fails if the memory reserved is insufficient, or
> if the reserved memory was DLPAR hot-removed.
> 
> In the normal case, post reboot, the preserved memory is filtered to
> extract only relevant areas of interest using the makedumpfile tool.
> While the tool provides flexibility to determine what needs to be part
> of the dump and what memory to filter out, all supported distributions
> default this to "Capture only kernel data and nothing else".
> 
> We take advantage of this default and the Linux kernel's Contiguous
> Memory Allocator (CMA) to fundamentally change the memory reservation
> model for fadump.
> 
> Instead of setting aside a significant chunk of memory nobody can use,
> this patch uses CMA instead, to reserve a significant chunk of memory
> that the kernel is prevented from using (due to MIGRATE_CMA), but
> applications are free to use it. With this fadump will still be able
> to capture all of the kernel memory and most of the user space memory
> except the user pages that were present in CMA region.
> 
> Essentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream:
> [root@zzxx-yy10 ~]# free -m
>   totalusedfree  shared  buff/cache   
> available
> Mem:   7557 1936822  12 541
> 6725
> Swap:  4095   04095
> 
> With this patch:
> [root@zzxx-yy10 ~]# free -m
>   totalusedfree  shared  buff/cache   
> available
> Mem:   8133 1947464  12 475
> 7338
> Swap:  4095   04095
> 
> Changes made here are completely transparent to how fadump has
> traditionally worked.
> 
> Thanks to Aneesh Kumar and Anshuman Khandual for helping us understand
> CMA and its usage.
> 
> TODO:
> - Handle case where CMA reservation spans nodes.
> 
> Signed-off-by: Ananth N Mavinakayanahalli 
> Signed-off-by: Mahesh Salgaonkar 
> Signed-off-by: Hari Bathini 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a4e92ce8e4c8275bacfe3529d6ac85

cheers


Re: [5/5] powerpc/zImage: Also check for stdout-path

2018-12-23 Thread Michael Ellerman
On Mon, 2018-03-19 at 05:14:03 UTC, Oliver O'Halloran wrote:
> The /chosen/linux,stdout-path is "deprecated" in favour of
> /chosen/stdout-path so we should be checking for both.
> 
> Signed-off-by: Oliver O'Halloran 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/9bbc7e4ce47ecefa142fcba55eef77

cheers


Re: [5/5] powerpc/4xx: Delete an unnecessary return statement in two functions

2018-12-23 Thread Michael Ellerman
On Thu, 2018-01-11 at 18:04:54 UTC, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 11 Jan 2018 18:40:23 +0100
> 
> The script "checkpatch.pl" pointed information out like the following.
> 
> WARNING: void function return statements are not generally useful
> 
> Thus remove such a statement in the affected functions.
> 
> Signed-off-by: Markus Elfring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/ae6263cc33742d1c179510b6aadd31

cheers


Re: [3/5] powerpc/4xx: Delete an error message for a failed memory allocation in three functions

2018-12-23 Thread Michael Ellerman
On Thu, 2018-01-11 at 18:02:45 UTC, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 11 Jan 2018 18:28:54 +0100
> 
> Omit an extra message for a memory allocation failure in these functions.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a8d5dadae59f5866ac3b68cb993d53

cheers


Re: [1/5] powerpc/4xx: Combine four seq_printf() calls into two in ocm_debugfs_show()

2018-12-23 Thread Michael Ellerman
On Thu, 2018-01-11 at 18:00:33 UTC, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 11 Jan 2018 18:08:08 +0100
> 
> Some data were printed into a sequence by four separate function calls.
> Print the same data by two single function calls instead.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/b52106a040e6f86848b05be1b43174

cheers


Re: [2/5] powerpc/4xx: Use seq_putc() in ocm_debugfs_show()

2018-12-23 Thread Michael Ellerman
On Thu, 2018-01-11 at 18:01:33 UTC, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 11 Jan 2018 18:10:02 +0100
> 
> A single character (line break) should be put into a sequence.
> Thus use the corresponding function "seq_putc".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/52930bc6e87191af3894bec302774f

cheers


Re: [v2] powerpc/pkeys: copy pkey-tracking-information at fork()

2018-12-23 Thread Michael Ellerman
On Thu, 2018-12-20 at 20:03:30 UTC, Ram Pai wrote:
> Pkey tracking information is not copied over to the mm_struct of the
> child during fork(). This can cause the child to erroneously allocate
> keys that were already allocated. Any allocated execute-only key is lost
> aswell.
> 
> Add code; called by dup_mmap(), to copy the pkey state from parent to
> child explicitly.
> 
> This problem was originally found by Dave Hansen on x86, which turns out
> to be a problem on powerpc aswell.
> 
> Reviewed-by: Thiago Jung Bauermann 
> Signed-off-by: Ram Pai 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/2cd4bd192ee94848695c1c052d8791

cheers


Re: powerpc/8xx: Allow pinning IMMR TLB when using early debug console

2018-12-23 Thread Michael Ellerman
On Thu, 2018-12-20 at 07:25:28 UTC, Christophe Leroy wrote:
> CONFIG_EARLY_DEBUG_CPM requires IMMR area TLB to be pinned
> otherwise it doesn't survive MMU_init, and the boot fails.
> 
> Signed-off-by: Christophe Leroy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/96d19d70e1012383365c68e271d99f

cheers


Re: [kernel, v6, 01/20] powerpc/ioda/npu: Call skiboot's hot reset hook when disabling NPU2

2018-12-23 Thread Michael Ellerman
On Wed, 2018-12-19 at 08:52:13 UTC, Alexey Kardashevskiy wrote:
> The skiboot firmware has a hot reset handler which fences the NVIDIA V100
> GPU RAM on Witherspoons and makes accesses no-op instead of throwing HMIs:
> https://github.com/open-power/skiboot/commit/fca2b2b839a67
> 
> Now we are going to pass V100 via VFIO which most certainly involves
> KVM guests which are often terminated without getting a chance to offline
> GPU RAM so we end up with a running machine with misconfigured memory.
> Accessing this memory produces hardware management interrupts (HMI)
> which bring the host down.
> 
> To suppress HMIs, this wires up this hot reset hook to vfio_pci_disable()
> via pci_disable_device() which switches NPU2 to a safe mode and prevents
> HMIs.
> 
> Signed-off-by: Alexey Kardashevskiy 
> Acked-by: Alistair Popple 
> Reviewed-by: David Gibson 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/ab7032e793f9ad799ca2692046fba5

cheers


Re: [v6,1/5] powerpc: add __NR_syscalls along with NR_syscalls

2018-12-23 Thread Michael Ellerman
On Mon, 2018-12-17 at 10:40:32 UTC, Firoz Khan wrote:
> NR_syscalls macro holds the number of system call exist
> in powerpc architecture. We have to change the value of
> NR_syscalls, if we add or delete a system call.
> 
> One of the patch in this patch series has a script which
> will generate a uapi header based on syscall.tbl file.
> The syscall.tbl file contains the number of system call
> information. So we have two option to update NR_syscalls
> value.
> 
> 1. Update NR_syscalls in asm/unistd.h manually by count-
>ing the no.of system calls. No need to update NR_sys-
>calls until we either add a new system call or delete
>existing system call.
> 
> 2. We can keep this feature in above mentioned script,
>that will count the number of syscalls and keep it in
>a generated file. In this case we don't need to expli-
>citly update NR_syscalls in asm/unistd.h file.
> 
> The 2nd option will be the recommended one. For that, I
> added the __NR_syscalls macro in uapi/asm/unistd.h along
> with NR_syscalls asm/unistd.h. The macro __NR_syscalls
> also added for making the name convention same across all
> architecture. While __NR_syscalls isn't strictly part of
> the uapi, having it as part of the generated header to
> simplifies the implementation. We also need to enclose
> this macro with #ifdef __KERNEL__ to avoid side effects.
> 
> Signed-off-by: Firoz Khan 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/8a19eeeab66dfdd7c67bc8e3048ac0

cheers


Re: powerpc/powernv: Move opal_power_control_init() call in opal_init().

2018-12-23 Thread Michael Ellerman
On Thu, 2018-12-13 at 05:47:31 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar 
> 
> opal_power_control_init() depends on opal message notifier to be
> initialized, which is done in opal_init()->opal_message_init(). But both
> these initialization are called through machine initcalls and it all
> depends on in which order they being called. So far these are called in
> correct order (may be we got lucky) and never saw any issue. But it is
> clearer to control initialization order explicitly by moving
> opal_power_control_init() into opal_init().
> 
> Signed-off-by: Mahesh Salgaonkar 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/08fb726df13778a54592aaa1deea6a

cheers


Re: [v2] ocxl: Fix endiannes bug in read_afu_name()

2018-12-23 Thread Michael Ellerman
On Tue, 2018-12-11 at 17:58:21 UTC, Greg Kurz wrote:
> The AFU Descriptor Template in the PCI config space has a Name Space
> field which is a 24 Byte ASCII character string of descriptive name
> space for the AFU. The OCXL driver read the string four characters at
> a time with pci_read_config_dword().
> 
> This optimization is valid on a little-endian system since this is PCI,
> but a big-endian system ends up with each subset of four characters in
> reverse order.
> 
> This could be fixed by switching to read characters one by one. Another
> option is to swap the bytes if we're big-endian.
> 
> Go for the latter with le32_to_cpu().
> 
> Cc: sta...@vger.kernel.org  # v4.16
> Signed-off-by: Greg Kurz 
> Acked-by: Frederic Barrat 
> Acked-by: Andrew Donnellan 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/2f07229f02d4c55affccd11a61af4f

cheers


Re: macintosh: Use of_node_name_{eq, prefix} for node name comparisons

2018-12-23 Thread Michael Ellerman
On Wed, 2018-12-05 at 19:50:28 UTC, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_{eq,prefix}
> helpers instead. This removes direct access to the node name pointer.
> 
> This changes a single case insensitive node name comparison to case
> sensitive for "ata4". This is the only instance of a case insensitive
> comparison for all the open coded node name comparisons on powerpc.
> Searching the commit history, there doesn't appear to be any reason for
> it to be case insensitive.
> 
> A couple of open coded iterating thru the child node names are converted
> to use for_each_child_of_node() instead.
> 
> Cc: Benjamin Herrenschmidt 
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/f1e0addca8bd7386f8cabbc64c9988

cheers


Re: ide: Use of_node_name_eq for node name comparisons

2018-12-23 Thread Michael Ellerman
On Wed, 2018-12-05 at 19:50:25 UTC, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
> 
> Cc: "David S. Miller" 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linux-...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/c1fa31b0fc90a80d64a334e5d35dca

cheers


Re: powerpc: Use of_node_name_eq for node name comparisons

2018-12-23 Thread Michael Ellerman
On Wed, 2018-12-05 at 19:50:18 UTC, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
> 
> A couple of open coded iterating thru the child node names are converted
> to use for_each_child_of_node() instead.
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Alistair Popple 
> Cc: Matt Porter 
> Cc: Anatolij Gustschin 
> Cc: Arnd Bergmann 
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/2c8e65b595cf0bf7c1413404dff9b9

cheers


Re: powerpc: pseries: pmem: Convert to using %pOFn instead of device_node.name

2018-12-23 Thread Michael Ellerman
On Wed, 2018-12-05 at 19:50:17 UTC, Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier. pmem.c was
> recently added and missed the initial conversion.
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/0d1223dd9273b2ba3e965a81092a23

cheers


Re: [v2, 01/11] powerpc/mm: Fix reporting of kernel execute faults on the 8xx

2018-12-23 Thread Michael Ellerman
On Wed, 2018-11-28 at 09:27:04 UTC, Christophe Leroy wrote:
> On the 8xx, no-execute is set via PPP bits in the PTE. Therefore
> a no-exec fault generates DSISR_PROTFAULT error bits,
> not DSISR_NOEXEC_OR_G.
> 
> This patch adds DSISR_PROTFAULT in the test mask.
> 
> Fixes: d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults")
> Signed-off-by: Christophe Leroy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/ffca395b11c4a5a6df6d6345f794b0

cheers


Re: powerpc/mm: Remove very old comment in hash-4k.h

2018-12-23 Thread Michael Ellerman
On Tue, 2018-11-27 at 08:18:05 UTC, Michael Ellerman wrote:
> This comment talks about PTEs being 64-bits and PMD/PGD being 32-bits,
> but that hasn't been true since 2005 when David Gibson implemented
> 4-level page tables in the commit titled "Four level pagetables for
> ppc64".
> 
> Remove it.
> 
> Signed-off-by: Michael Ellerman 

Applied to powerpc next.

https://git.kernel.org/powerpc/c/423e2f94456404b49d89ef587c3402

cheers


Re: powerpc/pseries: Fix node leak in update_lmb_associativity_index()

2018-12-23 Thread Michael Ellerman
On Tue, 2018-11-27 at 08:16:44 UTC, Michael Ellerman wrote:
> In update_lmb_associativity_index() we lookup dr_node using
> of_find_node_by_path() which takes a reference for us. In the
> non-error case we forget to drop the reference. Note that
> find_aa_index() does modify properties of the node, but doesn't need
> an extra reference held once it's returned.
> 
> Signed-off-by: Michael Ellerman 

Applied to powerpc next.

https://git.kernel.org/powerpc/c/47918bc68b7427e961035949cc1501

cheers


Re: [1/4] powerpc/tm: Save MSR to PACA before RFID

2018-12-23 Thread Michael Ellerman
On Mon, 2018-11-26 at 20:11:58 UTC, Breno Leitao wrote:
> As other exit points, move SRR1 (MSR) into paca->tm_scratch, so, if
> there is a TM Bad Thing in RFID, it is easy to understand what was the
> SRR1 value being used.
> 
> Signed-off-by: Breno Leitao 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/63a0d6b03b8e6fdd8c8ce5eec0ac04

cheers


Re: [v2] powerpc/tm: Set MSR[TS] just prior to recheckpoint

2018-12-23 Thread Michael Ellerman
On Wed, 2018-11-21 at 19:21:09 UTC, Breno Leitao wrote:
> On a signal handler return, the user could set a context with MSR[TS] bits
> set, and these bits would be copied to task regs->msr.
> 
> At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set,
> several __get_user() are called and then a recheckpoint is executed.
> 
> This is a problem since a page fault (in kernel space) could happen when
> calling __get_user(). If it happens, the process MSR[TS] bits were
> already set, but recheckpoint was not executed, and SPRs are still invalid.
> 
> The page fault can cause the current process to be de-scheduled, with
> MSR[TS] active and without tm_recheckpoint() being called.  More
> importantly, without TEXASR[FS] bit set also.
> 
> Since TEXASR might not have the FS bit set, and when the process is
> scheduled back, it will try to reclaim, which will be aborted because of
> the CPU is not in the suspended state, and, then, recheckpoint. This
> recheckpoint will restore thread->texasr into TEXASR SPR, which might be
> zero, hitting a BUG_ON().
> 
>   kernel BUG at 
> /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
>   cpu 0xb: Vector: 700 (Program Check) at [c0041f1576d0]
>   pc: c0054550: restore_gprs+0xb0/0x180
>   lr: 
>   sp: c0041f157950
>  msr: 800100021033
> current = 0xc0041f143000
> paca= 0xcfb86300   softe: 0irq_happened: 0x01
>   pid   = 1021, comm = kworker/11:1
>   kernel BUG at 
> /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
>   Linux version 4.9.0-3-powerpc64le (debian-ker...@lists.debian.org) (gcc 
> version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 
> (2017-06-26)
>   enter ? for help
>   [c0041f157b30] c001bc3c tm_recheckpoint.part.11+0x6c/0xa0
>   [c0041f157b70] c001d184 __switch_to+0x1e4/0x4c0
>   [c0041f157bd0] c082eeb8 __schedule+0x2f8/0x990
>   [c0041f157cb0] c082f598 schedule+0x48/0xc0
>   [c0041f157ce0] c00f0d28 worker_thread+0x148/0x610
>   [c0041f157d80] c00f96b0 kthread+0x120/0x140
>   [c0041f157e30] c000c0e0 ret_from_kernel_thread+0x5c/0x7c
> 
> This patch simply delays the MSR[TS] set, so, if there is any page fault in
> the __get_user() section, it does not have regs->msr[TS] set, since the TM
> structures are still invalid, thus avoiding doing TM operations for
> in-kernel exceptions and possible process reschedule.
> 
> With this patch, the MSR[TS] will only be set just before recheckpointing
> and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in
> invalid state.
> 
> Other than that, if CONFIG_PREEMPT is set, there might be a preemption just
> after setting MSR[TS] and before tm_recheckpoint(), thus, this block must
> be atomic from a preemption perspective, thus, calling
> preempt_disable/enable() on this code.
> 
> It is not possible to move tm_recheckpoint to happen earlier, because it is
> required to get the checkpointed registers from userspace, with
> __get_user(), thus, the only way to avoid this undesired behavior is
> delaying the MSR[TS] set.
> 
> The 32-bits signal handler seems to be safe this current issue, but, it
> might be exposed to the preemption issue, thus, disabling preemption in
> this chunk of code.
> 
> Changes from v2:
>  * Run the critical section with preempt_disable.
> 
> Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals")
> Cc: sta...@vger.kernel.org (v3.9+)
> Signed-off-by: Breno Leitao 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/e1c3743e1a20647c53b719dbf28b48

cheers


Re: [v2] Powerpc/perf: Wire up PMI throttling

2018-12-23 Thread Michael Ellerman
On Wed, 2018-11-21 at 03:56:37 UTC, Ravi Bangoria wrote:
> Commit 14c63f17b1fde ("perf: Drop sample rate when sampling is too
> slow") introduced a way to throttle PMU interrupts if we're spending
> too much time just processing those. Wire up powerpc PMI handler to
> use this infrastructure.
> 
> We have throttling of the *rate* of interrupts, but this adds
> throttling based on the *time taken* to process the interrupts.
> 
> Signed-off-by: Ravi Bangoria 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/0c9108b083706330cd5484d121fbb0

cheers


Re: powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"

2018-12-23 Thread Michael Ellerman
On Tue, 2018-11-20 at 15:12:30 UTC, Alexandre Belloni wrote:
> Fix a spelling mistake in a register description.
> 
> Signed-off-by: Alexandre Belloni 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a083787680f80f2c16316a1d907bf8

cheers


Re: Pull request: scottwood/linux.git next

2018-12-23 Thread Michael Ellerman
Hi Scott,

Scott Wood  writes:
> Highlights include elimination of legacy clock bindings use from dts
> files, an 83xx watchdog handler, fixes to old dts interrupt errors, and
> some minor cleanup.
>
> The following changes since commit 8c6c942d33f2a79439e86f8f406afae40a5bc767:
>
>   powerpc/eeh: Fix debugfs_simple_attr.cocci warnings (2018-12-20 22:59:03 
> +1100)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
>
> for you to fetch changes up to 5f470b3638a4ed03df79b993ece819cac2f4ca7e:
>
>   powerpc/configs/85xx: Enable CONFIG_DEBUG_KERNEL (2018-12-21 22:07:54 -0600)
>
> 
> Alexandre Belloni (1):
>   powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"
>
> Christoph Hellwig (1):
>   powerpc/fsl_pci: simplify fsl_pci_dma_set_mask

This one breaks networking on my p5020ds.

dmesg is just full of:

  e1000e 2000:01:00.0: Tx DMA map failed

Haven't had time to dig any further.

cheers


Re: [PATCH] powerpc/4xx/ocm: fix compiler error

2018-12-23 Thread christophe leroy




Le 23/12/2018 à 10:31, Segher Boessenkool a écrit :

On Sun, Dec 23, 2018 at 09:29:44AM +0100, Gabriel Paubert wrote:

•   The fetch access is to guarded storage and MSR[IR] = 1.


That is architected, yes.  You get an ISI if IR=1 and (N=1 or G=1).



If IR=0, mappings don't apply. So in 4xx/ocm, this mapping with 
_PAGE_EXEC and _PAGE_GUARDED at the same time seems pointless.


A standard ioremap() should do it (ie without exec), or a non guarded 
exec mapping if execution is expected for this area.


Christophe

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus



Re: [PATCH] powerpc/4xx/ocm: fix compiler error

2018-12-23 Thread Segher Boessenkool
On Sun, Dec 23, 2018 at 09:29:44AM +0100, Gabriel Paubert wrote:
> •   The fetch access is to guarded storage and MSR[IR] = 1.

That is architected, yes.  You get an ISI if IR=1 and (N=1 or G=1).


Segher