[PATCH V4 1/2] powerpc/numa: Update CPU topology when VPHN enabled

[Michael Bringmann]

powerpc/numa: Correct the currently broken capability to set the
topology for shared CPUs in LPARs.  At boot time for shared CPU
lpars, the topology for each shared CPU is set to node zero, however,
this is now updated correctly using the Virtual Processor Home Node
(VPHN) capabilities information provided by the pHyp. The VPHN handling
in Linux is disabled, if PRRN handling is present.

Signed-off-by: Michael Bringmann 
---
Changes in V4:
 -- Fix conditional compile bug.
---
 arch/powerpc/mm/numa.c |   19 ++-
 arch/powerpc/platforms/pseries/dlpar.c |2 ++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 371792e..afcee3f 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1153,6 +1154,8 @@ struct topology_update_data {
 static int vphn_enabled;
 static int prrn_enabled;
 static void reset_topology_timer(void);
+static int topology_inited;
+static int topology_update_needed;
 
 /*
  * Store the current values of the associativity change counters in the
@@ -1321,8 +1324,11 @@ int arch_update_cpu_topology(void)
struct device *dev;
int weight, new_nid, i = 0;
 
-   if (!prrn_enabled && !vphn_enabled)
+   if (!prrn_enabled && !vphn_enabled) {
+   if (!topology_inited)
+   topology_update_needed = 1;
return 0;
+   }
 
weight = cpumask_weight(_associativity_changes_mask);
if (!weight)
@@ -1361,6 +1367,8 @@ int arch_update_cpu_topology(void)
cpumask_andnot(_associativity_changes_mask,
_associativity_changes_mask,
cpu_sibling_mask(cpu));
+   pr_info("Assoc chg gives same node %d for cpu%d\n",
+   new_nid, cpu);
cpu = cpu_last_thread_sibling(cpu);
continue;
}
@@ -1377,6 +1385,9 @@ int arch_update_cpu_topology(void)
cpu = cpu_last_thread_sibling(cpu);
}
 
+   if (i)
+   updates[i-1].next = NULL;
+
pr_debug("Topology update for the following CPUs:\n");
if (cpumask_weight(_cpus)) {
for (ud = [0]; ud; ud = ud->next) {
@@ -1423,6 +1434,7 @@ int arch_update_cpu_topology(void)
 
 out:
kfree(updates);
+   topology_update_needed = 0;
return changed;
 }
 
@@ -1600,6 +1612,11 @@ static int topology_update_init(void)
if (!proc_create("powerpc/topology_updates", 0644, NULL, _ops))
return -ENOMEM;
 
+   topology_inited = 1;
+   if (topology_update_needed)
+   bitmap_fill(cpumask_bits(_associativity_changes_mask),
+   nr_cpumask_bits);
+
return 0;
 }
 device_initcall(topology_update_init);
diff --git a/arch/powerpc/platforms/pseries/dlpar.c 
b/arch/powerpc/platforms/pseries/dlpar.c
index bda18d8..5106263 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -592,6 +592,8 @@ static ssize_t dlpar_show(struct class *class, struct 
class_attribute *attr,
 
 static int __init pseries_dlpar_init(void)
 {
+   arch_update_cpu_topology();
+
pseries_hp_wq = alloc_workqueue("pseries hotplug workqueue",
WQ_UNBOUND, 1);
return sysfs_create_file(kernel_kobj, _attr_dlpar.attr);

[PATCH V4 2/2] powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Bringmann]

Removing or adding memory via the PowerPC hotplug interface currently
dumps newly added processors or memory into default node 0, instead of
into the node that would be calculated based upon the VPHN affinity
tables.  The code was updated to ensure that all nodes found at boot
are still available to subsequent DLPAR hotplug-memory operations,
even if they are not needed at boot time.

Signed-off-by: Michael Bringmann 
---
---
 arch/powerpc/mm/numa.c |7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index afcee3f..49d5222 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -905,13 +905,6 @@ void __init initmem_init(void)
 
memblock_dump_all();
 
-   /*
-* Reduce the possible NUMA nodes to the online NUMA nodes,
-* since we do not support node hotplug. This ensures that  we
-* lower the maximum NUMA node ID to what is actually present.
-*/
-   nodes_and(node_possible_map, node_possible_map, node_online_map);
-
for_each_online_node(nid) {
unsigned long start_pfn, end_pfn;
 

Re: [PATCH v2 1/3] EDAC: mv64x60: remove unused variable

[Borislav Petkov]

On Thu, May 18, 2017 at 08:31:33PM +1200, Chris Packham wrote:
> Signed-off-by: Chris Packham 
> ---
>  drivers/edac/mv64x60_edac.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
> index 14b7e7b71eaa..454e1e26ee7c 100644
> --- a/drivers/edac/mv64x60_edac.c
> +++ b/drivers/edac/mv64x60_edac.c
> @@ -853,8 +853,6 @@ static struct platform_driver * const drivers[] = {
>  
>  static int __init mv64x60_edac_init(void)
>  {
> - int ret = 0;
> -
>   printk(KERN_INFO "Marvell MV64x60 EDAC driver " MV64x60_REVISION "\n");
>   printk(KERN_INFO "\t(C) 2006-2007 MontaVista Software\n");
>   /* make sure error reporting method is sane */
> -- 

Looks like the logic behind that ret variable is to catch the retval of
platform_register_drivers() and test it to return early. And then issue
the printks and assign edac_op_state only in the success case.

Please do that instead.

Thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH V2 1/2] powerpc/numa: Update CPU topology when VPHN enabled

[kbuild test robot]

Hi Michael,

[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.12-rc2 next-20170526]
[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/Michael-Bringmann/powerpc-numa-Update-CPU-topology-when-VPHN-enabled/20170526-231219
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-powernv_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

>> arch/powerpc/mm/numa.c:47:12: error: 'topology_update_needed' defined but 
>> not used [-Werror=unused-variable]
static int topology_update_needed;
   ^~
>> arch/powerpc/mm/numa.c:46:12: error: 'topology_inited' defined but not used 
>> [-Werror=unused-variable]
static int topology_inited;
   ^~~
   cc1: all warnings being treated as errors

vim +/topology_update_needed +47 arch/powerpc/mm/numa.c

40  #include 
41  #include 
42  #include 
43  #include 
44  
45  static int numa_enabled = 1;
  > 46  static int topology_inited;
  > 47  static int topology_update_needed;
48  
49  static char *cmdline __initdata;
50  

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


.config.gz
Description: application/gzip

Re: [v3 0/9] parallelized "struct page" zeroing

[Pasha Tatashin]

Hi Michal,

I have considered your proposals:

1. Making memset(0) unconditional inside __init_single_page() is not 
going to work because it slows down SPARC, and ppc64. On SPARC even the 
BSTI optimization that I have proposed earlier won't work, because after 
consulting with other engineers I was told that stores (without loads!) 
after BSTI without membar are unsafe


2. Adding ARCH_WANT_LARGE_PAGEBLOCK_INIT is not going to solve the 
problem, because while arch might want a large memset(), it still wants 
to get the benefit of parallelized struct page initialization.


3. Another approach that have I considered is moving memset() above 
__init_single_page() and do it in a larger chunks. However, this 
solution is also not going to work, because inside the loops, there are 
cases where "struct page"s are skipped, so every single page is checked:

early_pfn_valid(pfn), early_pfn_in_nid(), and also mirroed_kernelcore cases.


I wouldn't be so sure about this. If any other platform has a similar
issues with small memset as sparc then the overhead is just papered over
by parallel initialization.


That is true, and that is fine, because parallelization gives an order 
of magnitude better improvements compared to trade of slower single 
thread performance. Remember, this will happen during boot and memory 
hotplug only, and not something that will eat up computing resources 
during runtime.


So, at the moment I cannot really find a better solution compared to 
what I have proposed: do memset() inside __init_single_page() only when 
deferred initialization is enabled.


Pasha

RE: [PATCH 3/3] powerpc/8xx: xmon compile fix

[David Laight]

From:  Michael Ellerman
> Sent: 26 May 2017 08:24
> Nicholas Piggin  writes:
> > diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> > index f11f65634aab..438fdb0fb142 100644
> > --- a/arch/powerpc/xmon/xmon.c
> > +++ b/arch/powerpc/xmon/xmon.c
> > @@ -1242,14 +1242,16 @@ bpt_cmds(void)
> >  {
> > int cmd;
> > unsigned long a;
> > -   int mode, i;
> > +   int i;
> > struct bpt *bp;
> > -   const char badaddr[] = "Only kernel addresses are permitted "
> > -   "for breakpoints\n";
> >
> > cmd = inchar();
> > switch (cmd) {
> > -#ifndef CONFIG_8xx
> > +#ifndef CONFIG_PPC_8xx
> > +   int mode;
> > +   const char badaddr[] = "Only kernel addresses are permitted "
> > +   "for breakpoints\n";
> > +
> > case 'd':   /* bd - hardware data breakpoint */
> > mode = 7;
> > cmd = inchar();
> 
> GCC 7 rejects this:
> 
>   arch/powerpc/xmon/xmon.c: In function bpt_cmds:
>   arch/powerpc/xmon/xmon.c:1252:13: error: statement will never be executed 
> [-Werror=switch-
> unreachable]
> const char badaddr[] = "Only kernel addresses are permitted for 
> breakpoints\n";
>^~~

Try 'static' ?

David

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Reza Arbab]

On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote:

Reza Arbab  writes:


On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:

The commit message for 3af229f2071f says:

   In practice, we never see a system with 256 NUMA nodes, and in fact, we
   do not support node hotplug on power in the first place, so the nodes
   ^^^
   that are online when we come up are the nodes that will be present for
   the lifetime of this kernel.

Is that no longer true?


I don't know what the reasoning behind that statement was at the time,
but as far as I can tell, the only thing missing for node hotplug now is
Balbir's patchset [1]. He fixes the resource issue which motivated
3af229f2071f and reverts it.

With that set, I can instantiate a new numa node just by doing
add_memory(nid, ...) where nid doesn't currently exist.


But does that actually happen on any real system?


I don't know if anything currently tries to do this. My interest in 
having this working is so that in the future, our coherent gpu memory 
could be added as a distinct node by the device driver.


--
Reza Arbab

[PATCH V3 2/2] powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Bringmann]

Removing or adding memory via the PowerPC hotplug interface currently
dumps newly added processors or memory into default node 0, instead of
into the node that would be calculated based upon the VPHN affinity
tables.  The code was updated to ensure that all nodes found at boot
are still available to subsequent DLPAR hotplug-memory operations,
even if they are not needed at boot time.

Signed-off-by: Michael Bringmann 
---
Changes in V3:
  -- Remove code not relevant to this defect.
---
 arch/powerpc/mm/numa.c |7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 15c2dd5..18f3038 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -907,13 +907,6 @@ void __init initmem_init(void)
 
memblock_dump_all();
 
-   /*
-* Reduce the possible NUMA nodes to the online NUMA nodes,
-* since we do not support node hotplug. This ensures that  we
-* lower the maximum NUMA node ID to what is actually present.
-*/
-   nodes_and(node_possible_map, node_possible_map, node_online_map);
-
for_each_online_node(nid) {
unsigned long start_pfn, end_pfn;
 

[PATCH V3 1/2] powerpc/numa: Update CPU topology when VPHN enabled

[Michael Bringmann]

powerpc/numa: Correct the currently broken capability to set the
topology for shared CPUs in LPARs.  At boot time for shared CPU
lpars, the topology for each shared CPU is set to node zero, however,
this is now updated correctly using the Virtual Processor Home Node
(VPHN) capabilities information provided by the pHyp. The VPHN handling
in Linux is disabled, if PRRN handling is present.

Signed-off-by: Michael Bringmann 
---
Changes in V3:
 -- Remove change unrelated to this patch
---
 arch/powerpc/mm/numa.c |   19 ++-
 arch/powerpc/platforms/pseries/dlpar.c |2 ++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 371792e..15c2dd5 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -42,6 +43,8 @@
 #include 
 
 static int numa_enabled = 1;
+static int topology_inited;
+static int topology_update_needed;
 
 static char *cmdline __initdata;
 
@@ -1321,8 +1324,11 @@ int arch_update_cpu_topology(void)
struct device *dev;
int weight, new_nid, i = 0;
 
-   if (!prrn_enabled && !vphn_enabled)
+   if (!prrn_enabled && !vphn_enabled) {
+   if (!topology_inited)
+   topology_update_needed = 1;
return 0;
+   }
 
weight = cpumask_weight(_associativity_changes_mask);
if (!weight)
@@ -1361,6 +1367,8 @@ int arch_update_cpu_topology(void)
cpumask_andnot(_associativity_changes_mask,
_associativity_changes_mask,
cpu_sibling_mask(cpu));
+   pr_info("Assoc chg gives same node %d for cpu%d\n",
+   new_nid, cpu);
cpu = cpu_last_thread_sibling(cpu);
continue;
}
@@ -1377,6 +1385,9 @@ int arch_update_cpu_topology(void)
cpu = cpu_last_thread_sibling(cpu);
}
 
+   if (i)
+   updates[i-1].next = NULL;
+
pr_debug("Topology update for the following CPUs:\n");
if (cpumask_weight(_cpus)) {
for (ud = [0]; ud; ud = ud->next) {
@@ -1423,6 +1434,7 @@ int arch_update_cpu_topology(void)
 
 out:
kfree(updates);
+   topology_update_needed = 0;
return changed;
 }
 
@@ -1600,6 +1612,11 @@ static int topology_update_init(void)
if (!proc_create("powerpc/topology_updates", 0644, NULL, _ops))
return -ENOMEM;
 
+   topology_inited = 1;
+   if (topology_update_needed)
+   bitmap_fill(cpumask_bits(_associativity_changes_mask),
+   nr_cpumask_bits);
+
return 0;
 }
 device_initcall(topology_update_init);
diff --git a/arch/powerpc/platforms/pseries/dlpar.c 
b/arch/powerpc/platforms/pseries/dlpar.c
index bda18d8..5106263 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -592,6 +592,8 @@ static ssize_t dlpar_show(struct class *class, struct 
class_attribute *attr,
 
 static int __init pseries_dlpar_init(void)
 {
+   arch_update_cpu_topology();
+
pseries_hp_wq = alloc_workqueue("pseries hotplug workqueue",
WQ_UNBOUND, 1);
return sysfs_create_file(kernel_kobj, _attr_dlpar.attr);

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Bringmann]

I am running into this problem on PowerPC systems where Balbir's patch set
was targeted.  So, yes, I do need to be able to add/enable a new numa node
during system execution in cases where more resources (memory, virtual
processors) are added to the system dynamically.

On 05/25/2017 10:46 PM, Michael Ellerman wrote:
> Reza Arbab  writes:
> 
>> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
>>> The commit message for 3af229f2071f says:
>>>
>>>In practice, we never see a system with 256 NUMA nodes, and in fact, we
>>>do not support node hotplug on power in the first place, so the nodes
>>>^^^
>>>that are online when we come up are the nodes that will be present for
>>>the lifetime of this kernel.
>>>
>>> Is that no longer true?
>>
>> I don't know what the reasoning behind that statement was at the time, 
>> but as far as I can tell, the only thing missing for node hotplug now is 
>> Balbir's patchset [1]. He fixes the resource issue which motivated 
>> 3af229f2071f and reverts it.
>>
>> With that set, I can instantiate a new numa node just by doing 
>> add_memory(nid, ...) where nid doesn't currently exist.
> 
> But does that actually happen on any real system?
> 
> cheers
> 
> 

-- 
Michael W. Bringmann
Linux Technology Center
IBM Corporation
Tie-Line  363-5196
External: (512) 286-5196
Cell:   (512) 466-0650
m...@linux.vnet.ibm.com

Re: [PATCH V2 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Bringmann]

>>  arch/powerpc/mm/numa.c |7 ---
>>  1 file changed, 7 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index 15c2dd5..18f3038 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -907,13 +907,6 @@ void __init initmem_init(void)
>>  
>>  memblock_dump_all();
>>  
>> -/*
>> - * Reduce the possible NUMA nodes to the online NUMA nodes,
>> - * since we do not support node hotplug. This ensures that  we
>> - * lower the maximum NUMA node ID to what is actually present.
>> - */
>> -nodes_and(node_possible_map, node_possible_map, node_online_map);
>> -
> 
> There is an overhead with turning this off if you have too many cgroups
> with the memory controller. I think this fix was added for a pathological
> test case. On my system I see 84 cgroups with 1 node, so the probable
> overhead is 84*255*sizeof(struct mem_cgroup_tree_per_node).
> 
> I tried some patches to reduce the overhead, but those need more overhauling
> and rework.

Is there some other way to add a node to a dynamic, running system without
crashing?  I have not encountered one as yet.

> Balbir Singh.

-- 
Michael W. Bringmann
Linux Technology Center
IBM Corporation
Tie-Line  363-5196
External: (512) 286-5196
Cell:   (512) 466-0650
m...@linux.vnet.ibm.com

Re: [PATCH] powerpc/perf: Fix Power9 test_adder field

[shriyak]

On 2017-05-26 13:38, Madhavan Srinivasan wrote:
Commit 8d911904f3ce4 ('powerpc/perf: Add restrictions to PMC5 in power9 
DD1')
was added to restrict the use of PMC5 in Power9 DD1. Intend is to 
diable

the use of PMC5 using raw event code. Commit instead of updating
"power9_isa207_pmu"
structure, updated "power9_pmu" structure. Patch to fix the same.

Fixes: 8d911904f3ce4 ('powerpc/perf: Add restrictions to PMC5 in power9 
DD1')

Reported-by: Shriya 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power9-pmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/perf/power9-pmu.c 
b/arch/powerpc/perf/power9-pmu.c

index 018f8e90ac35..bb28e1a41257 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -402,7 +402,7 @@ static struct power_pmu power9_isa207_pmu = {
.name   = "POWER9",
.n_counter  = MAX_PMU_COUNTERS,
.add_fields = ISA207_ADD_FIELDS,
-   .test_adder = ISA207_TEST_ADDER,
+   .test_adder = P9_DD1_TEST_ADDER,
.compute_mmcr   = isa207_compute_mmcr,
.config_bhrb= power9_config_bhrb,
.bhrb_filter_map= power9_bhrb_filter_map,
@@ -421,7 +421,7 @@ static struct power_pmu power9_pmu = {
.name   = "POWER9",
.n_counter  = MAX_PMU_COUNTERS,
.add_fields = ISA207_ADD_FIELDS,
-   .test_adder = P9_DD1_TEST_ADDER,
+   .test_adder = ISA207_TEST_ADDER,
.compute_mmcr   = isa207_compute_mmcr,
.config_bhrb= power9_config_bhrb,
.bhrb_filter_map= power9_bhrb_filter_map,


Tested-by: Shriya 

Re: [PATCH 4/4] arch/powerpc/44x/fsp2: wdt tcr update instead of whole rewrite

[Michael Ellerman]

Michael Ellerman  writes:

> Ivan Mikhaylov  writes:
>>
>> From my point of view it's possible. I've checked docu and on idea
>> it should be possible cause WP is only affecting watchdog ping time.
>
> The question is, is there any chance that leaving those bits set on
> another platform will cause a problem?
>
> ie. on existing machines we always clear those bits, is it OK that we
> will now start leaving those bits with whatever value they had.

I came up with the patch below (more or less your v2), if it breaks
something we can always fix it.

cheers

commit c80409358a9c91e1f6b18353dad939b851bb3522
Author: Ivan Mikhaylov 
Date:   Fri May 19 18:47:05 2017 +0300

powerpc/[booke|4xx]: Don't clobber TCR[WP] when setting TCR[DIE]

Prevent a kernel panic caused by unintentionally clearing TCR watchdog
bits. At this point in the kernel boot, the watchdog may have already
been enabled by u-boot. The original code's attempt to write to the TCR
register results in an inadvertent clearing of the watchdog
configuration bits, causing the 476 to reset.

Signed-off-by: Ivan Mikhaylov 
Signed-off-by: Michael Ellerman 

diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 2b33cfaac7b8..60714b8c9a2f 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -739,12 +739,20 @@ static int __init get_freq(char *name, int cells, 
unsigned long *val)
 static void start_cpu_decrementer(void)
 {
 #if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+   unsigned int tcr;
+
/* Clear any pending timer interrupts */
mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS);
 
-   /* Enable decrementer interrupt */
-   mtspr(SPRN_TCR, TCR_DIE);
-#endif /* defined(CONFIG_BOOKE) || defined(CONFIG_40x) */
+   tcr = mfspr(SPRN_TCR);
+   /*
+* The watchdog may have already been enabled by u-boot. So leave
+* TRC[WP] (Watchdog Period) alone.
+*/
+   tcr &= TCR_WP_MASK; /* Clear all bits except for TCR[WP] */
+   tcr |= TCR_DIE; /* Enable decrementer */
+   mtspr(SPRN_TCR, tcr);
+#endif
 }
 
 void __init generic_calibrate_decr(void)

Re: [PATCH] powerpc: use uapi/asm-generic/sockios.h

[Stephen Rothwell]

Hi Arnd,

On Fri, 26 May 2017 11:59:23 +0200 Arnd Bergmann  wrote:
>
> On Fri, May 26, 2017 at 10:32 AM, Stephen Rothwell  
> wrote:
> > Hi all,
> >
> > The arch version is identical except for comments and white space.
> >
> > Signed-off-by: Stephen Rothwell   
> 
> Acked-by: Arnd Bergmann 

Thanks.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] powerpc: use the asm-genric versions of some uapi includes

[Stephen Rothwell]

Hi Arnd,

On Fri, 26 May 2017 11:58:26 +0200 Arnd Bergmann  wrote:
>
> I think I had a patch series to do those some 10 years ago and never
> submitted it ;-)

Ah ha! :-)

> Acked-by: Arnd Bergmann 
> 
> asm/sockios.h is identical to the asm-generic version, so we can do
> the same there.

Yes, I see you found the next patch :-)

> asm/swab.h is functionally identical, the asm-generic version
> also has a workaround for non-gcc compilers.

I'll have a look.

> asm/socket.h would also be easy to change so we mostly use
> asm-generic, the generic version already has a special case
> for powerpc.

Yes, that is what I was aiming at, but I will submit that to the
networking tree as they have a patch to that powerpc file already which
is why I noticed at all.

-- 
Cheers,
Stephen Rothwell

libspe2:test_context_create_error on 4.12-rc1 and 4.2-rc2

[Sombat Tragolgosol]

Dear Sir,

I do run test libspe2. For For 4.4.69, 4.10.17 and 4.11.3, they all seem
PASS even having error almost the same, but for 4.12-rc1 and 4.12-rc2 , it
is hanged up on  test_context_create_error.

please see my two files attached for 4.11.3 and 4.12-rc2.


4.11.3
[  240.975893] WARNING: CPU: 0 PID: 3543 at fs/dcache.c:304
.dentry_free+0x18/0xc8

4.12-rc2
[ 1191.234695] kernel BUG at fs/dcache.c:304!
[ 1191.234705] Oops: Exception in kernel mode, sig: 5 [#1]

Best regards,
Sombat t.
[  240.973779] list_del corruption. prev->next should be ca7658d0, but 
was ca48b460
[  240.974548] [ cut here ]
[  240.974570] WARNING: CPU: 0 PID: 3543 at lib/list_debug.c:53 
.__list_del_entry_valid+0xdc/0x108
[  240.974579] Modules linked in: ps3nflash ps3flash cfg80211 bnep spufs 
input_leds evdev led_class usbhid btusb btrtl btbcm btintel bluetooth 
ps3_jupiter_sta ps3_jupiter ohci_hcd snd_ps3 snd_pcm snd_timer ehci_hcd ps3fb 
snd usbcore soundcore syscopyarea ps3_disp_manager ps3_lpm sysfillrect 
usb_common sysimgblt ps3rom ps3_gelic fb_sys_fops
[  240.974876] CPU: 0 PID: 3543 Comm: test_context_cr Not tainted 4.11.3 #1
[  240.974886] task: c6446400 task.stack: c9324000
[  240.974896] NIP: c036f0bc LR: c036f0b8 CTR: 
[  240.974906] REGS: c9327820 TRAP: 0700   Not tainted  (4.11.3)
[  240.974915] MSR: 80028032 
[  240.974978]   CR: 22002822  XER: 2000
[  240.974986] SOFTE: 1 
   GPR00: c036f0b8 c9327aa0 c08c3300 
0054 
   GPR04: cde04620 cde07f80 a4d82c17 
c6446b00 
   GPR08: 0007   
0001 
   GPR12: 22002884 c7ffe000 24022422 
100e20a4 
   GPR16: 100e5d40 4420  
100e8780 
   GPR20:   100e8788 
ca48b3e0 
   GPR24:  ca48b360 0001 
0001 
   GPR28: 00080060 ca765860 ca48b360 
ca7657e0 
[  240.975349] NIP [c036f0bc] .__list_del_entry_valid+0xdc/0x108
[  240.975360] LR [c036f0b8] .__list_del_entry_valid+0xd8/0x108
[  240.975368] Call Trace:
[  240.975380] [c9327aa0] [c036f0b8] 
.__list_del_entry_valid+0xd8/0x108 (unreliable)
[  240.975409] [c9327b10] [c018d068] .__dentry_kill+0x88/0x240
[  240.975428] [c9327ba0] [c018d5cc] .dput+0x3ac/0x508
[  240.975449] [c9327c60] [c017d09c] .done_path_create+0x1c/0x70
[  240.975509] [c9327ce0] [d030701c] .do_spu_create+0x7c/0xd0 
[spufs]
[  240.975531] [c9327d80] [c003a100] .SyS_spu_create+0x190/0x3a8
[  240.97] [c9327e30] [c000a3ac] system_call+0x38/0x104
[  240.975571] Instruction dump:
[  240.975588] 3c62ffe8 386381c0 482826e5 6000 0fe0 3860 4ba4 
7c641b78 
[  240.975660] 3c62ffe8 386381f8 482826c5 6000 <0fe0> 3860 4b84 
7c641b78 
[  240.975732] ---[ end trace 65eeb59a1a105781 ]---
[  240.975843] [ cut here ]
[  240.975893] WARNING: CPU: 0 PID: 3543 at fs/dcache.c:304 
.dentry_free+0x18/0xc8
[  240.975901] Modules linked in: ps3nflash ps3flash cfg80211 bnep spufs 
input_leds evdev led_class usbhid btusb btrtl btbcm btintel bluetooth 
ps3_jupiter_sta ps3_jupiter ohci_hcd snd_ps3 snd_pcm snd_timer ehci_hcd ps3fb 
snd usbcore soundcore syscopyarea ps3_disp_manager ps3_lpm sysfillrect 
usb_common sysimgblt ps3rom ps3_gelic fb_sys_fops
[  240.976172] CPU: 0 PID: 3543 Comm: test_context_cr Tainted: GW   
4.11.3 #1
[  240.976181] task: c6446400 task.stack: c9324000
[  240.976190] NIP: c018cf30 LR: c018d5cc CTR: 
[  240.976200] REGS: c93278b0 TRAP: 0700   Tainted: GW
(4.11.3)
[  240.976208] MSR: 80028032 
[  240.976266]   CR: 22002822  XER: 2000
[  240.976273] SOFTE: 1 
   GPR00: c018d5cc c9327b30 c08c3300 
ca7657e0 
   GPR04: 1a082000 c018d170 e2ec2f41 
c6446ab0 
   GPR08: f96264f1 0001 c086ce48 
0001 
   GPR12: 22002824 c7ffe000 24022422 
100e20a4 
   GPR16: 100e5d40 4420  
100e8780 
   GPR20:   100e8788 
ca48b3e0 
   GPR24:  ca48b360 0001 
0001 
   GPR28: 00080060 00080040 ca765860 
ca7657e0 
[  240.976585] NIP [c018cf30] .dentry_free+0x18/0xc8
[  

Re: [PATCH] powerpc: use uapi/asm-generic/sockios.h

[Arnd Bergmann]

On Fri, May 26, 2017 at 10:32 AM, Stephen Rothwell  
wrote:
> Hi all,
>
> The arch version is identical except for comments and white space.
>
> Signed-off-by: Stephen Rothwell 

Acked-by: Arnd Bergmann 

Re: [PATCH] powerpc: use the asm-genric versions of some uapi includes

[Arnd Bergmann]

On Fri, May 26, 2017 at 8:19 AM, Stephen Rothwell  wrote:
> These are completely obvious as all they do is include the asm-generic
> versions.
>
> Signed-off-by: Stephen Rothwell 

I think I had a patch series to do those some 10 years ago and never
submitted it ;-)

Acked-by: Arnd Bergmann 

asm/sockios.h is identical to the asm-generic version, so we can do
the same there.

asm/swab.h is functionally identical, the asm-generic version
also has a workaround for non-gcc compilers.

asm/socket.h would also be easy to change so we mostly use
asm-generic, the generic version already has a special case
for powerpc.

[PATCH] powerpc: use uapi/asm-generic/sockios.h

[Stephen Rothwell]

Hi all,

The arch version is identical except for comments and white space.

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/include/uapi/asm/Kbuild|  1 +
 arch/powerpc/include/uapi/asm/sockios.h | 20 
 2 files changed, 1 insertion(+), 20 deletions(-)
 delete mode 100644 arch/powerpc/include/uapi/asm/sockios.h

This follows on from my previous "powerpc: use the asm-genric versions
of some uapi includes".

diff --git a/arch/powerpc/include/uapi/asm/Kbuild 
b/arch/powerpc/include/uapi/asm/Kbuild
index 9aba4af4122e..0d960ef78a9a 100644
--- a/arch/powerpc/include/uapi/asm/Kbuild
+++ b/arch/powerpc/include/uapi/asm/Kbuild
@@ -4,4 +4,5 @@ include include/uapi/asm-generic/Kbuild.asm
 generic-y += param.h
 generic-y += poll.h
 generic-y += resource.h
+generic-y += sockios.h
 generic-y += statfs.h
diff --git a/arch/powerpc/include/uapi/asm/sockios.h 
b/arch/powerpc/include/uapi/asm/sockios.h
deleted file mode 100644
index 55cef7675a31..
--- a/arch/powerpc/include/uapi/asm/sockios.h
+++ /dev/null
@@ -1,20 +0,0 @@
-#ifndef _ASM_POWERPC_SOCKIOS_H
-#define _ASM_POWERPC_SOCKIOS_H
-
-/*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-/* Socket-level I/O control calls. */
-#define FIOSETOWN  0x8901
-#define SIOCSPGRP  0x8902
-#define FIOGETOWN  0x8903
-#define SIOCGPGRP  0x8904
-#define SIOCATMARK 0x8905
-#define SIOCGSTAMP 0x8906  /* Get stamp (timeval) */
-#define SIOCGSTAMPNS   0x8907  /* Get stamp (timespec) */
-
-#endif /* _ASM_POWERPC_SOCKIOS_H */
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

[PATCH] powerpc/perf: Fix Power9 test_adder field

[Madhavan Srinivasan]

Commit 8d911904f3ce4 ('powerpc/perf: Add restrictions to PMC5 in power9 DD1')
was added to restrict the use of PMC5 in Power9 DD1. Intend is to diable
the use of PMC5 using raw event code. Commit instead of updating 
"power9_isa207_pmu"
structure, updated "power9_pmu" structure. Patch to fix the same.

Fixes: 8d911904f3ce4 ('powerpc/perf: Add restrictions to PMC5 in power9 DD1')
Reported-by: Shriya 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power9-pmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 018f8e90ac35..bb28e1a41257 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -402,7 +402,7 @@ static struct power_pmu power9_isa207_pmu = {
.name   = "POWER9",
.n_counter  = MAX_PMU_COUNTERS,
.add_fields = ISA207_ADD_FIELDS,
-   .test_adder = ISA207_TEST_ADDER,
+   .test_adder = P9_DD1_TEST_ADDER,
.compute_mmcr   = isa207_compute_mmcr,
.config_bhrb= power9_config_bhrb,
.bhrb_filter_map= power9_bhrb_filter_map,
@@ -421,7 +421,7 @@ static struct power_pmu power9_pmu = {
.name   = "POWER9",
.n_counter  = MAX_PMU_COUNTERS,
.add_fields = ISA207_ADD_FIELDS,
-   .test_adder = P9_DD1_TEST_ADDER,
+   .test_adder = ISA207_TEST_ADDER,
.compute_mmcr   = isa207_compute_mmcr,
.config_bhrb= power9_config_bhrb,
.bhrb_filter_map= power9_bhrb_filter_map,
-- 
2.7.4

Re: [PATCH 3/3] powerpc/8xx: xmon compile fix

[Michael Ellerman]

Nicholas Piggin  writes:
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index f11f65634aab..438fdb0fb142 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -1242,14 +1242,16 @@ bpt_cmds(void)
>  {
>   int cmd;
>   unsigned long a;
> - int mode, i;
> + int i;
>   struct bpt *bp;
> - const char badaddr[] = "Only kernel addresses are permitted "
> - "for breakpoints\n";
>  
>   cmd = inchar();
>   switch (cmd) {
> -#ifndef CONFIG_8xx
> +#ifndef CONFIG_PPC_8xx
> + int mode;
> + const char badaddr[] = "Only kernel addresses are permitted "
> + "for breakpoints\n";
> +
>   case 'd':   /* bd - hardware data breakpoint */
>   mode = 7;
>   cmd = inchar();

GCC 7 rejects this:

  arch/powerpc/xmon/xmon.c: In function ‘bpt_cmds’:
  arch/powerpc/xmon/xmon.c:1252:13: error: statement will never be executed 
[-Werror=switch-unreachable]
const char badaddr[] = "Only kernel addresses are permitted for 
breakpoints\n";
   ^~~

I'll go back to the earlier version.

cheers

Re: timer_create affinity

[John Ogness]

On 2017-05-25, Nicolae Rosia  wrote:
> I'm working on a real-time application using POSIX timers running on a
> QorIQ PowerPC platform with a 4.1 PREEMPT RT kernel and I'm trying to
> understand whether the following can happen:
>
> 1. A thread with a core affinity #0 creates a timer which will invoke
> a callback.
> 2. The kernel will setup the timer using a local timer running on a
> different core, core #1
> 3. The ISR will fire, and could be dispatched by core #2
> 4. The scheduler will run the callback on core #3.
>
> Is there a way to make sure this whole chain will be executed on a
> single core, the core of the caller?

Avoid POSIX timers if you can. POSIX timers not only have the issue that
you mentioned, but also are generally bad for realtime applications.

The realtime wiki has an example[0] of running a cyclic task. With that
simple example you have complete control over the context of your
task. This is necessary to avoid things like priority inversion and
page-faults, and gives you control over things like affinity or cgroups.

John Ogness

[0] 
https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/cyclic

Re: [PATCH 1/1] futex: remove duplicated code

[Thomas Gleixner]

On Thu, 25 May 2017, Will Deacon wrote:
> On Mon, May 22, 2017 at 11:11:33PM +0200, Thomas Gleixner wrote:
> > On Mon, 15 May 2017, Will Deacon wrote:
> > > On Mon, May 15, 2017 at 03:07:42PM +0200, Jiri Slaby wrote:
> > > > There is code duplicated over all architecture's headers for
> > > > futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
> > > > and comparison of the result.
> > > > 
> > > > Remove this duplication and leave up to the arches only the needed
> > > > assembly which is now in arch_futex_atomic_op_inuser.
> > > > 
> > > > Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
> > > > remove pointless access_ok() checks") as access_ok there returns true.
> > > > We introduce it back to the helper for the sake of simplicity (it gets
> > > > optimized away anyway).
> > > 
> > > Whilst I think this is a good idea, the code in question actually results
> > > in undefined behaviour per the C spec and is reported by UBSAN. See my
> > > patch fixing arm64 here (which I'd forgotten about):
> > > 
> > > https://www.spinics.net/lists/linux-arch/msg38564.html
> > > 
> > > But, as stated in the thread above, I think we should go a step further
> > > and remove FUTEX_OP_{OR,ANDN,XOR,OPARG_SHIFT} altogether. They don't
> > > appear to be used by userspace, and this whole thing is a total mess.
> > 
> > You wish. The constants are not used, but FUTEX_WAKE_OP _IS_ used by
> > glibc. They only have one argument it seems:
> > 
> >#define FUTEX_OP_CLEAR_WAKE_IF_GT_ONE  ((4 << 24) | 1)
> > 
> > but I'm pretty sure that there is enough (probably horrible) code (think
> > java) out there using FUTEX_WAKE_OP for whatever (non)sensical reasons in
> > any available combination.
> 
> Indeed, and I'm not proposing to get rid of that. It's the grossly
> over-engineered array of operations and the FUTEX_OP_OPARG_SHIFT modifier
> that I think we should kill. The latter likely behaves differently across
> different architectures and potentially depending on the toolchain you used
> to build the kernel.
> 
> Does anybody know the history behind the interface design?

Which design?

4732efbeb997 ("[PATCH] FUTEX_WAKE_OP: pthread_cond_signal() speedup")

Thanks,

tglx

Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel

[Rob Landley]

On 05/25/2017 04:24 PM, Stephen Rothwell wrote:
> Hi Michael,
> 
> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman  
> wrote:
>>
>> It'll be:
>>
>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT")
>
> And Andrew has asked me to drop that patch from linux-next which will
> happen today.

What approach do the kernel developers suggest I take here?

I would have thought letting it soak in linux-next for a release so
people could fix userspace bugs would be the next step, but this sounds
like that's not an option?

Is the behavior the patch implements wrong?

Rob

[PATCH] powerpc: use the asm-genric versions of some uapi includes

[Stephen Rothwell]

These are completely obvious as all they do is include the asm-generic
versions.

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/include/uapi/asm/Kbuild | 5 +
 arch/powerpc/include/uapi/asm/param.h| 1 -
 arch/powerpc/include/uapi/asm/poll.h | 1 -
 arch/powerpc/include/uapi/asm/resource.h | 1 -
 arch/powerpc/include/uapi/asm/statfs.h   | 6 --
 5 files changed, 5 insertions(+), 9 deletions(-)
 delete mode 100644 arch/powerpc/include/uapi/asm/param.h
 delete mode 100644 arch/powerpc/include/uapi/asm/poll.h
 delete mode 100644 arch/powerpc/include/uapi/asm/resource.h
 delete mode 100644 arch/powerpc/include/uapi/asm/statfs.h

Compile tested with powerpc ppc64_defconfig and headers_install output
compared with only the include guards different (in statfs.h).

diff --git a/arch/powerpc/include/uapi/asm/Kbuild 
b/arch/powerpc/include/uapi/asm/Kbuild
index b15bf6bc0e94..9aba4af4122e 100644
--- a/arch/powerpc/include/uapi/asm/Kbuild
+++ b/arch/powerpc/include/uapi/asm/Kbuild
@@ -1,2 +1,7 @@
 # UAPI Header export list
 include include/uapi/asm-generic/Kbuild.asm
+
+generic-y += param.h
+generic-y += poll.h
+generic-y += resource.h
+generic-y += statfs.h
diff --git a/arch/powerpc/include/uapi/asm/param.h 
b/arch/powerpc/include/uapi/asm/param.h
deleted file mode 100644
index 965d45427975..
--- a/arch/powerpc/include/uapi/asm/param.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/powerpc/include/uapi/asm/poll.h 
b/arch/powerpc/include/uapi/asm/poll.h
deleted file mode 100644
index c98509d3149e..
--- a/arch/powerpc/include/uapi/asm/poll.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/powerpc/include/uapi/asm/resource.h 
b/arch/powerpc/include/uapi/asm/resource.h
deleted file mode 100644
index 04bc4db8921b..
--- a/arch/powerpc/include/uapi/asm/resource.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/powerpc/include/uapi/asm/statfs.h 
b/arch/powerpc/include/uapi/asm/statfs.h
deleted file mode 100644
index 5244834583a4..
--- a/arch/powerpc/include/uapi/asm/statfs.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _ASM_POWERPC_STATFS_H
-#define _ASM_POWERPC_STATFS_H
-
-#include 
-
-#endif
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell