[PATCH 17/31] arch,metag: Convert smp_mb__*
Implement the new barriers; as per the old versions the metag atomic
imply a full barrier.
Signed-off-by: Peter Zijlstra
---
arch/metag/include/asm/atomic.h |6 +-
arch/metag/include/asm/barrier.h |3 +++
arch/metag/include/asm/bitops.h |6 --
3 files changed, 4 insertions(+), 11 deletions(-)
--- a/arch/metag/include/asm/atomic.h
+++ b/arch/metag/include/asm/atomic.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_METAG_ATOMICITY_IRQSOFF)
/* The simple UP case. */
@@ -39,11 +40,6 @@
#define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
-#define smp_mb__before_atomic_dec()barrier()
-#define smp_mb__after_atomic_dec() barrier()
-#define smp_mb__before_atomic_inc()barrier()
-#define smp_mb__after_atomic_inc() barrier()
-
#endif
#define atomic_dec_if_positive(v) atomic_sub_if_positive(1, v)
--- a/arch/metag/include/asm/barrier.h
+++ b/arch/metag/include/asm/barrier.h
@@ -97,4 +97,7 @@ do {
\
___p1; \
})
+#define smp_mb__before_atomic()barrier()
+#define smp_mb__after_atomic() barrier()
+
#endif /* _ASM_METAG_BARRIER_H */
--- a/arch/metag/include/asm/bitops.h
+++ b/arch/metag/include/asm/bitops.h
@@ -5,12 +5,6 @@
#include
#include
-/*
- * clear_bit() doesn't provide any barrier for the compiler.
- */
-#define smp_mb__before_clear_bit() barrier()
-#define smp_mb__after_clear_bit() barrier()
-
#ifdef CONFIG_SMP
/*
* These functions are the basis of our bit ops.
--
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 27/31] arch,tile: Convert smp_mb__*
Implement the new smp_mb__* ops as per the old ones.
Signed-off-by: Peter Zijlstra
---
arch/tile/include/asm/atomic_32.h | 10 --
arch/tile/include/asm/atomic_64.h |6 --
arch/tile/include/asm/barrier.h | 14 ++
arch/tile/include/asm/bitops.h|1 +
arch/tile/include/asm/bitops_32.h |8 ++--
arch/tile/include/asm/bitops_64.h |4
6 files changed, 17 insertions(+), 26 deletions(-)
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -169,16 +169,6 @@ static inline void atomic64_set(atomic64
#define atomic64_dec_and_test(v) (atomic64_dec_return((v)) == 0)
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1LL, 0LL)
-/*
- * We need to barrier before modifying the word, since the _atomic_xxx()
- * routines just tns the lock and then read/modify/write of the word.
- * But after the word is updated, the routine issues an "mf" before returning,
- * and since it's a function call, we don't even need a compiler barrier.
- */
-#define smp_mb__before_atomic_dec()smp_mb()
-#define smp_mb__before_atomic_inc()smp_mb()
-#define smp_mb__after_atomic_dec() do { } while (0)
-#define smp_mb__after_atomic_inc() do { } while (0)
#endif /* !__ASSEMBLY__ */
--- a/arch/tile/include/asm/atomic_64.h
+++ b/arch/tile/include/asm/atomic_64.h
@@ -105,12 +105,6 @@ static inline long atomic64_add_unless(a
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
-/* Atomic dec and inc don't implement barrier, so provide them if needed. */
-#define smp_mb__before_atomic_dec()smp_mb()
-#define smp_mb__after_atomic_dec() smp_mb()
-#define smp_mb__before_atomic_inc()smp_mb()
-#define smp_mb__after_atomic_inc() smp_mb()
-
/* Define this to indicate that cmpxchg is an efficient operation. */
#define __HAVE_ARCH_CMPXCHG
--- a/arch/tile/include/asm/barrier.h
+++ b/arch/tile/include/asm/barrier.h
@@ -72,6 +72,20 @@ mb_incoherent(void)
#define mb() fast_mb()
#define iob() fast_iob()
+#ifndef __tilegx__ /* 32 bit */
+/*
+ * We need to barrier before modifying the word, since the _atomic_xxx()
+ * routines just tns the lock and then read/modify/write of the word.
+ * But after the word is updated, the routine issues an "mf" before returning,
+ * and since it's a function call, we don't even need a compiler barrier.
+ */
+#define smp_mb__before_atomic()smp_mb()
+#define smp_mb__after_atomic() do { } while (0)
+#else /* 64 bit */
+#define smp_mb__before_atomic()smp_mb()
+#define smp_mb__after_atomic() smp_mb()
+#endif
+
#include
#endif /* !__ASSEMBLY__ */
--- a/arch/tile/include/asm/bitops.h
+++ b/arch/tile/include/asm/bitops.h
@@ -17,6 +17,7 @@
#define _ASM_TILE_BITOPS_H
#include
+#include
#ifndef _LINUX_BITOPS_H
#error only can be included directly
--- a/arch/tile/include/asm/bitops_32.h
+++ b/arch/tile/include/asm/bitops_32.h
@@ -49,8 +49,8 @@ static inline void set_bit(unsigned nr,
* restricted to acting on a single-word quantity.
*
* clear_bit() may not contain a memory barrier, so if it is used for
- * locking purposes, you should call smp_mb__before_clear_bit() and/or
- * smp_mb__after_clear_bit() to ensure changes are visible on other cpus.
+ * locking purposes, you should call smp_mb__before_atomic() and/or
+ * smp_mb__after_atomic() to ensure changes are visible on other cpus.
*/
static inline void clear_bit(unsigned nr, volatile unsigned long *addr)
{
@@ -121,10 +121,6 @@ static inline int test_and_change_bit(un
return (_atomic_xor(addr, mask) & mask) != 0;
}
-/* See discussion at smp_mb__before_atomic_dec() in . */
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() do {} while (0)
-
#include
#endif /* _ASM_TILE_BITOPS_32_H */
--- a/arch/tile/include/asm/bitops_64.h
+++ b/arch/tile/include/asm/bitops_64.h
@@ -32,10 +32,6 @@ static inline void clear_bit(unsigned nr
__insn_fetchand((void *)(addr + nr / BITS_PER_LONG), ~mask);
}
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() smp_mb()
-
-
static inline void change_bit(unsigned nr, volatile unsigned long *addr)
{
unsigned long mask = (1UL << (nr % BITS_PER_LONG));
--
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 18/31] arch,mips: Convert smp_mb__*
MIPS is interesting and has hardware variants that reorder over ll/sc
as well as those that do not.
Implement the 2 new barrier functions as per the old barriers.
Signed-off-by: Peter Zijlstra
---
arch/mips/include/asm/atomic.h |9 -
arch/mips/include/asm/barrier.h |3 +++
arch/mips/include/asm/bitops.h | 11 ++-
arch/mips/kernel/irq.c |4 ++--
4 files changed, 7 insertions(+), 20 deletions(-)
--- a/arch/mips/include/asm/atomic.h
+++ b/arch/mips/include/asm/atomic.h
@@ -761,13 +761,4 @@ static __inline__ int atomic64_add_unles
#endif /* CONFIG_64BIT */
-/*
- * atomic*_return operations are serializing but not the non-*_return
- * versions.
- */
-#define smp_mb__before_atomic_dec()smp_mb__before_llsc()
-#define smp_mb__after_atomic_dec() smp_llsc_mb()
-#define smp_mb__before_atomic_inc()smp_mb__before_llsc()
-#define smp_mb__after_atomic_inc() smp_llsc_mb()
-
#endif /* _ASM_ATOMIC_H */
--- a/arch/mips/include/asm/barrier.h
+++ b/arch/mips/include/asm/barrier.h
@@ -195,4 +195,7 @@ do {
\
___p1; \
})
+#define smp_mb__before_atomic()smp_mb__before_llsc()
+#define smp_mb__after_atomic() smp_llsc_mb()
+
#endif /* __ASM_BARRIER_H */
--- a/arch/mips/include/asm/bitops.h
+++ b/arch/mips/include/asm/bitops.h
@@ -38,13 +38,6 @@
#endif
/*
- * clear_bit() doesn't provide any barrier for the compiler.
- */
-#define smp_mb__before_clear_bit() smp_mb__before_llsc()
-#define smp_mb__after_clear_bit() smp_llsc_mb()
-
-
-/*
* These are the "slower" versions of the functions and are in bitops.c.
* These functions call raw_local_irq_{save,restore}().
*/
@@ -120,7 +113,7 @@ static inline void set_bit(unsigned long
*
* clear_bit() is atomic and may not be reordered. However, it does
* not contain a memory barrier, so if it is used for locking purposes,
- * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
+ * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic()
* in order to ensure changes are visible on other processors.
*/
static inline void clear_bit(unsigned long nr, volatile unsigned long *addr)
@@ -175,7 +168,7 @@ static inline void clear_bit(unsigned lo
*/
static inline void clear_bit_unlock(unsigned long nr, volatile unsigned long
*addr)
{
- smp_mb__before_clear_bit();
+ smp_mb__before_atomic();
clear_bit(nr, addr);
}
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -62,9 +62,9 @@ void __init alloc_legacy_irqno(void)
void free_irqno(unsigned int irq)
{
- smp_mb__before_clear_bit();
+ smp_mb__before_atomic();
clear_bit(irq, irq_map);
- smp_mb__after_clear_bit();
+ smp_mb__after_atomic();
}
/*
--
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 19/31] arch,mn10300: Convert smp_mb__*
mn10300 fully relies on asm-generic/barrier.h and therefore its smp_mb() is barrier(). We can use the default implementation. Signed-off-by: Peter Zijlstra --- arch/mn10300/include/asm/atomic.h |7 +-- arch/mn10300/include/asm/bitops.h |4 +--- arch/mn10300/mm/tlb-smp.c |4 ++-- 3 files changed, 4 insertions(+), 11 deletions(-) --- a/arch/mn10300/include/asm/atomic.h +++ b/arch/mn10300/include/asm/atomic.h @@ -13,6 +13,7 @@ #include #include +#include #ifndef CONFIG_SMP #include @@ -234,12 +235,6 @@ static inline void atomic_set_mask(unsig #endif } -/* Atomic operations are already serializing on MN10300??? */ -#define smp_mb__before_atomic_dec()barrier() -#define smp_mb__after_atomic_dec() barrier() -#define smp_mb__before_atomic_inc()barrier() -#define smp_mb__after_atomic_inc() barrier() - #endif /* __KERNEL__ */ #endif /* CONFIG_SMP */ #endif /* _ASM_ATOMIC_H */ --- a/arch/mn10300/include/asm/bitops.h +++ b/arch/mn10300/include/asm/bitops.h @@ -18,9 +18,7 @@ #define __ASM_BITOPS_H #include - -#define smp_mb__before_clear_bit() barrier() -#define smp_mb__after_clear_bit() barrier() +#include /* * set bit --- a/arch/mn10300/mm/tlb-smp.c +++ b/arch/mn10300/mm/tlb-smp.c @@ -78,9 +78,9 @@ void smp_flush_tlb(void *unused) else local_flush_tlb_page(flush_mm, flush_va); - smp_mb__before_clear_bit(); + smp_mb__before_atomic(); cpumask_clear_cpu(cpu_id, &flush_cpumask); - smp_mb__after_clear_bit(); + smp_mb__after_atomic(); out: put_cpu(); } -- 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 23/31] arch,s390: Convert smp_mb__*
As per the existing implementation; implement the new one using
smp_mb().
AFAICT the s390 compare-and-swap does imply a barrier, however there
are some immediate ops that seem to be singly-copy atomic and do not
imply a barrier. One such is the "ni" op (which would be
and-immediate) which is used for the constant clear_bit
implementation. Therefore s390 needs full barriers for the
{before,after} atomic ops.
Signed-off-by: Peter Zijlstra
---
arch/s390/include/asm/atomic.h |6 +-
arch/s390/include/asm/barrier.h |5 +++--
arch/s390/include/asm/bitops.h |1 +
3 files changed, 5 insertions(+), 7 deletions(-)
--- a/arch/s390/include/asm/atomic.h
+++ b/arch/s390/include/asm/atomic.h
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#define ATOMIC_INIT(i) { (i) }
@@ -398,9 +399,4 @@ static inline long long atomic64_dec_if_
#define atomic64_dec_and_test(_v) (atomic64_sub_return(1, _v) == 0)
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
-#define smp_mb__before_atomic_dec()smp_mb()
-#define smp_mb__after_atomic_dec() smp_mb()
-#define smp_mb__before_atomic_inc()smp_mb()
-#define smp_mb__after_atomic_inc() smp_mb()
-
#endif /* __ARCH_S390_ATOMIC__ */
--- a/arch/s390/include/asm/barrier.h
+++ b/arch/s390/include/asm/barrier.h
@@ -27,8 +27,9 @@
#define smp_rmb() rmb()
#define smp_wmb() wmb()
#define smp_read_barrier_depends() read_barrier_depends()
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() smp_mb()
+
+#define smp_mb__before_atomic()smp_mb()
+#define smp_mb__after_atomic() smp_mb()
#define set_mb(var, value) do { var = value; mb(); } while (0)
--- a/arch/s390/include/asm/bitops.h
+++ b/arch/s390/include/asm/bitops.h
@@ -47,6 +47,7 @@
#include
#include
+#include
#ifndef CONFIG_64BIT
--
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 30/31] arch,doc: Convert smp_mb__*
Update the documentation to reflect the change of barrier primitives.
Signed-off-by: Peter Zijlstra
---
Documentation/atomic_ops.txt | 31 ++
Documentation/memory-barriers.txt | 44 ++
2 files changed, 24 insertions(+), 51 deletions(-)
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -285,15 +285,13 @@ If a caller requires memory barrier sema
operation which does not return a value, a set of interfaces are
defined which accomplish this:
- void smp_mb__before_atomic_dec(void);
- void smp_mb__after_atomic_dec(void);
- void smp_mb__before_atomic_inc(void);
- void smp_mb__after_atomic_inc(void);
+ void smp_mb__before_atomic(void);
+ void smp_mb__after_atomic(void);
-For example, smp_mb__before_atomic_dec() can be used like so:
+For example, smp_mb__before_atomic() can be used like so:
obj->dead = 1;
- smp_mb__before_atomic_dec();
+ smp_mb__before_atomic();
atomic_dec(&obj->ref_count);
It makes sure that all memory operations preceding the atomic_dec()
@@ -302,15 +300,10 @@ operation. In the above example, it gua
"1" to obj->dead will be globally visible to other cpus before the
atomic counter decrement.
-Without the explicit smp_mb__before_atomic_dec() call, the
+Without the explicit smp_mb__before_atomic() call, the
implementation could legally allow the atomic counter update visible
to other cpus before the "obj->dead = 1;" assignment.
-The other three interfaces listed are used to provide explicit
-ordering with respect to memory operations after an atomic_dec() call
-(smp_mb__after_atomic_dec()) and around atomic_inc() calls
-(smp_mb__{before,after}_atomic_inc()).
-
A missing memory barrier in the cases where they are required by the
atomic_t implementation above can have disastrous results. Here is
an example, which follows a pattern occurring frequently in the Linux
@@ -487,12 +480,12 @@ memory operation done by test_and_set_bi
Which returns a boolean indicating if bit "nr" is set in the bitmask
pointed to by "addr".
-If explicit memory barriers are required around clear_bit() (which
-does not return a value, and thus does not need to provide memory
-barrier semantics), two interfaces are provided:
+If explicit memory barriers are required around {set,clear}_bit() (which do
+not return a value, and thus does not need to provide memory barrier
+semantics), two interfaces are provided:
- void smp_mb__before_clear_bit(void);
- void smp_mb__after_clear_bit(void);
+ void smp_mb__before_atomic(void);
+ void smp_mb__after_atomic(void);
They are used as follows, and are akin to their atomic_t operation
brothers:
@@ -500,13 +493,13 @@ They are used as follows, and are akin t
/* All memory operations before this call will
* be globally visible before the clear_bit().
*/
- smp_mb__before_clear_bit();
+ smp_mb__before_atomic();
clear_bit( ... );
/* The clear_bit() will be visible before all
* subsequent memory operations.
*/
-smp_mb__after_clear_bit();
+smp_mb__after_atomic();
There are two special bitops with lock barrier semantics (acquire/release,
same as spinlocks). These operate in the same way as their non-_lock/unlock
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1583,20 +1583,21 @@ CPU from reordering them.
insert anything more than a compiler barrier in a UP compilation.
- (*) smp_mb__before_atomic_dec();
- (*) smp_mb__after_atomic_dec();
- (*) smp_mb__before_atomic_inc();
- (*) smp_mb__after_atomic_inc();
-
- These are for use with atomic add, subtract, increment and decrement
- functions that don't return a value, especially when used for reference
- counting. These functions do not imply memory barriers.
+ (*) smp_mb__before_atomic();
+ (*) smp_mb__after_atomic();
+
+ These are for use with atomic (such as add, subtract, increment and
+ decrement) functions that don't return a value, especially when used for
+ reference counting. These functions do not imply memory barriers.
+
+ These are also used for atomic bitop functions that do not return a
+ value (such as set_bit and clear_bit).
As an example, consider a piece of code that marks an object as being dead
and then decrements the object's reference count:
obj->dead = 1;
- smp_mb__before_atomic_dec();
+ smp_mb__before_atomic();
atomic_dec(&obj->ref_count);
This makes sure that the death mark on the object is perceived to be set
@@ -1606,27 +1607,6 @@ CPU from reordering them.
operations" subsection for information on where to use these.
- (*) smp_mb__before_clear_bit(void);
- (*) smp_mb__after_clear_bit(void);
-
- These are for use similar to the atomic inc/dec barriers. These are
- typically us
[PATCH 16/31] arch,m68k: Convert smp_mb__*
m68k uses asm-generic/barrier.h and its smp_mb() is barrier(),
therefore we can use the generic versions that use smp_mb().
Signed-off-by: Peter Zijlstra
---
arch/m68k/include/asm/atomic.h |8 +---
arch/m68k/include/asm/bitops.h |7 +--
2 files changed, 2 insertions(+), 13 deletions(-)
--- a/arch/m68k/include/asm/atomic.h
+++ b/arch/m68k/include/asm/atomic.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
/*
* Atomic operations that C can't guarantee us. Useful for
@@ -209,11 +210,4 @@ static __inline__ int __atomic_add_unles
return c;
}
-
-/* Atomic operations are already serializing */
-#define smp_mb__before_atomic_dec()barrier()
-#define smp_mb__after_atomic_dec() barrier()
-#define smp_mb__before_atomic_inc()barrier()
-#define smp_mb__after_atomic_inc() barrier()
-
#endif /* __ARCH_M68K_ATOMIC __ */
--- a/arch/m68k/include/asm/bitops.h
+++ b/arch/m68k/include/asm/bitops.h
@@ -13,6 +13,7 @@
#endif
#include
+#include
/*
* Bit access functions vary across the ColdFire and 68k families.
@@ -67,12 +68,6 @@ static inline void bfset_mem_set_bit(int
#define __set_bit(nr, vaddr) set_bit(nr, vaddr)
-/*
- * clear_bit() doesn't provide any barrier for the compiler.
- */
-#define smp_mb__before_clear_bit() barrier()
-#define smp_mb__after_clear_bit() barrier()
-
static inline void bclr_reg_clear_bit(int nr, volatile unsigned long *vaddr)
{
char *p = (char *)vaddr + (nr ^ 31) / 8;
--
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/31] arch,arc: Convert smp_mb__*
The arc mb() implementation is a compiler barrier(), therefore it all doesn't matter one way or the other. Simply remove the existing definitions and use whatever is generated by the defaults. Signed-off-by: Peter Zijlstra --- arch/arc/include/asm/atomic.h |5 - arch/arc/include/asm/bitops.h |5 + 2 files changed, 1 insertion(+), 9 deletions(-) --- a/arch/arc/include/asm/atomic.h +++ b/arch/arc/include/asm/atomic.h @@ -190,11 +190,6 @@ static inline void atomic_clear_mask(uns #endif /* !CONFIG_ARC_HAS_LLSC */ -#define smp_mb__before_atomic_dec()barrier() -#define smp_mb__after_atomic_dec() barrier() -#define smp_mb__before_atomic_inc()barrier() -#define smp_mb__after_atomic_inc() barrier() - /** * __atomic_add_unless - add unless the number is a given value * @v: pointer of type atomic_t --- a/arch/arc/include/asm/bitops.h +++ b/arch/arc/include/asm/bitops.h @@ -19,6 +19,7 @@ #include #include +#include /* * Hardware assisted read-modify-write using ARC700 LLOCK/SCOND insns. @@ -496,10 +497,6 @@ static inline __attribute__ ((const)) in */ #define ffz(x) __ffs(~(x)) -/* TODO does this affect uni-processor code */ -#define smp_mb__before_clear_bit() barrier() -#define smp_mb__after_clear_bit() barrier() - #include #include #include -- 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 15/31] arch,m32r: Convert smp_mb__*
M32r uses asm-generic/barrier.h and its smp_mb() is barrier(); therefore we can use the generic versions which default to smp_mb(). Signed-off-by: Peter Zijlstra --- arch/m32r/include/asm/atomic.h |7 +-- arch/m32r/include/asm/bitops.h |6 ++ 2 files changed, 3 insertions(+), 10 deletions(-) --- a/arch/m32r/include/asm/atomic.h +++ b/arch/m32r/include/asm/atomic.h @@ -13,6 +13,7 @@ #include #include #include +#include /* * Atomic operations that C can't guarantee us. Useful for @@ -308,10 +309,4 @@ static __inline__ void atomic_set_mask(u local_irq_restore(flags); } -/* Atomic operations are already serializing on m32r */ -#define smp_mb__before_atomic_dec()barrier() -#define smp_mb__after_atomic_dec() barrier() -#define smp_mb__before_atomic_inc()barrier() -#define smp_mb__after_atomic_inc() barrier() - #endif /* _ASM_M32R_ATOMIC_H */ --- a/arch/m32r/include/asm/bitops.h +++ b/arch/m32r/include/asm/bitops.h @@ -21,6 +21,7 @@ #include #include #include +#include /* * These have to be done with inline assembly: that way the bit-setting @@ -73,7 +74,7 @@ static __inline__ void set_bit(int nr, v * * clear_bit() is atomic and may not be reordered. However, it does * not contain a memory barrier, so if it is used for locking purposes, - * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit() + * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic() * in order to ensure changes are visible on other processors. */ static __inline__ void clear_bit(int nr, volatile void * addr) @@ -103,9 +104,6 @@ static __inline__ void clear_bit(int nr, local_irq_restore(flags); } -#define smp_mb__before_clear_bit() barrier() -#define smp_mb__after_clear_bit() barrier() - /** * change_bit - Toggle a bit in memory * @nr: Bit to clear -- 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 26/31] arch,sparc: Convert smp_mb__*
sparc32: fully relies on asm-generic/barrier.h and thus can use its
implementation.
sparc64: is strongly ordered and its atomic ops imply a full barrier,
implement the new primitives using barrier().
Signed-off-by: Peter Zijlstra
---
arch/sparc/include/asm/atomic_32.h |7 +--
arch/sparc/include/asm/atomic_64.h |7 +--
arch/sparc/include/asm/barrier_64.h |3 +++
arch/sparc/include/asm/bitops_32.h |3 ---
arch/sparc/include/asm/bitops_64.h |4 +---
5 files changed, 6 insertions(+), 18 deletions(-)
--- a/arch/sparc/include/asm/atomic_32.h
+++ b/arch/sparc/include/asm/atomic_32.h
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
@@ -52,10 +53,4 @@ extern void atomic_set(atomic_t *, int);
#define atomic_dec_and_test(v) (atomic_dec_return(v) == 0)
#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
-/* Atomic operations are already serializing */
-#define smp_mb__before_atomic_dec()barrier()
-#define smp_mb__after_atomic_dec() barrier()
-#define smp_mb__before_atomic_inc()barrier()
-#define smp_mb__after_atomic_inc() barrier()
-
#endif /* !(__ARCH_SPARC_ATOMIC__) */
--- a/arch/sparc/include/asm/atomic_64.h
+++ b/arch/sparc/include/asm/atomic_64.h
@@ -9,6 +9,7 @@
#include
#include
+#include
#define ATOMIC_INIT(i) { (i) }
#define ATOMIC64_INIT(i) { (i) }
@@ -108,10 +109,4 @@ static inline long atomic64_add_unless(a
extern long atomic64_dec_if_positive(atomic64_t *v);
-/* Atomic operations are already serializing */
-#define smp_mb__before_atomic_dec()barrier()
-#define smp_mb__after_atomic_dec() barrier()
-#define smp_mb__before_atomic_inc()barrier()
-#define smp_mb__after_atomic_inc() barrier()
-
#endif /* !(__ARCH_SPARC64_ATOMIC__) */
--- a/arch/sparc/include/asm/barrier_64.h
+++ b/arch/sparc/include/asm/barrier_64.h
@@ -68,4 +68,7 @@ do {
\
___p1; \
})
+#define smp_mb__before_atomic()barrier()
+#define smp_mb__after_atomic() barrier()
+
#endif /* !(__SPARC64_BARRIER_H) */
--- a/arch/sparc/include/asm/bitops_32.h
+++ b/arch/sparc/include/asm/bitops_32.h
@@ -90,9 +90,6 @@ static inline void change_bit(unsigned l
#include
-#define smp_mb__before_clear_bit() do { } while(0)
-#define smp_mb__after_clear_bit() do { } while(0)
-
#include
#include
#include
--- a/arch/sparc/include/asm/bitops_64.h
+++ b/arch/sparc/include/asm/bitops_64.h
@@ -13,6 +13,7 @@
#include
#include
+#include
extern int test_and_set_bit(unsigned long nr, volatile unsigned long *addr);
extern int test_and_clear_bit(unsigned long nr, volatile unsigned long *addr);
@@ -23,9 +24,6 @@ extern void change_bit(unsigned long nr,
#include
-#define smp_mb__before_clear_bit() barrier()
-#define smp_mb__after_clear_bit() barrier()
-
#include
#include
#include
--
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 29/31] arch,xtensa: Convert smp_mb__*
Xtensa SMP has ll/sc which is fully serializing, therefore its exising
smp_mb__{before,after}_clear_bit() appear unduly heavy.
Implement the new barriers are barrier().
Signed-off-by: Peter Zijlstra
---
arch/xtensa/include/asm/atomic.h |7 +--
arch/xtensa/include/asm/barrier.h |3 +++
arch/xtensa/include/asm/bitops.h |4 +---
3 files changed, 5 insertions(+), 9 deletions(-)
--- a/arch/xtensa/include/asm/atomic.h
+++ b/arch/xtensa/include/asm/atomic.h
@@ -19,6 +19,7 @@
#ifdef __KERNEL__
#include
#include
+#include
#define ATOMIC_INIT(i) { (i) }
@@ -387,12 +388,6 @@ static inline void atomic_set_mask(unsig
#endif
}
-/* Atomic operations are already serializing */
-#define smp_mb__before_atomic_dec()barrier()
-#define smp_mb__after_atomic_dec() barrier()
-#define smp_mb__before_atomic_inc()barrier()
-#define smp_mb__after_atomic_inc() barrier()
-
#endif /* __KERNEL__ */
#endif /* _XTENSA_ATOMIC_H */
--- a/arch/xtensa/include/asm/barrier.h
+++ b/arch/xtensa/include/asm/barrier.h
@@ -13,6 +13,9 @@
#define rmb() barrier()
#define wmb() mb()
+#define smp_mb__before_atomic()barrier()
+#define smp_mb__after_atomic() barrier()
+
#include
#endif /* _XTENSA_SYSTEM_H */
--- a/arch/xtensa/include/asm/bitops.h
+++ b/arch/xtensa/include/asm/bitops.h
@@ -21,9 +21,7 @@
#include
#include
-
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() smp_mb()
+#include
#include
--
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/31] arch: Prepare for smp_mb__{before,after}_atomic()
Since the smp_mb__{before,after}*() ops are fundamentally dependent on
how an arch can implement atomics it doesn't make sense to have 3
variants of them. They must all be the same.
Furthermore, the 3 variants suggest they're only valid for those 3
atomic ops, while we have many more where they could be applied.
So move away from
smp_mb__{before,after}_{atomic,clear}_{dec,inc,bit}() and reduce the
interface to just the two: smp_mb__{before,after}_atomic().
This patch prepares the way by introducing default implementations in
asm-generic/barrier.h that default to a full barrier and providing
__deprecated inlines for the previous 6 barriers if they're not
provided by the arch.
This should allow for a mostly painless transition (lots of deprecated
warns in the interim).
Signed-off-by: Peter Zijlstra
---
include/asm-generic/atomic.h |7 +--
include/asm-generic/barrier.h |8
include/asm-generic/bitops.h |9 +
include/linux/atomic.h| 36
include/linux/bitops.h| 20
kernel/sched/core.c | 16
6 files changed, 82 insertions(+), 14 deletions(-)
--- a/include/asm-generic/atomic.h
+++ b/include/asm-generic/atomic.h
@@ -16,6 +16,7 @@
#define __ASM_GENERIC_ATOMIC_H
#include
+#include
#ifdef CONFIG_SMP
/* Force people to define core atomics */
@@ -182,11 +183,5 @@ static inline void atomic_set_mask(unsig
}
#endif
-/* Assume that atomic operations are already serializing */
-#define smp_mb__before_atomic_dec()barrier()
-#define smp_mb__after_atomic_dec() barrier()
-#define smp_mb__before_atomic_inc()barrier()
-#define smp_mb__after_atomic_inc() barrier()
-
#endif /* __KERNEL__ */
#endif /* __ASM_GENERIC_ATOMIC_H */
--- a/include/asm-generic/barrier.h
+++ b/include/asm-generic/barrier.h
@@ -62,6 +62,14 @@
#define set_mb(var, value) do { (var) = (value); mb(); } while (0)
#endif
+#ifndef smp_mb__before_atomic
+#define smp_mb__before_atomic()smp_mb()
+#endif
+
+#ifndef smp_mb__after_atomic
+#define smp_mb__after_atomic() smp_mb()
+#endif
+
#define smp_store_release(p, v)
\
do { \
compiletime_assert_atomic_type(*p); \
--- a/include/asm-generic/bitops.h
+++ b/include/asm-generic/bitops.h
@@ -11,14 +11,7 @@
#include
#include
-
-/*
- * clear_bit may not imply a memory barrier
- */
-#ifndef smp_mb__before_clear_bit
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() smp_mb()
-#endif
+#include
#include
#include
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -3,6 +3,42 @@
#define _LINUX_ATOMIC_H
#include
+/*
+ * Provide __deprecated wrappers for the new interface, avoid flag day changes.
+ * We need the ugly external functions to break header recursion hell.
+ */
+#ifndef smp_mb__before_atomic_inc
+static inline void __deprecated smp_mb__before_atomic_inc(void)
+{
+ extern void __smp_mb__before_atomic(void);
+ __smp_mb__before_atomic();
+}
+#endif
+
+#ifndef smp_mb__after_atomic_inc
+static inline void __deprecated smp_mb__after_atomic_inc(void)
+{
+ extern void __smp_mb__after_atomic(void);
+ __smp_mb__after_atomic();
+}
+#endif
+
+#ifndef smp_mb__before_atomic_dec
+static inline void __deprecated smp_mb__before_atomic_dec(void)
+{
+ extern void __smp_mb__before_atomic(void);
+ __smp_mb__before_atomic();
+}
+#endif
+
+#ifndef smp_mb__after_atomic_dec
+static inline void __deprecated smp_mb__after_atomic_dec(void)
+{
+ extern void __smp_mb__after_atomic(void);
+ __smp_mb__after_atomic();
+}
+#endif
+
/**
* atomic_add_unless - add unless the number is already a given value
* @v: pointer of type atomic_t
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -32,6 +32,26 @@ extern unsigned long __sw_hweight64(__u6
*/
#include
+/*
+ * Provide __deprecated wrappers for the new interface, avoid flag day changes.
+ * We need the ugly external functions to break header recursion hell.
+ */
+#ifndef smp_mb__before_clear_bit
+static inline void __deprecated smp_mb__before_clear_bit(void)
+{
+ extern void __smp_mb__before_atomic(void);
+ __smp_mb__before_atomic();
+}
+#endif
+
+#ifndef smp_mb__after_clear_bit
+static inline void __deprecated smp_mb__after_clear_bit(void)
+{
+ extern void __smp_mb__after_atomic(void);
+ __smp_mb__after_atomic();
+}
+#endif
+
#define for_each_set_bit(bit, addr, size) \
for ((bit) = find_first_bit((addr), (size));\
(bit) < (size);\
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -89,6 +89,22 @@
#define CREATE_TRACE_POINTS
#include
+#ifdef smp_mb__before_atomic
+void __smp_mb__before_atomic(void)
+{
+ smp_mb__before_atomic();
+}
+
[PATCH 22/31] arch,powerpc: Convert smp_mb__*
Powerpc allows reordering over its ll/sc implementation. Implement the
two new barriers as appropriate.
Signed-off-by: Peter Zijlstra
---
arch/powerpc/include/asm/atomic.h |6 +-
arch/powerpc/include/asm/barrier.h |3 +++
arch/powerpc/include/asm/bitops.h |6 +-
arch/powerpc/kernel/crash.c|2 +-
4 files changed, 6 insertions(+), 11 deletions(-)
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -8,6 +8,7 @@
#ifdef __KERNEL__
#include
#include
+#include
#define ATOMIC_INIT(i) { (i) }
@@ -270,11 +271,6 @@ static __inline__ int atomic_dec_if_posi
}
#define atomic_dec_if_positive atomic_dec_if_positive
-#define smp_mb__before_atomic_dec() smp_mb()
-#define smp_mb__after_atomic_dec() smp_mb()
-#define smp_mb__before_atomic_inc() smp_mb()
-#define smp_mb__after_atomic_inc() smp_mb()
-
#ifdef __powerpc64__
#define ATOMIC64_INIT(i) { (i) }
--- a/arch/powerpc/include/asm/barrier.h
+++ b/arch/powerpc/include/asm/barrier.h
@@ -84,4 +84,7 @@ do {
\
___p1; \
})
+#define smp_mb__before_atomic() smp_mb()
+#define smp_mb__after_atomic() smp_mb()
+
#endif /* _ASM_POWERPC_BARRIER_H */
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -51,11 +51,7 @@
#define PPC_BIT(bit) (1UL << PPC_BITLSHIFT(bit))
#define PPC_BITMASK(bs, be)((PPC_BIT(bs) - PPC_BIT(be)) | PPC_BIT(bs))
-/*
- * clear_bit doesn't imply a memory barrier
- */
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() smp_mb()
+#include
/* Macro for generating the ***_bits() functions */
#define DEFINE_BITOP(fn, op, prefix) \
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -81,7 +81,7 @@ void crash_ipi_callback(struct pt_regs *
}
atomic_inc(&cpus_in_crash);
- smp_mb__after_atomic_inc();
+ smp_mb__after_atomic();
/*
* Starting the kdump boot.
--
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 21/31] arch,parisc: Convert smp_mb__*
parisc fully relies on asm-generic/barrier.h, therefore its smp_mb()
is barrier and the default implementation suffices.
Signed-off-by: Peter Zijlstra
---
arch/parisc/include/asm/atomic.h |6 +-
arch/parisc/include/asm/bitops.h |4 +---
2 files changed, 2 insertions(+), 8 deletions(-)
--- a/arch/parisc/include/asm/atomic.h
+++ b/arch/parisc/include/asm/atomic.h
@@ -7,6 +7,7 @@
#include
#include
+#include
/*
* Atomic operations that C can't guarantee us. Useful for
@@ -143,11 +144,6 @@ static __inline__ int __atomic_add_unles
#define ATOMIC_INIT(i) { (i) }
-#define smp_mb__before_atomic_dec()smp_mb()
-#define smp_mb__after_atomic_dec() smp_mb()
-#define smp_mb__before_atomic_inc()smp_mb()
-#define smp_mb__after_atomic_inc() smp_mb()
-
#ifdef CONFIG_64BIT
#define ATOMIC64_INIT(i) { (i) }
--- a/arch/parisc/include/asm/bitops.h
+++ b/arch/parisc/include/asm/bitops.h
@@ -8,6 +8,7 @@
#include
#include /* for BITS_PER_LONG/SHIFT_PER_LONG */
#include
+#include
#include
/*
@@ -19,9 +20,6 @@
#define CHOP_SHIFTCOUNT(x) (((unsigned long) (x)) & (BITS_PER_LONG - 1))
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() smp_mb()
-
/* See http://marc.theaimsgroup.com/?t=10882663793 for discussion
* on use of volatile and __*_bit() (set/clear/change):
* *_bit() want use of volatile.
--
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 24/31] arch,score: Convert smp_mb__*
score fully relies on asm-generic/barrier.h, so it can use its default implementation. Signed-off-by: Peter Zijlstra --- arch/score/include/asm/bitops.h |7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) --- a/arch/score/include/asm/bitops.h +++ b/arch/score/include/asm/bitops.h @@ -2,12 +2,7 @@ #define _ASM_SCORE_BITOPS_H #include /* swab32 */ - -/* - * clear_bit() doesn't provide any barrier for the compiler. - */ -#define smp_mb__before_clear_bit() barrier() -#define smp_mb__after_clear_bit() barrier() +#include #include #include -- 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 28/31] arch, x86: Convert smp_mb__*
x86 is strongly ordered and all its atomic ops imply a full barrier.
Implement the two new primitives as the old ones were.
Signed-off-by: Peter Zijlstra
---
arch/x86/include/asm/atomic.h |7 +--
arch/x86/include/asm/barrier.h |4
arch/x86/include/asm/bitops.h |6 ++
arch/x86/include/asm/sync_bitops.h |2 +-
arch/x86/kernel/apic/hw_nmi.c |2 +-
5 files changed, 9 insertions(+), 12 deletions(-)
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
/*
* Atomic operations that C can't guarantee us. Useful for
@@ -256,12 +257,6 @@ static inline void atomic_or_long(unsign
: : "r" ((unsigned)(mask)), "m" (*(addr)) \
: "memory")
-/* Atomic operations are already serializing on x86 */
-#define smp_mb__before_atomic_dec()barrier()
-#define smp_mb__after_atomic_dec() barrier()
-#define smp_mb__before_atomic_inc()barrier()
-#define smp_mb__after_atomic_inc() barrier()
-
#ifdef CONFIG_X86_32
# include
#else
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -141,6 +141,10 @@ do {
\
#endif
+/* Atomic operations are already serializing on x86 */
+#define smp_mb__before_atomic()barrier()
+#define smp_mb__after_atomic() barrier()
+
/*
* Stop RDTSC speculation. This is needed when you need to use RDTSC
* (or get_cycles or vread that possibly accesses the TSC) in a defined
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#if BITS_PER_LONG == 32
# define _BITOPS_LONG_SHIFT 5
@@ -102,7 +103,7 @@ static inline void __set_bit(long nr, vo
*
* clear_bit() is atomic and may not be reordered. However, it does
* not contain a memory barrier, so if it is used for locking purposes,
- * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
+ * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic()
* in order to ensure changes are visible on other processors.
*/
static __always_inline void
@@ -156,9 +157,6 @@ static inline void __clear_bit_unlock(lo
__clear_bit(nr, addr);
}
-#define smp_mb__before_clear_bit() barrier()
-#define smp_mb__after_clear_bit() barrier()
-
/**
* __change_bit - Toggle a bit in memory
* @nr: the bit to change
--- a/arch/x86/include/asm/sync_bitops.h
+++ b/arch/x86/include/asm/sync_bitops.h
@@ -41,7 +41,7 @@ static inline void sync_set_bit(long nr,
*
* sync_clear_bit() is atomic and may not be reordered. However, it does
* not contain a memory barrier, so if it is used for locking purposes,
- * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
+ * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic()
* in order to ensure changes are visible on other processors.
*/
static inline void sync_clear_bit(long nr, volatile unsigned long *addr)
--- a/arch/x86/kernel/apic/hw_nmi.c
+++ b/arch/x86/kernel/apic/hw_nmi.c
@@ -57,7 +57,7 @@ void arch_trigger_all_cpu_backtrace(void
}
clear_bit(0, &backtrace_flag);
- smp_mb__after_clear_bit();
+ smp_mb__after_atomic();
}
static int __kprobes
--
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/31] arch,arm64: Convert smp_mb__*
AARGH64 uses ll/sc primitives that do not imply any barriers for the
normal atomics, therefore smp_mb__{before,after} should be a full
barrier.
Since AARGH64 doesn't use asm-generic/barrier.h, add the required
definitions to its asm/barrier.h.
Signed-off-by: Peter Zijlstra
---
arch/arm64/include/asm/atomic.h |5 -
arch/arm64/include/asm/barrier.h |3 +++
arch/arm64/include/asm/bitops.h |9 -
3 files changed, 3 insertions(+), 14 deletions(-)
--- a/arch/arm64/include/asm/atomic.h
+++ b/arch/arm64/include/asm/atomic.h
@@ -152,11 +152,6 @@ static inline int __atomic_add_unless(at
#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
-#define smp_mb__before_atomic_dec()smp_mb()
-#define smp_mb__after_atomic_dec() smp_mb()
-#define smp_mb__before_atomic_inc()smp_mb()
-#define smp_mb__after_atomic_inc() smp_mb()
-
/*
* 64-bit atomic operations.
*/
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -97,6 +97,9 @@ do {
\
#define set_mb(var, value) do { var = value; smp_mb(); } while (0)
#define nop() asm volatile("nop");
+#define smp_mb__before_atomic()smp_mb()
+#define smp_mb__after_atomic() smp_mb()
+
#endif /* __ASSEMBLY__ */
#endif /* __ASM_BARRIER_H */
--- a/arch/arm64/include/asm/bitops.h
+++ b/arch/arm64/include/asm/bitops.h
@@ -17,17 +17,8 @@
#define __ASM_BITOPS_H
#include
-
#include
-/*
- * clear_bit may not imply a memory barrier
- */
-#ifndef smp_mb__before_clear_bit
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() smp_mb()
-#endif
-
#ifndef _LINUX_BITOPS_H
#error only can be included directly
#endif
--
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/31] arch,c6x: Convert smp_mb__*
c6x doesn't have a barrier.h and completely relies on asm-generic/barrier.h. Therefore its smp_mb() is barrier() and we can use the default versions that are smp_mb(). Signed-off-by: Peter Zijlstra --- arch/c6x/include/asm/bitops.h |8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) --- a/arch/c6x/include/asm/bitops.h +++ b/arch/c6x/include/asm/bitops.h @@ -14,14 +14,8 @@ #ifdef __KERNEL__ #include - #include - -/* - * clear_bit() doesn't provide any barrier for the compiler. - */ -#define smp_mb__before_clear_bit() barrier() -#define smp_mb__after_clear_bit() barrier() +#include /* * We are lucky, DSP is perfect for bitops: do it in 3 cycles -- 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/31] arch,ia64: Convert smp_mb__*
ia64 atomic ops are full barriers; implement the new
smp_mb__{before,after}_atomic().
Signed-off-by: Peter Zijlstra
---
arch/ia64/include/asm/atomic.h |7 +--
arch/ia64/include/asm/barrier.h |3 +++
arch/ia64/include/asm/bitops.h |6 ++
3 files changed, 6 insertions(+), 10 deletions(-)
--- a/arch/ia64/include/asm/atomic.h
+++ b/arch/ia64/include/asm/atomic.h
@@ -15,6 +15,7 @@
#include
#include
+#include
#define ATOMIC_INIT(i) { (i) }
@@ -208,10 +209,4 @@ atomic64_add_negative (__s64 i, atomic64
#define atomic64_inc(v)atomic64_add(1, (v))
#define atomic64_dec(v)atomic64_sub(1, (v))
-/* Atomic operations are already serializing */
-#define smp_mb__before_atomic_dec()barrier()
-#define smp_mb__after_atomic_dec() barrier()
-#define smp_mb__before_atomic_inc()barrier()
-#define smp_mb__after_atomic_inc() barrier()
-
#endif /* _ASM_IA64_ATOMIC_H */
--- a/arch/ia64/include/asm/barrier.h
+++ b/arch/ia64/include/asm/barrier.h
@@ -55,6 +55,9 @@
#endif
+#define smp_mb__before_atomic()barrier()
+#define smp_mb__after_atomic() barrier()
+
/*
* IA64 GCC turns volatile stores into st.rel and volatile loads into ld.acq no
* need for asm trickery!
--- a/arch/ia64/include/asm/bitops.h
+++ b/arch/ia64/include/asm/bitops.h
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
/**
* set_bit - Atomically set a bit in memory
@@ -65,9 +66,6 @@ __set_bit (int nr, volatile void *addr)
*((__u32 *) addr + (nr >> 5)) |= (1 << (nr & 31));
}
-#define smp_mb__before_clear_bit() barrier();
-#define smp_mb__after_clear_bit() barrier();
-
/**
* clear_bit - Clears a bit in memory
* @nr: Bit to clear
@@ -75,7 +73,7 @@ __set_bit (int nr, volatile void *addr)
*
* clear_bit() is atomic and may not be reordered. However, it does
* not contain a memory barrier, so if it is used for locking purposes,
- * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
+ * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic()
* in order to ensure changes are visible on other processors.
*/
static __inline__ void
--
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/31] arch,blackfin: Convert smp_mb__*
Blackfin's atomic primitives do not imply a full barrier as whitnessed
from its SMP smp_mb__{before,after}_clear_bit() implementations.
However since !SMP smp_mb() reduces to barrier() remove everything and
rely on the asm-generic/barrier.h implentation.
Signed-off-by: Peter Zijlstra
---
arch/blackfin/include/asm/barrier.h |3 +++
arch/blackfin/include/asm/bitops.h | 14 ++
2 files changed, 5 insertions(+), 12 deletions(-)
--- a/arch/blackfin/include/asm/barrier.h
+++ b/arch/blackfin/include/asm/barrier.h
@@ -27,6 +27,9 @@
#endif /* !CONFIG_SMP */
+#define smp_mb__before_atomic()barrier()
+#define smp_mb__after_atomic() barrier()
+
#include
#endif /* _BLACKFIN_BARRIER_H */
--- a/arch/blackfin/include/asm/bitops.h
+++ b/arch/blackfin/include/asm/bitops.h
@@ -27,21 +27,17 @@
#include
+#include
+
#ifndef CONFIG_SMP
#include
-
/*
* clear_bit may not imply a memory barrier
*/
-#ifndef smp_mb__before_clear_bit
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() smp_mb()
-#endif
#include
#include
#else
-#include
#include /* swab32 */
#include
@@ -101,12 +97,6 @@ static inline int test_and_change_bit(in
return __raw_bit_test_toggle_asm(a, nr & 0x1f);
}
-/*
- * clear_bit() doesn't provide any barrier for the compiler.
- */
-#define smp_mb__before_clear_bit() barrier()
-#define smp_mb__after_clear_bit() barrier()
-
#define test_bit __skip_test_bit
#include
#undef test_bit
--
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 25/31] arch,sh: Convert smp_mb__*
SH can use the asm-generic/barrier.h implementation since that uses
smp_mb().
Signed-off-by: Peter Zijlstra
---
arch/sh/include/asm/atomic.h |6 +-
arch/sh/include/asm/bitops.h |7 +--
2 files changed, 2 insertions(+), 11 deletions(-)
--- a/arch/sh/include/asm/atomic.h
+++ b/arch/sh/include/asm/atomic.h
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#define ATOMIC_INIT(i) { (i) }
@@ -62,9 +63,4 @@ static inline int __atomic_add_unless(at
return c;
}
-#define smp_mb__before_atomic_dec()smp_mb()
-#define smp_mb__after_atomic_dec() smp_mb()
-#define smp_mb__before_atomic_inc()smp_mb()
-#define smp_mb__after_atomic_inc() smp_mb()
-
#endif /* __ASM_SH_ATOMIC_H */
--- a/arch/sh/include/asm/bitops.h
+++ b/arch/sh/include/asm/bitops.h
@@ -9,6 +9,7 @@
/* For __swab32 */
#include
+#include
#ifdef CONFIG_GUSA_RB
#include
@@ -22,12 +23,6 @@
#include
#endif
-/*
- * clear_bit() doesn't provide any barrier for the compiler.
- */
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() smp_mb()
-
#ifdef CONFIG_SUPERH32
static inline unsigned long ffz(unsigned long word)
{
--
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/31] arch,arm: Convert smp_mb__*
ARM uses ll/sc primitives that do not imply barriers for all regular
atomic ops, therefore smp_mb__{before,after} need be a full barrier.
Since ARM doesn't use asm-generic/barrier.h include the required
definitions in its asm/barrier.h
Signed-off-by: Peter Zijlstra
---
arch/arm/include/asm/atomic.h |5 -
arch/arm/include/asm/barrier.h |3 +++
arch/arm/include/asm/bitops.h |4 +---
3 files changed, 4 insertions(+), 8 deletions(-)
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -211,11 +211,6 @@ static inline int __atomic_add_unless(at
#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
-#define smp_mb__before_atomic_dec()smp_mb()
-#define smp_mb__after_atomic_dec() smp_mb()
-#define smp_mb__before_atomic_inc()smp_mb()
-#define smp_mb__after_atomic_inc() smp_mb()
-
#ifndef CONFIG_GENERIC_ATOMIC64
typedef struct {
long long counter;
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -79,5 +79,8 @@ do {
\
#define set_mb(var, value) do { var = value; smp_mb(); } while (0)
+#define smp_mb__before_atomic()smp_mb()
+#define smp_mb__after_atomic() smp_mb()
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_BARRIER_H */
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -25,9 +25,7 @@
#include
#include
-
-#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() smp_mb()
+#include
/*
* These functions are the basis of our bit ops.
--
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/31] arch,cris: Convert smp_mb__*
Cris fully relies on asm-generic/barrier.h, therefore its smp_mb() is barrier(), thus we can use the default implementation that uses smp_mb(). Signed-off-by: Peter Zijlstra --- arch/cris/include/asm/atomic.h |7 +-- arch/cris/include/asm/bitops.h |9 ++--- 2 files changed, 3 insertions(+), 13 deletions(-) --- a/arch/cris/include/asm/atomic.h +++ b/arch/cris/include/asm/atomic.h @@ -6,6 +6,7 @@ #include #include #include +#include #include /* @@ -151,10 +152,4 @@ static inline int __atomic_add_unless(at return ret; } -/* Atomic operations are already serializing */ -#define smp_mb__before_atomic_dec()barrier() -#define smp_mb__after_atomic_dec() barrier() -#define smp_mb__before_atomic_inc()barrier() -#define smp_mb__after_atomic_inc() barrier() - #endif --- a/arch/cris/include/asm/bitops.h +++ b/arch/cris/include/asm/bitops.h @@ -21,6 +21,7 @@ #include #include #include +#include /* * set_bit - Atomically set a bit in memory @@ -42,7 +43,7 @@ * * clear_bit() is atomic and may not be reordered. However, it does * not contain a memory barrier, so if it is used for locking purposes, - * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit() + * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic() * in order to ensure changes are visible on other processors. */ @@ -84,12 +85,6 @@ static inline int test_and_set_bit(int n return retval; } -/* - * clear_bit() doesn't provide any barrier for the compiler. - */ -#define smp_mb__before_clear_bit() barrier() -#define smp_mb__after_clear_bit() barrier() - /** * test_and_clear_bit - Clear a bit and return its old value * @nr: Bit to clear -- 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 20/31] arch,openrisc: Convert smp_mb__*
Openrisc fully relies on asm-generic/barrier.h and therefore its smp_mb() is barrier(). Signed-off-by: Peter Zijlstra --- arch/openrisc/include/asm/bitops.h |9 + 1 file changed, 1 insertion(+), 8 deletions(-) --- a/arch/openrisc/include/asm/bitops.h +++ b/arch/openrisc/include/asm/bitops.h @@ -27,14 +27,7 @@ #include #include - -/* - * clear_bit may not imply a memory barrier - */ -#ifndef smp_mb__before_clear_bit -#define smp_mb__before_clear_bit() smp_mb() -#define smp_mb__after_clear_bit() smp_mb() -#endif +#include #include #include -- 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/31] arc,hexagon: Delete asm/barrier.h
Both already use asm-generic/barrier.h as per their
include/asm/Kbuild. Remove the stale files.
Signed-off-by: Peter Zijlstra
---
arch/arc/include/asm/barrier.h | 37 -
arch/hexagon/include/asm/barrier.h | 37 -
2 files changed, 74 deletions(-)
--- a/arch/arc/include/asm/barrier.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
- *
- * 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.
- */
-
-#ifndef __ASM_BARRIER_H
-#define __ASM_BARRIER_H
-
-#ifndef __ASSEMBLY__
-
-/* TODO-vineetg: Need to see what this does, don't we need sync anywhere */
-#define mb() __asm__ __volatile__ ("" : : : "memory")
-#define rmb() mb()
-#define wmb() mb()
-#define set_mb(var, value) do { var = value; mb(); } while (0)
-#define set_wmb(var, value) do { var = value; wmb(); } while (0)
-#define read_barrier_depends() mb()
-
-/* TODO-vineetg verify the correctness of macros here */
-#ifdef CONFIG_SMP
-#define smp_mb()mb()
-#define smp_rmb() rmb()
-#define smp_wmb() wmb()
-#else
-#define smp_mb()barrier()
-#define smp_rmb() barrier()
-#define smp_wmb() barrier()
-#endif
-
-#define smp_read_barrier_depends() do { } while (0)
-
-#endif
-
-#endif
--- a/arch/hexagon/include/asm/barrier.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Memory barrier definitions for the Hexagon architecture
- *
- * Copyright (c) 2010-2011, 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.
- *
- * 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 Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
- */
-
-#ifndef _ASM_BARRIER_H
-#define _ASM_BARRIER_H
-
-#define rmb() barrier()
-#define read_barrier_depends() barrier()
-#define wmb() barrier()
-#define mb() barrier()
-#define smp_rmb() barrier()
-#define smp_read_barrier_depends() barrier()
-#define smp_wmb() barrier()
-#define smp_mb() barrier()
-
-/* Set a value and use a memory barrier. Used by the scheduler somewhere. */
-#define set_mb(var, value) \
- do { var = value; mb(); } while (0)
-
-#endif /* _ASM_BARRIER_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: [GIT PULL 00/13] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > The following changes since commit 0afd2d51029961281572d02545c7bde1b3f4292c: > > Merge tag 'perf-core-for-mingo' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > (2014-03-18 09:23:09 +0100) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > tags/perf-core-for-mingo > > for you to fetch changes up to a51e87cb5a0fbebee15a3373d951dbf6f59a76c2: > > perf tools: Remove unused simple_strtoul() function (2014-03-18 18:17:07 > -0300) > > > perf/core improvements and fixes: > > User visible: > > . Fixup header alignment in 'perf sched latency' output (Ramkumar Ramachandra) > > . Fix off-by-one error in 'perf timechart record' argv handling (Ramkumar > Ramachandra) > > . Print the evsel name in the annotate stdio output, prep to fix support > outputting annotation for multiple events, not just for the first one > (Arnaldo Carvalho de Melo) > > Internals: > > . Use tid in mmap/mmap2 events to find maps (Don Zickus) > > . Record the reason for filtering an address_location (Namhyung Kim) > > . Apply all filters to an addr_location (Namhyung Kim) > > . Merge al->filtered with hist_entry->filtered in report/hists (Namhyung Kim) > > . Fix memory leak when synthesizing thread records (Namhyung Kim) > > . Use ui__has_annotation() in 'report' (Namhyung Kim) > > Cleanups: > > . Remove unused thread__find_map function (Jiri Olsa) > > . Remove unused simple_strtoul() function (Ramkumar Ramachandra) > > Documentation: > > . Update function names in debug messages (Ramkumar Ramachandra) > > . Update some code references in design.txt (Ramkumar Ramachandra) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (1): > perf annotate: Print the evsel name in the stdio output > > Don Zickus (1): > perf tools: Use tid in mmap/mmap2 events to find maps > > Jiri Olsa (1): > perf tools: Remove thread__find_map function > > Namhyung Kim (5): > perf symbols: Record the reason for filtering an address_location > perf symbols: Apply all filters to an addr_location > perf report: Merge al->filtered with hist_entry->filtered > perf tools: Fix memory leak when synthesizing thread records > perf report: Use ui__has_annotation() > > Ramkumar Ramachandra (5): > perf timechart: Fix off-by-one error in 'record' argv handling > perf sched: Fixup header alignment in 'latency' output > perf evsel: Update function names in debug messages > perf tools: Update some code references in design.txt > perf tools: Remove unused simple_strtoul() function > > tools/perf/builtin-report.c| 4 ++-- > tools/perf/builtin-sched.c | 10 +- > tools/perf/builtin-timechart.c | 4 ++-- > tools/perf/design.txt | 12 ++-- > tools/perf/tests/hists_link.c | 1 + > tools/perf/util/annotate.c | 14 +- > tools/perf/util/event.c| 34 > +- > tools/perf/util/evsel.c| 4 ++-- > tools/perf/util/hist.c | 9 + > tools/perf/util/hist.h | 9 + > tools/perf/util/include/linux/kernel.h | 6 -- > tools/perf/util/machine.c | 6 +++--- > tools/perf/util/symbol.h | 2 +- > tools/perf/util/thread.h | 6 -- > 14 files changed, 58 insertions(+), 63 deletions(-) Pulled, thanks a lot Arnaldo! Ingo -- 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 00/31] Clean up smp_mb__ barriers
Hi all,
Here's a respin (and per arch breakout) of the first 3 patches that spawned
this large C11 atomics thread.
These patches deprecate smp_mb__{before,after}_{atomic_{inc,dec},clear_bit}()
and replace it by just the two smp_mb__{before,after}_atomic().
Assuming people like this; how would we go about merging it? Can we stuff it
into tip/locking/core or something?
Its been compile tested for everything I have a working compiler for.
--
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/31] arch,avr32: Convert smp_mb__*
AVR32's mb() implementation is a compiler barrier(), therefore it all doesn't matter, fully rely on whatever asm-generic/barrier.h generates. Signed-off-by: Peter Zijlstra --- arch/avr32/include/asm/atomic.h |5 - arch/avr32/include/asm/bitops.h |9 ++--- 2 files changed, 2 insertions(+), 12 deletions(-) --- a/arch/avr32/include/asm/atomic.h +++ b/arch/avr32/include/asm/atomic.h @@ -183,9 +183,4 @@ static inline int atomic_sub_if_positive #define atomic_dec_if_positive(v) atomic_sub_if_positive(1, v) -#define smp_mb__before_atomic_dec()barrier() -#define smp_mb__after_atomic_dec() barrier() -#define smp_mb__before_atomic_inc()barrier() -#define smp_mb__after_atomic_inc() barrier() - #endif /* __ASM_AVR32_ATOMIC_H */ --- a/arch/avr32/include/asm/bitops.h +++ b/arch/avr32/include/asm/bitops.h @@ -13,12 +13,7 @@ #endif #include - -/* - * clear_bit() doesn't provide any barrier for the compiler - */ -#define smp_mb__before_clear_bit() barrier() -#define smp_mb__after_clear_bit() barrier() +#include /* * set_bit - Atomically set a bit in memory @@ -67,7 +62,7 @@ static inline void set_bit(int nr, volat * * clear_bit() is atomic and may not be reordered. However, it does * not contain a memory barrier, so if it is used for locking purposes, - * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit() + * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic() * in order to ensure changes are visible on other processors. */ static inline void clear_bit(int nr, volatile void * addr) -- 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 06/13] perf tools: Use tid in mmap/mmap2 events to find maps
On 18.03.2014 23:25, Arnaldo Carvalho de Melo wrote:
> From: Don Zickus
>
> Now that we can properly synthesize threads system-wide, make sure the
> mmap and mmap2 events use tids instead of pids to locate their maps.
This is a good change but it cannot go yet because it is dependent on Jiri's
"perf tools: Share map groups within process" series.
perf tools assume that threads share virtual memory. That means that a
mapping created by one thread is visible to all threads in the thread group.
That was implemented by putting all the maps on the thread group leader
(pid == tid). The alternative is to share the map groups instead, which is
what Jiri is doing.
>
> Signed-off-by: Don Zickus
> Cc: Jiri Olsa
> Cc: Stephane Eranian
> Link:
> http://lkml.kernel.org/r/1393429527-167840-3-git-send-email-dzic...@redhat.com
> Signed-off-by: Arnaldo Carvalho de Melo
> ---
> tools/perf/tests/hists_link.c | 1 +
> tools/perf/util/machine.c | 4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/tests/hists_link.c b/tools/perf/tests/hists_link.c
> index 2b6519e0e36f..7ccbc7b6ae77 100644
> --- a/tools/perf/tests/hists_link.c
> +++ b/tools/perf/tests/hists_link.c
> @@ -101,6 +101,7 @@ static struct machine *setup_fake_machine(struct machines
> *machines)
> .mmap = {
> .header = { .misc = PERF_RECORD_MISC_USER, },
> .pid = fake_mmap_info[i].pid,
> + .tid = fake_mmap_info[i].pid,
> .start = fake_mmap_info[i].start,
> .len = 0x1000ULL,
> .pgoff = 0ULL,
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index d280bf210183..a53cd0b8c151 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -1027,7 +1027,7 @@ int machine__process_mmap2_event(struct machine
> *machine,
> }
>
> thread = machine__findnew_thread(machine, event->mmap2.pid,
> - event->mmap2.pid);
> + event->mmap2.tid);
> if (thread == NULL)
> goto out_problem;
>
> @@ -1075,7 +1075,7 @@ int machine__process_mmap_event(struct machine
> *machine, union perf_event *event
> }
>
> thread = machine__findnew_thread(machine, event->mmap.pid,
> - event->mmap.pid);
> + event->mmap.tid);
> if (thread == NULL)
> goto out_problem;
>
>
--
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/
linux-next: Tree for Mar 19
Hi all, This tree still fails (more than usual) the powerpc allyesconfig build. Changes since 20140318: The powerpc tree still had its build failure. The net-next tree lost 2 of its another build failures. The wireless-next tree lost its build failure but gained another for which I reverted 2 commits. The drm-intel tree gained a build failure so I used the version from next-20140318. The sound-asoc tree gained a build failure so I used the version from next-20140318. The staging tree gained conflicts against the drm tree. The random tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 9392 8992 files changed, 730597 insertions(+), 502975 deletions(-) (the shortstat with -M -C looks like this: 8374 files changed, 400356 insertions(+), 196072 deletions(-) so there is a bit of movement of files going on.) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 213 trees (counting Linus' and 28 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (4907cdca7210 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1) Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8) Merging arm-current/fixes (38e0b088d322 ARM: 7992/1: boot: compressed: ignore bswapsdi2.S) Merging m68k-current/for-linus (7247f55381d5 m68k: Wire up sched_setattr and sched_getattr) Merging metag-fixes/fixes (0414855fdc4a Linux 3.14-rc5) Merging powerpc-merge/merge (a5b2cf5b1af4 powerpc: Align p_dyn, p_rela and p_st symbols) Merging sparc/master (151b628f1045 sparc64:tsb.c:use array size macro rather than number) Merging net/master (3e3d35402140 ATHEROS-ATL1E: Convert iounmap to pci_iounmap) Merging ipsec/master (52a4c6404f91 selinux: add gfp argument to security_xfrm_policy_alloc and fix callers) Merging sound-current/for-linus (305564413c99 ALSA: oxygen: Xonar DG(X): fix Stereo Upmixing regression) Merging pci-current/for-linus (707d4eefbdb3 Revert "[PATCH] Insert GART region into resource map") Merging wireless/master (584221918925 Revert "rt2x00: rt2800lib: Update BBP register initialization for RT53xx") Merging driver-core.current/driver-core-linus (0414855fdc4a Linux 3.14-rc5) Merging tty.current/tty-linus (0414855fdc4a Linux 3.14-rc5) Merging usb.current/usb-linus (fa389e220254 Linux 3.14-rc6) Merging staging.current/staging-linus (dcb99fd9b08c Linux 3.14-rc7) Merging char-misc.current/char-misc-linus (0414855fdc4a Linux 3.14-rc5) Merging input-current/for-linus (70b0052425ff Input: da9052_onkey - use correct register bit for key status) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (ee97dc7db4cb crypto: s390 - fix des and des3_ede ctr concurrency issue) Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (1f42e5dd5065 of: Add self test for of_match_node()) Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter kernel symbols for arm) Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before cancelling
Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel tree
On Wed, Mar 19, 2014 at 2:54 AM, Ben Widawsky wrote:
> On Tue, Mar 18, 2014 at 09:18:42PM -0400, Steven Rostedt wrote:
>> On Wed, 19 Mar 2014 11:53:50 +1100
>> Stephen Rothwell wrote:
>>
>>
>> > Caused by commit a25ca17c1eac ("drm/i915: Do not dereference pointers
>> > from ring buffer in evict event").
>> >
>> > I have used the drm-intel tree from next-20140318 for today.
>> >
>>
>> Bah! I'm still suffering from jet lag (just came back from Linux-Tage
>> in Chemnitz).
>>
>> The next time I compile test a patch for a module, I'll make sure I have
>> that module's config option set :-( The woe of using localmodconfig. I
>> should have picked the box with the i915. :-/
>>
>> Below is the fix. I'll repost a v2 of the original patch.
>>
>> Sorry about that.
>>
>
> I was about to send out the same fix when I saw this.
>
> Reviewed-by: Ben Widawsky
Just fixed this this morning before starting to read mail - my
apologies the mess me pushing out a patch yesterday right before
rushing out caused, really shouldn't be doing that ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] mmc: sdhci-bcm-kona: Fix locking in sdhci_bcm_kona_sd_card_emulate()
On Wed, Mar 5, 2014 at 8:25 PM, Markus Mayer wrote:
> Since sdhci_bcm_kona_sd_card_emulate() can be called from interrupt
> context, we must use a spinlock instead of a mutex. This change
> essentially restores the way things worked before the change to
> mutexes in http://www.spinics.net/lists/linux-mmc/msg20276.html.
>
> Without this change, we see "scheduling while atomic" errors.
>
> Signed-off-by: Markus Mayer
> ---
So digging back in memory (since I no longer have the
broadcom-internal email threads on this topic), I think I recall what
the problem is. card_event is being called directly from
mmc_gpio_cd_irqt, which is atomic context. My plan for this was to
delay the card_event callback into the mmc_rescan worker, as that
would have 2 nice results: remove the callback from atomic context
which it doesn't need to be in, and put it in line with the debounced
rescan (which I think it should be). I made mention of that option in
this thread (https://lkml.org/lkml/2013/8/19/539) but seems I never
followed up with code...
Something along the lines of the (untested) code below might do the trick:
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 098374b..d4ffba8 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2421,6 +2421,11 @@ void mmc_rescan(struct work_struct *work)
container_of(work, struct mmc_host, detect.work);
int i;
+ if (host->trigger_card_event && host->ops->card_event) {
+ host->ops->card_event(host);
+ host->trigger_card_event = 0;
+ }
+
if (host->rescan_disable)
return;
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 46596b71..fc648ae 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -29,9 +29,7 @@ static irqreturn_t mmc_gpio_cd_irqt(int irq, void *dev_id)
/* Schedule a card detection after a debounce timeout */
struct mmc_host *host = dev_id;
- if (host->ops->card_event)
- host->ops->card_event(host);
-
+ host->trigger_card_event = 1;
mmc_detect_change(host, msecs_to_jiffies(200));
return IRQ_HANDLED;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 99f5709..0b6bddf 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -322,6 +322,8 @@ struct mmc_host {
int rescan_disable; /* disable card detection */
int rescan_entered; /* used with nonremovable devices */
+ int trigger_card_event; /* card_event necessary */
+
struct mmc_card *card; /* device attached to this host */
wait_queue_head_t wq;
Of course there are (a few) more users of card_event callback than
bcm_kona that need to be confirmed ok such a change
Thanks,
csd
--
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] Video: atmel: avoid the id of fix screen info is overwritten
Correct passing parameter sequence, which will avoid the id of fix screen info is overwritten. Signed-off-by: Bo Shen --- drivers/video/atmel_lcdfb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c index cd96162..695f28a 100644 --- a/drivers/video/atmel_lcdfb.c +++ b/drivers/video/atmel_lcdfb.c @@ -1190,12 +1190,12 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev) if (!sinfo->config) goto free_info; - strcpy(info->fix.id, sinfo->pdev->name); info->flags = ATMEL_LCDFB_FBINFO_DEFAULT; info->pseudo_palette = sinfo->pseudo_palette; info->fbops = &atmel_lcdfb_ops; info->fix = atmel_lcdfb_fix; + strcpy(info->fix.id, sinfo->pdev->name); /* Enable LCDC Clocks */ sinfo->bus_clk = clk_get(dev, "hclk"); -- 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/
Re: [PATCH v3 1/3] clk: s2mps11: Add support for S2MPS14 clocks
On Tue, 2014-03-18 at 17:16 -0700, Mike Turquette wrote: > Quoting Krzysztof Kozlowski (2014-03-17 02:19:16) > > This patch adds support for S2MPS14 PMIC clocks (BT and AP) to the > > s2mps11 clock driver. > > > > Signed-off-by: Krzysztof Kozlowski > > Reviewed-by: Yadwinder Singh Brar > > Reviewed-by: Tomasz Figa > > This does not apply cleanly to to clk tree trip, nor does it compile > after manually merging due to changes introducing > linux/mfd/samsung/s2mps14.h. > > The changes look OK to me so maybe Lee can take it with my Ack? > > Acked-by: Mike Turquette > Hi, Thanks for the Ack. The patch depends on Tushar Behera's patches: - [PATCH V2 0/2] Add support for clocks in S5M8767 http://thread.gmane.org/gmane.linux.kernel.samsung-soc/27264 which are waiting for some time. Both patchsets should be pulled together. Best regards, Krzysztof -- 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/6] SP800-90A Deterministic Random Bit Generator
Am Montag, 17. März 2014, 08:34:06 schrieb Stephan Mueller:
> +static int drbg_seed(struct drbg_state *drbg, struct drbg_string *pers,
> + bool reseed)
> +{
> + int ret = 0;
> + unsigned char *entropy = NULL;
> + size_t entropylen = 0;
> + struct drbg_string data1;
> + struct drbg_string *data2;
> +
> + /* 9.1 / 9.2 / 9.3.1 step 3 */
> + if (pers && pers->len > (drbg_max_addtl(drbg)))
> + return -EINVAL;
> +
> + if (drbg->test_data) {
> + data1.buf = drbg->test_data->testentropy->buf;
> + data1.len = drbg->test_data->testentropy->len;
> + data1.next = NULL;
> + } else {
> + /* Gather entropy equal to the security strength of the DRBG.
> + * With a derivation function, a nonce is required in addition
> + * to the entropy. A nonce must be at least 1/2 of the
security
> + * strength of the DRBG in size. Thus, entropy * nonce is 3/2
> + * of the strength. The consideration of a nonce is only
> + * applicable during initial seeding. */
> + entropylen = (drbg_sec_strength(drbg->core->flags) / 8);
drbg_sec_strength returns the strength in bytes, thus the division by 8 must
be removed
> + if (!entropylen)
> + return -EFAULT;
> + if (!reseed)
> + /* make sure we round up strength/2 in
> + * case it is not divisible by 2 */
> + entropylen = ((entropylen + 1) / 2) * 3;
> +
> + entropy = kzalloc(entropylen, GFP_KERNEL);
> + if (!entropy)
> + return -ENOMEM;
> + get_random_bytes(entropy, entropylen);
> + drbg_string_fill(&data1, entropy, entropylen);
> + }
> +
> + /* concatenation of entropy with personalization str / addtl input) */
> + if (pers && 0 < pers->len) {
> + data2 = pers;
> + data2->next = NULL;
> + data1.next = data2;
> + }
> +
> + ret = drbg->d_ops->update(drbg, &data1, reseed);
> + if (ret)
> + goto out;
> +
> + drbg->seeded = true;
> + /* 10.1.1.2 / 10.1.1.3 step 5 */
> + drbg->reseed_ctr = 1;
> +
> +out:
> + if (entropy)
> + kzfree(entropy);
> + return ret;
> +}
> +
[...]
> +static unsigned int drbg_generate(struct drbg_state *drbg,
> + unsigned char *buf, unsigned int buflen,
> + struct drbg_string *addtl)
> +{
> + unsigned int len = 0;
> + struct drbg_state *shadow = NULL;
> +
> + if (0 == buflen || !buf)
> + return 0;
> + if (addtl && NULL == addtl->buf && 0 < addtl->len)
> + return 0;
> +
> + if (drbg_make_shadow(drbg, &shadow))
> + return 0;
> + /* 9.3.1 step 2 */
> + if (buflen > (drbg_max_request_bytes(shadow)))
> + goto err;
> + /* 9.3.1 step 3 is implicit with the chosen DRBG */
> + /* 9.3.1 step 4 */
> + if (addtl && addtl->len > (drbg_max_addtl(shadow)))
> + goto err;
> + /* 9.3.1 step 5 is implicit with the chosen DRBG */
> + /* 9.3.1 step 6 and 9 supplemented by 9.3.2 step c -- the spec is a
> + * bit convoluted here, we make it simpler */
> + if ((drbg_max_requests(shadow)) < shadow->reseed_ctr)
> + shadow->seeded = false;
> +
> + /* allocate cipher handle */
> + if (shadow->d_ops->crypto_init && shadow->d_ops->crypto_init(shadow))
> + goto err;
> +
> + if (shadow->pr || !shadow->seeded) {
> + /* 9.3.1 steps 7.1 through 7.3 */
> + if (drbg_seed(shadow, addtl, true))
> + goto err;
> + /* 9.3.1 step 7.4 */
> + addtl = NULL;
> + }
> + /* 9.3.1 step 8 and 10 */
> + len = drbg->d_ops->generate(shadow, buf, buflen, addtl);
This needs to be shadow->d_ops
> +
> + /* 10.1.1.4 step 6, 10.1.2.5 step 7, 10.2.1.5.2 step 7 */
> + shadow->reseed_ctr++;
> +
> +err:
> + if (shadow->d_ops->crypto_fini)
> + shadow->d_ops->crypto_fini(shadow);
> + drbg_restore_shadow(drbg, &shadow);
> + return len;
> +}
Ciao
Stephan
--
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] extcon next for 3.15
Dear Greg, This is extcon-next full request for v3.15. I add detailed description of this pull request on below. Please pull extcon with following updates. This patchset is rebased on 'Linux 3-14-rc5' because char-misc-next is based on 'Linux 3-14-rc5'. Best Regards, Chanwoo Choi The following changes since commit 0414855fdc4a40da05221fc6062cccbc0c30f169: Linux 3.14-rc5 (2014-03-02 18:56:16 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-3.15 for you to fetch changes up to 1ad94ffef22c0a6e2ee6ba90a800c32fd29ffa1f: extcon: Move OF helper function to extcon core and change function name (2014-03-19 14:41:58 +0900) Update extcon for v3.15 This patchset fix minor issue. The extcon-palmas/gpio use SIMPLE_DEV_PM_OPS macro instead of legacy method. OF helper function of extcon move in extcon core to remove separate of_extcon.c and change the name of OF helper function as following because previous function name is complicated and ambiguous naming. - of_extcon_get_extcon_dev() -> extcon_get_edev_by_phandle() Chanwoo Choi (2): extcon: of: Remove unnecessary function call by using the name of device_node extcon: Move OF helper function to extcon core and change function name Jingoo Han (2): extcon: palmas: Use SIMPLE_DEV_PM_OPS macro extcon: gpio: Use SIMPLE_DEV_PM_OPS macro drivers/extcon/Kconfig | 4 --- drivers/extcon/Makefile | 2 -- drivers/extcon/extcon-class.c| 42 ++ drivers/extcon/extcon-gpio.c | 4 +-- drivers/extcon/extcon-palmas.c | 5 +--- drivers/extcon/of_extcon.c | 64 drivers/usb/dwc3/dwc3-omap.c | 3 +- include/linux/extcon.h | 12 include/linux/extcon/of_extcon.h | 31 --- 9 files changed, 57 insertions(+), 110 deletions(-) delete mode 100644 drivers/extcon/of_extcon.c delete mode 100644 include/linux/extcon/of_extcon.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 3/4] blk-mq: replace blk_mq_init_commands with a ->init_request method
On Wed, Mar 19, 2014 at 11:08:20AM +0800, Ming Lei wrote: > > + blk_rq_init(q, q->flush_rq); > > + if (reg->cmd_size) > > + q->flush_rq->special = > > + blk_mq_rq_to_pdu(q->flush_rq); > > + > > + if (reg->ops->init_request(driver_data, > > + NULL, q->flush_rq, -1)) > > + goto err_flush_rq; > > + } > > The above looks a bit weird because q->flush_rq is invisible to > driver and should always be initialized no matter if driver defines > its .init_request callback or not. You mean the blk_rq_init? We already do a real initialization before actually using it, it's just there to prevent passing a half-initialized one to the driver. -- 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 4/4] blk-mq: add a exit_request method
On Wed, Mar 19, 2014 at 01:22:07PM +0800, Ming Lei wrote:
> exit_request definition is missed.
oops that accidentally went into another commit.
New version below:
---
From: Christoph Hellwig
Subject: blk-mq: add a exit_request method
This gives drivers an easy way to free any ressources allocated in
->init_request.
Signed-off-by: Christoph Hellwig
diff --git a/block/blk-mq.c b/block/blk-mq.c
index c2ce99b..c7e723e 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1000,6 +1000,16 @@ static void blk_mq_free_rq_map(struct blk_mq_hw_ctx
*hctx)
{
struct page *page;
+ if (hctx->rqs && hctx->queue->mq_ops->exit_request) {
+ int i;
+
+ for (i = 0; i < hctx->queue_depth; i++) {
+ if (!hctx->rqs[i])
+ continue;
+ hctx->queue->mq_ops->exit_request(hctx, hctx->rqs[i]);
+ }
+ }
+
while (!list_empty(&hctx->page_list)) {
page = list_first_entry(&hctx->page_list, struct page, lru);
list_del_init(&page->lru);
@@ -1332,7 +1342,7 @@ struct request_queue *blk_mq_init_queue(struct blk_mq_reg
*reg,
}
if (blk_mq_init_hw_queues(q, reg, driver_data))
- goto err_flush_rq;
+ goto err_flush_rq_init;
blk_mq_map_swqueue(q);
@@ -1342,6 +1352,9 @@ struct request_queue *blk_mq_init_queue(struct blk_mq_reg
*reg,
return q;
+err_flush_rq_init:
+ if (reg->ops->exit_request)
+ reg->ops->exit_request(NULL, q->flush_rq);
err_flush_rq:
kfree(q->flush_rq);
err_hw:
@@ -1387,6 +1400,9 @@ void blk_mq_free_queue(struct request_queue *q)
mutex_lock(&all_q_mutex);
list_del_init(&q->all_q_node);
mutex_unlock(&all_q_mutex);
+
+ if (q->mq_ops->exit_request)
+ q->mq_ops->exit_request(NULL, q->flush_rq);
}
/* Basically redo blk_mq_init_queue with queue frozen */
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 4d34957..ff194f8 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -68,6 +68,7 @@ typedef int (init_hctx_fn)(struct blk_mq_hw_ctx *, void *,
unsigned int);
typedef void (exit_hctx_fn)(struct blk_mq_hw_ctx *, unsigned int);
typedef int (init_request_fn)(void *, struct blk_mq_hw_ctx *,
struct request *, unsigned int);
+typedef void (exit_request_fn)(struct blk_mq_hw_ctx *, struct request *);
struct blk_mq_ops {
/*
@@ -104,8 +105,10 @@ struct blk_mq_ops {
/*
* Called for every command allocated by the block layer to allow
* the driver to set up driver specific data.
+* Ditto for exit/teardown.
*/
init_request_fn *init_request;
+ exit_request_fn *exit_request;
};
enum {
--
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: unisys: replace kzalloc/kfree with UISMALLOC/UISFREE
It doesn't need to trace status of buffer when buffers are
allocated/deallocated. So stuff of tracing memory status
are removed. And also UISMALLOC/UISFREE macro are removed
completetly. just use kzalloc/kfree.
Signed-off-by: Daeseok Youn
---
drivers/staging/unisys/include/uisutils.h |6 --
drivers/staging/unisys/uislib/uislib.c| 109 +++-
drivers/staging/unisys/uislib/uisutils.c |5 +-
3 files changed, 14 insertions(+), 106 deletions(-)
diff --git a/drivers/staging/unisys/include/uisutils.h
b/drivers/staging/unisys/include/uisutils.h
index 81b5d9b..1c6d872 100644
--- a/drivers/staging/unisys/include/uisutils.h
+++ b/drivers/staging/unisys/include/uisutils.h
@@ -340,12 +340,6 @@ static inline unsigned int Issue_VMCALL_FATAL_BYE_BYE(void)
}
#define UIS_DAEMONIZE(nam)
-void *uislib_malloc(size_t siz, gfp_t gfp, U8 contiguous, char *fn, int ln);
-#define UISMALLOC(siz, gfp) uislib_malloc(siz, gfp, 1, __FILE__, __LINE__)
-#define UISVMALLOC(siz) uislib_malloc(siz, 0, 0, __FILE__, __LINE__)
-void uislib_free(void *p, size_t siz, U8 contiguous, char *fn, int ln);
-#define UISFREE(p, siz) uislib_free(p, siz, 1, __FILE__, __LINE__)
-#define UISVFREE(p, siz) uislib_free(p, siz, 0, __FILE__, __LINE__)
void *uislib_cache_alloc(struct kmem_cache *cur_pool, char *fn, int ln);
#define UISCACHEALLOC(cur_pool) uislib_cache_alloc(cur_pool, __FILE__,
__LINE__)
void uislib_cache_free(struct kmem_cache *cur_pool, void *p, char *fn, int ln);
diff --git a/drivers/staging/unisys/uislib/uislib.c
b/drivers/staging/unisys/uislib/uislib.c
index 1737f3a..c0eaa15 100644
--- a/drivers/staging/unisys/uislib/uislib.c
+++ b/drivers/staging/unisys/uislib/uislib.c
@@ -316,7 +316,7 @@ create_bus(CONTROLVM_MESSAGE *msg, char *buf)
size =
sizeof(struct bus_info) +
(deviceCount * sizeof(struct device_info *));
- bus = UISMALLOC(size, GFP_ATOMIC);
+ bus = kzalloc(size, GFP_ATOMIC | __GFP_NORETRY);
if (!bus) {
LOGERR("CONTROLVM_BUS_CREATE Failed: kmalloc for bus
failed.\n");
POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, busNo,
@@ -324,8 +324,6 @@ create_bus(CONTROLVM_MESSAGE *msg, char *buf)
return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
}
- memset(bus, 0, size);
-
/* Currently by default, the bus Number is the GuestHandle.
* Configure Bus message can override this.
*/
@@ -359,7 +357,7 @@ create_bus(CONTROLVM_MESSAGE *msg, char *buf)
bus->busNo);
POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, bus->busNo,
POSTCODE_SEVERITY_ERR);
- UISFREE(bus, size);
+ kfree(bus);
return CONTROLVM_RESP_ERROR_ALREADY_DONE;
}
if ((msg->cmd.createBus.channelAddr != 0)
@@ -380,14 +378,14 @@ create_bus(CONTROLVM_MESSAGE *msg, char *buf)
cmd.add_vbus.busTypeGuid = msg->cmd.createBus.busDataTypeGuid;
cmd.add_vbus.busInstGuid = msg->cmd.createBus.busInstGuid;
if (!VirtControlChanFunc) {
- UISFREE(bus, size);
+ kfree(bus);
LOGERR("CONTROLVM_BUS_CREATE Failed: virtpci callback
not registered.");
POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, bus->busNo,
POSTCODE_SEVERITY_ERR);
return CONTROLVM_RESP_ERROR_VIRTPCI_DRIVER_FAILURE;
}
if (!VirtControlChanFunc(&cmd)) {
- UISFREE(bus, size);
+ kfree(bus);
LOGERR("CONTROLVM_BUS_CREATE Failed: virtpci
GUEST_ADD_VBUS returned error.");
POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, bus->busNo,
POSTCODE_SEVERITY_ERR);
@@ -485,9 +483,7 @@ destroy_bus(CONTROLVM_MESSAGE *msg, char *buf)
bus->pBusChannel = NULL;
}
- UISFREE(bus,
- sizeof(struct bus_info) +
- (bus->deviceCount * sizeof(struct device_info *)));
+ kfree(bus);
return CONTROLVM_RESP_SUCCESS;
}
@@ -507,7 +503,7 @@ create_device(CONTROLVM_MESSAGE *msg, char *buf)
POSTCODE_LINUX_4(DEVICE_CREATE_ENTRY_PC, devNo, busNo,
POSTCODE_SEVERITY_INFO);
- dev = UISMALLOC(sizeof(struct device_info), GFP_ATOMIC);
+ dev = kzalloc(sizeof(struct device_info), GFP_ATOMIC | __GFP_NORETRY);
if (!dev) {
LOGERR("CONTROLVM_DEVICE_CREATE Failed: kmalloc for dev
failed.\n");
POSTCODE_LINUX_4(DEVICE_CREATE_FAILURE_PC, devNo, busNo,
@@ -515,7 +511,6 @@ create_device(CONTROLVM_MESSAGE *msg, char *buf)
return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
}
- memset(dev, 0, sizeof(struct device_info));
dev->channelTypeGuid = msg->cmd.createDevice.dataTypeGuid
[PATCH 3/5] f2fs: remove unnecessary threshold
The NM_WOUT_THRESHOLD is now obsolete since f2fs starts to control on a basis
of the memory footprint.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/debug.c | 8
fs/f2fs/node.c | 5 +
fs/f2fs/node.h | 3 ---
3 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index b7111c4..b52c12c 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -250,10 +250,10 @@ static int stat_show(struct seq_file *s, void *v)
si->ndirty_dent, si->ndirty_dirs);
seq_printf(s, " - meta: %4d in %4d\n",
si->ndirty_meta, si->meta_pages);
- seq_printf(s, " - NATs: %5d > %lu\n",
- si->nats, NM_WOUT_THRESHOLD);
- seq_printf(s, " - SITs: %5d\n - free_nids: %5d\n",
- si->sits, si->fnids);
+ seq_printf(s, " - NATs: %9d\n - SITs: %9d\n",
+ si->nats, si->sits);
+ seq_printf(s, " - free_nids: %9d\n",
+ si->fnids);
seq_puts(s, "\nDistribution of User Blocks:");
seq_puts(s, " [ valid | invalid | free ]\n");
seq_puts(s, " [");
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 9cf524d..4f48aa3 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -224,7 +224,7 @@ int try_to_free_nats(struct f2fs_sb_info *sbi, int
nr_shrink)
{
struct f2fs_nm_info *nm_i = NM_I(sbi);
- if (available_free_memory(nm_i, NAT_ENTRIES) || nr_shrink <= 0)
+ if (available_free_memory(nm_i, NAT_ENTRIES))
return 0;
write_lock(&nm_i->nat_tree_lock);
@@ -1828,9 +1828,6 @@ flush_now:
if (!flushed)
mutex_unlock(&curseg->curseg_mutex);
f2fs_put_page(page, 1);
-
- /* 2) shrink nat caches if necessary */
- try_to_free_nats(sbi, nm_i->nat_cnt - NM_WOUT_THRESHOLD);
}
static int init_node_manager(struct f2fs_sb_info *sbi)
diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index c972154..c2015b7 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -20,9 +20,6 @@
/* maximum readahead size for node during getting data blocks */
#define MAX_RA_NODE128
-/* maximum cached nat entries to manage memory footprint */
-#define NM_WOUT_THRESHOLD (64 * NAT_ENTRY_PER_BLOCK)
-
/* control the memory footprint threshold (10MB per 1GB ram) */
#define DEF_RAM_THRESHOLD 10
--
1.8.4.474.g128a96c
--
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/5] f2fs: avoid to drop nat entries due to the negative nr_shrink
The try_to_free_nats should not receive the negative nr_shrink.
Otherwise, it can drop all the nat entries by the while loop.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/node.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 707fd20..04450a5 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -208,7 +208,7 @@ int try_to_free_nats(struct f2fs_sb_info *sbi, int
nr_shrink)
{
struct f2fs_nm_info *nm_i = NM_I(sbi);
- if (nm_i->nat_cnt <= NM_WOUT_THRESHOLD)
+ if (nm_i->nat_cnt <= NM_WOUT_THRESHOLD || nr_shrink <= 0)
return 0;
write_lock(&nm_i->nat_tree_lock);
--
1.8.4.474.g128a96c
--
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 4/5] f2fs: add missing documentation for dir_level
This patch adds missing dir_level documentation. Signed-off-by: Jaegeuk Kim --- Documentation/ABI/testing/sysfs-fs-f2fs | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 4ac2c25..62dd725 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -56,6 +56,12 @@ Contact: "Jaegeuk Kim" Description: Controls the number of trials to find a victim segment. +What: /sys/fs/f2fs//dir_level +Date: March 2014 +Contact: "Jaegeuk Kim" +Description: +Controls the directory level for large directory. + What: /sys/fs/f2fs//ram_thresh Date: March 2014 Contact: "Jaegeuk Kim" -- 1.8.4.474.g128a96c -- 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/5] f2fs: change reclaim rate in percentage
It is more reasonable to determine the reclaiming rate of prefree segments according to the volume size, which is set to 5% by default. For example, if the volume is 128GB, the prefree segments are reclaimed when the number reaches to 6.4GB. Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/f2fs.txt | 8 +--- fs/f2fs/segment.c | 3 ++- fs/f2fs/segment.h | 2 +- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index f415b9f..2f6d021 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -169,9 +169,11 @@ Files in /sys/fs/f2fs/ reclaim_segments This parameter controls the number of prefree segments to be reclaimed. If the number of prefree - segments is larger than this number, f2fs tries to - conduct checkpoint to reclaim the prefree segments - to free segments. By default, 100 segments, 200MB. + segments is larger than the number of segments + in the proportion to the percentage over total + volume size, f2fs tries to conduct checkpoint to + reclaim the prefree segments to free segments. + By default, 5% over total # of segments. max_small_discards This parameter controls the number of discard commands that consist small blocks less than 2MB. diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 6c5a4f0..e7ff23a 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -1758,7 +1758,8 @@ int build_segment_manager(struct f2fs_sb_info *sbi) sm_info->ovp_segments = le32_to_cpu(ckpt->overprov_segment_count); sm_info->main_segments = le32_to_cpu(raw_super->segment_count_main); sm_info->ssa_blkaddr = le32_to_cpu(raw_super->ssa_blkaddr); - sm_info->rec_prefree_segments = DEF_RECLAIM_PREFREE_SEGMENTS; + sm_info->rec_prefree_segments = sm_info->main_segments * + DEF_RECLAIM_PREFREE_SEGMENTS / 100; sm_info->ipu_policy = F2FS_IPU_DISABLE; sm_info->min_ipu_util = DEF_MIN_IPU_UTIL; diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index 9fc46ee..7091204 100644 --- a/fs/f2fs/segment.h +++ b/fs/f2fs/segment.h @@ -14,7 +14,7 @@ #define NULL_SEGNO ((unsigned int)(~0)) #define NULL_SECNO ((unsigned int)(~0)) -#define DEF_RECLAIM_PREFREE_SEGMENTS 100 /* 200MB of prefree segments */ +#define DEF_RECLAIM_PREFREE_SEGMENTS 5 /* 5% over total segments */ /* L: Logical segment # in volume, R: Relative segment # in main area */ #define GET_L2R_SEGNO(free_i, segno) (segno - free_i->start_segno) -- 1.8.4.474.g128a96c -- 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/5] f2fs: throttle the memory footprint with a sysfs entry
This patch introduces ram_thresh, a sysfs entry, which controls the memory
footprint used by the free nid list and the nat cache.
Previously, the free nid list was controlled by MAX_FREE_NIDS, while the nat
cache was managed by NM_WOUT_THRESHOLD.
However, this approach cannot be applied dynamically according to the system.
So, this patch adds ram_thresh that users can specify the threshold, which is
in order of 1 / 1024.
For example, if the total ram size is 4GB and the value is set to 10 by default,
f2fs tries to control the number of free nids and nat caches not to consume over
10 * (4GB / 1024) = 10MB.
Signed-off-by: Jaegeuk Kim
---
Documentation/ABI/testing/sysfs-fs-f2fs | 6 ++
Documentation/filesystems/f2fs.txt | 4
fs/f2fs/f2fs.h | 1 +
fs/f2fs/node.c | 23 ---
fs/f2fs/node.h | 11 ---
fs/f2fs/super.c | 5 +
6 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 32b0809..4ac2c25 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -55,3 +55,9 @@ Date: January 2014
Contact: "Jaegeuk Kim"
Description:
Controls the number of trials to find a victim segment.
+
+What: /sys/fs/f2fs//ram_thresh
+Date: March 2014
+Contact: "Jaegeuk Kim"
+Description:
+Controls the memory footprint used by f2fs.
diff --git a/Documentation/filesystems/f2fs.txt
b/Documentation/filesystems/f2fs.txt
index 803784e..f415b9f 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -202,6 +202,10 @@ Files in /sys/fs/f2fs/
Otherwise, it needs to decrease this value to
reduce the space overhead. The default value is 0.
+ ram_thresh This parameter controls the memory footprint used
+ by free nids and cached nat entries. By default,
+ 10 is set, which indicates 10 MB / 1 GB RAM.
+
USAGE
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 59fac1a..05c6524 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -242,6 +242,7 @@ struct f2fs_nm_info {
block_t nat_blkaddr;/* base disk address of NAT */
nid_t max_nid; /* maximum possible node ids */
nid_t next_scan_nid;/* the next nid to be scanned */
+ unsigned int ram_thresh;/* control the memory footprint */
/* NAT cache management */
struct radix_tree_root nat_root;/* root of the nat entry cache */
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 04450a5..9cf524d 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -26,6 +26,22 @@
static struct kmem_cache *nat_entry_slab;
static struct kmem_cache *free_nid_slab;
+static inline bool available_free_memory(struct f2fs_nm_info *nm_i, int type)
+{
+ struct sysinfo val;
+ unsigned long mem_size = 0;
+
+ si_meminfo(&val);
+ if (type == FREE_NIDS)
+ mem_size = nm_i->fcnt * sizeof(struct free_nid);
+ else if (type == NAT_ENTRIES)
+ mem_size += nm_i->nat_cnt * sizeof(struct nat_entry);
+ mem_size >>= 12;
+
+ /* give 50:50 memory for free nids and nat caches respectively */
+ return (mem_size < ((val.totalram * nm_i->ram_thresh) >> 11));
+}
+
static void clear_node_page_dirty(struct page *page)
{
struct address_space *mapping = page->mapping;
@@ -208,7 +224,7 @@ int try_to_free_nats(struct f2fs_sb_info *sbi, int
nr_shrink)
{
struct f2fs_nm_info *nm_i = NM_I(sbi);
- if (nm_i->nat_cnt <= NM_WOUT_THRESHOLD || nr_shrink <= 0)
+ if (available_free_memory(nm_i, NAT_ENTRIES) || nr_shrink <= 0)
return 0;
write_lock(&nm_i->nat_tree_lock);
@@ -1286,7 +1302,7 @@ static int add_free_nid(struct f2fs_nm_info *nm_i, nid_t
nid, bool build)
struct nat_entry *ne;
bool allocated = false;
- if (nm_i->fcnt > 2 * MAX_FREE_NIDS)
+ if (!available_free_memory(nm_i, FREE_NIDS))
return -1;
/* 0 nid should not be used */
@@ -1471,7 +1487,7 @@ void alloc_nid_failed(struct f2fs_sb_info *sbi, nid_t nid)
spin_lock(&nm_i->free_nid_list_lock);
i = __lookup_free_nid_list(nm_i, nid);
f2fs_bug_on(!i || i->state != NID_ALLOC);
- if (nm_i->fcnt > 2 * MAX_FREE_NIDS) {
+ if (!available_free_memory(nm_i, FREE_NIDS)) {
__del_from_free_nid_list(nm_i, i);
} else {
i->state = NID_NEW;
@@ -1834,6 +1850,7 @@ static int init_node_manager
Re: [PATCH 2/4] regulator: max8660: Silence checkpatch warnings
On 18 March 2014 18:09, Mark Brown wrote:
> On Tue, Mar 18, 2014 at 03:53:02PM +0530, Sachin Kamat wrote:
>> Silences the following type of error/warnings:
>> ERROR: that open brace { should be on the previous line
>> WARNING: Missing a blank line after declarations
>
> Applied, but...
>
>> - static const u8 max8660_addresses[MAX8660_N_REGS] =
>> - { 0x10, 0x12, 0x20, 0x23, 0x24, 0x29, 0x2a, 0x32, 0x33, 0x39, 0x80 };
>> + static const u8 max8660_addresses[MAX8660_N_REGS] = {
>> + 0x10, 0x12, 0x20, 0x23, 0x24, 0x29, 0x2a, 0x32, 0x33, 0x39, 0x80 };
>
> Think about what you're doing here - you want the }; on a new line too.
Sorry about it. I was kind of in two minds about shifting it. I will
send a followup
for completeness.
--
With warm regards,
Sachin
--
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/5] staging: wlags49_h2: remove commented code in wl_netdev.c
Remove unused code under C99 comment style
Signed-off-by: Mathieu Maret
---
drivers/staging/wlags49_h2/wl_netdev.c | 38 --
1 file changed, 38 deletions(-)
diff --git a/drivers/staging/wlags49_h2/wl_netdev.c
b/drivers/staging/wlags49_h2/wl_netdev.c
index ae42c8e..d9f9237 100644
--- a/drivers/staging/wlags49_h2/wl_netdev.c
+++ b/drivers/staging/wlags49_h2/wl_netdev.c
@@ -68,31 +68,14 @@
#include
#include
#include
-// #include
-// #include
-// #include
-// #include
-// #include
-//#include
-// #include
-// #include
-// #include
-// #include
-// #include
-// // #include
-
#include
#include
#include
-// #include
-// #include
-// #include
#include
#include
#include
-// #include
#include
#include
@@ -120,10 +103,6 @@
#define MTU_MAX (HCF_MAX_MSG - ETH_HLEN)
#endif
-//static int mtu = MTU_MAX;
-//MODULE_PARM(mtu, "i");
-//MODULE_PARM_DESC(mtu, "MTU");
-
/***
* macros
**/
@@ -159,16 +138,7 @@
**/
int wl_init(struct net_device *dev)
{
-//unsigned long flags;
-//struct wl_private *lp = wl_priv(dev);
-
DBG_PARAM(DbgInfo, "dev", "%s (0x%p)", dev->name, dev);
-
- /* Nothing to do, but grab the spinlock anyway just in case we ever need
- this routine */
-// wl_lock( lp, &flags );
-// wl_unlock( lp, &flags );
-
return 0;
} // wl_init
@@ -427,17 +397,12 @@ static void wl_get_drvinfo(struct net_device *dev, struct
ethtool_drvinfo *info)
{
strlcpy(info->driver, DRIVER_NAME, sizeof(info->driver));
strlcpy(info->version, DRV_VERSION_STR, sizeof(info->version));
-// strlcpy(info.fw_version, priv->fw_name,
-// sizeof(info.fw_version));
if (dev->dev.parent) {
dev_set_name(dev->dev.parent, "%s", info->bus_info);
- //strlcpy(info->bus_info, dev->dev.parent->bus_id,
- // sizeof(info->bus_info));
} else {
snprintf(info->bus_info, sizeof(info->bus_info),
"PCMCIA FIXME");
-// "PCMCIA 0x%lx", priv->hw.iobase);
}
} // wl_get_drvinfo
@@ -1237,8 +1202,6 @@ struct net_device *wl_device_alloc(void)
**/
void wl_device_dealloc(struct net_device *dev)
{
-//struct wl_private *lp = wl_priv(dev);
-
/* Dealloc the WDS ports */
WL_WDS_DEVICE_DEALLOC(lp);
@@ -1832,7 +1795,6 @@ int wl_rx_dma(struct net_device *dev)
struct sk_buff *skb;
struct wl_private *lp = NULL;
DESC_STRCT *desc, *desc_next;
- //CFG_MB_INFO_RANGE2_STRCT x;
/**/
DBG_PARAM(DbgInfo, "dev", "%s (0x%p)", dev->name, dev);
--
1.9.0
--
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/5] staging: wlags49_h2: Correct coding style in wl_netdev.c
Remove space between parenthesis.
Test with simple statement does not need brackets.
Simplify test condition
Signed-off-by: Mathieu Maret
---
drivers/staging/wlags49_h2/wl_netdev.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/wlags49_h2/wl_netdev.c
b/drivers/staging/wlags49_h2/wl_netdev.c
index 6455956..22d9ba3 100644
--- a/drivers/staging/wlags49_h2/wl_netdev.c
+++ b/drivers/staging/wlags49_h2/wl_netdev.c
@@ -113,7 +113,7 @@
status = hcf_rcv_msg(&(lp->hcfCtx), desc, 0) \
} while (0)
-#define BLOCK_INPUT_DMA(buf, len) memcpy( buf, desc_next->buf_addr, pktlen )
+#define BLOCK_INPUT_DMA(buf, len) memcpy(buf, desc_next->buf_addr, pktlen)
/***
* function prototypes
@@ -225,17 +225,15 @@ struct net_device_stats *wl_stats(struct net_device *dev)
#ifdef USE_WDS
for (count = 0; count < NUM_WDS_PORTS; count++) {
- if (dev == lp->wds_port[count].dev) {
+ if (dev == lp->wds_port[count].dev)
pStats = &(lp->wds_port[count].stats);
- }
}
#endif /* USE_WDS */
/* If pStats is still NULL, then the device is not a WDS port */
- if (pStats == NULL) {
+ if (pStats == NULL)
pStats = &(lp->stats);
- }
wl_unlock(lp, &flags);
@@ -578,9 +576,8 @@ void wl_tx_timeout(struct net_device *dev)
#endif /* USE_WDS */
/* If pStats is still NULL, then the device is not a WDS port */
- if (pStats == NULL) {
+ if (pStats == NULL)
pStats = &(lp->stats);
- }
/* Accumulate the timeout error */
pStats->tx_errors++;
@@ -663,9 +660,8 @@ int wl_send(struct wl_private *lp)
}
}
- if (lp->txF.skb == NULL) {
+ if (lp->txF.skb == NULL)
return FALSE;
- }
/* If the device has resources (FIDs) available, then Tx the packet */
/* Format the TxRequest and send it to the adapter */
@@ -926,9 +922,8 @@ int wl_rx(struct net_device *dev)
DBG_ERROR(DbgInfo,
"Rx request to card
FAILED\n");
- if (port == 0) {
+ if (port == 0)
lp->stats.rx_dropped++;
- }
#ifdef USE_WDS
else {
lp->wds_port[port -
@@ -942,9 +937,8 @@ int wl_rx(struct net_device *dev)
} else {
DBG_ERROR(DbgInfo, "Could not alloc skb\n");
- if (port == 0) {
+ if (port == 0)
lp->stats.rx_dropped++;
- }
#ifdef USE_WDS
else {
lp->wds_port[port -
@@ -1657,9 +1651,8 @@ void wl_wds_netif_carrier_on(struct wl_private *lp)
if (lp != NULL) {
for (count = 0; count < NUM_WDS_PORTS; count++) {
- if (lp->wds_port[count].is_registered) {
+ if (lp->wds_port[count].is_registered)
netif_carrier_on(lp->wds_port[count].dev);
- }
}
}
} /* wl_wds_netif_carrier_on */
@@ -1819,7 +1812,8 @@ int wl_rx_dma(struct net_device *dev)
DBG_PARAM(DbgInfo, "dev", "%s (0x%p)", dev->name, dev);
- if (((lp = dev->priv) != NULL) && !(lp->flags & WVLAN2_UIL_BUSY)) {
+ lp = dev->priv;
+ if ((lp != NULL) && !(lp->flags & WVLAN2_UIL_BUSY)) {
#ifdef USE_RTS
if (lp->useRTS == 1) {
@@ -1935,9 +1929,8 @@ int wl_rx_dma(struct net_device *dev)
DBG_ERROR(DbgInfo,
"Could not alloc skb\n");
- if (port == 0) {
+ if (port == 0)
lp->stats.rx_dropped++;
- }
#ifdef USE_WDS
else {
lp->wds_port[port -
--
1.9.0
--
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/5] staging: wlags49_h2: Correct comment style in wl_netdev.c
Code is using C99 code style, so change them to kernel style
Signed-off-by: Mathieu Maret
---
drivers/staging/wlags49_h2/wl_netdev.c | 158 +++--
1 file changed, 89 insertions(+), 69 deletions(-)
diff --git a/drivers/staging/wlags49_h2/wl_netdev.c
b/drivers/staging/wlags49_h2/wl_netdev.c
index d9f9237..255d291 100644
--- a/drivers/staging/wlags49_h2/wl_netdev.c
+++ b/drivers/staging/wlags49_h2/wl_netdev.c
@@ -140,7 +140,7 @@ int wl_init(struct net_device *dev)
{
DBG_PARAM(DbgInfo, "dev", "%s (0x%p)", dev->name, dev);
return 0;
-} // wl_init
+} /* wl_init */
/**/
@@ -168,12 +168,14 @@ int wl_config(struct net_device *dev, struct ifmap *map)
DBG_PARAM(DbgInfo, "dev", "%s (0x%p)", dev->name, dev);
DBG_PARAM(DbgInfo, "map", "0x%p", map);
- /* The only thing we care about here is a port change. Since this not
needed,
- ignore the request. */
+ /*
+* The only thing we care about here is a port change.
+* Since this not needed, ignore the request.
+*/
DBG_TRACE(DbgInfo, "%s: %s called.\n", dev->name, __func__);
return 0;
-} // wl_config
+} /* wl_config */
/**/
@@ -204,7 +206,7 @@ struct net_device_stats *wl_stats(struct net_device *dev)
struct net_device_stats *pStats;
struct wl_private *lp = wl_priv(dev);
- //DBG_PARAM( DbgInfo, "dev", "%s (0x%p)", dev->name, dev );
+ /*DBG_PARAM( DbgInfo, "dev", "%s (0x%p)", dev->name, dev ); */
pStats = NULL;
@@ -236,7 +238,7 @@ struct net_device_stats *wl_stats(struct net_device *dev)
wl_unlock(lp, &flags);
return pStats;
-} // wl_stats
+} /* wl_stats */
/**/
@@ -287,7 +289,8 @@ int wl_open(struct net_device *dev)
status);
}
}
- // Holding the lock too long, make a gap to allow other processes
+
+ /* Holding the lock too long, make a gap to allow other processes */
wl_unlock(lp, &flags);
wl_lock(lp, &flags);
@@ -298,15 +301,15 @@ int wl_open(struct net_device *dev)
status = wl_apply(lp);
}
- // Holding the lock too long, make a gap to allow other processes
+ /* Holding the lock too long, make a gap to allow other processes */
wl_unlock(lp, &flags);
wl_lock(lp, &flags);
- if (status != HCF_SUCCESS) {
- // Unsuccessful, try reset of the card to recover
+ /* Unsuccessful, try reset of the card to recover */
+ if (status != HCF_SUCCESS)
status = wl_reset(dev);
- }
- // Holding the lock too long, make a gap to allow other processes
+
+ /* Holding the lock too long, make a gap to allow other processes */
wl_unlock(lp, &flags);
wl_lock(lp, &flags);
@@ -314,7 +317,8 @@ int wl_open(struct net_device *dev)
netif_carrier_on(dev);
WL_WDS_NETIF_CARRIER_ON(lp);
- lp->is_handling_int = WL_HANDLING_INT; // Start handling
interrupts
+ /* Start handling interrupts */
+ lp->is_handling_int = WL_HANDLING_INT;
wl_act_int_on(lp);
netif_start_queue(dev);
@@ -327,7 +331,7 @@ int wl_open(struct net_device *dev)
wl_unlock(lp, &flags);
return status;
-} // wl_open
+} /* wl_open */
/**/
@@ -363,17 +367,19 @@ int wl_close(struct net_device *dev)
netif_carrier_off(dev);
WL_WDS_NETIF_CARRIER_OFF(lp);
- /* Shutdown the adapter:
- Disable adapter interrupts
- Stop Tx/Rx
- Update statistics
- Set low power mode
+ /*
+* Shutdown the adapter:
+* Disable adapter interrupts
+* Stop Tx/Rx
+* Update statistics
+* Set low power mode
*/
wl_lock(lp, &flags);
wl_act_int_off(lp);
- lp->is_handling_int = WL_NOT_HANDLING_INT; // Stop handling
interrupts
+ /* Stop handling interrupts */
+ lp->is_handling_int = WL_NOT_HANDLING_INT;
#ifdef USE_RTS
if (lp->useRTS == 1) {
@@ -389,7 +395,7 @@ int wl_close(struct net_device *dev)
wl_unlock(lp, &flags);
return 0;
-} // wl_close
+} /* wl_close */
/**/
@@ -404,7 +410,7 @
[PATCH 4/5] staging: wlags49_h2: Correct macro style in wl_netdev.c
Multi statement macro should use do{}while(0)
Signed-off-by: Mathieu Maret
---
drivers/staging/wlags49_h2/wl_netdev.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/wlags49_h2/wl_netdev.c
b/drivers/staging/wlags49_h2/wl_netdev.c
index 255d291..6455956 100644
--- a/drivers/staging/wlags49_h2/wl_netdev.c
+++ b/drivers/staging/wlags49_h2/wl_netdev.c
@@ -107,9 +107,11 @@
* macros
**/
#define BLOCK_INPUT(buf, len) \
-desc->buf_addr = buf; \
-desc->BUF_SIZE = len; \
-status = hcf_rcv_msg(&(lp->hcfCtx), desc, 0)
+ do { \
+ desc->buf_addr = buf; \
+ desc->BUF_SIZE = len; \
+ status = hcf_rcv_msg(&(lp->hcfCtx), desc, 0) \
+ } while (0)
#define BLOCK_INPUT_DMA(buf, len) memcpy( buf, desc_next->buf_addr, pktlen )
--
1.9.0
--
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/17] ioprio: Add a macro named NICE_TO_IOPRIO.
On Tue, Mar 11, 2014 at 06:09:16PM +0800, Dongsheng Yang wrote:
> As the task nice value is in [-20, 19] and the io priority is in [0, 7],
> and the convert method from niceval to ioprio is implemented with an
> opened code in task_nice_ioprio().
>
> This patch move the implementation to a macro NICE_TO_IOPRIO, making
> it more readable and modular.
>
> Signed-off-by: Dongsheng Yang
> ---
> include/linux/ioprio.h | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/ioprio.h b/include/linux/ioprio.h
> index beb9ce1..c0faa0b 100644
> --- a/include/linux/ioprio.h
> +++ b/include/linux/ioprio.h
> @@ -18,6 +18,11 @@
> #define ioprio_valid(mask) (IOPRIO_PRIO_CLASS((mask)) != IOPRIO_CLASS_NONE)
>
> /*
> + * Convert the nice value [19,-20] to io priority value [0,7].
> + */
> +#define NICE_TO_IOPRIO(nice) (nice_to_rlimit(nice) / 5)
> +
> +/*
> * These are the io priority groups as implemented by CFQ. RT is the realtime
> * class, it always gets premium service. BE is the best-effort scheduling
> * class, the default for any process. IDLE is the idle scheduling class, it
> @@ -52,7 +57,7 @@ enum {
> */
> static inline int task_nice_ioprio(struct task_struct *task)
> {
> - return (task_nice(task) + 20) / 5;
> + return NICE_TO_IOPRIO(task_nice(task));
> }
I'm still not seeing the point of adding that macro; if you want more
documentation; just add the comment.
--
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] mfd: sec-core: Fix uninitialized 'regmap_rtc' on S2MPA01
On 18 March 2014 18:41, Krzysztof Kozlowski wrote: > Initialize the 'regmap_rtc' on S2MPA01 to some sane value. Sane at least > for S5M87X chipsets, not S2MPS/S2MPA but it won't be used because > rtc-s5m driver does not support S2MPA01. > > This fixes following error: > drivers/mfd/sec-core.c:342:45: warning: 'regmap_rtc' may be used > uninitialized in this function [-Wuninitialized] > > Signed-off-by: Krzysztof Kozlowski >From the point of suppressing this warning and considering how it is done for S2MPS11, Acked-by: Sachin Kamat However, shouldn't we be making this RTC handling conditional/optional depending upon whether the h/w or s/w supports/implements it? -- With warm regards, Sachin -- 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] gpiolib: check if gpio_desc pointer is error or NULL
On 19/03/14 02:48, Alexandre Courbot wrote: On Tue, Mar 18, 2014 at 7:41 PM, Ben Dooks wrote: Some of the gpiod_ calls take a pointer to a gpio_desc as their argument but only check to see if it is NULL to validate the input. Calls such as devm_gpiod_get() return an error-pointer if they fail, so doing the following will not work: gpio = devm_gpiod_get(...); gpiod_direction_output(gpio, 0); The sequence produces an OOPS like: Unable to handle kernel paging request at virtual address fffe Change all calls that check for !desc to use IS_ERR_OR_NULL() to avoid these issues. This change is certainly correct from a semantics point of view. Maybe I'd argue that the burden is on the caller to check that gpiod_get() returns a valid GPIO descriptor, but having extra security doesn't hurt. However my problem with this change in its current form is that it will hide such forgetfulnesses by making functions like gpiod_get_value() fail silently instead of triggering a oops. On the other hand, it means that we do not have to keep checking the validity of the pointer in the caller. Could you make sure that any call of a gpiolib function on a non-valid descriptor raises at least a message in the console, and while you are at it harmonize the way these messages are output? Right now we are using pr_debug(), pr_warn() or WARN_ON() depending on the location. I would say that using an invalid GPIO descriptor is offending enough that it should trigger a stack dump at every attempt. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- 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/17 for-tip V3] A series patches about sched priority.
I picked up all except: 2 - whcih I don't think should go through a scheduler tree 6 - its tools/ bits, the changelog wasn't clear if the MIN/MAX_NICE macros were uapi visible and I couldn't be bothered to figure it out. 8 - I don't like the pointless macro -- 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] mfd: sec-core: Fix I2C dummy device resource leak on probe failure
> On 18 March 2014 18:27, Krzysztof Kozlowski wrote: > > Dummy I2C device allocated in sec_pmic_probe() leaked if > > devm_regmap_init_i2c() failed. Unregister it before returning from > > probe. > > > > Signed-off-by: Krzysztof Kozlowski > > Looks good. > Reviewed-by: Sachin Kamat Applied with Sachin's Ack. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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] gpiolib: check if gpio_desc pointer is error or NULL
On Wed, Mar 19, 2014 at 5:33 PM, Ben Dooks wrote: > On 19/03/14 02:48, Alexandre Courbot wrote: >> >> On Tue, Mar 18, 2014 at 7:41 PM, Ben Dooks >> wrote: >>> >>> Some of the gpiod_ calls take a pointer to a gpio_desc as their >>> argument but only check to see if it is NULL to validate the >>> input. >>> >>> Calls such as devm_gpiod_get() return an error-pointer if they >>> fail, so doing the following will not work: >>> >>> gpio = devm_gpiod_get(...); >>> gpiod_direction_output(gpio, 0); >>> >>> The sequence produces an OOPS like: >>> >>> Unable to handle kernel paging request at virtual address >>> fffe >>> >>> Change all calls that check for !desc to use IS_ERR_OR_NULL() to >>> avoid these issues. >> >> >> This change is certainly correct from a semantics point of view. Maybe >> I'd argue that the burden is on the caller to check that gpiod_get() >> returns a valid GPIO descriptor, but having extra security doesn't >> hurt. However my problem with this change in its current form is that >> it will hide such forgetfulnesses by making functions like >> gpiod_get_value() fail silently instead of triggering a oops. > > > On the other hand, it means that we do not have to keep checking > the validity of the pointer in the caller. A very scary perspective which I don't think we should support. Especially since the pointer only needs to be checked once, after gpiod_get() is called. -- 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/11] ARM: at91: rework main and slow clk implementation
Hi Boris, 2014-03-18 21:18 GMT+01:00 Boris BREZILLON : > > Hello, > > This series introduce the real clock model (as described in atmel datasheets) > for slow and main clocks. > > The modifications introduced by this series break the DT compat, but, as the > at91 CCF based implementation is pretty new (introduced in 3.14 only for sama5 > eval boards) I think it won't impact a lot of users. > > I tested it on sama5d3. > Alexandre, Jean-Jacques, could you test this series on your eval boards > (sam9261ek and sam9rlek) so that we can move to this new model and hopefully > consider the at91 clk DT binding as (almost :-)) stable. I'll try to do this this week, but I can make no promise > > Jean-Jacques, as you can see I reworked my first implementation as you > suggested, do you want me to add your Signed-off-by in the next version ? Nop, you did the job, not I. > > Mike, if this series is accepted, I'd like to get it merged as soon as > possible > to prevent other developpers from using a deprecated DT binding. > > Best Regards, > > Boris > > Boris BREZILLON (11): > clk: at91: rework main clk implementation > clk: at91: update main clk documentation > clk: at91: add slow clks driver > clk: at91: add slow clk documentation > ARM: at91/dt: move sama5d3 SoC to the new main/slow clk model > ARM: at91/dt: add xtal frequencies to sama5d3xcm boards > ARM: at91/dt: add xtal frequencies to sama5d3 xplained board > ARM: at91/dt: move at91sam9261 SoC to the new main clock model > ARM: at91/dt: define main xtal frequency of the at91sam9261ek board > ARM: at91/dt: move at91sam9rl SoC to the new slow/main clock models > ARM: at91/dt: define sam9rlek crystal frequencies > > .../devicetree/bindings/clock/at91-clock.txt | 128 - > arch/arm/boot/dts/at91-sama5d3_xplained.dts| 10 + > arch/arm/boot/dts/at91sam9261.dtsi | 10 +- > arch/arm/boot/dts/at91sam9261ek.dts|4 + > arch/arm/boot/dts/at91sam9rl.dtsi | 45 +- > arch/arm/boot/dts/at91sam9rlek.dts |8 + > arch/arm/boot/dts/sama5d3.dtsi | 61 +- > arch/arm/boot/dts/sama5d3xcm.dtsi | 10 + > drivers/clk/at91/Makefile |4 +- > drivers/clk/at91/clk-main.c| 581 > +--- > drivers/clk/at91/clk-slow.c| 467 > drivers/clk/at91/pmc.c | 12 + > drivers/clk/at91/pmc.h |9 + > drivers/clk/at91/sckc.c| 57 ++ > drivers/clk/at91/sckc.h| 22 + > include/linux/clk/at91_pmc.h |1 + > 16 files changed, 1342 insertions(+), 87 deletions(-) > create mode 100644 drivers/clk/at91/clk-slow.c > create mode 100644 drivers/clk/at91/sckc.c > create mode 100644 drivers/clk/at91/sckc.h > > -- > 1.7.9.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] mfd: sec-core: Fix uninitialized 'regmap_rtc' on S2MPA01
On Wed, 2014-03-19 at 13:57 +0530, Sachin Kamat wrote: > On 18 March 2014 18:41, Krzysztof Kozlowski wrote: > > Initialize the 'regmap_rtc' on S2MPA01 to some sane value. Sane at least > > for S5M87X chipsets, not S2MPS/S2MPA but it won't be used because > > rtc-s5m driver does not support S2MPA01. > > > > This fixes following error: > > drivers/mfd/sec-core.c:342:45: warning: 'regmap_rtc' may be used > > uninitialized in this function [-Wuninitialized] > > > > Signed-off-by: Krzysztof Kozlowski > > From the point of suppressing this warning and considering how it is > done for S2MPS11, > Acked-by: Sachin Kamat > > However, shouldn't we be making this RTC handling conditional/optional > depending upon > whether the h/w or s/w supports/implements it? I think the rtc-s5m driver should instantiate his regmap on its own. The same with i2c dummy device. This would remove problems with unsupported chipsets by rtc-s5m driver. Best regards, Krzysztof -- 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 v11 13/27] iommu/exynos: support for device tree
On Tue, 18 Mar 2014 16:46:24 +0530, Sachin Kamat wrote:
> On 18 March 2014 16:44, Cho KyongHo wrote:
> > On Fri, 14 Mar 2014 20:57:42 +0530, Sachin Kamat wrote:
> >> Hi KyongHo,
> >>
> >> On 14 March 2014 10:39, Cho KyongHo wrote:
> >> >
> >> > -static struct platform_driver exynos_sysmmu_driver = {
> >> > - .probe = exynos_sysmmu_probe,
> >> > - .driver = {
> >> > +#ifdef CONFIG_OF
> >>
> >> This is not needed as Exynos is DT only platform.
> >>
> > Yes, but I hesitate to remove that.
>
> What is the reason for your hesitation? :)
>
Actually, no reason because you mentioned that Exynos is DT only platofrm.
I will remove that.
Thank you.
KyongHo
--
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 2/4] hrtimer: export __hrtimer_start_range_ns
On Tue, Mar 18, 2014 at 04:56:42PM +0800, Yan, Zheng wrote: > export __hrtimer_start_range_ns() to allow building perf Intel uncore > driver as module Bah; you didn't cc the hrtimer maintainer. Thomas, ack on this? > Signed-off-by: Yan, Zheng > --- > kernel/hrtimer.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c > index 0909436..650bf38 100644 > --- a/kernel/hrtimer.c > +++ b/kernel/hrtimer.c > @@ -1030,6 +1030,7 @@ int __hrtimer_start_range_ns(struct hrtimer *timer, > ktime_t tim, > > return ret; > } > +EXPORT_SYMBOL_GPL(__hrtimer_start_range_ns); > > /** > * hrtimer_start_range_ns - (re)start an hrtimer on the current CPU > -- > 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 4/4] perf/x86/uncore: modularize Intel uncore driver
On Tue, Mar 18, 2014 at 04:56:44PM +0800, Yan, Zheng wrote: > This patch adds support for building Intel uncore driver as module. > It adds clean-up code and config option for the Intel uncore driver > > Signed-off-by: Yan, Zheng > --- > arch/x86/Kconfig | 7 > arch/x86/configs/i386_defconfig | 1 + > arch/x86/configs/x86_64_defconfig | 1 + > arch/x86/kernel/cpu/Makefile | 3 +- > arch/x86/kernel/cpu/perf_event_intel_uncore.c | 48 > --- > 5 files changed, 55 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 0af5250..8e4e247 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1103,6 +1103,13 @@ config X86_CPUID > with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to > /dev/cpu/31/cpuid. > > +config X86_INTEL_UNCORE > + tristate "Intel uncore performance monitoring support" > + depends on CPU_SUP_INTEL > + ---help--- > + This adds a driver to access the Uncore performance monitoring Units > + of Intel processors. > + Ingo do you agree with this config option placement? -- 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 3/4] blk-mq: replace blk_mq_init_commands with a ->init_request method
On Wed, Mar 19, 2014 at 3:54 PM, Christoph Hellwig wrote: > On Wed, Mar 19, 2014 at 11:08:20AM +0800, Ming Lei wrote: >> > + blk_rq_init(q, q->flush_rq); >> > + if (reg->cmd_size) >> > + q->flush_rq->special = >> > + blk_mq_rq_to_pdu(q->flush_rq); >> > + >> > + if (reg->ops->init_request(driver_data, >> > + NULL, q->flush_rq, -1)) >> > + goto err_flush_rq; >> > + } >> >> The above looks a bit weird because q->flush_rq is invisible to >> driver and should always be initialized no matter if driver defines >> its .init_request callback or not. > > You mean the blk_rq_init? We already do a real initialization before > actually using it, it's just there to prevent passing a half-initialized > one to the driver. > OK. Actually it doesn't matter because flush_rq will be reinitialized before using, not like common request. And driver should only initialize req->special instead of the request itself, maybe it is better to document the fact. Thanks, -- Ming Lei -- 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] mfd: mc13xxx: Move definitions out of structures
On Tue, 18 Mar 2014, Bryan Wu wrote:
> On Tue, Mar 18, 2014 at 2:40 AM, Lee Jones wrote:
> >> > > > > Signed-off-by: Alexander Shiyan
> >> > > > > ---
> >> > > > > include/linux/mfd/mc13xxx.h | 22 --
> >> > > > > 1 file changed, 12 insertions(+), 10 deletions(-)
> >> > > > >
> >> > > > > diff --git a/include/linux/mfd/mc13xxx.h
> >> > > > > b/include/linux/mfd/mc13xxx.h
> >> > > > > index a326c85..d63b1d3 100644
> >> > > > > --- a/include/linux/mfd/mc13xxx.h
> >> > > > > +++ b/include/linux/mfd/mc13xxx.h
> >> > > > > @@ -117,10 +117,6 @@ struct mc13xxx_led_platform_data {
> >> > > > >
> >> > > > > #define MAX_LED_CONTROL_REGS 6
> >> > > > >
> >> > > > > -struct mc13xxx_leds_platform_data {
> >> > > > > - struct mc13xxx_led_platform_data *led;
> >> > > > > - int num_leds;
> >> > > > > -
> >> > > > > /* MC13783 LED Control 0 */
> >> > > > > #define MC13783_LED_C0_ENABLE(1 << 0)
> >> > > > > #define MC13783_LED_C0_TRIODE_MD (1 << 7)
> >> > > > > @@ -169,10 +165,13 @@ struct mc13xxx_leds_platform_data {
> >> > > > > /* MC34708 LED Control 0 */
> >> > > >
> >> > > > I don't see the line above in the MFD tree?
> >> > > >
> >> > > > Which commit/branch/repo is this patch based on?
> >> > >
> >> > > Dependency:
> >> > > linux-next, a59ce6584d (leds: leds-mc13783: Add MC34708 LED support)
> >> > >
> >> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/include/linux/mfd/mc13xxx.h?id=a59ce6584d566847980f9dcad5343cd9856145c8
> >> >
> >> > Ah, you can't do that, as it will cause conflicts and Linus will
> >> > likely get upset.
> >>
> >> So what do we do now? What is the solution?
> >
> > Don't worry about it. Bryan and I should be able to sort something out.
>
> I lost the context here.
>
> I merged Alexander's patch as a59ce6584d566847980f9dcad5343cd9856145c8
> which modified the mc13xxx.h. But all things are related to LED driver
> and only add several lines. Next time I will ask Lee to give an review
> and ack.
>
> So probably this patch has to wait for
> a59ce6584d566847980f9dcad5343cd9856145c8 merged.
Yes, I think this is the best idea.
Alexander, can you re-send this patch with my Ack after the next merge
window please?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v11 10/27] iommu/exynos: use managed device helper functions
On Wed, 19 Mar 2014 08:59:09 +0900, Jingoo Han wrote:
> On Wednesday, March 19, 2014 12:12 AM, Tomasz Figa wrote:
> > On 18.03.2014 11:38, Cho KyongHo wrote:
> > > On Fri, 14 Mar 2014 14:28:36 +0100, Tomasz Figa wrote:
> > >> On 14.03.2014 06:05, Cho KyongHo wrote:
> > >>> This patch uses managed device helper functions in the probe().
> > >>>
> > >>> Signed-off-by: Cho KyongHo
> > >>> ---
> > >>>drivers/iommu/exynos-iommu.c | 64
> > >>> +-
> > >>>1 file changed, 26 insertions(+), 38 deletions(-)
> > >>>
> > >>> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > >>> index 36e6b73..33b424d 100644
> > >>> --- a/drivers/iommu/exynos-iommu.c
> > >>> +++ b/drivers/iommu/exynos-iommu.c
>
> [.]
>
> > >>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > >>> if (!res) {
> > >>> - dev_dbg(dev, "Unable to find IOMEM region\n");
> > >>> - ret = -ENOENT;
> > >>> - goto err_init;
> > >>> + dev_err(dev, "Unable to find IOMEM region\n");
> > >>> + return -ENOENT;
> > >>> }
> > >>
> > >> No need to check for error and print message, because
> > >> devm_ioremap_resource() already checks the passed resource and handles
> > >> error cases.
> > >>
> > >
> > > Yes but devm_ioremap_resource() just tells that the given 'res' is not
> > > correct. I think the message in the driver is more informative.
> >
> > The common practice used in Linux kernel is to not duplicate such
> > messages. It is obvious that devm_ioremap_resource() printing such
> > message is related to an IOMEM resource anyway, as you can't used it
> > with other types of resources.
>
> +1
>
> I agree with Tomasz Figa's opinion.
> These messages have been being removed from Linux kernel.
> Thank you.
>
Ok.
Thank you for the advice.
Kyong Ho
--
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 v11 10/27] iommu/exynos: use managed device helper functions
On Tue, 18 Mar 2014 16:14:53 +0100, Tomasz Figa wrote:
> On 18.03.2014 12:09, Cho KyongHo wrote:
> > On Fri, 14 Mar 2014 20:52:43 +0530, Sachin Kamat wrote:
> >> Hi KyongHo,
> >>
> >> On 14 March 2014 10:35, Cho KyongHo wrote:
> >>> This patch uses managed device helper functions in the probe().
> >>>
> >>> Signed-off-by: Cho KyongHo
> >>> ---
> >> [snip]
> >>
> >>> + data->clk = devm_clk_get(dev, "sysmmu");
> >>> + if (IS_ERR(data->clk)) {
> >>> + dev_info(dev, "No gate clock found!\n");
> >>> + data->clk = NULL;
> >>> + }
> >>
> >> Why aren't you returning from here upon error?
> >
> > It is for the case of a System MMU which does not need clock gating.
> >
>
> Are there really such cases?
>
Yes.
Especially in the case of initial stage of new SoC development.
I have experianced some software workaround for H/W restriction
needs prevention of clock gating for some devices.
Regards,
KyongHo
--
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 v11 10/27] iommu/exynos: use managed device helper functions
On 19 March 2014 14:29, Cho KyongHo wrote:
> On Tue, 18 Mar 2014 16:14:53 +0100, Tomasz Figa wrote:
>> On 18.03.2014 12:09, Cho KyongHo wrote:
>> > On Fri, 14 Mar 2014 20:52:43 +0530, Sachin Kamat wrote:
>> >> Hi KyongHo,
>> >>
>> >> On 14 March 2014 10:35, Cho KyongHo wrote:
>> >>> This patch uses managed device helper functions in the probe().
>> >>>
>> >>> Signed-off-by: Cho KyongHo
>> >>> ---
>> >> [snip]
>> >>
>> >>> + data->clk = devm_clk_get(dev, "sysmmu");
>> >>> + if (IS_ERR(data->clk)) {
>> >>> + dev_info(dev, "No gate clock found!\n");
>> >>> + data->clk = NULL;
>> >>> + }
>> >>
>> >> Why aren't you returning from here upon error?
>> >
>> > It is for the case of a System MMU which does not need clock gating.
>> >
>>
>> Are there really such cases?
>>
>
> Yes.
> Especially in the case of initial stage of new SoC development.
>
> I have experianced some software workaround for H/W restriction
> needs prevention of clock gating for some devices.
So aren't these basically some exceptions/hacks rather than the usual way
of functioning of the device?
--
With warm regards,
Sachin
--
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] Documentation: Add device tree bindings for DA9063 PMIC
This patch adds device tree binding documentation for the Dialog Semiconductors
DA9063 PMIC and its regulator nodes.
Signed-off-by: Philipp Zabel
---
.../devicetree/bindings/mfd/da9063-i2c.txt | 68 ++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/da9063-i2c.txt
diff --git a/Documentation/devicetree/bindings/mfd/da9063-i2c.txt
b/Documentation/devicetree/bindings/mfd/da9063-i2c.txt
new file mode 100644
index 000..776b662
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/da9063-i2c.txt
@@ -0,0 +1,68 @@
+* Dialog DA9063 Power Management Integrated Circuit (PMIC)
+
+Required properties:
+- compatible : Should be "dialog,da9063"
+- interrupt-parent : phandle pointing to the interrupt controller
+- interrupts : interrupt number and flags in interrupt-parent
+ for the chip IRQ line. Interrupt bindings are documented here:
+ Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+Sub-nodes:
+- regulators : Contain the regulator nodes. The DA9063 regulators are
+ bound using their names as listed below:
+
+bcore1 : regulator BCORE1
+bcore2 : regulator BCORE2
+bpro : regulator BPRO
+bmem : regulator BMEM
+bio: regulator BIO
+bperi : regulator BPERI
+ldo1 : regulator LDO1
+ldo2 : regulator LDO4
+ldo3 : regulator LDO3
+ldo4 : regulator LDO4
+ldo5 : regulator LDO5
+ldo6 : regulator LDO6
+ldo7 : regulator LDO7
+ldo8 : regulator LDO8
+ldo9 : regulator LDO9
+ldo10 : regulator LDO10
+ldo11 : regulator LDO11
+
+ The PMIC can also be configured to merge both bcore1/2 into a single
+ supply and to merge bmem and bio into a single supply. In this case,
+ the following regulators are bound instead of bcore1/2 and bpro/bmem:
+
+bcores-merged : merged regulators BCORE1, BCORE2
+bmem-bio-merged : merged regulators BMEM, BIO
+
+ See Documentation/devicetree/bindings/regulator/regulator.txt for
+ binding details of individual regulator device nodes.
+
+
+Examples:
+
+&i2c1 {
+ status = "okay";
+
+ pmic@58 {
+ compatible = "dialog,da9063";
+ reg = <0x58>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <17 0x8>; /* active-low GPIO4_17 */
+
+ regulators {
+ bcore1 {
+ regulator-min-microvolt = <30>;
+ regulator-max-microvolt = <157>;
+ };
+
+ bcore2 {
+ regulator-min-microvolt = <30>;
+ regulator-max-microvolt = <157>;
+ };
+
+ /* ... */
+ };
+ };
+};
--
1.9.0
--
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] mfd: mc13xxx: Move definitions out of structures
Wed, 19 Mar 2014 08:51:44 + от Lee Jones :
> On Tue, 18 Mar 2014, Bryan Wu wrote:
>
> > On Tue, Mar 18, 2014 at 2:40 AM, Lee Jones wrote:
> > >> > > > > Signed-off-by: Alexander Shiyan
> > >> > > > > ---
> > >> > > > > include/linux/mfd/mc13xxx.h | 22 --
> > >> > > > > 1 file changed, 12 insertions(+), 10 deletions(-)
> > >> > > > >
> > >> > > > > diff --git a/include/linux/mfd/mc13xxx.h
> > >> > > > > b/include/linux/mfd/mc13xxx.h
> > >> > > > > index a326c85..d63b1d3 100644
> > >> > > > > --- a/include/linux/mfd/mc13xxx.h
> > >> > > > > +++ b/include/linux/mfd/mc13xxx.h
> > >> > > > > @@ -117,10 +117,6 @@ struct mc13xxx_led_platform_data {
> > >> > > > >
> > >> > > > > #define MAX_LED_CONTROL_REGS 6
> > >> > > > >
> > >> > > > > -struct mc13xxx_leds_platform_data {
> > >> > > > > - struct mc13xxx_led_platform_data *led;
> > >> > > > > - int num_leds;
> > >> > > > > -
> > >> > > > > /* MC13783 LED Control 0 */
> > >> > > > > #define MC13783_LED_C0_ENABLE(1 << 0)
> > >> > > > > #define MC13783_LED_C0_TRIODE_MD (1 << 7)
> > >> > > > > @@ -169,10 +165,13 @@ struct mc13xxx_leds_platform_data {
> > >> > > > > /* MC34708 LED Control 0 */
> > >> > > >
> > >> > > > I don't see the line above in the MFD tree?
> > >> > > >
> > >> > > > Which commit/branch/repo is this patch based on?
> > >> > >
> > >> > > Dependency:
> > >> > > linux-next, a59ce6584d (leds: leds-mc13783: Add MC34708 LED support)
> > >> > >
> > >> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/include/linux/mfd/mc13xxx.h?id=a59ce6584d566847980f9dcad5343cd9856145c8
> > >> >
> > >> > Ah, you can't do that, as it will cause conflicts and Linus will
> > >> > likely get upset.
> > >>
> > >> So what do we do now? What is the solution?
> > >
> > > Don't worry about it. Bryan and I should be able to sort something out.
> >
> > I lost the context here.
> >
> > I merged Alexander's patch as a59ce6584d566847980f9dcad5343cd9856145c8
> > which modified the mc13xxx.h. But all things are related to LED driver
> > and only add several lines. Next time I will ask Lee to give an review
> > and ack.
> >
> > So probably this patch has to wait for
> > a59ce6584d566847980f9dcad5343cd9856145c8 merged.
>
> Yes, I think this is the best idea.
>
> Alexander, can you re-send this patch with my Ack after the next merge
> window please?
Sure.
---
Re: [PATCH v11 13/27] iommu/exynos: support for device tree
On Tue, 18 Mar 2014 16:25:11 +0100, Tomasz Figa wrote:
> On 18.03.2014 11:52, Cho KyongHo wrote:
> > On Fri, 14 Mar 2014 14:39:33 +0100, Tomasz Figa wrote:
> >>> @@ -557,11 +558,23 @@ static int exynos_sysmmu_probe(struct
> >>> platform_device *pdev)
> >>> return 0;
> >>>}
> >>>
> >>> -static struct platform_driver exynos_sysmmu_driver = {
> >>> - .probe = exynos_sysmmu_probe,
> >>> - .driver = {
> >>> +#ifdef CONFIG_OF
> >>> +static struct of_device_id sysmmu_of_match[] __initconst = {
> >>> + { .compatible = "samsung,sysmmu-v1", },
> >>> + { .compatible = "samsung,sysmmu-v2", },
> >>> + { .compatible = "samsung,sysmmu-v3.1", },
> >>> + { .compatible = "samsung,sysmmu-v3.2", },
> >>> + { .compatible = "samsung,sysmmu-v3.3", },
> >>
> >> Do you need all these compatible strings? I mean, are there any
> >> implementation differences that can't be identified by reading IP
> >> registers, such as REG_MMU_VERSION?
> >>
> >
> > Unfortunately, there is a SoC which overrides REG_MMU_VERSION with
> > a value for RTL designers and it is not related to System MMU
> > versions.
>
> OK.
>
> What about having a generic compatible string for Samsung SysMMU then,
> but an additional property that can override the version to account for
> such brokenness? If not provided, the version would be read from
> REG_MMU_VERSION.
>
Yes it is one of possible idea.
Let me think what better way is.
Thank you.
KyongHo
--
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/2] mfd: tps65910: Fix possible invalid pointer dereference on regmap_add_irq_chip fail
> tps65910_irq_init() sets the 'tps65910->chip_irq' before calling
> regmap_add_irq_chip(). If this regmap_add_irq_chip() call fails in
> memory allocation of regmap_irq_chip_data members then:
> 1. The 'tps65910->chip_irq' will still hold some value;
> 2. 'tps65910->irq_data' will be pointing to already freed memory
>(because regmap_add_irq_chip() will free it on error);
>
> This results in invalid memory access during driver remove because the
> tps65910_irq_exit() tests whether 'tps65910->chip_irq' is not null.
>
> Signed-off-by: Krzysztof Kozlowski
> Cc:
> Fixes: 4aab3fadad32 ("mfd: tps65910: Move interrupt implementation code to
> mfd file")
> ---
> drivers/mfd/tps65910.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Applied after cleaning up the commit message a little.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 2/2] mfd: tps65910: Fix regmap_irq_chip_data leak on mfd_add_devices fail
> The tps65910_i2c_probe() allocates regmap_irq_chip in > tps65910_irq_init() but it does not clean this up in case of > mfd_add_devices() failure. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/mfd/tps65910.c |1 + > 1 file changed, 1 insertion(+) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v11 19/27] iommu/exynos: add support for power management subsystems.
On Tue, 18 Mar 2014 16:33:04 +0100, Tomasz Figa wrote: > On 18.03.2014 12:23, Cho KyongHo wrote: > > On Fri, 14 Mar 2014 17:07:53 +0100, Tomasz Figa wrote: > >> Hi KyongHo, > >> > >> On 14.03.2014 06:10, Cho KyongHo wrote: > > [snip] > > >>> @@ -677,11 +679,40 @@ static int __init exynos_sysmmu_probe(struct > >>> platform_device *pdev) > >>> platform_set_drvdata(pdev, data); > >>> > >>> pm_runtime_enable(dev); > >>> + data->runtime_active = !pm_runtime_enabled(dev); > >> > >> Hmm, this seems to be a bit misleading. The field is named > >> runtime_active, but the assignment makes it true if PM runtime is _not_ > >> enabled (i.e. inactive). Is this correct? > >> > > > > I agree that it may lead misunderstood. > > data->runtime_active actually indicates if electric power is asserted > > to the System MMU. pm_runtime_enable() call must enable runtime pm > > for the given device. If runtime pm is not enabled although > > pm_runtime_enable() > > is called, CONFIG_PM_RUNTIME is not configured. > > > > Actually, it is replacible with > > if (IS_ENABLED(CONFIG_PM_RUNTIME)) > > data->runtime_active = true; > > I would keep it as !pm_runtime_enabled(dev), but rename the field to > something more meaningful, like data->is_powered_on. > That is good idea. thanks for advice. KyongHo. -- 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 3/5] regulator: arizona-ldo1: Move setup processing from arizona-core
On Tue, Mar 18, 2014 at 05:44:30PM +, Mark Brown wrote: > On Tue, Mar 18, 2014 at 05:22:31PM +, Charles Keepax wrote: > > > - /* > > -* LDO1 can only be used to supply DCVDD so if it has no > > -* consumers then DCVDD is supplied externally. > > -*/ > > - if (arizona->pdata.ldo1 && > > - arizona->pdata.ldo1->num_consumer_supplies == 0) > > - arizona->external_dcvdd = true; > > - > > Actually now that I look at this again one issue here - the reason this > is in the core is that if the system is using an external DCVDD it may > not be building the regulator driver at all (it won't do anything at > runtime) so the flag would never get set if it's done by the regulator > driver. Ah... missed that. I will respin again. Thanks, Charles -- 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: For review: open_by_name_at(2) man page
Hi Neil,
On 03/18/2014 11:24 PM, NeilBrown wrote:
> On Tue, 18 Mar 2014 13:37:15 +0100 "Michael Kerrisk (man-pages)"
> wrote:
>
>> On 03/18/2014 10:43 AM, Christoph Hellwig wrote:
>>> On Tue, Mar 18, 2014 at 09:00:07AM +1100, NeilBrown wrote:
ESTALE is also returned if the filesystem does not support file-handle ->
file mappings.
On filesystems which don't provide export_operations (/sys /proc ubifs
romfs cramfs nfs coda ... several others) name_to_handle_at will produce a
generic handle using the 32 bit inode and 32 bit i_generation.
>>>
>>> Do we? Seems like the code is erroring out early if there are no
>>> export_ops?
>>
>> It appears to me that Neil's statement isn't correct, at least for /proc
>> and /sys (see my other mail, to Neil). I'm unsure about whether it is true
>> for some of those other FSes thought.
>
>
> Indeed, I was wrong.
>
> I was looking at
>
> int exportfs_encode_inode_fh(struct inode *inode, struct fid *fid,
>int *max_len, struct inode *parent)
> {
> const struct export_operations *nop = inode->i_sb->s_export_op;
>
> if (nop && nop->encode_fh)
> return nop->encode_fh(inode, fid->raw, max_len, parent);
>
> return export_encode_fh(inode, fid, max_len, parent);
> }
>
>
> which uses a default if there is no 'nop'.
>
> However do_sys_name_to_handle() contains
>
> if (!path->dentry->d_sb->s_export_op ||
> !path->dentry->d_sb->s_export_op->fh_to_dentry)
> return -EOPNOTSUPP;
>
> long before export_encode_inode_fh() gets called. So the default isn't used.
Okay.
> I would have thought that exportfs_encode_inode_fh would never get called if
> there were no s_export_op pointer - certainly name_to_handle_at and nfsd
> would never call it in that case.
> However it seems that
>
> This routine will be used to generate a file handle in fdinfo output for
> inotify subsystem, where if no s_export_op present the general
> export_encode_fh should be used. Thus add a test if s_export_op present
> inside exportfs_encode_fh itself.
>
> according to
>
> commit ab49bdecc3ebb46ab661f5f05d5c5ea9606406c6
> Author: Cyrill Gorcunov
> Date: Mon Dec 17 16:05:06 2012 -0800
>
>
> I guess that means that you can extract filehandles from /proc/self/fdinfo/$FD
> when $FD is an inotify fd which is watching the particular file. I
> wouldn't have expected that, but maybe it is a good idea.
Yes, it does--I tested it, and it works! I was unaware of this feature,
though I'm not sure that I'll add anything to a man page just yet.
> So yes: if the filesystem doesn't support filehandles you get EOPNOTSUPP.
> So if you get ESTALE from open_by_handle_at(), then it really is a stale
> handle. Sorry for the confusion.
Yup, I've updated the page now.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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: For review: open_by_name_at(2) man page [v2]
[CC =+ Al Viro] Hi Neil, On 03/19/2014 05:13 AM, NeilBrown wrote: > On Tue, 18 Mar 2014 13:55:15 +0100 "Michael Kerrisk (man-pages)" > wrote: > >> Hi Aneesh, (and others) >> >> After integrating review comments from NeilBown and Christoph Hellwig, >> here is draft 2 of a man page I've written for name_to_handle_at(2) and >> open_by_name_at(2). Especially thanks to Neil's comments, several parts >> of the page underwent a substantial rewrite. Would you be willing to >> review it please, and let me know of any corrections/improvements? [various typos you reported fixed now.] >> .TP >> .B AT_EMPTY_PATH >> Allow >> .I pathname >> to be an empty string. >> See above. >> (which may have been obtained using the >> .BR open (2) >> .B O_PATH >> flag). > > What "may have been obtained" ?? Crufty text. gone now. >> The >> .I flags >> argument >> is as for >> .BR open (2). >> .\" FIXME: Confirm that the following is intended behavior. >> .\"(It certainly seems to be the behavior, from experimenting.) >> If >> .I handle >> refers to a symbolic link, the caller must specify the >> .B O_PATH >> flag, and the symbolic link is not dereferenced (the >> .B O_NOFOLLOW >> flag, if specified, is ignored). > > It certainly sounds like reasonable behaviour. I cannot comment on intention > though. > Are you bothered that O_PATH is needed for symlinks? No. > An fd on a symlink is a > sufficiently unusual thing that it seems reasonable for a programmer to > explicitly say they are expecting one. I think the point is this: If you have a file handle for a symlink, then you can't follow the symlink, which is why you must specify O_PATH and O_NOFOLLOW becomes irrelevant. I'm curious about the rationale though. I suspect it's something like: the process receiving the handle doesn't have enough information for the symlink to be interpreted, I think because it can;t reliably determine what directory the link lives in. Possibly Al Viro or Aneesh can confirm. >> In the event of an error, both system calls return \-1 and set >> .I errno >> to indicate the cause of the error. >> .SH ERRORS >> .BR name_to_handle_at () >> and >> .BR open_by_handle_at () >> can fail for the same errors as >> .BR openat (2). >> In addition, they can fail with the errors noted below. > > Should you mention EFAULT if mount_id or handle are not valid pointers? Done. >> Not all filesystem types support the translation of pathnames to >> file handles. >> .\" FIXME NeilBrown noted: >> .\"ESTALE is also returned if the filesystem does not support >> .\"file-handle -> file mappings. >> .\"On filesystems which don't provide export_operations (/sys /proc >> .\"ubifs romfs cramfs nfs coda ... several others) name_to_handle_at >> .\"will produce a generic handle using the 32 bit inode and 32 bit >> .\"i_generation. open_by_name_at given this (or any) filehandle >> .\"will fail with ESTALE. >> .\" However, on /proc and /sys, at least, name_to_handle_at() fails with >> .\" EOPNOTSUPP. Are there really filesystems that can deliver ESTALE (the >> .\" same error as for an invalid file handle) in the above circumstances? > > This is all wrong - discard it :-) Yup. Gone now ;-). Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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] mfd: sec-core: Fix uninitialized 'regmap_rtc' on S2MPA01
> Initialize the 'regmap_rtc' on S2MPA01 to some sane value. Sane at least > for S5M87X chipsets, not S2MPS/S2MPA but it won't be used because > rtc-s5m driver does not support S2MPA01. > > This fixes following error: > drivers/mfd/sec-core.c:342:45: warning: ‘regmap_rtc’ may be used > uninitialized in this function [-Wuninitialized] > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/mfd/sec-core.c |7 +++ > 1 file changed, 7 insertions(+) Please don't send patches in the middle of threads like this (v2's are a different story as it saves on re-sending entire patch-sets), as I very nearly missed it. We already have drivers doing similar things so I'll apply this as a temporary fix, but please find something a little less 'hacky' to supersede it _soon_. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: [RFC V2] cpufreq: make sure frequency transitions are serialized
On 03/19/2014 11:38 AM, Viresh Kumar wrote:
> On 18 March 2014 18:20, Srivatsa S. Bhat
> wrote:
>> On 03/14/2014 01:13 PM, Viresh Kumar wrote:
>>> + if ((state != CPUFREQ_PRECHANGE) && (state != CPUFREQ_POSTCHANGE))
>>
>> Wait a min, when is this condition ever true? I mean, what else can
>> 'state' ever be, apart from CPUFREQ_PRECHANGE and POSTCHANGE?
>
> There were two more 'unused' states available:
> CPUFREQ_RESUMECHANGE and CPUFREQ_SUSPENDCHANGE
>
> I have sent a patch to remove them now and this code would go away..
>
Ok..
>>> + return notify_transition_for_each_cpu(policy, freqs, state);
>>> +
>>> + /* Serialize pre-post notifications */
>>> + mutex_lock(&policy->transition_lock);
>>
>> Nope, this is definitely not the way to go, IMHO. We should enforce that
>> the *callers* serialize the transitions, something like this:
>>
>> cpufreq_transition_lock();
>>
>> cpufreq_notify_transition(CPUFREQ_PRECHANGE);
>>
>> //Perform the frequency change
>>
>> cpufreq_notify_transition(CPUFREQ_POSTCHANGE);
>>
>> cpufreq_transition_unlock();
>>
>> That's it!
>>
>> [ We can either introduce a new "transition" lock or perhaps even reuse
>> the cpufreq_driver_lock if it fits... but the point is, the _caller_ has
>> to perform the locking; trying to be smart inside cpufreq_notify_transition()
>> is a recipe for headache :-( ]
>>
>> Is there any problem with this approach due to which you didn't take
>> this route?
>
Wait, I think I remember. The problem was about dealing with drivers that
do asynchronous notification (those that have the ASYNC_NOTIFICATION flag
set). In particular, exynos-5440 driver sends out the POSTCHANGE notification
from a workqueue worker, much later than sending the PRECHANGE notification.
>From what I saw, this is how the exynos-5440 driver works:
1. ->target() is invoked, and the driver writes to a register and returns
to its caller.
2. An interrupt occurs that indicates that the frequency was changed.
3. The interrupt handler kicks off a worker thread which then sends out
the POSTCHANGE notification.
So the important question here is, how does the exynos-5440 driver
protect itself from say 2 ->target() calls which occur in close sequence
(before allowing the entire chain for the first call to complete)?
As far as I can see there is no such synchronization in the driver at
the moment. Adding Amit to CC for his comments.
Regards,
Srivatsa S. Bhat
> I didn't wanted drivers to handle this as core must make sure things are in
> order. Over that it would have helped by not pasting redundant code
> everywhere..
>
> Drivers are anyway going to call cpufreq_notify_transition(), why increase
> burden on them?
>
>>> + if (unlikely(WARN_ON(!policy->transition_ongoing &&
>>> + (state == CPUFREQ_POSTCHANGE {
>>> + mutex_unlock(&policy->transition_lock);
>>> + return;
>>> + }
>>> +
>>> + if (state == CPUFREQ_PRECHANGE) {
>>> + while (policy->transition_ongoing) {
>>> + mutex_unlock(&policy->transition_lock);
>>> + /* TODO: Can we do something better here? */
>>> + cpu_relax();
>>> + mutex_lock(&policy->transition_lock);
>>
>> If the caller takes care of the synchronization, we can avoid
>> these sorts of acrobatics ;-)
>
> If we are fine with taking a mutex for the entire transition, then
> we can avoid above kind of acrobatics by just taking the mutex
> from PRECHANGE and leaving it at POSTCHANGE..
>
> It will look like this then, hope this looks fine :)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2677ff1..3b9eac4 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -335,8 +335,15 @@ static void __cpufreq_notify_transition(struct
> cpufreq_policy *policy,
> void cpufreq_notify_transition(struct cpufreq_policy *policy,
> struct cpufreq_freqs *freqs, unsigned int state)
> {
> + if (state == CPUFREQ_PRECHANGE)
> + mutex_lock(&policy->transition_lock);
> +
> + /* Send notifications */
> for_each_cpu(freqs->cpu, policy->cpus)
> __cpufreq_notify_transition(policy, freqs, state);
> +
> + if (state == CPUFREQ_POSTCHANGE)
> + mutex_unlock(&policy->transition_lock);
> }
> EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
>
> @@ -983,6 +990,7 @@ static struct cpufreq_policy *cpufreq_policy_alloc(void)
>
> INIT_LIST_HEAD(&policy->policy_list);
> init_rwsem(&policy->rwsem);
> + mutex_init(&policy->transition_lock);
>
> return policy;
>
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 31c431e..5f9209a 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -104,6 +104,7 @@ struct cpufreq_policy {
> * __cpufreq_governor(data, CPUFREQ_GOV_P
Re: [PATCH] [media] ov2640: add support for async device registration
Hi, Sylwester
Thanks for your review.
On 3/15/2014 5:17 AM, Sylwester Nawrocki wrote:
Hi Josh,
On 03/14/2014 11:12 AM, Josh Wu wrote:
+clk = v4l2_clk_get(&client->dev, "mclk");
+if (IS_ERR(clk))
+return -EPROBE_DEFER;
You should instead make it:
return PTR_ERR(clk);
But you will need this patch for that to work:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/clk/clk.c?id=a34cd4666f3da84228a82f70c94b8d9b692034ea
With this patch there is no need to overwrite any returned error
value with EPROBE_DEFER.
Thanks for the information. I will use this in v2 version.
Best Regards,
Josh Wu
@@ -1097,23 +1106,26 @@ static int ov2640_probe(struct i2c_client
*client,
v4l2_ctrl_new_std(&priv->hdl,&ov2640_ctrl_ops,
V4L2_CID_HFLIP, 0, 1, 1, 0);
priv->subdev.ctrl_handler =&priv->hdl;
-if (priv->hdl.error)
-return priv->hdl.error;
-
-priv->clk = v4l2_clk_get(&client->dev, "mclk");
-if (IS_ERR(priv->clk)) {
-ret = PTR_ERR(priv->clk);
-goto eclkget;
--
Regards,
Sylwester
--
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: [RFC V2] cpufreq: make sure frequency transitions are serialized
On 19 March 2014 14:47, Srivatsa S. Bhat wrote: > Wait, I think I remember. The problem was about dealing with drivers that > do asynchronous notification (those that have the ASYNC_NOTIFICATION flag > set). In particular, exynos-5440 driver sends out the POSTCHANGE notification > from a workqueue worker, much later than sending the PRECHANGE notification. > > From what I saw, this is how the exynos-5440 driver works: > > 1. ->target() is invoked, and the driver writes to a register and returns >to its caller. > > 2. An interrupt occurs that indicates that the frequency was changed. > > 3. The interrupt handler kicks off a worker thread which then sends out >the POSTCHANGE notification. Correct!! > So the important question here is, how does the exynos-5440 driver > protect itself from say 2 ->target() calls which occur in close sequence > (before allowing the entire chain for the first call to complete)? > > As far as I can see there is no such synchronization in the driver at > the moment. Adding Amit to CC for his comments. Yes, and that's what my patch is trying to fix. Where is the confusion? -- 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 02/12] can: c_can: Fix hardware raminit function
On Wed, 19 Mar 2014, Oliver Hartkopp wrote:
> On 18.03.2014 23:15, Thomas Gleixner wrote:
> > On Tue, 18 Mar 2014, Marc Kleine-Budde wrote:
> >> On 03/18/2014 06:19 PM, Thomas Gleixner wrote:
> >>> +static void c_can_hw_raminit_wait(const struct c_can_priv *priv, u32
> >>> mask,
> >>> + u32 val)
> >>> +{
> >>> + /* We look only at the bits of our instance. */
> >>> + val &= mask;
> >>> + while ((readl(priv->raminit_ctrlreg) & mask) != val)
> >>> + udelay(1);
> >>
> >> Do we have to add a timeout here, or is it "safe" to have a potential
> >> endless loop here? As you have probably tortured the hardware and driver
> >> a lot (or have been tortured by them), I assume you would have added a
> >> timeout check if you had seen a lockup here.
> >
> > I haven't seen any failure on that. We could add a timeout for
> > paranoia reasons. I'm quite sure that the raminit works as advertised
> > when we do it the right way. The only way to wreckage it so far is by
> > not waiting for it to complete.
>
> As long as it is 100% guaranteed that we
>
> 1. really work on a valid C_CAN core
> 2. this CAN controller can not be unplugged
>
> not adding a timeout would be ok.
The raminit port is a D_CAN specific thing. But yeah, adding a timeout
wouldn't hurt at all.
Though the driver is incomplete anyway as not all D_CAN incarnations
use the raminit port. There is another way to do that via the CFR
register, which is not implemented in the driver.
It seems the chip integrator can chose between raminit port and CFR.
Thanks,
tglx
--
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/17 for-tip V3] A series patches about sched priority.
Hi Peter, On 03/19/2014 04:36 PM, Peter Zijlstra wrote: I picked up all except: 2 - whcih I don't think should go through a scheduler tree I will send it to sys maintainers. 6 - its tools/ bits, the changelog wasn't clear if the MIN/MAX_NICE macros were uapi visible and I couldn't be bothered to figure it out. Wow, yes it is not visible. 8 - I don't like the pointless macro Okey, Thanx Peter. -- 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/ -- 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/5] rtc: s5m: Add support for S2MPS14
Dear Alessandro Zummo,
I'm humbly reminding myself :). If these patches are OK can I have an
Ack from you so Lee Jones could apply them to MFD tree?
Best regards,
Krzysztof Kozlowski
On Fri, 2014-02-28 at 14:00 +0100, Krzysztof Kozlowski wrote:
> Hi,
>
>
> Few days ago I sent patches adding support for S2MPS14 device to the
> sec-core/s2mps11 drivers. These patches were rather large as they covered
> multiple subsystems so I decided to split everything into smaller, separate
> patches.
>
> The original patchset (version 3) can be found here:
> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/27194/focus=1649217
>
> This patchset is a small subset of above related to the S5M RTC driver.
> It adds support for the S2MPS14 device.
>
> These patches are rebased against Lee's "for-mfd-next" tree because they
> require
> changes in main MFD sec-core driver ("Add support for S2MPS14 for-mfd-next",
> which is already in Lee's "for-mfd-next" tree).
>
>
> Best regards,
> Krzysztof
>
> Krzysztof Kozlowski (5):
> mfd/rtc: sec/s5m: Rename SEC* symbols to S5M
> rtc: s5m: Remove undocumented time init on first boot
> rtc: s5m: Use shorter time of register update
> rtc: s5m: Support different register layout
> rtc: s5m: Add support for S2MPS14 RTC
>
> drivers/mfd/sec-core.c |2 +-
> drivers/rtc/Kconfig |4 +-
> drivers/rtc/rtc-s5m.c | 291
> ++-
> include/linux/mfd/samsung/rtc.h | 86 +++-
> 4 files changed, 249 insertions(+), 134 deletions(-)
>
--
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 0/5] compaction related commits
On 03/04/2014 01:23 AM, Joonsoo Kim wrote: > On Mon, Mar 03, 2014 at 12:02:00PM +0100, Vlastimil Babka wrote: >> On 02/14/2014 07:53 AM, Joonsoo Kim wrote: >>> changes for v2 >>> o include more experiment data in cover letter >>> o deal with vlastimil's comments mostly about commit description on 4/5 >>> >>> This patchset is related to the compaction. >>> >>> patch 1 fixes contrary implementation of the purpose of compaction. >>> patch 2~4 are for optimization. >>> patch 5 is just for clean-up. >>> >>> I tested this patchset with stress-highalloc benchmark on Mel's mmtest >>> and cannot find any regression in terms of success rate. And I find >>> much reduced(9%) elapsed time. >>> >>> Below is the average result of 10 runs on my 4GB quad core system. >>> >>> compaction-base+ is based on 3.13.0 with Vlastimil's recent fixes. >>> compaction-fix+ has this patch series on top of compaction-base+. >>> >>> Thanks. >>> >>> >>> stress-highalloc >>> 3.13.0 3.13.0 >>> compaction-base+compaction-fix+ >>> Success 1 14.10 15.00 >>> Success 2 20.20 20.00 >>> Success 3 68.30 73.40 >>> >>> >>> 3.13.0 3.13.0 >>> compaction-base+compaction-fix+ >>> User3486.02 3437.13 >>> System 757.92 741.15 >>> Elapsed 1638.52 1488.32 >>> >>> 3.13.0 3.13.0 >>> compaction-base+compaction-fix+ >>> Minor Faults172591561 167116621 >>> Major Faults 984 859 >>> Swap Ins 743 653 >>> Swap Outs 36573535 >>> Direct pages scanned 129742 127344 >>> Kswapd pages scanned 1852277 1817825 >>> Kswapd pages reclaimed 1838000 1804212 >>> Direct pages reclaimed129719 127327 >>> Kswapd efficiency98% 98% >>> Kswapd velocity 1130.0661221.296 >>> Direct efficiency99% 99% >>> Direct velocity 79.367 85.585 >>> Percentage direct scans 6% 6% >>> Zone normal velocity 231.829 246.097 >>> Zone dma32 velocity 972.5891055.158 >>> Zone dma velocity 5.015 5.626 >>> Page writes by reclaim 62876534 >>> Page writes file26302999 >>> Page writes anon36573535 >>> Page reclaim immediate 21872080 >>> Sector Reads 2917808 2877336 >>> Sector Writes 1147789111206722 >>> Page rescued immediate 0 0 >>> Slabs scanned2214118 2168524 >>> Direct inode steals121819788 >>> Kswapd inode steals 144830 132109 >>> Kswapd skipped wait0 0 >>> THP fault alloc0 0 >>> THP collapse alloc 0 0 >>> THP splits 0 0 >>> THP fault fallback 0 0 >>> THP collapse fail 0 0 >>> Compaction stalls738 714 >>> Compaction success 194 207 >>> Compaction failures 543 507 >>> Page migrate success 1806083 1464014 >>> Page migrate failure 0 0 >>> Compaction pages isolated3873329 3162974 >>> Compaction migrate scanned 7459486259874420 >>> Compaction free scanned 12554 110868637 >>> Compaction cost 24691998 >> >> FWIW, I've let a machine run the series with individual patches applied >> on 3.13 with my compaction patches, so 6 is the end of my series and 7-11 >> yours: >> The average is of 10 runs (in case you wonder how that's done, the success >> rates are >> calculated with a new R support that
Re: [PATCH v4 3/6] fat: zero out seek range on _fat_get_block
2014-03-18 23:59 GMT+09:00, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> +static void check_fallocated_region(struct inode *inode, sector_t
>> iblock,
>> +unsigned long *max_blocks, struct buffer_head *bh_result)
>> +{
>> +struct super_block *sb = inode->i_sb;
>> +sector_t last_block, disk_block;
>> +const unsigned long blocksize = sb->s_blocksize;
>> +const unsigned char blocksize_bits = sb->s_blocksize_bits;
>> +
>> +last_block = (MSDOS_I(inode)->mmu_private + (blocksize - 1))
>> +>> blocksize_bits;
>> +disk_block = (MSDOS_I(inode)->i_disksize + (blocksize - 1))
>> +>> blocksize_bits;
>> +if (iblock >= last_block && iblock <= disk_block) {
>
Hi OGAWA.
> Maybe off-by-one error. If iblock == disk_block, phys should not be set
> by fat_bmap()?
Yes, right, iblock == disk_block case is not needed in this condition
because fat_bmap don't set to phys when iblock==diskblock.(phys will
be 0)
So I will change it like this.
if (iblock >= last_block && iblock < disk_block) {
And I will fix your review comments in other patches.
Thanks for review!
> --
> OGAWA Hirofumi
>
--
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/
[BUG] Paravirtual time accounting / IRQ time accounting
In consolidated environments, when there are multiple virtual machines (VMs)
running on one CPU core, timekeeping will be a problem to the guest OS.
Here, I report my findings about Linux process scheduler.
Description
Linux CFS relies on rq->clock_task to charge each task, determine
vruntime, etc.
When CONFIG_IRQ_TIME_ACCOUNTING is enabled, the time spent on serving IRQ
will be excluded from updating rq->clock_task.
When CONFIG_PARAVIRT_TIME_ACCOUNTING is enabled, the time stolen by
the hypervisor
will also be excluded from updating rq->clock_task.
With "both" CONFIG_IRQ_TIME_ACCOUNTING and
CONFIG_PARAVIRT_TIME_ACCOUNTING enabled,
I put three KVM guests on one core and run hackbench in each guest. I
find that
in the guests, rq->clock_task stays *unchanged*. The malfunction
embarrasses CFS.
Analysis
[src/kernel/sched/core.c]
static void update_rq_clock_task(struct rq *rq, s64 delta)
{
... ...
#ifdef CONFIG_IRQ_TIME_ACCOUNTING
irq_delta = irq_time_read(cpu_of(rq)) - rq->prev_irq_time;
... ...
rq->prev_irq_time += irq_delta;
delta -= irq_delta;
#endif
#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
if (static_key_false((¶virt_steal_rq_enabled))) {
steal = paravirt_steal_clock(cpu_of(rq));
steal -= rq->prev_steal_time_rq;
... ...
rq->prev_steal_time_rq += steal;
delta -= steal;
}
#endif
rq->clock_task += delta;
... ...
}
--
"delta" -> the intended increment to rq->clock_task
"irq_delta" -> the time spent on serving IRQ (hard + soft)
"steal" -> the time stolen by the underlying hypervisor
--
"irq_delta" is calculated based on sched_clock_cpu(), which is vulnerable
to VM scheduling delays. "irq_delta" can include part or whole of "steal".
I observe that [irq_delta + steal >> delta].
As a result, "delta" becomes zero. That is why rq->clock_task stops.
Please confirm this bug. Thanks.
Luwei Cheng
--
CS student
The University of Hong Kong
--
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 0/3] perf tools: Add libdw DWARF post unwind support for ARM64
Adding libdw DWARF post unwind support, which is part of elfutils-devel/libdw-dev package from version 0.158. Also includes the test suite for dwarf unwinding, by adding the arch specific test code and the perf_regs_load function. This series depends on the following kernel patches series: - AARCH64 unwinding support [1], - ARM libdw integration [2], and on the changes from the branch for: - libdw AARCH64 unwinding support [3]. [1] http://www.spinics.net/lists/arm-kernel/msg304483.html [2] http://www.spinics.net/lists/arm-kernel/msg312423.html [3] https://git.fedorahosted.org/cgit/elfutils.git/log/?h=mjw/aarch64-unwind Jean Pihet (3): perf tests: Introduce perf_regs_load function on ARM64 perf tests: Add dwarf unwind test on ARM64 perf tools: Add libdw DWARF post unwind support for ARM64 tools/perf/Makefile.perf | 2 +- tools/perf/arch/arm64/Makefile | 7 tools/perf/arch/arm64/include/perf_regs.h | 5 +++ tools/perf/arch/arm64/tests/dwarf-unwind.c | 59 ++ tools/perf/arch/arm64/tests/regs_load.S| 39 tools/perf/arch/arm64/util/unwind-libdw.c | 53 +++ tools/perf/tests/builtin-test.c| 3 +- tools/perf/tests/tests.h | 3 +- 8 files changed, 168 insertions(+), 3 deletions(-) create mode 100644 tools/perf/arch/arm64/tests/dwarf-unwind.c create mode 100644 tools/perf/arch/arm64/tests/regs_load.S create mode 100644 tools/perf/arch/arm64/util/unwind-libdw.c --- - Rebased on latest acme/perf/core git tree, - Tested on the ARMv8 Foundation emulator. -- 1.7.11.7 -- 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] perf tests: Introduce perf_regs_load function on ARM64
Introducing perf_regs_load function, which is going
to be used for dwarf unwind test in following patches.
It takes single argument as a pointer to the regs dump
buffer and populates it with current registers values, as
expected by the perf built-in unwinding test.
Signed-off-by: Jean Pihet
Cc: Steve Capper
Cc: Corey Ashford
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Jiri Olsa
---
tools/perf/arch/arm64/Makefile| 1 +
tools/perf/arch/arm64/include/perf_regs.h | 2 ++
tools/perf/arch/arm64/tests/regs_load.S | 39 +++
3 files changed, 42 insertions(+)
create mode 100644 tools/perf/arch/arm64/tests/regs_load.S
diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index 67e9b3d..9b8f87e 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -4,4 +4,5 @@ LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
endif
ifndef NO_LIBUNWIND
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind-libunwind.o
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/tests/regs_load.o
endif
diff --git a/tools/perf/arch/arm64/include/perf_regs.h
b/tools/perf/arch/arm64/include/perf_regs.h
index 2359546..1e052f1 100644
--- a/tools/perf/arch/arm64/include/perf_regs.h
+++ b/tools/perf/arch/arm64/include/perf_regs.h
@@ -9,6 +9,8 @@
#define PERF_REG_IPPERF_REG_ARM64_PC
#define PERF_REG_SPPERF_REG_ARM64_SP
+void perf_regs_load(u64 *regs);
+
static inline const char *perf_reg_name(int id)
{
switch (id) {
diff --git a/tools/perf/arch/arm64/tests/regs_load.S
b/tools/perf/arch/arm64/tests/regs_load.S
new file mode 100644
index 000..92ab968
--- /dev/null
+++ b/tools/perf/arch/arm64/tests/regs_load.S
@@ -0,0 +1,39 @@
+#include
+
+/*
+ * Implementation of void perf_regs_load(u64 *regs);
+ *
+ * This functions fills in the 'regs' buffer from the actual registers values,
+ * in the way the perf built-in unwinding test expects them:
+ * - the PC at the time at the call to this function. Since this function
+ * is called using a bl instruction, the PC value is taken from LR,
+ * - the current SP (not touched by this function),
+ * - the current value of LR is merely retrieved and stored because the
+ * value before the call to this function is unknown at this time; it will
+ * be unwound from the dwarf information in unwind__get_entries.
+ */
+
+.text
+.type perf_regs_load,%function
+ENTRY(perf_regs_load)
+ stp x0, x1, [x0], #16 // store x0..x29
+ stp x2, x3, [x0], #16
+ stp x4, x5, [x0], #16
+ stp x6, x7, [x0], #16
+ stp x8, x9, [x0], #16
+ stp x10, x11, [x0], #16
+ stp x12, x13, [x0], #16
+ stp x14, x15, [x0], #16
+ stp x16, x17, [x0], #16
+ stp x18, x19, [x0], #16
+ stp x20, x21, [x0], #16
+ stp x22, x23, [x0], #16
+ stp x24, x25, [x0], #16
+ stp x26, x27, [x0], #16
+ stp x28, x29, [x0], #16
+ mov x1, sp
+ stp x30, x1, [x0], #16 // store lr and sp
+ str x30, [x0] // store pc as lr in order to skip the call
+ // to this function
+ ret
+ENDPROC(perf_regs_load)
--
1.7.11.7
--
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] perf tools: Add libdw DWARF post unwind support for ARM64
Adding libdw DWARF post unwind support, which is part
of elfutils-devel/libdw-dev package from version 0.158.
Note: the libdw code needs some support for dwarf unwinding
on ARM64, this code is submitted seperately on the elfutils
ML.
The new code is contained in unwin-libdw.c object, and
implements unwind__get_entries unwind interface function.
Signed-off-by: Jean Pihet
Cc: Jiri Olsa
Cc: Corey Ashford
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
---
tools/perf/arch/arm64/Makefile| 5 +++
tools/perf/arch/arm64/util/unwind-libdw.c | 53 +++
2 files changed, 58 insertions(+)
create mode 100644 tools/perf/arch/arm64/util/unwind-libdw.c
diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index 221f21d..09d6215 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -4,6 +4,11 @@ LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
endif
ifndef NO_LIBUNWIND
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind-libunwind.o
+endif
+ifndef NO_LIBDW_DWARF_UNWIND
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind-libdw.o
+endif
+ifndef NO_DWARF_UNWIND
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/tests/regs_load.o
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/tests/dwarf-unwind.o
endif
diff --git a/tools/perf/arch/arm64/util/unwind-libdw.c
b/tools/perf/arch/arm64/util/unwind-libdw.c
new file mode 100644
index 000..8d24958
--- /dev/null
+++ b/tools/perf/arch/arm64/util/unwind-libdw.c
@@ -0,0 +1,53 @@
+#include
+#include "../../util/unwind-libdw.h"
+#include "../../util/perf_regs.h"
+
+bool libdw__arch_set_initial_registers(Dwfl_Thread *thread, void *arg)
+{
+ struct unwind_info *ui = arg;
+ struct regs_dump *user_regs = &ui->sample->user_regs;
+ Dwarf_Word dwarf_regs[PERF_REG_ARM64_MAX];
+
+#define REG(r) ({ \
+ Dwarf_Word val = 0; \
+ perf_reg_value(&val, user_regs, PERF_REG_ARM64_##r);\
+ val;\
+})
+
+ dwarf_regs[0] = REG(X0);
+ dwarf_regs[1] = REG(X1);
+ dwarf_regs[2] = REG(X2);
+ dwarf_regs[3] = REG(X3);
+ dwarf_regs[4] = REG(X4);
+ dwarf_regs[5] = REG(X5);
+ dwarf_regs[6] = REG(X6);
+ dwarf_regs[7] = REG(X7);
+ dwarf_regs[8] = REG(X8);
+ dwarf_regs[9] = REG(X9);
+ dwarf_regs[10] = REG(X10);
+ dwarf_regs[11] = REG(X11);
+ dwarf_regs[12] = REG(X12);
+ dwarf_regs[13] = REG(X13);
+ dwarf_regs[14] = REG(X14);
+ dwarf_regs[15] = REG(X15);
+ dwarf_regs[16] = REG(X16);
+ dwarf_regs[17] = REG(X17);
+ dwarf_regs[18] = REG(X18);
+ dwarf_regs[19] = REG(X19);
+ dwarf_regs[20] = REG(X20);
+ dwarf_regs[21] = REG(X21);
+ dwarf_regs[22] = REG(X22);
+ dwarf_regs[23] = REG(X23);
+ dwarf_regs[24] = REG(X24);
+ dwarf_regs[25] = REG(X25);
+ dwarf_regs[26] = REG(X26);
+ dwarf_regs[27] = REG(X27);
+ dwarf_regs[28] = REG(X28);
+ dwarf_regs[29] = REG(X29);
+ dwarf_regs[30] = REG(LR);
+ dwarf_regs[31] = REG(SP);
+ dwarf_regs[32] = REG(PC);
+
+ return dwfl_thread_state_registers(thread, 0, PERF_REG_ARM64_MAX,
+ dwarf_regs);
+}
--
1.7.11.7
--
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] perf tests: Add dwarf unwind test on ARM64
Adding dwarf unwind test, that setups live machine data over
the perf test thread and does the remote unwind.
Need to use -fno-optimize-sibling-calls for test compilation,
otherwise 'krava_*' function calls are optimized into jumps
and ommited from the stack unwind.
Cc: Jiri Olsa
Cc: Corey Ashford
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Signed-off-by: Jean Pihet
---
tools/perf/Makefile.perf | 2 +-
tools/perf/arch/arm64/Makefile | 1 +
tools/perf/arch/arm64/include/perf_regs.h | 3 ++
tools/perf/arch/arm64/tests/dwarf-unwind.c | 59 ++
tools/perf/tests/builtin-test.c| 3 +-
tools/perf/tests/tests.h | 3 +-
6 files changed, 68 insertions(+), 3 deletions(-)
create mode 100644 tools/perf/arch/arm64/tests/dwarf-unwind.c
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index f281c4f..f9c8808 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -410,7 +410,7 @@ LIB_OBJS += $(OUTPUT)tests/code-reading.o
LIB_OBJS += $(OUTPUT)tests/sample-parsing.o
LIB_OBJS += $(OUTPUT)tests/parse-no-sample-id-all.o
ifndef NO_DWARF_UNWIND
-ifeq ($(ARCH),$(filter $(ARCH),x86 arm))
+ifeq ($(ARCH),$(filter $(ARCH),x86 arm arm64))
LIB_OBJS += $(OUTPUT)tests/dwarf-unwind.o
endif
endif
diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index 9b8f87e..221f21d 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -5,4 +5,5 @@ endif
ifndef NO_LIBUNWIND
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind-libunwind.o
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/tests/regs_load.o
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/tests/dwarf-unwind.o
endif
diff --git a/tools/perf/arch/arm64/include/perf_regs.h
b/tools/perf/arch/arm64/include/perf_regs.h
index 1e052f1..e74df99 100644
--- a/tools/perf/arch/arm64/include/perf_regs.h
+++ b/tools/perf/arch/arm64/include/perf_regs.h
@@ -9,6 +9,9 @@
#define PERF_REG_IPPERF_REG_ARM64_PC
#define PERF_REG_SPPERF_REG_ARM64_SP
+#define PERF_REGS_MAX PERF_REG_ARM64_MAX
+#define PERF_SAMPLE_REGS_ABI PERF_SAMPLE_REGS_ABI_64
+
void perf_regs_load(u64 *regs);
static inline const char *perf_reg_name(int id)
diff --git a/tools/perf/arch/arm64/tests/dwarf-unwind.c
b/tools/perf/arch/arm64/tests/dwarf-unwind.c
new file mode 100644
index 000..0aa64f3
--- /dev/null
+++ b/tools/perf/arch/arm64/tests/dwarf-unwind.c
@@ -0,0 +1,59 @@
+#include
+#include "perf_regs.h"
+#include "thread.h"
+#include "map.h"
+#include "event.h"
+#include "tests/tests.h"
+
+#define STACK_SIZE 8192
+
+static int sample_ustack(struct perf_sample *sample,
+struct thread *thread, u64 *regs)
+{
+ struct stack_dump *stack = &sample->user_stack;
+ struct map *map;
+ unsigned long sp;
+ u64 stack_size, *buf;
+
+ buf = malloc(STACK_SIZE);
+ if (!buf) {
+ pr_debug("failed to allocate sample uregs data\n");
+ return -1;
+ }
+
+ sp = (unsigned long) regs[PERF_REG_ARM64_SP];
+
+ map = map_groups__find(&thread->mg, MAP__FUNCTION, (u64) sp);
+ if (!map) {
+ pr_debug("failed to get stack map\n");
+ return -1;
+ }
+
+ stack_size = map->end - sp;
+ stack_size = stack_size > STACK_SIZE ? STACK_SIZE : stack_size;
+
+ memcpy(buf, (void *) sp, stack_size);
+ stack->data = (char *) buf;
+ stack->size = stack_size;
+ return 0;
+}
+
+int test__arch_unwind_sample(struct perf_sample *sample,
+struct thread *thread)
+{
+ struct regs_dump *regs = &sample->user_regs;
+ u64 *buf;
+
+ buf = malloc(sizeof(u64) * PERF_REGS_MAX);
+ if (!buf) {
+ pr_debug("failed to allocate sample uregs data\n");
+ return -1;
+ }
+
+ perf_regs_load(buf);
+ regs->abi = PERF_SAMPLE_REGS_ABI;
+ regs->regs = buf;
+ regs->mask = PERF_REGS_MASK;
+
+ return sample_ustack(sample, thread, buf);
+}
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 167d527..d802215 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -115,7 +115,8 @@ static struct test {
.desc = "Test parsing with no sample_id_all bit set",
.func = test__parse_no_sample_id_all,
},
-#if defined(__x86_64__) || defined(__i386__) || defined(__arm__)
+#if defined(__x86_64__) || defined(__i386__) || \
+defined(__arm__) || defined(__aarch64__)
#ifdef HAVE_DWARF_UNWIND_SUPPORT
{
.desc = "Test dwarf unwind",
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index 0c89cfe..e7bfddb 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -42,7 +42,8 @@ int test__keep_tracking(void);
int test_
printk: One small fixup for patch 5/8
Hello,
this is a small fixup for the patch 5/8 (printk: Hand over printing to
console if printing too long) in my printk series. It fixes a bogus warning
on non-preemptible kernels. Please just fold it into that patch (I can
resend the patch or the series but I don't think that's necessary for such
a small fixup).
Signed-off-by: Jan Kara
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 0910e1894224..cb7e06850eb5 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2022,7 +2022,7 @@ EXPORT_SYMBOL(console_trylock);
*/
static int console_lock_try_spin(void)
{
- WARN_ON_ONCE(!in_atomic());
+ WARN_ON_ONCE(preemptible());
/* Someone already spinning? Don't waste cpu time... */
if (test_and_set_bit(PRINTK_CONSOLE_SPIN_B, &printk_handover_state))
return 0;
--
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: [PATCHv2 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12
Hi Tomasz, On 03/19/2014 12:46 AM, Tomasz Figa wrote: > On 17.03.2014 06:19, Chanwoo Choi wrote: >> Hi Tomasz, >> >> On 03/15/2014 02:35 AM, Tomasz Figa wrote: >>> Hi Chanwoo, Mark, >>> >>> On 14.03.2014 11:56, Chanwoo Choi wrote: Hi Mark, On 03/14/2014 07:35 PM, Mark Rutland wrote: > On Fri, Mar 14, 2014 at 07:14:37AM +, Chanwoo Choi wrote: >> Hi Mark, >> >> On 03/14/2014 02:53 AM, Mark Rutland wrote: >>> On Thu, Mar 13, 2014 at 08:17:29AM +, Chanwoo Choi wrote: This patch add busfreq driver for Exynos4210/Exynos4x12 memory interface and bus to support DVFS(Dynamic Voltage Frequency Scaling) according to PPMU counters. PPMU (Performance Profiling Monitorings Units) of Exynos4 SoC provides PPMU counters for DMC(Dynamic Memory Controller) to check memory bus utilization and then busfreq driver adjusts dynamically the operating frequency/voltage by using DEVFREQ Subsystem. Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/devfreq/exynos4_bus.txt| 49 ++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/devfreq/exynos4_bus.txt diff --git a/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt new file mode 100644 index 000..2a83fcc --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt @@ -0,0 +1,49 @@ + +Exynos4210/4x12 busfreq driver +- + +Exynos4210/4x12 Soc busfreq driver with devfreq for Memory bus frequency/voltage +scaling according to PPMU counters of memory controllers + +Required properties: +- compatible: should contain Exynos4 SoC type as follwoing: + - "samsung,exynos4x12-busfreq" for Exynos4x12 + - "samsung,exynos4210-busfreq" for Exynos4210 >>> >>> Is there a device called "busfreq"? What device does this binding >>> describe? >> >> I'll add detailed description of busfreq as following: >> >> "busfreq(bus frequendcy)" driver means that busfreq driver control >> dynamically >> memory bus frequency/voltage by checking memory bus utilization to >> optimize >> power-consumption. When checking memeory bus utilization, >> exynos4_busfreq driver >> would use PPMU(Performance Profiling Monitoring Units). > > This still sounds like a description of the _driver_, not the _device_. > The binding should describe the hardware, now the high level abstraction > that software is going to build atop of it. > > It sounds like this is a binding for the DMC PPMU? > > Is the PPMU a component of the DMC, or is it bolted on the side? PPMU(Performance Profiling Monitoring Unit) is to profile performance event of various IP on Exynos4. Each PPMU provide perforamnce event for each IP. We can check various PPMU as following: PPMU_3D PPMU_ACP PPMU_CAMIF PPMU_CPU PPMU_DMC0 PPMU_DMC1 PPMU_FSYS PPMU_IMAGE PPMU_LCD0 PPMU_LCD1 PPMU_MFC_L PPMU_MFC_R PPMU_TV PPMU_LEFT_BUS PPMU_RIGHT_BUS DMC (Dynamic Memory Controller) control the operation of DRAM in Exynos4 SoC. If we need to get memory bust utilization of DMC, we can get memory bus utilization from PPMU_DMC0/PPMU_DMC1. So, Exynos4's busfreq used two(PPMU_DMC0/PPMU_DMC1) among upper various PPMU list. >>> >>> Well, PPMUs and DMCs are separate hardware blocks found inside Exynos SoCs. >>> Busfreq/devfreq is just a Linux-specific abstraction responsible for >>> collecting data using PPMUs and controlling frequencies and voltages of >>> appropriate power planes, vdd_int responsible for powering DMC0 and DMC1 >>> blocks in this case. >>> >> >> I knew already. >> >>> I'm afraid that the binding you're proposing is unfortunately incorrect, >>> because it represents the software abstraction, not the real hardware. >> >> What is exactly incorrect part of this patch? >> > > Device tree contains information about hardware, not about OS-specific > drivers or subsystems. Busfreq/devfreq is not a hardware block, but a > Linux-specific driver, so it's not suitable to be described by DT directly, > especially considering the fact that in future it might be replaced by or > merged with another subsystem. > > Only PPMUs are real hardware blocks present in the SoC. In addition, a > SoC-level aspect of hardware description may be added, such as a list of > power planes. See below for explanation. > You means that PPMU must need separate
Re: [PATCH 00/11] ARM: at91: rework main and slow clk implementation
Hello Jean-Christophe, Le 19/03/2014 07:06, Jean-Christophe PLAGNIOL-VILLARD a écrit : You must keep me in Cc I always did, this is an oversight. first and last warning Now, this is my turn. I don't like to be threatened, especially when this message is only sent to me. BTW, last warning, then what ? Now let's talk about your attitude. Regarding this specific series: I sent you several versions of the at91 CCF based clk implementation and you never fully reviewed those series (despite the fact you told me you would do it), why are you so interested in the at91 CCF implementation now ? Moreover, most of the time when you review a patchset your remarks are far from constructive, and we always have to ask you several times to get a real explanation. I'm not telling you're wrong when you "NACK" something, but explaining the reasons are part of your maintainer's job. This being said, I'll take care to keep you in Cc of all at91 related patches. Best Regards, Boris On Mar 19, 2014, at 4:18 AM, Boris BREZILLON wrote: Hello, This series introduce the real clock model (as described in atmel datasheets) for slow and main clocks. The modifications introduced by this series break the DT compat, but, as the at91 CCF based implementation is pretty new (introduced in 3.14 only for sama5 eval boards) I think it won't impact a lot of users. I tested it on sama5d3. Alexandre, Jean-Jacques, could you test this series on your eval boards (sam9261ek and sam9rlek) so that we can move to this new model and hopefully consider the at91 clk DT binding as (almost :-)) stable. Jean-Jacques, as you can see I reworked my first implementation as you suggested, do you want me to add your Signed-off-by in the next version ? Mike, if this series is accepted, I'd like to get it merged as soon as possible to prevent other developpers from using a deprecated DT binding. Best Regards, Boris Boris BREZILLON (11): clk: at91: rework main clk implementation clk: at91: update main clk documentation clk: at91: add slow clks driver clk: at91: add slow clk documentation ARM: at91/dt: move sama5d3 SoC to the new main/slow clk model ARM: at91/dt: add xtal frequencies to sama5d3xcm boards ARM: at91/dt: add xtal frequencies to sama5d3 xplained board ARM: at91/dt: move at91sam9261 SoC to the new main clock model ARM: at91/dt: define main xtal frequency of the at91sam9261ek board ARM: at91/dt: move at91sam9rl SoC to the new slow/main clock models ARM: at91/dt: define sam9rlek crystal frequencies .../devicetree/bindings/clock/at91-clock.txt | 128 - arch/arm/boot/dts/at91-sama5d3_xplained.dts| 10 + arch/arm/boot/dts/at91sam9261.dtsi | 10 +- arch/arm/boot/dts/at91sam9261ek.dts|4 + arch/arm/boot/dts/at91sam9rl.dtsi | 45 +- arch/arm/boot/dts/at91sam9rlek.dts |8 + arch/arm/boot/dts/sama5d3.dtsi | 61 +- arch/arm/boot/dts/sama5d3xcm.dtsi | 10 + drivers/clk/at91/Makefile |4 +- drivers/clk/at91/clk-main.c| 581 +--- drivers/clk/at91/clk-slow.c| 467 drivers/clk/at91/pmc.c | 12 + drivers/clk/at91/pmc.h |9 + drivers/clk/at91/sckc.c| 57 ++ drivers/clk/at91/sckc.h| 22 + include/linux/clk/at91_pmc.h |1 + 16 files changed, 1342 insertions(+), 87 deletions(-) create mode 100644 drivers/clk/at91/clk-slow.c create mode 100644 drivers/clk/at91/sckc.c create mode 100644 drivers/clk/at91/sckc.h -- 1.7.9.5 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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] Video: atmel: avoid the id of fix screen info is overwritten
On 19/03/2014 08:47, Bo Shen : > Correct passing parameter sequence, which will avoid the id of > fix screen info is overwritten. > > Signed-off-by: Bo Shen Acked-by: Nicolas Ferre Thanks. > --- > drivers/video/atmel_lcdfb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c > index cd96162..695f28a 100644 > --- a/drivers/video/atmel_lcdfb.c > +++ b/drivers/video/atmel_lcdfb.c > @@ -1190,12 +1190,12 @@ static int __init atmel_lcdfb_probe(struct > platform_device *pdev) > if (!sinfo->config) > goto free_info; > > - strcpy(info->fix.id, sinfo->pdev->name); > info->flags = ATMEL_LCDFB_FBINFO_DEFAULT; > info->pseudo_palette = sinfo->pseudo_palette; > info->fbops = &atmel_lcdfb_ops; > > info->fix = atmel_lcdfb_fix; > + strcpy(info->fix.id, sinfo->pdev->name); > > /* Enable LCDC Clocks */ > sinfo->bus_clk = clk_get(dev, "hclk"); > -- Nicolas Ferre -- 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: [RFC V2] cpufreq: make sure frequency transitions are serialized
On 03/19/2014 11:38 AM, Viresh Kumar wrote:
> On 18 March 2014 18:20, Srivatsa S. Bhat
> wrote:
>> On 03/14/2014 01:13 PM, Viresh Kumar wrote:
>>> + if ((state != CPUFREQ_PRECHANGE) && (state != CPUFREQ_POSTCHANGE))
>>
>> Wait a min, when is this condition ever true? I mean, what else can
>> 'state' ever be, apart from CPUFREQ_PRECHANGE and POSTCHANGE?
>
> There were two more 'unused' states available:
> CPUFREQ_RESUMECHANGE and CPUFREQ_SUSPENDCHANGE
>
> I have sent a patch to remove them now and this code would go away..
>
>>> + return notify_transition_for_each_cpu(policy, freqs, state);
>>> +
>>> + /* Serialize pre-post notifications */
>>> + mutex_lock(&policy->transition_lock);
>>
>> Nope, this is definitely not the way to go, IMHO. We should enforce that
>> the *callers* serialize the transitions, something like this:
>>
>> cpufreq_transition_lock();
>>
>> cpufreq_notify_transition(CPUFREQ_PRECHANGE);
>>
>> //Perform the frequency change
>>
>> cpufreq_notify_transition(CPUFREQ_POSTCHANGE);
>>
>> cpufreq_transition_unlock();
>>
>> That's it!
>>
>> [ We can either introduce a new "transition" lock or perhaps even reuse
>> the cpufreq_driver_lock if it fits... but the point is, the _caller_ has
>> to perform the locking; trying to be smart inside cpufreq_notify_transition()
>> is a recipe for headache :-( ]
>>
>> Is there any problem with this approach due to which you didn't take
>> this route?
>
> I didn't wanted drivers to handle this as core must make sure things are in
> order. Over that it would have helped by not pasting redundant code
> everywhere..
>
> Drivers are anyway going to call cpufreq_notify_transition(), why increase
> burden on them?
>
No, its not about burden. Its about the elegance of the design. We should
not be overly "smart" in the cpufreq core. Hiding the synchronization inside
the cpufreq core only encourages people to write buggy code in their drivers.
Why don't we go with what Rafael suggested? We can have dedicated
begin_transition() and end_transition() calls to demarcate the frequency
transitions. That way, it makes it very clear how the synchronization is
done. Of course, these functions would be provided (exported) by the cpufreq
core, by implementing them using locks/counters/whatever.
Basically what I'm arguing against, is the idea of having the cpufreq
core figure out what the driver _intended_ to do, from inside the
cpufreq_notify_transition() call.
What I would prefer instead is to have the cpufreq driver do something
like this:
cpufreq_freq_transition_begin();
cpufreq_notify_transition(CPUFREQ_PRECHANGE);
//perform the frequency change
cpufreq_notify_transition(CPUFREQ_POSTCHANGE);
cpufreq_freq_transition_end();
[ASYNC_NOTIFICATION drivers will invoke the last two functions in a
separate context/thread.]
Regards,
Srivatsa S. Bhat
>>> + if (unlikely(WARN_ON(!policy->transition_ongoing &&
>>> + (state == CPUFREQ_POSTCHANGE {
>>> + mutex_unlock(&policy->transition_lock);
>>> + return;
>>> + }
>>> +
>>> + if (state == CPUFREQ_PRECHANGE) {
>>> + while (policy->transition_ongoing) {
>>> + mutex_unlock(&policy->transition_lock);
>>> + /* TODO: Can we do something better here? */
>>> + cpu_relax();
>>> + mutex_lock(&policy->transition_lock);
>>
>> If the caller takes care of the synchronization, we can avoid
>> these sorts of acrobatics ;-)
>
> If we are fine with taking a mutex for the entire transition, then
> we can avoid above kind of acrobatics by just taking the mutex
> from PRECHANGE and leaving it at POSTCHANGE..
>
> It will look like this then, hope this looks fine :)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2677ff1..3b9eac4 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -335,8 +335,15 @@ static void __cpufreq_notify_transition(struct
> cpufreq_policy *policy,
> void cpufreq_notify_transition(struct cpufreq_policy *policy,
> struct cpufreq_freqs *freqs, unsigned int state)
> {
> + if (state == CPUFREQ_PRECHANGE)
> + mutex_lock(&policy->transition_lock);
> +
> + /* Send notifications */
> for_each_cpu(freqs->cpu, policy->cpus)
> __cpufreq_notify_transition(policy, freqs, state);
> +
> + if (state == CPUFREQ_POSTCHANGE)
> + mutex_unlock(&policy->transition_lock);
> }
> EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
>
> @@ -983,6 +990,7 @@ static struct cpufreq_policy *cpufreq_policy_alloc(void)
>
> INIT_LIST_HEAD(&policy->policy_list);
> init_rwsem(&policy->rwsem);
> + mutex_init(&policy->transition_lock);
>
> return policy;
>
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 31c431e..5f9209a 100644
> --- a/incl
Re: [RFC V2] cpufreq: make sure frequency transitions are serialized
On 03/19/2014 02:50 PM, Viresh Kumar wrote: > On 19 March 2014 14:47, Srivatsa S. Bhat > wrote: >> Wait, I think I remember. The problem was about dealing with drivers that >> do asynchronous notification (those that have the ASYNC_NOTIFICATION flag >> set). In particular, exynos-5440 driver sends out the POSTCHANGE notification >> from a workqueue worker, much later than sending the PRECHANGE notification. >> >> From what I saw, this is how the exynos-5440 driver works: >> >> 1. ->target() is invoked, and the driver writes to a register and returns >>to its caller. >> >> 2. An interrupt occurs that indicates that the frequency was changed. >> >> 3. The interrupt handler kicks off a worker thread which then sends out >>the POSTCHANGE notification. > > Correct!! > >> So the important question here is, how does the exynos-5440 driver >> protect itself from say 2 ->target() calls which occur in close sequence >> (before allowing the entire chain for the first call to complete)? >> >> As far as I can see there is no such synchronization in the driver at >> the moment. Adding Amit to CC for his comments. > > Yes, and that's what my patch is trying to fix. Where is the confusion? Sorry, for a moment I got confused and thought that your patch addresses the race conditions present in normal drivers alone, and not ASYNC_NOTIFICATION drivers. But now I understand that your patch intends to fix both the problems at once. I'll share my thoughts about the design in a separate reply. Regards, Srivatsa S. Bhat -- 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 5/7] sched: add a new SD_SHARE_POWERDOMAIN for sched_domain
On 19 March 2014 07:21, Preeti U Murthy wrote:
> Hi Vincent,
>
> On 03/18/2014 11:26 PM, Vincent Guittot wrote:
>> A new flag SD_SHARE_POWERDOMAIN is created to reflect whether groups of CPUs
>> in a sched_domain level can or not reach different power state. As an
>> example,
>> the flag should be cleared at CPU level if groups of cores can be power gated
>> independently. This information can be used to add load balancing level
>> between
>> group of CPUs than can power gate independantly. The default behavior of the
>> scheduler is to spread tasks across CPUs and groups of CPUs so the flag is
>> set
>> into all sched_domains.
>
> I don't see this flag being set either in sd_init() or in
> default_topology[]. Should not the default_topology[] flag setting
> routines set this flag at every level of sched domain along with other
> topology flags, unless the arch wants to override it?
Hi Preeti
I have made the choice to not add it in the default table for the
moment because the scheduler behavior is not changed. It will be added
with patchset that will take advantage of this flag in the load
balance decision.
Regards,
Vincent
>
> Regards
> Preeti U Murthy
>> This flag is part of the topology flags that can be set by arch.
>>
>> Signed-off-by: Vincent Guittot
>> ---
>> include/linux/sched.h | 1 +
>> kernel/sched/core.c | 9 ++---
>> 2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index 6479de4..7048369 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -861,6 +861,7 @@ enum cpu_idle_type {
>> #define SD_BALANCE_WAKE 0x0010 /* Balance on wakeup */
>> #define SD_WAKE_AFFINE 0x0020 /* Wake task to waking CPU */
>> #define SD_SHARE_CPUPOWER0x0080 /* Domain members share cpu power */
>> +#define SD_SHARE_POWERDOMAIN 0x0100 /* Domain members share power domain */
>> #define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu
>> pkg resources */
>> #define SD_SERIALIZE 0x0400 /* Only a single load balancing
>> instance */
>> #define SD_ASYM_PACKING 0x0800 /* Place busy groups earlier
>> in the domain */
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 0b51ee3..224ec3b 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -5298,7 +5298,8 @@ static int sd_degenerate(struct sched_domain *sd)
>>SD_BALANCE_FORK |
>>SD_BALANCE_EXEC |
>>SD_SHARE_CPUPOWER |
>> - SD_SHARE_PKG_RESOURCES)) {
>> + SD_SHARE_PKG_RESOURCES |
>> + SD_SHARE_POWERDOMAIN)) {
>> if (sd->groups != sd->groups->next)
>> return 0;
>> }
>> @@ -5329,7 +5330,8 @@ sd_parent_degenerate(struct sched_domain *sd, struct
>> sched_domain *parent)
>> SD_BALANCE_EXEC |
>> SD_SHARE_CPUPOWER |
>> SD_SHARE_PKG_RESOURCES |
>> - SD_PREFER_SIBLING);
>> + SD_PREFER_SIBLING |
>> + SD_SHARE_POWERDOMAIN);
>> if (nr_node_ids == 1)
>> pflags &= ~SD_SERIALIZE;
>> }
>> @@ -5946,7 +5948,8 @@ static int sched_domains_curr_level;
>> (SD_SHARE_CPUPOWER |\
>>SD_SHARE_PKG_RESOURCES | \
>>SD_NUMA | \
>> - SD_ASYM_PACKING)
>> + SD_ASYM_PACKING | \
>> + SD_SHARE_POWERDOMAIN)
>>
>> static struct sched_domain *
>> sd_init(struct sched_domain_topology_level *tl, int cpu)
>>
>
--
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 2/4] hrtimer: export __hrtimer_start_range_ns
On Wed, 19 Mar 2014, Peter Zijlstra wrote: > On Tue, Mar 18, 2014 at 04:56:42PM +0800, Yan, Zheng wrote: > > export __hrtimer_start_range_ns() to allow building perf Intel uncore > > driver as module > > Bah; you didn't cc the hrtimer maintainer. > > Thomas, ack on this? Yup. > > Signed-off-by: Yan, Zheng > > --- > > kernel/hrtimer.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c > > index 0909436..650bf38 100644 > > --- a/kernel/hrtimer.c > > +++ b/kernel/hrtimer.c > > @@ -1030,6 +1030,7 @@ int __hrtimer_start_range_ns(struct hrtimer *timer, > > ktime_t tim, > > > > return ret; > > } > > +EXPORT_SYMBOL_GPL(__hrtimer_start_range_ns); > > > > /** > > * hrtimer_start_range_ns - (re)start an hrtimer on the current CPU > > -- > > 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] avr32: replace simple_strtoul() with kstrtoul()
> - val = simple_strtoul(buf, &endp, 0); > - if (endp == buf || val > 0x3f) > - return -EINVAL; > + ret = kstrtoul(buf, 0, &val); > + if (ret) > + return ret; > val = (val << 12) | (sysreg_read(PCCR) & 0xfffc0fff); you removed 0x3f check this conversion is not trivial as it seems -- 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: netfilter: LLVMLinux: vlais-netfilter
From: beh...@converseincode.com
> From: Mark Charlebois
>
> Replaced non-standard C use of Variable Length Arrays In Structs (VLAIS) in
> xt_repldata.h with a C99 compliant flexible array member and then calculated
> offsets to the other struct members. These other members aren't referenced by
> name in this code, however this patch maintains the same memory layout and
> padding as was previously accomplished using VLAIS.
>
> Had the original structure been ordered differently, with the entries VLA at
> the end, then it could have been a flexible member, and this patch would have
> been a lot simpler. However since the data stored in this structure is
> ultimately exported to userspace, the order of this structure can't be
> changed.
>
> This patch makes no attempt to change the existing behavior, merely the way in
> which the current layout is accomplished using standard C99 constructs. As
> such
> the code can now be compiled with either gcc or clang.
>
> Author: Mark Charlebois
> Signed-off-by: Mark Charlebois
> Signed-off-by: Behan Webster
> Signed-off-by: Vinícius Tinti
> ---
> net/netfilter/xt_repldata.h | 27 ++-
> 1 file changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/net/netfilter/xt_repldata.h b/net/netfilter/xt_repldata.h
> index 6efe4e5..343599e 100644
> --- a/net/netfilter/xt_repldata.h
> +++ b/net/netfilter/xt_repldata.h
> @@ -5,23 +5,40 @@
> * they serve as the hanging-off data accessed through repl.data[].
> */
>
> +/* tbl has the following structure equivalent, but is C99 compliant:
> + * struct {
> + * struct type##_replace repl;
> + * struct type##_standard entries[nhooks];
> + * struct type##_error term;
> + * } *tbl;
> + */
> +
> #define xt_alloc_initial_table(type, typ2) ({ \
> unsigned int hook_mask = info->valid_hooks; \
> unsigned int nhooks = hweight32(hook_mask); \
> unsigned int bytes = 0, hooknum = 0, i = 0; \
> struct { \
> struct type##_replace repl; \
> - struct type##_standard entries[nhooks]; \
> - struct type##_error term; \
> - } *tbl = kzalloc(sizeof(*tbl), GFP_KERNEL); \
> + struct type##_standard entries[]; \
> + } *tbl; \
> + struct type##_error *term; \
> + size_t entries_end = offsetof(typeof(*tbl), \
> + entries[nhooks-1]) + sizeof(tbl->entries[0]); \
Is the compiler complaining about:
offsetof(typeof(*tbl), entries[nhooks])
If it does it is a PITA.
> + size_t term_offset = (entries_end + __alignof__(*term) - 1) \
> + & ~(__alignof__(*term) - 1); \
You've not tested this - the () are in the wrong places.
> + size_t term_end = term_offset + sizeof(*term); \
> + size_t tbl_sz = (term_end + __alignof__(tbl->repl) - 1) \
> + & ~(__alignof__(tbl->repl) - 1); \
> + tbl = kzalloc(tbl_sz, GFP_KERNEL); \
The number of temporary variables make the above hard to read.
I'm not at all sure you need to worry about the trailing alignment.
It rather depends on how the final data is used.
If the combined buffer is copied to userspace you may not
be copying all of the required data.
It might be easier to call copytouser() twice.
> if (tbl == NULL) \
> return NULL; \
> + term = (struct type##_error *)&(((char *)tbl)[term_offset]); \
> strncpy(tbl->repl.name, info->name, sizeof(tbl->repl.name)); \
> - tbl->term = (struct type##_error)typ2##_ERROR_INIT; \
> + *term = (struct type##_error)typ2##_ERROR_INIT; \
David
Re: [PATCH 00/31] Clean up smp_mb__ barriers
Shouldn't the mass-conversion patch (patch 31) go first? 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/
Thread Scheduler
Hi Maybe this is a noob question... Where in the linux kernel source (2.6), the thread scheduler has been implemented? Searching the web shows that there should sched_fair.c but I can not find that in the source directory (the kernel source has been installed). Basically, I want to know which part of the code calculated the priorities of the available threads and select them for running? Regards, Mahmood -- 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/
