* [PATCH 21/21] powerpc: Add missing prototypes in setup_32.c
From: Mathieu Malaterre @ 2018-02-25 17:22 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Paul Mackerras, Jiri Slaby, linuxppc-dev,
linux-kernel, Mathieu Malaterre
In-Reply-To: <20180225172236.29650-1-malat@debian.org>
This commit add the prototypes for the following function:
- early_init
- machine_init
- ppc_setup_l2cr
- ppc_setup_l3cr
- ppc_init
the other missing ones were already added in setup.h previously. Fix the
following warnings (treated as error in W=1):
AR init/built-in.o
arch/powerpc/kernel/setup_32.c:68:30: error: no previous prototype for ‘early_init’ [-Werror=missing-prototypes]
notrace unsigned long __init early_init(unsigned long dt_ptr)
^~~~~~~~~~
arch/powerpc/kernel/setup_32.c:99:21: error: no previous prototype for ‘machine_init’ [-Werror=missing-prototypes]
notrace void __init machine_init(u64 dt_ptr)
^~~~~~~~~~~~
arch/powerpc/kernel/setup_32.c:124:12: error: no previous prototype for ‘ppc_setup_l2cr’ [-Werror=missing-prototypes]
int __init ppc_setup_l2cr(char *str)
^~~~~~~~~~~~~~
arch/powerpc/kernel/setup_32.c:137:12: error: no previous prototype for ‘ppc_setup_l3cr’ [-Werror=missing-prototypes]
int __init ppc_setup_l3cr(char *str)
^~~~~~~~~~~~~~
arch/powerpc/kernel/setup_32.c:183:12: error: no previous prototype for ‘ppc_init’ [-Werror=missing-prototypes]
int __init ppc_init(void)
^~~~~~~~
arch/powerpc/kernel/setup_32.c:198:13: error: no previous prototype for ‘irqstack_early_init’ [-Werror=missing-prototypes]
void __init irqstack_early_init(void)
^~~~~~~~~~~~~~~~~~~
arch/powerpc/kernel/setup_32.c:238:13: error: no previous prototype for ‘setup_power_save’ [-Werror=missing-prototypes]
void __init setup_power_save(void)
^~~~~~~~~~~~~~~~
arch/powerpc/kernel/setup_32.c:253:13: error: no previous prototype for ‘initialize_cache_info’ [-Werror=missing-prototypes]
__init void initialize_cache_info(void)
^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
arch/powerpc/kernel/setup.h | 5 +++++
arch/powerpc/kernel/setup_32.c | 2 ++
2 files changed, 7 insertions(+)
diff --git a/arch/powerpc/kernel/setup.h b/arch/powerpc/kernel/setup.h
index 3fc11e30308f..d768023a04bd 100644
--- a/arch/powerpc/kernel/setup.h
+++ b/arch/powerpc/kernel/setup.h
@@ -17,6 +17,11 @@ void irqstack_early_init(void);
#ifdef CONFIG_PPC32
void setup_power_save(void);
+unsigned long __init early_init(unsigned long dt_ptr);
+void __init machine_init(u64 dt_ptr);
+int __init ppc_setup_l2cr(char *str);
+int __init ppc_setup_l3cr(char *str);
+int __init ppc_init(void);
#else
static inline void setup_power_save(void) { };
#endif
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 51ebc01fff52..12bcab77a29f 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -40,6 +40,8 @@
#include <asm/code-patching.h>
#include <asm/cpu_has_feature.h>
+#include "setup.h"
+
#define DBG(fmt...)
extern void bootx_init(unsigned long r4, unsigned long phys);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 01/21] powerpc: Remove warning on array size when empty
From: Segher Boessenkool @ 2018-02-25 18:53 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Michael Ellerman, linux-kernel, Paul Mackerras, Jiri Slaby,
linuxppc-dev
In-Reply-To: <20180225172236.29650-2-malat@debian.org>
Hi!
On Sun, Feb 25, 2018 at 06:22:16PM +0100, Mathieu Malaterre wrote:
> When neither CONFIG_ALTIVEC, nor CONFIG_VSX or CONFIG_PPC64 is defined, the
> array feature_properties is defined as an empty array, which in turn
> triggers the following warning (treated as error on W=1):
> - for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
> + for (; fp != feature_properties + ARRAY_SIZE(feature_properties); ++fp) {
You could just write != instead of < ? Seems more readable.
Maybe something can be done to ARRAY_SIZE to make this not warn.
Segher
^ permalink raw reply
* Re: [PATCH v12 22/22] selftests/vm: Fix deadlock in protection_keys.c
From: Balbir Singh @ 2018-02-25 23:19 UTC (permalink / raw)
To: Ram Pai
Cc: shuahkh, linux-kselftest, mpe, linuxppc-dev, linux-mm, x86,
linux-arch, linux-doc, linux-kernel, mingo, akpm, dave.hansen,
benh, paulus, khandual, aneesh.kumar, hbabu, mhocko, bauerman,
ebiederm, arnd
In-Reply-To: <1519264541-7621-23-git-send-email-linuxram@us.ibm.com>
On Wed, 21 Feb 2018 17:55:41 -0800
Ram Pai <linuxram@us.ibm.com> wrote:
> From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
>
> The sig_chld() handler calls dprintf2() taking care of setting
> dprint_in_signal so that sigsafe_printf() won't call printf().
> Unfortunately, this precaution is is negated by dprintf_level(), which
> has a call to fflush().
>
fflush() is not the signal-safe function list, so this makes sense.
I wonder if fflush() is needed in sigsafe_printf()?
How about?
diff --git a/tools/testing/selftests/x86/pkey-helpers.h b/tools/testing/selftests/x86/pkey-helpers.h
index b3cb7670e026..2c3b39851f10 100644
--- a/tools/testing/selftests/x86/pkey-helpers.h
+++ b/tools/testing/selftests/x86/pkey-helpers.h
@@ -29,6 +29,7 @@ static inline void sigsafe_printf(const char *format, ...)
va_start(ap, format);
if (!dprint_in_signal) {
vprintf(format, ap);
+ fflush(NULL); \
} else {
int ret;
int len = vsnprintf(dprint_in_signal_buffer,
@@ -49,7 +50,6 @@ static inline void sigsafe_printf(const char *format, ...)
#define dprintf_level(level, args...) do { \
if (level <= DEBUG_LEVEL) \
sigsafe_printf(args); \
- fflush(NULL); \
} while (0)
#define dprintf0(args...) dprintf_level(0, args)
#define dprintf1(args...) dprintf_level(1, args)
But both are equivalent I guess, so
Acked-by: Balbir Singh <bsingharora@gmail.com>
^ permalink raw reply related
* [PATCH stable v4.4] powerpc/64s: Fix RFI flush dependency on HARDLOCKUP_DETECTOR
From: Michael Ellerman @ 2018-02-26 2:13 UTC (permalink / raw)
To: stable, greg; +Cc: linuxppc-dev, bernhard.kaindl
The backport of commit aa8a5e0062ac ("powerpc/64s: Add support for RFI
flush of L1-D cache"), incorrectly placed the new RFI flush code
inside an existing #ifdef CONFIG_HARDLOCKUP_DETECTOR block.
This has the obvious effect of requiring HARDLOCKUP_DETECTOR to be
enabled in order for RFI flush to be enabled, which is a bug.
Fix it by moving the #endif up to where it belongs.
Fixes: c3892946315e ("powerpc/64s: Add support for RFI flush of L1-D cache")
Reported-by: Bernhard Kaindl <bernhard.kaindl@thalesgroup.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/setup_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index df4a87eb8da4..9eb469bed22b 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -835,6 +835,7 @@ static int __init disable_hardlockup_detector(void)
return 0;
}
early_initcall(disable_hardlockup_detector);
+#endif
#ifdef CONFIG_PPC_BOOK3S_64
static enum l1d_flush_type enabled_flush_types;
@@ -973,4 +974,3 @@ ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, cha
return sprintf(buf, "Vulnerable\n");
}
#endif /* CONFIG_PPC_BOOK3S_64 */
-#endif
--
2.14.1
^ permalink raw reply related
* [PATCH] selftests/powerpc: Skip tm-trap if transactional memory is not enabled
From: Michael Ellerman @ 2018-02-26 2:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: gromero
Some processor revisions do not support transactional memory, and
additionally kernel support can be disabled. In either case the
tm-trap test should be skipped, otherwise it will fail with a SIGILL.
Fixes: a08082f8e4e1 ("powerpc/selftests: Check endianness on trap in TM")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/tm/tm-trap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/powerpc/tm/tm-trap.c b/tools/testing/selftests/powerpc/tm/tm-trap.c
index 5d92c23ee6cb..179d592f0073 100644
--- a/tools/testing/selftests/powerpc/tm/tm-trap.c
+++ b/tools/testing/selftests/powerpc/tm/tm-trap.c
@@ -255,6 +255,8 @@ int tm_trap_test(void)
struct sigaction trap_sa;
+ SKIP_IF(!have_htm());
+
trap_sa.sa_flags = SA_SIGINFO;
trap_sa.sa_sigaction = trap_signal_handler;
sigaction(SIGTRAP, &trap_sa, NULL);
--
2.14.1
^ permalink raw reply related
* [PATCH] selftests/powerpc: Skip the subpage_prot tests if the syscall is disabled
From: Michael Ellerman @ 2018-02-26 4:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: khandual, aneesh.kumar
The subpage_prot syscall is only functional when the system is using
the Hash MMU. Since commit 5b2b80714796 ("powerpc/mm: Invalidate
subpage_prot() system call on radix platforms") it returns ENOENT when
the Radix MMU is active. Currently this just makes the test fail.
Instead check explicitly for ENOENT and skip if we see that.
Fixes: 5b2b80714796 ("powerpc/mm: Invalidate subpage_prot() system call on radix platforms")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/mm/subpage_prot.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/tools/testing/selftests/powerpc/mm/subpage_prot.c b/tools/testing/selftests/powerpc/mm/subpage_prot.c
index 35ade7406dcd..81570680e7ea 100644
--- a/tools/testing/selftests/powerpc/mm/subpage_prot.c
+++ b/tools/testing/selftests/powerpc/mm/subpage_prot.c
@@ -135,6 +135,15 @@ static int run_test(void *addr, unsigned long size)
return 0;
}
+static int syscall_available(void)
+{
+ int rc;
+
+ errno = 0;
+ rc = syscall(__NR_subpage_prot, 0, 0, 0);
+ return rc == 0 || errno != ENOENT;
+}
+
int test_anon(void)
{
unsigned long align;
@@ -145,6 +154,8 @@ int test_anon(void)
void *mallocblock;
unsigned long mallocsize;
+ SKIP_IF(!syscall_available());
+
if (getpagesize() != 0x10000) {
fprintf(stderr, "Kernel page size must be 64K!\n");
return 1;
@@ -180,6 +191,8 @@ int test_file(void)
off_t filesize;
int fd;
+ SKIP_IF(!syscall_available());
+
fd = open(file_name, O_RDWR);
if (fd == -1) {
perror("failed to open file");
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] selftests/powerpc: Skip the subpage_prot tests if the syscall is disabled
From: Aneesh Kumar K.V @ 2018-02-26 4:33 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: khandual
In-Reply-To: <20180226042510.13373-1-mpe@ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> The subpage_prot syscall is only functional when the system is using
> the Hash MMU. Since commit 5b2b80714796 ("powerpc/mm: Invalidate
> subpage_prot() system call on radix platforms") it returns ENOENT when
> the Radix MMU is active. Currently this just makes the test fail.
>
> Instead check explicitly for ENOENT and skip if we see that.
>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Fixes: 5b2b80714796 ("powerpc/mm: Invalidate subpage_prot() system call on radix platforms")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> tools/testing/selftests/powerpc/mm/subpage_prot.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/tools/testing/selftests/powerpc/mm/subpage_prot.c b/tools/testing/selftests/powerpc/mm/subpage_prot.c
> index 35ade7406dcd..81570680e7ea 100644
> --- a/tools/testing/selftests/powerpc/mm/subpage_prot.c
> +++ b/tools/testing/selftests/powerpc/mm/subpage_prot.c
> @@ -135,6 +135,15 @@ static int run_test(void *addr, unsigned long size)
> return 0;
> }
>
> +static int syscall_available(void)
> +{
> + int rc;
> +
> + errno = 0;
> + rc = syscall(__NR_subpage_prot, 0, 0, 0);
> + return rc == 0 || errno != ENOENT;
> +}
> +
> int test_anon(void)
> {
> unsigned long align;
> @@ -145,6 +154,8 @@ int test_anon(void)
> void *mallocblock;
> unsigned long mallocsize;
>
> + SKIP_IF(!syscall_available());
> +
> if (getpagesize() != 0x10000) {
> fprintf(stderr, "Kernel page size must be 64K!\n");
> return 1;
> @@ -180,6 +191,8 @@ int test_file(void)
> off_t filesize;
> int fd;
>
> + SKIP_IF(!syscall_available());
> +
> fd = open(file_name, O_RDWR);
> if (fd == -1) {
> perror("failed to open file");
> --
> 2.14.1
^ permalink raw reply
* Re: [PATCH] cpuidle/powernv : Restore different PSSCR for idle and hotplug
From: Stewart Smith @ 2018-02-26 4:47 UTC (permalink / raw)
To: Akshay Adiga, linux-kernel, linuxppc-dev; +Cc: npiggin, mpe, Akshay Adiga
In-Reply-To: <1519053500-31860-1-git-send-email-akshay.adiga@linux.vnet.ibm.com>
Akshay Adiga <akshay.adiga@linux.vnet.ibm.com> writes:
> commit 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle
> states via stop API.") uses stop-api provided by the firmware to restore
> PSSCR. PSSCR restore is required for handling special wakeup. When special
> wakeup is completed, the core enters stop state based on restored PSSCR.
>
> Currently PSSCR is restored to deepest available stop state, causing
> a idle cpu to enter deeper stop state on a special wakeup, which causes
> the cpu to hang on wakeup.
>
> A "sensors" command which reads temperature (through DTS sensors) on idle
> cpu can trigger special wakeup.
>
> Failed Scenario :
> Request restore of PSSCR with RL = 11
> cpu enters idle state (stop5)
> user triggers "sensors" command
> Assert special wakeup on cpu
> Restores PSSCR with RL = 11 <---- Done by firmware
> Read DTS sensor
> Deassert special wakeup
> cpu enters idle state (stop11) <-- Instead of stop5
>
> Cpu hang is caused because cpu ended up in a deeper state than it requested
>
> This patch fixes instability caused by special wakeup when stop11 is
> enabled. Requests restore of PSSCR to deepest stop state used by cpuidle.
> Only when offlining cpu, request restore of PSSCR to deepest stop state.
> On onlining cpu, request restore of PSSCR to deepest stop state used by
> cpuidle.
>
> Fixes : 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle
> states via stop API.")
This should CC stable ?
We'll need this to enable stop11 in firmware and not break things, right?
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply
* [PATCH 00/27] cpufreq: Stop validating cpufreq table in drivers
From: Viresh Kumar @ 2018-02-26 5:08 UTC (permalink / raw)
To: Rafael Wysocki, bcm-kernel-feedback-list, Benjamin Herrenschmidt,
Brian Norris, Florian Fainelli, Gregory Fong, Jonathan Hunter,
Krzysztof Kozlowski, Kukjin Kim, Markus Mayer, Matthias Brugger,
Michael Ellerman, Paul Mackerras, Sudeep Holla, Thierry Reding
Cc: Viresh Kumar, linux-pm, Vincent Guittot, linux-arm-kernel,
linux-mediatek, linuxppc-dev, linux-samsung-soc, linux-tegra
Hi,
A patchset [1] sent last week already updated the cpufreq core to start
validating cpufreq table if the policy contains a valid
"policy->freq_table" pointer.
This series updates all such drivers to stop validating the cpufreq
table directly and let only the core handle it.
It depends on the previous series [1] and two cleanup patches [2][3] and
is rebased over 4.16-rc3.
It is already tested by the 0-day testing infrastructure and no issues
were reported.
--
viresh
[1] https://lkml.kernel.org/r/bd8c6133ad0bdd56c936802bcf26878d7cbdb679.1519279148.git.viresh.kumar@linaro.org
[2] https://lkml.kernel.org/r/77d470741dab32c2076a35253b9c0c2f0136583b.1519293292.git.viresh.kumar@linaro.org
[3] https://lkml.kernel.org/r/6b737a9c285840b4b2036fa51b692ee835664ec8.1519358505.git.viresh.kumar@linaro.org
Viresh Kumar (27):
cpufreq: imx6q: Find max freq from frequency table itself
cpufreq: Don't validate cpufreq table from cpufreq_generic_init()
cpufreq: acpi: Don't validate the frequency table twice
cpufreq: arm_big_little: Don't validate the frequency table twice
cpufreq: blackfin: Don't validate the frequency table twice
cpufreq: brcmstb: Don't validate the frequency table twice
cpufreq: cpufreq-dt: Don't validate the frequency table twice
cpufreq: e_powersaver: Don't validate the frequency table twice
cpufreq: elanfreq: Don't validate the frequency table twice
cpufreq: ia64-acpi: Don't validate the frequency table twice
cpufreq: longhaul: Don't validate the frequency table twice
cpufreq: mediatek: Don't validate the frequency table twice
cpufreq: p4-clockmod: Don't validate the frequency table twice
cpufreq: powernow: Don't validate the frequency table twice
cpufreq: powerenv: Don't validate the frequency table twice
cpufreq: ppc_cbe: Don't validate the frequency table twice
cpufreq: pxa: Don't validate the frequency table twice
cpufreq: qoirq: Don't validate the frequency table twice
cpufreq: s3c24xx: Don't validate the frequency table twice
cpufreq: sc520: Don't validate the frequency table twice
cpufreq: scpi: Don't validate the frequency table twice
cpufreq: sfi: Don't validate the frequency table twice
cpufreq: sh: Don't validate the frequency table twice
cpufreq: sparc: Don't validate the frequency table twice
cpufreq: speedstep: Don't validate the frequency table twice
cpufreq: tegra186: Don't validate the frequency table twice
cpufreq: Drop cpufreq_table_validate_and_show()
Documentation/cpu-freq/core.txt | 12 +++++-------
Documentation/cpu-freq/cpu-drivers.txt | 6 ++----
drivers/cpufreq/acpi-cpufreq.c | 20 +++++++++++---------
drivers/cpufreq/arm_big_little.c | 9 +--------
drivers/cpufreq/blackfin-cpufreq.c | 3 ++-
drivers/cpufreq/brcmstb-avs-cpufreq.c | 6 +-----
drivers/cpufreq/cpufreq-dt.c | 8 +-------
drivers/cpufreq/cpufreq.c | 9 +--------
drivers/cpufreq/e_powersaver.c | 8 +-------
drivers/cpufreq/elanfreq.c | 3 ++-
drivers/cpufreq/freq_table.c | 14 --------------
drivers/cpufreq/ia64-acpi-cpufreq.c | 7 +------
drivers/cpufreq/imx6q-cpufreq.c | 7 ++++---
drivers/cpufreq/longhaul.c | 3 ++-
drivers/cpufreq/mediatek-cpufreq.c | 11 +----------
drivers/cpufreq/p4-clockmod.c | 3 ++-
drivers/cpufreq/powernow-k6.c | 3 ++-
drivers/cpufreq/powernow-k7.c | 3 ++-
drivers/cpufreq/powernow-k8.c | 10 +---------
drivers/cpufreq/powernv-cpufreq.c | 11 +++--------
drivers/cpufreq/ppc_cbe_cpufreq.c | 5 ++---
drivers/cpufreq/pxa2xx-cpufreq.c | 4 ++--
drivers/cpufreq/pxa3xx-cpufreq.c | 4 +++-
drivers/cpufreq/qoriq-cpufreq.c | 13 ++-----------
drivers/cpufreq/s3c24xx-cpufreq.c | 5 +----
drivers/cpufreq/sc520_freq.c | 3 ++-
drivers/cpufreq/scpi-cpufreq.c | 10 +---------
drivers/cpufreq/sfi-cpufreq.c | 3 ++-
drivers/cpufreq/sh-cpufreq.c | 22 ++++++++++++----------
drivers/cpufreq/sparc-us2e-cpufreq.c | 3 ++-
drivers/cpufreq/sparc-us3-cpufreq.c | 3 ++-
drivers/cpufreq/speedstep-centrino.c | 4 ++--
drivers/cpufreq/speedstep-ich.c | 4 +++-
drivers/cpufreq/speedstep-smi.c | 4 +++-
drivers/cpufreq/tegra186-cpufreq.c | 2 +-
include/linux/cpufreq.h | 2 --
36 files changed, 85 insertions(+), 162 deletions(-)
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply
* [PATCH 15/27] cpufreq: powerenv: Don't validate the frequency table twice
From: Viresh Kumar @ 2018-02-26 5:08 UTC (permalink / raw)
To: Rafael Wysocki, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: Viresh Kumar, linux-pm, Vincent Guittot, linuxppc-dev
In-Reply-To: <cover.1519620578.git.viresh.kumar@linaro.org>
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.
Stop validating the frequency table from powerenv driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/powernv-cpufreq.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index 29cdec198657..0591874856d3 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -812,7 +812,7 @@ static int powernv_cpufreq_target_index(struct cpufreq_policy *policy,
static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
- int base, i, ret;
+ int base, i;
struct kernfs_node *kn;
struct global_pstate_info *gpstates;
@@ -848,15 +848,10 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
gpstates->timer.expires = jiffies +
msecs_to_jiffies(GPSTATE_TIMER_INTERVAL);
spin_lock_init(&gpstates->gpstate_lock);
- ret = cpufreq_table_validate_and_show(policy, powernv_freqs);
-
- if (ret < 0) {
- kfree(policy->driver_data);
- return ret;
- }
+ policy->freq_table = powernv_freqs;
policy->fast_switch_possible = true;
- return ret;
+ return 0;
}
static int powernv_cpufreq_cpu_exit(struct cpufreq_policy *policy)
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* Re: [RFC, v0, 1/2] powerpc, drmem: Fix unexpected flag value in ibm, dynamic-memory-v2
From: Michael Ellerman @ 2018-02-26 5:35 UTC (permalink / raw)
To: Bharata B Rao, linuxppc-dev; +Cc: nfont, mwb, Bharata B Rao
In-Reply-To: <1519209387-29767-2-git-send-email-bharata@linux.vnet.ibm.com>
On Wed, 2018-02-21 at 10:36:26 UTC, Bharata B Rao wrote:
> Memory addtion and removal by count and indexed-count methods
> temporarily mark the LMBs that are being added/removed by a special
> flag value DRMEM_LMB_RESERVED. Accessing flags value directly at
> a few places without proper accessor method is causing two unexpected
> side-effects:
>
> - DRMEM_LMB_RESERVED bit is becoming part of the flags word of
> drconf_cell_v2 entries in ibm,dynamic-memory-v2 DT property.
> - This results in extra drconf_cell entries in ibm,dynamic-memory-v2.
> For example if 1G memory is added, it leads to one entry for 3 LMBs
> and 1 separate entry for the last LMB. All the 4 LMBs should be
> defined by one entry here.
>
> Fix this by always accessing the flags by its accessor method
> drmem_lmb_flags().
>
> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/2f7d03e0511991f124455682cc9409
cheers
^ permalink raw reply
* Re: [1/2] powerpc/pseries: Support firmware disable of RFI flush
From: Michael Ellerman @ 2018-02-26 5:35 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
Cc: mikey, linuxram, npiggin, mauricfo, oohall, leitao
In-Reply-To: <20180222132118.26774-1-mpe@ellerman.id.au>
On Thu, 2018-02-22 at 13:21:17 UTC, Michael Ellerman wrote:
> Some versions of firmware will have a setting that can be configured
> to disable the RFI flush, add support for it.
>
> Fixes: 8989d56878a7 ("powerpc/pseries: Query hypervisor for RFI flush settings")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/582605a429e20ae68fd0b041b2e840
cheers
^ permalink raw reply
* Re: [2/2] powerpc/powernv: Support firmware disable of RFI flush
From: Michael Ellerman @ 2018-02-26 5:35 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
Cc: mikey, linuxram, npiggin, mauricfo, oohall, leitao
In-Reply-To: <20180222132118.26774-2-mpe@ellerman.id.au>
On Thu, 2018-02-22 at 13:21:18 UTC, Michael Ellerman wrote:
> Some versions of firmware will have a setting that can be configured
> to disable the RFI flush, add support for it.
>
> Fixes: 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush settings")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/eb0a2d2620ae431c543963c8c7f08f
cheers
^ permalink raw reply
* Re: [PATCH v12 07/11] mm: Add address parameter to arch_validate_prot()
From: Michael Ellerman @ 2018-02-26 5:54 UTC (permalink / raw)
To: Khalid Aziz, akpm, benh, paulus, davem, dave.hansen
Cc: Khalid Aziz, bsingharora, nborisov, aarcange, anthony.yznaga,
mgorman, linuxram, kirill.shutemov, dan.j.williams, jack,
ross.zwisler, gregkh, tglx, mhocko, n-horiguchi, jglisse,
henry.willard, aneesh.kumar, khandual, linuxppc-dev, linux-kernel,
linux-mm, sparclinux, Khalid Aziz
In-Reply-To: <349751cbd54fda6f4a223f941aa71bbfe7be77ce.1519227112.git.khalid.aziz@oracle.com>
Khalid Aziz <khalid.aziz@oracle.com> writes:
> A protection flag may not be valid across entire address space and
> hence arch_validate_prot() might need the address a protection bit is
> being set on to ensure it is a valid protection flag. For example, sparc
> processors support memory corruption detection (as part of ADI feature)
> flag on memory addresses mapped on to physical RAM but not on PFN mapped
> pages or addresses mapped on to devices. This patch adds address to the
> parameters being passed to arch_validate_prot() so protection bits can
> be validated in the relevant context.
>
> Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
> Cc: Khalid Aziz <khalid@gonehiking.org>
> Reviewed-by: Anthony Yznaga <anthony.yznaga@oracle.com>
> ---
> v8:
> - Added addr parameter to powerpc arch_validate_prot() (suggested
> by Michael Ellerman)
> v9:
> - new patch
>
> arch/powerpc/include/asm/mman.h | 4 ++--
> arch/powerpc/kernel/syscalls.c | 2 +-
These changes look fine to me:
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
^ permalink raw reply
* Re: [PATCH 05/21] powerpc: Avoid comparison of unsigned long >= 0 in pfn_valid
From: Christophe LEROY @ 2018-02-26 6:32 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, Paul Mackerras, Jiri Slaby, linuxppc-dev
In-Reply-To: <20180225172236.29650-6-malat@debian.org>
Le 25/02/2018 à 18:22, Mathieu Malaterre a écrit :
> Rewrite comparison since all values compared are of type `unsigned long`.
>
> Fix a warning (treated as error in W=1):
>
> CC arch/powerpc/kernel/irq.o
> In file included from ./include/linux/bug.h:5:0,
> from ./include/linux/cpumask.h:13,
> from ./include/linux/smp.h:13,
> from ./include/linux/kernel_stat.h:5,
> from arch/powerpc/kernel/irq.c:35:
> ./include/linux/dma-mapping.h: In function ‘dma_map_resource’:
> ./arch/powerpc/include/asm/page.h:129:32: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits]
> #define pfn_valid(pfn) ((pfn) >= ARCH_PFN_OFFSET && (pfn) < max_mapnr)
> ^
> Suggested-by: Segher Boessenkool <segher@kernel.crashing.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/include/asm/page.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 8da5d4c1cab2..19dea64e7ed2 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -126,7 +126,8 @@ extern long long virt_phys_offset;
>
> #ifdef CONFIG_FLATMEM
> #define ARCH_PFN_OFFSET ((unsigned long)(MEMORY_START >> PAGE_SHIFT))
> -#define pfn_valid(pfn) ((pfn) >= ARCH_PFN_OFFSET && (pfn) < max_mapnr)
> +#define pfn_valid(pfn) \
> + (((pfn) - ARCH_PFN_OFFSET) < (max_mapnr - ARCH_PFN_OFFSET))
What will happen when ARCH_PFN_OFFSET is not nul and pfn is lower than
ARCH_PFN_OFFSET ?
Christophe
> #endif
>
> #define virt_to_pfn(kaddr) (__pa(kaddr) >> PAGE_SHIFT)
>
^ permalink raw reply
* Re: [PATCH 06/21] powerpc: Avoid comparison of unsigned long >= 0 in __access_ok
From: Christophe LEROY @ 2018-02-26 6:34 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, Paul Mackerras, Jiri Slaby, linuxppc-dev
In-Reply-To: <20180225172236.29650-7-malat@debian.org>
Le 25/02/2018 à 18:22, Mathieu Malaterre a écrit :
> Rewrite check size - 1 <= Y as size < Y since `size` is unsigned value.
> Fix warning (treated as error in W=1):
>
> CC arch/powerpc/kernel/signal_32.o
> In file included from ./include/linux/uaccess.h:14:0,
> from ./include/asm-generic/termios-base.h:8,
> from ./arch/powerpc/include/asm/termios.h:20,
> from ./include/uapi/linux/termios.h:6,
> from ./include/linux/tty.h:7,
> from arch/powerpc/kernel/signal_32.c:36:
> ./include/asm-generic/termios-base.h: In function ‘user_termio_to_kernel_termios’:
> ./arch/powerpc/include/asm/uaccess.h:52:35: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits]
> (((size) == 0) || (((size) - 1) <= ((segment).seg - (addr)))))
> ^
> ./arch/powerpc/include/asm/uaccess.h:58:3: note: in expansion of macro ‘__access_ok’
> __access_ok((__force unsigned long)(addr), (size), get_fs()))
> ^~~~~~~~~~~
> ./arch/powerpc/include/asm/uaccess.h:262:6: note: in expansion of macro ‘access_ok’
> if (access_ok(VERIFY_READ, __gu_addr, (size))) \
> ^~~~~~~~~
> ./arch/powerpc/include/asm/uaccess.h:80:2: note: in expansion of macro ‘__get_user_check’
> __get_user_check((x), (ptr), sizeof(*(ptr)))
> ^~~~~~~~~~~~~~~~
> ./include/asm-generic/termios-base.h:36:6: note: in expansion of macro ‘get_user’
> if (get_user(termios->c_line, &termio->c_line) < 0)
> ^~~~~~~~
> [...]
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/powerpc/include/asm/uaccess.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
> index 51bfeb8777f0..fadc406bd39d 100644
> --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -49,7 +49,7 @@
>
> #define __access_ok(addr, size, segment) \
> (((addr) <= (segment).seg) && \
> - (((size) == 0) || (((size) - 1) <= ((segment).seg - (addr)))))
> + (((size) == 0) || ((size) < ((segment).seg - (addr)))))
IIUC, ((2 - 1) <= 1) is the same as (2 < 1) ?????
Christophe
>
> #endif
>
>
^ permalink raw reply
* Re: [PATCH 06/21] powerpc: Avoid comparison of unsigned long >= 0 in __access_ok
From: Christophe LEROY @ 2018-02-26 6:50 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: linux-kernel, Paul Mackerras, Jiri Slaby, linuxppc-dev
In-Reply-To: <8862c1e1-d161-3410-1b2a-502ad06cef57@c-s.fr>
Le 26/02/2018 à 07:34, Christophe LEROY a écrit :
>
>
> Le 25/02/2018 à 18:22, Mathieu Malaterre a écrit :
>> Rewrite check size - 1 <= Y as size < Y since `size` is unsigned value.
>> Fix warning (treated as error in W=1):
>>
>> CC arch/powerpc/kernel/signal_32.o
>> In file included from ./include/linux/uaccess.h:14:0,
>> from ./include/asm-generic/termios-base.h:8,
>> from ./arch/powerpc/include/asm/termios.h:20,
>> from ./include/uapi/linux/termios.h:6,
>> from ./include/linux/tty.h:7,
>> from arch/powerpc/kernel/signal_32.c:36:
>> ./include/asm-generic/termios-base.h: In function
>> ‘user_termio_to_kernel_termios’:
>> ./arch/powerpc/include/asm/uaccess.h:52:35: error: comparison of
>> unsigned expression >= 0 is always true [-Werror=type-limits]
>> (((size) == 0) || (((size) - 1) <= ((segment).seg - (addr)))))
>> ^
>> ./arch/powerpc/include/asm/uaccess.h:58:3: note: in expansion of macro
>> ‘__access_ok’
>> __access_ok((__force unsigned long)(addr), (size), get_fs()))
>> ^~~~~~~~~~~
>> ./arch/powerpc/include/asm/uaccess.h:262:6: note: in expansion of
>> macro ‘access_ok’
>> if (access_ok(VERIFY_READ, __gu_addr, (size))) \
>> ^~~~~~~~~
>> ./arch/powerpc/include/asm/uaccess.h:80:2: note: in expansion of macro
>> ‘__get_user_check’
>> __get_user_check((x), (ptr), sizeof(*(ptr)))
>> ^~~~~~~~~~~~~~~~
>> ./include/asm-generic/termios-base.h:36:6: note: in expansion of macro
>> ‘get_user’
>> if (get_user(termios->c_line, &termio->c_line) < 0)
>> ^~~~~~~~
>> [...]
>> cc1: all warnings being treated as errors
>>
>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>> ---
>> arch/powerpc/include/asm/uaccess.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/uaccess.h
>> b/arch/powerpc/include/asm/uaccess.h
>> index 51bfeb8777f0..fadc406bd39d 100644
>> --- a/arch/powerpc/include/asm/uaccess.h
>> +++ b/arch/powerpc/include/asm/uaccess.h
>> @@ -49,7 +49,7 @@
>> #define __access_ok(addr, size, segment) \
>> (((addr) <= (segment).seg) && \
>> - (((size) == 0) || (((size) - 1) <= ((segment).seg - (addr)))))
>> + (((size) == 0) || ((size) < ((segment).seg - (addr)))))
>
> IIUC, ((2 - 1) <= 1) is the same as (2 < 1) ?????
Note that I already try to submit a fix for this warning 3 years ago
(https://patchwork.ozlabs.org/patch/418075/) and it was rejected with
the following comment:
Again, I don't think Linux enables this warning. What did you do to
produce this? In any case, it's a bad warning that doesn't take macros
into account, and the answer is not to make the code less clear by hiding
the fact that zero is a special case.
Christophe
>
> Christophe
>
>> #endif
>>
^ permalink raw reply
* Re: [PATCH v12 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled
From: Ram Pai @ 2018-02-26 7:26 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: kbuild test robot, kbuild-all, mpe, mingo, akpm, linuxppc-dev,
linux-mm, x86, linux-arch, linux-kernel, dave.hansen, benh,
paulus, khandual, bsingharora, hbabu, mhocko, bauerman, ebiederm,
corbet, arnd, fweimer, msuchanek
In-Reply-To: <43082fe4-a6e4-2468-0069-4fbc53418c79@linux.vnet.ibm.com>
On Sun, Feb 25, 2018 at 05:27:11PM +0530, Aneesh Kumar K.V wrote:
>
>
> On 02/24/2018 06:35 AM, Ram Pai wrote:
> >On Fri, Feb 23, 2018 at 03:11:45PM +0800, kbuild test robot wrote:
> >>Hi Ram,
> >>
> >>Thank you for the patch! Yet something to improve:
> >>
> >>[auto build test ERROR on linus/master]
> >>[also build test ERROR on v4.16-rc2 next-20180222]
> >>[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> >>
> >> chmod +x ~/bin/make.cross
> >...snip..
> >> # save the attached .config to linux build tree
> >> make.cross ARCH=powerpc
> >>
> >>Note: the linux-review/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743 HEAD c5692bca45543c242ffca15c811923e4c548ed19 builds fine.
> >> It only hurts bisectibility.
> >
> >oops, it broke git-bisect on powerpc :-(
> >The following change will fix it. This should nail it down.
> >
> >diff --git a/arch/powerpc/include/asm/pkeys.h
> >b/arch/powerpc/include/asm/pkeys.h
> >index 0409c80..0b3b669 100644
> >--- a/arch/powerpc/include/asm/pkeys.h
> >+++ b/arch/powerpc/include/asm/pkeys.h
> >@@ -25,6 +25,7 @@
> > # define VM_PKEY_BIT1 VM_HIGH_ARCH_1
> > # define VM_PKEY_BIT2 VM_HIGH_ARCH_2
> > # define VM_PKEY_BIT3 VM_HIGH_ARCH_3
> > # define VM_PKEY_BIT4 VM_HIGH_ARCH_4
> >+#elif !defined(VM_PKEY_BIT4)
> >+# define VM_PKEY_BIT4 VM_HIGH_ARCH_4
> >#endif
> >
>
> Why don't you remove this powerpc definition completely in this
> patch?
That was my thought too, but refrained from sneaking in the changes into
the patch, to maintain the integrity of all the reviewed-by.
Was planning on sending a seperate patch to remove the
powerpc definition entirely.
RP
^ permalink raw reply
* Re: [PATCH 06/21] powerpc: Avoid comparison of unsigned long >= 0 in __access_ok
From: Mathieu Malaterre @ 2018-02-26 7:44 UTC (permalink / raw)
To: Christophe LEROY
Cc: Michael Ellerman, LKML, Paul Mackerras, Jiri Slaby, linuxppc-dev
In-Reply-To: <6cba215c-127e-f3eb-b525-773b6aed0eb7@c-s.fr>
On Mon, Feb 26, 2018 at 7:50 AM, Christophe LEROY
<christophe.leroy@c-s.fr> wrote:
>
>
> Le 26/02/2018 =C3=A0 07:34, Christophe LEROY a =C3=A9crit :
>>
>>
>>
>> Le 25/02/2018 =C3=A0 18:22, Mathieu Malaterre a =C3=A9crit :
>>>
>>> Rewrite check size - 1 <=3D Y as size < Y since `size` is unsigned valu=
e.
>>> Fix warning (treated as error in W=3D1):
>>>
>>> CC arch/powerpc/kernel/signal_32.o
>>> In file included from ./include/linux/uaccess.h:14:0,
>>> from ./include/asm-generic/termios-base.h:8,
>>> from ./arch/powerpc/include/asm/termios.h:20,
>>> from ./include/uapi/linux/termios.h:6,
>>> from ./include/linux/tty.h:7,
>>> from arch/powerpc/kernel/signal_32.c:36:
>>> ./include/asm-generic/termios-base.h: In function
>>> =E2=80=98user_termio_to_kernel_termios=E2=80=99:
>>> ./arch/powerpc/include/asm/uaccess.h:52:35: error: comparison of unsign=
ed
>>> expression >=3D 0 is always true [-Werror=3Dtype-limits]
>>> (((size) =3D=3D 0) || (((size) - 1) <=3D ((segment).seg - (addr))))=
)
>>> ^
>>> ./arch/powerpc/include/asm/uaccess.h:58:3: note: in expansion of macro
>>> =E2=80=98__access_ok=E2=80=99
>>> __access_ok((__force unsigned long)(addr), (size), get_fs()))
>>> ^~~~~~~~~~~
>>> ./arch/powerpc/include/asm/uaccess.h:262:6: note: in expansion of macro
>>> =E2=80=98access_ok=E2=80=99
>>> if (access_ok(VERIFY_READ, __gu_addr, (size))) \
>>> ^~~~~~~~~
>>> ./arch/powerpc/include/asm/uaccess.h:80:2: note: in expansion of macro
>>> =E2=80=98__get_user_check=E2=80=99
>>> __get_user_check((x), (ptr), sizeof(*(ptr)))
>>> ^~~~~~~~~~~~~~~~
>>> ./include/asm-generic/termios-base.h:36:6: note: in expansion of macro
>>> =E2=80=98get_user=E2=80=99
>>> if (get_user(termios->c_line, &termio->c_line) < 0)
>>> ^~~~~~~~
>>> [...]
>>> cc1: all warnings being treated as errors
>>>
>>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>>> ---
>>> arch/powerpc/include/asm/uaccess.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/uaccess.h
>>> b/arch/powerpc/include/asm/uaccess.h
>>> index 51bfeb8777f0..fadc406bd39d 100644
>>> --- a/arch/powerpc/include/asm/uaccess.h
>>> +++ b/arch/powerpc/include/asm/uaccess.h
>>> @@ -49,7 +49,7 @@
>>> #define __access_ok(addr, size, segment) \
>>> (((addr) <=3D (segment).seg) && \
>>> - (((size) =3D=3D 0) || (((size) - 1) <=3D ((segment).seg - (addr))=
)))
>>> + (((size) =3D=3D 0) || ((size) < ((segment).seg - (addr)))))
>>
>>
>> IIUC, ((2 - 1) <=3D 1) is the same as (2 < 1) ?????
>
The whole series was pretty mediocre, but this one was actually pretty
destructive. Thanks for catching this.
>
> Note that I already try to submit a fix for this warning 3 years ago
> (https://patchwork.ozlabs.org/patch/418075/) and it was rejected with the
> following comment:
>
> Again, I don't think Linux enables this warning. What did you do to
> produce this? In any case, it's a bad warning that doesn't take macros
> into account, and the answer is not to make the code less clear by hiding
> the fact that zero is a special case.
Right. I'll try to see how to make W=3D1 run without error with an
alternate solution.
> Christophe
>
>
>>
>> Christophe
>>
>>> #endif
>>>
>
^ permalink raw reply
* Re: [PATCH 05/21] powerpc: Avoid comparison of unsigned long >= 0 in pfn_valid
From: Mathieu Malaterre @ 2018-02-26 7:49 UTC (permalink / raw)
To: Christophe LEROY
Cc: Michael Ellerman, LKML, Paul Mackerras, Jiri Slaby, linuxppc-dev
In-Reply-To: <55d52f37-c24d-c2da-43c6-73a55403d3b6@c-s.fr>
On Mon, Feb 26, 2018 at 7:32 AM, Christophe LEROY
<christophe.leroy@c-s.fr> wrote:
>
>
> Le 25/02/2018 =C3=A0 18:22, Mathieu Malaterre a =C3=A9crit :
>>
>> Rewrite comparison since all values compared are of type `unsigned long`=
.
>>
>> Fix a warning (treated as error in W=3D1):
>>
>> CC arch/powerpc/kernel/irq.o
>> In file included from ./include/linux/bug.h:5:0,
>> from ./include/linux/cpumask.h:13,
>> from ./include/linux/smp.h:13,
>> from ./include/linux/kernel_stat.h:5,
>> from arch/powerpc/kernel/irq.c:35:
>> ./include/linux/dma-mapping.h: In function =E2=80=98dma_map_resource=E2=
=80=99:
>> ./arch/powerpc/include/asm/page.h:129:32: error: comparison of unsigned
>> expression >=3D 0 is always true [-Werror=3Dtype-limits]
>> #define pfn_valid(pfn) ((pfn) >=3D ARCH_PFN_OFFSET && (pfn) < max_map=
nr)
>> ^
>> Suggested-by: Segher Boessenkool <segher@kernel.crashing.org>
>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>> ---
>> arch/powerpc/include/asm/page.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/page.h
>> b/arch/powerpc/include/asm/page.h
>> index 8da5d4c1cab2..19dea64e7ed2 100644
>> --- a/arch/powerpc/include/asm/page.h
>> +++ b/arch/powerpc/include/asm/page.h
>> @@ -126,7 +126,8 @@ extern long long virt_phys_offset;
>> #ifdef CONFIG_FLATMEM
>> #define ARCH_PFN_OFFSET ((unsigned long)(MEMORY_START >>
>> PAGE_SHIFT))
>> -#define pfn_valid(pfn) ((pfn) >=3D ARCH_PFN_OFFSET && (pfn) <
>> max_mapnr)
>> +#define pfn_valid(pfn) \
>> + (((pfn) - ARCH_PFN_OFFSET) < (max_mapnr -
>> ARCH_PFN_OFFSET))
>
>
> What will happen when ARCH_PFN_OFFSET is not nul and pfn is lower than
> ARCH_PFN_OFFSET ?
I assumed that normal unsigned integers modulo would make the test
fail. But for some particular value of max_mapnr the two are indeed
not equivalent.
> Christophe
>
>
>> #endif
>> #define virt_to_pfn(kaddr) (__pa(kaddr) >> PAGE_SHIFT)
>>
>
^ permalink raw reply
* Re: [PATCH stable v4.4] powerpc/64s: Fix RFI flush dependency on HARDLOCKUP_DETECTOR
From: Greg KH @ 2018-02-26 8:43 UTC (permalink / raw)
To: Michael Ellerman; +Cc: stable, linuxppc-dev, bernhard.kaindl
In-Reply-To: <20180226021317.28767-1-mpe@ellerman.id.au>
On Mon, Feb 26, 2018 at 01:13:17PM +1100, Michael Ellerman wrote:
> The backport of commit aa8a5e0062ac ("powerpc/64s: Add support for RFI
> flush of L1-D cache"), incorrectly placed the new RFI flush code
> inside an existing #ifdef CONFIG_HARDLOCKUP_DETECTOR block.
>
> This has the obvious effect of requiring HARDLOCKUP_DETECTOR to be
> enabled in order for RFI flush to be enabled, which is a bug.
>
> Fix it by moving the #endif up to where it belongs.
>
> Fixes: c3892946315e ("powerpc/64s: Add support for RFI flush of L1-D cache")
> Reported-by: Bernhard Kaindl <bernhard.kaindl@thalesgroup.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/kernel/setup_64.c | 2 +-
Thanks, now queued up.
greg k-h
^ permalink raw reply
* Re: [PATCH 05/21] powerpc: Avoid comparison of unsigned long >= 0 in pfn_valid
From: Segher Boessenkool @ 2018-02-26 8:46 UTC (permalink / raw)
To: Christophe LEROY
Cc: Mathieu Malaterre, Michael Ellerman, linuxppc-dev, Paul Mackerras,
linux-kernel, Jiri Slaby
In-Reply-To: <55d52f37-c24d-c2da-43c6-73a55403d3b6@c-s.fr>
On Mon, Feb 26, 2018 at 07:32:03AM +0100, Christophe LEROY wrote:
> Le 25/02/2018 à 18:22, Mathieu Malaterre a écrit :
> >-#define pfn_valid(pfn) ((pfn) >= ARCH_PFN_OFFSET && (pfn) <
> >max_mapnr)
> >+#define pfn_valid(pfn) \
> >+ (((pfn) - ARCH_PFN_OFFSET) < (max_mapnr - ARCH_PFN_OFFSET))
>
> What will happen when ARCH_PFN_OFFSET is not nul and pfn is lower than
> ARCH_PFN_OFFSET ?
It will work fine.
Say you are asking for a <= x < b so (in actual integers, no overflow)
that is 0 <= x-a < b-a and you also assume x-a overflows, so that we
are actually comparing x-a+M < b-a with M = 2**32 or such (the maximum
value in the unsigned integer type plus one). This comparison is
obviously always false.
(It also works if b < a btw).
Segher
^ permalink raw reply
* Re: [PATCH] macintosh/via-pmu68k: Initialize PMU driver with setup_arch and arch_initcall
From: Geert Uytterhoeven @ 2018-02-26 9:46 UTC (permalink / raw)
To: Finn Thain
Cc: Benjamin Herrenschmidt, linux-m68k, Linux Kernel Mailing List,
linuxppc-dev
In-Reply-To: <20180127235140.EA71C296D4@kvm5.telegraphics.com.au>
On Sun, Jan 28, 2018 at 12:51 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
> The PMU watchdog will power down the system if the kernel is slow
> to start up, e.g. due to unpacking a large initrd. The powerpc
> version of this driver (via-pmu.c) has a solution for the same
> problem. It uses this call sequence:
>
> setup_arch
> find_via_pmu
> init_pmu
> ...
> arch_initcall
> via_pmu_start
>
> Bring via-pmu68k.c into line with via-pmu.c to fix this issue.
>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Tested-by: Stan Johnson <userm57@yahoo.com>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Thanks, applied and queue for v4.17.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()
From: Rafael J. Wysocki @ 2018-02-26 9:48 UTC (permalink / raw)
To: Shilpasri G Bhat
Cc: Viresh Kumar, Rafael J. Wysocki, Linux PM,
Linux Kernel Mailing List, linuxppc-dev, Michael Ellerman
In-Reply-To: <14e2fe70-7628-4377-664d-3c4b0071e08d@linux.vnet.ibm.com>
On Mon, Feb 12, 2018 at 11:33 AM, Shilpasri G Bhat
<shilpa.bhat@linux.vnet.ibm.com> wrote:
> Hi,
>
> On 02/12/2018 03:59 PM, Viresh Kumar wrote:
>> On 12-02-18, 15:51, Shilpasri G Bhat wrote:
>>> This patch fixes the below Coverity warning:
>>>
>>> *** CID 182816: Memory - illegal accesses (NEGATIVE_RETURNS)
>>> /drivers/cpufreq/powernv-cpufreq.c: 1008 in powernv_fast_switch()
>>> 1002 unsigned int target_freq)
>>> 1003 {
>>> 1004 int index;
>>> 1005 struct powernv_smp_call_data freq_data;
>>> 1006
>>> 1007 index = cpufreq_table_find_index_dl(policy, target_freq);
>>>>>> CID 182816: Memory - illegal accesses (NEGATIVE_RETURNS)
>>>>>> Using variable "index" as an index to array "powernv_freqs".
>>> 1008 freq_data.pstate_id = powernv_freqs[index].driver_data;
>>> 1009 freq_data.gpstate_id = powernv_freqs[index].driver_data;
>>> 1010 set_pstate(&freq_data);
>>> 1011
>>> 1012 return powernv_freqs[index].frequency;
>>> 1013 }
>>>
>>> Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
>>> ---
>>> drivers/cpufreq/powernv-cpufreq.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
>>> index 29cdec1..69edfe9 100644
>>> --- a/drivers/cpufreq/powernv-cpufreq.c
>>> +++ b/drivers/cpufreq/powernv-cpufreq.c
>>> @@ -1005,6 +1005,9 @@ static unsigned int powernv_fast_switch(struct cpufreq_policy *policy,
>>> struct powernv_smp_call_data freq_data;
>>>
>>> index = cpufreq_table_find_index_dl(policy, target_freq);
>>> + if (unlikely(index < 0))
>>> + index = get_nominal_index();
>>> +
>>
>> AFAICT, you will get -1 here only if the freq table had no valid
>> frequencies (or the freq table is empty). Why would that happen ?
>
> I agree too. There is no way we can get -1 with initialized cpu frequency table.
> We don't initialize powernv-cpufreq if we don't have valid CPU frequency
> entries. Is there any other way to suppress the Coverity tool warning apart from
> ignoring it?
In principle you could use BUG_ON(something_impossible) to annotate
that kind of thing to the static analysis tools, but that would
generate extra code.
^ permalink raw reply
* Linux 4.16: Reported regressions as of Monday, 2018-02-26 (Was: Linux 4.16-rc3)
From: Thorsten Leemhuis @ 2018-02-26 10:25 UTC (permalink / raw)
To: Linus Torvalds, Linux Kernel Mailing List; +Cc: linuxppc-dev, Jonathan Corbet
In-Reply-To: <CA+55aFxk5KBxL9DvRtBivP3hKT-aOAzvSA_B47L1+y0P2GLe_A@mail.gmail.com>
On 26.02.2018 04:05, Linus Torvalds wrote:
> We're on the normal schedule for 4.16 and everything still looks very regular.
Hi! Find below my second regression report for Linux 4.16. It lists 8
regressions I'm currently aware of.
To anyone reading this: Are you aware of any other regressions that got
introduced this development cycle? Then please let me know by mail (a
simple bounce or forward to the email address is enough!).
For details see http://bit.ly/lnxregtrackid And please tell me if there
is anything in the report that shouldn't be there.
Ciao, Thorsten
== Current regressions ==
Debian kernel package tool make-kpkg stalls indefinitely during kernel
build due to commit "kconfig: remove check_stdin()"
Status: stalled after some discussions; seems nobody really cares deeply?
Note: From the discussion: "Shouldn't be a problem to back this one out
either if it turns out to cause massive amounts of pain in practice I
guess, even if it's the Debian tools doing something weird."
Reported: 2018-02-12
https://marc.info/?l=linux-kernel&m=151846414807219
Cause: d2a04648a5dbc3d1d043b35257364f0197d4d868
Linux-Regression-ID: 2fd778
Dell R640 does not boot due to SCSI/SATA failure
Reported: 2018-02-22
https://marc.info/?l=linux-kernel&m=151931128006031
Cause: 84676c1f21e8
Linux-Regression-ID: 15a115
On Nokia N900:/dev/input/event6 aka AV Jack support disappeared
Status: quite new
Reported: 2018-02-24
https://marc.info/?l=linux-omap&m=151950886524308&w=2
Cause: 14e3e295b2b9
Linux-Regression-ID: 4b650f
SD card reader stopped working
Status: quite new
Reported: 2018-02-24
https://bugzilla.kernel.org/show_bug.cgi?id=198917
Linux-Regression-ID: 9adeaf
[mm, mlock, vmscan] 9c4e6b1a70: stress-ng.hdd.ops_per_sec -7.9% regression
Status: WIP
Note: performance regression found by lkp-robot
Reported: 2018-02-25
https://marc.info/?l=linux-kernel&m=151956997301994
Cause: 9c4e6b1a7027f102990c0395296015a812525f4d
aim7.jobs-per-min -18.0% regression
Status: WIP; bisection result is doubted, but was verified
Note: performance regression found by lkp-robot
Reported: 2018-02-25
https://marc.info/?l=linux-kernel&m=151957120702272&w=2
Cause: c0cef30e4ff0dc025f4a1660b8f0ba43ed58426e
Interrupt storm after suspend causes one busy kworker
Status: quite new
Reported: 2018-02-25
https://bugzilla.kernel.org/show_bug.cgi?id=198929
Linux-Regression-ID: 41c451
== Fix heading mainline ==
Dell XPS 13 9360 keyboard no longer works
Status: Fix in the platform tree from what I've heard
Reported: 2018-02-22
https://marc.info/?l=linux-kernel&m=151927645427980
Cause: 30323fb6d552c41997baca5292bf7001366cab57
== Fixed since last report ==
DM Regression: read() returns data when it shouldn't
Status: Was fixed already when last report was compiled
Reported: 2018-02-14
https://marc.info/?l=linux-kernel&m=151861337518109&w=2
Cause: 18a25da84354c6bb655320de6072c00eda6eb602
Linux-Regression-ID: 9e195f
== Fixed before it was properly added to the report ==
kconfig.h: Include compiler types to avoid missed struct attributes
https://git.kernel.org/torvalds/c/28128c61e08e
i2c-designware: sound and s2ram broken on Broadwell-U system since
commit ca382f5b38f367b6 (add i2c gpio recovery option)
https://git.kernel.org/torvalds/c/d1fa74520dcd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox