Re: [PATCH] PCI: Add no-D3 quirk for Mellanox ConnectX-[45]

2018-12-05 Thread Leon Romanovsky
On Thu, Dec 06, 2018 at 03:19:51PM +1100, David Gibson wrote:
> Mellanox ConnectX-5 IB cards (MT27800) seem to cause a call trace when
> unbound from their regular driver and attached to vfio-pci in order to pass
> them through to a guest.
>
> This goes away if the disable_idle_d3 option is used, so it looks like a
> problem with the hardware handling D3 state.  To fix that more permanently,
> use a device quirk to disable D3 state for these devices.
>
> We do this by renaming the existing quirk_no_ata_d3() more generally and
> attaching it to the ConnectX-[45] devices (0x15b3:0x1013).
>
> Signed-off-by: David Gibson 
> ---
>  drivers/pci/quirks.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
>

Hi David,

Thank for your patch,

I would like to reproduce the calltrace before moving forward,
but have trouble to reproduce the original issue.

I'm working with vfio-pci and CX-4/5 cards on daily basis,
tried manually enter into D3 state now, and it worked for me.

Can you please post your full calltrace, and "lspci -s PCI_ID -vv"
output?

Thanks


signature.asc
Description: PGP signature


Re: [PATCH v2 2/6] microblaze: prefer memblock API returning virtual address

2018-12-05 Thread Mike Rapoport
On Wed, Dec 05, 2018 at 04:29:40PM +0100, Michal Simek wrote:
> On 03. 12. 18 16:47, Mike Rapoport wrote:
> > Rather than use the memblock_alloc_base that returns a physical address and
> > then convert this address to the virtual one, use appropriate memblock
> > function that returns a virtual address.
> > 
> > Signed-off-by: Mike Rapoport 
> > ---
> >  arch/microblaze/mm/init.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/microblaze/mm/init.c b/arch/microblaze/mm/init.c
> > index b17fd8a..44f4b89 100644
> > --- a/arch/microblaze/mm/init.c
> > +++ b/arch/microblaze/mm/init.c
> > @@ -363,8 +363,9 @@ void __init *early_get_page(void)
> >  * Mem start + kernel_tlb -> here is limit
> >  * because of mem mapping from head.S
> >  */
> > -   return __va(memblock_alloc_base(PAGE_SIZE, PAGE_SIZE,
> > -   memory_start + kernel_tlb));
> > +   return memblock_alloc_try_nid_raw(PAGE_SIZE, PAGE_SIZE,
> > +   MEMBLOCK_LOW_LIMIT, memory_start + kernel_tlb,
> > +   NUMA_NO_NODE);
> >  }
> >  
> >  #endif /* CONFIG_MMU */
> > 
> 
> I can't see any issue with functionality when this patch is applied.
> If you want me to take this via my tree please let me know.

I thought to route this via mmotm tree.

> Otherwise:
> 
> Tested-by: Michal Simek 

Thanks!

 
> Thanks,
> Michal
> 
> -- 
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze
> Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
> U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
> 
> 




-- 
Sincerely yours,
Mike.



Re: [PATCH] powerpc/ipic: Fix a bounds check in ipic_set_priority()

2018-12-05 Thread Christophe LEROY




Le 05/12/2018 à 04:26, Michael Ellerman a écrit :

Hi Dan,

Thanks for the patch.

Dan Carpenter  writes:

The ipic_info[] array only has 95 elements so I have made the bounds
check smaller to prevent a read overflow.  It was Smatch that found
this issue:

 arch/powerpc/sysdev/ipic.c:784 ipic_set_priority()
 error: buffer overflow 'ipic_info' 95 <= 127

Signed-off-by: Dan Carpenter 
---
I wasn't able to find any callers of this code.  Maybe we removed the
last one in commit b9f0f1bb2bca ("[POWERPC] Adapt ipic driver to new
host_ops interface, add set_irq_type to set IRQ sense").  So perhaps we
should just remove it.  I'm not really comfortable doing that myself,
because I don't know the code well enough and can't build test
it properly.


Hah wow, last usage removed in 2006!

I don't see any mention of it since then, so I'll remove it. If it
breaks something we can put it back.

Can smatch help us find things like this that are defined non-static but
never used?



I think we have to do that carrefully. Some of those functions might be 
used by out-of-tree boards.


I'm thinking especially at ipic_get_mcp_status() and 
ipic_set_mcp_status(). They are used in my 832x boards's machine check 
handler to know when a machine check is a timeout from the 832x watchdog.


Christophe


Re: [PATCH] powerpc/ipic: Remove unused ipic_set_priority()

2018-12-05 Thread Michael Ellerman
Thiago Jung Bauermann  writes:

> Michael Ellerman  writes:
>
>> ipic_set_priority() has been unused since 2006 when the last usage was
>> removed in commit b9f0f1bb2bca ("[POWERPC] Adapt ipic driver to new
>> host_ops interface, add set_irq_type to set IRQ sense").
>>
>> Reported-by: Dan Carpenter 
>> Signed-off-by: Michael Ellerman 
>> ---
>>  arch/powerpc/sysdev/ipic.c | 28 
>>  1 file changed, 28 deletions(-)
>
> There's also the function prototype in 

Thanks.

I knew that but forgot about it before committing because my brain is
like a sieve :)

Will send a v2.

cheers


[PATCH v2] powerpc/ipic: Remove unused ipic_set_priority()

2018-12-05 Thread Michael Ellerman
ipic_set_priority() has been unused since 2006 when the last usage was
removed in commit b9f0f1bb2bca ("[POWERPC] Adapt ipic driver to new
host_ops interface, add set_irq_type to set IRQ sense").

Reported-by: Dan Carpenter 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/ipic.h |  1 -
 arch/powerpc/sysdev/ipic.c  | 28 
 2 files changed, 29 deletions(-)

v2: Also remove the declaration, as noticed by Thiago.

diff --git a/arch/powerpc/include/asm/ipic.h b/arch/powerpc/include/asm/ipic.h
index fb59829983b8..3dbd47f2bffe 100644
--- a/arch/powerpc/include/asm/ipic.h
+++ b/arch/powerpc/include/asm/ipic.h
@@ -69,7 +69,6 @@ enum ipic_mcp_irq {
IPIC_MCP_MU   = 7,
 };
 
-extern int ipic_set_priority(unsigned int irq, unsigned int priority);
 extern void ipic_set_highest_priority(unsigned int irq);
 extern void ipic_set_default_priority(void);
 extern void ipic_enable_mcp(enum ipic_mcp_irq mcp_irq);
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 6300123ce965..8030a0f55e96 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -771,34 +771,6 @@ struct ipic * __init ipic_init(struct device_node *node, 
unsigned int flags)
return ipic;
 }
 
-int ipic_set_priority(unsigned int virq, unsigned int priority)
-{
-   struct ipic *ipic = ipic_from_irq(virq);
-   unsigned int src = virq_to_hw(virq);
-   u32 temp;
-
-   if (priority > 7)
-   return -EINVAL;
-   if (src > 127)
-   return -EINVAL;
-   if (ipic_info[src].prio == 0)
-   return -EINVAL;
-
-   temp = ipic_read(ipic->regs, ipic_info[src].prio);
-
-   if (priority < 4) {
-   temp &= ~(0x7 << (20 + (3 - priority) * 3));
-   temp |= ipic_info[src].prio_mask << (20 + (3 - priority) * 3);
-   } else {
-   temp &= ~(0x7 << (4 + (7 - priority) * 3));
-   temp |= ipic_info[src].prio_mask << (4 + (7 - priority) * 3);
-   }
-
-   ipic_write(ipic->regs, ipic_info[src].prio, temp);
-
-   return 0;
-}
-
 void ipic_set_highest_priority(unsigned int virq)
 {
struct ipic *ipic = ipic_from_irq(virq);
-- 
2.17.2



Re: Patch "powerpc/function_graph: Simplify with function_graph_enter()" has been added to the 4.19-stable tree

2018-12-05 Thread kbuild test robot
Hi gregkh,

I love your patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[cannot apply to v4.20-rc5 next-20181205]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/gregkh-linuxfoundation-org/Patch-powerpc-function_graph-Simplify-with-function_graph_enter-has-been-added-to-the-4-19-stable-tree/20181204-171923
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   arch/powerpc/kernel/trace/ftrace.c: In function 'prepare_ftrace_return':
>> arch/powerpc/kernel/trace/ftrace.c:963:7: error: implicit declaration of 
>> function 'function_graph_enter'; did you mean 'ftrace_graph_entry'? 
>> [-Werror=implicit-function-declaration]
 if (!function_graph_enter(parent, ip, 0, NULL))
  ^~~~
  ftrace_graph_entry
   cc1: all warnings being treated as errors

vim +963 arch/powerpc/kernel/trace/ftrace.c

   946  
   947  /*
   948   * Hook the return address and push it in the stack of return addrs
   949   * in current thread info. Return the address we want to divert to.
   950   */
   951  unsigned long prepare_ftrace_return(unsigned long parent, unsigned long 
ip)
   952  {
   953  unsigned long return_hooker;
   954  
   955  if (unlikely(ftrace_graph_is_dead()))
   956  goto out;
   957  
   958  if (unlikely(atomic_read(>tracing_graph_pause)))
   959  goto out;
   960  
   961  return_hooker = ppc_function_entry(return_to_handler);
   962  
 > 963  if (!function_graph_enter(parent, ip, 0, NULL))
   964  parent = return_hooker;
   965  out:
   966  return parent;
   967  }
   968  #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
   969  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


linux-next: manual merge of the akpm-current tree with the powerpc tree

2018-12-05 Thread Stephen Rothwell
Hi Andrew,

Today's linux-next merge of the akpm-current tree got conflicts in:

  arch/powerpc/include/asm/book3s/32/pgalloc.h
  arch/powerpc/include/asm/nohash/32/pgalloc.h
  arch/powerpc/mm/pgtable-book3s64.c

between commits:

  a95d133c8643 ("powerpc/mm: Move pte_fragment_alloc() to a common location")
  32ea4c149990 ("powerpc/mm: Extend pte_fragment functionality to PPC32")

from the powerpc tree and commit:

  913c2d755b39 ("mm: treewide: remove unused address argument from pte_alloc 
functions")

from the akpm-current tree.

I fixed it up (see below, plus the extra merge fix patch) 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.

From: Stephen Rothwell 
Date: Thu, 6 Dec 2018 17:41:27 +1100
Subject: [PATCH] fix up for "mm: treewide: remove unused address argument from
 pte_alloc functions"

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/mm/pgtable-frag.c | 2 +-
 arch/powerpc/mm/pgtable_32.c   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/mm/pgtable-frag.c b/arch/powerpc/mm/pgtable-frag.c
index af23a587f019..a7b05214760c 100644
--- a/arch/powerpc/mm/pgtable-frag.c
+++ b/arch/powerpc/mm/pgtable-frag.c
@@ -95,7 +95,7 @@ static pte_t *__alloc_for_ptecache(struct mm_struct *mm, int 
kernel)
return (pte_t *)ret;
 }
 
-pte_t *pte_fragment_alloc(struct mm_struct *mm, unsigned long vmaddr, int 
kernel)
+pte_t *pte_fragment_alloc(struct mm_struct *mm, int kernel)
 {
pte_t *pte;
 
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index deda68e02338..5b1e1adeb4d2 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -48,12 +48,12 @@ __ref pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
if (!slab_is_available())
return memblock_alloc(PTE_FRAG_SIZE, PTE_FRAG_SIZE);
 
-   return (pte_t *)pte_fragment_alloc(mm, address, 1);
+   return (pte_t *)pte_fragment_alloc(mm, 1);
 }
 
 pgtable_t pte_alloc_one(struct mm_struct *mm)
 {
-   return (pgtable_t)pte_fragment_alloc(mm, address, 0);
+   return (pgtable_t)pte_fragment_alloc(mm, 0);
 }
 
 void __iomem *
-- 
2.19.1

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/include/asm/book3s/32/pgalloc.h
index b5b955eb2fb7,af9e13555d95..
--- a/arch/powerpc/include/asm/book3s/32/pgalloc.h
+++ b/arch/powerpc/include/asm/book3s/32/pgalloc.h
@@@ -56,16 -61,29 +56,16 @@@ static inline void pmd_populate_kernel(
  static inline void pmd_populate(struct mm_struct *mm, pmd_t *pmdp,
pgtable_t pte_page)
  {
 -  *pmdp = __pmd((page_to_pfn(pte_page) << PAGE_SHIFT) | _PMD_PRESENT);
 -}
 -
 -#define pmd_pgtable(pmd) pmd_page(pmd)
 -#else
 -
 -static inline void pmd_populate_kernel(struct mm_struct *mm, pmd_t *pmdp,
 - pte_t *pte)
 -{
 -  *pmdp = __pmd((unsigned long)pte | _PMD_PRESENT);
 -}
 -
 -static inline void pmd_populate(struct mm_struct *mm, pmd_t *pmdp,
 -  pgtable_t pte_page)
 -{
 -  *pmdp = __pmd((unsigned long)lowmem_page_address(pte_page) | 
_PMD_PRESENT);
 +  *pmdp = __pmd(__pa(pte_page) | _PMD_PRESENT);
  }
  
 -#define pmd_pgtable(pmd) pmd_page(pmd)
 -#endif
 +#define pmd_pgtable(pmd) ((pgtable_t)pmd_page_vaddr(pmd))
  
- extern pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long addr);
- extern pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long addr);
+ extern pte_t *pte_alloc_one_kernel(struct mm_struct *mm);
+ extern pgtable_t pte_alloc_one(struct mm_struct *mm);
 +void pte_frag_destroy(void *pte_frag);
- pte_t *pte_fragment_alloc(struct mm_struct *mm, unsigned long vmaddr, int 
kernel);
++pte_t *pte_fragment_alloc(struct mm_struct *mm, int kernel);
 +void pte_fragment_free(unsigned long *table, int kernel);
  
  static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
  {
diff --cc arch/powerpc/include/asm/nohash/32/pgalloc.h
index 17963951bdb0,16623f53f0d4..
--- a/arch/powerpc/include/asm/nohash/32/pgalloc.h
+++ b/arch/powerpc/include/asm/nohash/32/pgalloc.h
@@@ -73,17 -77,14 +73,17 @@@ static inline void pmd_populate_kernel(
  static inline void pmd_populate(struct mm_struct *mm, pmd_t *pmdp,
pgtable_t pte_page)
  {
 -  *pmdp = __pmd((unsigned long)lowmem_page_address(pte_page) | 
_PMD_PRESENT);
 +  *pmdp = __pmd((unsigned long)pte_page | _PMD_PRESENT);
  }
  
 -#define pmd_pgtable(pmd) pmd_page(pmd)
 +#define pmd_pgtable(pmd) ((pgtable_t)pmd_page_vaddr(pmd))
  #endif
  
- extern pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long addr);
- extern pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long addr);
+ 

Re: [RFC PATCH] soc: fsl: guts: handle devm_kstrdup() failure

2018-12-05 Thread Nicholas Mc Guire
On Wed, Dec 05, 2018 at 02:42:55PM -0600, Li Yang wrote:
> On Sun, Dec 2, 2018 at 3:07 AM Nicholas Mc Guire  wrote:
> >
> > devm_kstrdup() may return NULL if internal allocation failed.
> > soc_dev_attr.machine  should be checked (although its only use
> > in pr_info() would be safe even with a NULL). Therefor
> > in the unlikely case of allocation failure, fsl_guts_probe() returns
> > -ENOMEM as this allocating failing is an indication of something
> > more serious going wrong at system level.
> >
> > As  machine  is from the device tree which I assume to be RO - if
> > that assumption is always correct - a better alternative would be
> > to use devm_kstrdup_const() here. That would then simply copy the
> > reference to the RO data and not perform any allocation at all.
> 
> I think your assumption is correct.  Do you want to send a new and
> better version?  :)

The issue was actually more general that I did not find a reliable
method to assure that some object is *always* RO. Even for device
tree data it was not clear to me if there could be systems where
it is not RO.
Anyway - will send the version using devm_kstrdup_const() then.

thx!
hofrat

> 
> >
> > Signed-off-by: Nicholas Mc Guire 
> > Fixes: a6fc3b698130 ("soc: fsl: add GUTS driver for QorIQ platforms")
> > ---
> >
> > Problem located by experimental coccinelle script
> >
> > Patch was compile tested with: multi_v7_defconfig (implies FSL_GUTS=y)
> >
> > Patch is against 4.20-rc4 (localversion-next is next-20181130)
> >
> >  drivers/soc/fsl/guts.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > index 302e0c8..a0c751b 100644
> > --- a/drivers/soc/fsl/guts.c
> > +++ b/drivers/soc/fsl/guts.c
> > @@ -156,8 +156,11 @@ static int fsl_guts_probe(struct platform_device *pdev)
> > if (of_property_read_string(root, "model", ))
> > of_property_read_string_index(root, "compatible", 0, 
> > );
> > of_node_put(root);
> > -   if (machine)
> > +   if (machine) {
> > soc_dev_attr.machine = devm_kstrdup(dev, machine, 
> > GFP_KERNEL);
> > +   if (!soc_dev_attr.machine)
> > +   return -ENOMEM;
> > +   }
> >
> > svr = fsl_guts_get_svr();
> > soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> > --
> > 2.1.4
> >


[PATCH] powerpc/boot: Fix build failures with -j 1

2018-12-05 Thread Michael Ellerman
In commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to
wrapper") we added a dependency to serial.c on autoconf.h:

  $(obj)/serial.c: $(obj)/autoconf.h

This works when building in-tree (ie. with KBUILD_OUTPUT unset)
because the obj tree is the src tree.

But when building with eg. O=build and -j 1 the build fails:

  gcc ... -I../arch/powerpc/boot -c -o arch/powerpc/boot/serial.o 
arch/powerpc/boot/serial.c
  gcc: error: arch/powerpc/boot/serial.c: No such file or directory

Why this is only happening with -j 1 is not clear, when building with
-j greater than 1 somehow we decide to look for serial.c in the src
tree (../), eg:

  gcc -I../arch/powerpc/boot -c -o arch/powerpc/boot/serial.o 
../arch/powerpc/boot/serial.c

Regardless we shouldn't be specifying a dependency on serial.c in the
build tree, we want to add a dependency to the version in $(srctree)
so fix the rule to say that.

Fixes: 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
Tested-by: Daniel Axtens 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/boot/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 39354365f54a..ed9883169190 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -197,7 +197,7 @@ $(addprefix $(obj)/,$(libfdt) $(libfdtheader)): $(obj)/%: 
$(srctree)/scripts/dtc
 $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds : $(obj)/%: $(srctree)/$(src)/%.S
$(Q)cp $< $@
 
-$(obj)/serial.c: $(obj)/autoconf.h
+$(srctree)/$(src)/serial.c: $(obj)/autoconf.h
 
 $(obj)/autoconf.h: $(obj)/%: $(objtree)/include/generated/%
$(Q)cp $< $@
-- 
2.17.2



[PATCH] PCI: Add no-D3 quirk for Mellanox ConnectX-[45]

2018-12-05 Thread David Gibson
Mellanox ConnectX-5 IB cards (MT27800) seem to cause a call trace when
unbound from their regular driver and attached to vfio-pci in order to pass
them through to a guest.

This goes away if the disable_idle_d3 option is used, so it looks like a
problem with the hardware handling D3 state.  To fix that more permanently,
use a device quirk to disable D3 state for these devices.

We do this by renaming the existing quirk_no_ata_d3() more generally and
attaching it to the ConnectX-[45] devices (0x15b3:0x1013).

Signed-off-by: David Gibson 
---
 drivers/pci/quirks.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 4700d24e5d55..add3f516ca12 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1315,23 +1315,24 @@ static void quirk_ide_samemode(struct pci_dev *pdev)
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_10, 
quirk_ide_samemode);
 
-/* Some ATA devices break if put into D3 */
-static void quirk_no_ata_d3(struct pci_dev *pdev)
+/* Some devices (including a number of ATA cards) break if put into D3 */
+static void quirk_no_d3(struct pci_dev *pdev)
 {
pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
 }
+
 /* Quirk the legacy ATA devices only. The AHCI ones are ok */
 DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_SERVERWORKS, PCI_ANY_ID,
-   PCI_CLASS_STORAGE_IDE, 8, quirk_no_ata_d3);
+   PCI_CLASS_STORAGE_IDE, 8, quirk_no_d3);
 DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
-   PCI_CLASS_STORAGE_IDE, 8, quirk_no_ata_d3);
+   PCI_CLASS_STORAGE_IDE, 8, quirk_no_d3);
 /* ALi loses some register settings that we cannot then restore */
 DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AL, PCI_ANY_ID,
-   PCI_CLASS_STORAGE_IDE, 8, quirk_no_ata_d3);
+   PCI_CLASS_STORAGE_IDE, 8, quirk_no_d3);
 /* VIA comes back fine but we need to keep it alive or ACPI GTM failures
occur when mode detecting */
 DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
-   PCI_CLASS_STORAGE_IDE, 8, quirk_no_ata_d3);
+   PCI_CLASS_STORAGE_IDE, 8, quirk_no_d3);
 
 /*
  * This was originally an Alpha-specific thing, but it really fits here.
@@ -3367,6 +3368,10 @@ static void mellanox_check_broken_intx_masking(struct 
pci_dev *pdev)
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_MELLANOX, PCI_ANY_ID,
mellanox_check_broken_intx_masking);
 
+/* Mellanox MT27800 (ConnectX-5) IB card seems to break with D3
+ * In particular this shows up when the device is bound to the vfio-pci driver 
*/
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MELLANOX, 
PCI_DEVICE_ID_MELLANOX_CONNECTX4, quirk_no_d3)
+
 static void quirk_no_bus_reset(struct pci_dev *dev)
 {
dev->dev_flags |= PCI_DEV_FLAGS_NO_BUS_RESET;
-- 
2.19.2



Re: [PATCH] tty: Use of_node_name_{eq, prefix} for node name comparisons

2018-12-05 Thread Michael Ellerman
Rob Herring  writes:

> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
>
> For hvc, the code can also be simplified by using of_stdout pointer
> instead of searching again for the stdout node.
>
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Greg Kroah-Hartman 
> Cc: Jiri Slaby 
> Cc: "David S. Miller" 
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ser...@vger.kernel.org
> Cc: sparcli...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/tty/hvc/hvc_opal.c  |  2 +-
>  drivers/tty/hvc/hvc_vio.c   | 11 +--
>  drivers/tty/serial/pmac_zilog.c |  4 ++--

LGTM.

Acked-by: Michael Ellerman  (powerpc)

cheers


Re: [alsa-devel] [PATCH] ASoC: Use of_node_name_eq for node name comparisons

2018-12-05 Thread Kuninori Morimoto


Hi Rob

> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
> 
> For the FSL ASoC card, the full node names appear to be "ssi", "esai",
> and "sai", so there's not any reason to use strstr and of_node_name_eq
> can be used instead.

I guess this patch is for FSL ?

> ---
>  sound/soc/fsl/fsl-asoc-card.c   | 6 +++---
>  sound/soc/generic/simple-scu-card.c | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)

