Re: [PATCH] pinctrl/nomadik: allocate IRQ descriptors dynamically

[Rob Herring]

On 09/26/2012 12:18 PM, Linus Walleij wrote:
> From: Linus Walleij 
> 
> This allocates the IRQ descriptors for the Nomadik pin controller
> dynamically so that we don't have to rely on some other mechanism
> doing it, and moving a step closer to a linear IRQ domain.
> 
> Cc: Rob Herring 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/pinctrl/pinctrl-nomadik.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-nomadik.c 
> b/drivers/pinctrl/pinctrl-nomadik.c
> index 3dde653..29921d1 100644
> --- a/drivers/pinctrl/pinctrl-nomadik.c
> +++ b/drivers/pinctrl/pinctrl-nomadik.c
> @@ -1185,6 +1185,8 @@ static int __devinit nmk_gpio_probe(struct 
> platform_device *dev)
>   struct clk *clk;
>   int secondary_irq;
>   void __iomem *base;
> + int irq_start;
> + int irq_base;
>   int irq;
>   int ret;
>  
> @@ -1288,9 +1290,22 @@ static int __devinit nmk_gpio_probe(struct 
> platform_device *dev)
>  
>   platform_set_drvdata(dev, nmk_chip);
>  
> + /*
> +  * Allocate descriptors and IRQ domain using the legacy model, this
> +  * should eventually be replaced with a linear IRQ domain as we get
> +  * independent from the irq numbers with the switch to device tree.
> +  */
> + irq_start = NOMADIK_GPIO_TO_IRQ(pdata->first_gpio);
> + irq_base = irq_alloc_descs(irq_start, 0, NMK_GPIO_PER_CHIP,
> +numa_node_id());
> + if (IS_ERR_VALUE(irq_base)) {
> + WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming 
> pre-allocated\n",
> +  irq_start);
> + irq_base = irq_start;
> + }
>   nmk_chip->domain = irq_domain_add_legacy(np, NMK_GPIO_PER_CHIP,

You might as well change to irq_domain_add_simple here.

Perhaps we should just add irq_alloc_descs call into
irq_domain_add_simple in the legacy case. It may need to be conditioned
on SPARSE_IRQ. There's currently no callers, so it wouldn't break anything.

Rob

> - 
> NOMADIK_GPIO_TO_IRQ(pdata->first_gpio),
> - 0, _gpio_irq_simple_ops, 
> nmk_chip);
> + irq_base, 0,
> + _gpio_irq_simple_ops, nmk_chip);
>   if (!nmk_chip->domain) {
>   dev_err(>dev, "failed to create irqdomain\n");
>   ret = -ENOSYS;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mtip32xx:Added appropriate timeout value for secure erase

[Jens Axboe]

On 09/27/2012 02:57 PM, Selvan Mani wrote:
> Hi Jens,
> 
> Please queue this patch for 3.7.
> 
> Added appropriate timeout value for secure erase based on identify device data

Queued up!

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/13] kmem accounting basic infrastructure

[Michal Hocko]

On Thu 27-09-12 16:20:55, Glauber Costa wrote:
> On 09/27/2012 04:15 PM, Michal Hocko wrote:
> > On Wed 26-09-12 16:33:34, Tejun Heo wrote:
> > [...]
>  So, this seems properly crazy to me at the similar level of
>  use_hierarchy fiasco.  I'm gonna NACK on this.
> >>>
> >>> As I said: all use cases I particularly care about are covered by a
> >>> global switch.
> >>>
> >>> I am laying down my views because I really believe they make more sense.
> >>> But at some point, of course, I'll shut up if I believe I am a lone voice.
> >>>
> >>> I believe it should still be good to hear from mhocko and kame, but from
> >>> your point of view, would all the rest, plus the introduction of a
> >>> global switch make it acceptable to you?
> >>
> >> The only thing I'm whining about is per-node switch + silently
> >> ignoring past accounting, so if those two are solved, I think I'm
> >> pretty happy with the rest.
> > 
> > I think that per-group "switch" is not nice as well but if we make it
> > hierarchy specific (which I am proposing for quite some time) and do not
> > let enable accounting for a group with tasks then we get both
> > flexibility and reasonable semantic. A global switch sounds too coars to
> > me and it really not necessary.
> > 
> > Would this work with you?
> > 
> 
> How exactly would that work? AFAIK, we have a single memcg root, we
> can't have multiple memcg hierarchies in a system. Am I missing something?

Well root is so different that we could consider the first level as the
real roots for hierarchies.
-- 
Michal Hocko
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 v3 04/13] kmem accounting basic infrastructure

[Glauber Costa]

On 09/27/2012 04:40 PM, Michal Hocko wrote:
> On Thu 27-09-12 16:20:55, Glauber Costa wrote:
>> On 09/27/2012 04:15 PM, Michal Hocko wrote:
>>> On Wed 26-09-12 16:33:34, Tejun Heo wrote:
>>> [...]
>> So, this seems properly crazy to me at the similar level of
>> use_hierarchy fiasco.  I'm gonna NACK on this.
>
> As I said: all use cases I particularly care about are covered by a
> global switch.
>
> I am laying down my views because I really believe they make more sense.
> But at some point, of course, I'll shut up if I believe I am a lone voice.
>
> I believe it should still be good to hear from mhocko and kame, but from
> your point of view, would all the rest, plus the introduction of a
> global switch make it acceptable to you?

 The only thing I'm whining about is per-node switch + silently
 ignoring past accounting, so if those two are solved, I think I'm
 pretty happy with the rest.
>>>
>>> I think that per-group "switch" is not nice as well but if we make it
>>> hierarchy specific (which I am proposing for quite some time) and do not
>>> let enable accounting for a group with tasks then we get both
>>> flexibility and reasonable semantic. A global switch sounds too coars to
>>> me and it really not necessary.
>>>
>>> Would this work with you?
>>>
>>
>> How exactly would that work? AFAIK, we have a single memcg root, we
>> can't have multiple memcg hierarchies in a system. Am I missing something?
> 
> Well root is so different that we could consider the first level as the
> real roots for hierarchies.
> 
So let's favor clarity: What you are proposing is that the first level
can have a switch for that, and the first level only. Is that right ?

At first, I just want to understand what exactly is your proposal. This
is not an endorsement of lack thereof.


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

Re: [PATCH 4/4] memory-hotplug: auto offline page_cgroup when onlining memory block failed

[Ni zhan Chen]

On 09/27/2012 01:45 PM, we...@cn.fujitsu.com wrote:

From: Wen Congyang 

When a memory block is onlined, we will try allocate memory on that node
to store page_cgroup. If onlining the memory block failed, we don't
offline the page cgroup, and we have no chance to offline this page cgroup
unless the memory block is onlined successfully again. It will cause
that we can't hot-remove the memory device on that node, because some
memory is used to store page cgroup. If onlining the memory block
is failed, there is no need to stort page cgroup for this memory. So
auto offline page_cgroup when onlining memory block failed.


looks reasonable to me. thanks.



CC: David Rientjes 
CC: Jiang Liu 
CC: Len Brown 
CC: Benjamin Herrenschmidt 
CC: Paul Mackerras 
Cc: Minchan Kim 
CC: Andrew Morton 
CC: KOSAKI Motohiro 
CC: Yasuaki Ishimatsu 
Signed-off-by: Wen Congyang 
---
  mm/page_cgroup.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 5ddad0c..44db00e 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -251,6 +251,9 @@ static int __meminit page_cgroup_callback(struct 
notifier_block *self,
mn->nr_pages, mn->status_change_nid);
break;
case MEM_CANCEL_ONLINE:
+   offline_page_cgroup(mn->start_pfn,
+   mn->nr_pages, mn->status_change_nid);
+   break;
case MEM_GOING_OFFLINE:
break;
case MEM_ONLINE:


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl/nomadik: allocate IRQ descriptors dynamically

[Linus Walleij]

On Thu, Sep 27, 2012 at 2:37 PM, Rob Herring  wrote:

>>   nmk_chip->domain = irq_domain_add_legacy(np, NMK_GPIO_PER_CHIP,
>
> You might as well change to irq_domain_add_simple here.

True. I'll fix.

> Perhaps we should just add irq_alloc_descs call into
> irq_domain_add_simple in the legacy case. It may need to be conditioned
> on SPARSE_IRQ. There's currently no callers, so it wouldn't break anything.

OK get ready to ACK, I'll fix.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs/namespace.c: introduce helper function path_unmounted()

[Yan Hong]

In fs/namespace.c, we verify whether a path is a mountpoint by
comparing path->dentry and path->mnt->mnt_root. Introduce
path_unmounted() to make code more readable.

Signed-off-by: Yan Hong 
---
 fs/namespace.c |   19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 4d31f73..3fdc239 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1234,6 +1234,11 @@ static int do_umount(struct mount *mnt, int flags)
return retval;
 }
 
+static inline bool path_unmounted(struct path *path)
+{
+   return path->dentry != path->mnt->mnt_root;
+}
+
 /*
  * Now umount can handle mount points as well as block devices.
  * This is important for filesystems which use unnamed block devices.
@@ -1260,7 +1265,7 @@ SYSCALL_DEFINE2(umount, char __user *, name, int, flags)
goto out;
mnt = real_mount(path.mnt);
retval = -EINVAL;
-   if (path.dentry != path.mnt->mnt_root)
+   if (path_unmounted())
goto dput_and_out;
if (!check_mnt(mnt))
goto dput_and_out;
@@ -1613,7 +1618,7 @@ static int do_change_type(struct path *path, int flag)
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
 
-   if (path->dentry != path->mnt->mnt_root)
+   if (path_unmounted(path))
return -EINVAL;
 
type = flags_to_propagation_type(flag);
@@ -1727,7 +1732,7 @@ static int do_remount(struct path *path, int flags, int 
mnt_flags,
if (!check_mnt(mnt))
return -EINVAL;
 
-   if (path->dentry != path->mnt->mnt_root)
+   if (path_unmounted(path))
return -EINVAL;
 
err = security_sb_remount(sb, data);
@@ -1793,7 +1798,7 @@ static int do_move_mount(struct path *path, char 
*old_name)
goto out1;
 
err = -EINVAL;
-   if (old_path.dentry != old_path.mnt->mnt_root)
+   if (path_unmounted(_path))
goto out1;
 
if (!mnt_has_parent(old))
@@ -1892,7 +1897,7 @@ static int do_add_mount(struct mount *newmnt, struct path 
*path, int mnt_flags)
/* Refuse the same filesystem on the same mount point */
err = -EBUSY;
if (path->mnt->mnt_sb == newmnt->mnt.mnt_sb &&
-   path->mnt->mnt_root == path->dentry)
+   !path_unmounted(path))
goto unlock;
 
err = -EINVAL;
@@ -2534,11 +2539,11 @@ SYSCALL_DEFINE2(pivot_root, const char __user *, 
new_root,
old.mnt == root.mnt)
goto out4; /* loop, on the same file system  */
error = -EINVAL;
-   if (root.mnt->mnt_root != root.dentry)
+   if (path_unmounted())
goto out4; /* not a mountpoint */
if (!mnt_has_parent(root_mnt))
goto out4; /* not attached */
-   if (new.mnt->mnt_root != new.dentry)
+   if (path_unmounted())
goto out4; /* not a mountpoint */
if (!mnt_has_parent(new_mnt))
goto out4; /* not attached */
-- 
1.7.9.5

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

[PATCH 3/8] fs/namespace.c: trivial code clean

[Yan Hong]

