[RFC PATCH V1 02/10] powerpc/mm: Convert early cpu/mmu feature check to use the new helpers
This switch most of the early feature check to use the non static key
variant of the function. In later patches we will be switching
cpu_has_feature and mmu_has_feature to use static keys and we can use
them only after static key/jump label is initialized. Any check for
feature before jump label init should be done using this new helper.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 4 ++--
arch/powerpc/include/asm/book3s/64/pgtable.h | 2 +-
arch/powerpc/kernel/paca.c| 2 +-
arch/powerpc/kernel/setup-common.c| 6 +++---
arch/powerpc/kernel/setup_32.c| 14 +++---
arch/powerpc/kernel/setup_64.c| 12 ++--
arch/powerpc/kernel/smp.c | 2 +-
arch/powerpc/kvm/book3s_hv_builtin.c | 2 +-
arch/powerpc/mm/44x_mmu.c | 6 +++---
arch/powerpc/mm/hash_native_64.c | 2 +-
arch/powerpc/mm/hash_utils_64.c | 18 +-
arch/powerpc/mm/hugetlbpage.c | 2 +-
arch/powerpc/mm/mmu_context_nohash.c | 4 ++--
arch/powerpc/mm/pgtable-hash64.c | 2 +-
arch/powerpc/mm/ppc_mmu_32.c | 2 +-
arch/powerpc/platforms/44x/iss4xx.c | 2 +-
arch/powerpc/platforms/44x/ppc476.c | 2 +-
arch/powerpc/platforms/85xx/smp.c | 6 +++---
arch/powerpc/platforms/cell/pervasive.c | 2 +-
arch/powerpc/platforms/cell/smp.c | 2 +-
arch/powerpc/platforms/powermac/setup.c | 2 +-
arch/powerpc/platforms/powermac/smp.c | 4 ++--
arch/powerpc/platforms/powernv/setup.c| 2 +-
arch/powerpc/platforms/powernv/smp.c | 4 ++--
arch/powerpc/platforms/powernv/subcore.c | 2 +-
arch/powerpc/platforms/pseries/lpar.c | 4 ++--
arch/powerpc/platforms/pseries/smp.c | 6 +++---
27 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
index 5f9ee699da5f..fde50026603e 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
@@ -256,7 +256,7 @@ static inline unsigned long hpte_encode_avpn(unsigned long
vpn, int psize,
*/
v = (vpn >> (23 - VPN_SHIFT)) & ~(mmu_psize_defs[psize].avpnm);
v <<= HPTE_V_AVPN_SHIFT;
- if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ if (!__cpu_has_feature(CPU_FTR_ARCH_300))
v |= ((unsigned long) ssize) << HPTE_V_SSIZE_SHIFT;
return v;
}
@@ -284,7 +284,7 @@ static inline unsigned long hpte_encode_r(unsigned long pa,
int base_psize,
int actual_psize, int ssize)
{
- if (cpu_has_feature(CPU_FTR_ARCH_300))
+ if (__cpu_has_feature(CPU_FTR_ARCH_300))
pa |= ((unsigned long) ssize) << HPTE_R_3_0_SSIZE_SHIFT;
/* A 4K page needs no special encoding */
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 71f0d8ead71d..4c48b87d46f2 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -806,7 +806,7 @@ static inline int __meminit vmemmap_create_mapping(unsigned
long start,
unsigned long page_size,
unsigned long phys)
{
- if (radix_enabled())
+ if (__radix_enabled())
return radix__vmemmap_create_mapping(start, page_size, phys);
return hash__vmemmap_create_mapping(start, page_size, phys);
}
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 93dae296b6be..1b0b89e80824 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -184,7 +184,7 @@ void setup_paca(struct paca_struct *new_paca)
* if we do a GET_PACA() before the feature fixups have been
* applied
*/
- if (cpu_has_feature(CPU_FTR_HVMODE))
+ if (__cpu_has_feature(CPU_FTR_HVMODE))
mtspr(SPRN_SPRG_HPACA, local_paca);
#endif
mtspr(SPRN_SPRG_PACA, local_paca);
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 8ca79b7503d8..f43d2d76d81f 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -236,7 +236,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
seq_printf(m, "unknown (%08x)", pvr);
#ifdef CONFIG_ALTIVEC
- if (cpu_has_feature(CPU_FTR_ALTIVEC))
+ if (__cpu_has_feature(CPU_FTR_ALTIVEC))
seq_printf(m, ", altivec supported");
#endif /* CONFIG_ALTIVEC */
@@ -484,7 +484,7 @@ void __init smp_setup_cpu_maps(void)
}
/* If no SMT supported, nthreads is forced to 1 */
- if (!cpu_has_feature(CPU_FTR_SMT)) {
+ if (!__cpu_has_
[RFC PATCH V1 01/10] powerpc/mm: Add __cpu/__mmu_has_feature
In later patches, we will be switching cpu and mmu feature check to
use static keys. This would require us to have a variant of feature
check that can be used in early boot before jump label is initialized.
This patch adds the same. We also add a variant for radix_enabled()
check
We also update the return type to bool.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/mmu.h | 19 +++
arch/powerpc/include/asm/cputable.h | 15 ++-
arch/powerpc/include/asm/mmu.h | 13 +++--
arch/powerpc/xmon/ppc-dis.c | 1 +
4 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h
b/arch/powerpc/include/asm/book3s/64/mmu.h
index b7514f19863f..7c4843e08948 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -24,9 +24,20 @@ struct mmu_psize_def {
extern struct mmu_psize_def mmu_psize_defs[MMU_PAGE_COUNT];
#ifdef CONFIG_PPC_RADIX_MMU
-#define radix_enabled() mmu_has_feature(MMU_FTR_TYPE_RADIX)
+static inline bool radix_enabled(void)
+{
+ return mmu_has_feature(MMU_FTR_TYPE_RADIX);
+}
+#define radix_enabled radix_enabled
+
+static inline bool __radix_enabled(void)
+{
+ return __mmu_has_feature(MMU_FTR_TYPE_RADIX);
+}
+#define __radix_enabled __radix_enabled
#else
#define radix_enabled() (0)
+#define __radix_enabled() (0)
#endif
#endif /* __ASSEMBLY__ */
@@ -115,7 +126,7 @@ extern void hash__early_init_mmu(void);
extern void radix__early_init_mmu(void);
static inline void early_init_mmu(void)
{
- if (radix_enabled())
+ if (__radix_enabled())
return radix__early_init_mmu();
return hash__early_init_mmu();
}
@@ -123,7 +134,7 @@ extern void hash__early_init_mmu_secondary(void);
extern void radix__early_init_mmu_secondary(void);
static inline void early_init_mmu_secondary(void)
{
- if (radix_enabled())
+ if (__radix_enabled())
return radix__early_init_mmu_secondary();
return hash__early_init_mmu_secondary();
}
@@ -135,7 +146,7 @@ extern void radix__setup_initial_memory_limit(phys_addr_t
first_memblock_base,
static inline void setup_initial_memory_limit(phys_addr_t first_memblock_base,
phys_addr_t first_memblock_size)
{
- if (radix_enabled())
+ if (__radix_enabled())
return radix__setup_initial_memory_limit(first_memblock_base,
first_memblock_size);
return hash__setup_initial_memory_limit(first_memblock_base,
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index df4fb5faba43..dfdf36bc2664 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -576,12 +576,17 @@ enum {
};
#endif /* __powerpc64__ */
-static inline int cpu_has_feature(unsigned long feature)
+static inline bool __cpu_has_feature(unsigned long feature)
{
- return (CPU_FTRS_ALWAYS & feature) ||
- (CPU_FTRS_POSSIBLE
- & cur_cpu_spec->cpu_features
- & feature);
+ if (CPU_FTRS_ALWAYS & feature)
+ return true;
+
+ return !!(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature);
+}
+
+static inline bool cpu_has_feature(unsigned long feature)
+{
+ return __cpu_has_feature(feature);
}
#define HBP_NUM 1
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index c740da6990a5..c488db09f7a0 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -138,9 +138,14 @@ enum {
0,
};
-static inline int mmu_has_feature(unsigned long feature)
+static inline bool __mmu_has_feature(unsigned long feature)
{
- return (MMU_FTRS_POSSIBLE & cur_cpu_spec->mmu_features & feature);
+ return !!(MMU_FTRS_POSSIBLE & cur_cpu_spec->mmu_features & feature);
+}
+
+static inline bool mmu_has_feature(unsigned long feature)
+{
+ return __mmu_has_feature(feature);
}
static inline void mmu_clear_feature(unsigned long feature)
@@ -236,5 +241,9 @@ extern void setup_initial_memory_limit(phys_addr_t
first_memblock_base,
#define radix_enabled() (0)
#endif
+#ifndef __radix_enabled
+#define __radix_enabled() (0)
+#endif
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MMU_H_ */
diff --git a/arch/powerpc/xmon/ppc-dis.c b/arch/powerpc/xmon/ppc-dis.c
index 89098f320ad5..acad77b4f7b6 100644
--- a/arch/powerpc/xmon/ppc-dis.c
+++ b/arch/powerpc/xmon/ppc-dis.c
@@ -19,6 +19,7 @@ You should have received a copy of the GNU General Public
License
along with this file; see the file COPYING. If not, write to the Free
Software Foundation, 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301,
USA. */
+#include
#include
#include "nonstdio.h"
#include "ansidecl.h"
--
2.7.4
___
Linuxppc-dev ma
Re: Rational for having CONFIG_FB_RADEON=m
Hi Michael, On Tue, Jun 14, 2016 at 5:26 AM, Michael Ellerman wrote: > On Mon, 2016-06-13 at 17:46 +0200, Mathieu Malaterre wrote: > >> 2. Try to fix `radeonfb` so that it is able to kick offb out of the >> way. Eg: >> https://lists.freedesktop.org/archives/dri-devel/2010-August/002907.html >> >> From my understanding it would make sense to go for (2), since it >> would allow for proper support for CONFIG_FB_RADEON=m on PowerMac. In >> this case, would such patch be accepted ? > > Sounds like the right fix to me. Ben's patch above was merged, so it's > supposed > to kick out offb AFAICS, the fact that it can't seems like a bug. I can do a `modprobe radeon` just fine, thanks to this patch. A similar patch needs to be applied for `radeonfb` now. I'll work on it ASAP. -M ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [FIX PATCH v2 0/2] Fix powerpc,numa: Fix memory_hotplug_max()
On Tue, Jun 14, 2016 at 03:19:27PM +1000, Michael Ellerman wrote: > On Tue, 2016-06-14 at 10:16 +0530, Bharata B Rao wrote: > > On Thu, May 12, 2016 at 07:04:13PM +0530, Bharata B Rao wrote: > > > This patchset fixes memory_hotplug_max() routine to return correct > > > value of maximum hotpluggable address. > > > > > > In this version, whitespace fixes are separated into a different patch. > > > > > > v2: > > > https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg103342.html > > > > > > Bharata B Rao (2): > > > powerpc,numa: Fix whitespace in hot_add_drconf_memory_max() > > > powerpc,numa: Fix memory_hotplug_max() > > > > > > arch/powerpc/mm/numa.c | 36 ++-- > > > 1 file changed, 26 insertions(+), 10 deletions(-) > > > > Can this fix be considered for inclusion ? Should I be posting this against > > latest git now ? > > No that's fine, it still applies cleanly. > > Have you tested this on PowerVM ? No. Let me grab a PowerVM box, test and get back. > > Has this always been broken, or did we break it in a particular commit? If the > latter can you tell me which commit. memory_hotplug_max() got introduced in cd34206e9 and has been buggy since then. Just that it got exposed by memory hotplug and DDW features on PowerKVM. > > Should we be sending this to stable? I am not sure as only PowerKVM is affected with the introducion of DDW feature in yet-to-be-released QEMU-2.7. Even there, we are working around the problem within QEMU itself, but better to fix this in the kernel once. Regards, Bharata. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [FIX PATCH v2 0/2] Fix powerpc,numa: Fix memory_hotplug_max()
On Tue, 2016-06-14 at 10:16 +0530, Bharata B Rao wrote: > On Thu, May 12, 2016 at 07:04:13PM +0530, Bharata B Rao wrote: > > This patchset fixes memory_hotplug_max() routine to return correct > > value of maximum hotpluggable address. > > > > In this version, whitespace fixes are separated into a different patch. > > > > v2: > > https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg103342.html > > > > Bharata B Rao (2): > > powerpc,numa: Fix whitespace in hot_add_drconf_memory_max() > > powerpc,numa: Fix memory_hotplug_max() > > > > arch/powerpc/mm/numa.c | 36 ++-- > > 1 file changed, 26 insertions(+), 10 deletions(-) > > Can this fix be considered for inclusion ? Should I be posting this against > latest git now ? No that's fine, it still applies cleanly. Have you tested this on PowerVM ? Has this always been broken, or did we break it in a particular commit? If the latter can you tell me which commit. Should we be sending this to stable? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V2, 08/10] powerpc/mm: Clear top 16 bits of va only on older cpus
On Thu, 2016-09-06 at 06:19:15 UTC, "Aneesh Kumar K.V" wrote:
> Updated patch below. MMU_FTRS_POWER4 is inherited by others, hence don't
> update that.
>
> >From 4ed66fd24dc4f976969cc34aca8df2ddbc69fe61 Mon Sep 17 00:00:00 2001
> From: "Aneesh Kumar K.V"
> Date: Sat, 4 Jun 2016 19:58:26 +0530
> Subject: [PATCH] powerpc/mm: Clear top 16 bits of va only on older cpus
>
> As per ISA, we need to do this only for architecture version 2.02 and
> earlier. This continued to work even for 2.07. But let's not do this for
> anything after 2.02
What are the practical effects of this?
> diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
> index e53ebebff474..fa314b1d667e 100644
> --- a/arch/powerpc/include/asm/mmu.h
> +++ b/arch/powerpc/include/asm/mmu.h
> @@ -24,6 +24,11 @@
> /*
> * This is individual features
> */
> +/*
> + * We need to clear top 16bits of va (from the remaining 64 bits )in
> + * tlbie* instructions
> + */
> +#define MMU_FTR_TLBIE_CROP_VAASM_CONST(0x8000)
>
> /* Enable use of high BAT registers */
> #define MMU_FTR_USE_HIGH_BATSASM_CONST(0x0001)
> @@ -124,7 +129,7 @@ enum {
> MMU_FTR_USE_TLBRSRV | MMU_FTR_USE_PAIRED_MAS |
> MMU_FTR_NO_SLBIE_B | MMU_FTR_16M_PAGE | MMU_FTR_TLBIEL |
> MMU_FTR_LOCKLESS_TLBIE | MMU_FTR_CI_LARGE_PAGE |
> - MMU_FTR_1T_SEGMENT |
> + MMU_FTR_1T_SEGMENT | MMU_FTR_TLBIE_CROP_VA |
> #ifdef CONFIG_PPC_RADIX_MMU
> MMU_FTR_RADIX |
> #endif
> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> index eeeacf6235a3..d8a0f7ca74e1 100644
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
> @@ -137,7 +137,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .cpu_name = "POWER4 (gp)",
> .cpu_features = CPU_FTRS_POWER4,
> .cpu_user_features = COMMON_USER_POWER4,
> - .mmu_features = MMU_FTRS_POWER4,
> + .mmu_features = MMU_FTRS_POWER4 |
> MMU_FTR_TLBIE_CROP_VA,
> .icache_bsize = 128,
> .dcache_bsize = 128,
> .num_pmcs = 8,
> @@ -152,7 +152,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .cpu_name = "POWER4+ (gq)",
> .cpu_features = CPU_FTRS_POWER4,
> .cpu_user_features = COMMON_USER_POWER4,
> - .mmu_features = MMU_FTRS_POWER4,
> + .mmu_features = MMU_FTRS_POWER4 |
> MMU_FTR_TLBIE_CROP_VA,
> .icache_bsize = 128,
> .dcache_bsize = 128,
> .num_pmcs = 8,
> @@ -168,7 +168,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .cpu_features = CPU_FTRS_PPC970,
> .cpu_user_features = COMMON_USER_POWER4 |
> PPC_FEATURE_HAS_ALTIVEC_COMP,
> - .mmu_features = MMU_FTRS_PPC970,
> + .mmu_features = MMU_FTRS_PPC970 |
> MMU_FTR_TLBIE_CROP_VA,
Please add it to MMU_FTRS_PPC970, rather than at every usage.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [FIX PATCH v2 0/2] Fix powerpc,numa: Fix memory_hotplug_max()
On Thu, May 12, 2016 at 07:04:13PM +0530, Bharata B Rao wrote: > This patchset fixes memory_hotplug_max() routine to return correct > value of maximum hotpluggable address. > > In this version, whitespace fixes are separated into a different patch. > > v2: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg103342.html > > Bharata B Rao (2): > powerpc,numa: Fix whitespace in hot_add_drconf_memory_max() > powerpc,numa: Fix memory_hotplug_max() > > arch/powerpc/mm/numa.c | 36 ++-- > 1 file changed, 26 insertions(+), 10 deletions(-) Can this fix be considered for inclusion ? Should I be posting this against latest git now ? Regards, Bharata. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] perf annotate: add powerpc support
On Fri, 2016-06-10 at 20:08 +0530, Naveen N. Rao wrote: > On 2016/06/10 10:36AM, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jun 10, 2016 at 06:32:51PM +0530, Naveen N. Rao escreveu: > > > Convert ins__find() to a __weak function for generic functionality, > > > while adding a powerpc-specific variant. We look at the function name > > > for branch instructions and classify the instructions to one among a > > > branch, a function call (branch with LR update) or a function return > > > (branch to LR). > > > > How would this allow one to get a perf.data collected on a powerpc > > system, transfer it to a x86-64 (or aarch64, to mention another > > workstation wannabe chip) system and then try annotating it? > > > > There was a previous discussion about this, and it involved having all > > yout ppc tables available as well as other arches tables, and then > > choosing which one to use based on: > > > > normalize_arch(thread->mg->machine->env->arch) > > > > just like was done for support cross unwinding, see recent patch kit by > > He Kuang, CCed. > > Nice. This would be good to have. I will look at adding powerpc support > for cross-architecture unwind. > > However, for cross-architecture annotation, I think there will be a lot > more dependencies since perf currently uses objdump to obtain the > disassembly. In addition, the actual binaries will also be needed. It's possible to build a multi-arch objdump, I don't know if it's packaged on all distros, or if perf wants to depend on it. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel 9/9] KVM: PPC: VFIO device: support SPAPR TCE
On 10/06/16 16:50, David Gibson wrote:
> On Thu, Jun 09, 2016 at 04:47:59PM +1000, Alexey Kardashevskiy wrote:
>> On 23/03/16 14:03, David Gibson wrote:
>>> On Tue, Mar 22, 2016 at 11:34:55AM +1100, Alexey Kardashevskiy wrote:
Uff, lost cc: list. Added back. Some comments below.
On 03/21/2016 04:19 PM, David Gibson wrote:
> On Fri, Mar 18, 2016 at 11:12:26PM +1100, Alexey Kardashevskiy wrote:
>> On March 15, 2016 17:29:26 David Gibson
>> wrote:
>>
>>> On Fri, Mar 11, 2016 at 10:09:50AM +1100, Alexey Kardashevskiy wrote:
On 03/10/2016 04:21 PM, David Gibson wrote:
> On Wed, Mar 09, 2016 at 08:20:12PM +1100, Alexey Kardashevskiy wrote:
>> On 03/09/2016 04:45 PM, David Gibson wrote:
>>> On Mon, Mar 07, 2016 at 02:41:17PM +1100, Alexey Kardashevskiy
>>> wrote:
sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap
via hypercalls which take a logical bus id (LIOBN) as a target
IOMMU
identifier. LIOBNs are made up, advertised to guest systems and
linked to IOMMU groups by the user space.
In order to enable acceleration for IOMMU operations in KVM, we
need
to tell KVM the information about the LIOBN-to-group mapping.
For that, a new KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN parameter
is added which accepts:
- a VFIO group fd and IO base address to find the actual hardware
TCE table;
- a LIOBN to assign to the found table.
Before notifying KVM about new link, this check the group for being
registered with KVM device in order to release them at unexpected
KVM
finish.
This advertises the new KVM_CAP_SPAPR_TCE_VFIO capability to the
user
space.
While we are here, this also fixes VFIO KVM device compiling to
let it
link to a KVM module.
Signed-off-by: Alexey Kardashevskiy
---
Documentation/virtual/kvm/devices/vfio.txt | 21 +-
arch/powerpc/kvm/Kconfig | 1 +
arch/powerpc/kvm/Makefile | 5 +-
arch/powerpc/kvm/powerpc.c | 1 +
include/uapi/linux/kvm.h | 9 +++
virt/kvm/vfio.c| 106
+
6 files changed, 140 insertions(+), 3 deletions(-)
diff --git a/Documentation/virtual/kvm/devices/vfio.txt
b/Documentation/virtual/kvm/devices/vfio.txt
index ef51740..c0d3eb7 100644
--- a/Documentation/virtual/kvm/devices/vfio.txt
+++ b/Documentation/virtual/kvm/devices/vfio.txt
@@ -16,7 +16,24 @@ Groups:
KVM_DEV_VFIO_GROUP attributes:
KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device
tracking
+ kvm_device_attr.addr points to an int32_t file descriptor
+ for the VFIO group.
>>>
>>> AFAICT these changes are accurate for VFIO as it is already, in
>>> which
>>> case it might be clearer to put them in a separate patch.
>>>
KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device
tracking
+ kvm_device_attr.addr points to an int32_t file descriptor
+ for the VFIO group.
-For each, kvm_device_attr.addr points to an int32_t file
descriptor
-for the VFIO group.
+ KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN: sets a liobn for a VFIO
group
+ kvm_device_attr.addr points to a struct:
+ struct kvm_vfio_spapr_tce_liobn {
+ __u32 argsz;
+ __s32 fd;
+ __u32 liobn;
+ __u8pad[4];
+ __u64 start_addr;
+ };
+ where
+ @argsz is the size of kvm_vfio_spapr_tce_liobn;
+ @fd is a file descriptor for a VFIO group;
+ @liobn is a logical bus id to be associated with the
group;
+ @start_addr is a DMA window offset on the IO (PCI) bus
>>>
>>> For the cause of DDW and multiple windows, I'm assuming you can call
>>> this multiple times with different LIOBNs and the same IOMMU group?
>>
>>
>> Yes. It is called twice per each group (when DDW is activated) - for
>> 32bit
>> and 64bit windows, this is why @start_
Re: Rational for having CONFIG_FB_RADEON=m
On Mon, 2016-06-13 at 17:46 +0200, Mathieu Malaterre wrote: > 2. Try to fix `radeonfb` so that it is able to kick offb out of the > way. Eg: > https://lists.freedesktop.org/archives/dri-devel/2010-August/002907.html > > From my understanding it would make sense to go for (2), since it > would allow for proper support for CONFIG_FB_RADEON=m on PowerMac. In > this case, would such patch be accepted ? Sounds like the right fix to me. Ben's patch above was merged, so it's supposed to kick out offb AFAICS, the fact that it can't seems like a bug. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/nohash: Fix build break with 4K pages
On Wed, 2016-08-06 at 13:21:11 UTC, Michael Ellerman wrote:
> Commit 74701d5947a6 "powerpc/mm: Rename function to indicate we are
> allocating fragments" renamed page_table_free() to pte_fragment_free().
> One occurrence was mistyped as pte_fragment_fre().
>
> This only breaks the nohash 4K page build, which is not the default or
> enabled in any defconfig.
>
> Fixes: 74701d5947a6 ("powerpc/mm: Rename function to indicate we are
> allocating fragments")
> Signed-off-by: Michael Ellerman
> Reviewed-by: Aneesh Kumar K.V
Applied to powerpc fixes with fixed changelog.
https://git.kernel.org/powerpc/c/8017ea35d33f9e0950d369773a
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 06/14] x86/ptrace: run seccomp after ptrace
On Thu, Jun 9, 2016 at 3:52 PM, Andy Lutomirski wrote: > On Thu, Jun 9, 2016 at 2:01 PM, Kees Cook wrote: >> This moves seccomp after ptrace on x86 to that seccomp can catch changes >> made by ptrace. Emulation should skip the rest of processing too. >> >> We can get rid of test_thread_flag because there's no longer any >> opportunity for seccomp to mess with ptrace state before invoking >> ptrace. >> >> Suggested-by: Andy Lutomirski >> Signed-off-by: Kees Cook >> Cc: x...@kernel.org >> Cc: Andy Lutomirski >> --- >> arch/x86/entry/common.c | 22 -- >> 1 file changed, 12 insertions(+), 10 deletions(-) >> >> diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c >> index df56ca394877..81c0e12d831c 100644 >> --- a/arch/x86/entry/common.c >> +++ b/arch/x86/entry/common.c >> @@ -73,6 +73,7 @@ static long syscall_trace_enter(struct pt_regs *regs) >> >> struct thread_info *ti = pt_regs_to_thread_info(regs); >> unsigned long ret = 0; >> + bool emulated = false; >> u32 work; >> >> if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) >> @@ -80,11 +81,19 @@ static long syscall_trace_enter(struct pt_regs *regs) >> >> work = ACCESS_ONCE(ti->flags) & _TIF_WORK_SYSCALL_ENTRY; >> >> + if (unlikely(work & _TIF_SYSCALL_EMU)) >> + emulated = true; >> + >> + if ((emulated || (work & _TIF_SYSCALL_TRACE)) && >> + tracehook_report_syscall_entry(regs)) >> + return -1L; >> + >> + if (emulated) >> + return -1L; >> + > > I think that this code will result in ptrace-induced skips calling the > audit exit hook but not the audit entry hook. I don't know whether > this is a problem. It's also worth making sure that ptracing a > seccomp-skipped syscall calls the exit hook with the right regs. > > I suspect it's fine, but I want to think about it a little bit more. I poked at it a bit and this seems to work correctly. selftests/x86/ptrace_syscall.c exercises PTRACE_SYSCALL_EMU pretty well, and it still passes. --Andy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Send SIGBUS on unaligned copy and paste
On Thu, Jun 09, 2016 at 08:57:50AM +0200, Christophe Leroy wrote:
Le 09/06/2016 à 08:01, Chris Smart a écrit :
Calling ISA 3.0 instructions copy, copy_first, paste and paste_last
generates an alignment fault when copying or pasting unaligned
data (128 byte). We catch this and send SIGBUS to the userspace
process that caused it.
[snip]
+if ((instruction & 0xfc0006fe) == 0x7c00060c){
Can you define corresponding instruction and mask in
arch/powerpc/include/asm/ppc-opcode.h
and use symbolic names here instead of raw values ?
Yep, thanks. Will look at doing this for V2.
Cheers,
-c
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 11/12] mmc: Only descend into mmc directory when CONFIG_MMC is set
Hi, [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.7-rc3 next-20160609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andrew-F-Davis/gpio-Only-descend-into-gpio-directory-when-CONFIG_GPIOLIB-is-set/20160614-061705 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next config: i386-randconfig-sb0-06140627 (attached as .config) compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "sdhci_pci_get_data" [drivers/mmc/host/sdhci-pci.ko] undefined! >> ERROR: "sdhci_pci_spt_drive_strength" [drivers/mmc/host/sdhci-pci.ko] >> undefined! ERROR: "hsi_board_list" [drivers/hsi/hsi.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/8] kexec_file: Generalize kexec_add_buffer.
On 06/13/16 at 04:08pm, Thiago Jung Bauermann wrote:
> Hello Dave,
>
> Thanks for the quick review and for your comments.
>
> I'll separate the change to add arch_walk_system_ram and the change to add
> kexec_locate_mem_hole into different patches, and add error handling for
> KEXEC_ON_CRASH.
>
> Am Montag, 13 Juni 2016, 15:29:39 schrieb Dave Young:
> > On 06/12/16 at 12:10am, Thiago Jung Bauermann wrote:
> > > Allow architectures to specify different memory walking functions for
> > > kexec_add_buffer. Intel uses iomem to track reserved memory ranges,
> > > but PowerPC uses the memblock subsystem.
> >
> > Can the crashk_res be inserted to iomem_resource so that only one
> > weak function for system ram is needed?
>
> Sorry, it's not clear to me what you mean by inserting crashk_res into
Hmm, I means exporting crashkernel mem to /proc/iomem like other arches
It is just oneline:
insert_resource(&iomem_resource, &crashk_res)
But your proposal below is also fine.
> iomem_resource, but I can add a bool for_crashkernel to arch_walk_system_ram
> so that it can decide which kind of memory to traverse, so the default
> implementation of kexec_file.c would be:
>
> int __weak arch_walk_system_ram(bool for_crashkernel, unsigned long start,
> unsigned long end, bool top_down,
> void *data,
> int (*func)(u64, u64, void *))
arch_walk_mem sounds better?
> {
> int ret;
>
> if (for_crashkernel)
> ret = walk_iomem_res_desc(crashk_res.desc,
> IORESOURCE_SYSTEM_RAM |
> IORESOURCE_BUSY,
> start, end, data, func);
> else
> ret = walk_system_ram_res(start, end, data, func);
>
> if (ret != 1) {
> /* A suitable memory range could not be found for buffer */
> return -EADDRNOTAVAIL;
> }
> }
>
> and kexec_add_buffer / kexec_locate_mem_hole would call it with:
>
> if (image->type == KEXEC_TYPE_CRASH)
> ret = arch_walk_system_ram(true, crashk_res.start,
> crashk_res.end, top_down, &buf,
> locate_mem_hole_callback);
> else
> ret = arch_walk_system_ram(false, 0, -1, top_down, &buf,
> locate_mem_hole_callback);
>
> What do you think?
Sounds good, but for_crashkernel can be image_type instead. and
image->type can be passed to the arch_walk_mem function directly.
Thanks
Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 06/12] hsi: Only descend into hsi directory when CONFIG_HSI is set
Hi, [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.7-rc3 next-20160609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andrew-F-Davis/gpio-Only-descend-into-gpio-directory-when-CONFIG_GPIOLIB-is-set/20160614-061705 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next config: i386-randconfig-sb0-06140627 (attached as .config) compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "hsi_board_list" [drivers/hsi/hsi.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 12/12] leds: Only descend into leds directory when CONFIG_NEW_LEDS is set
Hi, [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.7-rc3 next-20160609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andrew-F-Davis/gpio-Only-descend-into-gpio-directory-when-CONFIG_GPIOLIB-is-set/20160614-061705 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next config: arm-s3c6400_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): arch/arm/mach-s3c64xx/built-in.o: In function `crag6410_machine_init': >> arch/arm/mach-s3c64xx/mach-crag6410.c:854: undefined reference to >> `gpio_led_register_device' vim +854 arch/arm/mach-s3c64xx/mach-crag6410.c e1a3c74f Mark Brown 2011-05-06 838 s3c_sdhci2_set_platdata(&crag6410_hsmmc2_pdata); e1a3c74f Mark Brown 2011-05-06 839 e1a3c74f Mark Brown 2011-05-06 840 s3c_i2c0_set_platdata(&i2c0_pdata); 8351c7aa Mark Brown 2011-12-02 841 s3c_i2c1_set_platdata(&i2c1_pdata); e1a3c74f Mark Brown 2011-05-06 842 s3c_fb_set_platdata(&crag6410_lcd_pdata); 1f91b4cc Felipe Balbi 2015-08-06 843 dwc2_hsotg_set_platdata(&crag6410_hsotg_pdata); e1a3c74f Mark Brown 2011-05-06 844 e1a3c74f Mark Brown 2011-05-06 845 i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0)); e1a3c74f Mark Brown 2011-05-06 846 i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1)); e1a3c74f Mark Brown 2011-05-06 847 e1a3c74f Mark Brown 2011-05-06 848 samsung_keypad_set_platdata(&crag6410_keypad_data); 479535ed Mark Brown 2012-10-17 849 s3c64xx_spi0_set_platdata(NULL, 0, 2); e1a3c74f Mark Brown 2011-05-06 850 799fbf8c Thierry Reding 2015-10-13 851 pwm_add_table(crag6410_pwm_lookup, ARRAY_SIZE(crag6410_pwm_lookup)); e1a3c74f Mark Brown 2011-05-06 852 platform_add_devices(crag6410_devices, ARRAY_SIZE(crag6410_devices)); e1a3c74f Mark Brown 2011-05-06 853 66211f98 Mark Brown 2011-12-29 @854 gpio_led_register_device(-1, &gpio_leds_pdata); 66211f98 Mark Brown 2011-12-29 855 ae24c263 Mark Brown 2011-06-22 856 regulator_has_full_constraints(); ae24c263 Mark Brown 2011-06-22 857 c656c306 Mark Brown 2011-12-08 858 s3c64xx_pm_init(); e1a3c74f Mark Brown 2011-05-06 859 } e1a3c74f Mark Brown 2011-05-06 860 e1a3c74f Mark Brown 2011-05-06 861 MACHINE_START(WLF_CRAGG_6410, "Wolfson Cragganmore 6410") e1a3c74f Mark Brown 2011-05-06 862 /* Maintainer: Mark Brown */ :: The code at line 854 was first introduced by commit :: 66211f98d611056bf5fe918bbda37c636688574e ARM: S3C64XX: Support GPIO LEDs on Cragganmore :: TO: Mark Brown :: CC: Kukjin Kim --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 08/12] i2c: Only descend into i2c directory when CONFIG_I2C is set
Hi, [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.7-rc3 next-20160609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andrew-F-Davis/gpio-Only-descend-into-gpio-directory-when-CONFIG_GPIOLIB-is-set/20160614-061705 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next config: m32r-m32104ut_defconfig (attached as .config) compiler: m32r-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=m32r All errors (new ones prefixed by >>): >> ERROR: "__i2c_board_list" [drivers/i2c/i2c-core.ko] undefined! >> ERROR: "__i2c_board_lock" [drivers/i2c/i2c-core.ko] undefined! >> ERROR: "__i2c_first_dynamic_bus_num" [drivers/i2c/i2c-core.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: convert 'iommu_alloc failed' messages to dynamic debug
On 06/13/2016 06:51 PM, Benjamin Herrenschmidt wrote: Approximate wasn't a great choice of word but what I meant is: - The size doesn't mean you can do an allocation that size (pools layout etc..) - And it might be shared with another device (though less likely these days). Ah, yup - ok, now I get it; thanks. -- Mauricio Faria de Oliveira IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 12/18] limits: track RLIMIT_MEMLOCK actual max
On 06/13/16 20:43, Alex Williamson wrote: > On Mon, 13 Jun 2016 22:44:19 +0300 > Topi Miettinen wrote: > >> Track maximum size of locked memory, presented in /proc/self/limits. >> >> Signed-off-by: Topi Miettinen >> --- >> arch/ia64/kernel/perfmon.c | 1 + >> arch/powerpc/kvm/book3s_64_vio.c | 1 + >> arch/powerpc/mm/mmu_context_iommu.c| 1 + >> drivers/infiniband/core/umem.c | 1 + >> drivers/infiniband/hw/hfi1/user_pages.c| 1 + >> drivers/infiniband/hw/qib/qib_user_pages.c | 1 + >> drivers/infiniband/hw/usnic/usnic_uiom.c | 2 ++ >> drivers/misc/mic/scif/scif_rma.c | 1 + >> drivers/vfio/vfio_iommu_spapr_tce.c| 2 ++ >> drivers/vfio/vfio_iommu_type1.c| 2 ++ >> include/linux/sched.h | 10 -- >> kernel/bpf/syscall.c | 6 ++ >> kernel/events/core.c | 1 + >> mm/mlock.c | 7 +++ >> mm/mmap.c | 3 +++ >> mm/mremap.c| 3 +++ >> 16 files changed, 41 insertions(+), 2 deletions(-) > ... >> >> diff --git a/drivers/vfio/vfio_iommu_type1.c >> b/drivers/vfio/vfio_iommu_type1.c >> index 2ba1942..4c6e7a3 100644 >> --- a/drivers/vfio/vfio_iommu_type1.c >> +++ b/drivers/vfio/vfio_iommu_type1.c >> @@ -312,6 +312,8 @@ static long vfio_pin_pages(unsigned long vaddr, long >> npage, >> } >> } >> >> +bump_rlimit(RLIMIT_MEMLOCK, (current->mm->locked_vm + i) << PAGE_SHIFT); >> + >> if (!rsvd) >> vfio_lock_acct(i); >> > > > Not all cases passing through here bump rlimit (see: rsvd), there's an > entire case above the other end of this closing bracket that does bump > rlimit but returns before here, and I wonder why we wouldn't just do > this in our vfio_lock_acct() accounting function anyway. Thanks, Yes, just make disable_hugepages case go to end of function. -Topi > > Alex > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/12] Remove unneeded build directory traversals
Hello all, I was building a kernel for x86 and noticed Make still descended into directories like drivers/gpu/drm/hisilicon, this seems kind of odd given nothing will be built here. It looks to be due to some directories being included in obj-y unconditionally instead of only when the relevant CONFIG_ is set. These patches are split by subsystem in-case, for some reason, a file in a directory does need to be built, I believe I have checked for all instances of this, but a quick review from some maintainers would be nice. Thanks, Andrew Andrew F. Davis (12): gpio: Only descend into gpio directory when CONFIG_GPIOLIB is set pwm: Only descend into pwm directory when CONFIG_PWM is set amba: Only descend into amba directory when CONFIG_ARM_AMBA is set NFC: Only descend into nfc directory when CONFIG_NFC is set macintosh: Only descend into directory when CONFIG_MACINTOSH_DRIVERS is set hsi: Only descend into hsi directory when CONFIG_HSI is set auxdisplay: Only descend into directory when CONFIG_AUXDISPLAY is set i2c: Only descend into i2c directory when CONFIG_I2C is set [media] Only descend into directory when CONFIG_MEDIA_SUPPORT is set lguest: Only descend into lguest directory when CONFIG_LGUEST is set mmc: Only descend into mmc directory when CONFIG_MMC is set leds: Only descend into leds directory when CONFIG_NEW_LEDS is set drivers/Makefile | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-) -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 10/12] lguest: Only descend into lguest directory when CONFIG_LGUEST is set
When CONFIG_LGUEST is not set make will still descend into the lguest directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 19305e0..b178e2f 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -122,7 +122,7 @@ obj-$(CONFIG_ACCESSIBILITY) += accessibility/ obj-$(CONFIG_ISDN) += isdn/ obj-$(CONFIG_EDAC) += edac/ obj-$(CONFIG_EISA) += eisa/ -obj-y += lguest/ +obj-$(CONFIG_LGUEST) += lguest/ obj-$(CONFIG_CPU_FREQ) += cpufreq/ obj-$(CONFIG_CPU_IDLE) += cpuidle/ obj-y += mmc/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 05/12] macintosh: Only descend into directory when CONFIG_MACINTOSH_DRIVERS is set
When CONFIG_MACINTOSH_DRIVERS is not set make will still descend into the macintosh directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 4a885d8..5be5619 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -73,7 +73,7 @@ obj-$(CONFIG_LIBNVDIMM) += nvdimm/ obj-$(CONFIG_DEV_DAX) += dax/ obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/ obj-$(CONFIG_NUBUS)+= nubus/ -obj-y += macintosh/ +obj-$(CONFIG_MACINTOSH_DRIVERS)+= macintosh/ obj-$(CONFIG_IDE) += ide/ obj-$(CONFIG_SCSI) += scsi/ obj-y += nvme/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 08/12] i2c: Only descend into i2c directory when CONFIG_I2C is set
When CONFIG_I2C is not set make will still descend into the i2c directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index b4202d0..2d99d4e 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -107,7 +107,8 @@ obj-$(CONFIG_SERIO) += input/serio/ obj-$(CONFIG_GAMEPORT) += input/gameport/ obj-$(CONFIG_INPUT)+= input/ obj-$(CONFIG_RTC_LIB) += rtc/ -obj-y += i2c/ media/ +obj-$(CONFIG_I2C) += i2c/ +obj-y += media/ obj-$(CONFIG_PPS) += pps/ obj-$(CONFIG_PTP_1588_CLOCK) += ptp/ obj-$(CONFIG_W1) += w1/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 12/12] leds: Only descend into leds directory when CONFIG_NEW_LEDS is set
When CONFIG_NEW_LEDS is not set make will still descend into the leds directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 567e32c..fa514d5 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -127,7 +127,7 @@ obj-$(CONFIG_CPU_FREQ) += cpufreq/ obj-$(CONFIG_CPU_IDLE) += cpuidle/ obj-$(CONFIG_MMC) += mmc/ obj-$(CONFIG_MEMSTICK) += memstick/ -obj-y += leds/ +obj-$(CONFIG_NEW_LEDS) += leds/ obj-$(CONFIG_INFINIBAND) += infiniband/ obj-$(CONFIG_SGI_SN) += sn/ obj-y += firmware/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 01/12] gpio: Only descend into gpio directory when CONFIG_GPIOLIB is set
When CONFIG_GPIOLIB is not set make will still descend into the gpio directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 0b6f3d6..50f6131 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -12,7 +12,7 @@ obj-$(CONFIG_GENERIC_PHY) += phy/ # GPIO must come after pinctrl as gpios may need to mux pins etc obj-$(CONFIG_PINCTRL) += pinctrl/ -obj-y += gpio/ +obj-$(CONFIG_GPIOLIB) += gpio/ obj-y += pwm/ obj-$(CONFIG_PCI) += pci/ obj-$(CONFIG_PARISC) += parisc/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 06/12] hsi: Only descend into hsi directory when CONFIG_HSI is set
When CONFIG_HSI is not set make will still descend into the hsi directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 5be5619..78162ba 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -82,7 +82,7 @@ obj-$(CONFIG_TARGET_CORE) += target/ obj-$(CONFIG_MTD) += mtd/ obj-$(CONFIG_SPI) += spi/ obj-$(CONFIG_SPMI) += spmi/ -obj-y += hsi/ +obj-$(CONFIG_HSI) += hsi/ obj-y += net/ obj-$(CONFIG_ATM) += atm/ obj-$(CONFIG_FUSION) += message/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 04/12] NFC: Only descend into nfc directory when CONFIG_NFC is set
When CONFIG_NFC is not set make will still descend into the nfc directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 841c2dc..4a885d8 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -64,7 +64,11 @@ obj-$(CONFIG_FB_INTEL) += video/fbdev/intelfb/ obj-$(CONFIG_PARPORT) += parport/ obj-$(CONFIG_NVM) += lightnvm/ -obj-y += base/ block/ misc/ mfd/ nfc/ +obj-y += base/ +obj-y += block/ +obj-y += misc/ +obj-y += mfd/ +obj-$(CONFIG_NFC) += nfc/ obj-$(CONFIG_LIBNVDIMM)+= nvdimm/ obj-$(CONFIG_DEV_DAX) += dax/ obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 09/12] [media] Only descend into directory when CONFIG_MEDIA_SUPPORT is set
When CONFIG_MEDIA_SUPPORT is not set make will still descend into the media directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 2d99d4e..19305e0 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -108,7 +108,7 @@ obj-$(CONFIG_GAMEPORT) += input/gameport/ obj-$(CONFIG_INPUT)+= input/ obj-$(CONFIG_RTC_LIB) += rtc/ obj-$(CONFIG_I2C) += i2c/ -obj-y += media/ +obj-$(CONFIG_MEDIA_SUPPORT)+= media/ obj-$(CONFIG_PPS) += pps/ obj-$(CONFIG_PTP_1588_CLOCK) += ptp/ obj-$(CONFIG_W1) += w1/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 11/12] mmc: Only descend into mmc directory when CONFIG_MMC is set
When CONFIG_MMC is not set make will still descend into the mmc directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index b178e2f..567e32c 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -125,7 +125,7 @@ obj-$(CONFIG_EISA) += eisa/ obj-$(CONFIG_LGUEST) += lguest/ obj-$(CONFIG_CPU_FREQ) += cpufreq/ obj-$(CONFIG_CPU_IDLE) += cpuidle/ -obj-y += mmc/ +obj-$(CONFIG_MMC) += mmc/ obj-$(CONFIG_MEMSTICK) += memstick/ obj-y += leds/ obj-$(CONFIG_INFINIBAND) += infiniband/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 03/12] amba: Only descend into amba directory when CONFIG_ARM_AMBA is set
When CONFIG_ARM_AMBA is not set make will still descend into the amba directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 01e707b..841c2dc 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -28,7 +28,7 @@ obj-$(CONFIG_SFI) += sfi/ # PnP must come after ACPI since it will eventually need to check if acpi # was used and do nothing if so obj-$(CONFIG_PNP) += pnp/ -obj-y += amba/ +obj-$(CONFIG_ARM_AMBA) += amba/ # Many drivers will want to use DMA so this has to be made available # really early. obj-$(CONFIG_DMADEVICES) += dma/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 02/12] pwm: Only descend into pwm directory when CONFIG_PWM is set
When CONFIG_PWM is not set make will still descend into the pwm directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 50f6131..01e707b 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -13,7 +13,7 @@ obj-$(CONFIG_GENERIC_PHY) += phy/ # GPIO must come after pinctrl as gpios may need to mux pins etc obj-$(CONFIG_PINCTRL) += pinctrl/ obj-$(CONFIG_GPIOLIB) += gpio/ -obj-y += pwm/ +obj-$(CONFIG_PWM) += pwm/ obj-$(CONFIG_PCI) += pci/ obj-$(CONFIG_PARISC) += parisc/ obj-$(CONFIG_RAPIDIO) += rapidio/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 07/12] auxdisplay: Only descend into directory when CONFIG_AUXDISPLAY is set
When CONFIG_AUXDISPLAY is not set make will still descend into the auxdisplay directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 78162ba..b4202d0 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -90,7 +90,7 @@ obj-y += firewire/ obj-$(CONFIG_UIO) += uio/ obj-$(CONFIG_VFIO) += vfio/ obj-y += cdrom/ -obj-y += auxdisplay/ +obj-$(CONFIG_AUXDISPLAY) += auxdisplay/ obj-$(CONFIG_PCCARD) += pcmcia/ obj-$(CONFIG_DIO) += dio/ obj-$(CONFIG_SBUS) += sbus/ -- 2.8.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC 12/18] limits: track RLIMIT_MEMLOCK actual max
Track maximum size of locked memory, presented in /proc/self/limits.
Signed-off-by: Topi Miettinen
---
arch/ia64/kernel/perfmon.c | 1 +
arch/powerpc/kvm/book3s_64_vio.c | 1 +
arch/powerpc/mm/mmu_context_iommu.c| 1 +
drivers/infiniband/core/umem.c | 1 +
drivers/infiniband/hw/hfi1/user_pages.c| 1 +
drivers/infiniband/hw/qib/qib_user_pages.c | 1 +
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 ++
drivers/misc/mic/scif/scif_rma.c | 1 +
drivers/vfio/vfio_iommu_spapr_tce.c| 2 ++
drivers/vfio/vfio_iommu_type1.c| 2 ++
include/linux/sched.h | 10 --
kernel/bpf/syscall.c | 6 ++
kernel/events/core.c | 1 +
mm/mlock.c | 7 +++
mm/mmap.c | 3 +++
mm/mremap.c| 3 +++
16 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 2436ad5..d05ff3b 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -2341,6 +2341,7 @@ pfm_smpl_buffer_alloc(struct task_struct *task, struct
file *filp, pfm_context_t
ctx->ctx_smpl_vaddr = (void *)vma->vm_start;
*(unsigned long *)user_vaddr = vma->vm_start;
+ task_bump_rlimit(task, RLIMIT_MEMLOCK, size);
return 0;
error:
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 18cf6d1..2714bbf 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -71,6 +71,7 @@ static long kvmppc_account_memlimit(unsigned long stt_pages,
bool inc)
ret = -ENOMEM;
else
current->mm->locked_vm += stt_pages;
+ bump_rlimit(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
} else {
if (WARN_ON_ONCE(stt_pages > current->mm->locked_vm))
stt_pages = current->mm->locked_vm;
diff --git a/arch/powerpc/mm/mmu_context_iommu.c
b/arch/powerpc/mm/mmu_context_iommu.c
index da6a216..ace8b9d 100644
--- a/arch/powerpc/mm/mmu_context_iommu.c
+++ b/arch/powerpc/mm/mmu_context_iommu.c
@@ -46,6 +46,7 @@ static long mm_iommu_adjust_locked_vm(struct mm_struct *mm,
ret = -ENOMEM;
else
mm->locked_vm += npages;
+ bump_rlimit(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
} else {
if (WARN_ON_ONCE(npages > mm->locked_vm))
npages = mm->locked_vm;
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index fe4d2e1..9bd9638 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -224,6 +224,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context,
unsigned long addr,
ret = 0;
+ bump_rlimit(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
out:
if (ret < 0) {
if (need_release)
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
b/drivers/infiniband/hw/hfi1/user_pages.c
index 88e10b5f..096910d7 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -111,6 +111,7 @@ int hfi1_acquire_user_pages(unsigned long vaddr, size_t
npages, bool writable,
down_write(¤t->mm->mmap_sem);
current->mm->pinned_vm += ret;
+ bump_rlimit(RLIMIT_MEMLOCK, current->mm->pinned_vm << PAGE_SHIFT);
up_write(¤t->mm->mmap_sem);
return ret;
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c
b/drivers/infiniband/hw/qib/qib_user_pages.c
index 2d2b94f..06f93de 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -74,6 +74,7 @@ static int __qib_get_user_pages(unsigned long start_page,
size_t num_pages,
}
current->mm->pinned_vm += num_pages;
+ bump_rlimit(RLIMIT_MEMLOCK, current->mm->pinned_vm << PAGE_SHIFT);
ret = 0;
goto bail;
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c
b/drivers/infiniband/hw/usnic/usnic_uiom.c
index a0b6ebe..83409dc 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -178,6 +178,8 @@ static int usnic_uiom_get_pages(unsigned long addr, size_t
size, int writable,
ret = 0;
}
+ bump_rlimit(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
out:
if (ret < 0)
usnic_uiom_put_pages(chunk_list, 0);
diff --git a/drivers/misc/mic/scif/scif_rma.c b/drivers/misc/mic/scif/scif_rma.c
index e0203b1..1d6315a 100644
--- a/drivers/misc/mic/scif/scif_rma.c
+++ b/drivers/misc/mic/scif/scif_rma.c
@@ -306,6 +306,7 @@ static inline int __scif_check_inc_pinned_vm(struct
mm_struct *mm,
return -ENOMEM;
}
mm->pinned_vm = locked;
+ bump_rlimit(RLIMIT_MEMLOCK, locked <<
Re: [PATCH] powerpc: convert 'iommu_alloc failed' messages to dynamic debug
On Mon, 2016-06-13 at 18:43 -0300, Mauricio Faria de Oliveira wrote: > Hi Ben, > > On 06/13/2016 06:26 PM, Benjamin Herrenschmidt wrote: > > I've been thinking about this a bit... it might be worthwhile adding > > a dma_* call to query the approximate size of the IOMMU window, as > > a way for the device to adjust its requirements dynamically. > > Ok, cool; something like it was one of the options being discussed here. > > What do you mean by 'approximate'? Maybe the size of 'free regions' in > the pools? -- not sure because iiuic the window size is static / 2 gig, > so didn't get why (or of what) to provide an approximation (for). Approximate wasn't a great choice of word but what I meant is: - The size doesn't mean you can do an allocation that size (pools layout etc..) - And it might be shared with another device (though less likely these days). > > Another option would be to use a dma_attr for silencing mapping errors > > which NVME could use provided it does handle them gracefully ... > > Ah, that's new. Interesting. Thanks for suggestion! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 10/11] cpuidle/powernv: Add support for POWER ISA v3 idle states
On Wed, 2016-06-08 at 11:54 -0500, Shreyas B. Prabhu wrote:
>
> /*
> * States for dedicated partition case.
> */
> @@ -167,6 +183,8 @@ static int powernv_add_idle_states(void)
> int nr_idle_states = 1; /* Snooze */
> int dt_idle_states;
> u32 *latency_ns, *residency_ns, *flags;
> + u64 *psscr_val = NULL;
> + const char *names[CPUIDLE_STATE_MAX];
> int i, rc;
>
> /* Currently we have snooze statically defined */
> @@ -199,12 +217,41 @@ static int powernv_add_idle_states(void)
> goto out_free_latency;
> }
>
> + rc = of_property_read_string_array(power_mgt,
> + "ibm,cpu-idle-state-names", names,
> + dt_idle_states);
Ok so from this I assume that dt_idle_states is the number of entries,
which has been checked properly to be < CPUIDLE_STATE_MAX correct ?
Beause ...
> + if (rc < 0) {
> + pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-names in
> DT\n");
> + goto out_free_latency;
> + }
> +
> + /*
> + * If the idle states use stop instruction, probe for psscr values
> + * which are necessary to specify required stop level.
> + */
> + if (flags[0] & (OPAL_PM_STOP_INST_FAST | OPAL_PM_STOP_INST_DEEP)) {
> + psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val),
> + GFP_KERNEL);
> + rc = of_property_read_u64_array(power_mgt,
> + "ibm,cpu-idle-state-psscr",
> + psscr_val, dt_idle_states);
Here, psscr val is only one u64 ... shouldn't you kmalloc sizeof(..) *
dt_idle_states ?
> + if (rc) {
> + pr_warn("cpuidle-powernv: missing
> ibm,cpu-idle-states-psscr in DT\n");
> + goto out_free_psscr;
> + }
> + }
> residency_ns = kzalloc(sizeof(*residency_ns) * dt_idle_states,
> GFP_KERNEL);
Just like we do here
> rc = of_property_read_u32_array(power_mgt,
> "ibm,cpu-idle-state-residency-ns", residency_ns, dt_idle_states);
> for (i = 0; i < dt_idle_states; i++) {
> -
> + /*
> + * If an idle state has exit latency beyond
> + * POWERNV_THRESHOLD_LATENCY_NS then don't use it
> + * in cpu-idle.
> + */
> + if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
> + continue;
> /*
> * Cpuidle accepts exit_latency and target_residency in us.
> * Use default target_residency values if f/w does not expose
> it.
> @@ -216,6 +263,16 @@ static int powernv_add_idle_states(void)
> powernv_states[nr_idle_states].flags = 0;
> powernv_states[nr_idle_states].target_residency = 100;
> powernv_states[nr_idle_states].enter = &nap_loop;
> + } else if ((flags[i] & OPAL_PM_STOP_INST_FAST) &&
> + !(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
> + strncpy(powernv_states[nr_idle_states].name,
> + names[i], CPUIDLE_NAME_LEN);
> + strncpy(powernv_states[nr_idle_states].desc,
> + names[i], CPUIDLE_NAME_LEN);
> + powernv_states[nr_idle_states].flags = 0;
> +
> + powernv_states[nr_idle_states].enter = stop_loop;
> + stop_psscr_table[nr_idle_states] = psscr_val[i];
> }
>
> /*
> @@ -231,6 +288,16 @@ static int powernv_add_idle_states(void)
> powernv_states[nr_idle_states].flags =
> CPUIDLE_FLAG_TIMER_STOP;
> powernv_states[nr_idle_states].target_residency =
> 30;
> powernv_states[nr_idle_states].enter = &fastsleep_loop;
> + } else if ((flags[i] & OPAL_PM_STOP_INST_DEEP) &&
> + (flags[i] & OPAL_PM_TIMEBASE_STOP)) {
> + strncpy(powernv_states[nr_idle_states].name,
> + names[i], CPUIDLE_NAME_LEN);
> + strncpy(powernv_states[nr_idle_states].desc,
> + names[i], CPUIDLE_NAME_LEN);
> +
> + powernv_states[nr_idle_states].flags =
> CPUIDLE_FLAG_TIMER_STOP;
> + powernv_states[nr_idle_states].enter = stop_loop;
> + stop_psscr_table[nr_idle_states] = psscr_val[i];
> }
> #endif
> powernv_states[nr_idle_states].exit_latency =
> @@ -245,6 +312,8 @@ static int powernv_add_idle_states(void)
> }
>
> kfree(residency_ns);
> +out_free_psscr:
> + kfree(psscr_val);
> out_free_latency:
> kfree(latency_ns);
> out_free_flags:
___
Linuxppc-dev mailing list
Linux
Re: [PATCH] powerpc: convert 'iommu_alloc failed' messages to dynamic debug
Hi Ben, On 06/13/2016 06:26 PM, Benjamin Herrenschmidt wrote: I've been thinking about this a bit... it might be worthwhile adding a dma_* call to query the approximate size of the IOMMU window, as a way for the device to adjust its requirements dynamically. Ok, cool; something like it was one of the options being discussed here. What do you mean by 'approximate'? Maybe the size of 'free regions' in the pools? -- not sure because iiuic the window size is static / 2 gig, so didn't get why (or of what) to provide an approximation (for). Another option would be to use a dma_attr for silencing mapping errors which NVME could use provided it does handle them gracefully ... Ah, that's new. Interesting. Thanks for suggestion! -- Mauricio Faria de Oliveira IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: convert 'iommu_alloc failed' messages to dynamic debug
On Mon, 2016-06-13 at 10:27 -0300, Mauricio Faria de Oliveira wrote: > Hi Ben, > > On 06/11/2016 08:02 PM, Benjamin Herrenschmidt wrote: > > I'm not fan of this. This is a very useful message to diagnose why, > > for example, your network adapter is not working properly. > > > > A lot of drivers don't deal well with IOMMU errors. > > > > The fact that NVME trigger these is a problem that needs to be > > solved > > differently. > > Ok, I understand your points. > > Thanks for the review -- helps in setting another direction. I've been thinking about this a bit... it might be worthwhile adding a dma_* call to query the approximate size of the IOMMU window, as a way for the device to adjust its requirements dynamically. Another option would be to use a dma_attr for silencing mapping errors which NVME could use provided it does handle them gracefully ... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 09/11] cpuidle/powernv: Use CPUIDLE_STATE_MAX instead of MAX_POWERNV_IDLE_STATES
On Monday, June 13, 2016 05:01:50 PM Daniel Lezcano wrote: > On Wed, Jun 08, 2016 at 11:54:29AM -0500, Shreyas B. Prabhu wrote: > > Use cpuidle's CPUIDLE_STATE_MAX macro instead of powernv specific > > MAX_POWERNV_IDLE_STATES. > > > > Cc: Rafael J. Wysocki > > Cc: Daniel Lezcano > > Cc: linux...@vger.kernel.org > > Suggested-by: Daniel Lezcano > > Signed-off-by: Shreyas B. Prabhu > > --- > > Acked-by: Daniel Lezcano Since this seems to depend on some other patches in the series, I'm expecting it to go in along with the patches it depends on. Thanks, Rafael ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/14] run seccomp after ptrace
(Oops, forgot to send this series through the lsm list...) On Thu, Jun 9, 2016 at 2:01 PM, Kees Cook wrote: > There has been a long-standing (and documented) issue with seccomp > where ptrace can be used to change a syscall out from under seccomp. > This is a problem for containers and other wider seccomp filtered > environments where ptrace needs to remain available, as it allows > for an escape of the seccomp filter. > > Since the ptrace attack surface is available for any allowed syscall, > moving seccomp after ptrace doesn't increase the actually available > attack surface. And this actually improves tracing since, for > example, tracers will be notified of syscall entry before seccomp > sends a SIGSYS, which makes debugging filters much easier. > > The per-architecture changes do make one (hopefully small) > semantic change, which is that since ptrace comes first, it may > request a syscall be skipped. Running seccomp after this doesn't > make sense, so if ptrace wants to skip a syscall, it will bail > out early similarly to how seccomp was. This means that skipped > syscalls will not be fed through audit, though that likely means > we're actually avoiding noise this way. > > This series first cleans up seccomp to remove the now unneeded > two-phase entry, fixes the SECCOMP_RET_TRACE hole (same as the > ptrace hole above), and then reorders seccomp after ptrace on > each architecture. Has anyone else had a chance to review this series? I'd like to get it landed in -next as early as possible in case there are unexpected problems... -Kees -- Kees Cook Chrome OS & Brillo Security ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 12/18] limits: track RLIMIT_MEMLOCK actual max
On Mon, 13 Jun 2016 22:44:19 +0300 Topi Miettinen wrote: > Track maximum size of locked memory, presented in /proc/self/limits. > > Signed-off-by: Topi Miettinen > --- > arch/ia64/kernel/perfmon.c | 1 + > arch/powerpc/kvm/book3s_64_vio.c | 1 + > arch/powerpc/mm/mmu_context_iommu.c| 1 + > drivers/infiniband/core/umem.c | 1 + > drivers/infiniband/hw/hfi1/user_pages.c| 1 + > drivers/infiniband/hw/qib/qib_user_pages.c | 1 + > drivers/infiniband/hw/usnic/usnic_uiom.c | 2 ++ > drivers/misc/mic/scif/scif_rma.c | 1 + > drivers/vfio/vfio_iommu_spapr_tce.c| 2 ++ > drivers/vfio/vfio_iommu_type1.c| 2 ++ > include/linux/sched.h | 10 -- > kernel/bpf/syscall.c | 6 ++ > kernel/events/core.c | 1 + > mm/mlock.c | 7 +++ > mm/mmap.c | 3 +++ > mm/mremap.c| 3 +++ > 16 files changed, 41 insertions(+), 2 deletions(-) ... > > diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c > index 2ba1942..4c6e7a3 100644 > --- a/drivers/vfio/vfio_iommu_type1.c > +++ b/drivers/vfio/vfio_iommu_type1.c > @@ -312,6 +312,8 @@ static long vfio_pin_pages(unsigned long vaddr, long > npage, > } > } > > + bump_rlimit(RLIMIT_MEMLOCK, (current->mm->locked_vm + i) << PAGE_SHIFT); > + > if (!rsvd) > vfio_lock_acct(i); > Not all cases passing through here bump rlimit (see: rsvd), there's an entire case above the other end of this closing bracket that does bump rlimit but returns before here, and I wonder why we wouldn't just do this in our vfio_lock_acct() accounting function anyway. Thanks, Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/8] kexec_file: Generalize kexec_add_buffer.
Hi Dave,
Am Montag, 13 Juni 2016, 16:08:19 schrieb Thiago Jung Bauermann:
> Am Montag, 13 Juni 2016, 15:29:39 schrieb Dave Young:
> > On 06/12/16 at 12:10am, Thiago Jung Bauermann wrote:
> > > Allow architectures to specify different memory walking functions for
> > > kexec_add_buffer. Intel uses iomem to track reserved memory ranges,
> > > but PowerPC uses the memblock subsystem.
> >
> > Can the crashk_res be inserted to iomem_resource so that only one
> > weak function for system ram is needed?
>
> Sorry, it's not clear to me what you mean by inserting crashk_res into
> iomem_resource, but I can add a bool for_crashkernel to
> arch_walk_system_ram so that it can decide which kind of memory to
> traverse.
This is the patch implementing that idea. What do you think?
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
kexec_file: Generalize kexec_add_buffer.
Allow architectures to specify different memory walking functions for
kexec_add_buffer. Intel uses iomem to track reserved memory ranges,
but PowerPC uses the memblock subsystem.
Signed-off-by: Thiago Jung Bauermann
Cc: Eric Biederman
Cc: ke...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e8acb2b43dd9..be18cb80c14e 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -315,6 +315,9 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr
*ehdr,
Elf_Shdr *sechdrs, unsigned int relsec);
int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr
*sechdrs,
unsigned int relsec);
+int __weak arch_walk_system_ram(bool for_crashkernel, unsigned long start,
+ unsigned long end, bool top_down, void *data,
+ int (*func)(u64, u64, void *));
void arch_kexec_protect_crashkres(void);
void arch_kexec_unprotect_crashkres(void);
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b6eec7527e9f..5d0a6a20b12b 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -428,6 +428,38 @@ static int locate_mem_hole_callback(u64 start, u64 end,
void *arg)
return locate_mem_hole_bottom_up(start, end, kbuf);
}
+/**
+ * arch_walk_system_ram - call func(data) on free memory regions
+ * @for_crashkernel: Is this for the crash kernel?
+ * @start: Don't visit memory regions below this address.
+ * @end: Don't visit memory regions above this address.
+ * @top_down: Starts from the highest address?
+ * @data: Argument to pass to @func.
+ * @func: Function to call for each memory region.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int __weak arch_walk_system_ram(bool for_crashkernel, unsigned long start,
+ unsigned long end, bool top_down, void *data,
+ int (*func)(u64, u64, void *))
+{
+ int ret;
+
+ if (for_crashkernel)
+ ret = walk_iomem_res_desc(crashk_res.desc,
+ IORESOURCE_SYSTEM_RAM |
IORESOURCE_BUSY,
+ start, end, data, func);
+ else
+ ret = walk_system_ram_res(start, end, data, func);
+
+ if (ret != 1) {
+ /* A suitable memory range could not be found for buffer */
+ return -EADDRNOTAVAIL;
+ }
+
+ return 0;
+}
+
/*
* Helper function for placing a buffer in a kexec segment. This assumes
* that kexec_mutex is held.
@@ -473,17 +505,14 @@ int kexec_add_buffer(struct kimage *image, char *buffer,
unsigned long bufsz,
/* Walk the RAM ranges and allocate a suitable range for the buffer */
if (image->type == KEXEC_TYPE_CRASH)
- ret = walk_iomem_res_desc(crashk_res.desc,
- IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
- crashk_res.start, crashk_res.end, kbuf,
- locate_mem_hole_callback);
+ ret = arch_walk_system_ram(true, crashk_res.start,
+ crashk_res.end, top_down, kbuf,
+ locate_mem_hole_callback);
else
- ret = walk_system_ram_res(0, -1, kbuf,
- locate_mem_hole_callback);
- if (ret != 1) {
- /* A suitable memory range could not be found for buffer */
- return -EADDRNOTAVAIL;
- }
+ ret = arch_walk_system_ram(false, 0, -1, top_down, kbuf,
+ locate_mem_hole_callback);
+ if (ret)
+ return ret;
/* Found a suitable memory range */
ksegment = &image->segment[image->nr_segments];
___
Linuxppc-dev mailing list
Lin
Re: [PATCH 2/8] kexec_file: Generalize kexec_add_buffer.
Hello Dave,
Thanks for the quick review and for your comments.
I'll separate the change to add arch_walk_system_ram and the change to add
kexec_locate_mem_hole into different patches, and add error handling for
KEXEC_ON_CRASH.
Am Montag, 13 Juni 2016, 15:29:39 schrieb Dave Young:
> On 06/12/16 at 12:10am, Thiago Jung Bauermann wrote:
> > Allow architectures to specify different memory walking functions for
> > kexec_add_buffer. Intel uses iomem to track reserved memory ranges,
> > but PowerPC uses the memblock subsystem.
>
> Can the crashk_res be inserted to iomem_resource so that only one
> weak function for system ram is needed?
Sorry, it's not clear to me what you mean by inserting crashk_res into
iomem_resource, but I can add a bool for_crashkernel to arch_walk_system_ram
so that it can decide which kind of memory to traverse, so the default
implementation of kexec_file.c would be:
int __weak arch_walk_system_ram(bool for_crashkernel, unsigned long start,
unsigned long end, bool top_down,
void *data,
int (*func)(u64, u64, void *))
{
int ret;
if (for_crashkernel)
ret = walk_iomem_res_desc(crashk_res.desc,
IORESOURCE_SYSTEM_RAM |
IORESOURCE_BUSY,
start, end, data, func);
else
ret = walk_system_ram_res(start, end, data, func);
if (ret != 1) {
/* A suitable memory range could not be found for buffer */
return -EADDRNOTAVAIL;
}
}
and kexec_add_buffer / kexec_locate_mem_hole would call it with:
if (image->type == KEXEC_TYPE_CRASH)
ret = arch_walk_system_ram(true, crashk_res.start,
crashk_res.end, top_down, &buf,
locate_mem_hole_callback);
else
ret = arch_walk_system_ram(false, 0, -1, top_down, &buf,
locate_mem_hole_callback);
What do you think?
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Kernel 4.7: PAGE_GUARDED and _PAGE_NO_CACHE
Hi Ben, I could send you a patch but it doesn't work with the three PowerPC commits. I think we have to fix the boot issue at first. After that we can integrate the first patch for the Nemo board. Cheers, Christian On 13 June 2016 at 10:19 AM, Benjamin Herrenschmidt wrote: > > The right way to not have this problem anymore is to cleanup and > submit your patches upstream so they don't break all the time :-) > > Cheers, > Ben. > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Rational for having CONFIG_FB_RADEON=m
Dear all, Debian decided to switch to using CONFIG_FB_RADEON=m (Mach64 and Rage128 are still built-in). Since CONFIG_FB_OF=y and can never be a module, this means for PowerMac+radeon users that Open Firmware is always the implementation taken from the Frame Buffer: [0.740726] Using unsupported 800x600 ATY,RockHopper2_A at 9c008000, depth=8, pitch=1024 [0.750458] Console: switching to colour frame buffer device 100x37 [0.759850] fb0: Open Firmware frame buffer device on /pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0 And: $ cat /proc/fb 0 OFfb ATY,RockHo Since also `radeonfb` is not capable of kicking out `offb` this means I cannot `modprobe radeonfb`: [ 96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007) [ 96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 0x9800-0x9fff pref] [ 96.551531] radeonfb (:00:10.0): cannot request region 0. [ 96.551545] radeonfb: probe of :00:10.0 failed with error -16 So I have two options: 1. Try to convince debian-kernel team to switch back to CONFIG_FB_RADEON=y (this will conflict with results from: https://bugs.debian.org/614221) 2. Try to fix `radeonfb` so that it is able to kick offb out of the way. Eg: https://lists.freedesktop.org/archives/dri-devel/2010-August/002907.html From my understanding it would make sense to go for (2), since it would allow for proper support for CONFIG_FB_RADEON=m on PowerMac. In this case, would such patch be accepted ? Thanks ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 10/11] cpuidle/powernv: Add support for POWER ISA v3 idle states
On Wed, Jun 08, 2016 at 11:54:30AM -0500, Shreyas B. Prabhu wrote:
> POWER ISA v3 defines a new idle processor core mechanism. In summary,
> a) new instruction named stop is added.
> b) new per thread SPR named PSSCR is added which controls the behavior
> of stop instruction.
>
> Supported idle states and value to be written to PSSCR register to enter
> any idle state is exposed via ibm,cpu-idle-state-names and
> ibm,cpu-idle-state-psscr respectively. To enter an idle state,
> platform provided power_stop() needs to be invoked with the appropriate
> PSSCR value.
>
> This patch adds support for this new mechanism in cpuidle powernv driver.
>
> Cc: Rafael J. Wysocki
> Cc: Daniel Lezcano
> Cc: Rob Herring
> Cc: Lorenzo Pieralisi
> Cc: linux...@vger.kernel.org
> Cc: Michael Ellerman
> Cc: Paul Mackerras
> Cc: linuxppc-dev@lists.ozlabs.org
> Reviewed-by: Gautham R. Shenoy
> Signed-off-by: Shreyas B. Prabhu
> ---
[ ... ]
> + rc = of_property_read_string_array(power_mgt,
> +"ibm,cpu-idle-state-names", names,
> +dt_idle_states);
> + if (rc < 0) {
> + pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-names in
> DT\n");
> + goto out_free_latency;
> + }
> +
> + /*
> + * If the idle states use stop instruction, probe for psscr values
> + * which are necessary to specify required stop level.
> + */
> + if (flags[0] & (OPAL_PM_STOP_INST_FAST | OPAL_PM_STOP_INST_DEEP)) {
> + psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val),
> + GFP_KERNEL);
if (!psscr_val) check missing.
> + rc = of_property_read_u64_array(power_mgt,
> + "ibm,cpu-idle-state-psscr",
> + psscr_val, dt_idle_states);
> + if (rc) {
> + pr_warn("cpuidle-powernv: missing
> ibm,cpu-idle-states-psscr in DT\n");
> + goto out_free_psscr;
> + }
> + }
> residency_ns = kzalloc(sizeof(*residency_ns) * dt_idle_states,
> GFP_KERNEL);
if (!residency_ns) check missing.
I suppose the code is relying on 'of_property_read_u32_array' to check it,
right ?
-- Daniel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 09/11] cpuidle/powernv: Use CPUIDLE_STATE_MAX instead of MAX_POWERNV_IDLE_STATES
On Wed, Jun 08, 2016 at 11:54:29AM -0500, Shreyas B. Prabhu wrote: > Use cpuidle's CPUIDLE_STATE_MAX macro instead of powernv specific > MAX_POWERNV_IDLE_STATES. > > Cc: Rafael J. Wysocki > Cc: Daniel Lezcano > Cc: linux...@vger.kernel.org > Suggested-by: Daniel Lezcano > Signed-off-by: Shreyas B. Prabhu > --- Acked-by: Daniel Lezcano ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: convert 'iommu_alloc failed' messages to dynamic debug
Hi Ben, On 06/11/2016 08:02 PM, Benjamin Herrenschmidt wrote: I'm not fan of this. This is a very useful message to diagnose why, for example, your network adapter is not working properly. A lot of drivers don't deal well with IOMMU errors. The fact that NVME trigger these is a problem that needs to be solved differently. Ok, I understand your points. Thanks for the review -- helps in setting another direction. Kind regards, -- Mauricio Faria de Oliveira IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] crypto: vmx: Fix ABI detection
On Fri, Jun 10, 2016 at 04:47:02PM +1000, Anton Blanchard wrote:
> From: Anton Blanchard
>
> When calling ppc-xlate.pl, we pass it either linux-ppc64 or
> linux-ppc64le. The script however was expecting linux64le, a result
> of its OpenSSL origins. This means we aren't obeying the ppc64le
> ABIv2 rules.
>
> Fix this by checking for linux-ppc64le.
>
> Fixes: 5ca55738201c ("crypto: vmx - comply with ABIs that specify vrsave as
> reserved.")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Anton Blanchard
Both applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Kernel 4.7: PAGE_GUARDED and _PAGE_NO_CACHE
Hi All, Can I disable the new PowerPC features with Radix MMU Support (PPC_RADIX_MMU) [Y/n/?] (NEW) -> n ? I can't compile the RC3 without the PowerPC commits. Our kernel lost the mainline kernel support. Revert of the three PowerPC commits works but the kernel doesn't compile anymore. Cheers, Christian Sent from my iPhone > On 09 Jun 2016, at 14:13, Christian Zigotzky wrote: > > Michael, > > Thank you for your patch. I was able to compile the kernel but unfortunately > it doesn't boot. > > Do you have another hint or patch for me? > > Thanks in advance, > > Christian > >> On 09 June 2016 at 1:15 PM, Michael Ellerman wrote: >>> On Thu, 2016-06-09 at 10:48 +0200, Christian Zigotzky wrote: >>> >>> Shall I modify the workaround? Is the workaround for lack of the device >>> tree the problem? >> I don't think so. >> >> You could try this patch to try and isolate it: >> >> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h >> b/arch/powerpc/include/asm/book3s/64/pgtable.h >> index 88a5ecaa157b..ae2f2705e8a0 100644 >> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h >> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h >> @@ -251,7 +251,7 @@ extern unsigned long ioremap_bot; >> * PHB_IO_BASE = ISA_IO_BASE + 64K to ISA_IO_BASE + 2G, PHB IO spaces >> * IOREMAP_BASE = ISA_IO_BASE + 2G to VMALLOC_START + PGTABLE_RANGE >> */ >> -#define KERN_IO_START(KERN_VIRT_START + (KERN_VIRT_SIZE >> 1)) >> +#define KERN_IO_START(H_KERN_VIRT_START + (H_KERN_VIRT_SIZE >> 1)) >> #define FULL_IO_SIZE0x8000ul >> #define ISA_IO_BASE(KERN_IO_START) >> #define ISA_IO_END(KERN_IO_START + 0x1ul) >> >> >> cheers > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Kernel 4.7: PAGE_GUARDED and _PAGE_NO_CACHE
On Mon, 2016-06-13 at 09:14 +0100, Christian Zigotzky wrote: > Can I disable the new PowerPC features with > > Radix MMU Support (PPC_RADIX_MMU) [Y/n/?] (NEW) -> n > > ? > > I can't compile the RC3 without the PowerPC commits. Our kernel lost > the mainline kernel support. Revert of the three PowerPC commits > works but the kernel doesn't compile anymore. The right way to not have this problem anymore is to cleanup and submit your patches upstream so they don't break all the time :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 3/7] powerpc: use the new LED disk activity trigger
Hi all,
For consistency reasons this patch should be merged through LED tree,
but I need an ack from relevant maintainer. Benjamin, Michael, Paul?
Thanks,
Jacek Anaszewski
On 06/10/2016 07:59 AM, Stephan Linz wrote:
- dts: rename 'ide-disk' to 'disk-activity'
- defconfig: rename 'ADB_PMU_LED_IDE' to 'ADB_PMU_LED_DISK'
Cc: Joseph Jezak
Cc: Jörg Sommer
Signed-off-by: Stephan Linz
---
arch/powerpc/boot/dts/mpc8315erdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
arch/powerpc/configs/pmac32_defconfig | 2 +-
arch/powerpc/configs/ppc6xx_defconfig | 2 +-
drivers/macintosh/Kconfig | 13 ++---
drivers/macintosh/via-pmu-led.c | 4 ++--
8 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts
b/arch/powerpc/boot/dts/mpc8315erdb.dts
index 4354684..ca5139e 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -472,7 +472,7 @@
hdd {
gpios = <&mcu_pio 1 0>;
- linux,default-trigger = "ide-disk";
+ linux,default-trigger = "disk-activity";
};
};
};
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 2b4b653..e326139 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -496,7 +496,7 @@
hdd {
gpios = <&mcu_pio 1 0>;
- linux,default-trigger = "ide-disk";
+ linux,default-trigger = "disk-activity";
};
};
};
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts
b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 74b6a53..71842fc 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -480,7 +480,7 @@
hdd {
gpios = <&mcu_pio 1 0>;
- linux,default-trigger = "ide-disk";
+ linux,default-trigger = "disk-activity";
};
};
};
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts
b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index 3b5cbac..e442a29 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -446,7 +446,7 @@
hdd {
gpios = <&mcu_pio 1 0>;
- linux,default-trigger = "ide-disk";
+ linux,default-trigger = "disk-activity";
};
};
};
diff --git a/arch/powerpc/configs/pmac32_defconfig
b/arch/powerpc/configs/pmac32_defconfig
index ea8705f..3f6c9a6 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -158,7 +158,7 @@ CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_PMU=y
CONFIG_ADB_PMU_LED=y
-CONFIG_ADB_PMU_LED_IDE=y
+CONFIG_ADB_PMU_LED_DISK=y
CONFIG_PMAC_APM_EMU=m
CONFIG_PMAC_MEDIABAY=y
CONFIG_PMAC_BACKLIGHT=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig
b/arch/powerpc/configs/ppc6xx_defconfig
index 99ccbeba..1dde0be 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -442,7 +442,7 @@ CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_PMU=y
CONFIG_ADB_PMU_LED=y
-CONFIG_ADB_PMU_LED_IDE=y
+CONFIG_ADB_PMU_LED_DISK=y
CONFIG_PMAC_APM_EMU=y
CONFIG_PMAC_MEDIABAY=y
CONFIG_PMAC_BACKLIGHT=y
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 3e8b29e..d28690f 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -96,19 +96,18 @@ config ADB_PMU_LED
Support the front LED on Power/iBooks as a generic LED that can
be triggered by any of the supported triggers. To get the
behaviour of the old CONFIG_BLK_DEV_IDE_PMAC_BLINK, select this
- and the ide-disk LED trigger and configure appropriately through
- sysfs.
+ and the disk LED trigger and configure appropriately through sysfs.
-config ADB_PMU_LED_IDE
- bool "Use front LED as IDE LED by default"
+config ADB_PMU_LED_DISK
+ bool "Use front LED as DISK LED by default"
depends on ADB_PMU_LED
depends on LEDS_CLASS
depends on IDE_GD_ATA
select LEDS_TRIGGERS
- select LEDS_TRIGGER_IDE_DISK
+ select LEDS_TRIGGER_DISK
help
- This option makes the front LED default to the IDE trigger
- so that it blinks on IDE activity.
+ This option makes the front LED default to the disk trigger
+ so that it blinks on disk activity.
config PMAC_SMU
bool "Support for SMU based PowerMacs"
diff --git a/drivers/macintosh/via-pmu-led.c b/drivers/macintosh/via-pmu-led.c
index 19c3718..ae067ab 100644
--- a/drivers/macintosh/via-pmu-led.c
+++ b/drivers/macintosh/via-pmu-led.c
@@ -73,8 +73,8 @@ s
Re: [PATCH 2/8] kexec_file: Generalize kexec_add_buffer.
On 06/12/16 at 12:10am, Thiago Jung Bauermann wrote:
> Allow architectures to specify different memory walking functions for
> kexec_add_buffer. Intel uses iomem to track reserved memory ranges,
> but PowerPC uses the memblock subsystem.
Can the crashk_res be inserted to iomem_resource so that only one
weak function for system ram is needed?
>
> Also, factor kexec_locate_mem_hole out of kexec_add_buffer. It will be
> used by the PowerPC kexec_file_load implementation to find free memory
> for the purgatory stack.
>
> Cc: Eric Biederman
> Cc: ke...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> ---
> include/linux/kexec.h | 10 ++
> kernel/kexec_file.c | 96
> +--
> 2 files changed, 81 insertions(+), 25 deletions(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index e8acb2b43dd9..920e2cbe5bdd 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -210,6 +210,10 @@ extern asmlinkage long sys_kexec_load(unsigned long
> entry,
> struct kexec_segment __user *segments,
> unsigned long flags);
> extern int kernel_kexec(void);
> +int kexec_locate_mem_hole(struct kimage *image, unsigned long size,
> + unsigned long align, unsigned long start,
> + unsigned long end, bool top_down,
> + unsigned long *addr);
> extern int kexec_add_buffer(struct kimage *image, char *buffer,
> unsigned long bufsz, unsigned long memsz,
> unsigned long buf_align, unsigned long buf_min,
> @@ -315,6 +319,12 @@ int __weak arch_kexec_apply_relocations_add(const
> Elf_Ehdr *ehdr,
> Elf_Shdr *sechdrs, unsigned int relsec);
> int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr
> *sechdrs,
> unsigned int relsec);
> +int __weak arch_walk_iomem(unsigned long desc, unsigned long start,
> +unsigned long end, bool top_down, void *data,
> +int (*func)(u64, u64, void *));
> +int __weak arch_walk_system_ram(unsigned long start, unsigned long end,
> + bool top_down, void *data,
> + int (*func)(u64, u64, void *));
> void arch_kexec_protect_crashkres(void);
> void arch_kexec_unprotect_crashkres(void);
>
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index b6eec7527e9f..300f71cb4f72 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -428,6 +428,68 @@ static int locate_mem_hole_callback(u64 start, u64 end,
> void *arg)
> return locate_mem_hole_bottom_up(start, end, kbuf);
> }
>
> +int __weak arch_walk_iomem(unsigned long desc, unsigned long start,
> +unsigned long end, bool top_down, void *data,
> +int (*func)(u64, u64, void *))
> +{
> + return walk_iomem_res_desc(desc,
> +IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
> +start, end, data, func);
> +}
> +
> +int __weak arch_walk_system_ram(unsigned long start, unsigned long end,
> + bool top_down, void *data,
> + int (*func)(u64, u64, void *))
> +{
> + return walk_system_ram_res(start, end, data, func);
> +}
> +
> +/**
> + * kexec_locate_mem_hole - find free memory to load segment or use in
> purgatory
> + * @image: kexec image being updated.
> + * @size:Memory size.
> + * @align: Minimum alignment needed.
> + * @start: Minimum starting address.
> + * @end: Maximum end address.
> + * @top_down Find the highest free memory region?
> + * @addr On success, will have start address of the memory region found.
> + *
> + * Return: 0 on success, negative erro on failure.
> + */
> +int kexec_locate_mem_hole(struct kimage *image, unsigned long size,
> + unsigned long align, unsigned long start,
> + unsigned long end, bool top_down, unsigned long *addr)
> +{
> + int ret;
> + struct kexec_buf buf;
> +
> + memset(&buf, 0, sizeof(struct kexec_buf));
> + buf.image = image;
> +
> + buf.memsz = size;
> + buf.buf_align = align;
> + buf.buf_min = start;
> + buf.buf_max = end;
> + buf.top_down = top_down;
> +
> + /* Walk the RAM ranges and allocate a suitable range for the buffer */
> + if (image->type == KEXEC_TYPE_CRASH)
> + ret = arch_walk_iomem(crashk_res.desc, crashk_res.start,
> + crashk_res.end, top_down, &buf,
> + locate_mem_hole_callback);
> + else
> + ret = arch_walk_system_ram(0, -1, top_down, &buf,
> +locate_mem_hole_callback);
> + if (ret != 1) {
> + /* A
Re: [PATCH 2/8] kexec_file: Generalize kexec_add_buffer.
On 06/12/16 at 12:10am, Thiago Jung Bauermann wrote:
> Allow architectures to specify different memory walking functions for
> kexec_add_buffer. Intel uses iomem to track reserved memory ranges,
> but PowerPC uses the memblock subsystem.
>
> Also, factor kexec_locate_mem_hole out of kexec_add_buffer. It will be
> used by the PowerPC kexec_file_load implementation to find free memory
> for the purgatory stack.
Split factoring locate hole function to another patch will be clearer.
>
> Cc: Eric Biederman
> Cc: ke...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> ---
> include/linux/kexec.h | 10 ++
> kernel/kexec_file.c | 96
> +--
> 2 files changed, 81 insertions(+), 25 deletions(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index e8acb2b43dd9..920e2cbe5bdd 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -210,6 +210,10 @@ extern asmlinkage long sys_kexec_load(unsigned long
> entry,
> struct kexec_segment __user *segments,
> unsigned long flags);
> extern int kernel_kexec(void);
> +int kexec_locate_mem_hole(struct kimage *image, unsigned long size,
> + unsigned long align, unsigned long start,
> + unsigned long end, bool top_down,
> + unsigned long *addr);
> extern int kexec_add_buffer(struct kimage *image, char *buffer,
> unsigned long bufsz, unsigned long memsz,
> unsigned long buf_align, unsigned long buf_min,
> @@ -315,6 +319,12 @@ int __weak arch_kexec_apply_relocations_add(const
> Elf_Ehdr *ehdr,
> Elf_Shdr *sechdrs, unsigned int relsec);
> int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr
> *sechdrs,
> unsigned int relsec);
> +int __weak arch_walk_iomem(unsigned long desc, unsigned long start,
> +unsigned long end, bool top_down, void *data,
> +int (*func)(u64, u64, void *));
> +int __weak arch_walk_system_ram(unsigned long start, unsigned long end,
> + bool top_down, void *data,
> + int (*func)(u64, u64, void *));
> void arch_kexec_protect_crashkres(void);
> void arch_kexec_unprotect_crashkres(void);
>
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index b6eec7527e9f..300f71cb4f72 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -428,6 +428,68 @@ static int locate_mem_hole_callback(u64 start, u64 end,
> void *arg)
> return locate_mem_hole_bottom_up(start, end, kbuf);
> }
>
> +int __weak arch_walk_iomem(unsigned long desc, unsigned long start,
> +unsigned long end, bool top_down, void *data,
> +int (*func)(u64, u64, void *))
> +{
> + return walk_iomem_res_desc(desc,
> +IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
> +start, end, data, func);
> +}
> +
> +int __weak arch_walk_system_ram(unsigned long start, unsigned long end,
> + bool top_down, void *data,
> + int (*func)(u64, u64, void *))
> +{
> + return walk_system_ram_res(start, end, data, func);
> +}
> +
> +/**
> + * kexec_locate_mem_hole - find free memory to load segment or use in
> purgatory
> + * @image: kexec image being updated.
> + * @size:Memory size.
> + * @align: Minimum alignment needed.
> + * @start: Minimum starting address.
> + * @end: Maximum end address.
> + * @top_down Find the highest free memory region?
> + * @addr On success, will have start address of the memory region found.
> + *
> + * Return: 0 on success, negative erro on failure.
> + */
> +int kexec_locate_mem_hole(struct kimage *image, unsigned long size,
> + unsigned long align, unsigned long start,
> + unsigned long end, bool top_down, unsigned long *addr)
> +{
> + int ret;
> + struct kexec_buf buf;
> +
> + memset(&buf, 0, sizeof(struct kexec_buf));
> + buf.image = image;
> +
> + buf.memsz = size;
> + buf.buf_align = align;
> + buf.buf_min = start;
> + buf.buf_max = end;
> + buf.top_down = top_down;
> +
> + /* Walk the RAM ranges and allocate a suitable range for the buffer */
> + if (image->type == KEXEC_TYPE_CRASH)
> + ret = arch_walk_iomem(crashk_res.desc, crashk_res.start,
> + crashk_res.end, top_down, &buf,
> + locate_mem_hole_callback);
> + else
> + ret = arch_walk_system_ram(0, -1, top_down, &buf,
> +locate_mem_hole_callback);
> + if (ret != 1) {
> + /* A suitable memory range could not be
Re: [PATCH 1/8] kexec_file: Remove unused members from struct kexec_buf.
On 06/12/16 at 12:10am, Thiago Jung Bauermann wrote:
> kexec_add_buffer uses kexec_buf.buffer and kexec_buf.bufsz to pass along
> its own arguments buffer and bufsz, but since they aren't used anywhere
> else, it's pointless.
>
> Cc: Eric Biederman
> Cc: ke...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> ---
> kernel/kexec_file.c | 6 ++
> kernel/kexec_internal.h | 2 --
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 01ab82a40d22..b6eec7527e9f 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -464,8 +464,6 @@ int kexec_add_buffer(struct kimage *image, char *buffer,
> unsigned long bufsz,
> memset(&buf, 0, sizeof(struct kexec_buf));
> kbuf = &buf;
> kbuf->image = image;
> - kbuf->buffer = buffer;
> - kbuf->bufsz = bufsz;
>
> kbuf->memsz = ALIGN(memsz, PAGE_SIZE);
> kbuf->buf_align = max(buf_align, PAGE_SIZE);
> @@ -489,8 +487,8 @@ int kexec_add_buffer(struct kimage *image, char *buffer,
> unsigned long bufsz,
>
> /* Found a suitable memory range */
> ksegment = &image->segment[image->nr_segments];
> - ksegment->kbuf = kbuf->buffer;
> - ksegment->bufsz = kbuf->bufsz;
> + ksegment->kbuf = buffer;
> + ksegment->bufsz = bufsz;
> ksegment->mem = kbuf->mem;
> ksegment->memsz = kbuf->memsz;
> image->nr_segments++;
> diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
> index 0a52315d9c62..eefd5bf960c2 100644
> --- a/kernel/kexec_internal.h
> +++ b/kernel/kexec_internal.h
> @@ -26,8 +26,6 @@ struct kexec_sha_region {
> */
> struct kexec_buf {
> struct kimage *image;
> - char *buffer;
> - unsigned long bufsz;
> unsigned long mem;
> unsigned long memsz;
> unsigned long buf_align;
> --
> 1.9.1
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Acked-by: Dave Young
Thanks
Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] kexec_file_load implementation for PowerPC
On 06/12/16 at 12:10am, Thiago Jung Bauermann wrote: > Hello, > > This patch series implements the kexec_file_load system call on PowerPC. > > It starts by removing an x86 assumption from kexec_file: kexec_add_buffer uses > iomem to find reserved memory ranges, but PowerPC uses the memblock subsystem. > Hooks are added so that each arch can specify how memory ranges can be found. > > Also, the memory-walking logic in kexec_add_buffer is useful in this > implementation to find a free area for the purgatory's stack, so that same > patch moves that logic to kexec_locate_mem_hole. > > The kexec_file_load system call needs to apply relocations to the purgatory > but adding code for that would duplicate functionality with the module loading > mechanism, which also needs to apply relocations to the kernel modules. > Therefore, this patch series factors out the module relocation code so that it > can be shared. > > One thing that is still missing is crashkernel support, which I intend to > submit shortly. But seems there's no error handling in patches about KEXEC_ON_CRASH? It would be good to either sending out the whole set or handle the error cases correctly. [snip] Thanks Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
