date:20140207

const __read_mostly does not make any sense, because const
data is already read-only. Remove the __read_mostly
for the ipvs genl_ops. This avoids a LTO
section conflict compile problem.

Cc: Wensong Zhang 
Cc: Simon Horman 
Cc: Patrick McHardy 
Cc: lvs-de...@vger.kernel.org
Signed-off-by: Andi Kleen 
---
 net/netfilter/ipvs/ip_vs_ctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 35be035..2a68a38 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -3580,7 +3580,7 @@ out:
 }
 
 
-static const struct genl_ops ip_vs_genl_ops[] __read_mostly = {
+static const struct genl_ops ip_vs_genl_ops[] = {
{
.cmd= IPVS_CMD_NEW_SERVICE,
.flags  = GENL_ADMIN_PERM,
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 01/14] asmlinkage, kvm: Make kvm_rebooting visible

kvm_rebooting is referenced from assembler code, thus
needs to be visible.

Cc: g...@redhat.com
Cc: pbonz...@redhat.com
Cc: k...@vger.kernel.org
Signed-off-by: Andi Kleen 
---
 virt/kvm/kvm_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 03a0381..b5ec7fb 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -102,7 +102,7 @@ static void kvm_release_pfn_dirty(pfn_t pfn);
 static void mark_page_dirty_in_slot(struct kvm *kvm,
struct kvm_memory_slot *memslot, gfn_t gfn);
 
-bool kvm_rebooting;
+__visible bool kvm_rebooting;
 EXPORT_SYMBOL_GPL(kvm_rebooting);
 
 static bool largepages_enabled = true;
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 07/14] asmlinkage, mutex: Mark __visible

Various kernel/mutex.c functions can be called from
inline assembler, so they should be all global and
__visible

Cc: mi...@kernel.org
Signed-off-by: Andi Kleen 
---
 kernel/locking/mutex.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 4dd6e4c..adbc0d0 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -67,8 +67,7 @@ EXPORT_SYMBOL(__mutex_init);
  * We also put the fastpath first in the kernel image, to make sure the
  * branch is predicted by the CPU as default-untaken.
  */
-static __used noinline void __sched
-__mutex_lock_slowpath(atomic_t *lock_count);
+__visible void __sched __mutex_lock_slowpath(atomic_t *lock_count);
 
 /**
  * mutex_lock - acquire the mutex
@@ -225,7 +224,8 @@ static inline int mutex_can_spin_on_owner(struct mutex 
*lock)
 }
 #endif
 
-static __used noinline void __sched __mutex_unlock_slowpath(atomic_t 
*lock_count);
+__visible __used noinline
+void __sched __mutex_unlock_slowpath(atomic_t *lock_count);
 
 /**
  * mutex_unlock - release the mutex
@@ -746,7 +746,7 @@ __mutex_unlock_common_slowpath(atomic_t *lock_count, int 
nested)
 /*
  * Release the lock, slowpath:
  */
-static __used noinline void
+__visible void
 __mutex_unlock_slowpath(atomic_t *lock_count)
 {
__mutex_unlock_common_slowpath(lock_count, 1);
@@ -803,7 +803,7 @@ int __sched mutex_lock_killable(struct mutex *lock)
 }
 EXPORT_SYMBOL(mutex_lock_killable);
 
-static __used noinline void __sched
+__visible void __sched
 __mutex_lock_slowpath(atomic_t *lock_count)
 {
struct mutex *lock = container_of(lock_count, struct mutex, count);
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 11/14] asmlinkage, x86: Fix 32bit memcpy for LTO

These functions can be called implicitely from gcc, and thus need to be
visible.

Cc: x...@kernel.org
Signed-off-by: Andi Kleen 
---
 arch/x86/lib/memcpy_32.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/lib/memcpy_32.c b/arch/x86/lib/memcpy_32.c
index e78761d..a404b4b 100644
--- a/arch/x86/lib/memcpy_32.c
+++ b/arch/x86/lib/memcpy_32.c
@@ -4,7 +4,7 @@
 #undef memcpy
 #undef memset
 
-void *memcpy(void *to, const void *from, size_t n)
+__visible void *memcpy(void *to, const void *from, size_t n)
 {
 #ifdef CONFIG_X86_USE_3DNOW
return __memcpy3d(to, from, n);
@@ -14,13 +14,13 @@ void *memcpy(void *to, const void *from, size_t n)
 }
 EXPORT_SYMBOL(memcpy);
 
-void *memset(void *s, int c, size_t count)
+__visible void *memset(void *s, int c, size_t count)
 {
return __memset(s, c, count);
 }
 EXPORT_SYMBOL(memset);
 
-void *memmove(void *dest, const void *src, size_t n)
+__visible void *memmove(void *dest, const void *src, size_t n)
 {
int d0,d1,d2,d3,d4,d5;
char *ret = dest;
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/14] asmlinkage: Make lockdep_sys_exit asmlinkage

lockdep_sys_exit can be called from assembler code, so make it
asmlinkage

Cc: pet...@infradead.org
Cc: mi...@kernel.org
Signed-off-by: Andi Kleen 
---
 include/linux/lockdep.h  | 2 +-
 kernel/locking/lockdep.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 92b1bfc..7df9aa6 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -265,7 +265,7 @@ extern void lockdep_info(void);
 extern void lockdep_reset(void);
 extern void lockdep_reset_lock(struct lockdep_map *lock);
 extern void lockdep_free_key_range(void *start, unsigned long size);
-extern void lockdep_sys_exit(void);
+extern asmlinkage void lockdep_sys_exit(void);
 
 extern void lockdep_off(void);
 extern void lockdep_on(void);
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index eb8a547..c8b6753c 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -4191,7 +4191,7 @@ void debug_show_held_locks(struct task_struct *task)
 }
 EXPORT_SYMBOL_GPL(debug_show_held_locks);
 
-void lockdep_sys_exit(void)
+asmlinkage void lockdep_sys_exit(void)
 {
struct task_struct *curr = current;
 
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 13/14] initconst: Fix initconst mistake in dcdbas

const must be __initconst

Cc: douglas_warze...@dell.com
Signed-off-by: Andi Kleen 
---
 drivers/firmware/dcdbas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index 1b5e8e4..7160c43 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -584,7 +584,7 @@ static struct platform_driver dcdbas_driver = {
.remove = dcdbas_remove,
 };
 
-static const struct platform_device_info dcdbas_dev_info __initdata = {
+static const struct platform_device_info dcdbas_dev_info __initconst = {
.name   = DRIVER_NAME,
.id = -1,
.dma_mask   = DMA_BIT_MASK(32),
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/14] asmlinkage: Mark rwsem functions that can be called from assembler asmlinkage

Signed-off-by: Andi Kleen 
---
 kernel/locking/rwsem-xadd.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 19c5fa9..1d66e08 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -143,6 +143,7 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum 
rwsem_wake_type wake_type)
 /*
  * wait for the read lock to be granted
  */
+__visible
 struct rw_semaphore __sched *rwsem_down_read_failed(struct rw_semaphore *sem)
 {
long count, adjustment = -RWSEM_ACTIVE_READ_BIAS;
@@ -190,6 +191,7 @@ struct rw_semaphore __sched *rwsem_down_read_failed(struct 
rw_semaphore *sem)
 /*
  * wait until we successfully acquire the write lock
  */
+__visible
 struct rw_semaphore __sched *rwsem_down_write_failed(struct rw_semaphore *sem)
 {
long count, adjustment = -RWSEM_ACTIVE_WRITE_BIAS;
@@ -252,6 +254,7 @@ struct rw_semaphore __sched *rwsem_down_write_failed(struct 
rw_semaphore *sem)
  * handle waking up a waiter on the semaphore
  * - up_read/up_write has decremented the active part of count if we come here
  */
+__visible
 struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem)
 {
unsigned long flags;
@@ -272,6 +275,7 @@ struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem)
  * - caller incremented waiting part of count and discovered it still negative
  * - just wake up any readers at the front of the queue
  */
+__visible
 struct rw_semaphore *rwsem_downgrade_wake(struct rw_semaphore *sem)
 {
unsigned long flags;
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 02/14] asmlinkage: Make __iowrite32_copy visible

This is a assembler function on x86, so it should be visible.

Cc: x...@kernel.org
Signed-off-by: Andi Kleen 
---
 include/linux/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/io.h b/include/linux/io.h
index f4f42fa..8a18e75 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -24,7 +24,7 @@
 
 struct device;
 
-void __iowrite32_copy(void __iomem *to, const void *from, size_t count);
+__visible void __iowrite32_copy(void __iomem *to, const void *from, size_t 
count);
 void __iowrite64_copy(void __iomem *to, const void *from, size_t count);
 
 #ifdef CONFIG_MMU
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/14] asmlinkage: Make trace_hardirq visible

Can be called from assembler code.

Cc: pet...@infradead.org
Cc: mi...@kernel.org
Signed-off-by: Andi Kleen 
---
 kernel/locking/lockdep.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index c8b6753c..aa3bf15 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2557,7 +2557,7 @@ static void __trace_hardirqs_on_caller(unsigned long ip)
debug_atomic_inc(hardirqs_on_events);
 }
 
-void trace_hardirqs_on_caller(unsigned long ip)
+__visible void trace_hardirqs_on_caller(unsigned long ip)
 {
time_hardirqs_on(CALLER_ADDR0, ip);
 
@@ -2610,7 +2610,7 @@ EXPORT_SYMBOL(trace_hardirqs_on);
 /*
  * Hardirqs were disabled:
  */
-void trace_hardirqs_off_caller(unsigned long ip)
+__visible void trace_hardirqs_off_caller(unsigned long ip)
 {
struct task_struct *curr = current;
 
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/14] asmlinkage: Make main_extable_sort_needed visible

main_extable_sort_needed is used by the build system and needs
to be a normal ELF symbol. Make it visible so that LTO
does not remove or mangle it.

Signed-off-by: Andi Kleen 
---
 kernel/extable.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/extable.c b/kernel/extable.c
index 763faf0..d8a6446 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -36,7 +36,7 @@ extern struct exception_table_entry __start___ex_table[];
 extern struct exception_table_entry __stop___ex_table[];
 
 /* Cleared by build time tools if the table is already sorted. */
-u32 __initdata main_extable_sort_needed = 1;
+u32 __initdata __visible main_extable_sort_needed = 1;
 
 /* Sort the kernel's built-in exception table */
 void __init sort_main_extable(void)
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86, sections, numachip: Remove useless __read_mostly

const __read_mostly does not make any sense, because const
data is already read-only. Remove the __read_mostly
for the numachip APIC driver. This avoids a LTO
section conflict compile problem.

Cc: x...@kernel.org
Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/apic/apic_numachip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apic/apic_numachip.c 
b/arch/x86/kernel/apic/apic_numachip.c
index 3e67f9e..a481bb6 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -32,7 +32,7 @@
 
 static int numachip_system __read_mostly;
 
-static const struct apic apic_numachip __read_mostly;
+static const struct apic apic_numachip;
 
 static unsigned int get_apic_id(unsigned long x)
 {
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 10/14] asmlinkage Make __stack_chk_failed and memcmp visible

In LTO symbols implicitely referenced by the compiler need
to be visible. Earlier these symbols were visible implicitely
from being exported, but we disabled implicit visibility fo
 EXPORTs when modules are disabled to improve code size. So
now these symbols have to be marked visible explicitely.

Do this for __stack_chk_fail (with stack protector)
and memcmp.

Signed-off-by: Andi Kleen 
---
 kernel/panic.c | 2 +-
 lib/string.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/panic.c b/kernel/panic.c
index 6d63003..3eb0ffb 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -459,7 +459,7 @@ EXPORT_SYMBOL(warn_slowpath_null);
  * Called when gcc's -fstack-protector feature is used, and
  * gcc detects corruption of the on-stack canary value
  */
-void __stack_chk_fail(void)
+__visible void __stack_chk_fail(void)
 {
panic("stack-protector: Kernel stack is corrupted in: %p\n",
__builtin_return_address(0));
diff --git a/lib/string.c b/lib/string.c
index e5878de..9b1f906 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -648,7 +648,7 @@ EXPORT_SYMBOL(memmove);
  * @count: The size of the area.
  */
 #undef memcmp
-int memcmp(const void *cs, const void *ct, size_t count)
+__visible int memcmp(const void *cs, const void *ct, size_t count)
 {
const unsigned char *su1, *su2;
int res = 0;
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/14] asmlinkage: Make jiffies visible

Jiffies is referenced by the linker script, so it has to be visible.

Handled both the generic and the x86 version.

Cc: x...@kernel.org
Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/time.c | 2 +-
 kernel/timer.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
index 24d3c91..6ec91c0 100644
--- a/arch/x86/kernel/time.c
+++ b/arch/x86/kernel/time.c
@@ -23,7 +23,7 @@
 #include 
 
 #ifdef CONFIG_X86_64
-DEFINE_VVAR(volatile unsigned long, jiffies) = INITIAL_JIFFIES;
+__visible DEFINE_VVAR(volatile unsigned long, jiffies) = INITIAL_JIFFIES;
 #endif
 
 unsigned long profile_pc(struct pt_regs *regs)
diff --git a/kernel/timer.c b/kernel/timer.c
index accfd24..d78de04 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -52,7 +52,7 @@
 #define CREATE_TRACE_POINTS
 #include 
 
-u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;
+__visible u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;
 
 EXPORT_SYMBOL(jiffies_64);
 
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/14] asmlinkage, pnp: Make variables used from assembler code visible

Mark variables referenced from assembler files visible.

This fixes compile problems with LTO

Cc: pe...@perex.cz
Signed-off-by: Andi Kleen 
---
 drivers/pnp/pnpbios/bioscalls.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/pnp/pnpbios/bioscalls.c b/drivers/pnp/pnpbios/bioscalls.c
index 769d265..deb7f4b 100644
--- a/drivers/pnp/pnpbios/bioscalls.c
+++ b/drivers/pnp/pnpbios/bioscalls.c
@@ -21,7 +21,7 @@
 
 #include "pnpbios.h"
 
-static struct {
+__visible struct {
u16 offset;
u16 segment;
 } pnp_bios_callpoint;
@@ -41,6 +41,7 @@ asmlinkage void pnp_bios_callfunc(void);
 
 __asm__(".text \n"
__ALIGN_STR "\n"
+   ".globl pnp_bios_callfunc\n"
"pnp_bios_callfunc:\n"
"   pushl %edx  \n"
"   pushl %ecx  \n"
@@ -66,9 +67,9 @@ static struct desc_struct bad_bios_desc = 
GDT_ENTRY_INIT(0x4092,
  * after PnP BIOS oopses.
  */
 
-u32 pnp_bios_fault_esp;
-u32 pnp_bios_fault_eip;
-u32 pnp_bios_is_utter_crap = 0;
+__visible u32 pnp_bios_fault_esp;
+__visible u32 pnp_bios_fault_eip;
+__visible u32 pnp_bios_is_utter_crap = 0;
 
 static spinlock_t pnp_bios_lock;
 
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 12/14] asmlinkage: Make trace_hardirqs_on/off_caller visible

These functions are called from assembler, and thus need to be
__visible

Cc: Steven Rostedt 
Signed-off-by: Andi Kleen 
---
 kernel/trace/trace_irqsoff.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
index 2aefbee..887ef88 100644
--- a/kernel/trace/trace_irqsoff.c
+++ b/kernel/trace/trace_irqsoff.c
@@ -498,14 +498,14 @@ void trace_hardirqs_off(void)
 }
 EXPORT_SYMBOL(trace_hardirqs_off);
 
-void trace_hardirqs_on_caller(unsigned long caller_addr)
+__visible void trace_hardirqs_on_caller(unsigned long caller_addr)
 {
if (!preempt_trace() && irq_trace())
stop_critical_timing(CALLER_ADDR0, caller_addr);
 }
 EXPORT_SYMBOL(trace_hardirqs_on_caller);
 
-void trace_hardirqs_off_caller(unsigned long caller_addr)
+__visible void trace_hardirqs_off_caller(unsigned long caller_addr)
 {
if (!preempt_trace() && irq_trace())
start_critical_timing(CALLER_ADDR0, caller_addr);
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 14/14] initconst, x86: Fix initconst mistake in ts5500 code

const data must be initconst.

Cc: x...@kernel.org
Signed-off-by: Andi Kleen 
---
 arch/x86/platform/ts5500/ts5500.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/ts5500/ts5500.c 
b/arch/x86/platform/ts5500/ts5500.c
index 39febb2..9471b94 100644
--- a/arch/x86/platform/ts5500/ts5500.c
+++ b/arch/x86/platform/ts5500/ts5500.c
@@ -88,7 +88,7 @@ struct ts5500_sbc {
 static const struct {
const char * const string;
const ssize_t offset;
-} ts5500_signatures[] __initdata = {
+} ts5500_signatures[] __initconst = {
{ "TS-5x00 AMD Elan", 0xb14 },
 };
 
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] kbuild: Remove .dot postfixes in kallsyms

For static and some LTO symbols gcc generates . postfixes.
Remove those from the kallsyms, as they are not useful to the user
and makes it much larger. This also avoids some issues with LTO.

Signed-off-by: Andi Kleen 
---
 scripts/kallsyms.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index c874304..d0e2b56 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -122,7 +122,7 @@ static int read_symbol_tr(const char *sym, unsigned long 
long addr)
 static int read_symbol(FILE *in, struct sym_entry *s)
 {
char str[500];
-   char *sym, stype;
+   char *sym, stype, *dot;
int rc;
 
rc = fscanf(in, "%llx %c %499s\n", >addr, , str);
@@ -138,6 +138,11 @@ static int read_symbol(FILE *in, struct sym_entry *s)
return -1;
}
 
+   /* Drop static . postfixes */
+   dot = strchr(str, '.');
+   if (dot)
+   *dot = 0;
+
sym = str;
/* skip prefix char */
if (symbol_prefix_char && str[0] == symbol_prefix_char)
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/6] kbuild: Use single pass kallsyms

kallsyms currenly links the kernel upto three times
(in addition to another one for modpost checks)

Linking can be a quite slow operation, especially when
the kernel has a lot of debug information (lots of IO),
or Link Time Optimization is used.

Final linking is also a non parallelizable bottlneck, so it's
always good to do it less.

Use a different kallsyms method to avoid this:
- generate a initial kallsyms table from the top level
object files
- This table is usually a super set of the final table,
but without final addresses and some extra symbols
(e.g. discard and local symbols)
- Use this table to link the vmlinux
- Then generate a new kallsyms table with padding so
that all symbols stay at the same offsets. This works
because the new table is smaller or the same than the
original one.
We let the first kallsyms generate a padding file and
then use it on the next link.
- Then finally patch in the new table into the vmlinux

The size difference between the two tables is typically
small, so the additional padding is not a problem
(a few hundred bytes in my kernels)

Right now we still do two links. One to generate
the kernel, and another one to generate the vmlinux.o
for modpost.

On my slowish laptop this cuts down the final serialized phase
of a moderate size kernel build (just relinking vmlinux) by 1/3,
from ~30s to 20s

Tested on x86, tests on other architectures would be appreciated.

Signed-off-by: Andi Kleen 
---
 scripts/Makefile|  2 +-
 scripts/elf_file_offset | 24 +
 scripts/link-vmlinux.sh | 90 +++--
 scripts/patchfile.c | 81 
 4 files changed, 141 insertions(+), 56 deletions(-)
 create mode 100755 scripts/elf_file_offset
 create mode 100644 scripts/patchfile.c

diff --git a/scripts/Makefile b/scripts/Makefile
index 01e7adb..9c84464 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -10,7 +10,7 @@
 
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include
 
-hostprogs-$(CONFIG_KALLSYMS) += kallsyms
+hostprogs-$(CONFIG_KALLSYMS) += kallsyms patchfile
 hostprogs-$(CONFIG_LOGO) += pnmtologo
 hostprogs-$(CONFIG_VT)   += conmakehash
 hostprogs-$(CONFIG_IKCONFIG) += bin2c
diff --git a/scripts/elf_file_offset b/scripts/elf_file_offset
new file mode 100755
index 000..1bf135a
--- /dev/null
+++ b/scripts/elf_file_offset
@@ -0,0 +1,24 @@
+#!/bin/bash
+# find the file offset of a section in a ELF file
+# objdump --section-headers elf-file | 
+# gawk -f elf_file_offset filesize=SIZE section=SECTIONNAME 
+# gawk needed for strtonum()
+#Idx Name  Size  VMA   LMA   File off  Algn
+#  4 .kallsyms 001fd648  81b1c068  01b1c068  00d1c068  2**3
+
+$2 == section {
+   old = strtonum("0x" $3)
+   new = strtonum(filesize)
+   if (old < new) {
+   print "Not enough padding in vmlinux for new kallsyms, 
missing",new-old > "/dev/stderr"
+   print "Please lower (=increase) PAD_RATIO in kallsyms.c"
+   exit 1
+   }
+   print "0x" $6
+   # XXX doesn't exit in gawk 4.1.0 ?!?
+   #exit(0)
+}
+#END { 
+#print section " not found" > "/dev/stderr"
+#exit 1
+#}
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 2dcb377..0300047 100644
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 #
 # link vmlinux
 #
@@ -85,11 +85,13 @@ kallsyms()
if [ -n "${CONFIG_ARM}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
fi
+   kallsymopt="${kallsymopt} $3"
 
local aflags="${KBUILD_AFLAGS} ${KBUILD_AFLAGS_KERNEL}   \
  ${NOSTDINC_FLAGS} ${LINUXINCLUDE} ${KBUILD_CPPFLAGS}"
 
${NM} -n ${1} | \
+   awk 'NF == 3 { print}' |
scripts/kallsyms ${kallsymopt} | \
${CC} ${aflags} -c -o ${2} -x assembler-with-cpp -
 }
@@ -166,51 +168,41 @@ ${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init
 
 kallsymso=""
 kallsyms_vmlinux=""
-if [ -n "${CONFIG_KALLSYMS}" ]; then
-
-   # kallsyms support
-   # Generate section listing all symbols and add it into vmlinux
-   # It's a three step process:
-   # 1)  Link .tmp_vmlinux1 so it has all symbols and sections,
-   # but __kallsyms is empty.
-   # Running kallsyms on that gives us .tmp_kallsyms1.o with
-   # the right size
-   # 2)  Link .tmp_vmlinux2 so it now has a __kallsyms section of
-   # the right size, but due to the added section, some
-   # addresses have shifted.
-   # From here, we generate a correct .tmp_kallsyms2.o
-   # 2a) We may use an extra pass as this has been necessary to
-   # woraround some alignment related bugs.
-   # KALLSYMS_EXTRA_PASS=1 is used to trigger this.
-   # 3)  The

[PATCH 4/6] kbuild: Support padding in kallsyms tables

Add support for padding the variable length tables in kallsyms.
This adds a new --pad=XXX option to kallsyms to specify the table lengths,
and another option --pad-file=X to write the table lengths to a file.
Then when a table is shorter than the padding add the necessary padding
at the end.

This allows to replace an existing symbol table later with a different
one that may differ slightly.

Add 5% slack for now in case the prediction is too small
(can happen with LTO)

Signed-off-by: Andi Kleen 
---
 scripts/kallsyms.c | 93 --
 1 file changed, 90 insertions(+), 3 deletions(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index d79027e..c874304 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -23,6 +23,13 @@
 #include 
 #include 
 
+/* 
+ * The ratio to increase the padding, by how much the final kallsyms
+ * can be larger. This is for symbols that are not visible before
+ * final linking.
+ */
+#define PAD_RATIO 20 /* 1/x = ~5% */
+
 #ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof(arr[0]))
 #endif
@@ -41,6 +48,14 @@ struct text_range {
unsigned long long start, end;
 };
 
+enum pads {
+   PAD_OFF,
+   PAD_NAMES,
+   PAD_MARKERS,
+   PAD_TOKTAB,
+   NUM_PAD
+};
+
 static unsigned long long _text;
 static struct text_range text_ranges[] = {
{ "_stext", "_etext" },
@@ -69,6 +84,7 @@ static void usage(void)
fprintf(stderr, "Usage: kallsyms [--all-symbols] "
"[--symbol-prefix=] "
"[--page-offset=] "
+   "[--pad=A,B,C] [--pad-file=name] "
"< in.map > out.S\n");
exit(1);
 }
@@ -303,7 +319,14 @@ static int expand_symbol(unsigned char *data, int len, 
char *result)
return total;
 }
 
-static void write_src(void)
+static void bad_padding(char *msg, int diff)
+{
+   fprintf(stderr, "kallsyms: %s padding too short: %d missing\n",
+   msg, diff);
+   exit(EXIT_FAILURE);
+}
+
+static void write_src(int *pad, int *opad)
 {
unsigned int i, k, off;
unsigned int best_idx[256];
@@ -335,6 +358,16 @@ static void write_src(void)
for (i = 0; i < table_cnt; i++) {
printf("\tPTR\t%#llx\n", table[i].addr - _text);
}
+   if (pad) {
+   if (i > pad[PAD_OFF])
+   bad_padding("address pointers", i - pad[PAD_OFF]);
+   for (; i < pad[PAD_OFF]; i++)
+   printf("\tPTR\t0\n");
+   } else {
+   for (i = 0; i < table_cnt / PAD_RATIO; i++)
+   printf("\tPTR\t0\n");
+   opad[PAD_OFF] = table_cnt + table_cnt/PAD_RATIO;
+   }
printf("\n");
 
output_label("kallsyms_num_syms");
@@ -363,11 +396,31 @@ static void write_src(void)
 
off += table[i].len + 1;
}
+   if (pad) {
+   if (off > pad[PAD_NAMES])
+   bad_padding("name table", off - pad[PAD_NAMES]);
+   if (off < pad[PAD_NAMES])
+   printf("\t.fill %d,1,0\n", pad[PAD_NAMES] - off);
+   } else {
+   printf("\t.fill %d,1,0\n", off/PAD_RATIO);
+   off += off/PAD_RATIO;
+   opad[PAD_NAMES] = off;
+   }
printf("\n");
 
output_label("kallsyms_markers");
for (i = 0; i < ((table_cnt + 255) >> 8); i++)
printf("\tPTR\t%d\n", markers[i]);
+   if (pad) {
+   if (i > pad[PAD_MARKERS])
+   bad_padding("markers", i - pad[PAD_MARKERS]);
+   for (; i < pad[PAD_MARKERS]; i++)
+   printf("\tPTR\t0\n");
+   } else {
+   for (k = 0; k < i/PAD_RATIO; k++)
+   printf("\tPTR\t0\n");
+   opad[PAD_MARKERS] = i + i/PAD_RATIO;
+   }
printf("\n");
 
free(markers);
@@ -380,6 +433,16 @@ static void write_src(void)
printf("\t.asciz\t\"%s\"\n", buf);
off += strlen(buf) + 1;
}
+   if (pad) {
+   if (off > pad[PAD_TOKTAB])
+   bad_padding("token table", off - pad[PAD_TOKTAB]);
+   if (off < pad[PAD_TOKTAB])
+   printf("\t.fill %d,1,0\n", pad[PAD_TOKTAB] - off);
+   } else {
+   printf("\t.fill %d,1,0\n", off/PAD_RATIO);
+   off += off/PAD_RATIO;
+   opad[PAD_TOKTAB] = off;
+   }
printf("\n");
 
output_label("kallsyms_token_index");
@@ -647,6 +710,10 @@ static void sort_symbols(void)
 
 int main(int argc, char **argv)
 {
+   int inpad[NUM_PAD], opad[NUM_PAD];
+   int *inpadp = NULL;
+   FILE *opadf = NULL;
+
if (argc >= 2) {
int i;
for (i = 1; i < argc; i++) {
@@ -661,6 +728,22 @@ int main(int argc, char **argv)
} else if

[PATCH 3/6] kbuild: Don't include const variable in kallsyms with !KALLSYMS_ALL

const variables are put into the text segment, so !KALLSYMS_ALL
includes them into the kallsyms section. Remove them to make
the kallsyms smaller. This also avoids some problems with LTO.
The way LTO generates the first pass kallsyms cannot handle
variables currently, so if we don't filter them out the
first and second level pass differ too much.

Signed-off-by: Andi Kleen 
---
 scripts/kallsyms.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index ceef756..d79027e 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -151,6 +151,11 @@ static int read_symbol(FILE *in, struct sym_entry *s)
/* exclude debugging symbols */
else if (stype == 'N')
return -1;
+   /* Don't include const symbols in the text section
+* unless --all-symbols is specified.
+*/
+   else if (toupper(stype) != 'T' && !all_symbols)
+   return -1;
 
/* include the type field in the symbol name, so that it gets
 * compressed together */
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] kbuild: Remove relocations from kallsyms table

Remove the ELF relocations from the kallsyms_address[] table.
Instead we just store offsets to _text and relocate that while
accessing the kallsyms table. This is done with a new
kallsyms_offsets[] table. With these changes .tmp_kallsyms*.o
becomes relocation free.

In theory this would also allow to shrink the kallsyms table
on 64bit by using offsets.

Signed-off-by: Andi Kleen 
---
 kernel/kallsyms.c  | 27 ---
 scripts/kallsyms.c | 18 ++
 2 files changed, 22 insertions(+), 23 deletions(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 3127ad5..e7d7844 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -36,7 +36,7 @@
  * These will be re-linked against their real values
  * during the second link stage.
  */
-extern const unsigned long kallsyms_addresses[] __attribute__((weak));
+extern const long kallsyms_offsets[] __attribute__((weak));
 extern const u8 kallsyms_names[] __attribute__((weak));
 
 /*
@@ -51,6 +51,11 @@ extern const u16 kallsyms_token_index[] 
__attribute__((weak));
 
 extern const unsigned long kallsyms_markers[] __attribute__((weak));
 
+static inline unsigned long kallsyms_address(int ind)
+{
+   return (unsigned long)RELOC_HIDE(&_text, kallsyms_offsets[ind]);
+}
+
 static inline int is_kernel_inittext(unsigned long addr)
 {
if (addr >= (unsigned long)_sinittext
@@ -186,7 +191,7 @@ unsigned long kallsyms_lookup_name(const char *name)
off = kallsyms_expand_symbol(off, namebuf, ARRAY_SIZE(namebuf));
 
if (strcmp(namebuf, name) == 0)
-   return kallsyms_addresses[i];
+   return kallsyms_address(i);
}
return module_kallsyms_lookup_name(name);
 }
@@ -203,7 +208,7 @@ int kallsyms_on_each_symbol(int (*fn)(void *, const char *, 
struct module *,
 
for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
off = kallsyms_expand_symbol(off, namebuf, ARRAY_SIZE(namebuf));
-   ret = fn(data, namebuf, NULL, kallsyms_addresses[i]);
+   ret = fn(data, namebuf, NULL, kallsyms_address(i));
if (ret != 0)
return ret;
}
@@ -219,15 +224,15 @@ static unsigned long get_symbol_pos(unsigned long addr,
unsigned long i, low, high, mid;
 
/* This kernel should never had been booted. */
-   BUG_ON(!kallsyms_addresses);
+   BUG_ON(!kallsyms_offsets);
 
-   /* Do a binary search on the sorted kallsyms_addresses array. */
+   /* Do a binary search on the sorted kallsyms_offsets array. */
low = 0;
high = kallsyms_num_syms;
 
while (high - low > 1) {
mid = low + (high - low) / 2;
-   if (kallsyms_addresses[mid] <= addr)
+   if (kallsyms_address(mid) <= addr)
low = mid;
else
high = mid;
@@ -237,15 +242,15 @@ static unsigned long get_symbol_pos(unsigned long addr,
 * Search for the first aliased symbol. Aliased
 * symbols are symbols with the same address.
 */
-   while (low && kallsyms_addresses[low-1] == kallsyms_addresses[low])
+   while (low && kallsyms_address(low - 1) == kallsyms_address(low))
--low;
 
-   symbol_start = kallsyms_addresses[low];
+   symbol_start = kallsyms_address(low);
 
/* Search for next non-aliased symbol. */
for (i = low + 1; i < kallsyms_num_syms; i++) {
-   if (kallsyms_addresses[i] > symbol_start) {
-   symbol_end = kallsyms_addresses[i];
+   if (kallsyms_address(i) > symbol_start) {
+   symbol_end = kallsyms_address(i);
break;
}
}
@@ -469,7 +474,7 @@ static unsigned long get_ksymbol_core(struct kallsym_iter 
*iter)
unsigned off = iter->nameoff;
 
iter->module_name[0] = '\0';
-   iter->value = kallsyms_addresses[iter->pos];
+   iter->value = kallsyms_address(iter->pos);
 
iter->type = kallsyms_get_symbol_type(off);
 
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 10085de..56f5986 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -190,7 +190,7 @@ static int symbol_valid(struct sym_entry *s)
 * specified so exclude them to get a stable symbol list.
 */
static char *special_symbols[] = {
-   "kallsyms_addresses",
+   "kallsyms_offsets",
"kallsyms_num_syms",
"kallsyms_names",
"kallsyms_markers",
@@ -322,19 +322,13 @@ static void write_src(void)
 * symbols that are declared static and are private to their
 * .o files.  This prevents .tmp_kallsyms.o or any other
 * object from referencing them.
+*
+* We do the offsets to _text now in kallsyms.c at runtime,
+* to get a relocationless symbol table.
 */
-

[PATCH 2/6] kbuild: Put kallsyms into own section

Put the kallsyms information into an own .kallsyms section.
This makes it easier to patch the kallsyms inside the executable.
Otherwise it shouldn't change anything.

Signed-off-by: Andi Kleen 
---
 include/asm-generic/vmlinux.lds.h | 4 
 scripts/kallsyms.c| 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index bc2121f..6214f18 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -280,6 +280,10 @@
\
TRACEDATA   \
\
+   .kallsyms  : AT(ADDR(.kallsyms) - LOAD_OFFSET) {\
+   *(.kallsyms)\
+   }   \
+   \
/* Kernel symbol table: Normal symbols */   \
__ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) { \
VMLINUX_SYMBOL(__start___ksymtab) = .;  \
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 56f5986..ceef756 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -314,7 +314,7 @@ static void write_src(void)
printf("#define ALGN .align 4\n");
printf("#endif\n");
 
-   printf("\t.section .rodata, \"a\"\n");
+   printf("\t.section .kallsyms, \"a\"\n");
 
/* Provide proper symbols relocatability by their '_text'
 * relativeness.  The symbol names cannot be used to construct
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] ASoC: fsl-sai: convert to use regmap API for Freeacale SAI

2014-02-07 Thread Xiubo Li

Signed-off-by: Xiubo Li 
Cc: Nicolin Chen 
---

This version applies against sound-3.14-rc1.


 sound/soc/fsl/fsl_sai.c | 255 +++-
 sound/soc/fsl/fsl_sai.h |  47 +
 2 files changed, 166 insertions(+), 136 deletions(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index cdd3fa8..faa65af 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,34 +23,6 @@
 
 #include "fsl_sai.h"
 
-static inline u32 sai_readl(struct fsl_sai *sai,
-   const void __iomem *addr)
-{
-   u32 val;
-
-   val = __raw_readl(addr);
-
-   if (likely(sai->big_endian_regs))
-   val = be32_to_cpu(val);
-   else
-   val = le32_to_cpu(val);
-   rmb();
-
-   return val;
-}
-
-static inline void sai_writel(struct fsl_sai *sai,
-   u32 val, void __iomem *addr)
-{
-   wmb();
-   if (likely(sai->big_endian_regs))
-   val = cpu_to_be32(val);
-   else
-   val = cpu_to_le32(val);
-
-   __raw_writel(val, addr);
-}
-
 static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai *cpu_dai,
int clk_id, unsigned int freq, int fsl_dir)
 {
@@ -61,7 +34,8 @@ static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai 
*cpu_dai,
else
reg_cr2 = FSL_SAI_RCR2;
 
-   val_cr2 = sai_readl(sai, sai->base + reg_cr2);
+   regmap_read(sai->regmap, reg_cr2, _cr2);
+
val_cr2 &= ~FSL_SAI_CR2_MSEL_MASK;
 
switch (clk_id) {
@@ -81,7 +55,7 @@ static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai 
*cpu_dai,
return -EINVAL;
}
 
-   sai_writel(sai, val_cr2, sai->base + reg_cr2);
+   regmap_write(sai->regmap, reg_cr2, val_cr2);
 
return 0;
 }
@@ -89,32 +63,22 @@ static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai 
*cpu_dai,
 static int fsl_sai_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
int clk_id, unsigned int freq, int dir)
 {
-   struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
int ret;
 
if (dir == SND_SOC_CLOCK_IN)
return 0;
 
-   ret = clk_prepare_enable(sai->clk);
-   if (ret)
-   return ret;
-
ret = fsl_sai_set_dai_sysclk_tr(cpu_dai, clk_id, freq,
FSL_FMT_TRANSMITTER);
if (ret) {
dev_err(cpu_dai->dev, "Cannot set tx sysclk: %d\n", ret);
-   goto err_clk;
+   return ret;
}
 
ret = fsl_sai_set_dai_sysclk_tr(cpu_dai, clk_id, freq,
FSL_FMT_RECEIVER);
-   if (ret) {
+   if (ret)
dev_err(cpu_dai->dev, "Cannot set rx sysclk: %d\n", ret);
-   goto err_clk;
-   }
-
-err_clk:
-   clk_disable_unprepare(sai->clk);
 
return ret;
 }
@@ -133,8 +97,8 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai 
*cpu_dai,
reg_cr4 = FSL_SAI_RCR4;
}
 
-   val_cr2 = sai_readl(sai, sai->base + reg_cr2);
-   val_cr4 = sai_readl(sai, sai->base + reg_cr4);
+   regmap_read(sai->regmap, reg_cr2, _cr2);
+   regmap_read(sai->regmap, reg_cr4, _cr4);
 
if (sai->big_endian_data)
val_cr4 &= ~FSL_SAI_CR4_MF;
@@ -183,35 +147,25 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai 
*cpu_dai,
return -EINVAL;
}
 
-   sai_writel(sai, val_cr2, sai->base + reg_cr2);
-   sai_writel(sai, val_cr4, sai->base + reg_cr4);
+   regmap_write(sai->regmap, reg_cr2, val_cr2);
+   regmap_write(sai->regmap, reg_cr4, val_cr4);
 
return 0;
 }
 
 static int fsl_sai_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
 {
-   struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
int ret;
 
-   ret = clk_prepare_enable(sai->clk);
-   if (ret)
-   return ret;
-
ret = fsl_sai_set_dai_fmt_tr(cpu_dai, fmt, FSL_FMT_TRANSMITTER);
if (ret) {
dev_err(cpu_dai->dev, "Cannot set tx format: %d\n", ret);
-   goto err_clk;
+   return ret;
}
 
ret = fsl_sai_set_dai_fmt_tr(cpu_dai, fmt, FSL_FMT_RECEIVER);
-   if (ret) {
+   if (ret)
dev_err(cpu_dai->dev, "Cannot set rx format: %d\n", ret);
-   goto err_clk;
-   }
-
-err_clk:
-   clk_disable_unprepare(sai->clk);
 
return ret;
 }
@@ -235,11 +189,12 @@ static int fsl_sai_hw_params(struct snd_pcm_substream 
*substream,
reg_mr = FSL_SAI_RMR;
}
 
-   val_cr4 = sai_readl(sai, sai->base + reg_cr4);
+   regmap_read(sai->regmap, reg_cr4, _cr4);
+   regmap_read(sai->regmap, reg_cr4, _cr5);
+
val_cr4 &= ~FSL_SAI_CR4_SYWD_MASK;
val_cr4 &= ~FSL_SAI_CR4_FRSZ_MASK;
 
-   val_cr5 = sai_readl(sai, sai->base + reg_cr5);

Re: [PATCH] jfs: fix generic posix ACL regression

2014-02-07 Thread Christoph Hellwig

On Fri, Feb 07, 2014 at 02:59:20PM -0600, Dave Kleikamp wrote:
> -#ifdef JFS_POSIX_ACL
> +#ifdef CONFIG_JFS_POSIX_ACL

Ooops, sorry.

I don't understand the can_set_xattr move - while the check obviously
aren't needed when using the generic xattr code I don't see how they
cause harm either.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

www.xrefs.info: updated with new kernels

2014-02-07 Thread John Smith

hello: the following new released kernels' source code cross
references have been added into www.xrefs.info:
version:
 - 3.12.7, 3.12.8, 3.12.9, 3.12.10
 - 3.10.26, 3.10.27, 3.10.28, 3.10.29
 - 3.4.76, 3.4.77, 3.4.78, 3.4.79

Thanks.
Xrefs.info Admin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ieee80211: Print human-readable disassoc/deauth reason codes

2014-02-07 Thread Kalle Valo

Luca Coelho  writes:

>> Forum, and there we are lucky if we get dmesg output. When we do and it 
>> contains 
>> a deauthentication reason, I always need to bring up a web page to interpret 
>> the 
>> output. With this change, one step could be skipped.
>
> But is it worth putting this parsing in the *kernel*? I mean, if anyone
> is interested enough in the problem, a simple google query is not that
> hard, right?

Sure, it's not hard to find it. My and Larry's point is more about
convenience and user friendliness.

On the other hand I do understand that kernel is getting bloated all the
time, for example openwrt is suffering from that. So not really sure
what is the best.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: rfkill-regulator: Add devicetree support.

2014-02-07 Thread Bill Fink

On Fri,  7 Feb 2014, Marek Belisko wrote:

> Signed-off-by: NeilBrown 
> Signed-off-by: Marek Belisko 
> ---
> Based on Neil's patch and extend for documentation and bindings include.
> 
>  .../bindings/net/rfkill/rfkill-relugator.txt   | 28 

  ^
  Typo in file name.

-Bill



>  include/dt-bindings/net/rfkill-regulator.h | 23 +
>  net/rfkill/rfkill-regulator.c  | 38 
> ++
>  3 files changed, 89 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
>  create mode 100644 include/dt-bindings/net/rfkill-regulator.h
> 
> diff --git 
> a/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt 
> b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> new file mode 100644
> index 000..cdb7dd7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> @@ -0,0 +1,28 @@
> +Regulator consumer for rfkill devices
> +
> +Required properties:
> +- compatible   : Must be "rfkill-regulator".
> +- label  : Name of rfkill device.
> +- type  : Type of rfkill device.
> +
> +Possible values (defined in include/dt-bindings/net/rfkill-regulator.h):
> + RFKILL_TYPE_ALL
> + RFKILL_TYPE_WLAN
> + RFKILL_TYPE_BLUETOOTH
> + RFKILL_TYPE_UWB
> + RFKILL_TYPE_WIMAX
> + RFKILL_TYPE_WWAN
> + RFKILL_TYPE_GPS
> + RFKILL_TYPE_FM
> + RFKILL_TYPE_NFC
> +
> +- vrfkill-supply - regulator device.
> +
> +Example:
> + gps-rfkill {
> + compatible = "rfkill-regulator";
> + label = "GPS";
> + type = ;
> + vrfkill-supply = <>;
> + };
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Welding Electrode/Welding Wire/Sintered Flux

2014-02-07 Thread Iris

Dear Manager,

I'm Iris. Our company dealding welding materials for many years. Mainly 
products are Welding Electrode/Welding Wire/Sintered Flux , with diferent size 
and type.

Should you have any questions, pls do not hesitate to contact me. Best price 
will be supplied to you.

Tks & br,

IrisN�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

[PATCH 1/2] sched/rt: Remove leaf_rt_rq_list from struct rq

This is a leftover from commit e23ee74777f389369431d77390c4b09332ce026a
("sched/rt: Simplify pull_rt_task() logic and remove .leaf_rt_rq_list").

Signed-off-by: Li Zefan 
---
 kernel/sched/core.c  | 1 -
 kernel/sched/sched.h | 4 
 2 files changed, 5 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a88f4a4..1f7d88a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6277,7 +6277,6 @@ void __init sched_init(void)
 
rq->rt.rt_runtime = def_rt_bandwidth.rt_runtime;
 #ifdef CONFIG_RT_GROUP_SCHED
-   INIT_LIST_HEAD(>leaf_rt_rq_list);
init_tg_rt_entry(_task_group, >rt, NULL, i, NULL);
 #endif
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 88c85b2..1c83665 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -438,10 +438,6 @@ struct rq {
struct list_head leaf_cfs_rq_list;
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
-#ifdef CONFIG_RT_GROUP_SCHED
-   struct list_head leaf_rt_rq_list;
-#endif
-
/*
 * This is part of a global counter where only the total sum
 * over all CPUs matters. A task can increase this counter on
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] sched/rt: Make init_sched_rt_calss() __init

It's a bootstrap function.

Signed-off-by: Li Zefan 
---
 kernel/sched/rt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 1c40655..e45ec9a 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1825,7 +1825,7 @@ static void switched_from_rt(struct rq *rq, struct 
task_struct *p)
resched_task(rq->curr);
 }
 
-void init_sched_rt_class(void)
+void __init init_sched_rt_class(void)
 {
unsigned int i;
 
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: smp_twd: Set the CLOCK_EVT_FEAT_PERCPU flag

2014-02-07 Thread Soren Brinkmann

The twd timers are per CPU devices. Set the corresponding flag to mark
them as such.

Signed-off-by: Soren Brinkmann 
---
 arch/arm/kernel/smp_twd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 6591e26fc13f..85407473c97d 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -294,7 +294,7 @@ static void twd_timer_setup(void)
 
clk->name = "local_timer";
clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
-   CLOCK_EVT_FEAT_C3STOP;
+   CLOCK_EVT_FEAT_C3STOP | CLOCK_EVT_FEAT_PERCPU;
clk->rating = 350;
clk->set_mode = twd_set_mode;
clk->set_next_event = twd_set_next_event;
-- 
1.8.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] jfs: fix generic posix ACL regression

2014-02-07 Thread Michael L. Semon


Looks good.  I'm keeping the patch.  It was placed through the
following tests:

*) the test suite from the January 19 git acl, as root;
   (git://git.savannah.nongnu.org/acl.git)

*) the acl test suite, as a regular user;

*) xfstests (full run); and

*) some fs_mark and LTP fsstress in a dir populated with three
   default ACLs.

Tests were done on an i686 Pentium 4 PC, using kernels 3.14.0-rc1+
and 3.13.0+.  Comparisons were made with standard XFS.  Due to non-JFS
issues, lockdep is off and CONFIG_AIO=n, meaning that their effects
are not represented here.

The xfstests run for JFS looked unchanged over kernel 3.13.0+, with
the exeption of the error "+error: ctime not updated after setfacl"
from generic/307.  The test uses integer seconds to compare ctime, so
I inserted some regular stat commands into the test.  The nanosecond
portion of the timestamps also do not change.  JFS from 3.13.0+
passed this test; XFS from 3.14.0-rc1+ passed this test as well.

For JFS, the new generic ACL infrastructure provides a reduction of
99 failures from the acl test suite, most of them from the misc.test
series of tests.  Pass or fail, results were equal to that of XFS,
which seemed to gain 10 errors from the root/*.test tests.

Thanks!  Christoph's generic ACL work now makes much more sense to
me than it did at this time yesterday.  The prompt patch from Shaggy
allows me to use it on JFS as well :-)

Michael

On Fri, 7 Feb 2014, Dave Kleikamp wrote:


I missed a couple errors in reviewing the patches converting jfs
to use the generic posix ACL function. Setting ACL's currently
fails with -EOPNOTSUPP.

Signed-off-by: Dave Kleikamp 
Reported-by: Michael L. Semon 
Cc: Christoph Hellwig 
---
fs/jfs/xattr.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c
index 3bd5ee4..46325d5 100644
--- a/fs/jfs/xattr.c
+++ b/fs/jfs/xattr.c
@@ -854,9 +854,6 @@ int jfs_setxattr(struct dentry *dentry, const char *name, 
const void *value,
int rc;
tid_t tid;

-   if ((rc = can_set_xattr(inode, name, value, value_len)))
-   return rc;
-
/*
 * If this is a request for a synthetic attribute in the system.*
 * namespace use the generic infrastructure to resolve a handler
@@ -865,6 +862,9 @@ int jfs_setxattr(struct dentry *dentry, const char *name, 
const void *value,
if (!strncmp(name, XATTR_SYSTEM_PREFIX, XATTR_SYSTEM_PREFIX_LEN))
return generic_setxattr(dentry, name, value, value_len, flags);

+   if ((rc = can_set_xattr(inode, name, value, value_len)))
+   return rc;
+
if (value == NULL) {/* empty EA, do not remove */
value = "";
value_len = 0;
@@ -1034,9 +1034,6 @@ int jfs_removexattr(struct dentry *dentry, const char 
*name)
int rc;
tid_t tid;

-   if ((rc = can_set_xattr(inode, name, NULL, 0)))
-   return rc;
-
/*
 * If this is a request for a synthetic attribute in the system.*
 * namespace use the generic infrastructure to resolve a handler
@@ -1045,6 +1042,9 @@ int jfs_removexattr(struct dentry *dentry, const char 
*name)
if (!strncmp(name, XATTR_SYSTEM_PREFIX, XATTR_SYSTEM_PREFIX_LEN))
return generic_removexattr(dentry, name);

+   if ((rc = can_set_xattr(inode, name, NULL, 0)))
+   return rc;
+
tid = txBegin(inode->i_sb, 0);
mutex_lock(>commit_mutex);
rc = __jfs_setxattr(tid, dentry->d_inode, name, NULL, 0, XATTR_REPLACE);
@@ -1061,7 +1061,7 @@ int jfs_removexattr(struct dentry *dentry, const char 
*name)
 * attributes are handled directly.
 */
const struct xattr_handler *jfs_xattr_handlers[] = {
-#ifdef JFS_POSIX_ACL
+#ifdef CONFIG_JFS_POSIX_ACL
_acl_access_xattr_handler,
_acl_default_xattr_handler,
#endif
--
1.8.5.3



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Missing ATSC, the whole block, in a make oldconfig output

2014-02-07 Thread Gene Heskett

Greetings guys;

So has make oldconfig been superceeded?  Or has that whole tree been 
excised from the sources?
 
Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Staging: comedi: fix memory leak in comedi_bond.c

2014-02-07 Thread Chase Southwood

We allocate bdev and then krealloc the devs pointer in order to add bdev
at the end of the devpriv->devs array list.  But if for some reason this
krealloc fails, we need to free bdev before returning an error otherwise
this memory is leaked.

Signed-off-by: Chase Southwood 
---
 drivers/staging/comedi/drivers/comedi_bond.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/comedi/drivers/comedi_bond.c 
b/drivers/staging/comedi/drivers/comedi_bond.c
index 51a59e5..406aedb 100644
--- a/drivers/staging/comedi/drivers/comedi_bond.c
+++ b/drivers/staging/comedi/drivers/comedi_bond.c
@@ -254,6 +254,7 @@ static int do_dev_config(struct comedi_device *dev, struct 
comedi_devconfig *it)
if (!devs) {
dev_err(dev->class_dev,
"Could not allocate memory. Out of 
memory?\n");
+   kfree(bdev);
return -ENOMEM;
}
devpriv->devs = devs;
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] v3.14-rc1 locking bug in system suspend

2014-02-07 Thread Shawn Guo

On Thu, Feb 06, 2014 at 10:55:13PM +0800, Shawn Guo wrote:
> On Wed, Feb 05, 2014 at 10:54:10PM +0800, Shawn Guo wrote:
> > I start seeing the following locking bug on IMX6 with suspend operation
> > after moving to v3.14-rc1.  Before I start looking into the issue, I
> > would like to confirm if it's an IMX specific problem or one seen on
> > other platforms.  Please ask if you need more info.
> 
> Sorry.  This is not a new bug of v3.14-rc1.  It's been there with
> v3.13-rc for a while.  It looks like there is something wrong in the
> use of power_lock in struct snd_card.  Will dig into it.

Okay.  This is an IMX specific problem caused by audio driver.  I will
send a fix to alsa-devel list shortly.

Shawn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Commit 597ce1723 (MIPS: Support for 64-bit FP with O32 binaries) causing qemu hang with mips64 kernels

On 02/07/2014 07:57 PM, Huacai Chen wrote:

Hi,

Maybe you can try this:
http://patchwork.linux-mips.org/patch/6506/
http://patchwork.linux-mips.org/patch/6507/

With those two patches applied the problem is gone.

Thanks a lot!

Guenter

On Sat, Feb 8, 2014 at 11:39 AM, Guenter Roeck wrote:

Hi all,

in 3.14-rc1, my mips64 qemu test fails. The image boots and then hangs.
Bisect points to commit 597ce1723 (MIPS: Support for 64-bit FP with O32
binaries).
Reverting this commit fixes the problem. Disabling MIPS_O32_FP64_SUPPORT
in my test image does _not_ solve the problem. The qemu version does not
seem
to make a difference; I tested with qemu 1.6.0 and 1.7.0.

Console log output is available in
http://server.roeck-us.net:8010/builders/qemu-mips64-master/builds/34/steps/buildcommand/logs/stdio

When the problem is seen, the emulation hangs as can be seen in the log,
and the qemu process consumes 100% CPU until it is killed.

qemu command line is

qemu-system-mips64 -kernel vmlinux -M malta -hda
core-image-minimal-qemumips64.ext3 \
-vga cirrus -usb -usbdevice wacom-tablet -no-reboot -m 128 --append
"root=/dev/hda \
rw mem=128M console=ttyS0 console=tty" -nographic

The same configuration works fine with earlier kernels. I'll be happy to
provide
the detailed configuration as well as the root file system for testing if
needed.

Obviously I have no idea if this is a problem with the patch or with qemu.
If there is anything I can do to help tracking down the problem further,
please let me know.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: Commit 597ce1723 (MIPS: Support for 64-bit FP with O32 binaries) causing qemu hang with mips64 kernels

2014-02-07 Thread Huacai Chen

Hi,

Maybe you can try this:
http://patchwork.linux-mips.org/patch/6506/
http://patchwork.linux-mips.org/patch/6507/

On Sat, Feb 8, 2014 at 11:39 AM, Guenter Roeck  wrote:
>
> Hi all,
>
> in 3.14-rc1, my mips64 qemu test fails. The image boots and then hangs.
> Bisect points to commit 597ce1723 (MIPS: Support for 64-bit FP with O32
> binaries).
> Reverting this commit fixes the problem. Disabling MIPS_O32_FP64_SUPPORT
> in my test image does _not_ solve the problem. The qemu version does not
> seem
> to make a difference; I tested with qemu 1.6.0 and 1.7.0.
>
> Console log output is available in
> http://server.roeck-us.net:8010/builders/qemu-mips64-master/builds/34/steps/buildcommand/logs/stdio
>
> When the problem is seen, the emulation hangs as can be seen in the log,
> and the qemu process consumes 100% CPU until it is killed.
>
> qemu command line is
>
> qemu-system-mips64 -kernel vmlinux -M malta -hda
> core-image-minimal-qemumips64.ext3 \
> -vga cirrus -usb -usbdevice wacom-tablet -no-reboot -m 128 --append
> "root=/dev/hda \
> rw mem=128M console=ttyS0 console=tty" -nographic
>
> The same configuration works fine with earlier kernels. I'll be happy to
> provide
> the detailed configuration as well as the root file system for testing if
> needed.
>
> Obviously I have no idea if this is a problem with the patch or with qemu.
> If there is anything I can do to help tracking down the problem further,
> please let me know.
>
> Thanks,
> Guenter
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Qemu-devel] Commit 34b9c07a3 (microblaze: Disable stack protection from bootloader) causing qemu crash


On 02/07/2014 06:31 PM, Edgar E. Iglesias wrote:

On Fri, Feb 07, 2014 at 03:17:31PM -0800, Guenter Roeck wrote:

Michal,

commit 34b9c07a3 (microblaze: Disable stack protection from bootloader) results
in the following qemu crash in 3.14-rc1.

/opt/buildbot/bin/qemu-system-microblaze -M petalogix-s3adsp1800 -kernel 
arch/microblaze/boot/linux.bin -no-reboot -append "console=ttyUL0,115200 " 
-nographic
qemu: fatal: fetching nop sequence

IN: PC=20
rmsr=4300 resr=7 rear=c0389fe8 debug=0 imm=ffd0 iflags=0 fsr=0
btaken=1 btarget=c03a9f24 mode=kernel(saved=kernel) eip=512 ie=0
r00= r01=c0389fcc r02=c0386a52 r03=00c0
r04=4100 r05=9052fab4 r06= r07=90530ab4
r08= r09=0040 r10=0040 r11=c03a9f24
r12=00621000 r13=40aef0c0 r14= r15=c294
r16= r17=c03a9f28 r18= r19=
r20= r21= r22= r23=
r24= r25= r26= r27=
r28= r29=0040 r30=0300 r31=c03932d4


Aborted (core dumped)

I have seen this with qemu 1.6.0 and 1.7.0.

Reverting the patch solves the problem.

Is this a qemu bug, a bug in the code, or a bug in my configuration ?
Any idea what I can do about it ?


Hi Guenter,

Seems to be a typo in the kernel, the following should fix it.

Cheers,
Edgar

---8<---
From: "Edgar E. Iglesias" 
Date: Sat, 8 Feb 2014 10:59:59 +1000
Subject: [PATCH] microblaze: Fix a typo when disabling stack protection

Correct a typo causing the stack protector to be left enabled.
0xFFF -> 0x

Signed-off-by: Edgar E. Iglesias 


Hi Edgar,

you are right, that fixes the problem.

Tested-by: Guenter Roeck 

Thanks!
Guenter


---
  arch/microblaze/kernel/head.S | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/microblaze/kernel/head.S b/arch/microblaze/kernel/head.S
index b7fb043..17645b2 100644
--- a/arch/microblaze/kernel/head.S
+++ b/arch/microblaze/kernel/head.S
@@ -66,7 +66,7 @@ real_start:
mts rmsr, r0
  /* Disable stack protection from bootloader */
mts rslr, r0
-   addir8, r0, 0xFFF
+   addir8, r0, 0x
mts rshr, r8
  /*
   * According to Xilinx, msrclr instruction behaves like 'mfs rX,rpc'



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Commit 597ce1723 (MIPS: Support for 64-bit FP with O32 binaries) causing qemu hang with mips64 kernels



Hi all,

in 3.14-rc1, my mips64 qemu test fails. The image boots and then hangs.
Bisect points to commit 597ce1723 (MIPS: Support for 64-bit FP with O32 
binaries).
Reverting this commit fixes the problem. Disabling MIPS_O32_FP64_SUPPORT
in my test image does _not_ solve the problem. The qemu version does not seem
to make a difference; I tested with qemu 1.6.0 and 1.7.0.

Console log output is available in
http://server.roeck-us.net:8010/builders/qemu-mips64-master/builds/34/steps/buildcommand/logs/stdio

When the problem is seen, the emulation hangs as can be seen in the log,
and the qemu process consumes 100% CPU until it is killed.

qemu command line is

qemu-system-mips64 -kernel vmlinux -M malta -hda 
core-image-minimal-qemumips64.ext3 \
-vga cirrus -usb -usbdevice wacom-tablet -no-reboot -m 128 --append 
"root=/dev/hda \
rw mem=128M console=ttyS0 console=tty" -nographic

The same configuration works fine with earlier kernels. I'll be happy to provide
the detailed configuration as well as the root file system for testing if 
needed.

Obviously I have no idea if this is a problem with the patch or with qemu.
If there is anything I can do to help tracking down the problem further,
please let me know.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/5] ARM: qcom: Split Qualcomm support into legacy and multiplatform

2014-02-07 Thread Stephen Boyd

On 02/06, Kumar Gala wrote:
> diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-qcom/platsmp.c
> similarity index 98%
> rename from arch/arm/mach-msm/platsmp.c
> rename to arch/arm/mach-qcom/platsmp.c
> index 251a91e..67823a7 100644
> --- a/arch/arm/mach-msm/platsmp.c
> +++ b/arch/arm/mach-qcom/platsmp.c
> @@ -2,6 +2,7 @@
>   *  Copyright (C) 2002 ARM Ltd.
>   *  All Rights Reserved
>   *  Copyright (c) 2010, Code Aurora Forum. All rights reserved.
> + *  Copyright (c) 2014 The Linux Foundation. All rights reserved.

We should replace the Code Aurora Forum copyright with Linux
Foundation here.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 3/3] mmc: sdhci-msm: Add platform_execute_tunning implementation

2014-02-07 Thread Stephen Boyd

On 01/30, Georgi Djakov wrote:
> @@ -75,17 +110,389 @@ struct sdhci_msm_host {
>  };
>  
>  /* MSM platform specific tuning */
> -int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode)
> +static inline int msm_dll_poll_ck_out_en(struct sdhci_host *host, u8 poll)
> +{
> + u32 wait_cnt = 50;
> + u8 ck_out_en = 0;

Looks like a useless assignment.

> + struct mmc_host *mmc = host->mmc;
> +
> + /* poll for CK_OUT_EN bit.  max. poll time = 50us */
> + ck_out_en = !!(readl_relaxed(host->ioaddr + CORE_DLL_CONFIG) &
> + CORE_CK_OUT_EN);
> +
> + while (ck_out_en != poll) {
> + if (--wait_cnt == 0) {
> + dev_err(mmc_dev(mmc), "%s: CK_OUT_EN bit is not %d\n",
> +mmc_hostname(mmc), poll);
> + return -ETIMEDOUT;
> + }
> + udelay(1);
> +
> + ck_out_en = !!(readl_relaxed(host->ioaddr + CORE_DLL_CONFIG) &
> + CORE_CK_OUT_EN);
> + }
> +
> + return 0;
> +}
> +
> +static int msm_config_cm_dll_phase(struct sdhci_host *host, u8 phase)
> +{
> + int rc = 0;

Looks like a useless assignment.

> + u8 grey_coded_phase_table[] = {
> + 0x0, 0x1, 0x3, 0x2, 0x6, 0x7, 0x5, 0x4,
> + 0xc, 0xd, 0xf, 0xe, 0xa, 0xb, 0x9, 0x8
> + };

This could be static const?

> + unsigned long flags;
> + u32 config;
> + struct mmc_host *mmc = host->mmc;
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config &= ~(CORE_CDR_EN | CORE_CK_OUT_EN);
> + config |= (CORE_CDR_EXT_EN | CORE_DLL_EN);
> + writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> +
> + /* Wait until CK_OUT_EN bit of DLL_CONFIG register becomes '0' */
> + rc = msm_dll_poll_ck_out_en(host, 0);
> + if (rc)
> + goto err_out;
> +
> + /*
> +  * Write the selected DLL clock output phase (0 ... 15)
> +  * to CDR_SELEXT bit field of DLL_CONFIG register.
> +  */
> + writel_relaxed(((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
> +  & ~(0xF << 20))
> + | (grey_coded_phase_table[phase] << 20)),
> +host->ioaddr + CORE_DLL_CONFIG);

Wow this is complicated. Can we please break this up into
multiple lines? What does 0xf << 20 mean?

> +
> + /* Set CK_OUT_EN bit of DLL_CONFIG register to 1. */
> + writel_relaxed((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
> + | CORE_CK_OUT_EN), host->ioaddr + CORE_DLL_CONFIG);
> +
[...]
> +}
> +
> +static int msm_find_most_appropriate_phase(struct sdhci_host *host,
> +u8 *phase_table, u8 total_phases)
> +{
[...]
> +
> + for (cnt = 0; cnt <= row_index; cnt++) {
> + if (phases_per_row[cnt] > curr_max) {
> + curr_max = phases_per_row[cnt];
> + selected_row_index = cnt;
> + }
> + }
> +
> + i = ((curr_max * 3) / 4);

Unnecessary extra parentheses here.

> + if (i)
> + i--;
> +
> + ret = (int)ranges[selected_row_index][i];

Is this cast necessary?

> +
> + if (ret >= MAX_PHASES) {
> + ret = -EINVAL;
> + dev_err(mmc_dev(mmc), "%s: invalid phase selected=%d\n",
> +mmc_hostname(mmc), ret);
> + }
> +
> + return ret;
> +}
> +
> +static inline void msm_cm_dll_set_freq(struct sdhci_host *host)
> +{
> + u32 mclk_freq = 0;
> +
> + /* Program the MCLK value to MCLK_FREQ bit field */
> + if (host->clock <= 11200)
> + mclk_freq = 0;
> + else if (host->clock <= 12500)
> + mclk_freq = 1;
> + else if (host->clock <= 13700)
> + mclk_freq = 2;
> + else if (host->clock <= 15000)
> + mclk_freq = 3;
> + else if (host->clock <= 16200)
> + mclk_freq = 4;
> + else if (host->clock <= 17500)
> + mclk_freq = 5;
> + else if (host->clock <= 18700)
> + mclk_freq = 6;
> + else if (host->clock <= 2)
> + mclk_freq = 7;

This could be a case statement but I'm not sure it's any clearer.
At least the range is specified.

switch (host->clock) {
case 0 ... 11200:
mclk_freq = 0;
break;
case 11201 ...  12500:
mclk_freq = 1;
break;
...

> +
> + writel_relaxed(((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
> +  & ~(7 << 24)) | (mclk_freq << 24)),
> +host->ioaddr + CORE_DLL_CONFIG);

This is also complicated. Can you split this up into multiple lines?

> +int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode)
> +{
[...]
> + do {
> + struct mmc_command cmd = { 0 };
> + struct mmc_data data = { 0 };
> +

Re: [PATCH] slub: Hold list_lock unconditionally before the call to add_full.

2014-02-07 Thread Gautham R Shenoy

On Fri, Feb 07, 2014 at 12:46:19PM -0800, David Rientjes wrote:
> On Sat, 8 Feb 2014, Gautham R Shenoy wrote:
> 
> > Hi,
> > 
> > From the lockdep annotation and the comment that existed before the
> > lockdep annotations were introduced, 
> > mm/slub.c:add_full(s, n, page) expects to be called with n->list_lock
> > held.
> > 
> > However, there's a call path in deactivate_slab() when
> > 
> >  (new.inuse || n->nr_partial <= s->min_partial) &&
> >  !(new.freelist) &&
> >  !(kmem_cache_debug(s))
> > 
> > which ends up calling add_full() without holding
> > n->list_lock.
> > 
> > This was discovered while onlining/offlining cpus in 3.14-rc1 due to
> > the lockdep annotations added by commit
> > c65c1877bd6826ce0d9713d76e30a7bed8e49f38.
> > 
> > Fix this by unconditionally taking the lock
> > irrespective of the state of kmem_cache_debug(s).
> > 
> > Cc: Peter Zijlstra 
> > Cc: Pekka Enberg 
> > Signed-off-by: Gautham R. Shenoy 
> 
> No, it's not needed unless kmem_cache_debug(s) is actually set, 
> specifically s->flags & SLAB_STORE_USER.
> 
> You want the patch at http://marc.info/?l=linux-kernel=139147105027693 
> instead which is already in -mm and linux-next.
>

Ah, thanks! Wasn't aware of this fix. Shall apply this one.

--
Thanks and Regards
gautham. 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] staging: android: remove unused constant, BINDER_SET_IDLE_PRIORITY

2014-02-07 Thread SeongJae Park

Remove constant BINDER_SET_IDLE_PRIORITY because it is not used from
anywhere.

Signed-off-by: SeongJae Park 
---
 drivers/staging/android/binder.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/android/binder.h b/drivers/staging/android/binder.h
index c4c1ed6..6d08e61 100644
--- a/drivers/staging/android/binder.h
+++ b/drivers/staging/android/binder.h
@@ -87,10 +87,9 @@ struct binder_version {
 #define BINDER_WRITE_READ  _IOWR('b', 1, struct binder_write_read)
 #define BINDER_SET_IDLE_TIMEOUT_IOW('b', 3, __s64)
 #define BINDER_SET_MAX_THREADS _IOW('b', 5, __u32)
-#define BINDER_SET_IDLE_PRIORITY   _IOW('b', 6, __s32)
-#define BINDER_SET_CONTEXT_MGR _IOW('b', 7, __s32)
-#define BINDER_THREAD_EXIT _IOW('b', 8, __s32)
-#define BINDER_VERSION _IOWR('b', 9, struct binder_version)
+#define BINDER_SET_CONTEXT_MGR _IOW('b', 6, __s32)
+#define BINDER_THREAD_EXIT _IOW('b', 7, __s32)
+#define BINDER_VERSION _IOWR('b', 8, struct binder_version)
 
 /*
  * NOTE: Two special error codes you should check for when calling
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] staging: android: binder: use whitespace consistently

2014-02-07 Thread SeongJae Park

Whitespace between #define keyword and BINDER_* constants are space in
some point and tab in some point. Using space or tab is just writer's
choice. But, let's use them more consistently.

Signed-off-by: SeongJae Park 
---
 drivers/staging/android/binder.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/binder.h b/drivers/staging/android/binder.h
index cbe34516..c4c1ed6 100644
--- a/drivers/staging/android/binder.h
+++ b/drivers/staging/android/binder.h
@@ -85,11 +85,11 @@ struct binder_version {
 #define BINDER_CURRENT_PROTOCOL_VERSION 7
 
 #define BINDER_WRITE_READ  _IOWR('b', 1, struct binder_write_read)
-#defineBINDER_SET_IDLE_TIMEOUT _IOW('b', 3, __s64)
-#defineBINDER_SET_MAX_THREADS  _IOW('b', 5, __u32)
-#defineBINDER_SET_IDLE_PRIORITY_IOW('b', 6, __s32)
-#defineBINDER_SET_CONTEXT_MGR  _IOW('b', 7, __s32)
-#defineBINDER_THREAD_EXIT  _IOW('b', 8, __s32)
+#define BINDER_SET_IDLE_TIMEOUT_IOW('b', 3, __s64)
+#define BINDER_SET_MAX_THREADS _IOW('b', 5, __u32)
+#define BINDER_SET_IDLE_PRIORITY   _IOW('b', 6, __s32)
+#define BINDER_SET_CONTEXT_MGR _IOW('b', 7, __s32)
+#define BINDER_THREAD_EXIT _IOW('b', 8, __s32)
 #define BINDER_VERSION _IOWR('b', 9, struct binder_version)
 
 /*
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v5 1/2] dmaengine: add Qualcomm BAM dma driver

2014-02-07 Thread Stephen Boyd

On 02/04, Andy Gross wrote:
> diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
> new file mode 100644
> index 000..214250c
> --- /dev/null
> +++ b/drivers/dma/qcom_bam_dma.c
> @@ -0,0 +1,1066 @@
> +/*
> + * QCOM BAM DMA engine driver

Can you please move this down into the comment below?

> + *
> + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *

And split this out into its own comment block? I think this will
make the lawyers happier.

> + *
> + * QCOM BAM DMA blocks are distributed amongst a number of the on-chip
> + * peripherals on the MSM 8x74.  The configuration of the channels are 
> dependent
> + * on the way they are hard wired to that specific peripheral.  The 
> peripheral
> + * device tree entries specify the configuration of each channel.
> + *
> + * The DMA controller requires the use of external memory for storage of the
> + * hardware descriptors for each channel.  The descriptor FIFO is accessed 
> as a
> + * circular buffer and operations are managed according to the offset within 
> the
> + * FIFO.  After pipe/channel reset, all of the pipe registers and internal 
> state
> + * are back to defaults.
> + *
> + * During DMA operations, we write descriptors to the FIFO, being careful to
> + * handle wrapping and then write the last FIFO offset to that channel's
> + * P_EVNT_REG register to kick off the transaction.  The P_SW_OFSTS register
> + * indicates the current FIFO offset that is being processed, so there is 
> some
> + * indication of where the hardware is currently working.
> + */
[...]
> +
> +/* PIPE CTRL */
> +#define  P_ENBIT(1)

   
Nitpick: Weird tab here?

> +
> +/**
> + * bam_start_dma - start next transaction
> + * @bchan - bam dma channel
> + *
> + * Note: must hold bam dma channel vc.lock

You can use lockdep_assert_held() here to document this
requirement and test for it at runtime.

> + */
> +static void bam_start_dma(struct bam_chan *bchan)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] SUNRPC: Allow one callback request to be received from two sk_buff

2014-02-07 Thread shaobingqing

In current code, there only one struct rpc_rqst is prealloced. If one
callback request is received from two sk_buff, the xprt_alloc_bc_request
would be execute two times with the same transport->xid. The first time
xprt_alloc_bc_request will alloc one struct rpc_rqst and the TCP_RCV_COPY_DATA
bit of transport->tcp_flags will not be cleared. The second time
xprt_alloc_bc_request could not alloc struct rpc_rqst any more and NULL
pointer will be returned, then xprt_force_disconnect occur. I think one
callback request can be allowed to be received from two sk_buff.

Signed-off-by: shaobingqing 
---
 include/linux/sunrpc/xprt.h |1 +
 net/sunrpc/xprt.c   |1 +
 net/sunrpc/xprtsock.c   |   13 -
 3 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/include/linux/sunrpc/xprt.h b/include/linux/sunrpc/xprt.h
index cec7b9b..82bfe01 100644
--- a/include/linux/sunrpc/xprt.h
+++ b/include/linux/sunrpc/xprt.h
@@ -211,6 +211,7 @@ struct rpc_xprt {
 * items */
struct list_headbc_pa_list; /* List of preallocated
 * backchannel rpc_rqst's */
+   struct rpc_rqst *req_first;
 #endif /* CONFIG_SUNRPC_BACKCHANNEL */
struct list_headrecv;
 
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index 095363e..93ad8bc 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -1256,6 +1256,7 @@ static void xprt_init(struct rpc_xprt *xprt, struct net 
*net)
 #if defined(CONFIG_SUNRPC_BACKCHANNEL)
spin_lock_init(>bc_pa_lock);
INIT_LIST_HEAD(>bc_pa_list);
+   xprt->req_first = NULL;
 #endif /* CONFIG_SUNRPC_BACKCHANNEL */
 
xprt->last_used = jiffies;
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index ee03d35..c43dca4 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1272,7 +1272,16 @@ static inline int xs_tcp_read_callback(struct rpc_xprt 
*xprt,
container_of(xprt, struct sock_xprt, xprt);
struct rpc_rqst *req;
 
-   req = xprt_alloc_bc_request(xprt);
+   if (xprt->req_first != NULL &&
+   xprt->req_first->rq_xid == transport->tcp_xid) {
+   req = xprt->req_first;
+   } else if (xprt->req_first != NULL &&
+   xprt->req_first->rq_xid != transport->tcp_xid) {
+   xprt_free_bc_request(xprt);
+   req = xprt_alloc_bc_request(xprt);
+   } else {
+   req = xprt_alloc_bc_request(xprt);
+   }
if (req == NULL) {
printk(KERN_WARNING "Callback slot table overflowed\n");
xprt_force_disconnect(xprt);
@@ -1297,6 +1306,8 @@ static inline int xs_tcp_read_callback(struct rpc_xprt 
*xprt,
list_add(>rq_bc_list, _serv->sv_cb_list);
spin_unlock(_serv->sv_cb_lock);
wake_up(_serv->sv_cb_waitq);
+   } else {
+   xprt->req_first = req;
}
 
req->rq_private_buf.len = transport->tcp_copied;
-- 
1.7.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Qemu-devel] Commit 34b9c07a3 (microblaze: Disable stack protection from bootloader) causing qemu crash

2014-02-07 Thread Edgar E. Iglesias

On Fri, Feb 07, 2014 at 03:17:31PM -0800, Guenter Roeck wrote:
> Michal,
> 
> commit 34b9c07a3 (microblaze: Disable stack protection from bootloader) 
> results
> in the following qemu crash in 3.14-rc1.
> 
> /opt/buildbot/bin/qemu-system-microblaze -M petalogix-s3adsp1800 -kernel 
> arch/microblaze/boot/linux.bin -no-reboot -append "console=ttyUL0,115200 " 
> -nographic
> qemu: fatal: fetching nop sequence
> 
> IN: PC=20
> rmsr=4300 resr=7 rear=c0389fe8 debug=0 imm=ffd0 iflags=0 fsr=0
> btaken=1 btarget=c03a9f24 mode=kernel(saved=kernel) eip=512 ie=0
> r00= r01=c0389fcc r02=c0386a52 r03=00c0
> r04=4100 r05=9052fab4 r06= r07=90530ab4
> r08= r09=0040 r10=0040 r11=c03a9f24
> r12=00621000 r13=40aef0c0 r14= r15=c294
> r16= r17=c03a9f28 r18= r19=
> r20= r21= r22= r23=
> r24= r25= r26= r27=
> r28= r29=0040 r30=0300 r31=c03932d4
> 
> 
> Aborted (core dumped)
> 
> I have seen this with qemu 1.6.0 and 1.7.0.
> 
> Reverting the patch solves the problem.
> 
> Is this a qemu bug, a bug in the code, or a bug in my configuration ?
> Any idea what I can do about it ?

Hi Guenter,

Seems to be a typo in the kernel, the following should fix it.

Cheers,
Edgar

---8<---
From: "Edgar E. Iglesias" 
Date: Sat, 8 Feb 2014 10:59:59 +1000
Subject: [PATCH] microblaze: Fix a typo when disabling stack protection

Correct a typo causing the stack protector to be left enabled.
0xFFF -> 0x

Signed-off-by: Edgar E. Iglesias 
---
 arch/microblaze/kernel/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/microblaze/kernel/head.S b/arch/microblaze/kernel/head.S
index b7fb043..17645b2 100644
--- a/arch/microblaze/kernel/head.S
+++ b/arch/microblaze/kernel/head.S
@@ -66,7 +66,7 @@ real_start:
mts rmsr, r0
 /* Disable stack protection from bootloader */
mts rslr, r0
-   addir8, r0, 0xFFF
+   addir8, r0, 0x
mts rshr, r8
 /*
  * According to Xilinx, msrclr instruction behaves like 'mfs rX,rpc'
-- 
1.9.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Attaching a cgroup subsystem to multiple hierarchies

(Add Michal back to the Cc list, and Cc cgroup mailing list)

On 2014/2/7 17:21, Glyn Normington wrote:
> Hi Michal
> 
> On 6 Feb 2014, at 18:59, Michal Hocko  wrote:
> 
>> On Wed 05-02-14 14:39:52, Glyn Normington wrote:
>>> Reading cgroups.txt and casting around the net leads me to believe
>>> that it is possible to attach a cgroup subsystem (e.g. memory) to
>>> multiple hierarchies, but this seems to result in “mirrored”
>>> hierarchies which are automatically kept in step with each other -
>>> essentially it looks like the same hierarchy at multiple file system
>>> paths.
>>>
>>> Take the following interaction for example:
>>>
>>> \begin{verbatim}
>>> $ pwd   
>>> /home/vagrant
>>> $ mkdir mem1
>>> $ mkdir mem2
>>> $ sudo su
>>> # mount -t cgroup -o memory none /home/vagrant/mem1
>>> # mount -t cgroup -o memory none /home/vagrant/mem2
>>> # cd mem1
>>> # mkdir inst1  
>>> # ls inst1 
>>> cgroup.clone_children  memory.failcnt ...
>>> # ls ../mem2
>>> cgroup.clone_children  inst1 memory.limit_in_bytes ...
>>> # cd inst1
>>> # echo 100 > memory.limit_in_bytes 
>>> # cat memory.limit_in_bytes 
>>> 1003520
>>> # cat ../../mem2/inst1/memory.limit_in_bytes 
>>> 1003520
>>> # echo $$ > tasks
>>> # cat tasks
>>> 1365
>>> 1409
>>> # cat ../../mem2/inst1/tasks
>>> 1365
>>> 1411
>>>
>>> Is this working as intended?
>>
>> Yes, it doesn't make any sense to have two different views on the same
>> controllers.
> 
> Then wouldn’t it be better for the second mount to fail?
> 

We don't disallow mounting procfs/sysfs to more than one mount point.
Why we want to do this to cgroupfs?

>>
>>> Is there some other way to attach a subsystem to *distinct*
>>> hierarchies?
>>
>> No.
>>
>>> Distinct hierarchies would allow distinct cgroups, distinct settings
>>> (e.g. memory.limit_in_bytes) and distinct partitions of the tasks in
>>> the system.
>>
>> Which one should be applied then?
> 
> Good question. All of them, I would say: the constraints due to distinct 
> settings would be ANDed together.
> 
> The implementation would be more complex and less efficient as a subsystem's 
> resources consumed by a process would need charging against each hierarchy to 
> which the subsystem was attached.
> 
> I very much doubt this would be worth implementing and I’m not at all 
> suggesting it.
> 

Don't even think about it. :)

>>
>>>
>>> Note: I don’t have a good use for this function - I’m simply
>>> trying to reverse engineer the semantics of cgroups to get a precise
>>> understanding.
>>
>> I think there is no need to reverse engineer ;)
>> Documentation/cgroups/cgroups.txt in the kernel tree does give a decent
>> description IMO.
> 
> I disagree. For example, cgroups.txt does not clearly state whether or not a 
> single subsystem may be attached to distinct hierarchies.
> 
> This seems to have caused confusion elsewhere. For example, Red Hat write “… 
> a single subsystem can be attached to two hierarchies if both of those 
> hierarchies have only that subsystem attached.” ([1]).
> 

No documentation is perfect, but you can make it better by sending us
a patch.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] jffs2: remove wait queue after schedule()

@wait is a local variable, so if we don't remove it from the wait queue
list, later wake_up() may end up accessing invalid memory.

This was spotted by eyes.

Cc: 
Signed-off-by: Li Zefan 
---
 fs/jffs2/nodemgmt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/jffs2/nodemgmt.c b/fs/jffs2/nodemgmt.c
index fb30161..610a22c 100644
--- a/fs/jffs2/nodemgmt.c
+++ b/fs/jffs2/nodemgmt.c
@@ -179,6 +179,7 @@ int jffs2_reserve_space(struct jffs2_sb_info *c, uint32_t 
minsize,
spin_unlock(>erase_completion_lock);
 
schedule();
+   remove_wait_queue(>erase_wait, 
);
} else
spin_unlock(>erase_completion_lock);
} else if (ret)
-- 
1.8.0.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] jffs2: fix unbalanced locking

This was found by our internal debugging feature on runtime, but this
bug won't lead to deadlock, as the structure that this lock is embedded
in is freed on error.

Cc: 
Signed-off-by: Li Zefan 
---
 fs/jffs2/readinode.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/jffs2/readinode.c b/fs/jffs2/readinode.c
index 386303d..8261021 100644
--- a/fs/jffs2/readinode.c
+++ b/fs/jffs2/readinode.c
@@ -1143,6 +1143,7 @@ static int jffs2_do_read_inode_internal(struct 
jffs2_sb_info *c,
JFFS2_ERROR("cannot read nodes for ino %u, returned error is 
%d\n", f->inocache->ino, ret);
if (f->inocache->state == INO_STATE_READING)
jffs2_set_inocache_state(c, f->inocache, 
INO_STATE_CHECKEDABSENT);
+   mutex_unlock(>sem);
return ret;
}
 
@@ -1159,6 +1160,7 @@ static int jffs2_do_read_inode_internal(struct 
jffs2_sb_info *c,
jffs2_free_tmp_dnode_info(rii.mdata_tn);
rii.mdata_tn = NULL;
}
+   mutex_unlock(>sem);
return ret;
}
 
@@ -1183,6 +1185,7 @@ static int jffs2_do_read_inode_internal(struct 
jffs2_sb_info *c,
if (!rii.fds) {
if (f->inocache->state == INO_STATE_READING)
jffs2_set_inocache_state(c, 
f->inocache, INO_STATE_CHECKEDABSENT);
+   mutex_unlock(>sem);
return -EIO;
}
JFFS2_NOTICE("but it has children so we fake some modes 
for it\n");
-- 
1.8.0.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] jffs2: avoid soft-lockup in jffs2_reserve_space_gc()

We triggered soft-lockup under stress test on 2.6.34 kernel.

BUG: soft lockup - CPU#1 stuck for 60009ms! [lockf2.test:14488]
...
[] (jffs2_do_reserve_space+0x420/0x440 [jffs2])
[] (jffs2_reserve_space_gc+0x34/0x78 [jffs2])
[] (jffs2_garbage_collect_dnode.isra.3+0x264/0x478 [jffs2])
[] (jffs2_garbage_collect_pass+0x9c0/0xe4c [jffs2])
[] (jffs2_reserve_space+0x104/0x2a8 [jffs2])
[] (jffs2_write_inode_range+0x5c/0x4d4 [jffs2])
[] (jffs2_write_end+0x198/0x2c0 [jffs2])
[] (generic_file_buffered_write+0x158/0x200)
[] (__generic_file_aio_write+0x3a4/0x414)
[] (generic_file_aio_write+0x5c/0xbc)
[] (do_sync_write+0x98/0xd4)
[] (vfs_write+0xa8/0x150)
[] (sys_write+0x3c/0xc0)]

Fix this by adding a cond_resched() in the while loop.

Cc: 
Signed-off-by: Li Zefan 
---
 fs/jffs2/nodemgmt.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/fs/jffs2/nodemgmt.c b/fs/jffs2/nodemgmt.c
index 0331072..fb30161 100644
--- a/fs/jffs2/nodemgmt.c
+++ b/fs/jffs2/nodemgmt.c
@@ -216,15 +216,20 @@ int jffs2_reserve_space_gc(struct jffs2_sb_info *c, 
uint32_t minsize,
 
jffs2_dbg(1, "%s(): Requested 0x%x bytes\n", __func__, minsize);
 
-   spin_lock(>erase_completion_lock);
-   while(ret == -EAGAIN) {
+   while (true) {
+   spin_lock(>erase_completion_lock);
ret = jffs2_do_reserve_space(c, minsize, len, sumsize);
if (ret) {
jffs2_dbg(1, "%s(): looping, ret is %d\n",
  __func__, ret);
}
+   spin_unlock(>erase_completion_lock);
+
+   if (ret == -EAGAIN)
+   cond_resched();
+   else
+   break;
}
-   spin_unlock(>erase_completion_lock);
if (!ret)
ret = jffs2_prealloc_raw_node_refs(c, c->nextblock, 1);
 
-- 
1.8.0.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] trivial: unexport static function create_syslog_header

2014-02-07 Thread Jiang Liu

Function create_syslog_header() is defined as static, so it should
not be exported.

Signed-off-by: Jiang Liu 
---
 drivers/base/core.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2b56717..b5d1b84 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2058,7 +2058,6 @@ create_syslog_header(const struct device *dev, char *hdr, 
size_t hdrlen)
 
return pos;
 }
-EXPORT_SYMBOL(create_syslog_header);
 
 int dev_vprintk_emit(int level, const struct device *dev,
 const char *fmt, va_list args)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 RESEND 6/8] staging/lustre/obdclass: remove extra break in class_process_config

2014-02-07 Thread Peng Tao

On Sat, Feb 8, 2014 at 1:43 AM, Greg Kroah-Hartman
 wrote:
> On Wed, Jan 22, 2014 at 09:36:17PM +0800, Peng Tao wrote:
>> From: Artem Blagodarenko 
>>
>> This is only part of the original Lustre commit, splitted to do the
>> cleanup work.
>>
>> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3155
>> Lustre-change: http://review.whamcloud.com/6025
>> Signed-off-by: Artem Blagodarenko 
>> Reviewed-by: Andreas Dilger 
>> Reviewed-by: Emoly Liu 
>> Signed-off-by: Peng Tao 
>> Signed-off-by: Andreas Dilger 
>> ---
>>  .../staging/lustre/lustre/obdclass/obd_config.c|4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/staging/lustre/lustre/obdclass/obd_config.c 
>> b/drivers/staging/lustre/lustre/obdclass/obd_config.c
>> index 27f56c0..fd08f1d 100644
>> --- a/drivers/staging/lustre/lustre/obdclass/obd_config.c
>> +++ b/drivers/staging/lustre/lustre/obdclass/obd_config.c
>> @@ -1226,24 +1226,20 @@ int class_process_config(struct lustre_cfg *lcfg)
>>   case LCFG_POOL_NEW: {
>>   err = obd_pool_new(obd, lustre_cfg_string(lcfg, 2));
>>   GOTO(out, err = 0);
>> - break;
>
> This confuses the static checkers.  Just fix up the GOTO logic (hint,
> remove it!) and then it will be "obvious" that the break can go away.
> But for now, please leave it, unless you want to have someone just put
> it back...
Got it.

Thanks,
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH resend 2/2] tools lib traceevent: Use realpath for srctree and objtree

2014-02-07 Thread Wang Nan

If BUILD_SRC or CURDIR contains tailing '/', the file names passed to gcc will
contain '//'. It will be contained .o's in debuginfo, then confuse debugedit:

https://bugzilla.redhat.com/show_bug.cgi?id=304121

This patch uses realpath command to makesure potential tailing '/'s are removed.

Signed-off-by: Wang Nan 
Acked-by: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Cc: Steven Rostedt 
Cc: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Geng Hui 

---
 tools/lib/traceevent/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/traceevent/Makefile b/tools/lib/traceevent/Makefile
index 005c9cc..5bb281c 100644
--- a/tools/lib/traceevent/Makefile
+++ b/tools/lib/traceevent/Makefile
@@ -107,8 +107,8 @@ endif # BUILD_SRC
 # We process the rest of the Makefile if this is the final invocation of make
 ifeq ($(skip-makefile),)
 
-srctree:= $(if $(BUILD_SRC),$(BUILD_SRC),$(CURDIR))
-objtree:= $(CURDIR)
+srctree:= $(realpath $(if $(BUILD_SRC),$(BUILD_SRC),$(CURDIR)))
+objtree:= $(realpath $(CURDIR))
 src:= $(srctree)
 obj:= $(objtree)
 
-- 
1.8.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH resend 1/2] liblockdep: Use realpath for srctree and objtree

2014-02-07 Thread Wang Nan

If BUILD_SRC or CURDIR contains tailing '/', the file names passed to gcc will
contain '//'. It will be contained .o's in debuginfo, then confuse debugedit:

https://bugzilla.redhat.com/show_bug.cgi?id=304121

This patch uses realpath command to makesure potential tailing '/'s are removed.

Signed-off-by: Wang Nan 
Acked-by: Sasha Levin  
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Geng Hui 

---
 tools/lib/lockdep/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/lockdep/Makefile b/tools/lib/lockdep/Makefile
index da8b7aa..e638dd5 100644
--- a/tools/lib/lockdep/Makefile
+++ b/tools/lib/lockdep/Makefile
@@ -87,8 +87,8 @@ endif # BUILD_SRC
 # We process the rest of the Makefile if this is the final invocation of make
 ifeq ($(skip-makefile),)
 
-srctree:= $(if $(BUILD_SRC),$(BUILD_SRC),$(CURDIR))
-objtree:= $(CURDIR)
+srctree:= $(realpath $(if $(BUILD_SRC),$(BUILD_SRC),$(CURDIR)))
+objtree:= $(realpath $(CURDIR))
 src:= $(srctree)
 obj:= $(objtree)
 
-- 
1.8.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9] mm: Remove ifdef condition in include/linux/mm.h

2014-02-07 Thread Josh Triplett

On Fri, Feb 07, 2014 at 05:02:02PM -0800, David Rientjes wrote:
> On Fri, 7 Feb 2014, Josh Triplett wrote:
> 
> > > Why??  If CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID then, yes, we need it to be 
> > > global.  Otherwise it's perfectly fine just being static in file scope.  
> > > This causes the compilation unit to break when you compile it, not wait 
> > > until vmlinux and find undefined references.
> > > 
> > > I see no reason it can't be done like this in mm/page_alloc.c:
> > > 
> > >   #ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
> > >   extern int __meminit __early_pfn_to_nid(unsigned long pfn);
> > 
> > No, a .c file should not have an extern declaration in it.  This should
> > live in an appropriate header file, to be included in both page_alloc.c
> > and any arch file that defines an overriding function.
> > 
> 
> Ok, so you have religious beliefs about extern being used in files ending 
> in .c and don't mind the 2900 occurrences of it in the kernel tree and 
> desire 14 line obfuscation in header files with comments to what is being 
> defined in .c files such as "please see mm/page_alloc.c" as mm.h has.  

I (and many others) have very specific technical objections to not
having the same prototype seen by both the definition and use of a
function: that helps keep the prototype in sync with the definition(s),
helps keep all definitions in sync if there are multiple such
definitions, and eliminates -Wmissing-prototype warnings (which in
addition to those benefits also help detect functions that should be
made static or eliminated).

And as mentioned before, those 14 lines can be significantly simplified;
Rashika's patch already does one such simplification.

Those 2900 occurrences should go away as well, and Rashika's previous
patches have already fixed many of them.

> > > Both of these options look much better than
> > > 
> > >   include/linux/mm.h:
> > > 
> > >   #if !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP) && \
> > >   !defined(CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID)
> > >   static inline int __early_pfn_to_nid(unsigned long pfn)
> > >   {
> > >   return 0;
> > >   }
> > >   #else
> > >   /* please see mm/page_alloc.c */
> > >   extern int __meminit early_pfn_to_nid(unsigned long pfn);
> > >   #ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
> > >   /* there is a per-arch backend function. */
> > >   extern int __meminit __early_pfn_to_nid(unsigned long pfn);
> > >   #endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
> > >   #endif
> > > 
> > > where all this confusion is originating from.
> > 
> > The proposal is to first simplify those ifdefs by eliminating the inner
> > one in the #else; I agree with Andrew that we ought to go ahead and take
> > that step given the patch at hand, and then figure out if there's an
> > additional simplification possible.
> > 
> 
> If additional simplification is possible?  Yeah, it's __weak which is 
> designed for this purpose.

No objections here if someone wants to write that patch.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9] mm: Remove ifdef condition in include/linux/mm.h

2014-02-07 Thread David Rientjes

On Fri, 7 Feb 2014, Josh Triplett wrote:

> > Why??  If CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID then, yes, we need it to be 
> > global.  Otherwise it's perfectly fine just being static in file scope.  
> > This causes the compilation unit to break when you compile it, not wait 
> > until vmlinux and find undefined references.
> > 
> > I see no reason it can't be done like this in mm/page_alloc.c:
> > 
> > #ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
> > extern int __meminit __early_pfn_to_nid(unsigned long pfn);
> 
> No, a .c file should not have an extern declaration in it.  This should
> live in an appropriate header file, to be included in both page_alloc.c
> and any arch file that defines an overriding function.
> 

Ok, so you have religious beliefs about extern being used in files ending 
in .c and don't mind the 2900 occurrences of it in the kernel tree and 
desire 14 line obfuscation in header files with comments to what is being 
defined in .c files such as "please see mm/page_alloc.c" as mm.h has.  
Good point.

> > Both of these options look much better than
> > 
> > include/linux/mm.h:
> > 
> > #if !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP) && \
> > !defined(CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID)
> > static inline int __early_pfn_to_nid(unsigned long pfn)
> > {
> > return 0;
> > }
> > #else
> > /* please see mm/page_alloc.c */
> > extern int __meminit early_pfn_to_nid(unsigned long pfn);
> > #ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
> > /* there is a per-arch backend function. */
> > extern int __meminit __early_pfn_to_nid(unsigned long pfn);
> > #endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
> > #endif
> > 
> > where all this confusion is originating from.
> 
> The proposal is to first simplify those ifdefs by eliminating the inner
> one in the #else; I agree with Andrew that we ought to go ahead and take
> that step given the patch at hand, and then figure out if there's an
> additional simplification possible.
> 

If additional simplification is possible?  Yeah, it's __weak which is 
designed for this purpose.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] block: rework flush sequencing for blk-mq

2014-02-07 Thread Shaohua Li

On Fri, Feb 07, 2014 at 06:19:15AM -0800, Christoph Hellwig wrote:
> On Fri, Feb 07, 2014 at 09:18:27AM +0800, Shaohua Li wrote:
> > Reusing the tag for flush request is considered before. The problem is 
> > driver
> > need get a request from a tag, reusing tag breaks this. The possible 
> > solution
> > is we provide a blk_mq_tag_to_request, and force driver uses it. And in this
> > function, if tag equals to flush_rq tag, we return flush_request.
> 
> If we want to support tag to request reverse mapping we defintively
> need to do this in the core, at which point special casing flush_rq
> there is easy.
> 
> Which driver needs the reverse mapping? Neither virtio_blk nor null_blk
> seem to and I've not seen any other conversions submitted except for the
> scsi work.

Yep, none driver needs it. But reverse mapping is the one of the points we use
tag, so better we prepare it.

Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC 2/6] mailbox: document bindings

Signed-off-by: Courtney Cavin 
---
 .../devicetree/bindings/mailbox/mailbox.txt| 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/mailbox.txt
new file mode 100644
index 000..846eb49
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/mailbox.txt
@@ -0,0 +1,44 @@
+Binding documentation for mailbox providers and consumers
+--
+
+Mailbox providers may be represented by any node in a device tree.  These
+nodes are designated as mailbox providers.  Consumers can then use a phandle
+to a mailbox provider, along with channel specifier information in order to
+get a mailbox.
+
+MAILBOX PROVIDERS
+
+#mbox-cells:
+   Usage: required
+   Type: u32
+   Desc: Number of cells in a mailbox specifier; Typically 1 for nodes
+ which only need a channel index.
+
+
+Example:
+   mailbox: mailbox {
+   #mbox-cells = <1>;
+   ...
+   };
+
+
+MAILBOX CONSUMERS
+
+mbox:
+   Usage: required
+   Type: < [phandle] [mailbox-specifier] >
+   Desc: List of phandle and mailbox specifier pairs, matching provider's
+ #mbox-cells property
+
+mbox-names:
+   Usage: optional
+   Type: string array
+   Desc: List of mailbox input name strings sorted in the same order as
+ the mbox property.  Consumer drivers should use mbox-names
+ to match mailbox input names with mailbox specifiers.
+
+Example:
+   consumer {
+   mbox-names = "comms";
+   mbox = < 0>;
+   };
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC 1/6] mailbox: add core framework

The mailbox drivers are fragmented, and some implement their own core.
Unify the drivers and implement common functionality in a framework.

Signed-off-by: Courtney Cavin 
---
 drivers/mailbox/Makefile |   1 +
 drivers/mailbox/core.c   | 573 +++
 include/linux/mbox.h | 175 +++
 3 files changed, 749 insertions(+)
 create mode 100644 drivers/mailbox/core.c
 create mode 100644 include/linux/mbox.h

diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index e0facb3..53712ed 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_MAILBOX)  += core.o
 obj-$(CONFIG_PL320_MBOX)   += pl320-ipc.o
 
 obj-$(CONFIG_OMAP_MBOX)+= omap-mailbox.o
diff --git a/drivers/mailbox/core.c b/drivers/mailbox/core.c
new file mode 100644
index 000..0dc865e
--- /dev/null
+++ b/drivers/mailbox/core.c
@@ -0,0 +1,573 @@
+/*
+ * Generic mailbox implementation
+ *
+ * Copyright (C) 2014 Sony Mobile Communications, AB.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_MUTEX(mbox_lock);
+static LIST_HEAD(mbox_adapters);
+
+static DEFINE_MUTEX(mbox_lookup_lock);
+static LIST_HEAD(mbox_lookup_list);
+
+static int __mbox_adapter_request(struct mbox_adapter *adap,
+   struct mbox_channel *chan)
+{
+   int rc;
+
+   if (chan->users > 0) {
+   chan->users++;
+   return 0;
+   }
+
+   if (!try_module_get(adap->ops->owner))
+   return -ENODEV;
+
+   if (adap->ops->request) {
+   rc = adap->ops->request(adap, chan);
+   if (rc) {
+   module_put(adap->ops->owner);
+   return rc;
+   }
+   }
+
+   chan->users++;
+
+   return 0;
+}
+
+static void __mbox_adapter_release(struct mbox_adapter *adap,
+   struct mbox_channel *chan)
+{
+   if (!adap || !chan)
+   return;
+
+   if (chan->users == 0) {
+   dev_err(adap->dev, "device already released\n");
+   return;
+   }
+
+   chan->users--;
+   if (chan->users > 0)
+   return;
+
+   if (adap->ops->release)
+   adap->ops->release(adap, chan);
+   module_put(adap->ops->owner);
+}
+
+static struct mbox_channel *
+mbox_adapter_request_channel(struct mbox_adapter *adap, unsigned int index)
+{
+   struct mbox_channel *chan;
+   int rc;
+
+   if (!adap || index >= adap->nchannels)
+   return ERR_PTR(-EINVAL);
+
+   mutex_lock(>lock);
+   chan = >channels[index];
+
+   rc = __mbox_adapter_request(adap, chan);
+   if (rc)
+   chan = ERR_PTR(rc);
+   mutex_unlock(>lock);
+
+   return chan;
+}
+
+static void mbox_adapter_release_channel(struct mbox_adapter *adap,
+   struct mbox_channel *chan)
+{
+   if (!adap || !chan)
+   return;
+
+   mutex_lock(>lock);
+   __mbox_adapter_release(adap, chan);
+   mutex_unlock(>lock);
+}
+
+static int of_mbox_simple_xlate(struct mbox_adapter *adap,
+   const struct of_phandle_args *args)
+{
+   if (adap->of_n_cells < 1)
+   return -EINVAL;
+   if (args->args[0] >= adap->nchannels)
+   return -EINVAL;
+
+   return args->args[0];
+}
+
+static struct mbox_adapter *of_node_to_mbox_adapter(struct device_node *np)
+{
+   struct mbox_adapter *adap;
+
+   mutex_lock(_lock);
+   list_for_each_entry(adap, _adapters, list) {
+   if (adap->dev && adap->dev->of_node == np) {
+   mutex_unlock(_lock);
+   return adap;
+   }
+   }
+   mutex_unlock(_lock);
+
+   return ERR_PTR(-EPROBE_DEFER);
+}
+
+static void of_mbox_adapter_add(struct mbox_adapter *adap)
+{
+   if (!adap->dev)
+   return;
+
+   if (!adap->of_xlate) {
+   adap->of_xlate = of_mbox_simple_xlate;
+   adap->of_n_cells = 1;
+   }
+
+   of_node_get(adap->dev->of_node);
+}
+
+static void of_mbox_adapter_remove(struct mbox_adapter *adap)
+{
+   if (!adap->dev)
+   return;
+   of_node_put(adap->dev->of_node);
+}
+
+static struct mbox_channel *
+of_mbox_adapter_request_channel(struct device_node *np, const char *con_id)
+{
+   struct of_phandle_args args;
+   struct mbox_adapter *adap;
+   struct mbox_channel *chan;
+   int index = 0;
+   int rc;
+
+

[RFC 6/6] mailbox: omap2+: move to common mbox framework

Signed-off-by: Courtney Cavin 
---
 drivers/mailbox/Kconfig |   1 -
 drivers/mailbox/mailbox-omap2.c | 315 +---
 2 files changed, 132 insertions(+), 184 deletions(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ae6b09b..a592a5a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -27,7 +27,6 @@ config OMAP1_MBOX
 config OMAP2PLUS_MBOX
tristate "OMAP2+ Mailbox framework support"
depends on ARCH_OMAP2PLUS
-   depends on BROKEN
help
  Mailbox implementation for OMAP family chips with hardware for
  interprocessor communication involving DSP, IVA1.0 and IVA2 in
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 42d2b89..7ddde19 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -18,8 +18,8 @@
 #include 
 #include 
 #include 
-
-#include "omap-mbox.h"
+#include 
+#include 
 
 #define MAILBOX_REVISION   0x000
 #define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
@@ -42,192 +42,165 @@
 #define MBOX_NR_REGS   (MBOX_REG_SIZE / sizeof(u32))
 #define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32))
 
-static void __iomem *mbox_base;
-
 struct omap_mbox2_fifo {
unsigned long msg;
unsigned long fifo_stat;
unsigned long msg_stat;
 };
 
+struct omap2_mbox;
+
 struct omap_mbox2_priv {
+   struct omap2_mbox *mbox;
+   int irq;
+
struct omap_mbox2_fifo tx_fifo;
struct omap_mbox2_fifo rx_fifo;
unsigned long irqenable;
unsigned long irqstatus;
u32 newmsg_bit;
u32 notfull_bit;
-   u32 ctx[OMAP4_MBOX_NR_REGS];
unsigned long irqdisable;
u32 intr_type;
 };
 
-static inline unsigned int mbox_read_reg(size_t ofs)
-{
-   return __raw_readl(mbox_base + ofs);
-}
+struct omap2_mbox {
+   struct mbox_adapter adapter;
+   struct completion completion;
+   void __iomem *base;
+   atomic_t active;
+   struct omap_mbox2_priv *priv;
+};
 
-static inline void mbox_write_reg(u32 val, size_t ofs)
+static inline unsigned int mbox_read_reg(void __iomem *base, size_t ofs)
 {
-   __raw_writel(val, mbox_base + ofs);
+   return __raw_readl(base + ofs);
 }
 
-/* Mailbox H/W preparations */
-static int omap2_mbox_startup(struct omap_mbox *mbox)
+static inline void mbox_write_reg(void __iomem *base, u32 val, size_t ofs)
 {
-   u32 l;
-
-   pm_runtime_enable(mbox->dev->parent);
-   pm_runtime_get_sync(mbox->dev->parent);
-
-   l = mbox_read_reg(MAILBOX_REVISION);
-   pr_debug("omap mailbox rev %d.%d\n", (l & 0xf0) >> 4, (l & 0x0f));
-
-   return 0;
+   __raw_writel(val, base + ofs);
 }
 
-static void omap2_mbox_shutdown(struct omap_mbox *mbox)
+static int omap2_mbox_request(struct mbox_adapter *adap,
+   struct mbox_channel *chan)
 {
-   pm_runtime_put_sync(mbox->dev->parent);
-   pm_runtime_disable(mbox->dev->parent);
-}
+   struct omap_mbox2_priv *p;
+   struct omap2_mbox *mbox;
+   u32 enable;
 
-/* Mailbox FIFO handle functions */
-static mbox_msg_t omap2_mbox_fifo_read(struct omap_mbox *mbox)
-{
-   struct omap_mbox2_fifo *fifo =
-   &((struct omap_mbox2_priv *)mbox->priv)->rx_fifo;
-   return (mbox_msg_t) mbox_read_reg(fifo->msg);
-}
+   mbox = container_of(adap, struct omap2_mbox, adapter);
+   p = >priv[chan->id];
 
-static void omap2_mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
-{
-   struct omap_mbox2_fifo *fifo =
-   &((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
-   mbox_write_reg(msg, fifo->msg);
-}
+   if (atomic_inc_return(>active) == 1) {
+   pm_runtime_enable(adap->dev);
+   pm_runtime_get_sync(adap->dev);
+   }
 
-static int omap2_mbox_fifo_empty(struct omap_mbox *mbox)
-{
-   struct omap_mbox2_fifo *fifo =
-   &((struct omap_mbox2_priv *)mbox->priv)->rx_fifo;
-   return (mbox_read_reg(fifo->msg_stat) == 0);
-}
+   enable = mbox_read_reg(mbox->base, p->irqenable);
+   enable |= p->notfull_bit | p->newmsg_bit;
+   mbox_write_reg(mbox->base, enable, p->irqenable);
 
-static int omap2_mbox_fifo_full(struct omap_mbox *mbox)
-{
-   struct omap_mbox2_fifo *fifo =
-   &((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
-   return mbox_read_reg(fifo->fifo_stat);
+   return 0;
 }
 
-/* Mailbox IRQ handle functions */
-static void omap2_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static int omap2_mbox_release(struct mbox_adapter *adap,
+   struct mbox_channel *chan)
 {
-   struct omap_mbox2_priv *p = mbox->priv;
-   u32 l, bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
+   struct omap_mbox2_priv *p;
+   struct omap2_mbox *mbox;
+   u32 disable;
 
-   l = mbox_read_reg(p->irqenable);
-   l |= bit;
-

[RFC 4/6] mailbox: omap: remove omap-specific framework

This framework is no longer needed, and the users should move over to
the new common framework.  Mark the existing implementations as broken,
and deprecate the api, as a stop-gap.

Signed-off-by: Courtney Cavin 
---
 drivers/mailbox/Kconfig|  19 +-
 drivers/mailbox/Makefile   |   1 -
 drivers/mailbox/omap-mailbox.c | 469 -
 drivers/mailbox/omap-mbox.h|  67 --
 include/linux/omap-mailbox.h   |  45 +++-
 5 files changed, 40 insertions(+), 561 deletions(-)
 delete mode 100644 drivers/mailbox/omap-mailbox.c
 delete mode 100644 drivers/mailbox/omap-mbox.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index c8b5c13..6befc6e 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,17 +16,10 @@ config PL320_MBOX
  Management Engine, primarily for cpufreq. Say Y here if you want
  to use the PL320 IPCM support.
 
-config OMAP_MBOX
-   tristate
-   help
- This option is selected by any OMAP architecture specific mailbox
- driver such as CONFIG_OMAP1_MBOX or CONFIG_OMAP2PLUS_MBOX. This
- enables the common OMAP mailbox framework code.
-
 config OMAP1_MBOX
tristate "OMAP1 Mailbox framework support"
depends on ARCH_OMAP1
-   select OMAP_MBOX
+   depends on BROKEN
help
  Mailbox implementation for OMAP chips with hardware for
  interprocessor communication involving DSP in OMAP1. Say Y here
@@ -35,19 +28,11 @@ config OMAP1_MBOX
 config OMAP2PLUS_MBOX
tristate "OMAP2+ Mailbox framework support"
depends on ARCH_OMAP2PLUS
-   select OMAP_MBOX
+   depends on BROKEN
help
  Mailbox implementation for OMAP family chips with hardware for
  interprocessor communication involving DSP, IVA1.0 and IVA2 in
  OMAP2/3; or IPU, IVA HD and DSP in OMAP4/5. Say Y here if you
  want to use OMAP2+ Mailbox framework support.
 
-config OMAP_MBOX_KFIFO_SIZE
-   int "Mailbox kfifo default buffer size (bytes)"
-   depends on OMAP2PLUS_MBOX || OMAP1_MBOX
-   default 256
-   help
- Specify the default size of mailbox's kfifo buffers (bytes).
- This can also be changed at runtime (via the mbox_kfifo_size
- module parameter).
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 53712ed..c8e51a0 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -1,7 +1,6 @@
 obj-$(CONFIG_MAILBOX)  += core.o
 obj-$(CONFIG_PL320_MBOX)   += pl320-ipc.o
 
-obj-$(CONFIG_OMAP_MBOX)+= omap-mailbox.o
 obj-$(CONFIG_OMAP1_MBOX)   += mailbox_omap1.o
 mailbox_omap1-objs := mailbox-omap1.o
 obj-$(CONFIG_OMAP2PLUS_MBOX)   += mailbox_omap2.o
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
deleted file mode 100644
index d79a646..000
--- a/drivers/mailbox/omap-mailbox.c
+++ /dev/null
@@ -1,469 +0,0 @@
-/*
- * OMAP mailbox driver
- *
- * Copyright (C) 2006-2009 Nokia Corporation. All rights reserved.
- *
- * Contact: Hiroshi DOYU 
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "omap-mbox.h"
-
-static struct omap_mbox **mboxes;
-
-static int mbox_configured;
-static DEFINE_MUTEX(mbox_configured_lock);
-
-static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
-module_param(mbox_kfifo_size, uint, S_IRUGO);
-MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
-
-/* Mailbox FIFO handle functions */
-static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
-{
-   return mbox->ops->fifo_read(mbox);
-}
-static inline void mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
-{
-   mbox->ops->fifo_write(mbox, msg);
-}
-static inline int mbox_fifo_empty(struct omap_mbox *mbox)
-{
-   return mbox->ops->fifo_empty(mbox);
-}
-static inline int mbox_fifo_full(struct omap_mbox *mbox)
-{
-   return mbox->ops->fifo_full(mbox);
-}
-
-/* Mailbox IRQ handle functions */
-static inline void ack_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
-   if (mbox->ops->ack_irq)
-   mbox->ops->ack_irq(mbox, irq);
-}
-static inline int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)

[RFC 3/6] mailbox: pl320: migrate to mbox framework

We don't remove the legacy methods here, but we mark them as deprecated
in the hopes that people with the ability to properly test modifications
can adapt its users.

Signed-off-by: Courtney Cavin 
---
 drivers/mailbox/pl320-ipc.c | 258 ++--
 include/linux/mailbox.h |  29 -
 2 files changed, 225 insertions(+), 62 deletions(-)

diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
index d873cba..b8da247 100644
--- a/drivers/mailbox/pl320-ipc.c
+++ b/drivers/mailbox/pl320-ipc.c
@@ -15,7 +15,6 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -27,6 +26,7 @@
 #include 
 
 #include 
+#include 
 
 #define IPCMxSOURCE(m) ((m) * 0x40)
 #define IPCMxDSET(m)   (((m) * 0x40) + 0x004)
@@ -50,131 +50,162 @@
 #define A9_SOURCE  1
 #define M3_SOURCE  0
 
-static void __iomem *ipc_base;
-static int ipc_irq;
-static DEFINE_MUTEX(ipc_m1_lock);
-static DECLARE_COMPLETION(ipc_completion);
-static ATOMIC_NOTIFIER_HEAD(ipc_notifier);
+struct pl320 {
+   struct mbox_adapter adapter;
+   void __iomem *base;
+   int irq;
+   struct completion completion;
+};
 
-static inline void set_destination(int source, int mbox)
+static inline void set_destination(struct pl320 *pl, int source, int mbox)
 {
-   __raw_writel(CHAN_MASK(source), ipc_base + IPCMxDSET(mbox));
-   __raw_writel(CHAN_MASK(source), ipc_base + IPCMxMSET(mbox));
+   __raw_writel(CHAN_MASK(source), pl->base + IPCMxDSET(mbox));
+   __raw_writel(CHAN_MASK(source), pl->base + IPCMxMSET(mbox));
 }
 
-static inline void clear_destination(int source, int mbox)
+static inline void clear_destination(struct pl320 *pl, int source, int mbox)
 {
-   __raw_writel(CHAN_MASK(source), ipc_base + IPCMxDCLEAR(mbox));
-   __raw_writel(CHAN_MASK(source), ipc_base + IPCMxMCLEAR(mbox));
+   __raw_writel(CHAN_MASK(source), pl->base + IPCMxDCLEAR(mbox));
+   __raw_writel(CHAN_MASK(source), pl->base + IPCMxMCLEAR(mbox));
 }
 
-static void __ipc_send(int mbox, u32 *data)
+static void __ipc_send(struct pl320 *pl, int mbox, const u32 *data)
 {
int i;
for (i = 0; i < 7; i++)
-   __raw_writel(data[i], ipc_base + IPCMxDR(mbox, i));
-   __raw_writel(0x1, ipc_base + IPCMxSEND(mbox));
+   __raw_writel(data[i], pl->base + IPCMxDR(mbox, i));
+   __raw_writel(0x1, pl->base + IPCMxSEND(mbox));
 }
 
-static u32 __ipc_rcv(int mbox, u32 *data)
+static u32 __ipc_rcv(struct pl320 *pl, int mbox, u32 *data)
 {
int i;
for (i = 0; i < 7; i++)
-   data[i] = __raw_readl(ipc_base + IPCMxDR(mbox, i));
+   data[i] = __raw_readl(pl->base + IPCMxDR(mbox, i));
return data[1];
 }
 
 /* blocking implmentation from the A9 side, not usuable in interrupts! */
-int pl320_ipc_transmit(u32 *data)
+static int pl320_ipc_put_message(struct mbox_adapter *adap,
+   struct mbox_channel *chan, const void *data, unsigned int len)
 {
+   struct pl320 *pl;
+   u32 repl[7];
int ret;
 
-   mutex_lock(_m1_lock);
+   if (len != 28 || chan->id != 0)
+   return -EINVAL;
 
-   init_completion(_completion);
-   __ipc_send(IPC_TX_MBOX, data);
-   ret = wait_for_completion_timeout(_completion,
+   pl = container_of(adap, struct pl320, adapter);
+   reinit_completion(>completion);
+   __ipc_send(pl, IPC_TX_MBOX, data);
+   ret = wait_for_completion_timeout(>completion,
  msecs_to_jiffies(1000));
-   if (ret == 0) {
-   ret = -ETIMEDOUT;
-   goto out;
-   }
+   if (ret == 0)
+   return -ETIMEDOUT;
+
+   ret = __ipc_rcv(pl, IPC_TX_MBOX, repl);
 
-   ret = __ipc_rcv(IPC_TX_MBOX, data);
-out:
-   mutex_unlock(_m1_lock);
return ret;
 }
-EXPORT_SYMBOL_GPL(pl320_ipc_transmit);
 
 static irqreturn_t ipc_handler(int irq, void *dev)
 {
+   struct pl320 *pl = dev;
u32 irq_stat;
u32 data[7];
 
-   irq_stat = __raw_readl(ipc_base + IPCMMIS(1));
+   irq_stat = __raw_readl(pl->base + IPCMMIS(1));
if (irq_stat & MBOX_MASK(IPC_TX_MBOX)) {
-   __raw_writel(0, ipc_base + IPCMxSEND(IPC_TX_MBOX));
-   complete(_completion);
+   __raw_writel(0, pl->base + IPCMxSEND(IPC_TX_MBOX));
+   complete(>completion);
}
if (irq_stat & MBOX_MASK(IPC_RX_MBOX)) {
-   __ipc_rcv(IPC_RX_MBOX, data);
-   atomic_notifier_call_chain(_notifier, data[0], data + 1);
-   __raw_writel(2, ipc_base + IPCMxSEND(IPC_RX_MBOX));
+   __ipc_rcv(pl, IPC_RX_MBOX, data);
+   mbox_channel_notify(>adapter.channels[0], data, 28);
+   __raw_writel(2, pl->base + IPCMxSEND(IPC_RX_MBOX));
}
 
return IRQ_HANDLED;
 }
 
-int pl320_ipc_register_notifier(struct notifier_block *nb)
-{
-

[RFC 5/6] mailbox: omap1: move to common mbox framework

Signed-off-by: Courtney Cavin 
---
 drivers/mailbox/Kconfig |   1 -
 drivers/mailbox/mailbox-omap1.c | 153 +++-
 2 files changed, 73 insertions(+), 81 deletions(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 6befc6e..ae6b09b 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -19,7 +19,6 @@ config PL320_MBOX
 config OMAP1_MBOX
tristate "OMAP1 Mailbox framework support"
depends on ARCH_OMAP1
-   depends on BROKEN
help
  Mailbox implementation for OMAP chips with hardware for
  interprocessor communication involving DSP in OMAP1. Say Y here
diff --git a/drivers/mailbox/mailbox-omap1.c b/drivers/mailbox/mailbox-omap1.c
index 9001b76..474890d 100644
--- a/drivers/mailbox/mailbox-omap1.c
+++ b/drivers/mailbox/mailbox-omap1.c
@@ -12,10 +12,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
-#include "omap-mbox.h"
-
 #define MAILBOX_ARM2DSP1   0x00
 #define MAILBOX_ARM2DSP1b  0x04
 #define MAILBOX_DSP2ARM1   0x08
@@ -26,8 +26,6 @@
 #define MAILBOX_DSP2ARM1_Flag  0x1c
 #define MAILBOX_DSP2ARM2_Flag  0x20
 
-static void __iomem *mbox_base;
-
 struct omap_mbox1_fifo {
unsigned long cmd;
unsigned long data;
@@ -39,90 +37,70 @@ struct omap_mbox1_priv {
struct omap_mbox1_fifo rx_fifo;
 };
 
-static inline int mbox_read_reg(size_t ofs)
+struct omap1_mbox {
+   struct mbox_adapter adapter;
+   struct omap_mbox1_priv priv;
+   void __iomem *base;
+   int irq;
+};
+
+static inline int mbox_read_reg(void __iomem *base, size_t ofs)
 {
-   return __raw_readw(mbox_base + ofs);
+   return __raw_readw(base + ofs);
 }
 
-static inline void mbox_write_reg(u32 val, size_t ofs)
+static inline void mbox_write_reg(void __iomem *base, u32 val, size_t ofs)
 {
-   __raw_writew(val, mbox_base + ofs);
+   __raw_writew(val, base + ofs);
 }
 
-/* msg */
-static mbox_msg_t omap1_mbox_fifo_read(struct omap_mbox *mbox)
+static int omap1_mbox_put_message(struct mbox_adapter *adap,
+   struct mbox_channel *chan, const void *data, unsigned int len)
+
 {
-   struct omap_mbox1_fifo *fifo =
-   &((struct omap_mbox1_priv *)mbox->priv)->rx_fifo;
-   mbox_msg_t msg;
+   struct omap_mbox1_fifo *fifo;
+   struct omap1_mbox *mbox;
+   u32 msg;
+   int i;
 
-   msg = mbox_read_reg(fifo->data);
-   msg |= ((mbox_msg_t) mbox_read_reg(fifo->cmd)) << 16;
+   if (len != sizeof(msg))
+   return -EINVAL;
 
-   return msg;
-}
+   msg = ((u32 *)data)[0];
+   mbox = container_of(adap, struct omap1_mbox, adapter);
+   fifo = >priv.tx_fifo;
 
-static void
-omap1_mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
-{
-   struct omap_mbox1_fifo *fifo =
-   &((struct omap_mbox1_priv *)mbox->priv)->tx_fifo;
+   /* wait for available space */
+   for (i = 0; i < 100 && mbox_read_reg(mbox->base, fifo->flag); ++i)
+   usleep_range(10, 20);
+   if (i == 100)
+   return -ETIMEDOUT;
 
-   mbox_write_reg(msg & 0x, fifo->data);
-   mbox_write_reg(msg >> 16, fifo->cmd);
-}
+   mbox_write_reg(mbox->base, msg & 0x, fifo->data);
+   mbox_write_reg(mbox->base, msg >> 16, fifo->cmd);
 
-static int omap1_mbox_fifo_empty(struct omap_mbox *mbox)
-{
return 0;
 }
 
-static int omap1_mbox_fifo_full(struct omap_mbox *mbox)
+static irqreturn_t omap1_mbox_irq(int irq, void *dev)
 {
-   struct omap_mbox1_fifo *fifo =
-   &((struct omap_mbox1_priv *)mbox->priv)->rx_fifo;
+   struct omap1_mbox *mbox = dev;
+   struct omap_mbox1_fifo *fifo;
+   u32 msg;
 
-   return mbox_read_reg(fifo->flag);
-}
+   fifo = >priv.rx_fifo;
+   msg = mbox_read_reg(mbox->base, fifo->data);
+   msg |= ((u32)mbox_read_reg(mbox->base, fifo->cmd)) << 16;
 
-/* irq */
-static void
-omap1_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
-   if (irq == IRQ_RX)
-   enable_irq(mbox->irq);
-}
+   mbox_channel_notify(>adapter.channels[0], , sizeof(msg));
 
-static void
-omap1_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
-   if (irq == IRQ_RX)
-   disable_irq(mbox->irq);
+   return IRQ_HANDLED;
 }
 
-static int
-omap1_mbox_is_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
-   if (irq == IRQ_TX)
-   return 0;
-   return 1;
-}
-
-static struct omap_mbox_ops omap1_mbox_ops = {
-   .type   = OMAP_MBOX_TYPE1,
-   .fifo_read  = omap1_mbox_fifo_read,
-   .fifo_write = omap1_mbox_fifo_write,
-   .fifo_empty = omap1_mbox_fifo_empty,
-   .fifo_full  = omap1_mbox_fifo_full,
-   .enable_irq = omap1_mbox_enable_irq,
-   .disable_irq= omap1_mbox_disable_irq,
-   .is_irq = omap1_mbox_is_irq,
-};
-
 /*

[RFC 0/6] mailbox: add common framework and port drivers

There is currently no common framework for mailbox drivers, so this is my
attempt to come up with something suitable.  There seems to be a need for
making this generic, so I have attempted to do just that.  Most of this is
modeled pretty strongly after the pwm core, with some influences from the clock
core.

Looking at the existing use-cases, and some new ones, it would appear that the
requirements here are rather simple. We need essentially two things for
consumers:
- put_message
- callback for receiving messages

The code currently uses atomic notifiers for callbacks.  The common omap core
deals with fifos and work-queues in order to escape atomic contexts, but from
what I can see, this is unneeded.  I am also of the opinion that the contexts
can be much better managed in the drivers which are working with these
contexts, rather than generically.

Hopefully this will be suitable for the plethora of other drivers around the
kernel which implement mailboxes, as well.  In any case, I'm rather interested
to see what the rest of the world thinks.

Keep in mind that while the pl320 & omap code should compile, I don't currently
have a platform on which I can perform proper testing.  I also removed the
context save/restore code from omap2 mailbox support, because I think it should
be able to be done via driver suspend/resume, but haven't done a full
investigation just yet.

I'm also aware that breaking omap, just to fix it again probably isn't the best
course of action, and I'm open to suggestions.

-Courtney

Courtney Cavin (6):
  mailbox: add core framework
  mailbox: document bindings
  mailbox: pl320: migrate to mbox framework
  mailbox: omap: remove omap-specific framework
  mailbox: omap1: move to common mbox framework
  mailbox: omap2+: move to common mbox framework

 .../devicetree/bindings/mailbox/mailbox.txt|  44 ++
 drivers/mailbox/Kconfig|  17 -
 drivers/mailbox/Makefile   |   2 +-
 drivers/mailbox/core.c | 573 +
 drivers/mailbox/mailbox-omap1.c| 153 +++---
 drivers/mailbox/mailbox-omap2.c| 315 +--
 drivers/mailbox/omap-mailbox.c | 469 -
 drivers/mailbox/omap-mbox.h|  67 ---
 drivers/mailbox/pl320-ipc.c| 258 +++---
 include/linux/mailbox.h|  29 +-
 include/linux/mbox.h   | 175 +++
 include/linux/omap-mailbox.h   |  45 +-
 12 files changed, 1261 insertions(+), 886 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mailbox/mailbox.txt
 create mode 100644 drivers/mailbox/core.c
 delete mode 100644 drivers/mailbox/omap-mailbox.c
 delete mode 100644 drivers/mailbox/omap-mbox.h
 create mode 100644 include/linux/mbox.h

-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2 1/1] Drivers: hv: vmbus: Extract the mmio information from DSDT

2014-02-07 Thread KY Srinivasan



> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, February 07, 2014 3:21 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; 
> o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com
> Subject: Re: [PATCH V2 1/1] Drivers: hv: vmbus: Extract the mmio information
> from DSDT
> 
> On Wed, Jan 29, 2014 at 06:14:39PM -0800, K. Y. Srinivasan wrote:
> > On Gen2 firmware, Hyper-V does not emulate the PCI bus. However, the
> MMIO
> > information is packaged up in DSDT. Extract this information and export it
> > for use by the synthetic framebuffer driver. This is the only driver that
> > needs this currently.
> 
> I don't see a follow-on patch that uses these variables, where is that?

The synthetic framebuffer driver will use this. It will be submitted shortly.

K. Y 
> 
> thanks,
> 
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: use __GFP_NORETRY for high order allocations

2014-02-07 Thread Eric W. Biederman

David Miller  writes:

> From: Eric Dumazet 
> Date: Thu, 06 Feb 2014 10:42:42 -0800
>
>> From: Eric Dumazet 
>> 
>> sock_alloc_send_pskb() & sk_page_frag_refill()
>> have a loop trying high order allocations to prepare
>> skb with low number of fragments as this increases performance.
>> 
>> Problem is that under memory pressure/fragmentation, this can
>> trigger OOM while the intent was only to try the high order
>> allocations, then fallback to order-0 allocations.
>> 
>> We had various reports from unexpected regressions.
>> 
>> According to David, setting __GFP_NORETRY should be fine,
>> as the asynchronous compaction is still enabled, and this
>> will prevent OOM from kicking as in :
>  ...
>> Signed-off-by: Eric Dumazet 
>> Acked-by: David Rientjes 
>
> Applied, do we want this for -stable?

The first hunk goes back to 3.12 and the second hunk goes back to 3.8.

I think so.The change is safe and this class of problem can cause an
external attack to trigger an OOM on your box, by controlling the packet
flow.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pci: Add support for creating a generic host_bridge from device tree

2014-02-07 Thread Tanmay Inamdar

On Thu, Feb 6, 2014 at 2:18 AM, Liviu Dudau  wrote:
> On Wed, Feb 05, 2014 at 10:26:27PM +, Tanmay Inamdar wrote:
>> Hello Liviu,
>>
>> I did not get the first email of this particular patch on any of
>> subscribed mailing lists (don't know why), hence replying here.
>
> Strange, it shows in the MARC and GMANE archive for linux-pci, probably
> a hickup on your receiving side?
>
>>
>> +struct pci_host_bridge *
>> +pci_host_bridge_of_init(struct device *parent, int busno, struct pci_ops 
>> *ops,
>> + void *host_data, struct list_head *resources)
>> +{
>> + struct pci_bus *root_bus;
>> + struct pci_host_bridge *bridge;
>> +
>> + /* first parse the host bridge bus ranges */
>> + if (pci_host_bridge_of_get_ranges(parent->of_node, resources))
>> + return NULL;
>> +
>> + /* then create the root bus */
>> + root_bus = pci_create_root_bus(parent, busno, ops, host_data, resources);
>> + if (!root_bus)
>> + return NULL;
>> +
>> + bridge = to_pci_host_bridge(root_bus->bridge);
>> +
>> + return bridge;
>> +}
>>
>> You are keeping the domain_nr inside pci_host_bridge structure. In
>> above API, domain_nr is required in 'pci_find_bus' function called
>> from 'pci_create_root_bus'. Since the bridge is allocated after
>> creating root bus, 'pci_find_bus' always gets domain_nr as 0. This
>> will cause problem for scanning multiple domains.
>
> Good catch. I was switching between creating a pci_controller in arch/arm64 
> and
> adding the needed bits in pci_host_bridge. After internal review I've decided 
> to
> add the domain_nr to pci_host_bridge, but forgot to update the code 
> everywhere.
>
> Thanks for reviewing this, will fix in v2.
>
> Do you find porting to the new API straight forward?

It is quite straight forward for MEM regions but for IO regions it is
not. You always assume IO resource starting at 0x0. IMO, this will
cause problem for systems with multiple ports / IO windows. You can
take a look at 'drivers/pci/host/pcie-designware.c'.

Also the manipulations of addresses for IO_RESOURCES can be dangerous.
It can make some value negative. For example if my PCI IO range starts
in 32 bit address range say 0x8000_ with CPU address
0xb0_8000_, window->offset after manipulation will become
negative.

Personally I would like to do get all the PCI and CPU addresses from
my device tree as is and do the 'pci_add_resource_offset'. This will
help me setup my regions correctly without any further arithmetic.
Please let me know what you think.

>
> Best regards,
> Liviu
>
>>
>>
>> On Mon, Feb 3, 2014 at 10:46 AM, Arnd Bergmann  wrote:
>> > On Monday 03 February 2014 18:33:48 Liviu Dudau wrote:
>> >> +/**
>> >> + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from 
>> >> DT
>> >> + * @dev: device node of the host bridge having the range property
>> >> + * @resources: list where the range of resources will be added after DT 
>> >> parsing
>> >> + *
>> >> + * This function will parse the "ranges" property of a PCI host bridge 
>> >> device
>> >> + * node and setup the resource mapping based on its content. It is 
>> >> expected
>> >> + * that the property conforms with the Power ePAPR document.
>> >> + *
>> >> + * Each architecture will then apply their filtering based on the 
>> >> limitations
>> >> + * of each platform. One general restriction seems to be the number of 
>> >> IO space
>> >> + * ranges, the PCI framework makes intensive use of struct resource 
>> >> management,
>> >> + * and for IORESOURCE_IO types they can only be requested if they are 
>> >> contained
>> >> + * within the global ioport_resource, so that should be limited to one 
>> >> IO space
>> >> + * range.
>> >
>> > Actually we have quite a different set of restrictions around I/O space on 
>> > ARM32
>> > at the moment: Each host bridge can have its own 64KB range in an arbitrary
>> > location on MMIO space, and the total must not exceed 2MB of I/O space.
>> >
>> >> + */
>> >> +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
>> >> + struct list_head *resources)
>> >> +{
>> >> + struct resource *res;
>> >> + struct of_pci_range range;
>> >> + struct of_pci_range_parser parser;
>> >> + int err;
>> >> +
>> >> + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
>> >> +
>> >> + /* Check for ranges property */
>> >> + err = of_pci_range_parser_init(, dev);
>> >> + if (err)
>> >> + return err;
>> >> +
>> >> + pr_debug("Parsing ranges property...\n");
>> >> + for_each_of_pci_range(, ) {
>> >> + /* Read next ranges element */
>> >> + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
>> >> + range.pci_space, range.pci_addr);
>> >> + pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
>> >> + range.cpu_addr, range.size);
>> >> +
>> >> + /* If we failed translation or got a zero-sized region
>> >> +  *

Re: [PATCHSET v2 driver-core-next] kernfs: prepare for cgroup's kernfs conversion

On Fri, Feb 07, 2014 at 01:43:20PM -0500, Tejun Heo wrote:
> Hello,
> 
> On Mon, Feb 03, 2014 at 02:09:07PM -0500, Tejun Heo wrote:
> >  0001-kernfs-invoke-dir_ops-while-holding-active-ref-of-th.patch
> >  0002-kernfs-rename-kernfs_dir_ops-to-kernfs_syscall_ops.patch
> >  0003-kernfs-implement-kernfs_syscall_ops-remount_fs-and-s.patch
> >  0004-kernfs-add-missing-kernfs_active-checks-in-directory.patch
> >  0005-kernfs-allow-nodes-to-be-created-in-the-deactivated-.patch
> >  0006-kernfs-implement-kernfs_ops-atomic_write_len.patch
> >  0007-kernfs-add-kernfs_open_file-priv.patch
> >  0008-kernfs-implement-kernfs_node_from_dentry-kernfs_root.patch
> >  0009-kernfs-implement-kernfs_get_parent-kernfs_name-path-.patch
> >  0010-kernfs-add-CONFIG_KERNFS.patch
> 
> 0009 updated to v2 and a new patch added between 0009 and 0010.  Both
> are for dummy definition related issues for !CONFIG_SYSFS.  The git
> tree has been updated accordingly.

Ok, I should have now applied all of these, and hopefully in the correct
order.  If I got anything wrong, please let me know.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.13.2

On Fri, Feb 07, 2014 at 03:29:54PM -0800, Nicholas A. Bellinger wrote:
> On Thu, 2014-02-06 at 12:01 -0800, Greg KH wrote:
> > I'm announcing the release of the 3.13.2 kernel.
> > 
> > All users of the 3.13 kernel series must upgrade.
> > 
> > The updated 3.13.y git tree can be found at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
> > linux-3.13.y
> > and can be browsed at the normal kernel.org git web browser:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Hi Greg,
> 
> I noticed that the following two target upstream patches in v3.14-rc1
> did not make it into v3.13.y or stable-queue.git:
> 
> commit 6f6b5d1ec56acdeab0503d2b823f6f88a0af493e
> Author: Kent Overstreet 
> Date:   Sun Jan 19 08:26:37 2014 +
> 
> percpu_ida: Make percpu_ida_alloc + callers accept task state bitmask
> 
> commit 555b270e25b0279b98083518a85f4b1da144a181
> Author: Nicholas Bellinger 
> Date:   Mon Jan 20 03:36:24 2014 +
> 
> iscsi-target: Fix connection reset hang with percpu_ida_alloc
> 
> These two patches have been respun for v3.13.y code here:
> 
> http://www.spinics.net/lists/target-devel/msg06191.html
> http://www.spinics.net/lists/target-devel/msg06192.html
> 
> Please apply for v3.13.y ASAP.

They are in my queue, I have a few hundred other patches to dig through
as well.  Don't worry, they aren't lost...

Same goes for 3.12 and the other patches you have resent me, please be
patient.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 00/14] Add support for MSM's mmio clock/reset controller

2014-02-07 Thread Frank Rowand

On 2/7/2014 12:51 PM, Joe Perches wrote:
> On Fri, 2014-02-07 at 11:38 -0800, Frank Rowand wrote:
>> On 2/6/2014 9:11 PM, Joe Perches wrote:
>>> For patch 1, what checkpatch bug might that be?
> []
>> Sorry, it is patch 2, not patch 1 ("[PATCH v5 02/14] clk: Add 
>> set_rate_and_parent() op"):
>>
>>WARNING: Multiple spaces after return type
>>#188: FILE: include/linux/clk-provider.h:154:
>>+   int (*set_rate_and_parent)(struct clk_hw *hw,
>>
>>total: 0 errors, 1 warnings, 152 lines checked
> 
> Yup, that one might be a bit aggressive.
> 
> It's a complaint about function pointer declaration style.
> 
> from checkpatch:
> --
> # unnecessary space "type  (*funcptr)(args...)"
>   elsif ($declare =~ /\s{2,}$/) {
>   WARN("SPACING",
>"Multiple spaces after return type\n" . 
> $herecurr);
>   }
> --
> 
> This is warning about style equivalent to declarations like:
> 
> int   foo(int bar);
> 
> checkpatch doesn't warn about declarations of that style,
> so likely checkpatch shouldn't warn about multiple spaces
> after a function pointer return type either.
> 
> I don't have a strong opinion one way or another about it.
> 
> If you think it should be silenced, it could be either
> downgraded to a CHK or removed altogether.

OK, now the warning makes sense.  I was reading "spaces" to mean
the space character instead of white space.

I don't have a strong opinion either, but downgrading to a CHK
would be nice.

It would be less confusing to me (though awkward sounding) to
change the message to "Multiple whitespaces after return type".

-Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.12.10

2014-02-07 Thread Nicholas A. Bellinger

On Thu, 2014-02-06 at 12:00 -0800, Greg KH wrote:
> I'm announcing the release of the 3.12.10 kernel.
> 
> All users of the 3.12 kernel series must upgrade.
> 
> The updated 3.12.y git tree can be found at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
> linux-3.12.y
> and can be browsed at the normal kernel.org git web browser:
>   
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
> 
> thanks,
> 
> greg k-h
> 

Ditto for v3.12.y missing the following two upstream patches:

commit 6f6b5d1ec56acdeab0503d2b823f6f88a0af493e
Author: Kent Overstreet 
Date:   Sun Jan 19 08:26:37 2014 +

percpu_ida: Make percpu_ida_alloc + callers accept task state bitmask

commit 555b270e25b0279b98083518a85f4b1da144a181
Author: Nicholas Bellinger 
Date:   Mon Jan 20 03:36:24 2014 +

iscsi-target: Fix connection reset hang with percpu_ida_alloc

The two patches have been respun for v3.12.y code here:

http://www.spinics.net/lists/target-devel/msg06193.html
http://www.spinics.net/lists/target-devel/msg06194.html

Please apply for v3.12.y ASAP.

Thank you,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] x86/kaslr for v3.14

2014-02-07 Thread Dave Young

On 02/07/14 at 03:20pm, H. Peter Anvin wrote:
> On 02/07/2014 03:16 PM, Dave Young wrote:
> > 
> > Hi Vivek,
> > 
> > Chaowang  is looking into passing setup_data 
> > SETUP_E820_EXT
> > instead of using exactmap. Previously Thomas Renninger tried passing them 
> > in e820.
> > I did not find the old thread, but I remember it's not enough because of the
> > 128 entries limitation. 
> > 
> 
> THERE IS NO SUCH LIMITATION.
> 
> Only 128 slots fit in struct boot_params, but additional entries can be
> added to the setup_data linked list.

Ok, I did not describe it right, I actually means the space limit. Thanks for
clarifying. 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.13.2

2014-02-07 Thread Nicholas A. Bellinger

On Thu, 2014-02-06 at 12:01 -0800, Greg KH wrote:
> I'm announcing the release of the 3.13.2 kernel.
> 
> All users of the 3.13 kernel series must upgrade.
> 
> The updated 3.13.y git tree can be found at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
> linux-3.13.y
> and can be browsed at the normal kernel.org git web browser:
>   
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
> 
> thanks,
> 
> greg k-h
> 

Hi Greg,

I noticed that the following two target upstream patches in v3.14-rc1
did not make it into v3.13.y or stable-queue.git:

commit 6f6b5d1ec56acdeab0503d2b823f6f88a0af493e
Author: Kent Overstreet 
Date:   Sun Jan 19 08:26:37 2014 +

percpu_ida: Make percpu_ida_alloc + callers accept task state bitmask

commit 555b270e25b0279b98083518a85f4b1da144a181
Author: Nicholas Bellinger 
Date:   Mon Jan 20 03:36:24 2014 +

iscsi-target: Fix connection reset hang with percpu_ida_alloc

These two patches have been respun for v3.13.y code here:

http://www.spinics.net/lists/target-devel/msg06191.html
http://www.spinics.net/lists/target-devel/msg06192.html

Please apply for v3.13.y ASAP.

Thank you,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9] mm: Remove ifdef condition in include/linux/mm.h

2014-02-07 Thread Josh Triplett

On Fri, Feb 07, 2014 at 03:09:09PM -0800, David Rientjes wrote:
> On Fri, 7 Feb 2014, Andrew Morton wrote:
> 
> > > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > > > > index 1cedd00..5f8348f 100644
> > > > > > --- a/include/linux/mm.h
> > > > > > +++ b/include/linux/mm.h
> > > > > > @@ -1589,10 +1589,8 @@ static inline int 
> > > > > > __early_pfn_to_nid(unsigned long pfn)
> > > > > >  #else
> > > > > >  /* please see mm/page_alloc.c */
> > > > > >  extern int __meminit early_pfn_to_nid(unsigned long pfn);
> > > > > > -#ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
> > > > > >  /* there is a per-arch backend function. */
> > > > > >  extern int __meminit __early_pfn_to_nid(unsigned long pfn);
> > > > > > -#endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
> > > > > >  #endif
> > > > > >  
> > > > > >  extern void set_dma_reserve(unsigned long new_dma_reserve);
> > > > > 
> > > > > Wouldn't it be better to just declare the __early_pfn_to_nid() in 
> > > > > mm/page_alloc.c to be static?
> > > > 
> > > > Won't that break the ability to override that function in
> > > > architecture-specific code (as arch/ia64/mm/numa.c does)?
> > > > 
> > > 
> > > Why?  CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID should define where this function 
> > > is defined so ia64 should have it set and the definition which I'm 
> > > suggesting be static is only compiled when this is undefined in 
> > > mm/page_alloc.c.  I'm not sure why we'd want to be messing with the 
> > > declaration?
> > 
> > __early_pfn_to_nid() must be global if it is implemented in arch/. 
> > 
> 
> Why??  If CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID then, yes, we need it to be 
> global.  Otherwise it's perfectly fine just being static in file scope.  
> This causes the compilation unit to break when you compile it, not wait 
> until vmlinux and find undefined references.
> 
> I see no reason it can't be done like this in mm/page_alloc.c:
> 
>   #ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
>   extern int __meminit __early_pfn_to_nid(unsigned long pfn);

No, a .c file should not have an extern declaration in it.  This should
live in an appropriate header file, to be included in both page_alloc.c
and any arch file that defines an overriding function.

> Both of these options look much better than
> 
>   include/linux/mm.h:
> 
>   #if !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP) && \
>   !defined(CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID)
>   static inline int __early_pfn_to_nid(unsigned long pfn)
>   {
>   return 0;
>   }
>   #else
>   /* please see mm/page_alloc.c */
>   extern int __meminit early_pfn_to_nid(unsigned long pfn);
>   #ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
>   /* there is a per-arch backend function. */
>   extern int __meminit __early_pfn_to_nid(unsigned long pfn);
>   #endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
>   #endif
> 
> where all this confusion is originating from.

The proposal is to first simplify those ifdefs by eliminating the inner
one in the #else; I agree with Andrew that we ought to go ahead and take
that step given the patch at hand, and then figure out if there's an
additional simplification possible.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] x86/kaslr for v3.14

2014-02-07 Thread H. Peter Anvin

On 02/07/2014 03:16 PM, Dave Young wrote:
> 
> Hi Vivek,
> 
> Chaowang  is looking into passing setup_data 
> SETUP_E820_EXT
> instead of using exactmap. Previously Thomas Renninger tried passing them in 
> e820.
> I did not find the old thread, but I remember it's not enough because of the
> 128 entries limitation. 
> 

THERE IS NO SUCH LIMITATION.

Only 128 slots fit in struct boot_params, but additional entries can be
added to the setup_data linked list.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 1/1] Drivers: hv: vmbus: Extract the mmio information from DSDT

On Wed, Jan 29, 2014 at 06:14:39PM -0800, K. Y. Srinivasan wrote:
> On Gen2 firmware, Hyper-V does not emulate the PCI bus. However, the MMIO
> information is packaged up in DSDT. Extract this information and export it
> for use by the synthetic framebuffer driver. This is the only driver that
> needs this currently.

I don't see a follow-on patch that uses these variables, where is that?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv4] driver core/platform: don't leak memory allocated for dma_mask

On Mon, Jan 27, 2014 at 11:05:52AM +0100, Yann Droneaud wrote:
> Since commit 01dcc60a7cb8, platform_device_register_full() is
> available to allocate and register a platform device.
> 
> If a dma_mask is provided as part of platform_device_info,
> platform_device_register_full() allocate memory for a u64 using
> kmalloc().
> 
> A comment in the code state that "[t]his memory isn't freed when the
> device is put".
> 
> It's never a good thing to leak memory, but there's only very few
> users of platform_device_info's dma_mask, and those are mostly
> "static" devices that are not going to be plugged/unplugged often.
> 
> So memory leak is not really an issue, but allocating 8 bytes through
> kmalloc() seems overkill.
> 
> And it's a pity to have to allocate 8 bytes for the dma_mask while up
> to 7 bytes are wasted at the end of struct platform_object in the form
> of padding after name field: unfortunately this padding is not used
> when allocating the memory to hold the name.
> 
> To address theses issues, this patch adds dma_mask to platform_object
> struct so that it is always allocated for all struct platform_device
> allocated through platform_device_alloc() or platform_device_register_full().
> And since it's within struct platform_object, dma_mask won't be leaked
> anymore when struct platform_device got released. Storage for dma_mask
> is added almost for free by removing the padding at the end of struct
> platform_object.
> 
> Padding at the end of the structure is removed by making name a C99
> flexible array member (eg. a zero sized array). To handle this change,
> memory allocation is updated to take care of allocating an additional
> byte for the NUL terminating character.
> 
> No more memory leak, no small allocation, no byte wasted and
> a slight reduction in code size.
> 
> Built on Fedora 20, using GCC 4.8, for ARM, i386, x86_64 and PPC64
> architectures, the size of the object file and the data structure layout
> are updated as follow, produced with commands:
> 
>   $ size drivers/base/platform.o
>   $ pahole drivers/base/platform.o \
>--recursive \
>--class_name device,pdev_archdata,platform_device,platform_object
> 
>   --- size+pahole.next-20140124
>   +++ size+pahole.next-20140124+
>   @@ -1,5 +1,5 @@
>   textdata bss dec hex filename
>   -   5616 472  32612017e8 obj-arm/drivers/base/platform.o
>   +   5572 472  32607617bc obj-arm/drivers/base/platform.o
>struct device {
>struct device *parent;   /* 0 4 */
>struct device_private *p;/* 4 4 */
>   @@ -77,15 +77,15 @@ struct platform_object {
>/* XXX last struct has 4 bytes of padding */
> 
>/* --- cacheline 6 boundary (384 bytes) --- */
>   -char   name[1];  /*   384 1 */
>   +u64dma_mask; /*   384 8 */
>   +char   name[0];  /*   392 0 */
> 
>   -/* size: 392, cachelines: 7, members: 2 */
>   -/* padding: 7 */
>   +/* size: 392, cachelines: 7, members: 3 */
>/* paddings: 1, sum paddings: 4 */
>/* last cacheline: 8 bytes */
>};
> 
>   textdata bss dec hex filename
>   -   6007 532  32657119ab obj-i386/drivers/base/platform.o
>   +   5943 532  326507196b obj-i386/drivers/base/platform.o
>struct device {
>struct device *parent;   /* 0 4 */
>struct device_private *p;/* 4 4 */
>   @@ -161,14 +161,14 @@ struct platform_device {
>struct platform_object {
>struct platform_device pdev; /* 0   392 */
>/* --- cacheline 6 boundary (384 bytes) was 8 bytes ago --- */
>   -char   name[1];  /*   392 1 */
>   +u64dma_mask; /*   392 8 */
>   +char   name[0];  /*   400 0 */
> 
>   -/* size: 396, cachelines: 7, members: 2 */
>   -/* padding: 3 */
>   -/* last cacheline: 12 bytes */
>   +/* size: 400, cachelines: 7, members: 3 */
>   +/* last cacheline: 16 bytes */
>};
> 
>   textdata bss dec hex filename
>   -   88512112  48   110112b03 obj-ppc64/drivers/base/platform.o
>   +   87872104  48   109392abb obj-ppc64/drivers/base/platform.o
>struct device {
>struct device *parent;   /* 0 8 */
>struct device_private *p;/* 8 8 */
>   @@ -256,14 +256,14 @@ struct platform_device {
>struct platform_object {
>struct platform_device pdev; /*

Commit 34b9c07a3 (microblaze: Disable stack protection from bootloader) causing qemu crash

Michal,

commit 34b9c07a3 (microblaze: Disable stack protection from bootloader) results
in the following qemu crash in 3.14-rc1.

/opt/buildbot/bin/qemu-system-microblaze -M petalogix-s3adsp1800 -kernel 
arch/microblaze/boot/linux.bin -no-reboot -append "console=ttyUL0,115200 " 
-nographic
qemu: fatal: fetching nop sequence

IN: PC=20
rmsr=4300 resr=7 rear=c0389fe8 debug=0 imm=ffd0 iflags=0 fsr=0
btaken=1 btarget=c03a9f24 mode=kernel(saved=kernel) eip=512 ie=0
r00= r01=c0389fcc r02=c0386a52 r03=00c0
r04=4100 r05=9052fab4 r06= r07=90530ab4
r08= r09=0040 r10=0040 r11=c03a9f24
r12=00621000 r13=40aef0c0 r14= r15=c294
r16= r17=c03a9f28 r18= r19=
r20= r21= r22= r23=
r24= r25= r26= r27=
r28= r29=0040 r30=0300 r31=c03932d4


Aborted (core dumped)

I have seen this with qemu 1.6.0 and 1.7.0.

Reverting the patch solves the problem.

Is this a qemu bug, a bug in the code, or a bug in my configuration ?
Any idea what I can do about it ?

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] x86/kaslr for v3.14

2014-02-07 Thread Dave Young

On 02/07/14 at 11:24am, Vivek Goyal wrote:
> On Fri, Feb 07, 2014 at 08:04:13AM -0800, H. Peter Anvin wrote:
> > On 02/07/2014 06:49 AM, Vivek Goyal wrote:
> > > 
> > > Hi Kees,
> > > 
> > > Dave Young is testing kdump with kaslr enabled. He is facing some issues.
> > > 
> > > One issue he mentioned is that when second kernel boots, it might be
> > > placed in an area which is outside the reserved area for second kernel.
> > > 
> > > We reserve a certain memory for second kernel. And modify memory map of
> > > second kernel using memmap=exactmap parameter. Looks like kernel placement
> > > is happening before memmap=exactmap takes effect. And that seems to be
> > > the reason that second kernel can be placed outside the reserved memory.
> > > 
> > > IOW, memmap=exactmap and kaslr don't work together. Is it possible to
> > > first let memmap=exactmap take affect and then kaslr does its job. Or it
> > > is too late by the time memmap=exactmap is parsed.
> > > 
> > > As a workaround, Dave is currently using "nokaslr" command line parameter
> > > for second kernel. He is still facing issues where makedumpfile segment
> > > faults. He is looking into it further.
> > > 
> > > I thought I will atleast bring up with issue of memmap=exactmap and kaslr
> > > being incompatible.
> > > 
> > 
> > Yes, because memmap=exactmap gets parsed too late; kaslr assumes that
> > the e820 information passed to it is actually correct.
> > 
> > Yet another cause of breakage caused by the decision on the part of
> > kdump to rely on command-line options.
> 
> [CC kexec mailing list]
> 
> Ok, I think this is high time we change kexec-tools to not use
> memmap=exactmap and start passing modified memory map in bootparams. I
> think only concern with that change was backward compatibility of
> kexec-tools with older kernels.
> 
> IIUC, only thing which will be impacted by this change is users of
> saved_max_pfn which determine the highest accessible pfn in first
> kernel. Some calgary IOMMU code seems to be the only user of it now.
> 
> So may be we can create a new command line option say --pass-memmap-cmdline
> to kexec-tools which forces old behavior and by default we pass memmap
> in bootparams.
> 
> Or create --do-not-pass-memmap-cmdline and new users will use it. Default
> will be old behavior.

Hi Vivek,

Chaowang  is looking into passing setup_data SETUP_E820_EXT
instead of using exactmap. Previously Thomas Renninger tried passing them in 
e820.
I did not find the old thread, but I remember it's not enough because of the
128 entries limitation. 

In case for kaslr, I agree that it do not make sense for kdump kernel. IMHO it's
better to disable it automaticlly for kdump kernel but we can use the nokaslr
as workaround for now. 

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 1/1] Drivers: hv: Implement the file copy service

On Tue, Jan 21, 2014 at 05:43:53PM -0800, K. Y. Srinivasan wrote:
> +/*
> + * Create a char device that can support read/write for passing
> + * the payload.
> + */
> +static struct cdev fcopy_cdev;
> +static struct class *cl;
> +static struct device *sysfs_dev;

Why not just be a misc device, you only want 1 minor number for a char
device:

> +static int fcopy_dev_init(void)
> +{
> + int result;
> +
> + result = alloc_chrdev_region(_dev, 1, 1, "hv_fcopy");

See, one minor.

> + if (result < 0) {
> + pr_err("Cannot get major number\n");
> + return result;
> + }
> +
> + cl = class_create(THIS_MODULE, "chardev");

That's a _really_ generic name, come on, you know better than that.

> + if (IS_ERR(cl)) {
> + pr_err("Error creating fcopy class.\n");

Your error string is wrong :(

> + result = PTR_ERR(cl);
> + goto err_unregister;
> + }
> +
> + sysfs_dev = device_create(cl, NULL, fcopy_dev, "%s", "hv_fcopy");

A device at the root of sysfs?  No, you have a bus to hang devices off
of, use that.  What do you need this device for anyway?

> + if (IS_ERR(sysfs_dev)) {
> + pr_err("Device creation failed\n");
> + result = PTR_ERR(cl);
> + goto err_destroy_class;
> + }
> +
> + cdev_init(_cdev, _fops);
> + fcopy_cdev.owner = THIS_MODULE;
> + fcopy_cdev.ops = _fops;
> +
> + result = cdev_add(_cdev, fcopy_dev, 1);

Ah, to get udev to pay attention to the char device, no, just use a misc
device, should make this whole code a lot simpler and more "obvious" as
to what you want/need.

> + if (result) {
> + pr_err("Cannot cdev_add\n");
> + goto err_destroy_device;
> + }
> + return result;
> +
> +err_destroy_device:
> + device_destroy(cl, fcopy_dev);
> +err_destroy_class:
> + class_destroy(cl);
> +err_unregister:
> + unregister_chrdev_region(fcopy_dev, 1);
> + return result;

Ugh, I hate the cdev interface, one of these days I'll fix it up, it's
so unwieldy...

> +static void fcopy_dev_deinit(void)
> +{
> + /*
> +  * first kill the daemon.
> +  */
> + if (dtp != NULL)
> + send_sig(SIGKILL, dtp, 0);

We kill userspace daemon's from the kernel?  That's a recipe for
disaster...

Why?  What does it matter here if the daemon keeps running, it should
fail gracefully if the character device is removed, right?  If not, that
needs to be fixed anyway.

thanks,

greg k-h

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: respect the clock dependencies in of_clk_init

2014-02-07 Thread Sebastian Hesselbarth


On 02/07/2014 03:49 PM, Gregory CLEMENT wrote:

On 07/02/2014 15:43, Ezequiel Garcia wrote:

On Fri, Feb 07, 2014 at 09:24:30AM -0500, Jason Cooper wrote:

On Fri, Feb 07, 2014 at 10:06:08AM -0300, Emilio López wrote:

[snip a great explanation]

Guys, can I get some Tested-by's on this?



In case someone missed Emilio's comment about it, I gave his oneliner
a test on A370 Reference Design. It worked just as well as Sebastian's.


Well ok it's working but this patch is not better than Sebastian, it is
even worth. I don't think it is a good idea at all to totally ignore the


Tstststs.. Gregory please re-read the above slowly.. and think about
where you'd put me in.

Hint: "this patch", "not better than", "even worse". ;)


information given by the device tree.


Actually, I have no strong opinion about how we fix the issue now. 
Emilio's patch is short and very suitable for a fix. I'll test later

this weekend.

For the long run, I definitely prefer probe ordering within clk frame
work or even better some early_device stuff.


Tested-by: Ezequiel Garcia 


-8<--

 From ffdb49506e3ce92090c15e1f9b37f4d465097ac1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Emilio=20L=C3=B3pez?= 
Date: Thu, 6 Feb 2014 18:07:07 -0300
Subject: [PATCH] clk: mvebu: fix name dependency during registration time

Currently, mvebu_clk_gating_setup has a silly dependency on clock
registration order just to gather the parent clock name. This is


Of course, the dependency is not silly but we are just ignoring that
some clocks actually have a different parent clock. As long as we are
not interested in the frequency and they all depend on a fixed-clock
it makes no difference. Also, on some gates, we do some tweaking, e.g.
on Dove there is a clock gate for the GBE ip that we loop back to the
GBE PHY gate.. some day I may be so bored to get it straight.


completely unnecesary, as it supports using an already provided name
via the clk_gating_soc_desc structs, and we can therefore solve this
issue with a 69+/- line patch. But, given that the parent name is
always "tclk" as default-hardcoded on mvebu_coreclk_setup(), we can
just default-hardcode it here too and get away with solving this
problem with a one-liner.


I agree with the default hard-coded "tclk" for now. But in general,
clocking can become very nasty and rather than coding the whole fscking
clock tree like the imx clock tree beast does, it would be much more
readable to be able separate the clock drivers into different parts.

Sebastian


---
  drivers/clk/mvebu/common.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
index 25ceccf..6c63b43 100644
--- a/drivers/clk/mvebu/common.c
+++ b/drivers/clk/mvebu/common.c
@@ -121,7 +121,7 @@ void __init mvebu_clk_gating_setup(struct
device_node *np,
struct clk_gating_ctrl *ctrl;
struct clk *clk;
void __iomem *base;
-   const char *default_parent = NULL;
+   const char *default_parent = "tclk";
int n;

base = of_iomap(np, 0);
--
1.8.5.3



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9] mm: Remove ifdef condition in include/linux/mm.h

2014-02-07 Thread David Rientjes

On Fri, 7 Feb 2014, Andrew Morton wrote:

> > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > > > index 1cedd00..5f8348f 100644
> > > > > --- a/include/linux/mm.h
> > > > > +++ b/include/linux/mm.h
> > > > > @@ -1589,10 +1589,8 @@ static inline int __early_pfn_to_nid(unsigned 
> > > > > long pfn)
> > > > >  #else
> > > > >  /* please see mm/page_alloc.c */
> > > > >  extern int __meminit early_pfn_to_nid(unsigned long pfn);
> > > > > -#ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
> > > > >  /* there is a per-arch backend function. */
> > > > >  extern int __meminit __early_pfn_to_nid(unsigned long pfn);
> > > > > -#endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
> > > > >  #endif
> > > > >  
> > > > >  extern void set_dma_reserve(unsigned long new_dma_reserve);
> > > > 
> > > > Wouldn't it be better to just declare the __early_pfn_to_nid() in 
> > > > mm/page_alloc.c to be static?
> > > 
> > > Won't that break the ability to override that function in
> > > architecture-specific code (as arch/ia64/mm/numa.c does)?
> > > 
> > 
> > Why?  CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID should define where this function 
> > is defined so ia64 should have it set and the definition which I'm 
> > suggesting be static is only compiled when this is undefined in 
> > mm/page_alloc.c.  I'm not sure why we'd want to be messing with the 
> > declaration?
> 
> __early_pfn_to_nid() must be global if it is implemented in arch/. 
> 

Why??  If CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID then, yes, we need it to be 
global.  Otherwise it's perfectly fine just being static in file scope.  
This causes the compilation unit to break when you compile it, not wait 
until vmlinux and find undefined references.

I see no reason it can't be done like this in mm/page_alloc.c:

#ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
extern int __meminit __early_pfn_to_nid(unsigned long pfn);
#else
static int __meminit __early_pfn_to_nid(unsigned long pfn)
{
...
}

or delcare __early_pfn_to_nid() to have __attribute__((weak)) and override 
it when CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID (and get rid of the pointless 
CONFIG option entirely at that point).

Both of these options look much better than

include/linux/mm.h:

#if !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP) && \
!defined(CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID)
static inline int __early_pfn_to_nid(unsigned long pfn)
{
return 0;
}
#else
/* please see mm/page_alloc.c */
extern int __meminit early_pfn_to_nid(unsigned long pfn);
#ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
/* there is a per-arch backend function. */
extern int __meminit __early_pfn_to_nid(unsigned long pfn);
#endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
#endif

where all this confusion is originating from.

It's obviously up to your taste in how to proceed, but the latter looks 
sloppy to me and is the reason we have so many unreferenced prototypes in 
header files.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv4 4/7] hwspinlock/core: add common OF helpers

2014-02-07 Thread Bjorn Andersson

On Mon, Jan 13, 2014 at 4:19 PM, Suman Anna  wrote:
> This patch adds three new OF helper functions to use/request
> locks from a hwspinlock device instantiated through a
> device-tree blob.

Nice, I ran in to the problem of needing a probe deferral on a
hwspinlock earlier this week so I implemented this yesterday...then I
got a pointer to your series.

[snip]
>  /**
> + * of_hwspin_lock_request_specific() - request a OF phandle-based specific 
> lock
> + * @np: device node from which to request the specific hwlock
> + * @propname: property name containing hwlock specifier(s)
> + * @index: index of the hwlock
> + *
> + * This function is the OF equivalent of hwspin_lock_request_specific(). This
> + * function provides a means for users of the hwspinlock module to request a
> + * specific hwspinlock using the phandle of the hwspinlock device. The 
> requested
> + * lock number is indexed relative to the hwspinlock device, unlike the
> + * hwspin_lock_request_specific() which is an absolute lock number.
> + *
> + * Returns the address of the assigned hwspinlock, or NULL on error
> + */
> +struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
> +   const char *propname, int index)
> +{
> +   struct hwspinlock_device *bank;
> +   struct of_phandle_args args;
> +   int id;
> +   int ret;
> +
> +   ret = of_parse_phandle_with_args(np, propname, "#hwlock-cells", index,
> +);
> +   if (ret) {
> +   pr_warn("%s: can't parse hwlocks property of node '%s[%d]' 
> ret = %d\n",
> +   __func__, np->full_name, index, ret);
> +   return NULL;
> +   }

of_parse_phandle_with_args() already does pr_err if it can't find the
phandle and on some of the issues related to arguments. So please
remove this pr_warn().

It seems to be standard practice to pass the error value back to the
consumer, so you should
return ERR_PTR(ret); here instead of the NULL...

> +
> +   mutex_lock(_tree_lock);
> +   list_for_each_entry(bank, _devices, list)
> +   if (bank->dev->of_node == args.np)
> +   break;
> +   mutex_unlock(_tree_lock);
> +   if (>list == _devices) {
> +   pr_warn("%s: requested hwspinlock device %s is not 
> registered\n",
> +   __func__, args.np->full_name);
> +   return NULL;

...especially since you want the consumer to have the ability to
identify this error. Here you should
return ERR_PTR(-EPROBE_DEFER); so that the consumer knows that this
lock is not _yet_ registered, but will be in the future.

You should remove this pr_warn as well. The standard use of this
function would be in a probe() and just returning this error value
from that probe will give you a line in the log indicating that this
was in fact the issue.

> +   }
> +
> +   id = bank->ops->of_xlate(bank, );
> +   if (id < 0 || id >= bank->num_locks) {
> +   pr_warn("%s: requested lock %d is either out of range [0, %d] 
> or failed translation\n",
> +   __func__, id, bank->num_locks - 1);
> +   return NULL;

Please return ERR_PTR(-EINVAL); here.


Looking forward to your next spin, as I will actually use this interface :)

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/73] init: delete the __cpuinit related stubs

On Tue, Jan 21, 2014 at 04:22:04PM -0500, Paul Gortmaker wrote:
> The __cpuinit support was removed several releases ago.  People
> have had a chance to update their out of tree code, so now we
> remove the no-op stubs.
> 
> Also delete the mention of __cpuinitdata from the tag script.
> 
> Cc: Andrew Morton 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Paul Gortmaker 

Acked-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/13] cross rename v4

2014-02-07 Thread J. Bruce Fields

On Fri, Feb 07, 2014 at 05:48:58PM +0100, Miklos Szeredi wrote:
> Changes since the last version (based on Al's review):
> 
>  - cross-rename: fix locking of nondirectories for NFSv4
>  - ext4: split cross-rename and plain rename into separate functions
>  - introduce i_op->rename2 with flags, don't touch ->rename
>  - last (optional) patch to merge ->rename2 back into ->rename
> 
> The splitting of the ext4 implemetation was indeed a good idea as it 
> uncovered a
> memory leak and small inconsistencies with the merged implementation.
> 
> Splitting out rename2 will lessen the code churn, but I think is ugly.  
> However
> this is a question of taste, last patch can be ommitted without loss of
> functionality.
> 
> Bruce, could you please review the locking and delegation thing in patch #8
> "vfs: add cross-rename"?

Yep, done.  I'll also try running this through my nfs tests, for what
it's worth.  (Not today as there's some unrelated regression to sort
out first.)

Feel free to add a

Reviewed-by: J. Bruce Fields 

for any but the ext4 patches, which I skipped.

--b.

> 
> Git tree is here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git cross-rename
> 
> Thanks,
> Miklos
> 
> ---
> Miklos Szeredi (13):
>   vfs: add d_is_dir()
>   vfs: rename: move d_move() up
>   vfs: rename: use common code for dir and non-dir
>   vfs: add renameat2 syscall
>   vfs: add RENAME_NOREPLACE flag
>   security: add flags to rename hooks
>   vfs: lock_two_nondirectories: allow directory args
>   vfs: add cross-rename
>   ext4: rename: create ext4_renament structure for local vars
>   ext4: rename: move EMLINK check up
>   ext4: rename: split out helper functions
>   ext4: add cross rename support
>   vfs: merge rename2 into rename
> 
> ---
>  Documentation/filesystems/Locking  |   2 +-
>  Documentation/filesystems/vfs.txt  |  14 +-
>  arch/x86/syscalls/syscall_64.tbl   |   1 +
>  .../lustre/lustre/include/linux/lustre_compat25.h  |   4 +-
>  drivers/staging/lustre/lustre/llite/namei.c|   3 +-
>  drivers/staging/lustre/lustre/lvfs/lvfs_linux.c|   2 +-
>  fs/9p/v9fs.h   |   3 +-
>  fs/9p/vfs_inode.c  |   4 +-
>  fs/affs/affs.h |   3 +-
>  fs/affs/namei.c|   3 +-
>  fs/afs/dir.c   |   6 +-
>  fs/bad_inode.c |   3 +-
>  fs/bfs/dir.c   |   3 +-
>  fs/btrfs/inode.c   |   3 +-
>  fs/cachefiles/namei.c  |   4 +-
>  fs/ceph/dir.c  |   3 +-
>  fs/cifs/cifsfs.h   |   2 +-
>  fs/cifs/inode.c|   3 +-
>  fs/coda/dir.c  |   8 +-
>  fs/dcache.c|  45 +-
>  fs/debugfs/inode.c |   2 +-
>  fs/ecryptfs/inode.c|   5 +-
>  fs/exofs/namei.c   |   3 +-
>  fs/ext2/namei.c|   5 +-
>  fs/ext3/namei.c|   5 +-
>  fs/ext4/namei.c| 483 
> +++--
>  fs/ext4/super.c|   6 +-
>  fs/f2fs/namei.c|   3 +-
>  fs/fat/namei_msdos.c   |   3 +-
>  fs/fat/namei_vfat.c|   3 +-
>  fs/fuse/dir.c  |   3 +-
>  fs/gfs2/inode.c|   3 +-
>  fs/hfs/dir.c   |   3 +-
>  fs/hfsplus/dir.c   |   3 +-
>  fs/hostfs/hostfs_kern.c|   3 +-
>  fs/hpfs/namei.c|   3 +-
>  fs/inode.c |  20 +-
>  fs/jffs2/dir.c |   5 +-
>  fs/jfs/namei.c |   3 +-
>  fs/kernfs/dir.c|   3 +-
>  fs/libfs.c |   3 +-
>  fs/logfs/dir.c |   3 +-
>  fs/minix/namei.c   |   5 +-
>  fs/namei.c | 310 +++--
>  fs/ncpfs/dir.c |   5 +-
>  fs/nfs/dir.c   |   3 +-
>  fs/nfs/internal.h  |   3 +-
>  fs/nfsd/vfs.c  |   2 +-
>  fs/nilfs2/namei.c  |   3 +-
>  fs/ocfs2/namei.c

Re: [PATCH 72/73] drivers: delete remaining non-required instances of

On Tue, Jan 21, 2014 at 04:23:15PM -0500, Paul Gortmaker wrote:
> None of these files are actually using any __init type directives
> and hence don't need to include .  Most are just a
> left over from __devinit and __cpuinit removal, or simply due to
> code getting copied from one driver to the next.
> 
> This covers off all the remaining scattered instances in drivers
> in order to avoid a bunch more separate smaller commits.
> 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Paul Gortmaker 

Acked-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3] net/dt: Add support for overriding phy configuration from device tree

2014-02-07 Thread Florian Fainelli

2014-02-05 David Laight :
> From: Florian Fainelli
>> It would be good to explain exactly how your hardware is broken
>> exactly. I really do not think that such a fine-grained setting where
>> you could disable, e.g: 100BaseT_Full, but allow 100BaseT_Half to
>> remain usable makes that much sense. In general, Gigabit might be
>> badly broken, but 100 and 10Mbits/sec should work fine. How about the
>> MASTER-SLAVE bit, is overriding it really required?
>
> There are plenty of systems out there where you'd want to disable
> either HDX or FDX modes.
> The MAC unit has to know whether the PHY is in HDX or FDX in order
> to work properly. Many do not need to know the speed - since the
> PHY is responsible for the tx/rx fifo clock.
> Getting the negotiated speed out of the PHY can be difficult, while
> the ANAR can easily be set.
> Unfortunately it is usually impossible to disable the 'fall-back'
> 10M HDX.

The problem that I have with that approach in general is that:

- it bloats the code for a set of properties that are going to be used
by hopefully a few percentage of the actual Device Trees out there
- it puts no limits on what is acceptable/best-practice to be put in
terms of configuration in the Device Tree, how about the 16x16 other
register values out there which are standardized?
- a PHY fixup should be registered based on the top-level compatible
property for a given board where the specific PHY on a specific board
is known to be broken
- make things incredibly harder to debug than they are today

I do acknowledge the need to have a solution to these problems, but
this seems to duplicate existing mechanisms available (e.g: PHY
fixups) without leveraging information that should be properly flagged
in the Device Tree (board model, root-node compatible string etc...)
to allow software to take corrective measures.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/13] vfs: add cross-rename

2014-02-07 Thread J. Bruce Fields

On Fri, Feb 07, 2014 at 05:49:06PM +0100, Miklos Szeredi wrote:
> From: Miklos Szeredi 
> 
> If flags contain RENAME_EXCHANGE then exchange source and destination files.
> There's no restriction on the type of the files; e.g. a directory can be
> exchanged with a symlink.
> 
> Signed-off-by: Miklos Szeredi 
> Reviewed-by: Jan Kara 

I don't see any problem with the delegation stuff.  Some random
bikeshedding:

> @@ -2575,6 +2579,10 @@ static void __d_move(struct dentry * dentry, struct 
> dentry * target)
>  
>   /* Unhash the target: dput() will then get rid of it */

I never understood the point of this comment.  It's not even right, is
it?  And if anything this makes it less so.  Delete?

>   __d_drop(target);
> + if (exchange) {
> + __d_rehash(target,
> +d_hash(dentry->d_parent, dentry->d_name.hash));
> + }
>  
>   list_del(>d_u.d_child);
>   list_del(>d_u.d_child);
...
> @@ -4042,7 +4057,7 @@ int vfs_rename(struct inode *old_dir, struct dentry 
> *old_dentry,
>  
>   old_name = fsnotify_oldname_init(old_dentry->d_name.name);
>   dget(new_dentry);
> - if (!is_dir)
> + if (!is_dir || (flags & RENAME_EXCHANGE))
>   lock_two_nondirectories(source, target);
>   else if (target)
>   mutex_lock(>i_mutex);

I had to stop to think about that for a minute: OK, so in the normal
rename case we still need to lock the to-be-deleted target, and
lock_two_nondirectories won't do that for us because it ignores
directories.  Got it.

This feels a bit ugly but I don't have a better idea.

> @@ -4051,25 +4066,25 @@ int vfs_rename(struct inode *old_dir, struct dentry 
> *old_dentry,

Most of this function is under (flags & RENAME_EXCHANGE) conditionals at
this point.  Have you looked at how much is duplicated if you split this
into something like vfs_rename and vfs_exchange?

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] w1: refcnt fix, skip non-error send, docs

2014-02-07 Thread zbr



08.02.2014, 02:25, "David Fries" :

>>  Can you also check that protocol documentation is correct?
>
> Documentation/connector/connector.txt ?  I found it a little unclear,
> I'll see what I can do.

No, I meant Documentation/w1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/3] Add modules for realtek USB card reader

On Thu, Feb 06, 2014 at 10:35:04PM +0800, rogera...@realtek.com wrote:
> From: Roger Tseng 
> 
> This patchset adds modules to support Realtek USB vendor specific class flash
> card reader: one base module in MFD subsystem and two host modules in both mmc
> and memstick subsystems. The architecture is similar to rtsx_pci.
> 
> This work is done primarily to replace the staging driver: staging/rts5139,
> which doesn't utilize mmc nor memstick subsystems. Once the patchset or its
> revision is applied, we may need Greg's help to remove the staging one.
> 
> v2:
> 1. Fix potential buffer overflow in rtsx_usb_seq_write_register()
> 2. Remove unnecessary casting and messages
> 3. Revise coding style and white spaces
> 
> v3:
> 1. Fix MMC detection fail when under xhci
> 2. Minor change of pm_runtime behavior in rtsx_usb_ms to prevent some rare
>freeze due to erroneous Memstick card(not MS-Pro)
> 3. Further revise coding style as suggested in the thread of v2
> 4. Using managed resources: devm_*
> 5. Change license from "GPL v2 and later" to "GPL v2"
> 
> Roger Tseng (3):
>   mfd: Add realtek USB card reader driver
>   mmc: Add realtek USB sdmmc host driver
>   memstick: Add realtek USB memstick host driver

Looks good to me, thanks for doing this work:

Acked-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9] mm: Remove ifdef condition in include/linux/mm.h

2014-02-07 Thread Andrew Morton

On Fri, 7 Feb 2014 13:15:29 -0800 (PST) David Rientjes  
wrote:

> On Fri, 7 Feb 2014, Josh Triplett wrote:
> 
> > > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > > index 1cedd00..5f8348f 100644
> > > > --- a/include/linux/mm.h
> > > > +++ b/include/linux/mm.h
> > > > @@ -1589,10 +1589,8 @@ static inline int __early_pfn_to_nid(unsigned 
> > > > long pfn)
> > > >  #else
> > > >  /* please see mm/page_alloc.c */
> > > >  extern int __meminit early_pfn_to_nid(unsigned long pfn);
> > > > -#ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
> > > >  /* there is a per-arch backend function. */
> > > >  extern int __meminit __early_pfn_to_nid(unsigned long pfn);
> > > > -#endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
> > > >  #endif
> > > >  
> > > >  extern void set_dma_reserve(unsigned long new_dma_reserve);
> > > 
> > > Wouldn't it be better to just declare the __early_pfn_to_nid() in 
> > > mm/page_alloc.c to be static?
> > 
> > Won't that break the ability to override that function in
> > architecture-specific code (as arch/ia64/mm/numa.c does)?
> > 
> 
> Why?  CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID should define where this function 
> is defined so ia64 should have it set and the definition which I'm 
> suggesting be static is only compiled when this is undefined in 
> mm/page_alloc.c.  I'm not sure why we'd want to be messing with the 
> declaration?

__early_pfn_to_nid() must be global if it is implemented in arch/. 

Making it static when it is implemented in core mm makes a bit of
sense, in that it cleans up the non-ia64 namespace and discourages
usage from other compilation units.  But it's is a bit odd and
unexpected to do such a thing.  I'm inclined to happily nuke the ifdef
then go think about something else ;)




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-sunxi] Re: [PATCH] irq: Add new flag to ack level-triggered interrupts before unmasking

2014-02-07 Thread Carlo Caione

On Fri, Feb 7, 2014 at 6:24 PM, Thomas Gleixner  wrote:
> Not sure, really, but I tend to a core patch. Though we really want to
> know whether the issue is threaded only or not. If it's a general
> issue then this wants to go into unmask_irq() itself and not into an
> extra unmask_threaded_irq() function.

Unfortunately I cannot be sure whether the problem is still present
for the non threaded case since in the hardware I have the NMI
controller is only connected to the PMIC.
Considering that I have no way of checking what do you suggest?

-- 
Carlo Caione
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ieee80211: Print human-readable disassoc/deauth reason codes

2014-02-07 Thread Luca Coelho

On Fri, 2014-02-07 at 09:46 -0600, Larry Finger wrote:
> On 02/07/2014 06:53 AM, Kalle Valo wrote:
> > Johannes Berg  writes:
> >
> >> On Wed, 2014-02-05 at 19:44 -0600, Calvin Owens wrote:
> >>> Create a function to return a descriptive string for each reason code,
> >>> and print that instead of the numeric value in the kernel log. These
> >>> codes are easily found on popular search engines, but one is generally
> >>> not able to access the internet when dealing with wireless connectivity
> >>> issues.
> >>
> >> I believe both iw and wpa_supplicant already have the reason code
> >> printout, and if you're diagnosing connectivity issues then you're
> >> probably using those anyway (e.g. iw event -t), so I don't really see
> >> much point in adding this to the kernel?
> >
> > FWIW I find this useful. When I have connection problems I rarely look
> > at wpasupplicant, mostly I'm so lazy that I just check from the kernel
> > log what's happening. Just my 0.02 EUR.
> 
> I would also find it useful. I assist with wireless problems on the openSUSE 
> Forum, and there we are lucky if we get dmesg output. When we do and it 
> contains 
> a deauthentication reason, I always need to bring up a web page to interpret 
> the 
> output. With this change, one step could be skipped.

But is it worth putting this parsing in the *kernel*? I mean, if anyone
is interested enough in the problem, a simple google query is not that
hard, right?

If this happens to you "on-the-fly" and all you want is your connection
to work, you won't start debugging right away.  You'll (maybe) save the
kernel logs, try to reconnect and debug later, at home.

If you think you *can* fix the problem on-the-fly, but you can't google
because the connection doesn't work, you certainly have either the IEEE
802.11 specs or the kernel sources somewhere in your device. :)

--
Luca.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] w1: refcnt fix, skip non-error send, docs

2014-02-07 Thread David Fries

On Sat, Feb 08, 2014 at 01:23:43AM +0400, z...@ioremap.net wrote:
> Hi
> 
> 07.02.2014, 10:00, "David Fries" :
> 
> > Here's a patch to implement that.  Is this what you have in mind?
> >
> > From 4ed65d81b0121a8c191a9833d041484e9097198b Mon Sep 17 00:00:00 2001
> > From: David Fries 
> > Date: Thu, 6 Feb 2014 23:45:05 -0600
> > Subject: [PATCH] w1: correct cn_msg ack, no change or seq + 1
> >
> > Netlink messages sent from the kernel consists of kernel generated
> > notifications for adds or removes, the error message (also indicates
> > the message has been processed), and the messages that have data to
> > return.  The cn_msg ack is left alone for the first two, and when
> > returning data it is the sequence number + 1.  Modifying the code to
> > the protocol standard.
> >
> > Signed-off-by: David Fries 
> 
> Yes, it looks right.
> Can you also check that protocol documentation is correct?

Documentation/connector/connector.txt ?  I found it a little unclear,
I'll see what I can do.

-- 
David Fries PGP pub CB1EE8F0
http://fries.net/~david/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernfs: skip lockdep annotation always if ignore_lockdep is set

On Fri, Feb 07, 2014 at 02:53:13PM -0500, Tejun Heo wrote:
> On Fri, Feb 07, 2014 at 09:47:01PM +0200, Imre Deak wrote:
> > We skip lockdep annotations for sysfs attributes with ignore_lockdep
> > set. An exception is kernfs_deactivate where we annotate even in this
> > case. Since the lockdep map key needed for the annotation is not
> > initialized whenever ignore_lockdep is set, we'll get a warning for
> > the uninitialized key.
> > 
> > Note that this happens since,
> > 
> > commit 517e64f57883bd63c5a4ab8b3d0d3ed68c55d0cf
> > Author: Tejun Heo 
> > Date:   Thu Nov 28 14:54:29 2013 -0500
> > 
> > Before this change we had a valid key even in case of ignore_lockdep, so
> > the annotation in kernfs_deactivate worked, or at least didn't produce
> > the above warning. Fix this by skipping the annotation whenever
> > ignore_lockdep is set.
> > 
> > The actual attribute triggering the bug was 'delete_device' in
> > drivers/i2c/i2c-core.c, for the backtrace see the reference below.
> 
> I think Greg already has about the same patch queued.
> 
>   http://lkml.kernel.org/g/20140129170403.gj30...@htj.dyndns.org

Yes, I just sent it to Linus a few minutes ago.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] Driver core fix for 3.14-rc2