Signed-off-by: Yan Hong 
---
 fs/namespace.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index dd969f8..bbe9014 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -763,7 +763,7 @@ vfs_kern_mount(struct file_system_type *type, int flags, 
const char *name, void
 
mnt->mnt.mnt_root = root;
mnt->mnt.mnt_sb = root->d_sb;
-   mnt->mnt_mountpoint = mnt->mnt.mnt_root;
+   mnt->mnt_mountpoint = root;
mnt->mnt_parent = mnt;
br_write_lock(_lock);
list_add_tail(>mnt_instance, >d_sb->s_mounts);
@@ -798,7 +798,7 @@ static struct mount *clone_mnt(struct mount *old, struct 
dentry *root,
atomic_inc(>s_active);
mnt->mnt.mnt_sb = sb;
mnt->mnt.mnt_root = dget(root);
-   mnt->mnt_mountpoint = mnt->mnt.mnt_root;
+   mnt->mnt_mountpoint = root;
mnt->mnt_parent = mnt;
br_write_lock(_lock);
list_add_tail(>mnt_instance, >s_mounts);
-- 
1.7.9.5

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

[PATCH 2/8] fs/namespace.c: remove unused macro MNT_WRITER_UNDERFLOW_LIMIT

[Yan Hong]

Its users have gone.

Signed-off-by: Yan Hong 
---
 fs/namespace.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 3fdc239..dd969f8 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -59,7 +59,6 @@ static inline unsigned long hash(struct vfsmount *mnt, struct 
dentry *dentry)
return tmp & (HASH_SIZE - 1);
 }
 
-#define MNT_WRITER_UNDERFLOW_LIMIT -(1<<16)
 
 /*
  * allocation is serialized by namespace_sem, but we need the spinlock to
-- 
1.7.9.5

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

[PATCH 4/8] fs/namespace.c: check permission early in sys_[u]mount

[Yan Hong]

We have several branches in sys_mount, each of them will check
CAP_SYS_ADMIN capability seperately. Do this check at the beginning
of sys_mount.

Also check permission as early as possible in sys_umount.

Signed-off-by: Yan Hong 
---
 fs/namespace.c |   26 +++---
 1 file changed, 7 insertions(+), 19 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index bbe9014..ca2b6e9 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1256,6 +1256,9 @@ SYSCALL_DEFINE2(umount, char __user *, name, int, flags)
if (flags & ~(MNT_FORCE | MNT_DETACH | MNT_EXPIRE | UMOUNT_NOFOLLOW))
return -EINVAL;
 
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
if (!(flags & UMOUNT_NOFOLLOW))
lookup_flags |= LOOKUP_FOLLOW;
 
@@ -1269,10 +1272,6 @@ SYSCALL_DEFINE2(umount, char __user *, name, int, flags)
if (!check_mnt(mnt))
goto dput_and_out;
 
-   retval = -EPERM;
-   if (!capable(CAP_SYS_ADMIN))
-   goto dput_and_out;
-
retval = do_umount(mnt, flags);
 dput_and_out:
/* we mustn't call path_put() as that would clear mnt_expiry_mark */
@@ -1296,9 +1295,7 @@ SYSCALL_DEFINE1(oldumount, char __user *, name)
 
 static int mount_is_safe(struct path *path)
 {
-   if (capable(CAP_SYS_ADMIN))
-   return 0;
-   return -EPERM;
+   return 0;
 #ifdef notyet
if (S_ISLNK(path->dentry->d_inode->i_mode))
return -EPERM;
@@ -1614,9 +1611,6 @@ static int do_change_type(struct path *path, int flag)
int type;
int err = 0;
 
-   if (!capable(CAP_SYS_ADMIN))
-   return -EPERM;
-
if (path_unmounted(path))
return -EINVAL;
 
@@ -1725,9 +1719,6 @@ static int do_remount(struct path *path, int flags, int 
mnt_flags,
struct super_block *sb = path->mnt->mnt_sb;
struct mount *mnt = real_mount(path->mnt);
 
-   if (!capable(CAP_SYS_ADMIN))
-   return -EPERM;
-
if (!check_mnt(mnt))
return -EINVAL;
 
@@ -1774,8 +1765,6 @@ static int do_move_mount(struct path *path, char 
*old_name)
struct mount *p;
struct mount *old;
int err = 0;
-   if (!capable(CAP_SYS_ADMIN))
-   return -EPERM;
if (!old_name || !*old_name)
return -EINVAL;
err = kern_path(old_name, LOOKUP_FOLLOW, _path);
@@ -1924,10 +1913,6 @@ static int do_new_mount(struct path *path, char *type, 
int flags,
if (!type)
return -EINVAL;
 
-   /* we need capabilities... */
-   if (!capable(CAP_SYS_ADMIN))
-   return -EPERM;
-
mnt = do_kern_mount(type, flags, name, data);
if (IS_ERR(mnt))
return PTR_ERR(mnt);
@@ -2410,6 +2395,9 @@ SYSCALL_DEFINE5(mount, char __user *, dev_name, char 
__user *, dir_name,
char *kernel_dev;
unsigned long data_page;
 
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
ret = copy_mount_string(type, _type);
if (ret < 0)
goto out_type;
-- 
1.7.9.5

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

[PATCH 5/8] fs/namei.c: introduce macro AT_FDINV

[Yan Hong]

File descriptor is irrelevent when LOOKUP_ROOT is set.
Introduce AT_FDINV to avoid using hard coded value or reusing
existing macro.

Signed-off-by: Yan Hong 
---
 fs/namei.c|   11 ++-
 include/linux/fcntl.h |2 ++
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index c5b85b3..5ffd97d 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2034,8 +2034,8 @@ int vfs_path_lookup(struct dentry *dentry, struct 
vfsmount *mnt,
nd.root.dentry = dentry;
nd.root.mnt = mnt;
BUG_ON(flags & LOOKUP_PARENT);
-   /* the first argument of do_path_lookup() is ignored with LOOKUP_ROOT */
-   err = do_path_lookup(AT_FDCWD, name, flags | LOOKUP_ROOT, );
+
+   err = do_path_lookup(AT_FDINV, name, flags | LOOKUP_ROOT, );
if (!err)
*path = nd.path;
return err;
@@ -2969,11 +2969,12 @@ struct file *do_file_open_root(struct dentry *dentry, 
struct vfsmount *mnt,
if (dentry->d_inode->i_op->follow_link && op->intent & LOOKUP_OPEN)
return ERR_PTR(-ELOOP);
 
-   file = path_openat(-1, name, , op, flags | LOOKUP_RCU);
+   file = path_openat(AT_FDINV, name, , op, flags | LOOKUP_RCU);
if (unlikely(file == ERR_PTR(-ECHILD)))
-   file = path_openat(-1, name, , op, flags);
+   file = path_openat(AT_FDINV, name, , op, flags);
if (unlikely(file == ERR_PTR(-ESTALE)))
-   file = path_openat(-1, name, , op, flags | LOOKUP_REVAL);
+   file = path_openat(AT_FDINV, name, , op,
+   flags | LOOKUP_REVAL);
return file;
 }
 
diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
index f550f89..abd94fe 100644
--- a/include/linux/fcntl.h
+++ b/include/linux/fcntl.h
@@ -41,6 +41,8 @@
 #define AT_FDCWD   -100/* Special value used to indicate
openat should use the current
working directory. */
+#define AT_FDINV   -200/* Special value used when LOOKUP_ROOT
+  is set. */
 #define AT_SYMLINK_NOFOLLOW0x100   /* Do not follow symbolic links.  */
 #define AT_REMOVEDIR   0x200   /* Remove directory instead of
unlinking file.  */
-- 
1.7.9.5

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

[PATCH 6/8] fs/inode.c: call alloc_inode() in new_inode() directly

[Yan Hong]

This saves us a list head initialization.

Signed-off-by: Yan Hong 
---
 fs/inode.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/inode.c b/fs/inode.c
index ac8d904..3a2cd41 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -921,9 +921,11 @@ struct inode *new_inode(struct super_block *sb)
 
spin_lock_prefetch(_sb_list_lock);
 
-   inode = new_inode_pseudo(sb);
-   if (inode)
+   inode = alloc_inode(sb);
+   if (inode) {
+   inode->i_state = 0;
inode_sb_list_add(inode);
+   }
return inode;
 }
 EXPORT_SYMBOL(new_inode);
-- 
1.7.9.5

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

[PATCH 7/8] fs/inode.c: remove outstanding spin lock prefetch

[Yan Hong]

Do we have particular reason to do this here?

Signed-off-by: Yan Hong 
---
 fs/inode.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/fs/inode.c b/fs/inode.c
index 3a2cd41..e89d30c 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include  /* for inode_has_buffers */
 #include 
 #include "internal.h"
@@ -919,8 +918,6 @@ struct inode *new_inode(struct super_block *sb)
 {
struct inode *inode;
 
-   spin_lock_prefetch(_sb_list_lock);
-
inode = alloc_inode(sb);
if (inode) {
inode->i_state = 0;
-- 
1.7.9.5

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

[PATCH 8/8] vfs: misc comment clean

[Yan Hong]

Mostly fix comments which reference inexist locks or parameters.

Signed-off-by: Yan Hong 
---
 fs/dcache.c|   12 
 fs/inode.c |4 ++--
 fs/namei.c |2 +-
 fs/namespace.c |9 +++--
 4 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index 8086636..2d97518 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -44,8 +44,6 @@
  * Usage:
  * dcache->d_inode->i_lock protects:
  *   - i_dentry, d_alias, d_inode of aliases
- * dcache_hash_bucket lock protects:
- *   - the dcache hash table
  * s_anon bl list spinlock protects:
  *   - the s_anon list (see __d_drop)
  * dcache_lru_lock protects:
@@ -64,7 +62,6 @@
  * dentry->d_inode->i_lock
  *   dentry->d_lock
  * dcache_lru_lock
- * dcache_hash_bucket lock
  * s_anon lock
  *
  * If there is an ancestor relationship:
@@ -145,10 +142,9 @@ int proc_nr_dentry(ctl_table *table, int write, void 
__user *buffer,
 
 #include 
 /*
- * NOTE! 'cs' and 'scount' come from a dentry, so it has a
- * aligned allocation for this particular component. We don't
- * strictly need the load_unaligned_zeropad() safety, but it
- * doesn't hurt either.
+ * NOTE! 'cs' comes from a dentry, so it has an aligned allocation
+ * for this particular component. We don't strictly need the
+ * load_unaligned_zeropad() safety, but it doesn't hurt either.
  *
  * In contrast, 'ct' and 'tcount' can be from a pathname, and do
  * need the careful unaligned handling.
@@ -304,7 +300,7 @@ static void dentry_unlink_inode(struct dentry * dentry)
 }
 
 /*
- * dentry_lru_(add|del|prune|move_tail) must be called with d_lock held.
+ * dentry_lru_(add|del|prune|move_list) must be called with d_lock held.
  */
 static void dentry_lru_add(struct dentry *dentry)
 {
diff --git a/fs/inode.c b/fs/inode.c
index e89d30c..46d4f16 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -676,7 +676,7 @@ static int can_unuse(struct inode *inode)
  * Walk the superblock inode LRU for freeable inodes and attempt to free them.
  * This is called from the superblock shrinker function with a number of inodes
  * to trim from the LRU. Inodes to be freed are moved to a temporary list and
- * then are freed outside inode_lock by dispose_list().
+ * then are freed outside s_inode_lru_lock by dispose_list().
  *
  * Any inodes which are pinned purely because of attached pagecache have their
  * pagecache removed.  If the inode has metadata buffers attached to
@@ -777,7 +777,7 @@ void prune_icache_sb(struct super_block *sb, int nr_to_scan)
 
 static void __wait_on_freeing_inode(struct inode *inode);
 /*
- * Called with the inode lock held.
+ * Called with the inode_hash_lock held.
  */
 static struct inode *find_inode(struct super_block *sb,
struct hlist_head *head,
diff --git a/fs/namei.c b/fs/namei.c
index 5ffd97d..7b1f714 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -421,7 +421,7 @@ EXPORT_SYMBOL(path_put);
  * Path walking has 2 modes, rcu-walk and ref-walk (see
  * Documentation/filesystems/path-lookup.txt).  In situations when we can't
  * continue in RCU mode, we attempt to drop out of rcu-walk mode and grab
- * normal reference counts on dentries and vfsmounts to transition to rcu-walk
+ * normal reference counts on dentries and vfsmounts to transition to ref-walk
  * mode.  Refcounts are grabbed at the last known good point before rcu-walk
  * got stuck, so ref-walk may continue from there. If this is not successful
  * (eg. a seqcount has changed), then failure is returned and it's up to caller
diff --git a/fs/namespace.c b/fs/namespace.c
index ca2b6e9..b7477ee 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1239,9 +1239,6 @@ static inline bool path_unmounted(struct path *path)
 }
 
 /*
- * Now umount can handle mount points as well as block devices.
- * This is important for filesystems which use unnamed block devices.
- *
  * We now support a flag for forced unmount like the other 'big iron'
  * unixes. Our API is identical to OSF/1 to avoid making a mess of AMD
  */
@@ -1431,9 +1428,9 @@ static int invent_group_ids(struct mount *mnt, bool 
recurse)
 }
 
 /*
- *  @source_mnt : mount tree to be attached
- *  @nd : place the mount tree @source_mnt is attached
- *  @parent_nd  : if non-null, detach the source_mnt from its parent and
+ *  @source_mnt  : mount tree to be attached
+ *  @path: place the mount tree @source_mnt is attached
+ *  @parent_path : if non-null, detach the @source_mnt from its parent and
  *store the parent mount and mountpoint dentry.
  *(done when source_mnt is moved)
  *
-- 
1.7.9.5

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

Re: [PATCH] pinctrl/nomadik: allocate IRQ descriptors dynamically

[Russell King - ARM Linux]

On Wed, Sep 26, 2012 at 07:18:07PM +0200, Linus Walleij wrote:
> + irq_start = NOMADIK_GPIO_TO_IRQ(pdata->first_gpio);
> + irq_base = irq_alloc_descs(irq_start, 0, NMK_GPIO_PER_CHIP,
> +numa_node_id());
> + if (IS_ERR_VALUE(irq_base)) {

commit 07ab67c8d0d7c1021343b7d5c045033d6bf7be69
Author: Linus Torvalds 
Date:   Thu May 19 22:43:37 2005 -0700

Fix get_unmapped_area sanity tests

As noted by Chris Wright, we need to do the full range of tests regardless
of whether MAP_FIXED is set or not, so re-organize get_unmapped_area()
slightly to do the sanity checks unconditionally.

diff --git a/include/linux/err.h b/include/linux/err.h
index 17c55df..ff71d2a 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -13,6 +13,8 @@
  * This should be a per-architecture thing, to allow different
  * error and pointer decisions.
  */
+#define IS_ERR_VALUE(x) unlikely((x) > (unsigned long)-1000L)

This is because get_unmapped_area() can return negative numbers which are
not error codes.

My position on this is that IS_ERR_VALUE() should only be used for checking
the return value of a function where some negative numbers are not error
codes, and everywhere else should use "ret < 0".

Just because we have a funky macro is no reason to blindly (ab)use it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 04/13] kmem accounting basic infrastructure

[Michal Hocko]

On Thu 27-09-12 16:40:03, Glauber Costa wrote:
> On 09/27/2012 04:40 PM, Michal Hocko wrote:
> > On Thu 27-09-12 16:20:55, Glauber Costa wrote:
> >> On 09/27/2012 04:15 PM, Michal Hocko wrote:
> >>> On Wed 26-09-12 16:33:34, Tejun Heo wrote:
> >>> [...]
> >> So, this seems properly crazy to me at the similar level of
> >> use_hierarchy fiasco.  I'm gonna NACK on this.
> >
> > As I said: all use cases I particularly care about are covered by a
> > global switch.
> >
> > I am laying down my views because I really believe they make more sense.
> > But at some point, of course, I'll shut up if I believe I am a lone 
> > voice.
> >
> > I believe it should still be good to hear from mhocko and kame, but from
> > your point of view, would all the rest, plus the introduction of a
> > global switch make it acceptable to you?
> 
>  The only thing I'm whining about is per-node switch + silently
>  ignoring past accounting, so if those two are solved, I think I'm
>  pretty happy with the rest.
> >>>
> >>> I think that per-group "switch" is not nice as well but if we make it
> >>> hierarchy specific (which I am proposing for quite some time) and do not
> >>> let enable accounting for a group with tasks then we get both
> >>> flexibility and reasonable semantic. A global switch sounds too coars to
> >>> me and it really not necessary.
> >>>
> >>> Would this work with you?
> >>>
> >>
> >> How exactly would that work? AFAIK, we have a single memcg root, we
> >> can't have multiple memcg hierarchies in a system. Am I missing something?
> > 
> > Well root is so different that we could consider the first level as the
> > real roots for hierarchies.
> > 
> So let's favor clarity: What you are proposing is that the first level
> can have a switch for that, and the first level only. Is that right ?

I do not want any more switches. I am fine with your "set the limit and
start accounting apprach" and then inherit the _internal_ flag down the
hierarchy.
If you are in a child and want to set the limit then you can do that
only if your parent is accounted already (so that you can have your own
limit). We will need the same thing for oom_controll and swappinness.
-- 
Michal Hocko
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/

[ANNOUNCE] 3.2.30-rt45

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.2.30-rt45 stable release.


This release is just an update to the new stable 3.2.30 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  Head SHA1: 6674e5257742c7852038926912dc22d88468990b


Or to build 3.2.30-rt45 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.30.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.30-rt45.patch.xz



Enjoy,

-- Steve



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] procfs: Add ability to plug in auxiliary fdinfo providers

[Pavel Emelyanov]

On 09/17/2012 10:18 PM, Cyrill Gorcunov wrote:
> On Thu, Sep 13, 2012 at 01:29:07AM +0400, Cyrill Gorcunov wrote:
>> This patch brings ability to print out auxiliary data associated
>> with file in procfs interface /proc/pid/fdinfo/fd.
>>
>> In particular further patches make eventfd, evenpoll, signalfd
>> and fsnotify to print additional information complete enough
>> to restore these objects after checkpoint.
>>
>> To simplify the code we add show_fdinfo callback inside
>> struct file_operations (as Al and Pavel are proposing).
>>
> 
> Hi, sorry for bothering but is there some opinions on this series?

Al, we'd appreciate if you share your plans about this series. Please.

> (I've found that epoll change log has not been well refreshed and
>  says that this fdinfo feature is config-checkpoint-restore dependant,
>  but in real this config entry was ripped off during conversation).
> 
> So, at moment I somehow confused since it's a bit unclear where to
> move, either this series is more-less acceptible or not. I could
> bring back all config-checkpoint-restore dependency (since I still
> believe this feature better to be enabled not by default but iif
> user has asked fo it).
> .
> 

Thanks,
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hashtable: introduce a small and naive hashtable

[Mathieu Desnoyers]

* David Laight (david.lai...@aculab.com) wrote:
> > > > And even then, if we would do:
> > > >
> > > > for (i = 0; i < HASH_SIZE(hashtable); i++)
> > > > if (!hlist_empty([i]))
> > > > break;
> > > >
> > > > return i >= HASH_SIZE(hashtable);
> > > >
> > > > What happens if the last entry of the table is non-empty ?
> > >
> > > It still works, as 'i' is not incremented due to the break. And i will
> > > still be less than HASH_SIZE(hashtable). Did you have *your* cup of
> > > coffee today? ;-)
> > 
> > Ahh, right! Actually I had it already ;-)
> 
> I tend to dislike the repeated test, gcc might be able to optimise
> it away, but the code is cleaner written as:
> 
>   for (i = 0; i < HASH_SIZE(hashtable); i++)
>   if (!hlist_empty([i]))
>   return false;
>   return true;
> 

Agreed, this looks like a good way to write it.

> > Agreed that the flags should be removed. Moving to define + static
> > inline is still important though.
> 
> Not sure I'd bother making the function inline.

Do you mean you prefer to keep it as a macro, or that you don't think
the "inline" keyword is relevant anymore, and want to do a "static" only
function in the header file ?

In both cases, please explain the reasons for doing things that way.

Thanks,

Mathieu

> 
>   David
> 
> 
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R Consultant
EfficiOS Inc.
http://www.efficios.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 v3] watchdog/imx2+: add support for pretimeout interrupt functionality

[Oskar Schirmer]

Hi Wim,

unless there is another issue with this patch,
could You give an ack now?

thanks,
  Oskar

On Thu, Sep 20, 2012 at 15:37:24 +, Oskar Schirmer wrote:
> This watchdog device provides pretimeout facilities:
> Set some timeout value and get informed about imminent
> watchdog activity thru interrupt.
> 
> Allow user to wait for this asynchronous event thru poll(2),
> and to clear it implicitely upon dog appeasement.
> 
> There is only one precedent in current kernel that implements
> watchdog pretimeout, ipmi_watchdog. It provides pretimeout
> event thru poll, and requires a read(2) call to clear it.
> 
> However, as write(2) does calm the dog and so wind up the
> timer anyway, it is obvious to let poll(2) state writability
> where pretimeout has passed.
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data

[Andy Shevchenko]

On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: 
> On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote:
> > On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote:
> > > Not all of the controllers support the 64 bit data width. Make it 
> > > configurable
> > > via platform data. The driver will try to get a value from the component
> > > parameters, otherwise it will use the platform data.
> > > 
> > What was this gen against, I can apply this.
> > 
> 
> %s/can/can't
Against linux-next, last used was yesterday's version of it.


-- 
Andy Shevchenko 
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hashtable: introduce a small and naive hashtable

[Mathieu Desnoyers]

* Sasha Levin (levinsasha...@gmail.com) wrote:
> On 09/27/2012 10:25 AM, David Laight wrote:
>  And even then, if we would do:
> 
>   for (i = 0; i < HASH_SIZE(hashtable); i++)
>   if (!hlist_empty([i]))
>   break;
> 
>   return i >= HASH_SIZE(hashtable);
> 
>  What happens if the last entry of the table is non-empty ?
> >>>
> >>> It still works, as 'i' is not incremented due to the break. And i will
> >>> still be less than HASH_SIZE(hashtable). Did you have *your* cup of
> >>> coffee today? ;-)
> >>
> >> Ahh, right! Actually I had it already ;-)
> > 
> > I tend to dislike the repeated test, gcc might be able to optimise
> > it away, but the code is cleaner written as:
> > 
> > for (i = 0; i < HASH_SIZE(hashtable); i++)
> > if (!hlist_empty([i]))
> > return false;
> > return true;
> 
> Right, the flag thing in the macro was there just to make it work
> properly as a macro.
> 
> >> Agreed that the flags should be removed. Moving to define + static
> >> inline is still important though.
> > 
> > Not sure I'd bother making the function inline.
> 
> I usually never make anything 'inline', I just let gcc do it's own
> thing when it compiles the code. If there are any objections
> please let me know before I send the new version.

AFAIK, gcc nowadays use "inline" only as a hint, because programmers
were using it everywhere, even where it should not have been used. This
is where the attribute always_inline becomes useful, if you really,
really want to inline. However, for kernel coding style consistency, it
might be better to use "static inline", because it is used everywhere
else in kernel headers. Or maybe are there some headers that do not use
"inline" I am not aware of ?

Moreover, if your thinking is that we do not need a static inline
function replicated at every caller, maybe we should introduce a
lib/hashtable.c that implements those 2 functions.

Thanks,

Mathieu

> 
> 
> Thanks,
> Sasha
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R Consultant
EfficiOS Inc.
http://www.efficios.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 8/9] mm: compaction: Cache if a pageblock was scanned and no pages were isolated

[Mel Gorman]

On Tue, Sep 25, 2012 at 01:03:52PM -0700, Andrew Morton wrote:
> On Tue, 25 Sep 2012 10:12:07 +0100
> Mel Gorman  wrote:
> 
> > First, we'd introduce a variant of get_pageblock_migratetype() that returns
> > all the bits for the pageblock flags and then helpers to extract either the
> > migratetype or the PG_migrate_skip. We already are incurring the cost of
> > get_pageblock_migratetype() so it will not be much more expensive than what
> > is already there. If there is an allocation or free within a pageblock that
> > as the PG_migrate_skip bit set then we increment a counter. When the counter
> > reaches some to-be-decided "threshold" then compaction may clear all the
> > bits. This would match the criteria of the clearing being based on activity.
> > 
> > There are four potential problems with this
> > 
> > 1. The logic to retrieve all the bits and split them up will be a little
> >convulated but maybe it would not be that bad.
> > 
> > 2. The counter is a shared-writable cache line but obviously it could
> >be moved to vmstat and incremented with inc_zone_page_state to offset
> >the cost a little.
> > 
> > 3. The biggested weakness is that there is not way to know if the
> >counter is incremented based on activity in a small subset of blocks.
> > 
> > 4. What should the threshold be?
> > 
> > The first problem is minor but the other three are potentially a mess.
> > Adding another vmstat counter is bad enough in itself but if the counter
> > is incremented based on a small subsets of pageblocks, the hint becomes
> > is potentially useless.
> > 
> > However, does this match what you have in mind or am I over-complicating
> > things?
> 
> Sounds complicated.
> 
> Using wall time really does suck. 

I know, we spent a fair amount of effort getting rid of congestion_wait()
from paths it did not belong to for similar reasons.

> Are you sure you can't think of
> something more logical?
> 

No, I'm not sure.

As a matter of general policy I should not encourage this but apparently
you can nag better code out of me, patch is below :). I would rather it
was added on top rather than merged with the time-based series so it can
be reverted easily if necessary.

> How would we demonstrate the suckage?  What would be the observeable downside 
> of
> switching that 5 seconds to 5 hours?
> 

Reduced allocation success rates.

> > Lets take an unlikely case - 128G single-node machine. That loop count
> > on x86-64 would be 65536. It'll be fast enough, particularly in this
> > path.
> 
> That could easily exceed a millisecond.  Can/should we stick a
> cond_resched() in there?

Ok, I think it is very unlikely but not impossible. I posted a patch for
it already.

Here is a candidate patch that replaces the time heuristic with one that
is based on VM activity. My own testing indicate that scan rates are
slightly higher with this patch than the time heuristic but well within
acceptable limits.

Richard, can you also test this patch and make sure your test case has
not regressed again please?

---8<---
mm: compaction: Clear PG_migrate_skip based on compaction and reclaim activity

Compaction caches if a pageblock was scanned and no pages were isolated
so that the pageblocks can be skipped in the future to reduce scanning.
This information is not cleared by the page allocator based on activity
due to the impact it would have to the page allocator fast paths. Hence
there is a requirement that something clear the cache or pageblocks will
be skipped forever. Currently the cache is cleared if there were a number
of recent allocation failures and it has not been cleared within the last
5 seconds. Time-based decisions like this are terrible as they have no
relationship to VM activity and is basically a big hammer.

Unfortunately, accurate heuristics would add cost to some hot paths so this
patch implements a rough heuristic. There are two cases where the cache
is cleared.

1. If a !kswapd process completes a compaction cycle (migrate and free
   scanner meet), the zone is marked compact_blockskip_flush. When kswapd
   goes to sleep, it will clear the cache. This is expected to be the
   common case where the cache is cleared. It does not really matter if
   kswapd happens to be asleep or going to sleep when the flag is set as
   it will be woken on the next allocation request.

2. If there has been multiple failures recently and compaction just
   finished being deferred then a process will clear the cache and start
   a full scan. This situation happens if there are multiple high-order
   allocation requests under heavy memory pressure.

The clearing of the PG_migrate_skip bits and other scans is inherently
racy but the race is harmless. For allocations that can fail such as
THP, they will simply fail. For requests that cannot fail, they will
retry the allocation. Tests indicated that scanning rates were roughly
similar to when the time-based heuristic was used and the allocation
success rates were similar.

[PATCH 2/4] irqdomain: augment add_simple() to allocate descs

[Linus Walleij]

From: Linus Walleij 

Currently we rely on all IRQ chip instances to dynamically
allocate their IRQ descriptors unless they use the linear
IRQ domain. So for irqdomain_add_legacy() and
irqdomain_add_simple() the caller need to make sure that
descriptors are allocated.

Let's slightly augment the yet unused irqdomain_add_simple()
to also allocate descriptors as a means to simplify usage
and avoid code duplication throughout the kernel.

We warn if descriptors cannot be allocated, e.g. if a
platform has the bad habit of hogging descriptors at boot
time.

Cc: Rob Herring 
Cc: Thomas Gleixner 
Cc: Grant Likely 
Cc: Russell King 
Cc: Lee Jones 
Signed-off-by: Linus Walleij 
---
Rob/Grant/Thomas if you ACK this I will take it through the
pinctrl tree since I introduce its only user right there.
---
 kernel/irq/irqdomain.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 49a7772..a0655b6 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -148,7 +148,8 @@ static unsigned int irq_domain_legacy_revmap(struct 
irq_domain *domain,
  * @host_data: Controller private data pointer
  *
  * Allocates a legacy irq_domain if irq_base is positive or a linear
- * domain otherwise.
+ * domain otherwise. For the legacy domain, IRQ descriptors will also
+ * be allocated.
  *
  * This is intended to implement the expected behaviour for most
  * interrupt controllers which is that a linear mapping should
@@ -162,11 +163,21 @@ struct irq_domain *irq_domain_add_simple(struct 
device_node *of_node,
 const struct irq_domain_ops *ops,
 void *host_data)
 {
-   if (first_irq > 0)
-   return irq_domain_add_legacy(of_node, size, first_irq, 0,
+   if (first_irq > 0) {
+   int irq_base;
+
+   irq_base = irq_alloc_descs(first_irq, 0, size, numa_node_id());
+   if (irq_base < 0) {
+   WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming 
pre-allocated\n",
+first_irq);
+   irq_base = first_irq;
+   }
+   return irq_domain_add_legacy(of_node, size, irq_base, 0,
 ops, host_data);
-   else
-   return irq_domain_add_linear(of_node, size, ops, host_data);
+   }
+
+   /* A linear domain is the default */
+   return irq_domain_add_linear(of_node, size, ops, host_data);
 }
 
 /**
-- 
1.7.11.3

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

[PATCH 4/4] ARM: nomadik/ux500: convert to SPARSE_IRQ

[Linus Walleij]

From: Linus Walleij 

This converts the Nomadik and Ux500 over to using sparse IRQ,
including some pokes around the pinctrl driver. To avoid
referencing unnecessary header files, the plat-nomadik timer
driver is augmented to pass an irq number at init time, and
the change is applied across both platforms simultaneously
for this reason.

Cc: Lee Jones 
Signed-off-by: Linus Walleij 
---
 arch/arm/Kconfig  | 2 ++
 arch/arm/mach-nomadik/board-nhk8815.c | 4 ++--
 arch/arm/mach-nomadik/include/mach/irqs.h | 2 +-
 arch/arm/mach-ux500/board-mop500.c| 1 -
 arch/arm/mach-ux500/cpu-db8500.c  | 1 +
 arch/arm/mach-ux500/devices-common.c  | 1 +
 arch/arm/mach-ux500/devices-db8500.c  | 1 +
 arch/arm/mach-ux500/devices-db8500.h  | 1 +
 arch/arm/mach-ux500/include/mach/irqs.h   | 2 +-
 arch/arm/mach-ux500/timer.c   | 2 +-
 arch/arm/plat-nomadik/include/plat/mtu.h  | 2 +-
 arch/arm/plat-nomadik/timer.c | 4 ++--
 drivers/pinctrl/pinctrl-nomadik.c | 1 +
 13 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2f88d8d..bec5d08 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -945,6 +945,7 @@ config ARCH_U8500
select ARCH_HAS_CPUFREQ
select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
+   select SPARSE_IRQ
help
  Support for ST-Ericsson's Ux500 architecture
 
@@ -958,6 +959,7 @@ config ARCH_NOMADIK
select PINCTRL
select MIGHT_HAVE_CACHE_L2X0
select ARCH_REQUIRE_GPIOLIB
+   select SPARSE_IRQ
help
  Support for the Nomadik platform by ST-Ericsson
 
diff --git a/arch/arm/mach-nomadik/board-nhk8815.c 
b/arch/arm/mach-nomadik/board-nhk8815.c
index f4535a7..287b349 100644
--- a/arch/arm/mach-nomadik/board-nhk8815.c
+++ b/arch/arm/mach-nomadik/board-nhk8815.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -36,6 +35,7 @@
 
 #include 
 #include 
+#include 
 
 #include "cpu-8815.h"
 
@@ -260,7 +260,7 @@ static void __init nomadik_timer_init(void)
src_cr |= SRC_CR_INIT_VAL;
writel(src_cr, io_p2v(NOMADIK_SRC_BASE));
 
-   nmdk_timer_init(io_p2v(NOMADIK_MTU0_BASE));
+   nmdk_timer_init(io_p2v(NOMADIK_MTU0_BASE), IRQ_MTU0);
 }
 
 static struct sys_timer nomadik_timer = {
diff --git a/arch/arm/mach-nomadik/include/mach/irqs.h 
b/arch/arm/mach-nomadik/include/mach/irqs.h
index a118e61..b549d05 100644
--- a/arch/arm/mach-nomadik/include/mach/irqs.h
+++ b/arch/arm/mach-nomadik/include/mach/irqs.h
@@ -72,7 +72,7 @@
 #define NOMADIK_NR_GPIO128 /* last 4 not wired to pins 
*/
 #define NOMADIK_GPIO_TO_IRQ(gpio)  ((gpio) + NOMADIK_GPIO_OFFSET)
 #define NOMADIK_IRQ_TO_GPIO(irq)   ((irq) - NOMADIK_GPIO_OFFSET)
-#define NR_IRQS
NOMADIK_GPIO_TO_IRQ(NOMADIK_NR_GPIO)
+#define NOMADIK_NR_IRQS
NOMADIK_GPIO_TO_IRQ(NOMADIK_NR_GPIO)
 
 /* Following two are used by entry_macro.S, to access our dual-vic */
 #define VIC_REG_IRQSR0 0
diff --git a/arch/arm/mach-ux500/board-mop500.c 
b/arch/arm/mach-ux500/board-mop500.c
index a534d88..da2fd05 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -1,4 +1,3 @@
-
 /*
  * Copyright (C) 2008-2009 ST-Ericsson
  *
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index db3c52d..0a09647 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "devices-db8500.h"
 #include "ste-dma40-db8500.h"
diff --git a/arch/arm/mach-ux500/devices-common.c 
b/arch/arm/mach-ux500/devices-common.c
index dfdd4a5..0923dbd 100644
--- a/arch/arm/mach-ux500/devices-common.c
+++ b/arch/arm/mach-ux500/devices-common.c
@@ -15,6 +15,7 @@
 #include 
 
 #include 
+#include 
 
 #include "devices-common.h"
 
diff --git a/arch/arm/mach-ux500/devices-db8500.c 
b/arch/arm/mach-ux500/devices-db8500.c
index 91754a8..bec92a7 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 
 #include "ste-dma40-db8500.h"
 
diff --git a/arch/arm/mach-ux500/devices-db8500.h 
b/arch/arm/mach-ux500/devices-db8500.h
index 3c8010f..4b24c99 100644
--- a/arch/arm/mach-ux500/devices-db8500.h
+++ b/arch/arm/mach-ux500/devices-db8500.h
@@ -8,6 +8,7 @@
 #ifndef __DEVICES_DB8500_H
 #define __DEVICES_DB8500_H
 
+#include 
 #include "devices-common.h"
 
 struct ske_keypad_platform_data;
diff --git a/arch/arm/mach-ux500/include/mach/irqs.h 
b/arch/arm/mach-ux500/include/mach/irqs.h
index e892854..fc77b42 100644
--- a/arch/arm/mach-ux500/include/mach/irqs.h
+++ b/arch/arm/mach-ux500/include/mach/irqs.h
@@ -46,6 +46,6 @@
 #include 
 #endif
 
-#define NR_IRQSIRQ_BOARD_END
+#define UX500_NR_IRQS  IRQ_BOARD_END
 
 #endif 

[PATCH 1/4] pinctrl/nomadik: use irq_find_mapping()

[Linus Walleij]

From: Linus Walleij 

The code was using a homegrown method of looking up the offset
from the irq domain, not to be encouraged. Use the proper
irq_find_mapping() call instead.

Cc: Lee Jones 
Cc: Rob Herring 
Signed-off-by: Linus Walleij 
---
 drivers/pinctrl/pinctrl-nomadik.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-nomadik.c 
b/drivers/pinctrl/pinctrl-nomadik.c
index 3dde653..e031c84 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -826,16 +826,14 @@ static void __nmk_gpio_irq_handler(unsigned int irq, 
struct irq_desc *desc,
 {
struct nmk_gpio_chip *nmk_chip;
struct irq_chip *host_chip = irq_get_chip(irq);
-   unsigned int first_irq;
 
chained_irq_enter(host_chip, desc);
 
nmk_chip = irq_get_handler_data(irq);
-   first_irq = nmk_chip->domain->revmap_data.legacy.first_irq;
while (status) {
int bit = __ffs(status);
 
-   generic_handle_irq(first_irq + bit);
+   generic_handle_irq(irq_find_mapping(nmk_chip->domain, bit));
status &= ~BIT(bit);
}
 
-- 
1.7.11.3

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

[PATCH 3/4] pinctrl/nomadik: use simple or linear IRQ domain

[Linus Walleij]

From: Linus Walleij 

This alters the Nomadik pinctrl driver to:

- Call irqdomain_add_linear() for the DT case so we get
  all independent from IRQ numbers in this case.
- Call irqdomain_add_simple() for the legacy case, which
  allocates the IRQ descriptors for the Nomadik pin controller
  dynamically.

Cc: Lee Jones 
Cc: Rob Herring 
Signed-off-by: Linus Walleij 
---
 drivers/pinctrl/pinctrl-nomadik.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-nomadik.c 
b/drivers/pinctrl/pinctrl-nomadik.c
index e031c84..6aab107 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -1286,9 +1286,19 @@ static int __devinit nmk_gpio_probe(struct 
platform_device *dev)
 
platform_set_drvdata(dev, nmk_chip);
 
-   nmk_chip->domain = irq_domain_add_legacy(np, NMK_GPIO_PER_CHIP,
-   
NOMADIK_GPIO_TO_IRQ(pdata->first_gpio),
-   0, _gpio_irq_simple_ops, 
nmk_chip);
+   if (np) {
+   /* The DT case will just grab a set of IRQ numbers */
+   nmk_chip->domain = irq_domain_add_linear(np, NMK_GPIO_PER_CHIP,
+   _gpio_irq_simple_ops, nmk_chip);
+   } else {
+   /* Non-DT legacy mode, use hardwired IRQ numbers */
+   int irq_start;
+
+   irq_start = NOMADIK_GPIO_TO_IRQ(pdata->first_gpio);
+   nmk_chip->domain = irq_domain_add_simple(NULL,
+   NMK_GPIO_PER_CHIP, irq_start,
+   _gpio_irq_simple_ops, nmk_chip);
+   }
if (!nmk_chip->domain) {
dev_err(>dev, "failed to create irqdomain\n");
ret = -ENOSYS;
-- 
1.7.11.3

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

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Alex Deucher]

On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund  wrote:
> On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
>> > -Original Message-
>> > From: Andres Freund [mailto:and...@anarazel.de]
>> > Sent: Wednesday, September 26, 2012 9:41 AM
>> > To: Dan Carpenter
>> > Cc: Deucher, Alexander; LKML; David Airlie;
>> > dri-de...@lists.freedesktop.org Subject: Re: radeon: Regression between
>> > v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
>> >
>> > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
>> > > This is fixed now?
>> >
>> > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in
>> > rc6.
>> >
>> > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
>> > Sorry, I somehow accidentally marked your  email as read and thus didn't
>> > notice it.
>> >
>> > > I think I see the problem.  I think it's a limitation of the current
>> > > current
>> >
>> > modesetting API.  The current API sets up each display independently
>> > which doesn't work so well if there are resource restrictions.  There
>> > shouldn't be any contention on your board since you are only using 2
>> > non-DP displays.  It looks like X is mapping different crtcs to displays
>> > than the kernel fb.
>> >
>> > Initially the kernel set up the follow:
>> > > > [2.134901] [drm] crtc 0 using pll 0x2
>> > > > [2.362257] [drm] crtc 1 using pll 0x1
>> > > > [2.386709] [drm] crtc 2 using pll 0x0
>> > >
>> > > Crtc 0 -> DCPLL -> DP
>> > > Crtc 1 -> PPLL2 -> DVI
>> > > Crtc 2 -> PPLL1 -> DVI
>> > >
>> > > When X loads, it tried to set a different crtc to display mapping:
>> > > > [   60.679310] [drm] crtc 0 using pll 0xff
>> > > > [   60.789183] [drm] crtc 1 using pll 0x2
>> > > > [   60.819594] [drm] crtc 2 using pll 0x1
>> > >
>> > > Crtc 0 -> INVALID -> DVI 0
>> > > Crtc 1 -> DCPLL -> DP
>> > > Crtc 2 -> PPLL2 -> DVI 1
>> > >
>> > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by
>> > > crtc 1 and crtc  2 from the previous modeset.  Since the modeset API is
>> > > not atomic, it doesn't have the whole picture.  I'm not sure of a good
>> > > solution right now prior to the new atomic modeset API that is under
>> > > discussion.  I guess we can revert the patch for 3.6.  For 3.7 I guess
>> > > we need to validate the actual connector to make sure we aren't trying
>> > > to set a different configuration relating to the same connector
>> > > without first tearing down the first one.  In the interim, you should
>> > > be able to work around it by disabling the non-DP outputs and then
>> > > bringing than back up.
>> >
>> > Thanks! That explanation makes sense. I can work around it just fine,
>> > starting X multiple times works which coincides nicely with your
>> > explanation.
>> >
>> > The code in the 3.7 branch doesn't do that extended validation yet,
>> > rigth? If you want/need you can CC for testing once thats ready.
>>
>> It should handle it now.  If you could test it that would be great.
> Ok, just to be sure I tested Linus' tree and everything works fine there.
>
> Unfortunately thats not the case with a straight merge of alexdeucher/drm-
> next-3.7-wip. When gdm started *the first time* the DVI-connected (uhm, same
> sink type? Thats the saphire magic allowing more monitors on that type of
> graphics card?) I got a "unable to allocate a PPLL" error again. Logging
> in/starting a new X seems to fix that.

So you have a xorg.conf with a hardcoded configuration?  If so can you
send it to me?

Thanks,

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

Re: [PATCH 3/3] memory_hotplug: Don't modify the zone_start_pfn outside of zone_span_writelock()

[Ni zhan Chen]

On 09/27/2012 02:47 PM, Lai Jiangshan wrote:

The __add_zone() maybe call sleep-able init_currently_empty_zone()
to init wait_table,

But this function also modifies the zone_start_pfn without any lock.
It is bugy.

So we move this modification out, and we ensure the modification
of zone_start_pfn is only done with zone_span_writelock() held or in booting.

Since zone_start_pfn is not modified by init_currently_empty_zone()
grow_zone_span() needs to check zone_start_pfn before update it.

CC: Mel Gorman 
Signed-off-by: Lai Jiangshan 
Reported-by: Yasuaki ISIMATU 
Tested-by: Wen Congyang 
---
  mm/memory_hotplug.c |2 +-
  mm/page_alloc.c |3 +--
  2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index b62d429b..790561f 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -205,7 +205,7 @@ static void grow_zone_span(struct zone *zone, unsigned long 
start_pfn,
zone_span_writelock(zone);
  
  	old_zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;

-   if (start_pfn < zone->zone_start_pfn)
+   if (!zone->zone_start_pfn || start_pfn < zone->zone_start_pfn)
zone->zone_start_pfn = start_pfn;
  
  	zone->spanned_pages = max(old_zone_end_pfn, end_pfn) -

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c13ea75..2545013 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3997,8 +3997,6 @@ int __meminit init_currently_empty_zone(struct zone *zone,
return ret;
pgdat->nr_zones = zone_idx(zone) + 1;
  
-	zone->zone_start_pfn = zone_start_pfn;

-


then how can mminit_dprintk print zone->zone_start_pfn ? always print 0 
make no sense.



mminit_dprintk(MMINIT_TRACE, "memmap_init",
"Initialising map node %d zone %lu pfns %lu -> %lu\n",
pgdat->node_id,
@@ -4465,6 +4463,7 @@ static void __paginginit free_area_init_core(struct 
pglist_data *pgdat,
ret = init_currently_empty_zone(zone, zone_start_pfn,
size, MEMMAP_EARLY);
BUG_ON(ret);
+   zone->zone_start_pfn = zone_start_pfn;
memmap_init(size, nid, j, zone_start_pfn);
zone_start_pfn += size;
}


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

Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver

[Linus Walleij]

On Wed, Sep 26, 2012 at 8:07 PM, Murali Karicheri  wrote:

> +struct clk_davinci_pll_data {
> +   /* physical addresses set by platform code */
> +   u32 phy_pllm;
> +   /* if PLL has a prediv register this should be non zero */
> +   u32 phy_prediv;
> +   /* if PLL has a postdiv register this should be non zero */
> +   u32 phy_postdiv;
> +   /* mapped addresses. should be initialized by  */
> +   void __iomem *pllm;
> +   void __iomem *prediv;
> +   void __iomem *postdiv;
> +   u32 pllm_mask;
> +   u32 prediv_mask;
> +   u32 postdiv_mask;
> +   u32 num;
> +   /* framework flags */
> +   u32 flags;
> +   /* pll flags */
> +   u32 pll_flags;
> +   /* use this value for prediv */
> +   u32 fixed_prediv;
> +   /* multiply PLLM by this factor. By default most SOC set this to zero
> +* that translates to a multiplier of 1 and incrementer of 1.
> +* To override default, set this factor
> +*/
> +   u32 pllm_multiplier;
> +};
> +

No, that's not what I meant.

I meant like this:

/**
 * struct clk_davinci_pll_data - struct holding the PLL data
 * phy_pllm: physical addresses set by platform code
 * phy_prediv: ...
(...)
 */
struct clk_davinci_pll_data {
  u32 phy_pllm;
  u32 phy_prediv;
(...)
};

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Andres Freund]

On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund  wrote:
> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
> >> > -Original Message-
> >> > From: Andres Freund [mailto:and...@anarazel.de]
> >> > Sent: Wednesday, September 26, 2012 9:41 AM
> >> > To: Dan Carpenter
> >> > Cc: Deucher, Alexander; LKML; David Airlie;
> >> > dri-de...@lists.freedesktop.org Subject: Re: radeon: Regression
> >> > between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
> >> > 
> >> > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
> >> > > This is fixed now?
> >> > 
> >> > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is
> >> > in rc6.
> >> > 
> >> > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
> >> > Sorry, I somehow accidentally marked your  email as read and thus
> >> > didn't notice it.
> >> > 
> >> > > I think I see the problem.  I think it's a limitation of the current
> >> > > current
> >> > 
> >> > modesetting API.  The current API sets up each display independently
> >> > which doesn't work so well if there are resource restrictions.  There
> >> > shouldn't be any contention on your board since you are only using 2
> >> > non-DP displays.  It looks like X is mapping different crtcs to
> >> > displays than the kernel fb.
> >> > 
> >> > Initially the kernel set up the follow:
> >> > > > [2.134901] [drm] crtc 0 using pll 0x2
> >> > > > [2.362257] [drm] crtc 1 using pll 0x1
> >> > > > [2.386709] [drm] crtc 2 using pll 0x0
> >> > > 
> >> > > Crtc 0 -> DCPLL -> DP
> >> > > Crtc 1 -> PPLL2 -> DVI
> >> > > Crtc 2 -> PPLL1 -> DVI
> >> > > 
> >> > > When X loads, it tried to set a different crtc to display mapping:
> >> > > > [   60.679310] [drm] crtc 0 using pll 0xff
> >> > > > [   60.789183] [drm] crtc 1 using pll 0x2
> >> > > > [   60.819594] [drm] crtc 2 using pll 0x1
> >> > > 
> >> > > Crtc 0 -> INVALID -> DVI 0
> >> > > Crtc 1 -> DCPLL -> DP
> >> > > Crtc 2 -> PPLL2 -> DVI 1
> >> > > 
> >> > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use
> >> > > by crtc 1 and crtc  2 from the previous modeset.  Since the modeset
> >> > > API is not atomic, it doesn't have the whole picture.  I'm not sure
> >> > > of a good solution right now prior to the new atomic modeset API
> >> > > that is under discussion.  I guess we can revert the patch for 3.6.
> >> > >  For 3.7 I guess we need to validate the actual connector to make
> >> > > sure we aren't trying to set a different configuration relating to
> >> > > the same connector without first tearing down the first one.  In
> >> > > the interim, you should be able to work around it by disabling the
> >> > > non-DP outputs and then bringing than back up.
> >> > 
> >> > Thanks! That explanation makes sense. I can work around it just fine,
> >> > starting X multiple times works which coincides nicely with your
> >> > explanation.
> >> > 
> >> > The code in the 3.7 branch doesn't do that extended validation yet,
> >> > rigth? If you want/need you can CC for testing once thats ready.
> >> 
> >> It should handle it now.  If you could test it that would be great.
> > 
> > Ok, just to be sure I tested Linus' tree and everything works fine there.
> > 
> > Unfortunately thats not the case with a straight merge of
> > alexdeucher/drm- next-3.7-wip. When gdm started *the first time* the
> > DVI-connected (uhm, same sink type? Thats the saphire magic allowing
> > more monitors on that type of graphics card?) I got a "unable to
> > allocate a PPLL" error again. Logging in/starting a new X seems to fix
> > that.
> 
> So you have a xorg.conf with a hardcoded configuration?  If so can you
> send it to me?
Yes, but just setting the xrand positions:

Section "Monitor"
Identifier   "DVI-1"
Option   "Primary"  "True"
EndSection

Section "Monitor"
Identifier   "DVI-0"
Option   "RightOf"  "DVI-1"
Option   "Rotate"   "Left"
Option   "Primary"  "False"
EndSection

Section "Monitor"
Identifier   "Displayport-0"
Option   "LeftOf"   "DVI-1"
Option   "Rotate"   "Left"
Option   "Primary"  "False"
EndSection


Andres
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/4] perf annotate: configure objdump path at compile time

[Namhyung Kim]

On Thu, 27 Sep 2012 14:25:10 +0300, Irina Tirdea wrote:
>>> The perf built to run on the host needs to use arm-eabi-objdump from
>>> the toolchain so that it can analyse data recorded on Android. This
>>> patch is targeting this scenario, not the previous one. In this case,
>>> the CROSS_COMPILE option would be different than arm-eabi- so using
>>> $(CROSS_COMPILE)objdump would be wrong. objdump should be overridden
>>> when running make since there is no connection between the toolchain
>>> used here and the path for objdump. I am always overriding objdump
>>> when calling make, so I did not catch this.
>>>
>>> I think that I should change DEFAULT_OBJDUMP_PATH=objdump in the
>>> Makefile to handle the first scenario. I'll also explain this in the
>>> commit message so that it is more clear and make the same change for
>>> the addr2line patch.
>>>
>>> What do you think?
>>
>> I think the right thing to do is finding a correct objdump at runtime in
>> some way.  Why do you want to make it compile-time configurable?
>>
>
> The correct objdump path can be detected at runtime by setting the
> toolchain path. But since the name is arm-eabi-objdump and not
> objdump, it does not know to use it instead.
>
> The only way (I can think of) to change objdump at runtime would be to
> use the --objdump option for perf annotate (and provide a similar
> option for addr2line). The problem with this approach is that the user
> has to be aware that perf annotate uses the objdump tool and that he
> has to use the cross-compiler version instead. Since the user will
> have perf compiled for host as part of his Android tree, he will
> expect it to work without these further changes from his part. The
> path for objdump can be set in the Android Makefile at compile time so
> that the user doesn't need to be aware of it.

What I'm thinking is that perf can try to find cross-built binutils when
it detects perf.data file is came from other machine/architecture.
Fortunately perf_session_env was added recently and it has the arch
information from the file so we can use it to find the path.

Following patch is a proof-of-concept patch and only build tested.
What do you think?  Could you play with it for some time? :)

Thanks,
Namhyung


>From 7068a43a4b450c60fdcc8a3916ce624c1ef2c9b2 Mon Sep 17 00:00:00 2001
From: Namhyung Kim 
Date: Thu, 27 Sep 2012 21:54:33 +0900
Subject: [RFC] perf tools: Try to find cross-built objdump path

As we have architecture information of saved perf.data file, we can
try to find cross-built objdump path.

The triplets are incomplete and maybe need some regexp works.

Cc: Irina Tirdea 
Signed-off-by: Namhyung Kim 
---
 tools/perf/Makefile   |  2 +
 tools/perf/arch/common.c  | 42 +++
 tools/perf/builtin-annotate.c |  3 ++
 tools/perf/util/annotate.c| 96 +++
 tools/perf/util/annotate.h| 10 +
 5 files changed, 153 insertions(+)
 create mode 100644 tools/perf/arch/common.c

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 5973f383eb8e..b189229eb576 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -412,6 +412,8 @@ LIB_OBJS += $(OUTPUT)ui/helpline.o
 LIB_OBJS += $(OUTPUT)ui/hist.o
 LIB_OBJS += $(OUTPUT)ui/stdio/hist.o
 
+LIB_OBJS += $(OUTPUT)arch/common.o
+
 BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
 BUILTIN_OBJS += $(OUTPUT)builtin-bench.o
 # Benchmark modules
diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
new file mode 100644
index ..c3872427d135
--- /dev/null
+++ b/tools/perf/arch/common.c
@@ -0,0 +1,42 @@
+#include 
+
+const char * const arm_triplets[] = {
+   "arm-eabi-",
+   "arm-unknown-linux-",
+   "arm-unknown-linux-gnu-",
+   "arm-unknown-linux-gnueabi-",
+   NULL
+};
+
+const char * const powerpc_triplets[] = {
+   "powerpc-unknown-linux-gnu-",
+   "powerpc64-unknown-linux-gnu-",
+   NULL
+};
+
+const char * const s390_triplets[] = {
+   "s390-ibm-linux-",
+   NULL
+};
+
+const char * const sh_triplets[] = {
+   "sh-unknown-linux-gnu-",
+   "sh64-unknown-linux-gnu-",
+   NULL
+};
+
+const char * const sparc_triplets[] = {
+   "sparc-unknown-linux-gnu-",
+   "sparc64-unknown-linux-gnu-",
+   NULL
+};
+
+const char * const x86_triplets[] = {
+   "x86_64-pc-linux-gnu-",
+   "x86_64-unknown-linux-gnu-",
+   "i686-pc-linux-gnu-",
+   "i586-pc-linux-gnu-",
+   "i486-pc-linux-gnu-",
+   "i386-pc-linux-gnu-",
+   NULL
+};
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 9ea38540b873..20fe9bb6505b 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -186,6 +186,9 @@ static int __cmd_annotate(struct perf_annotate *ann)
goto out_delete;
}
 
+   if (!objdump_path)
+   try_objdump_path(session);
+
ret = perf_session__process_events(session, >tool);
if (ret)
   

Re: [PATCH 3/4] pinctrl/nomadik: use simple or linear IRQ domain

[Rob Herring]

On 09/27/2012 08:13 AM, Linus Walleij wrote:
> From: Linus Walleij 
> 
> This alters the Nomadik pinctrl driver to:
> 
> - Call irqdomain_add_linear() for the DT case so we get
>   all independent from IRQ numbers in this case.
> - Call irqdomain_add_simple() for the legacy case, which
>   allocates the IRQ descriptors for the Nomadik pin controller
>   dynamically.
> 
> Cc: Lee Jones 
> Cc: Rob Herring 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/pinctrl/pinctrl-nomadik.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-nomadik.c 
> b/drivers/pinctrl/pinctrl-nomadik.c
> index e031c84..6aab107 100644
> --- a/drivers/pinctrl/pinctrl-nomadik.c
> +++ b/drivers/pinctrl/pinctrl-nomadik.c
> @@ -1286,9 +1286,19 @@ static int __devinit nmk_gpio_probe(struct 
> platform_device *dev)
>  
>   platform_set_drvdata(dev, nmk_chip);
>  
> - nmk_chip->domain = irq_domain_add_legacy(np, NMK_GPIO_PER_CHIP,
> - 
> NOMADIK_GPIO_TO_IRQ(pdata->first_gpio),
> - 0, _gpio_irq_simple_ops, 
> nmk_chip);
> + if (np) {
> + /* The DT case will just grab a set of IRQ numbers */
> + nmk_chip->domain = irq_domain_add_linear(np, NMK_GPIO_PER_CHIP,
> + _gpio_irq_simple_ops, nmk_chip);


irq_start = -1;

if (!np)
irq_start = NOMADIK_GPIO_TO_IRQ(pdata->first_gpio);

and then always call irq_domain_add_simple.

Rob

> + } else {
> + /* Non-DT legacy mode, use hardwired IRQ numbers */
> + int irq_start;
> +
> + irq_start = NOMADIK_GPIO_TO_IRQ(pdata->first_gpio);
> + nmk_chip->domain = irq_domain_add_simple(NULL,
> + NMK_GPIO_PER_CHIP, irq_start,
> + _gpio_irq_simple_ops, nmk_chip);
> + }
>   if (!nmk_chip->domain) {
>   dev_err(>dev, "failed to create irqdomain\n");
>   ret = -ENOSYS;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hashtable: introduce a small and naive hashtable

[Steven Rostedt]

On Thu, 2012-09-27 at 09:11 -0400, Mathieu Desnoyers wrote:

> AFAIK, gcc nowadays use "inline" only as a hint

Only if CONFIG_OPTIMIZE_INLINING is set.

>From include/linux/compiler-gcc.h:

#if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
!defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
# define inline inline  __attribute__((always_inline)) notrace
# define __inline__ __inline__  __attribute__((always_inline)) notrace
# define __inline   __inline__attribute__((always_inline)) notrace
#else
/* A lot of inline functions can cause havoc with function tracing */
# define inline inline  notrace
# define __inline__ __inline__  notrace
# define __inline   __inlinenotrace
#endif

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/13] Add a __GFP_KMEMCG flag

[Mel Gorman]

On Tue, Sep 18, 2012 at 06:04:02PM +0400, Glauber Costa wrote:
> This flag is used to indicate to the callees that this allocation is a
> kernel allocation in process context, and should be accounted to
> current's memcg. It takes numerical place of the of the recently removed
> __GFP_NO_KSWAPD.
> 
> Signed-off-by: Glauber Costa 
> CC: Christoph Lameter 
> CC: Pekka Enberg 
> CC: Michal Hocko 
> CC: Johannes Weiner 
> CC: Suleiman Souhlal 
> CC: Rik van Riel 
> CC: Mel Gorman 
> Acked-by: Kamezawa Hiroyuki 

I agree with Christophs recommendation that this flag always exist instead
of being 0 in the !MEMCG_KMEM case. If __GFP_KMEMCG ever is used in another
part of the VM (which would be unexpected but still) then the behaviour
might differ too much between MEMCG_KMEM and !MEMCG_KMEM cases. As unlikely
as the case is, it's not impossible.

For tracing __GFP_KMEMCG should have an entry in
include/trace/events/gfpflags.h

Get rid of the CONFIG_MEMCG_KMEM check and update
include/trace/events/gfpflags.h and then feel free to stick my Acked-by
on it.

-- 
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/

[RFC v2] perf tools: Try to find cross-built objdump path

[Namhyung Kim]

From: Namhyung Kim 

As we have architecture information of saved perf.data file, we can
try to find cross-built objdump path.

The triplets are incomplete and maybe need some regexp works.

Cc: Irina Tirdea 
Signed-off-by: Namhyung Kim 
---
v2: don't modify env string

 tools/perf/Makefile   |   2 +
 tools/perf/arch/common.c  |  42 +
 tools/perf/builtin-annotate.c |   3 ++
 tools/perf/util/annotate.c| 103 ++
 tools/perf/util/annotate.h|  10 
 5 files changed, 160 insertions(+)
 create mode 100644 tools/perf/arch/common.c

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 5973f383eb8e..b189229eb576 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -412,6 +412,8 @@ LIB_OBJS += $(OUTPUT)ui/helpline.o
 LIB_OBJS += $(OUTPUT)ui/hist.o
 LIB_OBJS += $(OUTPUT)ui/stdio/hist.o
 
+LIB_OBJS += $(OUTPUT)arch/common.o
+
 BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
 BUILTIN_OBJS += $(OUTPUT)builtin-bench.o
 # Benchmark modules
diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
new file mode 100644
index ..c3872427d135
--- /dev/null
+++ b/tools/perf/arch/common.c
@@ -0,0 +1,42 @@
+#include 
+
+const char * const arm_triplets[] = {
+   "arm-eabi-",
+   "arm-unknown-linux-",
+   "arm-unknown-linux-gnu-",
+   "arm-unknown-linux-gnueabi-",
+   NULL
+};
+
+const char * const powerpc_triplets[] = {
+   "powerpc-unknown-linux-gnu-",
+   "powerpc64-unknown-linux-gnu-",
+   NULL
+};
+
+const char * const s390_triplets[] = {
+   "s390-ibm-linux-",
+   NULL
+};
+
+const char * const sh_triplets[] = {
+   "sh-unknown-linux-gnu-",
+   "sh64-unknown-linux-gnu-",
+   NULL
+};
+
+const char * const sparc_triplets[] = {
+   "sparc-unknown-linux-gnu-",
+   "sparc64-unknown-linux-gnu-",
+   NULL
+};
+
+const char * const x86_triplets[] = {
+   "x86_64-pc-linux-gnu-",
+   "x86_64-unknown-linux-gnu-",
+   "i686-pc-linux-gnu-",
+   "i586-pc-linux-gnu-",
+   "i486-pc-linux-gnu-",
+   "i386-pc-linux-gnu-",
+   NULL
+};
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 9ea38540b873..20fe9bb6505b 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -186,6 +186,9 @@ static int __cmd_annotate(struct perf_annotate *ann)
goto out_delete;
}
 
+   if (!objdump_path)
+   try_objdump_path(session);
+
ret = perf_session__process_events(session, >tool);
if (ret)
goto out_delete;
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index f0a910371377..df17c443e3b3 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -15,6 +15,7 @@
 #include "debug.h"
 #include "annotate.h"
 #include 
+#include 
 
 const char *disassembler_style;
 const char *objdump_path;
@@ -1140,3 +1141,105 @@ int symbol__tty_annotate(struct symbol *sym, struct map 
*map, int evidx,
 
return 0;
 }
+
+static bool lookup_path(char *name)
+{
+   bool found = false;
+   char *path, *tmp;
+   char buf[PATH_MAX];
+   char *env = getenv("PATH");
+
+   if (!env)
+   return false;
+
+   env = strdup(env);
+   if (!env)
+   return false;
+
+   path = strtok_r(env, ":", );
+   while (path) {
+   scnprintf(buf, sizeof(buf), "%s%s", path, name);
+   if (access(buf, F_OK) == 0) {
+   found = true;
+   break;
+   }
+   strtok_r(NULL, ":", );
+   }
+   free(env);
+   return found;
+}
+
+static int lookup_triplets(const char **triplets, const char *name)
+{
+   int i;
+   char buf[PATH_MAX];
+
+   for (i = 0; triplets[i] != NULL; i++) {
+   scnprintf(buf, sizeof(buf), "%s%s", triplets[i], name);
+   if (lookup_path(buf))
+   return i;
+   }
+   return -1;
+}
+
+static char *try_binutils_path(struct perf_session *session, const char *name)
+{
+   int idx;
+   char *arch, *env;
+   struct utsname uts;
+   const char **path_list;
+   char buf[PATH_MAX];
+
+   if (uname() < 0)
+   return NULL;
+
+   /*
+* We don't need to try to find objdump path for native system.
+* Just use default "objdump".
+*/
+   if (!strcmp(uts.machine, session->header.env.arch))
+   return NULL;
+
+   env = getenv("CROSS_COMPILE");
+   if (env) {
+   scnprintf(buf, sizeof(buf), "%s%s", env, name);
+   if (buf[0] == '/') {
+   if (access(buf, F_OK) == 0)
+   return strdup(buf);
+
+   return NULL;
+   }
+
+   if (lookup_path(buf))
+   return strdup(buf);
+   }
+
+   arch = 

Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected

[Mike Galbraith]

On Thu, 2012-09-27 at 12:20 +0200, Borislav Petkov wrote: 
> On Thu, Sep 27, 2012 at 12:17:22AM -0700, da...@lang.hm wrote:
> > It seems to me that trying to figure out if you are going to
> > overload the L2 is an impossible task, so just assume that it will
> > all fit, and the worst case is you have one balancing cycle where
> > you can't do as much work and then the normal balancing will kick in
> > and move something anyway.
> 
> Right, and this implies that when the load balancer runs, it will
> definitely move the task away from the L2. But what do I do in the cases
> where the two tasks don't overload the L2 and it is actually beneficial
> to keep them there? How does the load balancer know that?

It doesn't, but it has task_hot().  A preempted buddy may be pulled, but
the next wakeup will try to bring buddies back together.

-Mike 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] printk: drop ambiguous LOG_CONT flag

[Kay Sievers]

On Thu, Sep 27, 2012 at 12:33 AM, "Jan H. Schönherr"
 wrote:
