Re: [PATCH v4 06/10] powerpc/smp: Generalize 2nd sched domain

2020-07-29 Thread Gautham R Shenoy
On Mon, Jul 27, 2020 at 11:02:26AM +0530, Srikar Dronamraju wrote: > Currently "CACHE" domain happens to be the 2nd sched domain as per > powerpc_topology. This domain will collapse if cpumask of l2-cache is > same as SMT domain. However we could generalize this domain such that it > could mean

[PATCH v3 3/3] cpuidle-pseries : Fixup exit latency for CEDE(0)

2020-07-29 Thread Gautham R. Shenoy
From: "Gautham R. Shenoy" We are currently assuming that CEDE(0) has exit latency 10us, since there is no way for us to query from the platform. However, if the wakeup latency of an Extended CEDE state is smaller than 10us, then we can be sure that the exit latency of CEDE(0) cannot be more

Re: [PATCH v2] powerpc/vio: drop bus_type from parent device

2020-07-29 Thread Greg KH
On Thu, Jul 30, 2020 at 11:28:38AM +1000, Michael Ellerman wrote: > [ Added Peter & Greg to Cc ] > > Thadeu Lima de Souza Cascardo writes: > > Commit df44b479654f62b478c18ee4d8bc4e9f897a9844 ("kobject: return error > > code if writing /sys/.../uevent fails") started returning failure when > >

[PATCH v3 2/3] cpuidle-pseries: Add function to parse extended CEDE records

2020-07-29 Thread Gautham R. Shenoy
From: "Gautham R. Shenoy" Currently we use CEDE with latency-hint 0 as the only other idle state on a dedicated LPAR apart from the polling "snooze" state. The platform might support additional extended CEDE idle states, which can be discovered through the "ibm,get-system-parameter" rtas-call

[PATCH v3 0/3] cpuidle-pseries: Parse extended CEDE information for idle.

2020-07-29 Thread Gautham R. Shenoy
From: "Gautham R. Shenoy" 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: https://lore.kernel.org/lkml/1596005254-25753-1-git-send-email-...@linux.vnet.ibm.com/ v1:

[PATCH v3 1/3] cpuidle-pseries: Set the latency-hint before entering CEDE

2020-07-29 Thread Gautham R. Shenoy
From: "Gautham R. Shenoy" As per the PAPR, each H_CEDE call is associated with a latency-hint to be passed in the VPA field "cede_latency_hint". The CEDE states that we were implicitly entering so far is CEDE with latency-hint = 0. This patch explicitly sets the latency hint corresponding to

[PATCH v3] selftests: powerpc: Fix online CPU selection

2020-07-29 Thread Sandipan Das
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 of the allocated affinity mask is dependent on the number of

Re: [PATCH v2] selftests: powerpc: Fix online CPU selection

2020-07-29 Thread Sandipan Das
Hi Srikar, Michael, On 29/07/20 9:33 pm, Srikar Dronamraju wrote: > * Sandipan Das [2020-06-09 13:07:33]: > >> 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 >>

Re: [PATCH 11/15] memblock: reduce number of parameters in for_each_mem_range()

2020-07-29 Thread Baoquan He
On 07/28/20 at 08:11am, Mike Rapoport wrote: > 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

Re: [PATCH 10/15] memblock: make memblock_debug and related functionality private

2020-07-29 Thread Baoquan He
On 07/28/20 at 08:11am, Mike Rapoport wrote: > 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. > >

Re: [PATCH 09/15] memblock: make for_each_memblock_type() iterator private

2020-07-29 Thread Baoquan He
On 07/28/20 at 08:11am, Mike Rapoport wrote: > From: Mike Rapoport > > for_each_memblock_type() is not used outside mm/memblock.c, move it there > from include/linux/memblock.h > > --- > include/linux/memblock.h | 5 - > mm/memblock.c| 5 + > 2 files changed, 5

Re: [PATCH v2] powerpc/vio: drop bus_type from parent device

2020-07-29 Thread Michael Ellerman
[ Added Peter & Greg to Cc ] Thadeu Lima de Souza Cascardo writes: > Commit df44b479654f62b478c18ee4d8bc4e9f897a9844 ("kobject: return error > code if writing /sys/.../uevent fails") started returning failure when > writing to /sys/devices/vio/uevent. > > This causes an early udevadm trigger to

Re: [PATCH] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal

2020-07-29 Thread Michael Ellerman
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 >>> unfortunately lookups take the form of linear searches. As long as >>> this is the case, traversals have the potential to

Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10

2020-07-29 Thread Segher Boessenkool
On Wed, Jul 29, 2020 at 03:44:56PM -0400, 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

Re: [PATCH net] ibmvnic: Fix IRQ mapping disposal in error path

2020-07-29 Thread Thomas Falcon
On 7/29/20 5:28 PM, Jakub Kicinski wrote: On Wed, 29 Jul 2020 16:36:32 -0500 Thomas Falcon wrote: RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ error paths. Fix this and dispose of TX IRQ mappings correctly in case of an error. Signed-off-by: Thomas Falcon Thomas, please

Re: [PATCH net] ibmvnic: Fix IRQ mapping disposal in error path

2020-07-29 Thread David Miller
From: Thomas Falcon Date: Wed, 29 Jul 2020 16:36:32 -0500 > RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ > error paths. Fix this and dispose of TX IRQ mappings correctly in > case of an error. > > Signed-off-by: Thomas Falcon Applied with Fixes: tag added and queued up for

Re: [PATCH net] ibmvnic: Fix IRQ mapping disposal in error path

2020-07-29 Thread Jakub Kicinski
On Wed, 29 Jul 2020 16:36:32 -0500 Thomas Falcon wrote: > RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ > error paths. Fix this and dispose of TX IRQ mappings correctly in > case of an error. > > Signed-off-by: Thomas Falcon Thomas, please remember about Fixes tags (for

Re: [PATCH v2] pseries/drmem: don't cache node id in drmem_lmb struct

2020-07-29 Thread Laurent Dufour
Hi Scott, Le 28/07/2020 à 18:53, Scott Cheloha a écrit : At memory hot-remove time we can retrieve an LMB's nid from its corresponding memory_block. There is no need to store the nid in multiple locations. Note that lmb_to_memblock() uses find_memory_block() to get the corresponding

linux-next: Fixes tag needs some work in the powerpc tree

2020-07-29 Thread Stephen Rothwell
Hi all, In commit 443359aebce0 ("powerpc/perf: Fix MMCRA_BHRB_DISABLE define for binutils < 2.28") Fixes tag Fixes: 9908c826d5ed ("Add Power10 PMU feature to DT CPU features") has these problem(s): - Subject does not match target commit subject Just use git log -1

[PATCH 2/2] spi: mpc512x-psc: Convert to use GPIO descriptors

2020-07-29 Thread Linus Walleij
This driver is already relying on the core to provide valid GPIO numbers in spi->cs_gpio through of_spi_get_gpio_numbers(), so we can switch to letting the core use GPIO descriptors instead. Make sure that the .set_cs() is always called, as some controller set-up is also needed. Cc: Uwe

[PATCH 1/2] spi: mpc512x-psc: Use the framework .set_cs()

2020-07-29 Thread Linus Walleij
The mpc512x-psc is rolling its own chip select control code, but the SPI master framework can handle this. It was also evaluating the CS status for each transfer but the CS change should be per-message not per-transfer. Switch to use the core .set_cs() to control the chip select. Cc: Uwe

[PATCH net] ibmvnic: Fix IRQ mapping disposal in error path

2020-07-29 Thread Thomas Falcon
RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ error paths. Fix this and dispose of TX IRQ mappings correctly in case of an error. Signed-off-by: Thomas Falcon --- drivers/net/ethernet/ibm/ibmvnic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10

2020-07-29 Thread Vladis Dronov
Hello, - Original Message - > From: "Segher Boessenkool" > To: "Vladis Dronov" > Cc: linuxppc-dev@lists.ozlabs.org, "Aneesh Kumar K . V" > , linux-ker...@vger.kernel.org, > "Paul Mackerras" > Sent: Wednesday, July 29, 2020 4:49:49 PM > Subject: Re: [PATCH] powerpc: fix function

Re: [PATCH v2] selftests: powerpc: Fix online CPU selection

2020-07-29 Thread Srikar Dronamraju
* Sandipan Das [2020-06-09 13:07:33]: > 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 > of the

Re: [PATCH] powerpc/fadump: Fix build error with CONFIG_PRESERVE_FA_DUMP=y

2020-07-29 Thread Gustavo Romero
On 7/27/20 4:03 AM, Michael Ellerman wrote: skiroot_defconfig fails: arch/powerpc/kernel/fadump.c:48:17: error: ‘cpus_in_fadump’ defined but not used 48 | static atomic_t cpus_in_fadump; Fix it by moving the definition into the #ifdef where it's used. Fixes: ba608c4fa12c ("powerpc/fadump:

Re: [PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10

2020-07-29 Thread Segher Boessenkool
On Wed, Jul 29, 2020 at 03:37:41PM +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

[PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10

2020-07-29 Thread Vladis Dronov
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 .meminit.text:split_kernel_mapping() The function

Re: [patch 01/15] mm/memory.c: avoid access flag update TLB flush for retried page fault

2020-07-29 Thread Michael Ellerman
Nicholas Piggin writes: > Excerpts from Linus Torvalds's message of July 29, 2020 5:02 am: >> On Tue, Jul 28, 2020 at 3:53 AM Nicholas Piggin wrote: >>> >>> The quirk is a problem with coprocessor where it's supposed to >>> invalidate the translation after a fault but it doesn't, so we can get a

Re: [PATCH v2] selftests: powerpc: Fix online CPU selection

2020-07-29 Thread Michael Ellerman
Sandipan Das writes: > 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 > of the allocated affinity mask

Re: ASMedia ASM2142 USB host controller tries to DMA to address zero when doing bulk reads from multiple devices

2020-07-29 Thread Oliver O'Halloran
On Tue, Jul 21, 2020 at 3:51 PM Forest Crossman wrote: > > Hello, again! > > After fixing the issue in my previous thread using this patch[1], I > decided to do some stress-testing of the controller to make sure it > could handle my intended workloads and that there were no further DMA > address

Re: [PATCH 0/7] Optimization to improve cpu online/offline on Powerpc

2020-07-29 Thread Satheesh Rajendran
On Mon, Jul 27, 2020 at 01:25:25PM +0530, Srikar Dronamraju wrote: > Anton reported that his 4096 cpu (1024 cores in a socket) was taking too > long to boot. He also analyzed that most of the time was being spent on > updating cpu_core_mask. > > Here are some optimizations and fixes to make

Re: [PATCH] powerpc/powernv/pci: Fix build of pci-ioda.o

2020-07-29 Thread Gustavo Romero
Hi Oliver, On 7/28/20 7:50 PM, Oliver O'Halloran wrote: On Wed, Jul 29, 2020 at 8:35 AM Gustavo Romero wrote: Currently pnv_ioda_setup_bus_dma() is outside of a CONFIG_IOMMU_API guard and if CONFIG_IOMMU_API=n the build can fail if the compiler sets -Werror=unused-function, because

[PATCH v6 11/11] ppc64/kexec_file: enable early kernel's OPAL calls

2020-07-29 Thread Hari Bathini
Kernel built with CONFIG_PPC_EARLY_DEBUG_OPAL enabled expects r8 & r9 to be filled with OPAL base & entry addresses respectively. Setting these registers allows the kernel to perform OPAL calls before the device tree is parsed. Signed-off-by: Hari Bathini Reviewed-by: Thiago Jung Bauermann ---

[PATCH v6 10/11] ppc64/kexec_file: fix kexec load failure with lack of memory hole

2020-07-29 Thread Hari Bathini
The kexec purgatory has to run in real mode. Only the first memory block maybe accessible in real mode. And, unlike the case with panic kernel, no memory is set aside for regular kexec load. Another thing to note is, the memory for crashkernel is reserved at an offset of 128MB. So, when

[PATCH v6 09/11] ppc64/kexec_file: add appropriate regions for memory reserve map

2020-07-29 Thread Hari Bathini
While initrd, elfcorehdr and backup regions are already added to the reserve map, there are a few missing regions that need to be added to the memory reserve map. Add them here. And now that all the changes to load panic kernel are in place, claim likewise. Signed-off-by: Hari Bathini Tested-by:

[PATCH v6 08/11] ppc64/kexec_file: prepare elfcore header for crashing kernel

2020-07-29 Thread Hari Bathini
Prepare elf headers for the crashing kernel's core file using crash_prepare_elf64_headers() and pass on this info to kdump kernel by updating its command line with elfcorehdr parameter. Also, add elfcorehdr location to reserve map to avoid it from being stomped on while booting. Signed-off-by:

[PATCH v6 07/11] ppc64/kexec_file: setup backup region for kdump kernel

2020-07-29 Thread Hari Bathini
Though kdump kernel boots from loaded address, the first 64KB of it is copied down to real 0. So, setup a backup region and let purgatory copy the first 64KB of crashed kernel into this backup region before booting into kdump kernel. Update reserve map with backup region and crashed kernel's

[PATCH v6 06/11] ppc64/kexec_file: restrict memory usage of kdump kernel

2020-07-29 Thread Hari Bathini
Kdump kernel, used for capturing the kernel core image, is supposed to use only specific memory regions to avoid corrupting the image to be captured. The regions are crashkernel range - the memory reserved explicitly for kdump kernel, memory used for the tce-table, the OPAL region and RTAS region

Re: [PATCH 05/15] h8300, nds32, openrisc: simplify detection of memory extents

2020-07-29 Thread Stafford Horne
On Tue, Jul 28, 2020 at 08:11:43AM +0300, Mike Rapoport wrote: > 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 > --- > arch/h8300/kernel/setup.c| 8

[PATCH v6 05/11] powerpc/drmem: make lmb walk a bit more flexible

2020-07-29 Thread Hari Bathini
Currently, numa & prom are the users of drmem lmb walk code. Loading kdump with kexec_file also needs to walk the drmem LMBs to setup the usable memory ranges for kdump kernel. But there are couple of issues in using the code as is. One, walk_drmem_lmb() code is built into the .init section

[PATCH v6 04/11] ppc64/kexec_file: avoid stomping memory used by special regions

2020-07-29 Thread Hari Bathini
crashkernel region could have an overlap with special memory regions like opal, rtas, tce-table & such. These regions are referred to as exclude memory ranges. Setup this ranges during image probe in order to avoid them while finding the buffer for different kdump segments. Override

[PATCH v6 03/11] powerpc/kexec_file: add helper functions for getting memory ranges

2020-07-29 Thread Hari Bathini
In kexec case, the kernel to be loaded uses the same memory layout as the running kernel. So, passing on the DT of the running kernel would be good enough. But in case of kdump, different memory ranges are needed to manage loading the kdump kernel, booting into it and exporting the elfcore of the

[PATCH v6 02/11] powerpc/kexec_file: mark PPC64 specific code

2020-07-29 Thread Hari Bathini
Some of the kexec_file_load code isn't PPC64 specific. Move PPC64 specific code from kexec/file_load.c to kexec/file_load_64.c. Also, rename purgatory/trampoline.S to purgatory/trampoline_64.S in the same spirit. No functional changes. Signed-off-by: Hari Bathini Tested-by: Pingfan Liu

[PATCH v6 01/11] kexec_file: allow archs to handle special regions while locating memory hole

2020-07-29 Thread Hari Bathini
Some architectures may have special memory regions, within the given memory range, which can't be used for the buffer in a kexec segment. Implement weak arch_kexec_locate_mem_hole() definition which arch code may override, to take care of special regions, while trying to locate a memory hole.

[PATCH v6 00/11] ppc64: enable kdump support for kexec_file_load syscall

2020-07-29 Thread Hari Bathini
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 changes are inspired from kexec-tools code but heavily modified for

Re: [PATCH] powerpc: Fix MMCRA_BHRB_DISABLE define to work with binutils version < 2.28

2020-07-29 Thread Madhavan Srinivasan
On 7/29/20 9:46 AM, Athira Rajeev wrote: commit 9908c826d5ed ("powerpc/perf: Add Power10 PMU feature to DT CPU features") defines MMCRA_BHRB_DISABLE as `0x20UL`. Binutils version less than 2.28 doesn't support UL suffix. linux-ppc/arch/powerpc/kernel/cpu_setup_power.S: Assembler

Re: [PATCH 04/15] arm64: numa: simplify dummy_numa_init()

2020-07-29 Thread Jonathan Cameron
On Tue, 28 Jul 2020 08:11:42 +0300 Mike Rapoport wrote: > 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

[PATCH v2 3/3] cpuidle-pseries : Fixup exit latency for CEDE(0)

2020-07-29 Thread Gautham R. Shenoy
From: "Gautham R. Shenoy" We are currently assuming that CEDE(0) has exit latency 10us, since there is no way for us to query from the platform. However, if the wakeup latency of an Extended CEDE state is smaller than 10us, then we can be sure that the exit latency of CEDE(0) cannot be more

[PATCH v2 0/3] cpuidle-pseries: Parse extended CEDE information for idle.

2020-07-29 Thread Gautham R. Shenoy
From: "Gautham R. Shenoy" Hi, This is a v2 of the patch series to parse the extended CEDE information in the pseries-cpuidle driver. The v1 of this patchset can be found here : https://lore.kernel.org/linuxppc-dev/1594120299-31389-1-git-send-email-...@linux.vnet.ibm.com/ The change from v1

[PATCH v2 1/3] cpuidle-pseries: Set the latency-hint before entering CEDE

2020-07-29 Thread Gautham R. Shenoy
From: "Gautham R. Shenoy" As per the PAPR, each H_CEDE call is associated with a latency-hint to be passed in the VPA field "cede_latency_hint". The CEDE states that we were implicitly entering so far is CEDE with latency-hint = 0. This patch explicitly sets the latency hint corresponding to

[PATCH v2 2/3] cpuidle-pseries: Add function to parse extended CEDE records

2020-07-29 Thread Gautham R. Shenoy
From: "Gautham R. Shenoy" Currently we use CEDE with latency-hint 0 as the only other idle state on a dedicated LPAR apart from the polling "snooze" state. The platform might support additional extended CEDE idle states, which can be discovered through the "ibm,get-system-parameter" rtas-call

Re: [PATCH v4 09/10] Powerpc/smp: Create coregroup domain

2020-07-29 Thread Srikar Dronamraju
* Valentin Schneider [2020-07-28 16:03:11]: Hi Valentin, Thanks for looking into the patches. > On 27/07/20 06:32, Srikar Dronamraju wrote: > > Add percpu coregroup maps and masks to create coregroup domain. > > If a coregroup doesn't exist, the coregroup domain will be degenerated > > in