LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH -next] powerpc/pseries: Fix platform_no_drv_owner.cocci warnings
From: Julia Lawall @ 2019-02-18 12:53 UTC (permalink / raw)
  To: YueHaibing
  Cc: kernel-janitors, linux-kernel, Oliver O'Halloran,
	Paul Mackerras, Dan Williams, linuxppc-dev
In-Reply-To: <20190218125930.87548-1-yuehaibing@huawei.com>



On Mon, 18 Feb 2019, YueHaibing wrote:

> Remove .owner field if calls are used which set it automatically
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
>  arch/powerpc/platforms/pseries/papr_scm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index bba281b1fe1b..e3f5c1a01950 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -21,6 +21,7 @@
>  	 (1ul << ND_CMD_GET_CONFIG_DATA) | \
>  	 (1ul << ND_CMD_SET_CONFIG_DATA))
>
> +

No need to add a blank line.

julia

>  struct papr_scm_priv {
>  	struct platform_device *pdev;
>  	struct device_node *dn;
> @@ -358,7 +359,6 @@ static struct platform_driver papr_scm_driver = {
>  	.remove = papr_scm_remove,
>  	.driver = {
>  		.name = "papr_scm",
> -		.owner = THIS_MODULE,
>  		.of_match_table = papr_scm_match,
>  	},
>  };
>
>
>
>

^ permalink raw reply

* [PATCH -next] powerpc/pseries: Fix platform_no_drv_owner.cocci warnings
From: YueHaibing @ 2019-02-18 12:59 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Oliver O'Halloran, Dan Williams
  Cc: linuxppc-dev, kernel-janitors, YueHaibing, linux-kernel

Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 arch/powerpc/platforms/pseries/papr_scm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index bba281b1fe1b..e3f5c1a01950 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -21,6 +21,7 @@
 	 (1ul << ND_CMD_GET_CONFIG_DATA) | \
 	 (1ul << ND_CMD_SET_CONFIG_DATA))
 
+
 struct papr_scm_priv {
 	struct platform_device *pdev;
 	struct device_node *dn;
@@ -358,7 +359,6 @@ static struct platform_driver papr_scm_driver = {
 	.remove = papr_scm_remove,
 	.driver = {
 		.name = "papr_scm",
-		.owner = THIS_MODULE,
 		.of_match_table = papr_scm_match,
 	},
 };




^ permalink raw reply related

* [PATCH -next] powerpc/pseries: Drop pointless static qualifier in vpa_debugfs_init()
From: YueHaibing @ 2019-02-18 12:56 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Masahiro Yamada, Aravinda Prasad, Alexey Kardashevskiy,
	Aneesh Kumar K.V, Laurent Dufour
  Cc: linuxppc-dev, kernel-janitors, YueHaibing, linux-kernel

There is no need to have the 'struct dentry *vpa_dir' variable static
since new value always be assigned before use it.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 arch/powerpc/platforms/pseries/lpar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index f2a9f0adc2d3..f649c1b652eb 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -1263,7 +1263,7 @@ static int __init vpa_debugfs_init(void)
 {
 	char name[16];
 	long i;
-	static struct dentry *vpa_dir;
+	struct dentry *vpa_dir;
 
 	if (!firmware_has_feature(FW_FEATURE_SPLPAR))
 		return 0;




^ permalink raw reply related

* [PATCH] powerpc: Move page table dump files in a dedicated subdirectory
From: Christophe Leroy @ 2019-02-18 12:28 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
  Cc: linuxppc-dev, linux-kernel

This patch moves the files related to page table dump in a
dedicated subdirectory.

The purpose is to clean a bit arch/powerpc/mm by regrouping
multiple files handling a dedicated function.

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
 arch/powerpc/Kconfig.debug                                   |  4 ----
 arch/powerpc/mm/Makefile                                     | 10 +---------
 arch/powerpc/mm/ptdump/Makefile                              |  9 +++++++++
 arch/powerpc/mm/{ => ptdump}/dump_bats.c                     |  0
 arch/powerpc/mm/{ => ptdump}/dump_hashpagetable.c            |  0
 arch/powerpc/mm/{ => ptdump}/dump_linuxpagetables-8xx.c      |  0
 arch/powerpc/mm/{ => ptdump}/dump_linuxpagetables-book3s64.c |  0
 arch/powerpc/mm/{ => ptdump}/dump_linuxpagetables-generic.c  |  0
 arch/powerpc/mm/{ => ptdump}/dump_linuxpagetables.c          |  0
 arch/powerpc/mm/{ => ptdump}/dump_linuxpagetables.h          |  0
 arch/powerpc/mm/{ => ptdump}/dump_sr.c                       |  0
 11 files changed, 10 insertions(+), 13 deletions(-)
 create mode 100644 arch/powerpc/mm/ptdump/Makefile
 rename arch/powerpc/mm/{ => ptdump}/dump_bats.c (100%)
 rename arch/powerpc/mm/{ => ptdump}/dump_hashpagetable.c (100%)
 rename arch/powerpc/mm/{ => ptdump}/dump_linuxpagetables-8xx.c (100%)
 rename arch/powerpc/mm/{ => ptdump}/dump_linuxpagetables-book3s64.c (100%)
 rename arch/powerpc/mm/{ => ptdump}/dump_linuxpagetables-generic.c (100%)
 rename arch/powerpc/mm/{ => ptdump}/dump_linuxpagetables.c (100%)
 rename arch/powerpc/mm/{ => ptdump}/dump_linuxpagetables.h (100%)
 rename arch/powerpc/mm/{ => ptdump}/dump_sr.c (100%)

diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index f4961fbcb48d..4e00cb0a5464 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -361,10 +361,6 @@ config PPC_PTDUMP
 
 	  If you are unsure, say N.
 
-config PPC_HTDUMP
-	def_bool y
-	depends on PPC_PTDUMP && PPC_BOOK3S_64
-
 config PPC_FAST_ENDIAN_SWITCH
 	bool "Deprecated fast endian-switch syscall"
         depends on DEBUG_KERNEL && PPC_BOOK3S_64
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index d974f7bcb177..ab2ed80d224d 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -47,14 +47,6 @@ obj-$(CONFIG_NOT_COHERENT_CACHE) += dma-noncoherent.o
 obj-$(CONFIG_HIGHMEM)		+= highmem.o
 obj-$(CONFIG_PPC_COPRO_BASE)	+= copro_fault.o
 obj-$(CONFIG_SPAPR_TCE_IOMMU)	+= mmu_context_iommu.o
-obj-$(CONFIG_PPC_PTDUMP)	+= dump_linuxpagetables.o
-ifdef CONFIG_PPC_PTDUMP
-obj-$(CONFIG_4xx)		+= dump_linuxpagetables-generic.o
-obj-$(CONFIG_PPC_8xx)		+= dump_linuxpagetables-8xx.o
-obj-$(CONFIG_PPC_BOOK3E_MMU)	+= dump_linuxpagetables-generic.o
-obj-$(CONFIG_PPC_BOOK3S_32)	+= dump_linuxpagetables-generic.o dump_bats.o dump_sr.o
-obj-$(CONFIG_PPC_BOOK3S_64)	+= dump_linuxpagetables-book3s64.o
-endif
-obj-$(CONFIG_PPC_HTDUMP)	+= dump_hashpagetable.o
+obj-$(CONFIG_PPC_PTDUMP)	+= ptdump/
 obj-$(CONFIG_PPC_MEM_KEYS)	+= pkeys.o
 obj-$(CONFIG_KASAN)		+= kasan/
diff --git a/arch/powerpc/mm/ptdump/Makefile b/arch/powerpc/mm/ptdump/Makefile
new file mode 100644
index 000000000000..c60578d16ac4
--- /dev/null
+++ b/arch/powerpc/mm/ptdump/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-y	+= dump_linuxpagetables.o
+
+obj-$(CONFIG_4xx)		+= dump_linuxpagetables-generic.o
+obj-$(CONFIG_PPC_8xx)		+= dump_linuxpagetables-8xx.o
+obj-$(CONFIG_PPC_BOOK3E_MMU)	+= dump_linuxpagetables-generic.o
+obj-$(CONFIG_PPC_BOOK3S_32)	+= dump_linuxpagetables-generic.o dump_bats.o dump_sr.o
+obj-$(CONFIG_PPC_BOOK3S_64)	+= dump_linuxpagetables-book3s64.o dump_hashpagetable.o
diff --git a/arch/powerpc/mm/dump_bats.c b/arch/powerpc/mm/ptdump/dump_bats.c
similarity index 100%
rename from arch/powerpc/mm/dump_bats.c
rename to arch/powerpc/mm/ptdump/dump_bats.c
diff --git a/arch/powerpc/mm/dump_hashpagetable.c b/arch/powerpc/mm/ptdump/dump_hashpagetable.c
similarity index 100%
rename from arch/powerpc/mm/dump_hashpagetable.c
rename to arch/powerpc/mm/ptdump/dump_hashpagetable.c
diff --git a/arch/powerpc/mm/dump_linuxpagetables-8xx.c b/arch/powerpc/mm/ptdump/dump_linuxpagetables-8xx.c
similarity index 100%
rename from arch/powerpc/mm/dump_linuxpagetables-8xx.c
rename to arch/powerpc/mm/ptdump/dump_linuxpagetables-8xx.c
diff --git a/arch/powerpc/mm/dump_linuxpagetables-book3s64.c b/arch/powerpc/mm/ptdump/dump_linuxpagetables-book3s64.c
similarity index 100%
rename from arch/powerpc/mm/dump_linuxpagetables-book3s64.c
rename to arch/powerpc/mm/ptdump/dump_linuxpagetables-book3s64.c
diff --git a/arch/powerpc/mm/dump_linuxpagetables-generic.c b/arch/powerpc/mm/ptdump/dump_linuxpagetables-generic.c
similarity index 100%
rename from arch/powerpc/mm/dump_linuxpagetables-generic.c
rename to arch/powerpc/mm/ptdump/dump_linuxpagetables-generic.c
diff --git a/arch/powerpc/mm/dump_linuxpagetables.c b/arch/powerpc/mm/ptdump/dump_linuxpagetables.c
similarity index 100%
rename from arch/powerpc/mm/dump_linuxpagetables.c
rename to arch/powerpc/mm/ptdump/dump_linuxpagetables.c
diff --git a/arch/powerpc/mm/dump_linuxpagetables.h b/arch/powerpc/mm/ptdump/dump_linuxpagetables.h
similarity index 100%
rename from arch/powerpc/mm/dump_linuxpagetables.h
rename to arch/powerpc/mm/ptdump/dump_linuxpagetables.h
diff --git a/arch/powerpc/mm/dump_sr.c b/arch/powerpc/mm/ptdump/dump_sr.c
similarity index 100%
rename from arch/powerpc/mm/dump_sr.c
rename to arch/powerpc/mm/ptdump/dump_sr.c
-- 
2.13.3


^ permalink raw reply related

* Re: [RFC PATCH 4/5] powerpc: move KASAN into its own subdirectory
From: Christophe Leroy @ 2019-02-18 12:27 UTC (permalink / raw)
  To: Michael Ellerman, Daniel Axtens, aneesh.kumar, bsingharora
  Cc: linuxppc-dev, kasan-dev
In-Reply-To: <87d0npqwzr.fsf@concordia.ellerman.id.au>



Le 18/02/2019 à 10:14, Michael Ellerman a écrit :
> christophe leroy <christophe.leroy@c-s.fr> writes:
> 
>> Le 15/02/2019 à 01:04, Daniel Axtens a écrit :
>>> In preparation for adding ppc64 implementations, break out the
>>> code into its own subdirectory.
>>
>> That's not a bad idea, arch/powerpc/mm is rather messy with lot of
>> subarch stuff.
> 
> I'm always happy to have more directories with more focused content.
> 

Nice to know how to make you happy :)

I'll send you a patch for moving all page table dumping stuff into a 
subdirectory.

Christophe

^ permalink raw reply

* [PATCH] powerpc: dump as a single line areas mapping a single physical page.
From: Christophe Leroy @ 2019-02-18 12:25 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
  Cc: linuxppc-dev, linux-kernel

When using KASAN, there are parts of the shadow area where all
pages are mapped to the kasan_early_shadow_page. It is pointless
to dump one line for each of those pages (in the example below there
are 7168 entries pointing to the same physical page).

~# cat /sys/kernel/debug/kernel_page_tables
 ...
---[ kasan shadow mem start ]---
0xf7c00000-0xf8bfffff 0x06fac000       16M        rw       present           dirty  accessed
0xf8c00000-0xf8c03fff 0x00cd0000       16K        r        present           dirty  accessed
0xf8c04000-0xf8c07fff 0x00cd0000       16K        r        present           dirty  accessed
0xf8c08000-0xf8c0bfff 0x00cd0000       16K        r        present           dirty  accessed
0xf8c0c000-0xf8c0ffff 0x00cd0000       16K        r        present           dirty  accessed
0xf8c10000-0xf8c13fff 0x00cd0000       16K        r        present           dirty  accessed
 ... 7168 identical lines
0xffbfc000-0xffbfffff 0x00cd0000       16K        r        present           dirty  accessed
---[ kasan shadow mem end ]---
 ...

This patch modifies linux table dump to dump as a single line areas
where all addresses points to the same physical page. That physical
address is put inside [] to show that all virt pages points to the
same phys page.

~# cat /sys/kernel/debug/kernel_page_tables
 ...
---[ kasan shadow mem start ]---
0xf7c00000-0xf8bfffff  0x06fac000        16M        rw       present           dirty  accessed
0xf8c00000-0xffbfffff [0x00cd0000]       16K        r        present           dirty  accessed
---[ kasan shadow mem end ]---
 ...

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
 arch/powerpc/mm/dump_linuxpagetables.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/mm/dump_linuxpagetables.c b/arch/powerpc/mm/dump_linuxpagetables.c
index 6aa41669ac1a..b0da447197d4 100644
--- a/arch/powerpc/mm/dump_linuxpagetables.c
+++ b/arch/powerpc/mm/dump_linuxpagetables.c
@@ -143,14 +143,19 @@ static void dump_addr(struct pg_state *st, unsigned long addr)
 	unsigned long delta;
 
 #ifdef CONFIG_PPC64
-	seq_printf(st->seq, "0x%016lx-0x%016lx ", st->start_address, addr-1);
-	seq_printf(st->seq, "0x%016lx ", st->start_pa);
+#define REG		"0x%016lx"
 #else
-	seq_printf(st->seq, "0x%08lx-0x%08lx ", st->start_address, addr - 1);
-	seq_printf(st->seq, "0x%08lx ", st->start_pa);
+#define REG		"0x%08lx"
 #endif
 
-	delta = (addr - st->start_address) >> 10;
+	seq_printf(st->seq, REG "-" REG " ", st->start_address, addr - 1);
+	if (st->start_pa == st->last_pa && st->start_address + PAGE_SIZE != addr) {
+		seq_printf(st->seq, "[" REG "]", st->start_pa);
+		delta = PAGE_SIZE >> 10;
+	} else {
+		seq_printf(st->seq, " " REG " ", st->start_pa);
+		delta = (addr - st->start_address) >> 10;
+	}
 	/* Work out what appropriate unit to use */
 	while (!(delta & 1023) && unit[1]) {
 		delta >>= 10;
@@ -184,7 +189,8 @@ static void note_page(struct pg_state *st, unsigned long addr,
 	 */
 	} else if (flag != st->current_flags || level != st->level ||
 		   addr >= st->marker[1].start_address ||
-		   pa != st->last_pa + PAGE_SIZE) {
+		   (pa != st->last_pa + PAGE_SIZE &&
+		    (pa != st->start_pa || st->start_pa != st->last_pa))) {
 
 		/* Check the PTE flags */
 		if (st->current_flags) {
-- 
2.13.3


^ permalink raw reply related

* Re: [PATCH v04] powerpc/numa: Perform full re-add of CPU for PRRN/VPHN topology update
From: Michal Suchánek @ 2019-02-18 10:49 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <d8b67f9d-77d0-2be3-15bc-c7f11bc519f7@linux.vnet.ibm.com>

On Thu, 14 Feb 2019 09:56:26 -0600
Michael Bringmann <mwb@linux.vnet.ibm.com> wrote:

Hello,

> To: linuxppc-dev@lists.ozlabs.org
> To: linux-kernel@vger.kernel.org
> Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Paul Mackerras <paulus@samba.org>
> Michael Ellerman <mpe@ellerman.id.au>
> Nathan Lynch <nathanl@linux.vnet.ibm.com>
> Corentin Labbe <clabbe@baylibre.com>
> Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> Guenter Roeck <linux@roeck-us.net>
> Michael Bringmann <mwb@linux.vnet.ibm.com>
> "Oliver O'Halloran" <oohall@gmail.com>
> Russell Currey <ruscur@russell.cc>
> Haren Myneni <haren@us.ibm.com>
> Al Viro <viro@zeniv.linux.org.uk>
> Kees Cook <keescook@chromium.org>
> Nicholas Piggin <npiggin@gmail.com>
> Rob Herring <robh@kernel.org>
> Juliet Kim <minkim@us.ibm.com>
> Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
> Date: 2018-11-05 16:14:12 -0600
> Subject: [PATCH v04] powerpc/numa: Perform full re-add of CPU for PRRN/VPHN topology update

Looks like something went wrong with the e-mail headers.

Maybe you should re-send?

Thanks

Michal

> 
> On pseries systems, performing changes to a partition's affinity
> can result in altering the nodes a CPU is assigned to the
> current system.  For example, some systems are subject to resource
> balancing operations by the operator or control software.  In such
> environments, system CPUs may be in node 1 and 3 at boot, and be
> moved to nodes 2, 3, and 5, for better performance.
> 
> The current implementation attempts to recognize such changes within
> the powerpc-specific version of arch_update_cpu_topology to modify a
> range of system data structures directly.  However, some scheduler
> data structures may be inaccessible, or the timing of a node change
> may still lead to corruption or error in other modules (e.g. user
> space) which do not receive notification of these changes.
> 
> This patch modifies the PRRN/VPHN topology update worker function to
> recognize an affinity change for a CPU, and to perform a full DLPAR
> remove and add of the CPU instead of dynamically changing its node
> to resolve this issue.
> 
> [Based upon patch submission:
> Subject: [PATCH] powerpc/pseries: Perform full re-add of CPU for topology update post-migration
> From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> Date: Tue Oct 30 05:43:36 AEDT 2018
> ]
> 
> [Replace patch submission:
> Subject: [PATCH] powerpc/topology: Update numa mask when cpu node mapping changes
> From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> Date: Wed Oct 10 15:24:46 AEDT 2018
> ]
> 
> Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
> ---
> Changes in v04:
>   -- Revise tests in topology_timer_fn to check vphn_enabled before prrn_enabled
>   -- Remove unnecessary changes to numa_update_cpu_topology
> Changes in v03:
>   -- Fixed under-scheduling of topo updates.
> Changes in v02:
>   -- Reuse more of the previous implementation to reduce patch size
>   -- Replace former calls to numa_update_cpu_topology(false) by
>      topology_schedule_update
>   -- Make sure that we report topology changes back through
>      arch_update_cpu_topology
>   -- Fix problem observed in powerpc next kernel with updating
>      cpu_associativity_changes_mask in timer_topology_fn when both
>      prrn_enabled and vphn_enabled, and many extra CPUs are possible,
>      but not installed.
>   -- Fix problem with updating cpu_associativity_changes_mask when
>      VPHN associativity information does not arrive until after first
>      call to update topology occurs.
> ---
>  arch/powerpc/include/asm/topology.h |    7 +----
>  arch/powerpc/kernel/rtasd.c         |    2 +
>  arch/powerpc/mm/numa.c              |   47 +++++++++++++++++++++++------------
>  3 files changed, 34 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
> index f85e2b01c3df..79505c371fd5 100644
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -42,7 +42,7 @@ extern void __init dump_numa_cpu_topology(void);
>  
>  extern int sysfs_add_device_to_node(struct device *dev, int nid);
>  extern void sysfs_remove_device_from_node(struct device *dev, int nid);
> -extern int numa_update_cpu_topology(bool cpus_locked);
> +extern void topology_schedule_update(void);
>  
>  static inline void update_numa_cpu_lookup_table(unsigned int cpu, int node)
>  {
> @@ -77,10 +77,7 @@ static inline void sysfs_remove_device_from_node(struct device *dev,
>  {
>  }
>  
> -static inline int numa_update_cpu_topology(bool cpus_locked)
> -{
> -	return 0;
> -}
> +static inline void topology_schedule_update(void) {}
>  
>  static inline void update_numa_cpu_lookup_table(unsigned int cpu, int node) {}
>  
> diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
> index 8a1746d755c9..b1828de7ab78 100644
> --- a/arch/powerpc/kernel/rtasd.c
> +++ b/arch/powerpc/kernel/rtasd.c
> @@ -285,7 +285,7 @@ static void handle_prrn_event(s32 scope)
>  	 * the RTAS event.
>  	 */
>  	pseries_devicetree_update(-scope);
> -	numa_update_cpu_topology(false);
> +	topology_schedule_update();
>  }
>  
>  static void handle_rtas_event(const struct rtas_error_log *log)
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index b5d1c45c1475..eb63479f09d7 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1077,6 +1077,8 @@ static int prrn_enabled;
>  static void reset_topology_timer(void);
>  static int topology_timer_secs = 1;
>  static int topology_inited;
> +static int topology_update_in_progress;
> +static int topology_changed;
>  
>  /*
>   * Change polling interval for associativity changes.
> @@ -1297,9 +1299,9 @@ static int update_lookup_table(void *data)
>   * Update the node maps and sysfs entries for each cpu whose home node
>   * has changed. Returns 1 when the topology has changed, and 0 otherwise.
>   *
> - * cpus_locked says whether we already hold cpu_hotplug_lock.
> + * readd_cpus: Also readd any CPUs that have changed affinity
>   */
> -int numa_update_cpu_topology(bool cpus_locked)
> +static int numa_update_cpu_topology(bool readd_cpus)
>  {
>  	unsigned int cpu, sibling, changed = 0;
>  	struct topology_update_data *updates, *ud;
> @@ -1307,7 +1309,8 @@ int numa_update_cpu_topology(bool cpus_locked)
>  	struct device *dev;
>  	int weight, new_nid, i = 0;
>  
> -	if (!prrn_enabled && !vphn_enabled && topology_inited)
> +	if ((!prrn_enabled && !vphn_enabled && topology_inited) ||
> +		topology_update_in_progress)
>  		return 0;
>  
>  	weight = cpumask_weight(&cpu_associativity_changes_mask);
> @@ -1318,6 +1321,8 @@ int numa_update_cpu_topology(bool cpus_locked)
>  	if (!updates)
>  		return 0;
>  
> +	topology_update_in_progress = 1;
> +
>  	cpumask_clear(&updated_cpus);
>  
>  	for_each_cpu(cpu, &cpu_associativity_changes_mask) {
> @@ -1339,16 +1344,21 @@ int numa_update_cpu_topology(bool cpus_locked)
>  
>  		new_nid = find_and_online_cpu_nid(cpu);
>  
> -		if (new_nid == numa_cpu_lookup_table[cpu]) {
> +		if ((new_nid == numa_cpu_lookup_table[cpu]) ||
> +			!cpu_present(cpu)) {
>  			cpumask_andnot(&cpu_associativity_changes_mask,
>  					&cpu_associativity_changes_mask,
>  					cpu_sibling_mask(cpu));
> -			dbg("Assoc chg gives same node %d for cpu%d\n",
> +			if (cpu_present(cpu))
> +				dbg("Assoc chg gives same node %d for cpu%d\n",
>  					new_nid, cpu);
>  			cpu = cpu_last_thread_sibling(cpu);
>  			continue;
>  		}
>  
> +		if (readd_cpus)
> +			dlpar_cpu_readd(cpu);
> +
>  		for_each_cpu(sibling, cpu_sibling_mask(cpu)) {
>  			ud = &updates[i++];
>  			ud->next = &updates[i];
> @@ -1390,7 +1400,7 @@ int numa_update_cpu_topology(bool cpus_locked)
>  	if (!cpumask_weight(&updated_cpus))
>  		goto out;
>  
> -	if (cpus_locked)
> +	if (!readd_cpus)
>  		stop_machine_cpuslocked(update_cpu_topology, &updates[0],
>  					&updated_cpus);
>  	else
> @@ -1401,9 +1411,9 @@ int numa_update_cpu_topology(bool cpus_locked)
>  	 * offline CPUs. It is best to perform this update from the stop-
>  	 * machine context.
>  	 */
> -	if (cpus_locked)
> +	if (!readd_cpus)
>  		stop_machine_cpuslocked(update_lookup_table, &updates[0],
> -					cpumask_of(raw_smp_processor_id()));
> +			     cpumask_of(raw_smp_processor_id()));
>  	else
>  		stop_machine(update_lookup_table, &updates[0],
>  			     cpumask_of(raw_smp_processor_id()));
> @@ -1420,35 +1430,40 @@ int numa_update_cpu_topology(bool cpus_locked)
>  	}
>  
>  out:
> +	topology_update_in_progress = 0;
>  	kfree(updates);
>  	return changed;
>  }
>  
>  int arch_update_cpu_topology(void)
>  {
> -	return numa_update_cpu_topology(true);
> +	return numa_update_cpu_topology(false);
>  }
>  
>  static void topology_work_fn(struct work_struct *work)
>  {
> -	rebuild_sched_domains();
> +	lock_device_hotplug();
> +	if (numa_update_cpu_topology(true))
> +		rebuild_sched_domains();
> +	unlock_device_hotplug();
>  }
>  static DECLARE_WORK(topology_work, topology_work_fn);
>  
> -static void topology_schedule_update(void)
> +void topology_schedule_update(void)
>  {
> -	schedule_work(&topology_work);
> +	if (!topology_update_in_progress)
> +		schedule_work(&topology_work);
>  }
>  
>  static void topology_timer_fn(struct timer_list *unused)
>  {
> -	if (prrn_enabled && cpumask_weight(&cpu_associativity_changes_mask))
> -		topology_schedule_update();
> -	else if (vphn_enabled) {
> +	if (vphn_enabled) {
>  		if (update_cpu_associativity_changes_mask() > 0)
>  			topology_schedule_update();
>  		reset_topology_timer();
>  	}
> +	else if (prrn_enabled && cpumask_weight(&cpu_associativity_changes_mask))
> +		topology_schedule_update();
>  }
>  static struct timer_list topology_timer;
>  
> @@ -1553,7 +1568,7 @@ void __init shared_proc_topology_init(void)
>  	if (lppaca_shared_proc(get_lppaca())) {
>  		bitmap_fill(cpumask_bits(&cpu_associativity_changes_mask),
>  			    nr_cpumask_bits);
> -		numa_update_cpu_topology(false);
> +		topology_schedule_update();
>  	}
>  }
>  
> 


^ permalink raw reply

* Re: [PATCH v5 3/3] powerpc/32: Add KASAN support
From: Michael Ellerman @ 2019-02-18  9:27 UTC (permalink / raw)
  To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
	Nicholas Piggin, Aneesh Kumar K.V, Andrey Ryabinin,
	Alexander Potapenko, Dmitry Vyukov, Daniel Axtens
  Cc: linux-mm, linuxppc-dev, linux-kernel, kasan-dev
In-Reply-To: <3429fe33b68206ecc2a725a740937bbaef2d1ac8.1549935251.git.christophe.leroy@c-s.fr>

Christophe Leroy <christophe.leroy@c-s.fr> writes:

> diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
> index e0637730a8e7..dba2c1038363 100644
> --- a/arch/powerpc/include/asm/ppc_asm.h
> +++ b/arch/powerpc/include/asm/ppc_asm.h
> @@ -251,6 +251,10 @@ GLUE(.,name):
>  
>  #define _GLOBAL_TOC(name) _GLOBAL(name)
>  
> +#define KASAN_OVERRIDE(x, y) \
> +	.weak x;	     \
> +	.set x, y
> +

Can you add a comment describing what that does and why?

> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 879b36602748..fc4c42262694 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -16,8 +16,9 @@ CFLAGS_prom_init.o      += -fPIC
>  CFLAGS_btext.o		+= -fPIC
>  endif
>  
> -CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
> -CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
> +CFLAGS_early_32.o += -DDISABLE_BRANCH_PROFILING
> +CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) -DDISABLE_BRANCH_PROFILING
> +CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) -DDISABLE_BRANCH_PROFILING

Why do we need to disable branch profiling now?

I'd probably be happier if all the CFLAGS changes were done in a leadup
patch to make them more obvious.

> diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/kernel/prom_init_check.sh
> index 667df97d2595..da6bb16e0876 100644
> --- a/arch/powerpc/kernel/prom_init_check.sh
> +++ b/arch/powerpc/kernel/prom_init_check.sh
> @@ -16,8 +16,16 @@
>  # If you really need to reference something from prom_init.o add
>  # it to the list below:
>  
> +grep CONFIG_KASAN=y .config >/dev/null

Just to be safe "^CONFIG_KASAN=y$" ?

> +if [ $? -eq 0 ]
> +then
> +	MEMFCT="__memcpy __memset"
> +else
> +	MEMFCT="memcpy memset"
> +fi

MEM_FUNCS ?

> diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
> index 3bf9fc6fd36c..ce8d4a9f810a 100644
> --- a/arch/powerpc/lib/Makefile
> +++ b/arch/powerpc/lib/Makefile
> @@ -8,6 +8,14 @@ ccflags-$(CONFIG_PPC64)	:= $(NO_MINIMAL_TOC)
>  CFLAGS_REMOVE_code-patching.o = $(CC_FLAGS_FTRACE)
>  CFLAGS_REMOVE_feature-fixups.o = $(CC_FLAGS_FTRACE)
>  
> +KASAN_SANITIZE_code-patching.o := n
> +KASAN_SANITIZE_feature-fixups.o := n
> +
> +ifdef CONFIG_KASAN
> +CFLAGS_code-patching.o += -DDISABLE_BRANCH_PROFILING
> +CFLAGS_feature-fixups.o += -DDISABLE_BRANCH_PROFILING
> +endif

There's that branch profiling again, though here it's only if KASAN is enabled.

> diff --git a/arch/powerpc/mm/kasan_init.c b/arch/powerpc/mm/kasan_init.c
> new file mode 100644
> index 000000000000..bd8e0a263e12
> --- /dev/null
> +++ b/arch/powerpc/mm/kasan_init.c
> @@ -0,0 +1,114 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#define DISABLE_BRANCH_PROFILING
> +
> +#include <linux/kasan.h>
> +#include <linux/printk.h>
> +#include <linux/memblock.h>
> +#include <linux/sched/task.h>
> +#include <asm/pgalloc.h>
> +
> +void __init kasan_early_init(void)
> +{
> +	unsigned long addr = KASAN_SHADOW_START;
> +	unsigned long end = KASAN_SHADOW_END;
> +	unsigned long next;
> +	pmd_t *pmd = pmd_offset(pud_offset(pgd_offset_k(addr), addr), addr);

Can none of those fail?


cheers

^ permalink raw reply

* Re: [RFC PATCH 4/5] powerpc: move KASAN into its own subdirectory
From: Michael Ellerman @ 2019-02-18  9:14 UTC (permalink / raw)
  To: christophe leroy, Daniel Axtens, aneesh.kumar, bsingharora
  Cc: linuxppc-dev, kasan-dev
In-Reply-To: <252ac94f-1fd6-8df1-9dd3-95ea3d68b67e@c-s.fr>

christophe leroy <christophe.leroy@c-s.fr> writes:

> Le 15/02/2019 à 01:04, Daniel Axtens a écrit :
>> In preparation for adding ppc64 implementations, break out the
>> code into its own subdirectory.
>
> That's not a bad idea, arch/powerpc/mm is rather messy with lot of
> subarch stuff.

I'm always happy to have more directories with more focused content.

cheers

^ permalink raw reply

* [PATCH V3] ASoC: fsl_esai: fix register setting issue in RIGHT_J mode
From: S.j. Wang @ 2019-02-18  8:29 UTC (permalink / raw)
  To: timur@kernel.org, nicoleotsuka@gmail.com, Xiubo.Lee@gmail.com,
	festevam@gmail.com, broonie@kernel.org,
	alsa-devel@alsa-project.org
  Cc: linuxppc-dev@lists.ozlabs.org

The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to
wrong register, correct it.

Fixes 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Ackedy-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
Changes in v3
- Add Cc: <stable@vger.kernel.org>

 sound/soc/fsl/fsl_esai.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 57b484768a58..afe67c865330 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -398,7 +398,8 @@ static int fsl_esai_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
 		break;
 	case SND_SOC_DAIFMT_RIGHT_J:
 		/* Data on rising edge of bclk, frame high, right aligned */
-		xccr |= ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP | ESAI_xCR_xWA;
+		xccr |= ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP;
+		xcr  |= ESAI_xCR_xWA;
 		break;
 	case SND_SOC_DAIFMT_DSP_A:
 		/* Data on rising edge of bclk, frame high, 1clk before data */
@@ -455,12 +456,12 @@ static int fsl_esai_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
 		return -EINVAL;
 	}
 
-	mask = ESAI_xCR_xFSL | ESAI_xCR_xFSR;
+	mask = ESAI_xCR_xFSL | ESAI_xCR_xFSR | ESAI_xCR_xWA;
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, mask, xcr);
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR, mask, xcr);
 
 	mask = ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP | ESAI_xCCR_xFSP |
-		ESAI_xCCR_xFSD | ESAI_xCCR_xCKD | ESAI_xCR_xWA;
+		ESAI_xCCR_xFSD | ESAI_xCCR_xCKD;
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR, mask, xccr);
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR, mask, xccr);
 
-- 
1.9.1


^ permalink raw reply related

* RE: [PATCH V2] ASoC: fsl_esai: fix register setting issue in RIGHT_J mode
From: S.j. Wang @ 2019-02-18  8:21 UTC (permalink / raw)
  To: Greg KH
  Cc: alsa-devel@alsa-project.org, timur@kernel.org,
	Xiubo.Lee@gmail.com, linuxppc-dev@lists.ozlabs.org,
	stable@vger.kernel.org, nicoleotsuka@gmail.com,
	broonie@kernel.org, festevam@gmail.com
In-Reply-To: <20190218080345.GA27289@kroah.com>

Thanks, will send the patch again.

Best regards
Wang shengjiu
> 
> On Mon, Feb 18, 2019 at 02:08:52AM +0000, S.j. Wang wrote:
> > Fixes commit 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
> >
> > The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to
> > wrong register, correct it.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > Reviewed-by: Fabio Estevam <festevam@gmail.com>
> > Ackedy-by: Nicolin Chen <nicoleotsuka@gmail.com>
> > ---
> > Changes in v2
> > - add Fixes tag and cc stable kernel.
> 
> <formletter>
> 
> This is not the correct way to submit patches for inclusion in the stable
> kernel tree.  Please read:
> 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.kernel.org%2Fdoc%2Fhtml%2Flatest%2Fprocess%2Fstable-kernel-
> rules.html&amp;data=02%7C01%7Cshengjiu.wang%40nxp.com%7C16b1bd8
> d2f1c43b82dd108d695779d87%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
> 0%7C0%7C636860738312039576&amp;sdata=l5OkD8ToHrcGa4dbXOuHdFTIF
> pVdN9u5AzCZKj2C5Ew%3D&amp;reserved=0
> for how to do this properly.
> 
> </formletter>

^ permalink raw reply

* Re: [PATCH V2] ASoC: fsl_esai: fix register setting issue in RIGHT_J mode
From: Greg KH @ 2019-02-18  8:03 UTC (permalink / raw)
  To: S.j. Wang
  Cc: alsa-devel@alsa-project.org, timur@kernel.org,
	Xiubo.Lee@gmail.com, linuxppc-dev@lists.ozlabs.org,
	stable@vger.kernel.org, nicoleotsuka@gmail.com,
	broonie@kernel.org, festevam@gmail.com
In-Reply-To: <2a1997c2cd213ebfde70a2b325644de51e77d159.1550455620.git.shengjiu.wang@nxp.com>

On Mon, Feb 18, 2019 at 02:08:52AM +0000, S.j. Wang wrote:
> Fixes commit 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
> 
> The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to
> wrong register, correct it.
> 
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
> Ackedy-by: Nicolin Chen <nicoleotsuka@gmail.com>
> ---
> Changes in v2
> - add Fixes tag and cc stable kernel.

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

^ permalink raw reply

* Re: [PATCH kernel] powerpc/powernv/sriov: Register IOMMU groups for VFs
From: Alexey Kardashevskiy @ 2019-02-18  6:43 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: kvm-ppc, David Gibson
In-Reply-To: <20190218055801.35165-1-aik@ozlabs.ru>



On 18/02/2019 16:58, Alexey Kardashevskiy wrote:
> The compound IOMMU group rework moved iommu_register_group() together in
> pnv_pci_ioda_setup_iommu_api() (which is a part of ppc_md.pcibios_fixup).
> As the result, pnv_ioda_setup_bus_iommu_group() does not create groups
> any more, it only adds devices to groups.
> 
> This works fine for boot time devices. However IOMMU groups for SRIOV's
> VFs were added by pnv_ioda_setup_bus_iommu_group() so this got broken:
> pnv_tce_iommu_bus_notifier() expects a group to be registered for VF
> and it is not.
> 
> This adds missing group registration and adds a NULL pointer check into
> the bus notifier so we won't stop in xmon if there is no group, although
> it is not expected to happen now.
> 
> Fixes: 0bd971676e68 "powerpc/powernv/npu: Add compound IOMMU groups"
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Forgot this:

Reported-by: Santwana Samantray<santwana.samantray@in.ibm.com>


> ---
> 
> Fixes https://bugzilla.linux.ibm.com/show_bug.cgi?id=175550
> "Kernel Oops while creating SRIOV VF's."
> 
> 
> ---
>  arch/powerpc/platforms/powernv/pci-ioda.c | 2 ++
>  arch/powerpc/platforms/powernv/pci.c      | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 7db3119..145373f 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -1593,6 +1593,8 @@ static void pnv_ioda_setup_vf_PE(struct pci_dev *pdev, u16 num_vfs)
>  
>  		pnv_pci_ioda2_setup_dma_pe(phb, pe);
>  #ifdef CONFIG_IOMMU_API
> +		iommu_register_group(&pe->table_group,
> +				pe->phb->hose->global_number, pe->pe_number);
>  		pnv_ioda_setup_bus_iommu_group(pe, &pe->table_group, NULL);
>  #endif
>  	}
> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
> index 45fb70b..ef9448a 100644
> --- a/arch/powerpc/platforms/powernv/pci.c
> +++ b/arch/powerpc/platforms/powernv/pci.c
> @@ -1147,6 +1147,8 @@ static int pnv_tce_iommu_bus_notifier(struct notifier_block *nb,
>  			return 0;
>  
>  		pe = &phb->ioda.pe_array[pdn->pe_number];
> +		if (!pe->table_group.group)
> +			return 0;
>  		iommu_add_device(&pe->table_group, dev);
>  		return 0;
>  	case BUS_NOTIFY_DEL_DEVICE:
> 

-- 
Alexey

^ permalink raw reply

* Re: [RFC PATCH 3/5] kasan: allow architectures to provide an outline readiness check
From: Daniel Axtens @ 2019-02-18  6:13 UTC (permalink / raw)
  To: christophe leroy, aneesh.kumar, bsingharora
  Cc: linuxppc-dev, Aneesh Kumar K . V, kasan-dev
In-Reply-To: <dd65d283-5f6b-8e07-37ba-8ebc24cd5294@c-s.fr>

christophe leroy <christophe.leroy@c-s.fr> writes:

> Le 15/02/2019 à 01:04, Daniel Axtens a écrit :
>> In powerpc (as I understand it), we spend a lot of time in boot
>> running in real mode before MMU paging is initalised. During
>> this time we call a lot of generic code, including printk(). If
>> we try to access the shadow region during this time, things fail.
>> 
>> My attempts to move early init before the first printk have not
>> been successful. (Both previous RFCs for ppc64 - by 2 different
>> people - have needed this trick too!)
>> 
>> So, allow architectures to define a check_return_arch_not_ready()
>> hook that bails out of check_memory_region_inline() unless the
>> arch has done all of the init.
>> 
>> Link: https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
>> Link: https://patchwork.ozlabs.org/patch/795211/      # ppc radix series
>> Originally-by: Balbir Singh <bsingharora@gmail.com>
>> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> Signed-off-by: Daniel Axtens <dja@axtens.net>
>> ---
>>   include/linux/kasan.h | 4 ++++
>>   mm/kasan/generic.c    | 2 ++
>>   2 files changed, 6 insertions(+)
>> 
>> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
>> index f6261840f94c..83edc5e2b6a0 100644
>> --- a/include/linux/kasan.h
>> +++ b/include/linux/kasan.h
>> @@ -14,6 +14,10 @@ struct task_struct;
>>   #include <asm/kasan.h>
>>   #include <asm/pgtable.h>
>>   
>> +#ifndef check_return_arch_not_ready
>> +#define check_return_arch_not_ready()	do { } while (0)
>> +#endif
>
> A static inline would be better I believe.
>
> Something like
>
> #ifndef kasan_arch_is_ready
> static inline bool kasan_arch_is_ready {return true;}
> #endif
>
>> +
>>   extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
>>   extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
>>   extern pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD];
>> diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
>> index bafa2f986660..4c18bbd09a20 100644
>> --- a/mm/kasan/generic.c
>> +++ b/mm/kasan/generic.c
>> @@ -170,6 +170,8 @@ static __always_inline void check_memory_region_inline(unsigned long addr,
>>   						size_t size, bool write,
>>   						unsigned long ret_ip)
>>   {
>> +	check_return_arch_not_ready();
>> +
>
> Not good for readibility that the above macro embeds a return, something 
> like below would be better I think:
>
> 	if (!kasan_arch_is_ready())
> 		return;
>
> Unless somebody minds, I'll do the change and take this patch in my 
> series in order to handle the case of book3s/32 hash.

Please do; feel free to take as many of the patches as you would like
and I'll rebase whatever is left on the next version of your series.

The idea with the macro magic was to take advantage of the speed of
static keys (I think, I borrowed it from Balbir's patch). Perhaps an
inline function will achieve this anyway, but given that KASAN with
outline instrumentation is inevitably slow, I guess it doesn't matter
much either way.

Regards,
Daniel
>
> Christophe
>
>>   	if (unlikely(size == 0))
>>   		return;
>>   
>> 
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
> https://www.avast.com/antivirus

^ permalink raw reply

* [PATCH kernel] powerpc/powernv/sriov: Register IOMMU groups for VFs
From: Alexey Kardashevskiy @ 2019-02-18  5:58 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Alexey Kardashevskiy, kvm-ppc, David Gibson

The compound IOMMU group rework moved iommu_register_group() together in
pnv_pci_ioda_setup_iommu_api() (which is a part of ppc_md.pcibios_fixup).
As the result, pnv_ioda_setup_bus_iommu_group() does not create groups
any more, it only adds devices to groups.

This works fine for boot time devices. However IOMMU groups for SRIOV's
VFs were added by pnv_ioda_setup_bus_iommu_group() so this got broken:
pnv_tce_iommu_bus_notifier() expects a group to be registered for VF
and it is not.

This adds missing group registration and adds a NULL pointer check into
the bus notifier so we won't stop in xmon if there is no group, although
it is not expected to happen now.

Fixes: 0bd971676e68 "powerpc/powernv/npu: Add compound IOMMU groups"
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---

Fixes https://bugzilla.linux.ibm.com/show_bug.cgi?id=175550
"Kernel Oops while creating SRIOV VF's."


---
 arch/powerpc/platforms/powernv/pci-ioda.c | 2 ++
 arch/powerpc/platforms/powernv/pci.c      | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 7db3119..145373f 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1593,6 +1593,8 @@ static void pnv_ioda_setup_vf_PE(struct pci_dev *pdev, u16 num_vfs)
 
 		pnv_pci_ioda2_setup_dma_pe(phb, pe);
 #ifdef CONFIG_IOMMU_API
+		iommu_register_group(&pe->table_group,
+				pe->phb->hose->global_number, pe->pe_number);
 		pnv_ioda_setup_bus_iommu_group(pe, &pe->table_group, NULL);
 #endif
 	}
diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
index 45fb70b..ef9448a 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -1147,6 +1147,8 @@ static int pnv_tce_iommu_bus_notifier(struct notifier_block *nb,
 			return 0;
 
 		pe = &phb->ioda.pe_array[pdn->pe_number];
+		if (!pe->table_group.group)
+			return 0;
 		iommu_add_device(&pe->table_group, dev);
 		return 0;
 	case BUS_NOTIFY_DEL_DEVICE:
-- 
2.17.1


^ permalink raw reply related

* Re: [PATCH] cpufreq: powernv: fix missing check of return value in init_powernv_pstates()
From: Viresh Kumar @ 2019-02-18  4:59 UTC (permalink / raw)
  To: Yangtao Li; +Cc: linux-pm, rjw, linux-kernel, paulus, linuxppc-dev
In-Reply-To: <20190216170623.12634-1-tiny.windzz@gmail.com>

On 16-02-19, 12:06, Yangtao Li wrote:
> kmalloc() could fail, so insert a check of its return value. And
> if it fails, returns -ENOMEM.
> 
> And remove (struct pstate_idx_revmap_data *) to fix coccinelle WARNING
> by the way.
> 
> WARNING: casting value returned by memory allocation function to (struct
> pstate_idx_revmap_data *) is useless.
> 
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
>  drivers/cpufreq/powernv-cpufreq.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> index 7e7ad3879c4e..d2230812fa4b 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -244,6 +244,7 @@ static int init_powernv_pstates(void)
>  	u32 len_ids, len_freqs;
>  	u32 pstate_min, pstate_max, pstate_nominal;
>  	u32 pstate_turbo, pstate_ultra_turbo;
> +	int rc = -ENODEV;
>  
>  	power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
>  	if (!power_mgt) {
> @@ -327,8 +328,11 @@ static int init_powernv_pstates(void)
>  		powernv_freqs[i].frequency = freq * 1000; /* kHz */
>  		powernv_freqs[i].driver_data = id & 0xFF;
>  
> -		revmap_data = (struct pstate_idx_revmap_data *)
> -			      kmalloc(sizeof(*revmap_data), GFP_KERNEL);
> +		revmap_data = kmalloc(sizeof(*revmap_data), GFP_KERNEL);
> +		if (!revmap_data) {
> +			rc = -ENOMEM;
> +			goto out;
> +		}
>  
>  		revmap_data->pstate_id = id & 0xFF;
>  		revmap_data->cpufreq_table_idx = i;
> @@ -357,7 +361,7 @@ static int init_powernv_pstates(void)
>  	return 0;
>  out:
>  	of_node_put(power_mgt);
> -	return -ENODEV;
> +	return rc;
>  }
>  
>  /* Returns the CPU frequency corresponding to the pstate_id. */

Applied. Thanks.

-- 
viresh

^ permalink raw reply

* Re: [PATCH 10/11] lib: consolidate the GENERIC_HWEIGHT symbol
From: Masahiro Yamada @ 2019-02-18  3:06 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: linux-xtensa, Linux Kbuild mailing list, linux-s390,
	Linux Kernel Mailing List, linux-riscv, linuxppc-dev
In-Reply-To: <20190213174005.28785-11-hch@lst.de>

On Thu, Feb 14, 2019 at 2:41 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Introduce a new ARCH_HAS_HWEIGHT symbol for alpha and ia64,


I think this is really confusing.


"ARCH has its own optimized hweight implementation"

   is not equivalent to

"ARCH does not need generic hweight at all".


For example, see

arch/powerpc/lib/hweight_64.S


As far as I understood the code,
it will fallback to generic lib/hweight.c
if it turns out the optimized one is not available.


Thanks.


> and just
> default to the generic version otherwise.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  arch/alpha/Kconfig      | 5 +----
>  arch/arc/Kconfig        | 3 ---
>  arch/arm/Kconfig        | 4 ----
>  arch/arm64/Kconfig      | 3 ---
>  arch/c6x/Kconfig        | 3 ---
>  arch/csky/Kconfig       | 3 ---
>  arch/h8300/Kconfig      | 3 ---
>  arch/hexagon/Kconfig    | 3 ---
>  arch/ia64/Kconfig       | 1 +
>  arch/m68k/Kconfig       | 4 ----
>  arch/microblaze/Kconfig | 3 ---
>  arch/mips/Kconfig       | 4 ----
>  arch/nds32/Kconfig      | 3 ---
>  arch/nios2/Kconfig      | 3 ---
>  arch/openrisc/Kconfig   | 3 ---
>  arch/parisc/Kconfig     | 4 ----
>  arch/powerpc/Kconfig    | 4 ----
>  arch/riscv/Kconfig      | 3 ---
>  arch/s390/Kconfig       | 3 ---
>  arch/sh/Kconfig         | 3 ---
>  arch/sparc/Kconfig      | 4 ----
>  arch/unicore32/Kconfig  | 3 ---
>  arch/x86/Kconfig        | 3 ---
>  arch/x86/um/Kconfig     | 3 ---
>  arch/xtensa/Kconfig     | 3 ---
>  lib/Kconfig             | 7 +++++++
>  26 files changed, 9 insertions(+), 79 deletions(-)
>
> diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
> index 65b5514e5a7f..a549c53563e8 100644
> --- a/arch/alpha/Kconfig
> +++ b/arch/alpha/Kconfig
> @@ -2,6 +2,7 @@
>  config ALPHA
>         bool
>         default y
> +       select ARCH_HAS_HWEIGHT if ALPHA_EV67
>         select ARCH_MIGHT_HAVE_PC_PARPORT
>         select ARCH_MIGHT_HAVE_PC_SERIO
>         select ARCH_NO_PREEMPT
> @@ -446,10 +447,6 @@ config ALPHA_IRONGATE
>         depends on ALPHA_NAUTILUS
>         default y
>
> -config GENERIC_HWEIGHT
> -       bool
> -       default y if !ALPHA_EV67
> -
>  config ALPHA_AVANTI
>         bool
>         depends on ALPHA_XL || ALPHA_AVANTI_CH
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 6476404b98b8..8bf4c0f7cc1d 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -72,9 +72,6 @@ config MMU
>  config NO_IOPORT_MAP
>         def_bool y
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config HAVE_ARCH_TRANSPARENT_HUGEPAGE
>         def_bool y
>         depends on ARC_MMU_V4
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index c230fb1e09ba..b47825767e3d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -182,10 +182,6 @@ config ARCH_HAS_BANDGAP
>  config FIX_EARLYCON_MEM
>         def_bool y if MMU
>
> -config GENERIC_HWEIGHT
> -       bool
> -       default y
> -
>  config ARCH_MAY_HAVE_PC_FDC
>         bool
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7cc3334aba29..98c3776ccf6b 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -237,9 +237,6 @@ config ILLEGAL_POINTER_VALUE
>         hex
>         default 0xdead000000000000
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config ZONE_DMA32
>         def_bool y
>
> diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
> index 19b145ef7d92..c439d2f46af0 100644
> --- a/arch/c6x/Kconfig
> +++ b/arch/c6x/Kconfig
> @@ -28,9 +28,6 @@ config MMU
>  config FPU
>         def_bool n
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config C6X_BIG_KERNEL
>         bool "Build a big kernel"
>         help
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> index c0a49cbd3df0..14a9905e99a4 100644
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -84,9 +84,6 @@ config CPU_NO_USER_BKPT
>           instruction exception.
>           In kernel we parse the *regs->pc to determine whether to send SIGTRAP or not.
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config MMU
>         def_bool y
>
> diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
> index 4f5a1efab822..77ce104bb42e 100644
> --- a/arch/h8300/Kconfig
> +++ b/arch/h8300/Kconfig
> @@ -27,9 +27,6 @@ config H8300
>  config CPU_BIG_ENDIAN
>         def_bool y
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config NO_IOPORT_MAP
>         def_bool y
>
> diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
> index 7a01f4c5a4f6..fb2996063d5a 100644
> --- a/arch/hexagon/Kconfig
> +++ b/arch/hexagon/Kconfig
> @@ -61,9 +61,6 @@ config MMU
>  config GENERIC_IRQ_PROBE
>         def_bool y
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  menu "Machine selection"
>
>  choice
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index fc44c046953e..c9eb106b1f4c 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -8,6 +8,7 @@ menu "Processor type and features"
>
>  config IA64
>         bool
> +       select ARCH_HAS_HWEIGHT
>         select ARCH_MIGHT_HAVE_PC_PARPORT
>         select ARCH_MIGHT_HAVE_PC_SERIO
>         select ACPI if (!IA64_HP_SIM)
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index 1bf6abaea604..91b150b6572c 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -38,10 +38,6 @@ config ARCH_HAS_ILOG2_U32
>  config ARCH_HAS_ILOG2_U64
>         bool
>
> -config GENERIC_HWEIGHT
> -       bool
> -       default y
> -
>  config TIME_LOW_RES
>         bool
>         default y
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index d8907d6f969c..0185ac1f0268 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -71,9 +71,6 @@ config ARCH_HAS_ILOG2_U32
>  config ARCH_HAS_ILOG2_U64
>         def_bool n
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  source "arch/microblaze/Kconfig.platform"
>
>  menu "Processor type and features"
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index bd0c9be7e7cf..04e041cac595 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -1042,10 +1042,6 @@ source "arch/mips/paravirt/Kconfig"
>
>  endmenu
>
> -config GENERIC_HWEIGHT
> -       bool
> -       default y
> -
>  config SCHED_OMIT_FRAME_POINTER
>         bool
>         default y
> diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
> index 7b3a36705aa8..979661f0ab51 100644
> --- a/arch/nds32/Kconfig
> +++ b/arch/nds32/Kconfig
> @@ -50,9 +50,6 @@ config NDS32
>         help
>           Andes(nds32) Linux support.
>
> -config GENERIC_HWEIGHT
> -        def_bool y
> -
>  config GENERIC_LOCKBREAK
>          def_bool y
>         depends on PREEMPT
> diff --git a/arch/nios2/Kconfig b/arch/nios2/Kconfig
> index 11ef63217ebe..a0485f5f0db0 100644
> --- a/arch/nios2/Kconfig
> +++ b/arch/nios2/Kconfig
> @@ -27,9 +27,6 @@ config NIOS2
>         select CPU_NO_EFFICIENT_FFS
>         select ARCH_DISCARD_MEMBLOCK
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config NO_IOPORT_MAP
>         def_bool y
>
> diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
> index 15d7df402c19..dc026973e6f6 100644
> --- a/arch/openrisc/Kconfig
> +++ b/arch/openrisc/Kconfig
> @@ -46,9 +46,6 @@ config CPU_BIG_ENDIAN
>  config MMU
>         def_bool y
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config NO_IOPORT_MAP
>         def_bool y
>
> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
> index 42282b8e086d..7d5ded83c180 100644
> --- a/arch/parisc/Kconfig
> +++ b/arch/parisc/Kconfig
> @@ -86,10 +86,6 @@ config ARCH_HAS_ILOG2_U64
>         bool
>         default n
>
> -config GENERIC_HWEIGHT
> -       bool
> -       default y
> -
>  config TIME_LOW_RES
>         bool
>         depends on SMP
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index a0e9207893c8..8dd4d2b24fdb 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -96,10 +96,6 @@ config GENERIC_LOCKBREAK
>         default y
>         depends on SMP && PREEMPT
>
> -config GENERIC_HWEIGHT
> -       bool
> -       default y
> -
>  config ARCH_HAS_DMA_SET_COHERENT_MASK
>          bool
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 2b173a48bdbc..0acdd7aaaaea 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -69,9 +69,6 @@ config PAGE_OFFSET
>         default 0xffffffff80000000 if 64BIT && MAXPHYSMEM_2GB
>         default 0xffffffe000000000 if 64BIT && MAXPHYSMEM_128GB
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config PGTABLE_LEVELS
>         int
>         default 3 if 64BIT
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 2a5c12be633e..9a25e19364f5 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -14,9 +14,6 @@ config ARCH_HAS_ILOG2_U32
>  config ARCH_HAS_ILOG2_U64
>         def_bool n
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config GENERIC_LOCKBREAK
>         def_bool y if SMP && PREEMPT
>
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index 3d0bd7fbe11a..af6a40af1702 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -94,9 +94,6 @@ config ARCH_DEFCONFIG
>         default "arch/sh/configs/shx3_defconfig" if SUPERH32
>         default "arch/sh/configs/cayman_defconfig" if SUPERH64
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config GENERIC_LOCKBREAK
>         def_bool y
>         depends on SMP && PREEMPT
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index 58270c021b01..78135ac357ed 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -187,10 +187,6 @@ config NR_CPUS
>
>  source "kernel/Kconfig.hz"
>
> -config GENERIC_HWEIGHT
> -       bool
> -       default y
> -
>  config ARCH_MAY_HAVE_PC_FDC
>         bool
>         default y
> diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
> index 9de1d983a99a..e69a8c3232e1 100644
> --- a/arch/unicore32/Kconfig
> +++ b/arch/unicore32/Kconfig
> @@ -38,9 +38,6 @@ config ARCH_HAS_ILOG2_U32
>  config ARCH_HAS_ILOG2_U64
>         bool
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config ARCH_MAY_HAVE_PC_FDC
>         bool
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f4cb31174e1b..7a9347c7448e 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -255,9 +255,6 @@ config GENERIC_ISA_DMA
>         def_bool y
>         depends on ISA_DMA_API
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config ARCH_MAY_HAVE_PC_FDC
>         def_bool y
>         depends on ISA_DMA_API
> diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
> index f5a8cded3ca4..1628a54af003 100644
> --- a/arch/x86/um/Kconfig
> +++ b/arch/x86/um/Kconfig
> @@ -49,6 +49,3 @@ config ARCH_HAS_SC_SIGNALS
>
>  config ARCH_REUSE_HOST_VSYSCALL_AREA
>         def_bool !64BIT
> -
> -config GENERIC_HWEIGHT
> -       def_bool y
> diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
> index d02c25184ca0..ff57afdeda04 100644
> --- a/arch/xtensa/Kconfig
> +++ b/arch/xtensa/Kconfig
> @@ -47,9 +47,6 @@ config XTENSA
>           with reasonable minimum requirements.  The Xtensa Linux project has
>           a home page at <http://www.linux-xtensa.org/>.
>
> -config GENERIC_HWEIGHT
> -       def_bool y
> -
>  config ARCH_HAS_ILOG2_U32
>         def_bool n
>
> diff --git a/lib/Kconfig b/lib/Kconfig
> index bd2e7e74c321..91019f26d0a8 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -35,6 +35,13 @@ config RATIONAL
>  config GENERIC_CSUM
>         bool
>
> +config ARCH_HAS_HWEIGHT
> +       bool
> +
> +config GENERIC_HWEIGHT
> +       default y if !ARCH_HAS_HWEIGHT
> +       bool
> +
>  config GENERIC_STRNCPY_FROM_USER
>         bool
>
> --
> 2.20.1
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



--
Best Regards
Masahiro Yamada

^ permalink raw reply

* Re: [PATCH] powerpc/pseries: export timebase register sample in lparcfg
From: Michael Ellerman @ 2019-02-18  2:33 UTC (permalink / raw)
  To: Tyrel Datwyler; +Cc: brking, linuxppc-dev, puvichakravarthy
In-Reply-To: <f47fe713-9c83-554c-9409-265e10389c5c@linux.vnet.ibm.com>

Tyrel Datwyler <tyreld@linux.vnet.ibm.com> writes:
> Ping? Any objections to this patch? A fix is already upstream in powerpc-utils
> to utilize the timebase value if available.

I'm slightly wary of adding things to lparcfg as it's world-readable and
hard to remove things once they're added (because tools rely on it).

But I guess this is fine.

If we ever want to restrict mftb access then we need to remember to also
lock down this file, or reduce the precision it returns.

cheers

> On 12/08/2018 03:48 PM, Tyrel Datwyler wrote:
>> The Processor Utilzation of Resource Registers (PURR) provide an estimate of
>> resources used by a cpu thread. Section 7.6 in Book III of the ISA outlines
>> how to calculate the percentage of shared resources for threads using the
>> ratio of the PURR delta and Timebase Register delta for a sampled period.
>> 
>> This calculation is currently done erroneously by the lparstat tool from the
>> powerpc-utils package. This patch exports the current timebase value after
>> we sample the PURRs and exposes it to userspace accounting tools via
>> /proc/ppc64/lparcfg.
>> 
>> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
>> ---
>>  arch/powerpc/platforms/pseries/lparcfg.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
>> index 7944873..1ea73ec 100644
>> --- a/arch/powerpc/platforms/pseries/lparcfg.c
>> +++ b/arch/powerpc/platforms/pseries/lparcfg.c
>> @@ -475,6 +475,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
>>  		splpar_dispatch_data(m);
>> 
>>  		seq_printf(m, "purr=%ld\n", get_purr());
>> +        seq_printf(m, "tbr=%ld\n", mftb());
>>  	} else {		/* non SPLPAR case */
>> 
>>  		seq_printf(m, "system_active_processors=%d\n",
>> 

^ permalink raw reply

* [PATCH V2] ASoC: fsl_esai: fix register setting issue in RIGHT_J mode
From: S.j. Wang @ 2019-02-18  2:08 UTC (permalink / raw)
  To: timur@kernel.org, nicoleotsuka@gmail.com, Xiubo.Lee@gmail.com,
	festevam@gmail.com, broonie@kernel.org,
	alsa-devel@alsa-project.org
  Cc: linuxppc-dev@lists.ozlabs.org, stable@vger.kernel.org

Fixes commit 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")

The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to
wrong register, correct it.

Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Ackedy-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
Changes in v2
- add Fixes tag and cc stable kernel.

 sound/soc/fsl/fsl_esai.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 57b484768a58..afe67c865330 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -398,7 +398,8 @@ static int fsl_esai_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
 		break;
 	case SND_SOC_DAIFMT_RIGHT_J:
 		/* Data on rising edge of bclk, frame high, right aligned */
-		xccr |= ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP | ESAI_xCR_xWA;
+		xccr |= ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP;
+		xcr  |= ESAI_xCR_xWA;
 		break;
 	case SND_SOC_DAIFMT_DSP_A:
 		/* Data on rising edge of bclk, frame high, 1clk before data */
@@ -455,12 +456,12 @@ static int fsl_esai_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
 		return -EINVAL;
 	}
 
-	mask = ESAI_xCR_xFSL | ESAI_xCR_xFSR;
+	mask = ESAI_xCR_xFSL | ESAI_xCR_xFSR | ESAI_xCR_xWA;
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, mask, xcr);
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR, mask, xcr);
 
 	mask = ESAI_xCCR_xCKP | ESAI_xCCR_xHCKP | ESAI_xCCR_xFSP |
-		ESAI_xCCR_xFSD | ESAI_xCCR_xCKD | ESAI_xCR_xWA;
+		ESAI_xCCR_xFSD | ESAI_xCCR_xCKD;
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR, mask, xccr);
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR, mask, xccr);
 
-- 
1.9.1


^ permalink raw reply related

* Re: [PATCH] powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()
From: Michael Ellerman @ 2019-02-18  0:49 UTC (permalink / raw)
  To: Balbir Singh
  Cc: erhard_f, jack, linuxppc-dev, linux-kernel, linux-mm,
	aneesh.kumar
In-Reply-To: <20190217215556.GH31125@350D>

Balbir Singh <bsingharora@gmail.com> writes:
> On Sun, Feb 17, 2019 at 07:34:20PM +1100, Michael Ellerman wrote:
>> Balbir Singh <bsingharora@gmail.com> writes:
>> > On Sat, Feb 16, 2019 at 08:22:12AM -0600, Segher Boessenkool wrote:
>> >> On Sat, Feb 16, 2019 at 09:55:11PM +1100, Balbir Singh wrote:
>> >> > On Thu, Feb 14, 2019 at 05:23:39PM +1100, Michael Ellerman wrote:
>> >> > > In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT
>> >> > > rather than just checking that the value is non-zero, e.g.:
>> >> > > 
>> >> > >   static inline int pgd_present(pgd_t pgd)
>> >> > >   {
>> >> > >  -       return !pgd_none(pgd);
>> >> > >  +       return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
>> >> > >   }
>> >> > > 
>> >> > > Unfortunately this is broken on big endian, as the result of the
>> >> > > bitwise && is truncated to int, which is always zero because
>> >> 
>> >> (Bitwise "&" of course).
>> >> 
>> >> > Not sure why that should happen, why is the result an int? What
>> >> > causes the casting of pgd_t & be64 to be truncated to an int.
>> >> 
>> >> Yes, it's not obvious as written...  It's simply that the return type of
>> >> pgd_present is int.  So it is truncated _after_ the bitwise and.
>> >>
>> >
>> > Thanks, I am surprised the compiler does not complain about the truncation
>> > of bits. I wonder if we are missing -Wconversion
>> 
>> Good luck with that :)
>> 
>> What I should start doing is building with it enabled and then comparing
>> the output before and after commits to make sure we're not introducing
>> new cases.
>
> Fair enough, my point was that the compiler can help out. I'll see what
> -Wconversion finds on my local build :)

I get about 43MB of warnings here :)

cheers

^ permalink raw reply

* Re: [PATCH v2 6/7] powerpc/eeh: Allow disabling recovery
From: Oliver @ 2019-02-17 23:19 UTC (permalink / raw)
  To: Sam Bobroff; +Cc: linuxppc-dev
In-Reply-To: <20190215055805.GF8338@tungsten.ozlabs.ibm.com>

On Fri, Feb 15, 2019 at 4:58 PM Sam Bobroff <sbobroff@linux.ibm.com> wrote:
>
> On Fri, Feb 15, 2019 at 11:48:16AM +1100, Oliver O'Halloran wrote:
> > Currently when we detect an error we automatically invoke the EEH recovery
> > handler. This can be annoying when debugging EEH problems, or when working
> > on EEH itself so this patch adds a debugfs knob that will prevent a
> > recovery event from being queued up when an issue is detected.
> >
> > Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> > ---
> >  arch/powerpc/include/asm/eeh.h  |  1 +
> >  arch/powerpc/kernel/eeh.c       | 10 ++++++++++
> >  arch/powerpc/kernel/eeh_event.c |  9 +++++++++
> >  3 files changed, 20 insertions(+)
> >
> > diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
> > index 478f199d5663..810e05273ad3 100644
> > --- a/arch/powerpc/include/asm/eeh.h
> > +++ b/arch/powerpc/include/asm/eeh.h
> > @@ -220,6 +220,7 @@ struct eeh_ops {
> >
> >  extern int eeh_subsystem_flags;
> >  extern u32 eeh_max_freezes;
> > +extern bool eeh_debugfs_no_recover;
> >  extern struct eeh_ops *eeh_ops;
> >  extern raw_spinlock_t confirm_error_lock;
> >
> > diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
> > index 82d22c671c0e..9f20099ce2d9 100644
> > --- a/arch/powerpc/kernel/eeh.c
> > +++ b/arch/powerpc/kernel/eeh.c
> > @@ -111,6 +111,13 @@ EXPORT_SYMBOL(eeh_subsystem_flags);
> >   */
> >  u32 eeh_max_freezes = 5;
> >
> > +/*
> > + * Controls whether a recovery event should be scheduled when an
> > + * isolated device is discovered. This is only really useful for
> > + * debugging problems with the EEH core.
> > + */
> > +bool eeh_debugfs_no_recover;
> > +
> >  /* Platform dependent EEH operations */
> >  struct eeh_ops *eeh_ops = NULL;
> >
> > @@ -1810,6 +1817,9 @@ static int __init eeh_init_proc(void)
> >                                          &eeh_enable_dbgfs_ops);
> >               debugfs_create_u32("eeh_max_freezes", 0600,
> >                               powerpc_debugfs_root, &eeh_max_freezes);
> > +             debugfs_create_bool("eeh_disable_recovery", 0600,
> > +                             powerpc_debugfs_root,
> > +                             &eeh_debugfs_no_recover);
> >               eeh_cache_debugfs_init();
> >  #endif
> >       }
> > diff --git a/arch/powerpc/kernel/eeh_event.c b/arch/powerpc/kernel/eeh_event.c
> > index 227e57f980df..19837798bb1d 100644
> > --- a/arch/powerpc/kernel/eeh_event.c
> > +++ b/arch/powerpc/kernel/eeh_event.c
> > @@ -126,6 +126,15 @@ int eeh_send_failure_event(struct eeh_pe *pe)
> >       unsigned long flags;
> >       struct eeh_event *event;
> >
> > +     /*
> > +      * If we've manually supressed recovery events via debugfs
> > +      * then just drop it on the floor.
> > +      */
> > +     if (eeh_debugfs_no_recover) {
> > +             pr_err("EEH: Event dropped due to no_recover setting\n");
> > +             return 0;
> > +     }
> > +
>
> I think it might be clearer if you did the 'no recovery' test at the
> call sites (I think there are only a few), instead of inside the
> function (and then the next patch wouldn't need to add a wrapper).

I don't think adding boilerplate at all the call sites is an
improvement. It's just a recipe for adding bugs.

>
> >       event = kzalloc(sizeof(*event), GFP_ATOMIC);
> >       if (!event) {
> >               pr_err("EEH: out of memory, event not handled\n");
> > --
> > 2.20.1
> >

^ permalink raw reply

* Re: [PATCH v6] powerpc/64s: reimplement book3s idle code in C
From: Paul Mackerras @ 2019-02-17 23:06 UTC (permalink / raw)
  To: Nicholas Piggin
  Cc: Gautham R . Shenoy, Mahesh Jagannath Salgaonkar, kvm-ppc,
	Aneesh Kumar K.V, linuxppc-dev, Akshay Adiga
In-Reply-To: <20181013120409.1993-1-npiggin@gmail.com>

On Sat, Oct 13, 2018 at 10:04:09PM +1000, Nicholas Piggin wrote:
> Reimplement Book3S idle code in C, moving POWER7/8/9 implementation
> speific HV idle code to the powernv platform code.
> 

[...]

> @@ -2760,21 +2744,47 @@ BEGIN_FTR_SECTION
>  	li	r4, LPCR_PECE_HVEE@higher
>  	sldi	r4, r4, 32
>  	or	r5, r5, r4
> -END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
> +FTR_SECTION_ELSE
> +	li	r3, PNV_THREAD_NAP
> +ALT_FTR_SECTION_END_IFSET(CPU_FTR_ARCH_300)
>  	mtspr	SPRN_LPCR,r5
>  	isync
> -	li	r0, 0
> -	std	r0, HSTATE_SCRATCH0(r13)
> -	ptesync
> -	ld	r0, HSTATE_SCRATCH0(r13)
> -1:	cmpd	r0, r0
> -	bne	1b
> +
> +	mr	r0, r1
> +	ld	r1, PACAEMERGSP(r13)
> +	subi	r1, r1, STACK_FRAME_OVERHEAD
> +	std	r0, 0(r1)
> +	ld	r0, PACAR1(r13)
> +	std	r0, 8(r1)

This bit seems wrong to me.  If this is a secondary thread on POWER8,
we were already on the emergency stack, and now we've reset r1 back to
the top of the emergency stack and we're overwriting it.

I wonder why you didn't see secondary threads going off into lala land
in your tests?

Paul.

^ permalink raw reply

* Re: [PATCH] powerpc/pseries: export timebase register sample in lparcfg
From: Tyrel Datwyler @ 2019-02-17 22:25 UTC (permalink / raw)
  To: mpe; +Cc: brking, linuxppc-dev, puvichakravarthy
In-Reply-To: <1544312907-17555-1-git-send-email-tyreld@linux.vnet.ibm.com>

Ping? Any objections to this patch? A fix is already upstream in powerpc-utils
to utilize the timebase value if available.

-Tyrel

On 12/08/2018 03:48 PM, Tyrel Datwyler wrote:
> The Processor Utilzation of Resource Registers (PURR) provide an estimate of
> resources used by a cpu thread. Section 7.6 in Book III of the ISA outlines
> how to calculate the percentage of shared resources for threads using the
> ratio of the PURR delta and Timebase Register delta for a sampled period.
> 
> This calculation is currently done erroneously by the lparstat tool from the
> powerpc-utils package. This patch exports the current timebase value after
> we sample the PURRs and exposes it to userspace accounting tools via
> /proc/ppc64/lparcfg.
> 
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> ---
>  arch/powerpc/platforms/pseries/lparcfg.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
> index 7944873..1ea73ec 100644
> --- a/arch/powerpc/platforms/pseries/lparcfg.c
> +++ b/arch/powerpc/platforms/pseries/lparcfg.c
> @@ -475,6 +475,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
>  		splpar_dispatch_data(m);
> 
>  		seq_printf(m, "purr=%ld\n", get_purr());
> +        seq_printf(m, "tbr=%ld\n", mftb());
>  	} else {		/* non SPLPAR case */
> 
>  		seq_printf(m, "system_active_processors=%d\n",
> 


^ permalink raw reply

* Re: [PATCH] powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()
From: Balbir Singh @ 2019-02-17 21:55 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: erhard_f, jack, linuxppc-dev, linux-kernel, linux-mm,
	aneesh.kumar
In-Reply-To: <87ef86dd9v.fsf@concordia.ellerman.id.au>

On Sun, Feb 17, 2019 at 07:34:20PM +1100, Michael Ellerman wrote:
> Balbir Singh <bsingharora@gmail.com> writes:
> > On Sat, Feb 16, 2019 at 08:22:12AM -0600, Segher Boessenkool wrote:
> >> Hi all,
> >> 
> >> On Sat, Feb 16, 2019 at 09:55:11PM +1100, Balbir Singh wrote:
> >> > On Thu, Feb 14, 2019 at 05:23:39PM +1100, Michael Ellerman wrote:
> >> > > In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT
> >> > > rather than just checking that the value is non-zero, e.g.:
> >> > > 
> >> > >   static inline int pgd_present(pgd_t pgd)
> >> > >   {
> >> > >  -       return !pgd_none(pgd);
> >> > >  +       return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
> >> > >   }
> >> > > 
> >> > > Unfortunately this is broken on big endian, as the result of the
> >> > > bitwise && is truncated to int, which is always zero because
> >> 
> >> (Bitwise "&" of course).
> >> 
> >> > Not sure why that should happen, why is the result an int? What
> >> > causes the casting of pgd_t & be64 to be truncated to an int.
> >> 
> >> Yes, it's not obvious as written...  It's simply that the return type of
> >> pgd_present is int.  So it is truncated _after_ the bitwise and.
> >>
> >
> > Thanks, I am surprised the compiler does not complain about the truncation
> > of bits. I wonder if we are missing -Wconversion
> 
> Good luck with that :)
> 
> What I should start doing is building with it enabled and then comparing
> the output before and after commits to make sure we're not introducing
> new cases.
>

Fair enough, my point was that the compiler can help out. I'll see what
-Wconversion finds on my local build :)

Balbir Singh. 

^ permalink raw reply

* Re: [PATCH] cpufreq: powernv: fix missing check of return value in init_powernv_pstates()
From: Akshay Adiga @ 2019-02-17 19:11 UTC (permalink / raw)
  To: Yangtao Li
  Cc: linux-pm, viresh.kumar, rjw, linux-kernel, paulus, linuxppc-dev
In-Reply-To: <20190216170623.12634-1-tiny.windzz@gmail.com>

On Sat, Feb 16, 2019 at 12:06:23PM -0500, Yangtao Li wrote:
> kmalloc() could fail, so insert a check of its return value. And
> if it fails, returns -ENOMEM.
> 
> And remove (struct pstate_idx_revmap_data *) to fix coccinelle WARNING
> by the way.
> 
> WARNING: casting value returned by memory allocation function to (struct
> pstate_idx_revmap_data *) is useless.
> 
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
>  drivers/cpufreq/powernv-cpufreq.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
Looks good to me. Thanks for fixing this.


^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox