Re: [PATCH] powerpc/powernv: Select CONFIG_PRINTK to fix build failure
On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote: In an allnoconfig we get the following build failure: An allnoconfig doesn't include CONFIG_PPC_POWERNV? But I think I know what you mean. arch/powerpc/platforms/built-in.o: In function `.__machine_initcall_powernv_opal_init': opal.c:(.init.text+0x468): undefined reference to `.log_buf_addr_get' opal.c:(.init.text+0x474): undefined reference to `.log_buf_len_get' make: *** [vmlinux] Error 1 This happens because powernv requires printk() support. Enable it in the config file. Sort of. It just requires those two routines. Or is there a stronger dependency? I think the better fix is for those two routines to be defined for CONFIG_PRINTK=n, but return NULL and zero respectively. And the opal code could skip registering the region when they return NULL/zero. Care to do a couple of patches? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
On Mon, 2014-12-22 at 14:38 +0800, Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com Kernel cannot bring up Non-boot cpus always get Processor xx is stuck. this issue bring by http://patchwork.ozlabs.org/patch/418912/ (powerpc: Secondary CPUs must set cpu_callin_map after setting active and online) We've decided we're just going to revert that patch for this cycle. We'll do a better fix for next, and hopefully people will test it before it gets to mainline :D cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
On Sat, 27 Dec 2014 12:17:43 -0500 Pranith Kumar bobby.pr...@gmail.com wrote: @@ -65,10 +65,13 @@ #include asm/kexec.h #include asm/mmu_context.h #include asm/code-patching.h -#include asm/kvm_ppc.h #include asm/hugetlb.h #include asm/epapr_hcalls.h +#if IS_ENABLED(CONFIG_KVM) +#include asm/kvm_ppc.h +#endif + #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) #else I always cringe when I see an include protected by an #ifdef. Is this really necessary? All that is done in asm-offsets.c is to calculate offsets, the code where the two offsets in question are used (entry64.S) does have the #ifdef for CONFIG_KVM. -- blue skies, Martin. Reality continues to ruin my life. - Calvin. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] macintosh: ams: cleanup on stack DECLARE_COMPLETION
fix-up for incorrect use of DECLARE_COMPLETION. see also commit
6e9a4738 (completions: lockdep annotate on stack completions)
V2: split out patch for individual files and (hopefully) proper
labeling this time
patch is against linux-next 3.19.0-rc1 -next-20141226
patch was compile tested with ppc6xx_defconfig, CONFIG_SENSORS_AMS=m,
CONFIG_SENSORS_AMS_PMU=y
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
drivers/macintosh/ams/ams-pmu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/ams/ams-pmu.c b/drivers/macintosh/ams/ams-pmu.c
index 4f61b3e..c2b178f 100644
--- a/drivers/macintosh/ams/ams-pmu.c
+++ b/drivers/macintosh/ams/ams-pmu.c
@@ -52,7 +52,7 @@ static void ams_pmu_req_complete(struct adb_request *req)
static void ams_pmu_set_register(u8 reg, u8 value)
{
static struct adb_request req;
- DECLARE_COMPLETION(req_complete);
+ DECLARE_COMPLETION_ONSTACK(req_complete);
req.arg = req_complete;
if (pmu_request(req, ams_pmu_req_complete, 4, ams_pmu_cmd, 0x00, reg,
value))
@@ -65,7 +65,7 @@ static void ams_pmu_set_register(u8 reg, u8 value)
static u8 ams_pmu_get_register(u8 reg)
{
static struct adb_request req;
- DECLARE_COMPLETION(req_complete);
+ DECLARE_COMPLETION_ONSTACK(req_complete);
req.arg = req_complete;
if (pmu_request(req, ams_pmu_req_complete, 3, ams_pmu_cmd, 0x01, reg))
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v3.19-rc2
On Mon, Dec 29, 2014 at 8:59 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
JFYI, when comparing v3.19-rc2[1] to v3.19-rc1[3], the summaries are:
- build errors: +8/-5
Surprise! No new R_PPC64_REL24 relocation truncations, hence not much new
generic code was added. Bloat-o-meter on atari_defconfig agrees: +36 bytes.
+ /home/kisskb/slave/src/arch/powerpc/platforms/pseries/hotplug-memory.c:
error: 'SECTION_SIZE_BITS' undeclared (first use in this function):
= 27:31
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error:
'PAGES_PER_SECTION' undeclared (first use in this function): =
1836:46, 1178:18
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error:
'PAGE_SECTION_MASK' undeclared (first use in this function): =
1177:20
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error: implicit
declaration of function '__nr_to_section'
[-Werror=implicit-function-declaration]: = 1841:3
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error: implicit
declaration of function 'find_memory_block_hinted'
[-Werror=implicit-function-declaration]: = 1848:3
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error: implicit
declaration of function 'pfn_to_section_nr'
[-Werror=implicit-function-declaration]: = 1837:3
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error: implicit
declaration of function 'present_section_nr'
[-Werror=implicit-function-declaration]: = 1838:3
powerpc-randconfig
+ error: initramfs.c: undefined reference to `__stack_chk_guard':
= .init.text+0x3132)
i386-randconfig
[1] http://kisskb.ellerman.id.au/kisskb/head/8257/ (all 262 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/8241/ (all 262 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote: Isolate the SRCU functions and data structures within CONFIG_SRCU so that there is a compile time failure if srcu is used when not enabled. This was decided to be better than waiting until link time for a failure to occur. Yes, false positives and extra ifdefs are so much better. :-P Why not just ifdef the functions/macros, and leave the types alone? If you're worried about direct access to struct members, you could even ifdef the members away while leaving the struct itself. It is not normal practice in Linux to need ifdefs around #includes. There are places which include kvm headers and utilize kvm data structures without checking if KVM is enabled. In two such archs(s390, ppc64), the current patch makes the uses of KVM conditional on KVM being enabled. The other option, which is to enable KVM unconditionally seemed a bit too much as we could easily figure out KVM only parts and enclose them in ifdefs. Maybe not so easy (mpc85xx_smp_defconfig with NOTIFY stuff turned off so that SRCU gets deselected): In file included from /home/scott/fsl/git/linux/upstream/arch/powerpc/include/asm/kvm_ppc.h:30:0, from /home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/smp.c:39: /home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type /home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type /home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for target 'arch/powerpc/kernel/smp.o' failed make[2]: *** [arch/powerpc/kernel/smp.o] Error 1 /home/scott/fsl/git/linux/upstream/Makefile:955: recipe for target 'arch/powerpc/kernel' failed make[1]: *** [arch/powerpc/kernel] Error 2 make[1]: *** Waiting for unfinished jobs Are you sure KVM is the only SRCU user so impacted? It's also likely that new such problems get introduced, because most people are going to have SRCU enabled and thus not notice the breakage they're adding. There's also at least one place that needs to be fixed, that currently expects to get other headers indirectly via srcu.h: /home/scott/fsl/git/linux/upstream/lib/assoc_array.c: In function 'assoc_array_apply_edit': /home/scott/fsl/git/linux/upstream/lib/assoc_array.c:1425:2: error: implicit declaration of function 'call_rcu' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors /home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for target 'lib/assoc_array.o' failed -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ASoC: fsl_esai: Fix incorrect xDC field width of xCCR registers
The xDC field should have 5 bit width according to Reference Manual. Thus this patch fixes it. Signed-off-by: Aurelien BOUIN a_bo...@yahoo.fr Signed-off-by: Nicolin Chen nicoleots...@gmail.com --- The patch was originally submitted by Aurelien BOUIN while in an informal way. And he hasn't finished any re-submitting during the past two weeks. Thus I create a new patch with his signed-off included so as to fix the probelm as soon as possible, not sure whether it's decent or not though. --Nicolin sound/soc/fsl/fsl_esai.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/fsl_esai.h b/sound/soc/fsl/fsl_esai.h index 91a550f..5e793bb 100644 --- a/sound/soc/fsl/fsl_esai.h +++ b/sound/soc/fsl/fsl_esai.h @@ -302,7 +302,7 @@ #define ESAI_xCCR_xFP_MASK (((1 ESAI_xCCR_xFP_WIDTH) - 1) ESAI_xCCR_xFP_SHIFT) #define ESAI_xCCR_xFP(v) v) - 1) ESAI_xCCR_xFP_SHIFT) ESAI_xCCR_xFP_MASK) #define ESAI_xCCR_xDC_SHIFT 9 -#define ESAI_xCCR_xDC_WIDTH4 +#define ESAI_xCCR_xDC_WIDTH5 #define ESAI_xCCR_xDC_MASK (((1 ESAI_xCCR_xDC_WIDTH) - 1) ESAI_xCCR_xDC_SHIFT) #define ESAI_xCCR_xDC(v) v) - 1) ESAI_xCCR_xDC_SHIFT) ESAI_xCCR_xDC_MASK) #define ESAI_xCCR_xPSR_SHIFT 8 -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
On Mon, Dec 29, 2014 at 5:03 AM, Martin Schwidefsky schwidef...@de.ibm.com wrote: On Sat, 27 Dec 2014 12:17:43 -0500 Pranith Kumar bobby.pr...@gmail.com wrote: @@ -65,10 +65,13 @@ #include asm/kexec.h #include asm/mmu_context.h #include asm/code-patching.h -#include asm/kvm_ppc.h #include asm/hugetlb.h #include asm/epapr_hcalls.h +#if IS_ENABLED(CONFIG_KVM) +#include asm/kvm_ppc.h +#endif + #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) #else I always cringe when I see an include protected by an #ifdef. Is this really necessary? All that is done in asm-offsets.c is to calculate offsets, the code where the two offsets in question are used (entry64.S) does have the #ifdef for CONFIG_KVM. I agree that this is not the ideal way to do this. But, it has been the way things were already being done. If you see arch/powerpc/kernel/asm-offsets.c, there are quite some includes which are within ifdefs. I've considered other alternatives (though not in-depth) and found that they will require quite some refactoring. One simple idea is to move this #ifdef to within kvm_ppc.h. That should make the inclusion of this file a no-op in all the places where this is being included without KVM being enabled. But I am not 100% sure of that approach. Any suggestions are welcome. -- Pranith ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
On Mon, Dec 29, 2014 at 6:05 PM, Scott Wood scottw...@freescale.com wrote: On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote: Isolate the SRCU functions and data structures within CONFIG_SRCU so that there is a compile time failure if srcu is used when not enabled. This was decided to be better than waiting until link time for a failure to occur. Yes, false positives and extra ifdefs are so much better. :-P Why not just ifdef the functions/macros, and leave the types alone? If you're worried about direct access to struct members, you could even ifdef the members away while leaving the struct itself. It is not normal practice in Linux to need ifdefs around #includes. Yup, totally agree that this is not ideal. The idea here is to not even compile the structure for tinification purposes. ifdefs for headers are ugly, but given the current code structure, I was not able to figure out any other way around it without major overhaul. There are places which include kvm headers and utilize kvm data structures without checking if KVM is enabled. In two such archs(s390, ppc64), the current patch makes the uses of KVM conditional on KVM being enabled. The other option, which is to enable KVM unconditionally seemed a bit too much as we could easily figure out KVM only parts and enclose them in ifdefs. Maybe not so easy (mpc85xx_smp_defconfig with NOTIFY stuff turned off so that SRCU gets deselected): In file included from /home/scott/fsl/git/linux/upstream/arch/powerpc/include/asm/kvm_ppc.h:30:0, from /home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/smp.c:39: /home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type /home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type /home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for target 'arch/powerpc/kernel/smp.o' failed make[2]: *** [arch/powerpc/kernel/smp.o] Error 1 /home/scott/fsl/git/linux/upstream/Makefile:955: recipe for target 'arch/powerpc/kernel' failed make[1]: *** [arch/powerpc/kernel] Error 2 make[1]: *** Waiting for unfinished jobs Are you sure KVM is the only SRCU user so impacted? It's also likely that new such problems get introduced, because most people are going to have SRCU enabled and thus not notice the breakage they're adding. Well, it is the major one which I encountered until now. There might be other problems lurking which I will gladly try to fix if and when they are reported. There's also at least one place that needs to be fixed, that currently expects to get other headers indirectly via srcu.h: /home/scott/fsl/git/linux/upstream/lib/assoc_array.c: In function 'assoc_array_apply_edit': /home/scott/fsl/git/linux/upstream/lib/assoc_array.c:1425:2: error: implicit declaration of function 'call_rcu' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors /home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for target 'lib/assoc_array.o' failed I will send a patch fixing this(need to use rcupdate.h here explicitly). Thanks for reporting these! -Scott -- Pranith ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] srcu: Isolate srcu sections using CONFIG_SRCU
Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
is a compile time failure if srcu is used when not enabled. This was decided to
be better than waiting until link time for a failure to occur.
There are places which include kvm headers and utilize kvm data structures
without checking if KVM is enabled. In two such archs(s390, ppc64), the current
patch makes the uses of KVM conditional on KVM being enabled. The other option,
which is to enable KVM unconditionally seemed a bit too much as we could easily
figure out KVM only parts and enclose them in ifdefs.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Scott Wood scottw...@freescale.com
---
v2:
- fix build failures reported by Scott Wood
arch/powerpc/kernel/setup_64.c | 7 ++-
arch/powerpc/kernel/smp.c | 9 +++-
arch/s390/kernel/asm-offsets.c | 7 ++-
include/linux/notifier.h | 47 --
include/linux/srcu.h | 6 +-
5 files changed, 52 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4f3cfe1..f55302f 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -65,10 +65,13 @@
#include asm/kexec.h
#include asm/mmu_context.h
#include asm/code-patching.h
-#include asm/kvm_ppc.h
#include asm/hugetlb.h
#include asm/epapr_hcalls.h
+#if IS_ENABLED(CONFIG_KVM)
+#include asm/kvm_ppc.h
+#endif
+
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
#else
@@ -286,8 +289,10 @@ void __init early_setup(unsigned long dt_ptr)
*/
cpu_ready_for_interrupts();
+#if IS_ENABLED(CONFIG_KVM)
/* Reserve large chunks of memory for use by CMA for KVM */
kvm_cma_reserve();
+#endif
/*
* Reserve any gigantic pages requested on the command line.
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 71e186d..0001daa 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -36,7 +36,6 @@
#include linux/atomic.h
#include asm/irq.h
#include asm/hw_irq.h
-#include asm/kvm_ppc.h
#include asm/page.h
#include asm/pgtable.h
#include asm/prom.h
@@ -54,6 +53,10 @@
#include asm/debug.h
#include asm/kexec.h
+#if IS_ENABLED(CONFIG_KVM)
+#include asm/kvm_ppc.h
+#endif
+
#ifdef DEBUG
#include asm/udbg.h
#define DBG(fmt...) udbg_printf(fmt)
@@ -470,7 +473,11 @@ int generic_check_cpu_restart(unsigned int cpu)
static bool secondaries_inhibited(void)
{
+#if IS_ENABLED(CONFIG_KVM)
return kvm_hv_mode_active();
+#else
+ return false;
+#endif
}
#else /* HOTPLUG_CPU */
diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c
index ef279a1..2813a3c 100644
--- a/arch/s390/kernel/asm-offsets.c
+++ b/arch/s390/kernel/asm-offsets.c
@@ -7,12 +7,15 @@
#define ASM_OFFSETS_C
#include linux/kbuild.h
-#include linux/kvm_host.h
#include linux/sched.h
#include asm/idle.h
#include asm/vdso.h
#include asm/pgtable.h
+#if IS_ENABLED(CONFIG_KVM)
+#include linux/kvm_host.h
+#endif
+
/*
* Make sure that the compiler is new enough. We want a compiler that
* is known to work with the Q assembler constraint.
@@ -182,8 +185,10 @@ int main(void)
DEFINE(__LC_PGM_TDB, offsetof(struct _lowcore, pgm_tdb));
DEFINE(__THREAD_trap_tdb, offsetof(struct task_struct,
thread.trap_tdb));
DEFINE(__GMAP_ASCE, offsetof(struct gmap, asce));
+#if IS_ENABLED(CONFIG_KVM)
DEFINE(__SIE_PROG0C, offsetof(struct kvm_s390_sie_block, prog0c));
DEFINE(__SIE_PROG20, offsetof(struct kvm_s390_sie_block, prog20));
+#endif /* CONFIG_KVM */
#endif /* CONFIG_32BIT */
return 0;
}
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index d14a4c3..fe4f02a 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -47,6 +47,8 @@
* runtime initialization.
*/
+struct notifier_block;
+
typedefint (*notifier_fn_t)(struct notifier_block *nb,
unsigned long action, void *data);
@@ -70,12 +72,6 @@ struct raw_notifier_head {
struct notifier_block __rcu *head;
};
-struct srcu_notifier_head {
- struct mutex mutex;
- struct srcu_struct srcu;
- struct notifier_block __rcu *head;
-};
-
#define ATOMIC_INIT_NOTIFIER_HEAD(name) do { \
spin_lock_init((name)-lock); \
(name)-head = NULL;\
@@ -88,11 +84,6 @@ struct srcu_notifier_head {
(name)-head = NULL;\
} while (0)
-/* srcu_notifier_heads must be initialized and cleaned up dynamically */
-extern void srcu_init_notifier_head(struct srcu_notifier_head *nh);
-#define srcu_cleanup_notifier_head(name) \
- cleanup_srcu_struct((name)-srcu);
-
#define ATOMIC_NOTIFIER_INIT(name) { \
.lock = __SPIN_LOCK_UNLOCKED(name.lock),\
.head = NULL }
@@ -101,7 +92,6 @@ extern
Re: [PATCH] powerpc/powernv: Select CONFIG_PRINTK to fix build failure
On Mon, Dec 29, 2014 at 4:01 AM, Michael Ellerman m...@ellerman.id.au wrote: On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote: In an allnoconfig we get the following build failure: An allnoconfig doesn't include CONFIG_PPC_POWERNV? But I think I know what you mean. arch/powerpc/platforms/built-in.o: In function `.__machine_initcall_powernv_opal_init': opal.c:(.init.text+0x468): undefined reference to `.log_buf_addr_get' opal.c:(.init.text+0x474): undefined reference to `.log_buf_len_get' make: *** [vmlinux] Error 1 This happens because powernv requires printk() support. Enable it in the config file. Sort of. It just requires those two routines. Or is there a stronger dependency? I think the better fix is for those two routines to be defined for CONFIG_PRINTK=n, but return NULL and zero respectively. And the opal code could skip registering the region when they return NULL/zero. Care to do a couple of patches? Sure, I will give it a try. Thanks for the review! -- Pranith ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
