Re: [patch 09/18] cpufreq/pasemi: Adjust system_state check
On 14-05-17, 20:27, Thomas Gleixner wrote: > To enable smp_processor_id() and might_sleep() debug checks earlier, it's > required to add system states between SYSTEM_BOOTING and SYSTEM_RUNNING. > > Adjust the system_state check in pas_cpufreq_cpu_exit() to handle the extra > states. > > Signed-off-by: Thomas Gleixner > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: linuxppc-dev@lists.ozlabs.org > --- > drivers/cpufreq/pasemi-cpufreq.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/drivers/cpufreq/pasemi-cpufreq.c > +++ b/drivers/cpufreq/pasemi-cpufreq.c > @@ -226,7 +226,7 @@ static int pas_cpufreq_cpu_exit(struct c >* We don't support CPU hotplug. Don't unmap after the system >* has already made it to a running state. >*/ > - if (system_state != SYSTEM_BOOTING) > + if (system_state >= SYSTEM_RUNNING) > return 0; > > if (sdcasr_mapbase) Acked-by: Viresh Kumar -- viresh
Re: powerpc/mm/book3s/64: Rework page table geometry for lower memory usage
On Tue, 2017-05-09 at 08:05:48 UTC, Michael Ellerman wrote:
> Recently in commit f6eedbba7a26 ("powerpc/mm/hash: Increase VA range to
> 128TB")
> we increased the virtual address space for user processes to 128TB by default,
> and up to 512TB if user space opts in.
>
> This obviously required expanding the range of the Linux page tables. For
> Book3s
> 64-bit using hash and with PAGE_SIZE=64K, we increased the PGD to 2^15
> entries.
> This meant we could cover the full address range, while still being able to
> insert a 16G hugepage at the PGD level and a 16M hugepage in the PMD.
>
> The downside of that geometry is that it uses a lot of memory for the PGD, and
> in particular makes the PGD a 4-page allocation, which means it's much more
> likely to fail under memory pressure.
>
> Instead we can make the PMD larger, so that a single PUD entry maps 16G,
> allowing the 16G hugepages to sit at that level in the tree. We're then able
> to
> split the remaining bits between the PUG and PGD. We make the PGD slightly
> larger as that results in lower memory usage for typical programs.
>
> When THP is enabled the PMD actually doubles in size, to 2^11 entries, or 2^14
> bytes, which is large but still < PAGE_SIZE.
>
> Signed-off-by: Michael Ellerman
> Reviewed-by: Aneesh Kumar K.V
> Reviewed-by: Balbir Singh
Applied to powerpc next.
https://git.kernel.org/powerpc/c/ba95b5d0359609b4ec8010f77c40ab
cheers
Re: [1/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
On Tue, 2017-05-09 at 13:44:30 UTC, Michael Ellerman wrote: > From: Nicholas Piggin > > Introduce primitives for FDT parsing. These will be used for powerpc > cpufeatures node scanning, which has quite complex structure but should > be processed early. > > Cc: devicet...@vger.kernel.org > Acked-by: Rob Herring > Signed-off-by: Nicholas Piggin > Signed-off-by: Michael Ellerman Series applied to powerpc next. https://git.kernel.org/powerpc/c/ea47dd191d543f81e0912b5dc0471b cheers
Re: powerpc: fix distclean with Makefile.postlink
On Mon, 2017-05-08 at 08:50:16 UTC, =?utf-8?q?Horia_Geant=C4=83?= wrote:
> Makefile.postlink always includes include/config/auto.conf, however
> this file is not present in a clean kernel tree, causing make to fail:
>
> arch/powerpc/Makefile.postlink:10: include/config/auto.conf: No such file or
> directory
> make[1]: *** No rule to make target `include/config/auto.conf'. Stop.
> make: *** [vmlinuxclean] Error 2
>
> Change the inclusion such that file not being found does not trigger
> an error.
>
> Fixes: f188d0524d7e ("powerpc: Use the new post-link pass to check
> relocations")
> Reported-by: Mircea Pop
> Signed-off-by: Horia GeantÄ
> Tested-by: Justin M. Forbes
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/24e0bfbf63bac18495b0ad76115269
cheers
Re: [linux-next, bisected, 1945bc45] build brakes for PowerPC BE configuration on LPAR
On Thu, 2017-05-04 at 10:41:12 UTC, Nicholas Piggin wrote: > On Thu, 04 May 2017 14:54:19 +0530 > Abdul Haleem wrote: > > > Hi, > > > > linux-next build fails on BE config with next-20170424 onwards > > > > the patch https://lkml.org/lkml/2017/4/20/994 fixes a similar issue > > with kvm guest build failure. > > > > arch/powerpc/kernel/exceptions-64s.S: Assembler messages: > > arch/powerpc/kernel/exceptions-64s.S:395: Error: operand out of range > > (0x8280 is not between 0x and > > 0x) > > make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 > > > > Bisection resulted with the below bad commit. > > > > commit 1945bc4549e5cb1f9aa873ec29191aa54dc851d > > Author: Nicholas Piggin > > Date: Wed Apr 19 23:05:47 2017 +1000 > > > > powerpc/64s: Fix POWER9 machine check handler from stop state > > > > Reviewed-by: Gautham R. Shenoy > > Reviewed-by: Mahesh J Salgaonkar > > Signed-off-by: Nicholas Piggin > > Signed-off-by: Michael Ellerman > > > > arch/powerpc/include/asm/reg.h | 1 + > > arch/powerpc/kernel/exceptions-64s.S | 79 > > --- > > arch/powerpc/kernel/idle_book3s.S| 25 + > > 3 files changed, 70 insertions(+), 35 deletions(-) > > > > the BE configuration file is attached. > > Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/6102c005a71b4a7a6433d43b887662 cheers
Re: [v2] powerpc/powernv: Block PCI config access on BCM5718 during EEH recovery
On Wed, 2017-04-19 at 04:46:24 UTC, Gavin Shan wrote:
> Similar to what is done in commit b6541db13952 ("powerpc/eeh: Block
> PCI config access upon frozen PE"), we need block PCI config access
> for BCM5719 when recovering frozen error on them. Otherwise, an
> unexpected recursive fenced PHB error is observed.
>
>0001:06:00.0 Ethernet controller: Broadcom Corporation \
> NetXtreme BCM5718 Gigabit Ethernet PCIe (rev 10)
>0001:06:00.1 Ethernet controller: Broadcom Corporation \
> NetXtreme BCM5718 Gigabit Ethernet PCIe (rev 10)
>
> Signed-off-by: Gavin Shan
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c374ed27c93698c794f99c5d41d9ad
cheers
Re: [PATCH 2/2] v1 powerpc/powernv: Enable removal of memory for in memory tracing
On 05/15/2017 09:04 AM, Rashmica Gupta wrote: > > > On 14/05/17 14:55, Anshuman Khandual wrote: >> On 05/09/2017 12:36 PM, Rashmica Gupta wrote: >>> Sorry for the late reply, I somehow missed this. >>> >>> >>> On 03/05/17 21:56, Anshuman Khandual wrote: On 05/03/2017 09:22 AM, Rashmica Gupta wrote: > On 28/04/17 19:52, Anshuman Khandual wrote: >> On 04/28/2017 11:12 AM, Rashmica Gupta wrote: >>> Some powerpc hardware features may want to gain access to a chunk of >> What kind of features ? Please add specifics. >> >>> undisturbed real memory. This update provides a means to unplug >>> said >>> memory >> Undisturbed ? Meaning part of memblock and currently inside the buddy >> allocator which we are trying to hot unplug out ? >> >>> from the kernel with a set of debugfs calls. By writing an integer >>> containing >>> the size of memory to be unplugged into >> Does the size has some constraints like aligned with memblock section >> size ? LMB size ? page block size ? etc. Please add the details. > Will do. > >>> /sys/kernel/debug/powerpc/memtrace/enable, the code will remove that >>> much >>> memory from the end of each available chip's memory space (ie each >>> memory node). >> amount (I guess bytes in this case) of memory will be removed >> from the end of the NUMA node ? Whats the guarantee that they >> would be >> free at that time and not being pinned by some process ? If its not >> guaranteed to be freed, then interface description should state that >> clearly. > We start looking from the end of the NUMA node but of course there > is no > guarantee > that we will always be able to find some memory there that we are able > to remove. Okay. Do we have interface for giving this memory back to the buddy allocator again when we are done with HW tracing ? If not we need to add one. >>> Not at the moment. Last time I spoke to Anton he said something along >>> the lines >>> of it not being too important as if you are getting the hardware traces >>> for debugging >>> purposes you are probably not worried about a bit of memory being out of >>> action. >>> >>> However I can't see why having an interface to online the memory would >>> be a bad thing, >>> so I'll look into it. >> Yes, the interface to put them back into buddy is important even if the >> amount of memory is very less for tracing. Just need to trigger hotplug >> and online procedure to put it back. >> >>> In addition, the means to read out the contents of the unplugged >>> memory is also >>> provided by reading out the >>> /sys/kernel/debug/powerpc/memtrace//trace >>> file. >> All of the debugfs file interfaces added here should be documented >> some >> where in detail. >> >>> Signed-off-by: Anton Blanchard >>> Signed-off-by: Rashmica Gupta >>> >>> --- >>> This requires the 'Wire up hpte_removebolted for powernv' patch. >>> >>> RFC -> v1: Added in two missing locks. Replaced the open-coded >>> flush_memory_region() with the existing >>> flush_inval_dcache_range(start, end). >>> >>> memtrace_offline_pages() is open-coded because offline_pages is >>> designed to be >>> called through the sysfs interface - not directly. >>> >>> We could move the offlining of pages to userspace, which removes >>> some >>> of this >>> open-coding. This would then require passing info to the kernel such >>> that it >>> can then remove the memory that has been offlined. This could be >>> done >>> using >>> notifiers, but this isn't simple due to locking (remove_memory needs >>> mem_hotplug_begin() which the sysfs interface already has). This >>> could also be >>> done through the debugfs interface (similar to what is done here). >>> Either way, >>> this would require the process that needs the memory to have >>> open-coded code >>> which it shouldn't really be involved with. >>> >>> As the current remove_memory() function requires the memory to >>> already be >>> offlined, it makes sense to keep the offlining and removal of memory >>> functionality grouped together so that a process can simply make one >>> request to >>> unplug some memory. Ideally there would be a kernel function we >>> could >>> call that >>> would offline the memory and then remove it. >>> >>> >>> arch/powerpc/platforms/powernv/memtrace.c | 276 >>> ++ >>> 1 file changed, 276 insertions(+) >>> create mode 100644 arch/powerpc/platforms/powernv/memtrace.c >>> >>> diff --git a/arch/powerpc/platforms/powernv/memtrace.c >>> b/arch/powerpc/platforms/powernv/memtrace.c >>> new file mode 100644 >>> index 000..86184b1 >>> --- /dev/null >>> +++ b/arch/powerpc/platforms/
Re: [PATCH 2/2] v1 powerpc/powernv: Enable removal of memory for in memory tracing
On 14/05/17 14:55, Anshuman Khandual wrote: On 05/09/2017 12:36 PM, Rashmica Gupta wrote: Sorry for the late reply, I somehow missed this. On 03/05/17 21:56, Anshuman Khandual wrote: On 05/03/2017 09:22 AM, Rashmica Gupta wrote: On 28/04/17 19:52, Anshuman Khandual wrote: On 04/28/2017 11:12 AM, Rashmica Gupta wrote: Some powerpc hardware features may want to gain access to a chunk of What kind of features ? Please add specifics. undisturbed real memory. This update provides a means to unplug said memory Undisturbed ? Meaning part of memblock and currently inside the buddy allocator which we are trying to hot unplug out ? from the kernel with a set of debugfs calls. By writing an integer containing the size of memory to be unplugged into Does the size has some constraints like aligned with memblock section size ? LMB size ? page block size ? etc. Please add the details. Will do. /sys/kernel/debug/powerpc/memtrace/enable, the code will remove that much memory from the end of each available chip's memory space (ie each memory node). amount (I guess bytes in this case) of memory will be removed from the end of the NUMA node ? Whats the guarantee that they would be free at that time and not being pinned by some process ? If its not guaranteed to be freed, then interface description should state that clearly. We start looking from the end of the NUMA node but of course there is no guarantee that we will always be able to find some memory there that we are able to remove. Okay. Do we have interface for giving this memory back to the buddy allocator again when we are done with HW tracing ? If not we need to add one. Not at the moment. Last time I spoke to Anton he said something along the lines of it not being too important as if you are getting the hardware traces for debugging purposes you are probably not worried about a bit of memory being out of action. However I can't see why having an interface to online the memory would be a bad thing, so I'll look into it. Yes, the interface to put them back into buddy is important even if the amount of memory is very less for tracing. Just need to trigger hotplug and online procedure to put it back. In addition, the means to read out the contents of the unplugged memory is also provided by reading out the /sys/kernel/debug/powerpc/memtrace//trace file. All of the debugfs file interfaces added here should be documented some where in detail. Signed-off-by: Anton Blanchard Signed-off-by: Rashmica Gupta --- This requires the 'Wire up hpte_removebolted for powernv' patch. RFC -> v1: Added in two missing locks. Replaced the open-coded flush_memory_region() with the existing flush_inval_dcache_range(start, end). memtrace_offline_pages() is open-coded because offline_pages is designed to be called through the sysfs interface - not directly. We could move the offlining of pages to userspace, which removes some of this open-coding. This would then require passing info to the kernel such that it can then remove the memory that has been offlined. This could be done using notifiers, but this isn't simple due to locking (remove_memory needs mem_hotplug_begin() which the sysfs interface already has). This could also be done through the debugfs interface (similar to what is done here). Either way, this would require the process that needs the memory to have open-coded code which it shouldn't really be involved with. As the current remove_memory() function requires the memory to already be offlined, it makes sense to keep the offlining and removal of memory functionality grouped together so that a process can simply make one request to unplug some memory. Ideally there would be a kernel function we could call that would offline the memory and then remove it. arch/powerpc/platforms/powernv/memtrace.c | 276 ++ 1 file changed, 276 insertions(+) create mode 100644 arch/powerpc/platforms/powernv/memtrace.c diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c new file mode 100644 index 000..86184b1 --- /dev/null +++ b/arch/powerpc/platforms/powernv/memtrace.c @@ -0,0 +1,276 @@ +/* + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Copyright (C) IBM Corporation, 2014 + * + * Author: Anton Blanchard + */ + +#define pr_fmt(fmt) "powernv-memtrace: " fmt + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +st
[patch 06/18] powerpc: Adjust system_state check
To enable smp_processor_id() and might_sleep() debug checks earlier, it's
required to add system states between SYSTEM_BOOTING and SYSTEM_RUNNING.
Adjust the system_state check in smp_generic_cpu_bootable() to handle the
extra states.
Signed-off-by: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/smp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -97,7 +97,7 @@ int smp_generic_cpu_bootable(unsigned in
/* Special case - we inhibit secondary thread startup
* during boot if the user requests it.
*/
- if (system_state == SYSTEM_BOOTING && cpu_has_feature(CPU_FTR_SMT)) {
+ if (system_state < SYSTEM_RUNNING && cpu_has_feature(CPU_FTR_SMT)) {
if (!smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
return 0;
if (smt_enabled_at_boot
[patch 09/18] cpufreq/pasemi: Adjust system_state check
To enable smp_processor_id() and might_sleep() debug checks earlier, it's required to add system states between SYSTEM_BOOTING and SYSTEM_RUNNING. Adjust the system_state check in pas_cpufreq_cpu_exit() to handle the extra states. Signed-off-by: Thomas Gleixner Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: linuxppc-dev@lists.ozlabs.org --- drivers/cpufreq/pasemi-cpufreq.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/cpufreq/pasemi-cpufreq.c +++ b/drivers/cpufreq/pasemi-cpufreq.c @@ -226,7 +226,7 @@ static int pas_cpufreq_cpu_exit(struct c * We don't support CPU hotplug. Don't unmap after the system * has already made it to a running state. */ - if (system_state != SYSTEM_BOOTING) + if (system_state >= SYSTEM_RUNNING) return 0; if (sdcasr_mapbase)
[PATCH] fsl_udc_core: fix spelling mistake: "Dectected" -> "Detected"
From: Colin Ian King Trivial fix to spelling mistake in seq_printf text Signed-off-by: Colin Ian King --- drivers/usb/gadget/udc/fsl_udc_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c index 6f2f71c054be..63ab3d50f3f6 100644 --- a/drivers/usb/gadget/udc/fsl_udc_core.c +++ b/drivers/usb/gadget/udc/fsl_udc_core.c @@ -2067,7 +2067,7 @@ static int fsl_proc_read(struct seq_file *m, void *v) "Sleep Enable: %d SOF Received Enable: %d " "Reset Enable: %d\n" "System Error Enable: %d " - "Port Change Dectected Enable: %d\n" + "Port Change Detected Enable: %d\n" "USB Error Intr Enable: %d USB Intr Enable: %d\n\n", (tmp_reg & USB_INTR_DEVICE_SUSPEND) ? 1 : 0, (tmp_reg & USB_INTR_SOF_EN) ? 1 : 0, -- 2.11.0
Re: [PATCH V4] hwmon: (ibmpowernv) Add highest/lowest attributes to sensors
On 05/06/2017 08:27 AM, Shilpasri G Bhat wrote:
OCC provides historical minimum and maximum value for the sensor
readings. This patch exports them as highest and lowest attributes
for the inband sensors copied by OCC to main memory.
Signed-off-by: Shilpasri G Bhat
---
Changes from V3:
- Removed extra variable 'hwmon_index'
- Retain the initialization of sensor_data for *_input attribute in
create_device_attrs(), otherwise all the sensors from different
classes will numbered continuously.
drivers/hwmon/ibmpowernv.c | 69 +-
1 file changed, 62 insertions(+), 7 deletions(-)
diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 6d2e660..862b832 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -287,6 +287,7 @@ static int populate_attr_groups(struct platform_device
*pdev)
opal = of_find_node_by_path("/ibm,opal/sensors");
for_each_child_of_node(opal, np) {
const char *label;
+ int len;
if (np->name == NULL)
continue;
@@ -298,10 +299,14 @@ static int populate_attr_groups(struct platform_device
*pdev)
sensor_groups[type].attr_count++;
/*
-* add a new attribute for labels
+* add attributes for labels, min and max
*/
if (!of_property_read_string(np, "label", &label))
sensor_groups[type].attr_count++;
+ if (of_find_property(np, "sensor-data-min", &len))
+ sensor_groups[type].attr_count++;
+ if (of_find_property(np, "sensor-data-max", &len))
+ sensor_groups[type].attr_count++;
len isn't used, so you can just pass NULL and avoid the unnecessary variable.
}
of_node_put(opal);
@@ -337,6 +342,41 @@ static void create_hwmon_attr(struct sensor_data *sdata,
const char *attr_name,
sdata->dev_attr.show = show;
}
+static void populate_sensor(struct sensor_data *sdata, int od, int hd, int sid,
+ const char *attr_name, enum sensors type,
+ const struct attribute_group *pgroup,
+ ssize_t (*show)(struct device *dev,
+ struct device_attribute *attr,
+ char *buf))
+{
+ sdata->id = sid;
+ sdata->type = type;
+ sdata->opal_index = od;
+ sdata->hwmon_index = hd;
+ create_hwmon_attr(sdata, attr_name, show);
+ pgroup->attrs[sensor_groups[type].attr_count++] = &sdata->dev_attr.attr;
+}
+
+static char *get_max_attr(enum sensors type)
+{
+ switch (type) {
+ case POWER_INPUT:
+ return "input_highest";
+ default:
+ return "highest";
+ }
+}
+
+static char *get_min_attr(enum sensors type)
+{
+ switch (type) {
+ case POWER_INPUT:
+ return "input_lowest";
+ default:
+ return "lowest";
+ }
+}
+
/*
* Iterate through the device tree for each child of 'sensors' node, create
* a sysfs attribute file, the file is named by translating the DT node name
@@ -417,16 +457,31 @@ static int create_device_attrs(struct platform_device
*pdev)
* attribute. They are related to the same
* sensor.
*/
- sdata[count].type = type;
- sdata[count].opal_index = sdata[count - 1].opal_index;
- sdata[count].hwmon_index = sdata[count - 1].hwmon_index;
make_sensor_label(np, &sdata[count], label);
+ populate_sensor(&sdata[count], opal_index,
+ sdata[count - 1].hwmon_index,
+ sensor_id, "label", type, pgroups[type],
+ show_label);
+ count++;
+ }
- create_hwmon_attr(&sdata[count], "label", show_label);
+ if (!of_property_read_u32(np, "sensor-data-max", &sensor_id)) {
+ attr_name = get_max_attr(type);
+ populate_sensor(&sdata[count], opal_index,
+ sdata[count - 1].hwmon_index,
+ sensor_id, attr_name, type,
+ pgroups[type], show_sensor);
+ count++;
+ }
- pgroups[type]->attrs[sensor_groups[type].attr_count++] =
- &sdata[count++].dev_attr.attr;
+ if (!of_property_read_u32(np, "sensor-data-min", &sensor_id)) {
+ attr_name = get_min_attr(type);
+ populate_sensor(&sdata[count], opal_index,
+
