[PATCH] mm: remove compressed copy from zram in-memory
Swap subsystem does lazy swap slot free with expecting the page
would be swapped out again so we can avoid unnecessary write.
But the problem in in-memory swap(ex, zram) is that it consumes
memory space until vm_swap_full(ie, used half of all of swap device)
condition meet. It could be bad if we use multiple swap device,
small in-memory swap and big storage swap or in-memory swap alone.
This patch makes swap subsystem free swap slot as soon as swap-read
is completed and make the swapcache page dirty so the page should
be written out the swap device to reclaim it.
It means we never lose it.
I tested this patch with kernel compile workload.
1. before
compile time : 9882.42
zram max wasted space by fragmentation: 13471881 byte
memory space consumed by zram: 174227456 byte
the number of slot free notify: 206684
2. after
compile time : 9653.90
zram max wasted space by fragmentation: 11805932 byte
memory space consumed by zram: 154001408 byte
the number of slot free notify: 426972
Cc: Hugh Dickins hu...@google.com
Cc: Seth Jennings sjenn...@linux.vnet.ibm.com
Cc: Nitin Gupta ngu...@vflare.org
Cc: Konrad Rzeszutek Wilk kon...@darnok.org
Cc: Shaohua Li s...@kernel.org
Signed-off-by: Dan Magenheimer dan.magenhei...@oracle.com
Signed-off-by: Minchan Kim minc...@kernel.org
---
Fragment ratio is almost same but memory consumption and compile time
is better. I am working to add defragment function of zsmalloc.
mm/page_io.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/mm/page_io.c b/mm/page_io.c
index 78eee32..644900a 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -20,6 +20,7 @@
#include linux/buffer_head.h
#include linux/writeback.h
#include linux/frontswap.h
+#include linux/blkdev.h
#include asm/pgtable.h
static struct bio *get_swap_bio(gfp_t gfp_flags,
@@ -81,8 +82,30 @@ void end_swap_bio_read(struct bio *bio, int err)
iminor(bio-bi_bdev-bd_inode),
(unsigned long long)bio-bi_sector);
} else {
+ /*
+* There is no reason to keep both uncompressed data and
+* compressed data in memory.
+*/
+ struct swap_info_struct *sis;
+
SetPageUptodate(page);
+ sis = page_swap_info(page);
+ if (sis-flags SWP_BLKDEV) {
+ struct gendisk *disk = sis-bdev-bd_disk;
+ if (disk-fops-swap_slot_free_notify) {
+ swp_entry_t entry;
+ unsigned long offset;
+
+ entry.val = page_private(page);
+ offset = swp_offset(entry);
+
+ SetPageDirty(page);
+ disk-fops-swap_slot_free_notify(sis-bdev,
+ offset);
+ }
+ }
}
+
unlock_page(page);
bio_put(bio);
}
--
1.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] hfsplus: add printk to log allocation failure in hfs_find_init()
On Sun, 2013-04-07 at 15:00 -0700, Joe Perches wrote:
On Mon, 2013-04-08 at 01:21 +0400, Alexey Khoroshilov wrote:
Add printk to log allocation failure in hfs_find_init(),
so that there is a sign in dmesg when the error condition is triggered.
(per Hin-Tak Leung request)
Not needed. There already is a generic dump_stack
on all allocation failures without __GFP_NOWARN.
I agree too.
Moreover, Hin-Tak asks about dprint() but not printk(). The dprint()
messages can be useful for debugging purposes and will be disabled for
usual kernel build.
I think that adding dprint() messages in hfs_find_init() is not
necessary. But adding dprint() for __hfsplus_ext_write_extent() and
other places can be useful, from my point of view. And such messages can
be useful as for HFS+ as for HFS drivers.
With the best regards,
Vyacheslav Dubeyko.
diff --git a/fs/hfsplus/bfind.c b/fs/hfsplus/bfind.c
[]
@@ -18,8 +18,10 @@ int hfs_find_init(struct hfs_btree *tree, struct
hfs_find_data *fd)
+ if (!ptr) {
+ printk(KERN_ERR hfs: allocation failed in hfs_find_init()\n);
return -ENOMEM;
--
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: [v5] clk: add si5351 i2c common clock driver
On 04/08/2013 02:17 AM, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
On 04/08/2013 12:50 AM, Guenter Roeck wrote:
On Fri, Apr 05, 2013 at 05:23:35AM -, Sebastian Hesselbarth wrote:
This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.
Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
Tested-by: Daniel Mackzon...@gmail.com
[ ... ]
+static inline void _si5351_msynth_set_pll_master(
+ struct si5351_driver_data *drvdata, unsigned char num, int is_master)
+{
+ unsigned long flags;
+
+ if (num 8 ||
+ (drvdata-variant == SI5351_VARIANT_A3 num 3))
+ return;
+
+ flags = __clk_get_flags(drvdata-msynth[num].hw.clk);
+ if (is_master)
+ flags |= CLK_SET_RATE_PARENT;
+ else
+ flags= ~CLK_SET_RATE_PARENT;
+ __clk_set_flags(drvdata-msynth[num].hw.clk, flags);
+}
+
Unless I am missing something, neither __clk_get_flags() nor the new
__clk_set_flags is exported.
Did you try to build and load the driver as module ?
Well, good catch. I didn't try to build v5 as a module, but I guess it
will fail. But I consider this as something that has to be addressed in
clk framework itself, not in this patch. There will be other
clk-providers built as module in the future for sure.
Sure, but you provided the patch to make __clk_set_flags global. To avoid
build failures, I would suggest to either submit a patch to export the
missing functions, or to remove the ability to build the driver as module.
Actually, I knew that __clk_set_flags patch will not be accepted before
posting it ;)
On a side note, do you happen to know anyone working on drivers for Si5319 or
Si5368 ?
No.
Thanks,
Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AMD Vi error and lost networking with r8169
Sure. Will apply this evening. It may take several days before I can report back due to the intermittent nature of the thing. Thanks David Quoting Francois Romieu rom...@fr.zoreil.com: David R da...@unsolicited.net : I'm been seeing some problems with my new ish AMD motherboard/processor combo and networking (r8169). I see the following page fault :- Apr 7 12:25:14 david kernel: [156421.436545] AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0015 address=0x3000 flags=0x0050] Can you give the hack below a try ? diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 28fb50a..ed8625d 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -4125,6 +4125,8 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp) case RTL_GIGA_MAC_VER_23: case RTL_GIGA_MAC_VER_24: case RTL_GIGA_MAC_VER_34: + case RTL_GIGA_MAC_VER_35: + case RTL_GIGA_MAC_VER_36: RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST); break; default: -- 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] F2FS: Fix the logic of IS_DNODE()
Hi,
2013-04-07 (일), 12:57 -0400, Zhihui Zhang:
Signed-off-by: Zhihui Zhang zzhs...@gmail.com
---
fs/f2fs/node.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index afdb130..2be47b2 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -239,7 +239,7 @@ static inline bool IS_DNODE(struct page *node_page)
return false;
if (ofs = 6 + 2 * NIDS_PER_BLOCK) {
ofs -= 6 + 2 * NIDS_PER_BLOCK;
- if ((long int)ofs % (NIDS_PER_BLOCK + 1))
+ if (!((long int)ofs % (NIDS_PER_BLOCK + 1)))
Great catch!
I'll apply this.
Thank you.
return false;
}
return true;
--
Jaegeuk Kim
Samsung
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] clk: add helper to set flags for clk-provider
On 04/08/2013 05:59 AM, Mike Turquette wrote: Quoting Sebastian Hesselbarth (2013-04-04 22:22:12) Clock providers are not allowed to mess with struct clk internals directly but using helpers provided by clk-provider.h. This patch adds a helper to allow to set flags of a clock after registration. This is useful, if clock flags change during runtime, e.g. ability to set parent clock after mux switch. Hi Sebastian, I do not like this change. There are a few reasons why. Firstly the clk flags have never been advertised as changing at runtime. On that note, can you expand your example of ability to set parent clock after mux switch? I do not follow what you mean. Mike, I knew you wouldn't like it. I just wanted to raise this discussion. Consider a clock mux like in si5351 where each output clock can be muxed to either it's own pll clock divider, the pll clock divider of clk0, xtal, or clkin. And consider you want to allow to configure the mux at runtime (si5351 driver doesn't, but just think about it). Now, for it's own pll clock divider you want CLK_SET_PARENT_RATE while for clk0's pll clock divider you want ~CLK_SET_PARENT_RATE because it will break clk0's output rate. How can you have two sets of flags in the current API? Secondly, it is possible to need flags during __clk_init. This exists today for root clocks that use the CLK_IS_ROOT flag. So setting that flag after registration is too late. Sure, but some others work just fine if you change them during runtime. Finally, how can we make sure that this api is not abused? I'm concerned about drivers which use __clk_set_flags in a hacky way, when in fact the flags are supposed to be permanent properties of that clock. How can you ever make sure, the API is not abused? For the si5351 patch at least, you pointed out not to use clk-private.h and now rejected v5 again. I am asking, if those clock flags are really permanent properties? Not that any current driver uses this, but especially clk muxes are meant to switch to another clock that may have/require different flags. Do you truly need the ability to change clock flags at runtime, or do you instead need a way to express flags in DT? I'm sure the clock bindings are not the first binding to run up against flags or properties that do not strictly match the hardware description. Maybe solving that problem is the right way? Of course, I can parse the flags prior registration and store them in some struct. I was just re-working v4 of si5351 patch and wanted this discussion first. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/12][V2] memcg: make memcg's life cycle the same as cgroup
Changes since v1: - wrote better changelog and added acked-by and reviewed-by tags - revised some comments as suggested by Michal - added a wmb() in kmem_cgroup_css_offline(), pointed out by Michal - fixed a bug which causes a css_put() never be called Now memcg has its own refcnt, so when a cgroup is destroyed, the memcg can still be alive. This patchset converts memcg to always use css_get/put, so memcg will have the same life cycle as its corresponding cgroup. The historical reason that memcg didn't use css_get in some cases, is that cgroup couldn't be removed if there're still css refs. The situation has changed so that rmdir a cgroup will succeed regardless css refs, but won't be freed until css refs goes down to 0. Since the introduction of kmemcg, the memcg refcnt handling grows even more complicated. This patchset greately simplifies memcg's life cycle management. Also, after those changes, we can convert memcg to use cgroup-id, and then we can kill css_id. This patchset is based on linux-next but with memcg: debugging facility to access dangling memcgs. excluded. The first 4 patches are bug fixes that should go into 3.9, and the rest are for 3.10. The extra patch 13/12 is for the dangling memcg debugging patch. You'll see 2 small conflicts when you apply that debugging patch on top of this patchset. Just move memcg_dangling_add() to mem_cgroup_css_offline() and move memcg_dangling_free() to mem_cggroup_css_free(). Li Zefan (10): memcg: take reference before releasing rcu_read_lock memcg: avoid accessing memcg after releasing reference memcg: use css_get() in sock_update_memcg() memcg: don't use mem_cgroup_get() when creating a kmemcg cache memcg: use css_get/put when charging/uncharging kmem memcg: use css_get/put for swap memcg cgroup: make sure parent won't be destroyed before its children memcg: don't need to get a reference to the parent memcg: kill memcg refcnt memcg: don't need to free memcg via RCU or workqueue Michal Hocko (2): Revert memcg: avoid dangling reference count in creation failure. memcg, kmem: fix reference count handling on the error path --- kernel/cgroup.c | 10 +++ mm/memcontrol.c | 267 -- 2 files changed, 116 insertions(+), 161 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: module: strncpy issue, using strlcpy instead of strncpy
Chen Gang gang.c...@asianux.com writes:
ownername and namebuf are all NUL terminated string.
need always let them ended by '\0'.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
kernel/module.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 3c2c72d..597efd8 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1283,7 +1283,7 @@ static const struct kernel_symbol
*resolve_symbol(struct module *mod,
getname:
/* We must make copy under the lock if we failed to get ref. */
- strncpy(ownername, module_name(owner), MODULE_NAME_LEN);
+ strlcpy(ownername, module_name(owner), MODULE_NAME_LEN);
This should just be strcpy().
unlock:
mutex_unlock(module_mutex);
return sym;
@@ -3464,7 +3464,7 @@ const char *module_address_lookup(unsigned long addr,
}
/* Make a copy in here where it's safe */
if (ret) {
- strncpy(namebuf, ret, KSYM_NAME_LEN - 1);
+ strlcpy(namebuf, ret, KSYM_NAME_LEN);
This isn't a bug, because the caller (kallsyms_lookup) puts a NUL in
ret[KSYM_NAME_LEN].
However, kallsyms_lookup also calls kallsyms_expand_symbol, which
doesn't stop at KSYM_NAME_LEN, so if a name was longer than that we'd
have a real bug.
Would you like to take a look at that, too?
Thanks,
Rusty.
--
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/12] memcg: take reference before releasing rcu_read_lock
The memcg is not referenced, so it can be destroyed at anytime right
after we exit rcu read section, so it's not safe to access it.
To fix this, we call css_tryget() to get a reference while we're still
in rcu read section.
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Glauber Costa glom...@parallels.com
Acked-by: Michal Hocko mho...@suse.cz
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 63 ++---
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index d280016..e054ac0 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3460,7 +3460,6 @@ static void memcg_create_cache_work_func(struct
work_struct *w)
/*
* Enqueue the creation of a per-memcg kmem_cache.
- * Called with rcu_read_lock.
*/
static void __memcg_create_cache_enqueue(struct mem_cgroup *memcg,
struct kmem_cache *cachep)
@@ -3468,12 +3467,8 @@ static void __memcg_create_cache_enqueue(struct
mem_cgroup *memcg,
struct create_work *cw;
cw = kmalloc(sizeof(struct create_work), GFP_NOWAIT);
- if (cw == NULL)
- return;
-
- /* The corresponding put will be done in the workqueue. */
- if (!css_tryget(memcg-css)) {
- kfree(cw);
+ if (cw == NULL) {
+ css_put(memcg-css);
return;
}
@@ -3529,10 +3524,9 @@ struct kmem_cache *__memcg_kmem_get_cache(struct
kmem_cache *cachep,
rcu_read_lock();
memcg = mem_cgroup_from_task(rcu_dereference(current-mm-owner));
- rcu_read_unlock();
if (!memcg_can_account_kmem(memcg))
- return cachep;
+ goto out;
idx = memcg_cache_id(memcg);
@@ -3541,29 +3535,38 @@ struct kmem_cache *__memcg_kmem_get_cache(struct
kmem_cache *cachep,
* code updating memcg_caches will issue a write barrier to match this.
*/
read_barrier_depends();
- if (unlikely(cachep-memcg_params-memcg_caches[idx] == NULL)) {
- /*
-* If we are in a safe context (can wait, and not in interrupt
-* context), we could be be predictable and return right away.
-* This would guarantee that the allocation being performed
-* already belongs in the new cache.
-*
-* However, there are some clashes that can arrive from locking.
-* For instance, because we acquire the slab_mutex while doing
-* kmem_cache_dup, this means no further allocation could happen
-* with the slab_mutex held.
-*
-* Also, because cache creation issue get_online_cpus(), this
-* creates a lock chain: memcg_slab_mutex - cpu_hotplug_mutex,
-* that ends up reversed during cpu hotplug. (cpuset allocates
-* a bunch of GFP_KERNEL memory during cpuup). Due to all that,
-* better to defer everything.
-*/
- memcg_create_cache_enqueue(memcg, cachep);
- return cachep;
+ if (likely(cachep-memcg_params-memcg_caches[idx])) {
+ cachep = cachep-memcg_params-memcg_caches[idx];
+ goto out;
}
- return cachep-memcg_params-memcg_caches[idx];
+ /* The corresponding put will be done in the workqueue. */
+ if (!css_tryget(memcg-css))
+ goto out;
+ rcu_read_unlock();
+
+ /*
+* If we are in a safe context (can wait, and not in interrupt
+* context), we could be be predictable and return right away.
+* This would guarantee that the allocation being performed
+* already belongs in the new cache.
+*
+* However, there are some clashes that can arrive from locking.
+* For instance, because we acquire the slab_mutex while doing
+* kmem_cache_dup, this means no further allocation could happen
+* with the slab_mutex held.
+*
+* Also, because cache creation issue get_online_cpus(), this
+* creates a lock chain: memcg_slab_mutex - cpu_hotplug_mutex,
+* that ends up reversed during cpu hotplug. (cpuset allocates
+* a bunch of GFP_KERNEL memory during cpuup). Due to all that,
+* better to defer everything.
+*/
+ memcg_create_cache_enqueue(memcg, cachep);
+ return cachep;
+out:
+ rcu_read_unlock();
+ return cachep;
}
EXPORT_SYMBOL(__memcg_kmem_get_cache);
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/12] memcg: avoid accessing memcg after releasing reference
This might cause use-after-free bug. Signed-off-by: Li Zefan lize...@huawei.com Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Acked-by: Michal Hocko mho...@suse.cz --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index e054ac0..2364f4e 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -3192,12 +3192,12 @@ void memcg_release_cache(struct kmem_cache *s) root = s-memcg_params-root_cache; root-memcg_params-memcg_caches[id] = NULL; - mem_cgroup_put(memcg); mutex_lock(memcg-slab_caches_mutex); list_del(s-memcg_params-list); mutex_unlock(memcg-slab_caches_mutex); + mem_cgroup_put(memcg); out: kfree(s-memcg_params); } -- 1.8.0.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/12] Revert memcg: avoid dangling reference count in creation failure.
From: Michal Hocko mho...@suse.cz This reverts commit e4715f01be697a3730c78f8b595591d6a88c mem_cgroup_put is hierarchy aware so mem_cgroup_put(memcg) already drops an additional reference from all parents so the additional mem_cgrroup_put(parent) potentially causes use-after-free. Signed-off-by: Li Zefan lize...@huawei.com Signed-off-by: Michal Hocko mho...@suse.cz --- mm/memcontrol.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 2364f4e..44cec72 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6250,8 +6250,6 @@ mem_cgroup_css_online(struct cgroup *cont) * call __mem_cgroup_free, so return directly */ mem_cgroup_put(memcg); - if (parent-use_hierarchy) - mem_cgroup_put(parent); } return error; } -- 1.8.0.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/12] memcg, kmem: fix reference count handling on the error path
From: Michal Hocko mho...@suse.cz
mem_cgroup_css_online calls mem_cgroup_put if memcg_init_kmem
fails. This is not correct because only memcg_propagate_kmem takes an
additional reference while mem_cgroup_sockets_init is allowed to fail as
well (although no current implementation fails) but it doesn't take any
reference. This all suggests that it should be memcg_propagate_kmem that
should clean up after itself so this patch moves mem_cgroup_put over
there.
Unfortunately this is not that easy (as pointed out by Li Zefan) because
memcg_kmem_mark_dead marks the group dead (KMEM_ACCOUNTED_DEAD) if it
is marked active (KMEM_ACCOUNTED_ACTIVE) which is the case even if
memcg_propagate_kmem fails so the additional reference is dropped in
that case in kmem_cgroup_destroy which means that the reference would be
dropped two times.
The easiest way then would be to simply remove mem_cgrroup_put from
mem_cgroup_css_online and rely on kmem_cgroup_destroy doing the right
thing.
Signed-off-by: Li Zefan lize...@huawei.com
Signed-off-by: Michal Hocko mho...@suse.cz
Cc: sta...@vger.kernel.org # 3.8.x
---
mm/memcontrol.c | 8
1 file changed, 8 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 44cec72..e65eaac 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6243,14 +6243,6 @@ mem_cgroup_css_online(struct cgroup *cont)
error = memcg_init_kmem(memcg, mem_cgroup_subsys);
mutex_unlock(memcg_create_mutex);
- if (error) {
- /*
-* We call put now because our (and parent's) refcnts
-* are already in place. mem_cgroup_put() will internally
-* call __mem_cgroup_free, so return directly
-*/
- mem_cgroup_put(memcg);
- }
return error;
}
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/12] memcg: use css_get() in sock_update_memcg()
Use css_get/css_put instead of mem_cgroup_get/put.
Note, if at the same time someone is moving @current to a different
cgroup and removing the old cgroup, css_tryget() may return false,
and sock-sk_cgrp won't be initialized, which is fine.
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Acked-by: Michal Hocko mho...@suse.cz
---
mm/memcontrol.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index e65eaac..bbf5bf3 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -536,15 +536,15 @@ void sock_update_memcg(struct sock *sk)
*/
if (sk-sk_cgrp) {
BUG_ON(mem_cgroup_is_root(sk-sk_cgrp-memcg));
- mem_cgroup_get(sk-sk_cgrp-memcg);
+ css_get(sk-sk_cgrp-memcg-css);
return;
}
rcu_read_lock();
memcg = mem_cgroup_from_task(current);
cg_proto = sk-sk_prot-proto_cgroup(memcg);
- if (!mem_cgroup_is_root(memcg) memcg_proto_active(cg_proto))
{
- mem_cgroup_get(memcg);
+ if (!mem_cgroup_is_root(memcg)
+ memcg_proto_active(cg_proto) css_tryget(memcg-css)) {
sk-sk_cgrp = cg_proto;
}
rcu_read_unlock();
@@ -558,7 +558,7 @@ void sock_release_memcg(struct sock *sk)
struct mem_cgroup *memcg;
WARN_ON(!sk-sk_cgrp-memcg);
memcg = sk-sk_cgrp-memcg;
- mem_cgroup_put(memcg);
+ css_put(sk-sk_cgrp-memcg-css);
}
}
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/12] memcg: don't use mem_cgroup_get() when creating a kmemcg cache
Use css_get()/css_put() instead of mem_cgroup_get()/mem_cgroup_put().
There are two things being done in the current code:
First, we acquired a css_ref to make sure that the underlying cgroup
would not go away. That is a short lived reference, and it is put as
soon as the cache is created.
At this point, we acquire a long-lived per-cache memcg reference count
to guarantee that the memcg will still be alive.
so it is:
enqueue: css_get
create : memcg_get, css_put
destroy: memcg_put
So we only need to get rid of the memcg_get, change the memcg_put to
css_put, and get rid of the now extra css_put.
(This changelog is basically written by Glauber)
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Michal Hocko mho...@suse.cz
---
mm/memcontrol.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index bbf5bf3..c308ea0 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3197,7 +3197,7 @@ void memcg_release_cache(struct kmem_cache *s)
list_del(s-memcg_params-list);
mutex_unlock(memcg-slab_caches_mutex);
- mem_cgroup_put(memcg);
+ css_put(memcg-css);
out:
kfree(s-memcg_params);
}
@@ -3356,16 +3356,18 @@ static struct kmem_cache
*memcg_create_kmem_cache(struct mem_cgroup *memcg,
mutex_lock(memcg_cache_mutex);
new_cachep = cachep-memcg_params-memcg_caches[idx];
- if (new_cachep)
+ if (new_cachep) {
+ css_put(memcg-css);
goto out;
+ }
new_cachep = kmem_cache_dup(memcg, cachep);
if (new_cachep == NULL) {
new_cachep = cachep;
+ css_put(memcg-css);
goto out;
}
- mem_cgroup_get(memcg);
atomic_set(new_cachep-memcg_params-nr_pages , 0);
cachep-memcg_params-memcg_caches[idx] = new_cachep;
@@ -3453,8 +3455,6 @@ static void memcg_create_cache_work_func(struct
work_struct *w)
cw = container_of(w, struct create_work, work);
memcg_create_kmem_cache(cw-memcg, cw-cachep);
- /* Drop the reference gotten when we enqueued. */
- css_put(cw-memcg-css);
kfree(cw);
}
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/12] memcg: use css_get/put when charging/uncharging kmem
Use css_get/put instead of mem_cgroup_get/put.
We can't do a simple replacement, because here mem_cgroup_put()
is called during mem_cgroup_css_free(), while mem_cgroup_css_free()
won't be called until css refcnt goes down to 0.
Instead we increment css refcnt in mem_cgroup_css_offline(), and
then check if there's still kmem charges. If not, css refcnt will
be decremented immediately, otherwise the refcnt won't be decremented
when kmem charges goes down to 0.
v2:
- added wmb() in kmem_cgroup_css_offline(), pointed out by Michal
- revised comments as suggested by Michal
- fixed to check if kmem is activated in kmem_cgroup_css_offline()
Signed-off-by: Li Zefan lize...@huawei.com
---
mm/memcontrol.c | 66 +++--
1 file changed, 41 insertions(+), 25 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index c308ea0..7be796c 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3003,8 +3003,16 @@ static void memcg_uncharge_kmem(struct mem_cgroup
*memcg, u64 size)
if (res_counter_uncharge(memcg-kmem, size))
return;
+ /*
+* Releases a reference taken in kmem_cgroup_css_offline in case
+* this last uncharge is racing with the offlining code or it is
+* outliving the memcg existence.
+*
+* The memory barrier imposed by testclear is paired with the
+* explicit one in kmem_cgroup_css_offline.
+*/
if (memcg_kmem_test_and_clear_dead(memcg))
- mem_cgroup_put(memcg);
+ css_put(memcg-css);
}
void memcg_cache_list_add(struct mem_cgroup *memcg, struct kmem_cache *cachep)
@@ -5090,14 +5098,6 @@ static int memcg_update_kmem_limit(struct cgroup *cont,
u64 val)
* starts accounting before all call sites are patched
*/
memcg_kmem_set_active(memcg);
-
- /*
-* kmem charges can outlive the cgroup. In the case of slab
-* pages, for instance, a page contain objects from various
-* processes, so it is unfeasible to migrate them away. We
-* need to reference count the memcg because of that.
-*/
- mem_cgroup_get(memcg);
} else
ret = res_counter_set_limit(memcg-kmem, val);
out:
@@ -5130,12 +5130,10 @@ static int memcg_propagate_kmem(struct mem_cgroup
*memcg)
goto out;
/*
-* destroy(), called if we fail, will issue static_key_slow_inc() and
-* mem_cgroup_put() if kmem is enabled. We have to either call them
-* unconditionally, or clear the KMEM_ACTIVE flag. I personally find
-* this more consistent, since it always leads to the same destroy path
+* __mem_cgroup_free() will issue static_key_slow_dec() because this
+* memcg is active already. If the later initialization fails then the
+* cgroup core triggers the cleanup so we do not have to do it here.
*/
- mem_cgroup_get(memcg);
static_key_slow_inc(memcg_kmem_enabled_key);
mutex_lock(set_limit_mutex);
@@ -5818,23 +5816,39 @@ static int memcg_init_kmem(struct mem_cgroup *memcg,
struct cgroup_subsys *ss)
return mem_cgroup_sockets_init(memcg, ss);
};
-static void kmem_cgroup_destroy(struct mem_cgroup *memcg)
+static void kmem_cgroup_css_offline(struct mem_cgroup *memcg)
{
- mem_cgroup_sockets_destroy(memcg);
+ if (!memcg_kmem_is_active(memcg))
+ return;
+ /*
+* kmem charges can outlive the cgroup. In the case of slab
+* pages, for instance, a page contain objects from various
+* processes. As we prevent from taking a reference for every
+* such allocation we have to be careful when doing uncharge
+* (see memcg_uncharge_kmem) and here during offlining.
+*
+* The idea is that that only the _last_ uncharge which sees
+* the dead memcg will drop the last reference. An additional
+* reference is taken here before the group is marked dead
+* which is then paired with css_put during uncharge resp. here.
+*
+* Although this might sound strange as this path is called when
+* the reference has already dropped down to 0 and shouldn't be
+* incremented anymore (css_tryget would fail) we do not have
+* other options because of the kmem allocations lifetime.
+*/
+ css_get(memcg-css);
+
+ /* see comment in memcg_uncharge_kmem() */
+ wmb();
memcg_kmem_mark_dead(memcg);
if (res_counter_read_u64(memcg-kmem, RES_USAGE) != 0)
return;
- /*
-* Charges already down to 0, undo mem_cgroup_get() done in the charge
-* path here, being careful not to race with memcg_uncharge_kmem: it is
-* possible that the charges went down to 0 between mark_dead and the
-* res_counter
[PATCH 08/12] memcg: use css_get/put for swap memcg
Use css_get/put instead of mem_cgroup_get/put. A simple replacement
will do.
The historical reason that memcg has its own refcnt instead of always
using css_get/put, is that cgroup couldn't be removed if there're still
css refs, so css refs can't be used as long-lived reference. The
situation has changed so that rmdir a cgroup will succeed regardless
css refs, but won't be freed until css refs goes down to 0.
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Michal Hocko mho...@suse.cz
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7be796c..7fdd69d 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4149,12 +4149,12 @@ __mem_cgroup_uncharge_common(struct page *page, enum
charge_type ctype,
unlock_page_cgroup(pc);
/*
* even after unlock, we have memcg-res.usage here and this memcg
-* will never be freed.
+* will never be freed, so it's safe to call css_get().
*/
memcg_check_events(memcg, page);
if (do_swap_account ctype == MEM_CGROUP_CHARGE_TYPE_SWAPOUT) {
mem_cgroup_swap_statistics(memcg, true);
- mem_cgroup_get(memcg);
+ css_get(memcg-css);
}
/*
* Migration does not charge the res_counter for the
@@ -4254,7 +4254,7 @@ mem_cgroup_uncharge_swapcache(struct page *page,
swp_entry_t ent, bool swapout)
/*
* record memcg information, if swapout memcg != NULL,
-* mem_cgroup_get() was called in uncharge().
+* css_get() was called in uncharge().
*/
if (do_swap_account swapout memcg)
swap_cgroup_record(ent, css_id(memcg-css));
@@ -4285,7 +4285,7 @@ void mem_cgroup_uncharge_swap(swp_entry_t ent)
if (!mem_cgroup_is_root(memcg))
res_counter_uncharge(memcg-memsw, PAGE_SIZE);
mem_cgroup_swap_statistics(memcg, false);
- mem_cgroup_put(memcg);
+ css_put(memcg-css);
}
rcu_read_unlock();
}
@@ -4319,11 +4319,14 @@ static int mem_cgroup_move_swap_account(swp_entry_t
entry,
* This function is only called from task migration context now.
* It postpones res_counter and refcount handling till the end
* of task migration(mem_cgroup_clear_mc()) for performance
-* improvement. But we cannot postpone mem_cgroup_get(to)
-* because if the process that has been moved to @to does
-* swap-in, the refcount of @to might be decreased to 0.
+* improvement. But we cannot postpone css_get(to) because if
+* the process that has been moved to @to does swap-in, the
+* refcount of @to might be decreased to 0.
+*
+* We are in attach() phase, so the cgroup is guaranteed to be
+* alive, so we can just call css_get().
*/
- mem_cgroup_get(to);
+ css_get(to-css);
return 0;
}
return -EINVAL;
@@ -6604,6 +6607,7 @@ static void __mem_cgroup_clear_mc(void)
{
struct mem_cgroup *from = mc.from;
struct mem_cgroup *to = mc.to;
+ int i;
/* we must uncharge all the leftover precharges from mc.to */
if (mc.precharge) {
@@ -6624,7 +6628,9 @@ static void __mem_cgroup_clear_mc(void)
if (!mem_cgroup_is_root(mc.from))
res_counter_uncharge(mc.from-memsw,
PAGE_SIZE * mc.moved_swap);
- __mem_cgroup_put(mc.from, mc.moved_swap);
+
+ for (i = 0; i mc.moved_swap; i++)
+ css_put(mc.from-css);
if (!mem_cgroup_is_root(mc.to)) {
/*
@@ -6634,7 +6640,7 @@ static void __mem_cgroup_clear_mc(void)
res_counter_uncharge(mc.to-res,
PAGE_SIZE * mc.moved_swap);
}
- /* we've already done mem_cgroup_get(mc.to) */
+ /* we've already done css_get(mc.to) */
mc.moved_swap = 0;
}
memcg_oom_recover(from);
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/12] cgroup: make sure parent won't be destroyed before its children
Suppose we rmdir a cgroup and there're still css refs, this cgroup won't
be freed. Then we rmdir the parent cgroup, and the parent is freed
immediately due to css ref draining to 0. Now it would be a disaster if
the still-alive child cgroup tries to access its parent.
Make sure this won't happen.
Signed-off-by: Li Zefan lize...@huawei.com
Reviewed-by: Michal Hocko mho...@suse.cz
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
kernel/cgroup.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 06aeb42..7ee3bdf 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -888,6 +888,13 @@ static void cgroup_free_fn(struct work_struct *work)
mutex_unlock(cgroup_mutex);
/*
+* We get a ref to the parent's dentry, and put the ref when
+* this cgroup is being freed, so it's guaranteed that the
+* parent won't be destroyed before its children.
+*/
+ dput(cgrp-parent-dentry);
+
+ /*
* Drop the active superblock reference that we took when we
* created the cgroup
*/
@@ -4170,6 +4177,9 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
for_each_subsys(root, ss)
dget(dentry);
+ /* hold a ref to the parent's dentry */
+ dget(parent-dentry);
+
/* creation succeeded, notify subsystems */
for_each_subsys(root, ss) {
err = online_css(ss, cgrp);
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/12] memcg: don't need to get a reference to the parent
The cgroup core guarantees it's always safe to access the parent.
v2:
- added a comment in mem_cgroup_put() as suggested by Michal
- removed mem_cgroup_get(), otherwise gcc will warn that it's not used
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Michal Hocko mho...@suse.cz
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7fdd69d..9ca5a99 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -501,7 +501,6 @@ enum res_type {
*/
static DEFINE_MUTEX(memcg_create_mutex);
-static void mem_cgroup_get(struct mem_cgroup *memcg);
static void mem_cgroup_put(struct mem_cgroup *memcg);
static inline
@@ -6125,19 +6124,10 @@ static void free_rcu(struct rcu_head *rcu_head)
schedule_work(memcg-work_freeing);
}
-static void mem_cgroup_get(struct mem_cgroup *memcg)
-{
- atomic_inc(memcg-refcnt);
-}
-
static void __mem_cgroup_put(struct mem_cgroup *memcg, int count)
{
- if (atomic_sub_and_test(count, memcg-refcnt)) {
- struct mem_cgroup *parent = parent_mem_cgroup(memcg);
+ if (atomic_sub_and_test(count, memcg-refcnt))
call_rcu(memcg-rcu_freeing, free_rcu);
- if (parent)
- mem_cgroup_put(parent);
- }
}
static void mem_cgroup_put(struct mem_cgroup *memcg)
@@ -6239,12 +6229,9 @@ mem_cgroup_css_online(struct cgroup *cont)
res_counter_init(memcg-kmem, parent-kmem);
/*
-* We increment refcnt of the parent to ensure that we can
-* safely access it on res_counter_charge/uncharge.
-* This refcnt will be decremented when freeing this
-* mem_cgroup(see mem_cgroup_put).
+* No need to take a reference to the parent because cgroup
+* core guarantees its existence.
*/
- mem_cgroup_get(parent);
} else {
res_counter_init(memcg-res, NULL);
res_counter_init(memcg-memsw, NULL);
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/12] memcg: kill memcg refcnt
Now memcg has the same life cycle as its corresponding cgroup.
Kill the useless refcnt.
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Michal Hocko mho...@suse.cz
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 9ca5a99..a6d44bc 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -297,8 +297,6 @@ struct mem_cgroup {
booloom_lock;
atomic_tunder_oom;
- atomic_trefcnt;
-
int swappiness;
/* OOM-Killer disable */
int oom_kill_disable;
@@ -501,8 +499,6 @@ enum res_type {
*/
static DEFINE_MUTEX(memcg_create_mutex);
-static void mem_cgroup_put(struct mem_cgroup *memcg);
-
static inline
struct mem_cgroup *mem_cgroup_from_css(struct cgroup_subsys_state *s)
{
@@ -6124,17 +6120,6 @@ static void free_rcu(struct rcu_head *rcu_head)
schedule_work(memcg-work_freeing);
}
-static void __mem_cgroup_put(struct mem_cgroup *memcg, int count)
-{
- if (atomic_sub_and_test(count, memcg-refcnt))
- call_rcu(memcg-rcu_freeing, free_rcu);
-}
-
-static void mem_cgroup_put(struct mem_cgroup *memcg)
-{
- __mem_cgroup_put(memcg, 1);
-}
-
/*
* Returns the parent mem_cgroup in memcgroup hierarchy with hierarchy enabled.
*/
@@ -6194,7 +6179,6 @@ mem_cgroup_css_alloc(struct cgroup *cont)
memcg-last_scanned_node = MAX_NUMNODES;
INIT_LIST_HEAD(memcg-oom_notify);
- atomic_set(memcg-refcnt, 1);
memcg-move_charge_at_immigrate = 0;
mutex_init(memcg-thresholds_lock);
spin_lock_init(memcg-move_lock);
@@ -6285,7 +6269,7 @@ static void mem_cgroup_css_free(struct cgroup *cont)
mem_cgroup_sockets_destroy(memcg);
- mem_cgroup_put(memcg);
+ call_rcu(memcg-rcu_freeing, free_rcu);
}
#ifdef CONFIG_MMU
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/12] memcg: don't need memcg-memcg_name
Now memcg has the same life cycle as its corresponding cgroup,
we don't have to save the cgroup path name in memcg-memcg_name.
Signed-off-by: Li Zefan lize...@huawei.com
---
mm/memcontrol.c | 65 +
1 file changed, 24 insertions(+), 41 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index aeab1d3..06e995e 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -306,20 +306,12 @@ struct mem_cgroup {
struct list_head dead;
};
- union {
- /*
-* Should we move charges of a task when a task is moved into
-* this mem_cgroup ? And what type of charges should we move ?
-*/
- unsigned long move_charge_at_immigrate;
+ /*
+* Should we move charges of a task when a task is moved into
+* this mem_cgroup ? And what type of charges should we move ?
+*/
+ unsigned long move_charge_at_immigrate;
- /*
-* We are no longer concerned about moving charges after memcg
-* is dead. So we will fill this up with its name, to aid
-* debugging.
-*/
- char *memcg_name;
- };
/*
* set 0 if pages under this cgroup are moving to other cgroup.
*/
@@ -381,36 +373,10 @@ static inline void memcg_dangling_free(struct mem_cgroup
*memcg)
mutex_lock(dangling_memcgs_mutex);
list_del(memcg-dead);
mutex_unlock(dangling_memcgs_mutex);
- free_pages((unsigned long)memcg-memcg_name, 0);
}
static inline void memcg_dangling_add(struct mem_cgroup *memcg)
{
- /*
-* cgroup.c will do page-sized allocations most of the time,
-* so we'll just follow the pattern. Also, __get_free_pages
-* is a better interface than kmalloc for us here, because
-* we'd like this memory to be always billed to the root cgroup,
-* not to the process removing the memcg. While kmalloc would
-* require us to wrap it into memcg_stop/resume_kmem_account,
-* with __get_free_pages we just don't pass the memcg flag.
-*/
- memcg-memcg_name = (char *)__get_free_pages(GFP_KERNEL, 0);
-
- /*
-* we will, in general, just ignore failures. No need to go crazy,
-* being this just a debugging interface. It is nice to copy a memcg
-* name over, but if we (unlikely) can't, just the address will do
-*/
- if (!memcg-memcg_name)
- goto add_list;
-
- if (cgroup_path(memcg-css.cgroup, memcg-memcg_name, PAGE_SIZE) 0) {
- free_pages((unsigned long)memcg-memcg_name, 0);
- memcg-memcg_name = NULL;
- }
-
-add_list:
INIT_LIST_HEAD(memcg-dead);
mutex_lock(dangling_memcgs_mutex);
list_add(memcg-dead, dangling_memcgs);
@@ -5188,12 +5154,28 @@ static int mem_cgroup_dangling_read(struct cgroup
*cont, struct cftype *cft,
struct seq_file *m)
{
struct mem_cgroup *memcg;
+ char *memcg_name;
+ int ret;
+
+ /*
+* cgroup.c will do page-sized allocations most of the time,
+* so we'll just follow the pattern. Also, __get_free_pages
+* is a better interface than kmalloc for us here, because
+* we'd like this memory to be always billed to the root cgroup,
+* not to the process removing the memcg. While kmalloc would
+* require us to wrap it into memcg_stop/resume_kmem_account,
+* with __get_free_pages we just don't pass the memcg flag.
+*/
+ memcg_name = (char *)__get_free_pages(GFP_KERNEL, 0);
+ if (!memcg_name)
+ return -ENOMEM;
mutex_lock(dangling_memcgs_mutex);
list_for_each_entry(memcg, dangling_memcgs, dead) {
- if (memcg-memcg_name)
- seq_printf(m, %s:\n, memcg-memcg_name);
+ ret = cgroup_path(memcg-css.cgroup, memcg_name, PAGE_SIZE);
+ if (!ret)
+ seq_printf(m, %s:\n, memcg_name);
else
seq_printf(m, %p (name lost):\n, memcg);
@@ -5203,6 +5185,7 @@ static int mem_cgroup_dangling_read(struct cgroup *cont,
struct cftype *cft,
}
mutex_unlock(dangling_memcgs_mutex);
+ free_pages((unsigned long)memcg_name, 0);
return 0;
}
#endif
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/12] memcg: don't need to free memcg via RCU or workqueue
Now memcg has the same life cycle with its corresponding cgroup, and
a cgroup is freed via RCU and then mem_cgroup_css_free() is called
in a work function, so we can simply call __mem_cgroup_free() in
mem_cgroup_css_free().
This actually reverts 59927fb984de1703c67bc640c3e522d8b5276c73
(memcg: free mem_cgroup by RCU to fix oops).
Cc: Hugh Dickins hu...@google.com
Signed-off-by: Li Zefan lize...@huawei.com
---
mm/memcontrol.c | 51 +--
1 file changed, 5 insertions(+), 46 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index a6d44bc..5aa6e91 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -261,28 +261,10 @@ struct mem_cgroup {
*/
struct res_counter res;
- union {
- /*
-* the counter to account for mem+swap usage.
-*/
- struct res_counter memsw;
-
- /*
-* rcu_freeing is used only when freeing struct mem_cgroup,
-* so put it into a union to avoid wasting more memory.
-* It must be disjoint from the css field. It could be
-* in a union with the res field, but res plays a much
-* larger part in mem_cgroup life than memsw, and might
-* be of interest, even at time of free, when debugging.
-* So share rcu_head with the less interesting memsw.
-*/
- struct rcu_head rcu_freeing;
- /*
-* We also need some space for a worker in deferred freeing.
-* By the time we call it, rcu_freeing is no longer in use.
-*/
- struct work_struct work_freeing;
- };
+ /*
+* the counter to account for mem+swap usage.
+*/
+ struct res_counter memsw;
/*
* the counter to account for kernel memory usage.
@@ -6097,29 +6079,6 @@ static void __mem_cgroup_free(struct mem_cgroup *memcg)
vfree(memcg);
}
-
-/*
- * Helpers for freeing a kmalloc()ed/vzalloc()ed mem_cgroup by RCU,
- * but in process context. The work_freeing structure is overlaid
- * on the rcu_freeing structure, which itself is overlaid on memsw.
- */
-static void free_work(struct work_struct *work)
-{
- struct mem_cgroup *memcg;
-
- memcg = container_of(work, struct mem_cgroup, work_freeing);
- __mem_cgroup_free(memcg);
-}
-
-static void free_rcu(struct rcu_head *rcu_head)
-{
- struct mem_cgroup *memcg;
-
- memcg = container_of(rcu_head, struct mem_cgroup, rcu_freeing);
- INIT_WORK(memcg-work_freeing, free_work);
- schedule_work(memcg-work_freeing);
-}
-
/*
* Returns the parent mem_cgroup in memcgroup hierarchy with hierarchy enabled.
*/
@@ -6269,7 +6228,7 @@ static void mem_cgroup_css_free(struct cgroup *cont)
mem_cgroup_sockets_destroy(memcg);
- call_rcu(memcg-rcu_freeing, free_rcu);
+ __mem_cgroup_free(memcg);
}
#ifdef CONFIG_MMU
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH resend] sched: Fix sd-*_idx limit range avoiding overflow
Commit 201c373e8e (sched/debug: Limit sd-*_idx range on sysctl) was an incomplete bug fix. This patch fixs sd-*_idx limit range to [0 ~ CPU_LOAD_IDX_MAX - 1] avioding array overflow caused by setting sd-*_idx to CPU_LOAD_IDX_MAX on sysctl. Signed-off-by: Libin huawei.li...@huawei.com --- kernel/sched/core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 7f12624..ba89ada 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4999,7 +4999,7 @@ static void sd_free_ctl_entry(struct ctl_table **tablep) } static int min_load_idx = 0; -static int max_load_idx = CPU_LOAD_IDX_MAX; +static int max_load_idx = CPU_LOAD_IDX_MAX - 1; static void set_table_entry(struct ctl_table *entry, -- 1.6.0.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AVR32: fix building warnings caused by redifinitions of HZ
Around Sun 07 Apr 2013 23:29:17 +0800 or thereabout, Jiang Liu wrote: On 04/07/2013 03:55 PM, Hans-Christian Egtvedt wrote: Around Sun 07 Apr 2013 00:43:36 +0800 or thereabout, Jiang Liu wrote: Fix building warnings caused by redifinitions of HZ: snipp warning Thanks for fixing. Signed-off-by: Jiang Liu jiang@huawei.com Cc: Haavard Skinnemoen hskinnem...@gmail.com Cc: Hans-Christian Egtvedt egtv...@samfundet.no Cc: linux-kernel@vger.kernel.org Acked-by: Hans-Christian Egtvedt egtv...@samfundet.no --- arch/avr32/include/uapi/asm/param.h |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/avr32/include/uapi/asm/param.h b/arch/avr32/include/uapi/asm/param.h index d28aa5e..abda103 100644 --- a/arch/avr32/include/uapi/asm/param.h +++ b/arch/avr32/include/uapi/asm/param.h @@ -2,7 +2,11 @@ #define _UAPI__ASM_AVR32_PARAM_H -#ifndef HZ +#ifndef __KERNEL__ + /* +* Technically, this is wrong, but some old apps still refer to it. +* The proper way to get the HZ value is via sysconf(_SC_CLK_TCK). +*/ With this comment, are there AVR32 drivers/users that should be fixed? Or is it parts of the tree in general? Hi Hans, It's copied from arch/ia64/include/uapi/asm/param.h, I feel it should be the same for AVR32 too. Most likely yes, the original param.h header file was added by David Howells from RedHat, and has never been touched since. Again, thanks for fixing. -- mvh Hans-Christian Egtvedt -- 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] at24: extend driver to allow writing via i2c_smbus_write_byte_data
Using the new mail address of wolfram sang - got the following error:
Delivery to the following recipient failed permanently:
w.s...@pengutronix.de
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
server for the recipient domainpengutronix.de by mail.pengutronix.de.
[2001:6f8:1178:4:290:27ff:fe1d:cc33].
The error that the other server returned was:
550 Account closed - please contact i...@pengutronix.de instead
2013/3/27 Christian Gmeiner christian.gmei...@gmail.com:
2013/1/24 Wolfram Sang w.s...@pengutronix.de:
On Wed, Dec 19, 2012 at 05:07:09PM +0100, Christian Gmeiner wrote:
I have a at24 EEPROM connected via i2c bus provided by ISCH i2c
bus driver. This bus driver does not support
I2C_FUNC_SMBUS_WRITE_I2C_BLOCK and so I was looking for a way
to be able to write the eeprom. This patch adds support for
I2C_SMBUS_BYTE_DATA writing via i2c_smbus_write_byte_data.
It is quite slow, but it works.
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
drivers/misc/eeprom/at24.c | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 2baeec5..723b411 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -56,6 +56,7 @@ struct at24_data {
struct at24_platform_data chip;
struct memory_accessor macc;
int use_smbus;
+ int use_smbuse_write;
Can't you use the same 'use_smbus' variable and do a similar switch-case
as in the read function?
Sorry for the really late answer.
I am not sure if there exits some i2c buses which have different
access methods for read and write.
E.g. I2C_FUNC_SMBUS_WRITE_I2C_BLOCK and I2C_FUNC_SMBUS_READ_BYTE_DATA
If there will never be such a combination then I can reuse the same
'use_smbus' variable.
--
Christian Gmeiner, MSc
--
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 akpm tree with the scsi tree
Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in drivers/scsi/qla2xxx/qla_attr.c between commit 4a9fa41bd404 ([SCSI] qla2xxx: Remove debug code that msleeps for random duration) from the scsi tree and commit scsi: rename random32() to prandom_u32() from the akpm tree. The former removed the code in this file that was updated by the latter, so I did that (and dropped the next patch (scsi: fix the wrong position of the comment) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgplLUMwooVok.pgp Description: PGP signature
Re: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic channels
Russell,
On 04/03/2013 01:17 PM, Peter Ujfalusi wrote:
cyclic DMA is only used by audio which needs DMA to be started without a
delay.
If the DMA for audio is started using the tasklet we experience random
channel switch (to be more precise: channel shift).
Reported-by: Peter Meerwald pme...@pmeerw.net
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Russell,
Instead of removing the tasklet we can identify the DMA channel used by audio
based on the cyclic flag of the channel.
I think this can be used as a short term solution to fix the audio channel
shift
issue and later when we have the dynamic DMA channel allocation we can adjust
the code.
Could you, please look at this patch?
Thank you,
Péter
Regards,
Peter
drivers/dma/omap-dma.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 2ea3d7e..ec3fc4f 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan
*chan)
spin_lock_irqsave(c-vc.lock, flags);
if (vchan_issue_pending(c-vc) !c-desc) {
- struct omap_dmadev *d = to_omap_dma_dev(chan-device);
- spin_lock(d-lock);
- if (list_empty(c-node))
- list_add_tail(c-node, d-pending);
- spin_unlock(d-lock);
- tasklet_schedule(d-task);
+ /*
+ * c-cyclic is used only by audio and in this case the DMA need
+ * to be started without delay.
+ */
+ if (!c-cyclic) {
+ struct omap_dmadev *d = to_omap_dma_dev(chan-device);
+ spin_lock(d-lock);
+ if (list_empty(c-node))
+ list_add_tail(c-node, d-pending);
+ spin_unlock(d-lock);
+ tasklet_schedule(d-task);
+ } else {
+ omap_dma_start_desc(c);
+ }
}
spin_unlock_irqrestore(c-vc.lock, flags);
}
--
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] avr32: fix build error in atstk1006_defconfig
Hi, Andrew Could you merge it for avr32? Thanks in advance. Best Regards, Josh Wu On 4/1/2013 2:26 PM, Josh Wu wrote: fixed the following compile error when use avr32 atstk1006_defconfig: drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location': drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function 'writel_relaxed' which was introduced by commit: 1c7b874d33b463f7150b1ab4617f000af9b327fd mtd: at91: atmel_nand: add Programmable Multibit ECC controller support The PMECC for nand flash code uses writel_relaxed(). But in avr32, there is no macro writel_relaxed defined. This patch add writex_relaxed macro definitions. Signed-off-by: Josh Wu josh...@atmel.com Acked-by: Havard Skinnemoen hav...@skinnemoen.net Acked-by: Hans-Christian Egtvedt egtv...@samfundet.no --- change since v1: refined the commit message and wrap it into 80 characters. arch/avr32/include/asm/io.h |4 1 file changed, 4 insertions(+) diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h index cf60d0a..fc6483f 100644 --- a/arch/avr32/include/asm/io.h +++ b/arch/avr32/include/asm/io.h @@ -165,6 +165,10 @@ BUILDIO_IOPORT(l, u32) #define readw_be __raw_readw #define readl_be __raw_readl +#define writeb_relaxed writeb +#define writew_relaxed writew +#define writel_relaxed writel + #define writeb_be __raw_writeb #define writew_be __raw_writew #define writel_be __raw_writel -- 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][PATCH 0/7] memcg: make memcg's life cycle the same as cgroup
On 04/07/2013 12:44 PM, Li Zefan wrote: Hi, I'm rebasing this patchset against latest linux-next, and it conflicts with [PATCH v2] memcg: debugging facility to access dangling memcgs. slightly. That is a debugging patch and will never be pushed into mainline, so should I still base this patchset on that debugging patch? It will conflict as well with my shrinking patches: I will still keep the memcgs in the dangling list, but that will have nothing to do with debugging. So I will split that patch in a list management part, which will be used, and a debugging part (with the file + the debugging information). I will be happy to rebase it ontop of your series. Also that patch needs update (and can be simplified) after this patchset: - move memcg_dangling_add() to mem_cgroup_css_offline() - remove memcg-memcg_name, and use cgroup_path() in mem_cgroup_dangling_read()? Don't worry about it. If this is just this one patch conflicting, I would avise Andrew to remove it, and I will provide another (maybe two, already splitted up) version. -- 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] tty: mxser: fix cycle termination condition in mxser_probe() and mxser_module_init()
On 04/07/2013 09:46 PM, Alexey Khoroshilov wrote:
There is a bug in resources deallocation code in mxser_probe() and
mxser_module_init().
As soon as variable 'i' is unsigned int, cycle termination condition i = 0
is always true.
The patch fixes the issue.
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
Yes, thanks.
Acked-by: Jiri Slaby jsl...@suse.cz
---
drivers/tty/mxser.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 484b6a3..302909c 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -2643,9 +2643,9 @@ static int mxser_probe(struct pci_dev *pdev,
mxvar_sdriver, brd-idx + i, pdev-dev);
if (IS_ERR(tty_dev)) {
retval = PTR_ERR(tty_dev);
- for (i--; i = 0; i--)
+ for (; i 0; i--)
tty_unregister_device(mxvar_sdriver,
- brd-idx + i);
+ brd-idx + i - 1);
goto err_relbrd;
}
}
@@ -2751,9 +2751,9 @@ static int __init mxser_module_init(void)
tty_dev = tty_port_register_device(brd-ports[i].port,
mxvar_sdriver, brd-idx + i, NULL);
if (IS_ERR(tty_dev)) {
- for (i--; i = 0; i--)
+ for (; i 0; i--)
tty_unregister_device(mxvar_sdriver,
- brd-idx + i);
+ brd-idx + i - 1);
for (i = 0; i brd-info-nports; i++)
tty_port_destroy(brd-ports[i].port);
free_irq(brd-irq, brd);
--
js
suse labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] clk: exynos5250: Fix divider values for sclk_mmc{0,1,2,3}
Mike Turquette wrote:
Quoting Tushar Behera (2013-04-02 01:20:40)
In legacy setup, sclk_mmc{0,1,2,3} used PRE_RATIO bit-field (8-bit wide)
instead of RATIO bit-field (4-bit wide) for dividing clock rate.
With current common clock setup, we are using RATIO bit-field which
is creating FIFO read errors while accessing eMMC. Changing over to
use PRE_RATIO bit-field fixes this issue.
dwmmc_exynos 1220.dwmmc0: data FIFO error (status=8020)
mmcblk0: error -5 transferring data, sector 1, nr 7, cmd response 0x900,
card status 0x0
end_request: I/O error, dev mmcblk0, sector 1
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
CC: Thomas Abraham thomas.abra...@linaro.org
I guess this will be applied through the samsung tree, so:
Acked-by: Mike Turquette mturque...@linaro.org
Thanks, applied.
- Kukjin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically
On 04/05/2013 06:16 AM, Yinghai Lu wrote:
Chao said that kdump does does work well on his system on 3.8
without extra parameter, even iommu does not work with kdump.
And now have to append crashkernel_low=Y in first kernel to make
kdump work.
We have now modified crashkernel=X to allocate memory beyong 4G (if
available) and do not allocate low range for crashkernel if the user
does not specify that with crashkernel_low=Y. This causes regression
if iommu is not enabled. Without iommu, swiotlb needs to be setup in
first 4G and there is no low memory available to second kernel.
Is it possible to reuse the 1st kernel swiotlb region in 2nd capture
kernel if it's available?
Set crashkernel_low automatically if the user does not specify that.
For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.
How about make swiotlb size tunable in 1st kernel as well such as adding
a swiotlb_size= to cmdline, if it's set in 1st kernel crashkernel
reserving code can take it automaticlly.
This will benefit to user who use low-mem machines.
-v3: add swiotlb_size() according to Konrad.
-v4: add comments what 8M is for according to hpa.
also update more crashkernel_low= in kernel-parameters.txt
-v5: update changelog according to Vivek.
-v6: Change description about swiotlb referring according to HATAYAMA.
Reported-by: WANG Chao chaow...@redhat.com
Tested-by: WANG Chao chaow...@redhat.com
Signed-off-by: Yinghai Lu ying...@kernel.org
---
Documentation/kernel-parameters.txt | 14 +++---
arch/x86/kernel/setup.c | 20 +---
include/linux/swiotlb.h |1 +
lib/swiotlb.c | 19 +++
4 files changed, 44 insertions(+), 10 deletions(-)
Index: linux-2.6/arch/x86/kernel/setup.c
===
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -519,19 +519,33 @@ static void __init reserve_crashkernel_l
unsigned long long low_base = 0, low_size = 0;
unsigned long total_low_mem;
unsigned long long base;
+ bool auto_set = false;
int ret;
total_low_mem = memblock_mem_size(1UL(32-PAGE_SHIFT));
ret = parse_crashkernel_low(boot_command_line, total_low_mem,
low_size, base);
- if (ret != 0 || low_size = 0)
- return;
+ if (ret != 0) {
+ /*
+ * two parts from lib/swiotlb.c:
+ * swiotlb size: user specified with swiotlb= or default.
+ * swiotlb overflow buffer: now is hardcoded to 32k,
+ * round to 8M to cover more others.
+ */
+ low_size = swiotlb_size_or_default() + (8UL20);
+ auto_set = true;
+ } else {
+ /* passed with crashkernel_low=0 ? */
+ if (!low_size)
+ return;
+ }
low_base = memblock_find_in_range(low_size, (1ULL32),
low_size, alignment);
if (!low_base) {
- pr_info(crashkernel low reservation failed - No suitable area
found.\n);
+ if (!auto_set)
+ pr_info(crashkernel low reservation failed - No
suitable area found.\n);
return;
}
Index: linux-2.6/include/linux/swiotlb.h
===
--- linux-2.6.orig/include/linux/swiotlb.h
+++ linux-2.6/include/linux/swiotlb.h
@@ -25,6 +25,7 @@ extern int swiotlb_force;
extern void swiotlb_init(int verbose);
int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
extern unsigned long swiotlb_nr_tbl(void);
+unsigned long swiotlb_size_or_default(void);
extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
/*
Index: linux-2.6/lib/swiotlb.c
===
--- linux-2.6.orig/lib/swiotlb.c
+++ linux-2.6/lib/swiotlb.c
@@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
if (!strcmp(str, force))
swiotlb_force = 1;
- return 1;
+ return 0;
}
-__setup(swiotlb=, setup_io_tlb_npages);
+early_param(swiotlb, setup_io_tlb_npages);
/* make io_tlb_overflow tunable too? */
unsigned long swiotlb_nr_tbl(void)
@@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
return io_tlb_nslabs;
}
EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
+
+/* default to 64MB */
+#define IO_TLB_DEFAULT_SIZE (64UL20)
+unsigned long swiotlb_size_or_default(void)
+{
+ unsigned long size;
+
+ size = io_tlb_nslabs IO_TLB_SHIFT;
+
+ return size ? size : (IO_TLB_DEFAULT_SIZE);
+}
+
/* Note that this doesn't work with highmem page */
static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
Re: [RFC/PATCH] perf: Expand definition of sysfs format attribute
On Mon, Mar 04, 2013 at 03:21:05PM +1100, Michael Ellerman wrote: Make it explicit that the format attributes may define overlapping bit ranges. Unfortunately this was left unspecified originally, and all the examples show non-overlapping ranges. I don't believe this is an ABI change, as we are defining something that was previously undefined, but others may disagree. The POWER8 PMU would like to define overlapping ranges, as bit ranges in the event code have different meanings for certain events. It will also allow us to define an overarching event field, that encompasses all others. As far as I can see perf is comfortable with this change, however I am not sure if there are any other users of the interface. Any comments on this one? cheers -- 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: Debugging COW (copy on write) memory after fork: Is it possible to dump only the private anonymous memory of a process?
On 04/06/2013 09:11 PM, Bruno Prémont wrote: On Fri, 05 April 2013 Vassilis Virvilisv.virvi...@biovista.com wrote: Question Is it possible to dump only the private anonymous memory of a process? I don't know if that's possible, but from your background you could probably work around it be mmap()ing the memory you need and once initialized mark all of that memory read-only (if you mmap very large chunks you can even benefit from huge-pages). Any of the forked processes that tried to access the memory would then get a signal if they ever tried to write to the data (and thus unsharing it) I can't do that. We are talking about an existing system (in perl with C modules) that has been parallelized in a second step. If you allocate and initialize all of your memory in little malloc()'ed chunks it's possibly glibc's memory housekeeping that unshares all those pages over time. Yes I suppose it is a series of mallocs. I could easily verify that with strace. However if glibc's memory housekeeping undermines the COW behaviour that would be very bad. I have unit tests that I was able to work around the usual perl problems that cause memory unsharing such as the reference counting and hash accessing. Garbage collector shouldn't be a problem because there is nothing to collect from the shared memory, only private local variables that go out of scope. The problem is when I am employing these workarounds in the live system (with considerable IO) I am getting massive unsharing. So I thought to have a look and see what's going in two or three consecutive private memory dumps. The point is I need to locate the source of the memory unsharing. Any ideas how this can be done? At this point I could try in house compiled kernels if I can enable some logging to track this behavior. Does any knob like this exist? Even as an #ifdef? Vassilis -- 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: [Xen-devel] [PATCH-v2] xen: Don't call arch_trigger_all_cpu_backtrace in dom0(pvm)
On 07.04.13 at 07:54, Zhenzhong Duan zhenzhong.d...@oracle.com wrote:
nmi isn't supported in dom0, fallback to general all cpu backtrace code.
Since when is sending NMIs not supported, and since when is this
Dom0-specific? If you want to deal with this, you should do so
properly: Special case sending NMIs in the respective Xen specific
code (using VCPUOP_send_nmi), and carry this out in a way not
dependent upon running (un)privileged.
Without fix, on xAPIC system, doing sysrq+l, no backtrace is showed,
as xen_send_IPI_all is called and it doesn't support nmi vector.
On x2APIC enabled system, got NULL pointer dereference as below.
SysRq : Show backtrace of all active CPUs
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [8125e3cb] memcpy+0xb/0x120
Call Trace:
[81039633] ? __x2apic_send_IPI_mask+0x73/0x160
[8103973e] x2apic_send_IPI_all+0x1e/0x20
[8103498c] arch_trigger_all_cpu_backtrace+0x6c/0xb0
[81501be4] ? _raw_spin_lock_irqsave+0x34/0x50
[8131654e] sysrq_handle_showallcpus+0xe/0x10
[8131616d] __handle_sysrq+0x7d/0x140
[81316230] ? __handle_sysrq+0x140/0x140
[81316287] write_sysrq_trigger+0x57/0x60
[811ca996] proc_reg_write+0x86/0xc0
[8116dd8e] vfs_write+0xce/0x190
[8116e3e5] sys_write+0x55/0x90
[8150a242] system_call_fastpath+0x16/0x1b
That's because apic points to apic_x2apic_cluster or apic_x2apic_phys
but the basic element like cpumask isn't initialized.
That's of course a bug on its own, fixing of which would go under
a suitable subject/title.
-v2: Mask x2APIC feature in pvm to avoid overwrite of apic pointer,
update commit message per Konrad's suggestion.
Signed-off-by: Zhenzhong Duan zhenzhong.d...@oracle.com
Tested-by: Tamon Shiose tamon.shi...@oracle.com
---
arch/x86/xen/enlighten.c |3 +++
include/linux/nmi.h |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c8e1c7b..12b0718 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -386,6 +386,9 @@ static void __init xen_init_cpuid_mask(void)
cpuid_leaf1_edx_mask =
~((1 X86_FEATURE_APIC) | /* disable local APIC */
(1 X86_FEATURE_ACPI)); /* disable ACPI */
+
+ cpuid_leaf1_ecx_mask = ~(1 (X86_FEATURE_X2APIC % 32));
+
Bottom line - while this part may be fine (under a different title), ...
ax = 1;
cx = 0;
xen_cpuid(ax, bx, cx, dx);
diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index db50840..b845757 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -32,6 +32,8 @@ static inline void touch_nmi_watchdog(void)
#ifdef arch_trigger_all_cpu_backtrace
static inline bool trigger_all_cpu_backtrace(void)
{
+ if (xen_domain())
+ return false;
... this part clearly isn't.
Jan
arch_trigger_all_cpu_backtrace();
return true;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Apr 8
Hi all, Changes since 20130405: The vfs tree gained a build failure so I used the version from next-20130405. The wireless-next tree still had its build failure for which I applied a supplied patch. The mfd tree gained a build failure so I used the version from next-20130405. The omap_dss2 tree gained a conflict against Linus' tree. The akpm tree gained a conflict against the scsi tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use git pull to do so as that will try to merge the new linux-next release with the old one. You should use git fetch as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 222 trees (counting Linus' and 31 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (875b767 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging fixes/master (9064171 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes) Merging kbuild-current/rc-fixes (6dbe51c Linux 3.9-rc1) Merging arc-current/for-curr (252b19f ARC: [plat-arcfpga] Allow initramfs path to be symlink) Merging arm-current/fixes (4e1db26 ARM: 7690/1: mm: fix CONFIG_LPAE typos) Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. CONFIG_HAS_DMA) Merging powerpc-merge/merge (af81d78 powerpc: Rename USER_ESID_BITS* to ESID_BITS*) Merging sparc/master (cbf1ef6 sparc: use asm-generic version of types.h) Merging net/master (cb28ea3 bnx2x: Fix KR2 rapid link flap) Merging ipsec/master (da241ef Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging sound-current/for-linus (889d668 ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_*) Merging pci-current/for-linus (de7d5f7 PCI/PM: Disable runtime PM of PCIe ports) Merging wireless/master (69a2bac rt2x00: rt2x00pci: fix build error on Ralink RT3x5x SoCs) Merging driver-core.current/driver-core-linus (07961ac Linux 3.9-rc5) Merging tty.current/tty-linus (1f66396 OMAP/serial: Revert bad fix of Rx FIFO threshold granularity) Merging usb.current/usb-linus (07961ac Linux 3.9-rc5) Merging staging.current/staging-linus (07961ac Linux 3.9-rc5) Merging char-misc.current/char-misc-linus (6d4f013 misc/vmw_vmci: Add dependency on CONFIG_NET) Merging input-current/for-linus (4b7d293 Input: mms114 - Fix regulator enable and disable paths) Merging md-current/for-linus (238f590 md: remove CONFIG_MULTICORE_RAID456 entirely) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (d47cbd5b crypto: ux500 - add missing comma) Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe()) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6) Merging devicetree-current/devicetree/merge (ab28698 of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS) Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error) Merging gpio-current/gpio/merge (e97f9b5 gpio/gpio-ich: fix ichx_gpio_check_available() return what callers expect) Merging rr-fixes/fixes (9ba5c80 virtio: console: add locking around c_ovq operations) Merging mfd-fixes/master (0371541 mfd: twl4030-madc: Remove __exit_p annotation) Merging vfio-fixes/for-linus
Re: [PATCH 1/4] regulator: ab8500: Get rid of is_enabled from struct ab8500_regulator_info
On Sun, 07 Apr 2013, Axel Lin wrote:
The intention of this patch is to simplify the code.
Maintain the is_enabled flag is not trivial, it not only needs to set/clear
the
flag in disable()/enable() but also needs to set the flag in is_enable() to
get
initial status. The only benefit of keeping is_enabled flag is just save a
register read when set_mode(). Remove is_enabled flag makes the code simpler.
This patch also moves ab8500_regulator_is_enabled() close to
ab8500_regulator_[en|dis]able functions.
This is required to avoid a forward declaration because now we call
ab8500_regulator_is_enabled() in ab8500_regulator_set_mode().
This change also makes the code better in readability by moving similar
functions to one place.
Signed-off-by: Axel Lin axel@ingics.com
Code looks good to me:
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/regulator/ab8500.c | 72
1 file changed, 32 insertions(+), 40 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 517305e..9ebd131 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -46,7 +46,6 @@ struct ab8500_shared_mode {
* @desc: regulator description
* @regulator_dev: regulator device
* @shared_mode: used when mode is shared between two regulators
- * @is_enabled: status of regulator (on/off)
* @load_lp_uA: maximum load in idle (low power) mode
* @update_bank: bank to control on/off
* @update_reg: register to control on/off
@@ -69,7 +68,6 @@ struct ab8500_regulator_info {
struct regulator_desc desc;
struct regulator_dev*regulator;
struct ab8500_shared_mode *shared_mode;
- bool is_enabled;
int load_lp_uA;
u8 update_bank;
u8 update_reg;
@@ -259,8 +257,6 @@ static int ab8500_regulator_enable(struct regulator_dev
*rdev)
return ret;
}
- info-is_enabled = true;
-
dev_vdbg(rdev_get_dev(rdev),
%s-enable (bank, reg, mask, value): 0x%x, 0x%x, 0x%x, 0x%x\n,
info-desc.name, info-update_bank, info-update_reg,
@@ -288,8 +284,6 @@ static int ab8500_regulator_disable(struct regulator_dev
*rdev)
return ret;
}
- info-is_enabled = false;
-
dev_vdbg(rdev_get_dev(rdev),
%s-disable (bank, reg, mask, value): 0x%x, 0x%x, 0x%x, 0x%x\n,
info-desc.name, info-update_bank, info-update_reg,
@@ -298,6 +292,37 @@ static int ab8500_regulator_disable(struct regulator_dev
*rdev)
return ret;
}
+static int ab8500_regulator_is_enabled(struct regulator_dev *rdev)
+{
+ int ret;
+ struct ab8500_regulator_info *info = rdev_get_drvdata(rdev);
+ u8 regval;
+
+ if (info == NULL) {
+ dev_err(rdev_get_dev(rdev), regulator info null pointer\n);
+ return -EINVAL;
+ }
+
+ ret = abx500_get_register_interruptible(info-dev,
+ info-update_bank, info-update_reg, regval);
+ if (ret 0) {
+ dev_err(rdev_get_dev(rdev),
+ couldn't read 0x%x register\n, info-update_reg);
+ return ret;
+ }
+
+ dev_vdbg(rdev_get_dev(rdev),
+ %s-is_enabled (bank, reg, mask, value): 0x%x, 0x%x, 0x%x,
+ 0x%x\n,
+ info-desc.name, info-update_bank, info-update_reg,
+ info-update_mask, regval);
+
+ if (regval info-update_mask)
+ return 1;
+ else
+ return 0;
+}
+
static unsigned int ab8500_regulator_get_optimum_mode(
struct regulator_dev *rdev, int input_uV,
int output_uV, int load_uA)
@@ -398,7 +423,7 @@ static int ab8500_regulator_set_mode(struct regulator_dev
*rdev,
mask = info-update_mask;
}
- if (info-is_enabled || dmr) {
+ if (dmr || ab8500_regulator_is_enabled(rdev)) {
ret = abx500_mask_and_set_register_interruptible(info-dev,
bank, reg, mask, val);
if (ret 0)
@@ -464,39 +489,6 @@ static unsigned int ab8500_regulator_get_mode(struct
regulator_dev *rdev)
return ret;
}
-static int ab8500_regulator_is_enabled(struct regulator_dev *rdev)
-{
- int ret;
- struct ab8500_regulator_info *info = rdev_get_drvdata(rdev);
- u8 regval;
-
- if (info == NULL) {
- dev_err(rdev_get_dev(rdev), regulator info null pointer\n);
- return -EINVAL;
- }
-
- ret = abx500_get_register_interruptible(info-dev,
- info-update_bank, info-update_reg, regval);
- if (ret 0) {
- dev_err(rdev_get_dev(rdev),
- couldn't read 0x%x register\n, info-update_reg);
- return ret;
- }
-
- dev_vdbg(rdev_get_dev(rdev),
- %s-is_enabled (bank, reg, mask, value): 0x%x, 0x%x, 0x%x,
- 0x%x\n,
-
Re: [PATCH 4/4] regulator: ab8500-ext: Remove get_voltage to avoid duplicate implementation
On Sun, 07 Apr 2013, Axel Lin wrote:
The implementation of ab8500_ext_fixed_get_voltage is identical to
ab8500_ext_list_voltage. We can avoid the duplicate implementation by just
remove get_voltage. For fixed regulator, regulator core will call
list_voltage(rdev, 0) to get voltage if both get_voltage get_voltage_sel are
not implemented.
Signed-off-by: Axel Lin axel@ingics.com
Nice simplification:
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/regulator/ab8500-ext.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index c7896af..9aee21c 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -237,21 +237,6 @@ static unsigned int ab8500_ext_regulator_get_mode(struct
regulator_dev *rdev)
return ret;
}
-static int ab8500_ext_fixed_get_voltage(struct regulator_dev *rdev)
-{
- struct regulation_constraints *regu_constraints = rdev-constraints;
-
- if (regu_constraints == NULL) {
- dev_err(rdev_get_dev(rdev), regulator constraints null
pointer\n);
- return -EINVAL;
- }
- if (regu_constraints-min_uV regu_constraints-max_uV) {
- if (regu_constraints-min_uV == regu_constraints-max_uV)
- return regu_constraints-min_uV;
- }
- return -EINVAL;
-}
-
static int ab8500_ext_list_voltage(struct regulator_dev *rdev,
unsigned selector)
{
@@ -275,7 +260,6 @@ static struct regulator_ops ab8500_ext_regulator_ops = {
.is_enabled = ab8500_ext_regulator_is_enabled,
.set_mode = ab8500_ext_regulator_set_mode,
.get_mode = ab8500_ext_regulator_get_mode,
- .get_voltage= ab8500_ext_fixed_get_voltage,
.list_voltage = ab8500_ext_list_voltage,
};
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull another powerpc fix
The following changes since commit 875b7679abbb232b584f2eec59fa6e45690dd6c4: Merge git://git.kernel.org/pub/scm/virt/kvm/kvm (2013-04-07 13:01:25 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes.git tags/for-linus for you to fetch changes up to 9fb2640159f9d4f5a2a9d60e490482d4cbecafdb: powerpc: pSeries_lpar_hpte_remove fails from Adjunct partition being performed before the ANDCOND test (2013-04-08 15:19:09 +1000) A single BUG_ON fix for a condition that could happen for machines with certain hardware installed. Michael Wolf (1): powerpc: pSeries_lpar_hpte_remove fails from Adjunct partition being performed before the ANDCOND test arch/powerpc/platforms/pseries/lpar.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpBfNuOBrSsY.pgp Description: PGP signature
Re: [PATCH 2/4] regulator: ab8500-ext: Get rid of is_enabled from struct ab8500_ext_regulator_info
On Sun, 07 Apr 2013, Axel Lin wrote:
The intention of this patch is to simplify the code.
Maintain the is_enabled flag is not trivial, it not only needs to set/clear
the
flag in disable()/enable() but also needs to set the flag in is_enable() to
get
initial status. The only benefit of keeping is_enabled flag is just save a
register read when set_mode(). Remove is_enabled flag makes the code simpler.
Signed-off-by: Axel Lin axel@ingics.com
Looks fine:
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/regulator/ab8500-ext.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index 57d43a1..5e604a2 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -29,7 +29,6 @@
* @desc: regulator description
* @rdev: regulator device
* @cfg: regulator configuration (extension of regulator FW configuration)
- * @is_enabled: status of regulator (on/off)
* @update_bank: bank to control on/off
* @update_reg: register to control on/off
* @update_mask: mask to enable/disable and set mode of regulator
@@ -46,7 +45,6 @@ struct ab8500_ext_regulator_info {
struct regulator_desc desc;
struct regulator_dev *rdev;
struct ab8500_ext_regulator_cfg *cfg;
- bool is_enabled;
u8 update_bank;
u8 update_reg;
u8 update_mask;
@@ -78,8 +76,6 @@ static int enable(struct ab8500_ext_regulator_info *info,
u8 *regval)
return ret;
}
- info-is_enabled = true;
-
return ret;
}
@@ -125,8 +121,6 @@ static int disable(struct ab8500_ext_regulator_info
*info, u8 *regval)
return ret;
}
- info-is_enabled = false;
-
return ret;
}
@@ -177,11 +171,9 @@ static int ab8500_ext_regulator_is_enabled(struct
regulator_dev *rdev)
if (((regval info-update_mask) == info-update_val_lp) ||
((regval info-update_mask) == info-update_val_hp))
- info-is_enabled = true;
+ return 1;
else
- info-is_enabled = false;
-
- return info-is_enabled;
+ return 0;
}
static int ab8500_ext_regulator_set_mode(struct regulator_dev *rdev,
@@ -207,7 +199,7 @@ static int ab8500_ext_regulator_set_mode(struct
regulator_dev *rdev,
return -EINVAL;
}
- if (info-is_enabled) {
+ if (ab8500_ext_regulator_is_enabled(rdev)) {
u8 regval;
ret = enable(info, regval);
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] watchdog: core: don't try to stop device if not running
On 04/05/2013 08:34 PM, Guenter Roeck wrote:
On Fri, Apr 05, 2013 at 06:09:44PM +0200, Hector Palacios wrote:
A watchdog device may be stopped from userspace using WDIOC_SETOPTIONS
ioctl and flag WDIOS_DISABLECARD. If the device is closed after this
operation, watchdog_release() is called and status bits checked for
stopping it. Besides, if the device has not been unregistered a critical
message watchdog did not stop! is printed, although the ioctl may have
successfully stopped it already.
Without the patch a user application sample code like this will successfully
stop the watchdog, but the kernel will output the message
watchdog did not stop!:
wd_fd = open(/dev/watchdog, O_RDWR);
flags = WDIOS_DISABLECARD;
ioctl(wd_fd, WDIOC_SETOPTIONS, flags);
close(wd_fd);
Signed-off-by: Hector Palacios hector.palac...@digi.com
How about the following patch instead ?
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 08b48bb..9775e8d 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -469,7 +469,9 @@ static int watchdog_release(struct inode *inode, struct
file *file)
* or if WDIOF_MAGICCLOSE is not set. If nowayout was set then
* watchdog_stop will fail.
*/
- if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
+ if (!test_bit(WDOG_ACTIVE, wdd-status))
+ err = 0;
+ else if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
!(wdd-info-options WDIOF_MAGICCLOSE))
err = watchdog_stop(wdd);
Much less invasive and the result is the same.
I like the simplicity but it is kind of inverted logic to initially define err =
-EBUSY only to turn it to zero later, so I'm rebuilding your approach like this:
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index ef8edec..a4163cd 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -463,16 +463,19 @@ out:
static int watchdog_release(struct inode *inode, struct file *file)
{
struct watchdog_device *wdd = file-private_data;
- int err = -EBUSY;
+ int err = 0;
/*
* We only stop the watchdog if we received the magic character
* or if WDIOF_MAGICCLOSE is not set. If nowayout was set then
* watchdog_stop will fail.
*/
- if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
- !(wdd-info-options WDIOF_MAGICCLOSE))
+ if (test_bit(WDOG_ACTIVE, wdd-status))
+ err = -EBUSY;
+ else if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
+ !(wdd-info-options WDIOF_MAGICCLOSE)) {
err = watchdog_stop(wdd);
+ }
/* If the watchdog was not stopped, send a keepalive ping */
which makes the code more readable.
Thanks,
--
Héctor Palacios
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: cptm1217: Use dev_pm_ops
Use dev_pm_ops instead of the deprecated legacy suspend/resume callbacks.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
drivers/staging/cptm1217/clearpad_tm1217.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/cptm1217/clearpad_tm1217.c
b/drivers/staging/cptm1217/clearpad_tm1217.c
index 31fb5d3..e96eee3 100644
--- a/drivers/staging/cptm1217/clearpad_tm1217.c
+++ b/drivers/staging/cptm1217/clearpad_tm1217.c
@@ -557,12 +557,15 @@ fail:
}
+#ifdef CONFIG_PM_SLEEP
+
/*
* cp_tm1217 suspend
*
*/
-static int cp_tm1217_suspend(struct i2c_client *client, pm_message_t mesg)
+static int cp_tm1217_suspend(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
struct cp_tm1217_device *ts = i2c_get_clientdata(client);
u8 req[2];
int retval;
@@ -583,8 +586,9 @@ static int cp_tm1217_suspend(struct i2c_client *client,
pm_message_t mesg)
* cp_tm1217_resume
*
*/
-static int cp_tm1217_resume(struct i2c_client *client)
+static int cp_tm1217_resume(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
struct cp_tm1217_device *ts = i2c_get_clientdata(client);
u8 req[2];
int retval;
@@ -618,6 +622,11 @@ static int cp_tm1217_resume(struct i2c_client *client)
return 0;
}
+#endif
+
+static SIMPLE_DEV_PM_OPS(cp_tm1217_pm_ops, cp_tm1217_suspend,
+ cp_tm1217_resume);
+
/*
* cp_tm1217_remove
*
@@ -647,12 +656,11 @@ static struct i2c_driver cp_tm1217_driver = {
.driver = {
.owner = THIS_MODULE,
.name = CPTM1217_DRIVER_NAME,
+ .pm = cp_tm1217_pm_ops,
},
.id_table = cp_tm1217_idtable,
.probe = cp_tm1217_probe,
.remove = cp_tm1217_remove,
- .suspend= cp_tm1217_suspend,
- .resume = cp_tm1217_resume,
};
module_i2c_driver(cp_tm1217_driver);
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] futex: bugfix for robust futex deadlock when waking only one thread in handle_futex_death
From: Zhang Yi zhang.y...@zte.com.cn
The function handle_futex_death just wakes one thread, which may be not
enough
when the owner process is dead. Think about this scene：
1. A robust futex is shared for two processes, each process has multi
threads
try to get the lock.
2. One of the threads gets the lock, and the others are waiting and sorted
in
order of priority.
3. The process to which the lock owner thread belongs is dying，and
handle_futex_death is called to wake the first waiter
4. When the first waiter belongs to the same process，it has no chance to
return
to the userspace to get the lock and will not call handle_futex_death any
more，
and then the rest threads of the other process will never be waked, and
will block
forever.
This patch wakes all the waiters when lock owner is in group-exit, letting
all
the waiters return to userspace and try to get the lock again.
Signed-off-by: Zhang Yi zhang.y...@zte.com.cn
Tested-by: Ma Chenggong ma.chengg...@zte.com.cn
Reviewed-by: Liu Dong liu.do...@zte.com.cn
Reviewed-by: Cui Yunfeng cui.yunf...@zte.com.cn
Reviewed-by: Lu Zhongjun lu.zhong...@zte.com.cn
Reviewed-by: Jiang Biao jiang.bi...@zte.com.cn
--- orig/linux-3.9-rc5/kernel/futex.c 2013-03-31 22:12:43.0
+
+++ new/linux-3.9-rc5/kernel/futex.c2013-04-03 12:33:27.735392000
+
@@ -2545,8 +2545,10 @@ retry:
* Wake robust non-PI futexes here. The wakeup of
* PI futexes happens in exit_pi_state():
*/
- if (!pi (uval FUTEX_WAITERS))
- futex_wake(uaddr, 1, 1, FUTEX_BITSET_MATCH_ANY);
+ if (!pi (uval FUTEX_WAITERS)){
+ int wake_nr = signal_group_exit(current-signal) ?
INT_MAX : 1;
+ futex_wake(uaddr, 1, wake_nr,
FUTEX_BITSET_MATCH_ANY);
+ }
}
return 0;
}
ZTE Information Security Notice: The information contained in this mail (and
any attachment transmitted herewith) is privileged and confidential and is
intended for the exclusive use of the addressee(s). If you are not an intended
recipient, any disclosure, reproduction, distribution or other dissemination or
use of the information contained is strictly prohibited. If you have received
this mail in error, please delete it and notify us immediately.
hi:) I'm Alannisannettecdlpv.
This fleck lay down boulevard, and was innate and ugly. όἠūḑὀ=ǧǖẽ??ƅńẹᾑ Yet, in impact of these streaming memories, it would waver streaky to spend the pulley, absurdity and representation that were scampered beside the coffin of let him. -- 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] f2fs: write checkpoint before starting FG_GC
In order to be aware of prefree and free sections during FG_GC, let's start with
write_checkpoint().
Signed-off-by: Jaegeuk Kim jaegeuk@samsung.com
---
fs/f2fs/gc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 83cec8f..37b05e1 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -669,8 +669,10 @@ gc_more:
if (!(sbi-sb-s_flags MS_ACTIVE))
goto stop;
- if (gc_type == BG_GC has_not_enough_free_secs(sbi, nfree))
+ if (gc_type == BG_GC has_not_enough_free_secs(sbi, nfree)) {
gc_type = FG_GC;
+ write_checkpoint(sbi, false);
+ }
if (!__get_victim(sbi, segno, gc_type, NO_CHECK_TYPE))
goto stop;
--
1.8.1.3.566.gaa39828
--
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 RFC] watchdog: core: don't try to stop device if not running
On Mon, Apr 08, 2013 at 09:48:57AM +0200, Hector Palacios wrote:
On 04/05/2013 08:34 PM, Guenter Roeck wrote:
On Fri, Apr 05, 2013 at 06:09:44PM +0200, Hector Palacios wrote:
A watchdog device may be stopped from userspace using WDIOC_SETOPTIONS
ioctl and flag WDIOS_DISABLECARD. If the device is closed after this
operation, watchdog_release() is called and status bits checked for
stopping it. Besides, if the device has not been unregistered a critical
message watchdog did not stop! is printed, although the ioctl may have
successfully stopped it already.
Without the patch a user application sample code like this will successfully
stop the watchdog, but the kernel will output the message
watchdog did not stop!:
wd_fd = open(/dev/watchdog, O_RDWR);
flags = WDIOS_DISABLECARD;
ioctl(wd_fd, WDIOC_SETOPTIONS, flags);
close(wd_fd);
Signed-off-by: Hector Palacios hector.palac...@digi.com
How about the following patch instead ?
diff --git a/drivers/watchdog/watchdog_dev.c
b/drivers/watchdog/watchdog_dev.c
index 08b48bb..9775e8d 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -469,7 +469,9 @@ static int watchdog_release(struct inode *inode, struct
file *file)
* or if WDIOF_MAGICCLOSE is not set. If nowayout was set then
* watchdog_stop will fail.
*/
-if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
+if (!test_bit(WDOG_ACTIVE, wdd-status))
+err = 0;
+else if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
!(wdd-info-options WDIOF_MAGICCLOSE))
err = watchdog_stop(wdd);
Much less invasive and the result is the same.
I like the simplicity but it is kind of inverted logic to initially
define err = -EBUSY only to turn it to zero later, so I'm rebuilding
your approach like this:
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index ef8edec..a4163cd 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -463,16 +463,19 @@ out:
static int watchdog_release(struct inode *inode, struct file *file)
{
struct watchdog_device *wdd = file-private_data;
- int err = -EBUSY;
+ int err = 0;
/*
* We only stop the watchdog if we received the magic character
* or if WDIOF_MAGICCLOSE is not set. If nowayout was set then
* watchdog_stop will fail.
*/
- if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
- !(wdd-info-options WDIOF_MAGICCLOSE))
+ if (test_bit(WDOG_ACTIVE, wdd-status))
+ err = -EBUSY;
+ else if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
+ !(wdd-info-options WDIOF_MAGICCLOSE)) {
err = watchdog_stop(wdd);
+ }
Ok, but the added { } are unnecessary and violate coding style rules.
Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 0/4] cpufreq: exynos5440: support for cpufreq driver
Submitting the V6 version of exynos5440 cpufreq driver. This patchset addresses all the coding and design concerns raised especially by Viresh. Changes in V6: * Used cpufreq post-change notifier call back in case of failure as pointed by Viresh. * Called cpufreq_frequency_table_cpuinfo before calling cpufreq_frequency_table_get_attr as pointed by Viresh. * Used modified API cpufreq_notify_transition. Changes in V5: * Removed the unnecessary DT look up entry from mach-exynos5-dt.c. * Fixed all coding and comments issue raised by Viresh. Changes in V4: * Added dev_err logs instead of pr_err. * Used the devm_ioremap_resource API. * Implemented several coding guidelines and minor error comments from Sylwester, Russell and Viresh. Changes in V3: * Converted the driver to probe based as suggested by Viresh. This is also beneficial for multiplatform kernel. * Other coding guidelines related changes. * Moved the DT node outside cpu0 node as the driver is now a platform driver. Changes in V2: * Added OPP library support to parse DT parameters. * Removed a hack to handle interrupts in bootup. * Implemented other review comments from Viresh and Inder. All these patches are dependent on Thomas Abraham common clock patches. (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html) This whole patch series is based on Rafael tree. git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge Amit Daniel Kachhap (4): cpufreq: exynos: Add cpufreq driver for exynos5440 cpufreq: exynos: Remove error return even if no soc is found arm: exynos: Enable OPP library support for exynos5440 arm: dts: Add cpufreq controller node for Exynos5440 SoC .../bindings/cpufreq/cpufreq-exynos5440.txt| 28 ++ arch/arm/boot/dts/exynos5440.dtsi | 12 + arch/arm/mach-exynos/Kconfig |2 + drivers/cpufreq/Kconfig.arm|9 + drivers/cpufreq/Makefile |1 + drivers/cpufreq/exynos-cpufreq.c |2 +- drivers/cpufreq/exynos5440-cpufreq.c | 479 7 files changed, 532 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c -- 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 V6 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they scale at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
cpufreq framework. The major difference being interrupt notification for
frequency change. Also, OPP library is used for device tree parsing to get
different parameters like frequency, voltage etc. Since the opp library sorts
the frequency table in ascending order so they are again re-arranged in
descending order. This will have one-to-one mapping with the clock controller
state management logic.
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../bindings/cpufreq/cpufreq-exynos5440.txt| 28 ++
drivers/cpufreq/Kconfig.arm|9 +
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/exynos5440-cpufreq.c | 479
4 files changed, 517 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000..caff1a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,28 @@
+
+Exynos5440 cpufreq driver
+---
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be transitioned
into,
+ in the decreasing order. Frequency should be in KHz units and voltage
+ should be in microvolts.
+
+Optional properties:
+- clock-latency: Clock monitor latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ operating-points =
+ 100 975000
+ 80 925000;
+ clock-latency = 10;
+ };
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index f3f3b14..bce2195 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ
This adds the CPUFreq driver for Samsung EXYNOS5250
SoC.
+config ARM_EXYNOS5440_CPUFREQ
+ def_bool SOC_EXYNOS5440
+ depends on HAVE_CLK PM_OPP OF
+ help
+ This adds the CPUFreq driver for Samsung EXYNOS5440
+ SoC. The nature of exynos5440 clock controller is
+ different than previous exynos controllers so not using
+ the common exynos framework.
+
config ARM_HIGHBANK_CPUFREQ
tristate Calxeda Highbank-based
depends on ARCH_HIGHBANK
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 5db1f1f..6ad0b91 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
obj-$(CONFIG_ARM_INTEGRATOR) += integrator-cpufreq.o
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
new file mode 100644
index 000..9c37825
--- /dev/null
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -0,0 +1,479 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Amit Daniel Kachhap amit.dan...@samsung.com
+ *
+ * EXYNOS5440 - CPU frequency scaling support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/clk.h
+#include linux/cpu.h
+#include linux/cpufreq.h
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/opp.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+/* Register definitions */
+#define XMU_DVFS_CTRL 0x0060
+#define XMU_PMU_P0_7 0x0064
+#define XMU_C0_3_PSTATE0x0090
+#define XMU_P_LIMIT0x00a0
[PATCH V6 2/4] cpufreq: exynos: Remove error return even if no soc is found
This patch helps to have single binary for exynos5440 and previous exynos soc's. This change is needed for adding exynos5440 cpufreq driver which does not uses exynos-cpufreq common file and adds it own driver. Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Rafael J. Wysocki r...@sisk.pl Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- drivers/cpufreq/exynos-cpufreq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c index c0c4ce5..475b4f6 100644 --- a/drivers/cpufreq/exynos-cpufreq.c +++ b/drivers/cpufreq/exynos-cpufreq.c @@ -294,7 +294,7 @@ static int __init exynos_cpufreq_init(void) else if (soc_is_exynos5250()) ret = exynos5250_cpufreq_init(exynos_info); else - pr_err(%s: CPU type not found\n, __func__); + return 0; if (ret) goto err_vdd_arm; -- 1.7.1 -- 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 V6 4/4] arm: dts: Add cpufreq controller node for Exynos5440 SoC
Add cpufreq controller device node for Exynos5440 SoC for passing
parameters like controller base address, interrupt and cpufreq
table. This node is added outside cpu0 as this driver is now a platform
driver and a new device structure is needed.
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
arch/arm/boot/dts/exynos5440.dtsi | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 9a99755..94074ea 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -63,6 +63,18 @@
};
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ operating-points =
+ /* KHzuV */
+ 120 1025000
+ 100 975000
+ 80 925000
+ ;
+ };
+
serial@B {
compatible = samsung,exynos4210-uart;
reg = 0xB 0x1000;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][TRIVIAL] iommu: Include linux/err.h
The linux/iommu.h header uses ERR_PTR defined in linux/err.h but doesn't include it. Reviewed-by: Alex Williamson alex.william...@redhat.com Signed-off-by: Wang YanQing udkni...@gmail.com --- I send this twice to joerg.roe...@amd.com more than one month, but it had been ignored, I don't why. include/linux/iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index f3b99e1..f4a49a6 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -20,6 +20,7 @@ #define __LINUX_IOMMU_H #include linux/errno.h +#include linux/err.h #include linux/types.h #define IOMMU_READ (1) -- 1.7.11.1.116.g8228a23 -- 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 v1] pwm: add sysfs interface
On Wed, Apr 03, 2013 at 03:58:55PM +0200, Lars Poeschel wrote: From: Lars Poeschel poesc...@lemonage.de This adds a simple sysfs interface to the pwm subsystem. It is heavily inspired by the gpio sysfs interface. /sys/class/pwm /export ... asks the kernel to export a PWM to userspace /unexport ... to return a PWM to the kernel /pwmN ... for each exported PWM #N /duty_ns ... r/w, length of duty portion /period_ns ... r/w, length of the pwm period pwm - PWM. There are other occurrences of this in the remainder of the patch. I haven't explicitly pointed them out, but please check those too. The rule of thumb is to use all uppercase PWM in prose because it is an abbreviation. The lowercase variant is okay for variable names and such. /polarity ... r/w, normal(0) or inverse(1) polarity only created if driver supports it /run ... r/w, write 1 to start and 0 to stop the pwm /pwmchipN ... for each pwmchip; #N is its first PWM I think I'd prefer for each PWM chip, or for each pwm_chip. No data structure named pwmchip exists in the kernel. /base ... (r/o) same as N /ngpio ... (r/o) number of PWM; numbered N .. MAX_PWMS npwm? number of PWM devices? MAX_PWMS - N + (npwm - 1)? diff --git a/Documentation/ABI/testing/sysfs-class-pwm b/Documentation/ABI/testing/sysfs-class-pwm new file mode 100644 index 000..e9be1a3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-pwm @@ -0,0 +1,37 @@ +What:/sys/class/pwm/ +Date:March 2013 +KernelVersion: 3.11 +Contact: Lars Poeschel poesc...@lemonage.de +Description: + + The sysfs interface for PWM is selectable as a Kconfig option. + If a driver successfully probed a pwm chip, it appears at PWM chip please. + /sys/class/pwm/pwmchipN/ where N is the number of it's first PWM channel. A it's - its Also this highlights a fundamental problem with this patch. I know people like to handle PWMs the same as GPIOs, but the problem here is that the PWM subsystem was designed to do per-chip indexing. The global namespace was introduced only for backwards compatibility. An explicit goal was to get rid of the global namespace once all uses of the legacy API have been removed. This whole sysfs interface relies on the fact that there is some global namespace, so if we expose the global namespace to userspace via sysfs we make it much harder to get rid of it. So instead of using pwmchipN as the name I think it'd be better to use the device name for the directory entry in sysfs (much like the backlight, power or other classes). On a side-note, there's really no need to encode the base in the name, since you can much more easily obtain it from the base attribute. + single driver may probe multiple chips. That sentence is superfluous. I think it's a generally accepted fact that one driver can probe multiple devices. PWMs are identified as they are + inside the kernel, using integers in the range 0..MAX_PWMS. To use an + individual PWM, you have to explicitly export it by writing it's kernel + global number into the /sys/class/pwm/export file. Write it's number to + /sys/class/pwm/unexport to make the pwm available for other uses. For reasons explained above I think we should make each PWM channel exportable via its chip. That would expose the per-chip indexing in the sysfs interface. In other words the export/unexport attributes should be moved within the pwm_chip nodes. + After a PWM channel is exported, it is available under + /sys/class/pwm/pwmN/. Under this directory you can set the parameters for + this PWM channel and at least let it start running. I don't understand the last part of this sentence. at least let it start running? + See below for the parameters. + It is recommended to set the period_ns at first and the duty_ns after that. Why is it recommended to set the period_ns first and then duty_ns? Both typically need to be set atomically, which is why the in-kernel function that configures a PWM channel takes both as parameters. Can we not post- pone setting these until we actually enable the PWM? I think further the it might be safer to disable the PWM as soon as any of the attributes is written and require the user to explicitly enable it again when they have finished configuration. +Directory structure: + + /sys/class/pwm + /export ... asks the kernel to export a PWM to userspace + /unexport ... to return a PWM to the kernel + /pwmN ... for each exported PWM #N + /duty_ns ... r/w, length of duty portion + /period_ns ... r/w, length of the pwm period + /polarity ... r/w, normal(0) or inverse(1) polarity + only
[PATCH 0/8] memcg, cgroup: kill css_id
(This patchset depends on memcg: make memcg's life cycle the same as cgroup) This patchset converts memcg to always use cgroup-id, and then kills css_id. As we've removed memcg's own refcnt, converting memcg to use cgroup-id is very straight-forward. Li Zefan (8): cgroup: implement cgroup_is_ancestor() cgroup: implement cgroup_from_id() memcg: convert to use cgroup_is_ancestor() memcg: convert to use cgroup_from_id() memcg: convert to use cgroup-id memcg: fail to create cgroup if the cgroup id is too big memcg: don't use css_id any more cgroup: kill css_id -- include/linux/cgroup.h | 44 ++--- kernel/cgroup.c| 302 +- mm/memcontrol.c| 53 ++- 3 files changed, 77 insertions(+), 322 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] cgroup: implement cgroup_is_ancestor()
This will be used as a replacement for css_is_ancestor().
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/cgroup.h | 3 +++
kernel/cgroup.c| 21 +
2 files changed, 24 insertions(+)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 2eaedc1..96072e4 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -177,6 +177,7 @@ struct cgroup {
atomic_t count;
int id; /* ida allocated in-hierarchy ID */
+ int depth; /* the depth of the cgroup */
/*
* We link our 'sibling' struct into our parent's 'children'.
@@ -730,6 +731,8 @@ unsigned short css_id(struct cgroup_subsys_state *css);
unsigned short css_depth(struct cgroup_subsys_state *css);
struct cgroup_subsys_state *cgroup_css_from_dir(struct file *f, int id);
+bool cgroup_is_ancestor(struct cgroup *child, struct cgroup *root);
+
#else /* !CONFIG_CGROUPS */
static inline int cgroup_init_early(void) { return 0; }
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 7ee3bdf..e87872c 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4133,6 +4133,7 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
cgrp-dentry = dentry;
cgrp-parent = parent;
+ cgrp-depth = parent-depth + 1;
cgrp-root = parent-root;
cgrp-top_cgroup = parent-top_cgroup;
@@ -5299,6 +5300,26 @@ struct cgroup_subsys_state *cgroup_css_from_dir(struct
file *f, int id)
return css ? css : ERR_PTR(-ENOENT);
}
+/**
+ * cgroup_is_ancestor - test root cgroup is an ancestor of child
+ * @child: the cgroup to be tested.
+ * @root: the cgroup supposed to be an ancestor of the child.
+ *
+ * Returns true if root is an ancestor of child in its hierarchy.
+ */
+bool cgroup_is_ancestor(struct cgroup *child, struct cgroup *root)
+{
+ int depth = child-depth;
+
+ if (depth root-depth)
+ return false;
+
+ while (depth-- != root-depth)
+ child = child-parent;
+
+ return (child == root);
+}
+
#ifdef CONFIG_CGROUP_DEBUG
static struct cgroup_subsys_state *debug_css_alloc(struct cgroup *cont)
{
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] memcg: convert to use cgroup_from_id()
This is a preparation to kill css_id.
Signed-off-by: Li Zefan lize...@huawei.com
---
mm/memcontrol.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 14f1375..3561d0b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2769,15 +2769,15 @@ static void __mem_cgroup_cancel_local_charge(struct
mem_cgroup *memcg,
*/
static struct mem_cgroup *mem_cgroup_lookup(unsigned short id)
{
- struct cgroup_subsys_state *css;
+ struct cgroup *cgrp;
/* ID 0 is unused ID */
if (!id)
return NULL;
- css = css_lookup(mem_cgroup_subsys, id);
- if (!css)
+ cgrp = cgroup_from_id(mem_cgroup_subsys, id);
+ if (!cgrp)
return NULL;
- return mem_cgroup_from_css(css);
+ return mem_cgroup_from_cont(cgrp);
}
struct mem_cgroup *try_get_mem_cgroup_from_page(struct page *page)
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] memcg: convert to use cgroup_is_ancestor()
This is a preparation to kill css_id. Signed-off-by: Li Zefan lize...@huawei.com --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 5aa6e91..14f1375 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1383,7 +1383,7 @@ bool __mem_cgroup_same_or_subtree(const struct mem_cgroup *root_memcg, return true; if (!root_memcg-use_hierarchy || !memcg) return false; - return css_is_ancestor(memcg-css, root_memcg-css); + return cgroup_is_ancestor(memcg-css.cgroup, root_memcg-css.cgroup); } static bool mem_cgroup_same_or_subtree(const struct mem_cgroup *root_memcg, -- 1.8.0.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] memcg: convert to use cgroup-id
This is a preparation to kill css_id.
Signed-off-by: Li Zefan lize...@huawei.com
---
mm/memcontrol.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 3561d0b..c4e0173 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -492,6 +492,11 @@ static inline bool mem_cgroup_is_root(struct mem_cgroup
*memcg)
return (memcg == root_mem_cgroup);
}
+static inline unsigned short mem_cgroup_id(struct mem_cgroup *memcg)
+{
+ return memcg-css.cgroup-id;
+}
+
/* Writing them here to avoid exposing memcg's inner layout */
#if defined(CONFIG_INET) defined(CONFIG_MEMCG_KMEM)
@@ -4234,7 +4239,7 @@ mem_cgroup_uncharge_swapcache(struct page *page,
swp_entry_t ent, bool swapout)
* css_get() was called in uncharge().
*/
if (do_swap_account swapout memcg)
- swap_cgroup_record(ent, css_id(memcg-css));
+ swap_cgroup_record(ent, mem_cgroup_id(memcg));
}
#endif
@@ -4286,8 +4291,8 @@ static int mem_cgroup_move_swap_account(swp_entry_t entry,
{
unsigned short old_id, new_id;
- old_id = css_id(from-css);
- new_id = css_id(to-css);
+ old_id = mem_cgroup_id(from);
+ new_id = mem_cgroup_id(to);
if (swap_cgroup_cmpxchg(entry, old_id, new_id) == old_id) {
mem_cgroup_swap_statistics(from, false);
@@ -6428,7 +6433,7 @@ static enum mc_target_type get_mctgt_type(struct
vm_area_struct *vma,
}
/* There is a swap entry and a page doesn't exist or isn't charged */
if (ent.val !ret
- css_id(mc.from-css) == lookup_swap_cgroup_id(ent)) {
+ mem_cgroup_id(mc.from) == lookup_swap_cgroup_id(ent)) {
ret = MC_TARGET_SWAP;
if (target)
target-ent = ent;
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] cgroup: implement cgroup_from_id()
This will be used as a replacement for css_lookup().
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 31 +--
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 96072e4..6ae8ae1 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -732,6 +732,7 @@ unsigned short css_depth(struct cgroup_subsys_state *css);
struct cgroup_subsys_state *cgroup_css_from_dir(struct file *f, int id);
bool cgroup_is_ancestor(struct cgroup *child, struct cgroup *root);
+struct cgroup *cgroup_from_id(struct cgroup_subsys *ss, int id);
#else /* !CONFIG_CGROUPS */
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index e87872c..5ae1e87 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -139,7 +139,7 @@ struct cgroupfs_root {
unsigned long flags;
/* IDs for cgroups in this hierarchy */
- struct ida cgroup_ida;
+ struct idr cgroup_idr;
/* The path to use for release notifications. */
char release_agent_path[PATH_MAX];
@@ -908,7 +908,7 @@ static void cgroup_free_fn(struct work_struct *work)
simple_xattrs_free(cgrp-xattrs);
- ida_simple_remove(cgrp-root-cgroup_ida, cgrp-id);
+ idr_remove(cgrp-root-cgroup_idr, cgrp-id);
kfree(rcu_dereference_raw(cgrp-name));
kfree(cgrp);
}
@@ -1512,7 +1512,8 @@ static struct cgroupfs_root *cgroup_root_from_opts(struct
cgroup_sb_opts *opts)
root-subsys_mask = opts-subsys_mask;
root-flags = opts-flags;
- ida_init(root-cgroup_ida);
+ idr_init(root-cgroup_idr);
+
if (opts-release_agent)
strcpy(root-release_agent_path, opts-release_agent);
if (opts-name)
@@ -1531,7 +1532,7 @@ static void cgroup_drop_root(struct cgroupfs_root *root)
spin_lock(hierarchy_id_lock);
ida_remove(hierarchy_ida, root-hierarchy_id);
spin_unlock(hierarchy_id_lock);
- ida_destroy(root-cgroup_ida);
+ idr_destroy(root-cgroup_idr);
kfree(root);
}
@@ -1645,6 +1646,11 @@ static struct dentry *cgroup_mount(struct
file_system_type *fs_type,
mutex_lock(cgroup_mutex);
mutex_lock(cgroup_root_mutex);
+ root_cgrp-id = idr_alloc(root-cgroup_idr, root_cgrp,
+ 0, 0, GFP_KERNEL);
+ if (root_cgrp-id 0)
+ goto unlock_drop;
+
/* Check for name clashes with existing mounts */
ret = -EBUSY;
if (strlen(root-name))
@@ -4104,7 +4110,7 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
goto err_free_cgrp;
rcu_assign_pointer(cgrp-name, name);
- cgrp-id = ida_simple_get(root-cgroup_ida, 1, 0, GFP_KERNEL);
+ cgrp-id = idr_alloc(root-cgroup_idr, cgrp, 1, 0, GFP_KERNEL);
if (cgrp-id 0)
goto err_free_name;
@@ -4215,7 +4221,7 @@ err_free_all:
/* Release the reference count that we took on the superblock */
deactivate_super(sb);
err_free_id:
- ida_simple_remove(root-cgroup_ida, cgrp-id);
+ idr_remove(root-cgroup_idr, cgrp-id);
err_free_name:
kfree(rcu_dereference_raw(cgrp-name));
err_free_cgrp:
@@ -5320,6 +5326,19 @@ bool cgroup_is_ancestor(struct cgroup *child, struct
cgroup *root)
return (child == root);
}
+/**
+ * cgroup_from_id - lookup cgroup by id
+ * @ss: cgroup subsys to be looked into.
+ * @id: the id
+ *
+ * Returns pointer to cgroup if there is valid one with id.
+ * NULL if not. Should be called under rcu_read_lock()
+ */
+struct cgroup *cgroup_from_id(struct cgroup_subsys *ss, int id)
+{
+ return idr_find(ss-root-cgroup_idr, id);
+}
+
#ifdef CONFIG_CGROUP_DEBUG
static struct cgroup_subsys_state *debug_css_alloc(struct cgroup *cont)
{
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Update device tree binding document for pwm-tiehrpwm pwm-tiecap
On Mon, Apr 08, 2013 at 05:56:39AM +, Philip, Avinash wrote: Thierry, On Mon, Mar 25, 2013 at 12:34:51, Philip, Avinash wrote: Update device tree document of pwm-tiehrpwm pwm-tiecap in order to reflect the usage of similar modules in both da850 and am33xx platforms. Can you accept both documentation update patches with Peter Korsgaard's Ack. Thanks for the reminder. Both patches applied. Thierry pgpsiL9XB8iqe.pgp Description: PGP signature
[PATCH 6/8] memcg: fail to create cgroup if the cgroup id is too big
memcg requires the cgroup id to be smaller than 65536.
Signed-off-by: Li Zefan lize...@huawei.com
---
mm/memcontrol.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index c4e0173..947dff1 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -492,6 +492,12 @@ static inline bool mem_cgroup_is_root(struct mem_cgroup
*memcg)
return (memcg == root_mem_cgroup);
}
+/*
+ * We restrict the id in the range of [0, 65535], so it can fit into
+ * an unsigned short.
+ */
+#define MEM_CGROUP_ID_MAX (65535)
+
static inline unsigned short mem_cgroup_id(struct mem_cgroup *memcg)
{
return memcg-css.cgroup-id;
@@ -6125,6 +6131,9 @@ mem_cgroup_css_alloc(struct cgroup *cont)
long error = -ENOMEM;
int node;
+ if (cont-id MEM_CGROUP_ID_MAX)
+ return ERR_PTR(-ENOSPC);
+
memcg = mem_cgroup_alloc();
if (!memcg)
return ERR_PTR(error);
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] memcg: don't use css_id any more
Now memcg uses cgroup-id instead of css_id. Update some comments and
set mem_cgroup_subsys-use_id to 0.
Signed-off-by: Li Zefan lize...@huawei.com
---
mm/memcontrol.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 947dff1..26ee672 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -574,16 +574,11 @@ static void disarm_sock_keys(struct mem_cgroup *memcg)
#ifdef CONFIG_MEMCG_KMEM
/*
* This will be the memcg's index in each cache's -memcg_params-memcg_caches.
- * There are two main reasons for not using the css_id for this:
- * 1) this works better in sparse environments, where we have a lot of memcgs,
- * but only a few kmem-limited. Or also, if we have, for instance, 200
- * memcgs, and none but the 200th is kmem-limited, we'd have to have a
- * 200 entry array for that.
- *
- * 2) In order not to violate the cgroup API, we would like to do all memory
- * allocation in -create(). At that point, we haven't yet allocated the
- * css_id. Having a separate index prevents us from messing with the cgroup
- * core for this
+ * The main reason for not using cgrp_id for this:
+ * this works better in sparse environments, where we have a lot of memcgs,
+ * but only a few kmem-limited. Or also, if we have, for instance, 200
+ * memcgs, and none but the 200th is kmem-limited, we'd have to have a
+ * 200 entry array for that.
*
* The current size of the caches array is stored in
* memcg_limited_groups_array_size. It will double each time we have to
@@ -598,10 +593,10 @@ int memcg_limited_groups_array_size;
* cgroups is a reasonable guess. In the future, it could be a parameter or
* tunable, but that is strictly not necessary.
*
- * MAX_SIZE should be as large as the number of css_ids. Ideally, we could get
+ * MAX_SIZE should be as large as the number of cgrp_ids. Ideally, we could get
* this constant directly from cgroup, but it is understandable that this is
* better kept as an internal representation in cgroup.c. In any case, the
- * css_id space is not getting any smaller, and we don't have to necessarily
+ * cgrp_id space is not getting any smaller, and we don't have to necessarily
* increase ours as well if it increases.
*/
#define MEMCG_CACHES_MIN_SIZE 4
@@ -6065,7 +6060,6 @@ static void __mem_cgroup_free(struct mem_cgroup *memcg)
size_t size = memcg_size();
mem_cgroup_remove_from_trees(memcg);
- free_css_id(mem_cgroup_subsys, memcg-css);
for_each_node(node)
free_mem_cgroup_per_zone_info(memcg, node);
@@ -6846,7 +6840,6 @@ struct cgroup_subsys mem_cgroup_subsys = {
.attach = mem_cgroup_move_task,
.base_cftypes = mem_cgroup_files,
.early_init = 0,
- .use_id = 1,
};
#ifdef CONFIG_MEMCG_SWAP
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 3/4] arm: exynos: Enable OPP library support for exynos5440
The OPP library support is needed for exynos5440 cpu frequency dynamic scaling driver. Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Rafael J. Wysocki r...@sisk.pl Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 70f94c8..d5dde07 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -72,10 +72,12 @@ config SOC_EXYNOS5440 bool SAMSUNG EXYNOS5440 default y depends on ARCH_EXYNOS5 + select ARCH_HAS_OPP select ARM_ARCH_TIMER select AUTO_ZRELADDR select PINCTRL select PINCTRL_EXYNOS5440 + select PM_OPP help Enable EXYNOS5440 SoC support -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
On Thu, Mar 28, 2013 at 6:12 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 28 March 2013 13:35, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
+static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+ policy-cur = dvfs_info-cur_frequency;
+ cpufreq_frequency_table_get_attr(dvfs_info-freq_table,
policy-cpu);
+
+ /* set the transition latency value */
+ policy-cpuinfo.transition_latency = dvfs_info-latency;
+
+ cpumask_setall(policy-cpus);
+
+ return cpufreq_frequency_table_cpuinfo(policy,
dvfs_info-freq_table);
I missed this earlier and saw this mistake in yet another driver.
You need to call cpufreq_frequency_table_get_attr() only when
cpufreq_frequency_table_cpuinfo() has passed.
ok. Submitted the V6 version with this change.
+}
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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/
[PATCH 8/8] cgroup: kill css_id
The only user of css_id was memcg, and it has been converted to
use cgroup-id, so kill css_id.
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/cgroup.h | 38
kernel/cgroup.c| 258 -
2 files changed, 296 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 6ae8ae1..d2c06db 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -495,11 +495,6 @@ struct cgroup_subsys {
int active;
int disabled;
int early_init;
- /*
-* True if this subsys uses ID. ID is not available before cgroup_init()
-* (not available in early_init time.)
-*/
- bool use_id;
/*
* If %false, this subsystem is properly hierarchical -
@@ -525,9 +520,6 @@ struct cgroup_subsys {
*/
struct cgroupfs_root *root;
struct list_head sibling;
- /* used when use_id == true */
- struct idr idr;
- spinlock_t id_lock;
/* list of cftype_sets */
struct list_head cftsets;
@@ -699,36 +691,6 @@ int cgroup_attach_task(struct cgroup *cgrp, struct
task_struct *tsk,
bool threadgroup);
int cgroup_attach_task_all(struct task_struct *from, struct task_struct *);
-/*
- * CSS ID is ID for cgroup_subsys_state structs under subsys. This only works
- * if cgroup_subsys.use_id == true. It can be used for looking up and scanning.
- * CSS ID is assigned at cgroup allocation (create) automatically
- * and removed when subsys calls free_css_id() function. This is because
- * the lifetime of cgroup_subsys_state is subsys's matter.
- *
- * Looking up and scanning function should be called under rcu_read_lock().
- * Taking cgroup_mutex is not necessary for following calls.
- * But the css returned by this routine can be not populated yet or being
- * destroyed. The caller should check css and cgroup's status.
- */
-
-/*
- * Typically Called at -destroy(), or somewhere the subsys frees
- * cgroup_subsys_state.
- */
-void free_css_id(struct cgroup_subsys *ss, struct cgroup_subsys_state *css);
-
-/* Find a cgroup_subsys_state which has given ID */
-
-struct cgroup_subsys_state *css_lookup(struct cgroup_subsys *ss, int id);
-
-/* Returns true if root is ancestor of cg */
-bool css_is_ancestor(struct cgroup_subsys_state *cg,
-const struct cgroup_subsys_state *root);
-
-/* Get id and depth of css */
-unsigned short css_id(struct cgroup_subsys_state *css);
-unsigned short css_depth(struct cgroup_subsys_state *css);
struct cgroup_subsys_state *cgroup_css_from_dir(struct file *f, int id);
bool cgroup_is_ancestor(struct cgroup *child, struct cgroup *root);
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 5ae1e87..2389484 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -165,38 +165,6 @@ struct cfent {
};
/*
- * CSS ID -- ID per subsys's Cgroup Subsys State(CSS). used only when
- * cgroup_subsys-use_id != 0.
- */
-#define CSS_ID_MAX (65535)
-struct css_id {
- /*
-* The css to which this ID points. This pointer is set to valid value
-* after cgroup is populated. If cgroup is removed, this will be NULL.
-* This pointer is expected to be RCU-safe because destroy()
-* is called after synchronize_rcu(). But for safe use, css_tryget()
-* should be used for avoiding race.
-*/
- struct cgroup_subsys_state __rcu *css;
- /*
-* ID of this css.
-*/
- unsigned short id;
- /*
-* Depth in hierarchy which this ID belongs to.
-*/
- unsigned short depth;
- /*
-* ID is freed by RCU. (and lookup routine is RCU safe.)
-*/
- struct rcu_head rcu_head;
- /*
-* Hierarchy of CSS ID belongs to.
-*/
- unsigned short stack[0]; /* Array of Length (depth+1) */
-};
-
-/*
* cgroup_event represents events which userspace want to receive.
*/
struct cgroup_event {
@@ -363,9 +331,6 @@ struct cg_cgroup_link {
static struct css_set init_css_set;
static struct cg_cgroup_link init_css_set_link;
-static int cgroup_init_idr(struct cgroup_subsys *ss,
- struct cgroup_subsys_state *css);
-
/* css_set_lock protects the list of css_set objects, and the
* chain of tasks off each css_set. Nests outside task-alloc_lock
* due to cgroup_iter_start() */
@@ -843,9 +808,6 @@ static struct backing_dev_info cgroup_backing_dev_info = {
.capabilities = BDI_CAP_NO_ACCT_AND_WRITEBACK,
};
-static int alloc_css_id(struct cgroup_subsys *ss,
- struct cgroup *parent, struct cgroup *child);
-
static struct inode *cgroup_new_inode(umode_t mode, struct super_block *sb)
{
struct inode *inode = new_inode(sb);
@@ -4002,18 +3964,6 @@ static int cgroup_populate_dir(struct cgroup *cgrp, bool
base_files,
cgroup_addrm_files(cgrp, ss, set-cfts, true);
}
-
Re: [PATCH] HID: Roccat: Added media key support for Kone
On Sun, 7 Apr 2013, Stefan Achatz wrote: Kone now reports media key events through it's chardev to userspace. Signed-off-by: Stefan Achatz erazor...@users.sourceforge.net Applied. -- Jiri Kosina SUSE Labs -- 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] mfd: adp5520: Use module_i2c_driver()
On 27 March 2013 14:50, Hennerich, Michael michael.henner...@analog.com wrote: Von: Sachin Kamat [sachin.ka...@linaro.org] Gesendet: Mittwoch, 27. März 2013 09:59 An: device-drivers-de...@blackfin.uclinux.org; LKML Cc: Hennerich, Michael; sa...@linux.intel.com; sachin.ka...@linaro.org Betreff: Re: [PATCH 1/1] mfd: adp5520: Use module_i2c_driver() On 15 March 2013 17:10, Sachin Kamat sachin.ka...@linaro.org wrote: module_i2c_driver() removes some boilerplate and makes the code simple. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Acked-by: Michael Hennerich michael.henner...@analog.com Ping Samuel. -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 0/4] cpufreq: exynos5440: support for cpufreq driver
On Fri, Apr 5, 2013 at 6:08 PM, Rafael J. Wysocki r...@sisk.pl wrote: On Thursday, March 28, 2013 01:35:18 PM Amit Daniel Kachhap wrote: Submitting the V5 version of exynos5440 cpufreq driver. This patchset addresses all the coding and design concerns raised especially by Viresh. Changes in V5: * Removed the unnecessary DT look up entry from mach-exynos5-dt.c. * Fixed all coding and comments issue raised by Viresh. Changes in V4: * Added dev_err logs instead of pr_err. * Used the devm_ioremap_resource API. * Implemented several coding guidelines and minor error comments from Sylwester, Russell and Viresh. Changes in V3: * Converted the driver to probe based as suggested by Viresh. This is also beneficial for multiplatform kernel. * Other coding guidelines related changes. * Moved the DT node outside cpu0 node as the driver is now a platform driver. Changes in V2: * Added OPP library support to parse DT parameters. * Removed a hack to handle interrupts in bootup. * Implemented other review comments from Viresh and Inder. All these patches are dependent on Thomas Abraham common clock patches. (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html) This whole patch series is based on 3.9-rc4. Amit Daniel Kachhap (4): cpufreq: exynos: Add cpufreq driver for exynos5440 cpufreq: exynos: Remove error return even if no soc is found arm: exynos: Enable OPP library support for exynos5440 arm: dts: Add cpufreq controller node for Exynos5440 SoC .../bindings/cpufreq/cpufreq-exynos5440.txt| 28 ++ arch/arm/boot/dts/exynos5440.dtsi | 12 + arch/arm/mach-exynos/Kconfig |2 + drivers/cpufreq/Kconfig.arm|9 + drivers/cpufreq/Makefile |1 + drivers/cpufreq/exynos-cpufreq.c |2 +- drivers/cpufreq/exynos5440-cpufreq.c | 474 7 files changed, 527 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c Is this for me or the Samsung tree? If it's for me, I need ACKs from the Samsung tree maintainers. Also, please address the Viresh's comments. Thanks, Rafael Hi Rafael, I submitted the V6 version with all comments from Viresh addressed. Hi Kukjin Kim, Any suggestion on how this patch should be merged. In my opinion it should go via Rafael's tree as this patch uses some fixes present in Rafael's tree like modified cpufreq_notify_transition API. Thanks, Amit Daniel -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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/
WARNING: at mm/mmap.c:2702 exit_mmap+0x134/0x160() (SIGILL on sparc64)
While compiling 3.9-5rc6 on sparc64 (Ultrasparc-II Netra X1), I got the following error: [604143.245710] WARNING: at mm/mmap.c:2702 exit_mmap+0x134/0x160() [604143.323469] Modules linked in: ipv6 loop ohci_hcd i2c_ali15x3 usbcore i2c_ali1535 usb_common i2c_core [604143.445845] Call Trace: [604143.479021] [004b7f54] exit_mmap+0x134/0x160 [604143.546570] [004516ec] mmput+0x2c/0xc0 [604143.607248] [0045676c] exit_mm+0xec/0x120 [604143.671352] [0045802c] do_exit+0xec/0x360 [604143.735468] [004583e4] do_group_exit+0x24/0xc0 [604143.805295] [00463424] get_signal_to_deliver+0x1a4/0x320 [604143.886545] [00443d34] do_signal32+0x14/0x220 [604143.955249] [0042c640] do_signal+0x2c0/0x520 [604144.022774] [0042d0a0] do_notify_resume+0x40/0x60 [604144.096054] [00404ac4] __handle_signal+0xc/0x2c [604144.167063] ---[ end trace 485ee697b10175b2 ]--- [604144.228837] BUG: Bad rss-counter state mm:f8006e5123c0 idx:1 val:1 This is not reproducible. The machine has been stable for long and I have seen no other errors. Rerunning the same make produced no errors. -- Meelis Roos (mr...@linux.ee) -- 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: Excessive stall times on ext4 in 3.9-rc2
On Sun, Apr 07, 2013 at 05:59:06PM -0400, Frank Ch. Eigler wrote: Hi - tytso wrote: So I tried to reproduce the problem, and so I installed systemtap (bleeding edge, since otherwise it won't work with development kernel), and then rebuilt a kernel with all of the necessary CONFIG options enabled: CONFIG_DEBUG_INFO, CONFIG_KPROBES, CONFIG_RELAY, CONFIG_DEBUG_FS, CONFIG_MODULES, CONFIG_MODULE_UNLOAD [...] That sounds about right. I then pulled down mmtests, and tried running watch-dstate.pl, which is what I assume you were using [...] I just took a look at the mmtests, particularly the stap-fix.sh stuff. The heroics therein are really not called for. git kernel developers should use git systemtap, as has always been the case. All compatibility hacks in stap-fix.sh have already been merged, in many cases for months. At one point in the past this used to be the case but then systemtap had to be compiled as part of automated tests across different kernel versions. It could have been worked around in various ways or even installed manually when machines were deployed but stap-fix.sh generally took less time to keep working. [...] semantic error: while resolving probe point: identifier 'kprobe' at /tmp/stapdjN4_l:18:7 source: probe kprobe.function(get_request_wait) ^ Pass 2: analysis failed. [man error::pass2] Unexpected exit of STAP script at ./watch-dstate.pl line 296. I have no clue what to do next. Can you give me a hint? You should see the error::pass2 man page, which refers to error::reporting, which refers to involving stap folks and running stap-report to gather needed info. But in this case, that's unnecessary: the problem is most likely that the get_request_wait function does not actually exist any longer, since commit a06e05e6afab70b4b23c0a7975aaeae24b195cd6 Author: Tejun Heo t...@kernel.org Date: Mon Jun 4 20:40:55 2012 -0700 block: refactor get_request[_wait]() Yes, this was indeed the problem. The next version of watch-dstate.pl treated get_request_wait() as a function that may or may not exist. It uses /proc/kallsyms to figure it out. Thanks. -- Mel Gorman SUSE Labs -- 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 RFC] watchdog: core: don't try to stop device if not running
On 04/08/2013 10:16 AM, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 09:48:57AM +0200, Hector Palacios wrote:
On 04/05/2013 08:34 PM, Guenter Roeck wrote:
On Fri, Apr 05, 2013 at 06:09:44PM +0200, Hector Palacios wrote:
A watchdog device may be stopped from userspace using WDIOC_SETOPTIONS
ioctl and flag WDIOS_DISABLECARD. If the device is closed after this
operation, watchdog_release() is called and status bits checked for
stopping it. Besides, if the device has not been unregistered a critical
message watchdog did not stop! is printed, although the ioctl may have
successfully stopped it already.
Without the patch a user application sample code like this will successfully
stop the watchdog, but the kernel will output the message
watchdog did not stop!:
wd_fd = open(/dev/watchdog, O_RDWR);
flags = WDIOS_DISABLECARD;
ioctl(wd_fd, WDIOC_SETOPTIONS, flags);
close(wd_fd);
Signed-off-by: Hector Palacios hector.palac...@digi.com
How about the following patch instead ?
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 08b48bb..9775e8d 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -469,7 +469,9 @@ static int watchdog_release(struct inode *inode, struct
file *file)
* or if WDIOF_MAGICCLOSE is not set. If nowayout was set then
* watchdog_stop will fail.
*/
- if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
+ if (!test_bit(WDOG_ACTIVE, wdd-status))
+ err = 0;
+ else if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
!(wdd-info-options WDIOF_MAGICCLOSE))
err = watchdog_stop(wdd);
Much less invasive and the result is the same.
I like the simplicity but it is kind of inverted logic to initially
define err = -EBUSY only to turn it to zero later, so I'm rebuilding
your approach like this:
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index ef8edec..a4163cd 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -463,16 +463,19 @@ out:
static int watchdog_release(struct inode *inode, struct file *file)
{
struct watchdog_device *wdd = file-private_data;
- int err = -EBUSY;
+ int err = 0;
/*
* We only stop the watchdog if we received the magic character
* or if WDIOF_MAGICCLOSE is not set. If nowayout was set then
* watchdog_stop will fail.
*/
- if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
- !(wdd-info-options WDIOF_MAGICCLOSE))
+ if (test_bit(WDOG_ACTIVE, wdd-status))
+ err = -EBUSY;
+ else if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
+ !(wdd-info-options WDIOF_MAGICCLOSE)) {
err = watchdog_stop(wdd);
+ }
Ok, but the added { } are unnecessary and violate coding style rules.
Oops. Remainders of a debug message. Thanks for pointing out.
--
Héctor Palacios
--
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 V6 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
On 8 April 2013 13:47, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index f3f3b14..bce2195 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ
This adds the CPUFreq driver for Samsung EXYNOS5250
SoC.
+config ARM_EXYNOS5440_CPUFREQ
+ def_bool SOC_EXYNOS5440
+ depends on HAVE_CLK PM_OPP OF
Don't you need a depend on your Soc or mach or arch? Don't send another
version for this now.. Just send a new patch over this patchset.
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
+static int exynos_target(struct cpufreq_policy *policy,
+ unsigned int target_freq,
+ unsigned int relation)
+{
+ unsigned int index, tmp;
+ int ret = 0, i;
+ struct cpufreq_frequency_table *freq_table = dvfs_info-freq_table;
+
+ mutex_lock(cpufreq_lock);
+ freqs.old = dvfs_info-cur_frequency;
+
+ ret = cpufreq_frequency_table_target(policy, freq_table,
+ target_freq, relation, index);
+ if (ret)
+ goto out;
+
Move freqs.old = *** here.
+ freqs.new = freq_table[index].frequency;
+ freqs.cpu = policy-cpu;
You don't need this. Below call takes care of it.
Rest is fine.. Just resend this patch with all above issues fixed and i will Ack
it without any further reviews :)
Don't wait for few days for doing this, send it right now. :)
--
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/
[Pull request] bcache data offset
Hello, These patches update the bcache superblock format so that backing device data can be at an arbitrary offset from the start of the backing device; this helps convert partitions or logical volumes to bcache in-place, and https://github.com/g2p/blocks has been updated to use the new format. The kernel half is on top of bcache-for-upstream, the bcache-tools half is on top of the development version of bcache-tools. They can be pulled from - https://github.com/g2p/linux/tree/bcache-for-upstream - https://github.com/g2p/bcache-tools/tree/enable-data-offset -- 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] bcache: Take data offset from the bdev superblock.
Add a new superblock version, and consolidate related defines.
Signed-off-by: Gabriel de Perthuis g2p.code+bca...@gmail.com
---
drivers/md/bcache/bcache.h | 23 ++-
drivers/md/bcache/request.c | 2 +-
drivers/md/bcache/super.c | 21 -
3 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
index f057235..8a110e6 100644
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -223,11 +223,17 @@ struct bkey {
#define BKEY_PADDED(key) \
union { struct bkey key; uint64_t key ## _pad[BKEY_PAD]; }
-/* Version 1: Backing device
+/* Version 0: Cache device
+ * Version 1: Backing device
* Version 2: Seed pointer into btree node checksum
- * Version 3: New UUID format
+ * Version 3: Cache device with new UUID format
+ * Version 4: Backing device with data offset
*/
-#define BCACHE_SB_VERSION 3
+#define BCACHE_SB_VERSION_CDEV 0
+#define BCACHE_SB_VERSION_BDEV 1
+#define BCACHE_SB_VERSION_CDEV_WITH_UUID 3
+#define BCACHE_SB_VERSION_BDEV_WITH_OFFSET 4
+#define BCACHE_SB_MAX_VERSION 4
#define SB_SECTOR 8
#define SB_SIZE4096
@@ -236,13 +242,12 @@ struct bkey {
/* SB_JOURNAL_BUCKETS must be divisible by BITS_PER_LONG */
#define MAX_CACHES_PER_SET 8
-#define BDEV_DATA_START16 /* sectors */
+#define BDEV_DATA_START_DEFAULT16 /* sectors */
struct cache_sb {
uint64_tcsum;
uint64_toffset; /* sector where this sb was written */
uint64_tversion;
-#define CACHE_BACKING_DEV 1
uint8_t magic[16];
@@ -485,6 +490,7 @@ struct cached_dev {
* where it's at.
*/
sector_tlast_read;
+ sector_tdata_start_sector;
/* Number of writeback bios in flight */
atomic_tin_flight;
@@ -861,6 +867,13 @@ static inline bool key_merging_disabled(struct cache_set
*c)
#endif
}
+
+static inline bool SB_IS_BDEV(const struct cache_sb *sb) {
+ return sb-version == BCACHE_SB_VERSION_BDEV
+ || sb-version == BCACHE_SB_VERSION_BDEV_WITH_OFFSET;
+}
+
+
struct bbio {
unsignedsubmit_time_us;
union {
diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index 83731dc..9f74aff 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -1220,7 +1220,7 @@ static void cached_dev_make_request(struct request_queue
*q, struct bio *bio)
part_stat_unlock();
bio-bi_bdev = dc-bdev;
- bio-bi_sector += BDEV_DATA_START;
+ bio-bi_sector += dc-data_start_sector;
if (cached_dev_get(dc)) {
s = search_alloc(bio, d);
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 5fa3cd2..a409bb5 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -148,7 +148,7 @@ static const char *read_super(struct cache_sb *sb, struct
block_device *bdev,
goto err;
err = Unsupported superblock version;
- if (sb-version BCACHE_SB_VERSION)
+ if (sb-version BCACHE_SB_MAX_VERSION)
goto err;
err = Bad block/bucket size;
@@ -168,7 +168,7 @@ static const char *read_super(struct cache_sb *sb, struct
block_device *bdev,
if (get_capacity(bdev-bd_disk) sb-bucket_size * sb-nbuckets)
goto err;
- if (sb-version == CACHE_BACKING_DEV)
+ if (SB_IS_BDEV(sb))
goto out;
err = Bad UUID;
@@ -286,7 +286,7 @@ void bcache_write_super(struct cache_set *c)
for_each_cache(ca, c, i) {
struct bio *bio = ca-sb_bio;
- ca-sb.version = BCACHE_SB_VERSION;
+ ca-sb.version = BCACHE_SB_VERSION_CDEV_WITH_UUID;
ca-sb.seq = c-sb.seq;
ca-sb.last_mount = c-sb.last_mount;
@@ -1047,9 +1047,20 @@ static const char *register_bdev(struct cache_sb *sb,
struct page *sb_page,
dc-bdev = bdev;
dc-bdev-bd_holder = dc;
+ err = bad start sector;
+ if (sb-version == BCACHE_SB_VERSION_BDEV) {
+ dc-data_start_sector = BDEV_DATA_START_DEFAULT;
+ } else {
+ if (sb-keys 1)
+ goto err;
+ dc-data_start_sector = sb-d[0];
+ if (dc-data_start_sector BDEV_DATA_START_DEFAULT)
+ goto err;
+ }
+
g = dc-disk.disk;
- set_capacity(g, dc-bdev-bd_part-nr_sects - 16);
+ set_capacity(g, dc-bdev-bd_part-nr_sects - dc-data_start_sector);
bch_cached_dev_request_init(dc);
@@ -1802,7 +1813,7 @@ static ssize_t register_bcache(struct kobject *k, struct
[Resend with Ack][PATCH] mm: remove CONFIG_HOTPLUG ifdefs
CONFIG_HOTPLUG is going away as an option, cleanup CONFIG_HOTPLUG
ifdefs in mm files.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Minchan Kim minc...@kernel.org
Cc: Mel Gorman mgor...@suse.de
Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Cc: Rik van Riel r...@redhat.com
Cc: Hugh Dickins hu...@google.com
Cc: Bill Pemberton wf...@virginia.edu
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
include/linux/vmstat.h |7 +--
mm/vmstat.c|2 --
2 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 5fd71a7..c586679 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -48,13 +48,8 @@ static inline void count_vm_events(enum vm_event_item item,
long delta)
}
extern void all_vm_events(unsigned long *);
-#ifdef CONFIG_HOTPLUG
+
extern void vm_events_fold_cpu(int cpu);
-#else
-static inline void vm_events_fold_cpu(int cpu)
-{
-}
-#endif
#else
diff --git a/mm/vmstat.c b/mm/vmstat.c
index e1d8ed1..c823776 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -52,7 +52,6 @@ void all_vm_events(unsigned long *ret)
}
EXPORT_SYMBOL_GPL(all_vm_events);
-#ifdef CONFIG_HOTPLUG
/*
* Fold the foreign cpu events into our own.
*
@@ -69,7 +68,6 @@ void vm_events_fold_cpu(int cpu)
fold_state-event[i] = 0;
}
}
-#endif /* CONFIG_HOTPLUG */
#endif /* CONFIG_VM_EVENT_COUNTERS */
--
1.7.1
--
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] intel-iommu: Synchronize gcmd value with global command register
(2013/04/04 23:24), David Woodhouse wrote: On Thu, 2013-04-04 at 14:48 +0900, Takao Indoh wrote: - DMAR fault messages floods and second kernel does not boot. Recently I saw similar report. https://lkml.org/lkml/2013/3/8/120 Right. So the fix for that is to make the subsequent errors silent, until/unless we actually get a request to create a mapping for the given device. - igb driver detectes error on linkup and kdump via network fails. That's a driver bug, IIRC. It was failing to completely reset the hardware. It's fixed now, isn't it? No, it can be reproduced with latest kernel(3.9.0-rc6). - On a certain platform, though kdump itself works, PCIe error like Unexpected Completion is detected and it gets hardware degraded. More information required. When I tested intel_iommu on a certain machine, the following error message was logged in its firmware, and I/O board got abnormal status. 05:00.0 is igb, so I think this was caused by DMA error on igb. This occurs before igb driver loading, so this cannot be fixed in driver. PCI: Unexpected Completion Bus: 5 Device: 0x00 Function: 0x00 Anyway, I'm thinking we should introduce something framework to clean all devices to stop DMA at boot time rather than dealing with the problem in each driver. And one of the way I found is resetting devcies by PCIe layer. If DMAR is disabled in init_dmars(), we can have a chance to handle devices to stop DMA in PCI layer, like qci-quirk. This is one of the reason why I propose this patch. Thanks, Takao Indoh -- 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] mm/memcontrol.c: trivial fix - remove unnecessary ;
Just a trivial issue I stumbled on while doing something else...
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2b552224f5cf..dceee534b4b5 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5744,7 +5744,7 @@ static int memcg_init_kmem(struct mem_cgroup *memcg,
struct cgroup_subsys *ss)
return ret;
return mem_cgroup_sockets_init(memcg, ss);
-};
+}
static void kmem_cgroup_destroy(struct mem_cgroup *memcg)
{
--
Michel Walken Lespinasse
A program is never fully debugged until the last user dies.
--
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 PATCH v2 2/6] powerpc: Exception hooks for context tracking subsystem
On Fri, 2013-04-05 at 13:50 +1100, Paul Mackerras wrote: On Fri, Mar 29, 2013 at 06:00:17PM +0800, Li Zhong wrote: This is the exception hooks for context tracking subsystem, including data access, program check, single step, instruction breakpoint, machine check, alignment, fp unavailable, altivec assist, unknown exception, whose handlers might use RCU. This patch corresponds to [PATCH] x86: Exception hooks for userspace RCU extended QS commit 6ba3c97a38803883c2eee489505796cb0a727122 Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com Hi Paul, Thanks for your review! Please check my answers below, and correct me if any errors. Is there a reason why you didn't put the exception_exit() call in ret_from_except_lite in entry_64.S, and the exception_entry() call in EXCEPTION_PROLOG_COMMON? That would seem to catch all these cases in a more centralized place. It seems to me that ret_from_except_lite and EXCEPTION_PROLOG_COMMON are also used by interrupts, where I think we don't need the hooks. So using this way could help to avoid adding overhead to these code path (interrupts, and some exit path of syscall). And I think adding the hook on higher level code seems a little easier for reading and checking. It seems that some exceptions don't use EXCEPTION_PROLOG_COMMON, and some don't go ret_from_except_lite exit path (like fp unavailable might go directly to fast_exception_return ). Maybe fast_exception_return is a centralized place for us to return to user space? But it still adds some overheads which is not necessarily needed. And I think it also makes the implementation here consistent with the style that x86 uses. Also, I notice that with the exception_exit calls where they are, we can still deliver signals (thus possibly taking a page fault) or call schedule() for preemption after the exception_exit() call. Is that OK, or is it a potential problem? If I understand correctly, I guess you are talking about the cases where we might return to user space without context state correctly being set as in user? There is user_enter() called in do_notify_resume() in patch #3, so after handling the signals we always call user_enter(). There are also some changes of the context_tracking code from Frederic, which might be related: ( they are now in tip tree, and url of the patches for your convenience https://lkml.org/lkml/2013/3/1/266 ) 6c1e0256fad84a843d915414e4b5973b7443d48d context_tracking: Restore correct previous context state on exception exit. With this patch, if a later exception happened after user_enter(), before the CPU actually returns to user space, the correct context state(in user) is saved and restored when handling the later exception. Patch #6 converts the code to use these new APIs, which is currently not available in powerpc tree. b22366cd54c6fe05db426f20adb10f461c19ec06 context_tracking: Restore preempted context state after preempt_schedule_irq With this patch, the user context state could be correctly restored after schedule returns. Thanks, Zhong Paul. -- 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/PATCH] perf: Expand definition of sysfs format attribute
On Mon, 2013-03-04 at 15:21 +1100, Michael Ellerman wrote: Make it explicit that the format attributes may define overlapping bit ranges. Unfortunately this was left unspecified originally, and all the examples show non-overlapping ranges. I don't believe this is an ABI change, as we are defining something that was previously undefined, but others may disagree. The POWER8 PMU would like to define overlapping ranges, as bit ranges in the event code have different meanings for certain events. It will also allow us to define an overarching event field, that encompasses all others. As far as I can see perf is comfortable with this change, however I am not sure if there are any other users of the interface. Signed-off-by: Michael Ellerman mich...@ellerman.id.au --- Documentation/ABI/testing/sysfs-bus-event_source-devices-format |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format index 079afc7..77f47ff 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format @@ -9,6 +9,12 @@ Description: we want to export, so that userspace can deal with sane name/value pairs. + Userspace must be prepared for the possibility that attributes + define overlapping bit ranges. For example: + attr1 = 'config:0-23' + attr2 = 'config:0-7' + attr3 = 'config:12-35' + Example: 'config1:1,6-10,44' Defines contents of attribute that occupies bits 1,6-10,44 of perf_event_attr::config1. ISTR discussing this with Jiri at some point.. I think we ended up with being fine with overlapping ranges but having perf issue a warning (not an error) when attributes of a single event have overlap. I'm not sure the latter was ever implemented in the userspace side. -- 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 6/6] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
On Saturday, March 23, 2013 1:09 PM, Jingoo Han wrote:
Exynos5440 has two PCIe controllers which can be used as root complex
for PCIe interface.
Signed-off-by: Jingoo Han jg1@samsung.com
---
arch/arm/boot/dts/exynos5440-ssdk5440.dts |8 +++
arch/arm/boot/dts/exynos5440.dtsi | 32
+
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
index a21eb4c..746f9fc 100644
--- a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
+++ b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
@@ -34,4 +34,12 @@
clock-frequency = 5000;
};
};
+
+ pcie0@4000 {
+ reset-gpio = 5;
+ };
+
+ pcie1@6000 {
+ reset-gpio = 22;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index c374a31..41b2d2c 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -178,4 +178,36 @@
clocks = clock 21;
clock-names = rtc;
};
+
+ pcie0@4000 {
+ compatible = samsung,exynos5440-pcie;
+ reg = 0x4000 0x4000
+ 0x29 0x1000
+ 0x27 0x1000
+ 0x271000 0x40;
+ interrupts = 0 20 0, 0 21 0, 0 22 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ device_type = pci;
+ bus-range = 0x0 0xf;
+ ranges = 0x0800 0 0x4000 0x4000 0 0x0020 /*
configuration space */
+ 0x8100 0 0 0x4020 0 0x4000 /*
downstream I/O */
+ 0x8200 0 0 0x40204000 0 0x1000; /*
non-prefetchable memory */
+ };
+
+ pcie1@6000 {
+ compatible = samsung,exynos5440-pcie;
+ reg = 0x6000 0x4000
+ 0x2a 0x1000
+ 0x272000 0x1000
+ 0x271040 0x40;
+ interrupts = 0 23 0, 0 24 0, 0 25 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ device_type = pci;
+ bus-range = 0x0 0xf;
+ ranges = 0x0800 0 0x6000 0x6000 0 0x0020 /*
configuration space */
+ 0x8100 0 0 0x6020 0 0x4000 /*
downstream I/O */
+ 0x8200 0 0 0x60204000 0 0x1000; /*
non-prefetchable memory */
+ };
Hi Jason,
I have a question.
Now, I am reviewing the Tegra PCIe, Marvell PCIe patchset.
However, in the case of Exynos PCIe,
'downstream I/O' and 'non-prefetchable memory' are different between PCIe0 and
PCIe1.
These regions are not shared.
PCIe0:
ranges = 0x0800 0 0x4000 0x4000 0 0x0020 /*
configuration space */
0x8100 0 0 0x4020 0 0x4000 /*
downstream I/O */
0x8200 0 0 0x40204000 0 0x1000; /*
non-prefetchable memory */
PCIe1:
ranges = 0x0800 0 0x4000 0x4000 0 0x0020 /*
configuration space */
0x8100 0 0 0x4020 0 0x4000 /*
downstream I/O */
0x8200 0 0 0x40204000 0 0x1000; /*
non-prefetchable memory */
PCIe0 uses 0x4000~0x5fff, PCI1 uses 0x6000~0x7fff.
How can I handle this? :)
The following is right?
+ pcie-controller {
.
+ ranges = 0x8200 0 0x4000 0x4000 0 0x0020 /*
port 0 registers */
+ 0x8200 0 0x6000 0x6000 0 0x0020 /*
port 1 registers */
+ 0x8100 0 0 0x4020 0 0x4000 /*
port 0 downstream I/O */
+ 0x8100 0 0 0x6020 0 0x4000 /*
port 1 downstream I/O */
+ 0x8200 0 0x40204000 0x40204000 0 0x1000; /*
port 0 non-prefetchable memory */
+ 0x8200 0 0x40204000 0x60204000 0 0x1000; /*
port 1 non-prefetchable memory */
+
+ pci@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0x4000 0
0x0020
+ 0x81000800 0 0x4020 0
0x4000
+ 0x81000800 0 0x40204000 0
0x1000;
.
+ pci@2,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0x6000 0
0x0020
+ 0x81000800 0 0x6020 0
0x4000
+ 0x81000800 0 0x60204000 0
0x1000;
Best regards,
Jingoo Han
};
--
Re: Version number policy!
Thanx Christian for a valuable input. It’s a good idea to pack bitmap into the tail/header of the firmware binary to get capabilities even before fw loading. The plan is to add 8 bytes for caps and also add time stamp. Let me play around with that and provide fw and driver patch for review. 2013/4/6 Adrian Chadd adr...@freebsd.org: On 5 April 2013 22:52, Kalle Valo kv...@adurom.com wrote: Eugene Krasnikov k.eugen...@gmail.com writes: Good point regarding timestamp. When it comes to feature bitmap do you have an example of such a bitmap from carl9170? Why not to rely always on major version? I'm with Christian here. In ath6kl we switched to firmware advertising feature capabilities and I have never looked back, it's so much easier. You don't need to do any mapping between firmware versions and features, you just deal one feature at a time. Ok. Well, we've got plenty of time to finalise this before things get established. There's still plenty of tidying up to do before we start pushing in new features. Thanks for all your feedback so far! Adrian -- Best regards, Eugene -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 3/3] ARM: davinci: da850: add EHRPWM ECAP DT node
On Tue, Apr 02, 2013 at 14:03:34, Nori, Sekhar wrote: On 3/25/2013 1:19 PM, Philip Avinash wrote: Add da850 EHRPWM ECAP DT node. Also adds OF_DEV_AUXDATA for EHRPWM ECAP driver to use EHRPWM ECAP clock. This looks fine to me but I will wait for the bindings to get accepted before taking this one. Sekhar, Binding document got accepted in PWM tree [1]. Can you accept this patch? 1. https://gitorious.org/linux-pwm Thanks Avinash Thanks, Sekhar
[PATCH v2] watchdog: core: don't try to stop device if not running
A watchdog device may be stopped from userspace using WDIOC_SETOPTIONS
ioctl and flag WDIOS_DISABLECARD. If the device is closed after this
operation, watchdog_release() is called and status bits checked for
stopping it. Besides, if the device has not been unregistered a critical
message watchdog did not stop! is printed, although the ioctl may have
successfully stopped it already.
Without the patch a user application sample code like this will successfully
stop the watchdog, but the kernel will output the message
watchdog did not stop!:
wd_fd = open(/dev/watchdog, O_RDWR);
flags = WDIOS_DISABLECARD;
ioctl(wd_fd, WDIOC_SETOPTIONS, flags);
close(wd_fd);
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
Changes from v1:
- Make it less intrusive with 'if/else if' clauses
- Change the logic of 'err' variable for better readability of code
- Remove one-liner if brackets that broke coding sytle
drivers/watchdog/watchdog_dev.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index ef8edec..8e0f1b8 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -463,15 +463,17 @@ out:
static int watchdog_release(struct inode *inode, struct file *file)
{
struct watchdog_device *wdd = file-private_data;
- int err = -EBUSY;
+ int err = 0;
/*
* We only stop the watchdog if we received the magic character
* or if WDIOF_MAGICCLOSE is not set. If nowayout was set then
* watchdog_stop will fail.
*/
- if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
- !(wdd-info-options WDIOF_MAGICCLOSE))
+ if (test_bit(WDOG_ACTIVE, wdd-status))
+ err = -EBUSY;
+ else if (test_and_clear_bit(WDOG_ALLOW_RELEASE, wdd-status) ||
+!(wdd-info-options WDIOF_MAGICCLOSE))
err = watchdog_stop(wdd);
/* If the watchdog was not stopped, send a keepalive ping */
--
1.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mac80211_hwsim: Register and bind to driver
Looks fine, but ... @@ -2179,6 +2183,8 @@ static int __init init_mac80211_hwsim(void) if (IS_ERR(hwsim_class)) return PTR_ERR(hwsim_class); + driver_register(mac80211_hwsim_driver); + memset(addr, 0, ETH_ALEN); addr[0] = 0x02; I think you forgot to update the error path to unregister the driver. johannes -- 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] mac80211_hwsim: Register and bind to driver
Properly register our mac80211_hwsim_driver, attach it to the platform bus.
Bind newly created hwsim devices to that driver, so that our wlan devices get
a proper driver sysfs attribute.
This makes mac80211_hwsim interfaces work with NetworkManager.
Signed-off-by: Martin Pitt martin.p...@ubuntu.com
---
drivers/net/wireless/mac80211_hwsim.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 0064d38..50a8b52 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -25,6 +25,7 @@
#include linux/if_arp.h
#include linux/rtnetlink.h
#include linux/etherdevice.h
+#include linux/platform_device.h
#include linux/debugfs.h
#include linux/module.h
#include linux/ktime.h
@@ -1675,6 +1676,7 @@ static void mac80211_hwsim_free(void)
debugfs_remove(data-debugfs_ps);
debugfs_remove(data-debugfs);
ieee80211_unregister_hw(data-hw);
+ device_release_driver(data-dev);
device_unregister(data-dev);
ieee80211_free_hw(data-hw);
}
@@ -1683,7 +1685,9 @@ static void mac80211_hwsim_free(void)
static struct device_driver mac80211_hwsim_driver = {
- .name = mac80211_hwsim
+ .name = mac80211_hwsim,
+ .bus = platform_bus_type,
+ .owner = THIS_MODULE,
};
static const struct net_device_ops hwsim_netdev_ops = {
@@ -2179,6 +2183,8 @@ static int __init init_mac80211_hwsim(void)
if (IS_ERR(hwsim_class))
return PTR_ERR(hwsim_class);
+ driver_register(mac80211_hwsim_driver);
+
memset(addr, 0, ETH_ALEN);
addr[0] = 0x02;
@@ -2205,6 +2211,14 @@ static int __init init_mac80211_hwsim(void)
goto failed_drvdata;
}
data-dev-driver = mac80211_hwsim_driver;
+ err = device_bind_driver(data-dev);
+ if (err != 0) {
+ printk(KERN_DEBUG
+ mac80211_hwsim: device_bind_driver
+ failed (%d)\n, err);
+ goto failed_hw;
+ }
+
skb_queue_head_init(data-pending);
SET_IEEE80211_DEV(hw, data-dev);
@@ -2518,5 +2532,6 @@ static void __exit exit_mac80211_hwsim(void)
mac80211_hwsim_free();
unregister_netdev(hwsim_mon);
+ driver_unregister(mac80211_hwsim_driver);
}
module_exit(exit_mac80211_hwsim);
--
1.7.2.5
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
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 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
Rafael J. Wysocki wrote: On Friday, April 05, 2013 12:36:34 PM Viresh Kumar wrote: On 5 April 2013 12:18, Kukjin Kim kgene@samsung.com wrote: Basically, this moving looks good to me, but should be re-worked based on for-next of samsung tree because this touches too many samsung stuff so this should be sent to upstream via samsung tree. Hmm... Its already applied in Rafael's tree. But it doesn't mean that it can't be moved to your tree if there is a issue. Well, I'm dropping it. Please merge via the Samsung tree. OK, I will. I got patch file from Viresh, and there is a sign from Rafael, but it should be ack. So Rafael, let me use your ack on this patch when I apply. If any problems, please let me know. Thanks. - Kukjin -- 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 V6 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
On 8 April 2013 14:17, Viresh Kumar viresh.ku...@linaro.org wrote: On 8 April 2013 13:47, Amit Daniel Kachhap amit.dan...@samsung.com wrote: diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index f3f3b14..bce2195 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ This adds the CPUFreq driver for Samsung EXYNOS5250 SoC. +config ARM_EXYNOS5440_CPUFREQ + def_bool SOC_EXYNOS5440 + depends on HAVE_CLK PM_OPP OF Don't you need a depend on your Soc or mach or arch? Don't send another version for this now.. Just send a new patch over this patchset. Sorry, i overlooked def_bool... This comments stands invalid. -- 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 v9 0/2] ARM: davinci: add support for dm365 vpbe display
From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch series enables VPBE display driver on DM365. Changes for v9: 1: Removed extra line after break's and defines as pointed by Sekhar. 2: Included Ack's from Sekhar. Changes for v8: 1: Fixed nits pointed by Sekhar. Changes for v7: 1: Fixed nits pointed by Sekhar. Changes for v6: 1: Fixed review comments pointed by Sekhar. Changes for v5: 1: pass different platform names to handle different ip's. 2: Fixed review comments pointed by Sekhar. Changes for v4: 1: Replaced the obsolete preset API by timings API. Changes for v3: 1: Removed VPSS clock alias for master and slave which was sent for VPSS driver. since this patch was dependent on patch[1]. I will revist this patch once MC(captrure driver) goes into mainline. [1] http://www.spinics.net/lists/linux-media/msg50562.html Changes for v2: 1: Added VPSS clock so that capture and display can work independent. Lad, Prabhakar (2): ARM: davinci: dm365: add support for v4l2 video display ARM: davinci: dm365 EVM: add support for VPBE display arch/arm/mach-davinci/board-dm365-evm.c | 166 +++- arch/arm/mach-davinci/davinci.h |7 +- arch/arm/mach-davinci/dm365.c | 184 --- 3 files changed, 340 insertions(+), 17 deletions(-) -- 1.7.4.1 -- 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 v9 1/2] ARM: davinci: dm365: add support for v4l2 video display
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm365.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Acked-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/board-dm365-evm.c |4 +-
arch/arm/mach-davinci/davinci.h |7 +-
arch/arm/mach-davinci/dm365.c | 184 ---
3 files changed, 178 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index c2d4958..cf77c46 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -564,8 +564,6 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm365_evm_map_io(void)
{
- /* setup input configuration for VPFE input devices */
- dm365_set_vpfe_config(vpfe_cfg);
dm365_init();
}
@@ -597,6 +595,8 @@ static __init void dm365_evm_init(void)
davinci_setup_mmc(0, dm365evm_mmc_config);
+ dm365_init_video(vpfe_cfg, NULL);
+
/* maybe setup mmc1/etc ... _after_ mmc0 */
evm_init_cpld();
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..a9de512 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -36,8 +36,13 @@
#include media/davinci/vpbe_osd.h
#define DAVINCI_SYSTEM_MODULE_BASE 0x01c4
+#define SYSMOD_VDAC_CONFIG 0x2c
#define SYSMOD_VIDCLKCTL 0x38
#define SYSMOD_VPSS_CLKCTL 0x44
+#define VPSS_VENCCLKEN_ENABLE BIT(3)
+#define VPSS_DACCLKEN_ENABLE BIT(4)
+#define VPSS_PLLC2SYSCLK5_ENABLE BIT(5)
+
#define SYSMOD_VDD3P3VPWDN 0x48
#define SYSMOD_VSCLKDIS0x6c
#define SYSMOD_PUPDCTL10x7c
@@ -84,7 +89,7 @@ void __init dm365_init_ks(struct davinci_ks_platform_data
*pdata);
void __init dm365_init_rtc(void);
void dm365_init_spi0(unsigned chipselect_mask,
const struct spi_board_info *info, unsigned len);
-void dm365_set_vpfe_config(struct vpfe_config *cfg);
+int dm365_init_video(struct vpfe_config *, struct vpbe_config *);
/* DM644x function declarations */
void __init dm644x_init(void);
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index c61dd94..ff771ce 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -39,16 +39,13 @@
#include asp.h
#define DM365_REF_FREQ 2400/* 24 MHz on the DM365 EVM */
-
-/* Base of key scan register bank */
-#define DM365_KEYSCAN_BASE 0x01c69400
-
#define DM365_RTC_BASE 0x01c69000
-
+#define DM365_KEYSCAN_BASE 0x01c69400
+#define DM365_OSD_BASE 0x01c71c00
+#define DM365_VENC_BASE0x01c71e00
#define DAVINCI_DM365_VC_BASE 0x01d0c000
#define DAVINCI_DMA_VC_TX 2
#define DAVINCI_DMA_VC_RX 3
-
#define DM365_EMAC_BASE0x01d07000
#define DM365_EMAC_MDIO_BASE (DM365_EMAC_BASE + 0x4000)
#define DM365_EMAC_CNTRL_OFFSET0x
@@ -1233,6 +1230,173 @@ static struct platform_device dm365_isif_dev = {
},
};
+static struct resource dm365_osd_resources[] = {
+ {
+ .start = DM365_OSD_BASE,
+ .end = DM365_OSD_BASE + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm365_video_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm365_osd_dev = {
+ .name = DM365_VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm365_osd_resources),
+ .resource = dm365_osd_resources,
+ .dev= {
+ .dma_mask = dm365_video_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+static struct resource dm365_venc_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end = IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* venc registers io space */
+ {
+ .start = DM365_VENC_BASE,
+ .end = DM365_VENC_BASE + 0x177,
+ .flags = IORESOURCE_MEM,
+ },
+ /* vdaccfg registers io space */
+ {
+ .start = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG,
+ .end = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG + 3,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct resource dm365_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end = IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* venc registers io space */
+ {
+ .start = DM365_VENC_BASE,
+ .end = DM365_VENC_BASE +
[PATCH v9 2/2] ARM: davinci: dm365 EVM: add support for VPBE display
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add support for V4L2 video display to DM365 EVM.
Support for SD and ED modes is provided, along with Composite
and Component outputs.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Acked-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/board-dm365-evm.c | 164 ++-
1 files changed, 163 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index cf77c46..0518ce5 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -27,6 +27,7 @@
#include linux/input.h
#include linux/spi/spi.h
#include linux/spi/eeprom.h
+#include linux/v4l2-dv-timings.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -39,6 +40,7 @@
#include linux/platform_data/mtd-davinci.h
#include linux/platform_data/keyscan-davinci.h
+#include media/ths7303.h
#include media/tvp514x.h
#include davinci.h
@@ -374,6 +376,166 @@ static struct vpfe_config vpfe_cfg = {
.ccdc = ISIF,
};
+/* venc standards timings */
+static struct vpbe_enc_mode_info dm365evm_enc_std_timing[] = {
+ {
+ .name = ntsc,
+ .timings_type = VPBE_ENC_STD,
+ .std_id = V4L2_STD_525_60,
+ .interlaced = 1,
+ .xres = 720,
+ .yres = 480,
+ .aspect = {11, 10},
+ .fps= {3, 1001},
+ .left_margin= 0x79,
+ .upper_margin = 0x10,
+ },
+ {
+ .name = pal,
+ .timings_type = VPBE_ENC_STD,
+ .std_id = V4L2_STD_625_50,
+ .interlaced = 1,
+ .xres = 720,
+ .yres = 576,
+ .aspect = {54, 59},
+ .fps= {25, 1},
+ .left_margin= 0x7E,
+ .upper_margin = 0x16,
+ },
+};
+
+/* venc dv timings */
+static struct vpbe_enc_mode_info dm365evm_enc_preset_timing[] = {
+ {
+ .name = 480p59_94,
+ .timings_type = VPBE_ENC_DV_TIMINGS,
+ .dv_timings = V4L2_DV_BT_CEA_720X480P59_94,
+ .interlaced = 0,
+ .xres = 720,
+ .yres = 480,
+ .aspect = {1, 1},
+ .fps= {5994, 100},
+ .left_margin= 0x8F,
+ .upper_margin = 0x2D,
+ },
+ {
+ .name = 576p50,
+ .timings_type = VPBE_ENC_DV_TIMINGS,
+ .dv_timings = V4L2_DV_BT_CEA_720X576P50,
+ .interlaced = 0,
+ .xres = 720,
+ .yres = 576,
+ .aspect = {1, 1},
+ .fps= {50, 1},
+ .left_margin= 0x8C,
+ .upper_margin = 0x36,
+ },
+ {
+ .name = 720p60,
+ .timings_type = VPBE_ENC_DV_TIMINGS,
+ .dv_timings = V4L2_DV_BT_CEA_1280X720P60,
+ .interlaced = 0,
+ .xres = 1280,
+ .yres = 720,
+ .aspect = {1, 1},
+ .fps= {60, 1},
+ .left_margin= 0x117,
+ .right_margin = 70,
+ .upper_margin = 38,
+ .lower_margin = 3,
+ .hsync_len = 80,
+ .vsync_len = 5,
+ },
+ {
+ .name = 1080i60,
+ .timings_type = VPBE_ENC_DV_TIMINGS,
+ .dv_timings = V4L2_DV_BT_CEA_1920X1080I60,
+ .interlaced = 1,
+ .xres = 1920,
+ .yres = 1080,
+ .aspect = {1, 1},
+ .fps= {30, 1},
+ .left_margin= 0xc9,
+ .right_margin = 80,
+ .upper_margin = 30,
+ .lower_margin = 3,
+ .hsync_len = 88,
+ .vsync_len = 5,
+ },
+};
+
+#define VENC_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * the order same as that of encoders. First those from venc followed by that
+ * from encoders. Index in the output refers to index on a particular
+ * encoder.Driver uses this index to pass it to encoder when it supports more
+ * than one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm365evm_vpbe_outputs[] = {
+ {
+ .output = {
+ .index = 0,
+ .name = Composite,
+ .type =
Re: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 8 April 2013 14:45, Kukjin Kim kgene@samsung.com wrote: Rafael J. Wysocki wrote: Well, I'm dropping it. Please merge via the Samsung tree. OK, I will. I got patch file from Viresh, and there is a sign from Rafael, but it should be ack. So Rafael, let me use your ack on this patch when I apply. If any problems, please let me know. Ahh.. I forgot to remove it. I picked the initial patch from Rafael's tree. But yes, you need it anyway :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] AB8500 Power and MFD related updates
Hi Lee, On Thu, Mar 07, 2013 at 12:38:59PM +0800, Lee Jones wrote: The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 (2013-03-03 15:11:05 -0800) are available in the git repository at: git://git.linaro.org/people/ljones/linux-3.0-ux500.git for-mfd-and-power I was expecting to get an MFD only branch (Basically what your for-mfd branch looks like, and then the for-mfd-and-power one to be based on the mfd only with the power patches applied on top of it. Now, I have to pull the power patches as well, which is no big deal but not ideal neither. Anyway, I pulled this branch into mfd-next, with a tiny conflict. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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] mfd: adp5520: Use module_i2c_driver()
On Mon, Apr 08, 2013 at 02:05:37PM +0530, Sachin Kamat wrote: On 27 March 2013 14:50, Hennerich, Michael michael.henner...@analog.com wrote: Von: Sachin Kamat [sachin.ka...@linaro.org] Gesendet: Mittwoch, 27. März 2013 09:59 An: device-drivers-de...@blackfin.uclinux.org; LKML Cc: Hennerich, Michael; sa...@linux.intel.com; sachin.ka...@linaro.org Betreff: Re: [PATCH 1/1] mfd: adp5520: Use module_i2c_driver() On 15 March 2013 17:10, Sachin Kamat sachin.ka...@linaro.org wrote: module_i2c_driver() removes some boilerplate and makes the code simple. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Acked-by: Michael Hennerich michael.henner...@analog.com Ping Samuel. Patch applied to mfd-next, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 failure after merge of the mfd tree
Hi Alexander, On Mon, Apr 08, 2013 at 08:45:51AM +0400, Alexander Shiyan wrote: Hello. After merging the mfd tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/regulator/anatop-regulator.c: In function 'anatop_regulator_probe': drivers/regulator/anatop-regulator.c:134:2: error: implicit declaration of function 'of_get_parent' [-Werror=implicit-function-declaration] Caused by commit 5ab3a89a741f (mfd: syscon: Add non-DT support). I have used the mfd tree from next-20130405 for today. This means that we do not have empty declarations for the of_xx functions in linux/of.h for !CONFIG_OF. OK to declare these functions or any other opinions? Ok with me, but you'd need to get Grant and Rob's ACK. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 kernel/smpboot.c:134!
On Sun, 7 Apr 2013, Borislav Petkov wrote:
On Sun, Apr 07, 2013 at 11:20:10AM +0200, Thomas Gleixner wrote:
And it's even more bogus because the cpu to which we would bind in
kthread_create_on_cpu() is not yet online.
In case you guys are wondering about reproducibility, I saw the same
BUG_ON yesterday on a 32-bit atom smp qemu guest too (don't ask why?
:-))
I don't have to ask. It's caused by massive brain failure on my side.
Does the patch below fix the issue ?
Thanks,
tglx
---
Index: linux-2.6/kernel/kthread.c
===
--- linux-2.6.orig/kernel/kthread.c
+++ linux-2.6/kernel/kthread.c
@@ -131,8 +131,14 @@ static void __kthread_parkme(struct kthr
schedule();
__set_current_state(TASK_INTERRUPTIBLE);
}
- clear_bit(KTHREAD_IS_PARKED, self-flags);
__set_current_state(TASK_RUNNING);
+ clear_bit(KTHREAD_IS_PARKED, self-flags);
+
+ /* Rebind ourself to the target cpu */
+ if (test_bit(KTHREAD_IS_PER_CPU, self-flags)) {
+ set_cpus_allowed_ptr(currrent, cpumask_of(self-cpu));
+ current-flags |= PF_THREAD_BOUND;
+ }
}
void kthread_parkme(void)
@@ -344,11 +350,8 @@ void kthread_unpark(struct task_struct *
* park before that happens we'd see the IS_PARKED bit
* which might be about to be cleared.
*/
- if (test_and_clear_bit(KTHREAD_IS_PARKED, kthread-flags)) {
- if (test_bit(KTHREAD_IS_PER_CPU, kthread-flags))
- __kthread_bind(k, kthread-cpu);
+ if (test_and_clear_bit(KTHREAD_IS_PARKED, kthread-flags))
wake_up_process(k);
- }
}
put_task_struct(k);
}
--
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] increased us/sys-load due to tty-layer in 2.6.38+ ?!
Hi! I noticed a problem with the tty subsystem on ARM. Starting with 2.6.38+ load on the serial connection causes a 10-15% increase in system/userspace load. This doesn't change up to v3.9-rc4. The following setup was used: telnet screen microcom -p /dev/ttyUSB0 | ++ |--|+ | +---+-|+ | | | +--+|| | UUT |-USB-| FTDI |-UART-|| | | +--+| PC | +---+ ++ ^ | telnet top -d1 The unit under test (UUT) is connected via USB-FTDI-UART to a PC. On the PC a while true; do find /; done produces some random output. I connect to the UUT via telnet and then open a serial connection to the PC in a screen session, seeing the output produced on the PC. Then screen gets detached. So, basically, what I'm trying to do is producing load only on the USB-FTDI-UART connection and not on the UUT itself. Then another telnet connection is opened, to monitor the UUT with top -d1. As UUT an imx27, kirkwood and an AT91 were used. To find the offending code, I bisected v2.6.38..v3.0 which gave the following top output (non-scientifically, I know. But the switch in load distribution is obvious nevertheless): 2.6.38 Cpu(s): 3.8%us, 1.9%sy, 0.0%ni, 94.3%id 2.6.38+ Cpu(s): 1.9%us, 3.8%sy, 0.0%ni, 94.3%id last good commit Cpu(s): 1.9%us, 2.8%sy, 0.0%ni, 95.3%id first bad commit Cpu(s): 4.8%us, 14.5%sy, 0.0%ni, 80.6%id 2.6.39-rc4 Cpu(s): 10.5%us, 8.9%sy, 0.0%ni, 79.8%id 3.0 Cpu(s): 15.9%us, 19.6%sy, 0.0%ni, 62.3%id This resulted in f23eb2b2b28547fc70df82dd5049eb39bec5ba12 tty: stop using delayed_work in the tty layer as possible cause. Reverting this commit by hand in v3.8 showed a load distribution similar to 2.6.38. What I haven't done, is measure if the load is really increasing or if top only tells me so. Maybe the algorithm to calculate this somehow produces different results because of the switch from schedule_delayed_work to schedule_work? So, is this a bug, a feature, a symptom,...? Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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/15] arizona updates for v3.10
Hi Mark, On Wed, Apr 03, 2013 at 07:04:23PM +0100, Mark Brown wrote: On Mon, Apr 01, 2013 at 06:27:48PM +0100, Mark Brown wrote: mfd: arizona: Updates for v3.10 This is really a few separate topics which I can split out if required: - WM5102 updates to improve robustness - Improved support for interoperation with edge triggered interrupt controllers - Support for some unusual clocking configurations - A couple small single patch updates and fixes A few more updates for this which I'll post just now, I've updated the tag and branch: The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9: Linux 3.9-rc5 (2013-03-31 15:12:43 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git tags/mfd-arizona-3.10 Thanks, I pulled this one into mfd-next now. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 v8 0/2] ARM: davinci: dm355: add support for vpbe display
From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch series enables VPBE display driver on DM355. This patch series is dependent on VPSS clock cleanup patches (http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg25613.html) posted. Changes for v8: 1: Removed extra line after break's and defines as pointed by Sekhar. 2: Included Ack from Sekhar for the second patch of the series. Changes for v7: 1: Fixed nits pointed by Sekhar for DM365 series. Changes for v6: 1: Fixed nits pointed by Sekhar. Changes for v5: 1: Rebased on 3.9, fix review comments pointed by Sekhar for DM365 series. Changes for v4: 1: pass different platform names to handle different ip's. Changes for v3: 1: Replaced obsolete preset API by timings API. Changes for v2: 1: Removed VPSS clock alias for master and slave which was sent for VPSS driver. since this patch was dependent on patch[1]. I will revist this patch once MC(captrure driver) goes into mainline. [1] http://www.spinics.net/lists/linux-media/msg50562.html Lad, Prabhakar (2): ARM: davinci: dm355: add support for v4l2 video display ARM: davinci: dm355 EVM: add support for VPBE display arch/arm/mach-davinci/board-dm355-evm.c | 71 +- arch/arm/mach-davinci/davinci.h |3 +- arch/arm/mach-davinci/dm355.c | 167 ++- 3 files changed, 233 insertions(+), 8 deletions(-) -- 1.7.4.1 -- 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 v8 1/2] ARM: davinci: dm355: add support for v4l2 video display
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm355.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
arch/arm/mach-davinci/board-dm355-evm.c |4 +-
arch/arm/mach-davinci/davinci.h |3 +-
arch/arm/mach-davinci/dm355.c | 167 ++-
3 files changed, 166 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 147b8e1..37d12cc 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -253,8 +253,6 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm355_evm_map_io(void)
{
- /* setup input configuration for VPFE input devices */
- dm355_set_vpfe_config(vpfe_cfg);
dm355_init();
}
@@ -344,6 +342,8 @@ static __init void dm355_evm_init(void)
davinci_setup_mmc(0, dm355evm_mmc_config);
davinci_setup_mmc(1, dm355evm_mmc_config);
+ dm355_init_video(vpfe_cfg, NULL);
+
dm355_init_spi0(BIT(0), dm355_evm_spi_info,
ARRAY_SIZE(dm355_evm_spi_info));
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index a9de512..c4d9be5 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -39,6 +39,7 @@
#define SYSMOD_VDAC_CONFIG 0x2c
#define SYSMOD_VIDCLKCTL 0x38
#define SYSMOD_VPSS_CLKCTL 0x44
+#define VPSS_MUXSEL_EXTCLK_ENABLE BIT(1)
#define VPSS_VENCCLKEN_ENABLE BIT(3)
#define VPSS_DACCLKEN_ENABLE BIT(4)
#define VPSS_PLLC2SYSCLK5_ENABLE BIT(5)
@@ -79,7 +80,7 @@ void __init dm355_init(void);
void dm355_init_spi0(unsigned chipselect_mask,
const struct spi_board_info *info, unsigned len);
void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata);
-void dm355_set_vpfe_config(struct vpfe_config *cfg);
+int dm355_init_video(struct vpfe_config *, struct vpbe_config *);
/* DM365 function declarations */
void __init dm365_init(void);
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 8e98bb0..bf9a9d4 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -35,6 +35,8 @@
#include asp.h
#define DM355_UART2_BASE (IO_PHYS + 0x206000)
+#define DM355_OSD_BASE (IO_PHYS + 0x70200)
+#define DM355_VENC_BASE(IO_PHYS + 0x70400)
/*
* Device specific clocks
@@ -744,11 +746,146 @@ static struct platform_device vpfe_capture_dev = {
},
};
-void dm355_set_vpfe_config(struct vpfe_config *cfg)
+static struct resource dm355_osd_resources[] = {
+ {
+ .start = DM355_OSD_BASE,
+ .end= DM355_OSD_BASE + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm355_osd_dev = {
+ .name = DM355_VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm355_osd_resources),
+ .resource = dm355_osd_resources,
+ .dev= {
+ .dma_mask = vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+static struct resource dm355_venc_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end= IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* venc registers io space */
+ {
+ .start = DM355_VENC_BASE,
+ .end= DM355_VENC_BASE + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+ /* VDAC config register io space */
+ {
+ .start = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG,
+ .end= DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG + 3,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct resource dm355_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end= IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* venc registers io space */
+ {
+ .start = DM355_VENC_BASE,
+ .end= DM355_VENC_BASE + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static int dm355_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
+ int field)
+{
+ switch (if_type) {
+ case V4L2_MBUS_FMT_SGRBG8_1X8:
+ davinci_cfg_reg(DM355_VOUT_FIELD_G70);
+ break;
+ case V4L2_MBUS_FMT_YUYV10_1X20:
+ if (field)
+ davinci_cfg_reg(DM355_VOUT_FIELD);
+ else
+ davinci_cfg_reg(DM355_VOUT_FIELD_G70);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+
[PATCH v8 2/2] ARM: davinci: dm355 EVM: add support for VPBE display
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add support for V4L2 video display to DM355 EVM.
Support for SD modes is provided, along with Composite
output
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Acked-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/board-dm355-evm.c | 69 ++-
1 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 37d12cc..1043506 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -242,6 +242,73 @@ static struct vpfe_config vpfe_cfg = {
.ccdc = DM355 CCDC,
};
+/* venc standards timings */
+static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
+ {
+ .name = ntsc,
+ .timings_type = VPBE_ENC_STD,
+ .std_id = V4L2_STD_525_60,
+ .interlaced = 1,
+ .xres = 720,
+ .yres = 480,
+ .aspect = {11, 10},
+ .fps= {3, 1001},
+ .left_margin= 0x79,
+ .upper_margin = 0x10,
+ },
+ {
+ .name = pal,
+ .timings_type = VPBE_ENC_STD,
+ .std_id = V4L2_STD_625_50,
+ .interlaced = 1,
+ .xres = 720,
+ .yres = 576,
+ .aspect = {54, 59},
+ .fps= {25, 1},
+ .left_margin= 0x7E,
+ .upper_margin = 0x16
+ },
+};
+
+#define VENC_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * the order same as that of encoders. First those from venc followed by that
+ * from encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm355evm_vpbe_outputs[] = {
+ {
+ .output = {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .std= VENC_STD_ALL,
+ .capabilities = V4L2_OUT_CAP_STD,
+ },
+ .subdev_name= DM355_VPBE_VENC_SUBDEV_NAME,
+ .default_mode = ntsc,
+ .num_modes = ARRAY_SIZE(dm355evm_enc_preset_timing),
+ .modes = dm355evm_enc_preset_timing,
+ .if_params = V4L2_MBUS_FMT_FIXED,
+ },
+};
+
+static struct vpbe_config dm355evm_display_cfg = {
+ .module_name= dm355-vpbe-display,
+ .i2c_adapter_id = 1,
+ .osd= {
+ .module_name= DM355_VPBE_OSD_SUBDEV_NAME,
+ },
+ .venc = {
+ .module_name= DM355_VPBE_VENC_SUBDEV_NAME,
+ },
+ .num_outputs= ARRAY_SIZE(dm355evm_vpbe_outputs),
+ .outputs= dm355evm_vpbe_outputs,
+};
+
static struct platform_device *davinci_evm_devices[] __initdata = {
dm355evm_dm9000,
davinci_nand_device,
@@ -342,7 +409,7 @@ static __init void dm355_evm_init(void)
davinci_setup_mmc(0, dm355evm_mmc_config);
davinci_setup_mmc(1, dm355evm_mmc_config);
- dm355_init_video(vpfe_cfg, NULL);
+ dm355_init_video(vpfe_cfg, dm355evm_display_cfg);
dm355_init_spi0(BIT(0), dm355_evm_spi_info,
ARRAY_SIZE(dm355_evm_spi_info));
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: Add device tree bindings for Arizona class devices
Hi Mark, On Tue, Apr 02, 2013 at 10:38:48PM +0100, Mark Brown wrote: Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com --- Documentation/devicetree/bindings/mfd/arizona.txt | 62 drivers/mfd/arizona-core.c| 64 + drivers/mfd/arizona-i2c.c | 10 +++- drivers/mfd/arizona-spi.c | 10 +++- drivers/mfd/arizona.h | 12 5 files changed, 154 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/arizona.txt Applied as well, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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] mac80211_hwsim: Register and bind to driver
Hello Johannes, Johannes Berg [2013-04-08 11:12 +0200]: I think you forgot to update the error path to unregister the driver. Oops, thanks for spotting. Sending [PATCH v2]. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/
