Re: [PATCH v2 1/2] zsmalloc: add function to query object size
Sorry for late response. I should have hurried.
I just sent by my comment of your previous version's mail thread.
Please look at it.
On Wed, Nov 28, 2012 at 11:48:30PM -0800, Nitin Gupta wrote:
> Changelog v2 vs v1
> - None
>
> Adds zs_get_object_size(handle) which provides the size of
> the given object. This is useful since the user (zram etc.)
> now do not have to maintain object sizes separately, saving
> on some metadata size (4b per page).
>
> The object handle encodes pair which currently points
> to the start of the object. Now, the handle implicitly stores the size
> information by pointing to the object's end instead. Since zsmalloc is
> a slab based allocator, the start of the object can be easily determined
> and the difference between the end offset encoded in the handle and the
> start gives us the object size.
>
> Signed-off-by: Nitin Gupta
> ---
> drivers/staging/zsmalloc/zsmalloc-main.c | 177
> +-
> drivers/staging/zsmalloc/zsmalloc.h |1 +
> 2 files changed, 127 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
> b/drivers/staging/zsmalloc/zsmalloc-main.c
> index 09a9d35..65c9d3b 100644
> --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> @@ -112,20 +112,20 @@
> #define MAX_PHYSMEM_BITS 36
> #else /* !CONFIG_HIGHMEM64G */
> /*
> - * If this definition of MAX_PHYSMEM_BITS is used, OBJ_INDEX_BITS will just
> + * If this definition of MAX_PHYSMEM_BITS is used, OFFSET_BITS will just
> * be PAGE_SHIFT
> */
> #define MAX_PHYSMEM_BITS BITS_PER_LONG
> #endif
> #endif
> #define _PFN_BITS(MAX_PHYSMEM_BITS - PAGE_SHIFT)
> -#define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS)
> -#define OBJ_INDEX_MASK ((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
> +#define OFFSET_BITS (BITS_PER_LONG - _PFN_BITS)
> +#define OFFSET_MASK ((_AC(1, UL) << OFFSET_BITS) - 1)
>
> #define MAX(a, b) ((a) >= (b) ? (a) : (b))
> /* ZS_MIN_ALLOC_SIZE must be multiple of ZS_ALIGN */
> #define ZS_MIN_ALLOC_SIZE \
> - MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
> + MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OFFSET_BITS))
> #define ZS_MAX_ALLOC_SIZEPAGE_SIZE
>
> /*
> @@ -256,6 +256,11 @@ static int is_last_page(struct page *page)
> return PagePrivate2(page);
> }
>
> +static unsigned long get_page_index(struct page *page)
> +{
> + return is_first_page(page) ? 0 : page->index;
> +}
> +
> static void get_zspage_mapping(struct page *page, unsigned int *class_idx,
> enum fullness_group *fullness)
> {
> @@ -433,39 +438,86 @@ static struct page *get_next_page(struct page *page)
> return next;
> }
>
> -/* Encode as a single handle value */
> -static void *obj_location_to_handle(struct page *page, unsigned long obj_idx)
> +static struct page *get_prev_page(struct page *page)
> {
> - unsigned long handle;
> + struct page *prev, *first_page;
>
> - if (!page) {
> - BUG_ON(obj_idx);
> - return NULL;
> - }
> + first_page = get_first_page(page);
> + if (page == first_page)
> + prev = NULL;
> + else if (page == (struct page *)first_page->private)
> + prev = first_page;
> + else
> + prev = list_entry(page->lru.prev, struct page, lru);
>
> - handle = page_to_pfn(page) << OBJ_INDEX_BITS;
> - handle |= (obj_idx & OBJ_INDEX_MASK);
> + return prev;
>
> - return (void *)handle;
> }
>
> -/* Decode pair from the given object handle */
> -static void obj_handle_to_location(unsigned long handle, struct page **page,
> - unsigned long *obj_idx)
> +static void *encode_ptr(struct page *page, unsigned long offset)
> {
> - *page = pfn_to_page(handle >> OBJ_INDEX_BITS);
> - *obj_idx = handle & OBJ_INDEX_MASK;
> + unsigned long ptr;
> + ptr = page_to_pfn(page) << OFFSET_BITS;
> + ptr |= offset & OFFSET_MASK;
> + return (void *)ptr;
> +}
> +
> +static void decode_ptr(unsigned long ptr, struct page **page,
> + unsigned int *offset)
> +{
> + *page = pfn_to_page(ptr >> OFFSET_BITS);
> + *offset = ptr & OFFSET_MASK;
> +}
> +
> +static struct page *obj_handle_to_page(unsigned long handle)
> +{
> + struct page *page;
> + unsigned int offset;
> +
> + decode_ptr(handle, , );
> + if (offset < get_page_index(page))
> + page = get_prev_page(page);
> +
> + return page;
> +}
> +
> +static unsigned int obj_handle_to_offset(unsigned long handle,
> + unsigned int class_size)
> +{
> + struct page *page;
> + unsigned int offset;
> +
> + decode_ptr(handle, , );
> + if (offset < get_page_index(page))
> + offset = PAGE_SIZE - class_size + get_page_index(page);
> + else
> + offset = roundup(offset,
Re: [PATCH 03/14] perf tool: Fix period symbol_conf.field_sep display
On Wed, 28 Nov 2012 14:52:38 +0100, Jiri Olsa wrote:
> Currently we don't properly display hist data with
> symbol_conf.field_sep separator. We need to display
> either space or separator.
>
> Signed-off-by: Jiri Olsa
> Cc: Arnaldo Carvalho de Melo
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Paul Mackerras
> Cc: Corey Ashford
> Cc: Frederic Weisbecker
> Cc: Namhyung Kim
> ---
> tools/perf/ui/hist.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
> index 5452960..20a4392 100644
> --- a/tools/perf/ui/hist.c
> +++ b/tools/perf/ui/hist.c
> @@ -523,17 +523,13 @@ int hist_entry__period_snprintf(struct perf_hpp *hpp,
> struct hist_entry *he,
> struct perf_hpp_fmt *fmt;
> char *start = hpp->buf;
> int ret;
> - bool first = true;
>
> if (symbol_conf.exclude_other && !he->parent)
> return 0;
>
> perf_hpp__for_each_format(fmt) {
> - if (!sep || !first) {
> - ret = scnprintf(hpp->buf, hpp->size, "%s", sep ?: " ");
> - advance_hpp(hpp, ret);
> - first = false;
> - }
> + ret = scnprintf(hpp->buf, hpp->size, "%s", sep ?: " ");
> + advance_hpp(hpp, ret);
It will display the separator even before the first column so that the
output can be messed up with this. I can see that there's a bug setting
'first' to false - the line should be moved out of the block otherwise
it's pointless since we cannot enter the block.
Thanks,
Namhyung
>
> if (color && fmt->color)
> ret = fmt->color(fmt, hpp, he);
--
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] zram: Fix use-after-free bug in disk write case
Hi Nitin,
On Wed, Nov 28, 2012 at 11:45:06PM -0800, Nitin Gupta wrote:
> Changelog v2 vs v1:
> - Changelog message now correctly explains the problem
>
> Fixes a bug introduced by commit c8f2f0db1 ("zram: Fix handling
> of incompressible pages") which caused a freed buffer to be used
> in case a partial write (non PAGE_SIZED) request is received and
> the data is found to be incompressible.
>
> Fixes bug 50081:
> https://bugzilla.kernel.org/show_bug.cgi?id=50081
When I saw https://bugzilla.kernel.org/attachment.cgi?id=85571, it was
swap write usecase so parital write can not happen.
So this bug isn't related to freed buffer caused by partial write.
This bug is related to unmapped buffer access.
1) user_mem = kmap_atomic
2) uncmem = usermem
3) compress
4) kunmap_atomic(usermem) <-- So, uncmem is dangling.
5) src = uncmem; <-- So, src is dangling.
6) memcpy(cmem, src, clen) <-- HIT
>
> Signed-off-by: Nitin Gupta
> Reported-by: Mihail Kasadjikov
> Reported-by: Tomas M
> Reviewed-by: Minchan Kim
> ---
> drivers/staging/zram/zram_drv.c | 39
> ---
> 1 file changed, 24 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index fb4a7c9..f2a73bd 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -265,7 +265,7 @@ out_cleanup:
> static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32
> index,
> int offset)
> {
> - int ret;
> + int ret = 0;
> size_t clen;
> unsigned long handle;
> struct page *page;
> @@ -286,10 +286,8 @@ static int zram_bvec_write(struct zram *zram, struct
> bio_vec *bvec, u32 index,
> goto out;
> }
> ret = zram_decompress_page(zram, uncmem, index);
> - if (ret) {
> - kfree(uncmem);
> + if (ret)
> goto out;
> - }
> }
>
> /*
> @@ -302,16 +300,18 @@ static int zram_bvec_write(struct zram *zram, struct
> bio_vec *bvec, u32 index,
>
> user_mem = kmap_atomic(page);
>
> - if (is_partial_io(bvec))
> + if (is_partial_io(bvec)) {
> memcpy(uncmem + offset, user_mem + bvec->bv_offset,
> bvec->bv_len);
> - else
> + kunmap_atomic(user_mem);
> + user_mem = NULL;
> + } else {
> uncmem = user_mem;
> + }
>
> if (page_zero_filled(uncmem)) {
> - kunmap_atomic(user_mem);
> - if (is_partial_io(bvec))
> - kfree(uncmem);
> + if (!is_partial_io(bvec))
> + kunmap_atomic(user_mem);
> zram_stat_inc(>stats.pages_zero);
> zram_set_flag(zram, index, ZRAM_ZERO);
> ret = 0;
> @@ -321,9 +321,11 @@ static int zram_bvec_write(struct zram *zram, struct
> bio_vec *bvec, u32 index,
> ret = lzo1x_1_compress(uncmem, PAGE_SIZE, src, ,
> zram->compress_workmem);
>
> - kunmap_atomic(user_mem);
> - if (is_partial_io(bvec))
> - kfree(uncmem);
> + if (!is_partial_io(bvec)) {
> + kunmap_atomic(user_mem);
> + user_mem = NULL;
> + uncmem = NULL;
> + }
>
> if (unlikely(ret != LZO_E_OK)) {
> pr_err("Compression failed! err=%d\n", ret);
> @@ -332,8 +334,10 @@ static int zram_bvec_write(struct zram *zram, struct
> bio_vec *bvec, u32 index,
>
> if (unlikely(clen > max_zpage_size)) {
> zram_stat_inc(>stats.bad_compress);
> - src = uncmem;
> clen = PAGE_SIZE;
> + src = NULL;
> + if (is_partial_io(bvec))
> + src = uncmem;
> }
>
> handle = zs_malloc(zram->mem_pool, clen);
> @@ -345,7 +349,11 @@ static int zram_bvec_write(struct zram *zram, struct
> bio_vec *bvec, u32 index,
> }
> cmem = zs_map_object(zram->mem_pool, handle, ZS_MM_WO);
>
> + if ((clen == PAGE_SIZE) && !is_partial_io(bvec))
> + src = kmap_atomic(page);
> memcpy(cmem, src, clen);
> + if ((clen == PAGE_SIZE) && !is_partial_io(bvec))
> + kunmap_atomic(src);
>
> zs_unmap_object(zram->mem_pool, handle);
>
> @@ -358,9 +366,10 @@ static int zram_bvec_write(struct zram *zram, struct
> bio_vec *bvec, u32 index,
> if (clen <= PAGE_SIZE / 2)
> zram_stat_inc(>stats.good_compress);
>
> - return 0;
> -
> out:
> + if (is_partial_io(bvec))
> + kfree(uncmem);
> +
> if (ret)
> zram_stat64_inc(zram, >stats.failed_writes);
> return ret;
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/5] OMAP: iommu: hwmod, reset handling and runtime PM
On Tue, Nov 20, 2012 at 3:05 AM, Omar Ramirez Luna wrote: > These patches are needed for remoteproc to work on OMAP4. > > Introduced iommu hwmod support for OMAP3 (iva, isp) and > OMAP4 (ipu, dsp), along with the corresponding runtime PM > and routines to deassert reset lines, enable/disable clocks > and configure sysc registers. I tested the entire series with remoteproc/rpmsg on OMAP4 and it looks good. Since this is super needed, and have already been going on for quite a while, I'd really like to see this go in. We could then incrementally deal with any outstanding comment or issue that might show up. Joerg, can you please take it (or at least its first four patches) ? We have Tony's ack for the mach-omap2 parts. Tested-by: Ohad Ben-Cohen Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] zram: reduce metadata overhead
Changelog v2 vs v1:
- Use is_zero_page() instead of direct handle comparison
- Use 1 as invalid handle value instead of -1 since handle
is unsigned and thus -1 may refer to a valid object. While 1
is guaranteed to be invalid since can never
refer to (end of) a valid object.
- Remove references to 'table' in comments and messages since
we just have a plain array of handles now.
For every allocated object, zram maintains the the handle, size,
flags and count fields. Of these, only the handle is required
since zsmalloc now provides the object size given the handle.
The flags field was needed only to mark a given page as zero-filled.
Instead of this field, we now use an invalid value (-1) to mark such
pages. Lastly, the count field was unused, so was simply removed.
Signed-off-by: Nitin Gupta
Reviewed-by: Jerome Marchand
---
drivers/staging/zram/zram_drv.c | 97 ---
drivers/staging/zram/zram_drv.h | 20 ++--
2 files changed, 43 insertions(+), 74 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index f2a73bd..e6c9bec 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -71,24 +71,6 @@ static void zram_stat64_inc(struct zram *zram, u64 *v)
zram_stat64_add(zram, v, 1);
}
-static int zram_test_flag(struct zram *zram, u32 index,
- enum zram_pageflags flag)
-{
- return zram->table[index].flags & BIT(flag);
-}
-
-static void zram_set_flag(struct zram *zram, u32 index,
- enum zram_pageflags flag)
-{
- zram->table[index].flags |= BIT(flag);
-}
-
-static void zram_clear_flag(struct zram *zram, u32 index,
- enum zram_pageflags flag)
-{
- zram->table[index].flags &= ~BIT(flag);
-}
-
static int page_zero_filled(void *ptr)
{
unsigned int pos;
@@ -104,6 +86,11 @@ static int page_zero_filled(void *ptr)
return 1;
}
+static inline int is_zero_page(unsigned long handle)
+{
+ return handle == zero_page_handle;
+}
+
static void zram_set_disksize(struct zram *zram, size_t totalram_bytes)
{
if (!zram->disksize) {
@@ -135,21 +122,20 @@ static void zram_set_disksize(struct zram *zram, size_t
totalram_bytes)
static void zram_free_page(struct zram *zram, size_t index)
{
- unsigned long handle = zram->table[index].handle;
- u16 size = zram->table[index].size;
+ unsigned long handle = zram->handle[index];
+ size_t size;
- if (unlikely(!handle)) {
- /*
-* No memory is allocated for zero filled pages.
-* Simply clear zero page flag.
-*/
- if (zram_test_flag(zram, index, ZRAM_ZERO)) {
- zram_clear_flag(zram, index, ZRAM_ZERO);
- zram_stat_dec(>stats.pages_zero);
- }
+ if (unlikely(!handle))
+ return;
+
+ if (is_zero_page(handle)) {
+ /* No memory is allocated for zero filled pages */
+ zram->handle[index] = 0;
+ zram_stat_dec(>stats.pages_zero);
return;
}
+ size = zs_get_object_size(zram->mem_pool, handle);
if (unlikely(size > max_zpage_size))
zram_stat_dec(>stats.bad_compress);
@@ -158,12 +144,10 @@ static void zram_free_page(struct zram *zram, size_t
index)
if (size <= PAGE_SIZE / 2)
zram_stat_dec(>stats.good_compress);
- zram_stat64_sub(zram, >stats.compr_size,
- zram->table[index].size);
+ zram_stat64_sub(zram, >stats.compr_size, size);
zram_stat_dec(>stats.pages_stored);
- zram->table[index].handle = 0;
- zram->table[index].size = 0;
+ zram->handle[index] = 0;
}
static void handle_zero_page(struct bio_vec *bvec)
@@ -188,19 +172,20 @@ static int zram_decompress_page(struct zram *zram, char
*mem, u32 index)
int ret = LZO_E_OK;
size_t clen = PAGE_SIZE;
unsigned char *cmem;
- unsigned long handle = zram->table[index].handle;
+ unsigned long handle = zram->handle[index];
+ size_t objsize;
- if (!handle || zram_test_flag(zram, index, ZRAM_ZERO)) {
+ if (!handle || is_zero_page(handle)) {
memset(mem, 0, PAGE_SIZE);
return 0;
}
+ objsize = zs_get_object_size(zram->mem_pool, handle);
cmem = zs_map_object(zram->mem_pool, handle, ZS_MM_RO);
- if (zram->table[index].size == PAGE_SIZE)
+ if (objsize == PAGE_SIZE)
memcpy(mem, cmem, PAGE_SIZE);
else
- ret = lzo1x_decompress_safe(cmem, zram->table[index].size,
- mem, );
+ ret = lzo1x_decompress_safe(cmem, objsize, mem, );
zs_unmap_object(zram->mem_pool, handle);
/* Should NEVER happen. Return bio error if it does. */
@@
[PATCH v2 1/2] zsmalloc: add function to query object size
Changelog v2 vs v1
- None
Adds zs_get_object_size(handle) which provides the size of
the given object. This is useful since the user (zram etc.)
now do not have to maintain object sizes separately, saving
on some metadata size (4b per page).
The object handle encodes pair which currently points
to the start of the object. Now, the handle implicitly stores the size
information by pointing to the object's end instead. Since zsmalloc is
a slab based allocator, the start of the object can be easily determined
and the difference between the end offset encoded in the handle and the
start gives us the object size.
Signed-off-by: Nitin Gupta
---
drivers/staging/zsmalloc/zsmalloc-main.c | 177 +-
drivers/staging/zsmalloc/zsmalloc.h |1 +
2 files changed, 127 insertions(+), 51 deletions(-)
diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
b/drivers/staging/zsmalloc/zsmalloc-main.c
index 09a9d35..65c9d3b 100644
--- a/drivers/staging/zsmalloc/zsmalloc-main.c
+++ b/drivers/staging/zsmalloc/zsmalloc-main.c
@@ -112,20 +112,20 @@
#define MAX_PHYSMEM_BITS 36
#else /* !CONFIG_HIGHMEM64G */
/*
- * If this definition of MAX_PHYSMEM_BITS is used, OBJ_INDEX_BITS will just
+ * If this definition of MAX_PHYSMEM_BITS is used, OFFSET_BITS will just
* be PAGE_SHIFT
*/
#define MAX_PHYSMEM_BITS BITS_PER_LONG
#endif
#endif
#define _PFN_BITS (MAX_PHYSMEM_BITS - PAGE_SHIFT)
-#define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS)
-#define OBJ_INDEX_MASK ((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
+#define OFFSET_BITS(BITS_PER_LONG - _PFN_BITS)
+#define OFFSET_MASK((_AC(1, UL) << OFFSET_BITS) - 1)
#define MAX(a, b) ((a) >= (b) ? (a) : (b))
/* ZS_MIN_ALLOC_SIZE must be multiple of ZS_ALIGN */
#define ZS_MIN_ALLOC_SIZE \
- MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
+ MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OFFSET_BITS))
#define ZS_MAX_ALLOC_SIZE PAGE_SIZE
/*
@@ -256,6 +256,11 @@ static int is_last_page(struct page *page)
return PagePrivate2(page);
}
+static unsigned long get_page_index(struct page *page)
+{
+ return is_first_page(page) ? 0 : page->index;
+}
+
static void get_zspage_mapping(struct page *page, unsigned int *class_idx,
enum fullness_group *fullness)
{
@@ -433,39 +438,86 @@ static struct page *get_next_page(struct page *page)
return next;
}
-/* Encode as a single handle value */
-static void *obj_location_to_handle(struct page *page, unsigned long obj_idx)
+static struct page *get_prev_page(struct page *page)
{
- unsigned long handle;
+ struct page *prev, *first_page;
- if (!page) {
- BUG_ON(obj_idx);
- return NULL;
- }
+ first_page = get_first_page(page);
+ if (page == first_page)
+ prev = NULL;
+ else if (page == (struct page *)first_page->private)
+ prev = first_page;
+ else
+ prev = list_entry(page->lru.prev, struct page, lru);
- handle = page_to_pfn(page) << OBJ_INDEX_BITS;
- handle |= (obj_idx & OBJ_INDEX_MASK);
+ return prev;
- return (void *)handle;
}
-/* Decode pair from the given object handle */
-static void obj_handle_to_location(unsigned long handle, struct page **page,
- unsigned long *obj_idx)
+static void *encode_ptr(struct page *page, unsigned long offset)
{
- *page = pfn_to_page(handle >> OBJ_INDEX_BITS);
- *obj_idx = handle & OBJ_INDEX_MASK;
+ unsigned long ptr;
+ ptr = page_to_pfn(page) << OFFSET_BITS;
+ ptr |= offset & OFFSET_MASK;
+ return (void *)ptr;
+}
+
+static void decode_ptr(unsigned long ptr, struct page **page,
+ unsigned int *offset)
+{
+ *page = pfn_to_page(ptr >> OFFSET_BITS);
+ *offset = ptr & OFFSET_MASK;
+}
+
+static struct page *obj_handle_to_page(unsigned long handle)
+{
+ struct page *page;
+ unsigned int offset;
+
+ decode_ptr(handle, , );
+ if (offset < get_page_index(page))
+ page = get_prev_page(page);
+
+ return page;
+}
+
+static unsigned int obj_handle_to_offset(unsigned long handle,
+ unsigned int class_size)
+{
+ struct page *page;
+ unsigned int offset;
+
+ decode_ptr(handle, , );
+ if (offset < get_page_index(page))
+ offset = PAGE_SIZE - class_size + get_page_index(page);
+ else
+ offset = roundup(offset, class_size) - class_size;
+
+ return offset;
}
-static unsigned long obj_idx_to_offset(struct page *page,
- unsigned long obj_idx, int class_size)
+/* Encode as a single handle value */
+static void *obj_location_to_handle(struct page *page, unsigned int offset,
+ unsigned int size, unsigned int class_size)
{
-
Re: [RFC][PATCH 2/2] fix kvm's use of __pa() on percpu areas
On Thu, Nov 29, 2012 at 12:53:56AM +, Dave Hansen wrote:
>
> In short, it is illegal to call __pa() on an address holding
> a percpu variable. The times when this actually matters are
> pretty obscure (certain 32-bit NUMA systems), but it _does_
> happen. It is important to keep KVM guests working on these
> systems because the real hardware is getting harder and
> harder to find.
>
> This bug manifested first by me seeing a plain hang at boot
> after this message:
>
> CPU 0 irqstacks, hard=f3018000 soft=f301a000
>
> or, sometimes, it would actually make it out to the console:
>
> [0.00] BUG: unable to handle kernel paging request at
>
> I eventually traced it down to the KVM async pagefault code.
> This can be worked around by disabling that code either at
> compile-time, or on the kernel command-line.
>
> The kvm async pagefault code was injecting page faults in
> to the guest which the guest misinterpreted because its
> "reason" was not being properly sent from the host.
>
> The guest passes a physical address of an per-cpu async page
> fault structure via an MSR to the host. Since __pa() is
> broken on percpu data, the physical address it sent was
> bascially bogus and the host went scribbling on random data.
> The guest never saw the real reason for the page fault (it
> was injected by the host), assumed that the kernel had taken
> a _real_ page fault, and panic()'d.
>
> Signed-off-by: Dave Hansen
> ---
>
> linux-2.6.git-dave/arch/x86/kernel/kvm.c |9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff -puN arch/x86/kernel/kvm.c~fix-kvm-__pa-use-on-percpu-areas
> arch/x86/kernel/kvm.c
> --- linux-2.6.git/arch/x86/kernel/kvm.c~fix-kvm-__pa-use-on-percpu-areas
> 2012-11-29 00:39:59.130213376 +
> +++ linux-2.6.git-dave/arch/x86/kernel/kvm.c 2012-11-29 00:51:55.428091802
> +
> @@ -284,9 +284,9 @@ static void kvm_register_steal_time(void
>
> memset(st, 0, sizeof(*st));
>
> - wrmsrl(MSR_KVM_STEAL_TIME, (__pa(st) | KVM_MSR_ENABLED));
> + wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
Where is this slow_virt_to_phys() coming from? I do not find it in
kvm.git.
> printk(KERN_INFO "kvm-stealtime: cpu %d, msr %lx\n",
> - cpu, __pa(st));
> + cpu, slow_virt_to_phys(st));
> }
>
> static DEFINE_PER_CPU(unsigned long, kvm_apic_eoi) = KVM_PV_EOI_DISABLED;
> @@ -311,7 +311,7 @@ void __cpuinit kvm_guest_cpu_init(void)
> return;
>
> if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF) && kvmapf) {
> - u64 pa = __pa(&__get_cpu_var(apf_reason));
> + u64 pa = slow_virt_to_phys(&__get_cpu_var(apf_reason));
>
> #ifdef CONFIG_PREEMPT
> pa |= KVM_ASYNC_PF_SEND_ALWAYS;
> @@ -327,7 +327,8 @@ void __cpuinit kvm_guest_cpu_init(void)
> /* Size alignment is implied but just to make it explicit. */
> BUILD_BUG_ON(__alignof__(kvm_apic_eoi) < 4);
> __get_cpu_var(kvm_apic_eoi) = 0;
> - pa = __pa(&__get_cpu_var(kvm_apic_eoi)) | KVM_MSR_ENABLED;
> + pa = slow_virt_to_phys(&__get_cpu_var(kvm_apic_eoi))
> + | KVM_MSR_ENABLED;
> wrmsrl(MSR_KVM_PV_EOI_EN, pa);
> }
>
> _
--
Gleb.
--
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/2] mmc: dw_mmc: exynos: Stop claiming wp-gpio
Hi Doug,
On Thursday, November 29, 2012, Doug Anderson wrote:
> Seungwon,
>
> Thanks for the review. See below for comments. If you'd like me to
> respin then please let me know. Otherwise I look forward to your ack.
>
> On Wed, Nov 28, 2012 at 1:29 AM, Seungwon Jeon wrote:
> > Yes. pin of write protection is common property.
> > This change is good. I have some suggestion below.
> > Could you check it?
> >
> > On Friday, November 23, 2012, Doug Anderson wrote:
> >> The exynos code claimed wp-gpio with devm_gpio_request() but never did
> >> anything with it. That meant that anyone using a write protect GPIO
> >> would effectively be write protected all the time.
> >>
> >> A future change will move the wp-gpio support to the core dw_mmc.c
> >> file. Now the exynos-specific code won't claim the GPIO but will
> >> just set the DW_MCI_QUIRK_NO_WRITE_PROTECT quirk if write protect
> >> won't be used.
> >>
> >> Signed-off-by: Doug Anderson
> >>
> >> ---
> >> Changes in v2:
> >> - Nothing new in this patch
> >>
> >> drivers/mmc/host/dw_mmc-exynos.c | 12 ++--
> >> 1 files changed, 6 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
> >> b/drivers/mmc/host/dw_mmc-exynos.c
> >> index 4d50da6..58cc03e 100644
> >> --- a/drivers/mmc/host/dw_mmc-exynos.c
> >> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> >> @@ -175,12 +175,12 @@ static int dw_mci_exynos_setup_bus(struct dw_mci
> >> *host,
> >> }
> >> }
> >>
> >> - gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
> >> - if (gpio_is_valid(gpio)) {
> >> - if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
> >> - dev_info(host->dev, "gpio [%d] request failed\n",
> >> - gpio);
> >> - } else {
> >> + /*
> >> + * If there are no write-protect GPIOs present then we assume no
> >> write
> >> + * protect. The mci_readl() in dw_mmc.c won't work since it's not
> >> + * hooked up on exynos.
> >> + */
> >> + if (!of_find_property(slot_np, "wp-gpios", NULL)) {
> >> dev_info(host->dev, "wp gpio not available");
> >> host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
> >> }
> > All card types need this quirk in case wp-gpio property is empty?
> > I think wp-pin is valid for SD card, not eMMC/SDIO.
>
> Right. It is only checked right now by the SD code (mmc/core/sd.c).
> It doesn't particularly hurt to set it the quirk in other cases though
> and it seems nice not to add special cases. I could imagine someone
> extending the MMC code at some point to support write protect (via
> GPIO) for eMMC, so there's even a slight justification for avoiding
> the special case.
>
>
> > Of course, I know origin code did it.
> > How about removing whole checking routine?
> > Instead, new definition for this quirk can be added into
> > 'dw_mci_of_quirks'(dw_mmc.c) and dts file.
>
> On _exynos_ all SD cards need this quirk if there is no wp-gpio
> property. However this is not generally true for all users of dw_mmc.
> The DesignWare IP Block actually has a write protect input that can
> be read with "mci_readl(slot->host, WRTPRT)" but on exynos the
> DesignWare write protect line isn't exposed on any physical pins.
> That means that the only possible way to do write protect on exynos is
> using a GPIO.
>
> The above means that on exynos if the GPIO isn't defined we will
> assume no write protect. On other platforms if the GPIO isn't defined
> we'll assume that the "mci_readl" will work and we'll use that.
>
> If people would prefer it I can code up an alternate solution that
> doesn't touch any exynos code but that would introduce a new device
> tree binding. We could accomplish what's needed for exynos using a
> property like "broken-internal-wp".
>
> Please let me know if you'd like me to submit a new patch with this
> solution or if you like the existing solution.
>
Write protect is additional interface related with SD socket.
WP switch appears in SD standard size card.
In case EMMC/SDIO spec, there is no mentions about this WP pin.
As you mentioned above, that's why 'ger_ro' is called only in sd
path(mmc/core/sd.c).
So, I meant that we don't need to consider WP pin status about non-SD type.
Such as exynos5250, there is no exposed interface from host controller for
write protection pin.
In that case, if general gpio pin is connected like your board environment, we
can define wp-gpio.
Otherwise, 'broken-internal-wp' property will be good solution.
Please feel free to modify.
If you will do, I'll be happy.
Thanks,
Seungwon Jeon
> >> --
> >> 1.7.7.3
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH v3 0/9] Media Controller capture driver for DM365
On Wed November 28 2012 20:30:21 Greg Kroah-Hartman wrote: > On Wed, Nov 28, 2012 at 08:18:20PM +0100, Hans Verkuil wrote: > > On Wed November 28 2012 18:22:48 Greg Kroah-Hartman wrote: > > > On Wed, Nov 28, 2012 at 10:18:02AM -0200, Mauro Carvalho Chehab wrote: > > > > Em Wed, 28 Nov 2012 12:56:10 +0100 > > > > Hans Verkuil escreveu: > > > > > > > > > On Wed 28 November 2012 12:45:37 Dan Carpenter wrote: > > > > > > I wish people wouldn't submit big patches right before the merge > > > > > > window opens... :/ It's better to let it sit in linux-next for a > > > > > > couple weeks so people can mess with it a bit. > > > > > > > > > > It's been under review for quite some time now, and the main change > > > > > since > > > > > the last posted version is that this is now moved to staging/media. > > > > > > > > > > So it is not yet ready for prime time, but we do want it in to > > > > > simplify > > > > > the last remaining improvements needed to move it to drivers/media. > > > > > > > > "last remaining improvements"? I didn't review the patchset, but > > > > the TODO list seems to have several pending stuff there: > > > > > > > > +- User space interface refinement > > > > +- Controls should be used when possible rather than private > > > > ioctl > > > > +- No enums should be used > > > > +- Use of MC and V4L2 subdev APIs when applicable > > > > +- Single interface header might suffice > > > > +- Current interface forces to configure everything at once > > > > +- Get rid of the dm365_ipipe_hw.[ch] layer > > > > +- Active external sub-devices defined by link configuration; no strcmp > > > > + needed > > > > +- More generic platform data (i2c adapters) > > > > +- The driver should have no knowledge of possible external subdevs; see > > > > + struct vpfe_subdev_id > > > > +- Some of the hardware control should be refactorede > > > > +- Check proper serialisation (through mutexes and spinlocks) > > > > +- Names that are visible in kernel global namespace should have a > > > > common > > > > + prefix (or a few) > > > > > > > > From the above comments, both Kernelspace and Userspace APIs require > > > > lots of work. > > > > And that's why it is in staging. Should a long TODO list now suddenly > > prevent staging from being used? In Barcelona we discussed this and the > > only requirement we came up was was that it should compile. > > Yes, that's all I care about in staging, but as I stated, I don't > maintain drivers/staging/media/ that area is under Mauro's control > (MAINTAINERS even says this), and I'm a bit leery of going against the > wishes of an existing subsystem maintainer for adding staging drivers > that tie into their subsystem. > > So if you get Mauro's approval, I'll be glad to queue it up. Just for the record, my comments were addressed to Mauro, not to you. I should have stated that in my mail explicitly. As you said, it's Mauro's decision. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] zram: Fix use-after-free bug in disk write case
Changelog v2 vs v1:
- Changelog message now correctly explains the problem
Fixes a bug introduced by commit c8f2f0db1 ("zram: Fix handling
of incompressible pages") which caused a freed buffer to be used
in case a partial write (non PAGE_SIZED) request is received and
the data is found to be incompressible.
Fixes bug 50081:
https://bugzilla.kernel.org/show_bug.cgi?id=50081
Signed-off-by: Nitin Gupta
Reported-by: Mihail Kasadjikov
Reported-by: Tomas M
Reviewed-by: Minchan Kim
---
drivers/staging/zram/zram_drv.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index fb4a7c9..f2a73bd 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -265,7 +265,7 @@ out_cleanup:
static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index,
int offset)
{
- int ret;
+ int ret = 0;
size_t clen;
unsigned long handle;
struct page *page;
@@ -286,10 +286,8 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
goto out;
}
ret = zram_decompress_page(zram, uncmem, index);
- if (ret) {
- kfree(uncmem);
+ if (ret)
goto out;
- }
}
/*
@@ -302,16 +300,18 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
user_mem = kmap_atomic(page);
- if (is_partial_io(bvec))
+ if (is_partial_io(bvec)) {
memcpy(uncmem + offset, user_mem + bvec->bv_offset,
bvec->bv_len);
- else
+ kunmap_atomic(user_mem);
+ user_mem = NULL;
+ } else {
uncmem = user_mem;
+ }
if (page_zero_filled(uncmem)) {
- kunmap_atomic(user_mem);
- if (is_partial_io(bvec))
- kfree(uncmem);
+ if (!is_partial_io(bvec))
+ kunmap_atomic(user_mem);
zram_stat_inc(>stats.pages_zero);
zram_set_flag(zram, index, ZRAM_ZERO);
ret = 0;
@@ -321,9 +321,11 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
ret = lzo1x_1_compress(uncmem, PAGE_SIZE, src, ,
zram->compress_workmem);
- kunmap_atomic(user_mem);
- if (is_partial_io(bvec))
- kfree(uncmem);
+ if (!is_partial_io(bvec)) {
+ kunmap_atomic(user_mem);
+ user_mem = NULL;
+ uncmem = NULL;
+ }
if (unlikely(ret != LZO_E_OK)) {
pr_err("Compression failed! err=%d\n", ret);
@@ -332,8 +334,10 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
if (unlikely(clen > max_zpage_size)) {
zram_stat_inc(>stats.bad_compress);
- src = uncmem;
clen = PAGE_SIZE;
+ src = NULL;
+ if (is_partial_io(bvec))
+ src = uncmem;
}
handle = zs_malloc(zram->mem_pool, clen);
@@ -345,7 +349,11 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
}
cmem = zs_map_object(zram->mem_pool, handle, ZS_MM_WO);
+ if ((clen == PAGE_SIZE) && !is_partial_io(bvec))
+ src = kmap_atomic(page);
memcpy(cmem, src, clen);
+ if ((clen == PAGE_SIZE) && !is_partial_io(bvec))
+ kunmap_atomic(src);
zs_unmap_object(zram->mem_pool, handle);
@@ -358,9 +366,10 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
if (clen <= PAGE_SIZE / 2)
zram_stat_inc(>stats.good_compress);
- return 0;
-
out:
+ if (is_partial_io(bvec))
+ kfree(uncmem);
+
if (ret)
zram_stat64_inc(zram, >stats.failed_writes);
return ret;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] zsmalloc: add function to query object size
On Mon, Nov 26, 2012 at 11:26:40PM -0800, Nitin Gupta wrote:
> Adds zs_get_object_size(handle) which provides the size of
> the given object. This is useful since the user (zram etc.)
> now do not have to maintain object sizes separately, saving
> on some metadata size (4b per page).
>
> The object handle encodes pair which currently points
Nitpick.
in descrption would be proper instead of
. You are going to replace with .
> to the start of the object. Now, the handle implicitly stores the size
> information by pointing to the object's end instead. Since zsmalloc is
> a slab based allocator, the start of the object can be easily determined
> and the difference between the end offset encoded in the handle and the
> start gives us the object size.
It's a good idea. Look at just minor comment below.
Let's talk with another concern. This patch surely helps current
customer's memory usage who should add 4 byte for accounting the
statistics while zsmalloc could be slow down.
Is it really valuable?
Yes. zram/zcache had a tight coupling with zsmalloc so it already
lost modularity. :( In this POV, this patch makes sense.
But if someone are willing to remove statistics for performance?
Although he remove it, zsmalloc is still slow down.
Statistic for user of zsmalloc should be cost of user himself, not zsmalloc
and it accelerates dependency with customer so it makes changing allocator
hard in future. We already had such experience(xvmalloc->zsmalloc). Of course,
it's not good that worry future things too early without any plan.
So I'm not strong againt you. If any reviewer don't raise an eyebrow,
I wil rely on your decision.
Thanks.
>
> Signed-off-by: Nitin Gupta
> ---
> drivers/staging/zsmalloc/zsmalloc-main.c | 177
> +-
> drivers/staging/zsmalloc/zsmalloc.h |1 +
> 2 files changed, 127 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
> b/drivers/staging/zsmalloc/zsmalloc-main.c
> index 09a9d35..65c9d3b 100644
> --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> @@ -112,20 +112,20 @@
> #define MAX_PHYSMEM_BITS 36
> #else /* !CONFIG_HIGHMEM64G */
> /*
> - * If this definition of MAX_PHYSMEM_BITS is used, OBJ_INDEX_BITS will just
> + * If this definition of MAX_PHYSMEM_BITS is used, OFFSET_BITS will just
> * be PAGE_SHIFT
> */
> #define MAX_PHYSMEM_BITS BITS_PER_LONG
> #endif
> #endif
> #define _PFN_BITS(MAX_PHYSMEM_BITS - PAGE_SHIFT)
> -#define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS)
> -#define OBJ_INDEX_MASK ((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
> +#define OFFSET_BITS (BITS_PER_LONG - _PFN_BITS)
> +#define OFFSET_MASK ((_AC(1, UL) << OFFSET_BITS) - 1)
>
> #define MAX(a, b) ((a) >= (b) ? (a) : (b))
> /* ZS_MIN_ALLOC_SIZE must be multiple of ZS_ALIGN */
> #define ZS_MIN_ALLOC_SIZE \
> - MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
> + MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OFFSET_BITS))
> #define ZS_MAX_ALLOC_SIZEPAGE_SIZE
>
> /*
> @@ -256,6 +256,11 @@ static int is_last_page(struct page *page)
> return PagePrivate2(page);
> }
>
> +static unsigned long get_page_index(struct page *page)
IMO, first_obj_offset(struct page *page) would be better readable.
> +{
> + return is_first_page(page) ? 0 : page->index;
> +}
> +
> static void get_zspage_mapping(struct page *page, unsigned int *class_idx,
> enum fullness_group *fullness)
> {
> @@ -433,39 +438,86 @@ static struct page *get_next_page(struct page *page)
> return next;
> }
>
> -/* Encode as a single handle value */
> -static void *obj_location_to_handle(struct page *page, unsigned long obj_idx)
> +static struct page *get_prev_page(struct page *page)
> {
> - unsigned long handle;
> + struct page *prev, *first_page;
>
> - if (!page) {
> - BUG_ON(obj_idx);
> - return NULL;
> - }
> + first_page = get_first_page(page);
> + if (page == first_page)
> + prev = NULL;
> + else if (page == (struct page *)first_page->private)
> + prev = first_page;
> + else
> + prev = list_entry(page->lru.prev, struct page, lru);
>
> - handle = page_to_pfn(page) << OBJ_INDEX_BITS;
> - handle |= (obj_idx & OBJ_INDEX_MASK);
> + return prev;
>
> - return (void *)handle;
> }
>
> -/* Decode pair from the given object handle */
> -static void obj_handle_to_location(unsigned long handle, struct page **page,
> - unsigned long *obj_idx)
> +static void *encode_ptr(struct page *page, unsigned long offset)
> {
> - *page = pfn_to_page(handle >> OBJ_INDEX_BITS);
> - *obj_idx = handle & OBJ_INDEX_MASK;
> + unsigned long ptr;
> + ptr = page_to_pfn(page) << OFFSET_BITS;
> + ptr |= offset & OFFSET_MASK;
> + return (void *)ptr;
> +}
> +
> +static void
Re: [PATCH 01/14] perf tool: Introduce perf_hpp__list for period related columns
Hi Jiri,
On Wed, 28 Nov 2012 14:52:36 +0100, Jiri Olsa wrote:
> Adding perf_hpp__list list to register and contain all period
> related columns the command is interested in.
>
> This way we get rid of static array holding all possible
> columns and enable commands to register their own columns.
But it seems you didn't get rid of the array? :)
>
> It'll be handy for diff command in future to process and display
> data for multiple files.
[snip]
> diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
> index 8b091a5..a935a60 100644
> --- a/tools/perf/util/hist.h
> +++ b/tools/perf/util/hist.h
> @@ -126,13 +126,19 @@ struct perf_hpp {
> };
>
> struct perf_hpp_fmt {
> - bool cond;
> int (*header)(struct perf_hpp *hpp);
> int (*width)(struct perf_hpp *hpp);
> int (*color)(struct perf_hpp *hpp, struct hist_entry *he);
> int (*entry)(struct perf_hpp *hpp, struct hist_entry *he);
> +
> + struct list_head list;
> };
>
> +extern struct list_head perf_hpp__list;
> +
> +#define perf_hpp__for_each_format(format) \
> + list_for_each_entry(format, _hpp__list, list)
> +
> extern struct perf_hpp_fmt perf_hpp__format[];
Instead of using new perf_hpp__list, how about this?
#define perf_hpp__for_each_format(fmt) \
for (fmt = _hpp__format[0]; fmt <
_hpp__format[PERF_HPP__MAX_INDEX]; fmt++) \
if (fmt->cond)
Thanks,
Namhyung
>
> enum {
> @@ -155,7 +161,8 @@ enum {
> };
>
> void perf_hpp__init(void);
> -void perf_hpp__column_enable(unsigned col, bool enable);
> +void perf_hpp__column_register(struct perf_hpp_fmt *format);
> +void perf_hpp__column_enable(unsigned col);
> int hist_entry__period_snprintf(struct perf_hpp *hpp, struct hist_entry *he,
> bool color);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/9] Media Controller capture driver for DM365
On Thu November 29 2012 00:47:41 Sylwester Nawrocki wrote: > On 11/28/2012 10:29 PM, Dan Carpenter wrote: > > On Wed, Nov 28, 2012 at 08:30:04PM +0100, Sylwester Nawrocki wrote: > >> On 11/28/2012 01:22 PM, Dan Carpenter wrote: > >>> In the end this is just a driver, and I don't especially care. But > >>> it's like not just this one which makes me frustrated. I really > >>> believe in linux-next and I think everything should spend a couple > >>> weeks there before being merged. > >> > >> Couple of weeks in linux-next plus a couple of weeks of final patch > >> series version awaiting to being reviewed and picked up by a maintainer > >> makes almost entire kernel development cycle. These are huge additional > >> delays, especially in the embedded world. Things like these certainly > >> aren't encouraging for moving over from out-of-tree to the mainline > >> development process. And in this case we are talking only about merging > >> driver to the staging tree... > > > > Yeah. A couple weeks is probably too long. But I think a week is > > totally reasonable. > > Agreed, exactly that couple weeks requirement seemed a bit long to me. > > > You have the process wrong. The maintainer reviews it first, merges > > it into his -next git tree. It sits in linux-next for a bit. The > > merge window opens up. It is merged. It gets tested for 3 months. > > It is released. > > I believe what you're describing is true for most subsystems. At > linux-media the process looks roughly that you prepare a patch and post > it to the mailing list for review. Regular developers review it, you > address the comments and submit again. Repeat these steps until > everyone's happy. Then, when the patch looks like it is ready for > merging it is preferred to send the maintainer a pull request. > Now there can be a delay of up to couple weeks. Afterwards the patch > in most cases gets merged, with a few possible change requests. However > it may happen the maintainer has different views on what's has been > agreed before and you start everything again. Yes, and the problem is that the maintainer (Mauro) tends to look at this close to the merge window, generally leaving you with very little time to make adjustments. In all honesty, in this particular case the pull request came in late because other reviewers asked TI to move the driver to staging because we thought the driver wasn't quite ready yet. If it would just be merged as a staging driver, then it would most likely be sitting in linux-next by now since a few days, well in time for the merge window. Instead we are having this whole discussion :-( > With a few sub-maintainers recently appointed hopefully there can be > seen some improvement. I sincerely hope so. Of course, since I'm going to be one of the sub-maintainers I'm going to see this from the other side as well, so I might get the same critisism in the future :-) > > It should work as a continuous even flow. It shouldn't be a rush to > > submit drivers right before the merge window opens. It's not hard, > > you can submit a driver to linux-next at any time. It magically > > flows through the process and is released some months later. > > > > It does suck to add a 3 month delay for people who miss the cut off. > > Don't wait until the last minute. In the embedded world you can > > use git cherry-pick to get the driver from linux-next. > > Yeah, it's not unusual to work with specific -rc tree with multiple > subsystem -next branches on top of it. > > It's just those cases where you're told to get feature A in the kernel > release X and it is already late in the development cycle... But it > might just be a matter of planning the work adequately with proper > understanding of the whole process. Well, it would work if you can rely on patches being reviewed and merged in a timely manner. Hopefully that will happen when the sub-maintainers can start next year. It should make everything more predictable. Regards, Hans -- 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: kernel BUG at mm/huge_memory.c:212!
Hi Jiri,
On Wed, Nov 28, 2012 at 5:18 AM, Jiri Slaby wrote:
> Hi,
>
> I've hit BUG_ON(atomic_dec_and_test(_zero_refcount)) in
> put_huge_zero_page right now. There are some "Bad rss-counter state"
> before that, but those are perhaps unrelated as I saw many of them in
> the previous -next. But even with yesterday's next I got the BUG.
>
Could you please give more details about your test or how to trigger this BUG?
I'm using kernel with huge zero page feature but haven't seen it yet.
> [ 7395.654928] BUG: Bad rss-counter state mm:8800088289c0 idx:1 val:-1
> [ 7417.652911] BUG: Bad rss-counter state mm:880008829a00 idx:1 val:-1
> [ 7423.317027] BUG: Bad rss-counter state mm:8800088296c0 idx:1 val:-1
> [ 7463.737596] BUG: Bad rss-counter state mm:88000882ad80 idx:1 val:-2
> [ 7486.462237] BUG: Bad rss-counter state mm:880008829040 idx:1 val:-2
> [ 7499.118560] BUG: Bad rss-counter state mm:880008829040 idx:1 val:-2
> [ 7507.000464] BUG: Bad rss-counter state mm:880008828000 idx:1 val:-2
> [ 7512.898902] BUG: Bad rss-counter state mm:880008829380 idx:1 val:-2
> [ 7522.299066] BUG: Bad rss-counter state mm:8800088296c0 idx:1 val:-2
> [ 7530.471048] BUG: Bad rss-counter state mm:8800088296c0 idx:1 val:-2
> [ 7597.602661] BUG: 'atomic_dec_and_test(_zero_refcount)' is true!
> [ 7597.602683] [ cut here ]
> [ 7597.602711] kernel BUG at /l/latest/linux/mm/huge_memory.c:212!
> [ 7597.602732] invalid opcode: [#1] SMP
> [ 7597.602751] Modules linked in: vfat fat dvb_usb_dib0700 dib0090
> dib7000p dib7000m dib0070 dib8000 dib3000mc dibx000_common microcode
> [ 7597.602811] CPU 1
> [ 7597.602823] Pid: 1221, comm: java Not tainted
> 3.7.0-rc6-next-20121126_64+ #1698 To Be Filled By O.E.M. To Be Filled By
> O.E.M./To be filled by O.E.M.
> [ 7597.602867] RIP: 0010:[] []
> put_huge_zero_page+0x2e/0x30
> [ 7597.602902] RSP: :8801a58cdd48 EFLAGS: 00010292
> [ 7597.602921] RAX: 0038 RBX: 880183cc0d00 RCX:
> 0007
> [ 7597.602944] RDX: 00b5 RSI: 0046 RDI:
> 81dc605c
> [ 7597.602967] RBP: 8801a58cdd48 R08: 746127203a475542 R09:
> 047b
> [ 7597.602990] R10: 6365645f63696d6f R11: 7365745f646e615f R12:
> 7fd4b3e0
> [ 7597.603014] R13: 7fd4b3dcc000 R14: 8801bdebab00 R15:
> 81d94225
> [ 7597.603037] FS: 7fd4c7ebe700() GS:8801cbc8()
> knlGS:
> [ 7597.603064] CS: 0010 DS: ES: CR0: 80050033
> [ 7597.603083] CR2: 7fd4b3dcc498 CR3: 00017d6bc000 CR4:
> 07e0
> [ 7597.603106] DR0: DR1: DR2:
>
> [ 7597.603129] DR3: DR6: 0ff0 DR7:
> 0400
> [ 7597.603152] Process java (pid: 1221, threadinfo 8801a58cc000,
> task 8801a4655be0)
> [ 7597.603178] Stack:
> [ 7597.603187] 8801a58cddc8 8116b8d4 8801a38cb000
> 8801bdebab00
> [ 7597.603219] 880183cc0d00 0001a38cb067 ea0006cccb40
> 8801a3911cf0
> [ 7597.603250] 0001b332d000 7fd4b3c0 880183cc0d00
> 7fd4b3dcc498
> [ 7597.603282] Call Trace:
> [ 7597.603293] [] do_huge_pmd_wp_page+0x7e4/0x900
> [ 7597.603316] [] handle_mm_fault+0x145/0x330
> [ 7597.603337] [] __do_page_fault+0x145/0x480
> [ 7597.603358] [] ? sched_clock_local+0x25/0xa0
> [ 7597.603378] [] ? __enqueue_entity+0x78/0x80
> [ 7597.603400] [] ? sys_futex+0x8d/0x190
> [ 7597.603420] [] do_page_fault+0xe/0x10
> [ 7597.603440] [] page_fault+0x22/0x30
> [ 7597.603458] Code: 66 90 f0 ff 0d c0 05 cf 00 0f 94 c0 84 c0 75 02 f3
> c3 55 48 c7 c6 60 51 97 81 48 c7 c7 1a 82 94 81 48 89 e5 31 c0 e8 25 60
> 54 00 <0f> 0b 66 66 66 66 90 55 48 89 e5 53 48 83 ec 08 48 83 7e 08 00
> [ 7597.603640] RIP [] put_huge_zero_page+0x2e/0x30
> [ 7597.603664] RSP
> [ 7597.636299] ---[ end trace 241e96a56fc0cf87 ]---
> [ 7612.907136] SysRq : Keyboard mode set to system default
>
Btw: Could you have a try with below patch? I think it might be
related but not sure.
Thank you!
(Sorry i can only use web email currently so the patch format may be incorrect)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 4489e16..d282d80 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1096,7 +1096,7 @@ pgtable_t get_pmd_huge_pte(struct mm_struct *mm)
static int do_huge_pmd_wp_zero_page_fallback(struct mm_struct *mm,
struct vm_area_struct *vma, unsigned long address,
- pmd_t *pmd, unsigned long haddr)
+ pmd_t *pmd, pmd_t orig_pmd, unsigned long haddr)
{
pgtable_t pgtable;
pmd_t _pmd;
@@ -1125,6 +1125,10 @@ static int
do_huge_pmd_wp_zero_page_fallback(struct mm_struct *mm,
mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
spin_lock(>page_table_lock);
+ if (unlikely(!pmd_same(*pmd, orig_pmd))) {
+ WARN_ON(1);
+ goto
Re: [RFC,v2,8/8] drm: tegra: Add gr2d device
On 11/26/2012 09:19 PM, Terje Bergström wrote:
> Add client driver for 2D device.
>
> Signed-off-by: Arto Merilainen
> Signed-off-by: Terje Bergstrom
>
> ---
>
[...]
> +
> +static int
> +tegra_drm_ioctl_open_channel(struct drm_device *drm, void *data,
> + struct drm_file *file_priv)
> +{
> + struct tegra_drm_open_channel_args *args = data;
> + struct tegra_drm_client *client;
> + struct tegra_drm_context *context;
> + struct tegra_drm_fpriv *fpriv = tegra_drm_fpriv(file_priv);
> + int err = 0;
> +
> + dev_dbg(drm->dev, "> %s(fpriv=%p, class=%x)\n", __func__,
> + fpriv, args->class);
> +
> + context = kzalloc(sizeof(*context), GFP_KERNEL);
> + if (!context) {
> + err = -ENOMEM;
> + goto out;
Change to "return -ENOMEM". Otherwise the NULL "context" will be kfree.
> + }
> +
> + list_for_each_entry(client, _drm_subdrv_list, list) {
> + if (client->class == args->class) {
> + dev_dbg(drm->dev, "opening client %x\n", args->class);
> + context->client = client;
> + err = client->ops->open_channel(client, context);
> + if (err)
> + goto out;
> +
> + dev_dbg(drm->dev, "context %p\n", context);
> + list_add(>list, >contexts);
> + args->context = context;
> + goto out;
> + }
> + }
> + err = -ENODEV;
> +
> +out:
> + if (err)
> + kfree(context);
> +
> + dev_dbg(drm->dev, "< %s() = %d\n", __func__, err);
> + return err;
> +}
> +
> +static int
> +tegra_drm_ioctl_close_channel(struct drm_device *drm, void *data,
> + struct drm_file *file_priv)
> +{
> + struct tegra_drm_open_channel_args *args = data;
> + struct tegra_drm_context *context;
> + struct tegra_drm_fpriv *fpriv = tegra_drm_fpriv(file_priv);
> + int err = 0;
> +
> + dev_dbg(drm->dev, "> %s(fpriv=%p)\n", __func__, fpriv);
> + list_for_each_entry(context, >contexts, list) {
Consider "list_for_each_entry_safe" cause you remove list members during
the loop.
> + if (context == args->context) {
> + context->client->ops->close_channel(context);
> + list_del(>list);
> + kfree(context);
> + goto out;
> + }
> + }
> + err = -EINVAL;
> +
> +out:
> + dev_dbg(drm->dev, "< %s() = %d\n", __func__, err);
> + return err;
> +}
> +
[...]
> +
> +static int gr2d_submit(struct tegra_drm_context *context,
> + struct tegra_drm_submit_args *args)
I'm still in the middle of code reading of job submit, so I'll get you
back if I find something.
[...]
> +
> +static struct of_device_id gr2d_match[] __devinitdata = {
> + { .compatible = "nvidia,tegra20-gr2d", },
> + { .compatible = "nvidia,tegra30-gr2d", },
Just as swarren mentioned, you'd better place "nvidia,tegra30-gr2d" in
the front of "nvidia,tegra20-gr2d"...
[...]
> +
> +#define DRM_TEGRA_GEM_CREATE 0x00
> +
> +#define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + \
> + DRM_TEGRA_GEM_CREATE, struct tegra_gem_create)
> +
Just a very minor suggestion: could you put them at the end of this
file? I mean, stay with other IOCTLs like SYNCPT_READ, SYNCPT_WAIT...
[...]
> +
> +#define DRM_TEGRA_DRM_SYNCPT_READ 0x01
> +#define DRM_TEGRA_DRM_SYNCPT_INCR 0x02
> +#define DRM_TEGRA_DRM_SYNCPT_WAIT 0x03
> +#define DRM_TEGRA_DRM_OPEN_CHANNEL 0x04
> +#define DRM_TEGRA_DRM_CLOSE_CHANNEL 0x05
> +#define DRM_TEGRA_DRM_GET_SYNCPOINTS 0x06
> +#define DRM_TEGRA_DRM_GET_MODMUTEXES 0x07
> +#define DRM_TEGRA_DRM_SUBMIT 0x08
> +
> +#define DRM_IOCTL_TEGRA_DRM_SYNCPT_READ DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_SYNCPT_READ, struct tegra_drm_syncpt_read_args)
> +#define DRM_IOCTL_TEGRA_DRM_SYNCPT_INCR DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_SYNCPT_INCR, struct tegra_drm_syncpt_incr_args)
> +#define DRM_IOCTL_TEGRA_DRM_SYNCPT_WAIT DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_SYNCPT_WAIT, struct tegra_drm_syncpt_wait_args)
> +#define DRM_IOCTL_TEGRA_DRM_OPEN_CHANNEL DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_OPEN_CHANNEL, struct tegra_drm_open_channel_args)
> +#define DRM_IOCTL_TEGRA_DRM_CLOSE_CHANNEL DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_CLOSE_CHANNEL, struct tegra_drm_open_channel_args)
> +#define DRM_IOCTL_TEGRA_DRM_GET_SYNCPOINTS DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_GET_SYNCPOINTS, struct tegra_drm_get_channel_param_args)
> +#define DRM_IOCTL_TEGRA_DRM_GET_MODMUTEXES DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_GET_MODMUTEXES, struct tegra_drm_get_channel_param_args)
> +#define DRM_IOCTL_TEGRA_DRM_SUBMIT DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_SUBMIT, struct tegra_drm_submit_args)
> +
> +#endif
>
--
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] tmpfs: support SEEK_DATA and SEEK_HOLE (reprise)
On 11/29/2012 02:53 PM, Jim Meyering wrote: > Jeff Liu wrote: > >> On 11/29/2012 12:15 PM, Jim Meyering wrote: >>> Hugh Dickins wrote: On Thu, 29 Nov 2012, Jaegeuk Hanse wrote: >>> ... > But this time in which scenario will use it? I was not very convinced by the grep argument from Jim and Paul: that seemed to be grep holding on to a no-arbitrary-limits dogma, at the expense of its users, causing an absurd line-length issue, which use of SEEK_DATA happens to avoid in some cases. The cp of sparse files from Jeff and Dave was more convincing; but I still didn't see why little old tmpfs needed to be ahead of the pack. But at LinuxCon/Plumbers in San Diego in August, a more convincing case was made: I was hoping you would not ask, because I did not take notes, and cannot pass on the details - was it rpm building on tmpfs? I was convinced enough to promise support on tmpfs when support on ext4 goes in. >>> >>> Re the cp-vs-sparse-file case, the current FIEMAP-based code in GNU >>> cp is ugly and complicated enough that until recently it harbored a >>> hard-to-reproduce data-corrupting bug[*]. Now that SEEK_DATA/SEEK_HOLE >>> support work will work also for tmpfs and ext4, we can plan to remove >>> the FIEMAP-based code in favor of a simpler SEEK_DATA/SEEK_HOLE-based >>> implementation. >> How do we teach du(1) to aware of the real disk footprint with Btrfs >> clone or OCFS2 reflinked files if we remove the FIEMAP-based code? >> >> How about if we still keep it there, and introduce SEEK_DATA/SEEK_HOLE >> code to the extent-scan module which is dedicated to deal with sparse files? > > Hi Jeff, > By "removing the FIEMAP-based code" I mean the uses in copy.c. > All of that should remain independent of how du does its job, > so if FIEMAP is required for your planned du enhancement, > then feel free to use it. Hi Jim, Thanks for the clarification, that's fine. :) Regards, -Jeff > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warnings after merge of the akpm tree
On Thu, Nov 29, 2012 at 05:19:39PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
> In file included from drivers/block/drbd/drbd_bitmap.c:32:0:
> drivers/block/drbd/drbd_int.h:2339:0: warning: "__wait_event_lock_irq"
> redefined [enabled by default]
> include/linux/wait.h:554:0: note: this is the location of the previous
> definition
> Introduced by the interaction of commit c1fd29a11f43 ("drbd: Fix a race
> condition that can lead to a BUG()") from the block tree and commit
> "wait: add wait_event_lock_irq() interface" from the akpm tree.
Thanks.
We can just drop our copy-n-paste-from-md.h then.
Lars
---
commit 2712ab592def9f0171b6d47349879e975db57657
Author: Lars Ellenberg
Date: Thu Nov 29 08:20:27 2012 +0100
drbd: fix merge clash: wait_event_lock_irq() is now defined in wait.h
Signed-off-by: Lars Ellenberg
diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
index ef72a72..6b51afa 100644
--- a/drivers/block/drbd/drbd_int.h
+++ b/drivers/block/drbd/drbd_int.h
@@ -2334,30 +2334,3 @@ static inline void drbd_md_flush(struct drbd_conf *mdev)
}
#endif
-
-/* This is defined in drivers/md/md.h as well. Should go into wait.h */
-#define __wait_event_lock_irq(wq, condition, lock, cmd)\
-do { \
- wait_queue_t __wait;\
- init_waitqueue_entry(&__wait, current); \
- \
- add_wait_queue(, &__wait); \
- for (;;) { \
- set_current_state(TASK_UNINTERRUPTIBLE);\
- if (condition) \
- break; \
- spin_unlock_irq(); \
- cmd;\
- schedule(); \
- spin_lock_irq(); \
- } \
- current->state = TASK_RUNNING; \
- remove_wait_queue(, &__wait);\
-} while (0)
-
-#define wait_event_lock_irq(wq, condition, lock, cmd) \
-do { \
- if (condition) \
- break; \
- __wait_event_lock_irq(wq, condition, lock, cmd);\
-} while (0)
diff --git a/drivers/block/drbd/drbd_state.c b/drivers/block/drbd/drbd_state.c
index 69ef352..53bf618 100644
--- a/drivers/block/drbd/drbd_state.c
+++ b/drivers/block/drbd/drbd_state.c
@@ -1800,8 +1800,7 @@ _conn_request_state(struct drbd_tconn *tconn, union
drbd_state mask, union drbd_
spin_lock_irq(>req_lock);
wait_event_lock_irq(tconn->ping_wait,
(rv = _conn_rq_cond(tconn, mask, val)),
- tconn->req_lock,
- );
+ tconn->req_lock);
clear_bit(CONN_WD_ST_CHG_REQ, >flags);
if (rv < SS_SUCCESS)
goto abort;
--
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 REPORT] [mm-hotplug, aio] aio ring_pages can't be offlined
Hi all, We encounter a "Resource temporarily unavailable" fail while trying to offline a memory section in a movable zone. We found that there are some pages can't be migrated. The offline operation fails in function migrate_page_move_mapping() returning -EAGAIN till timeout because the if assertion 'page_count(page) != 1' fails. I wonder in the case 'page_count(page) != 1', should we always wait (return -EAGAING)? Or in other words, can we do something here for migration if we know where the pages from? And finally found that such pages are used by /sbin/multipathd in the form of aio ring_pages. Besides once increment introduced by the offline calling chain, another increment is added by aio_setup_ring() via callling get_userpages(), it won't decrease until we call aio_free_ring(). The dump_page info in the offline context is showed as following: page:ea0011e69140 count:2 mapcount:0 mapping:8801d6949881 index:0x7fc4b6d1d page flags: 0x318081d(locked|referenced|uptodate|dirty|swapbacked|unevictable) page:ea0011fb0480 count:2 mapcount:0 mapping:8801d6949881 index:0x7fc4b6d1c page flags: 0x318081d(locked|referenced|uptodate|dirty|swapbacked|unevictable) page:ea0011fbaa80 count:2 mapcount:0 mapping:8801d6949881 index:0x7fc4b6d1a page flags: 0x318081d(locked|referenced|uptodate|dirty|swapbacked|unevictable) page:ea0011ff21c0 count:2 mapcount:0 mapping:8801d6949881 index:0x7fc4b6d1b page flags: 0x318081d(locked|referenced|uptodate|dirty|swapbacked|unevictable) The multipathd seems never going to release the ring_pages until we reboot the box. Furthermore, if some guy makes app which only calls io_setup() but never calls io_destroy() for the reason that he has to keep the io_setup() for a long time or just forgets to or even on purpose that we can't expect. So I think the mm-hotplug framwork should get the capability to deal with such situation. And should we consider adding migration support for such pages? However I don't know if there are any other kinds of such particular pages in current kernel/Linux system. If unluckily there are many apparently it's hard to handle them all, just adding migrate support for aio ring_pages is insufficient. But if luckily can we use the private field of page struct to track the ring_pages[] pointer so that we can retrieve the user when migrate? Doing so another problem occurs, how to distinguish such special pages? Use pageflag may cause an impact on current pageflag layout, add new pageflag item also seems to be impossible. I'm not sure what way is the right approach, seeking for help. Any comments are extremely needed, thanks :) Thanks, linfeng -- 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] tmpfs: support SEEK_DATA and SEEK_HOLE (reprise)
Jeff Liu wrote: > On 11/29/2012 12:15 PM, Jim Meyering wrote: >> Hugh Dickins wrote: >>> On Thu, 29 Nov 2012, Jaegeuk Hanse wrote: >> ... But this time in which scenario will use it? >>> >>> I was not very convinced by the grep argument from Jim and Paul: >>> that seemed to be grep holding on to a no-arbitrary-limits dogma, >>> at the expense of its users, causing an absurd line-length issue, >>> which use of SEEK_DATA happens to avoid in some cases. >>> >>> The cp of sparse files from Jeff and Dave was more convincing; >>> but I still didn't see why little old tmpfs needed to be ahead >>> of the pack. >>> >>> But at LinuxCon/Plumbers in San Diego in August, a more convincing >>> case was made: I was hoping you would not ask, because I did not take >>> notes, and cannot pass on the details - was it rpm building on tmpfs? >>> I was convinced enough to promise support on tmpfs when support on >>> ext4 goes in. >> >> Re the cp-vs-sparse-file case, the current FIEMAP-based code in GNU >> cp is ugly and complicated enough that until recently it harbored a >> hard-to-reproduce data-corrupting bug[*]. Now that SEEK_DATA/SEEK_HOLE >> support work will work also for tmpfs and ext4, we can plan to remove >> the FIEMAP-based code in favor of a simpler SEEK_DATA/SEEK_HOLE-based >> implementation. > How do we teach du(1) to aware of the real disk footprint with Btrfs > clone or OCFS2 reflinked files if we remove the FIEMAP-based code? > > How about if we still keep it there, and introduce SEEK_DATA/SEEK_HOLE > code to the extent-scan module which is dedicated to deal with sparse files? Hi Jeff, By "removing the FIEMAP-based code" I mean the uses in copy.c. All of that should remain independent of how du does its job, so if FIEMAP is required for your planned du enhancement, then feel free to use it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the pwm tree with the driver-core tree
On Thu, Nov 29, 2012 at 04:29:45PM +1100, Stephen Rothwell wrote:
> Hi Thierry,
>
> Today's linux-next merge of the pwm tree got a conflict in
> drivers/pwm/pwm-twl6030.c between commit fd1091125a1d ("pwm: remove use
> of __devexit_p") from the driver-core tree and commit 6179a58ec7e2 ("pwm:
> Remove pwm-twl6030 driver") from the pwm tree.
>
> I fixed it up (the latter removed the file) and can carry the fix as
> necessary (no action is required).
Great, thanks!
Thierry
pgpCWpvVzoN62.pgp
Description: PGP signature
Re: linux-next: manual merge of the pwm tree with the driver-core tree
On Thu, Nov 29, 2012 at 04:27:30PM +1100, Stephen Rothwell wrote:
> Hi Thierry,
>
> Today's linux-next merge of the pwm tree got a conflict in
> drivers/pwm/pwm-tiehrpwm.c between commit 3e9fe83d278c ("pwm: remove use
> of __devinit") from the driver-core tree and commit 53ad9e8d3703 ("pwm:
> tiehrpwm: Add device-tree binding") from the pwm tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Also looking good, thanks.
Thierry
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/pwm/pwm-tiehrpwm.c
> index 9ffd389,542d5f3..000
> --- a/drivers/pwm/pwm-tiehrpwm.c
> +++ b/drivers/pwm/pwm-tiehrpwm.c
> @@@ -392,7 -403,13 +403,13 @@@ static const struct pwm_ops ehrpwm_pwm_
> .owner = THIS_MODULE,
> };
>
> + static const struct of_device_id ehrpwm_of_match[] = {
> + { .compatible = "ti,am33xx-ehrpwm" },
> + {},
> + };
> + MODULE_DEVICE_TABLE(of, ehrpwm_of_match);
> +
> -static int __devinit ehrpwm_pwm_probe(struct platform_device *pdev)
> +static int ehrpwm_pwm_probe(struct platform_device *pdev)
> {
> int ret;
> struct resource *r;
> @@@ -439,11 -471,29 +471,29 @@@
> }
>
> pm_runtime_enable(>dev);
> + pm_runtime_get_sync(>dev);
> +
> + status = pwmss_submodule_state_change(pdev->dev.parent,
> + PWMSS_EPWMCLK_EN);
> + if (!(status & PWMSS_EPWMCLK_EN_ACK)) {
> + dev_err(>dev, "PWMSS config space clock enable failed\n");
> + ret = -EINVAL;
> + goto pwmss_clk_failure;
> + }
> +
> + pm_runtime_put_sync(>dev);
> +
> platform_set_drvdata(pdev, pc);
> return 0;
> +
> + pwmss_clk_failure:
> + pm_runtime_put_sync(>dev);
> + pm_runtime_disable(>dev);
> + pwmchip_remove(>chip);
> + return ret;
> }
>
> -static int __devexit ehrpwm_pwm_remove(struct platform_device *pdev)
> +static int ehrpwm_pwm_remove(struct platform_device *pdev)
> {
> struct ehrpwm_pwm_chip *pc = platform_get_drvdata(pdev);
>
> @@@ -454,10 -512,12 +512,12 @@@
>
> static struct platform_driver ehrpwm_pwm_driver = {
> .driver = {
> - .name = "ehrpwm",
> + .name = "ehrpwm",
> + .owner = THIS_MODULE,
> + .of_match_table = ehrpwm_of_match,
> },
> .probe = ehrpwm_pwm_probe,
> -.remove = __devexit_p(ehrpwm_pwm_remove),
> +.remove = ehrpwm_pwm_remove,
> };
>
> module_platform_driver(ehrpwm_pwm_driver);
pgpid87oQZLq3.pgp
Description: PGP signature
Re: linux-next: manual merge of the pwm tree with the driver-core tree
On Thu, Nov 29, 2012 at 04:25:14PM +1100, Stephen Rothwell wrote:
> Hi Thierry,
>
> Today's linux-next merge of the pwm tree got a conflict in
> drivers/pwm/pwm-tiecap.c between commit 3e9fe83d278c ("pwm: remove use of
> __devinit") from the driver-core tree and commit 333b08ee8c6e ("pwm:
> tiecap: Add device-tree binding") from the pwm tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good to me, thanks Stephen.
Thierry
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/pwm/pwm-tiecap.c
> index 87c091b,b4f9d47..000
> --- a/drivers/pwm/pwm-tiecap.c
> +++ b/drivers/pwm/pwm-tiecap.c
> @@@ -184,7 -188,13 +188,13 @@@ static const struct pwm_ops ecap_pwm_op
> .owner = THIS_MODULE,
> };
>
> + static const struct of_device_id ecap_of_match[] = {
> + { .compatible = "ti,am33xx-ecap" },
> + {},
> + };
> + MODULE_DEVICE_TABLE(of, ecap_of_match);
> +
> -static int __devinit ecap_pwm_probe(struct platform_device *pdev)
> +static int ecap_pwm_probe(struct platform_device *pdev)
> {
> int ret;
> struct resource *r;
> @@@ -231,11 -249,29 +249,29 @@@
> }
>
> pm_runtime_enable(>dev);
> + pm_runtime_get_sync(>dev);
> +
> + status = pwmss_submodule_state_change(pdev->dev.parent,
> + PWMSS_ECAPCLK_EN);
> + if (!(status & PWMSS_ECAPCLK_EN_ACK)) {
> + dev_err(>dev, "PWMSS config space clock enable failed\n");
> + ret = -EINVAL;
> + goto pwmss_clk_failure;
> + }
> +
> + pm_runtime_put_sync(>dev);
> +
> platform_set_drvdata(pdev, pc);
> return 0;
> +
> + pwmss_clk_failure:
> + pm_runtime_put_sync(>dev);
> + pm_runtime_disable(>dev);
> + pwmchip_remove(>chip);
> + return ret;
> }
>
> -static int __devexit ecap_pwm_remove(struct platform_device *pdev)
> +static int ecap_pwm_remove(struct platform_device *pdev)
> {
> struct ecap_pwm_chip *pc = platform_get_drvdata(pdev);
>
> @@@ -246,10 -290,12 +290,12 @@@
>
> static struct platform_driver ecap_pwm_driver = {
> .driver = {
> - .name = "ecap",
> + .name = "ecap",
> + .owner = THIS_MODULE,
> + .of_match_table = ecap_of_match,
> },
> .probe = ecap_pwm_probe,
> -.remove = __devexit_p(ecap_pwm_remove),
> +.remove = ecap_pwm_remove,
> };
>
> module_platform_driver(ecap_pwm_driver);
pgpI45tXRbocg.pgp
Description: PGP signature
Re: [PATCH] Introduce a method to catch mmap_region (was: Recent kernel "mount" slow)
On Wed, Nov 28, 2012 at 10:37:27PM -0800, Linus Torvalds wrote: > On Wed, Nov 28, 2012 at 10:30 PM, Al Viro wrote: > > > > Note that sync_blockdev() a few lines prior to that is good only if we > > have no other processes doing write(2) (or dirtying the mmapped pages, > > for that matter). The window isn't too wide, but... > > So with Mikulas' patches, the write actually would block (at write > level) due to the locking. The mmap'ed patches may be around and > flushed, but the logic to not allow currently *active* mmaps (with the > rather nasty random -EBUSY return value) should mean that there is no > race. > > Or rather, there's a race, but it results in that EBUSY thing. Same as with fs mounted on it, or the sucker having been claimed for RAID array, etc. Frankly, I'm more than slightly tempted to make bdev mmap() just claim the sodding device exclusive for as long as it's mmapped... In principle, I agree, but... I still have nightmares from mmap/truncate races way back. You are stepping into what used to be a really nasty minefield. I'll look into that, but it's *definitely* not -rc8 fodder. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ARM: tegra: bus_notifier registers IOMMU devices(was: How to specify IOMMU'able devices in DT)
On Wed, 28 Nov 2012 19:07:46 +0100 Stephen Warren wrote: .. > >>> Please read more about bus notifiers. IMHO a good example is provided in > >>> the following thread: > >>> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg12238.html > >> > >> This bus notifier seems enough flexible to afford the variation of > >> IOMMU map info, like Tegra ASID, which could be platform-specific, and > >> the other could be common too. There's already iommu_bus_notifier > >> too. I'll try to implement something base on this. > > > > Experimentally implemented as below. With the followig patch, each > > device could specify its own map in DT, and automatically the device > > would be attached to the map. > > > > There is a case that some devices share a map. This patch doesn't > > suppor such case yet. > > > > From 8cb75bb6f3a8535a077e0e85265f87c1f1289bfd Mon Sep 17 00:00:00 2001 > > From: Hiroshi Doyu > > Date: Wed, 28 Nov 2012 14:47:04 +0200 > > Subject: [PATCH 1/1] ARM: tegra: bus_notifier registers IOMMU devices > > > > platform_bus notifier registers IOMMU devices if dma-window is > > specified. > > > > Its format is: > > dma-window = <"start" "size">; > > ex) > > dma-window = <0x12345000 0x8000>; > > > > Signed-off-by: Hiroshi Doyu > > --- > > arch/arm/mach-tegra/board-dt-tegra30.c | 40 > > > > Shouldn't this patch be to the IOMMU driver itself, not the core Tegra code? That could be possible and cleaner. I'll check if it works. -- 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/18] perf tools: Fix typo on hist__entry_add_pair
From: Namhyung Kim
Fix a misplaced underscore. In this case, 'hist_entry' is the name of
data structure and we usually put double underscores between data
structure and actual function name.
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 4 ++--
tools/perf/util/sort.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index cb17e2a8c6ed..d2bc05cd1708 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -785,7 +785,7 @@ void hists__match(struct hists *leader, struct hists *other)
pair = hists__find_entry(other, pos);
if (pair)
- hist__entry_add_pair(pos, pair);
+ hist_entry__add_pair(pos, pair);
}
}
@@ -806,7 +806,7 @@ int hists__link(struct hists *leader, struct hists *other)
pair = hists__add_dummy_entry(leader, pos);
if (pair == NULL)
return -1;
- hist__entry_add_pair(pair, pos);
+ hist_entry__add_pair(pair, pos);
}
}
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index b4e8c3ba559d..91ae2744e7d5 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -118,7 +118,7 @@ static inline struct hist_entry
*hist_entry__next_pair(struct hist_entry *he)
return NULL;
}
-static inline void hist__entry_add_pair(struct hist_entry *he,
+static inline void hist_entry__add_pair(struct hist_entry *he,
struct hist_entry *pair)
{
list_add_tail(>pairs.head, >pairs.node);
--
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 04/18] perf header: Add HEADER_GROUP_DESC feature
From: Namhyung Kim
Save group relationship information so that it can be restored when
perf report is running.
Cc: Jiri Olsa
Cc: Stephane Eranian
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-record.c | 3 +
tools/perf/util/header.c| 153
tools/perf/util/header.h| 2 +
3 files changed, 158 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f3151d3c70ce..d50f0dcfe1c1 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -592,6 +592,9 @@ static int __cmd_record(struct perf_record *rec, int argc,
const char **argv)
goto out_delete_session;
}
+ if (!evsel_list->nr_groups)
+ perf_header__clear_feat(>header, HEADER_GROUP_DESC);
+
/*
* perf_session__delete(session) will be called at perf_record__exit()
*/
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 195a47a8f052..6ae8185842f2 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1073,6 +1073,41 @@ static int write_pmu_mappings(int fd, struct perf_header
*h __maybe_unused,
}
/*
+ * File format:
+ *
+ * struct group_descs {
+ * u32 nr_groups;
+ * struct group_desc {
+ * charname[];
+ * u32 leader_idx;
+ * u32 nr_members;
+ * }[nr_groups];
+ * };
+ */
+static int write_group_desc(int fd, struct perf_header *h __maybe_unused,
+ struct perf_evlist *evlist)
+{
+ u32 nr_groups = evlist->nr_groups;
+ struct perf_evsel *evsel;
+
+ do_write(fd, _groups, sizeof(nr_groups));
+
+ list_for_each_entry(evsel, >entries, node) {
+ if (perf_evsel__is_group_leader(evsel) &&
+ evsel->nr_members > 1) {
+ const char *name = evsel->group_name ?: "{anon_group}";
+ u32 leader_idx = evsel->idx;
+ u32 nr_members = evsel->nr_members;
+
+ do_write_string(fd, name);
+ do_write(fd, _idx, sizeof(leader_idx));
+ do_write(fd, _members, sizeof(nr_members));
+ }
+ }
+ return 0;
+}
+
+/*
* default get_cpuid(): nothing gets recorded
* actual implementation must be in arch/$(ARCH)/util/header.c
*/
@@ -1433,6 +1468,31 @@ error:
fprintf(fp, "# pmu mappings: unable to read\n");
}
+static void print_group_desc(struct perf_header *ph, int fd __maybe_unused,
+FILE *fp)
+{
+ struct perf_session *session;
+ struct perf_evsel *evsel;
+ u32 nr = 0;
+
+ session = container_of(ph, struct perf_session, header);
+
+ list_for_each_entry(evsel, >evlist->entries, node) {
+ if (perf_evsel__is_group_leader(evsel) &&
+ evsel->nr_members > 1) {
+ fprintf(fp, "# group: %s{%s", evsel->group_name ?: "",
+ perf_evsel__name(evsel));
+
+ nr = evsel->nr_members - 1;
+ } else if (nr) {
+ fprintf(fp, ",%s", perf_evsel__name(evsel));
+
+ if (--nr == 0)
+ fprintf(fp, "}\n");
+ }
+ }
+}
+
static int __event_process_build_id(struct build_id_event *bev,
char *filename,
struct perf_session *session)
@@ -1947,6 +2007,98 @@ error:
return -1;
}
+static int process_group_desc(struct perf_file_section *section __maybe_unused,
+ struct perf_header *ph, int fd,
+ void *data __maybe_unused)
+{
+ size_t ret = -1;
+ u32 i, nr, nr_groups;
+ struct perf_session *session;
+ struct perf_evsel *evsel, *leader = NULL;
+ struct group_desc {
+ char *name;
+ u32 leader_idx;
+ u32 nr_members;
+ } *desc;
+
+ if (read(fd, _groups, sizeof(nr_groups)) != sizeof(nr_groups))
+ return -1;
+
+ if (ph->needs_swap)
+ nr_groups = bswap_32(nr_groups);
+
+ ph->env.nr_groups = nr_groups;
+ if (!nr_groups) {
+ pr_debug("group desc not available\n");
+ return 0;
+ }
+
+ desc = calloc(nr_groups, sizeof(*desc));
+ if (!desc)
+ return -1;
+
+ for (i = 0; i < nr_groups; i++) {
+ desc[i].name = do_read_string(fd, ph);
+ if (!desc[i].name)
+ goto out_free;
+
+ if (read(fd, [i].leader_idx, sizeof(u32)) != sizeof(u32))
+ goto out_free;
+
+ if (read(fd, [i].nr_members, sizeof(u32)) != sizeof(u32))
+ goto out_free;
+
+ if (ph->needs_swap) {
+
[PATCH 06/18] perf hists: Link hist entry pairs to leader
From: Namhyung Kim Current hists__match/link() link a leader to its pair, so if multiple pairs were linked, the leader will lose pointer to previous pairs since it was overwritten. Fix it by making leader the list head. Cc: Jiri Olsa Cc: Stephane Eranian Signed-off-by: Namhyung Kim --- tools/perf/util/hist.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c index d2bc05cd1708..82df1b26f0d4 100644 --- a/tools/perf/util/hist.c +++ b/tools/perf/util/hist.c @@ -785,7 +785,7 @@ void hists__match(struct hists *leader, struct hists *other) pair = hists__find_entry(other, pos); if (pair) - hist_entry__add_pair(pos, pair); + hist_entry__add_pair(pair, pos); } } @@ -806,7 +806,7 @@ int hists__link(struct hists *leader, struct hists *other) pair = hists__add_dummy_entry(leader, pos); if (pair == NULL) return -1; - hist_entry__add_pair(pair, pos); + hist_entry__add_pair(pos, pair); } } -- 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 07/18] perf hists: Exchange order of comparing items when collapsing hists
From: Namhyung Kim
When comparing entries for collapsing put the given entry first, and
then the iterated entry. This is for the sake of consistency and will
be required by the event group report.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 82df1b26f0d4..161c35e7ed0e 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -433,7 +433,7 @@ static bool hists__collapse_insert_entry(struct hists
*hists __maybe_unused,
parent = *p;
iter = rb_entry(parent, struct hist_entry, rb_node_in);
- cmp = hist_entry__collapse(iter, he);
+ cmp = hist_entry__collapse(he, iter);
if (!cmp) {
he_stat__add_stat(>stat, >stat);
--
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 00/18] perf report: Add support for event group view (v6)
Hi all,
This is my 6th iteration of event group view patchset.
For basic idea and usage example, please see my original post [1].
The largest change in this version is using 'pairs' list of hist_entry
instead of allocating group_stats for all group members. But I needed
to allocate temporary arrays for internal purpose anyway. If you have
a better solution please let me know.
Jiri, sorry for the delay. I had to hunt down some nasty bugs in my
patches. And I saw you submitted the multiplu diff series which will
conflict my changes. I'll have a look at it soon, and I'd be glad if
you take a look at my changes too. :)
You can get this series via my tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
perf/group-v6
Any comments are welcome, thanks,
Namhyung
v5 -> v6:
* set ->leader alse for leader evsel (Arnaldo)
* use hists__{match,link} (Arnaldo)
v4 -> v5:
* rebase onto acme/perf/core
v3 -> v4:
* patch 1-9 in previous post are merged.
* add Jiri's Acked-by
* add report.group config option
v2 -> v3:
* drop patch 1 since it's merged into acme/perf/core
* cherry-pick Jiri's hpp changes
* add missing bswap_32 on reading nr_groups (Jiri)
* remove perf_evlist__recalc_nr_groups() in favor of list_is_last (Jiri)
v1 -> v2:
* save group relation to header (Jiri)
[1] https://lkml.org/lkml/2012/7/24/81
Namhyung Kim (18):
perf evsel: Set leader evsel's ->leader to itself
perf evsel: Convert to _is_group_leader method
perf tools: Keep group information
perf header: Add HEADER_GROUP_DESC feature
perf tools: Fix typo on hist__entry_add_pair
perf hists: Link hist entry pairs to leader
perf hists: Exchange order of comparing items when collapsing hists
perf hists: Add hists__{match,link}_collapsed
perf symbol: Introduce symbol_conf.event_group
perf report: Make another loop for linking group hists
perf hists: Resort hist entries using group members for output
perf ui/hist: Add support for event group view
perf hist browser: Add support for event group view
perf gtk/browser: Add support for event group view
perf report: Bypass non-leader events when event group is enabled
perf report: Show group description when event group is enabled
perf report: Add --group option
perf report: Add report.group config option
tools/perf/Documentation/perf-report.txt | 3 +
tools/perf/builtin-record.c | 3 +
tools/perf/builtin-report.c | 47 +++-
tools/perf/builtin-stat.c| 2 +-
tools/perf/tests/parse-events.c | 20 +-
tools/perf/ui/browsers/hists.c | 237 ---
tools/perf/ui/gtk/browser.c | 99 ++--
tools/perf/ui/hist.c | 375 ---
tools/perf/ui/stdio/hist.c | 2 +
tools/perf/util/evlist.c | 12 +-
tools/perf/util/evlist.h | 1 +
tools/perf/util/evsel.c | 32 ++-
tools/perf/util/evsel.h | 20 +-
tools/perf/util/header.c | 153 +
tools/perf/util/header.h | 2 +
tools/perf/util/hist.c | 182 +--
tools/perf/util/hist.h | 2 +
tools/perf/util/parse-events.c | 1 +
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.y | 10 +
tools/perf/util/sort.h | 2 +-
tools/perf/util/symbol.c | 4 +
tools/perf/util/symbol.h | 3 +-
23 files changed, 934 insertions(+), 279 deletions(-)
--
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 09/18] perf symbol: Introduce symbol_conf.event_group
From: Namhyung Kim
The event_group field is for enabling event group view on perf report
and other commands. It requires collapsing hist entries since every
member in a group needs to be linked before final output resorting.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/symbol.c | 4
tools/perf/util/symbol.h | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 295f8d4feedf..a64b0bf77f32 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -15,6 +15,7 @@
#include "machine.h"
#include "symbol.h"
#include "strlist.h"
+#include "sort.h"
#include
#include
@@ -1650,6 +1651,9 @@ int symbol__init(void)
symbol_conf.kptr_restrict = symbol__read_kptr_restrict();
+ if (symbol_conf.event_group)
+ sort__need_collapse = 1;
+
symbol_conf.initialized = true;
return 0;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index de68f98b236d..8bef1452675f 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -96,7 +96,8 @@ struct symbol_conf {
initialized,
kptr_restrict,
annotate_asm_raw,
- annotate_src;
+ annotate_src,
+ event_group;
const char *vmlinux_name,
*kallsyms_name,
*source_prefix,
--
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 08/18] perf hists: Add hists__{match,link}_collapsed
From: Namhyung Kim
The current hists__match/link functions are worked on the output tree
(hists->entries). However for event group view it needs to be
matched/linked before the final resort. Thus add new helpers for
doing it on the collapsed tree.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 117 +
tools/perf/util/hist.h | 2 +
2 files changed, 101 insertions(+), 18 deletions(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 161c35e7ed0e..2af8ec6e8e26 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -717,19 +717,72 @@ void hists__inc_nr_events(struct hists *hists, u32 type)
++hists->stats.nr_events[type];
}
+struct rb_hist_fns {
+ struct rb_root * (*get_rb_root)(struct hists *);
+ struct rb_node * (*get_rb_node)(struct hist_entry *);
+ struct hist_entry * (*get_hist_entry)(struct rb_node *);
+ int64_t (*cmp_hist_entry)(struct hist_entry *, struct hist_entry *);
+};
+
+static struct rb_root *get_output_rb_root(struct hists *hists)
+{
+ return >entries;
+}
+
+static struct rb_node *get_output_rb_node(struct hist_entry *he)
+{
+ return >rb_node;
+}
+
+static struct hist_entry *get_output_hist_entry(struct rb_node *node)
+{
+ return rb_entry(node, struct hist_entry, rb_node);
+}
+
+static const struct rb_hist_fns output_fns = {
+ .get_rb_root= get_output_rb_root,
+ .get_rb_node= get_output_rb_node,
+ .get_hist_entry = get_output_hist_entry,
+ .cmp_hist_entry = hist_entry__cmp,
+};
+
+static struct rb_root *get_collapsed_rb_root(struct hists *hists)
+{
+ return >entries_collapsed;
+}
+
+static struct rb_node *get_collapsed_rb_node(struct hist_entry *he)
+{
+ return >rb_node_in;
+}
+
+static struct hist_entry *get_collapsed_hist_entry(struct rb_node *node)
+{
+ return rb_entry(node, struct hist_entry, rb_node_in);
+}
+
+static const struct rb_hist_fns collapsed_fns = {
+ .get_rb_root= get_collapsed_rb_root,
+ .get_rb_node= get_collapsed_rb_node,
+ .get_hist_entry = get_collapsed_hist_entry,
+ .cmp_hist_entry = hist_entry__collapse,
+};
+
static struct hist_entry *hists__add_dummy_entry(struct hists *hists,
-struct hist_entry *pair)
+struct hist_entry *pair,
+const struct rb_hist_fns *fns)
{
- struct rb_node **p = >entries.rb_node;
+ struct rb_root *root = fns->get_rb_root(hists);
+ struct rb_node **p = >rb_node;
struct rb_node *parent = NULL;
struct hist_entry *he;
int cmp;
while (*p != NULL) {
parent = *p;
- he = rb_entry(parent, struct hist_entry, rb_node);
+ he = fns->get_hist_entry(parent);
- cmp = hist_entry__cmp(pair, he);
+ cmp = fns->cmp_hist_entry(pair, he);
if (!cmp)
goto out;
@@ -742,10 +795,12 @@ static struct hist_entry *hists__add_dummy_entry(struct
hists *hists,
he = hist_entry__new(pair);
if (he) {
+ struct rb_node *n = fns->get_rb_node(he);
+
memset(>stat, 0, sizeof(he->stat));
he->hists = hists;
- rb_link_node(>rb_node, parent, p);
- rb_insert_color(>rb_node, >entries);
+ rb_link_node(n, parent, p);
+ rb_insert_color(n, root);
hists__inc_nr_entries(hists, he);
}
out:
@@ -753,13 +808,15 @@ out:
}
static struct hist_entry *hists__find_entry(struct hists *hists,
- struct hist_entry *he)
+ struct hist_entry *he,
+ const struct rb_hist_fns *fns)
{
- struct rb_node *n = hists->entries.rb_node;
+ struct rb_root *root = fns->get_rb_root(hists);
+ struct rb_node *n = root->rb_node;
while (n) {
- struct hist_entry *iter = rb_entry(n, struct hist_entry,
rb_node);
- int64_t cmp = hist_entry__cmp(he, iter);
+ struct hist_entry *iter = fns->get_hist_entry(n);
+ int64_t cmp = fns->cmp_hist_entry(he, iter);
if (cmp < 0)
n = n->rb_left;
@@ -775,35 +832,49 @@ static struct hist_entry *hists__find_entry(struct hists
*hists,
/*
* Look for pairs to link to the leader buckets (hist_entries):
*/
-void hists__match(struct hists *leader, struct hists *other)
+static void __hists__match(struct hists *leader, struct hists *other,
+ const struct rb_hist_fns *fns)
{
+ struct rb_root *root = fns->get_rb_root(leader);
struct rb_node
[PATCH 10/18] perf report: Make another loop for linking group hists
From: Namhyung Kim
Now the event grouping viewing requires linking all member hists in a
group to the leader's. Thus hists__output_resort should be called
after linking all events in evlist.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index fc251005dd3d..13a2cd20a1cd 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -416,8 +416,16 @@ static int __cmd_report(struct perf_report *rep)
hists->symbol_filter_str = rep->symbol_filter_str;
hists__collapse_resort(hists);
- hists__output_resort(hists);
nr_samples += hists->stats.nr_events[PERF_RECORD_SAMPLE];
+
+ /* Non-group events are considered as leader */
+ if (symbol_conf.event_group &&
+ !perf_evsel__is_group_leader(pos)) {
+ struct hists *leader_hists = >leader->hists;
+
+ hists__match_collapsed(leader_hists, hists);
+ hists__link_collapsed(leader_hists, hists);
+ }
}
if (nr_samples == 0) {
@@ -425,6 +433,9 @@ static int __cmd_report(struct perf_report *rep)
goto out_delete;
}
+ list_for_each_entry(pos, >evlist->entries, node)
+ hists__output_resort(>hists);
+
if (use_browser > 0) {
if (use_browser == 1) {
perf_evlist__tui_browse_hists(session->evlist, help,
--
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] omap: craneboard: support the TPS65910 PMU
This patch supports the TPS65910 PMU function on the AM3517 Craneboard.
The IRQ pin, SYS_NIRQ is dedicated connection between the AM3517 and
the TPS65910 PMU.
To handle the PMU IRQs, mux configuration is required.
Platform data configuration:
.IRQ number : SYS_NIRQ (M_IRQ_7)
.External clock source : external 32KHz clock is connected
Signed-off-by: Milo(Woogyom) Kim
---
arch/arm/mach-omap2/board-am3517crane.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 37646e5..82805de 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -41,6 +42,7 @@
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -86,6 +88,24 @@ static struct mtd_partition crane_nand_partitions[] = {
},
};
+static struct tps65910_board tps65910_pdata = {
+ .irq = 7 + OMAP_INTC_START,
+ .en_ck32k_xtal = true,
+};
+
+static struct i2c_board_info __initdata tps65910_board_info[] = {
+ {
+ I2C_BOARD_INFO("tps65910", 0x2d),
+ .platform_data = _pdata,
+ },
+};
+
+static void __init am3517_crane_i2c_init(void)
+{
+ omap_register_i2c_bus(1, 2600, tps65910_board_info,
+ ARRAY_SIZE(tps65910_board_info));
+}
+
static void __init am3517_crane_init(void)
{
int ret;
@@ -96,6 +116,7 @@ static void __init am3517_crane_init(void)
board_nand_init(crane_nand_partitions,
ARRAY_SIZE(crane_nand_partitions), 0,
NAND_BUSWIDTH_16, NULL);
+ am3517_crane_i2c_init();
/* Configure GPIO for EHCI port */
if (omap_mux_init_gpio(GPIO_USB_NRESET, OMAP_PIN_OUTPUT)) {
--
1.7.9.5
Best Regards,
Milo
--
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/18] perf hists: Resort hist entries using group members for output
From: Namhyung Kim
When event group is enabled, sorting hist entries on periods for
output should consider groups members' period also. To do that, build
period table using link/pair information and compare the table.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/evsel.h | 2 ++
tools/perf/util/hist.c | 59 -
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 887834ed0af1..54a8efbd8dcb 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -78,6 +78,8 @@ struct perf_evsel {
char*group_name;
};
+#define hists_to_evsel(h) container_of(h, struct perf_evsel, hists)
+
struct cpu_map;
struct thread_map;
struct perf_evlist;
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 2af8ec6e8e26..be03277732e7 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -4,6 +4,7 @@
#include "hist.h"
#include "session.h"
#include "sort.h"
+#include "evsel.h"
#include
static bool hists__filter_entry_by_dso(struct hists *hists,
@@ -523,6 +524,62 @@ void hists__collapse_resort_threaded(struct hists *hists)
* reverse the map, sort on period.
*/
+static int period_cmp(u64 period_a, u64 period_b)
+{
+ if (period_a > period_b)
+ return 1;
+ if (period_a < period_b)
+ return -1;
+ return 0;
+}
+
+static int hist_entry__sort_on_period(struct hist_entry *a,
+ struct hist_entry *b)
+{
+ int ret;
+ int i, nr_members;
+ struct perf_evsel *evsel;
+ struct hist_entry *pair;
+ u64 *periods_a, *periods_b;
+
+ ret = period_cmp(a->stat.period, b->stat.period);
+ if (ret || !symbol_conf.event_group)
+ return ret;
+
+ evsel = hists_to_evsel(a->hists);
+ nr_members = evsel->nr_members;
+ if (nr_members <= 1)
+ return ret;
+
+ periods_a = zalloc(sizeof(periods_a) * nr_members);
+ periods_b = zalloc(sizeof(periods_b) * nr_members);
+
+ if (!periods_a || !periods_b)
+ goto out;
+
+ list_for_each_entry(pair, >pairs.head, pairs.node) {
+ evsel = hists_to_evsel(pair->hists);
+ periods_a[perf_evsel__group_idx(evsel)] = pair->stat.period;
+ }
+
+ list_for_each_entry(pair, >pairs.head, pairs.node) {
+ evsel = hists_to_evsel(pair->hists);
+ periods_b[perf_evsel__group_idx(evsel)] = pair->stat.period;
+ }
+
+ for (i = 1; i < nr_members; i++) {
+ ret = period_cmp(periods_a[i], periods_b[i]);
+ if (ret)
+ break;
+ }
+
+out:
+ free(periods_a);
+ free(periods_b);
+
+ return ret;
+}
+
static void __hists__insert_output_entry(struct rb_root *entries,
struct hist_entry *he,
u64 min_callchain_hits)
@@ -539,7 +596,7 @@ static void __hists__insert_output_entry(struct rb_root
*entries,
parent = *p;
iter = rb_entry(parent, struct hist_entry, rb_node);
- if (he->stat.period > iter->stat.period)
+ if (hist_entry__sort_on_period(he, iter) > 0)
p = &(*p)->rb_left;
else
p = &(*p)->rb_right;
--
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 03/18] perf tools: Keep group information
From: Namhyung Kim
Add a few of group-related field in struct perf_{evlist,evsel} so that
the group information in a evlist can be known easily. It only counts
groups which have more than 1 members since leader-only groups are
treated as non-group events.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/evlist.c | 7 ++-
tools/perf/util/evlist.h | 1 +
tools/perf/util/evsel.h| 6 ++
tools/perf/util/parse-events.c | 1 +
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.y | 10 ++
6 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index d0e1e821fe85..a446b5b91530 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -111,6 +111,9 @@ void __perf_evlist__set_leader(struct list_head *list)
struct perf_evsel *evsel, *leader;
leader = list_entry(list->next, struct perf_evsel, node);
+ evsel = list_entry(list->prev, struct perf_evsel, node);
+
+ leader->nr_members = evsel->idx - leader->idx + 1;
list_for_each_entry(evsel, list, node) {
if (evsel != leader)
@@ -120,8 +123,10 @@ void __perf_evlist__set_leader(struct list_head *list)
void perf_evlist__set_leader(struct perf_evlist *evlist)
{
- if (evlist->nr_entries)
+ if (evlist->nr_entries) {
+ evlist->nr_groups = evlist->nr_entries > 1 ? 1 : 0;
__perf_evlist__set_leader(>entries);
+ }
}
int perf_evlist__add_default(struct perf_evlist *evlist)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 56003f779e60..fa76bf91c7e0 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -21,6 +21,7 @@ struct perf_evlist {
struct list_head entries;
struct hlist_head heads[PERF_EVLIST__HLIST_SIZE];
int nr_entries;
+ int nr_groups;
int nr_fds;
int nr_mmaps;
int mmap_len;
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 46c8004ca56b..887834ed0af1 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -73,6 +73,7 @@ struct perf_evsel {
boolneeds_swap;
/* parse modifier helper */
int exclude_GH;
+ int nr_members;
struct perf_evsel *leader;
char*group_name;
};
@@ -230,4 +231,9 @@ static inline bool perf_evsel__is_group_leader(const struct
perf_evsel *evsel)
{
return evsel->leader == evsel;
}
+
+static inline int perf_evsel__group_idx(struct perf_evsel *evsel)
+{
+ return evsel->idx - evsel->leader->idx;
+}
#endif /* __PERF_EVSEL_H */
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 020323af3364..25a556cf74ee 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -843,6 +843,7 @@ int parse_events(struct perf_evlist *evlist, const char
*str,
if (!ret) {
int entries = data.idx - evlist->nr_entries;
perf_evlist__splice_list_tail(evlist, , entries);
+ evlist->nr_groups += data.nr_groups;
return 0;
}
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index f6399373d67d..5a42c6d7cc9a 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -65,6 +65,7 @@ struct parse_events__term {
struct parse_events_data__events {
struct list_head list;
int idx;
+ int nr_groups;
};
struct parse_events_data__terms {
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 0f9914ae6bac..69cff676dcb1 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -122,6 +122,11 @@ group_def:
PE_NAME '{' events '}'
{
struct list_head *list = $3;
+ struct parse_events_data__events *data = _data;
+
+ /* Count groups only have more than 1 members */
+ if (!list_is_last(list->next, list))
+ data->nr_groups++;
parse_events__set_leader($1, list);
$$ = list;
@@ -130,6 +135,11 @@ PE_NAME '{' events '}'
'{' events '}'
{
struct list_head *list = $2;
+ struct parse_events_data__events *data = _data;
+
+ /* Count groups only have more than 1 members */
+ if (!list_is_last(list->next, list))
+ data->nr_groups++;
parse_events__set_leader(NULL, list);
$$ = list;
--
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] mfd: tps65910: fix wrong ack_base register
The interrupt status registers of TPS65910/1 should be cleared
when the associated interrupt event occurs.
This work is done in the regmap irq thread - using 'ack_base' register.
The ACK registers should be fixed as status register, not mask registers.
This patch fixes the infinite interrupt event problem by clearing
interrupt status registers.
Tested on the AM3517 Craneboard.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/mfd/tps65910.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index ca37833..fdb3027 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -211,7 +211,7 @@ static struct regmap_irq_chip tps65911_irq_chip = {
.irq_reg_stride = 2,
.status_base = TPS65910_INT_STS,
.mask_base = TPS65910_INT_MSK,
- .ack_base = TPS65910_INT_MSK,
+ .ack_base = TPS65910_INT_STS,
};
static struct regmap_irq_chip tps65910_irq_chip = {
@@ -222,7 +222,7 @@ static struct regmap_irq_chip tps65910_irq_chip = {
.irq_reg_stride = 2,
.status_base = TPS65910_INT_STS,
.mask_base = TPS65910_INT_MSK,
- .ack_base = TPS65910_INT_MSK,
+ .ack_base = TPS65910_INT_STS,
};
static int tps65910_irq_init(struct tps65910 *tps65910, int irq,
--
1.7.9.5
Best Regards,
Milo
--
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] rtc: Add NXP PCF8523 support
On Wed, Nov 28, 2012 at 03:31:58PM -0800, Andrew Morton wrote:
> On Wed, 28 Nov 2012 20:21:26 +0100
> Thierry Reding wrote:
>
> > + err = i2c_transfer(client->adapter, , 1);
> > + if (err < 0) {
> > + /*
> > +* If the time cannot be set, restart the RTC anyway. Note
> > +* that errors are ignored if the RTC cannot be started so
> > +* that we have a chance to propagate the original error.
> > +*/
> > + pcf8523_start_rtc(client);
> > + return err;
> > + }
> > +
> > + return pcf8523_start_rtc(client);
>
> hm, well, that is of course equivalent to
>
> err = i2c_transfer(client->adapter, , 1);
> pcf8523_start_rtc(client);
> return err;
At the risk of sounding pedantic, it isn't quite the same thing. There
is a possibility that i2c_transfer() succeeds but pcf8523_start_rtc()
still fails. So in fact we catch errors in i2c_transfer() and from
starting the RTC in case the time was properly set. The only error we
might loose if if the RTC fails to start after the time cannot be set
but in that case there's probably not a whole lot we can do.
> but I suppose the code as proposed is clear, extensible, and not our
> worst-ever sin ;)
Yes, this is one of the cases where the gain in clarity justifies the
extra verbosity. =)
Thierry
pgpPnuSxJENjJ.pgp
Description: PGP signature
[PATCH 1/3] omap: craneboard: support NAND device
This patch enables the NAND device on the AM3517 Craneboard.
MTD partitions are created as below.
0x-0x0008 : "X-Loader"
0x0008-0x0024 : "U-Boot"
0x0024-0x0028 : "U-Boot Env"
0x0028-0x0078 : "Kernel"
0x0078-0x1000 : "File System"
Signed-off-by: Milo(Woogyom) Kim
---
arch/arm/mach-omap2/board-am3517crane.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 51b96a1..37646e5 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -20,12 +20,17 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
#include "common.h"
+#include "common-board-devices.h"
+#include "board-flash.h"
#include "am35xx-emac.h"
#include "mux.h"
@@ -51,6 +56,36 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata =
{
.reset_gpio_port[2] = -EINVAL
};
+static struct mtd_partition crane_nand_partitions[] = {
+ {
+ .name = "X-Loader",
+ .offset = 0,
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ {
+ .name = "U-Boot",
+ .offset = MTDPART_OFS_APPEND,
+ .size = 14 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ {
+ .name = "U-Boot Env",
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "Kernel",
+ .offset = MTDPART_OFS_APPEND,
+ .size = 40 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "File System",
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
static void __init am3517_crane_init(void)
{
int ret;
@@ -58,6 +93,9 @@ static void __init am3517_crane_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
omap_sdrc_init(NULL, NULL);
+ board_nand_init(crane_nand_partitions,
+ ARRAY_SIZE(crane_nand_partitions), 0,
+ NAND_BUSWIDTH_16, NULL);
/* Configure GPIO for EHCI port */
if (omap_mux_init_gpio(GPIO_USB_NRESET, OMAP_PIN_OUTPUT)) {
--
1.7.9.5
Best Regards,
Milo
--
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/18] perf evsel: Convert to _is_group_leader method
From: Namhyung Kim
Convert perf_evsel__is_group_member to perf_evsel__is_group_leader.
This is because the most usecases are using negative form to check
whether the given evsel is a leader or not and it's IMHO somewhat
ambiguous - leader also *is* a member of the group.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-stat.c | 2 +-
tools/perf/tests/parse-events.c | 20 ++--
tools/perf/util/evlist.c| 4 ++--
tools/perf/util/evsel.c | 6 +++---
tools/perf/util/evsel.h | 4 ++--
5 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index c247faca7127..c12655af2b88 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -153,7 +153,7 @@ retry:
}
if (!perf_target__has_task() &&
- !perf_evsel__is_group_member(evsel)) {
+ perf_evsel__is_group_leader(evsel)) {
attr->disabled = 1;
attr->enable_on_exec = 1;
}
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index 42a0c8cd3cd5..17f1cd656314 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -521,7 +521,7 @@ static int test__group1(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude guest", !evsel->attr.exclude_guest);
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
- TEST_ASSERT_VAL("wrong leader", !perf_evsel__is_group_member(evsel));
+ TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
/* cycles:upp */
evsel = perf_evsel__next(evsel);
@@ -557,7 +557,7 @@ static int test__group2(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude guest", !evsel->attr.exclude_guest);
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
- TEST_ASSERT_VAL("wrong leader", !perf_evsel__is_group_member(evsel));
+ TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
/* cache-references + :u modifier */
evsel = perf_evsel__next(evsel);
@@ -583,7 +583,7 @@ static int test__group2(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude guest", !evsel->attr.exclude_guest);
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
- TEST_ASSERT_VAL("wrong leader", !perf_evsel__is_group_member(evsel));
+ TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
return 0;
}
@@ -606,7 +606,7 @@ static int test__group3(struct perf_evlist *evlist
__maybe_unused)
TEST_ASSERT_VAL("wrong exclude guest", evsel->attr.exclude_guest);
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
- TEST_ASSERT_VAL("wrong leader", !perf_evsel__is_group_member(evsel));
+ TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
TEST_ASSERT_VAL("wrong group name",
!strcmp(leader->group_name, "group1"));
@@ -636,7 +636,7 @@ static int test__group3(struct perf_evlist *evlist
__maybe_unused)
TEST_ASSERT_VAL("wrong exclude guest", !evsel->attr.exclude_guest);
TEST_ASSERT_VAL("wrong exclude host", evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
- TEST_ASSERT_VAL("wrong leader", !perf_evsel__is_group_member(evsel));
+ TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
TEST_ASSERT_VAL("wrong group name",
!strcmp(leader->group_name, "group2"));
@@ -663,7 +663,7 @@ static int test__group3(struct perf_evlist *evlist
__maybe_unused)
TEST_ASSERT_VAL("wrong exclude guest", !evsel->attr.exclude_guest);
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
- TEST_ASSERT_VAL("wrong leader", !perf_evsel__is_group_member(evsel));
+ TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
return 0;
}
@@ -687,7 +687,7 @@ static int test__group4(struct perf_evlist *evlist
__maybe_unused)
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", evsel->attr.precise_ip == 1);
TEST_ASSERT_VAL("wrong group name", !evsel->group_name);
- TEST_ASSERT_VAL("wrong leader", !perf_evsel__is_group_member(evsel));
+ TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
/* instructions:kp + p */
evsel = perf_evsel__next(evsel);
@@ -724,7 +724,7 @@ static int test__group5(struct perf_evlist *evlist
__maybe_unused)
[PATCH 17/18] perf report: Add --group option
From: Namhyung Kim
Add --group option to enable event grouping. When enabled, all the
group members information will be shown together with the leader.
Cc: Jiri Olsa
Cc: Stephane Eranian
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-report.txt | 3 +++
tools/perf/builtin-report.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index f4d91bebd59d..b3e8fcb9bbce 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -171,6 +171,9 @@ OPTIONS
--objdump=::
Path to objdump binary.
+--group::
+ Show event group information together.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-annotate[1]
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index e5b53f6554f4..c7079dff7411 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -668,6 +668,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
"Specify disassembler style (e.g. -M intel for intel
syntax)"),
OPT_BOOLEAN(0, "show-total-period", _conf.show_total_period,
"Show a column with the sum of periods"),
+ OPT_BOOLEAN(0, "group", _conf.event_group,
+ "Show event group information together"),
OPT_CALLBACK_NOOPT('b', "branch-stack", __branch_mode, "",
"use branch records for histogram filling",
parse_branch_mode),
OPT_STRING(0, "objdump", _path, "path",
--
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 18/18] perf report: Add report.group config option
From: Namhyung Kim
Add report.group config option for setting default value of event
group view. It affects the report output only if perf.data contains
event group info.
A user can write .perfconfig file like below to enable group view by
default:
$ cat ~/.perfconfig
[report]
group = true
And it can be disabled through command line:
$ perf report --no-group
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index c7079dff7411..f35e489156dc 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -8,6 +8,7 @@
#include "builtin.h"
#include "util/util.h"
+#include "util/cache.h"
#include "util/annotate.h"
#include "util/color.h"
@@ -54,6 +55,16 @@ struct perf_report {
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
};
+static int perf_report_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, "report.group")) {
+ symbol_conf.event_group = perf_config_bool(var, value);
+ return 0;
+ }
+
+ return perf_default_config(var, value, cb);
+}
+
static int perf_report__add_branch_hist_entry(struct perf_tool *tool,
struct addr_location *al,
struct perf_sample *sample,
@@ -677,6 +688,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_END()
};
+ perf_config(perf_report_config, NULL);
+
argc = parse_options(argc, argv, options, report_usage, 0);
if (report.use_stdio)
--
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 01/18] perf evsel: Set leader evsel's ->leader to itself
From: Namhyung Kim
Currently only non-leader members are set ->leader to the leader evsel
of the group and the leader has set NULL. Thus it requires special
casing for leader evsels. Set ->leader to itself will remove this.
Suggested-by: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/evlist.c | 1 -
tools/perf/util/evsel.c | 1 +
tools/perf/util/evsel.h | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 705293489e3c..90db2a14e4bb 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -111,7 +111,6 @@ void __perf_evlist__set_leader(struct list_head *list)
struct perf_evsel *evsel, *leader;
leader = list_entry(list->next, struct perf_evsel, node);
- leader->leader = NULL;
list_for_each_entry(evsel, list, node) {
if (evsel != leader)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 1fb636c550a1..ceabe05c6b12 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -55,6 +55,7 @@ void perf_evsel__init(struct perf_evsel *evsel,
{
evsel->idx = idx;
evsel->attr= *attr;
+ evsel->leader = evsel;
INIT_LIST_HEAD(>node);
hists__init(>hists);
evsel->sample_size = __perf_evsel__sample_size(attr->sample_type);
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index a4c1dd4e149f..d504668e7ae5 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -228,6 +228,6 @@ static inline struct perf_evsel *perf_evsel__next(struct
perf_evsel *evsel)
static inline bool perf_evsel__is_group_member(const struct perf_evsel *evsel)
{
- return evsel->leader != NULL;
+ return evsel->leader != evsel;
}
#endif /* __PERF_EVSEL_H */
--
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 16/18] perf report: Show group description when event group is enabled
From: Namhyung Kim
When using event group viewer, it's better to show the group
description rather than the leader information alone.
If a leader did not contain any member, it's a non-group event.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c| 15 +++
tools/perf/ui/browsers/hists.c | 25 +
tools/perf/ui/gtk/browser.c| 14 +++---
tools/perf/util/evsel.c| 25 +
tools/perf/util/evsel.h| 8
5 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 87af38bd75a8..e5b53f6554f4 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -299,6 +299,21 @@ static size_t hists__fprintf_nr_sample_events(struct hists
*self,
char unit;
unsigned long nr_samples = self->stats.nr_events[PERF_RECORD_SAMPLE];
u64 nr_events = self->stats.total_period;
+ struct perf_evsel *evsel = hists_to_evsel(self);
+ char buf[512];
+ size_t size = sizeof(buf);
+
+ if (symbol_conf.event_group && evsel->nr_members > 1) {
+ struct perf_evsel *pos;
+
+ perf_evsel__group_desc(evsel, buf, size);
+ evname = buf;
+
+ for_each_group_member(pos, evsel) {
+ nr_samples +=
pos->hists.stats.nr_events[PERF_RECORD_SAMPLE];
+ nr_events += pos->hists.stats.total_period;
+ }
+ }
nr_samples = convert_unit(nr_samples, );
ret = fprintf(fp, "# Samples: %lu%c", nr_samples, unit);
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 0d8b0143cd9b..3e31534fcc47 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1211,6 +1211,21 @@ static int hists__browser_title(struct hists *hists,
char *bf, size_t size,
const struct thread *thread = hists->thread_filter;
unsigned long nr_samples = hists->stats.nr_events[PERF_RECORD_SAMPLE];
u64 nr_events = hists->stats.total_period;
+ struct perf_evsel *evsel = hists_to_evsel(hists);
+ char buf[512];
+ size_t buflen = sizeof(buf);
+
+ if (symbol_conf.event_group && evsel->nr_members > 1) {
+ struct perf_evsel *pos;
+
+ perf_evsel__group_desc(evsel, buf, buflen);
+ ev_name = buf;
+
+ for_each_group_member(pos, evsel) {
+ nr_samples +=
pos->hists.stats.nr_events[PERF_RECORD_SAMPLE];
+ nr_events += pos->hists.stats.total_period;
+ }
+ }
nr_samples = convert_unit(nr_samples, );
printed = scnprintf(bf, size,
@@ -1607,6 +1622,16 @@ static void perf_evsel_menu__write(struct ui_browser
*browser,
ui_browser__set_color(browser, current_entry ? HE_COLORSET_SELECTED :
HE_COLORSET_NORMAL);
+ if (symbol_conf.event_group && evsel->nr_members > 1) {
+ struct perf_evsel *pos;
+
+ ev_name = perf_evsel__group_name(evsel);
+
+ for_each_group_member(pos, evsel) {
+ nr_events +=
pos->hists.stats.nr_events[PERF_RECORD_SAMPLE];
+ }
+ }
+
nr_events = convert_unit(nr_events, );
printed = scnprintf(bf, sizeof(bf), "%lu%c%s%s", nr_events,
unit, unit == ' ' ? "" : " ", ev_name);
diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 3b1642dc0e31..e7e11df829ed 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -324,10 +324,18 @@ int perf_evlist__gtk_browse_hists(struct perf_evlist
*evlist,
const char *evname = perf_evsel__name(pos);
GtkWidget *scrolled_window;
GtkWidget *tab_label;
+ char buf[512];
+ size_t size = sizeof(buf);
- if (symbol_conf.event_group &&
- !perf_evsel__is_group_leader(pos))
- continue;
+ if (symbol_conf.event_group) {
+ if (!perf_evsel__is_group_leader(pos))
+ continue;
+
+ if (pos->nr_members > 1) {
+ perf_evsel__group_desc(pos, buf, size);
+ evname = buf;
+ }
+ }
scrolled_window = gtk_scrolled_window_new(NULL, NULL);
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 73e6085a7294..a35e2547a7eb 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -405,6 +405,31 @@ const char *perf_evsel__name(struct perf_evsel *evsel)
return evsel->name ?: "unknown";
}
+const char *perf_evsel__group_name(struct perf_evsel
[PATCH 14/18] perf gtk/browser: Add support for event group view
From: Namhyung Kim
Show group members' overhead also when showing the leader's if event
group is enabled. Use macro for defining hpp functions which looks
almost identical.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/ui/gtk/browser.c | 87 -
1 file changed, 70 insertions(+), 17 deletions(-)
diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 253b6219a39e..04ed0cbbc090 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -45,30 +45,82 @@ static const char *perf_gtk__get_percent_color(double
percent)
return NULL;
}
-#define HPP__COLOR_FN(_name, _field)
\
-static int perf_gtk__hpp_color_ ## _name(struct perf_hpp *hpp,
\
-struct hist_entry *he)
\
+static int perf_gtk__percent_color_snprintf(char *buf, size_t size,
+ double percent)
+{
+ int ret = 0;
+ const char *markup;
+
+ markup = perf_gtk__get_percent_color(percent);
+ if (markup)
+ ret += scnprintf(buf, size, markup);
+
+ ret += scnprintf(buf + ret, size - ret, "%6.2f%%", percent);
+
+ if (markup)
+ ret += scnprintf(buf + ret, size - ret, "");
+
+ return ret;
+}
+
+
+#define __HPP_COLOR_PERCENT_FN(_type, _field)
\
+static int perf_gtk__hpp_color_##_type(struct perf_hpp *hpp,
\
+ struct hist_entry *he)
\
{
\
+ int ret;
\
+ double percent = 0.0;
\
struct hists *hists = he->hists;
\
- double percent = 100.0 * he->stat._field / hists->stats.total_period;
\
- const char *markup;
\
- int ret = 0;
\
\
- markup = perf_gtk__get_percent_color(percent);
\
- if (markup)
\
- ret += scnprintf(hpp->buf, hpp->size, "%s", markup);
\
- ret += scnprintf(hpp->buf + ret, hpp->size - ret, "%6.2f%%", percent);
\
- if (markup)
\
- ret += scnprintf(hpp->buf + ret, hpp->size - ret, "");
\
+ if (hists->stats.total_period)
\
+ percent = 100.0 * he->stat._field / hists->stats.total_period;
\
+
\
+ ret = perf_gtk__percent_color_snprintf(hpp->buf, hpp->size, percent);
\
+
\
+ if (symbol_conf.event_group) {
\
+ int i;
\
+ struct perf_evsel *evsel = hists_to_evsel(hists);
\
+ struct hist_entry *pair;
\
+ int nr_members = evsel->nr_members;
\
+ double *percents;
\
+
\
+ if (nr_members <= 1)
\
+ return ret;
\
+
\
+ percents = zalloc(sizeof(*percents) * nr_members);
\
+ if (percents == NULL) {
\
+ pr_warning("Not enough memory!\n");
\
+ return ret;
\
+ }
\
+
\
+ list_for_each_entry(pair, >pairs.head, pairs.node) {
\
+ u64 period = pair->stat._field;
\
+ u64 total = pair->hists->stats.total_period;
\
+
\
+ if (!total)
\
+
[PATCH 15/18] perf report: Bypass non-leader events when event group is enabled
From: Namhyung Kim
Since we have all necessary information in the leader events and
other members don't, bypass members. Member events will be shown
along with the leaders if event group is enabled.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c| 4
tools/perf/ui/browsers/hists.c | 41 +++--
tools/perf/ui/gtk/browser.c| 4
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 13a2cd20a1cd..87af38bd75a8 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -319,6 +319,10 @@ static int perf_evlist__tty_browse_hists(struct
perf_evlist *evlist,
struct hists *hists = >hists;
const char *evname = perf_evsel__name(pos);
+ if (symbol_conf.event_group &&
+ !perf_evsel__is_group_leader(pos))
+ continue;
+
hists__fprintf_nr_sample_events(hists, evname, stdout);
hists__fprintf(hists, true, 0, 0, stdout);
fprintf(stdout, "\n\n");
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 7ac47adc8e09..0d8b0143cd9b 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1717,8 +1717,19 @@ out:
return key;
}
+static bool filter_group_entries(struct ui_browser *self __maybe_unused,
+void *entry)
+{
+ struct perf_evsel *evsel = list_entry(entry, struct perf_evsel, node);
+
+ if (symbol_conf.event_group && !perf_evsel__is_group_leader(evsel))
+ return true;
+
+ return false;
+}
+
static int __perf_evlist__tui_browse_hists(struct perf_evlist *evlist,
- const char *help,
+ int nr_entries, const char *help,
struct hist_browser_timer *hbt,
struct perf_session_env *env)
{
@@ -1729,7 +1740,8 @@ static int __perf_evlist__tui_browse_hists(struct
perf_evlist *evlist,
.refresh= ui_browser__list_head_refresh,
.seek = ui_browser__list_head_seek,
.write = perf_evsel_menu__write,
- .nr_entries = evlist->nr_entries,
+ .filter = filter_group_entries,
+ .nr_entries = nr_entries,
.priv = evlist,
},
.env = env,
@@ -1745,20 +1757,37 @@ static int __perf_evlist__tui_browse_hists(struct
perf_evlist *evlist,
menu.b.width = line_len;
}
- return perf_evsel_menu__run(, evlist->nr_entries, help, hbt);
+ return perf_evsel_menu__run(, nr_entries, help, hbt);
}
int perf_evlist__tui_browse_hists(struct perf_evlist *evlist, const char *help,
struct hist_browser_timer *hbt,
struct perf_session_env *env)
{
- if (evlist->nr_entries == 1) {
+ int nr_entries = evlist->nr_entries;
+
+single_entry:
+ if (nr_entries == 1) {
struct perf_evsel *first = list_entry(evlist->entries.next,
struct perf_evsel, node);
const char *ev_name = perf_evsel__name(first);
- return perf_evsel__hists_browse(first, evlist->nr_entries, help,
+
+ return perf_evsel__hists_browse(first, nr_entries, help,
ev_name, false, hbt, env);
}
- return __perf_evlist__tui_browse_hists(evlist, help, hbt, env);
+ if (symbol_conf.event_group) {
+ struct perf_evsel *pos;
+
+ nr_entries = 0;
+ list_for_each_entry(pos, >entries, node)
+ if (perf_evsel__is_group_leader(pos))
+ nr_entries++;
+
+ if (nr_entries == 1)
+ goto single_entry;
+ }
+
+ return __perf_evlist__tui_browse_hists(evlist, nr_entries, help,
+ hbt, env);
}
diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 04ed0cbbc090..3b1642dc0e31 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -325,6 +325,10 @@ int perf_evlist__gtk_browse_hists(struct perf_evlist
*evlist,
GtkWidget *scrolled_window;
GtkWidget *tab_label;
+ if (symbol_conf.event_group &&
+ !perf_evsel__is_group_leader(pos))
+ continue;
+
scrolled_window = gtk_scrolled_window_new(NULL, NULL);
[PATCH 13/18] perf hist browser: Add support for event group view
From: Namhyung Kim
Show group members' overhead also when showing the leader's if event
group is enabled. Use macro for defining hpp functions which looks
almost identical.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 171 ++---
tools/perf/ui/hist.c | 5 +-
2 files changed, 146 insertions(+), 30 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index ccc4bd161420..7ac47adc8e09 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -567,23 +567,145 @@ static int hist_browser__show_callchain(struct
hist_browser *browser,
return row - first_row;
}
-#define HPP__COLOR_FN(_name, _field) \
-static int hist_browser__hpp_color_ ## _name(struct perf_hpp *hpp, \
-struct hist_entry *he) \
-{ \
- struct hists *hists = he->hists;\
- double percent = 100.0 * he->stat._field / hists->stats.total_period; \
- *(double *)hpp->ptr = percent; \
- return scnprintf(hpp->buf, hpp->size, "%6.2f%%", percent); \
+struct hpp_arg {
+ struct ui_browser *b;
+ char folded_sign;
+ bool current_entry;
+};
+
+static int hist_browser__hpp_color_overhead(struct perf_hpp *hpp,
+ struct hist_entry *he)
+{
+ int ret;
+ double percent = 0.0;
+ struct hists *hists = he->hists;
+ struct hpp_arg *arg = hpp->ptr;
+
+ if (hists->stats.total_period)
+ percent = 100.0 * he->stat.period / hists->stats.total_period;
+
+ ui_browser__set_percent_color(arg->b, percent, arg->current_entry);
+
+ if (symbol_conf.use_callchain) {
+ slsmg_printf("%c ", arg->folded_sign);
+ ret += 2;
+ }
+
+ ret = scnprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
+ slsmg_printf("%s", hpp->buf);
+
+ if (symbol_conf.event_group) {
+ int i;
+ struct perf_evsel *evsel = hists_to_evsel(hists);
+ struct hist_entry *pair;
+ int nr_members = evsel->nr_members;
+ double *percents;
+
+ if (nr_members <= 1)
+ goto out;
+
+ percents = zalloc(sizeof(*percents) * nr_members);
+ if (percents == NULL) {
+ pr_warning("Not enough memory!\n");
+ goto out;
+ }
+
+ list_for_each_entry(pair, >pairs.head, pairs.node) {
+ int idx;
+ u64 period = pair->stat.period;
+ u64 total = pair->hists->stats.total_period;
+
+ if (!total)
+ continue;
+
+ evsel = hists_to_evsel(pair->hists);
+ idx = perf_evsel__group_idx(evsel);
+ percents[idx] = 100.0 * period / total;
+ }
+
+ for (i = 1; i < nr_members; i++) {
+ ui_browser__set_percent_color(arg->b, percents[i],
+ arg->current_entry);
+ ret += scnprintf(hpp->buf, hpp->size,
+" %6.2f%%", percents[i]);
+ slsmg_printf("%s", hpp->buf);
+ }
+ free(percents);
+ }
+out:
+ if (!arg->current_entry || !arg->b->navkeypressed)
+ ui_browser__set_color(arg->b, HE_COLORSET_NORMAL);
+
+ return ret;
+}
+
+#define __HPP_COLOR_PERCENT_FN(_type, _field)
\
+static int hist_browser__hpp_color_##_type(struct perf_hpp *hpp,
\
+ struct hist_entry *he)
\
+{
\
+ int ret;
\
+ double percent = 0.0;
\
+ struct hists *hists = he->hists;
\
+ struct hpp_arg *arg = hpp->ptr;
\
+
\
+ if (hists->stats.total_period)
\
+ percent = 100.0 * he->stat._field / hists->stats.total_period;
\
+
\
+ ui_browser__set_percent_color(arg->b, percent, arg->current_entry);
\
+ ret = scnprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
\
+
[PATCH 12/18] perf ui/hist: Add support for event group view
From: Namhyung Kim
Show group members' overhead also when showing the leader's if event
group is enabled. Use macro for defining hpp functions which looks
almost identical.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/ui/hist.c | 370 +++--
tools/perf/ui/stdio/hist.c | 2 +
2 files changed, 191 insertions(+), 181 deletions(-)
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index aa84130024d5..b42bd15af3f5 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -3,152 +3,198 @@
#include "../util/hist.h"
#include "../util/util.h"
#include "../util/sort.h"
-
+#include "../util/evsel.h"
/* hist period print (hpp) functions */
-static int hpp__header_overhead(struct perf_hpp *hpp)
-{
- return scnprintf(hpp->buf, hpp->size, "Overhead");
-}
-
-static int hpp__width_overhead(struct perf_hpp *hpp __maybe_unused)
-{
- return 8;
-}
-
-static int hpp__color_overhead(struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period / hists->stats.total_period;
-
- return percent_color_snprintf(hpp->buf, hpp->size, " %6.2f%%", percent);
-}
-
-static int hpp__entry_overhead(struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period / hists->stats.total_period;
- const char *fmt = symbol_conf.field_sep ? "%.2f" : " %6.2f%%";
-
- return scnprintf(hpp->buf, hpp->size, fmt, percent);
-}
-
-static int hpp__header_overhead_sys(struct perf_hpp *hpp)
-{
- const char *fmt = symbol_conf.field_sep ? "%s" : "%7s";
-
- return scnprintf(hpp->buf, hpp->size, fmt, "sys");
-}
-
-static int hpp__width_overhead_sys(struct perf_hpp *hpp __maybe_unused)
-{
- return 7;
-}
-
-static int hpp__color_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_sys /
hists->stats.total_period;
-
- return percent_color_snprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
-}
-
-static int hpp__entry_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_sys /
hists->stats.total_period;
- const char *fmt = symbol_conf.field_sep ? "%.2f" : "%6.2f%%";
-
- return scnprintf(hpp->buf, hpp->size, fmt, percent);
-}
-
-static int hpp__header_overhead_us(struct perf_hpp *hpp)
-{
- const char *fmt = symbol_conf.field_sep ? "%s" : "%7s";
-
- return scnprintf(hpp->buf, hpp->size, fmt, "user");
-}
-
-static int hpp__width_overhead_us(struct perf_hpp *hpp __maybe_unused)
-{
- return 7;
-}
-
-static int hpp__color_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_us / hists->stats.total_period;
-
- return percent_color_snprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
-}
-
-static int hpp__entry_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_us / hists->stats.total_period;
- const char *fmt = symbol_conf.field_sep ? "%.2f" : "%6.2f%%";
-
- return scnprintf(hpp->buf, hpp->size, fmt, percent);
-}
-
-static int hpp__header_overhead_guest_sys(struct perf_hpp *hpp)
-{
- return scnprintf(hpp->buf, hpp->size, "guest sys");
-}
-
-static int hpp__width_overhead_guest_sys(struct perf_hpp *hpp __maybe_unused)
-{
- return 9;
-}
-
-static int hpp__color_overhead_guest_sys(struct perf_hpp *hpp,
-struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_guest_sys /
hists->stats.total_period;
-
- return percent_color_snprintf(hpp->buf, hpp->size, " %6.2f%% ",
percent);
-}
-
-static int hpp__entry_overhead_guest_sys(struct perf_hpp *hpp,
-struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_guest_sys /
hists->stats.total_period;
- const char *fmt = symbol_conf.field_sep ? "%.2f" : " %6.2f%% ";
-
- return scnprintf(hpp->buf, hpp->size, fmt, percent);
-}
-
-static int hpp__header_overhead_guest_us(struct perf_hpp *hpp)
-{
- return scnprintf(hpp->buf, hpp->size, "guest usr");
-}
-
-static int hpp__width_overhead_guest_us(struct perf_hpp *hpp __maybe_unused)
-{
- return 9;
-}
-
-static int hpp__color_overhead_guest_us(struct perf_hpp *hpp,
- struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_guest_us /
hists->stats.total_period;
-
- return percent_color_snprintf(hpp->buf, hpp->size, " %6.2f%%
[PATCH 00/18] perf report: Add support for event group view (v6)
Hi all,
This is my 6th iteration of event group view patchset.
For basic idea and usage example, please see my original post [1].
The largest change in this version is using 'pairs' list of hist_entry
instead of allocating group_stats for all group members. But I needed
to allocate temporary arrays for internal purpose anyway. If you have
a better solution please let me know.
Jiri, sorry for the delay, I had to hunt down some nasty bugs in my
patches. And I saw you submitted the multiplu diff series which will
conflict my changes. I'll have a look at it soon, and I'd be glad if
you take a look at my changes too. :)
You can get this series via my tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
perf/group-v6
Any comments are welcome, thanks,
Namhyung
v5 -> v6:
* set ->leader alse for leader evsel (Arnaldo)
* use hists__{match,link} (Arnaldo)
v4 -> v5:
* rebase onto acme/perf/core
v3 -> v4:
* patch 1-9 in previous post are merged.
* add Jiri's Acked-by
* add report.group config option
v2 -> v3:
* drop patch 1 since it's merged into acme/perf/core
* cherry-pick Jiri's hpp changes
* add missing bswap_32 on reading nr_groups (Jiri)
* remove perf_evlist__recalc_nr_groups() in favor of list_is_last (Jiri)
v1 -> v2:
* save group relation to header (Jiri)
[1] https://lkml.org/lkml/2012/7/24/81
Namhyung Kim (18):
perf evsel: Set leader evsel's ->leader to itself
perf evsel: Convert to _is_group_leader method
perf tools: Keep group information
perf header: Add HEADER_GROUP_DESC feature
perf tools: Fix typo on hist__entry_add_pair
perf hists: Link hist entry pairs to leader
perf hists: Exchange order of comparing items when collapsing hists
perf hists: Add hists__{match,link}_collapsed
perf symbol: Introduce symbol_conf.event_group
perf report: Make another loop for linking group hists
perf hists: Resort hist entries using group members for output
perf ui/hist: Add support for event group view
perf hist browser: Add support for event group view
perf gtk/browser: Add support for event group view
perf report: Bypass non-leader events when event group is enabled
perf report: Show group description when event group is enabled
perf report: Add --group option
perf report: Add report.group config option
tools/perf/Documentation/perf-report.txt | 3 +
tools/perf/builtin-record.c | 3 +
tools/perf/builtin-report.c | 47 +++-
tools/perf/builtin-stat.c| 2 +-
tools/perf/tests/parse-events.c | 20 +-
tools/perf/ui/browsers/hists.c | 237 ---
tools/perf/ui/gtk/browser.c | 99 ++--
tools/perf/ui/hist.c | 375 ---
tools/perf/ui/stdio/hist.c | 2 +
tools/perf/util/evlist.c | 12 +-
tools/perf/util/evlist.h | 1 +
tools/perf/util/evsel.c | 32 ++-
tools/perf/util/evsel.h | 20 +-
tools/perf/util/header.c | 153 +
tools/perf/util/header.h | 2 +
tools/perf/util/hist.c | 182 +--
tools/perf/util/hist.h | 2 +
tools/perf/util/parse-events.c | 1 +
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.y | 10 +
tools/perf/util/sort.h | 2 +-
tools/perf/util/symbol.c | 4 +
tools/perf/util/symbol.h | 3 +-
23 files changed, 934 insertions(+), 279 deletions(-)
--
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 00/18] perf report: Add support for event group view (v6)
Hi all,
This is my 6th iteration of event group view patchset.
For basic idea and usage example, please see my original post [1].
The largest change in this version is using 'pairs' list of hist_entry
instead of allocating group_stats for all group members. But I needed
to allocate temporary arrays for internal purpose anyway. If you have
a better solution please let me know.
Jiri, sorry for the delay. I had to hunt down some nasty bugs in my
patches. And I saw you submitted the multiplu diff series which will
conflict my changes. I'll have a look at it soon, and I'd be glad if
you take a look at my changes too. :)
You can get this series via my tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
perf/group-v6
Any comments are welcome, thanks,
Namhyung
v5 -> v6:
* set ->leader alse for leader evsel (Arnaldo)
* use hists__{match,link} (Arnaldo)
v4 -> v5:
* rebase onto acme/perf/core
v3 -> v4:
* patch 1-9 in previous post are merged.
* add Jiri's Acked-by
* add report.group config option
v2 -> v3:
* drop patch 1 since it's merged into acme/perf/core
* cherry-pick Jiri's hpp changes
* add missing bswap_32 on reading nr_groups (Jiri)
* remove perf_evlist__recalc_nr_groups() in favor of list_is_last (Jiri)
v1 -> v2:
* save group relation to header (Jiri)
[1] https://lkml.org/lkml/2012/7/24/81
Namhyung Kim (18):
perf evsel: Set leader evsel's ->leader to itself
perf evsel: Convert to _is_group_leader method
perf tools: Keep group information
perf header: Add HEADER_GROUP_DESC feature
perf tools: Fix typo on hist__entry_add_pair
perf hists: Link hist entry pairs to leader
perf hists: Exchange order of comparing items when collapsing hists
perf hists: Add hists__{match,link}_collapsed
perf symbol: Introduce symbol_conf.event_group
perf report: Make another loop for linking group hists
perf hists: Resort hist entries using group members for output
perf ui/hist: Add support for event group view
perf hist browser: Add support for event group view
perf gtk/browser: Add support for event group view
perf report: Bypass non-leader events when event group is enabled
perf report: Show group description when event group is enabled
perf report: Add --group option
perf report: Add report.group config option
tools/perf/Documentation/perf-report.txt | 3 +
tools/perf/builtin-record.c | 3 +
tools/perf/builtin-report.c | 47 +++-
tools/perf/builtin-stat.c| 2 +-
tools/perf/tests/parse-events.c | 20 +-
tools/perf/ui/browsers/hists.c | 237 ---
tools/perf/ui/gtk/browser.c | 99 ++--
tools/perf/ui/hist.c | 375 ---
tools/perf/ui/stdio/hist.c | 2 +
tools/perf/util/evlist.c | 12 +-
tools/perf/util/evlist.h | 1 +
tools/perf/util/evsel.c | 32 ++-
tools/perf/util/evsel.h | 20 +-
tools/perf/util/header.c | 153 +
tools/perf/util/header.h | 2 +
tools/perf/util/hist.c | 182 +--
tools/perf/util/hist.h | 2 +
tools/perf/util/parse-events.c | 1 +
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.y | 10 +
tools/perf/util/sort.h | 2 +-
tools/perf/util/symbol.c | 4 +
tools/perf/util/symbol.h | 3 +-
23 files changed, 934 insertions(+), 279 deletions(-)
--
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/
Re: [PATCH] Introduce a method to catch mmap_region (was: Recent kernel "mount" slow)
On Wed, Nov 28, 2012 at 10:30 PM, Al Viro wrote:
>
> Note that sync_blockdev() a few lines prior to that is good only if we
> have no other processes doing write(2) (or dirtying the mmapped pages,
> for that matter). The window isn't too wide, but...
So with Mikulas' patches, the write actually would block (at write
level) due to the locking. The mmap'ed patches may be around and
flushed, but the logic to not allow currently *active* mmaps (with the
rather nasty random -EBUSY return value) should mean that there is no
race.
Or rather, there's a race, but it results in that EBUSY thing.
With my simplfied locking, the sync_blockdev() is right before (not a
few lines prior) to the kill_bdev(), and in a perfect world they'd
actually be one single operation ("write back and invalidate pages
with the wrong block-size"). But they aren't.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] fs:sysfs pass NULL as second parameter for set_anon_super
set_anon_super does not use the second parameter in its implementation.
So there is no need to pass on the second parameter.
Signed-off-by: Abhijit Pawar
---
fs/sysfs/mount.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
index db940a9..3e3f7ea 100644
--- a/fs/sysfs/mount.c
+++ b/fs/sysfs/mount.c
@@ -89,7 +89,7 @@ static int sysfs_test_super(struct super_block *sb, void
*data)
static int sysfs_set_super(struct super_block *sb, void *data)
{
int error;
- error = set_anon_super(sb, data);
+ error = set_anon_super(sb, NULL);
if (!error)
sb->s_fs_info = data;
return error;
--
1.7.7.6
--
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] Introduce a method to catch mmap_region (was: Recent kernel "mount" slow)
On Wed, Nov 28, 2012 at 10:25 PM, Al Viro wrote: > > Umm... set_blocksize() is calling kill_bdev(), which does > truncate_inode_pages(mapping, 0). What's going to happen to data in > the dirty pages? IO in progress is not the only thing to worry about... Hmm. Yes. I think it works by virtue of "if you change the blocksize while there is active IO, you're insane and you deserve whatever you get". It shouldn't even be fundamentally hard to make it work, although I suspect it would be more code than it would be worth. The sane model would be to not use truncate_inode_pages(), but instead just walk the pages and get rid of the buffer heads with the wrong size. Preferably *combining* that with the sync_blockdev(). We have no real reason to even invalidate the page cache, it's just the buffers we want to get rid of. But I suspect it's true that none of that is really *worth* it, considering that nobody likely wants to do any concurrent IO. We don't want to crash, or corrupt the data structures, but I suspect "you get what you deserve" might actually be the right model ;) So the current "sync_blockdev()+kill_bdev()" takes care of the *sane* case (we flush any data that happened *before* the block size change), and any concurrent writes with block-size changes are "good luck with that". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] fs:nfs pass NULL as second parameter for set_anon_super
set_anon_super does not use the second parameter in its implementation. So there is no need to pass on the second parameter. Signed-off-by: Abhijit Pawar --- fs/nfs/super.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/nfs/super.c b/fs/nfs/super.c index e12cea4..c8bdd86 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -2310,7 +2310,7 @@ static int nfs_set_super(struct super_block *s, void *data) s->s_flags = sb_mntdata->mntflags; s->s_fs_info = server; s->s_d_op = server->nfs_client->rpc_ops->dentry_ops; - ret = set_anon_super(s, server); + ret = set_anon_super(s, NULL); if (ret == 0) server->s_dev = s->s_dev; return ret; -- 1.7.7.6 -- 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] Introduce a method to catch mmap_region (was: Recent kernel "mount" slow)
On Thu, Nov 29, 2012 at 06:25:19AM +, Al Viro wrote: > Umm... set_blocksize() is calling kill_bdev(), which does > truncate_inode_pages(mapping, 0). What's going to happen to data in > the dirty pages? IO in progress is not the only thing to worry about... Note that sync_blockdev() a few lines prior to that is good only if we have no other processes doing write(2) (or dirtying the mmapped pages, for that matter). The window isn't too wide, but... -- 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/6] fs:btrfs pass NULL as second parameter for set_anon_super
set_anon_super does not use the second parameter in its implementation.
So there is no need to pass on the second parameter.
Signed-off-by: Abhijit Pawar
---
fs/btrfs/super.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 915ac14..c9994a3 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -954,7 +954,7 @@ static int btrfs_test_super(struct super_block *s, void
*data)
static int btrfs_set_super(struct super_block *s, void *data)
{
- int err = set_anon_super(s, data);
+ int err = set_anon_super(s, NULL);
if (!err)
s->s_fs_info = data;
return err;
--
1.7.7.6
--
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] MAINTAINERS: TTY - Add linux-serial mailing list
于 2012年11月29日 14:14, Joe Perches 写道: > Signed-off-by: Joe Perches > --- > MAINTAINERS |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index afc0b27..255dafb 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7658,6 +7658,7 @@ K: ^Subject:.*(?i)trivial > TTY LAYER > M: Greg Kroah-Hartman > M: Jiri Slaby > +L: linux-ser...@vger.kernel.org > S: Supported > T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git > F: drivers/tty/ > > > > thank you very much. -- Chen Gang Asianux Corporation -- 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: build warning after merge of the final tree (sound-asoc tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
sound/soc/codecs/wm_adsp.c: In function 'wm_adsp2_event':
sound/soc/codecs/wm_adsp.c:556:4: warning: suggest parentheses around
comparison in operand of '&' [-Wparentheses]
Introduced by commit 973838a030d2 ("ASoC: wm_adsp: Enable DVFS for ADSP2").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpHqZEeQOLDF.pgp
Description: PGP signature
Re: [PATCH] Introduce a method to catch mmap_region (was: Recent kernel "mount" slow)
On Wed, Nov 28, 2012 at 10:16:21PM -0800, Linus Torvalds wrote: > On Wed, Nov 28, 2012 at 6:58 PM, Linus Torvalds > wrote: > > > > But the fact that the code wants to do things like > > > > block = (sector_t)page->index << (PAGE_CACHE_SHIFT - bbits); > > > > seriously seems to be the main thing that keeps us using > > 'inode->i_blkbits'. Calculating bbits from bh->b_size is just costly > > enough to hurt (not everywhere, but on some machines). > > > > Very annoying. > > Hmm. Here's a patch that does that anyway. I'm not 100% happy with the > whole ilog2 thing, but at the same time, in other cases it actually > seems to improve code generation (ie gets rid of the whole unnecessary > two dereferences through page->mapping->host just to get the block > size, when we have it in the buffer-head that we have to touch > *anyway*). > > Comments? Again, untested. > > And I notice that Al Viro hasn't been cc'd, which is sad, since he's > been involved in much of fs/block_dev.c. > > Al - this is an independent patch to fs/buffer.c to make > fs/block_dev.c able to change the block size of a block device while > there is IO in progress that may still use the old block size. The > discussion has been on fsdevel and lkml, but you may have missed it... Umm... set_blocksize() is calling kill_bdev(), which does truncate_inode_pages(mapping, 0). What's going to happen to data in the dirty pages? IO in progress is not the only thing to worry about... -- 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] Add mempressure cgroup
On Thu, Nov 29, 2012 at 08:14:13AM +0200, Kirill A. Shutemov wrote:
> On Wed, Nov 28, 2012 at 02:29:08AM -0800, Anton Vorontsov wrote:
> > +static int mpc_pre_destroy(struct cgroup *cg)
> > +{
> > + struct mpc_state *mpc = cg2mpc(cg);
> > + int ret = 0;
> > +
> > + mutex_lock(>lock);
> > +
> > + if (mpc->eventfd)
> > + ret = -EBUSY;
>
> cgroup_rmdir() will unregister all events for you. No need to handle it
> here.
Okie, thanks!
[...]
> > +static int mpc_register_level_event(struct cgroup *cg, struct cftype *cft,
> > + struct eventfd_ctx *eventfd,
> > + const char *args)
> > +{
> > + struct mpc_state *mpc = cg2mpc(cg);
> > + int i;
> > + int ret;
> > +
> > + mutex_lock(>lock);
> > +
> > + /*
> > +* It's easy to implement multiple thresholds, but so far we don't
> > +* need it.
> > +*/
> > + if (mpc->eventfd) {
> > + ret = -EBUSY;
> > + goto out_unlock;
> > + }
>
> One user which listen for one threashold per cgroup?
> I think it's wrong. It's essensial for API to serve multiple users.
Yea, if we'll consider merging this, I'll definitely fix this. Just didn't
want to bring the complexity into the code.
Thanks,
Anton.
--
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] ARM: tegra: remove unused functions in mach/clk.h
On Tuesday 27 November 2012 12:29 PM, Sivaram Nair wrote:
This is a cleaning up patch that removes couple of functions in
mach/clk.h that are no longer used and does not have any body.
Signed-off-by: Sivaram Nair
---
arch/arm/mach-tegra/include/mach/clk.h |5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/mach-tegra/include/mach/clk.h
b/arch/arm/mach-tegra/include/mach/clk.h
index 95f3a54..64d2657 100644
--- a/arch/arm/mach-tegra/include/mach/clk.h
+++ b/arch/arm/mach-tegra/include/mach/clk.h
@@ -34,11 +34,6 @@ enum tegra_clk_ex_param {
void tegra_periph_reset_deassert(struct clk *c);
void tegra_periph_reset_assert(struct clk *c);
-#ifndef CONFIG_COMMON_CLK
-unsigned long clk_get_rate_all_locked(struct clk *c);
-#endif
-
-void tegra2_sdmmc_tap_delay(struct clk *c, int delay);
int tegra_clk_cfg_ex(struct clk *c, enum tegra_clk_ex_param p, u32 setting);
#endif
Reviewed-by: Prashant Gaikwad
--
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: build warnings after merge of the akpm tree
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
In file included from drivers/block/drbd/drbd_bitmap.c:32:0:
drivers/block/drbd/drbd_int.h:2339:0: warning: "__wait_event_lock_irq"
redefined [enabled by default]
include/linux/wait.h:554:0: note: this is the location of the previous
definition
drivers/block/drbd/drbd_int.h:2358:0: warning: "wait_event_lock_irq" redefined
[enabled by default]
include/linux/wait.h:621:0: note: this is the location of the previous
definition
In file included from drivers/block/drbd/drbd_receiver.c:46:0:
drivers/block/drbd/drbd_int.h:2339:0: warning: "__wait_event_lock_irq"
redefined [enabled by default]
include/linux/wait.h:554:0: note: this is the location of the previous
definition
drivers/block/drbd/drbd_int.h:2358:0: warning: "wait_event_lock_irq" redefined
[enabled by default]
include/linux/wait.h:621:0: note: this is the location of the previous
definition
In file included from drivers/block/drbd/drbd_proc.c:34:0:
drivers/block/drbd/drbd_int.h:2339:0: warning: "__wait_event_lock_irq"
redefined [enabled by default]
include/linux/wait.h:554:0: note: this is the location of the previous
definition
drivers/block/drbd/drbd_int.h:2358:0: warning: "wait_event_lock_irq" redefined
[enabled by default]
include/linux/wait.h:621:0: note: this is the location of the previous
definition
In file included from drivers/block/drbd/drbd_worker.c:38:0:
drivers/block/drbd/drbd_int.h:2339:0: warning: "__wait_event_lock_irq"
redefined [enabled by default]
include/linux/wait.h:554:0: note: this is the location of the previous
definition
drivers/block/drbd/drbd_int.h:2358:0: warning: "wait_event_lock_irq" redefined
[enabled by default]
include/linux/wait.h:621:0: note: this is the location of the previous
definition
In file included from drivers/block/drbd/drbd_actlog.c:31:0:
drivers/block/drbd/drbd_int.h:2339:0: warning: "__wait_event_lock_irq"
redefined [enabled by default]
include/linux/wait.h:554:0: note: this is the location of the previous
definition
drivers/block/drbd/drbd_int.h:2358:0: warning: "wait_event_lock_irq" redefined
[enabled by default]
include/linux/wait.h:621:0: note: this is the location of the previous
definition
In file included from drivers/block/drbd/drbd_req.c:30:0:
drivers/block/drbd/drbd_int.h:2339:0: warning: "__wait_event_lock_irq"
redefined [enabled by default]
include/linux/wait.h:554:0: note: this is the location of the previous
definition
drivers/block/drbd/drbd_int.h:2358:0: warning: "wait_event_lock_irq" redefined
[enabled by default]
include/linux/wait.h:621:0: note: this is the location of the previous
definition
Introduced by the interaction of commit c1fd29a11f43 ("drbd: Fix a race
condition that can lead to a BUG()") from the block tree and commit
"wait: add wait_event_lock_irq() interface" from the akpm tree.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpcYamSl6CZO.pgp
Description: PGP signature
Re: [PATCH] Introduce a method to catch mmap_region (was: Recent kernel "mount" slow)
On Wed, Nov 28, 2012 at 6:58 PM, Linus Torvalds wrote: > > But the fact that the code wants to do things like > > block = (sector_t)page->index << (PAGE_CACHE_SHIFT - bbits); > > seriously seems to be the main thing that keeps us using > 'inode->i_blkbits'. Calculating bbits from bh->b_size is just costly > enough to hurt (not everywhere, but on some machines). > > Very annoying. Hmm. Here's a patch that does that anyway. I'm not 100% happy with the whole ilog2 thing, but at the same time, in other cases it actually seems to improve code generation (ie gets rid of the whole unnecessary two dereferences through page->mapping->host just to get the block size, when we have it in the buffer-head that we have to touch *anyway*). Comments? Again, untested. And I notice that Al Viro hasn't been cc'd, which is sad, since he's been involved in much of fs/block_dev.c. Al - this is an independent patch to fs/buffer.c to make fs/block_dev.c able to change the block size of a block device while there is IO in progress that may still use the old block size. The discussion has been on fsdevel and lkml, but you may have missed it... Linus patch.diff Description: Binary data
Re: [patch] [SCSI] csiostor: remove unneeded memset()
On 11/27/2012 11:03 PM, Dan Carpenter wrote: > No need to memset() this when we just copy over it on the next line. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/scsi/csiostor/csio_lnode.c > b/drivers/scsi/csiostor/csio_lnode.c > index 551959e..8b54976 100644 > --- a/drivers/scsi/csiostor/csio_lnode.c > +++ b/drivers/scsi/csiostor/csio_lnode.c > @@ -245,7 +245,6 @@ csio_append_attrib(uint8_t **ptr, uint16_t type, uint8_t > *val, uint16_t len) > len += 4; /* includes attribute type and length */ > len = (len + 3) & ~3; /* should be multiple of 4 bytes */ > ae->len = htons(len); > - memset(ae->value, 0, len - 4); > memcpy(ae->value, val, len); > *ptr += len; > } > Acked-by: Naresh Kumar Inna Thanks, Naresh. -- 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: build warnings after merge of the slave-dma tree
Hi Vinod,
After merging the slave-dma tree, today's linux-next build (x86_64
allmodconfig) produced these warning:
drivers/dma/dmaengine.c: At top level:
include/linux/of_dma.h:47:12: warning: 'of_dma_controller_register' defined but
not used [-Wunused-function]
include/linux/of_dma.h:55:12: warning: 'of_dma_controller_free' defined but not
used [-Wunused-function]
include/linux/of_dma.h:65:25: warning: 'of_dma_simple_xlate' defined but not
used [-Wunused-function]
These dummy functions need an inline keyword.
Introduced by commit 7a74a3a0e055 ("of: dma- fix build break for
!CONFIG_OF").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpdXBBk7Kbmn.pgp
Description: PGP signature
[PATCH] MAINTAINERS: TTY - Add linux-serial mailing list
Signed-off-by: Joe Perches --- MAINTAINERS |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index afc0b27..255dafb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7658,6 +7658,7 @@ K:^Subject:.*(?i)trivial TTY LAYER M: Greg Kroah-Hartman M: Jiri Slaby +L: linux-ser...@vger.kernel.org S: Supported T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git F: drivers/tty/ -- 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] Add mempressure cgroup
On Wed, Nov 28, 2012 at 02:29:08AM -0800, Anton Vorontsov wrote:
> +static int mpc_pre_destroy(struct cgroup *cg)
> +{
> + struct mpc_state *mpc = cg2mpc(cg);
> + int ret = 0;
> +
> + mutex_lock(>lock);
> +
> + if (mpc->eventfd)
> + ret = -EBUSY;
cgroup_rmdir() will unregister all events for you. No need to handle it
here.
> +
> + mutex_unlock(>lock);
> +
> + return ret;
> +}
> +static int mpc_register_level_event(struct cgroup *cg, struct cftype *cft,
> + struct eventfd_ctx *eventfd,
> + const char *args)
> +{
> + struct mpc_state *mpc = cg2mpc(cg);
> + int i;
> + int ret;
> +
> + mutex_lock(>lock);
> +
> + /*
> + * It's easy to implement multiple thresholds, but so far we don't
> + * need it.
> + */
> + if (mpc->eventfd) {
> + ret = -EBUSY;
> + goto out_unlock;
> + }
One user which listen for one threashold per cgroup?
I think it's wrong. It's essensial for API to serve multiple users.
> +
> + ret = -EINVAL;
> + for (i = 0; i < VMPRESSURE_NUM_LEVELS; i++) {
> + if (strcmp(vmpressure_str_levels[i], args))
> + continue;
> + mpc->eventfd = eventfd;
> + mpc->thres = i;
> + ret = 0;
> + break;
> + }
> +out_unlock:
> + mutex_unlock(>lock);
> +
> + return ret;
> +}
--
Kirill A. Shutemov
--
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] ARM: tegra: moving stuff away from mach/clk.h
On Tuesday 27 November 2012 12:29 PM, Sivaram Nair wrote:
This patch moves some stuff away from mach/clk.h to other mach-tegra
files. This is part of the efforts to get rid of mach/clk.h which in
turn will help to enable single zImage.
Signed-off-by: Sivaram Nair
---
arch/arm/mach-tegra/clock.c|1 +
arch/arm/mach-tegra/clock.h| 12 ++--
arch/arm/mach-tegra/include/mach/clk.h | 11 ---
3 files changed, 11 insertions(+), 13 deletions(-)
This patch will not add any real value since I have removed clk_cfg_ex
functionality in clock code rework.
It's just that I will have to rebase my changes on this.
Reviewed-by: Prashant Gaikwad
diff --git a/arch/arm/mach-tegra/clock.c b/arch/arm/mach-tegra/clock.c
index 867bf8b..4440626 100644
--- a/arch/arm/mach-tegra/clock.c
+++ b/arch/arm/mach-tegra/clock.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "board.h"
#include "clock.h"
diff --git a/arch/arm/mach-tegra/clock.h b/arch/arm/mach-tegra/clock.h
index 2aa37f5..e6685d4 100644
--- a/arch/arm/mach-tegra/clock.h
+++ b/arch/arm/mach-tegra/clock.h
@@ -25,8 +25,6 @@
#include
#include
-#include
-
#define DIV_BUS (1 << 0)
#define DIV_U71 (1 << 1)
#define DIV_U71_FIXED (1 << 2)
@@ -70,6 +68,15 @@ struct clk_pll_freq_table {
u8 cpcon;
};
+enum tegra_clk_ex_param {
+ TEGRA_CLK_VI_INP_SEL,
+ TEGRA_CLK_DTV_INVERT,
+ TEGRA_CLK_NAND_PAD_DIV2_ENB,
+ TEGRA_CLK_PLLD_CSI_OUT_ENB,
+ TEGRA_CLK_PLLD_DSI_OUT_ENB,
+ TEGRA_CLK_PLLD_MIPI_MUX_SEL,
+};
+
enum clk_state {
UNINITIALIZED = 0,
ON,
@@ -149,5 +156,6 @@ void tegra2_init_clocks(void);
void tegra30_init_clocks(void);
struct clk *tegra_get_clock_by_name(const char *name);
void tegra_clk_init_from_table(struct tegra_clk_init_table *table);
+int tegra_clk_cfg_ex(struct clk *c, enum tegra_clk_ex_param p, u32 setting);
#endif
diff --git a/arch/arm/mach-tegra/include/mach/clk.h
b/arch/arm/mach-tegra/include/mach/clk.h
index 64d2657..6338652 100644
--- a/arch/arm/mach-tegra/include/mach/clk.h
+++ b/arch/arm/mach-tegra/include/mach/clk.h
@@ -22,18 +22,7 @@
struct clk;
-enum tegra_clk_ex_param {
- TEGRA_CLK_VI_INP_SEL,
- TEGRA_CLK_DTV_INVERT,
- TEGRA_CLK_NAND_PAD_DIV2_ENB,
- TEGRA_CLK_PLLD_CSI_OUT_ENB,
- TEGRA_CLK_PLLD_DSI_OUT_ENB,
- TEGRA_CLK_PLLD_MIPI_MUX_SEL,
-};
-
void tegra_periph_reset_deassert(struct clk *c);
void tegra_periph_reset_assert(struct clk *c);
-int tegra_clk_cfg_ex(struct clk *c, enum tegra_clk_ex_param p, u32 setting);
-
#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/
Re: [PATCH] export of_reconfig_notifier_[register,unregister]
On Wed, 2012-11-28 at 13:42 -0600, Nathan Fontenot wrote:
> The of reconfiguration notification chains should be exported for use
> by modules.
>
> Signed-off-by:Nathan Fontenot
Grant, I'm applying that into the powerpc tree (with a slightly modified
subject line). You don't need to add it to your tree at this stage I
suspect.
Cheers,
Ben.
> ---
> Index: linux-next/drivers/of/base.c
> ===
> --- linux-next.orig/drivers/of/base.c 2012-11-28 09:18:02.0 -0600
> +++ linux-next/drivers/of/base.c 2012-11-28 11:05:00.0 -0600
> @@ -1282,11 +1282,13 @@
> {
> return blocking_notifier_chain_register(_reconfig_chain, nb);
> }
> +EXPORT_SYMBOL_GPL(of_reconfig_notifier_register);
>
> int of_reconfig_notifier_unregister(struct notifier_block *nb)
> {
> return blocking_notifier_chain_unregister(_reconfig_chain, nb);
> }
> +EXPORT_SYMBOL_GPL(of_reconfig_notifier_unregister);
>
> int of_reconfig_notify(unsigned long action, void *p)
> {
>
> --
> 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/
[PATCH 3/6] fs: 9p pass NULL as second parameter for set_anon_super
set_anon_super does not use the second parameter in its implementation.
So there is no need to pass on the second parameter.
Signed-off-by: Abhijit Pawar
---
fs/9p/vfs_super.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/9p/vfs_super.c b/fs/9p/vfs_super.c
index 137d503..132db90 100644
--- a/fs/9p/vfs_super.c
+++ b/fs/9p/vfs_super.c
@@ -61,7 +61,7 @@ static const struct super_operations v9fs_super_ops,
v9fs_super_ops_dotl;
static int v9fs_set_super(struct super_block *s, void *data)
{
s->s_fs_info = data;
- return set_anon_super(s, data);
+ return set_anon_super(s, NULL);
}
/**
--
1.7.7.6
--
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: [Suggestion] drivers/tty: drivers/char/: for MAX_ASYNC_BUFFER_SIZE
于 2012年11月29日 13:13, Greg KH 写道: > On Thu, Nov 29, 2012 at 12:40:49PM +0800, Chen Gang wrote: >> Hello Greg Kroah-Hartman: >> >> for MAX_ASYNC_BUFFER_SIZE: >> it is defined as 4096; >> but for the max buffer size which it processes, is 65535. >> so suggest to #define MAX_ASYNC_BUFFER_SIZE 0x1 (better than 0x) > > Please, send tty questions to the linux-ser...@vger.kernel.org list > also. I cc to linux-ser...@vger.kernel.org, in this reply. I referenced the file MAINTAINERS, before sent original mail: it seems all drivers/tty/serial/* are relative with linux-ser...@vger.kernel.org. but our case is not relative drivers/tty/serial. so for not bother them, I am not send to them, originally. in MAINTAINERS, line 7438, I find for common of driver/tty/*, can send to you and no cc, so I send you and cc to linux-kernel@vger.kernel.org. next time, for all tty questions, I will cc to linux-ser...@vger.kernel.org (not cc to linux-kernel@vger.kernel.org). > > And, I really don't understand here, why do you want to change this? > What is it going to change? And why? > Why: for the context MGSLPC_INFO *info in drivers/char/pcmcia/synclink_cs.c info->max_frame_size can be the value between 4096 .. 65535 (can be set by its module input parameter) info->flag_buf length is 4096 (MAX_ASYNC_BUFFER_SIZE) in function rx_get_frame the framesize is limit by info->max_frame_size, but may still be larger that 4096. when call function ldisc_receive_buf, info->flag_buf is equal to 4096, but framesize can be more than 4096. it will cause memory over flow. What: #define MAX_ASYNC_BUFFER_SIZE 0x1 (instead of 4096, originally). let it match the max frame size. At last: my suggestion may be incorrect, need relative member (who expert about it) to help checking. welcome another suggestion or completions. thanks. gchen. > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > -- Chen Gang Asianux Corporation -- 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/7] mfd: update on max8925 for DT support
On 11/23/2012 05:09 PM, Haojian Zhuang wrote: On Tue, Nov 6, 2012 at 3:35 PM, Qing Xu wrote: From: Qing Xu 1. add irqdomain for max8925, it is necessary for dt support 2. bug fix in max8925 mfd devices'irq base and device registry failure 3. support DT for max8925 mfd devices Qing Xu (7): mfd: max8925: add irqdomain for dt mfd: max8925: fix mfd device register failure mfd: max8925: fix onkey driver irq base mfd: max8925: support dt for power supply mfd: max8925: support dt for regulator mfd: max8925: support dt for backlight mfd: max8925: add dts arch/arm/boot/dts/mmp2-brownstone.dts | 166 + arch/arm/boot/dts/mmp2.dtsi |4 +- drivers/input/misc/max8925_onkey.c|3 - drivers/mfd/max8925-core.c| 107 + drivers/mfd/max8925-i2c.c | 32 ++- drivers/power/max8925_power.c | 57 ++- drivers/regulator/max8925-regulator.c | 35 +++- drivers/video/backlight/max8925_bl.c | 31 ++- include/linux/mfd/max8925.h | 12 ++- 9 files changed, 389 insertions(+), 58 deletions(-) No document on devicetree binding? I added a new patch of "Documentation: add docs for max8925 dt", please help to review, thanks a lot! -- 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 docs for max8925 dt
From: Qing Xu
add docs for dt of max8925-mfd, max8925-backlight, and
max8925-battery
Signed-off-by: Qing Xu
---
Documentation/devicetree/bindings/mfd/max8925.txt | 64
.../bindings/power_supply/max8925_batter.txt | 18 ++
.../bindings/video/backlight/max8925-backlight.txt | 10 +++
3 files changed, 92 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/max8925.txt
create mode 100644
Documentation/devicetree/bindings/power_supply/max8925_batter.txt
create mode 100644
Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
diff --git a/Documentation/devicetree/bindings/mfd/max8925.txt
b/Documentation/devicetree/bindings/mfd/max8925.txt
new file mode 100644
index 000..13bb62b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max8925.txt
@@ -0,0 +1,64 @@
+* Maxim max8925 Power Management IC
+
+Required parent device properties:
+- compatible : "maxim,max8925"
+- reg : the I2C slave address for the max8925 chip
+- interrupts : IRQ line for the max8925 chip
+- interrupt-controller: describes the max8925 as an interrupt
+ controller (has its own domain)
+- #interrupt-cells : should be 1.
+ - The cell is the max8925 local IRQ number
+
+Optional parent device properties:
+- tsc-irq: there are 2 IRQ lines for max8925, one is indicated in
+ interrupts property, the other is indicated here.
+
+max8925 consists of a large and varied group of sub-devices:
+
+Device Supply NamesDescription
+-- ---
+max8925-onkey : : On key
+max8925-rtc: : RTC
+max8925-regulator : : Regulators
+max8925-backlight : : Backlight
+max8925-touch : : Touchscreen
+max8925-power : : Charger
+
+Example:
+
+ pmic: max8925@3c {
+ compatible = "maxim,max8925";
+ reg = <0x3c>;
+ interrupts = <1>;
+ interrupt-parent = <>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ tsc-irq = <0>;
+
+ regulators {
+ SDV1 {
+ regulator-min-microvolt = <637500>;
+ regulator-max-microvolt = <1425000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO1 {
+ regulator-min-microvolt = <75>;
+ regulator-max-microvolt = <390>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ };
+ backlight {
+ max8925-dual-string = <0>;
+ };
+ charger {
+ batt-detect = <0>;
+ topoff-threshold = <1>;
+ fast-charge = <7>;
+ no-temp-support = <0>;
+ no-insert-detect = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power_supply/max8925_batter.txt
b/Documentation/devicetree/bindings/power_supply/max8925_batter.txt
new file mode 100644
index 000..d7e3e0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/max8925_batter.txt
@@ -0,0 +1,18 @@
+max8925-battery bindings
+
+
+Optional properties :
+ - batt-detect: whether support battery detect
+ - topoff-threshold: set charging current in topoff mode
+ - fast-charge: set charging current in fast mode
+ - no-temp-support: whether support temperature protection detect
+ - no-insert-detect: whether support insert detect
+
+Example:
+ charger {
+ batt-detect = <0>;
+ topoff-threshold = <1>;
+ fast-charge = <7>;
+ no-temp-support = <0>;
+ no-insert-detect = <0>;
+ };
diff --git
a/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
new file mode 100644
index 000..d692db3
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
@@ -0,0 +1,10 @@
+88pm860x-backlight bindings
+
+Optional properties:
+ - max8925-dual-string: whether support dual string
+
+Example:
+
+ backlights {
+ max8925-dual-string = <0>;
+ };
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "tuntap: multiqueue support" causes udev fork bombs
On Wednesday, November 28, 2012 11:25:41 AM Jiri Slaby wrote:
> Hi,
>
> with this commit:
> commit c8d68e6be1c3b242f1c598595830890b65cea64a
> Author: Jason Wang
> Date: Wed Oct 31 19:46:00 2012 +
>
> tuntap: multiqueue support
>
>
> I see fork bombs from udev. It is trying to create 2048 processes. 1024
> for tx, 1024 for rx. OOM killer indeed steps in and kills everything.
Hi, thanks for the reporting, could you pls try the following patch?
---
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index b44d7b7..cc3f878 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -492,9 +492,6 @@ static int tun_attach(struct tun_struct *tun, struct file
*file)
tun_set_real_num_queues(tun);
- if (tun->numqueues == 1)
- netif_carrier_on(tun->dev);
-
/* device is allowed to go away first, so no need to hold extra
* refcnt.
*/
@@ -1611,6 +1608,10 @@ static int tun_set_iff(struct net *net, struct file
*file, struct ifreq *ifr)
TUN_USER_FEATURES;
dev->features = dev->hw_features;
+ err = tun_attach(tun, file);
+ if (err < 0)
+ goto err_free_dev;
+
err = register_netdevice(tun->dev);
if (err < 0)
goto err_free_dev;
@@ -1620,9 +1621,7 @@ static int tun_set_iff(struct net *net, struct file
*file, struct ifreq *ifr)
device_create_file(>dev->dev, _attr_group))
pr_err("Failed to create tun sysfs files\n");
- err = tun_attach(tun, file);
- if (err < 0)
- goto err_free_dev;
+ netif_carrier_on(tun->dev);
}
tun_debug(KERN_INFO, tun, "tun_set_iff\n");
--
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] backlight: corgi_lcd: Fix WARN_ON() when calling corgi_bl_set_intensity.
On Thursday, November 29, 2012 6:47 AM, Marko Katic wrote > Subject: [PATCH] backlight: corgi_lcd: Fix WARN_ON() when calling > corgi_bl_set_intensity. CC'ed Andrew Morton. Hi Marko Katic, The commit subject and commit message are not clear. How about using subject as below? backlight: corgi_lcd: use gpio_set_value_cansleep() In addition, 'Fix WARN_ON() when calling corgi_bl_set_intensity' would be the reason why you submit this patch. Please make the commit message more detail. Also, I have a question on gpio driver. In order to trigger WARN_ON(chip->can_sleep), 'can_sleep' should be set as 1. However, I cannot find 'can_sleep = 1' in the PXA gpio driver. What gpio driver do you use to test corgi_lcd driver? Best regards, Jingoo Han > > From: Marko Katic > > > Signed-off-by: Marko Katic > --- > drivers/video/backlight/corgi_lcd.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/backlight/corgi_lcd.c > b/drivers/video/backlight/corgi_lcd.c > index c781768..8b002d7 100644 > --- a/drivers/video/backlight/corgi_lcd.c > +++ b/drivers/video/backlight/corgi_lcd.c > @@ -409,10 +409,10 @@ static int corgi_bl_set_intensity(struct corgi_lcd > *lcd, int intensity) > cont = !!(intensity & 0x20) ^ lcd->gpio_backlight_cont_inverted; > > if (gpio_is_valid(lcd->gpio_backlight_cont)) > - gpio_set_value(lcd->gpio_backlight_cont, cont); > + gpio_set_value_cansleep(lcd->gpio_backlight_cont, cont); > > if (gpio_is_valid(lcd->gpio_backlight_on)) > - gpio_set_value(lcd->gpio_backlight_on, intensity); > + gpio_set_value_cansleep(lcd->gpio_backlight_on, intensity); > > if (lcd->kick_battery) > lcd->kick_battery(); > -- > 1.7.4.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: manual merge of the pwm tree with the driver-core tree
Hi Thierry,
Today's linux-next merge of the pwm tree got a conflict in
drivers/pwm/pwm-twl6030.c between commit fd1091125a1d ("pwm: remove use
of __devexit_p") from the driver-core tree and commit 6179a58ec7e2 ("pwm:
Remove pwm-twl6030 driver") from the pwm tree.
I fixed it up (the latter removed the file) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpIxTvE5HK8s.pgp
Description: PGP signature
linux-next: manual merge of the pwm tree with the driver-core tree
Hi Thierry,
Today's linux-next merge of the pwm tree got a conflict in
drivers/pwm/pwm-tiehrpwm.c between commit 3e9fe83d278c ("pwm: remove use
of __devinit") from the driver-core tree and commit 53ad9e8d3703 ("pwm:
tiehrpwm: Add device-tree binding") from the pwm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/pwm/pwm-tiehrpwm.c
index 9ffd389,542d5f3..000
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@@ -392,7 -403,13 +403,13 @@@ static const struct pwm_ops ehrpwm_pwm_
.owner = THIS_MODULE,
};
+ static const struct of_device_id ehrpwm_of_match[] = {
+ { .compatible = "ti,am33xx-ehrpwm" },
+ {},
+ };
+ MODULE_DEVICE_TABLE(of, ehrpwm_of_match);
+
-static int __devinit ehrpwm_pwm_probe(struct platform_device *pdev)
+static int ehrpwm_pwm_probe(struct platform_device *pdev)
{
int ret;
struct resource *r;
@@@ -439,11 -471,29 +471,29 @@@
}
pm_runtime_enable(>dev);
+ pm_runtime_get_sync(>dev);
+
+ status = pwmss_submodule_state_change(pdev->dev.parent,
+ PWMSS_EPWMCLK_EN);
+ if (!(status & PWMSS_EPWMCLK_EN_ACK)) {
+ dev_err(>dev, "PWMSS config space clock enable failed\n");
+ ret = -EINVAL;
+ goto pwmss_clk_failure;
+ }
+
+ pm_runtime_put_sync(>dev);
+
platform_set_drvdata(pdev, pc);
return 0;
+
+ pwmss_clk_failure:
+ pm_runtime_put_sync(>dev);
+ pm_runtime_disable(>dev);
+ pwmchip_remove(>chip);
+ return ret;
}
-static int __devexit ehrpwm_pwm_remove(struct platform_device *pdev)
+static int ehrpwm_pwm_remove(struct platform_device *pdev)
{
struct ehrpwm_pwm_chip *pc = platform_get_drvdata(pdev);
@@@ -454,10 -512,12 +512,12 @@@
static struct platform_driver ehrpwm_pwm_driver = {
.driver = {
- .name = "ehrpwm",
+ .name = "ehrpwm",
+ .owner = THIS_MODULE,
+ .of_match_table = ehrpwm_of_match,
},
.probe = ehrpwm_pwm_probe,
- .remove = __devexit_p(ehrpwm_pwm_remove),
+ .remove = ehrpwm_pwm_remove,
};
module_platform_driver(ehrpwm_pwm_driver);
pgpSE1caXNifo.pgp
Description: PGP signature
linux-next: manual merge of the pwm tree with the driver-core tree
Hi Thierry,
Today's linux-next merge of the pwm tree got a conflict in
drivers/pwm/pwm-tiecap.c between commit 3e9fe83d278c ("pwm: remove use of
__devinit") from the driver-core tree and commit 333b08ee8c6e ("pwm:
tiecap: Add device-tree binding") from the pwm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/pwm/pwm-tiecap.c
index 87c091b,b4f9d47..000
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@@ -184,7 -188,13 +188,13 @@@ static const struct pwm_ops ecap_pwm_op
.owner = THIS_MODULE,
};
+ static const struct of_device_id ecap_of_match[] = {
+ { .compatible = "ti,am33xx-ecap" },
+ {},
+ };
+ MODULE_DEVICE_TABLE(of, ecap_of_match);
+
-static int __devinit ecap_pwm_probe(struct platform_device *pdev)
+static int ecap_pwm_probe(struct platform_device *pdev)
{
int ret;
struct resource *r;
@@@ -231,11 -249,29 +249,29 @@@
}
pm_runtime_enable(>dev);
+ pm_runtime_get_sync(>dev);
+
+ status = pwmss_submodule_state_change(pdev->dev.parent,
+ PWMSS_ECAPCLK_EN);
+ if (!(status & PWMSS_ECAPCLK_EN_ACK)) {
+ dev_err(>dev, "PWMSS config space clock enable failed\n");
+ ret = -EINVAL;
+ goto pwmss_clk_failure;
+ }
+
+ pm_runtime_put_sync(>dev);
+
platform_set_drvdata(pdev, pc);
return 0;
+
+ pwmss_clk_failure:
+ pm_runtime_put_sync(>dev);
+ pm_runtime_disable(>dev);
+ pwmchip_remove(>chip);
+ return ret;
}
-static int __devexit ecap_pwm_remove(struct platform_device *pdev)
+static int ecap_pwm_remove(struct platform_device *pdev)
{
struct ecap_pwm_chip *pc = platform_get_drvdata(pdev);
@@@ -246,10 -290,12 +290,12 @@@
static struct platform_driver ecap_pwm_driver = {
.driver = {
- .name = "ecap",
+ .name = "ecap",
+ .owner = THIS_MODULE,
+ .of_match_table = ecap_of_match,
},
.probe = ecap_pwm_probe,
- .remove = __devexit_p(ecap_pwm_remove),
+ .remove = ecap_pwm_remove,
};
module_platform_driver(ecap_pwm_driver);
pgp40SlhQqUjL.pgp
Description: PGP signature
[PATCH RFT v2] regulator: max1586: Implement get_voltage_sel callback
This is required since commit f7df20ec32
"regulator: core: Use list_voltage() to read single voltage regulators",
otherwise _regulator_get_voltage returns rdev->desc->ops->list_voltage(rdev, 0).
The Maxim 1586 controls V3 and V6 voltages, but offers no way of reading back
the set up value. Thus this patch caches the setting when setting new voltage.
Signed-off-by: Axel Lin
---
v2: get_voltage_sel returns selector rather than voltage.
drivers/regulator/max1586.c | 44 ---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/max1586.c b/drivers/regulator/max1586.c
index 3a035ec..8c5a54f 100644
--- a/drivers/regulator/max1586.c
+++ b/drivers/regulator/max1586.c
@@ -44,6 +44,9 @@ struct max1586_data {
unsigned int min_uV;
unsigned int max_uV;
+ unsigned int v3_curr_sel;
+ unsigned int v6_curr_sel;
+
struct regulator_dev *rdev[0];
};
@@ -63,31 +66,60 @@ static int v6_voltages_uv[] = { 1, 180, 250,
300 };
* R24 and R25=100kOhm as described in the data sheet.
* The gain is approximately: 1 + R24/R25 + R24/185.5kOhm
*/
+static int max1586_v3_get_voltage_sel(struct regulator_dev *rdev)
+{
+ struct max1586_data *max1586 = rdev_get_drvdata(rdev);
+
+ return max1586->v3_curr_sel;
+}
+
static int max1586_v3_set_voltage_sel(struct regulator_dev *rdev,
unsigned selector)
{
struct max1586_data *max1586 = rdev_get_drvdata(rdev);
struct i2c_client *client = max1586->client;
+ int ret;
u8 v3_prog;
dev_dbg(>dev, "changing voltage v3 to %dmv\n",
regulator_list_voltage_linear(rdev, selector) / 1000);
v3_prog = I2C_V3_SELECT | (u8) selector;
- return i2c_smbus_write_byte(client, v3_prog);
+ ret = i2c_smbus_write_byte(client, v3_prog);
+ if (ret)
+ return ret;
+
+ max1586->v3_curr_sel = selector;
+
+ return 0;
+}
+
+static int max1586_v6_get_voltage_sel(struct regulator_dev *rdev)
+{
+ struct max1586_data *max1586 = rdev_get_drvdata(rdev);
+
+ return max1586->v6_curr_sel;
}
static int max1586_v6_set_voltage_sel(struct regulator_dev *rdev,
unsigned int selector)
{
- struct i2c_client *client = rdev_get_drvdata(rdev);
+ struct max1586_data *max1586 = rdev_get_drvdata(rdev);
+ struct i2c_client *client = max1586->client;
u8 v6_prog;
+ int ret;
dev_dbg(>dev, "changing voltage v6 to %dmv\n",
rdev->desc->volt_table[selector] / 1000);
v6_prog = I2C_V6_SELECT | (u8) selector;
- return i2c_smbus_write_byte(client, v6_prog);
+ ret = i2c_smbus_write_byte(client, v6_prog);
+ if (ret)
+ return ret;
+
+ max1586->v6_curr_sel = selector;
+
+ return 0;
}
/*
@@ -95,12 +127,14 @@ static int max1586_v6_set_voltage_sel(struct regulator_dev
*rdev,
* the set up value.
*/
static struct regulator_ops max1586_v3_ops = {
+ .get_voltage_sel = max1586_v3_get_voltage_sel,
.set_voltage_sel = max1586_v3_set_voltage_sel,
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
};
static struct regulator_ops max1586_v6_ops = {
+ .get_voltage_sel = max1586_v6_get_voltage_sel,
.set_voltage_sel = max1586_v6_set_voltage_sel,
.list_voltage = regulator_list_voltage_table,
};
@@ -148,6 +182,10 @@ static int max1586_pmic_probe(struct i2c_client *client,
max1586->min_uV = MAX1586_V3_MIN_UV / 1000 * pdata->v3_gain / 1000;
max1586->max_uV = MAX1586_V3_MAX_UV / 1000 * pdata->v3_gain / 1000;
+ /* Set curr_sel to default voltage on power-up */
+ max1586->v3_curr_sel = 24; /* 1.3V */
+ max1586->v6_curr_sel = 0;
+
rdev = max1586->rdev;
for (i = 0; i < pdata->num_subdevs && i <= MAX1586_V6; i++) {
id = pdata->subdevs[i].id;
--
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: linux-next: manual merge of the driver-core tree with the mfd tree
On Thu, Nov 29, 2012 at 02:43:02PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/gpio/gpio-tps6586x.c between commit fe39f2f4dc84 ("mfd: Implement
> tps6586x gpio_to_irq") from the mfd tree and commit 3836309d9346 ("gpio:
> remove use of __devinit") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the mfd tree
On Thu, Nov 29, 2012 at 02:47:12PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/mfd/ab8500-core.c between commit 8ae754ebd5ed ("mfd: ab8500-core:
> Remove unused ab8500-gpio IRQ ranges") from the mfd tree and commit
> a9e9ce4c4167 ("mfd: remove use of __devinitdata") from the driver-core
> tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the mfd tree
On Thu, Nov 29, 2012 at 02:57:14PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/mfd/sta2x11-mfd.c between various commits from the mfd tree and
> commits f791be492f76 ("mfd: remove use of __devinit"), a9e9ce4c4167
> ("mfd: remove use of __devinitdata") and a73e5df16b52 ("mfd: remove use
> of __devinitconst") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the mfd tree
On Thu, Nov 29, 2012 at 02:50:39PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/mfd/da9052-core.c between commit 8bad1abd6303 ("mfd: da9052:
> Introduce da9052-irq.c") from the mfd tree and commit a9e9ce4c4167 ("mfd:
> remove use of __devinitdata") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the mfd tree
On Thu, Nov 29, 2012 at 03:00:44PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/mfd/tps65090.c between various commits from the mfd tree and
> commits 84449216b01f ("mfd: remove use of __devexit_p"), f791be492f76
> ("mfd: remove use of __devinit") and 4740f73fe538 ("mfd: remove use of
> __devexit") from the driver-core tree.
>
> I fixed it up (by using the mfd tree version) and can carry the fix as
> necessary (no action is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the pci tree
On Thu, Nov 29, 2012 at 03:03:40PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/pci/pci.h between commit 4e15c46bdc4d ("PCI: Add pci_device_type
> to pdev's device struct") from the pci tree and commit b40b97ae736c
> ("PCI: Remove CONFIG_HOTPLUG ifdefs") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the pci tree
On Thu, Nov 29, 2012 at 03:06:41PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/pci/quirks.c between commit 21c5fd97380b ("PCI: Add workaround
> for PLX PCI 9050 BAR alignment erratum") from the pci tree and commit
> 15856ad50bf5 ("PCI: Remove __dev* markings") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the battery tree
On Thu, Nov 29, 2012 at 03:09:33PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/power/ab8500_btemp.c between commit bd9e8ab2d58d ("ab8500: Add
> devicetree support for btemp") from the battery tree and commit
> c8afa6406e60 ("power: remove use of __devinit") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the battery tree
On Thu, Nov 29, 2012 at 03:11:42PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/power/ab8500_charger.c between commit 4aef72dbb2e8 ("ab8500: Add
> devicetree support for charger") from the battery tree and commit
> c8afa6406e60 ("power: remove use of __devinit") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the battery tree
On Thu, Nov 29, 2012 at 03:15:58PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/power/abx500_chargalg.c between commit a12810ab9fcf ("ab8500: Add
> devicetree support for chargalg") from the battery tree and commit
> c8afa6406e60 ("power: remove use of __devinit") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the battery tree
On Thu, Nov 29, 2012 at 03:13:36PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/power/ab8500_fg.c between commit e0f1abeba5c2 ("ab8500: Add
> devicetree support for fuelgauge") from the battery tree and commit
> c8afa6406e60 ("power: remove use of __devinit") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the mfd tree
On Thu, Nov 29, 2012 at 03:18:04PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/power/da9052-battery.c between commit 4b5edf7887c6 ("power:
> da9052-battery: Convert to the new da9052 interrupt functions") from the
> mfd tree and commit c8afa6406e60 ("power: remove use of __devinit") from
> the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the battery tree
On Thu, Nov 29, 2012 at 03:20:08PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/power/max8925_power.c between commit eba3b670a916
> ("max8925_power: Add support for device-tree initialization") from the
> battery tree and commit c8afa6406e60 ("power: remove use of __devinit")
> from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the tip tree
On Thu, Nov 29, 2012 at 03:24:11PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> lib/Makefile between commit e6459606b04e ("lib: Add early cpio decoder")
> from the tip tree and commit 610141ee651c ("lib: kobject_uevent is no
> longer dependant on CONFIG_HOTPLUG") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the slave-dma tree
On Thu, Nov 29, 2012 at 09:16:06AM +0530, Viresh Kumar wrote: > On 29 November 2012 09:10, Stephen Rothwell wrote: > > diff --cc drivers/dma/dw_dmac.c > > > +#ifdef CONFIG_OF > > +static struct dw_dma_platform_data * > > +__devinit dw_dma_parse_dt(struct platform_device *pdev) > > Do we need a separate patch to fix this place? I believe yes. Don't worry about that for now, I'll sweep the tree after 3.8-rc1 is out to catch stuff like this. Otherwise the merge issues are going to be even worse. Or, you can fix this in the slave-dma tree if you want. > > - static int __devinit dw_probe(struct platform_device *pdev) > > + static int dw_probe(struct platform_device *pdev) > > Thanks for this. Me too, thanks Stephen, and sorry for the problems this caused. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the driver-core tree
On Thu, Nov 29, 2012 at 04:03:09PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/leds/leds-ns2.c between commit 98ea1ea20cb7 ("leds: remove use of
> __devinit") from the driver-core tree and commit 72052fcc1026 ("leds:
> leds-ns2: add device tree binding") from the arm-soc tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the gpio tree with the driver-core tree
On Thu, Nov 29, 2012 at 03:57:23PM +1100, Stephen Rothwell wrote:
> Hi Grant,
>
> Today's linux-next merge of the gpio tree got a conflict in
> drivers/gpio/gpio-em.c between commit 3836309d9346 ("gpio: remove use of
> __devinit") from the driver-core tree and commit 7385500a49b7 ("gpio/em:
> convert to linear IRQ domain") from the gpio tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the staging tree with the tty tree
On Thu, Nov 29, 2012 at 03:47:39PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflicts in
> drivers/staging/fwserial/fwserial.c, drivers/staging/Kconfig and
> drivers/staging/Kconfig between commit 7355ba3445f2 ("staging: fwserial:
> Add TTY-over-Firewire serial driver") from the tty tree and commit
> e5711071ad94 ("staging: fwserial: Add TTY-over-Firewire serial driver")
> from the staging tree.
>
> I am not sure why this patch exists in both trees :-(
I needed to do that to handle the tty driver changes that were required
for it due to the tty layer changes.
> I fixed it up (they are the same but the trees contain more commits
> affecting these files) and can carry the fix as necessary (no action is
> required).
The tty tree will end up having the "correct" one here, thanks for
resolving this in your tree.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFT] regulator: max1586: Implement get_voltage_sel callback
This is required since commit f7df20ec32
"regulator: core: Use list_voltage() to read single voltage regulators",
otherwise _regulator_get_voltage returns rdev->desc->ops->list_voltage(rdev, 0).
The Maxim 1586 controls V3 and V6 voltages, but offers no way of reading back
the set up value. Thus this patch caches the setting when setting new voltage.
Signed-off-by: Axel Lin
---
drivers/regulator/max1586.c | 44 ---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/max1586.c b/drivers/regulator/max1586.c
index 3a035ec..98ffa0d 100644
--- a/drivers/regulator/max1586.c
+++ b/drivers/regulator/max1586.c
@@ -44,6 +44,9 @@ struct max1586_data {
unsigned int min_uV;
unsigned int max_uV;
+ unsigned int v3_curr_sel;
+ unsigned int v6_curr_sel;
+
struct regulator_dev *rdev[0];
};
@@ -63,31 +66,60 @@ static int v6_voltages_uv[] = { 1, 180, 250,
300 };
* R24 and R25=100kOhm as described in the data sheet.
* The gain is approximately: 1 + R24/R25 + R24/185.5kOhm
*/
+static int max1586_v3_get_voltage_sel(struct regulator_dev *rdev)
+{
+ struct max1586_data *max1586 = rdev_get_drvdata(rdev);
+
+ return regulator_list_voltage_linear(rdev, max1586->v3_curr_sel);
+}
+
static int max1586_v3_set_voltage_sel(struct regulator_dev *rdev,
unsigned selector)
{
struct max1586_data *max1586 = rdev_get_drvdata(rdev);
struct i2c_client *client = max1586->client;
+ int ret;
u8 v3_prog;
dev_dbg(>dev, "changing voltage v3 to %dmv\n",
regulator_list_voltage_linear(rdev, selector) / 1000);
v3_prog = I2C_V3_SELECT | (u8) selector;
- return i2c_smbus_write_byte(client, v3_prog);
+ ret = i2c_smbus_write_byte(client, v3_prog);
+ if (ret)
+ return ret;
+
+ max1586->v3_curr_sel = selector;
+
+ return 0;
+}
+
+static int max1586_v6_get_voltage_sel(struct regulator_dev *rdev)
+{
+ struct max1586_data *max1586 = rdev_get_drvdata(rdev);
+
+ return regulator_list_voltage_table(rdev, max1586->v6_curr_sel);
}
static int max1586_v6_set_voltage_sel(struct regulator_dev *rdev,
unsigned int selector)
{
- struct i2c_client *client = rdev_get_drvdata(rdev);
+ struct max1586_data *max1586 = rdev_get_drvdata(rdev);
+ struct i2c_client *client = max1586->client;
u8 v6_prog;
+ int ret;
dev_dbg(>dev, "changing voltage v6 to %dmv\n",
rdev->desc->volt_table[selector] / 1000);
v6_prog = I2C_V6_SELECT | (u8) selector;
- return i2c_smbus_write_byte(client, v6_prog);
+ ret = i2c_smbus_write_byte(client, v6_prog);
+ if (ret)
+ return ret;
+
+ max1586->v6_curr_sel = selector;
+
+ return 0;
}
/*
@@ -95,12 +127,14 @@ static int max1586_v6_set_voltage_sel(struct regulator_dev
*rdev,
* the set up value.
*/
static struct regulator_ops max1586_v3_ops = {
+ .get_voltage_sel = max1586_v3_get_voltage_sel,
.set_voltage_sel = max1586_v3_set_voltage_sel,
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
};
static struct regulator_ops max1586_v6_ops = {
+ .get_voltage_sel = max1586_v6_get_voltage_sel,
.set_voltage_sel = max1586_v6_set_voltage_sel,
.list_voltage = regulator_list_voltage_table,
};
@@ -148,6 +182,10 @@ static int max1586_pmic_probe(struct i2c_client *client,
max1586->min_uV = MAX1586_V3_MIN_UV / 1000 * pdata->v3_gain / 1000;
max1586->max_uV = MAX1586_V3_MAX_UV / 1000 * pdata->v3_gain / 1000;
+ /* Set curr_sel to default voltage on power-up */
+ max1586->v3_curr_sel = 24; /* 1.3V */
+ max1586->v6_curr_sel = 0;
+
rdev = max1586->rdev;
for (i = 0; i < pdata->num_subdevs && i <= MAX1586_V6; i++) {
id = pdata->subdevs[i].id;
--
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: 【Suggestion】drivers/tty: drivers/char/: for MAX_ASYNC_BUFFER_SIZE
On Thu, Nov 29, 2012 at 12:40:49PM +0800, Chen Gang wrote: > Hello Greg Kroah-Hartman: > > for MAX_ASYNC_BUFFER_SIZE: > it is defined as 4096; > but for the max buffer size which it processes, is 65535. > so suggest to #define MAX_ASYNC_BUFFER_SIZE 0x1 (better than 0x) Please, send tty questions to the linux-ser...@vger.kernel.org list also. And, I really don't understand here, why do you want to change this? What is it going to change? And why? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Suggestion] drivers/tty: drivers/char/: for MAX_ASYNC_BUFFER_SIZE
Hello Greg Kroah-Hartman:
for MAX_ASYNC_BUFFER_SIZE:
it is defined as 4096;
but for the max buffer size which it processes, is 65535.
so suggest to #define MAX_ASYNC_BUFFER_SIZE 0x1 (better than 0x)
I use 3 Step to prove it, please see below:
by the way:
I find it only through code review, not test it.
so I send it as suggestions (not a patch).
next time:
for the same case, if it is better to send a patch, directly.
please tell me by replying for this mail.
(at least, it can save your time, since you are busy)
gchen.
-
Step 1:
the MAX_ASYNC_BUFFER_SIZE is 4096:
root@gchen-desktop:~/linux# grep -rn MAX_ASYNC_BUFFER_SIZE *
drivers/char/pcmcia/synclink_cs.c:213: char flag_buf[MAX_ASYNC_BUFFER_SIZE];
drivers/tty/synclink_gt.c:320: char flag_buf[MAX_ASYNC_BUFFER_SIZE];
drivers/tty/synclink_gt.c:321: char char_buf[MAX_ASYNC_BUFFER_SIZE];
drivers/tty/synclink.c:294: char flag_buf[MAX_ASYNC_BUFFER_SIZE];
drivers/tty/synclink.c:295: char char_buf[MAX_ASYNC_BUFFER_SIZE];
drivers/tty/synclinkmp.c:265: char flag_buf[MAX_ASYNC_BUFFER_SIZE];
drivers/tty/synclinkmp.c:266: char char_buf[MAX_ASYNC_BUFFER_SIZE];
include/uapi/linux/synclink.h:54:#define MAX_ASYNC_BUFFER_SIZE 4096
-
Step 2:
one sample in drivers/char/pcmcia/synclink_cs.c: (same for another files)
we check the framesize according to info->max_frame_size in line 3687..3689.
and call ldisc_receive_buf without checking whether it is larger than
MAX_ASYNC_BUFFER_SIZE at line 3705
info->max_frame_size can be the value between 4096 and 65535 in line
2729..2732.
ldisc_receive_buf call ld->ops->receive_buf to perform the work.
496 static void ldisc_receive_buf(struct tty_struct *tty,
497 const __u8 *data, char *flags, int count)
498 {
499 struct tty_ldisc *ld;
500 if (!tty)
501 return;
502 ld = tty_ldisc_ref(tty);
503 if (ld) {
504 if (ld->ops->receive_buf)
505 ld->ops->receive_buf(tty, data, flags, count);
506 tty_ldisc_deref(ld);
507 }
508 }
...
2728
2729 if (info->max_frame_size < 4096)
2730 info->max_frame_size = 4096;
2731 else if (info->max_frame_size > 65535)
2732 info->max_frame_size = 65535;
2733
...
3686 if (framesize) {
3687 if ((info->params.crc_type & HDLC_CRC_RETURN_EX &&
3688 framesize+1 > info->max_frame_size) ||
3689 framesize > info->max_frame_size)
3690 info->icount.rxlong++;
3691 else {
3692 if (status & BIT5)
3693 info->icount.rxok++;
3694
3695 if (info->params.crc_type & HDLC_CRC_RETURN_EX) {
3696 *(buf->data + framesize) = status & BIT5 ?
RX_OK:RX_CRC_ERROR;
3697 ++framesize;
3698 }
3699
3700 #if SYNCLINK_GENERIC_HDLC
3701 if (info->netcount)
3702 hdlcdev_rx(info, buf->data, framesize);
3703 else
3704 #endif
3705 ldisc_receive_buf(tty, buf->data,
info->flag_buf, framesize);
3706 }
3707 }
-
Step 3:
one sample in drivers/tty/n_gsm.c (same for another implementation)
receive_buf is a function ptr which may be gsmld_receive_buf at line 2819.
it does not check the length of count whether larger than
MAX_ASYNC_BUFFER_SIZE.
if count is larger than MAX_ASYNC_BUFFER_SIZE, will cause issue.
it is only a sample, maybe not the function ptr which mentioned in Step 2.
at lease, I have checked 3 function ptr implementations, none of them check
the MAX_ASYNC_BUFFER_SIZE.
the all function ptr searching is at the bottom.
2257 static void gsmld_receive_buf(struct tty_struct *tty, const unsigned char
*cp,
2258 char *fp, int count)
2259 {
2260 struct gsm_mux *gsm = tty->disc_data;
2261 const unsigned char *dp;
2262 char *f;
2263 int i;
2264 char buf[64];
2265 char flags;
2266
2267 if (debug & 4)
2268 print_hex_dump_bytes("gsmld_receive: ", DUMP_PREFIX_OFFSET,
2269 cp, count);
2270
2271 for (i = count, dp = cp, f = fp; i; i--, dp++) {
2272 flags = *f++;
2273 switch (flags) {
2274 case TTY_NORMAL:
2275 gsm->receive(gsm, *dp);
2276 break;
2277 case TTY_OVERRUN:
2278
[PATCH 2/2] i2c-s3c2410: Add bus arbitration implementation
From: Simon Glass
The arbitrator is a general purpose function which uses two GPIOs to
communicate with another device to claim/release a bus. We use it to
arbitrate an i2c port between the AP and the EC.
Signed-off-by: Simon Glass
Cc: Grant Grundler
Signed-off-by: Naveen Krishna Chatradhi
---
.../devicetree/bindings/i2c/samsung-i2c.txt| 46 ++
drivers/i2c/busses/i2c-s3c2410.c | 167 ++--
2 files changed, 200 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt
b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt
index e9611ac..4bed49f 100644
--- a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt
@@ -28,6 +28,11 @@ Optional properties:
specified, default value is 0.
- samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
specified, the default value in Hz is 10.
+ - samsung,arbitration-gpios : Two GPIOs to use with the GPIO-based bus
+arbitration protocol (see below). The first should be an output, and is
+used to claim the I2C bus, the second should be an input, and signals that
+the other side wants to claim the bus. This allows two masters to share
+the same I2C bus.
Example:
@@ -52,4 +57,45 @@ Example:
compatible = "wlf,wm8994";
reg = <0x1a>;
};
+
+ /* If you want GPIO-based bus arbitration */
+ samsung,arbitration-gpios = < 3 1 0 0>,/* AP_CLAIM */
+ < 4 0 3 0>;/* EC_CLAIM */
};
+
+
+GPIO-based Arbitration
+==
+(documented here for want of a better place - an implementation is in the
+i2c-s3c2410 driver)
+
+This uses GPIO lines between the AP (Exynos) and an attached EC (embedded
+controller) which both want to talk on the same I2C bus as master.
+
+The AP and EC each have a 'bus claim' line, which is an output that the
+other can see. These are both active low, with pull-ups enabled.
+
+- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
+- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus
+
+
+Algorithm
+-
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say the AP wants to claim the bus. It:
+1. Asserts AP_CLAIM
+2. Waits a little bit for the other side to notice (slew time, say 10
+microseconds)
+3. Checks EC_CLAIM. If this is not asserted, then the AP has the bus, and
+we are done
+4. Otherwise, wait for a few milliseconds and see if EC_CLAIM is released
+5. If not, back off, release the claim and wait for a few more milliseconds
+6. Go back to 1 (until retry time has expired)
+
+To release the bus, just de-assert the claim line. If the other wants the bus
+it will notice soon enough.
+
+The same algorithm applies on the EC side.
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 2fd346d..87a6928 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -62,6 +62,13 @@ enum s3c24xx_i2c_state {
STATE_STOP
};
+enum {
+ I2C_ARB_GPIO_AP,/* AP claims i2c bus */
+ I2C_ARB_GPIO_EC,/* EC claims i2c bus */
+
+ I2C_ARB_GPIO_COUNT,
+};
+
struct s3c24xx_i2c {
wait_queue_head_t wait;
unsigned intquirks;
@@ -85,10 +92,16 @@ struct s3c24xx_i2c {
struct s3c2410_platform_i2c *pdata;
int gpios[2];
+ int arb_gpios[I2C_ARB_GPIO_COUNT];
struct pinctrl *pctrl;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
+ /* Arbitration parameters */
+ boolarbitrate;
+ unsigned intslew_delay_us;
+ unsigned intwait_retry_us;
+ unsigned intwait_free_us;
};
static struct platform_device_id s3c24xx_driver_ids[] = {
@@ -116,6 +129,61 @@ static const struct of_device_id s3c24xx_i2c_match[] = {
MODULE_DEVICE_TABLE(of, s3c24xx_i2c_match);
#endif
+/*
+ * If we have enabled arbitration on this bus, claim the i2c bus, using
+ * the GPIO-based signalling protocol.
+ */
+int s3c24xx_i2c_claim(struct s3c24xx_i2c *i2c)
+{
+ unsigned long stop_retry, stop_time;
+
+ if (!i2c->arbitrate)
+ return 0;
+
+ /* Start a round of trying to claim the bus */
+ stop_time = jiffies + usecs_to_jiffies(i2c->wait_free_us) + 1;
+ do {
+ /* Indicate that we want to claim the bus */
+ gpio_set_value(i2c->arb_gpios[I2C_ARB_GPIO_AP], 0);
+ udelay(i2c->slew_delay_us);
+
+ /* Wait for the EC to release it */
+
