On PPC64, the TOC pointer needs to be saved and restored.
Suggested-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
v9: New.
I'm not sure this is really needed, I can't see the VDSO C code doing
anything with r2, at least on ppc64_defconfig.
So I let you decide whether you take it or
This is the tenth version of a series to switch powerpc VDSO to
generic C implementation.
Changes since v10 are:
- Added a comment explaining the reason for the double stack frame
- Moved back .cfi_register lr next to mflr
Main changes since v9 are:
- Dropped the patches which put the VDSO datapa
cpu_relax() need to be in asm/vdso/processor.h to be used by
the C VDSO generic library.
Move it there.
Signed-off-by: Christophe Leroy
---
v9: Forgot to remove cpu_relax() from processor.h in v8
---
arch/powerpc/include/asm/processor.h | 13 ++---
arch/powerpc/include/asm/vdso/pro
Provides __kernel_clock_gettime64() on vdso32. This is the
64 bits version of __kernel_clock_gettime() which is
y2038 compliant.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/vdso32/gettimeofday.S | 9 +
arch/powerpc/kernel/vdso32/vdso32.lds.S| 1 +
arch/powerpc/kernel/vds
For VDSO32 on PPC64, we create a fake 32 bits config, on the same
principle as MIPS architecture, in order to get the correct parts of
the different asm header files.
With the C VDSO, the performance is slightly lower, but it is worth
it as it will ease maintenance and evolution, and also brings c
Prepare for switching VDSO to generic C implementation in following
patch. Here, we:
- Prepare the helpers to call the C VDSO functions
- Prepare the required callbacks for the C VDSO functions
- Prepare the clocksource.h files to define VDSO_ARCH_CLOCKMODES
- Add the C trampolines to the generic C
On 08/02/20 at 07:35pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The only user of memblock_mem_size() was x86 setup code, it is gone now and
> memblock_mem_size() funciton can be removed.
>
> Signed-off-by: Mike Rapoport
> ---
> include/linux/memblock.h | 1 -
> mm/memblock.c
On 08/02/20 at 07:36pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Iteration over memblock.reserved with for_each_reserved_mem_region() used
> __next_reserved_mem_region() that implemented a subset of
> __next_mem_region().
>
> Use __for_each_mem_range() and, essentially, __next_mem_region()
All the LMB from the same set of ibm,dynamic-memory-v2 property are
sharing the same NUMA node. Don't compute that node for each one.
Tested on a system with 1022 LMBs spread on 4 NUMA nodes, only 4 calls to
lmb_set_nid() have been made instead of 1022.
This should prevent some soft lockups when
On 08/02/20 at 07:36pm, Mike Rapoport wrote:
> From: Mike Rapoport
>
> for_each_memblock() is used to iterate over memblock.memory in
> a few places that use data from memblock_region rather than the memory
> ranges.
>
> Introduce separate for_each_mem_region() and for_each_reserved_mem_region()
From: Colin Ian King
There are spelling mistakes in DBG messages. Fix them.
Signed-off-by: Colin Ian King
---
drivers/macintosh/windfarm_lm75_sensor.c | 2 +-
drivers/macintosh/windfarm_lm87_sensor.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/windf
'--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Laurent-Dufour/powerpc-drmem-Don-t-compute-the-NUMA-node-for-each-LMB/20200805-173213
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
confi
On Sun, Aug 02, 2020 at 07:36:01PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> for_each_memblock() is used to iterate over memblock.memory in
> a few places that use data from memblock_region rather than the memory
> ranges.
>
> Introduce separate for_each_mem_region() and for_each_res
On Sun, Aug 02, 2020 at 07:35:56PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> There are several occurrences of the following pattern:
>
> for_each_memblock(memory, reg) {
> start = __pfn_to_phys(memblock_region_memory_base_pfn(reg);
> end = __pfn_to_p
note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Laurent-Dufour/powerpc-drmem-Don-t-compute-the-NUMA-node-for-each-LMB/20200805-173213
base: https://git.kernel.org/pub
Balamuruhan S wrote:
add emulate_step() changes to support vsx vector paired storage
access instructions that provides octword operands loads/stores
between storage and set of 64 Vector Scalar Registers (VSRs).
This should be squashed in with the previous patch. Otherwise, emulation
of these i
From: Colin Ian King
There is a spelling mistake in a literal string. Fix it.
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
On 27-07-20, 15:34, Gustavo A. R. Silva wrote:
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 2c508ee672b9..9b69716172a4 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -1061,16 +1061,16 @@ static bool _start(struct pl330_thread *thrd)
>
> if (
All the LMB from the same set of ibm,dynamic-memory-v2 property are
sharing the same NUMA node. Don't compute that node for each one.
Tested on a system with 1022 LMBs spread on 4 NUMA nodes, only 4 calls to
lmb_set_nid() have been made instead of 1022.
This should prevent some soft lockups when
Hi!
On Wed, Aug 05, 2020 at 04:24:16PM +1000, Michael Ellerman wrote:
> Christophe Leroy writes:
> > Indeed, 32-bit doesn't have a redzone, so I believe it needs a stack
> > frame whenever it has anything to same.
>
> Yeah OK that would explain it.
>
> > Here is what I have in libc.so:
> >
> >
Hi!
On Wed, Aug 05, 2020 at 07:09:23AM +, Christophe Leroy wrote:
> Provide vdso_shift_ns(), as the generic x >> s gives the following
> bad result:
>
> 18: 35 25 ff e0 addic. r9,r5,-32
> 1c: 41 80 00 10 blt 2c
> 20: 7c 64 4c 30 srw r4,r3,r9
> 24: 38 60 00 00
On BOOK3S_32, when we have modules and strict kernel RWX, modules
are not in vmalloc space but in a dedicated segment that is
below PAGE_OFFSET.
So KASAN_SHADOW_START must take it into account.
MODULES_VADDR can't be used because it is not defined yet
in kasan.h
Fixes: 6ca055322da8 ("powerpc/32s
When MODULES_VADDR is defined, is_module_segment() shall check the
address against it instead of checking agains VMALLOC_START.
Fixes: 6ca055322da8 ("powerpc/32s: Use dedicated segment for modules with
STRICT_KERNEL_RWX")
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/book3s32/mmu.c | 7 ++
Le 22/07/2020 à 04:24, Michael Ellerman a écrit :
The assembler says:
arch/powerpc/kernel/head_40x.S:623: Warning: invalid register expression
I get exactly the same with head_32.S, for the exact same reason.
Christophe
It's objecting to the use of r0 as the RA argument. That's becaus
On 8/5/20 6:19 AM, Vinod Koul wrote:
> On 27-07-20, 15:34, Gustavo A. R. Silva wrote:
>
>> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
>> index 2c508ee672b9..9b69716172a4 100644
>> --- a/drivers/dma/pl330.c
>> +++ b/drivers/dma/pl330.c
>> @@ -1061,16 +1061,16 @@ static bool _start(struc
Hi,
On 08/05/2020 02:03 PM, Segher Boessenkool wrote:
Hi!
On Wed, Aug 05, 2020 at 07:09:23AM +, Christophe Leroy wrote:
+/*
+ * powerpc specific delta calculation.
+ *
+ * This variant removes the masking of the subtraction because the
+ * clocksource mask of all VDSO capable clocksources
Hi Again,
Le 05/08/2020 à 16:03, Segher Boessenkool a écrit :
Hi!
On Wed, Aug 05, 2020 at 07:09:23AM +, Christophe Leroy wrote:
+/*
+ * The macros sets two stack frames, one for the caller and one for the callee
+ * because there are no requirement for the caller to set a stack frame when
On Sun, Aug 2, 2020 at 6:41 PM Mike Rapoport wrote:
>
> .clang-format | 3 ++-
The .clang-format bit:
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Sun, Aug 2, 2020 at 6:40 PM Mike Rapoport wrote:
>
> .clang-format| 2 +-
The .clang-format bit:
Acked-by: Miguel Ojeda
Cheers,
Miguel
Travis reported successful compilation with mpe/merge:
https://travis-ci.org/github/LeoBras/linux-ppc/builds/715028857
Hi!
On Wed, Aug 05, 2020 at 04:40:16PM +, Christophe Leroy wrote:
> >It cannot optimise it because it does not know shift < 32. The code
> >below is incorrect for shift equal to 32, fwiw.
>
> Is there a way to tell it ?
Sure, for example the &31 should work (but it doesn't, with the GCC
ver
Hi!
On Wed, Aug 05, 2020 at 06:51:44PM +0200, Christophe Leroy wrote:
> Le 05/08/2020 à 16:03, Segher Boessenkool a écrit :
> >On Wed, Aug 05, 2020 at 07:09:23AM +, Christophe Leroy wrote:
> >>+/*
> >>+ * The macros sets two stack frames, one for the caller and one for the
> >>callee
> >>+ *
On Wed, Aug 05, 2020 at 11:43:37AM +0100, Colin King wrote:
> From: Colin Ian King
>
> There are spelling mistakes in DBG messages. Fix them.
>
> Signed-off-by: Colin Ian King
These comments can go entirely. i2c_detach is long history. And for
remove, we have debugging output in the driver cor
Quoting Michael Roth (2020-08-04 23:37:32)
> Quoting Michael Ellerman (2020-08-04 22:07:08)
> > Greg Kurz writes:
> > > On Tue, 04 Aug 2020 23:35:10 +1000
> > > Michael Ellerman wrote:
> > >> Spinning forever seems like a bad idea, but as has been demonstrated at
> > >> least twice now, continuin
Quoting Michael Roth (2020-08-05 17:29:28)
> Quoting Michael Roth (2020-08-04 23:37:32)
> > Quoting Michael Ellerman (2020-08-04 22:07:08)
> > > Greg Kurz writes:
> > > > On Tue, 04 Aug 2020 23:35:10 +1000
> > > > Michael Ellerman wrote:
> > > >> Spinning forever seems like a bad idea, but as has
On 7/27/20 11:46 AM, Scott Cheloha wrote:
> The H_GetPerformanceCounterInfo (GPCI) hypercall input/output structs are
> useful to modules outside of perf/, so move them into asm/hvcall.h to live
> alongside the other powerpc hypercall structs.
>
> Leave the perf-specific GPCI stuff in perf/hv-gpci
On 7/27/20 11:46 AM, Scott Cheloha wrote:
> The H_GetPerformanceCounterInfo (GPCI) PHYP hypercall has a subcall,
> Affinity_Domain_Info_By_Partition, which returns, among other things,
> a "partition affinity score" for a given LPAR. This score, a value on
> [0-100], represents the processor-memor
Hi all,
On Mon, 3 Aug 2020 16:55:46 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> drivers/misc/ocxl/config.c
>
> between commit:
>
> 3591538a31af ("ocxl: Address kernel doc errors & warnings")
>
> from the powerpc tree and commit:
On Tue, 4 Aug 2020 at 11:59, Michael Ellerman wrote:
>
> Joel Stanley writes:
> > It's not done anything for a long time. Save the percpu variable, and
> > emit a warning to remind users to not expect it to do anything.
> >
> > Fixes: 3fa8cad82b94 ("powerpc/pseries/cpuidle: smt-snooze-delay clean
Hi Chris,
> void __set_breakpoint(int nr, struct arch_hw_breakpoint *brk);
> +void __get_breakpoint(int nr, struct arch_hw_breakpoint *brk);
> bool ppc_breakpoint_available(void);
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> extern void do_send_trap(struct pt_regs *regs, unsigned long address,
> dif
thefirst ECS writes:
> In order to help debug a certain discrepancy, I need to "simulate" an "echo 1
> > /proc/file" but doing it from kernel even when root file system is
> unavailable.
>
> I have simulated it just fine via call_usermodehelper (with argv etc of "echo
> 1 > /proc/file") from i
Segher Boessenkool writes:
> On Wed, Aug 05, 2020 at 04:24:16PM +1000, Michael Ellerman wrote:
>> Christophe Leroy writes:
>> > Indeed, 32-bit doesn't have a redzone, so I believe it needs a stack
>> > frame whenever it has anything to same.
>>
>> Yeah OK that would explain it.
>>
>> > Here is
Christophe Leroy writes:
> Le 22/07/2020 à 04:24, Michael Ellerman a écrit :
>> The assembler says:
>>arch/powerpc/kernel/head_40x.S:623: Warning: invalid register expression
>
> I get exactly the same with head_32.S, for the exact same reason.
Ah yep, I see it. I mostly build pmac32_defconfi
"Christopher M. Riedl" writes:
> When code patching a STRICT_KERNEL_RWX kernel the page containing the
> address to be patched is temporarily mapped with permissive memory
> protections. Currently, a per-cpu vmalloc patch area is used for this
> purpose. While the patch area is per-cpu, the tempo
allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20200805
i386
defconfig
i386 randconfig-a005-20200805
i386 randconfig-a004-20200805
i386 randconfig-a001-20200805
i386 randconfig-a003-20200805
i386 randconfig-a002-20200805
i386 randconfig-a006-20200805
x86_64 r
pet...@infradead.org writes:
> On Tue, Aug 04, 2020 at 05:40:07PM +0530, Srikar Dronamraju wrote:
>> * pet...@infradead.org [2020-08-04 12:45:20]:
>>
>> > On Tue, Aug 04, 2020 at 09:03:06AM +0530, Srikar Dronamraju wrote:
>> > > cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
Hi,
On 08/05/2020 06:40 PM, Segher Boessenkool wrote:
Hi!
On Wed, Aug 05, 2020 at 04:40:16PM +, Christophe Leroy wrote:
It cannot optimise it because it does not know shift < 32. The code
below is incorrect for shift equal to 32, fwiw.
Is there a way to tell it ?
Sure, for example the
The assembler says:
arch/powerpc/kernel/head_32.S:1095: Warning: invalid register expression
It's objecting to the use of r0 as the RA argument. That's because
when RA = 0 the literal value 0 is used, rather than the content of
r0, making the use of r0 in the source potentially confusing.
Fix i
49 matches
Mail list logo