But, this patch is including simple-scu-card.
Is this miss ?


Best regards
---
Kuninori Morimoto


Re: [PATCH v2 34/34] dt-bindings: arm: Convert ZTE board/soc bindings to json-schema

2018-12-05 Thread Shawn Guo
On Mon, Dec 03, 2018 at 03:32:23PM -0600, Rob Herring wrote:
> Convert ZTE SoC bindings to DT schema format using json-schema.
> 
> Cc: Jun Nie 
> Cc: Mark Rutland 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Acked-by: Shawn Guo 
> Signed-off-by: Rob Herring 
> ---
>  Documentation/devicetree/bindings/arm/zte.txt | 14 --
>  .../devicetree/bindings/arm/zte.yaml  | 26 +++

I do not have any changes on bindings/arm/zte.txt in my queue, so please
you take it.

Shawn


Re: [PATCH v2 18/34] dt-bindings: arm: Convert FSL board/soc bindings to json-schema

2018-12-05 Thread Shawn Guo
On Mon, Dec 03, 2018 at 03:32:07PM -0600, Rob Herring wrote:
> Convert Freescale SoC bindings to DT schema format using json-schema.
> 
> Cc: Shawn Guo 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/armadeus.txt  |   6 -
>  Documentation/devicetree/bindings/arm/bhf.txt |   6 -
>  .../bindings/arm/compulab-boards.txt  |  25 --
>  Documentation/devicetree/bindings/arm/fsl.txt | 229 --
>  .../devicetree/bindings/arm/fsl.yaml  | 214 

Rob,

I do have any changes on bindings/arm/fsl.txt queued for 4.21 on my
tree, so please send it via your tree.

Acked-by: Shawn Guo 


Re: [PATCH] ASoC: Use of_node_name_eq for node name comparisons

2018-12-05 Thread Nicolin Chen
Hi Rob,

On Thu, Dec 6, 2018 at 3:51 AM 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.
>
> For the FSL ASoC card, the full node names appear to be "ssi", "esai",
> and "sai", so there's not any reason to use strstr and of_node_name_eq

I am not quite sure about the replacement of strstr.
IIRC, a node name in fsl dts might appear to be "ssi@".

I am currently out of town so cannot verify the patch.

Fabio, would it be possible for you to run a boot test?

Thanks
Nicolin


Re: [v11 6/7] arm64: dts: ls1046a: add qdma device tree nodes

2018-12-05 Thread Shawn Guo
On Tue, Oct 30, 2018 at 10:36:03AM +0800, Peng Ma wrote:
> add the qDMA device tree nodes for LS1046A devices.
> 
> Signed-off-by: Wen He 
> Signed-off-by: Peng Ma 
> ---
> change in v11:
>   - no
> 
>  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |   21 +
>  1 files changed, 21 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> index ef83786..dc65318 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> @@ -704,6 +704,27 @@
>   < 0 0 4  GIC_SPI 154 
> IRQ_TYPE_LEVEL_HIGH>;
>   };
>  
> + qdma: dma-controller@838 {
> + compatible = "fsl,ls1046a-qdma", "fsl,ls1021a-qdma";
> + reg = <0x0 0x838 0x0 0x1000>, /* Controller regs */
> +   <0x0 0x839 0x0 0x1>, /* Status regs */
> +   <0x0 0x83a 0x0 0x4>; /* Block regs */
> + interrupts = <0 153 0x4>,
> +  <0 39 0x4>,
> +  <0 40 0x4>,
> +  <0 41 0x4>,
> +  <0 42 0x4>;

Use GIC_SPI and IRQ_TYPE_xxx defines.

Shawn

> + interrupt-names = "qdma-error", "qdma-queue0",
> + "qdma-queue1", "qdma-queue2", "qdma-queue3";
> + dma-channels = <8>;
> + block-number = <1>;
> + block-offset = <0x1>;
> + fsl,dma-queues = <2>;
> + status-sizes = <64>;
> + queue-sizes = <64 64>;
> + big-endian;
> + };
> +
>   };
>  
>   reserved-memory {
> -- 
> 1.7.1
> 


Re: [v11 5/7] arm64: dts: ls1043a: add qdma device tree nodes

2018-12-05 Thread Shawn Guo
On Tue, Oct 30, 2018 at 10:36:02AM +0800, Peng Ma wrote:
> add the qDMA device tree nodes for LS1043A devices.
> 
> Signed-off-by: Wen He 
> Signed-off-by: Peng Ma 
> ---
> change in v11:
>   - no
> 
>  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |   22 ++
>  1 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> index 7881e3d..d560141 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> @@ -734,6 +734,28 @@
>   < 0 0 3  0 156 0x4>,
>   < 0 0 4  0 157 0x4>;
>   };
> +
> + qdma: dma-controller@838 {
> + compatible = "fsl,ls1021a-qdma", "fsl,ls1043a-qdma";
> + reg = <0x0 0x838 0x0 0x1000>, /* Controller regs */
> +   <0x0 0x839 0x0 0x1>, /* Status regs */
> +   <0x0 0x83a 0x0 0x4>; /* Block regs */
> + interrupts = <0 153 0x4>,
> +  <0 39 0x4>,
> +  <0 40 0x4>,
> +  <0 41 0x4>,
> +  <0 42 0x4>;

I know this dts file did not use GIC_SPI and IRQ_TYPE_xxx defines from
the beginning.  But please use them for new additions.

Shawn

> + interrupt-names = "qdma-error", "qdma-queue0",
> + "qdma-queue1", "qdma-queue2", "qdma-queue3";
> + dma-channels = <8>;
> + block-number = <1>;
> + block-offset = <0x1>;
> + fsl,dma-queues = <2>;
> + status-sizes = <64>;
> + queue-sizes = <64 64>;
> + big-endian;
> + };
> +
>   };
>  
>   firmware {
> -- 
> 1.7.1
> 


Re: [v11 4/7] arm: dts: ls1021a: add qdma device tree nodes

2018-12-05 Thread Shawn Guo
On Tue, Oct 30, 2018 at 10:36:01AM +0800, Peng Ma wrote:
> add the qDMA device tree nodes for LS1021A devices.
> 
> Signed-off-by: Wen He 
> Signed-off-by: Peng Ma 

Applied, thanks.


Re: [PATCH 2/2] fsl: add i2c controlled qixis driver

2018-12-05 Thread Li Yang
On Thu, Oct 4, 2018 at 11:03 PM Pankaj Bansal  wrote:
>
> FPGA on LX2160AQDS/LX2160ARDB connected on I2C bus, so add qixis
> driver which is basically an i2c client driver to control FPGA.

Is this driver just used to print out the QIXIS version and create
platform devices for all the subnodes?   If that's the case, a
"simple-bus" compatibility in the fpga node would be enough.

>
> Signed-off-by: Wang Dongsheng 
> Signed-off-by: Pankaj Bansal 
> ---
>  drivers/soc/fsl/Kconfig|  9 
>  drivers/soc/fsl/Makefile   |  1 +
>  drivers/soc/fsl/qixis_ctrl.c   | 75 
>  include/linux/fsl/qixis_ctrl.h | 20 +
>  4 files changed, 105 insertions(+)
>
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> index 8f80e8bbf29e..c355c2cbbd45 100644
> --- a/drivers/soc/fsl/Kconfig
> +++ b/drivers/soc/fsl/Kconfig
> @@ -28,4 +28,13 @@ config FSL_MC_DPIO
>   other DPAA2 objects. This driver does not expose the DPIO
>   objects individually, but groups them under a service layer
>   API.
> +
> +config FSL_QIXIS
> +   tristate "QIXIS system controller driver"
> +   select REGMAP_I2C
> +   default n
> +   help
> + Say y here to enable QIXIS system controller api. The qixis driver
> + provides FPGA functions to control system.
> +
>  endmenu
> diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> index 803ef1bfb5ff..47e0cfc66ca4 100644
> --- a/drivers/soc/fsl/Makefile
> +++ b/drivers/soc/fsl/Makefile
> @@ -5,5 +5,6 @@
>  obj-$(CONFIG_FSL_DPAA) += qbman/
>  obj-$(CONFIG_QUICC_ENGINE) += qe/
>  obj-$(CONFIG_CPM)  += qe/
> +obj-$(CONFIG_FSL_QIXIS)+= qixis_ctrl.o
>  obj-$(CONFIG_FSL_GUTS) += guts.o
>  obj-$(CONFIG_FSL_MC_DPIO)  += dpio/
> diff --git a/drivers/soc/fsl/qixis_ctrl.c b/drivers/soc/fsl/qixis_ctrl.c
> new file mode 100644
> index ..b94649fb9726
> --- /dev/null
> +++ b/drivers/soc/fsl/qixis_ctrl.c
> @@ -0,0 +1,75 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/* Freescale QIXIS system controller driver.
> + *
> + * Copyright 2015 Freescale Semiconductor, Inc.
> + * Copyright 2018 NXP
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static struct regmap *qixis_regmap;
> +
> +static struct regmap_config qixis_regmap_config = {
> +   .reg_bits = 8,
> +   .val_bits = 8,
> +};
> +
> +static int fsl_qixis_i2c_probe(struct i2c_client *client)
> +{
> +   struct platform_device *pdev;
> +   struct device_node *child;
> +   u32 qver;
> +
> +   if (!i2c_check_functionality(client->adapter, 
> I2C_FUNC_SMBUS_BYTE_DATA))
> +   return -EOPNOTSUPP;
> +
> +   qixis_regmap = regmap_init_i2c(client, _regmap_config);
> +
> +   /* create platform device for  each of the child node of FPGA node */
> +   for_each_child_of_node(client->dev.of_node, child) {
> +   pdev = of_platform_device_create(child, NULL, >dev);
> +   };
> +
> +   regmap_read(qixis_regmap, offsetof(struct fsl_qixis_regs, qixis_ver),
> +   );
> +
> +   pr_info("Freescale QIXIS Version: 0x%08x\n", qver);
> +
> +   return 0;
> +}
> +
> +static int fsl_qixis_i2c_remove(struct i2c_client *client)
> +{

Don't need to cleanup the regmap created?

> +   return 0;
> +}
> +
> +static const struct of_device_id fsl_qixis_of_match[] = {
> +   { .compatible = "fsl,fpga-qixis-i2c" },
> +   {}
> +};
> +MODULE_DEVICE_TABLE(of, fsl_qixis_of_match);
> +
> +static struct i2c_driver fsl_qixis_i2c_driver = {
> +   .driver = {
> +   .name   = "qixis_ctrl",
> +   .owner  = THIS_MODULE,
> +   .of_match_table = of_match_ptr(fsl_qixis_of_match),
> +   },
> +   .probe_new  = fsl_qixis_i2c_probe,
> +   .remove = fsl_qixis_i2c_remove,
> +};
> +module_i2c_driver(fsl_qixis_i2c_driver);
> +
> +MODULE_AUTHOR("Wang Dongsheng ");
> +MODULE_DESCRIPTION("Freescale QIXIS system controller driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/fsl/qixis_ctrl.h b/include/linux/fsl/qixis_ctrl.h
> new file mode 100644
> index ..00e80ef21adc
> --- /dev/null
> +++ b/include/linux/fsl/qixis_ctrl.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0+
> + *
> + * Definitions for Freescale QIXIS system controller.
> + *
> + * Copyright 2015 Freescale Semiconductor, Inc.
> + * Copyright 2018 NXP
> + */
> +
> +#ifndef _FSL_QIXIS_CTRL_H_
> +#define _FSL_QIXIS_CTRL_H_
> +
> +/* QIXIS MAP */
> +struct fsl_qixis_regs {
> +   u8  id; /* Identification Registers */
> +   u8  version;/* Version Register */
> +   u8  qixis_ver;  /* QIXIS Version Register */
> +   u8  reserved1[0x1f];
> +};
> +
> +#endif
> --
> 2.17.1
>

Re: [PATCH kernel v4 04/19] powerpc/powernv: Move npu struct from pnv_phb to pci_controller

2018-12-05 Thread David Gibson
On Wed, Dec 05, 2018 at 05:17:57PM +1100, Alexey Kardashevskiy wrote:
> 
> 
> On 05/12/2018 16:47, Alexey Kardashevskiy wrote:
> > 
> > 
> > On 05/12/2018 16:14, David Gibson wrote:
> >> On Fri, Nov 23, 2018 at 04:52:49PM +1100, Alexey Kardashevskiy wrote:
> >>> The powernv PCI code stores NPU data in the pnv_phb struct. The latter
> >>> is referenced by pci_controller::private_data. We are going to have NPU2
> >>> support in the pseries platform as well but it does not store any
> >>> private_data in in the pci_controller struct; and even if it did,
> >>> it would be a different data structure.
> >>>
> >>> This makes npu a pointer and stores it one level higher in
> >>> the pci_controller struct.
> >>>
> >>> Signed-off-by: Alexey Kardashevskiy 
> >>> ---
> >>> Changes:
> >>> v4:
> >>> * changed subj from "powerpc/powernv: Detach npu struct from pnv_phb"
> >>> * got rid of global list of npus - store them now in pci_controller
> >>> * got rid of npdev_to_npu() helper
> >>> ---
> >>>  arch/powerpc/include/asm/pci-bridge.h|  1 +
> >>>  arch/powerpc/platforms/powernv/pci.h | 16 -
> >>>  arch/powerpc/platforms/powernv/npu-dma.c | 81 ++--
> >>>  3 files changed, 64 insertions(+), 34 deletions(-)
> >>>
> >>> diff --git a/arch/powerpc/include/asm/pci-bridge.h 
> >>> b/arch/powerpc/include/asm/pci-bridge.h
> >>> index 94d4490..aee4fcc 100644
> >>> --- a/arch/powerpc/include/asm/pci-bridge.h
> >>> +++ b/arch/powerpc/include/asm/pci-bridge.h
> >>> @@ -129,6 +129,7 @@ struct pci_controller {
> >>>  #endif   /* CONFIG_PPC64 */
> >>>  
> >>>   void *private_data;
> >>> + struct npu *npu;
> >>>  };
> >>>  
> >>>  /* These are used for config access before all the PCI probing
> >>> diff --git a/arch/powerpc/platforms/powernv/pci.h 
> >>> b/arch/powerpc/platforms/powernv/pci.h
> >>> index 2131373..f2d50974 100644
> >>> --- a/arch/powerpc/platforms/powernv/pci.h
> >>> +++ b/arch/powerpc/platforms/powernv/pci.h
> >>> @@ -8,9 +8,6 @@
> >>>  
> >>>  struct pci_dn;
> >>>  
> >>> -/* Maximum possible number of ATSD MMIO registers per NPU */
> >>> -#define NV_NMMU_ATSD_REGS 8
> >>> -
> >>>  enum pnv_phb_type {
> >>>   PNV_PHB_IODA1   = 0,
> >>>   PNV_PHB_IODA2   = 1,
> >>> @@ -176,19 +173,6 @@ struct pnv_phb {
> >>>   unsigned intdiag_data_size;
> >>>   u8  *diag_data;
> >>>  
> >>> - /* Nvlink2 data */
> >>> - struct npu {
> >>> - int index;
> >>> - __be64 *mmio_atsd_regs[NV_NMMU_ATSD_REGS];
> >>> - unsigned int mmio_atsd_count;
> >>> -
> >>> - /* Bitmask for MMIO register usage */
> >>> - unsigned long mmio_atsd_usage;
> >>> -
> >>> - /* Do we need to explicitly flush the nest mmu? */
> >>> - bool nmmu_flush;
> >>> - } npu;
> >>> -
> >>>   int p2p_target_count;
> >>>  };
> >>>  
> >>> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
> >>> b/arch/powerpc/platforms/powernv/npu-dma.c
> >>> index 91d488f..7dd5c0e5 100644
> >>> --- a/arch/powerpc/platforms/powernv/npu-dma.c
> >>> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> >>> @@ -327,6 +327,25 @@ struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct 
> >>> pnv_ioda_pe *npe)
> >>>   return gpe;
> >>>  }
> >>>  
> >>> +/*
> >>> + * NPU2 ATS
> >>> + */
> >>> +/* Maximum possible number of ATSD MMIO registers per NPU */
> >>> +#define NV_NMMU_ATSD_REGS 8
> >>> +
> >>> +/* An NPU descriptor, valid for POWER9 only */
> >>> +struct npu {
> >>> + int index;
> >>> + __be64 *mmio_atsd_regs[NV_NMMU_ATSD_REGS];
> >>> + unsigned int mmio_atsd_count;
> >>> +
> >>> + /* Bitmask for MMIO register usage */
> >>> + unsigned long mmio_atsd_usage;
> >>> +
> >>> + /* Do we need to explicitly flush the nest mmu? */
> >>> + bool nmmu_flush;
> >>> +};
> >>> +
> >>>  /* Maximum number of nvlinks per npu */
> >>>  #define NV_MAX_LINKS 6
> >>>  
> >>> @@ -478,7 +497,6 @@ static void acquire_atsd_reg(struct npu_context 
> >>> *npu_context,
> >>>   int i, j;
> >>>   struct npu *npu;
> >>>   struct pci_dev *npdev;
> >>> - struct pnv_phb *nphb;
> >>>  
> >>>   for (i = 0; i <= max_npu2_index; i++) {
> >>>   mmio_atsd_reg[i].reg = -1;
> >>> @@ -493,8 +511,10 @@ static void acquire_atsd_reg(struct npu_context 
> >>> *npu_context,
> >>>   if (!npdev)
> >>>   continue;
> >>>  
> >>> - nphb = pci_bus_to_host(npdev->bus)->private_data;
> >>> - npu = >npu;
> >>> + npu = pci_bus_to_host(npdev->bus)->npu;
> >>> + if (!npu)
> >>> + continue;
> >>
> >> This patch changes a bunch of places that used to unconditionally
> >> locate an NPU now have a failure path.
> >>
> >> Given that this used to always have an NPU, doesn't that mean that if
> >> the NPU is not present something has already gone wrong, and we should
> >> WARN_ON() or something?
> > 
> > 
> > 
> > That means this is a leftover since I dropped that npdev_to_npu helper
> > which could 

Re: [PATCH] serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250

2018-12-05 Thread Florian Fainelli
On 12/4/18 9:47 PM, Michael Ellerman wrote:
> Hi Florian,
> 
> Florian Fainelli  writes:
>> +PPC folks
>>
>> On 11/23/18 10:20 AM, Guenter Roeck wrote:
>>> On Mon, Nov 19, 2018 at 12:50:50PM -0800, Guenter Roeck wrote:
 On Mon, Nov 19, 2018 at 10:44:30AM -0800, Florian Fainelli wrote:
> On 11/15/18 5:16 PM, Guenter Roeck wrote:
>> On Thu, Nov 15, 2018 at 11:48:20AM -0800, Florian Fainelli wrote:
>>>
>>> OK, would you mind testing this below? It seems to me that 8250_of.c is
>>> incompatible with arch/powerpc/kernel/legacy_serial.c and that is what
>>> is causing the issue here.
>>>
>>> diff --git a/drivers/tty/serial/8250/Kconfig
>>> b/drivers/tty/serial/8250/Kconfig
>>> index d7737dca0e48..21cb14cbd34a 100644
>>> --- a/drivers/tty/serial/8250/Kconfig
>>> +++ b/drivers/tty/serial/8250/Kconfig
>>> @@ -483,7 +483,7 @@ config SERIAL_8250_PXA
>>>
>>>  config SERIAL_OF_PLATFORM
>>> tristate "Devicetree based probing for 8250 ports"
>>> -   depends on SERIAL_8250 && OF
>>> +   depends on SERIAL_8250 && OF && !(PPC && PPC_UDBG_16550)
>>> default SERIAL_8250
>>> help
>>>   This option is used for all 8250 compatible serial ports that
>>
>> 44x/virtex5_defconfig has both PPC_UDBG_16550 and SERIAL_OF_PLATFORM 
>> enabled
>> and fails to boot (or display anything on the console) with this patch 
>> applied.
>
> Thanks for trying, can you either share or provide a link to the mpc85xx
> and ml507 qemu command lines that you use? I spent a good chunk of my
> time trying to get a kernel to boot but has failed so far.
>

>>>
>>> Any update ? I still see the boot failures in next-20181123.
>>
>> Yes, took most of last week's off sorry for the delay. I have finally
>> been able to boot a kernel using your instructions, thanks. The problem
>> is the following call chain:
>>
>> of_platform_serial_probe()
>>  -> serial8250_register_8250_port()
>> -> up->port.uartclk == 0, return -EINVAL
>>  -> irq_dispose_mapping()
>>
>> and then we basically unwind what we just did with
>> of_platform_serial_probe() including disabling the UART's IRQ, comment
>> out the irq_dispose_mapping() and you will have a functional console
>> again. 8250_of.c is clearly not a full replacement for legacy_serial.c
>> (that was a first attempt), so we need to keep that code around. Making
>> the depends even more conditional also does not sound too appealing,
>> because while we have identified mpc85xx as being problematic, who knows
>> about other platforms. So the best I have that does not involve a revert
>> is this below.
>>
>> Ben, Michael, would that sound reasonable to you? It seems to me that
>> there is a million ways to shoot the legacy_serial 8250 registration in
>> the foot in any cases, and having CONFIG_SERIAL_OF_PLATFORM just made it
>> painfully obvious.
> 
> We generally try to avoid changing the device tree from inside Linux,
> it's meant to describe the hardware as we're given it, not the state of
> Linux drivers etc. Perhaps this is an exceptional case but it still
> seems fishy.

Technically this is changing the Linux internal representation of a
Device Tree node reference (device_node), which is a bit away from
actual HW representation.

> 
> I also worry that marking the device node disabled might break something
> else, but that's maybe me being paranoid.

The code as it is today only makes use of device_node pointers/Device
Tree to find out about the UART base address and a bunch of properties,
but it registers the UART as platform_device without making use of the
existing OF infrastructure to do that (historical reasons really).

> 
> I guess I don't really understand how things are supposed to work
> though. We have the 8250 driver and also the OF platform driver, the
> former has already setup the device and then the OF driver just comes
> along and takes over?

When the OF platform driver comes along it tries to register the same
device instance, fails to do so because the port->clk is 0, which the
8250 core thinks is an error, and then it starts unwinding the 8250 port
structure, which in turns steps on the instance that was registered
manually by legacy_serial.c

> 
> eg. in the boot log from the mpc8544ds you see:
> 
>   serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42, base_baud = 115200) is a 
> 16550A
>   printk: console [ttyS0] enabled
>   printk: console [ttyS0] enabled
>   printk: bootconsole [udbg0] disabled
>   printk: bootconsole [udbg0] disabled
>   of_serial: probe of e0004500.serial failed with error -22
> 
> ie. the 8250 core has already setup the device, so there should really
> be nothing to do?
> 
> If the 8250 code could detect that it already has this port registered
> then maybe things would work.
> 
> The patch below works for me with mpc8544ds. Whether it's worth changing
> the 8250 code this much to accomodate legacy_serial 

Re: [PATCH v2 1/6] powerpc: prefer memblock APIs returning virtual address

2018-12-05 Thread Mike Rapoport
On Wed, Dec 05, 2018 at 11:37:44PM +1100, Michael Ellerman wrote:
> Mike Rapoport  writes:
> > On Tue, Dec 04, 2018 at 08:59:41PM +1100, Michael Ellerman wrote:
> >> Hi Mike,
> >> 
> >> Thanks for trying to clean these up.
> >> 
> >> I think a few could be improved though ...
> >> 
> >> Mike Rapoport  writes:
> >> > diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
> >> > index 913bfca..fa884ad 100644
> >> > --- a/arch/powerpc/kernel/paca.c
> >> > +++ b/arch/powerpc/kernel/paca.c
> >> > @@ -42,17 +42,15 @@ static void *__init alloc_paca_data(unsigned long 
> >> > size, unsigned long align,
> >> >  nid = early_cpu_to_node(cpu);
> >> >  }
> >> >  
> >> > -pa = memblock_alloc_base_nid(size, align, limit, nid, 
> >> > MEMBLOCK_NONE);
> >> > -if (!pa) {
> >> > -pa = memblock_alloc_base(size, align, limit);
> >> > -if (!pa)
> >> > -panic("cannot allocate paca data");
> >> > -}
> >> > +ptr = memblock_alloc_try_nid_raw(size, align, 
> >> > MEMBLOCK_LOW_LIMIT,
> >> > + limit, nid);
> >> > +if (!ptr)
> >> > +panic("cannot allocate paca data");
> >>   
> >> The old code doesn't zero, but two of the three callers of
> >> alloc_paca_data() *do* zero the whole allocation, so I'd be happy if we
> >> did it in here instead.
> >
> > I looked at the callers and couldn't tell if zeroing memory in
> > init_lppaca() would be ok.
> > I'll remove the _raw here.
>   
> Thanks.
> 
> >> That would mean we could use memblock_alloc_try_nid() avoiding the need
> >> to panic() manually.
> >
> > Actual, my plan was to remove panic() from all memblock_alloc* and make all
> > callers to check the returned value.
> > I believe it's cleaner and also allows more meaningful panic messages. Not
> > mentioning the reduction of memblock code.
> 
> Hmm, not sure.
> 
> I see ~200 calls to the panicking functions, that seems like a lot of
> work to change all those.

Yeah, I know :)

> And I think I disagree on the "more meaningful panic message". This is a
> perfect example, compare:
> 
>   panic("cannot allocate paca data");
> to:
>   panic("%s: Failed to allocate %llu bytes align=0x%llx nid=%d from=%pa 
> max_addr=%pa\n",
> __func__, (u64)size, (u64)align, nid, _addr, _addr);
> 
> The former is basically useless, whereas the second might at least give
> you a hint as to *why* the allocation failed.

We can easily keep the memblock message, just make it pr_err instead of
panic.
The message at the call site can show where the problem was without the
need to dive into the stack dump.

> I know it's kind of odd for a function to panic() rather than return an
> error, but memblock is kind of special because it's so early in boot.
> Most of these allocations have to succeed to get the system up and
> running.

The downside of having panic() inside some memblock functions is that it
makes the API way too bloated. And, at least currently, it's inconsistent.
For instance memblock_alloc_try_nid_raw() does not panic, but
memblock_alloc_try_nid() does.

When it was about 2 functions and a wrapper, it was perfectly fine, but
since than memblock has three sets of partially overlapping APIs with
endless convenience wrappers.

I believe that patching up ~200 calls is worth the reduction of memblock
API to saner size.

Another thing, the absence of check for return value for memory allocation
is not only odd, but it also makes the code obfuscated.
 
> cheers
> 

-- 
Sincerely yours,
Mike.



Re: [PATCH v2 12/34] dt-bindings: arm: Convert Altera board/soc bindings to json-schema

2018-12-05 Thread Dinh Nguyen



On 12/3/18 3:32 PM, Rob Herring wrote:
> Convert Altera SoC bindings to DT schema format using json-schema.
> 
> Cc: Mark Rutland 
> Cc: Dinh Nguyen 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/altera.txt| 14 -
>  .../devicetree/bindings/arm/altera.yaml   | 20 +++
>  2 files changed, 20 insertions(+), 14 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/altera.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/altera.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/altera.txt 
> b/Documentation/devicetree/bindings/arm/altera.txt
> deleted file mode 100644
> index 558735aacca8..
> --- a/Documentation/devicetree/bindings/arm/altera.txt
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -Altera's SoCFPGA platform device tree bindings
> --
> -
> -Boards with Cyclone 5 SoC:
> -Required root node properties:
> -compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> -
> -Boards with Arria 5 SoC:
> -Required root node properties:
> -compatible = "altr,socfpga-arria5", "altr,socfpga";
> -
> -Boards with Arria 10 SoC:
> -Required root node properties:
> -compatible = "altr,socfpga-arria10", "altr,socfpga";
> diff --git a/Documentation/devicetree/bindings/arm/altera.yaml 
> b/Documentation/devicetree/bindings/arm/altera.yaml
> new file mode 100644
> index ..49e0362ddc11
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/altera.yaml
> @@ -0,0 +1,20 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/altera.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Altera's SoCFPGA platform device tree bindings
> +
> +maintainers:
> +  - Dinh Nguyen 
> +
> +properties:
> +  compatible:
> +items:
> +  - enum:
> +- altr,socfpga-cyclone5
> +- altr,socfpga-arria5
> +- altr,socfpga-arria10
> +  - const: altr,socfpga
> +...
> 

Acked-by: Dinh Nguyen 


Re: [PATCH v2 04/34] dt-bindings: altera: Convert clkmgr binding to json-schema

2018-12-05 Thread Dinh Nguyen



On 12/3/18 3:31 PM, Rob Herring wrote:
> Convert Altera clkmgr to DT schema format using json-schema.
> 
> Cc: Mark Rutland 
> Cc: Dinh Nguyen 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../arm/altera/socfpga-clk-manager.txt| 11 ---
>  .../arm/altera/socfpga-clk-manager.yaml   | 31 +++
>  2 files changed, 31 insertions(+), 11 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
>  create mode 100644 
> Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt 
> b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
> deleted file mode 100644
> index 2c28f1d12f45..
> --- a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -Altera SOCFPGA Clock Manager
> -
> -Required properties:
> -- compatible : "altr,clk-mgr"
> -- reg : Should contain base address and length for Clock Manager
> -
> -Example:
> -  clkmgr@ffd04000 {
> - compatible = "altr,clk-mgr";
> - reg = <0xffd04000 0x1000>;
> - };
> diff --git 
> a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml 
> b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml
> new file mode 100644
> index ..e4131fa42b26
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml
> @@ -0,0 +1,31 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/altera/socfpga-clk-manager.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Altera SOCFPGA Clock Manager
> +
> +maintainers:
> +  - Dinh Nguyen 
> +
> +description: test
> +
> +properties:
> +  compatible:
> +items:
> +  - const: altr,clk-mgr
> +  reg:
> +maxItems: 1
> +
> +required:
> +  - compatible
> +
> +examples:
> +  - |
> +clkmgr@ffd04000 {
> +  compatible = "altr,clk-mgr";
> +  reg = <0xffd04000 0x1000>;
> +};
> +
> +...
> 

Acked-by: Dinh Nguyen 


Re: [PATCH 3/3] arch: remove redundant generic-y defines

2018-12-05 Thread Christoph Hellwig
On Wed, Dec 05, 2018 at 06:44:38AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 05, 2018 at 08:28:06PM +0900, Masahiro Yamada wrote:
> > Now that Kbuild automatically creates asm-generic wrappers for missing
> > mandatory headers, it is redundant to list the same headers in
> > generic-y and mandatory-y.
> > 
> > Suggested-by: Sam Ravnborg 
> > Signed-off-by: Masahiro Yamada 
> 
> Oh, that is very useful, especially as maintainance of those
> generic-y lines has been a mess!
> 
> Acked-by: Christoph Hellwig 

Actually - it seems like you are keeping some generic-y lines, what
is the reason for that?


Re: [PATCH 3/3] arch: remove redundant generic-y defines

2018-12-05 Thread Christoph Hellwig
On Wed, Dec 05, 2018 at 08:28:06PM +0900, Masahiro Yamada wrote:
> Now that Kbuild automatically creates asm-generic wrappers for missing
> mandatory headers, it is redundant to list the same headers in
> generic-y and mandatory-y.
> 
> Suggested-by: Sam Ravnborg 
> Signed-off-by: Masahiro Yamada 

Oh, that is very useful, especially as maintainance of those
generic-y lines has been a mess!

Acked-by: Christoph Hellwig 


[PATCH 3/3] arch: remove redundant generic-y defines

2018-12-05 Thread Masahiro Yamada
Now that Kbuild automatically creates asm-generic wrappers for missing
mandatory headers, it is redundant to list the same headers in
generic-y and mandatory-y.

Suggested-by: Sam Ravnborg 
Signed-off-by: Masahiro Yamada 
---

 arch/alpha/include/uapi/asm/Kbuild  |  5 -
 arch/arc/include/uapi/asm/Kbuild| 23 ---
 arch/arm/include/uapi/asm/Kbuild| 15 ---
 arch/arm64/include/uapi/asm/Kbuild  | 17 -
 arch/c6x/include/uapi/asm/Kbuild| 25 -
 arch/h8300/include/uapi/asm/Kbuild  | 25 -
 arch/hexagon/include/uapi/asm/Kbuild| 22 --
 arch/ia64/include/uapi/asm/Kbuild   |  5 -
 arch/m68k/include/uapi/asm/Kbuild   | 18 --
 arch/microblaze/include/uapi/asm/Kbuild | 24 
 arch/mips/include/uapi/asm/Kbuild   |  1 -
 arch/nds32/include/uapi/asm/Kbuild  | 24 
 arch/nios2/include/uapi/asm/Kbuild  | 24 
 arch/openrisc/include/uapi/asm/Kbuild   | 26 --
 arch/parisc/include/uapi/asm/Kbuild |  5 -
 arch/powerpc/include/uapi/asm/Kbuild|  6 --
 arch/riscv/include/uapi/asm/Kbuild  | 25 -
 arch/s390/include/uapi/asm/Kbuild   | 14 --
 arch/sh/include/uapi/asm/Kbuild | 17 -
 arch/sparc/include/uapi/asm/Kbuild  |  1 -
 arch/unicore32/include/uapi/asm/Kbuild  | 27 ---
 arch/x86/include/uapi/asm/Kbuild|  1 -
 arch/xtensa/include/uapi/asm/Kbuild |  8 
 23 files changed, 358 deletions(-)

diff --git a/arch/alpha/include/uapi/asm/Kbuild 
b/arch/alpha/include/uapi/asm/Kbuild
index 1a5b753..14a2e9a 100644
--- a/arch/alpha/include/uapi/asm/Kbuild
+++ b/arch/alpha/include/uapi/asm/Kbuild
@@ -2,8 +2,3 @@
 include include/uapi/asm-generic/Kbuild.asm
 
 generic-y += bpf_perf_event.h
-generic-y += ipcbuf.h
-generic-y += msgbuf.h
-generic-y += poll.h
-generic-y += sembuf.h
-generic-y += shmbuf.h
diff --git a/arch/arc/include/uapi/asm/Kbuild b/arch/arc/include/uapi/asm/Kbuild
index 170b5db..f53f8e4 100644
--- a/arch/arc/include/uapi/asm/Kbuild
+++ b/arch/arc/include/uapi/asm/Kbuild
@@ -1,29 +1,6 @@
 # UAPI Header export list
 include include/uapi/asm-generic/Kbuild.asm
 
-generic-y += auxvec.h
-generic-y += bitsperlong.h
 generic-y += bpf_perf_event.h
-generic-y += errno.h
-generic-y += fcntl.h
-generic-y += ioctl.h
-generic-y += ioctls.h
-generic-y += ipcbuf.h
 generic-y += kvm_para.h
-generic-y += mman.h
-generic-y += msgbuf.h
-generic-y += param.h
-generic-y += poll.h
-generic-y += posix_types.h
-generic-y += resource.h
-generic-y += sembuf.h
-generic-y += shmbuf.h
-generic-y += siginfo.h
-generic-y += socket.h
-generic-y += sockios.h
-generic-y += stat.h
-generic-y += statfs.h
-generic-y += termbits.h
-generic-y += termios.h
-generic-y += types.h
 generic-y += ucontext.h
diff --git a/arch/arm/include/uapi/asm/Kbuild b/arch/arm/include/uapi/asm/Kbuild
index 4d1cc18..279edb1 100644
--- a/arch/arm/include/uapi/asm/Kbuild
+++ b/arch/arm/include/uapi/asm/Kbuild
@@ -6,19 +6,4 @@ generated-y += unistd-common.h
 generated-y += unistd-oabi.h
 generated-y += unistd-eabi.h
 
-generic-y += bitsperlong.h
 generic-y += bpf_perf_event.h
-generic-y += errno.h
-generic-y += ioctl.h
-generic-y += ipcbuf.h
-generic-y += msgbuf.h
-generic-y += param.h
-generic-y += poll.h
-generic-y += resource.h
-generic-y += sembuf.h
-generic-y += shmbuf.h
-generic-y += siginfo.h
-generic-y += socket.h
-generic-y += sockios.h
-generic-y += termbits.h
-generic-y += termios.h
diff --git a/arch/arm64/include/uapi/asm/Kbuild 
b/arch/arm64/include/uapi/asm/Kbuild
index 6c5adf4..bca548a 100644
--- a/arch/arm64/include/uapi/asm/Kbuild
+++ b/arch/arm64/include/uapi/asm/Kbuild
@@ -2,21 +2,4 @@
 # UAPI Header export list
 include include/uapi/asm-generic/Kbuild.asm
 
-generic-y += errno.h
-generic-y += ioctl.h
-generic-y += ioctls.h
-generic-y += ipcbuf.h
 generic-y += kvm_para.h
-generic-y += mman.h
-generic-y += msgbuf.h
-generic-y += poll.h
-generic-y += resource.h
-generic-y += sembuf.h
-generic-y += shmbuf.h
-generic-y += socket.h
-generic-y += sockios.h
-generic-y += swab.h
-generic-y += termbits.h
-generic-y += termios.h
-generic-y += types.h
-generic-y += siginfo.h
diff --git a/arch/c6x/include/uapi/asm/Kbuild b/arch/c6x/include/uapi/asm/Kbuild
index 26644e1..f53f8e4 100644
--- a/arch/c6x/include/uapi/asm/Kbuild
+++ b/arch/c6x/include/uapi/asm/Kbuild
@@ -1,31 +1,6 @@
 # UAPI Header export list
 include include/uapi/asm-generic/Kbuild.asm
 
-generic-y += auxvec.h
-generic-y += bitsperlong.h
 generic-y += bpf_perf_event.h
-generic-y += errno.h
-generic-y += fcntl.h
-generic-y += ioctl.h
-generic-y += ioctls.h
-generic-y += ipcbuf.h
 generic-y += kvm_para.h
-generic-y += mman.h
-generic-y += msgbuf.h
-generic-y += param.h
-generic-y += poll.h
-generic-y += 

Re: [RFC PATCH] soc: fsl: guts: handle devm_kstrdup() failure

2018-12-05 Thread Li Yang
On Sun, Dec 2, 2018 at 3:07 AM Nicholas Mc Guire  wrote:
>
> devm_kstrdup() may return NULL if internal allocation failed.
> soc_dev_attr.machine  should be checked (although its only use
> in pr_info() would be safe even with a NULL). Therefor
> in the unlikely case of allocation failure, fsl_guts_probe() returns
> -ENOMEM as this allocating failing is an indication of something
> more serious going wrong at system level.
>
> As  machine  is from the device tree which I assume to be RO - if
> that assumption is always correct - a better alternative would be
> to use devm_kstrdup_const() here. That would then simply copy the
> reference to the RO data and not perform any allocation at all.

I think your assumption is correct.  Do you want to send a new and
better version?  :)

>
> Signed-off-by: Nicholas Mc Guire 
> Fixes: a6fc3b698130 ("soc: fsl: add GUTS driver for QorIQ platforms")
> ---
>
> Problem located by experimental coccinelle script
>
> Patch was compile tested with: multi_v7_defconfig (implies FSL_GUTS=y)
>
> Patch is against 4.20-rc4 (localversion-next is next-20181130)
>
>  drivers/soc/fsl/guts.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> index 302e0c8..a0c751b 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -156,8 +156,11 @@ static int fsl_guts_probe(struct platform_device *pdev)
> if (of_property_read_string(root, "model", ))
> of_property_read_string_index(root, "compatible", 0, 
> );
> of_node_put(root);
> -   if (machine)
> +   if (machine) {
> soc_dev_attr.machine = devm_kstrdup(dev, machine, GFP_KERNEL);
> +   if (!soc_dev_attr.machine)
> +   return -ENOMEM;
> +   }
>
> svr = fsl_guts_get_svr();
> soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> --
> 2.1.4
>


Re: pkeys: Reserve PKEY_DISABLE_READ

2018-12-05 Thread Ram Pai
On Wed, Dec 05, 2018 at 08:21:02AM -0800, Andy Lutomirski wrote:
> > On Dec 2, 2018, at 8:02 PM, Ram Pai  wrote:
> >
> >> On Thu, Nov 29, 2018 at 12:37:15PM +0100, Florian Weimer wrote:
> >> * Dave Hansen:
> >>
>  On 11/27/18 3:57 AM, Florian Weimer wrote:
>  I would have expected something that translates PKEY_DISABLE_WRITE |
>  PKEY_DISABLE_READ into PKEY_DISABLE_ACCESS, and also accepts
>  PKEY_DISABLE_ACCESS | PKEY_DISABLE_READ, for consistency with POWER.
> 
>  (My understanding is that PKEY_DISABLE_ACCESS does not disable all
>  access, but produces execute-only memory.)
> >>>
> >>> Correct, it disables all data access, but not execution.
> >>
> >> So I would expect something like this (completely untested, I did not
> >> even compile this):
> >
> >
> > Ok. I re-read through the entire email thread to understand the problem and
> > the proposed solution. Let me summarize it below. Lets see if we are on the 
> > same
> > plate.
> >
> > So the problem is as follows:
> >
> > Currently the kernel supports  'disable-write'  and 'disable-access'.
> >
> > On x86, cpu supports 'disable-write' and 'disable-access'. This
> > matches with what the kernel supports. All good.
> >
> > However on power, cpu supports 'disable-read' too. Since userspace can
> > program the cpu directly, userspace has the ability to set
> > 'disable-read' too.  This can lead to inconsistency between the kernel
> > and the userspace.
> >
> > We want the kernel to match userspace on all architectures.
> >
> > Proposed Solution:
> >
> > Enhance the kernel to understand 'disable-read', and facilitate 
> > architectures
> > that understand 'disable-read' to allow it.
> >
> > Also explicitly define the semantics of disable-access  as
> > 'disable-read and disable-write'
> >
> > Did I get this right?  Assuming I did, the implementation has to do
> > the following --
> >
> >On power, sys_pkey_alloc() should succeed if the init_val
> >is PKEY_DISABLE_READ, PKEY_DISABLE_WRITE, PKEY_DISABLE_ACCESS
> >or any combination of the three.
> >
> >On x86, sys_pkey_alloc() should succeed if the init_val is
> >PKEY_DISABLE_WRITE or PKEY_DISABLE_ACCESS or PKEY_DISABLE_READ
> >or any combination of the three, except  PKEY_DISABLE_READ
> >  specified all by itself.
> >
> >On all other arches, none of the flags are supported.
> 
> I don’t really love having a situation where you can use different
> flag combinations to refer to the same mode.

true. But it is a side-effect of x86 cpu implicitly defining
'disable-access' as a combination of 'disable-read' and 'disable_write'.
In other words, if you disable-access on a pte on x86, you are
automatically disabling read and disabling write on that page.
The software/kernel just happens to explicitly capture that implicit
behavior.

> 
> Also, we should document the effect these flags have on execute permission.

Actually none of the above flags, interact with execute permission. They
operate independently; both on x86 and on POWER.  But yes, this
statement needs to be documented somewhere.

RP



Re: pkeys: Reserve PKEY_DISABLE_READ

2018-12-05 Thread Ram Pai
On Wed, Dec 05, 2018 at 02:00:59PM +0100, Florian Weimer wrote:
> * Ram Pai:
> 
> > Ok. here is a patch, compiled but not tested. See if this meets the
> > specifications.
> >
> > ---
> >
> > commit 3dc06e73f3795921265d5d1d935e428deab01616
> > Author: Ram Pai 
> > Date:   Tue Dec 4 00:04:11 2018 -0500
> >
> > pkeys: add support of PKEY_DISABLE_READ
> 
> Thanks.  In the x86 code, the translation of PKEY_DISABLE_READ |
> PKEY_DISABLE_WRITE to PKEY_DISABLE_ACCESS appears to be missing.  I
> believe the existing code produces PKEY_DISABLE_WRITE, which is wrong.

ah. yes. good point.

> 
> Rest looks okay to me (again not tested).

thanks,
RP



