Re: [RESEND PATCH v5 0/4] Add perf interface to expose nvdimm

Hi Le 16/11/2021 à 05:49, Kajol Jain a écrit : > Patchset adds performance stats reporting support for nvdimm. > Added interface includes support for pmu register/unregister > functions. A structure is added called nvdimm_pmu to be used for > adding arch/platform specific data such as cpumask,

Re: [PATCH v13 00/10] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK

Michael Ellerman a écrit : Christophe Leroy writes: The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which moves the thread_info into task_struct. Moving thread_info into task_struct has the following advantages: - It protects thread_info from corruption in the case of

Re: [PATCH] Remove 'type' argument from access_ok() function

Mathieu Malaterre a écrit : In commit 05a4ab823983 ("powerpc/uaccess: fix warning/error with access_ok()") an attempt was made to remove a warning by referencing the variable `type`, however in commit 96d4f267e40f ("Remove 'type' argument from access_ok() function") the variable `type` has

Re: [PATCH v5] soc/fsl/qe: fix err handling of ucc_of_parse_tdm

Peng Hao a écrit : From: Wen Yang Currently there are some issues with the ucc_of_parse_tdm function: 1, a possible null pointer dereference in ucc_of_parse_tdm, detected by the semantic patch deref_null.cocci, with the following warning: drivers/soc/fsl/qe/qe_tdm.c:177:21-24: ERROR: pdev is

Re: [PATCH v8 13/25] m68k: Dispatch nvram_ops calls to Atari or Mac functions

Finn Thain a écrit : On Sat, 29 Dec 2018, Arnd Bergmann wrote: On Wed, Dec 26, 2018 at 1:43 AM Finn Thain wrote: > + > +static ssize_t m68k_nvram_get_size(void) > +{ > + if (MACH_IS_ATARI) > + return atari_nvram_get_size(); > + else if (MACH_IS_MAC) > +

Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM

Arnd Bergmann a écrit : On Sat, Dec 29, 2018 at 3:51 AM Michael Schmitz wrote: Hi Finn, Am 29.12.2018 um 15:34 schrieb Finn Thain: > On Sat, 29 Dec 2018, Michael Schmitz wrote: > >> >> IS_BUILTIN(CONFIG_NVRAM) is probably what Christophe really meant to suggest. >> >> Or (really going

Re: [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()

Finn Thain a écrit : Make use of arch_nvram_ops in device drivers so that the nvram_* function exports can be removed. Since they are no longer global symbols, rename the PPC32 nvram_* functions appropriately. Signed-off-by: Finn Thain --- arch/powerpc/kernel/setup_32.c | 8

Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM

Michael Schmitz a écrit : Hi Finn, Am 29.12.2018 um 14:06 schrieb Finn Thain: On Fri, 28 Dec 2018, LEROY Christophe wrote: diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c index 89f5154c40b6..99e5729d910d 100644 --- a/drivers/scsi/atari_scsi.c +++ b/drivers/scsi

Re: [PATCH v8 02/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c

Finn Thain a écrit : Move the m68k-specific code out of the driver to make the driver generic. I've used 'SPDX-License-Identifier: GPL-2.0+' for the new file because the old file is covered by MODULE_LICENSE("GPL"). Signed-off-by: Finn Thain Tested-by: Christian T. Steigies Acked-by: Geert

Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM

Finn Thain a écrit : On powerpc, setting CONFIG_NVRAM=n builds a kernel with no NVRAM support. Setting CONFIG_NVRAM=m enables the /dev/nvram misc device module without enabling NVRAM support in drivers. Setting CONFIG_NVRAM=y enables the misc device (built-in) and also enables NVRAM support in

Re: [PATCH AUTOSEL 4.14 05/30] powerpc/traps: restore recoverability of machine_check interrupts

Looks like this patch didn't make its way into 4.14 yet. Is there a problem with this patch ? Christophe Sasha Levin a écrit : From: Christophe Leroy [ Upstream commit daf00ae71dad8aa05965713c62558aeebf2df48e ] commit b96672dd840f ("powerpc: Machine check interrupt is a non- maskable

Re: [PATCH AUTOSEL 4.14 05/30] powerpc/traps: restore recoverability of machine_check interrupts

Looks like this patch didn't make its way into 4.14 yet. Is there a problem with this patch ? Christophe Sasha Levin a écrit : From: Christophe Leroy [ Upstream commit daf00ae71dad8aa05965713c62558aeebf2df48e ] commit b96672dd840f ("powerpc: Machine check interrupt is a non- maskable

Re: [PATCH 7/7] powerpc/traps: Show instructions on exceptions

Murilo Opsfelder Araujo a écrit : Move show_instructions() declaration to arch/powerpc/include/asm/stacktrace.h and include asm/stracktrace.h in arch/powerpc/kernel/process.c, which contains the implementation. Modify show_instructions() not to call __kernel_text_address(), allowing

Re: [PATCH 7/7] powerpc/traps: Show instructions on exceptions

Murilo Opsfelder Araujo a écrit : Move show_instructions() declaration to arch/powerpc/include/asm/stacktrace.h and include asm/stracktrace.h in arch/powerpc/kernel/process.c, which contains the implementation. Modify show_instructions() not to call __kernel_text_address(), allowing

Re: [PATCH 6/7] powerpc/traps: Print signal name for unhandled signals

Murilo Opsfelder Araujo a écrit : This adds a human-readable name in the unhandled signal message. Before this patch, a page fault looked like: Jul 11 16:04:11 localhost kernel: pandafault[6303]: unhandled signal 11 at 17d0 nip 161c lr 7fff93c55100 code 2

Re: [PATCH 6/7] powerpc/traps: Print signal name for unhandled signals

Murilo Opsfelder Araujo a écrit : This adds a human-readable name in the unhandled signal message. Before this patch, a page fault looked like: Jul 11 16:04:11 localhost kernel: pandafault[6303]: unhandled signal 11 at 17d0 nip 161c lr 7fff93c55100 code 2

Re: [PATCH 2/7] powerpc/traps: Return early in show_signal_msg()

Murilo Opsfelder Araujo a écrit : Modify logic of show_signal_msg() to return early, if possible. Replace printk_ratelimited() by printk() and a default rate limit burst to limit displaying unhandled signals messages. Can you explain more the benefits of this change ? Christophe

Re: [PATCH 2/7] powerpc/traps: Return early in show_signal_msg()

Murilo Opsfelder Araujo a écrit : Modify logic of show_signal_msg() to return early, if possible. Replace printk_ratelimited() by printk() and a default rate limit burst to limit displaying unhandled signals messages. Can you explain more the benefits of this change ? Christophe

Re: [PATCH v4 03/19] powerpc: Mark variable `l` as unused, remove `path`

Mathieu Malaterre a écrit : Add gcc attribute unused for `l` variable, replace `path` variable directly with prom_scratch. Fix warnings treated as errors with W=1: arch/powerpc/kernel/prom_init.c:607:6: error: variable ‘l’ set but not used

Re: [PATCH v4 03/19] powerpc: Mark variable `l` as unused, remove `path`

Mathieu Malaterre a écrit : Add gcc attribute unused for `l` variable, replace `path` variable directly with prom_scratch. Fix warnings treated as errors with W=1: arch/powerpc/kernel/prom_init.c:607:6: error: variable ‘l’ set but not used [-Werror=unused-but-set-variable]

Re: [PATCH v2 03/19] powerpc: Mark variables as unused

Michael Ellerman <m...@ellerman.id.au> a écrit : LEROY Christophe <christophe.le...@c-s.fr> writes: Mathieu Malaterre <ma...@debian.org> a écrit : Add gcc attribute unused for two variables. Fix warnings treated as errors with W=1: arch/powerpc/kernel/prom_init.c:1388:

Re: [PATCH v2 03/19] powerpc: Mark variables as unused

Michael Ellerman a écrit : LEROY Christophe writes: Mathieu Malaterre a écrit : Add gcc attribute unused for two variables. Fix warnings treated as errors with W=1: arch/powerpc/kernel/prom_init.c:1388:8: error: variable ‘path’ set but not used [-Werror=unused-but-set-variable

Re: [PATCH v2 04/19] powerpc/kvm: Prefer fault_in_pages_readable function

Mathieu Malaterre a écrit : Directly use fault_in_pages_readable instead of manual __get_user code. Fix warning treated as error with W=1: arch/powerpc/kernel/kvm.c:675:6: error: variable ‘tmp’ set but not used [-Werror=unused-but-set-variable] Suggested-by: Christophe

Re: [PATCH v2 04/19] powerpc/kvm: Prefer fault_in_pages_readable function

Mathieu Malaterre a écrit : Directly use fault_in_pages_readable instead of manual __get_user code. Fix warning treated as error with W=1: arch/powerpc/kernel/kvm.c:675:6: error: variable ‘tmp’ set but not used [-Werror=unused-but-set-variable] Suggested-by: Christophe Leroy

Re: [PATCH v2 05/19] powerpc/chrp/setup: Add attribute unused and make some functions static

The subject of the patch should be updated as well Christophe Mathieu Malaterre a écrit : Remove variable declaration idu_size and associated code since not used. These functions can all be static, make it so. Fix warnings treated as errors with W=1:

Re: [PATCH v2 05/19] powerpc/chrp/setup: Add attribute unused and make some functions static

The subject of the patch should be updated as well Christophe Mathieu Malaterre a écrit : Remove variable declaration idu_size and associated code since not used. These functions can all be static, make it so. Fix warnings treated as errors with W=1:

Re: [PATCH v2 03/19] powerpc: Mark variables as unused

Mathieu Malaterre a écrit : Add gcc attribute unused for two variables. Fix warnings treated as errors with W=1: arch/powerpc/kernel/prom_init.c:1388:8: error: variable ‘path’ set but not used [-Werror=unused-but-set-variable] Suggested-by: Christophe Leroy

Re: [PATCH v2 03/19] powerpc: Mark variables as unused

Mathieu Malaterre a écrit : Add gcc attribute unused for two variables. Fix warnings treated as errors with W=1: arch/powerpc/kernel/prom_init.c:1388:8: error: variable ‘path’ set but not used [-Werror=unused-but-set-variable] Suggested-by: Christophe Leroy Signed-off-by: Mathieu

Re: [PATCH v2 02/19] powerpc/powermac: Mark variable x as unused

Mathieu Malaterre a écrit : Since the value of x is never intended to be read, remove it. Fix warning treated as error with W=1: arch/powerpc/platforms/powermac/udbg_scc.c:76:9: error: variable ‘x’ set but not used [-Werror=unused-but-set-variable] Suggested-by:

Re: [PATCH v2 02/19] powerpc/powermac: Mark variable x as unused

Mathieu Malaterre a écrit : Since the value of x is never intended to be read, remove it. Fix warning treated as error with W=1: arch/powerpc/platforms/powermac/udbg_scc.c:76:9: error: variable ‘x’ set but not used [-Werror=unused-but-set-variable] Suggested-by: Christophe Leroy

Re: [PATCH v2 01/19] powerpc/powermac: Mark variable x as unused

Mathieu Malaterre a écrit : Since the value of x is never intended to be read, declare it with gcc attribute as unused. Fix warning treated as error with W=1: arch/powerpc/platforms/powermac/bootx_init.c:471:21: error: variable ‘x’ set but not used

Re: [PATCH v2 01/19] powerpc/powermac: Mark variable x as unused

Mathieu Malaterre a écrit : Since the value of x is never intended to be read, declare it with gcc attribute as unused. Fix warning treated as error with W=1: arch/powerpc/platforms/powermac/bootx_init.c:471:21: error: variable ‘x’ set but not used [-Werror=unused-but-set-variable]

Re: [PATCH 15/19] powerpc: Add missing prototype

Mathieu Malaterre a écrit : On Fri, Mar 23, 2018 at 1:20 PM, christophe leroy wrote: Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit : Add one missing prototype for function rh_dump_blk. Fix warning treated as error in W=1:

Re: [PATCH 15/19] powerpc: Add missing prototype

Mathieu Malaterre a écrit : On Fri, Mar 23, 2018 at 1:20 PM, christophe leroy wrote: Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit : Add one missing prototype for function rh_dump_blk. Fix warning treated as error in W=1: arch/powerpc/lib/rheap.c:740:6: error: no previous

Re: [PATCH 11/19] powerpc/powermac: Move pmac_pfunc_base_install prototype to header file

Mathieu Malaterre a écrit : On Fri, Mar 23, 2018 at 1:13 PM, christophe leroy wrote: Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit : The pmac_pfunc_base_install prototype was declared in powermac/smp.c since function was used there, move it

Re: [PATCH 11/19] powerpc/powermac: Move pmac_pfunc_base_install prototype to header file

Mathieu Malaterre a écrit : On Fri, Mar 23, 2018 at 1:13 PM, christophe leroy wrote: Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit : The pmac_pfunc_base_install prototype was declared in powermac/smp.c since function was used there, move it to pmac_pfunc.h header to be visible in

Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec

LEROY Christophe <christophe.le...@c-s.fr> a écrit : Mathieu Malaterre <ma...@debian.org> a écrit : Christophe, On Sat, Mar 24, 2018 at 9:10 PM, LEROY Christophe <christophe.le...@c-s.fr> wrote: Mathieu Malaterre <ma...@debian.org> a écrit : On Fri, Mar 23, 201

Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec

LEROY Christophe a écrit : Mathieu Malaterre a écrit : Christophe, On Sat, Mar 24, 2018 at 9:10 PM, LEROY Christophe wrote: Mathieu Malaterre a écrit : On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy wrote: Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit : Some functions

Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec

Mathieu Malaterre <ma...@debian.org> a écrit : Christophe, On Sat, Mar 24, 2018 at 9:10 PM, LEROY Christophe <christophe.le...@c-s.fr> wrote: Mathieu Malaterre <ma...@debian.org> a écrit : On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy <christophe.le...@c-s.fr>

Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec

Mathieu Malaterre a écrit : Christophe, On Sat, Mar 24, 2018 at 9:10 PM, LEROY Christophe wrote: Mathieu Malaterre a écrit : On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy wrote: Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit : Some functions prototypes were missing

Re: [PATCH 01/16] initrd: Add generic code path for common initrd unloading logic.

Shea Levy a écrit : Signed-off-by: Shea Levy --- init/initramfs.c | 7 +++ usr/Kconfig | 4 2 files changed, 11 insertions(+) diff --git a/init/initramfs.c b/init/initramfs.c index 7e99a0038942..de5ce873eb5a 100644 --- a/init/initramfs.c

Re: [PATCH 01/16] initrd: Add generic code path for common initrd unloading logic.

Shea Levy a écrit : Signed-off-by: Shea Levy --- init/initramfs.c | 7 +++ usr/Kconfig | 4 2 files changed, 11 insertions(+) diff --git a/init/initramfs.c b/init/initramfs.c index 7e99a0038942..de5ce873eb5a 100644 --- a/init/initramfs.c +++ b/init/initramfs.c @@ -526,6

Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec

Mathieu Malaterre a écrit : On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy wrote: Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit : Some functions prototypes were missing for the non-altivec code. Add the missing prototypes directly in

Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec

Mathieu Malaterre a écrit : On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy wrote: Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit : Some functions prototypes were missing for the non-altivec code. Add the missing prototypes directly in xor_vmx, fix warnings treated as errors with

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

Meelis Roos a écrit : > > How early does it hang ? Any oops or trace ? > > Very early - instead oif kernel emssages, I see some repeated gibberish > of some characteers, and the background turns white. > I am booting from yaboot, background is normally black. Ok, could you try

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

Meelis Roos a écrit : > > How early does it hang ? Any oops or trace ? > > Very early - instead oif kernel emssages, I see some repeated gibberish > of some characteers, and the background turns white. > I am booting from yaboot, background is normally black. Ok, could you try by replacing

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

Meelis Roos a écrit : Meelis Roos a écrit : > > > For me, 4.13 worked and 4.14 hangs early during boot. Bisecting led to > > > the following commit. I had STRICT_KERNEL_RWX enabled when I met the > > > option. When I disabled STRICT_KERNEL_RWX, the same kernel

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

Meelis Roos a écrit : Meelis Roos a écrit : > > > For me, 4.13 worked and 4.14 hangs early during boot. Bisecting led to > > > the following commit. I had STRICT_KERNEL_RWX enabled when I met the > > > option. When I disabled STRICT_KERNEL_RWX, the same kernel booted fine. > > > > Can you

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

Meelis Roos a écrit : > For me, 4.13 worked and 4.14 hangs early during boot. Bisecting led to > the following commit. I had STRICT_KERNEL_RWX enabled when I met the > option. When I disabled STRICT_KERNEL_RWX, the same kernel booted fine. Can you please check that 4.13 boots

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

Meelis Roos a écrit : > For me, 4.13 worked and 4.14 hangs early during boot. Bisecting led to > the following commit. I had STRICT_KERNEL_RWX enabled when I met the > option. When I disabled STRICT_KERNEL_RWX, the same kernel booted fine. Can you please check that 4.13 boots properly with

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

Meelis Roos a écrit : For me, 4.13 worked and 4.14 hangs early during boot. Bisecting led to the following commit. I had STRICT_KERNEL_RWX enabled when I met the option. When I disabled STRICT_KERNEL_RWX, the same kernel booted fine. Can you please check that 4.13 boots

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

Meelis Roos a écrit : For me, 4.13 worked and 4.14 hangs early during boot. Bisecting led to the following commit. I had STRICT_KERNEL_RWX enabled when I met the option. When I disabled STRICT_KERNEL_RWX, the same kernel booted fine. Can you please check that 4.13 boots properly with

Strange reports of perf events on powerpc 83xx

Hi, Has anybody already used 'perf' tool on powerpc MPC83xx ? I have been succesfully using perf on MPC8xx, but on MPC83xx I get something strange. perf record/report reports addresses on user stack, as if it was mixing up D accesses and I accesses. Any idea of what the problem can be ?

Strange reports of perf events on powerpc 83xx

Hi, Has anybody already used 'perf' tool on powerpc MPC83xx ? I have been succesfully using perf on MPC8xx, but on MPC83xx I get something strange. perf record/report reports addresses on user stack, as if it was mixing up D accesses and I accesses. Any idea of what the problem can be ?

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

Le 17/08/2015 13:00, leroy christophe a écrit : Le 17/08/2015 12:56, leroy christophe a écrit : Le 07/08/2015 01:25, Segher Boessenkool a écrit : On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote: If this makes performance non-negligibly worse on other 32-bit chips

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

Le 17/08/2015 12:56, leroy christophe a écrit : Le 07/08/2015 01:25, Segher Boessenkool a écrit : On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote: If this makes performance non-negligibly worse on other 32-bit chips, and is an important improvement on 8xx, then we can use

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

Le 07/08/2015 01:25, Segher Boessenkool a écrit : On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote: If this makes performance non-negligibly worse on other 32-bit chips, and is an important improvement on 8xx, then we can use an ifdef since 8xx already requires its own kernel build.

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

Le 17/08/2015 12:56, leroy christophe a écrit : Le 07/08/2015 01:25, Segher Boessenkool a écrit : On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote: If this makes performance non-negligibly worse on other 32-bit chips, and is an important improvement on 8xx, then we can use

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

Le 07/08/2015 01:25, Segher Boessenkool a écrit : On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote: If this makes performance non-negligibly worse on other 32-bit chips, and is an important improvement on 8xx, then we can use an ifdef since 8xx already requires its own kernel build.

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

Le 17/08/2015 13:00, leroy christophe a écrit : Le 17/08/2015 12:56, leroy christophe a écrit : Le 07/08/2015 01:25, Segher Boessenkool a écrit : On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote: If this makes performance non-negligibly worse on other 32-bit chips

Re: [HELP/RFC] Moving ppc8xx microcode patch from micropatch.c to firmware

Le 30/06/2015 22:38, christophe leroy a écrit : I'm trying to move the 3 microcode patches included in arch/powerpc/sysdev/micropatch.c into the firmware directory in order to use request_firmware() and then be able to add additional micropatch that I need to relocate SMC2 on my MPC885. I've

Re: [HELP/RFC] Moving ppc8xx microcode patch from micropatch.c to firmware

Le 30/06/2015 22:38, christophe leroy a écrit : I'm trying to move the 3 microcode patches included in arch/powerpc/sysdev/micropatch.c into the firmware directory in order to use request_firmware() and then be able to add additional micropatch that I need to relocate SMC2 on my MPC885. I've

Oops in 3.18.14 in destroy_inode()

[46796.501487] Unable to handle kernel paging request for data at address 0x02dd [46796.514365] Faulting instruction address: 0xc00c5978 [46796.524217] Oops: Kernel access of bad area, sig: 11 [#1] [46796.529351] PREEMPT CMPC885 [46796.532144] CPU: 0 PID: 1107 Comm: snmpd Not tainted 3.18.14

Oops in 3.18.14 in destroy_inode()

[46796.501487] Unable to handle kernel paging request for data at address 0x02dd [46796.514365] Faulting instruction address: 0xc00c5978 [46796.524217] Oops: Kernel access of bad area, sig: 11 [#1] [46796.529351] PREEMPT CMPC885 [46796.532144] CPU: 0 PID: 1107 Comm: snmpd Not tainted 3.18.14

Re: [BUG] mpc8323_rdb platform doesn't boot since kernel 3.16

Le 10/06/2015 20:17, Rob Herring a écrit : On Wed, Jun 10, 2015 at 10:12 AM, leroy christophe wrote: Le 06/06/2015 17:32, Rob Herring a écrit : On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy wrote: I've got a MPC8323 RDB evaluation platform from freescale kernel 4.0 doesn't boot kernel

Re: [BUG] mpc8323_rdb platform doesn't boot since kernel 3.16

Le 10/06/2015 20:17, Rob Herring a écrit : On Wed, Jun 10, 2015 at 10:12 AM, leroy christophe christophe.le...@c-s.fr wrote: Le 06/06/2015 17:32, Rob Herring a écrit : On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy christophe.le...@c-s.fr wrote: I've got a MPC8323 RDB evaluation platform

Re: [BUG] mpc8323_rdb platform doesn't boot since kernel 3.16

Le 06/06/2015 17:32, Rob Herring a écrit : On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy wrote: I've got a MPC8323 RDB evaluation platform from freescale kernel 4.0 doesn't boot kernel 3.16 doesn't boot kernel 3.15 boots ok I disected the issue down to your commit "of/fdt: Convert FDT

Re: [BUG] mpc8323_rdb platform doesn't boot since kernel 3.16

Le 06/06/2015 17:32, Rob Herring a écrit : On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy christophe.le...@c-s.fr wrote: I've got a MPC8323 RDB evaluation platform from freescale kernel 4.0 doesn't boot kernel 3.16 doesn't boot kernel 3.15 boots ok I disected the issue down to your commit

Re: [v2,2/2] powerpc32: add support for csum_add()

Le 05/05/2015 00:10, Segher Boessenkool a écrit : On Fri, May 01, 2015 at 08:00:14PM -0500, Scott Wood wrote: On Tue, 2015-04-28 at 21:01 +0200, christophe leroy wrote: The generated code is most likely different on ppc64. I have no ppc64 compiler For reference: yes you do. Just add -m64.

Re: [v2,2/2] powerpc32: add support for csum_add()

Le 05/05/2015 00:10, Segher Boessenkool a écrit : On Fri, May 01, 2015 at 08:00:14PM -0500, Scott Wood wrote: On Tue, 2015-04-28 at 21:01 +0200, christophe leroy wrote: The generated code is most likely different on ppc64. I have no ppc64 compiler For reference: yes you do. Just add -m64.

Re: [PATCH v2] splice: sendfile() at once fails for big files

Le 06/05/2015 16:23, Jens Axboe a écrit : On 05/05/2015 09:41 PM, Linus Torvalds wrote: Jens, ping? The test results should make this a no-brainer, but I hate how random these flag ops. Missed the original, apparently. I too am confused how this is a correctness fix and not just an

Re: [PATCH v2] splice: sendfile() at once fails for big files

Le 06/05/2015 16:23, Jens Axboe a écrit : On 05/05/2015 09:41 PM, Linus Torvalds wrote: Jens, ping? The test results should make this a no-brainer, but I hate how random these flag ops. Missed the original, apparently. I too am confused how this is a correctness fix and not just an

Re: [PATCH 07/11] powerpc/8xx: macro for handling CPU15 errata

Le 20/04/2015 13:40, David Laight a écrit : From: Christophe Leroy Sent: 20 April 2015 06:27 Having a macro will help keep clear code. ... * We have to use the MD_xxx registers for the tablewalk because the * equivalent MI_xxx registers only perform the attribute functions. */ +

Re: [PATCH 07/11] powerpc/8xx: macro for handling CPU15 errata

Le 20/04/2015 13:40, David Laight a écrit : From: Christophe Leroy Sent: 20 April 2015 06:27 Having a macro will help keep clear code. ... * We have to use the MD_xxx registers for the tablewalk because the * equivalent MI_xxx registers only perform the attribute functions. */ +

Re: [PATCH 00/11] powerpc8xx: Further optimisation of TLB handling

Le 20/04/2015 07:26, Christophe Leroy a écrit : This patchset provides a further optimisation of TLB handling in the 8xx. Main changes are based on: - Using processor handling of PGD/PTE Validity bits instead of testing ourselves the entries validity - Aligning PGD address to allow direct bit

Re: [PATCH 00/11] powerpc8xx: Further optimisation of TLB handling

Le 20/04/2015 07:26, Christophe Leroy a écrit : This patchset provides a further optimisation of TLB handling in the 8xx. Main changes are based on: - Using processor handling of PGD/PTE Validity bits instead of testing ourselves the entries validity - Aligning PGD address to allow direct bit

Re: [PATCH v3 03/17] crypto: talitos - talitos_ptr renamed ptr for more lisibility

Le 17/04/2015 17:14, David Laight a écrit : From: Christophe Leroy Linux CodyingStyle recommends to use short variables for local variables. ptr is just good enough for those 3 lines functions. It helps keep single lines shorter than 80 characters. ... -static void to_talitos_ptr(struct

Re: [PATCH v3 00/17] crypto: talitos - Add support for SEC1

Oops, this is the first time I use directly the output of git format-patch into sendmail, and it looks like the mails are dated with the commit date, not today's date. I will resend now with today's date. Sorry for the noise. Christophe Le 17/04/2015 15:47, Christophe Leroy a écrit : The

Re: [PATCH v3 00/17] crypto: talitos - Add support for SEC1

Oops, this is the first time I use directly the output of git format-patch into sendmail, and it looks like the mails are dated with the commit date, not today's date. I will resend now with today's date. Sorry for the noise. Christophe Le 17/04/2015 15:47, Christophe Leroy a écrit : The

Re: [PATCH v3 03/17] crypto: talitos - talitos_ptr renamed ptr for more lisibility

Le 17/04/2015 17:14, David Laight a écrit : From: Christophe Leroy Linux CodyingStyle recommends to use short variables for local variables. ptr is just good enough for those 3 lines functions. It helps keep single lines shorter than 80 characters. ... -static void to_talitos_ptr(struct

Re: [v3, 01/11] powerpc/8xx: remove remaining unnecessary code in FixupDAR

Le 13/04/2015 22:26, Scott Wood a écrit : On Sun, 2015-04-12 at 18:16 +0200, leroy christophe wrote: Le 26/03/2015 22:32, Scott Wood a écrit : On Tue, Feb 03, 2015 at 12:38:16PM +0100, LEROY Christophe wrote: Since commit 33fb845a6f01 ("powerpc/8xx: Don't use MD_TWC for walk"

Re: [v3, 01/11] powerpc/8xx: remove remaining unnecessary code in FixupDAR

Le 13/04/2015 22:26, Scott Wood a écrit : On Sun, 2015-04-12 at 18:16 +0200, leroy christophe wrote: Le 26/03/2015 22:32, Scott Wood a écrit : On Tue, Feb 03, 2015 at 12:38:16PM +0100, LEROY Christophe wrote: Since commit 33fb845a6f01 (powerpc/8xx: Don't use MD_TWC for walk), MD_EPN

Re: [v3, 01/11] powerpc/8xx: remove remaining unnecessary code in FixupDAR

Le 26/03/2015 22:32, Scott Wood a écrit : On Tue, Feb 03, 2015 at 12:38:16PM +0100, LEROY Christophe wrote: Since commit 33fb845a6f01 ("powerpc/8xx: Don't use MD_TWC for walk"), MD_EPN and MD_TWC are not writen anymore in FixupDAR so saving r3 has become useless. Signed-off-by:

Re: [v3, 01/11] powerpc/8xx: remove remaining unnecessary code in FixupDAR

Le 26/03/2015 22:32, Scott Wood a écrit : On Tue, Feb 03, 2015 at 12:38:16PM +0100, LEROY Christophe wrote: Since commit 33fb845a6f01 (powerpc/8xx: Don't use MD_TWC for walk), MD_EPN and MD_TWC are not writen anymore in FixupDAR so saving r3 has become useless. Signed-off-by: Christophe

Re: [PATCH v2 11/11] powerpc/8xx: Add support for TASK_SIZE greater than 0x80000000

Le 21/03/2015 01:47, Scott Wood a écrit : On Tue, 2015-01-20 at 10:57 +0100, Christophe Leroy wrote: By default, TASK_SIZE is set to 0x8000 for PPC_8xx, which is most likely sufficient for most cases. However, kernel configuration allows to set TASK_SIZE to another value, so the 8xx shall

Re: powerpc32: fix warning from include/linux/mm.h

Le 21/03/2015 00:52, Scott Wood a écrit : On Fri, Dec 05, 2014 at 12:20:20PM +0100, LEROY Christophe wrote: include/linux/mm.h: In function 'is_vmalloc_addr': include/linux/mm.h:367:14: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] return addr

Re: powerpc32: fix warning from include/linux/mm.h

Le 21/03/2015 00:52, Scott Wood a écrit : On Fri, Dec 05, 2014 at 12:20:20PM +0100, LEROY Christophe wrote: include/linux/mm.h: In function 'is_vmalloc_addr': include/linux/mm.h:367:14: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] return addr

Re: [PATCH v2 11/11] powerpc/8xx: Add support for TASK_SIZE greater than 0x80000000

Le 21/03/2015 01:47, Scott Wood a écrit : On Tue, 2015-01-20 at 10:57 +0100, Christophe Leroy wrote: By default, TASK_SIZE is set to 0x8000 for PPC_8xx, which is most likely sufficient for most cases. However, kernel configuration allows to set TASK_SIZE to another value, so the 8xx shall

Re: [PATCH] spi: fsl-spi: use of_iomap() to map parameter ram on CPM1

Le 06/03/2015 12:44, Mark Brown a écrit : On Wed, Mar 04, 2015 at 09:00:39AM +0100, leroy christophe wrote: Le 03/03/2015 19:44, Mark Brown a écrit : Why are we using of_iomap() rather than a generic I/O mapping function here? because all drivers for powerpc seems to be using of_iomap

Re: [PATCH] spi: fsl-spi: use of_iomap() to map parameter ram on CPM1

Le 06/03/2015 12:44, Mark Brown a écrit : On Wed, Mar 04, 2015 at 09:00:39AM +0100, leroy christophe wrote: Le 03/03/2015 19:44, Mark Brown a écrit : Why are we using of_iomap() rather than a generic I/O mapping function here? because all drivers for powerpc seems to be using of_iomap

Re: [PATCH 0/17] crypto: talitos - Add support for SEC1

Le 06/03/2015 01:28, Herbert Xu a écrit : On Thu, Mar 05, 2015 at 06:21:01PM -0600, Kim Phillips wrote: On Thu, 5 Mar 2015 17:46:05 +0100 Christophe Leroy wrote: [15/17] crypto: talitos - Implementation of SEC1 ... [16/17] crypto: talitos - SEC1 bugs on 0 data hash [17/17] crypto: talitos

Re: [PATCH 0/17] crypto: talitos - Add support for SEC1

Le 06/03/2015 01:28, Herbert Xu a écrit : On Thu, Mar 05, 2015 at 06:21:01PM -0600, Kim Phillips wrote: On Thu, 5 Mar 2015 17:46:05 +0100 Christophe Leroy christophe.le...@c-s.fr wrote: [15/17] crypto: talitos - Implementation of SEC1 ... [16/17] crypto: talitos - SEC1 bugs on 0 data hash

Re: [PATCH 0/17] crypto: talitos - Add support for SEC1

Le 06/03/2015 01:21, Kim Phillips a écrit : On Thu, 5 Mar 2015 17:46:05 +0100 Christophe Leroy wrote: [15/17] crypto: talitos - Implementation of SEC1 ... [16/17] crypto: talitos - SEC1 bugs on 0 data hash [17/17] crypto: talitos - Update DT bindings with SEC1 This patchseries doesn't

Re: [PATCH 0/17] crypto: talitos - Add support for SEC1

Le 06/03/2015 01:21, Kim Phillips a écrit : On Thu, 5 Mar 2015 17:46:05 +0100 Christophe Leroy christophe.le...@c-s.fr wrote: [15/17] crypto: talitos - Implementation of SEC1 ... [16/17] crypto: talitos - SEC1 bugs on 0 data hash [17/17] crypto: talitos - Update DT bindings with SEC1

Re: [PATCH] spi: fsl-spi: use of_iomap() to map parameter ram on CPM1

Le 03/03/2015 19:44, Mark Brown a écrit : On Thu, Feb 26, 2015 at 05:11:42PM +0100, Christophe Leroy wrote: On CPM2, the SPI parameter RAM is dynamically allocated in the dualport RAM whereas in CPM1, it is statically allocated to a default address with capability to relocate it somewhere else

Re: [PATCH] spi: fsl-spi: use of_iomap() to map parameter ram on CPM1

Le 03/03/2015 19:44, Mark Brown a écrit : On Thu, Feb 26, 2015 at 05:11:42PM +0100, Christophe Leroy wrote: On CPM2, the SPI parameter RAM is dynamically allocated in the dualport RAM whereas in CPM1, it is statically allocated to a default address with capability to relocate it somewhere else

Re: [PATCH v2 07/11] powerpc/8xx: macro for handling CPU15 errata

Le 20/01/2015 12:09, David Laight a écrit : From Christophe Leroy Having a macro will help keep clear code. It might remove an #if but it doesn't really help. All it means is that anyone reading the code has to hunt for the definition before proceeding. Some comment about what (and why) the

Re: [PATCH v2 07/11] powerpc/8xx: macro for handling CPU15 errata

Le 20/01/2015 12:09, David Laight a écrit : From Christophe Leroy Having a macro will help keep clear code. It might remove an #if but it doesn't really help. All it means is that anyone reading the code has to hunt for the definition before proceeding. Some comment about what (and why) the

Re: [PATCH 05/11] powerpc/8xx: Optimise access to swapper_pg_dir

Le 06/01/2015 13:08, David Laight a écrit : On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote: All accessed to PGD entries are done via 0(r11). By using lower part of swapper_pg_dir as load index to r11, we can remove the ori instruction. Signed-off-by: Christophe Leroy Nice :)

Re: [PATCH 05/11] powerpc/8xx: Optimise access to swapper_pg_dir

Le 06/01/2015 13:08, David Laight a écrit : On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote: All accessed to PGD entries are done via 0(r11). By using lower part of swapper_pg_dir as load index to r11, we can remove the ori instruction. Signed-off-by: Christophe Leroy

  1   2   3   >