Hi all,
We are getting build failures in some PowerPC configs for Linus' tree.
See e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/14306515/
In file included from /kisskb/src/arch/powerpc/include/asm/paca.h:18,
from /kisskb/src/arch/powerpc/include/asm/percpu.h:13,
From: Mike Rapoport
The memory size calculation in cma_early_percent_memory() traverses
memblock.memory rather than simply call memblock_phys_mem_size(). The
comment in that function suggests that at some point there should have been
call to memblock_analyze() before memblock_phys_mem_size()
From: Mike Rapoport
Instead of traversing memblock.memory regions to find memory_start and
memory_end, simply query memblock_{start,end}_of_DRAM().
Signed-off-by: Mike Rapoport
Acked-by: Stafford Horne
---
arch/h8300/kernel/setup.c| 8 +++-
arch/nds32/kernel/setup.c| 8 ++--
From: Mike Rapoport
The only user of memblock_dbg() outside memblock was s390 setup code and it
is converted to use pr_debug() instead.
This allows to stop exposing memblock_debug and memblock_dbg() to the rest
of the kernel.
Signed-off-by: Mike Rapoport
Reviewed-by: Baoquan He
---
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() with
appropriate parameters to reduce code duplication.
Hi Sachin,
On 02/08/20 4:45 pm, Sachin Sant wrote:
> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
> build due to following error:
>
> gcc -std=gnu99 -O2 -Wall -Werror
> -DGIT_VERSION='"v5.8-rc7-1276-g3f68564f1f5a"'
>
* Mike Rapoport wrote:
> From: Mike Rapoport
>
> Currently, initrd image is reserved very early during setup and then it
> might be relocated and re-reserved after the initial physical memory
> mapping is created. The "late" reservation of memblock verifies that mapped
> memory size exceeds
From: Mike Rapoport
RISC-V does not (yet) support NUMA and for UMA architectures node 0 is
used implicitly during early memory initialization.
There is no need to call memblock_set_node(), remove this call and the
surrounding code.
Signed-off-by: Mike Rapoport
---
arch/riscv/mm/init.c | 9
From: Mike Rapoport
dummy_numa_init() loops over memblock.memory and passes nid=0 to
numa_add_memblk() which essentially wraps memblock_set_node(). However,
memblock_set_node() can cope with entire memory span itself, so the loop
over memblock.memory regions is redundant.
Using a single call to
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_phys(memblock_region_memory_end_pfn(reg));
/* do
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()
to improve encapsulation of memblock internals from its
* 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()
> to improve
From: Mike Rapoport
The function free_highpages() in both arm and xtensa essentially open-code
for_each_free_mem_range() loop to detect high memory pages that were not
reserved and that should be initialized and passed to the buddy allocator.
Replace open-coded implementation of
From: Mike Rapoport
There are several occurrences of the following pattern:
for_each_memblock(memory, reg) {
start_pfn = memblock_region_memory_base_pfn(reg);
end_pfn = memblock_region_memory_end_pfn(reg);
/* do something with start_pfn
From: Mike Rapoport
Currently for_each_mem_range() iterator is the most generic way to traverse
memblock regions. As such, it has 8 parameters and it is hardly convenient
to users. Most users choose to utilize one of its wrappers and the only
user that actually needs most of the parameters
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| 15 ---
2 files changed, 16 deletions(-)
diff
From: Mike Rapoport
* Replace magic numbers with defines
* Replace memblock_find_in_range() + memblock_reserve() with
memblock_phys_alloc_range()
* Stop checking for low memory size in reserve_crashkernel_low(). The
allocation from limited range will anyway fail if there is no enough
On Sun, Aug 02, 2020 at 08:48:42PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> We are getting build failures in some PowerPC configs for Linus' tree.
> See e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/14306515/
>
> In file included from /kisskb/src/arch/powerpc/include/asm/paca.h:18,
>
From: Mike Rapoport
microblaze does not support neither NUMA not SPARSMEM, so there is no point
to call memblock_set_node() and sparse_memory_present_with_active_regions()
functions during microblaze memory initialization.
Remove these calls and the surrounding code.
Signed-off-by: Mike
From: Mike Rapoport
for_each_memblock_type() is not used outside mm/memblock.c, move it there
from include/linux/memblock.h
Signed-off-by: Mike Rapoport
Reviewed-by: Baoquan He
---
include/linux/memblock.h | 5 -
mm/memblock.c| 5 +
2 files changed, 5 insertions(+), 5
From: Mike Rapoport
Currently, initrd image is reserved very early during setup and then it
might be relocated and re-reserved after the initial physical memory
mapping is created. The "late" reservation of memblock verifies that mapped
memory size exceeds the size of initrd, the checks whether
* Mike Rapoport wrote:
> From: Mike Rapoport
>
> * Replace magic numbers with defines
> * Replace memblock_find_in_range() + memblock_reserve() with
> memblock_phys_alloc_range()
> * Stop checking for low memory size in reserve_crashkernel_low(). The
> allocation from limited range will
pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
build due to following error:
gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1276-g3f68564f1f5a"'
-I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64
pkey_exec_prot.c
Nathan Lynch writes:
> Michael Ellerman writes:
>> Nathan Lynch writes:
>>> Michael Ellerman writes:
Nathan Lynch writes:
> Laurent Dufour writes:
>> Le 28/07/2020 à 19:37, Nathan Lynch a écrit :
>>> The drmem lmb list can have hundreds of thousands of entries, and
>>>
Nathan Chancellor writes:
> On Wed, Jul 22, 2020 at 04:57:14PM +1000, Oliver O'Halloran wrote:
>> Using single PE BARs to map an SR-IOV BAR is really a choice about what
>> strategy to use when mapping a BAR. It doesn't make much sense for this to
>> be a global setting since a device might have
On Mon, 27 Jul 2020 16:09:47 +1000, Nicholas Piggin wrote:
> Commit 2f92447f9f96 ("powerpc/book3s64/hash: Use the pte_t address from the
> caller") removed the local_irq_disable from hash_preload, but it was
> required for more than just the page table walk: the hash pte busy bit is
> effectively
On Wed, 15 Apr 2020 11:23:41 +1000, Alastair D'Silva wrote:
> These patches address checkpatch & kernel doc warnings
> in the OpenCAPI infrastructure.
>
> Alastair D'Silva (2):
> ocxl: Remove unnecessary externs
> ocxl: Address kernel doc errors & warnings
>
> [...]
Applied to powerpc/next.
On Wed, 29 Jul 2020 14:08:28 +1000, Anton Blanchard wrote:
> I've forgotten to manual enable NVME when building pseries kernels
> for machines with NVME adapters. Since it's a reasonably common
> configuration, enable it by default.
Applied to powerpc/next.
[1/1] powerpc/configs: Add
On Wed, 29 Jul 2020 17:08:44 +0530, Hari Bathini wrote:
> Sorry! There was a gateway issue on my system while posting v5, due to
> which some patches did not make it through. Resending...
>
> This patch series enables kdump support for kexec_file_load system
> call (kexec -s -p) on PPC64. The
On Thu, 27 Jun 2019 00:15:33 -0500, Nathan Lynch wrote:
> A few changes that would have aided debugging this code's interactions
> with partition migration, maybe they'll help with the next thing
> (hibernation?).
>
> Nathan Lynch (4):
> powerpc/cacheinfo: set pr_fmt
> powerpc/cacheinfo:
On Thu, 30 Jul 2020 10:38:46 +0530, Sandipan Das wrote:
> The size of the CPU affinity mask must be large enough for
> systems with a very large number of CPUs. Otherwise, tests
> which try to determine the first online CPU by calling
> sched_getaffinity() will fail. This makes sure that the size
On Tue, 28 Jul 2020 18:33:05 +0530, Balamuruhan S wrote:
> This patchset adds support to emulate divde, divde., divdeu and divdeu.
> instructions and testcases for it.
>
> Resend v4: rebased on latest powerpc next branch
>
> Changes in v4:
> -
> Fix review comments from Naveen,
> *
On Wed, 29 Jul 2020 15:37:41 +0200, Vladis Dronov wrote:
> Certain warnings are emitted for powerpc code when building with a gcc-10
> toolset:
>
> WARNING: modpost: vmlinux.o(.text.unlikely+0x377c): Section mismatch in
> reference from the function remove_pmd_table() to the function
>
From: Mike Rapoport
Hi,
These patches simplify several uses of memblock iterators and hide some of
the memblock implementation details from the rest of the system.
The patches are on top of v5.8-rc7 + cherry-pick of "mm/sparse: cleanup the
code surrounding memory_present()" [1] from mmotm
On Tue, 28 Jul 2020 12:50:39 -0300, Thadeu Lima de Souza Cascardo wrote:
> When running under older versions of qemu of under newer versions with old
> machine types, some security features will not be reported to the guest.
> This will lead the guest OS to consider itself Vulnerable to
On Tue, 23 Jun 2020 15:57:50 +0530, Mahesh Salgaonkar wrote:
> With the proposed change in percpu bootmem allocator to use page mapping
> [1], the percpu first chunk memory area can come from vmalloc ranges. This
> makes hmi handler to crash the kernel whenever percpu variable is accessed
> in
On Thu, 27 Jun 2019 00:30:42 -0500, Nathan Lynch wrote:
> Mainly this produces better information about what's happening with
> the device tree as a result of LPM or PRRN.
>
> Nathan Lynch (2):
> powerpc/pseries/mobility: set pr_fmt
> powerpc/pseries/mobility: add pr_debug for device tree
On Thu, 19 Sep 2019 18:16:33 -0500, Nathan Lynch wrote:
> In the unlikely event that the device tree lacks a /cpus node,
> find_dlpar_cpus_to_add() oddly frees the cpu_drcs buffer it has been
> passed before returning an error. Its only caller also frees the
> buffer on error.
>
> Remove the less
On Tue, 9 Jun 2020 13:44:23 +0530, Harish wrote:
> On systems with large number of cpus, test fails trying to set
> affinity by calling sched_setaffinity() with smaller size for
> affinity mask. This patch fixes it by making sure that the size of
> allocated affinity mask is dependent on the
From: Mike Rapoport
The memory size calculation in kvm_cma_reserve() traverses memblock.memory
rather than simply call memblock_phys_mem_size(). The comment in that
function suggests that at some point there should have been call to
memblock_analyze() before memblock_phys_mem_size() could be
Mike Rapoport writes:
> On Thu, Jul 30, 2020 at 10:15:13PM +1000, Michael Ellerman wrote:
>> Mike Rapoport writes:
>> > From: Mike Rapoport
>> >
>> > fadump_reserve_crash_area() reserves memory from a specified base address
>> > till the end of the RAM.
>> >
>> > Replace iteration through the
On Thu, 30 Jul 2020 11:02:54 +0530, Gautham R. Shenoy wrote:
> This is a v3 of the patch series to parse the extended CEDE
> information in the pseries-cpuidle driver.
>
> The previous two versions of the patches can be found here:
>
> v2:
>
On Fri, 21 Sep 2018 01:04:22 +0200, David Lamparter wrote:
> This just adds the zl2006 voltage regulators / power monitors and the
> onboard I2C eeproms. The ICS9FG108 clock chip doesn't seem to have a
> driver, so it is left in the DTS as a comment. And for good measure,
> the SPD eeproms are
On Fri, 31 Jul 2020 12:11:51 +0530, Vaibhav Jain wrote:
> Changes since v3[1]:
>
> * Fixed a rebase issue pointed out by Aneesh in first patch in the series.
>
> [1]
> https://lore.kernel.org/linux-nvdimm/20200730121303.134230-1-vaib...@linux.ibm.com
Applied to powerpc/next.
[1/2]
Srikar Dronamraju writes:
> * Aneesh Kumar K.V [2020-07-31 16:49:14]:
>
>> We use ibm,associativity and ibm,associativity-lookup-arrays to derive the
>> numa
>> node numbers. These device tree properties are firmware indicated grouping of
>> resources based on their hierarchy in the platform.
allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20200802
i386 randconfig-a005-20200802
i386
allnoconfig
i386 randconfig-a004-20200802
i386 randconfig-a005-20200802
i386 randconfig-a001-20200802
i386 randconfig-a002-20200802
i386 randconfig-a003-20200802
i386 randconfig
Some of our tests use VSX or newer VMX instructions, so need to be
skipped on older CPUs to avoid SIGILL'ing.
Similarly TAR was added in v2.07, and the PMU event used in the stcx
fail test only works on Power8 or later.
Signed-off-by: Michael Ellerman
---
allnoconfig
powerpc defconfig
i386 randconfig-a004-20200802
i386 randconfig-a005-20200802
i386 randconfig-a001-20200802
i386 randconfig-a002-20200802
i386 randconfig-a003-20200802
i386
Hi again Stephen,
On Sun, Aug 02, 2020 at 07:20:19PM +0200, Willy Tarreau wrote:
> On Sun, Aug 02, 2020 at 08:48:42PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > We are getting build failures in some PowerPC configs for Linus' tree.
> > See e.g.
On POWER10 bit 12 in the PVR indicates if the core is SMT4 or
SMT8. Bit 12 is set for SMT4.
Without this patch, /proc/cpuinfo on a SMT4 DD1 POWER10 looks like
this:
cpu : POWER10, altivec supported
revision: 17.0 (pvr 0080 1100)
Signed-off-by: Michael Neuling
---
Hi all,
On Mon, 3 Aug 2020 13:54:47 +1000 Stephen Rothwell
wrote:
>
> Commit
>
> 1c9df907da83 ("random: fix circular include dependency on arm64 after
> addition of percpu.h")
>
> exposed a curcular include dependency:
>
> asm/mmu.h includes asm/percpu.h, which includes asm/paca.h, which
On Mon, Aug 03, 2020 at 02:10:17PM +1000, Stephen Rothwell wrote:
> Our mails have crossed.
Ah indeed :-)
> I just sent a more comprehensive patch. I
> think your patch would require a lot of build testing and even then may
> fail for some CONFIG combination that we didn't test or added in the
Commit
1c9df907da83 ("random: fix circular include dependency on arm64 after
addition of percpu.h")
exposed a curcular include dependency:
asm/mmu.h includes asm/percpu.h, which includes asm/paca.h, which
includes asm/mmu.h
So fix it by extracting the small part of asm/mmu.h that needs
Hi Willy,
On Mon, 3 Aug 2020 05:45:47 +0200 Willy Tarreau wrote:
>
> On Sun, Aug 02, 2020 at 07:20:19PM +0200, Willy Tarreau wrote:
> > On Sun, Aug 02, 2020 at 08:48:42PM +1000, Stephen Rothwell wrote:
> > >
> > > We are getting build failures in some PowerPC configs for Linus' tree.
> > > See
On Sun, Aug 02, 2020 at 11:12:23PM +1000, Michael Ellerman wrote:
> Nathan Chancellor writes:
> > On Wed, Jul 22, 2020 at 04:57:14PM +1000, Oliver O'Halloran wrote:
> >> Using single PE BARs to map an SR-IOV BAR is really a choice about what
> >> strategy to use when mapping a BAR. It doesn't
> On 02-Aug-2020, at 10:58 PM, Sandipan Das wrote:
>
> Hi Sachin,
>
> On 02/08/20 4:45 pm, Sachin Sant wrote:
>> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
>> build due to following error:
>>
>> gcc -std=gnu99 -O2 -Wall -Werror
>>
Nathan Chancellor writes:
> On Sun, Aug 02, 2020 at 11:12:23PM +1000, Michael Ellerman wrote:
>> Nathan Chancellor writes:
>> > On Wed, Jul 22, 2020 at 04:57:14PM +1000, Oliver O'Halloran wrote:
>> >> Using single PE BARs to map an SR-IOV BAR is really a choice about what
>> >> strategy to use
58 matches
Mail list logo