Re: [PATCH] soc/fsl/qe: fix err handling of ucc_of_parse_tdm

2018-12-05 Thread Li Yang
On Thu, Nov 22, 2018 at 2:42 PM Yi Wang  wrote:
>
> From: Wen Yang 
>
> Currently there are 2 problems with the ucc_of_parse_tdm function:
> 1,a possible null pointer dereference in ucc_of_parse_tdm,
> detected by the semantic patch deref_null.cocci,
> with the following warning:
> drivers/soc/fsl/qe/qe_tdm.c:177:21-24: ERROR: pdev is NULL but dereferenced.
> 2,dev gets modified, so in any case that devm_iounmap() will fail even when
> the new pdev is valid, because the iomap was done with a different pdev.
> This patch fixes them.

While we are at this, I think this logic need more serious fixing.  I
see there is no driver bind with the "fsl,t1040-qe-si" or
"fsl,t1040-qe-siram" device.  So allocating resources using devm_*()
with these devices won't provide a cleanup path for these resources
when the caller fails.  I think we should probably allocate resource
under device of caller (e.g. ucc-hdlc), so that when caller probe
fails or is removed it will trigger the cleanup.

>
> Suggested-by: Christophe LEROY 
> Signed-off-by: Wen Yang 
> CC: Julia Lawall 
> CC: Zhao Qiang 
> ---
>  drivers/soc/fsl/qe/qe_tdm.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe_tdm.c b/drivers/soc/fsl/qe/qe_tdm.c
> index f78c346..9a29f0b 100644
> --- a/drivers/soc/fsl/qe/qe_tdm.c
> +++ b/drivers/soc/fsl/qe/qe_tdm.c
> @@ -47,7 +47,7 @@ int ucc_of_parse_tdm(struct device_node *np, struct ucc_tdm 
> *utdm,
> struct resource *res;
> struct device_node *np2;
> static int siram_init_flag;
> -   struct platform_device *pdev;
> +   struct platform_device *pdev_si, *pdev_siram;
>
> sprop = of_get_property(np, "fsl,rx-sync-clock", NULL);
> if (sprop) {
> @@ -129,16 +129,16 @@ int ucc_of_parse_tdm(struct device_node *np, struct 
> ucc_tdm *utdm,
> if (!np2)
> return -EINVAL;
>
> -   pdev = of_find_device_by_node(np2);
> -   if (!pdev) {
> +   pdev_si = of_find_device_by_node(np2);
> +   if (!pdev_si) {
> pr_err("%pOFn: failed to lookup pdev\n", np2);
> of_node_put(np2);
> return -EINVAL;
> }
>
> of_node_put(np2);
> -   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -   utdm->si_regs = devm_ioremap_resource(>dev, res);
> +   res = platform_get_resource(pdev_si, IORESOURCE_MEM, 0);
> +   utdm->si_regs = devm_ioremap_resource(_si->dev, res);
> if (IS_ERR(utdm->si_regs)) {
> ret = PTR_ERR(utdm->si_regs);
> goto err_miss_siram_property;
> @@ -150,8 +150,8 @@ int ucc_of_parse_tdm(struct device_node *np, struct 
> ucc_tdm *utdm,
> goto err_miss_siram_property;
> }
>
> -   pdev = of_find_device_by_node(np2);
> -   if (!pdev) {
> +   pdev_siram = of_find_device_by_node(np2);
> +   if (!pdev_siram) {
> ret = -EINVAL;
> pr_err("%pOFn: failed to lookup pdev\n", np2);
> of_node_put(np2);
> @@ -159,8 +159,8 @@ int ucc_of_parse_tdm(struct device_node *np, struct 
> ucc_tdm *utdm,
> }
>
> of_node_put(np2);
> -   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -   utdm->siram = devm_ioremap_resource(>dev, res);
> +   res = platform_get_resource(pdev_siram, IORESOURCE_MEM, 0);
> +   utdm->siram = devm_ioremap_resource(_siram->dev, res);
> if (IS_ERR(utdm->siram)) {
> ret = PTR_ERR(utdm->siram);
> goto err_miss_siram_property;
> @@ -174,7 +174,7 @@ int ucc_of_parse_tdm(struct device_node *np, struct 
> ucc_tdm *utdm,
> return ret;
>
>  err_miss_siram_property:
> -   devm_iounmap(>dev, utdm->si_regs);
> +   devm_iounmap(_si->dev, utdm->si_regs);
> return ret;
>  }
>  EXPORT_SYMBOL(ucc_of_parse_tdm);
> --
> 2.9.5
>


Re: [PATCH] tty: Use of_node_name_{eq,prefix} for node name comparisons

2018-12-05 Thread David Miller
From: Rob Herring 
Date: Wed,  5 Dec 2018 13:50:43 -0600

> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
> 
> For hvc, the code can also be simplified by using of_stdout pointer
> instead of searching again for the stdout node.
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Greg Kroah-Hartman 
> Cc: Jiri Slaby 
> Cc: "David S. Miller" 
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ser...@vger.kernel.org
> Cc: sparcli...@vger.kernel.org
> Signed-off-by: Rob Herring 

Acked-by: David S. Miller 


[PATCH] ASoC: Use of_node_name_eq for node name comparisons

2018-12-05 Thread Rob Herring
Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.

For the FSL ASoC card, the full node names appear to be "ssi", "esai",
and "sai", so there's not any reason to use strstr and of_node_name_eq
can be used instead.

Cc: Timur Tabi 
Cc: Nicolin Chen 
Cc: Xiubo Li 
Cc: Fabio Estevam 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Rob Herring 
---
 sound/soc/fsl/fsl-asoc-card.c   | 6 +++---
 sound/soc/generic/simple-scu-card.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 44433b20435c..81f2fe2c6d23 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -571,17 +571,17 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
}
 
/* Common settings for corresponding Freescale CPU DAI driver */
-   if (strstr(cpu_np->name, "ssi")) {
+   if (of_node_name_eq(cpu_np, "ssi")) {
/* Only SSI needs to configure AUDMUX */
ret = fsl_asoc_card_audmux_init(np, priv);
if (ret) {
dev_err(>dev, "failed to init audmux\n");
goto asrc_fail;
}
-   } else if (strstr(cpu_np->name, "esai")) {
+   } else if (of_node_name_eq(cpu_np, "esai")) {
priv->cpu_priv.sysclk_id[1] = ESAI_HCKT_EXTAL;
priv->cpu_priv.sysclk_id[0] = ESAI_HCKR_EXTAL;
-   } else if (strstr(cpu_np->name, "sai")) {
+   } else if (of_node_name_eq(cpu_np, "sai")) {
priv->cpu_priv.sysclk_id[1] = FSL_SAI_CLK_MAST1;
priv->cpu_priv.sysclk_id[0] = FSL_SAI_CLK_MAST1;
}
diff --git a/sound/soc/generic/simple-scu-card.c 
b/sound/soc/generic/simple-scu-card.c
index 85b46f0eae0f..e9a1acffcf5b 100644
--- a/sound/soc/generic/simple-scu-card.c
+++ b/sound/soc/generic/simple-scu-card.c
@@ -216,7 +216,7 @@ static int asoc_simple_card_parse_of(struct 
simple_card_data *priv)
i = 0;
for_each_child_of_node(node, np) {
is_fe = false;
-   if (strcmp(np->name, PREFIX "cpu") == 0)
+   if (of_node_name_eq(np, PREFIX "cpu"))
is_fe = true;
 
ret = asoc_simple_card_dai_link_of(np, priv, daifmt, i, is_fe);
-- 
2.19.1



[PATCH] ALSA: soundbus: Remove direct OF name and type accesses

2018-12-05 Thread Rob Herring
Convert soundbus uevent and sysfs OF node name and device type usage to
use printf specifier and helper functions instead of directly accessing
the name and type pointers. This will allow the eventual removal of the
pointers.

Cc: Johannes Berg 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: alsa-de...@alsa-project.org
Signed-off-by: Rob Herring 
---
 sound/aoa/soundbus/core.c  |  2 +-
 sound/aoa/soundbus/sysfs.c | 34 +-
 2 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/sound/aoa/soundbus/core.c b/sound/aoa/soundbus/core.c
index f3076a3f7f2f..065d3a55725e 100644
--- a/sound/aoa/soundbus/core.c
+++ b/sound/aoa/soundbus/core.c
@@ -74,7 +74,7 @@ static int soundbus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
of = _dev->ofdev;
 
/* stuff we want to pass to /sbin/hotplug */
-   retval = add_uevent_var(env, "OF_NAME=%s", of->dev.of_node->name);
+   retval = add_uevent_var(env, "OF_NAME=%pOFn", of->dev.of_node);
if (retval)
return retval;
 
diff --git a/sound/aoa/soundbus/sysfs.c b/sound/aoa/soundbus/sysfs.c
index 81da020bddef..a2d55e15afbb 100644
--- a/sound/aoa/soundbus/sysfs.c
+++ b/sound/aoa/soundbus/sysfs.c
@@ -1,18 +1,10 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 
 #include 
 /* FIX UP */
 #include "soundbus.h"
 
-#define soundbus_config_of_attr(field, format_string)  \
-static ssize_t \
-field##_show (struct device *dev, struct device_attribute *attr,   \
-  char *buf)   \
-{  \
-   struct soundbus_dev *mdev = to_soundbus_device (dev);   \
-   return sprintf (buf, format_string, mdev->ofdev.dev.of_node->field); \
-}
-
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -25,17 +17,33 @@ static ssize_t modalias_show(struct device *dev, struct 
device_attribute *attr,
strcat(buf, "\n");
length = strlen(buf);
} else {
-   length = sprintf(buf, "of:N%sT%s\n",
-of->dev.of_node->name, of->dev.of_node->type);
+   length = sprintf(buf, "of:N%pOFn%c%s\n",
+of->dev.of_node, 'T',
+ of_node_get_device_type(of->dev.of_node));
}
 
return length;
 }
 static DEVICE_ATTR_RO(modalias);
 
-soundbus_config_of_attr (name, "%s\n");
+static ssize_t name_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   struct soundbus_dev *sdev = to_soundbus_device(dev);
+   struct platform_device *of = >ofdev;
+
+   return sprintf(buf, "%pOFn\n", of->dev.of_node);
+}
 static DEVICE_ATTR_RO(name);
-soundbus_config_of_attr (type, "%s\n");
+
+static ssize_t type_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   struct soundbus_dev *sdev = to_soundbus_device(dev);
+   struct platform_device *of = >ofdev;
+
+   return sprintf(buf, "%s\n", of_node_get_device_type(of->dev.of_node));
+}
 static DEVICE_ATTR_RO(type);
 
 struct attribute *soundbus_dev_attrs[] = {
-- 
2.19.1



[PATCH] ALSA: Use of_node_name_eq for node name comparisons

2018-12-05 Thread Rob Herring
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: Johannes Berg 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: alsa-de...@alsa-project.org
Signed-off-by: Rob Herring 
---
 sound/aoa/fabrics/layout.c   | 2 +-
 sound/aoa/soundbus/i2sbus/core.c | 6 +++---
 sound/ppc/pmac.c | 4 ++--
 sound/ppc/tumbler.c  | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
index 3a23fd032611..8797d42e2b76 100644
--- a/sound/aoa/fabrics/layout.c
+++ b/sound/aoa/fabrics/layout.c
@@ -776,7 +776,7 @@ static int check_codec(struct aoa_codec *codec,
struct codec_connection *cc;
 
/* if the codec has a 'codec' node, we require a reference */
-   if (codec->node && (strcmp(codec->node->name, "codec") == 0)) {
+   if (of_node_name_eq(codec->node, "codec")) {
snprintf(propname, sizeof(propname),
 "platform-%s-codec-ref", codec->name);
ref = of_get_property(ldev->sound, propname, NULL);
diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c
index bd7c5029fc59..c3f57a3fb1a5 100644
--- a/sound/aoa/soundbus/i2sbus/core.c
+++ b/sound/aoa/soundbus/i2sbus/core.c
@@ -154,7 +154,7 @@ static int i2sbus_add_dev(struct macio_dev *macio,
  struct device_node *np)
 {
struct i2sbus_dev *dev;
-   struct device_node *child = NULL, *sound = NULL;
+   struct device_node *child, *sound = NULL;
struct resource *r;
int i, layout = 0, rlen, ok = force;
char node_name[6];
@@ -177,8 +177,8 @@ static int i2sbus_add_dev(struct macio_dev *macio,
return 0;
 
i = 0;
-   while ((child = of_get_next_child(np, child))) {
-   if (strcmp(child->name, "sound") == 0) {
+   for_each_child_of_node(np, child) {
+   if (of_node_name_eq(child, "sound")) {
i++;
sound = child;
}
diff --git a/sound/ppc/pmac.c b/sound/ppc/pmac.c
index 48dd44f8e914..d692e4070167 100644
--- a/sound/ppc/pmac.c
+++ b/sound/ppc/pmac.c
@@ -908,7 +908,7 @@ static void detect_byte_swap(struct snd_pmac *chip)
 
/* if seems that Keylargo can't byte-swap  */
for (mio = chip->node->parent; mio; mio = mio->parent) {
-   if (strcmp(mio->name, "mac-io") == 0) {
+   if (of_node_name_eq(mio, "mac-io")) {
if (of_device_is_compatible(mio, "Keylargo"))
chip->can_byte_swap = 0;
break;
@@ -1313,7 +1313,7 @@ int snd_pmac_new(struct snd_card *card, struct snd_pmac 
**chip_return)
} else if (chip->is_pbook_G3) {
struct device_node* mio;
for (mio = chip->node->parent; mio; mio = mio->parent) {
-   if (strcmp(mio->name, "mac-io") == 0) {
+   if (of_node_name_eq(mio, "mac-io")) {
struct resource r;
if (of_address_to_resource(mio, 0, ) == 0)
chip->macio_base =
diff --git a/sound/ppc/tumbler.c b/sound/ppc/tumbler.c
index 0779a2912237..6d7cce95 100644
--- a/sound/ppc/tumbler.c
+++ b/sound/ppc/tumbler.c
@@ -1365,8 +1365,8 @@ int snd_pmac_tumbler_init(struct snd_pmac *chip)
mix->anded_reset = 0;
mix->reset_on_sleep = 1;
 
-   for (np = chip->node->child; np; np = np->sibling) {
-   if (!strcmp(np->name, "sound")) {
+   for_each_child_of_node(chip->node, np) {
+   if (of_node_name_eq(np, "sound")) {
if (of_get_property(np, "has-anded-reset", NULL))
mix->anded_reset = 1;
if (of_get_property(np, "layout-id", NULL))
-- 
2.19.1



[PATCH] tty: Use of_node_name_{eq,prefix} for node name comparisons

2018-12-05 Thread Rob Herring
Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.

For hvc, the code can also be simplified by using of_stdout pointer
instead of searching again for the stdout node.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: "David S. Miller" 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ser...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Signed-off-by: Rob Herring 
---
 drivers/tty/hvc/hvc_opal.c  |  2 +-
 drivers/tty/hvc/hvc_vio.c   | 11 +--
 drivers/tty/serial/pmac_zilog.c |  4 ++--
 drivers/tty/serial/suncore.c|  8 
 drivers/tty/serial/sunsu.c  |  4 ++--
 5 files changed, 10 insertions(+), 19 deletions(-)

diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
index 77baf895108f..c66412566efc 100644
--- a/drivers/tty/hvc/hvc_opal.c
+++ b/drivers/tty/hvc/hvc_opal.c
@@ -353,7 +353,7 @@ void __init hvc_opal_init_early(void)
if (!opal)
return;
for_each_child_of_node(opal, np) {
-   if (!strcmp(np->name, "serial")) {
+   if (of_node_name_eq(np, "serial")) {
stdout_node = np;
break;
}
diff --git a/drivers/tty/hvc/hvc_vio.c b/drivers/tty/hvc/hvc_vio.c
index 59eaa620bf13..6de6d4a1a221 100644
--- a/drivers/tty/hvc/hvc_vio.c
+++ b/drivers/tty/hvc/hvc_vio.c
@@ -371,20 +371,11 @@ device_initcall(hvc_vio_init); /* after 
drivers/tty/hvc/hvc_console.c */
 void __init hvc_vio_init_early(void)
 {
const __be32 *termno;
-   const char *name;
const struct hv_ops *ops;
 
/* find the boot console from /chosen/stdout */
-   if (!of_stdout)
-   return;
-   name = of_get_property(of_stdout, "name", NULL);
-   if (!name) {
-   printk(KERN_WARNING "stdout node missing 'name' property!\n");
-   return;
-   }
-
/* Check if it's a virtual terminal */
-   if (strncmp(name, "vty", 3) != 0)
+   if (!of_node_name_prefix(of_stdout, "vty"))
return;
termno = of_get_property(of_stdout, "reg", NULL);
if (termno == NULL)
diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
index a9d40988e1c8..bcb5bf70534e 100644
--- a/drivers/tty/serial/pmac_zilog.c
+++ b/drivers/tty/serial/pmac_zilog.c
@@ -1648,9 +1648,9 @@ static int __init pmz_probe(void)
 */
node_a = node_b = NULL;
for (np = NULL; (np = of_get_next_child(node_p, np)) != NULL;) {
-   if (strncmp(np->name, "ch-a", 4) == 0)
+   if (of_node_name_prefix(np, "ch-a"))
node_a = of_node_get(np);
-   else if (strncmp(np->name, "ch-b", 4) == 0)
+   else if (of_node_name_prefix(np, "ch-b"))
node_b = of_node_get(np);
}
if (!node_a && !node_b) {
diff --git a/drivers/tty/serial/suncore.c b/drivers/tty/serial/suncore.c
index 70a4ea4eaa6e..661e8b151366 100644
--- a/drivers/tty/serial/suncore.c
+++ b/drivers/tty/serial/suncore.c
@@ -89,14 +89,14 @@ void sunserial_console_termios(struct console *con, struct 
device_node *uart_dp)
int baud, bits, stop, cflag;
char parity;
 
-   if (!strcmp(uart_dp->name, "rsc") ||
-   !strcmp(uart_dp->name, "rsc-console") ||
-   !strcmp(uart_dp->name, "rsc-control")) {
+   if (of_node_name_eq(uart_dp, "rsc") ||
+   of_node_name_eq(uart_dp, "rsc-console") ||
+   of_node_name_eq(uart_dp, "rsc-control")) {
mode = of_get_property(uart_dp,
   "ssp-console-modes", NULL);
if (!mode)
mode = "115200,8,n,1,-";
-   } else if (!strcmp(uart_dp->name, "lom-console")) {
+   } else if (of_node_name_eq(uart_dp, "lom-console")) {
mode = "9600,8,n,1,-";
} else {
struct device_node *dp;
diff --git a/drivers/tty/serial/sunsu.c b/drivers/tty/serial/sunsu.c
index 6cf3e9b0728f..8ed60ccd45fb 100644
--- a/drivers/tty/serial/sunsu.c
+++ b/drivers/tty/serial/sunsu.c
@@ -1482,8 +1482,8 @@ static int su_probe(struct platform_device *op)
up->port.ops = _pops;
 
ignore_line = false;
-   if (!strcmp(dp->name, "rsc-console") ||
-   !strcmp(dp->name, "lom-console"))
+   if (of_node_name_eq(dp, "rsc-console") ||
+   of_node_name_eq(dp, "lom-console"))
ignore_line = true;
 
sunserial_console_match(SUNSU_CONSOLE(), dp,
-- 
2.19.1



[PATCH] PCI: Use of_node_name_eq for node name comparisons

2018-12-05 Thread Rob Herring
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: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Bjorn Helgaas 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Rob Herring 
---
 drivers/pci/hotplug/rpaphp_core.c | 2 +-
 drivers/pci/of.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/hotplug/rpaphp_core.c 
b/drivers/pci/hotplug/rpaphp_core.c
index bcd5d357ca23..7697d9c92b98 100644
--- a/drivers/pci/hotplug/rpaphp_core.c
+++ b/drivers/pci/hotplug/rpaphp_core.c
@@ -354,7 +354,7 @@ int rpaphp_add_slot(struct device_node *dn)
const int *indexes, *names, *types, *power_domains;
char *name, *type;
 
-   if (!dn->name || strcmp(dn->name, "pci"))
+   if (!of_node_name_eq(dn, "pci"))
return 0;
 
/* If this is not a hotplug slot, return without doing anything. */
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 4c4217d0c3f1..3d32da15c215 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -113,7 +113,7 @@ struct device_node *of_pci_find_child_device(struct 
device_node *parent,
 * a fake root for all functions of a multi-function
 * device we go down them as well.
 */
-   if (!strcmp(node->name, "multifunc-device")) {
+   if (of_node_name_eq(node, "multifunc-device")) {
for_each_child_of_node(node, node2) {
if (__of_pci_pci_compare(node2, devfn)) {
of_node_put(node);
-- 
2.19.1



[PATCH] macintosh: Use of_node_name_{eq, prefix} for node name comparisons

2018-12-05 Thread Rob Herring
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 
---
 drivers/macintosh/ans-lcd.c   |  2 +-
 drivers/macintosh/macio_asic.c| 33 +++
 drivers/macintosh/rack-meter.c| 13 -
 drivers/macintosh/via-pmu.c   |  4 +--
 drivers/macintosh/windfarm_lm87_sensor.c  |  4 +--
 drivers/macintosh/windfarm_smu_controls.c |  4 +--
 drivers/macintosh/windfarm_smu_sensors.c  |  2 +-
 7 files changed, 30 insertions(+), 32 deletions(-)

diff --git a/drivers/macintosh/ans-lcd.c b/drivers/macintosh/ans-lcd.c
index c8e078b911c7..ef0c2366cf59 100644
--- a/drivers/macintosh/ans-lcd.c
+++ b/drivers/macintosh/ans-lcd.c
@@ -160,7 +160,7 @@ anslcd_init(void)
struct device_node* node;
 
node = of_find_node_by_name(NULL, "lcd");
-   if (!node || !node->parent || strcmp(node->parent->name, "gc")) {
+   if (!node || !of_node_name_eq(node->parent, "gc")) {
of_node_put(node);
return -ENODEV;
}
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index bc8418801224..3543a82081de 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -190,11 +190,11 @@ static int macio_resource_quirks(struct device_node *np, 
struct resource *res,
return 0;
 
/* Grand Central has too large resource 0 on some machines */
-   if (index == 0 && !strcmp(np->name, "gc"))
+   if (index == 0 && of_node_name_eq(np, "gc"))
res->end = res->start + 0x1;
 
/* Airport has bogus resource 2 */
-   if (index >= 2 && !strcmp(np->name, "radio"))
+   if (index >= 2 && of_node_name_eq(np, "radio"))
return 1;
 
 #ifndef CONFIG_PPC64
@@ -207,20 +207,20 @@ static int macio_resource_quirks(struct device_node *np, 
struct resource *res,
 * level of hierarchy, but I don't really feel the need
 * for it
 */
-   if (!strcmp(np->name, "escc"))
+   if (of_node_name_eq(np, "escc"))
return 1;
 
/* ESCC has bogus resources >= 3 */
-   if (index >= 3 && !(strcmp(np->name, "ch-a") &&
-   strcmp(np->name, "ch-b")))
+   if (index >= 3 && (of_node_name_eq(np, "ch-a") ||
+  of_node_name_eq(np, "ch-b")))
return 1;
 
/* Media bay has too many resources, keep only first one */
-   if (index > 0 && !strcmp(np->name, "media-bay"))
+   if (index > 0 && of_node_name_eq(np, "media-bay"))
return 1;
 
/* Some older IDE resources have bogus sizes */
-   if (!strcmp(np->name, "IDE") || !strcmp(np->name, "ATA") ||
+   if (of_node_name_eq(np, "IDE") || of_node_name_eq(np, "ATA") ||
of_node_is_type(np, "ide") || of_node_is_type(np, "ata")) {
if (index == 0 && (res->end - res->start) > 0xfff)
res->end = res->start + 0xfff;
@@ -260,7 +260,7 @@ static void macio_add_missing_resources(struct macio_dev 
*dev)
irq_base = 64;
 
/* Fix SCC */
-   if (strcmp(np->name, "ch-a") == 0) {
+   if (of_node_name_eq(np, "ch-a")) {
macio_create_fixup_irq(dev, 0, 15 + irq_base);
macio_create_fixup_irq(dev, 1,  4 + irq_base);
macio_create_fixup_irq(dev, 2,  5 + irq_base);
@@ -268,18 +268,18 @@ static void macio_add_missing_resources(struct macio_dev 
*dev)
}
 
/* Fix media-bay */
-   if (strcmp(np->name, "media-bay") == 0) {
+   if (of_node_name_eq(np, "media-bay")) {
macio_create_fixup_irq(dev, 0, 29 + irq_base);
printk(KERN_INFO "macio: fixed media-bay irq on gatwick\n");
}
 
/* Fix left media bay childs */
-   if (dev->media_bay != NULL && strcmp(np->name, "floppy") == 0) {
+   if (dev->media_bay != NULL && of_node_name_eq(np, "floppy")) {
macio_create_fixup_irq(dev, 0, 19 + irq_base);
macio_create_fixup_irq(dev, 1,  1 + irq_base);
printk(KERN_INFO "macio: fixed left floppy irqs\n");
}
-   if (dev->media_bay != NULL && strcasecmp(np->name, "ata4") == 0) {
+   if (dev->media_bay != NULL && of_node_name_eq(np, "ata4")) {
macio_create_fixup_irq(dev, 0, 14 + irq_base);
macio_create_fixup_irq(dev, 0,  3 

[PATCH] ide: Use of_node_name_eq for node name comparisons

2018-12-05 Thread Rob Herring
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 
---
 drivers/ide/pmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
index c5b902b86b44..ec46aa84d18d 100644
--- a/drivers/ide/pmac.c
+++ b/drivers/ide/pmac.c
@@ -1045,7 +1045,7 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, 
struct ide_hw *hw)
d.port_ops = _ide_ata4_port_ops;
d.udma_mask = ATA_UDMA5;
} else if (of_device_is_compatible(np, "keylargo-ata")) {
-   if (strcmp(np->name, "ata-4") == 0) {
+   if (of_node_name_eq(np, "ata-4")) {
pmif->kind = controller_kl_ata4;
d.port_ops = _ide_ata4_port_ops;
d.udma_mask = ATA_UDMA4;
-- 
2.19.1



[PATCH] i2c: powermac: Use of_node_name_eq for node name comparisons

2018-12-05 Thread Rob Herring
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: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linux-...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Rob Herring 
---
 drivers/i2c/busses/i2c-powermac.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-powermac.c 
b/drivers/i2c/busses/i2c-powermac.c
index f6f4ed8afc93..281113c28314 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -229,9 +229,9 @@ static u32 i2c_powermac_get_addr(struct i2c_adapter *adap,
return (be32_to_cpup(prop) & 0xff) >> 1;
 
/* Now handle some devices with missing "reg" properties */
-   if (!strcmp(node->name, "cereal"))
+   if (of_node_name_eq(node, "cereal"))
return 0x60;
-   else if (!strcmp(node->name, "deq"))
+   else if (of_node_name_eq(node, "deq"))
return 0x34;
 
dev_warn(>dev, "No i2c address for %pOF\n", node);
@@ -304,7 +304,7 @@ static bool i2c_powermac_get_type(struct i2c_adapter *adap,
}
 
/* Now look for known workarounds */
-   if (!strcmp(node->name, "deq")) {
+   if (of_node_name_eq(node, "deq")) {
/* Apple uses address 0x34 for TAS3001 and 0x35 for TAS3004 */
if (addr == 0x34) {
snprintf(type, type_size, "MAC,tas3001");
@@ -331,7 +331,7 @@ static void i2c_powermac_register_devices(struct 
i2c_adapter *adap,
 * case we skip this function completely as the device-tree will
 * not contain anything useful.
 */
-   if (!strcmp(adap->dev.of_node->name, "via-pmu"))
+   if (of_node_name_eq(adap->dev.of_node, "via-pmu"))
return;
 
for_each_child_of_node(adap->dev.of_node, node) {
-- 
2.19.1



[PATCH] powerpc: Use of_node_name_eq for node name comparisons

2018-12-05 Thread Rob Herring
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 
---
 arch/powerpc/kernel/legacy_serial.c  |  7 +++--
 arch/powerpc/platforms/44x/warp.c|  4 +--
 arch/powerpc/platforms/52xx/efika.c  |  6 ++---
 arch/powerpc/platforms/cell/setup.c  |  2 +-
 arch/powerpc/platforms/cell/spu_manage.c | 10 ++--
 arch/powerpc/platforms/chrp/setup.c  |  5 +---
 arch/powerpc/platforms/powermac/feature.c| 11 
 arch/powerpc/platforms/powermac/low_i2c.c|  4 +--
 arch/powerpc/platforms/powermac/pci.c| 27 
 arch/powerpc/platforms/powermac/pfunc_base.c |  7 +++--
 arch/powerpc/platforms/powermac/pic.c|  4 +--
 arch/powerpc/platforms/powermac/setup.c  | 10 ++--
 arch/powerpc/platforms/powermac/udbg_scc.c   |  2 +-
 arch/powerpc/platforms/powernv/opal.c|  2 +-
 arch/powerpc/platforms/pseries/setup.c   |  2 +-
 15 files changed, 39 insertions(+), 64 deletions(-)

diff --git a/arch/powerpc/kernel/legacy_serial.c 
b/arch/powerpc/kernel/legacy_serial.c
index 2a6f339e92cd..3343f9005ddc 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -398,8 +398,7 @@ void __init find_legacy_serial_ports(void)
/* Next, fill our array with ISA ports */
for_each_node_by_type(np, "serial") {
struct device_node *isa = of_get_parent(np);
-   if (isa && (!strcmp(isa->name, "isa") ||
-   !strcmp(isa->name, "lpc"))) {
+   if (of_node_name_eq(isa, "isa") || of_node_name_eq(isa, "lpc")) 
{
if (of_device_is_available(np)) {
index = add_legacy_isa_port(np, isa);
if (index >= 0 && np == stdout)
@@ -413,11 +412,11 @@ void __init find_legacy_serial_ports(void)
/* Next, try to locate PCI ports */
for (np = NULL; (np = of_find_all_nodes(np));) {
struct device_node *pci, *parent = of_get_parent(np);
-   if (parent && !strcmp(parent->name, "isa")) {
+   if (of_node_name_eq(parent, "isa")) {
of_node_put(parent);
continue;
}
-   if (strcmp(np->name, "serial") &&
+   if (!of_node_name_eq(np, "serial") &&
!of_node_is_type(np, "serial")) {
of_node_put(parent);
continue;
diff --git a/arch/powerpc/platforms/44x/warp.c 
b/arch/powerpc/platforms/44x/warp.c
index a886c2c22097..533c512ba5e1 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -179,9 +179,9 @@ static int pika_setup_leds(void)
}
 
for_each_child_of_node(np, child)
-   if (strcmp(child->name, "green") == 0)
+   if (of_node_name_eq(child, "green"))
green_led = of_get_gpio(child, 0);
-   else if (strcmp(child->name, "red") == 0)
+   else if (of_node_name_eq(child, "red"))
red_led = of_get_gpio(child, 0);
 
of_node_put(np);
diff --git a/arch/powerpc/platforms/52xx/efika.c 
b/arch/powerpc/platforms/52xx/efika.c
index 1ecbf176d35a..61538869e88a 100644
--- a/arch/powerpc/platforms/52xx/efika.c
+++ b/arch/powerpc/platforms/52xx/efika.c
@@ -82,11 +82,9 @@ static void __init efika_pcisetup(void)
return;
}
 
-   for (pcictrl = NULL;;) {
-   pcictrl = of_get_next_child(root, pcictrl);
-   if ((pcictrl == NULL) || (strcmp(pcictrl->name, "pci") == 0))
+   for_each_child_of_node(root, pcictrl)
+   if (of_node_name_eq(pcictrl, "pci"))
break;
-   }
 
of_node_put(root);
 
diff --git a/arch/powerpc/platforms/cell/setup.c 
b/arch/powerpc/platforms/cell/setup.c
index 902d527d043f..e2e1371a71e2 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -131,7 +131,7 @@ static int cell_setup_phb(struct pci_controller *phb)
 
np = phb->dn;
model = of_get_property(np, "model", NULL);
-   if (model == NULL || strcmp(np->name, "pci"))
+   if (model == NULL || !of_node_name_eq(np, "pci"))
return 0;
 
/* Setup workarounds for spider */
diff --git a/arch/powerpc/platforms/cell/spu_manage.c 
b/arch/powerpc/platforms/cell/spu_manage.c
index f7e36373f6e0..bed935c51ec2 100644
--- a/arch/powerpc/platforms/cell/spu_manage.c
+++ b/arch/powerpc/platforms/cell/spu_manage.c
@@ 

[PATCH] powerpc: pseries: pmem: Convert to using %pOFn instead of device_node.name

2018-12-05 Thread Rob Herring
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 
---
 arch/powerpc/platforms/pseries/pmem.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/pmem.c 
b/arch/powerpc/platforms/pseries/pmem.c
index a27f40eb57b1..27f0a915c8a9 100644
--- a/arch/powerpc/platforms/pseries/pmem.c
+++ b/arch/powerpc/platforms/pseries/pmem.c
@@ -52,8 +52,8 @@ static ssize_t pmem_drc_add_node(u32 drc_index)
/* NB: The of reconfig notifier creates platform device from the node */
rc = dlpar_attach_node(dn, pmem_node);
if (rc) {
-   pr_err("Failed to attach node %s, rc: %d, drc index: %x\n",
-   dn->name, rc, drc_index);
+   pr_err("Failed to attach node %pOF, rc: %d, drc index: %x\n",
+   dn, rc, drc_index);
 
if (dlpar_release_drc(drc_index))
dlpar_free_cc_nodes(dn);
@@ -93,8 +93,8 @@ static ssize_t pmem_drc_remove_node(u32 drc_index)
 
rc = dlpar_release_drc(drc_index);
if (rc) {
-   pr_err("Failed to release drc (%x) for CPU %s, rc: %d\n",
-   drc_index, dn->name, rc);
+   pr_err("Failed to release drc (%x) for CPU %pOFn, rc: %d\n",
+   drc_index, dn, rc);
dlpar_attach_node(dn, pmem_node);
return rc;
}
-- 
2.19.1



Re: [PATCH v2 26/34] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema

2018-12-05 Thread Simon Horman
On Tue, Dec 04, 2018 at 09:08:57AM -0600, Rob Herring wrote:
> On Tue, Dec 4, 2018 at 8:57 AM Geert Uytterhoeven  
> wrote:
> >
> > Hi Simon,
> >
> > On Tue, Dec 4, 2018 at 3:48 PM Simon Horman  wrote:
> > > On Mon, Dec 03, 2018 at 03:32:15PM -0600, Rob Herring wrote:
> > > > Convert Renesas SoC bindings to DT schema format using json-schema.
> > > >
> > > > Cc: Simon Horman 
> > > > Cc: Magnus Damm 
> > > > Cc: Mark Rutland 
> > > > Cc: linux-renesas-...@vger.kernel.org
> > > > Cc: devicet...@vger.kernel.org
> > > > Signed-off-by: Rob Herring 
> > > > ---
> > > >  .../devicetree/bindings/arm/shmobile.txt  | 151 
> > > >  .../devicetree/bindings/arm/shmobile.yaml | 218 ++
> > > >  2 files changed, 218 insertions(+), 151 deletions(-)
> > > >  delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt
> > > >  create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml
> > >
> > > Hi Rob,
> > >
> > > what is this based on? I get a conflict when applying the .txt change
> > > and if I knew the base for this patch it would be rather easy to work
> > > out what has changed.
> 
> 4.20-rc2
> 
> > >
> > > Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS?
> 
> Yes. Though it was pointed out that get_maintainers.pl can pull emails
> out of this file. We'd need to get that to work by default though.
> 
> > Probably even s/shmobile.yaml/renesas.yaml/, while at it?
> 
> Sure, if that's what you all want.

How about this?

From: Rob Herring 
Subject: [PATCH v2.1] dt-bindings: arm: Convert Renesas board/soc bindings to
 json-schema

Convert Renesas SoC bindings to DT schema format using json-schema.

v2.1 [Simon Horman]
- rebased on renesas-devel-20181204-v4.20-rc5
  + Added r8a7744 development platform and SoM
  + Correct RZ/G2E part number
- Update MAINTAINERS

Signed-off-by: Rob Herring 
Signed-off-by: Simon Horman 
---
 Documentation/devicetree/bindings/arm/renesas.yaml | 228 +
 Documentation/devicetree/bindings/arm/shmobile.txt | 155 --
 MAINTAINERS|   4 +-
 3 files changed, 230 insertions(+), 157 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/renesas.yaml
 delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt

diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml 
b/Documentation/devicetree/bindings/arm/renesas.yaml
new file mode 100644
index ..5e9d4864a600
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/renesas.yaml
@@ -0,0 +1,228 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/shmobile.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings
+
+maintainers:
+  - Geert Uytterhoeven 
+
+properties:
+  $nodename:
+const: '/'
+  compatible:
+oneOf:
+  - description: Emma Mobile EV2
+items:
+  - enum:
+  - renesas,kzm9d # Kyoto Microcomputer Co. KZM-A9-Dual
+  - const: renesas,emev2
+
+  - description: RZ/A1H (R7S72100)
+items:
+  - enum:
+  - renesas,genmai # Genmai (RTK772100BC0BR)
+  - renesas,gr-peach # GR-Peach (X28A-M01-E/F)
+  - renesas,rskrza1 # RSKRZA1 (YR0K77210C000BE)
+  - const: renesas,r7s72100
+
+  - description: RZ/A2 (R7S9210)
+items:
+  - const: renesas,r7s9210
+
+  - description: SH-Mobile AG5 (R8A73A00/SH73A0)
+items:
+  - enum:
+  - renesas,kzm9g # Kyoto Microcomputer Co. KZM-A9-GT
+  - const: renesas,sh73a0
+
+  - description: R-Mobile APE6 (R8A73A40)
+items:
+  - enum:
+  - renesas,ape6evm
+  - const: renesas,r8a73a4
+
+  - description: R-Mobile A1 (R8A77400)
+items:
+  - enum:
+  - renesas,armadillo800eva # Atmark Techno Armadillo-800 EVA
+  - const: renesas,r8a7740
+
+  - description: RZ/G1H (R8A77420)
+items:
+  - const: renesas,r8a7742
+
+  - description: RZ/G1M (R8A77430)
+items:
+  - enum:
+  # iWave Systems RZ/G1M Qseven Development Platform 
(iW-RainboW-G20D-Qseven)
+  - iwave,g20d
+  - const: iwave,g20m
+  - const: renesas,r8a7743
+
+  - items:
+  - enum:
+  # iWave Systems RZ/G1M Qseven System On Module 
(iW-RainboW-G20M-Qseven)
+  - iwave,g20m
+  - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE)
+  - const: renesas,r8a7743
+
+  - description: RZ/G1N (R8A77440)
+items:
+  - enum:
+  # iWave Systems RZ/G1N Qseven Development Platform 
(iW-RainboW-G20D-Qseven)
+  - iwave,g20d
+  - const: iwave,g20m
+  - const: renesas,r8a7744
+
+  - items:
+  - enum:
+  # iWave Systems RZ/G1N 

[PATCH v2] misc: cxl: Use device_type helpers to access the node type

2018-12-05 Thread Rob Herring
Remove directly accessing device_type property and use the
of_node_is_type accessor instead. While not using it here, this is
part of eventually removing the struct device_node.type pointer.

Cc: Frederic Barrat 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: linuxppc-dev@lists.ozlabs.org
Acked-by: Andrew Donnellan 
Signed-off-by: Rob Herring 
---
v2:
- Reword commit message as this change was using the .type ptr.

 drivers/misc/cxl/pci.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index b66d832d3233..c79ba1c699ad 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -1718,7 +1718,6 @@ int cxl_slot_is_switched(struct pci_dev *dev)
 {
struct device_node *np;
int depth = 0;
-   const __be32 *prop;
 
if (!(np = pci_device_to_OF_node(dev))) {
pr_err("cxl: np = NULL\n");
@@ -1727,8 +1726,7 @@ int cxl_slot_is_switched(struct pci_dev *dev)
of_node_get(np);
while (np) {
np = of_get_next_parent(np);
-   prop = of_get_property(np, "device_type", NULL);
-   if (!prop || strcmp((char *)prop, "pciex"))
+   if (!of_node_is_type(np, "pciex"))
break;
depth++;
}
-- 
2.19.1



Re: [PATCH] powerpc/ipic: Remove unused ipic_set_priority()

2018-12-05 Thread Thiago Jung Bauermann


Michael Ellerman  writes:

> ipic_set_priority() has been unused since 2006 when the last usage was
> removed in commit b9f0f1bb2bca ("[POWERPC] Adapt ipic driver to new
> host_ops interface, add set_irq_type to set IRQ sense").
>
> Reported-by: Dan Carpenter 
> Signed-off-by: Michael Ellerman 
> ---
>  arch/powerpc/sysdev/ipic.c | 28 
>  1 file changed, 28 deletions(-)

There's also the function prototype in 

-- 
Thiago Jung Bauermann
IBM Linux Technology Center



Re: [PATCH v2 22/34] dt-bindings: arm: Convert QCom board/soc bindings to json-schema

2018-12-05 Thread Andy Gross
On Mon, Dec 03, 2018 at 03:32:11PM -0600, Rob Herring wrote:
> Convert QCom SoC bindings to DT schema format using json-schema.
> 
> Cc: Andy Gross 
> Cc: David Brown 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring 

Acked-by: Andy Gross 


Re: [PATCH RFC 7/7] mm: better document PG_reserved

2018-12-05 Thread David Hildenbrand
On 05.12.18 18:32, Matthew Wilcox wrote:
> On Wed, Dec 05, 2018 at 04:05:12PM +0100, David Hildenbrand wrote:
>> On 05.12.18 15:35, Matthew Wilcox wrote:
>>> On Wed, Dec 05, 2018 at 01:28:51PM +0100, David Hildenbrand wrote:
 I don't see a reason why we have to document "Some of them might not even
 exist". If there is a user, we should document it. E.g. for balloon
 drivers we now use PG_offline to indicate that a page might currently
 not be backed by memory in the hypervisor. And that is independent from
 PG_reserved.
>>>
>>> I think you're confused by the meaning of "some of them might not even
>>> exist".  What this means is that there might not be memory there; maybe
>>> writes to that memory will be discarded, or maybe they'll cause a machine
>>> check.  Maybe reads will return ~0, or 0, or cause a machine check.
>>> We just don't know what's there, and we shouldn't try touching the memory.
>>
>> If there are users, let's document it. And I need more details for that :)
>>
>> 1. machine check: if there is a HW error, we set PG_hwpoison (except
>> ia64 MCA, see the list)
>>
>> 2. Writes to that memory will be discarded
>>
>> Who is the user of that? When will we have such pages right now?
>>
>> 3. Reads will return ~0, / 0?
>>
>> I think this is a special case of e.g. x86? But where do we have that,
>> are there any user?
> 
> When there are gaps in the physical memory.  As in, if you put that
> physical address on the bus (or in a packet), no device will respond
> to it.  Look:
> 
> -0fff : Reserved
> 1000-00057fff : System RAM
> 00058000-00058fff : Reserved
> 00059000-0009dfff : System RAM
> 0009e000-000f : Reserved
> 
> Those examples I gave are examples of how various different architectures
> respond to "no device responded to this memory access".
> 

Okay, so for this memory we will have
a) vmmaps
b) Memory block devices
c) A sections that is online

So essentially "Gaps in physical memory" which is part of a online section.

This might be a candidate for PG_offline as well.

Thanks for the info, I'll try to find out how such things are handled.
In general I assume this memory has to be readable, because otherwise
kdump and friends would crash already when trying to dump?

-- 

Thanks,

David / dhildenb


[PATCH v2] powerpc/32: Move the old 6xx -mcpu logic before the TARGET_CPU logic

2018-12-05 Thread Mathieu Malaterre
The code:

  ifdef CONFIG_6xx
  KBUILD_CFLAGS  += -mcpu=powerpc
  endif

was added in 2006 in commit f48b8296b315 ("[PATCH] powerpc32: Set cpu
explicitly in kernel compiles"). This change was acceptable since the
TARGET_CPU logic was 64-bit only.

Since commit 0e00a8c9fd92 ("powerpc: Allow CPU selection
also on PPC32") this logic is no longer acceptable after the TARGET_CPU
specific. It currently appends -mcpu=powerpc at the end of the command
line, after any TARGET_CPU specific:

  gcc -Wp,-MD,init/.do_mounts.o.d ...
-mcpu=powerpc -mbig-endian -m32 ...
-mcpu=e300c2 ...
-mcpu=powerpc ...
../init/do_mounts.c

Cc: Christophe Leroy 
Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
Suggested-by: Michael Ellerman 
Link: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg142315.html
Signed-off-by: Mathieu Malaterre 
---
v2: As suggested by Christophe rebase onto next-test

 arch/powerpc/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 40bbeeeb5b4a..4b16588c920f 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -30,6 +30,10 @@ endif
 endif
 endif
 
+ifdef CONFIG_PPC_BOOK3S_32
+KBUILD_CFLAGS  += -mcpu=powerpc
+endif
+
 ifeq ($(CROSS_COMPILE),)
 KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
 else
@@ -241,10 +245,6 @@ KBUILD_CFLAGS  += $(call cc-option,-fno-dwarf2-cfi-asm)
 # often slow when they are implemented at all
 KBUILD_CFLAGS  += $(call cc-option,-mno-string)
 
-ifdef CONFIG_PPC_BOOK3S_32
-KBUILD_CFLAGS  += -mcpu=powerpc
-endif
-
 cpu-as-$(CONFIG_4xx)   += -Wa,-m405
 cpu-as-$(CONFIG_ALTIVEC)   += $(call as-option,-Wa$(comma)-maltivec)
 cpu-as-$(CONFIG_E200)  += -Wa,-me200
-- 
2.19.2



Re: [v11 1/7] dmaengine: fsldma: Replace DMA_IN/OUT by FSL_DMA_IN/OUT

2018-12-05 Thread Vinod Koul
On 30-10-18, 10:35, Peng Ma wrote:
> From: Wen He 
> 
> This patch implement a standard macro call functions is
> used to NXP dma drivers.

Applied all except DTS patches, thanks
-- 
~Vinod


Re: [PATCH RFC 7/7] mm: better document PG_reserved

2018-12-05 Thread Matthew Wilcox
On Wed, Dec 05, 2018 at 04:05:12PM +0100, David Hildenbrand wrote:
> On 05.12.18 15:35, Matthew Wilcox wrote:
> > On Wed, Dec 05, 2018 at 01:28:51PM +0100, David Hildenbrand wrote:
> >> I don't see a reason why we have to document "Some of them might not even
> >> exist". If there is a user, we should document it. E.g. for balloon
> >> drivers we now use PG_offline to indicate that a page might currently
> >> not be backed by memory in the hypervisor. And that is independent from
> >> PG_reserved.
> > 
> > I think you're confused by the meaning of "some of them might not even
> > exist".  What this means is that there might not be memory there; maybe
> > writes to that memory will be discarded, or maybe they'll cause a machine
> > check.  Maybe reads will return ~0, or 0, or cause a machine check.
> > We just don't know what's there, and we shouldn't try touching the memory.
> 
> If there are users, let's document it. And I need more details for that :)
> 
> 1. machine check: if there is a HW error, we set PG_hwpoison (except
> ia64 MCA, see the list)
> 
> 2. Writes to that memory will be discarded
> 
> Who is the user of that? When will we have such pages right now?
> 
> 3. Reads will return ~0, / 0?
> 
> I think this is a special case of e.g. x86? But where do we have that,
> are there any user?

When there are gaps in the physical memory.  As in, if you put that
physical address on the bus (or in a packet), no device will respond
to it.  Look:

-0fff : Reserved
1000-00057fff : System RAM
00058000-00058fff : Reserved
00059000-0009dfff : System RAM
0009e000-000f : Reserved

Those examples I gave are examples of how various different architectures
respond to "no device responded to this memory access".



Re: pkeys: Reserve PKEY_DISABLE_READ

2018-12-05 Thread Andy Lutomirski
> On Dec 2, 2018, at 8:02 PM, Ram Pai  wrote:
>
>> On Thu, Nov 29, 2018 at 12:37:15PM +0100, Florian Weimer wrote:
>> * Dave Hansen:
>>
 On 11/27/18 3:57 AM, Florian Weimer wrote:
 I would have expected something that translates PKEY_DISABLE_WRITE |
 PKEY_DISABLE_READ into PKEY_DISABLE_ACCESS, and also accepts
 PKEY_DISABLE_ACCESS | PKEY_DISABLE_READ, for consistency with POWER.

 (My understanding is that PKEY_DISABLE_ACCESS does not disable all
 access, but produces execute-only memory.)
>>>
>>> Correct, it disables all data access, but not execution.
>>
>> So I would expect something like this (completely untested, I did not
>> even compile this):
>
>
> Ok. I re-read through the entire email thread to understand the problem and
> the proposed solution. Let me summarize it below. Lets see if we are on the 
> same
> plate.
>
> So the problem is as follows:
>
> Currently the kernel supports  'disable-write'  and 'disable-access'.
>
> On x86, cpu supports 'disable-write' and 'disable-access'. This
> matches with what the kernel supports. All good.
>
> However on power, cpu supports 'disable-read' too. Since userspace can
> program the cpu directly, userspace has the ability to set
> 'disable-read' too.  This can lead to inconsistency between the kernel
> and the userspace.
>
> We want the kernel to match userspace on all architectures.
>
> Proposed Solution:
>
> Enhance the kernel to understand 'disable-read', and facilitate architectures
> that understand 'disable-read' to allow it.
>
> Also explicitly define the semantics of disable-access  as
> 'disable-read and disable-write'
>
> Did I get this right?  Assuming I did, the implementation has to do
> the following --
>
>On power, sys_pkey_alloc() should succeed if the init_val
>is PKEY_DISABLE_READ, PKEY_DISABLE_WRITE, PKEY_DISABLE_ACCESS
>or any combination of the three.
>
>On x86, sys_pkey_alloc() should succeed if the init_val is
>PKEY_DISABLE_WRITE or PKEY_DISABLE_ACCESS or PKEY_DISABLE_READ
>or any combination of the three, except  PKEY_DISABLE_READ
>  specified all by itself.
>
>On all other arches, none of the flags are supported.

I don’t really love having a situation where you can use different
flag combinations to refer to the same mode.

Also, we should document the effect these flags have on execute permission.


Re: [PATCH v2 08/34] dt-bindings: arm: Convert PMU binding to json-schema

2018-12-05 Thread Rob Herring
On Wed, Dec 5, 2018 at 4:08 AM Will Deacon  wrote:
>
> Hi Rob,
>
> On Mon, Dec 03, 2018 at 03:31:57PM -0600, Rob Herring wrote:
> > Convert ARM PMU binding to DT schema format using json-schema.
>
> Just a couple of things below.
>
> > diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml 
> > b/Documentation/devicetree/bindings/arm/pmu.yaml
> > new file mode 100644
> > index ..3ea4abfbf276
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/pmu.yaml
> > @@ -0,0 +1,91 @@
>
> [...]
>
> > +properties:
> > +  compatible:
> > +oneOf:
> > +  - items:
> > +  - enum:
> > +  - apm,potenza-pmu
> > +  - arm,armv8-pmuv3
> > +  - arm,cortex-a73-pmu
> > +  - arm,cortex-a72-pmu
> > +  - arm,cortex-a57-pmu
> > +  - arm,cortex-a53-pmu
> > +  - arm,cortex-a35-pmu
> > +  - arm,cortex-a17-pmu
> > +  - arm,cortex-a15-pmu
> > +  - arm,cortex-a12-pmu
> > +  - arm,cortex-a9-pmu
> > +  - arm,cortex-a8-pmu
> > +  - arm,cortex-a7-pmu
> > +  - arm,cortex-a5-pmu
> > +  - arm,arm11mpcore-pmu
> > +  - arm,arm1176-pmu
> > +  - arm,arm1136-pmu
> > +  - brcm,vulcan-pmu
> > +  - cavium,thunder-pmu
> > +  - qcom,scorpion-pmu
> > +  - qcom,scorpion-mp-pmu
> > +  - qcom,krait-pmu
> > +  - items:
> > +  - const: arm,cortex-a7-pmu
> > +  - const: arm,cortex-a15-pmu
>
> What do these last two mean?

The first list only allows a single compatible string. This list says
there are 2 and that the compatible property should be:
compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";

Which shows up here:
arch/arm/boot/dts/sun6i-a31.dtsi:   compatible =
"arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
arch/arm/boot/dts/sun7i-a20.dtsi:   compatible =
"arm,cortex-a7-pmu", "arm,cortex-a15-pmu";

Maybe the dts is wrong and should be fixed?

> > +  interrupts:
> > +# Don't know how many CPUs, so no constraints to specify
> > +description: 1 per-cpu interrupt (PPI) or 1 interrupt per core.
> > +
> > +  interrupt-affinity:
> > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > +description:
> > +  When using SPIs, specifies a list of phandles to CPU
> > +  nodes corresponding directly to the affinity of
> > +  the SPIs listed in the interrupts property.
> > +
> > +  When using a PPI, specifies a list of phandles to CPU
> > +  nodes corresponding to the set of CPUs which have
> > +  a PMU of this type signalling the PPI listed in the
> > +  interrupts property, unless this is already specified
> > +  by the PPI interrupt specifier itself (in which case
> > +  the interrupt-affinity property shouldn't be present).
> > +
> > +  This property should be present when there is more than
> > +  a single SPI.
> > +
> > +  qcom,no-pc-write:
> > +type: boolean
> > +description:
> > +  Indicates that this PMU doesn't support the 0xc and 0xd events.
> > +
> > +  secure-reg-access:
> > +type: boolean
> > +description:
> > +  Indicates that the ARMv7 Secure Debug Enable Register
> > +  (SDER) is accessible. This will cause the driver to do
> > +  any setup required that is only possible in ARMv7 secure
> > +  state. If not present the ARMv7 SDER will not be touched,
> > +  which means the PMU may fail to operate unless external
> > +  code (bootloader or security monitor) has performed the
> > +  appropriate initialisation. Note that this property is
> > +  not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
> > +  in Non-secure state.
> > +
> > +required:
> > +  - compatible
>
> I probably said this before, but I do think that it's a shame to lose the
> example binding, especially for something like the PMU where you can
> pretty much take an example and bang in your own IRQ numbers to get it
> up and running.

I just thought it is so trivial that it didn't add much. I think most
folks would copy-n-paste from an actual dts file which has all the
other nodes you just need to update addresses and irq nums.

Rob


Re: [PATCH v2 2/6] microblaze: prefer memblock API returning virtual address

2018-12-05 Thread Michal Simek
On 03. 12. 18 16:47, Mike Rapoport wrote:
> Rather than use the memblock_alloc_base that returns a physical address and
> then convert this address to the virtual one, use appropriate memblock
> function that returns a virtual address.
> 
> Signed-off-by: Mike Rapoport 
> ---
>  arch/microblaze/mm/init.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/microblaze/mm/init.c b/arch/microblaze/mm/init.c
> index b17fd8a..44f4b89 100644
> --- a/arch/microblaze/mm/init.c
> +++ b/arch/microblaze/mm/init.c
> @@ -363,8 +363,9 @@ void __init *early_get_page(void)
>* Mem start + kernel_tlb -> here is limit
>* because of mem mapping from head.S
>*/
> - return __va(memblock_alloc_base(PAGE_SIZE, PAGE_SIZE,
> - memory_start + kernel_tlb));
> + return memblock_alloc_try_nid_raw(PAGE_SIZE, PAGE_SIZE,
> + MEMBLOCK_LOW_LIMIT, memory_start + kernel_tlb,
> + NUMA_NO_NODE);
>  }
>  
>  #endif /* CONFIG_MMU */
> 

I can't see any issue with functionality when this patch is applied.
If you want me to take this via my tree please let me know.
Otherwise:

Tested-by: Michal Simek 

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs




signature.asc
Description: OpenPGP digital signature


Re: [PATCH RFC 7/7] mm: better document PG_reserved

2018-12-05 Thread David Hildenbrand
On 05.12.18 15:35, Matthew Wilcox wrote:
> On Wed, Dec 05, 2018 at 01:28:51PM +0100, David Hildenbrand wrote:
>> I don't see a reason why we have to document "Some of them might not even
>> exist". If there is a user, we should document it. E.g. for balloon
>> drivers we now use PG_offline to indicate that a page might currently
>> not be backed by memory in the hypervisor. And that is independent from
>> PG_reserved.
> 
> I think you're confused by the meaning of "some of them might not even
> exist".  What this means is that there might not be memory there; maybe
> writes to that memory will be discarded, or maybe they'll cause a machine
> check.  Maybe reads will return ~0, or 0, or cause a machine check.
> We just don't know what's there, and we shouldn't try touching the memory.

If there are users, let's document it. And I need more details for that :)

1. machine check: if there is a HW error, we set PG_hwpoison (except
ia64 MCA, see the list)

2. Writes to that memory will be discarded

Who is the user of that? When will we have such pages right now?

3. Reads will return ~0, / 0?

I think this is a special case of e.g. x86? But where do we have that,
are there any user?


In summary: When can we have memory sections that are online but pages
reserved and not accessible? (one example is ballooning I mention here)

(I classify this as dangerous as dump tools will happily dump
PG_reserved pages (unless PG_hwpoison/PG_offline) and that's the right
thing to do).

I want to avoid documenting things that are not actually getting used.

> 
>> +++ b/include/linux/page-flags.h
>> @@ -17,8 +17,22 @@
>>  /*
>>   * Various page->flags bits:
>>   *
>> - * PG_reserved is set for special pages, which can never be swapped out. 
>> Some
>> - * of them might not even exist...
>> + * PG_reserved is set for special pages. The "struct page" of such a page
>> + * should in general not be touched (e.g. set dirty) except by their owner.
>> + * Pages marked as PG_reserved include:
>> + * - Kernel image (including vDSO) and similar (e.g. BIOS, initrd)
>> + * - Pages allocated early during boot (bootmem, memblock)
>> + * - Zero pages
>> + * - Pages that have been associated with a zone but are not available for
>> + *   the page allocator (e.g. excluded via online_page_callback())
>> + * - Pages to exclude from the hibernation image (e.g. loaded kexec images)
>> + * - MMIO pages (communicate with a device, special caching strategy needed)
>> + * - MCA pages on ia64 (pages with memory errors)
>> + * - Device memory (e.g. PMEM, DAX, HMM)
>> + * Some architectures don't allow to ioremap pages that are not marked
>> + * PG_reserved (as they might be in use by somebody else who does not 
>> respect
>> + * the caching strategy). Consequently, PG_reserved for a page mapped into
>> + * user space can indicate the zero page, the vDSO, MMIO pages or device 
>> memory.
> 
> So maybe just add one more option to the list.
> 


-- 

Thanks,

David / dhildenb


Re: [PATCH RFC 7/7] mm: better document PG_reserved

2018-12-05 Thread Matthew Wilcox
On Wed, Dec 05, 2018 at 01:28:51PM +0100, David Hildenbrand wrote:
> I don't see a reason why we have to document "Some of them might not even
> exist". If there is a user, we should document it. E.g. for balloon
> drivers we now use PG_offline to indicate that a page might currently
> not be backed by memory in the hypervisor. And that is independent from
> PG_reserved.

I think you're confused by the meaning of "some of them might not even
exist".  What this means is that there might not be memory there; maybe
writes to that memory will be discarded, or maybe they'll cause a machine
check.  Maybe reads will return ~0, or 0, or cause a machine check.
We just don't know what's there, and we shouldn't try touching the memory.

> +++ b/include/linux/page-flags.h
> @@ -17,8 +17,22 @@
>  /*
>   * Various page->flags bits:
>   *
> - * PG_reserved is set for special pages, which can never be swapped out. Some
> - * of them might not even exist...
> + * PG_reserved is set for special pages. The "struct page" of such a page
> + * should in general not be touched (e.g. set dirty) except by their owner.
> + * Pages marked as PG_reserved include:
> + * - Kernel image (including vDSO) and similar (e.g. BIOS, initrd)
> + * - Pages allocated early during boot (bootmem, memblock)
> + * - Zero pages
> + * - Pages that have been associated with a zone but are not available for
> + *   the page allocator (e.g. excluded via online_page_callback())
> + * - Pages to exclude from the hibernation image (e.g. loaded kexec images)
> + * - MMIO pages (communicate with a device, special caching strategy needed)
> + * - MCA pages on ia64 (pages with memory errors)
> + * - Device memory (e.g. PMEM, DAX, HMM)
> + * Some architectures don't allow to ioremap pages that are not marked
> + * PG_reserved (as they might be in use by somebody else who does not respect
> + * the caching strategy). Consequently, PG_reserved for a page mapped into
> + * user space can indicate the zero page, the vDSO, MMIO pages or device 
> memory.

So maybe just add one more option to the list.


Re: use generic DMA mapping code in powerpc V4

2018-12-05 Thread Christoph Hellwig
On Wed, Dec 05, 2018 at 10:44:05AM +0100, Christian Zigotzky wrote:
> Thanks for your reply. I undid all dma mapping commits with the following 
> command:
>
> git checkout 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97
>
> After that I compiled the kernels with this code for my P5020 board (Cyrus) 
> and for my PASEMI board (Nemo) today.
>
> Result: PASEMI onboard ethernet works again and the P5020 board boots.
>
> It seems the dma mapping commits are the problem.

Thanks.  Can you try a few stepping points in the tree?

First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6
(the first one) applied?

Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b

And if that still works with commits up to
c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a


Re: [PATCH RFC 6/7] arm64: kexec: no need to ClearPageReserved()

2018-12-05 Thread James Morse
Hi David,

(CC: +Akashi)

On 05/12/2018 12:28, David Hildenbrand wrote:
> This will already be done by free_reserved_page().

(will already be -> will be ?)

So it does!


> diff --git a/arch/arm64/kernel/machine_kexec.c 
> b/arch/arm64/kernel/machine_kexec.c
> index 922add8adb74..0ef4ea73aa54 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -353,7 +353,6 @@ void crash_free_reserved_phys_range(unsigned long begin, 
> unsigned long end)
>  
>   for (addr = begin; addr < end; addr += PAGE_SIZE) {
>   page = phys_to_page(addr);
> - ClearPageReserved(page);
>   free_reserved_page(page);
>   }
>  }
> 

Acked-by: James Morse 


Thanks,

James


Re: [PATCH 0/2] sriov enablement on s390

2018-12-05 Thread Sebastian Ott
Hello Bjorn,

On Wed, 10 Oct 2018, Bjorn Helgaas wrote:
> On Wed, Oct 10, 2018 at 02:55:07PM +0200, Sebastian Ott wrote:
> > On Wed, 12 Sep 2018, Bjorn Helgaas wrote:
> > > On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote:
> > > > On s390 we currently handle SRIOV within firmware. Which means
> > > > that the PF is under firmware control and not visible to operating
> > > > systems. SRIOV enablement happens within firmware and VFs are
> > > > passed through to logical partitions.
> > > > 
> > > > I'm working on a new mode were the PF is under operating system
> > > > control (including SRIOV enablement). However we still need
> > > > firmware support to access the VFs. The way this is supposed
> > > > to work is that when firmware traps the SRIOV enablement it
> > > > will present machine checks to the logical partition that
> > > > triggered the SRIOV enablement and provide the VFs via hotplug
> > > > events.
> > > > 
> > > > The problem I'm faced with is that the VF detection code in
> > > > sriov_enable leads to unusable functions in s390.
> > > 
> > > We're moving away from the weak function implementation style.  Can
> > > you take a look at Arnd's work here, which uses pci_host_bridge
> > > callbacks instead?
> > > 
> > >   https://lkml.kernel.org/r/20180817102645.3839621-1-a...@arndb.de
> > 
> > What's the status of Arnd's patches - will they go upstream in the next
> > couple of versions?
> 
> I hope so [1].  IIRC Arnd mentioned doing some minor updates, so I'm
> waiting on that.
> 
> > What about my patches that I rebased on Arnd's branch
> > will they be considered?
> 
> Definitely.  From my point of view they're just lined up behind Arnd's
> patches.
> 
> [1] 
> https://lore.kernel.org/linux-pci/20181002205903.gd120...@bhelgaas-glaptop.roam.corp.google.com

It appears like these patches are not in-line for the next merge window.
Would it be possible to go with my original patches (using __weak
functions)? (This would also make life easier with regards to backports)
I can post patches to convert this to use function pointers once Arnd's
patches make it to the kernel.

Regards,
Sebastian



Re: [PATCH RFC 0/7] mm: PG_reserved cleanups and documentation

2018-12-05 Thread David Hildenbrand
On 05.12.18 13:56, Michal Hocko wrote:
> On Wed 05-12-18 13:28:44, David Hildenbrand wrote:
> [...]
>> Most notably, for device memory we can hopefully soon stop setting
>> it PG_reserved
> 
> I am busy as hell so I am not likely to look at specific patche this
> week. But could you be more specific why we need to get rid of other
> PG_reserved users before we can do so for device memory?
> 

No worries, this has time.

For device memory, nothing should really be needed. I am only collecting
and docuumenting users and this is one user soon to go (eventually) :)

> I am all for removing relicts because they just confuse people but I
> fail to see any relation here.
> 

It's really only "why is this patch set not bigger", nothing related to
device memory actually :)

-- 

Thanks,

David / dhildenb


Re: pkeys: Reserve PKEY_DISABLE_READ

2018-12-05 Thread Florian Weimer
* Ram Pai:

> Ok. here is a patch, compiled but not tested. See if this meets the
> specifications.
>
> ---
>
> commit 3dc06e73f3795921265d5d1d935e428deab01616
> Author: Ram Pai 
> Date:   Tue Dec 4 00:04:11 2018 -0500
>
> pkeys: add support of PKEY_DISABLE_READ

Thanks.  In the x86 code, the translation of PKEY_DISABLE_READ |
PKEY_DISABLE_WRITE to PKEY_DISABLE_ACCESS appears to be missing.  I
believe the existing code produces PKEY_DISABLE_WRITE, which is wrong.

Rest looks okay to me (again not tested).

Thanks,
Florian


Re: [PATCH RFC 7/7] mm: better document PG_reserved

2018-12-05 Thread Michal Hocko
On Wed 05-12-18 13:28:51, David Hildenbrand wrote:
> The usage of PG_reserved and how PG_reserved pages are to be treated is
> burried deep down in different parts of the kernel. Let's shine some light
> onto these details by documenting (most?) current users and expected
> behavior.
> 
> I don't see a reason why we have to document "Some of them might not even
> exist". If there is a user, we should document it. E.g. for balloon
> drivers we now use PG_offline to indicate that a page might currently
> not be backed by memory in the hypervisor. And that is independent from
> PG_reserved.
> 
> Cc: Andrew Morton 
> Cc: Stephen Rothwell 
> Cc: Pavel Tatashin 
> Cc: Michal Hocko 
> Cc: Alexander Duyck 
> Cc: Matthew Wilcox 
> Cc: Anthony Yznaga 
> Cc: Miles Chen 
> Cc: yi.z.zh...@linux.intel.com
> Cc: Dan Williams 
> Signed-off-by: David Hildenbrand 

This looks like an improvement. The essential part is that PG_reserved
page belongs to its user and no generic code should touch it. The rest
is a description of current users which I haven't checked due to to lack
of time but yeah, I like the updated wording because I have seen
multiple people confused from the swapped out part which is not true for
many many years. I have tried to dig out when it was actually the case
but failed.

So I cannot give my Ack because I didn't really do a real review but I
like this FWIW.

> ---
>  include/linux/page-flags.h | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 68b8495e2fbc..112526f5ba61 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -17,8 +17,22 @@
>  /*
>   * Various page->flags bits:
>   *
> - * PG_reserved is set for special pages, which can never be swapped out. Some
> - * of them might not even exist...
> + * PG_reserved is set for special pages. The "struct page" of such a page
> + * should in general not be touched (e.g. set dirty) except by their owner.
> + * Pages marked as PG_reserved include:
> + * - Kernel image (including vDSO) and similar (e.g. BIOS, initrd)
> + * - Pages allocated early during boot (bootmem, memblock)
> + * - Zero pages
> + * - Pages that have been associated with a zone but are not available for
> + *   the page allocator (e.g. excluded via online_page_callback())
> + * - Pages to exclude from the hibernation image (e.g. loaded kexec images)
> + * - MMIO pages (communicate with a device, special caching strategy needed)
> + * - MCA pages on ia64 (pages with memory errors)
> + * - Device memory (e.g. PMEM, DAX, HMM)
> + * Some architectures don't allow to ioremap pages that are not marked
> + * PG_reserved (as they might be in use by somebody else who does not respect
> + * the caching strategy). Consequently, PG_reserved for a page mapped into
> + * user space can indicate the zero page, the vDSO, MMIO pages or device 
> memory.
>   *
>   * The PG_private bitflag is set on pagecache pages if they contain 
> filesystem
>   * specific data (which is normally at page->private). It can be used by
> -- 
> 2.17.2
> 

-- 
Michal Hocko
SUSE Labs


Re: [PATCH RFC 0/7] mm: PG_reserved cleanups and documentation

2018-12-05 Thread Michal Hocko
On Wed 05-12-18 13:28:44, David Hildenbrand wrote:
[...]
> Most notably, for device memory we can hopefully soon stop setting
> it PG_reserved

I am busy as hell so I am not likely to look at specific patche this
week. But could you be more specific why we need to get rid of other
PG_reserved users before we can do so for device memory?

I am all for removing relicts because they just confuse people but I
fail to see any relation here.

-- 
Michal Hocko
SUSE Labs


Re: [PATCH v2 1/6] powerpc: prefer memblock APIs returning virtual address

2018-12-05 Thread Michael Ellerman
Mike Rapoport  writes:
> On Tue, Dec 04, 2018 at 08:59:41PM +1100, Michael Ellerman wrote:
>> Hi Mike,
>> 
>> Thanks for trying to clean these up.
>> 
>> I think a few could be improved though ...
>> 
>> Mike Rapoport  writes:
>> > diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
>> > index 913bfca..fa884ad 100644
>> > --- a/arch/powerpc/kernel/paca.c
>> > +++ b/arch/powerpc/kernel/paca.c
>> > @@ -42,17 +42,15 @@ static void *__init alloc_paca_data(unsigned long 
>> > size, unsigned long align,
>> >nid = early_cpu_to_node(cpu);
>> >}
>> >  
>> > -  pa = memblock_alloc_base_nid(size, align, limit, nid, MEMBLOCK_NONE);
>> > -  if (!pa) {
>> > -  pa = memblock_alloc_base(size, align, limit);
>> > -  if (!pa)
>> > -  panic("cannot allocate paca data");
>> > -  }
>> > +  ptr = memblock_alloc_try_nid_raw(size, align, MEMBLOCK_LOW_LIMIT,
>> > +   limit, nid);
>> > +  if (!ptr)
>> > +  panic("cannot allocate paca data");
>>   
>> The old code doesn't zero, but two of the three callers of
>> alloc_paca_data() *do* zero the whole allocation, so I'd be happy if we
>> did it in here instead.
>
> I looked at the callers and couldn't tell if zeroing memory in
> init_lppaca() would be ok.
> I'll remove the _raw here.
  
Thanks.

>> That would mean we could use memblock_alloc_try_nid() avoiding the need
>> to panic() manually.
>
> Actual, my plan was to remove panic() from all memblock_alloc* and make all
> callers to check the returned value.
> I believe it's cleaner and also allows more meaningful panic messages. Not
> mentioning the reduction of memblock code.

Hmm, not sure.

I see ~200 calls to the panicking functions, that seems like a lot of
work to change all those.

And I think I disagree on the "more meaningful panic message". This is a
perfect example, compare:

panic("cannot allocate paca data");
to:
panic("%s: Failed to allocate %llu bytes align=0x%llx nid=%d from=%pa 
max_addr=%pa\n",
  __func__, (u64)size, (u64)align, nid, _addr, _addr);

The former is basically useless, whereas the second might at least give
you a hint as to *why* the allocation failed.

I know it's kind of odd for a function to panic() rather than return an
error, but memblock is kind of special because it's so early in boot.
Most of these allocations have to succeed to get the system up and
running.

cheers


[PATCH RFC 7/7] mm: better document PG_reserved

2018-12-05 Thread David Hildenbrand
The usage of PG_reserved and how PG_reserved pages are to be treated is
burried deep down in different parts of the kernel. Let's shine some light
onto these details by documenting (most?) current users and expected
behavior.

I don't see a reason why we have to document "Some of them might not even
exist". If there is a user, we should document it. E.g. for balloon
drivers we now use PG_offline to indicate that a page might currently
not be backed by memory in the hypervisor. And that is independent from
PG_reserved.

Cc: Andrew Morton 
Cc: Stephen Rothwell 
Cc: Pavel Tatashin 
Cc: Michal Hocko 
Cc: Alexander Duyck 
Cc: Matthew Wilcox 
Cc: Anthony Yznaga 
Cc: Miles Chen 
Cc: yi.z.zh...@linux.intel.com
Cc: Dan Williams 
Signed-off-by: David Hildenbrand 
---
 include/linux/page-flags.h | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 68b8495e2fbc..112526f5ba61 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -17,8 +17,22 @@
 /*
  * Various page->flags bits:
  *
- * PG_reserved is set for special pages, which can never be swapped out. Some
- * of them might not even exist...
+ * PG_reserved is set for special pages. The "struct page" of such a page
+ * should in general not be touched (e.g. set dirty) except by their owner.
+ * Pages marked as PG_reserved include:
+ * - Kernel image (including vDSO) and similar (e.g. BIOS, initrd)
+ * - Pages allocated early during boot (bootmem, memblock)
+ * - Zero pages
+ * - Pages that have been associated with a zone but are not available for
+ *   the page allocator (e.g. excluded via online_page_callback())
+ * - Pages to exclude from the hibernation image (e.g. loaded kexec images)
+ * - MMIO pages (communicate with a device, special caching strategy needed)
+ * - MCA pages on ia64 (pages with memory errors)
+ * - Device memory (e.g. PMEM, DAX, HMM)
+ * Some architectures don't allow to ioremap pages that are not marked
+ * PG_reserved (as they might be in use by somebody else who does not respect
+ * the caching strategy). Consequently, PG_reserved for a page mapped into
+ * user space can indicate the zero page, the vDSO, MMIO pages or device 
memory.
  *
  * The PG_private bitflag is set on pagecache pages if they contain filesystem
  * specific data (which is normally at page->private). It can be used by
-- 
2.17.2



[PATCH RFC 6/7] arm64: kexec: no need to ClearPageReserved()

2018-12-05 Thread David Hildenbrand
This will already be done by free_reserved_page().

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Bhupesh Sharma 
Cc: James Morse 
Cc: Marc Zyngier 
Cc: Dave Kleikamp 
Cc: Mark Rutland 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Matthew Wilcox 
Signed-off-by: David Hildenbrand 
---
 arch/arm64/kernel/machine_kexec.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kernel/machine_kexec.c 
b/arch/arm64/kernel/machine_kexec.c
index 922add8adb74..0ef4ea73aa54 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -353,7 +353,6 @@ void crash_free_reserved_phys_range(unsigned long begin, 
unsigned long end)
 
for (addr = begin; addr < end; addr += PAGE_SIZE) {
page = phys_to_page(addr);
-   ClearPageReserved(page);
free_reserved_page(page);
}
 }
-- 
2.17.2



[PATCH RFC 5/7] m68k/mm: use __ClearPageReserved()

2018-12-05 Thread David Hildenbrand
The PG_reserved flag is cleared from memory that is part of the kernel
image (and therefore marked as PG_reserved). Avoid using PG_reserved
directly.

Cc: Geert Uytterhoeven 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Matthew Wilcox 
Signed-off-by: David Hildenbrand 
---
 arch/m68k/mm/memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68k/mm/memory.c b/arch/m68k/mm/memory.c
index b86a2e21693b..227c04fe60d2 100644
--- a/arch/m68k/mm/memory.c
+++ b/arch/m68k/mm/memory.c
@@ -51,7 +51,7 @@ void __init init_pointer_table(unsigned long ptable)
pr_debug("init_pointer_table: %lx, %x\n", ptable, PD_MARKBITS(dp));
 
/* unreserve the page so it's possible to free that page */
-   PD_PAGE(dp)->flags &= ~(1 << PG_reserved);
+   __ClearPageReserved(PD_PAGE(dp));
init_page_count(PD_PAGE(dp));
 
return;
-- 
2.17.2



[PATCH RFC 4/7] riscv/vdso: don't clear PG_reserved

2018-12-05 Thread David Hildenbrand
The VDSO is part of the kernel image and therefore the struct pages are
marked as reserved during boot.

As we install a special mapping, the actual struct pages will never be
exposed to MM via the page tables. We can therefore leave the pages
marked as reserved.

Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Tobias Klauser 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Matthew Wilcox 
Signed-off-by: David Hildenbrand 
---
 arch/riscv/kernel/vdso.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/riscv/kernel/vdso.c b/arch/riscv/kernel/vdso.c
index 582cb153eb24..0cd044122234 100644
--- a/arch/riscv/kernel/vdso.c
+++ b/arch/riscv/kernel/vdso.c
@@ -54,7 +54,6 @@ static int __init vdso_init(void)
struct page *pg;
 
pg = virt_to_page(vdso_start + (i << PAGE_SHIFT));
-   ClearPageReserved(pg);
vdso_pagelist[i] = pg;
}
vdso_pagelist[i] = virt_to_page(vdso_data);
-- 
2.17.2



[PATCH RFC 3/7] powerpc/vdso: don't clear PG_reserved

2018-12-05 Thread David Hildenbrand
The VDSO is part of the kernel image and therefore the struct pages are
marked as reserved during boot.

As we install a special mapping, the actual struct pages will never be
exposed to MM via the page tables. We can therefore leave the pages
marked as reserved.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Christophe Leroy 
Cc: Kees Cook 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Matthew Wilcox 
Signed-off-by: David Hildenbrand 
---
 arch/powerpc/kernel/vdso.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 65b3bdb99f0b..d59dc2e9a695 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -795,7 +795,6 @@ static int __init vdso_init(void)
BUG_ON(vdso32_pagelist == NULL);
for (i = 0; i < vdso32_pages; i++) {
struct page *pg = virt_to_page(vdso32_kbase + i*PAGE_SIZE);
-   ClearPageReserved(pg);
get_page(pg);
vdso32_pagelist[i] = pg;
}
@@ -809,7 +808,6 @@ static int __init vdso_init(void)
BUG_ON(vdso64_pagelist == NULL);
for (i = 0; i < vdso64_pages; i++) {
struct page *pg = virt_to_page(vdso64_kbase + i*PAGE_SIZE);
-   ClearPageReserved(pg);
get_page(pg);
vdso64_pagelist[i] = pg;
}
-- 
2.17.2



[PATCH RFC 2/7] s390/vdso: don't clear PG_reserved

2018-12-05 Thread David Hildenbrand
The VDSO is part of the kernel image and therefore the struct pages are
marked as reserved during boot.

As we install a special mapping, the actual struct pages will never be
exposed to MM via the page tables. We can therefore leave the pages
marked as reserved.

Suggested-by: Martin Schwidefsky 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Matthew Wilcox 
Cc: Mike Rapoport 
Cc: Michal Hocko 
Cc: Vasily Gorbik 
Cc: Kees Cook 
Cc: Souptick Joarder 
Cc: Andrew Morton 
Cc: Michal Hocko 
Signed-off-by: David Hildenbrand 
---
 arch/s390/kernel/vdso.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/s390/kernel/vdso.c b/arch/s390/kernel/vdso.c
index ebe748a9f472..9e24d23c26c0 100644
--- a/arch/s390/kernel/vdso.c
+++ b/arch/s390/kernel/vdso.c
@@ -292,7 +292,6 @@ static int __init vdso_init(void)
BUG_ON(vdso32_pagelist == NULL);
for (i = 0; i < vdso32_pages - 1; i++) {
struct page *pg = virt_to_page(vdso32_kbase + i*PAGE_SIZE);
-   ClearPageReserved(pg);
get_page(pg);
vdso32_pagelist[i] = pg;
}
@@ -310,7 +309,6 @@ static int __init vdso_init(void)
BUG_ON(vdso64_pagelist == NULL);
for (i = 0; i < vdso64_pages - 1; i++) {
struct page *pg = virt_to_page(vdso64_kbase + i*PAGE_SIZE);
-   ClearPageReserved(pg);
get_page(pg);
vdso64_pagelist[i] = pg;
}
-- 
2.17.2



[PATCH RFC 1/7] agp: efficeon: no need to set PG_reserved on GATT tables

2018-12-05 Thread David Hildenbrand
The l1 GATT page table is kept in a special on-chip page with 64 entries.
We allocate the l2 page table pages via get_zeroed_page() and enter them
into the table. These l2 pages are modified accordingly when
inserting/removing memory via efficeon_insert_memory and
efficeon_remove_memory.

Apart from that, these pages are not exposed or ioremap'ed. We can stop
setting them reserved (propably copied from generic code).

Cc: David Airlie 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Matthew Wilcox 
Signed-off-by: David Hildenbrand 
---
 drivers/char/agp/efficeon-agp.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/char/agp/efficeon-agp.c b/drivers/char/agp/efficeon-agp.c
index 7f88490b5479..c53f0f9ef5b0 100644
--- a/drivers/char/agp/efficeon-agp.c
+++ b/drivers/char/agp/efficeon-agp.c
@@ -163,7 +163,6 @@ static int efficeon_free_gatt_table(struct agp_bridge_data 
*bridge)
unsigned long page = efficeon_private.l1_table[index];
if (page) {
efficeon_private.l1_table[index] = 0;
-   ClearPageReserved(virt_to_page((char *)page));
free_page(page);
freed++;
}
@@ -219,7 +218,6 @@ static int efficeon_create_gatt_table(struct 
agp_bridge_data *bridge)
efficeon_free_gatt_table(agp_bridge);
return -ENOMEM;
}
-   SetPageReserved(virt_to_page((char *)page));
 
for (offset = 0; offset < PAGE_SIZE; offset += clflush_chunk)
clflush((char *)page+offset);
-- 
2.17.2



[PATCH RFC 0/7] mm: PG_reserved cleanups and documentation

2018-12-05 Thread David Hildenbrand
I was recently going over all users of PG_reserved. Short story: it is
difficult and sometimes not really clear if setting/checking for
PG_reserved is only a relict from the past. Easy to break things.

I had way more cleanups in this series inititally,
but some architectures take PG_reserved as a way to apply a different
caching strategy (for MMIO pages). So I decided to only include the most
obvious changes (that are less likely to break something).

So let's see if the documentation update for PG_reserved I crafted
actually covers most cases or if there is plenty more.

Most notably, for device memory we can hopefully soon stop setting
it PG_reserved

I only briefly tested this on s390x.

David Hildenbrand (7):
  agp: efficeon: no need to set PG_reserved on GATT tables
  s390/vdso: don't clear PG_reserved
  powerpc/vdso: don't clear PG_reserved
  riscv/vdso: don't clear PG_reserved
  m68k/mm: use __ClearPageReserved()
  arm64: kexec: no need to ClearPageReserved()
  mm: better document PG_reserved

 arch/arm64/kernel/machine_kexec.c |  1 -
 arch/m68k/mm/memory.c |  2 +-
 arch/powerpc/kernel/vdso.c|  2 --
 arch/riscv/kernel/vdso.c  |  1 -
 arch/s390/kernel/vdso.c   |  2 --
 drivers/char/agp/efficeon-agp.c   |  2 --
 include/linux/page-flags.h| 18 --
 7 files changed, 17 insertions(+), 11 deletions(-)

-- 
2.17.2



[PATCH] powerpc/ipic: Remove unused ipic_set_priority()

2018-12-05 Thread Michael Ellerman
ipic_set_priority() has been unused since 2006 when the last usage was
removed in commit b9f0f1bb2bca ("[POWERPC] Adapt ipic driver to new
host_ops interface, add set_irq_type to set IRQ sense").

Reported-by: Dan Carpenter 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/sysdev/ipic.c | 28 
 1 file changed, 28 deletions(-)

diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 6300123ce965..8030a0f55e96 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -771,34 +771,6 @@ struct ipic * __init ipic_init(struct device_node *node, 
unsigned int flags)
return ipic;
 }
 
-int ipic_set_priority(unsigned int virq, unsigned int priority)
-{
-   struct ipic *ipic = ipic_from_irq(virq);
-   unsigned int src = virq_to_hw(virq);
-   u32 temp;
-
-   if (priority > 7)
-   return -EINVAL;
-   if (src > 127)
-   return -EINVAL;
-   if (ipic_info[src].prio == 0)
-   return -EINVAL;
-
-   temp = ipic_read(ipic->regs, ipic_info[src].prio);
-
-   if (priority < 4) {
-   temp &= ~(0x7 << (20 + (3 - priority) * 3));
-   temp |= ipic_info[src].prio_mask << (20 + (3 - priority) * 3);
-   } else {
-   temp &= ~(0x7 << (4 + (7 - priority) * 3));
-   temp |= ipic_info[src].prio_mask << (4 + (7 - priority) * 3);
-   }
-
-   ipic_write(ipic->regs, ipic_info[src].prio, temp);
-
-   return 0;
-}
-
 void ipic_set_highest_priority(unsigned int virq)
 {
struct ipic *ipic = ipic_from_irq(virq);
-- 
2.17.2



Re: [PATCH] powerpc: split compat syscall table out from native table

2018-12-05 Thread Michael Ellerman
Arnd Bergmann  writes:

> PowerPC uses a syscall table with native and compat calls interleaved,
> which is a slightly simpler way to define two matching tables.
>
> As we move to having the tables generated, that advantage is no longer
> important, but the interleaved table gets in the way of using the
> same scripts as on the other architectures.
>
> Split out a new compat_sys_call_table symbol that contains all the
> compat calls, and leave the main table for the native calls, to more
> closely match the method we use everywhere else.
>
> Signed-off-by: Arnd Bergmann 
> ---
> This is completely untested, it's just for illustration and to
> get comments about whether this is a good idea.

Seems like a good idea to me.

The code's not much more complicated, in fact it's probably clearer
except for the extra macros.

It's more cache efficient too, though it probably doesn't really matter.

cheers

> Firoz, can you try to get this working?
> ---
>  arch/powerpc/include/asm/syscall.h |  3 +--
>  arch/powerpc/kernel/entry_64.S |  7 --
>  arch/powerpc/kernel/systbl.S   | 37 --
>  arch/powerpc/kernel/vdso.c |  7 --
>  4 files changed, 41 insertions(+), 13 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/syscall.h 
> b/arch/powerpc/include/asm/syscall.h
> index ab9f3f0a8637..1a0e7a8b1c81 100644
> --- a/arch/powerpc/include/asm/syscall.h
> +++ b/arch/powerpc/include/asm/syscall.h
> @@ -18,9 +18,8 @@
>  #include 
>  
>  /* ftrace syscalls requires exporting the sys_call_table */
> -#ifdef CONFIG_FTRACE_SYSCALLS
>  extern const unsigned long sys_call_table[];
> -#endif /* CONFIG_FTRACE_SYSCALLS */
> +extern const unsigned long compat_sys_call_table[];
>  
>  static inline int syscall_get_nr(struct task_struct *task, struct pt_regs 
> *regs)
>  {
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 7b1693adff2a..5574d92646f1 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -54,6 +54,9 @@
>  SYS_CALL_TABLE:
>   .tc sys_call_table[TC],sys_call_table
>  
> +COMPAT_SYS_CALL_TABLE:
> + .tc compat_sys_call_table[TC],compat_sys_call_table
> +
>  /* This value is used to mark exception frames on the stack. */
>  exception_marker:
>   .tc ID_EXC_MARKER[TC],STACK_FRAME_REGS_MARKER
> @@ -173,7 +176,7 @@ system_call:  /* label this so stack 
> traces look sane */
>   ld  r11,SYS_CALL_TABLE@toc(2)
>   andis.  r10,r10,_TIF_32BIT@h
>   beq 15f
> - addir11,r11,8   /* use 32-bit syscall entries */
> + ld  r11,COMPAT_SYS_CALL_TABLE@toc(2)
>   clrldi  r3,r3,32
>   clrldi  r4,r4,32
>   clrldi  r5,r5,32
> @@ -181,7 +184,7 @@ system_call:  /* label this so stack 
> traces look sane */
>   clrldi  r7,r7,32
>   clrldi  r8,r8,32
>  15:
> - slwir0,r0,4
> + slwir0,r0,3
>  
>   barrier_nospec_asm
>   /*
> diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
> index 919a32746ede..883b8e36964c 100644
> --- a/arch/powerpc/kernel/systbl.S
> +++ b/arch/powerpc/kernel/systbl.S
> @@ -17,13 +17,13 @@
>  #include 
>  
>  #ifdef CONFIG_PPC64
> -#define SYSCALL(func).8byte  
> DOTSYM(sys_##func),DOTSYM(sys_##func)
> -#define COMPAT_SYS(func) .8byte  
> DOTSYM(sys_##func),DOTSYM(compat_sys_##func)
> -#define PPC_SYS(func).8byte  
> DOTSYM(ppc_##func),DOTSYM(ppc_##func)
> -#define OLDSYS(func) .8byte  
> DOTSYM(sys_ni_syscall),DOTSYM(sys_ni_syscall)
> -#define SYS32ONLY(func)  .8byte  
> DOTSYM(sys_ni_syscall),DOTSYM(compat_sys_##func)
> -#define PPC64ONLY(func)  .8byte  
> DOTSYM(ppc_##func),DOTSYM(sys_ni_syscall)
> -#define SYSX(f, f3264, f32)  .8byte  DOTSYM(f),DOTSYM(f3264)
> +#define SYSCALL(func).8byte  DOTSYM(sys_##func)
> +#define COMPAT_SYS(func) .8byte  DOTSYM(sys_##func)
> +#define PPC_SYS(func).8byte  DOTSYM(ppc_##func)
> +#define OLDSYS(func) .8byte  DOTSYM(sys_ni_syscall)
> +#define SYS32ONLY(func)  .8byte  DOTSYM(sys_ni_syscall)
> +#define PPC64ONLY(func)  .8byte  DOTSYM(ppc_##func)
> +#define SYSX(f, f3264, f32)  .8byte  DOTSYM(f)
>  #else
>  #define SYSCALL(func).long   sys_##func
>  #define COMPAT_SYS(func) .long   sys_##func
> @@ -48,3 +48,26 @@
>  sys_call_table:
>  
>  #include 
> +
> +#undef SYSCALL
> +#undef COMPAT_SYS
> +#undef PPC_SYS
> +#undef OLDSYS
> +#undef SYS32ONLY
> +#undef PPC64ONLY
> +#undef SYSX
> +
> +#ifdef CONFIG_COMPAT
> +#define SYSCALL(func).8byte  DOTSYM(sys_##func)
> +#define COMPAT_SYS(func) .8byte  DOTSYM(compat_sys_##func)
> +#define PPC_SYS(func).8byte  DOTSYM(ppc_##func)
> +#define OLDSYS(func) .8byte  DOTSYM(sys_ni_syscall)
> +#define SYS32ONLY(func)  .8byte  DOTSYM(compat_sys_##func)
> +#define PPC64ONLY(func)  

Re: [PATCH] powerpc/ipic: Fix a bounds check in ipic_set_priority()

2018-12-05 Thread Julia Lawall



On Wed, 5 Dec 2018, Michael Ellerman wrote:

> Julia Lawall  writes:
> > On Wed, 5 Dec 2018, Michael Ellerman wrote:
> >
> >> Hi Dan,
> >>
> >> Thanks for the patch.
> >>
> >> Dan Carpenter  writes:
> >> > The ipic_info[] array only has 95 elements so I have made the bounds
> >> > check smaller to prevent a read overflow.  It was Smatch that found
> >> > this issue:
> >> >
> >> > arch/powerpc/sysdev/ipic.c:784 ipic_set_priority()
> >> > error: buffer overflow 'ipic_info' 95 <= 127
> >> >
> >> > Signed-off-by: Dan Carpenter 
> >> > ---
> >> > I wasn't able to find any callers of this code.  Maybe we removed the
> >> > last one in commit b9f0f1bb2bca ("[POWERPC] Adapt ipic driver to new
> >> > host_ops interface, add set_irq_type to set IRQ sense").  So perhaps we
> >> > should just remove it.  I'm not really comfortable doing that myself,
> >> > because I don't know the code well enough and can't build test
> >> > it properly.
> >>
> >> Hah wow, last usage removed in 2006!
> >>
> >> I don't see any mention of it since then, so I'll remove it. If it
> >> breaks something we can put it back.
> >>
> >> Can smatch help us find things like this that are defined non-static but
> >> never used?
> >
> > I wrote a Coccinelle script for this, that just uses grep.  Of course the
> > results need checking because uses can be constructed within macros using
> > #.
>
> That would be cool. I can't immediately see it in scripts/coccinelle, is
> it somewhere else?

No, it needs improvement...  I'll try to do something with it soon.  I
don't think it  is well suited to scrips/coccinelle, because it needs to
know where the kernel tree is to do the grep.

julia

>
> > Are things that are defined static but are never used useful to keep
> > around?
>
> No, but the compiler will usually tell us about them via -Wunused-function.
>
> cheers
>


Re: [PATCH] powerpc/ipic: Fix a bounds check in ipic_set_priority()

2018-12-05 Thread Michael Ellerman
Julia Lawall  writes:
> On Wed, 5 Dec 2018, Michael Ellerman wrote:
>
>> Hi Dan,
>>
>> Thanks for the patch.
>>
>> Dan Carpenter  writes:
>> > The ipic_info[] array only has 95 elements so I have made the bounds
>> > check smaller to prevent a read overflow.  It was Smatch that found
>> > this issue:
>> >
>> > arch/powerpc/sysdev/ipic.c:784 ipic_set_priority()
>> > error: buffer overflow 'ipic_info' 95 <= 127
>> >
>> > Signed-off-by: Dan Carpenter 
>> > ---
>> > I wasn't able to find any callers of this code.  Maybe we removed the
>> > last one in commit b9f0f1bb2bca ("[POWERPC] Adapt ipic driver to new
>> > host_ops interface, add set_irq_type to set IRQ sense").  So perhaps we
>> > should just remove it.  I'm not really comfortable doing that myself,
>> > because I don't know the code well enough and can't build test
>> > it properly.
>>
>> Hah wow, last usage removed in 2006!
>>
>> I don't see any mention of it since then, so I'll remove it. If it
>> breaks something we can put it back.
>>
>> Can smatch help us find things like this that are defined non-static but
>> never used?
>
> I wrote a Coccinelle script for this, that just uses grep.  Of course the
> results need checking because uses can be constructed within macros using
> #.

That would be cool. I can't immediately see it in scripts/coccinelle, is
it somewhere else?

> Are things that are defined static but are never used useful to keep
> around?

No, but the compiler will usually tell us about them via -Wunused-function.

cheers


Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE

2018-12-05 Thread Lubomir Rintel
On Wed, 2018-12-05 at 17:01 +0530, Anshuman Khandual wrote:
> 
> On 12/05/2018 02:56 AM, Lubomir Rintel wrote:
> > On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote:
> > > At present there are multiple places where invalid node number is encoded
> > > as -1. Even though implicitly understood it is always better to have 
> > > macros
> > > in there. Replace these open encodings for an invalid node number with the
> > > global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
> > > 'invalid node' from various places redirecting them to a common 
> > > definition.
> > > 
> > > Signed-off-by: Anshuman Khandual 
> > > ---
> > > Changes in V2:
> > > 
> > > - Added inclusion of 'numa.h' header at various places per Andrew
> > > - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod
> > > 
> > > Changes in V1: (https://lkml.org/lkml/2018/11/23/485)
> > > 
> > > - Dropped OCFS2 changes per Joseph
> > > - Dropped media/video drivers changes per Hans
> > > 
> > > RFC - https://patchwork.kernel.org/patch/10678035/
> > > 
> > > Build tested this with multiple cross compiler options like alpha, sparc,
> > > arm64, x86, powerpc, powerpc64le etc with their default config which might
> > > not have compiled tested all driver related changes. I will appreciate
> > > folks giving this a test in their respective build environment.
> > > 
> > > All these places for replacement were found by running the following grep
> > > patterns on the entire kernel code. Please let me know if this might have
> > > missed some instances. This might also have replaced some false positives.
> > > I will appreciate suggestions, inputs and review.
> > > 
> > > 1. git grep "nid == -1"
> > > 2. git grep "node == -1"
> > > 3. git grep "nid = -1"
> > > 4. git grep "node = -1"
> > > 
> > >  arch/alpha/include/asm/topology.h |  3 ++-
> > >  arch/ia64/kernel/numa.c   |  2 +-
> > >  arch/ia64/mm/discontig.c  |  6 +++---
> > >  arch/ia64/sn/kernel/io_common.c   |  3 ++-
> > >  arch/powerpc/include/asm/pci-bridge.h |  3 ++-
> > >  arch/powerpc/kernel/paca.c|  3 ++-
> > >  arch/powerpc/kernel/pci-common.c  |  3 ++-
> > >  arch/powerpc/mm/numa.c| 14 +++---
> > >  arch/powerpc/platforms/powernv/memtrace.c |  5 +++--
> > >  arch/sparc/kernel/auxio_32.c  |  3 ++-
> > >  arch/sparc/kernel/pci_fire.c  |  3 ++-
> > >  arch/sparc/kernel/pci_schizo.c|  3 ++-
> > >  arch/sparc/kernel/pcic.c  |  7 ---
> > >  arch/sparc/kernel/psycho_common.c |  3 ++-
> > >  arch/sparc/kernel/sbus.c  |  3 ++-
> > >  arch/sparc/mm/init_64.c   |  6 +++---
> > >  arch/sparc/prom/init_32.c |  3 ++-
> > >  arch/sparc/prom/init_64.c |  5 +++--
> > >  arch/sparc/prom/tree_32.c | 13 +++--
> > >  arch/sparc/prom/tree_64.c | 19 ++-
> > >  arch/x86/include/asm/pci.h|  3 ++-
> > >  arch/x86/kernel/apic/x2apic_uv_x.c|  7 ---
> > >  arch/x86/kernel/smpboot.c |  3 ++-
> > >  arch/x86/platform/olpc/olpc_dt.c  | 17 +
> > >  drivers/block/mtip32xx/mtip32xx.c |  5 +++--
> > >  drivers/dma/dmaengine.c   |  4 +++-
> > >  drivers/infiniband/hw/hfi1/affinity.c |  3 ++-
> > >  drivers/infiniband/hw/hfi1/init.c |  3 ++-
> > >  drivers/iommu/dmar.c  |  5 +++--
> > >  drivers/iommu/intel-iommu.c   |  3 ++-
> > >  drivers/misc/sgi-xp/xpc_uv.c  |  3 ++-
> > >  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  5 +++--
> > >  include/linux/device.h|  2 +-
> > >  init/init_task.c  |  3 ++-
> > >  kernel/kthread.c  |  3 ++-
> > >  kernel/sched/fair.c   | 15 ---
> > >  lib/cpumask.c |  3 ++-
> > >  mm/huge_memory.c  | 13 +++--
> > >  mm/hugetlb.c  |  3 ++-
> > >  mm/ksm.c  |  2 +-
> > >  mm/memory.c   |  7 ---
> > >  mm/memory_hotplug.c   | 12 ++--
> > >  mm/mempolicy.c|  2 +-
> > >  mm/page_alloc.c   |  4 ++--
> > >  mm/page_ext.c |  2 +-
> > >  net/core/pktgen.c |  3 ++-
> > >  net/qrtr/qrtr.c   |  3 ++-
> > >  tools/perf/bench/numa.c   |  6 +++---
> > >  48 files changed, 146 insertions(+), 108 deletions(-)
> > Thanks for the patch. It seems to me that 

Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE

2018-12-05 Thread Anshuman Khandual



On 12/05/2018 02:56 AM, Lubomir Rintel wrote:
> On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace these open encodings for an invalid node number with the
>> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
>> 'invalid node' from various places redirecting them to a common definition.
>>
>> Signed-off-by: Anshuman Khandual 
>> ---
>> Changes in V2:
>>
>> - Added inclusion of 'numa.h' header at various places per Andrew
>> - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod
>>
>> Changes in V1: (https://lkml.org/lkml/2018/11/23/485)
>>
>> - Dropped OCFS2 changes per Joseph
>> - Dropped media/video drivers changes per Hans
>>
>> RFC - https://patchwork.kernel.org/patch/10678035/
>>
>> Build tested this with multiple cross compiler options like alpha, sparc,
>> arm64, x86, powerpc, powerpc64le etc with their default config which might
>> not have compiled tested all driver related changes. I will appreciate
>> folks giving this a test in their respective build environment.
>>
>> All these places for replacement were found by running the following grep
>> patterns on the entire kernel code. Please let me know if this might have
>> missed some instances. This might also have replaced some false positives.
>> I will appreciate suggestions, inputs and review.
>>
>> 1. git grep "nid == -1"
>> 2. git grep "node == -1"
>> 3. git grep "nid = -1"
>> 4. git grep "node = -1"
>>
>>  arch/alpha/include/asm/topology.h |  3 ++-
>>  arch/ia64/kernel/numa.c   |  2 +-
>>  arch/ia64/mm/discontig.c  |  6 +++---
>>  arch/ia64/sn/kernel/io_common.c   |  3 ++-
>>  arch/powerpc/include/asm/pci-bridge.h |  3 ++-
>>  arch/powerpc/kernel/paca.c|  3 ++-
>>  arch/powerpc/kernel/pci-common.c  |  3 ++-
>>  arch/powerpc/mm/numa.c| 14 +++---
>>  arch/powerpc/platforms/powernv/memtrace.c |  5 +++--
>>  arch/sparc/kernel/auxio_32.c  |  3 ++-
>>  arch/sparc/kernel/pci_fire.c  |  3 ++-
>>  arch/sparc/kernel/pci_schizo.c|  3 ++-
>>  arch/sparc/kernel/pcic.c  |  7 ---
>>  arch/sparc/kernel/psycho_common.c |  3 ++-
>>  arch/sparc/kernel/sbus.c  |  3 ++-
>>  arch/sparc/mm/init_64.c   |  6 +++---
>>  arch/sparc/prom/init_32.c |  3 ++-
>>  arch/sparc/prom/init_64.c |  5 +++--
>>  arch/sparc/prom/tree_32.c | 13 +++--
>>  arch/sparc/prom/tree_64.c | 19 ++-
>>  arch/x86/include/asm/pci.h|  3 ++-
>>  arch/x86/kernel/apic/x2apic_uv_x.c|  7 ---
>>  arch/x86/kernel/smpboot.c |  3 ++-
>>  arch/x86/platform/olpc/olpc_dt.c  | 17 +
>>  drivers/block/mtip32xx/mtip32xx.c |  5 +++--
>>  drivers/dma/dmaengine.c   |  4 +++-
>>  drivers/infiniband/hw/hfi1/affinity.c |  3 ++-
>>  drivers/infiniband/hw/hfi1/init.c |  3 ++-
>>  drivers/iommu/dmar.c  |  5 +++--
>>  drivers/iommu/intel-iommu.c   |  3 ++-
>>  drivers/misc/sgi-xp/xpc_uv.c  |  3 ++-
>>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  5 +++--
>>  include/linux/device.h|  2 +-
>>  init/init_task.c  |  3 ++-
>>  kernel/kthread.c  |  3 ++-
>>  kernel/sched/fair.c   | 15 ---
>>  lib/cpumask.c |  3 ++-
>>  mm/huge_memory.c  | 13 +++--
>>  mm/hugetlb.c  |  3 ++-
>>  mm/ksm.c  |  2 +-
>>  mm/memory.c   |  7 ---
>>  mm/memory_hotplug.c   | 12 ++--
>>  mm/mempolicy.c|  2 +-
>>  mm/page_alloc.c   |  4 ++--
>>  mm/page_ext.c |  2 +-
>>  net/core/pktgen.c |  3 ++-
>>  net/qrtr/qrtr.c   |  3 ++-
>>  tools/perf/bench/numa.c   |  6 +++---
>>  48 files changed, 146 insertions(+), 108 deletions(-)
> Thanks for the patch. It seems to me that you've got a fairly large
> amount of it wrong though -- perhaps relying just on "git grep" alone
> is not the best idea.

Hmm, okay.

> 
> The diffstat is not all that big, it is entirely plausible to just
> review each hunk manually: just do a "git show -U20" to get some
> context.
> 
> You get a NAK from me for the OLPC DT part, but I 

Re: [LKP] [mm] 19717e78a0: stderr.if(target_node==NUMA_NO_NODE){

2018-12-05 Thread Anshuman Khandual
On 12/05/2018 10:30 AM, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
> 
> commit: 19717e78a04d51512cf0e7b9b09c61f06b2af071 ("[PATCH V2] mm: Replace all 
> open encodings for NUMA_NO_NODE")
> url: 
> https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-Replace-all-open-encodings-for-NUMA_NO_NODE/20181126-203831
> 
> 
> in testcase: perf-sanity-tests
> with following parameters:
> 
>   perf_compiler: gcc
>   ucode: 0x713
> 
> 
> 
> on test machine: 16 threads Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 8G 
> memory
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):

The fix (in Andrew's staging tree) from Stephen Rothwell which adds 

definitions to  should fix this.


Re: [PATCH v2 08/34] dt-bindings: arm: Convert PMU binding to json-schema

2018-12-05 Thread Will Deacon
Hi Rob,

On Mon, Dec 03, 2018 at 03:31:57PM -0600, Rob Herring wrote:
> Convert ARM PMU binding to DT schema format using json-schema.

Just a couple of things below.

> diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml 
> b/Documentation/devicetree/bindings/arm/pmu.yaml
> new file mode 100644
> index ..3ea4abfbf276
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/pmu.yaml
> @@ -0,0 +1,91 @@

[...]

> +properties:
> +  compatible:
> +oneOf:
> +  - items:
> +  - enum:
> +  - apm,potenza-pmu
> +  - arm,armv8-pmuv3
> +  - arm,cortex-a73-pmu
> +  - arm,cortex-a72-pmu
> +  - arm,cortex-a57-pmu
> +  - arm,cortex-a53-pmu
> +  - arm,cortex-a35-pmu
> +  - arm,cortex-a17-pmu
> +  - arm,cortex-a15-pmu
> +  - arm,cortex-a12-pmu
> +  - arm,cortex-a9-pmu
> +  - arm,cortex-a8-pmu
> +  - arm,cortex-a7-pmu
> +  - arm,cortex-a5-pmu
> +  - arm,arm11mpcore-pmu
> +  - arm,arm1176-pmu
> +  - arm,arm1136-pmu
> +  - brcm,vulcan-pmu
> +  - cavium,thunder-pmu
> +  - qcom,scorpion-pmu
> +  - qcom,scorpion-mp-pmu
> +  - qcom,krait-pmu
> +  - items:
> +  - const: arm,cortex-a7-pmu
> +  - const: arm,cortex-a15-pmu

What do these last two mean?

> +
> +  interrupts:
> +# Don't know how many CPUs, so no constraints to specify
> +description: 1 per-cpu interrupt (PPI) or 1 interrupt per core.
> +
> +  interrupt-affinity:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description:
> +  When using SPIs, specifies a list of phandles to CPU
> +  nodes corresponding directly to the affinity of
> +  the SPIs listed in the interrupts property.
> +
> +  When using a PPI, specifies a list of phandles to CPU
> +  nodes corresponding to the set of CPUs which have
> +  a PMU of this type signalling the PPI listed in the
> +  interrupts property, unless this is already specified
> +  by the PPI interrupt specifier itself (in which case
> +  the interrupt-affinity property shouldn't be present).
> +
> +  This property should be present when there is more than
> +  a single SPI.
> +
> +  qcom,no-pc-write:
> +type: boolean
> +description:
> +  Indicates that this PMU doesn't support the 0xc and 0xd events.
> +
> +  secure-reg-access:
> +type: boolean
> +description:
> +  Indicates that the ARMv7 Secure Debug Enable Register
> +  (SDER) is accessible. This will cause the driver to do
> +  any setup required that is only possible in ARMv7 secure
> +  state. If not present the ARMv7 SDER will not be touched,
> +  which means the PMU may fail to operate unless external
> +  code (bootloader or security monitor) has performed the
> +  appropriate initialisation. Note that this property is
> +  not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
> +  in Non-secure state.
> +
> +required:
> +  - compatible

I probably said this before, but I do think that it's a shame to lose the
example binding, especially for something like the PMU where you can
pretty much take an example and bang in your own IRQ numbers to get it
up and running.

Will


Re: use generic DMA mapping code in powerpc V4

2018-12-05 Thread Christian Zigotzky

On 04 December 2018 at 3:24PM, Christoph Hellwig wrote:

On Tue, Dec 04, 2018 at 10:53:39AM +0100, Christian Zigotzky wrote:

I don't know why this kernel doesn't recognize the hard disks connected to
my physical P5020 board and why the onboard ethernet on my PASEMI board
doesn't work. (dma_direct_map_page: overflow)

Do you know if this actually works for the baseline before my patches?
E.g. with commit 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97 ?


Hi Christoph,

Thanks for your reply. I undid all dma mapping commits with the 
following command:


git checkout 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97

After that I compiled the kernels with this code for my P5020 board 
(Cyrus) and for my PASEMI board (Nemo) today.


Result: PASEMI onboard ethernet works again and the P5020 board boots.

It seems the dma mapping commits are the problem.

@All
Could you please test Christoph's kernel on your PASEMI and NXP boards? 
Download:


'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'

Thanks,
Christian



Re: [PATCH] powerpc/ipic: Fix a bounds check in ipic_set_priority()

2018-12-05 Thread Julia Lawall



On Wed, 5 Dec 2018, Michael Ellerman wrote:

> Hi Dan,
>
> Thanks for the patch.
>
> Dan Carpenter  writes:
> > The ipic_info[] array only has 95 elements so I have made the bounds
> > check smaller to prevent a read overflow.  It was Smatch that found
> > this issue:
> >
> > arch/powerpc/sysdev/ipic.c:784 ipic_set_priority()
> > error: buffer overflow 'ipic_info' 95 <= 127
> >
> > Signed-off-by: Dan Carpenter 
> > ---
> > I wasn't able to find any callers of this code.  Maybe we removed the
> > last one in commit b9f0f1bb2bca ("[POWERPC] Adapt ipic driver to new
> > host_ops interface, add set_irq_type to set IRQ sense").  So perhaps we
> > should just remove it.  I'm not really comfortable doing that myself,
> > because I don't know the code well enough and can't build test
> > it properly.
>
> Hah wow, last usage removed in 2006!
>
> I don't see any mention of it since then, so I'll remove it. If it
> breaks something we can put it back.
>
> Can smatch help us find things like this that are defined non-static but
> never used?

I wrote a Coccinelle script for this, that just uses grep.  Of course the
results need checking because uses can be constructed within macros using
#.

Are things that are defined static but are never used useful to keep
around?

julia