Le 17/10/2019 à 09:36, Andrew Donnellan a écrit :
On 10/9/19 7:16 pm, Christophe Leroy wrote:
+#if defined(CONFIG_VMAP_STACK) && CONFIG_THREAD_SHIFT < PAGE_SHIFT
+#define THREAD_SHIFT PAGE_SHIFT
+#else
#define THREAD_SHIFT CONFIG_THREAD_SHIFT
+#endif
#define THREAD_SIZE
On 17-10-19, 21:55, John Hubbard wrote:
> The following build warning occurred on powerpc 64-bit builds:
>
> drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
> drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040
> bytes is larger than 1024 bytes [-Wframe-larg
On Fri, Oct 18, 2019 at 10:56:57AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> WARNING: 2 bad relocations
> c1998a48 R_PPC64_ADDR64_binary__btf_vmlinux_bin_start
> c00
The following build warning occurred on powerpc 64-bit builds:
drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040 bytes
is larger than 1024 bytes [-Wframe-larger-than=]
This is due to putting 1024 bytes on th
On 17-10-19, 21:41, John Hubbard wrote:
> On 10/17/19 9:38 PM, Viresh Kumar wrote:
> > On 17-10-19, 21:34, John Hubbard wrote:
> >> On 10/17/19 9:27 PM, Viresh Kumar wrote:
> >>> On 17-10-19, 17:04, John Hubbard wrote:
> The following build warning occurred on powerpc 64-bit builds:
>
> >
On 10/17/19 9:38 PM, Viresh Kumar wrote:
> On 17-10-19, 21:34, John Hubbard wrote:
>> On 10/17/19 9:27 PM, Viresh Kumar wrote:
>>> On 17-10-19, 17:04, John Hubbard wrote:
The following build warning occurred on powerpc 64-bit builds:
drivers/cpufreq/powernv-cpufreq.c: In function 'in
On 17-10-19, 21:34, John Hubbard wrote:
> On 10/17/19 9:27 PM, Viresh Kumar wrote:
> > On 17-10-19, 17:04, John Hubbard wrote:
> >> The following build warning occurred on powerpc 64-bit builds:
> >>
> >> drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
> >> drivers/cpufreq/powernv-
On 10/17/19 9:27 PM, Viresh Kumar wrote:
> On 17-10-19, 17:04, John Hubbard wrote:
>> The following build warning occurred on powerpc 64-bit builds:
>>
>> drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
>> drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040
>
On 17-10-19, 17:04, John Hubbard wrote:
> The following build warning occurred on powerpc 64-bit builds:
>
> drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
> drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040
> bytes is larger than 1024 bytes [-Wframe-larg
There are pr_warning and pr_warng to show WARNING level message,
most of the code using pr_warn, number based on next-20191017,
pr_warn: 5206 pr_warning: 546 (tools: 399, others: 147)
Joe Perches posted a patch, commit f2c2cbcc35d4 ("powerpc: Use
pr_warn instead of pr_warning")
As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of
pr_warning"), removing pr_warning so all logging messages use a
consistent _warn style. Let's do it.
Cc: Benjamin Herrenschmidt
Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Sergey Senozhatsky
Signed-off-by: Kefeng Wang
---
driv
On Wed, Sep 25, 2019 at 10:36:43AM +0530, Bharata B Rao wrote:
> Manage migration of pages betwen normal and secure memory of secure
> guest by implementing H_SVM_PAGE_IN and H_SVM_PAGE_OUT hcalls.
>
> H_SVM_PAGE_IN: Move the content of a normal page to secure page
> H_SVM_PAGE_OUT: Move the conte
The following build warning occurred on powerpc 64-bit builds:
drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040 bytes
is larger than 1024 bytes [-Wframe-larger-than=]
This is due to putting 1024 bytes on th
Hi all,
After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
WARNING: 2 bad relocations
c1998a48 R_PPC64_ADDR64_binary__btf_vmlinux_bin_start
c1998a50 R_PPC64_ADDR64_binary__btf_vmlinux_bin_end
Introduced by commit
https://bugzilla.kernel.org/show_bug.cgi?id=201723
--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 285535
--> https://bugzilla.kernel.org/attachment.cgi?id=285535&action=edit
bisect.log
Final bisect commit.
It's not a bug, it's a feature. :(
# git bisect bad | tee
Hello Shengjiu,
On Thu, Oct 17, 2019 at 02:21:08PM +0800, Shengjiu Wang wrote:
> For P2P output, the output divider should align with the output sample
I think we should avoid "P2P" (or "M2M") keyword in the mainline
code as we know M2M will never get merged while somebody working
with the mainli
On 10/15/2019 07:29 AM, Michael Ellerman wrote:
Nayna Jain writes:
PowerNV systems uses kernel based bootloader, thus its secure boot
implementation uses kernel IMA security subsystem to verify the kernel
before kexec. Since the verification policy might differ based on the
secure boot mode
Nathan Lynch writes:
> Srikar Dronamraju writes:
>> Abdul reported a warning on a shared lpar.
>> "WARNING: workqueue cpumask: online intersect > possible intersect".
>> This is because per node workqueue possible mask is set very early in the
>> boot process even before the system was querying
> On Oct 17, 2019, at 12:29 PM, Oliver O'Halloran wrote:
>
>
> The ABI (v1 and v2) uses r2 as a pointer to the "table of contents"
> which is used to look up the addresses of global symbols. TOCs are
> specific to the current unit of execution and the vmlinux and each
> module has its own TOC
On Wed, Oct 16, 2019 at 06:46:09PM +0800, YueHaibing wrote:
> External E-Mail
>
>
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing
Acked-by: Ludovic Desroches
Thanks
> ---
> drivers/char/hw_random/atmel-rng.c
On the 8xx, signals are generated after executing the instruction.
So no need to manually single-step on 8xx. Also, 8xx __set_dabr()
currently ignores length and hardcodes the length to 8 bytes. So
all unaligned and 512 byte testcase will fail on 8xx. Ignore those
testcases on 8xx.
Signed-off-by:
So far we used to ignore exception if dar points outside of user
specified range. But now we are ignoring it only if actual load/
store range does not overlap with user specified range. Include
selftests for the same:
# ./tools/testing/selftests/powerpc/ptrace/perf-hwbreak
...
TESTED: No ove
ptrace-hwbreak.c selftest is logically broken. On powerpc, when
watchpoint is created with ptrace, signals are generated before
executing the instruction and user has to manually singlestep
the instruction with watchpoint disabled, which selftest never
does and thus it keeps on getting the signal a
On Powerpc, watchpoint match range is double-word granular. On a
watchpoint hit, DAR is set to the first byte of overlap between
actual access and watched range. And thus it's quite possible that
DAR does not point inside user specified range. Ex, say user creates
a watchpoint with address range 0x
ptrace_set_debugreg() does not consider new length while overwriting
the watchpoint. Fix that. ppc_set_hwdebug() aligns watchpoint address
to doubleword boundary but does not change the length. If address range
is crossing doubleword boundary and length is less then 8, we will loose
samples from se
Watchpoint match range is always doubleword(8 bytes) aligned on
powerpc. If the given range is crossing doubleword boundary, we
need to increase the length such that next doubleword also get
covered. Ex,
address len = 6 bytes
|=.
|v--|--v-
We are hadrcoding length everywhere in the watchpoint code.
Introduce macros for the length and use them.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hw_breakpoint.h | 3 +++
arch/powerpc/kernel/hw_breakpoint.c | 4 ++--
arch/powerpc/kernel/ptrace.c | 6 +++---
arc
v5: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198069.html
v5->v6:
- patch 6/7: mpe reported that the perf-hwbreak.c doesn't compile with older
gcc:
perf-hwbreak.c:182:2: error: dereferencing type-punned pointer will
break strict-aliasing rules [-Werror=strict
From: "Desnes A. Nunes do Rosario"
commit 5b216ea1c40cf06eead15054c70e238c9bd4729e upstream.
Newer versions of GCC (>= 9) demand that the size of the string to be
copied must be explicitly smaller than the size of the destination.
Thus, the NULL char has to be taken into account on strncpy.
Thi
From: "Aneesh Kumar K.V"
commit 93cad5f789951eaa27c3392b15294b4e51253944 upstream.
Cc: sta...@vger.kernel.org # v4.14
Signed-off-by: Aneesh Kumar K.V
[mpe: Some minor fixes to make it build]
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/20190924035254.24612-4-aneesh.ku...@li
From: "Aneesh Kumar K.V"
commit 09ce98cacd51fcd0fa0af2f79d1e1d3192f4cbb0 upstream.
Rename the #define to indicate this is related to store vs tlbie
ordering issue. In the next patch, we will be adding another feature
flag that is used to handles ERAT flush vs tlbie ordering issue.
Cc: sta...@vg
From: "Aneesh Kumar K.V"
commit 677733e296b5c7a37c47da391fc70a43dc40bd67 upstream.
The store ordering vs tlbie issue mentioned in commit
a5d4b5891c2f ("powerpc/mm: Fixup tlbie vs store ordering issue on
POWER9") is fixed for Nimbus 2.3 and Cumulus 1.3 revisions. We don't
need to apply the fixup
From: "Aneesh Kumar K.V"
commit 047e6575aec71d75b765c22111820c4776cd1c43 upstream.
On POWER9, under some circumstances, a broadcast TLB invalidation will
fail to invalidate the ERAT cache on some threads when there are
parallel mtpidr/mtlpidr happening on other threads of the same core.
This can
From: "Aneesh Kumar K.V"
commit a5d4b5891c2f1f865a2def1eb0030f534e77ff86 upstream.
On POWER9, under some circumstances, a broadcast TLB invalidation
might complete before all previous stores have drained, potentially
allowing stale stores from becoming visible after the invalidation.
This works
On 10/9/19 7:16 pm, Christophe Leroy wrote:
+#if defined(CONFIG_VMAP_STACK) && CONFIG_THREAD_SHIFT < PAGE_SHIFT
+#define THREAD_SHIFT PAGE_SHIFT
+#else
#define THREAD_SHIFT CONFIG_THREAD_SHIFT
+#endif
#define THREAD_SIZE (1 << THREAD_SHIFT)
Looking at 64-bit b
35 matches
Mail list logo