> Am 26.09.2012 23:15, schrieb Greg Kroah-Hartman:
>> On Wed, Sep 26, 2012 at 07:58:45PM +0200, Jan H. Schönherr wrote:
>>> Against v3.6-rc7, only lightly tested.
>>
>> Well, against linux-next and highly tested would be best.  It's a bit
>> late to get this into linux-next for 3.7, how important is it really?
>
> There are no conflicting commits in linux-next, so it should apply there
> as well.
>
> "Tested" as in: it fixes my use case: multiple printk()s shortly after each
> other -- with KERN_prefix but without a newline at the end. Those were
> sometimes concatenated since that printk-rewrite.

Please provide the output of /dev/kmsg so we can see what's going on here.

> All other printk()s that I come across more often look as usual, before and
> after the patch. (Mostly singular printk()s, but I also checked the output
> from the oom-killer.)
>
> There is no need to include this hastily -- at least not from my point of view
> -- as it is already broken in 3.5 and nobody else seems to notice it
> (... and I have now a fix for my development printk()s). Should I resend the
> patch later?
>
> I was also hoping that Kay might share his opinion, as the LOG_CONT
> flag is rather young, and he might have some different plans for it.

It is a flag that we have not been able to merge a continuation line
in the buffer, because we had a race with another thread, or the
console lock was taken for a long time and we couldn't use the merge
buffer.

LOG_CONT is used to merge (not intended to be) separate records at
time we read them from the record buffer, and print them, it is also
exported as a flag in /dev/kmsg.

I don't think we can just remove it, we can not get that information
from the prefix+newlines, they are not sufficient.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] sta2x11-mfd : add apb-soc regs driver and factor out common code

[Davide Ciminaghi]

On Wed, Sep 26, 2012 at 05:49:33PM +0100, Mark Brown wrote:
> On Wed, Sep 26, 2012 at 06:31:45PM +0200, Davide Ciminaghi wrote:
> 
> > Oh, and there's another problem (I'm looking at the code right now, I had
> > forgotten about this): the clock framework also asks for a spinlock_t *.
> > Regmap has its own spinlock (or mutex), and I don't think it would be a
> > good idea trying to export it.
> 
> Why is this a problem?  Nested spinlocks are perfectly fine.

after some cups of coffee, I tried thinking about this subject again, and
here's what I found:

as far as I know, nested locks are fine provided that you always take them in
the same order and release them in the opposite order (lock A, lock B,
unlock B, unlock A). So my conclusion is that nested spinlocks require
potential regmap users of sta2x11 registers to take the sta2x11-mfd spinlock
first. The pattern would be (sctl registers for instance):

spinlock_t *mfd_lock;
void *addr;

/* 
   Read sta2x11-mfd spinlock address for sctl registers and put it into
   mfd_lock
*/
sta2x11_mfd_get_regs_data(pdev, sta2x11_sctl, , _lock);

..

/* Take the outer lock */
spin_lock(mfd_lock);
/* 
   Take the inner lock, do whatever you need to do and release the inner lock
*/
regmap_...();
/* Release the outer lock */
spin_unlock(mfd_lock);

The other way around (taking the regmap spinlock as the "outer" one)
would imply at least exporting the regmap spinlock/mutex address or making the
regmap.lock/unlock function pointers public somehow, not
to mention the fact that, for instance, the clock framework helpers should be
modified to deal with nested locking.

If the above is correct, I'm not sure we'd gain a lot from regmap,
because we'd still need some sta2x11 extra code around regmap calls.

Maybe there's another solution: what about adding a couple of function
pointers (lock, unlock) to struct regmap_config ? If they're set to NULL,
everything works as usual. If they're not NULL, regmap uses such functions
to do locking and unlocking instead of the usual ones (and regmap_bus.fast_io
is ignored). I think this wouldn't hurt existing regmap users and allow
sta2x11-mfd to have just one spinlock for everything, no need for nested
locking this way.

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

Re: [PATCH 2/4] irqdomain: augment add_simple() to allocate descs

[Rob Herring]

On 09/27/2012 08:13 AM, Linus Walleij wrote:
> From: Linus Walleij 
> 
> Currently we rely on all IRQ chip instances to dynamically
> allocate their IRQ descriptors unless they use the linear
> IRQ domain. So for irqdomain_add_legacy() and
> irqdomain_add_simple() the caller need to make sure that
> descriptors are allocated.
> 
> Let's slightly augment the yet unused irqdomain_add_simple()
> to also allocate descriptors as a means to simplify usage
> and avoid code duplication throughout the kernel.
> 
> We warn if descriptors cannot be allocated, e.g. if a
> platform has the bad habit of hogging descriptors at boot
> time.
> 
> Cc: Rob Herring 
> Cc: Thomas Gleixner 
> Cc: Grant Likely 
> Cc: Russell King 
> Cc: Lee Jones 
> Signed-off-by: Linus Walleij 
> ---
> Rob/Grant/Thomas if you ACK this I will take it through the
> pinctrl tree since I introduce its only user right there.

You really should have Grant's ack here.

> ---
>  kernel/irq/irqdomain.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 49a7772..a0655b6 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -148,7 +148,8 @@ static unsigned int irq_domain_legacy_revmap(struct 
> irq_domain *domain,
>   * @host_data: Controller private data pointer
>   *
>   * Allocates a legacy irq_domain if irq_base is positive or a linear
> - * domain otherwise.
> + * domain otherwise. For the legacy domain, IRQ descriptors will also
> + * be allocated.
>   *
>   * This is intended to implement the expected behaviour for most
>   * interrupt controllers which is that a linear mapping should
> @@ -162,11 +163,21 @@ struct irq_domain *irq_domain_add_simple(struct 
> device_node *of_node,
>const struct irq_domain_ops *ops,
>void *host_data)
>  {
> - if (first_irq > 0)
> - return irq_domain_add_legacy(of_node, size, first_irq, 0,
> + if (first_irq > 0) {
> + int irq_base;
> +
> + irq_base = irq_alloc_descs(first_irq, 0, size, numa_node_id());

This will always fail for !SPARSE_IRQ, so we probably don't want warn in
that case. So perhaps something like this:

int irq_base = first_irq;

if (is_enabled(CONFIG_SPARSE_IRQ)) {
irq_base = irq_alloc_descs(first_irq, 0, size, numa_node_id());
if (irq_base < 0) {
WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming 
pre-allocated\n",
 first_irq);
irq_base = first_irq;
}
}

> + if (irq_base < 0) {
> + WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming 
> pre-allocated\n",
> +  first_irq);
> + irq_base = first_irq;
> + }
> + return irq_domain_add_legacy(of_node, size, irq_base, 0,
>ops, host_data);
> - else
> - return irq_domain_add_linear(of_node, size, ops, host_data);
> + }
> +
> + /* A linear domain is the default */
> + return irq_domain_add_linear(of_node, size, ops, host_data);
>  }
>  
>  /**
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: da9052-core: Fix request_threaded_irq() parameter

[Marek Vasut]

Dear Fabio Estevam,

> From: Fabio Estevam 
> 
> On a mx53qsb dt-kernel the da9052-core driver fails to probe:
> 
> da9052 1-0048: DA9052 ADC IRQ failed ret=-22
> 
> In request_threaded_irq() the first parameter is missing the
> da9052->irq_base.
> 
> Fix it and avoid the error.
> 
> Also define 'DA9052_IRQF' for improving readability.
> 
> Signed-off-by: Fabio Estevam 

Reviewed-by: Marek Vasut 

> ---
>  drivers/mfd/da9052-core.c |   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> index a0a62b2..a3450d2 100644
> --- a/drivers/mfd/da9052-core.c
> +++ b/drivers/mfd/da9052-core.c
> @@ -33,6 +33,7 @@
>  #define DA9052_IRQ_MASK_POS_60x20
>  #define DA9052_IRQ_MASK_POS_70x40
>  #define DA9052_IRQ_MASK_POS_80x80
> +#define DA9052_IRQF  (IRQF_TRIGGER_LOW | IRQF_ONESHOT)
> 
>  static bool da9052_reg_readable(struct device *dev, unsigned int reg)
>  {
> @@ -788,16 +789,15 @@ int __devinit da9052_device_init(struct da9052
> *da9052, u8 chip_id) da9052->irq_base = pdata->irq_base;
> 
>   ret = regmap_add_irq_chip(da9052->regmap, da9052->chip_irq,
> -   IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> -   da9052->irq_base, _regmap_irq_chip,
> -   >irq_data);
> +   DA9052_IRQF, da9052->irq_base,
> +   _regmap_irq_chip, >irq_data);
>   if (ret < 0)
>   goto regmap_err;
> 
>   da9052->irq_base = regmap_irq_chip_get_base(da9052->irq_data);
> 
> - ret = request_threaded_irq(DA9052_IRQ_ADC_EOM, NULL, da9052_auxadc_irq,
> -IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> + ret = request_threaded_irq(da9052->irq_base + DA9052_IRQ_ADC_EOM, NULL,
> +da9052_auxadc_irq, DA9052_IRQF,
>  "adc irq", da9052);
>   if (ret != 0)
>   dev_err(da9052->dev, "DA9052 ADC IRQ failed ret=%d\n", ret);

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/13] memcg: kmem controller infrastructure

[Michal Hocko]

On Thu 27-09-12 15:31:57, Glauber Costa wrote:
> On 09/26/2012 07:51 PM, Michal Hocko wrote:
> > On Tue 18-09-12 18:04:03, Glauber Costa wrote:
[...]
> >> +  *_memcg = NULL;
> >> +  rcu_read_lock();
> >> +  p = rcu_dereference(current->mm->owner);
> >> +  memcg = mem_cgroup_from_task(p);
> > 
> > mem_cgroup_from_task says it can return NULL. Do we care here? If not
> > then please put VM_BUG_ON(!memcg) here.
> > 
> >> +  rcu_read_unlock();
> >> +
> >> +  if (!memcg_can_account_kmem(memcg))
> >> +  return true;
> >> +
> >> +  mem_cgroup_get(memcg);
> > 
> > I am confused. Why do we take a reference to memcg rather than css_get
> > here? Ahh it is because we keep the reference while the page is
> > allocated, right? Comment please.
> ok.
> 
> > 
> > I am still not sure whether we need css_get here as well. How do you
> > know that the current is not moved in parallel and it is a last task in
> > a group which then can go away?
> 
> the reference count aquired by mem_cgroup_get will still prevent the
> memcg from going away, no?

Yes but you are outside of the rcu now and we usually do css_get before
we rcu_unlock. mem_cgroup_get just makes sure the group doesn't get
deallocated but it could be gone before you call it. Or I am just
confused - these 2 levels of ref counting is really not nice.

Anyway, I have just noticed that __mem_cgroup_try_charge does
VM_BUG_ON(css_is_removed(>css)) on a given memcg so you should
keep css ref count up as well.

> >> +  /* The page allocation failed. Revert */
> >> +  if (!page) {
> >> +  memcg_uncharge_kmem(memcg, PAGE_SIZE << order);
> >> +  return;
> >> +  }
> >> +
> >> +  pc = lookup_page_cgroup(page);
> >> +  lock_page_cgroup(pc);
> >> +  pc->mem_cgroup = memcg;
> >> +  SetPageCgroupUsed(pc);
> >> +  unlock_page_cgroup(pc);
> >> +}
> >> +
> >> +void __memcg_kmem_uncharge_page(struct page *page, int order)
> >> +{
> >> +  struct mem_cgroup *memcg = NULL;
> >> +  struct page_cgroup *pc;
> >> +
> >> +
> >> +  pc = lookup_page_cgroup(page);
> >> +  /*
> >> +   * Fast unlocked return. Theoretically might have changed, have to
> >> +   * check again after locking.
> >> +   */
> >> +  if (!PageCgroupUsed(pc))
> >> +  return;
> >> +
> >> +  lock_page_cgroup(pc);
> >> +  if (PageCgroupUsed(pc)) {
> >> +  memcg = pc->mem_cgroup;
> >> +  ClearPageCgroupUsed(pc);
> >> +  }
> >> +  unlock_page_cgroup(pc);
> >> +
> >> +  /*
> >> +   * Checking if kmem accounted is enabled won't work for uncharge, since
> >> +   * it is possible that the user enabled kmem tracking, allocated, and
> >> +   * then disabled it again.
> > 
> > disabling cannot happen, right?
> > 
> not anymore, right. I can update the comment, 

yes, it is confusing

> but I still believe it is a lot saner to trust information in
> page_cgroup.

I have no objections against that. PageCgroupUsed test and using
pc->mem_cgroup is fine.

> >> +#ifdef CONFIG_MEMCG_KMEM
> >> +int memcg_charge_kmem(struct mem_cgroup *memcg, gfp_t gfp, u64 size)
> >> +{
> >> +  struct res_counter *fail_res;
> >> +  struct mem_cgroup *_memcg;
> >> +  int ret;
> >> +  bool may_oom;
> >> +  bool nofail = false;
> >> +
> >> +  may_oom = (gfp & __GFP_WAIT) && (gfp & __GFP_FS) &&
> >> +  !(gfp & __GFP_NORETRY);
> > 
> > A comment please? Why __GFP_IO is not considered for example?
> > 
> > 
> 
> Actually, I believe testing for GFP_WAIT and !GFP_NORETRY would be enough.
> 
> The rationale here is, of course, under which circumstance would it be
> valid to call the oom killer? Which is, if the allocation can wait, and
> can retry.

Yes __GFP_WAIT is clear because memcg OOM can wait for arbitrary amount
of time (wait for userspace action on oom_control). __GFP_NORETRY
couldn't get to oom before because oom was excluded explicitely for THP
and migration didn't go through the charging path to reach the oom.
But I do agree that __GFP_NORETRY allocations shouldn't cause the OOM
because we should rather fail the allocation from kernel rather than
shoot something.

-- 
Michal Hocko
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 v3 05/13] Add a __GFP_KMEMCG flag

[Glauber Costa]

On 09/27/2012 05:34 PM, Mel Gorman wrote:
> On Tue, Sep 18, 2012 at 06:04:02PM +0400, Glauber Costa wrote:
>> This flag is used to indicate to the callees that this allocation is a
>> kernel allocation in process context, and should be accounted to
>> current's memcg. It takes numerical place of the of the recently removed
>> __GFP_NO_KSWAPD.
>>
>> Signed-off-by: Glauber Costa 
>> CC: Christoph Lameter 
>> CC: Pekka Enberg 
>> CC: Michal Hocko 
>> CC: Johannes Weiner 
>> CC: Suleiman Souhlal 
>> CC: Rik van Riel 
>> CC: Mel Gorman 
>> Acked-by: Kamezawa Hiroyuki 
> 
> I agree with Christophs recommendation that this flag always exist instead
> of being 0 in the !MEMCG_KMEM case. If __GFP_KMEMCG ever is used in another
> part of the VM (which would be unexpected but still) then the behaviour
> might differ too much between MEMCG_KMEM and !MEMCG_KMEM cases. As unlikely
> as the case is, it's not impossible.
> 
> For tracing __GFP_KMEMCG should have an entry in
> include/trace/events/gfpflags.h
> 
> Get rid of the CONFIG_MEMCG_KMEM check and update
> include/trace/events/gfpflags.h and then feel free to stick my Acked-by
> on it.
> 

Thanks, that is certainly doable.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] sta2x11-mfd : add apb-soc regs driver and factor out common code

[Mark Brown]

On Thu, Sep 27, 2012 at 03:41:10PM +0200, Davide Ciminaghi wrote:

> Maybe there's another solution: what about adding a couple of function
> pointers (lock, unlock) to struct regmap_config ? If they're set to NULL,
> everything works as usual. If they're not NULL, regmap uses such functions
> to do locking and unlocking instead of the usual ones (and regmap_bus.fast_io
> is ignored). I think this wouldn't hurt existing regmap users and allow
> sta2x11-mfd to have just one spinlock for everything, no need for nested
> locking this way.

That might work, yes, and would be generally useful I think.  Or we
could add regmap based versions of the clock utilities (which would also
be useful anyway).  Or both.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/13] mm: Allocate kernel pages to the right memcg

[Mel Gorman]

On Tue, Sep 18, 2012 at 06:04:04PM +0400, Glauber Costa wrote:
> When a process tries to allocate a page with the __GFP_KMEMCG flag, the
> page allocator will call the corresponding memcg functions to validate
> the allocation. Tasks in the root memcg can always proceed.
> 
> To avoid adding markers to the page - and a kmem flag that would
> necessarily follow, as much as doing page_cgroup lookups for no reason,
> whoever is marking its allocations with __GFP_KMEMCG flag is responsible
> for telling the page allocator that this is such an allocation at
> free_pages() time. This is done by the invocation of
> __free_accounted_pages() and free_accounted_pages().
> 
> [ v2: inverted test order to avoid a memcg_get leak,
>   free_accounted_pages simplification ]
> 
> Signed-off-by: Glauber Costa 
> CC: Christoph Lameter 
> CC: Pekka Enberg 
> CC: Michal Hocko 
> CC: Johannes Weiner 
> CC: Suleiman Souhlal 
> CC: Mel Gorman 
> Acked-by: Kamezawa Hiroyuki 
> ---
>  include/linux/gfp.h |  3 +++
>  mm/page_alloc.c | 35 +++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index d8eae4d..029570f 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -370,6 +370,9 @@ extern void free_pages(unsigned long addr, unsigned int 
> order);
>  extern void free_hot_cold_page(struct page *page, int cold);
>  extern void free_hot_cold_page_list(struct list_head *list, int cold);
>  
> +extern void __free_accounted_pages(struct page *page, unsigned int order);
> +extern void free_accounted_pages(unsigned long addr, unsigned int order);
> +
>  #define __free_page(page) __free_pages((page), 0)
>  #define free_page(addr) free_pages((addr), 0)
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b0c5a52..897d8e2 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2573,6 +2573,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int 
> order,
>   struct page *page = NULL;
>   int migratetype = allocflags_to_migratetype(gfp_mask);
>   unsigned int cpuset_mems_cookie;
> + struct mem_cgroup *memcg = NULL;
>  
>   gfp_mask &= gfp_allowed_mask;
>  
> @@ -2591,6 +2592,13 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int 
> order,
>   if (unlikely(!zonelist->_zonerefs->zone))
>   return NULL;
>  
> + /*
> +  * Will only have any effect when __GFP_KMEMCG is set.  This is
> +  * verified in the (always inline) callee
> +  */
> + if (!memcg_kmem_newpage_charge(gfp_mask, , order))
> + return NULL;
> +

1. returns quickly if memcg disabled
2. returns quickly if !__GFP_KMEMCG
3. returns quickly for kernel threads and interrupts

I'm expecting that these paths are completely dead when kmem accounting
is off so

Acked-by: Mel Gorman 


That said, it's not directly related to this patch but I would suggest that
you also check for TIF_MEMDIE in memcg_kmem_newpage_charge. It would be very
silly if a process failed to exit because it couldn't allocate a page it
needed. I expect that such a case is impossible today but it might change in
the future. If you're doing another revision, an extra check would not hurt.

It's difficult to predict if it should be making all the checks that
gfp_to_alloc_flags() does but you might need to in the future so keep it
in mind.




>  retry_cpuset:
>   cpuset_mems_cookie = get_mems_allowed();
>  
> @@ -2624,6 +2632,8 @@ out:
>   if (unlikely(!put_mems_allowed(cpuset_mems_cookie) && !page))
>   goto retry_cpuset;
>  
> + memcg_kmem_commit_charge(page, memcg, order);
> +
>   return page;

Ok.

>  }
>  EXPORT_SYMBOL(__alloc_pages_nodemask);
> @@ -2676,6 +2686,31 @@ void free_pages(unsigned long addr, unsigned int order)
>  
>  EXPORT_SYMBOL(free_pages);
>  
> +/*
> + * __free_accounted_pages and free_accounted_pages will free pages allocated
> + * with __GFP_KMEMCG.
> + *
> + * Those pages are accounted to a particular memcg, embedded in the
> + * corresponding page_cgroup. To avoid adding a hit in the allocator to 
> search
> + * for that information only to find out that it is NULL for users who have 
> no
> + * interest in that whatsoever, we provide these functions.
> + *
> + * The caller knows better which flags it relies on.
> + */
> +void __free_accounted_pages(struct page *page, unsigned int order)
> +{
> + memcg_kmem_uncharge_page(page, order);
> + __free_pages(page, order);
> +}
> +
> +void free_accounted_pages(unsigned long addr, unsigned int order)
> +{
> + if (addr != 0) {
> + VM_BUG_ON(!virt_addr_valid((void *)addr));

This is probably overkill. If it's invalid, the next line is likely to
blow up anyway. It's no biggie.

> + __free_accounted_pages(virt_to_page((void *)addr), order);
> + }
> +}
> +
>  static void *make_alloc_exact(unsigned long addr, unsigned order, size_t 
> size)
>  {
>   if (addr) {
> -- 
> 1.7.11.4
> 

-- 
Mel Gorman
SUSE Labs
--

Re: [PATCH v3 07/13] mm: Allocate kernel pages to the right memcg

[Michal Hocko]

On Tue 18-09-12 18:04:04, Glauber Costa wrote:
> When a process tries to allocate a page with the __GFP_KMEMCG flag, the
> page allocator will call the corresponding memcg functions to validate
> the allocation. Tasks in the root memcg can always proceed.
> 
> To avoid adding markers to the page - and a kmem flag that would
> necessarily follow, as much as doing page_cgroup lookups for no reason,
> whoever is marking its allocations with __GFP_KMEMCG flag is responsible
> for telling the page allocator that this is such an allocation at
> free_pages() time. This is done by the invocation of
> __free_accounted_pages() and free_accounted_pages().
> 
> [ v2: inverted test order to avoid a memcg_get leak,
>   free_accounted_pages simplification ]
> 
> Signed-off-by: Glauber Costa 
> CC: Christoph Lameter 
> CC: Pekka Enberg 
> CC: Michal Hocko 
> CC: Johannes Weiner 
> CC: Suleiman Souhlal 
> CC: Mel Gorman 
> Acked-by: Kamezawa Hiroyuki 

Acked-by: Michal Hocko 

Thanks!

> ---
>  include/linux/gfp.h |  3 +++
>  mm/page_alloc.c | 35 +++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index d8eae4d..029570f 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -370,6 +370,9 @@ extern void free_pages(unsigned long addr, unsigned int 
> order);
>  extern void free_hot_cold_page(struct page *page, int cold);
>  extern void free_hot_cold_page_list(struct list_head *list, int cold);
>  
> +extern void __free_accounted_pages(struct page *page, unsigned int order);
> +extern void free_accounted_pages(unsigned long addr, unsigned int order);
> +
>  #define __free_page(page) __free_pages((page), 0)
>  #define free_page(addr) free_pages((addr), 0)
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b0c5a52..897d8e2 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2573,6 +2573,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int 
> order,
>   struct page *page = NULL;
>   int migratetype = allocflags_to_migratetype(gfp_mask);
>   unsigned int cpuset_mems_cookie;
> + struct mem_cgroup *memcg = NULL;
>  
>   gfp_mask &= gfp_allowed_mask;
>  
> @@ -2591,6 +2592,13 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int 
> order,
>   if (unlikely(!zonelist->_zonerefs->zone))
>   return NULL;
>  
> + /*
> +  * Will only have any effect when __GFP_KMEMCG is set.  This is
> +  * verified in the (always inline) callee
> +  */
> + if (!memcg_kmem_newpage_charge(gfp_mask, , order))
> + return NULL;
> +
>  retry_cpuset:
>   cpuset_mems_cookie = get_mems_allowed();
>  
> @@ -2624,6 +2632,8 @@ out:
>   if (unlikely(!put_mems_allowed(cpuset_mems_cookie) && !page))
>   goto retry_cpuset;
>  
> + memcg_kmem_commit_charge(page, memcg, order);
> +
>   return page;
>  }
>  EXPORT_SYMBOL(__alloc_pages_nodemask);
> @@ -2676,6 +2686,31 @@ void free_pages(unsigned long addr, unsigned int order)
>  
>  EXPORT_SYMBOL(free_pages);
>  
> +/*
> + * __free_accounted_pages and free_accounted_pages will free pages allocated
> + * with __GFP_KMEMCG.
> + *
> + * Those pages are accounted to a particular memcg, embedded in the
> + * corresponding page_cgroup. To avoid adding a hit in the allocator to 
> search
> + * for that information only to find out that it is NULL for users who have 
> no
> + * interest in that whatsoever, we provide these functions.
> + *
> + * The caller knows better which flags it relies on.
> + */
> +void __free_accounted_pages(struct page *page, unsigned int order)
> +{
> + memcg_kmem_uncharge_page(page, order);
> + __free_pages(page, order);
> +}
> +
> +void free_accounted_pages(unsigned long addr, unsigned int order)
> +{
> + if (addr != 0) {
> + VM_BUG_ON(!virt_addr_valid((void *)addr));
> + __free_accounted_pages(virt_to_page((void *)addr), order);
> + }
> +}
> +
>  static void *make_alloc_exact(unsigned long addr, unsigned order, size_t 
> size)
>  {
>   if (addr) {
> -- 
> 1.7.11.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Michal Hocko
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 2/4] irqdomain: augment add_simple() to allocate descs

[Paul Mundt]

On Thu, Sep 27, 2012 at 03:13:45PM +0200, Linus Walleij wrote:
> + if (first_irq > 0) {
> + int irq_base;
> +
> + irq_base = irq_alloc_descs(first_irq, 0, size, numa_node_id());
> + if (irq_base < 0) {
> + WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming 
> pre-allocated\n",
> +  first_irq);
> + irq_base = first_irq;
> + }
> + return irq_domain_add_legacy(of_node, size, irq_base, 0,
>ops, host_data);

If first_irq is specified you presumably want irq_alloc_desc_at()
behaviour, so you should use irq_alloc_descs(first_irq, first_irq, ...),
similar to what irq_create_strict_mappings() does.

Also don't use numa_node_id() for this, of_node_to_nid() handles both the
OF and non-OF cases.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] staging/sbe-2t3e3: Use netdev_ printks in main.c

[YAMANE Toshiaki]

fixed below checkpatch warning.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: YAMANE Toshiaki 
---
 drivers/staging/sbe-2t3e3/main.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/sbe-2t3e3/main.c b/drivers/staging/sbe-2t3e3/main.c
index f3dbef6..48d80eb 100644
--- a/drivers/staging/sbe-2t3e3/main.c
+++ b/drivers/staging/sbe-2t3e3/main.c
@@ -135,9 +135,10 @@ void t3e3_read_card_serial_number(struct channel *sc)
for (i = 0; i < 3; i++)
sc->ether.card_serial_number[i] = t3e3_eeprom_read_word(sc, 10 
+ i);
 
-   printk(KERN_INFO "SBE wanPMC-2T3E3 serial number: %04X%04X%04X\n",
-  sc->ether.card_serial_number[0], sc->ether.card_serial_number[1],
-  sc->ether.card_serial_number[2]);
+   netdev_info(sc->dev, "SBE wanPMC-2T3E3 serial number: %04X%04X%04X\n",
+   sc->ether.card_serial_number[0], 
+   sc->ether.card_serial_number[1],
+   sc->ether.card_serial_number[2]);
 }
 
 /*
-- 
1.7.9.5

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

[PATCH 2/3] staging/sbe-2t3e3: Use netdev_ or dev_ or pr_ printks in module.c

[YAMANE Toshiaki]

fixed below checkpatch warning.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

and add pr_fmt.

Signed-off-by: YAMANE Toshiaki 
---
 drivers/staging/sbe-2t3e3/module.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/sbe-2t3e3/module.c 
b/drivers/staging/sbe-2t3e3/module.c
index cd778b3..4547137 100644
--- a/drivers/staging/sbe-2t3e3/module.c
+++ b/drivers/staging/sbe-2t3e3/module.c
@@ -10,6 +10,8 @@
  * This code is based on a driver written by SBE Inc.
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -66,7 +68,7 @@ static int __devinit t3e3_init_channel(struct channel 
*channel, struct pci_dev *
 
dev = alloc_hdlcdev(channel);
if (!dev) {
-   printk(KERN_ERR "SBE 2T3E3" ": Out of memory\n");
+   pr_err("SBE 2T3E3" ": Out of memory\n");
goto free_regions;
}
 
@@ -93,7 +95,8 @@ static int __devinit t3e3_init_channel(struct channel 
*channel, struct pci_dev *
t3e3_init(channel);
 
if (request_irq(dev->irq, _intr, IRQF_SHARED, dev->name, dev)) {
-   printk(KERN_WARNING "%s: could not get irq: %d\n", dev->name, 
dev->irq);
+   netdev_warn(channel->dev, "%s: could not get irq: %d\n",
+   dev->name, dev->irq);
goto free_regions;
}
 
@@ -137,7 +140,8 @@ static int __devinit t3e3_init_card(struct pci_dev *pdev, 
const struct pci_devic
break; /* found the second channel */
 
if (!pdev1) {
-   printk(KERN_ERR "SBE 2T3E3" ": Can't find the second 
channel\n");
+   dev_err(>dev,
+   "SBE 2T3E3" ": Can't find the second 
channel\n");
return -EFAULT;
}
channels = 2;
@@ -146,7 +150,7 @@ static int __devinit t3e3_init_card(struct pci_dev *pdev, 
const struct pci_devic
 
card = kzalloc(sizeof(struct card) + channels * sizeof(struct channel), 
GFP_KERNEL);
if (!card) {
-   printk(KERN_ERR "SBE 2T3E3" ": Out of memory\n");
+   dev_err(>dev, "SBE 2T3E3" ": Out of memory\n");
return -ENOBUFS;
}
 
-- 
1.7.9.5

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

[PATCH 3/3] staging/sbe-2t3e3: Use netdev_ printks in cpld.c

[YAMANE Toshiaki]

fixed below checkpatch warning.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: YAMANE Toshiaki 
---
 drivers/staging/sbe-2t3e3/cpld.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/sbe-2t3e3/cpld.c b/drivers/staging/sbe-2t3e3/cpld.c
index cc2b54d..27365f9 100644
--- a/drivers/staging/sbe-2t3e3/cpld.c
+++ b/drivers/staging/sbe-2t3e3/cpld.c
@@ -338,7 +338,7 @@ void cpld_set_fractional_mode(struct channel *sc, u32 mode,
   SBE_2T3E3_CPLD_VAL_FRACTIONAL_MODE_2);
break;
default:
-   printk(KERN_ERR "wrong mode in set_fractional_mode\n");
+   netdev_err(sc->dev, "wrong mode in set_fractional_mode\n");
return;
}
 
-- 
1.7.9.5

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

Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data

[Andy Shevchenko]

On Thu, Sep 27, 2012 at 1:06 PM, Vinod Koul  wrote:
> On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote:
>> Not all of the controllers support the 64 bit data width. Make it 
>> configurable
>> via platform data. The driver will try to get a value from the component
>> parameters, otherwise it will use the platform data.
>>
> What was this gen against, I can apply this.
Just rebased to recent linux-next, no conflicts.
...
Applying: dw_dmac: mark dwc_dump_chan_regs as inline
Applying: dw_dmac: fill optional encoded parameters in register structure
Applying: dw_dmac: get number of channels from hardware if possible
Applying: dw_dmac: autoconfigure block_size or use platform data
Applying: dw_dmac: autoconfigure data_width or get it via platform data
Applying: dw_dmac: introduce software emulation of LLP transfers
...

Have you kept the order of the patches?



-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG] Deferred probing in driver model is racy, resulting in lost probes

[Russell King - ARM Linux]

On Thu, Sep 27, 2012 at 07:47:46AM +0800, Ming Lei wrote:
> On Thu, Sep 27, 2012 at 4:23 AM, Russell King - ARM Linux
>  wrote:
> > To be honest, I've not bothered to test the above patch, and now when I
> > look at it, I notice it's broken - in that on error it will corrupt the
> > driver list.  Take a look at the error path.
> >
> > priv is drv->p.  We add priv->knode_bus to the driver list.  If
> > driver_attach() returns an error, then we go to out_unregister, which
> 
> In fact, driver_attach() always returns zero, so it does __not__ affect
> your test.

It may not affect my test, but the fact is, that patch lays down the
foundations for bugs to be introduced.  Now, while I can test it (and
have done) I don't think it's suitable for mainline because of _that_.

If driver_attach() always returns zero, there's no point in it returning
a value - it might as well return void and stop leading people to
believe that it might return an error.  So I suggest this alternative
patch instead, which gets rid of what is effectively dead code, and
probably a few warnings about not checking the return value from a
__must_check function (see usb-serial.c).

With this patch, no one is lead into a false sense of security that,
after your patch, if driver_attach() ever returns an error, proper
cleanup will happen - it's blatently obvious to anyone modifying it
that if they do want it to return an error, they have to audit all the
users of it, which IMHO is a good thing.

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 2bcef65..39b3ef4 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -714,12 +714,10 @@ int bus_add_driver(struct device_driver *drv)
if (error)
goto out_unregister;
 
-   if (drv->bus->p->drivers_autoprobe) {
-   error = driver_attach(drv);
-   if (error)
-   goto out_unregister;
-   }
klist_add_tail(>knode_bus, >p->klist_drivers);
+   if (drv->bus->p->drivers_autoprobe)
+   driver_attach(drv);
+
module_add_driver(drv->owner, drv);
 
error = driver_create_file(drv, _attr_uevent);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4b01ab3..2999df5 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -456,7 +456,7 @@ static int __driver_attach(struct device *dev, void *data)
  * returns 0 and the @dev->driver is set, we've found a
  * compatible pair.
  */
-int driver_attach(struct device_driver *drv)
+void driver_attach(struct device_driver *drv)
 {
return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);
 }
diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
index 444f8b6..4c16681 100644
--- a/drivers/char/agp/amd64-agp.c
+++ b/drivers/char/agp/amd64-agp.c
@@ -785,10 +785,12 @@ int __init agp_amd64_init(void)
 
/* Look for any AGP bridge */
agp_amd64_pci_driver.id_table = agp_amd64_pci_promisc_table;
-   err = driver_attach(_amd64_pci_driver.driver);
-   if (err == 0 && agp_bridges_found == 0) {
+   driver_attach(_amd64_pci_driver.driver);
+   if (agp_bridges_found == 0) {
pci_unregister_driver(_amd64_pci_driver);
err = -ENODEV;
+   } else {
+   err = 0;
}
}
return err;
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index bb0608c..d2a8de5 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1722,9 +1722,9 @@ static ssize_t store_new_id(struct device_driver *drv, 
const char *buf,
list_add_tail(>list, >dyn_list);
spin_unlock(>dyn_lock);
 
-   ret = driver_attach(>driver);
+   driver_attach(>driver);
 
-   return ret ? : count;
+   return count;
 }
 static DRIVER_ATTR(new_id, S_IWUSR, NULL, store_new_id);
 
