defconfig
loongarch defconfig
loongarch allnoconfig
arc randconfig-r043-20221216
s390 randconfig-r044-20221216
riscvrandconfig-r042-20221216
i386
randconfig-a004
mips allyesconfig
i386 randconfig-a012
m68k allmodconfig
riscvrandconfig-r042-20221216
i386 randconfig-a001
powerpc allmodconfig
arc
Currently, for vmalloc areas with flag VM_IOREMAP set, except of the
specific alignment clamping in __get_vm_area_node(), they will be
1) Shown as ioremap in /proc/vmallocinfo;
2) Ignored by /proc/kcore reading via vread()
So for the io mapping in ioremap_phb() of ppc, we should set VM_IOREMAP
Hi,
I've just debugged an issue that I traced down to this commit.
My mt7621 based board relies on the soc_info.mem_detect function for
memblock init which is never being called again with this patch being
applied.
The code in the original patch as well was on 6.0 doesn't allow any of
the
On Friday 16 December 2022 09:35:50 Christophe Leroy wrote:
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index bf5f0a998273..528452ce80b4 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -201,18 +201,20 @@ KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
>
On Friday 16 December 2022 12:10:48 Segher Boessenkool wrote:
> On Fri, Dec 16, 2022 at 05:57:46PM +, Christophe Leroy wrote:
> > Le 16/12/2022 à 18:18, Segher Boessenkool a écrit :
> > > On Fri, Dec 16, 2022 at 09:35:50AM +0100, Christophe Leroy wrote:
> > >> Today we have CONFIG_TARGET_CPU
From: Xiaowei Bao
Add PCIe EP mode support for ls1028a.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
---
All other patches were already accepte by maintainer in
https://lore.kernel.org/lkml/2022223457.10599-1-leoyang...@nxp.com/
But missed this one.
Re-post.
On Tue. 15 Dec. 2022 at 22:57, kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 459c73db4069c27c1d4a0e20d055b837396364b8 Add linux-next
> specific files for 20221215
>
> Error/Warning reports:
(...)
>
zap_page_range was originally designed to unmap pages within an address
range that could span multiple vmas. While working on [1], it was
discovered that all callers of zap_page_range pass a range entirely within
a single vma. In addition, the mmu notification call within zap_page
range does not
On Fri, Dec 16, 2022 at 11:23:59PM +0100, Pali Rohár wrote:
> > It appears the E500MC64 never made it outside of FSL, so it is best not
> > to use it at all, imo.
>
> Yes, it really makes sense to not use e500mc64 flag. Maybe gcc
> documentation could be updated to mention this fact?
Thanks. I
On Friday 16 December 2022 13:15:43 Segher Boessenkool wrote:
> > Anyway, do you know what is e500mc64 core? I was trying to find some
> > information about it, but it looks like some unreleased freescale core
> > which predates e5500 core.
>
> It looks that way yes. It was submitted at
>
Hi!
On Thu, Dec 15, 2022 at 09:42:02PM +0100, Pali Rohár wrote:
> On Wednesday 07 December 2022 14:38:40 Christophe Leroy wrote:
> > default "power8" if POWER8_CPU
> > default "power9" if POWER9_CPU
> > default "power10" if POWER10_CPU
> > + default "e500mc64" if E5500_CPU
>
> Now
On Fri, Dec 16, 2022 at 05:57:46PM +, Christophe Leroy wrote:
> Le 16/12/2022 à 18:18, Segher Boessenkool a écrit :
> > On Fri, Dec 16, 2022 at 09:35:50AM +0100, Christophe Leroy wrote:
> >> Today we have CONFIG_TARGET_CPU which provides the identification of the
> >> expected CPU, it is used
PING?
On Saturday 26 November 2022 17:23:45 Pali Rohár wrote:
> PING?
>
> On Tuesday 01 November 2022 23:26:03 Pali Rohár wrote:
> > Hello! Gentle reminder...
> >
> > On Sunday 09 October 2022 13:25:55 Pali Rohár wrote:
> > > Hello! Any comments on this? It would be nice to take these two
CC Joel for the -many subject.
Le 16/12/2022 à 18:18, Segher Boessenkool a écrit :
> Hi!
>
> On Fri, Dec 16, 2022 at 09:35:50AM +0100, Christophe Leroy wrote:
>> The problem comes from the fact that CONFIG_PPC_E500MC is selected for
>> both the e500mc (32 bits) and the e5500 (64 bits), and
There aren't enough resources to run these ports at 10G speeds. Disable
10G for these ports, reverting to the previous speed.
Fixes: 36926a7d70c2 ("powerpc: dts: t208x: Mark MAC1 and MAC2 as 10G")
Reported-by: Camelia Alexandra Groza
Signed-off-by: Sean Anderson
---
Changes in v2:
- Remove the
> -Original Message-
> From: Frank Li
> Subject: [PATCH 1/1] PCI: layerscape: Add EP mode support for ls1028a
>
> From: Xiaowei Bao
>
> Add PCIe EP mode support for ls1028a.
>
> Signed-off-by: Xiaowei Bao
> Signed-off-by: Hou Zhiqiang
> ---
>
> All other patches were already
Hi!
On Fri, Dec 16, 2022 at 09:35:50AM +0100, Christophe Leroy wrote:
> The problem comes from the fact that CONFIG_PPC_E500MC is selected for
> both the e500mc (32 bits) and the e5500 (64 bits), and therefore the
> following makefile rule is wrong:
>
> cpu-as-$(CONFIG_PPC_E500MC)+= $(call
> -Original Message-
> From: Sean Anderson
> Sent: Thursday, December 15, 2022 18:33
> To: Camelia Alexandra Groza
> Cc: David S . Miller ; net...@vger.kernel.org;
> devicet...@vger.kernel.org; Michael Ellerman ;
> linux-ker...@vger.kernel.org; Rob Herring ;
> Christophe Leroy ;
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: ca39c4daa6f7f770b1329ffb46f1e4a6bcc3f291 Add linux-next specific
files for 20221216
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211180516.dtowileo-...@intel.com
https
Nathan reported that the new per-cpu mm patching oopses if DEBUG_VM is
enabled:
[ cut here ]
kernel BUG at arch/powerpc/mm/pgtable.c:333!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in:
Print the FDT error description along with the error message if failed
to set the "linux,drconf-usable-memory" property in the kdump kernel's
FDT.
Signed-off-by: Sourabh Jain
---
arch/powerpc/kexec/file_load_64.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Stack validation in early boot can just bail out of checking alternate
stacks if they are not validated yet. Checking against a NULL stack
could cause NULLish pointer values to be considered valid.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/process.c | 11 +++
1 file
The early paca and boot cpuid dance is complicated and currently does
not quite work as expected for boot cpuid != 0 cases.
early_init_devtree() currently allocates the paca_ptrs and boot cpuid
paca, but until that returns and early_setup() calls setup_paca(), this
thread is currently still
powerpc/64 can boot on a non-zero SMP processor id. Initially, the boot
CPU is said to be "assumed to be 0" until early_init_devtree() discovers
the id from the device tree. That is not a good description because the
assumption can be wrong and that has to be handled, the better
description is
The stress_hpt memblock allocation did not pass in an alignment,
which causes a stack dump in early boot (that I missed, oops).
Fixes: 6b34a099faa1 ("powerpc/64s/hash: add stress_hpt kernel boot option to
increase hash faults")
Signed-off-by: Nicholas Piggin
---
The first patch is a fix for a commit that's in powerpc next which
is a pretty harmless dump_stack(). Except that we had some bugs with
doing stack unwinding that early when the boot CPU is not zero so
that ended up crashing badly.
First patch should be relatively safe and solve that problem, but
From: Tony Jones
[Upstream commit d72eadbc1d2866fc047edd4535ffb0298fe240be]
tests/attr.c invokes attr.py via an explicit invocation of Python
($PYTHON) so there is therefore no need for an explicit shebang.
Also most distros follow pep-0394 which recommends that /usr/bin/python
refer only to
On 16/12/22 11:45, Hari Bathini wrote:
On 15/12/22 2:08 pm, Sourabh Jain wrote:
On Systems where online memory is lesser compared to max memory, the
kexec_file_load system call may fail to load the kdump kernel with the
below errors:
"Failed to update fdt with
Le 16/12/2022 à 09:38, Jan-Benedict Glaw a écrit :
> On Fri, 2022-12-16 16:07:25 +0800, kernel test robot wrote:
>> Hi Christophe,
>>
>> I love your patch! Yet something to improve:
>
> [...]
>
>> If you fix the issue, kindly add following tag where applicable
>> | Reported-by: kernel test
On Fri, 2022-12-16 16:07:25 +0800, kernel test robot wrote:
> Hi Christophe,
>
> I love your patch! Yet something to improve:
[...]
> If you fix the issue, kindly add following tag where applicable
> | Reported-by: kernel test robot
>
> All errors (new ones prefixed by >>):
>
>Assembler
Jan-Benedict reported issue with building ppc64e_defconfig
with mainline GCC work:
powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/vdso/.gettimeofday-64.o.d
-nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated
-I./include -I./arch/powerpc/include/uapi
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on powerpc/fixes linus/master v6.1 next-20221216]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
33 matches
Mail list logo