diff --git a/drivers/input/gameport/gameport.c 
b/drivers/input/gameport/gameport.c
index da739d9..84f9878 100644
--- a/drivers/input/gameport/gameport.c
+++ b/drivers/input/gameport/gameport.c
@@ -670,12 +670,7 @@ static int gameport_driver_remove(struct device *dev)
 
 static void gameport_attach_driver(struct gameport_driver *drv)
 {
-   int error;
-
-   error = driver_attach(>driver);
-   if (error)
-   pr_err("driver_attach() failed for %s, error: %d\n",
-   drv->driver.name, error);
+   driver_attach(>driver);
 }
 
 int __gameport_register_driver(struct gameport_driver *drv, struct module 
*owner,
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index d0f7533..83f4eeb 100644
--- a/drivers/input/serio/serio.c
+++ b/drivers/input/serio/serio.c
@@ -802,12 +802,7 @@ static void serio_shutdown(struct device *dev)
 
 static void serio_attach_driver(struct serio_driver *drv)
 {
-   int error;
-
-   error = driver_attach(>driver);
-   if (error)
-   pr_warning("driver_attach() failed for 

Re: linux-next: manual merge of the char-misc tree with the tree

[Greg KH]

On Thu, Sep 27, 2012 at 03:31:19PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the char-misc tree got a conflict in
> drivers/char/pcmcia/synclink_cs.c between commit f21ec3d2d46e ("serial:
> add a new helper function") from the tty tree and commit 221b7b5796b5
> ("pcmcia: synclink_cs: fix potential tty NULL dereference") from the
> char-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good to me, thanks.

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

Re: [BUG] Deferred probing in driver model is racy, resulting in lost probes

[Russell King - ARM Linux]

On Thu, Sep 27, 2012 at 02:58:09PM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 27, 2012 at 07:47:46AM +0800, Ming Lei wrote:
> > On Thu, Sep 27, 2012 at 4:23 AM, Russell King - ARM Linux
> >  wrote:
> > > To be honest, I've not bothered to test the above patch, and now when I
> > > look at it, I notice it's broken - in that on error it will corrupt the
> > > driver list.  Take a look at the error path.
> > >
> > > priv is drv->p.  We add priv->knode_bus to the driver list.  If
> > > driver_attach() returns an error, then we go to out_unregister, which
> > 
> > In fact, driver_attach() always returns zero, so it does __not__ affect
> > your test.
> 
> It may not affect my test, but the fact is, that patch lays down the
> foundations for bugs to be introduced.  Now, while I can test it (and
> have done) I don't think it's suitable for mainline because of _that_.
> 
> If driver_attach() always returns zero, there's no point in it returning
> a value - it might as well return void and stop leading people to
> believe that it might return an error.  So I suggest this alternative
> patch instead, which gets rid of what is effectively dead code, and
> probably a few warnings about not checking the return value from a
> __must_check function (see usb-serial.c).
> 
> With this patch, no one is lead into a false sense of security that,
> after your patch, if driver_attach() ever returns an error, proper
> cleanup will happen - it's blatently obvious to anyone modifying it
> that if they do want it to return an error, they have to audit all the
> users of it, which IMHO is a good thing.

Sorry, old version of that patch.  Here's the right one.

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 2bcef65..39b3ef4 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -714,12 +714,10 @@ int bus_add_driver(struct device_driver *drv)
if (error)
goto out_unregister;
 
-   if (drv->bus->p->drivers_autoprobe) {
-   error = driver_attach(drv);
-   if (error)
-   goto out_unregister;
-   }
klist_add_tail(>knode_bus, >p->klist_drivers);
+   if (drv->bus->p->drivers_autoprobe)
+   driver_attach(drv);
+
module_add_driver(drv->owner, drv);
 
error = driver_create_file(drv, _attr_uevent);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4b01ab3..77e2412 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -456,9 +456,9 @@ static int __driver_attach(struct device *dev, void *data)
  * returns 0 and the @dev->driver is set, we've found a
  * compatible pair.
  */
-int driver_attach(struct device_driver *drv)
+void driver_attach(struct device_driver *drv)
 {
-   return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);
+   bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);
 }
 EXPORT_SYMBOL_GPL(driver_attach);
 
diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
index 444f8b6..4c16681 100644
--- a/drivers/char/agp/amd64-agp.c
+++ b/drivers/char/agp/amd64-agp.c
@@ -785,10 +785,12 @@ int __init agp_amd64_init(void)
 
/* Look for any AGP bridge */
agp_amd64_pci_driver.id_table = agp_amd64_pci_promisc_table;
-   err = driver_attach(_amd64_pci_driver.driver);
-   if (err == 0 && agp_bridges_found == 0) {
+   driver_attach(_amd64_pci_driver.driver);
+   if (agp_bridges_found == 0) {
pci_unregister_driver(_amd64_pci_driver);
err = -ENODEV;
+   } else {
+   err = 0;
}
}
return err;
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index bb0608c..d2a8de5 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1722,9 +1722,9 @@ static ssize_t store_new_id(struct device_driver *drv, 
const char *buf,
list_add_tail(>list, >dyn_list);
spin_unlock(>dyn_lock);
 
-   ret = driver_attach(>driver);
+   driver_attach(>driver);
 
-   return ret ? : count;
+   return count;
 }
 static DRIVER_ATTR(new_id, S_IWUSR, NULL, store_new_id);
 
diff --git a/drivers/input/gameport/gameport.c 
b/drivers/input/gameport/gameport.c
index da739d9..84f9878 100644
--- a/drivers/input/gameport/gameport.c
+++ b/drivers/input/gameport/gameport.c
@@ -670,12 +670,7 @@ static int gameport_driver_remove(struct device *dev)
 
 static void gameport_attach_driver(struct gameport_driver *drv)
 {
-   int error;
-
-   error = driver_attach(>driver);
-   if (error)
-   pr_err("driver_attach() failed for %s, error: %d\n",
-   drv->driver.name, error);
+   driver_attach(>driver);
 }
 
 int __gameport_register_driver(struct gameport_driver *drv, struct module 
*owner,
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index d0f7533..83f4eeb 100644
--- a/drivers/input/serio/serio.c
+++ 

Re: [PATCH] slab: Ignore internal flags in cache creation

[Christoph Lameter]

On Wed, 26 Sep 2012, David Rientjes wrote:

> I would suggest cachep->flags being used solely for the flags passed to
> kmem_cache_create() and seperating out all "internal flags" based on the
> individual slab allocator's implementation into a different field.  There
> should be no problem with moving CFLGS_OFF_SLAB elsewhere, in fact, I just
> removed a "dflags" field from mm/slab.c's kmem_cache that turned out never
> to be used.  You could simply reintroduce a new "internal_flags" field and
> use it at your discretion.

This means touching another field from critical paths of the allocators.
It would increase the cache footprint and therefore reduce performance.

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

[PATCH v2 2/2] usb: phy: omap-usb2: enable 960Mhz clock for omap5

[Kishon Vijay Abraham I]

"usb_otg_ss_refclk960m" is needed for usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/phy/omap-usb2.c |   18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..5512207 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -190,6 +190,12 @@ static int __devinit omap_usb2_probe(struct 
platform_device *pdev)
}
clk_prepare(phy->wkupclk);
 
+   phy->optclk = devm_clk_get(phy->dev, "usb_otg_ss_refclk960m");
+   if (IS_ERR(phy->optclk))
+   dev_vdbg(>dev, "unable to get refclk960m\n");
+   else
+   clk_prepare(phy->optclk);
+
usb_add_phy(>phy, USB_PHY_TYPE_USB2);
 
platform_set_drvdata(pdev, phy);
@@ -204,6 +210,7 @@ static int __devexit omap_usb2_remove(struct 
platform_device *pdev)
struct omap_usb *phy = platform_get_drvdata(pdev);
 
clk_unprepare(phy->wkupclk);
+   clk_unprepare(phy->optclk);
usb_remove_phy(>phy);
 
return 0;
@@ -217,6 +224,7 @@ static int omap_usb2_runtime_suspend(struct device *dev)
struct omap_usb *phy = platform_get_drvdata(pdev);
 
clk_disable(phy->wkupclk);
+   clk_disable(phy->optclk);
 
return 0;
 }
@@ -228,10 +236,16 @@ static int omap_usb2_runtime_resume(struct device *dev)
struct omap_usb *phy = platform_get_drvdata(pdev);
 
ret = clk_enable(phy->wkupclk);
-   if (ret < 0)
+   if (ret < 0) {
dev_err(phy->dev, "Failed to enable wkupclk %d\n", ret);
+   return ret;
+   }
 
-   return ret;
+   ret = clk_enable(phy->optclk);
+   if (ret < 0)
+   dev_vdbg(phy->dev, "Failed to enable optclk %d\n", ret);
+
+   return 0;
 }
 
 static const struct dev_pm_ops omap_usb2_pm_ops = {
-- 
1.7.9.5

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

[PATCH v2 1/2] usb: phy: add a new driver for usb3 phy

[Kishon Vijay Abraham I]

Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller.

This also includes device tree support for usb3 phy driver and
the documentation with device tree binding information is updated.

Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Felipe Balbi 
Signed-off-by: Moiz Sonasath 
---
 Documentation/devicetree/bindings/usb/usb-phy.txt |   18 +
 drivers/usb/phy/Kconfig   |9 +
 drivers/usb/phy/Makefile  |1 +
 drivers/usb/phy/omap-usb3.c   |  412 +
 include/linux/usb/omap_usb.h  |   33 ++
 5 files changed, 473 insertions(+)
 create mode 100644 drivers/usb/phy/omap-usb3.c

diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 80d4148..7c5fd89 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -15,3 +15,21 @@ usb2phy@4a0ad080 {
reg = <0x4a0ad080 0x58>,
  <0x4a002300 0x4>;
 };
+
+OMAP USB3 PHY
+
+Required properties:
+ - compatible: Should be "ti,omap-usb3"
+ - reg : Address and length of the register set for the device. Also
+add the address of control module phy power register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb3phy@4a084400 {
+   compatible = "ti,omap-usb3";
+   reg = <0x0x4a084400 0x80>,
+ <0x4a084800 0x64>,
+ <0x4a084c00 0x40>,
+ <0x4a002370 0x4>;
+};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 63c339b..353dc0c 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -13,6 +13,15 @@ config OMAP_USB2
  The USB OTG controller communicates with the comparator using this
  driver.
 
+config OMAP_USB3
+   tristate "OMAP USB3 PHY Driver"
+   select USB_OTG_UTILS
+   help
+ Enable this to support the USB3 PHY that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
 config USB_ISP1301
tristate "NXP ISP1301 USB transceiver support"
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b069f29..973b1e6 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,6 +5,7 @@
 ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
+obj-$(CONFIG_OMAP_USB3)+= omap-usb3.o
 obj-$(CONFIG_USB_ISP1301)  += isp1301.o
 obj-$(CONFIG_MV_U3D_PHY)   += mv_u3d_phy.o
 obj-$(CONFIG_USB_EHCI_TEGRA)   += tegra_usb_phy.o
diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
new file mode 100644
index 000..cecfbd4
--- /dev/null
+++ b/drivers/usb/phy/omap-usb3.c
@@ -0,0 +1,412 @@
+/*
+ * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineNUM_SYS_CLKS5
+#definePLL_STATUS  0x0004
+#definePLL_GO  0x0008
+#definePLL_CONFIGURATION1  0x000C
+#definePLL_CONFIGURATION2  0x0010
+#definePLL_CONFIGURATION3  0x0014
+#definePLL_CONFIGURATION4  0x0020
+
+#definePLL_REGM_MASK   0x001FFE00
+#definePLL_REGM_SHIFT  0x9
+#definePLL_REGM_F_MASK 0x0003
+#definePLL_REGM_F_SHIFT0x0
+#definePLL_REGN_MASK   0x01FE
+#definePLL_REGN_SHIFT  0x1
+#definePLL_SELFREQDCO_MASK 0x000E
+#definePLL_SELFREQDCO_SHIFT0x1
+#definePLL_SD_MASK 0x0003FC00
+#definePLL_SD_SHIFT0x9
+#defineSET_PLL_GO  0x1
+#definePLL_TICOPWDN0x1
+#definePLL_LOCK0x2
+#definePLL_IDLE0x1

[PATCH v2 0/2] usb: phy: add usb3 phy driver

[Kishon Vijay Abraham I]

Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller. Currently writing to control module register
is taken care in this driver which will be removed once the control
module driver is in place.

Changes from v1:
* Added missing clk_put()
* Remove the patches usb: dwc3: Fix gadget pullup in SS mode and
usb: phy: omap-usb3: Decrease the number of transitions to recovery. Those
are actually WA for hw issues which will be fixed in ES2.
* Removed the *has960mhzclk* property

This patch series was rebased on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
However the dependent modules are not yet upstreamed and hence only compile
tested in this tree

Kishon Vijay Abraham I (2):
  usb: phy: add a new driver for usb3 phy
  usb: phy: omap-usb2: enable 960Mhz clock for omap5

 Documentation/devicetree/bindings/usb/usb-phy.txt |   18 +
 drivers/usb/phy/Kconfig   |9 +
 drivers/usb/phy/Makefile  |1 +
 drivers/usb/phy/omap-usb2.c   |   18 +-
 drivers/usb/phy/omap-usb3.c   |  412 +
 include/linux/usb/omap_usb.h  |   33 ++
 6 files changed, 489 insertions(+), 2 deletions(-)
 create mode 100644 drivers/usb/phy/omap-usb3.c

-- 
1.7.9.5

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

Re: [RFC] tty: Add get- ioctls to fetch tty status

[Cyrill Gorcunov]

On Mon, Sep 24, 2012 at 06:14:41PM +0400, Cyrill Gorcunov wrote:
> 
> As to Alan's point on "what's the use of this if it can instantly change
> after you read the value" I guess it's the same as what we have when we
> simply set the value. Imagine we have two tasks fork'ed, first task do
> lock the pty while another task does unlock it immediately after that,
> as far as I see there is nothing preventing user space to do that, thus
> first task will think it has locked the peer while in real the peer remains
> unlocked. Same here with reading this value -- it's valid once read but
> can be changed right after. Isn't it?

Alan, Greg, what's opinion? This flags fetching is the same as say fetching
of termios settings, once fetched they can be changed immediately, and it's
up to caller what to do with termios settings. No?
---
From: Cyrill Gorcunov 
Subject: tty: Add get- ioctls to fetch tty status

For checkpoint/restore we need to know if tty has
exclusive or packet mode set, as well as if pty
is currently locked. Just to be able to restore
this characteristics.

For this sake the following ioctl codes are introduced

 - TIOCGPKT to get packet mode state
 - TIOCGPTLCK to get Pty locked state
 - TIOCGEXCL to get Exclusive mode state

Signed-off-by: Cyrill Gorcunov 
---
 drivers/tty/pty.c|   12 
 drivers/tty/tty_io.c |7 +++
 drivers/tty/tty_ioctl.c  |   16 
 fs/compat_ioctl.c|3 +++
 include/asm-generic/ioctls.h |3 +++
 5 files changed, 41 insertions(+)

Index: tty.git/drivers/tty/pty.c
===
--- tty.git.orig/drivers/tty/pty.c
+++ tty.git/drivers/tty/pty.c
@@ -174,6 +174,14 @@ static int pty_set_lock(struct tty_struc
return 0;
 }
 
+static int pty_get_lock(struct tty_struct *tty, int __user *arg)
+{
+   int locked = test_bit(TTY_PTY_LOCK, >flags);
+   if (put_user(locked, arg))
+   return -EFAULT;
+   return 0;
+}
+
 /* Send a signal to the slave */
 static int pty_signal(struct tty_struct *tty, int sig)
 {
@@ -393,6 +401,8 @@ static int pty_bsd_ioctl(struct tty_stru
switch (cmd) {
case TIOCSPTLCK: /* Set PT Lock (disallow slave open) */
return pty_set_lock(tty, (int __user *) arg);
+   case TIOCGPTLCK:
+   return pty_get_lock(tty, (int __user *) arg);
case TIOCSIG:/* Send signal to other side of pty */
return pty_signal(tty, (int) arg);
}
@@ -507,6 +517,8 @@ static int pty_unix98_ioctl(struct tty_s
switch (cmd) {
case TIOCSPTLCK: /* Set PT Lock (disallow slave open) */
return pty_set_lock(tty, (int __user *)arg);
+   case TIOCGPTLCK:
+   return pty_get_lock(tty, (int __user *) arg);
case TIOCGPTN: /* Get PT Number */
return put_user(tty->index, (unsigned int __user *)arg);
case TIOCSIG:/* Send signal to other side of pty */
Index: tty.git/drivers/tty/tty_io.c
===
--- tty.git.orig/drivers/tty/tty_io.c
+++ tty.git/drivers/tty/tty_io.c
@@ -2693,6 +2693,13 @@ long tty_ioctl(struct file *file, unsign
case TIOCNXCL:
clear_bit(TTY_EXCLUSIVE, >flags);
return 0;
+   case TIOCGEXCL:
+   {
+   int excl = test_bit(TTY_EXCLUSIVE, >flags);
+   if (put_user(excl, (int __user *)p))
+   return -EFAULT;
+   return 0;
+   }
case TIOCNOTTY:
if (current->signal->tty != tty)
return -ENOTTY;
Index: tty.git/drivers/tty/tty_ioctl.c
===
--- tty.git.orig/drivers/tty/tty_ioctl.c
+++ tty.git/drivers/tty/tty_ioctl.c
@@ -1173,6 +1173,22 @@ int n_tty_ioctl_helper(struct tty_struct
spin_unlock_irqrestore(>ctrl_lock, flags);
return 0;
}
+   case TIOCGPKT:
+   {
+   int pktmode;
+
+   if (tty->driver->type != TTY_DRIVER_TYPE_PTY ||
+   tty->driver->subtype != PTY_TYPE_MASTER)
+   return -ENOTTY;
+
+   spin_lock_irqsave(>ctrl_lock, flags);
+   pktmode = tty->packet;
+   spin_unlock_irqrestore(>ctrl_lock, flags);
+
+   if (put_user(pktmode, (int __user *) arg))
+   return -EFAULT;
+   return 0;
+   }
default:
/* Try the mode commands */
return tty_mode_ioctl(tty, file, cmd, arg);
Index: tty.git/fs/compat_ioctl.c
===
--- tty.git.orig/fs/compat_ioctl.c
+++ tty.git/fs/compat_ioctl.c
@@ -842,6 +842,9 @@ COMPATIBLE_IOCTL(TIOCGDEV)
 COMPATIBLE_IOCTL(TIOCCBRK)
 COMPATIBLE_IOCTL(TIOCGSID)
 COMPATIBLE_IOCTL(TIOCGICOUNT)
+COMPATIBLE_IOCTL(TIOCGPKT)

Re: [PATCH] slab: Ignore internal flags in cache creation

[Christoph Lameter]

On Wed, 26 Sep 2012, David Rientjes wrote:

> On Wed, 26 Sep 2012, Christoph Lameter wrote:
>
> > > Nack, this is already handled by CREATE_MASK in the mm/slab.c allocator;
> >
> > CREATE_MASK defines legal flags that can be specified. Other flags cause
> > and error. This is about flags that are internal that should be ignored
> > when specified.
> >
>
> That should be ignored for the mm/slab.c allocator, yes.

Then you are ok with the patch as is?


> > I think it makes sense to reserve some top flags for internal purposes.
> >
>
> It depends on the implementation: if another slab allocator were to use
> additional bits that would be a no-op with mm/slab.c, then this patch
> would be too restrictive.  There's also no requirement that any "internal
> flags" reserved by a slab allocator implementation must be shared in the
> same kmem_cache field as the flags passed to kmem_cache_create() -- it's
> actually better if they aren't since they seldom need to be accessed in
> the same cacheline.

There *are* multiple slab allocators using those bits! And this works for
them. There is nothing too restrictive here. The internal flags are
standardized by this patch to be in the highest nibble.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] sta2x11-mfd : add apb-soc regs driver and factor out common code

[Alan Cox]

> as far as I know, nested locks are fine provided that you always take them in
> the same order and release them in the opposite order (lock A, lock B,
> unlock B, unlock A). So my conclusion is that nested spinlocks require
> potential regmap users of sta2x11 registers to take the sta2x11-mfd spinlock
> first. The pattern would be (sctl registers for instance):

The release order does not matter. Taking AB and releasing AB or BA is
fine. Taking AB and dropping B and retaking B is fine. Taking AB and
somewhere else taking BA is not. There are performance reasons in some
cases why taking AB releasing A is best with locks, but thats generally
with sleepable locks.

It's a bit more subtle because you often have other interactions. In
particular people often come unstuck on del_timer_sync or waiting for
workqueues and IRQs to finish (even in free_irq) while holding a lock
that the handler needs to take.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: da9052-core: Fix request_threaded_irq() parameter

[Mark Brown]

On Thu, Sep 27, 2012 at 12:55:35AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> On a mx53qsb dt-kernel the da9052-core driver fails to probe:
> 
> da9052 1-0048: DA9052 ADC IRQ failed ret=-22
> 
> In request_threaded_irq() the first parameter is missing the da9052->irq_base.
> 
> Fix it and avoid the error.

The driver shouldn't be relying on irq_base at all, it should use
regmap_get_virq() to look up the interrupt number.  If it relies on
irq_base then the user is forced to assign one (or rely on automatic
assignment, which is a bit erratic.  Otherwise it can use a linear
domain which doesn't rely on being able to allocate a big block of
interrupt numbers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: Add get- ioctls to fetch tty status

[Alan Cox]

> Alan, Greg, what's opinion? This flags fetching is the same as say fetching
> of termios settings, once fetched they can be changed immediately, and it's
> up to caller what to do with termios settings. No?

I think you need to explain what you expect to be doing with it, and why
it is safe in that application.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma-debug: New interfaces to debug dma mapping errors

[Shuah Khan]

Hi Joerg,

On Thu, 2012-09-27 at 12:20 +0200, Joerg Roedel wrote:
> Hi Shuah,
> 
> the patch looks better then the older versions. It comes closer to a
> merge, but I see one issue here:
> 
> On Tue, Sep 25, 2012 at 07:05:17PM -0600, Shuah Khan wrote:
> > debug_dma_mapping_error(struct device *dev, dma_addr_t dma_addr):
> > Sets dma map error checked status for the dma map entry if one is
> > found. Decrements the system wide dma_map_errors_not_checked counter
> > that is incremented by debug_dma_map_page() when it checks for
> > mapping error before adding it to the dma debug entry table.
> 
> It is problematic that the DMA debug code can no longer call
> dma_mapping_error because of this. How about adding a special version of
> that function which does no checking and use it in the DMA debug code
> instead?

Yes. Konrad expressed the same concern and I understand the reasons.
Defining a special version of dma_mapping_error() will eliminate the
problem that prevents this routine being used from dma-debug api. Will
do that. Working on a v3 patch to fix this problem as well as the other
review comments from Konrad. Hoping I can have it ready in by the end of
this week(end)

Thanks,
-- Shuah

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: Add get- ioctls to fetch tty status

[Cyrill Gorcunov]

On Thu, Sep 27, 2012 at 03:14:47PM +0100, Alan Cox wrote:
> > Alan, Greg, what's opinion? This flags fetching is the same as say fetching
> > of termios settings, once fetched they can be changed immediately, and it's
> > up to caller what to do with termios settings. No?
> 
> I think you need to explain what you expect to be doing with it, and why
> it is safe in that application.

OK, it seems it was unclear from changelog. We need to know this parameters
to be able to restore tty connection after checkpoint.

While we easily can fetch termios settings and such, there are few bits which
are missed to expord. So this patch provides them to user-space.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG] Deferred probing in driver model is racy, resulting in lost probes

[Ming Lei]

On Thu, Sep 27, 2012 at 10:03 PM, Russell King - ARM Linux
 wrote:
> On Thu, Sep 27, 2012 at 02:58:09PM +0100, Russell King - ARM Linux wrote:
>> On Thu, Sep 27, 2012 at 07:47:46AM +0800, Ming Lei wrote:
>> > On Thu, Sep 27, 2012 at 4:23 AM, Russell King - ARM Linux
>> >  wrote:
>> > > To be honest, I've not bothered to test the above patch, and now when I
>> > > look at it, I notice it's broken - in that on error it will corrupt the
>> > > driver list.  Take a look at the error path.
>> > >
>> > > priv is drv->p.  We add priv->knode_bus to the driver list.  If
>> > > driver_attach() returns an error, then we go to out_unregister, which
>> >
>> > In fact, driver_attach() always returns zero, so it does __not__ affect
>> > your test.
>>
>> It may not affect my test, but the fact is, that patch lays down the
>> foundations for bugs to be introduced.  Now, while I can test it (and
>> have done) I don't think it's suitable for mainline because of _that_.
>>
>> If driver_attach() always returns zero, there's no point in it returning
>> a value - it might as well return void and stop leading people to
>> believe that it might return an error.  So I suggest this alternative
>> patch instead, which gets rid of what is effectively dead code, and
>> probably a few warnings about not checking the return value from a
>> __must_check function (see usb-serial.c).
>>
>> With this patch, no one is lead into a false sense of security that,
>> after your patch, if driver_attach() ever returns an error, proper
>> cleanup will happen - it's blatently obvious to anyone modifying it
>> that if they do want it to return an error, they have to audit all the
>> users of it, which IMHO is a good thing.
>
> Sorry, old version of that patch.  Here's the right one.

IMO, it is better to take the one line change first since it is really
correct and easy to be backported to previous stable releases.


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

Re: [RFC] tty: Add get- ioctls to fetch tty status

[H. Peter Anvin]

On 09/27/2012 07:14 AM, Cyrill Gorcunov wrote:

On Thu, Sep 27, 2012 at 03:14:47PM +0100, Alan Cox wrote:

Alan, Greg, what's opinion? This flags fetching is the same as say fetching
of termios settings, once fetched they can be changed immediately, and it's
up to caller what to do with termios settings. No?


I think you need to explain what you expect to be doing with it, and why
it is safe in that application.


OK, it seems it was unclear from changelog. We need to know this parameters
to be able to restore tty connection after checkpoint.

While we easily can fetch termios settings and such, there are few bits which
are missed to expord. So this patch provides them to user-space.



What bothers me (and the same applies to termios) is that you have NO 
idea if your particular process is the "owner" of that tty.  tty users 
use out-of-band protocols, often implicit, to determine which process 
"owns" the tty state.


If you can't guarantee that ALL those processes are stopped and 
checkpointed/restarted, you have a huge problem.


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: Add get- ioctls to fetch tty status

[Cyrill Gorcunov]

On Thu, Sep 27, 2012 at 07:17:49AM -0700, H. Peter Anvin wrote:
> >While we easily can fetch termios settings and such, there are few bits which
> >are missed to expord. So this patch provides them to user-space.
> >
> 
> What bothers me (and the same applies to termios) is that you have
> NO idea if your particular process is the "owner" of that tty.  tty
> users use out-of-band protocols, often implicit, to determine which
> process "owns" the tty state.
> 
> If you can't guarantee that ALL those processes are stopped and
> checkpointed/restarted, you have a huge problem.

Well, sure inside our tool before doing checkpoint we stop all
tasks which are part of dumpee process tree. This unfortunatly
doesn't apply to these ioctl calls. Peter, any idea how to deal
with that?

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

Re: [PATCHv2 2/4] dmaengine: dw_dmac: Add PCI part of the driver

[Arnd Bergmann]

On Thursday 27 September 2012, viresh kumar wrote:
> I believe there is no common initialization part here, because PCI device in 
> any
> case would be calling probe of platform device. :)

Looking at the driver more closely now. Right now, it only supports platform 
devices, and the dw_probe function contains some parts that are related to
platform devices and some parts that are needed also in case of PCI.

My suggestion would be that you split the dw_probe function to separate out
the bus specific parts and end up with three functions like

int dw_dmac_probe(struct dw_dma *dw);
int dw_dmac_platform_probe(struct platform_device *pdev);
int dw_dmac_pci_probe(struct dw_dma *dw);

where the first one is called by the other two, depending on the bus type.
This could be done either splitting the driver into multiple files so you can
have the platform and pci parts in separate driver modules depending on the
common module that does all the actual work, or everything can be put in
a single file with an #ifdef CONFIG_PCI to disable the pci driver parts
when they don't apply.

Does this make sense?

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

Re: [PATCH v2 1/2] usb: phy: add a new driver for usb3 phy

[Russell King - ARM Linux]

On Thu, Sep 27, 2012 at 07:34:07PM +0530, Kishon Vijay Abraham I wrote:
> +static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
> +{
> + u32 val;
> + unsigned long rate;
> + struct clk *sys_clk;
> +
> + sys_clk = clk_get(NULL, "sys_clkin");
> + if (IS_ERR(sys_clk)) {
> + pr_err("%s: unable to get sys_clkin\n", __func__);
> + return -EINVAL;
> + }
> +
> + rate = clk_get_rate(sys_clk);
> + rate = rate/100;
> + clk_put(sys_clk);

Actually, you're supposed to hold on to the struct clk all the time your
driver is making use of that - you're not supposed to drop it.

That has several advantages: if clk_get() fails, then you're failing
earlier on (when the driver is being probed) and when some event occurs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] drivers: usb: phy: add a new driver for omap usb2 phy

[Rob Herring]

On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote:
> Hi,
> 
> On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring  wrote:
>> On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote:
>>> All phy related programming like enabling/disabling the clocks, powering
>>> on/off the phy is taken care of by this driver. It is also used for OTG
>>> related functionality like srp.
>>>
>>> This also includes device tree support for usb2 phy driver and
>>> the documentation with device tree binding information is updated.
>>>
>>> Currently writing to control module register is taken care in this
>>> driver which will be removed once the control module driver is in place.
>>>
>>> Cc: Felipe Balbi 
>>> Signed-off-by: Kishon Vijay Abraham I 
>>> ---
>>>  Documentation/devicetree/bindings/usb/usb-phy.txt |   17 ++
>>>  drivers/usb/phy/Kconfig   |9 +
>>>  drivers/usb/phy/Makefile  |1 +
>>>  drivers/usb/phy/omap-usb2.c   |  271 
>>> +
>>>  include/linux/usb/omap_usb.h  |   46 
>>>  include/linux/usb/phy_companion.h |   34 +++
>>>  6 files changed, 378 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt
>>>  create mode 100644 drivers/usb/phy/omap-usb2.c
>>>  create mode 100644 include/linux/usb/omap_usb.h
>>>  create mode 100644 include/linux/usb/phy_companion.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
>>> b/Documentation/devicetree/bindings/usb/usb-phy.txt
>>> new file mode 100644
>>> index 000..80d4148
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
>>
>> This is a very generic name...
>>
>>> @@ -0,0 +1,17 @@
>>> +USB PHY
>>> +
>>> +OMAP USB2 PHY
>>> +
>>> +Required properties:
>>> + - compatible: Should be "ti,omap-usb2"
>>
>> ...for a specific phy. However, I do think a generic binding to describe
>> host ctrlr to phy connections is needed.
>>
>>> + - reg : Address and length of the register set for the device. Also
>>> +add the address of control module dev conf register until a driver for
>>> +control module is added
>>
>> The dts should describe the h/w, not what you need for the current
>> driver. The 2nd reg field does not belong here.
> 
> Indeed. This was discussed and agreed upon as a interim solution till
> we have a control module driver in place to write to the control
> module register.

Discussed where and agreed by who? I for one do not agree.

Rob

>>
>>> +
>>> +This is usually a subnode of ocp2scp to which it is connected.
>>
>> How is usb port to phy connection described?
> Currently the usb controller to phy connection is established only by
> type. We have a couple of patches being currently discussed in the
> list to establish the connection by phandle.
> 
> https://patchwork.kernel.org/patch/1457801/ (Generic PHY Framework:
> devm_of_phy_get())
> http://www.spinics.net/lists/linux-usb/msg69547.html
> 
> Thanks
> Kishon
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/13] kmem accounting basic infrastructure

[Mel Gorman]

On Wed, Sep 26, 2012 at 04:08:07PM -0700, Tejun Heo wrote:
> Hello, Glauber.
> 
> On Thu, Sep 27, 2012 at 02:54:11AM +0400, Glauber Costa wrote:
> > I don't. Much has been said in the past about the problem of sharing. A
> > lot of the kernel objects are shared by nature, this is pretty much
> > unavoidable. The answer we have been giving to this inquiry, is that the
> > workloads (us) interested in kmem accounted tend to be quite local in
> > their file accesses (and other kernel objects as well).
> > 
> > It should be obvious that not all workloads are like this, and some of
> > them would actually prefer to have their umem limited only.
> > 
> > There is nothing unreasonable in tracking user memory only.
> > 
> > If we have a global switch for "tracking all kernel memory", who would
> > you account the objects that are heavily shared to? I solve this by not
> > tracking kernel memory for cgroups in such workloads. What do you propose?
> 
> One of the things wrong with that is that it exposes the limitation of
> the current implementation as interface to userland, which is never a
> good idea.

I think the limitations have been fairly clearly explained and any admin
using the interface is going to have *some* familiarity with the limitations.

> In addition, how is userland supposed to know which
> workload is shared kmem heavy or not? 

By using a bit of common sense.

An application may not be able to figure this out but the administrator
is going to be able to make a very educated guess. If processes running
within two containers are not sharing a filesystem hierarchy for example
then it'll be clear they are not sharing dentries.

If there was a suspicion they were then it could be analysed with
something like SystemTap probing when files are opened and see if files
are being opened that are shared between containers.

It's not super-easy but it's not impossible either and I fail to see why
it's such a big deal for you.

>Details like that are not even
> inherent to workloads.  It's highly dependent on kernel implementation
> which may change any day.  If we hit workloads like that the right
> thing to do is improving kmemcg so that such problems don't occur, not
> exposing another switch.
> 
> If we can't make that work in reasonable (doesn't have to be perfect)
> way, we might as well just give up on kmem controller.  If userland
> has to second-guess kernel implementation details to make use of it,
> it's useless.
> 
> > > Well, that's really playing with words.  Limit is per cgroup and
> > > before the limit is set for the first time, everything is accounted to
> > > something else.  How is that keeping track?
> > > 
> > 
> > Even after the limit is set, it is set only by workloads that want kmem
> > to be tracked. If you want to track it during the whole lifetime of the
> > cgroup, you switch it before you put tasks to it. What is so crazy about it?
> 
> The fact that the numbers don't really mean what they apparently
> should mean.
> 

I think it is a reasonable limitation that only some kernel allocations are
accounted for although I'll freely admit I'm not a cgroup or memcg user
either.

My understanding is that this comes down to cost -- accounting for the
kernel memory usage is expensive so it is limited only to the allocations
that are easy to abuse by an unprivileged process. Hence this is
initially concerned with stack pages with dentries and TCP usage to
follow in later patches.

Further I would expect that an administrator would be aware of these
limitations and set kmem_accounting at cgroup creation time before any
processes start. Maybe that should be enforced but it's not a
fundamental problem.

Due to the cost of accounting, I can see why it would be desirable to
enable kmem_accounting for some cgroup trees and not others. It is not
unreasonable to expect that an administrator might want to account within
one cgroup where processes are accessing millions of files without
impairing the performance of another cgroup that is mostly using
anonymous memory.

> > > The proposed behavior seems really crazy to me.  Do people really
> > > think this is a good idea?
> > 
> > It is really sad that you lost the opportunity to say that in a room
> > full of mm developers that could add to this discussion in real time,
> > when after an explanation about this was given, Mel asked if anyone
> > would have any objections to this.
> 
> Sure, conferences are useful for building consensus but that's the
> extent of it.  Sorry that I didn't realize the implications then but
> conferences don't really add any finality to decisions.
> 
> So, this seems properly crazy to me at the similar level of
> use_hierarchy fiasco.  I'm gonna NACK on this.
> 

I think you're over-reacting to say the very least :|

-- 
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  

Re: [PATCHv2 2/4] dmaengine: dw_dmac: Add PCI part of the driver

[Vinod Koul]

On Thu, 2012-09-27 at 07:41 +, Arnd Bergmann wrote:
> On Thursday 27 September 2012, viresh kumar wrote:
> > I believe there is no common initialization part here, because PCI device 
> > in any
> > case would be calling probe of platform device. :)
> 
> Looking at the driver more closely now. Right now, it only supports platform 
> devices, and the dw_probe function contains some parts that are related to
> platform devices and some parts that are needed also in case of PCI.
> 
> My suggestion would be that you split the dw_probe function to separate out
> the bus specific parts and end up with three functions like
> 
> int dw_dmac_probe(struct dw_dma *dw);
> int dw_dmac_platform_probe(struct platform_device *pdev);
> int dw_dmac_pci_probe(struct dw_dma *dw);
yes and bus probe shoudl aquire resources, other stuff should be done in
dmac_probe.
> 
> where the first one is called by the other two, depending on the bus type.
> This could be done either splitting the driver into multiple files so you can
> have the platform and pci parts in separate driver modules depending on the
> common module that does all the actual work, or everything can be put in
> a single file with an #ifdef CONFIG_PCI to disable the pci driver parts
> when they don't apply.
probe wont be called if PCI device is not loaded, so see no reason why
CONFIG_xxx would be needed
> 
> Does this make sense?
Yup!
> 
>   Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
~Vinod

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scatterlist: refactor the sg_nents

[Maxim Levitsky]

Replace 'while' with 'for' as suggested by Tejun Heo

Signed-off-by: Maxim Levitsky 
---
 lib/scatterlist.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 5cd9cdc..3675452b 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -49,12 +49,9 @@ EXPORT_SYMBOL(sg_next);
  **/
 int sg_nents(struct scatterlist *sg)
 {
-   int nents = 0;
-   while (sg) {
+   int nents;
+   for (nents = 0; sg; sg = sg_next(sg))
nents++;
-   sg = sg_next(sg);
-   }
-
return nents;
 }
 EXPORT_SYMBOL(sg_nents);
-- 
1.7.9.5

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

Re: [PATCH 1/3] memory_hotplug: fix stale node_states[N_NORMAL_MEMORY]

[Ni zhan Chen]

On 09/27/2012 02:47 PM, Lai Jiangshan wrote:

Currently memory_hotplug only manages the node_states[N_HIGH_MEMORY],
it forgets to manage node_states[N_NORMAL_MEMORY]. it causes
node_states[N_NORMAL_MEMORY] becomes stale.

We add check_nodemasks_changes_online() and check_nodemasks_changes_offline()
to detect whether node_states[N_HIGH_MEMORY] and node_states[N_NORMAL_MEMORY]
are changed while hotpluging.

Also add @status_change_nid_normal to struct memory_notify, thus
the memory hotplug callbacks know whether the node_states[N_NORMAL_MEMORY]
are changed.


I still don't understand why need care N_NORMAL_MEMORY here, could you 
explain

in details?



Signed-off-by: Lai Jiangshan 
---
  Documentation/memory-hotplug.txt |5 ++-
  include/linux/memory.h   |1 +
  mm/memory_hotplug.c  |   94 +++--
  3 files changed, 83 insertions(+), 17 deletions(-)

diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 6d0c251..6e6cbc7 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -377,15 +377,18 @@ The third argument is passed by pointer of struct 
memory_notify.
  struct memory_notify {
 unsigned long start_pfn;
 unsigned long nr_pages;
+   int status_change_nid_normal;
 int status_change_nid;
  }
  
  start_pfn is start_pfn of online/offline memory.

  nr_pages is # of pages of online/offline memory.
+status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask
+is (will be) set/clear, if this is -1, then nodemask status is not changed.
  status_change_nid is set node id when N_HIGH_MEMORY of nodemask is (will be)
  set/clear. It means a new(memoryless) node gets new memory by online and a
  node loses all memory. If this is -1, then nodemask status is not changed.
-If status_changed_nid >= 0, callback should create/discard structures for the
+If status_changed_nid* >= 0, callback should create/discard structures for the
  node if necessary.
  
  --

diff --git a/include/linux/memory.h b/include/linux/memory.h
index ff9a9f8..a09216d 100644
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -53,6 +53,7 @@ int arch_get_memory_phys_device(unsigned long start_pfn);
  struct memory_notify {
unsigned long start_pfn;
unsigned long nr_pages;
+   int status_change_nid_normal;
int status_change_nid;
  };
  
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c

index 6a5b90d..b62d429b 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -460,6 +460,34 @@ static int online_pages_range(unsigned long start_pfn, 
unsigned long nr_pages,
return 0;
  }
  
+static void check_nodemasks_changes_online(unsigned long nr_pages,

+   struct zone *zone, struct memory_notify *arg)
+{
+   int nid = zone_to_nid(zone);
+   enum zone_type zone_last = ZONE_NORMAL;
+
+   if (N_HIGH_MEMORY == N_NORMAL_MEMORY)
+   zone_last = ZONE_MOVABLE;
+
+   if (zone_idx(zone) <= zone_last && !node_state(nid, N_NORMAL_MEMORY))
+   arg->status_change_nid_normal = nid;
+   else
+   arg->status_change_nid_normal = -1;
+
+   if (!node_state(nid, N_HIGH_MEMORY))
+   arg->status_change_nid = nid;
+   else
+   arg->status_change_nid = -1;
+}
+
+static void set_nodemasks(int node, struct memory_notify *arg)
+{
+   if (arg->status_change_nid_normal >= 0)
+   node_set_state(node, N_NORMAL_MEMORY);
+
+   node_set_state(node, N_HIGH_MEMORY);
+}
+
  
  int __ref online_pages(unsigned long pfn, unsigned long nr_pages)

  {
@@ -471,13 +499,18 @@ int __ref online_pages(unsigned long pfn, unsigned long 
nr_pages)
struct memory_notify arg;
  
  	lock_memory_hotplug();

+   /*
+* This doesn't need a lock to do pfn_to_page().
+* The section can't be removed here because of the
+* memory_block->state_mutex.
+*/
+   zone = page_zone(pfn_to_page(pfn));
+
arg.start_pfn = pfn;
arg.nr_pages = nr_pages;
-   arg.status_change_nid = -1;
+   check_nodemasks_changes_online(nr_pages, zone, );
  
  	nid = page_to_nid(pfn_to_page(pfn));

-   if (node_present_pages(nid) == 0)
-   arg.status_change_nid = nid;
  
  	ret = memory_notify(MEM_GOING_ONLINE, );

ret = notifier_to_errno(ret);
@@ -487,12 +520,6 @@ int __ref online_pages(unsigned long pfn, unsigned long 
nr_pages)
return ret;
}
/*
-* This doesn't need a lock to do pfn_to_page().
-* The section can't be removed here because of the
-* memory_block->state_mutex.
-*/
-   zone = page_zone(pfn_to_page(pfn));
-   /*
 * If this zone is not populated, then it is not in zonelist.
 * This means the page allocator ignores this zone.
 * So, zonelist must be updated after online.
@@ -517,7 +544,7 @@ int __ref 

Re: [PATCH v3 04/13] kmem accounting basic infrastructure

[Tejun Heo]

Hello, Michal.

On Thu, Sep 27, 2012 at 02:08:06PM +0200, Michal Hocko wrote:
> Yes, because we have many users (basically almost all) who care only
> about the user memory because that's what occupies the vast majority of
> the memory. They usually want to isolate workload which would disrupt
> the global memory otherwise (e.g. backup process vs. database). You
> really do not want to pay an additional overhead for kmem accounting
> here.

I'm not too convinced.  First of all, the overhead added by kmemcg
isn't big.  The hot path overhead is quite minimal - it doesn't do
much more than indirecting one more time.  In terms of memory usage,
it sure could lead to a bit more fragmentation but even if it gets to
several megs per cgroup, I don't think that's something excessive.
So, there is overhead but I don't believe it to be prohibitive.

> > So your question for global vs local switch (that again, doesn't
> > exist; only a local *limit* exists) should really be posed in the
> > following way:  "Can two different use cases with different needs be
> > hosted in the same box?"
> 
> I think this is a good and a relevant question. I think this boils down
> to whether you want to have trusted and untrusted workloads at the same
> machine.
> Trusted loads usually only need user memory accounting because kmem
> consumption should be really negligible (unless kernel is doing
> something really stupid and no kmem limit will help here). 
> On the other hand, untrusted workloads can do nasty things that
> administrator has hard time to mitigate and setting a kmem limit can
> help significantly.
> 
> IMHO such a different loads exist on a single machine quite often (Web
> server and a back up process as the most simplistic one). The per
> hierarchy accounting, therefore, sounds like a good idea without too
> much added complexity (actually the only added complexity is in the
> proper kmem.limit_in_bytes handling which is a single place).

The distinction between "trusted" and "untrusted" is something
artificially created due to the assumed deficiency of kmemcg
implementation.  Making things like this visible to userland is a bad
idea because it locks us into a place where we can't or don't need to
improve the said deficiencies and end up pushing the difficult
problems to somewhere else where it will likely be implemented in a
shabbier way.  There sure are cases when such approach simply cannot
be avoided, but I really don't think that's the case here - the
overhead already seems to be at an acceptable level and we're not
taking away the escape switch.

This is userland visible API.  We better err on the side of being
conservative than going overboard with flexibility.  Even if we
eventually need to make this switching fullly hierarchical, we really
should be doing,

1. Implement simple global switching and look for problem cases.

2. Analyze them and see whether the problem case can't be solved in a
   better, more intelligent way.

3. If the problem is something structurally inherent or reasonably too
   difficult to solve any other way, consider dumping the problem as
   config parameters to userland.

We can always expand the flexibility.  Let's do the simple thing
first.  As an added bonus, it would enable using static_keys for
accounting branches too.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data

[Vinod Koul]

On Thu, 2012-09-27 at 17:00 +0300, Andy Shevchenko wrote:
> On Thu, Sep 27, 2012 at 1:06 PM, Vinod Koul  
> wrote:
> > On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote:
> >> Not all of the controllers support the 64 bit data width. Make it 
> >> configurable
> >> via platform data. The driver will try to get a value from the component
> >> parameters, otherwise it will use the platform data.
> >>
> > What was this gen against, I can apply this.
> Just rebased to recent linux-next, no conflicts.
And I dont apply patches against linux-next!! I apply against
slave-dma-next.
> ...
> Applying: dw_dmac: mark dwc_dump_chan_regs as inline
> Applying: dw_dmac: fill optional encoded parameters in register structure
> Applying: dw_dmac: get number of channels from hardware if possible
> Applying: dw_dmac: autoconfigure block_size or use platform data
> Applying: dw_dmac: autoconfigure data_width or get it via platform data
> Applying: dw_dmac: introduce software emulation of LLP transfers
> ...
> 
> Have you kept the order of the patches?
Obviously see my next

The reason for conflict is nature of this patch. It should be split up. 
arch/arm/mach-spear13xx/spear13xx.c |2 ++
arch/avr32/mach-at32ap/at32ap700x.c |2 ++

It fails here, send these separately to Arnd.


-- 
~Vinod

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: da9052-core: Fix request_threaded_irq() parameter

[Arnd Bergmann]

On Thursday 27 September 2012, Mark Brown wrote:
> On Thu, Sep 27, 2012 at 12:55:35AM -0300, Fabio Estevam wrote:
> > From: Fabio Estevam 
> > 
> > On a mx53qsb dt-kernel the da9052-core driver fails to probe:
> > 
> > da9052 1-0048: DA9052 ADC IRQ failed ret=-22
> > 
> > In request_threaded_irq() the first parameter is missing the 
> > da9052->irq_base.
> > 
> > Fix it and avoid the error.
> 
> The driver shouldn't be relying on irq_base at all, it should use
> regmap_get_virq() to look up the interrupt number.  If it relies on
> irq_base then the user is forced to assign one (or rely on automatic
> assignment, which is a bit erratic.  Otherwise it can use a linear
> domain which doesn't rely on being able to allocate a big block of
> interrupt numbers.

For all I can tell, the driver implements the automatic assignment
correctly, but I was also going to ask for removing the da9052->irq_base
variable and using the linear domain instead.

We don't have any platforms actually setting the irq_base in the
mainline kernel (I assume some of out tree platforms do this), but there
are a few drivers that need to be adapted to use regmap_irq_get_virq
or irq_to_desc(irq)->hw_irq, respectively:

drivers/gpio/gpio-da9052.c: return da9052->irq_base + DA9052_IRQ_GPI0 + 
offset;
drivers/input/touchscreen/da9052_tsi.c: tsi->irq_pendwn = da9052->irq_base + 
irq_pendwn;
drivers/input/touchscreen/da9052_tsi.c: tsi->irq_datardy = da9052->irq_base + 
irq_datardy;
drivers/power/da9052-battery.c: irq -= bat->da9052->irq_base;
drivers/power/da9052-battery.c: ret = 
request_threaded_irq(bat->da9052->irq_base + irq,
drivers/power/da9052-battery.c: free_irq(bat->da9052->irq_base + irq, 
bat);
drivers/power/da9052-battery.c: free_irq(bat->da9052->irq_base + irq, 
bat);

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

[PATCH v2] drivers/media: Remove unnecessary semicolon

[Peter Senna Tschudin]

Remove unnecessary semicolon

And:
drivers/media/dvb-frontends/stv0900_core.c: remove unnecessary whitespace 
before a
quoted newline

Found by http://coccinelle.lip6.fr/

Signed-off-by: Peter Senna Tschudin 
---
 drivers/media/dvb-core/dvb_frontend.c |  2 +-
 drivers/media/dvb-frontends/a8293.c   |  2 +-
 drivers/media/dvb-frontends/af9013.c  |  6 +++---
 drivers/media/dvb-frontends/bcm3510.c |  2 +-
 drivers/media/dvb-frontends/cx24110.c |  6 +++---
 drivers/media/dvb-frontends/drxd_hard.c   |  2 +-
 drivers/media/dvb-frontends/isl6405.c |  2 +-
 drivers/media/dvb-frontends/isl6421.c |  2 +-
 drivers/media/dvb-frontends/itd1000.c |  2 +-
 drivers/media/dvb-frontends/lnbp21.c  |  4 ++--
 drivers/media/dvb-frontends/lnbp22.c  |  2 +-
 drivers/media/dvb-frontends/si21xx.c  |  4 ++--
 drivers/media/dvb-frontends/sp8870.c  |  6 +++---
 drivers/media/dvb-frontends/sp887x.c  |  6 +++---
 drivers/media/dvb-frontends/stv0299.c |  6 +++---
 drivers/media/dvb-frontends/stv0900_core.c|  4 ++--
 drivers/media/dvb-frontends/tda8083.c |  4 ++--
 drivers/media/i2c/cx25840/cx25840-core.c  |  2 +-
 drivers/media/pci/bt8xx/dst_ca.c  |  2 +-
 drivers/media/pci/cx23885/altera-ci.c |  4 ++--
 drivers/media/pci/cx23885/cimax2.c|  2 +-
 drivers/media/pci/cx88/cx88-blackbird.c   |  6 +++---
 drivers/media/pci/cx88/cx88-dvb.c |  2 +-
 drivers/media/pci/cx88/cx88-mpeg.c|  2 +-
 drivers/media/pci/cx88/cx88-tvaudio.c |  4 ++--
 drivers/media/pci/cx88/cx88-video.c   |  2 +-
 drivers/media/pci/saa7134/saa7134-video.c |  2 +-
 drivers/media/platform/exynos-gsc/gsc-regs.c  |  4 ++--
 drivers/media/radio/si470x/radio-si470x-i2c.c |  2 +-
 drivers/media/radio/si470x/radio-si470x-usb.c |  2 +-
 drivers/media/radio/si4713-i2c.c  | 12 ++--
 drivers/media/usb/dvb-usb-v2/af9015.c |  4 ++--
 drivers/media/usb/dvb-usb-v2/af9035.c |  2 +-
 33 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 479a5e5..b5f141a 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2288,7 +2288,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
fepriv->tune_mode_flags = (unsigned long) parg;
err = 0;
break;
-   };
+   }
 
return err;
 }
diff --git a/drivers/media/dvb-frontends/a8293.c 
b/drivers/media/dvb-frontends/a8293.c
index cff44a3..74fbb5d 100644
--- a/drivers/media/dvb-frontends/a8293.c
+++ b/drivers/media/dvb-frontends/a8293.c
@@ -90,7 +90,7 @@ static int a8293_set_voltage(struct dvb_frontend *fe,
default:
ret = -EINVAL;
goto err;
-   };
+   }
 
ret = a8293_wr(priv, >reg[0], 1);
if (ret)
diff --git a/drivers/media/dvb-frontends/af9013.c 
b/drivers/media/dvb-frontends/af9013.c
index e9f04a3..a204f28 100644
--- a/drivers/media/dvb-frontends/af9013.c
+++ b/drivers/media/dvb-frontends/af9013.c
@@ -241,7 +241,7 @@ static int af9013_set_gpio(struct af9013_state *state, u8 
gpio, u8 gpioval)
KBUILD_MODNAME, gpio);
ret = -EINVAL;
goto err;
-   };
+   }
 
switch (gpio) {
case 0:
@@ -253,7 +253,7 @@ static int af9013_set_gpio(struct af9013_state *state, u8 
gpio, u8 gpioval)
default:
pos = 4;
break;
-   };
+   }
 
ret = af9013_wr_reg_bits(state, addr, pos, 4, gpioval);
if (ret)
@@ -726,7 +726,7 @@ static int af9013_set_frontend(struct dvb_frontend *fe)
default:
dev_dbg(>i2c->dev, "%s: invalid hierarchy\n", __func__);
auto_mode = 1;
-   };
+   }
 
switch (c->modulation) {
case QAM_AUTO:
diff --git a/drivers/media/dvb-frontends/bcm3510.c 
b/drivers/media/dvb-frontends/bcm3510.c
index 033cd7a..1b77909 100644
--- a/drivers/media/dvb-frontends/bcm3510.c
+++ b/drivers/media/dvb-frontends/bcm3510.c
@@ -527,7 +527,7 @@ static int bcm3510_set_frontend(struct dvb_frontend *fe)
cmd.ACQUIRE1.IF_FREQ = 0x0;
default:
return -EINVAL;
-   };
+   }
cmd.ACQUIRE0.OFFSET = 0;
cmd.ACQUIRE0.NTSCSWEEP = 1;
cmd.ACQUIRE0.FA = 1;
diff --git a/drivers/media/dvb-frontends/cx24110.c 
b/drivers/media/dvb-frontends/cx24110.c
index 3180f5b..0cd6927 100644
--- a/drivers/media/dvb-frontends/cx24110.c
+++ b/drivers/media/dvb-frontends/cx24110.c
@@ -218,7 +218,7 @@ static int cx24110_set_fec (struct cx24110_state* state, 
fe_code_rate_t fec)
   } else
   return -EOPNOTSUPP;
 /* fixme (low): which is the correct return code? */
-   };
+   }

[PATCH 4/4] sl[au]b: process slabinfo_show in common code

[Glauber Costa]

With all the infrastructure in place, we can now have slabinfo_show
done from slab_common.c. A cache-specific function is called to grab
information about the cache itself, since that is still heavily
dependent on the implementation. But with the values produced by it, all
the printing and handling is done from common code.

Signed-off-by: Glauber Costa 
CC: Christoph Lameter 
CC: Pekka Enberg 
CC: David Rientjes 
---
 include/linux/slab_def.h | 10 ++
 include/linux/slub_def.h | 11 +++
 mm/slab.c| 24 +---
 mm/slab.h| 14 +-
 mm/slab_common.c | 18 +-
 mm/slub.c| 22 --
 6 files changed, 72 insertions(+), 27 deletions(-)

diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
index 36d7031..384cf17 100644
--- a/include/linux/slab_def.h
+++ b/include/linux/slab_def.h
@@ -97,6 +97,16 @@ struct kmem_cache {
 */
 };
 
+static inline int cache_order(struct kmem_cache *s)
+{
+   return s->gfporder;
+}
+
+static inline int objects_per_slab(struct kmem_cache *s)
+{
+   return s->num;
+}
+
 /* Size description struct for general caches. */
 struct cache_sizes {
size_t  cs_size;
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index f1590c9..668b9f1 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -125,6 +125,17 @@ struct kmem_cache {
struct kmem_cache_node *node[MAX_NUMNODES];
 };
 
+static inline int cache_order(struct kmem_cache *s)
+{
+   return oo_order(s->oo);
+}
+
+static inline int objects_per_slab(struct kmem_cache *s)
+{
+   return oo_objects(s->oo);
+}
+
+
 /*
  * Kmalloc subsystem.
  */
diff --git a/mm/slab.c b/mm/slab.c
index a3de3e5..1781150 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4283,9 +4283,8 @@ out:
 }
 
 #ifdef CONFIG_SLABINFO
-int slabinfo_show(struct seq_file *m, void *p)
+void get_slabinfo(struct kmem_cache *cachep, struct slabinfo *sinfo)
 {
-   struct kmem_cache *cachep = list_entry(p, struct kmem_cache, list);
struct slab *slabp;
unsigned long active_objs;
unsigned long num_objs;
@@ -4340,13 +4339,18 @@ int slabinfo_show(struct seq_file *m, void *p)
if (error)
printk(KERN_ERR "slab: cache %s error: %s\n", name, error);
 
-   seq_printf(m, "%-17s %6lu %6lu %6u %4u %4d",
-  name, active_objs, num_objs, cachep->size,
-  cachep->num, (1 << cachep->gfporder));
-   seq_printf(m, " : tunables %4u %4u %4u",
-  cachep->limit, cachep->batchcount, cachep->shared);
-   seq_printf(m, " : slabdata %6lu %6lu %6lu",
-  active_slabs, num_slabs, shared_avail);
+   sinfo->active_objs = active_objs;
+   sinfo->num_objs = num_objs;
+   sinfo->active_slabs = active_slabs;
+   sinfo->num_slabs = num_slabs;
+   sinfo->shared_avail = shared_avail;
+   sinfo->limit = cachep->limit;
+   sinfo->batchcount = cachep->batchcount;
+   sinfo->shared = cachep->shared;
+}
+
+void slabinfo_show_stats(struct seq_file *m, struct kmem_cache *cachep)
+{
 #if STATS
{   /* list3 stats */
unsigned long high = cachep->high_mark;
@@ -4376,8 +4380,6 @@ int slabinfo_show(struct seq_file *m, void *p)
   allochit, allocmiss, freehit, freemiss);
}
 #endif
-   seq_putc(m, '\n');
-   return 0;
 }
 
 #define MAX_SLABINFO_WRITE 128
diff --git a/mm/slab.h b/mm/slab.h
index 45b75c8..763f019 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -47,8 +47,20 @@ static inline struct kmem_cache *__kmem_cache_alias(const 
char *name, size_t siz
 
 int __kmem_cache_shutdown(struct kmem_cache *);
 
-int slabinfo_show(struct seq_file *m, void *p);
+struct slabinfo {
+   unsigned long active_objs;
+   unsigned long num_objs;
+   unsigned long active_slabs;
+   unsigned long num_slabs;
+   unsigned long shared_avail;
+   unsigned int limit;
+   unsigned int batchcount;
+   unsigned int shared;
 
+};
+
+void get_slabinfo(struct kmem_cache *s, struct slabinfo *sinfo);
+void slabinfo_show_stats(struct seq_file *m, struct kmem_cache *s);
 ssize_t slabinfo_write(struct file *file, const char __user *buffer,
   size_t count, loff_t *ppos);
 #endif
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 1bde24a..89db427 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -239,7 +239,23 @@ static void s_stop(struct seq_file *m, void *p)
 
 static int s_show(struct seq_file *m, void *p)
 {
-   return slabinfo_show(m, p);
+   struct kmem_cache *s = list_entry(p, struct kmem_cache, list);
+   struct slabinfo sinfo;
+
+   memset(, 0, sizeof(sinfo));
+   get_slabinfo(s, );
+
+   seq_printf(m, "%-17s %6lu %6lu %6u %4u %4d",
+  s->name, sinfo.active_objs, sinfo.num_objs, s->size,
+  

[PATCH 0/4] move slabinfo processing to common code

[Glauber Costa]

Hi,

This patch moves on with the slab caches commonization, by moving
the slabinfo processing to common code in slab_common.c. It only touches
slub and slab, since slob doesn't create that file, which is protected
by a Kconfig switch.

Enjoy,

Glauber Costa (4):
  move slabinfo processing to slab_common.c
  move print_slabinfo_header to slab_common.c
  slub: move slub internal functions to its header
  sl[au]b: process slabinfo_show in common code

 include/linux/slab_def.h |  10 
 include/linux/slub_def.h |  25 ++
 mm/slab.c| 116 ++-
 mm/slab.h|  16 +++
 mm/slab_common.c | 109 
 mm/slub.c|  89 
 6 files changed, 193 insertions(+), 172 deletions(-)

-- 
1.7.11.4

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

[PATCH 3/4] slub: move slub internal functions to its header

[Glauber Costa]

The functions oo_order() and oo_objects() are used by the slub to
determine respectively the order of a candidate allocation, and the
number of objects made available from it. I would like a stable visible
location outside slub.c so it can be acessed from slab_common.c.

I considered also just making it a common field between slub and slab,
but decided to move those to slub_def.h due to two main reasons: first,
it still deals with implementation specific details of the caches, so it
is better to just use wrappers. Second, because it is not necessarily
the order determined at cache creation time, but possibly a smaller
order in case of a retry. When we use it in slab_common.c we will be
talking about "base" values, but those functions would still have to
exist inside slub, so doing this we can just reuse them.

Signed-off-by: Glauber Costa 
CC: Christoph Lameter 
CC: Pekka Enberg 
CC: David Rientjes 
---
 include/linux/slub_def.h | 14 ++
 mm/slub.c| 14 --
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index df448ad..f1590c9 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -73,6 +73,20 @@ struct kmem_cache_order_objects {
unsigned long x;
 };
 
+#define OO_SHIFT   16
+#define OO_MASK((1 << OO_SHIFT) - 1)
+#define MAX_OBJS_PER_PAGE  32767 /* since page.objects is u15 */
+
+static inline int oo_order(struct kmem_cache_order_objects x)
+{
+   return x.x >> OO_SHIFT;
+}
+
+static inline int oo_objects(struct kmem_cache_order_objects x)
+{
+   return x.x & OO_MASK;
+}
+
 /*
  * Slab cache management.
  */
diff --git a/mm/slub.c b/mm/slub.c
index 4c2c092..9e72722 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -171,10 +171,6 @@ static inline int kmem_cache_debug(struct kmem_cache *s)
 #define SLUB_MERGE_SAME (SLAB_DEBUG_FREE | SLAB_RECLAIM_ACCOUNT | \
SLAB_CACHE_DMA | SLAB_NOTRACK)
 
-#define OO_SHIFT   16
-#define OO_MASK((1 << OO_SHIFT) - 1)
-#define MAX_OBJS_PER_PAGE  32767 /* since page.objects is u15 */
-
 /* Internal SLUB flags */
 #define __OBJECT_POISON0x8000UL /* Poison object */
 #define __CMPXCHG_DOUBLE   0x4000UL /* Use cmpxchg_double */
@@ -325,16 +321,6 @@ static inline struct kmem_cache_order_objects oo_make(int 
order,
return x;
 }
 
-static inline int oo_order(struct kmem_cache_order_objects x)
-{
-   return x.x >> OO_SHIFT;
-}
-
-static inline int oo_objects(struct kmem_cache_order_objects x)
-{
-   return x.x & OO_MASK;
-}
-
 /*
  * Per slab locking using the pagelock
  */
-- 
1.7.11.4

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

[PATCH 2/4] sl[au]b: move print_slabinfo_header to slab_common.c

[Glauber Costa]

The header format is highly similar between slab and slub. The main
difference lays in the fact that slab may optionally have statistics
added here in case of CONFIG_SLAB_DEBUG, while the slub will stick them
somewhere else.

By making sure that information conditionally lives inside a
globally-visible CONFIG_DEBUG_SLAB switch, we can move the header
printing to a common location.

Signed-off-by: Glauber Costa 
CC: Christoph Lameter 
CC: Pekka Enberg 
CC: David Rientjes 
---
 mm/slab.c| 24 
 mm/slab.h|  2 --
 mm/slab_common.c | 23 +++
 mm/slub.c| 10 --
 4 files changed, 23 insertions(+), 36 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 9502dfc..a3de3e5 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4283,30 +4283,6 @@ out:
 }
 
 #ifdef CONFIG_SLABINFO
-
-void print_slabinfo_header(struct seq_file *m)
-{
-   /*
-* Output format version, so at least we can change it
-* without _too_ many complaints.
-*/
-#if STATS
-   seq_puts(m, "slabinfo - version: 2.1 (statistics)\n");
-#else
-   seq_puts(m, "slabinfo - version: 2.1\n");
-#endif
-   seq_puts(m, "# name   "
-" ");
-   seq_puts(m, " : tunables   ");
-   seq_puts(m, " : slabdata   ");
-#if STATS
-   seq_puts(m, " : globalstat "
-"
");
-   seq_puts(m, " : cpustat");
-#endif
-   seq_putc(m, '\n');
-}
-
 int slabinfo_show(struct seq_file *m, void *p)
 {
struct kmem_cache *cachep = list_entry(p, struct kmem_cache, list);
diff --git a/mm/slab.h b/mm/slab.h
index ac0053f6..45b75c8 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -47,8 +47,6 @@ static inline struct kmem_cache *__kmem_cache_alias(const 
char *name, size_t siz
 
 int __kmem_cache_shutdown(struct kmem_cache *);
 
-void print_slabinfo_header(struct seq_file *m);
-
 int slabinfo_show(struct seq_file *m, void *p);
 
 ssize_t slabinfo_write(struct file *file, const char __user *buffer,
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 2e0061a..1bde24a 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -193,6 +193,29 @@ int slab_is_available(void)
 }
 
 #ifdef CONFIG_SLABINFO
+void print_slabinfo_header(struct seq_file *m)
+{
+   /*
+* Output format version, so at least we can change it
+* without _too_ many complaints.
+*/
+#ifdef CONFIG_DEBUG_SLAB
+   seq_puts(m, "slabinfo - version: 2.1 (statistics)\n");
+#else
+   seq_puts(m, "slabinfo - version: 2.1\n");
+#endif
+   seq_puts(m, "# name   "
+" ");
+   seq_puts(m, " : tunables   ");
+   seq_puts(m, " : slabdata   ");
+#ifdef CONFIG_DEBUG_SLAB
+   seq_puts(m, " : globalstat "
+"
");
+   seq_puts(m, " : cpustat");
+#endif
+   seq_putc(m, '\n');
+}
+
 static void *s_start(struct seq_file *m, loff_t *pos)
 {
loff_t n = *pos;
diff --git a/mm/slub.c b/mm/slub.c
index 6383622..4c2c092 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5392,16 +5392,6 @@ __initcall(slab_sysfs_init);
  * The /proc/slabinfo ABI
  */
 #ifdef CONFIG_SLABINFO
-void print_slabinfo_header(struct seq_file *m)
-{
-   seq_puts(m, "slabinfo - version: 2.1\n");
-   seq_puts(m, "# name   "
-" ");
-   seq_puts(m, " : tunables   ");
-   seq_puts(m, " : slabdata   ");
-   seq_putc(m, '\n');
-}
-
 int slabinfo_show(struct seq_file *m, void *p)
 {
unsigned long nr_partials = 0;
-- 
1.7.11.4

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

[PATCH 1/4] sl[au]b: move slabinfo processing to slab_common.c

[Glauber Costa]

This patch moves all the common machinery to slabinfo processing
to slab_common.c. We can do better by noticing that the output is
heavily common, and having the allocators to just provide finished
information about this. But after this first step, this can be done
easier.

Signed-off-by: Glauber Costa 
CC: Christoph Lameter 
CC: Pekka Enberg 
CC: David Rientjes 
---
 mm/slab.c| 72 ++--
 mm/slab.h|  6 +
 mm/slab_common.c | 70 ++
 mm/slub.c| 51 ---
 4 files changed, 94 insertions(+), 105 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 8524923..9502dfc 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4284,7 +4284,7 @@ out:
 
 #ifdef CONFIG_SLABINFO
 
-static void print_slabinfo_header(struct seq_file *m)
+void print_slabinfo_header(struct seq_file *m)
 {
/*
 * Output format version, so at least we can change it
@@ -4307,28 +4307,7 @@ static void print_slabinfo_header(struct seq_file *m)
seq_putc(m, '\n');
 }
 
-static void *s_start(struct seq_file *m, loff_t *pos)
-{
-   loff_t n = *pos;
-
-   mutex_lock(_mutex);
-   if (!n)
-   print_slabinfo_header(m);
-
-   return seq_list_start(_caches, *pos);
-}
-
-static void *s_next(struct seq_file *m, void *p, loff_t *pos)
-{
-   return seq_list_next(p, _caches, pos);
-}
-
-static void s_stop(struct seq_file *m, void *p)
-{
-   mutex_unlock(_mutex);
-}
-
-static int s_show(struct seq_file *m, void *p)
+int slabinfo_show(struct seq_file *m, void *p)
 {
struct kmem_cache *cachep = list_entry(p, struct kmem_cache, list);
struct slab *slabp;
@@ -4425,27 +4404,6 @@ static int s_show(struct seq_file *m, void *p)
return 0;
 }
 
-/*
- * slabinfo_op - iterator that generates /proc/slabinfo
- *
- * Output layout:
- * cache-name
- * num-active-objs
- * total-objs
- * object size
- * num-active-slabs
- * total-slabs
- * num-pages-per-slab
- * + further values on SMP and with statistics enabled
- */
-
-static const struct seq_operations slabinfo_op = {
-   .start = s_start,
-   .next = s_next,
-   .stop = s_stop,
-   .show = s_show,
-};
-
 #define MAX_SLABINFO_WRITE 128
 /**
  * slabinfo_write - Tuning for the slab allocator
@@ -4454,7 +4412,7 @@ static const struct seq_operations slabinfo_op = {
  * @count: data length
  * @ppos: unused
  */
-static ssize_t slabinfo_write(struct file *file, const char __user *buffer,
+ssize_t slabinfo_write(struct file *file, const char __user *buffer,
   size_t count, loff_t *ppos)
 {
char kbuf[MAX_SLABINFO_WRITE + 1], *tmp;
@@ -4497,19 +4455,6 @@ static ssize_t slabinfo_write(struct file *file, const 
char __user *buffer,
return res;
 }
 
-static int slabinfo_open(struct inode *inode, struct file *file)
-{
-   return seq_open(file, _op);
-}
-
-static const struct file_operations proc_slabinfo_operations = {
-   .open   = slabinfo_open,
-   .read   = seq_read,
-   .write  = slabinfo_write,
-   .llseek = seq_lseek,
-   .release= seq_release,
-};
-
 #ifdef CONFIG_DEBUG_SLAB_LEAK
 
 static void *leaks_start(struct seq_file *m, loff_t *pos)
@@ -4638,6 +4583,16 @@ static int leaks_show(struct seq_file *m, void *p)
return 0;
 }
 
+static void *s_next(struct seq_file *m, void *p, loff_t *pos)
+{
+   return seq_list_next(p, _caches, pos);
+}
+
+static void s_stop(struct seq_file *m, void *p)
+{
+   mutex_unlock(_mutex);
+}
+
 static const struct seq_operations slabstats_op = {
.start = leaks_start,
.next = s_next,
@@ -4672,7 +4627,6 @@ static const struct file_operations 
proc_slabstats_operations = {
 
 static int __init slab_proc_init(void)
 {
-   proc_create("slabinfo",S_IWUSR|S_IRUSR,NULL,_slabinfo_operations);
 #ifdef CONFIG_DEBUG_SLAB_LEAK
proc_create("slab_allocators", 0, NULL, _slabstats_operations);
 #endif
diff --git a/mm/slab.h b/mm/slab.h
index 7deeb44..ac0053f6 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -47,4 +47,10 @@ static inline struct kmem_cache *__kmem_cache_alias(const 
char *name, size_t siz
 
 int __kmem_cache_shutdown(struct kmem_cache *);
 
+void print_slabinfo_header(struct seq_file *m);
+
+int slabinfo_show(struct seq_file *m, void *p);
+
+ssize_t slabinfo_write(struct file *file, const char __user *buffer,
+  size_t count, loff_t *ppos);
 #endif
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 9c21725..2e0061a 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -189,3 +191,71 @@ int slab_is_available(void)
 {
return slab_state >= UP;
 }
+
+#ifdef CONFIG_SLABINFO
+static void *s_start(struct seq_file *m, loff_t *pos)
+{
+   loff_t n = *pos;
+
+   mutex_lock(_mutex);
+  

Re: [PATCHv2 2/4] dmaengine: dw_dmac: Add PCI part of the driver

[Arnd Bergmann]

On Thursday 27 September 2012, Vinod Koul wrote:
> > where the first one is called by the other two, depending on the bus type.
> > This could be done either splitting the driver into multiple files so you 
> > can
> > have the platform and pci parts in separate driver modules depending on the
> > common module that does all the actual work, or everything can be put in
> > a single file with an #ifdef CONFIG_PCI to disable the pci driver parts
> > when they don't apply.
>
> probe wont be called if PCI device is not loaded, so see no reason why
> CONFIG_xxx would be needed

I assumed that you could not have a call to pci_register_driver with
CONFIG_PCI disabled. It seems that the function is stubbed out, so
you're probably right that we can do it even without the #ifdef.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/13] kmem accounting basic infrastructure

[Mel Gorman]

On Thu, Sep 27, 2012 at 07:33:00AM -0700, Tejun Heo wrote:
> Hello, Michal.
> 
> On Thu, Sep 27, 2012 at 02:08:06PM +0200, Michal Hocko wrote:
> > Yes, because we have many users (basically almost all) who care only
> > about the user memory because that's what occupies the vast majority of
> > the memory. They usually want to isolate workload which would disrupt
> > the global memory otherwise (e.g. backup process vs. database). You
> > really do not want to pay an additional overhead for kmem accounting
> > here.
> 
> I'm not too convinced.  First of all, the overhead added by kmemcg
> isn't big. 

Really?

If kmemcg was globally accounted then every __GFP_KMEMCG allocation in
the page allocator potentially ends up down in
__memcg_kmem_newpage_charge which

1. takes RCU read lock
2. looks up cgroup from task
3. takes a reference count
4. memcg_charge_kmem -> __mem_cgroup_try_charge
5. release reference count

That's a *LOT* of work to incur for cgroups that do not care about kernel
accounting. This is why I thought it was reasonable that the kmem accounting
not be global.

-- 
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: [RFC] tty: Add get- ioctls to fetch tty status

[H. Peter Anvin]

On 09/27/2012 07:21 AM, Cyrill Gorcunov wrote:

On Thu, Sep 27, 2012 at 07:17:49AM -0700, H. Peter Anvin wrote:

While we easily can fetch termios settings and such, there are few bits which
are missed to expord. So this patch provides them to user-space.



What bothers me (and the same applies to termios) is that you have
NO idea if your particular process is the "owner" of that tty.  tty
users use out-of-band protocols, often implicit, to determine which
process "owns" the tty state.

If you can't guarantee that ALL those processes are stopped and
checkpointed/restarted, you have a huge problem.


Well, sure inside our tool before doing checkpoint we stop all
tasks which are part of dumpee process tree. This unfortunatly
doesn't apply to these ioctl calls. Peter, any idea how to deal
with that?



Sorry, no.  I suspect you might be trying to do something that is 
impossible to do in a general fashion without application changes.


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/char/tpm: remove tasklet and cleanup

[Ashley Lai]

On Wed, 2012-09-26 at 08:55 -0500, k...@linux.vnet.ibm.com wrote:
> On Mon, Sep 24, 2012 at 10:48:21AM -0500, k...@linux.vnet.ibm.com wrote:
> > On Mon, Sep 24, 2012 at 09:10:41AM -0500, k...@linux.vnet.ibm.com wrote:
> > > On Mon, Sep 24, 2012 at 12:26:05PM +1000, James Morris wrote:
> > > > On Wed, 12 Sep 2012, Ashley Lai wrote:
> > > > 
> > > > > This patch removed the tasklet and moved the wait queue into the
> > > > > private structure.  It also cleaned up the response CRQ path.
> > > > > 
> > > > > Signed-off-by: Ashley Lai 
> > > > 
> > > > 
> > > > Kent: any comment on this?  You should probably push this to me via 
> > > > your 
> > > > tree.
> > > 
> > >   Oh, I thought we were waiting on Ben. This looks good to me, I'll get
> > > this to you today.
> > 
> >   Ashley tells me Ben's review is in the works, so I'll send once we
> > have it.
> 
>   Ben - any status here?
> 
> Kent

Hi Ben,

Would you review the patch before the weekend?  If you are busy and not
able to review the patch this week, we will pull the patch into James's
tree next week.  I can resolve any additional comments you may have in a
different patch.

Thanks,
--Ashley Lai

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


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

RE: [PATCH v6] hashtable: introduce a small and naive hashtable

[David Laight]

> Moreover, if your thinking is that we do not need a static inline
> function replicated at every caller, maybe we should introduce a
> lib/hashtable.c that implements those 2 functions.

That was my thought...
Given their nature, I'd guess they aren't critical path.
Probably not worth adding an entire source file though.

With regard to 'inline', when I say it, I really mean it!
Unfortunately some people seem to just type it anyway (rather
like 'register' used to get used) - so the compilers start
ignoring the request.
At least some versions of gcc will usually inline static
functions that are only called once - but even then it can
change its mind for almost no reason.

David



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

WARNING: at block/genhd.c:1570 disk_clear_events+0xbf/0xd0()

[Roberto Corrado]

[  287.677274] [ cut here ]
[  287.678042] WARNING: at block/genhd.c:1570 disk_clear_events+0xbf/0xd0()
[  287.678042] Hardware name: CLE266-8235
[  287.678042] Modules linked in: fuse ppdev evdev pcmcia snd_via82xx gameport 
snd_ac97_codec ac97_bus snd_pcm ath5k snd_timer uhci_hcd snd_page_alloc ath 
snd_mpu401_uart snd_raw
[  287.678042] Pid: 889, comm: udevd Not tainted 
3.3.3-Server2.corradoroberto.it #1
[  287.678042] Call Trace:
[  287.678042]  [] warn_slowpath_common+0x72/0xa0
[  287.678042]  [] ? disk_clear_events+0xbf/0xd0
[  287.678042]  [] ? disk_clear_events+0xbf/0xd0
[  287.678042]  [] warn_slowpath_null+0x22/0x30
[  287.678042]  [] disk_clear_events+0xbf/0xd0
[  287.678042]  [] check_disk_change+0x26/0x70
[  287.678042]  [] sd_open+0x78/0x120
[  287.678042]  [] ? sd_rescan+0x30/0x30
[  287.678042]  [] __blkdev_get+0x2e9/0x400
[  287.678042]  [] blkdev_get+0x12c/0x230
[  287.678042]  [] blkdev_open+0x5b/0x90
[  287.678042]  [] __dentry_open+0x1d2/0x2d0
[  287.678042]  [] ? do_lookup+0x4a/0x350
[  287.678042]  [] nameidata_to_filp+0x66/0x80
[  287.678042]  [] ? blkdev_get+0x230/0x230
[  287.678042]  [] do_last+0x3b7/0x7b0
[  287.678042]  [] path_openat+0xa4/0x340
[  287.678042]  [] do_filp_open+0x31/0x80
[  287.678042]  [] ? alloc_fd+0x34/0xe0
[  287.678042]  [] ? getname_flags+0xb3/0x160
[  287.678042]  [] do_sys_open+0xdd/0x1b0
[  287.678042]  [] sys_open+0x32/0x40
[  287.678042]  [] syscall_call+0x7/0xb
[  287.678042] ---[ end trace 8e15e60cfd5ae222 ]---


smime.p7s
Description: S/MIME cryptographic signature

Re: [RFC] tty: Add get- ioctls to fetch tty status

[Cyrill Gorcunov]

On Thu, Sep 27, 2012 at 07:43:44AM -0700, H. Peter Anvin wrote:
> >>If you can't guarantee that ALL those processes are stopped and
> >>checkpointed/restarted, you have a huge problem.
> >
> >Well, sure inside our tool before doing checkpoint we stop all
> >tasks which are part of dumpee process tree. This unfortunatly
> >doesn't apply to these ioctl calls. Peter, any idea how to deal
> >with that?
> 
> Sorry, no.  I suspect you might be trying to do something that is
> impossible to do in a general fashion without application changes.

I see. What if I wrap all this entries with CONFIG_CHECKPOINT_RESTORE
and say add some sysctl which would enable/disbale this ioctls. Then
it'll be up to user-space callers to make sure that data received is
valid and can be used? The problem is that I need to fetch this bits
somehow with minimal changes in kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 04/13] kmem accounting basic infrastructure

[Tejun Heo]

Hello, Mel.

On Thu, Sep 27, 2012 at 03:28:22PM +0100, Mel Gorman wrote:
> > In addition, how is userland supposed to know which
> > workload is shared kmem heavy or not? 
> 
> By using a bit of common sense.
> 
> An application may not be able to figure this out but the administrator
> is going to be able to make a very educated guess. If processes running
> within two containers are not sharing a filesystem hierarchy for example
> then it'll be clear they are not sharing dentries.
> 
> If there was a suspicion they were then it could be analysed with
> something like SystemTap probing when files are opened and see if files
> are being opened that are shared between containers.
> 
> It's not super-easy but it's not impossible either and I fail to see why
> it's such a big deal for you.

Because we're not even trying to actually solve the problem but just
dumping it to userland.  If dentry/inode usage is the only case we're
being worried about, there can be better ways to solve it or at least
we should strive for that.

Also, the problem is not that it is impossible if you know and
carefully plan for things beforehand (that would be one extremely
competent admin) but that the problem is undiscoverable.  With kmemcg
accounting disabled, there's no way to tell a looking cgroup the admin
thinks running something which doesn'ft tax kmem much could be
generating a ton without the admin ever noticing.

> > The fact that the numbers don't really mean what they apparently
> > should mean.
> 
> I think it is a reasonable limitation that only some kernel allocations are
> accounted for although I'll freely admit I'm not a cgroup or memcg user
> either.
> 
> My understanding is that this comes down to cost -- accounting for the
> kernel memory usage is expensive so it is limited only to the allocations
> that are easy to abuse by an unprivileged process. Hence this is
> initially concerned with stack pages with dentries and TCP usage to
> follow in later patches.

I think the cost isn't too prohibitive considering it's already using
memcg.  Charging / uncharging happens only as pages enter and leave
slab caches and the hot path overhead is essentially single
indirection.  Glauber's benchmark seemed pretty reasonable to me and I
don't yet think that warrants exposing this subtle tree of
configuration.

> > Sure, conferences are useful for building consensus but that's the
> > extent of it.  Sorry that I didn't realize the implications then but
> > conferences don't really add any finality to decisions.
> > 
> > So, this seems properly crazy to me at the similar level of
> > use_hierarchy fiasco.  I'm gonna NACK on this.
> 
> I think you're over-reacting to say the very least :|

The part I nacked is enabling kmemcg on a populated cgroup and then
starting accounting from then without any apparent indication that any
past allocation hasn't been considered.  You end up with numbers which
nobody can't tell what they really mean and there's no mechanism to
guarantee any kind of ordering between populating the cgroup and
configuring it and there's *no* way to find out what happened
afterwards neither.  This is properly crazy and definitely deserves a
nack.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!

[Joerg Roedel]

On Tue, Aug 07, 2012 at 03:41:56PM +0200, Joerg Roedel wrote:
> starting with Linux 3.6-rc1 I experience this BUG on one of my test
> machines. Please let me know if you need any additional information.
> 
> [   20.271810] [ cut here ]
> [   20.276869] kernel BUG at /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!
> [   20.284306] invalid opcode:  [#1] SMP
> [   20.288806] Modules linked in: nfs4 auth_rpcgss nfs fscache lockd sunrpc 
> kvm_intel radeon kvm ttm drm_kms_helper i7core_edac drm edac_core joydev 
> hpilo psmouse hid_generic i2c_algo_bit serio_raw usbhid hid bnx2

I still see this BUG with 3.6-rc7. Any fix in sight?


Joerg


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Alex Deucher]

On Thu, Sep 27, 2012 at 9:23 AM, Andres Freund  wrote:
> On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
>> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund  wrote:
>> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
>> >> > -Original Message-
>> >> > From: Andres Freund [mailto:and...@anarazel.de]
>> >> > Sent: Wednesday, September 26, 2012 9:41 AM
>> >> > To: Dan Carpenter
>> >> > Cc: Deucher, Alexander; LKML; David Airlie;
>> >> > dri-de...@lists.freedesktop.org Subject: Re: radeon: Regression
>> >> > between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
>> >> >
>> >> > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
>> >> > > This is fixed now?
>> >> >
>> >> > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is
>> >> > in rc6.
>> >> >
>> >> > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
>> >> > Sorry, I somehow accidentally marked your  email as read and thus
>> >> > didn't notice it.
>> >> >
>> >> > > I think I see the problem.  I think it's a limitation of the current
>> >> > > current
>> >> >
>> >> > modesetting API.  The current API sets up each display independently
>> >> > which doesn't work so well if there are resource restrictions.  There
>> >> > shouldn't be any contention on your board since you are only using 2
>> >> > non-DP displays.  It looks like X is mapping different crtcs to
>> >> > displays than the kernel fb.
>> >> >
>> >> > Initially the kernel set up the follow:
>> >> > > > [2.134901] [drm] crtc 0 using pll 0x2
>> >> > > > [2.362257] [drm] crtc 1 using pll 0x1
>> >> > > > [2.386709] [drm] crtc 2 using pll 0x0
>> >> > >
>> >> > > Crtc 0 -> DCPLL -> DP
>> >> > > Crtc 1 -> PPLL2 -> DVI
>> >> > > Crtc 2 -> PPLL1 -> DVI
>> >> > >
>> >> > > When X loads, it tried to set a different crtc to display mapping:
>> >> > > > [   60.679310] [drm] crtc 0 using pll 0xff
>> >> > > > [   60.789183] [drm] crtc 1 using pll 0x2
>> >> > > > [   60.819594] [drm] crtc 2 using pll 0x1
>> >> > >
>> >> > > Crtc 0 -> INVALID -> DVI 0
>> >> > > Crtc 1 -> DCPLL -> DP
>> >> > > Crtc 2 -> PPLL2 -> DVI 1
>> >> > >
>> >> > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use
>> >> > > by crtc 1 and crtc  2 from the previous modeset.  Since the modeset
>> >> > > API is not atomic, it doesn't have the whole picture.  I'm not sure
>> >> > > of a good solution right now prior to the new atomic modeset API
>> >> > > that is under discussion.  I guess we can revert the patch for 3.6.
>> >> > >  For 3.7 I guess we need to validate the actual connector to make
>> >> > > sure we aren't trying to set a different configuration relating to
>> >> > > the same connector without first tearing down the first one.  In
>> >> > > the interim, you should be able to work around it by disabling the
>> >> > > non-DP outputs and then bringing than back up.
>> >> >
>> >> > Thanks! That explanation makes sense. I can work around it just fine,
>> >> > starting X multiple times works which coincides nicely with your
>> >> > explanation.
>> >> >
>> >> > The code in the 3.7 branch doesn't do that extended validation yet,
>> >> > rigth? If you want/need you can CC for testing once thats ready.
>> >>
>> >> It should handle it now.  If you could test it that would be great.
>> >
>> > Ok, just to be sure I tested Linus' tree and everything works fine there.
>> >
>> > Unfortunately thats not the case with a straight merge of
>> > alexdeucher/drm- next-3.7-wip. When gdm started *the first time* the
>> > DVI-connected (uhm, same sink type? Thats the saphire magic allowing
>> > more monitors on that type of graphics card?) I got a "unable to
>> > allocate a PPLL" error again. Logging in/starting a new X seems to fix
>> > that.
>>
>> So you have a xorg.conf with a hardcoded configuration?  If so can you
>> send it to me?
> Yes, but just setting the xrand positions:

Thanks.  I can't seem to reproduce it here, but I've pushed an updated
drm-next-3.7-wip which may help.  If not, can you apply the attached
patch and send me the output?

Thanks,

Alex


pll_debug.diff
Description: Binary data

Re: [PATCH 0/4] move slabinfo processing to common code

[Christoph Lameter]

On Thu, 27 Sep 2012, Glauber Costa wrote:

> This patch moves on with the slab caches commonization, by moving
> the slabinfo processing to common code in slab_common.c. It only touches
> slub and slab, since slob doesn't create that file, which is protected
> by a Kconfig switch.

Thanks. That was also something on my todo list.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/13] kmem accounting basic infrastructure

[Tejun Heo]

Hello, Mel.

On Thu, Sep 27, 2012 at 03:43:07PM +0100, Mel Gorman wrote:
> > I'm not too convinced.  First of all, the overhead added by kmemcg
> > isn't big. 
> 
> Really?
> 
> If kmemcg was globally accounted then every __GFP_KMEMCG allocation in
> the page allocator potentially ends up down in
> __memcg_kmem_newpage_charge which
> 
> 1. takes RCU read lock
> 2. looks up cgroup from task
> 3. takes a reference count
> 4. memcg_charge_kmem -> __mem_cgroup_try_charge
> 5. release reference count
> 
> That's a *LOT* of work to incur for cgroups that do not care about kernel
> accounting. This is why I thought it was reasonable that the kmem accounting
> not be global.

But that happens only when pages enter and leave slab and if it still
is significant, we can try to further optimize charging.  Given that
this is only for cases where memcg is already in use and we provide a
switch to disable it globally, I really don't think this warrants
implementing fully hierarchy configuration.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] sl[au]b: move slabinfo processing to slab_common.c

[Christoph Lameter]

On Thu, 27 Sep 2012, Glauber Costa wrote:

> This patch moves all the common machinery to slabinfo processing
> to slab_common.c. We can do better by noticing that the output is
> heavily common, and having the allocators to just provide finished
> information about this. But after this first step, this can be done
> easier.

Acked-by: Christoph Lameter 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] drivers: usb: phy: add a new driver for omap usb2 phy

[ABRAHAM, KISHON VIJAY]

Hi,

On Thu, Sep 27, 2012 at 7:54 PM, Rob Herring  wrote:
> On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote:
>> Hi,
>>
>> On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring  wrote:
>>> On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote:
 All phy related programming like enabling/disabling the clocks, powering
 on/off the phy is taken care of by this driver. It is also used for OTG
 related functionality like srp.

 This also includes device tree support for usb2 phy driver and
 the documentation with device tree binding information is updated.

 Currently writing to control module register is taken care in this
 driver which will be removed once the control module driver is in place.

 Cc: Felipe Balbi 
 Signed-off-by: Kishon Vijay Abraham I 
 ---
  Documentation/devicetree/bindings/usb/usb-phy.txt |   17 ++
  drivers/usb/phy/Kconfig   |9 +
  drivers/usb/phy/Makefile  |1 +
  drivers/usb/phy/omap-usb2.c   |  271 
 +
  include/linux/usb/omap_usb.h  |   46 
  include/linux/usb/phy_companion.h |   34 +++
  6 files changed, 378 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt
  create mode 100644 drivers/usb/phy/omap-usb2.c
  create mode 100644 include/linux/usb/omap_usb.h
  create mode 100644 include/linux/usb/phy_companion.h

 diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
 b/Documentation/devicetree/bindings/usb/usb-phy.txt
 new file mode 100644
 index 000..80d4148
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
>>>
>>> This is a very generic name...
>>>
 @@ -0,0 +1,17 @@
 +USB PHY
 +
 +OMAP USB2 PHY
 +
 +Required properties:
 + - compatible: Should be "ti,omap-usb2"
>>>
>>> ...for a specific phy. However, I do think a generic binding to describe
>>> host ctrlr to phy connections is needed.
>>>
 + - reg : Address and length of the register set for the device. Also
 +add the address of control module dev conf register until a driver for
 +control module is added
>>>
>>> The dts should describe the h/w, not what you need for the current
>>> driver. The 2nd reg field does not belong here.
>>
>> Indeed. This was discussed and agreed upon as a interim solution till
>> we have a control module driver in place to write to the control
>> module register.
>
> Discussed where and agreed by who? I for one do not agree.

Please find the discussion @ https://patchwork.kernel.org/patch/1415261/

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MOP500 Audio patches due for ASoC

[Lee Jones]

On Thu, 20 Sep 2012, Mark Brown wrote:

> On Thu, Sep 20, 2012 at 02:09:09PM +0200, Lee Jones wrote:
> > The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:
> > 
> >   Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.linaro.org/people/ljones/linux-3.0-ux500.git for-asoc-next
> 
> Pulled, thanks.

Hi Mark,

Is there any reason why the following patches didn't make it into -next?

ASoC: codecs: Enable AB8500 CODEC for Device Tree
ASoC: Ux500: Enable ux500 MSP driver for Device Tree

Kind regards,
Lee

-- 
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 2/4] sl[au]b: move print_slabinfo_header to slab_common.c

[Christoph Lameter]

On Thu, 27 Sep 2012, Glauber Costa wrote:

> By making sure that information conditionally lives inside a
> globally-visible CONFIG_DEBUG_SLAB switch, we can move the header
> printing to a common location.

Acked-by: Christoph Lameter 

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