[Patch 2/5] dt: unittest: typo in error string

2015-03-13 Thread Frank Rowand
From: Frank Rowand 

Fix bug pointed out by checkpatch.

Splitting string incorrectly removed a space between two words.

Signed-off-by: Frank Rowand 
---
 drivers/of/unittest.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: b/drivers/of/unittest.c
===
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -212,8 +212,9 @@ static void __init of_selftest_check_tre
child_count = of_selftest_check_node_linkage(of_root);
 
selftest(child_count > 0, "Device node data structure is corrupted\n");
-   selftest(child_count == allnode_count, "allnodes list size (%i) doesn't 
match"
-"sibling lists size (%i)\n", allnode_count, child_count);
+   selftest(child_count == allnode_count,
+"allnodes list size (%i) doesn't match sibling lists size 
(%i)\n",
+allnode_count, child_count);
pr_debug("allnodes list size (%i); sibling lists size (%i)\n", 
allnode_count, child_count);
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[Patch 1/5] dt: unittest: early return from test skips tests

2015-03-13 Thread Frank Rowand
From: Frank Rowand 

Fix bugs pointed out by checkpatch.

Mis-coding of two if statements caused early return from function.

Number of tests completed increased from 102 to 107.
Number of tests failed increased from 0 to 2.

Signed-off-by: Frank Rowand 
---
 drivers/of/unittest.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

Index: b/drivers/of/unittest.c
===
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -762,12 +762,14 @@ static void __init of_selftest_platform_
irq = platform_get_irq(pdev, 0);
selftest(irq < 0 && irq != -EPROBE_DEFER, "device parsing error failed 
- %d\n", irq);
 
-   if (selftest(np = of_find_node_by_path("/testcase-data/platform-tests"),
-"No testcase data in device tree\n"));
+   np = of_find_node_by_path("/testcase-data/platform-tests");
+   selftest(np, "No testcase data in device tree\n");
+   if (!np)
return;
 
-   if (selftest(!(rc = device_register(&test_bus)),
-"testbus registration failed; rc=%i\n", rc));
+   rc = device_register(&test_bus);
+   selftest(!rc, "testbus registration failed; rc=%i\n", rc);
+   if (rc)
return;
 
for_each_child_of_node(np, child) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5 linux-next] udf: remove redundant buffer_head.h includes

2015-03-13 Thread Jan Kara
On Tue 10-03-15 21:44:35, Fabian Frederick wrote:
> buffer_head.h was already included in udfdecl.h
> 
> Signed-off-by: Fabian Frederick 
  OK, applied to my tree. Thanks.

Honza

> ---
>  fs/udf/balloc.c| 1 -
>  fs/udf/dir.c   | 1 -
>  fs/udf/directory.c | 1 -
>  fs/udf/file.c  | 1 -
>  fs/udf/inode.c | 1 -
>  fs/udf/misc.c  | 1 -
>  fs/udf/namei.c | 1 -
>  fs/udf/partition.c | 1 -
>  fs/udf/super.c | 1 -
>  fs/udf/symlink.c   | 1 -
>  fs/udf/truncate.c  | 1 -
>  11 files changed, 11 deletions(-)
> 
> diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
> index 1cd8916..59ac281 100644
> --- a/fs/udf/balloc.c
> +++ b/fs/udf/balloc.c
> @@ -21,7 +21,6 @@
>  
>  #include "udfdecl.h"
>  
> -#include 
>  #include 
>  
>  #include "udf_i.h"
> diff --git a/fs/udf/dir.c b/fs/udf/dir.c
> index edf4232..8af629d 100644
> --- a/fs/udf/dir.c
> +++ b/fs/udf/dir.c
> @@ -30,7 +30,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include "udf_i.h"
>  #include "udf_sb.h"
> diff --git a/fs/udf/directory.c b/fs/udf/directory.c
> index 3e44f57..c763fda 100644
> --- a/fs/udf/directory.c
> +++ b/fs/udf/directory.c
> @@ -16,7 +16,6 @@
>  
>  #include 
>  #include 
> -#include 
>  
>  struct fileIdentDesc *udf_fileident_read(struct inode *dir, loff_t *nf_pos,
>struct udf_fileident_bh *fibh,
> diff --git a/fs/udf/file.c b/fs/udf/file.c
> index 08f3555..dda8ea7 100644
> --- a/fs/udf/file.c
> +++ b/fs/udf/file.c
> @@ -33,7 +33,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include "udf_i.h"
> diff --git a/fs/udf/inode.c b/fs/udf/inode.c
> index a445d59..0001ece 100644
> --- a/fs/udf/inode.c
> +++ b/fs/udf/inode.c
> @@ -33,7 +33,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/fs/udf/misc.c b/fs/udf/misc.c
> index c175b4d..71d1c25 100644
> --- a/fs/udf/misc.c
> +++ b/fs/udf/misc.c
> @@ -23,7 +23,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include "udf_i.h"
> diff --git a/fs/udf/namei.c b/fs/udf/namei.c
> index 189b98b..3bb7c02 100644
> --- a/fs/udf/namei.c
> +++ b/fs/udf/namei.c
> @@ -27,7 +27,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/fs/udf/partition.c b/fs/udf/partition.c
> index d6caf01..5f861ed2 100644
> --- a/fs/udf/partition.c
> +++ b/fs/udf/partition.c
> @@ -24,7 +24,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  uint32_t udf_get_pblock(struct super_block *sb, uint32_t block,
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index f169411..6299f34 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -48,7 +48,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
> index d986916a..cef3c69 100644
> --- a/fs/udf/symlink.c
> +++ b/fs/udf/symlink.c
> @@ -27,7 +27,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "udf_i.h"
>  
>  static int udf_pc_to_char(struct super_block *sb, unsigned char *from,
> diff --git a/fs/udf/truncate.c b/fs/udf/truncate.c
> index 8a9657d..42b8c57 100644
> --- a/fs/udf/truncate.c
> +++ b/fs/udf/truncate.c
> @@ -22,7 +22,6 @@
>  #include "udfdecl.h"
>  #include 
>  #include 
> -#include 
>  
>  #include "udf_i.h"
>  #include "udf_sb.h"
> -- 
> 1.9.1
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5 linux-next] udf: rename udf_get_filename()

2015-03-13 Thread Jan Kara
On Tue 10-03-15 21:44:34, Fabian Frederick wrote:
> udf_readdir(), udf_find_entry() and udf_pc_to_char() use
> udf_get_filename to obtain name length. Give that function
> an appropriate name.
  Hum, have you read what that function does? It actually converts the name
to a different format and returns converted length. So your name is IMHO
more confusing - it's as if sprintf() was called sprintf_length()... Not
applied.

Honza

> 
> Signed-off-by: Fabian Frederick 
> ---
>  fs/udf/dir.c | 3 ++-
>  fs/udf/namei.c   | 3 ++-
>  fs/udf/symlink.c | 7 ---
>  fs/udf/udfdecl.h | 4 ++--
>  fs/udf/unicode.c | 4 ++--
>  5 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/fs/udf/dir.c b/fs/udf/dir.c
> index 05e90ed..edf4232 100644
> --- a/fs/udf/dir.c
> +++ b/fs/udf/dir.c
> @@ -168,7 +168,8 @@ static int udf_readdir(struct file *file, struct 
> dir_context *ctx)
>   continue;
>   }
>  
> - flen = udf_get_filename(sb, nameptr, lfi, fname, UDF_NAME_LEN);
> + flen = udf_get_filename_length(sb, nameptr, lfi, fname,
> +UDF_NAME_LEN);
>   if (!flen)
>   continue;
>  
> diff --git a/fs/udf/namei.c b/fs/udf/namei.c
> index 33b246b..189b98b 100644
> --- a/fs/udf/namei.c
> +++ b/fs/udf/namei.c
> @@ -234,7 +234,8 @@ static struct fileIdentDesc *udf_find_entry(struct inode 
> *dir,
>   if (!lfi)
>   continue;
>  
> - flen = udf_get_filename(sb, nameptr, lfi, fname, UDF_NAME_LEN);
> + flen = udf_get_filename_length(sb, nameptr, lfi, fname,
> +UDF_NAME_LEN);
>   if (flen && udf_match(flen, fname, child->len, child->name))
>   goto out_ok;
>   }
> diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
> index ac10ca9..d986916a 100644
> --- a/fs/udf/symlink.c
> +++ b/fs/udf/symlink.c
> @@ -80,9 +80,10 @@ static int udf_pc_to_char(struct super_block *sb, unsigned 
> char *from,
>   elen += pc->lengthComponentIdent;
>   if (elen > fromlen)
>   return -EIO;
> - comp_len = udf_get_filename(sb, pc->componentIdent,
> - pc->lengthComponentIdent,
> - p, tolen);
> + comp_len = udf_get_filename_length(sb,
> + pc->componentIdent,
> + pc->lengthComponentIdent,
> + p, tolen);
>   p += comp_len;
>   tolen -= comp_len;
>   if (tolen == 0)
> diff --git a/fs/udf/udfdecl.h b/fs/udf/udfdecl.h
> index 47bb3f5..70dc260 100644
> --- a/fs/udf/udfdecl.h
> +++ b/fs/udf/udfdecl.h
> @@ -211,8 +211,8 @@ udf_get_lb_pblock(struct super_block *sb, struct 
> kernel_lb_addr *loc,
>  }
>  
>  /* unicode.c */
> -extern int udf_get_filename(struct super_block *, uint8_t *, int, uint8_t *,
> - int);
> +extern int udf_get_filename_length(struct super_block *, uint8_t *, int,
> +uint8_t *, int);
>  extern int udf_put_filename(struct super_block *, const uint8_t *, uint8_t *,
>   int);
>  extern int udf_build_ustr(struct ustr *, dstring *, int);
> diff --git a/fs/udf/unicode.c b/fs/udf/unicode.c
> index b84fee3..209c0c7 100644
> --- a/fs/udf/unicode.c
> +++ b/fs/udf/unicode.c
> @@ -334,8 +334,8 @@ try_again:
>   return u_len + 1;
>  }
>  
> -int udf_get_filename(struct super_block *sb, uint8_t *sname, int slen,
> -  uint8_t *dname, int dlen)
> +int udf_get_filename_length(struct super_block *sb, uint8_t *sname, int slen,
> + uint8_t *dname, int dlen)
>  {
>   struct ustr *filename, *unifilename;
>   int len = 0;
> -- 
> 1.9.1
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/5 linux-next] udf: remove else after return in __load_block_bitmap()

2015-03-13 Thread Jan Kara
On Tue 10-03-15 21:44:33, Fabian Frederick wrote:
> else after return is not needed.
  Thanks. Applied to my tree.

Honza

> 
> Signed-off-by: Fabian Frederick 
> ---
>  fs/udf/balloc.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
> index 30f4641..1cd8916 100644
> --- a/fs/udf/balloc.c
> +++ b/fs/udf/balloc.c
> @@ -63,15 +63,14 @@ static int __load_block_bitmap(struct super_block *sb,
> block_group, nr_groups);
>   }
>  
> - if (bitmap->s_block_bitmap[block_group]) {
> + if (bitmap->s_block_bitmap[block_group])
>   return block_group;
> - } else {
> - retval = read_block_bitmap(sb, bitmap, block_group,
> -block_group);
> - if (retval < 0)
> - return retval;
> - return block_group;
> - }
> +
> + retval = read_block_bitmap(sb, bitmap, block_group, block_group);
> + if (retval < 0)
> + return retval;
> +
> + return block_group;
>  }
>  
>  static inline int load_block_bitmap(struct super_block *sb,
> -- 
> 1.9.1
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5 linux-next] udf: use sector_t for udf_bitmap_prealloc_blocks() return value

2015-03-13 Thread Jan Kara
On Tue 10-03-15 21:44:32, Fabian Frederick wrote:
> udf_bitmap_prealloc_blocks() can only return positive value and is only
> used to assign sector_t allocated.
  The return value is number of allocated blocks. There's no good reason to
change that to sector_t... The variable 'allocated' in
udf_prealloc_blocks() could be int if anything.

Honza
> 
> Signed-off-by: Fabian Frederick 
> ---
>  fs/udf/balloc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
> index 02948f0..30f4641 100644
> --- a/fs/udf/balloc.c
> +++ b/fs/udf/balloc.c
> @@ -170,7 +170,7 @@ error_return:
>   mutex_unlock(&sbi->s_alloc_mutex);
>  }
>  
> -static int udf_bitmap_prealloc_blocks(struct super_block *sb,
> +static sector_t udf_bitmap_prealloc_blocks(struct super_block *sb,
> struct udf_bitmap *bitmap,
> uint16_t partition, uint32_t first_block,
> uint32_t block_count)
> -- 
> 1.9.1
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-next] udf: remove unused variable in udf_table_free_blocks()

2015-03-13 Thread Jan Kara
On Tue 10-03-15 21:44:31, Fabian Frederick wrote:
> Fix set but not used warning.
> 
> Signed-off-by: Fabian Frederick 
  Thanks. I've added the patch to my tree.

Honza

> ---
>  fs/udf/balloc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
> index 1ba2baa..02948f0 100644
> --- a/fs/udf/balloc.c
> +++ b/fs/udf/balloc.c
> @@ -358,7 +358,6 @@ static void udf_table_free_blocks(struct super_block *sb,
>   struct kernel_lb_addr eloc;
>   struct extent_position oepos, epos;
>   int8_t etype;
> - int i;
>   struct udf_inode_info *iinfo;
>  
>   mutex_lock(&sbi->s_alloc_mutex);
> @@ -425,7 +424,6 @@ static void udf_table_free_blocks(struct super_block *sb,
>   }
>  
>   if (epos.bh != oepos.bh) {
> - i = -1;
>   oepos.block = epos.block;
>   brelse(oepos.bh);
>   get_bh(epos.bh);
> -- 
> 1.9.1
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: Remove mentioning of block barriers

2015-03-13 Thread Jan Kara
On Fri 13-03-15 23:53:22, Leonid V. Fedorenchik wrote:
> Remove mentioning of block barriers since they were removed.
> 
> Signed-off-by: Leonid V. Fedorenchik 
  The change looks fine. It would be nice to at least reference
Documentation/block/writeback_cache_control.txt for description of
REQ_FLUSH and REQ_FUA flags.

Honza
> ---
>  Documentation/block/biodoc.txt | 36 +---
>  1 file changed, 9 insertions(+), 27 deletions(-)
> 
> diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
> index 5aabc08..fd12c0d 100644
> --- a/Documentation/block/biodoc.txt
> +++ b/Documentation/block/biodoc.txt
> @@ -48,8 +48,7 @@ Description of Contents:
>   - Highmem I/O support
>   - I/O scheduler modularization
>1.2 Tuning based on high level requirements/capabilities
> - 1.2.1 I/O Barriers
> - 1.2.2 Request Priority/Latency
> + 1.2.1 Request Priority/Latency
>1.3 Direct access/bypass to lower layers for diagnostics and special
>device operations
>   1.3.1 Pre-built commands
> @@ -255,29 +254,12 @@ some control over i/o ordering.
>  What kind of support exists at the generic block layer for this ?
>  
>  The flags and rw fields in the bio structure can be used for some tuning
> -from above e.g indicating that an i/o is just a readahead request, or for
> -marking  barrier requests (discussed next), or priority settings (currently
> -unused). As far as user applications are concerned they would need an
> -additional mechanism either via open flags or ioctls, or some other upper
> -level mechanism to communicate such settings to block.
> -
> -1.2.1 I/O Barriers
> -
> -There is a way to enforce strict ordering for i/os through barriers.
> -All requests before a barrier point must be serviced before the barrier
> -request and any other requests arriving after the barrier will not be
> -serviced until after the barrier has completed. This is useful for higher
> -level control on write ordering, e.g flushing a log of committed updates
> -to disk before the corresponding updates themselves.
> -
> -A flag in the bio structure, BIO_BARRIER is used to identify a barrier i/o.
> -The generic i/o scheduler would make sure that it places the barrier request 
> and
> -all other requests coming after it after all the previous requests in the
> -queue. Barriers may be implemented in different ways depending on the
> -driver. For more details regarding I/O barriers, please read barrier.txt
> -in this directory.
> -
> -1.2.2 Request Priority/Latency
> +from above e.g indicating that an i/o is just a readahead request, or 
> priority
> +settings (currently unused). As far as user applications are concerned they
> +would need an additional mechanism either via open flags or ioctls, or some
> +other upper level mechanism to communicate such settings to block.
> +
> +1.2.1 Request Priority/Latency
>  
>  Todo/Under discussion:
>  Arjan's proposed request priority scheme allows higher levels some broad
> @@ -906,8 +888,8 @@ queue and specific I/O schedulers.  Unless stated 
> otherwise, elevator is used
>  to refer to both parts and I/O scheduler to specific I/O schedulers.
>  
>  Block layer implements generic dispatch queue in block/*.c.
> -The generic dispatch queue is responsible for properly ordering barrier
> -requests, requeueing, handling non-fs requests and all other subtleties.
> +The generic dispatch queue is responsible for requeueing, handling non-fs
> +requests and all other subtleties.
>  
>  Specific I/O schedulers are responsible for ordering normal filesystem
>  requests.  They can also choose to delay certain requests to improve
> -- 
> 2.2.1
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[Patch 0/5] dt: unittest: fix breakage and warnings

2015-03-13 Thread Frank Rowand
Running checkpatch on early versions of my patchset to fix the devicetree
make dependency issues exposed a large number of warnings, including some that
are actual bugs.  http://lkml.iu.edu/hypermail/linux/kernel/1503.1/03335.html

These patches fix those bugs, and another bug exposed by fixing those bugs.
As a result, the number of tests completed increased from 102 to 107.

Since I was already poking around, I fixed a few classes of checkpatch warnings.

There are still plenty of warnings, but the noise is greatly reduced and future
checkpatch warnings that are problems should stand out more clearly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next 1/2] bpf: allow extended BPF programs access skb fields

2015-03-13 Thread Alexei Starovoitov

On 3/13/15 7:27 PM, Alexei Starovoitov wrote:

On 3/13/15 7:16 PM, Daniel Borkmann wrote:

On 03/14/2015 03:08 AM, Alexei Starovoitov wrote:

On 3/13/15 7:06 PM, Daniel Borkmann wrote:

On 03/14/2015 02:46 AM, Daniel Borkmann wrote:
...

Previously, it was much more consistent, which I like better. And only
because of the simple BUILD_BUG_ON()? :/


Alternative is to move all of them into a central place, something like
in twsk_build_assert() or __mld2_query_bugs[].


nope. that defeats the purpose of bug_on.


Well, it doesn't. ;) It throws a build error thus the user is forced to
investigate that further.


according to this distorted logic all build_bug_on can be in one file
across the whole tree, since 'user is forced to investigate' ?!


also note that this case and twsk_build_assert are different.
twsk_build_assert has no other choice then to have one function
that covers logic in the whole file, whereas in this patch:
+   BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, mark) != 4);
+   *insn++ = BPF_LDX_MEM(BPF_W, dst_reg, src_reg,
+ offsetof(struct sk_buff, mark));

the build_bug_on protect the line directly below.
Separating them just doesn't make sense at all.

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


[PATCH v6 3/3] cgroups: add a pids subsystem

2015-03-13 Thread Aleksa Sarai
Adds a new single-purpose pids subsystem to limit the number of
tasks that can be forked inside a cgroup. Essentially this is an
implementation of RLIMIT_NPROC that will applies to a cgroup rather than
a process tree.

However, it should be noted that organisational operations (adding and
removing tasks from a pids hierarchy) will *not* be prevented. Rather,
the number of tasks in the hierarchy cannot exceed the limit through
forking.

PIDs are fundamentally a global resource, and it is possible to reach
PID exhaustion inside a cgroup without hitting any reasonable kmemcg
policy. Once you've hit PID exhaustion, you're only in a marginally
better state than OOM. This subsystem allows PID exhaustion inside a
cgroup to be prevented.

Signed-off-by: Aleksa Sarai 
---
 include/linux/cgroup_subsys.h |   4 +
 init/Kconfig  |  11 ++
 kernel/Makefile   |   1 +
 kernel/cgroup_pids.c  | 301 ++
 4 files changed, 317 insertions(+)
 create mode 100644 kernel/cgroup_pids.c

diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index e4a96fb..a198822 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -47,6 +47,10 @@ SUBSYS(net_prio)
 SUBSYS(hugetlb)
 #endif
 
+#if IS_ENABLED(CONFIG_CGROUP_PIDS)
+SUBSYS(pids)
+#endif
+
 /*
  * The following subsystems are not supported on the default hierarchy.
  */
diff --git a/init/Kconfig b/init/Kconfig
index f5dbc6d..88364c9 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1054,6 +1054,17 @@ config CGROUP_HUGETLB
  control group is tracked in the third page lru pointer. This means
  that we cannot use the controller with huge page less than 3 pages.
 
+config CGROUP_PIDS
+   bool "Process number limiting on cgroups"
+   help
+ This options enables the setting of process number limits in the scope
+ of a cgroup. Any attempt to fork more processes than is allowed in the
+ cgroup will fail. PIDs are fundamentally a global resource because it
+ is fairly trivial to reach PID exhaustion before you reach even a
+ conservative kmemcg limit. As a result, it is possible to grind a
+ system to halt without being limited by other cgroup policies. The 
pids
+ cgroup subsystem is designed to stop this from happening.
+
 config CGROUP_PERF
bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
depends on PERF_EVENTS && CGROUPS
diff --git a/kernel/Makefile b/kernel/Makefile
index 1408b33..e823592 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o
 obj-$(CONFIG_COMPAT) += compat.o
 obj-$(CONFIG_CGROUPS) += cgroup.o
 obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
+obj-$(CONFIG_CGROUP_PIDS) += cgroup_pids.o
 obj-$(CONFIG_CPUSETS) += cpuset.o
 obj-$(CONFIG_UTS_NS) += utsname.o
 obj-$(CONFIG_USER_NS) += user_namespace.o
diff --git a/kernel/cgroup_pids.c b/kernel/cgroup_pids.c
new file mode 100644
index 000..436e4c7
--- /dev/null
+++ b/kernel/cgroup_pids.c
@@ -0,0 +1,301 @@
+/*
+ * Process number limiting controller for cgroups.
+ *
+ * Used to allow a cgroup hierarchy to stop any new processes
+ * from fork()ing after a certain limit is reached.
+ *
+ * Since it is trivial to hit the task limit without hitting
+ * any kmemcg limits in place, PIDs are a fundamental resource.
+ * As such, PID exhaustion must be preventable in the scope of
+ * a cgroup hierarchy by allowing resource limiting of the
+ * number of tasks in a cgroup.
+ *
+ * In order to use the `pids` controller, set the maximum number
+ * of tasks in pids.max (this is not available in the root cgroup
+ * for obvious reasons). The number of processes currently
+ * in the cgroup is given by pids.current. Organisational operations
+ * are not blocked by cgroup policies, so it is possible to have
+ * pids.current > pids.max. However, fork()s will still not work.
+ *
+ * To set a cgroup to have no limit, set pids.max to "max". fork()
+ * will return -EBUSY if forking would cause a cgroup policy to be
+ * violated.
+ *
+ * pids.current tracks all child cgroup hierarchies, so
+ * parent/pids.current is a superset of parent/child/pids.current.
+ *
+ * Copyright (C) 2015 Aleksa Sarai 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIDS_MAX (PID_MAX_LIMIT + 1ULL)
+#define PIDS_MAX_STR "max"
+
+struct pids_cgroup {
+   struct cgroup_subsys_state  css;
+
+   /*
+* Use 64-bit types so that we can safely represent "max" as
+* (PID_MAX_LIMIT + 1).
+*/
+   atomic64_t  counter;
+   int64_t limit;
+};
+
+static struct pids_cgroup *css_pids(struct cgroup_subsys_state *css)
+{
+   return container_of(css, struct pids_cgroup, css);
+}
+
+static struct pids_cgroup *parent_pids(struct pids_cgroup *pids)
+{
+   return css_pids(pid

[PATCH v6 2/3] cgroups: allow a cgroup subsystem to reject a fork

2015-03-13 Thread Aleksa Sarai
Add a new cgroup subsystem callback can_fork that conditionally
states whether or not the fork is accepted or rejected by a cgroup
policy.

In addition, add a cancel_fork callback so that if an error occurs later
in the forking process, any state modified by can_fork can be reverted.

In order to ensure that the fork charged the right hierarchy, save the
"current" css_set before doing ss->can_fork and compare it with the
"current" css_set that gets committed to the task *proper* in post_fork.
If they do not match, revert the can_fork's charging of the wrong
hierarchy and forcefully reapply it to the right hierarchy using the
reapply_fork callback. Since a changing "current" css_set in
copy_process indicates an organisation operation took place, we can
break the cgroup policy in this case.

This is in preparation for implementing the pids cgroup subsystem.

Signed-off-by: Aleksa Sarai 
---
 include/linux/cgroup.h | 13 ++-
 kernel/cgroup.c| 92 --
 kernel/fork.c  | 18 --
 3 files changed, 117 insertions(+), 6 deletions(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index b9cb94c..9592f6e 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -32,7 +32,9 @@ struct cgroup;
 extern int cgroup_init_early(void);
 extern int cgroup_init(void);
 extern void cgroup_fork(struct task_struct *p);
-extern void cgroup_post_fork(struct task_struct *p);
+extern int cgroup_can_fork(struct task_struct *p, void **state);
+extern void cgroup_cancel_fork(struct task_struct *p, void **state);
+extern void cgroup_post_fork(struct task_struct *p, void **old_state);
 extern void cgroup_exit(struct task_struct *p);
 extern int cgroupstats_build(struct cgroupstats *stats,
struct dentry *dentry);
@@ -649,6 +651,13 @@ struct cgroup_subsys {
  struct cgroup_taskset *tset);
void (*attach)(struct cgroup_subsys_state *css,
   struct cgroup_taskset *tset);
+   int (*can_fork)(struct cgroup_subsys_state *css,
+   struct task_struct *task);
+   void (*cancel_fork)(struct cgroup_subsys_state *css,
+   struct task_struct *task);
+   void (*reapply_fork)(struct cgroup_subsys_state *css,
+struct cgroup_subsys_state *old_css,
+struct task_struct *task);
void (*fork)(struct task_struct *task);
void (*exit)(struct cgroup_subsys_state *css,
 struct cgroup_subsys_state *old_css,
@@ -948,6 +957,8 @@ struct cgroup_subsys_state;
 static inline int cgroup_init_early(void) { return 0; }
 static inline int cgroup_init(void) { return 0; }
 static inline void cgroup_fork(struct task_struct *p) {}
+static inline int cgroup_can_fork(struct task_struct *p) { return 0; }
+static inline void cgroup_cancel_fork(struct task_struct *p) {}
 static inline void cgroup_post_fork(struct task_struct *p) {}
 static inline void cgroup_exit(struct task_struct *p) {}
 
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index d60107e..1a77790 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -183,6 +183,10 @@ static u64 css_serial_nr_next = 1;
  */
 static int need_forkexit_callback __read_mostly;
 
+/* Ditto for the can_fork/cancel_fork/reapply_fork callbacks. */
+static int need_canfork_callback __read_mostly = 0,
+  need_reapplyfork_callback __read_mostly = 0;
+
 static struct cftype cgroup_dfl_base_files[];
 static struct cftype cgroup_legacy_base_files[];
 
@@ -4947,6 +4951,8 @@ static void __init cgroup_init_subsys(struct 
cgroup_subsys *ss, bool early)
init_css_set.subsys[ss->id] = css;
 
need_forkexit_callback |= !!(ss->fork || ss->exit) << ss->id;
+   need_canfork_callback |= !!(ss->can_fork || ss->cancel_fork) << ss->id;
+   need_reapplyfork_callback |= !!(ss->reapply_fork) << ss->id;
 
/* At system boot, before all subsystems have been
 * registered, no tasks have been forked, so we don't
@@ -5200,6 +5206,66 @@ void cgroup_fork(struct task_struct *child)
 }
 
 /**
+ * cgroup_can_fork - called on a new task before the process is exposed.
+ * @child: the task in question.
+ *
+ * This calls the subsystem can_fork() callbacks. If the can_fork() callback
+ * returns an error, the fork aborts with that error code. This allows for
+ * a cgroup subsystem to conditionally allow or deny new forks.
+ */
+int cgroup_can_fork(struct task_struct *child, void **state)
+{
+   struct cgroup_subsys *ss;
+   struct css_set *cset;
+   int i, j, retval;
+
+   cset = task_css_set(current);
+   get_css_set(cset);
+   *state = cset;
+
+   for_each_subsys_which(need_canfork_callback, ss, i)
+   if (ss->can_fork) {
+   retval = ss->can_fork(cset->subsys[i], child);
+   if (retval)
+   goto out_revert;
+

[PATCH v6 1/3] cgroups: use bitmask to filter for_each_subsys

2015-03-13 Thread Aleksa Sarai
Add a new macro for_each_subsys_which that allows all enabled cgroup
subsystems to be filtered by a bitmask, such that mask & (1 << ssid)
determines if the subsystem is to be processed in the loop body (where
ssid is the unique id of the subsystem).

Signed-off-by: Aleksa Sarai 
---
 kernel/cgroup.c | 40 +---
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 29a7b2c..d60107e 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -175,7 +175,8 @@ static DEFINE_IDR(cgroup_hierarchy_idr);
  */
 static u64 css_serial_nr_next = 1;
 
-/* This flag indicates whether tasks in the fork and exit paths should
+/*
+ * This bitmask flag indicates whether tasks in the fork and exit paths should
  * check for fork/exit handlers to call. This avoids us having to do
  * extra work in the fork/exit path if none of the subsystems need to
  * be called.
@@ -409,6 +410,19 @@ static int notify_on_release(const struct cgroup *cgrp)
for ((ssid) = 0; (ssid) < CGROUP_SUBSYS_COUNT &&\
 (((ss) = cgroup_subsys[ssid]) || true); (ssid)++)
 
+/**
+ * for_each_subsys_which - filter for_each_subsys with a bitmask
+ * @ss_mask: the bitmask
+ * @ss: the iteration cursor
+ * @ssid: the index of @ss, CGROUP_SUBSYS_COUNT after reaching the end
+ *
+ * The block will only run for cases where the ssid-th bit (1 << ssid) of
+ * mask is set to 1.
+ */
+#define for_each_subsys_which(ss_mask, ss, ssid) \
+   for_each_subsys((ss), (ssid)) \
+   if ((ss_mask) & (1 << (ssid)))
+
 /* iterate across the hierarchies */
 #define for_each_root(root)\
list_for_each_entry((root), &cgroup_roots, root_list)
@@ -4932,7 +4946,7 @@ static void __init cgroup_init_subsys(struct 
cgroup_subsys *ss, bool early)
 * init_css_set is in the subsystem's root cgroup. */
init_css_set.subsys[ss->id] = css;
 
-   need_forkexit_callback |= ss->fork || ss->exit;
+   need_forkexit_callback |= !!(ss->fork || ss->exit) << ss->id;
 
/* At system boot, before all subsystems have been
 * registered, no tasks have been forked, so we don't
@@ -5239,11 +5253,9 @@ void cgroup_post_fork(struct task_struct *child)
 * css_set; otherwise, @child might change state between ->fork()
 * and addition to css_set.
 */
-   if (need_forkexit_callback) {
-   for_each_subsys(ss, i)
-   if (ss->fork)
-   ss->fork(child);
-   }
+   for_each_subsys_which(need_forkexit_callback, ss, i)
+   if (ss->fork)
+   ss->fork(child);
 }
 
 /**
@@ -5287,15 +5299,13 @@ void cgroup_exit(struct task_struct *tsk)
cset = task_css_set(tsk);
RCU_INIT_POINTER(tsk->cgroups, &init_css_set);
 
-   if (need_forkexit_callback) {
-   /* see cgroup_post_fork() for details */
-   for_each_subsys(ss, i) {
-   if (ss->exit) {
-   struct cgroup_subsys_state *old_css = 
cset->subsys[i];
-   struct cgroup_subsys_state *css = task_css(tsk, 
i);
+   /* see cgroup_post_fork() for details */
+   for_each_subsys_which(need_forkexit_callback, ss, i) {
+   if (ss->exit) {
+   struct cgroup_subsys_state *old_css = cset->subsys[i];
+   struct cgroup_subsys_state *css = task_css(tsk, i);
 
-   ss->exit(css, old_css, tsk);
-   }
+   ss->exit(css, old_css, tsk);
}
}
 
-- 
2.3.2

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


[PATCH v6 0/3] cgroups: add pids subsystem

2015-03-13 Thread Aleksa Sarai
This is a revised version of the pids v5 patchset, modified to deal with
several stylistic and correctness issues put forward by Tejun Heo. The
main changes include:

* Add bitmask filtering of for_each_subsys() in the form of
  for_each_subsys_which().

* Revert all succeeded can_fork() callbacks if any one of them fails
  inside cgroup_can_fork().

* Move revert/reapply code to a reapply_fork() callback provided by each
  cgroup controller. It is only run if the association for the specific
  subsystem changed during the interlude between cgroup_can_fork() and
  cgroup_post_fork().

* Pass an opaque pointer between cgroup_*_fork(), which holds the
  "current" task css_set. The css_set is pinned by bumping the refcount
  in cgroup_can_fork() and later unpinned in
  cgroup_{cancel,post}_fork().

* A whole bunch of userland API and stylistic fixes.

Aleksa Sarai (3):
  cgroups: use bitmask to filter for_each_subsys
  cgroups: allow a cgroup subsystem to reject a fork
  cgroups: add a pids subsystem

 include/linux/cgroup.h|  13 +-
 include/linux/cgroup_subsys.h |   4 +
 init/Kconfig  |  11 ++
 kernel/Makefile   |   1 +
 kernel/cgroup.c   | 132 +++---
 kernel/cgroup_pids.c  | 301 ++
 kernel/fork.c |  18 ++-
 7 files changed, 459 insertions(+), 21 deletions(-)
 create mode 100644 kernel/cgroup_pids.c

-- 
2.3.2

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


Re: [PATCH v2 1/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips

2015-03-13 Thread Guenter Roeck

On 03/09/2015 01:55 PM, Andy Lutomirski wrote:

Sandy Bridge Xeon and Extreme chips have integrated memory
controllers with (rather limited) onboard SMBUS masters.  This
driver gives access to the bus.

There are various groups working on standardizing a way to arbitrate
access to the bus between the OS, SMM firmware, a BMC, hardware
thermal control, etc.  In the mean time, running this driver is
unsafe except under special circumstances.  Nonetheless, this driver
has real users.

As a compromise, the driver will refuse to load unless
i2c_imc.allow_unsafe_access=Y.  When safe access becomes available,
we can leave this option as a way for legacy users to run the
driver, and we'll allow the driver to load by default if safe bus
access is available.

Signed-off-by: Andy Lutomirski 
---
  drivers/i2c/busses/Kconfig   |  17 ++
  drivers/i2c/busses/Makefile  |   1 +
  drivers/i2c/busses/i2c-imc.c | 567 +++
  3 files changed, 585 insertions(+)
  create mode 100644 drivers/i2c/busses/i2c-imc.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index ab838d9e28b6..50e3d79122dd 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -149,6 +149,23 @@ config I2C_ISMT
  This driver can also be built as a module.  If so, the module will be
  called i2c-ismt.

+config I2C_IMC
+   tristate "Intel iMC (LGA 2011) SMBus Controller"
+   depends on PCI && X86
+   help
+ If you say yes to this option, support will be included for the Intel
+ Integrated Memory Controller SMBus host controller interface.  This
+ controller is found on LGA 2011 Xeons and Core i7 Extremes.
+
+ There are currently no systems on which the kernel knows that it can
+ safely enable this driver.  For now, you need to pass this driver a
+ scary module parameter, and you should only pass that parameter if you
+ have a special motherboard and know exactly what you are doing.
+ Special motherboards include the Supermicro X9DRH-iF-NV.
+

I think the current approach of issuing warnings here and in the driver on load
is the wrong one. For the most part, users will just run with distributions.
If a distribution enables the driver, it will end up being used, warning or not.

A much better approach, in my opinion, would be to only enable the driver for
systems where it is known (or presumed) to be good, such as the Supermicro board
mentioned above. This can be done with DMI data.

For other boards, a 'force' module parameter can be added. This would ensure
that the user _has_ to do something manually to load the driver. The warning
on load would then only be displayed if the force module parameter is set.

Having said that, I am still not convinced that the driver should be in the 
kernel
to start with. Browsing through Intel's datasheets, the registers are supported
in E5-2600 v1, v2, and v3. However, in v3 Intel added a note saying that the 
registers
should not be accessed by the OS directly, but only through the bios. Given 
that,
and if that is possible, it might make more sense to rely on ACPI. It would then
be up to the board and/or BIOS vendor to decide if the information should be 
available
to the OS or not.

Thanks,
Guenter

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


Re: [PATCH] axp288_fuel_gauge: Add original author details

2015-03-13 Thread Todd E Brandt
On Fri, Mar 13, 2015 at 09:49:09PM +0530, Ramakrishna Pallala wrote:
> Add the original author details of the axp288_fuel_gauge driver.
> 
Acked-by: Todd Brandt 

> Signed-off-by: Ramakrishna Pallala 
> ---
>  drivers/power/axp288_fuel_gauge.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/power/axp288_fuel_gauge.c 
> b/drivers/power/axp288_fuel_gauge.c
> index c86e709..fc38979 100644
> --- a/drivers/power/axp288_fuel_gauge.c
> +++ b/drivers/power/axp288_fuel_gauge.c
> @@ -1146,6 +1146,7 @@ static struct platform_driver axp288_fuel_gauge_driver 
> = {
>  
>  module_platform_driver(axp288_fuel_gauge_driver);
>  
> +MODULE_AUTHOR("Ramakrishna Pallala ");
>  MODULE_AUTHOR("Todd Brandt ");
>  MODULE_DESCRIPTION("Xpower AXP288 Fuel Gauge Driver");
>  MODULE_LICENSE("GPL");
> -- 
> 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 v5 0/2] ARM: sun9i: Add USB host controller support for A80

2015-03-13 Thread Chen-Yu Tsai
Hi everyone,

This is v5 of my A80 USB support series. v5 addresses some comments
on the phy driver, and adds a patch switching the dts from phy driver
regulator bindings to phy core bindings.


Changes since v4:

  - Fixed copyright date

  - Dropped unused header files

  - Dropped regulator code in the phy driver in favor of phy core
power sequencing code

  - Dropped unneeded dev_set_drvdata()

  - Fixed MODULE_LICENSE to say GPL, matching header

  - Dropped unneeded "select USB_PHY" in Kconfig

  - Mention optional "phy-supply" property in bindings

  - Added "ARM: dts: sun9i: optimus: Switch to phy core regulator
bindings for usb phys"


Regards
ChenYu

Chen-Yu Tsai (2):
  phy: Add driver to support individual USB PHYs on sun9i
  ARM: dts: sun9i: optimus: Switch to phy core regulator bindings for
usb phys

 .../devicetree/bindings/phy/sun9i-usb-phy.txt  |  38 
 arch/arm/boot/dts/sun9i-a80-optimus.dts|   4 +-
 drivers/phy/Kconfig|  11 ++
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-sun9i-usb.c| 202 +
 5 files changed, 254 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
 create mode 100644 drivers/phy/phy-sun9i-usb.c

-- 
2.1.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 v5 2/2] ARM: dts: sun9i: optimus: Switch to phy core regulator bindings for usb phys

2015-03-13 Thread Chen-Yu Tsai
Since the phy core already supports specifying a regulator to handle
during power up/down, it was decided to drop the regulator support
in the sun9i usb phy driver.

This patch switches the DT to the core bindings. This and the phy driver
would be in the same release and should not be a problem as far as DT
stability goes.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts 
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index e53f2656c2d0..c6ca116c59d2 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -203,7 +203,7 @@
 };
 
 &usbphy1 {
-   vbus-supply = <®_usb1_vbus>;
+   phy-supply = <®_usb1_vbus>;
status = "okay";
 };
 
@@ -212,6 +212,6 @@
 };
 
 &usbphy3 {
-   vbus-supply = <®_usb3_vbus>;
+   phy-supply = <®_usb3_vbus>;
status = "okay";
 };
-- 
2.1.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 v5 1/2] phy: Add driver to support individual USB PHYs on sun9i

2015-03-13 Thread Chen-Yu Tsai
Unlike previous Allwinner SoCs, there is no central PHY control block
on the A80. Also, OTG support is completely split off into a different
controller.

This adds a new driver to support the regular USB PHYs.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
---
 .../devicetree/bindings/phy/sun9i-usb-phy.txt  |  38 
 drivers/phy/Kconfig|  11 ++
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-sun9i-usb.c| 202 +
 4 files changed, 252 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
 create mode 100644 drivers/phy/phy-sun9i-usb.c

diff --git a/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt 
b/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
new file mode 100644
index ..1cca85c709d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
@@ -0,0 +1,38 @@
+Allwinner sun9i USB PHY
+---
+
+Required properties:
+- compatible : should be one of
+  * allwinner,sun9i-a80-usb-phy
+- reg : a list of offset + length pairs
+- #phy-cells : from the generic phy bindings, must be 0
+- phy_type : "hsic" for HSIC usage;
+other values or absence of this property indicates normal USB
+- clocks : phandle + clock specifier for the phy clocks
+- clock-names : depending on the "phy_type" property,
+  * "phy" for normal USB
+  * "hsic_480M", "hsic_12M" for HSIC
+- resets : a list of phandle + reset specifier pairs
+- reset-names : depending on the "phy_type" property,
+  * "phy" for normal USB
+  * "hsic" for HSIC
+
+Optional Properties:
+- phy-supply : from the generic phy bindings, a phandle to a regulator that
+  provides power to VBUS.
+
+It is recommended to list all clocks and resets available.
+The driver will only use those matching the phy_type.
+
+Example:
+   usbphy1: phy@00a01800 {
+   compatible = "allwinner,sun9i-a80-usb-phy";
+   reg = <0x00a01800 0x4>;
+   clocks = <&usb_phy_clk 2>, <&usb_phy_clk 10>,
+  <&usb_phy_clk 3>;
+   clock-names = "hsic_480M", "hsic_12M", "phy";
+   resets = <&usb_phy_clk 18>, <&usb_phy_clk 19>;
+   reset-names = "hsic", "phy";
+   status = "disabled";
+   #phy-cells = <0>;
+   };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2962de205ba7..5b08eccc5cc5 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -174,6 +174,17 @@ config PHY_SUN4I_USB
  This driver controls the entire USB PHY block, both the USB OTG
  parts, as well as the 2 regular USB 2 host PHYs.
 
+config PHY_SUN9I_USB
+   tristate "Allwinner sun9i SoC USB PHY driver"
+   depends on ARCH_SUNXI && HAS_IOMEM && OF
+   depends on RESET_CONTROLLER
+   select GENERIC_PHY
+   help
+ Enable this to support the transceiver that is part of Allwinner
+ sun9i SoCs.
+
+ This driver controls each individual USB 2 host PHY.
+
 config PHY_SAMSUNG_USB2
tristate "Samsung USB 2.0 PHY driver"
depends on HAS_IOMEM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f080e1bb2a74..ab8f9af540a2 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
 obj-$(CONFIG_PHY_EXYNOS5250_SATA)  += phy-exynos5250-sata.o
 obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
 obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
+obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o
 obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
 phy-exynos-usb2-y  += phy-samsung-usb2.o
 phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4210_USB2)  += phy-exynos4210-usb2.o
diff --git a/drivers/phy/phy-sun9i-usb.c b/drivers/phy/phy-sun9i-usb.c
new file mode 100644
index ..0095914a662c
--- /dev/null
+++ b/drivers/phy/phy-sun9i-usb.c
@@ -0,0 +1,202 @@
+/*
+ * Allwinner sun9i USB phy driver
+ *
+ * Copyright (C) 2014-2015 Chen-Yu Tsai 
+ *
+ * Based on phy-sun4i-usb.c from
+ * Hans de Goede 
+ *
+ * and code from
+ * Allwinner Technology Co., Ltd. 
+ *
+ * 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.
+ *
+ * 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 
+
+#define SUNXI_AHB_INCR16_BURST_EN  BIT(11)
+#define SUNXI_AHB_INCR8_BURST_EN   BIT(10)
+#define SUNXI_AHB_INCR4_BURST_EN   

[PATCHv4] [media] saa7164: use an MSI interrupt when available

2015-03-13 Thread Brendan McGrath
Enhances driver to use an MSI interrupt when available.

Adds the module option 'enable_msi' (type bool) which by default is
enabled. Can be set to 'N' to disable.

Fixes (or can reduce the occurrence of) a crash which is most commonly
reported when both digital tuners of the saa7164 chip is in use. A reported 
example can
be found here:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/83948

Reviewed-by: Steven Toth 
Signed-off-by: Brendan McGrath 
---
Changes since v3:
  - fixes a conflict with a commit (3f845f3c4cf4) made to the media_tree after 
v3 was created (only the unified context has been changed)
  - corrected comments to reflect that the reported incident occured more 
commonly when multiple tuners were in use (not multiple saa7164 chips as 
previously stated)


 drivers/media/pci/saa7164/saa7164-core.c | 40 ++--
 drivers/media/pci/saa7164/saa7164.h  |  1 +
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/saa7164/saa7164-core.c 
b/drivers/media/pci/saa7164/saa7164-core.c
index 9cf3c6c..7635598 100644
--- a/drivers/media/pci/saa7164/saa7164-core.c
+++ b/drivers/media/pci/saa7164/saa7164-core.c
@@ -85,6 +85,11 @@ module_param(guard_checking, int, 0644);
 MODULE_PARM_DESC(guard_checking,
"enable dma sanity checking for buffer overruns");
 
+static bool enable_msi = true;
+module_param(enable_msi, bool, 0444);
+MODULE_PARM_DESC(enable_msi,
+   "enable the use of an msi interrupt if available");
+
 static unsigned int saa7164_devcount;
 
 static DEFINE_MUTEX(devlist);
@@ -1230,8 +1235,34 @@ static int saa7164_initdev(struct pci_dev *pci_dev,
goto fail_irq;
}
 
-   err = request_irq(pci_dev->irq, saa7164_irq,
-   IRQF_SHARED, dev->name, dev);
+   /* irq bit */
+   if (enable_msi)
+   err = pci_enable_msi(pci_dev);
+
+   if (!err && enable_msi) {
+   /* no error - so request an msi interrupt */
+   err = request_irq(pci_dev->irq, saa7164_irq, 0,
+ dev->name, dev);
+
+   if (err) {
+   /* fall back to legacy interrupt */
+   printk(KERN_ERR "%s() Failed to get an MSI interrupt."
+  " Falling back to a shared IRQ\n", __func__);
+   pci_disable_msi(pci_dev);
+   } else {
+   dev->msi = true;
+   }
+   }
+
+   if ((!enable_msi) || err) {
+   dev->msi = false;
+   /* if we have an error (i.e. we don't have an interrupt)
+or msi is not enabled - fallback to shared interrupt */
+
+   err = request_irq(pci_dev->irq, saa7164_irq,
+ IRQF_SHARED, dev->name, dev);
+   }
+
if (err < 0) {
printk(KERN_ERR "%s: can't get IRQ %d\n", dev->name,
pci_dev->irq);
@@ -1439,6 +1470,11 @@ static void saa7164_finidev(struct pci_dev *pci_dev)
/* unregister stuff */
free_irq(pci_dev->irq, dev);
 
+   if (dev->msi) {
+   pci_disable_msi(pci_dev);
+   dev->msi = false;
+   }
+
pci_disable_device(pci_dev);
 
mutex_lock(&devlist);
diff --git a/drivers/media/pci/saa7164/saa7164.h 
b/drivers/media/pci/saa7164/saa7164.h
index cd1a07c..6df4b252 100644
--- a/drivers/media/pci/saa7164/saa7164.h
+++ b/drivers/media/pci/saa7164/saa7164.h
@@ -459,6 +459,7 @@ struct saa7164_dev {
/* Interrupt status and ack registers */
u32 int_status;
u32 int_ack;
+   u32 msi;
 
struct cmd  cmds[SAA_CMD_MAX_MSG_UNITS];
struct mutexlock;
-- 
1.9.1

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


Commit 0e32b39c ("drm/i915: add DP 1.2 MST support (v0.7)") breaking DP audio on T440s

2015-03-13 Thread Paul Moore
Ever since v3.17 I've had a problem with displayport audio on my
system, but until lately I haven't had a chance to bisect the problem.
After a few rounds I've isolated the buggy commit to 0e32b39c
("drm/i915: add DP 1.2 MST support (v0.7)").

Simply put, prior to v3.17 everything worked correctly: audio from my
system was routed to my monitor via the DP connection and finally out
to the speakers connected to the monitor.  However, starting with
kernel v3.17 this no longer works.  The various PulseAudio tools all
indicate that the HDMI/DP audio output is unplugged/not-available.
I've tried a few different xrandr commands found via google and
manpages but nothing short of reverting to v3.16 solves the problem.
I'm hoping that someone with more understanding of the Intel graphics
drivers will be able to make some sense of it all and provide a fix.
I'm more than happy to provide additional information and test any
patches you may have.

For reference, my system is a ThinkPad T440s with a "Intel Corporation
Haswell-ULT Integrated Graphics Controller (rev 0b)" (according to
lspci) connected to a Dell U3011 via a Gefen DP KVM.

-Paul

-- 
paul moore
www.paul-moore.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 2/2] selftests/timers: change to use shared logic to run and install tests

2015-03-13 Thread John Stultz
On Fri, Mar 13, 2015 at 3:57 PM, Shuah Khan  wrote:
> Change the timers Makefile to make use of shared run and install
> logic in lib.mk. Destructive tests are installed. Regular tests
> are emited to run_kselftest script to match the run_tests behavior.
>
> Signed-off-by: Shuah Khan 
> ---
>  tools/testing/selftests/timers/Makefile | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/tools/testing/selftests/timers/Makefile 
> b/tools/testing/selftests/timers/Makefile
> index 9da3498..61e7284 100644
> --- a/tools/testing/selftests/timers/Makefile
> +++ b/tools/testing/selftests/timers/Makefile
> @@ -7,19 +7,21 @@ bins = posix_timers nanosleep inconsistency-check 
> nsleep-lat raw_skew \
> alarmtimer-suspend change_skew skew_consistency clocksource-switch \
> leap-a-day leapcrash set-tai set-2038
>
> +TEST_PROGS = posix_timers nanosleep nsleep-lat set-timer-lat mqueue-lat \
> +   inconsistency-check raw_skew
> +TEST_FILES = threadtest alarmtimer-suspend valid-adjtimex change_skew \
> +   skew_consistency clocksource-switch leap-a-day leapcrash \
> +   set-tai set-2038
> +
> +RUN_TESTS_WITH_ARGS := ./threadtest -t 30 -n 8 || echo "selftests: 
> threadtest [FAIL]"
> +
> +EMIT_TESTS_WITH_ARGS := echo "$(RUN_TESTS_WITH_ARGS)"
> +

So my make-foo isn't very strong, but no objections from me.

My only thoughts:
1) Would it be better if threadtest can be made to have better
defaults for kselftest so you don't need that extra logic?
2) While I get that TEST_FILES is likely going to be used to copy the
destructive tests over, It feels a little like its being bundled in
with something like data files that tests might need, which seems sort
of hackish. Would TEST_PROGS_EXTENDED or something be more clear and
make more sense?

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


Re: [PATCH v3 1/7] x86, kaslr: Use init_size instead of run_size

2015-03-13 Thread Yinghai Lu
On Fri, Mar 13, 2015 at 5:27 AM, Ingo Molnar  wrote:
>
> * Yinghai Lu  wrote:
>
>> commit e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
>> introduced one run_size for kaslr.
>> We should use real runtime size (include copy/decompress) aka init_size.
>
> Why, what happens if we don't change this?

While trying to update change log, found we still need to keep this run_size.
otherwise kaslr will find not needed big size of init_size instead of
max(output_len, run_size).

will refresh the patchset.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next 1/2] bpf: allow extended BPF programs access skb fields

2015-03-13 Thread Alexei Starovoitov

On 3/13/15 7:16 PM, Daniel Borkmann wrote:

On 03/14/2015 03:08 AM, Alexei Starovoitov wrote:

On 3/13/15 7:06 PM, Daniel Borkmann wrote:

On 03/14/2015 02:46 AM, Daniel Borkmann wrote:
...

Previously, it was much more consistent, which I like better. And only
because of the simple BUILD_BUG_ON()? :/


Alternative is to move all of them into a central place, something like
in twsk_build_assert() or __mld2_query_bugs[].


nope. that defeats the purpose of bug_on.


Well, it doesn't. ;) It throws a build error thus the user is forced to
investigate that further.


according to this distorted logic all build_bug_on can be in one file
across the whole tree, since 'user is forced to investigate' ?!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next 1/2] bpf: allow extended BPF programs access skb fields

2015-03-13 Thread Daniel Borkmann

On 03/14/2015 03:08 AM, Alexei Starovoitov wrote:

On 3/13/15 7:06 PM, Daniel Borkmann wrote:

On 03/14/2015 02:46 AM, Daniel Borkmann wrote:
...

Previously, it was much more consistent, which I like better. And only
because of the simple BUILD_BUG_ON()? :/


Alternative is to move all of them into a central place, something like
in twsk_build_assert() or __mld2_query_bugs[].


nope. that defeats the purpose of bug_on.


Well, it doesn't. ;) It throws a build error thus the user is forced to
investigate that further.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next 1/2] bpf: allow extended BPF programs access skb fields

2015-03-13 Thread Alexei Starovoitov

On 3/13/15 7:06 PM, Daniel Borkmann wrote:

On 03/14/2015 02:46 AM, Daniel Borkmann wrote:
...

Previously, it was much more consistent, which I like better. And only
because of the simple BUILD_BUG_ON()? :/


Alternative is to move all of them into a central place, something like
in twsk_build_assert() or __mld2_query_bugs[].


nope. that defeats the purpose of bug_on.
It needs to be next the code it's actually trying to protect.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next 1/2] bpf: allow extended BPF programs access skb fields

2015-03-13 Thread Alexei Starovoitov

On 3/13/15 6:46 PM, Daniel Borkmann wrote:

On 03/13/2015 07:57 PM, Alexei Starovoitov wrote:

introduce user accessible mirror of in-kernel 'struct sk_buff':
struct __sk_buff {
 __u32 len;
 __u32 pkt_type;
 __u32 mark;
 __u32 queue_mapping;
};

bpf programs can do:

int bpf_prog(struct __sk_buff *skb)
{
 __u32 var = skb->pkt_type;

which will be compiled to bpf assembler as:

dst_reg = *(u32 *)(src_reg + 4) // 4 == offsetof(struct __sk_buff,
pkt_type)

bpf verifier will check validity of access and will convert it to:

dst_reg = *(u8 *)(src_reg + offsetof(struct sk_buff, __pkt_type_offset))
dst_reg &= 7

since skb->pkt_type is a bitfield.

Signed-off-by: Alexei Starovoitov 

...

+static u32 convert_skb_access(int skb_field, int dst_reg, int src_reg,
+  struct bpf_insn *insn_buf)
+{
+struct bpf_insn *insn = insn_buf;
+
+switch (skb_field) {
+case SKF_AD_MARK:
+BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, mark) != 4);
+
+*insn++ = BPF_LDX_MEM(BPF_W, dst_reg, src_reg,
+  offsetof(struct sk_buff, mark));
+break;
+
+case SKF_AD_PKTTYPE:
+*insn++ = BPF_LDX_MEM(BPF_B, dst_reg, src_reg,
PKT_TYPE_OFFSET());
+*insn++ = BPF_ALU32_IMM(BPF_AND, dst_reg, PKT_TYPE_MAX);
+#ifdef __BIG_ENDIAN_BITFIELD
+*insn++ = BPF_ALU32_IMM(BPF_RSH, dst_reg, 5);
+#endif
+break;
+
+case SKF_AD_QUEUE:
+BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, queue_mapping) != 2);
+
+*insn++ = BPF_LDX_MEM(BPF_H, dst_reg, src_reg,
+  offsetof(struct sk_buff, queue_mapping));
+break;
+}
+
+return insn - insn_buf;
+}
+
  static bool convert_bpf_extensions(struct sock_filter *fp,
 struct bpf_insn **insnp)
  {
  struct bpf_insn *insn = *insnp;
+u32 cnt;

  switch (fp->k) {
  case SKF_AD_OFF + SKF_AD_PROTOCOL:
@@ -167,13 +200,8 @@ static bool convert_bpf_extensions(struct
sock_filter *fp,
  break;

  case SKF_AD_OFF + SKF_AD_PKTTYPE:
-*insn++ = BPF_LDX_MEM(BPF_B, BPF_REG_A, BPF_REG_CTX,
-  PKT_TYPE_OFFSET());
-*insn = BPF_ALU32_IMM(BPF_AND, BPF_REG_A, PKT_TYPE_MAX);
-#ifdef __BIG_ENDIAN_BITFIELD
-insn++;
-*insn = BPF_ALU32_IMM(BPF_RSH, BPF_REG_A, 5);
-#endif
+cnt = convert_skb_access(SKF_AD_PKTTYPE, BPF_REG_A,
BPF_REG_CTX, insn);
+insn += cnt - 1;
  break;

  case SKF_AD_OFF + SKF_AD_IFINDEX:
@@ -197,10 +225,8 @@ static bool convert_bpf_extensions(struct
sock_filter *fp,
  break;

  case SKF_AD_OFF + SKF_AD_MARK:
-BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, mark) != 4);
-
-*insn = BPF_LDX_MEM(BPF_W, BPF_REG_A, BPF_REG_CTX,
-offsetof(struct sk_buff, mark));
+cnt = convert_skb_access(SKF_AD_MARK, BPF_REG_A, BPF_REG_CTX,
insn);
+insn += cnt - 1;
  break;

  case SKF_AD_OFF + SKF_AD_RXHASH:
@@ -211,10 +237,8 @@ static bool convert_bpf_extensions(struct
sock_filter *fp,
  break;

  case SKF_AD_OFF + SKF_AD_QUEUE:
-BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, queue_mapping) != 2);
-
-*insn = BPF_LDX_MEM(BPF_H, BPF_REG_A, BPF_REG_CTX,
-offsetof(struct sk_buff, queue_mapping));
+cnt = convert_skb_access(SKF_AD_QUEUE, BPF_REG_A,
BPF_REG_CTX, insn);
+insn += cnt - 1;
  break;

  case SKF_AD_OFF + SKF_AD_VLAN_TAG:
@@ -1147,13 +1171,55 @@ sk_filter_func_proto(enum bpf_func_id func_id)

...

+static u32 sk_filter_convert_ctx_access(int dst_reg, int src_reg, int
ctx_off,
+struct bpf_insn *insn_buf)
+{
+struct bpf_insn *insn = insn_buf;
+
+switch (ctx_off) {
+case offsetof(struct __sk_buff, len):
+BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
+
+*insn++ = BPF_LDX_MEM(BPF_W, dst_reg, src_reg,
+  offsetof(struct sk_buff, len));
+break;
+
+case offsetof(struct __sk_buff, mark):
+return convert_skb_access(SKF_AD_MARK, dst_reg, src_reg, insn);
+
+case offsetof(struct __sk_buff, pkt_type):
+return convert_skb_access(SKF_AD_PKTTYPE, dst_reg, src_reg,
insn);
+
+case offsetof(struct __sk_buff, queue_mapping):
+return convert_skb_access(SKF_AD_QUEUE, dst_reg, src_reg, insn);
+}
+
+return insn - insn_buf;
  }


Hmm, I actually liked the previous version much better. :(

Now, some members use convert_skb_access() and some skb members are
converted directly in-place in both, convert_bpf_extensions() _and_
in sk_filter_convert_ctx_access().

Previously, it was much more consistent, which I like better. And only
because of the simple BUILD_BUG_ON()? :/


not because of single build_bug_on, but because of having
a single place to adjust offsets and sizes when location of
sk_buff fields changes. that's the main advantage and it's a big one.
imo it's much cleaner than previous approach.


--
To unsubscribe fro

Re: [PATCH v2 net-next 1/2] bpf: allow extended BPF programs access skb fields

2015-03-13 Thread Daniel Borkmann

On 03/14/2015 02:46 AM, Daniel Borkmann wrote:
...

Previously, it was much more consistent, which I like better. And only
because of the simple BUILD_BUG_ON()? :/


Alternative is to move all of them into a central place, something like
in twsk_build_assert() or __mld2_query_bugs[].
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Hello Dear Friend!I

2015-03-13 Thread kabiru wahid
Hello Dear Friend!,

It is my wish to solicit your assistance in a claim of $15.5 USD, this
is genuine claim that will be of great benefit for both of us, and i
cannot achieve it without the support of a foreigner, therefore, i
need your cooperation to Claim This fund is from diseased customer who
died without declaring his beneficiary/next of kinafter Which Will
you be Entitle to 40% of the Fund while 60% will be mine. Please get
back to Me if you are Interested for More details.

 Kind Regards,
Mr. Kabiru Wahid
kabiruwah...@terra.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 v2 net-next 1/2] bpf: allow extended BPF programs access skb fields

2015-03-13 Thread Daniel Borkmann

On 03/13/2015 07:57 PM, Alexei Starovoitov wrote:

introduce user accessible mirror of in-kernel 'struct sk_buff':
struct __sk_buff {
 __u32 len;
 __u32 pkt_type;
 __u32 mark;
 __u32 queue_mapping;
};

bpf programs can do:

int bpf_prog(struct __sk_buff *skb)
{
 __u32 var = skb->pkt_type;

which will be compiled to bpf assembler as:

dst_reg = *(u32 *)(src_reg + 4) // 4 == offsetof(struct __sk_buff, pkt_type)

bpf verifier will check validity of access and will convert it to:

dst_reg = *(u8 *)(src_reg + offsetof(struct sk_buff, __pkt_type_offset))
dst_reg &= 7

since skb->pkt_type is a bitfield.

Signed-off-by: Alexei Starovoitov 

...

+static u32 convert_skb_access(int skb_field, int dst_reg, int src_reg,
+ struct bpf_insn *insn_buf)
+{
+   struct bpf_insn *insn = insn_buf;
+
+   switch (skb_field) {
+   case SKF_AD_MARK:
+   BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, mark) != 4);
+
+   *insn++ = BPF_LDX_MEM(BPF_W, dst_reg, src_reg,
+ offsetof(struct sk_buff, mark));
+   break;
+
+   case SKF_AD_PKTTYPE:
+   *insn++ = BPF_LDX_MEM(BPF_B, dst_reg, src_reg, 
PKT_TYPE_OFFSET());
+   *insn++ = BPF_ALU32_IMM(BPF_AND, dst_reg, PKT_TYPE_MAX);
+#ifdef __BIG_ENDIAN_BITFIELD
+   *insn++ = BPF_ALU32_IMM(BPF_RSH, dst_reg, 5);
+#endif
+   break;
+
+   case SKF_AD_QUEUE:
+   BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, queue_mapping) != 2);
+
+   *insn++ = BPF_LDX_MEM(BPF_H, dst_reg, src_reg,
+ offsetof(struct sk_buff, queue_mapping));
+   break;
+   }
+
+   return insn - insn_buf;
+}
+
  static bool convert_bpf_extensions(struct sock_filter *fp,
   struct bpf_insn **insnp)
  {
struct bpf_insn *insn = *insnp;
+   u32 cnt;

switch (fp->k) {
case SKF_AD_OFF + SKF_AD_PROTOCOL:
@@ -167,13 +200,8 @@ static bool convert_bpf_extensions(struct sock_filter *fp,
break;

case SKF_AD_OFF + SKF_AD_PKTTYPE:
-   *insn++ = BPF_LDX_MEM(BPF_B, BPF_REG_A, BPF_REG_CTX,
- PKT_TYPE_OFFSET());
-   *insn = BPF_ALU32_IMM(BPF_AND, BPF_REG_A, PKT_TYPE_MAX);
-#ifdef __BIG_ENDIAN_BITFIELD
-   insn++;
-*insn = BPF_ALU32_IMM(BPF_RSH, BPF_REG_A, 5);
-#endif
+   cnt = convert_skb_access(SKF_AD_PKTTYPE, BPF_REG_A, 
BPF_REG_CTX, insn);
+   insn += cnt - 1;
break;

case SKF_AD_OFF + SKF_AD_IFINDEX:
@@ -197,10 +225,8 @@ static bool convert_bpf_extensions(struct sock_filter *fp,
break;

case SKF_AD_OFF + SKF_AD_MARK:
-   BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, mark) != 4);
-
-   *insn = BPF_LDX_MEM(BPF_W, BPF_REG_A, BPF_REG_CTX,
-   offsetof(struct sk_buff, mark));
+   cnt = convert_skb_access(SKF_AD_MARK, BPF_REG_A, BPF_REG_CTX, 
insn);
+   insn += cnt - 1;
break;

case SKF_AD_OFF + SKF_AD_RXHASH:
@@ -211,10 +237,8 @@ static bool convert_bpf_extensions(struct sock_filter *fp,
break;

case SKF_AD_OFF + SKF_AD_QUEUE:
-   BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, queue_mapping) != 2);
-
-   *insn = BPF_LDX_MEM(BPF_H, BPF_REG_A, BPF_REG_CTX,
-   offsetof(struct sk_buff, queue_mapping));
+   cnt = convert_skb_access(SKF_AD_QUEUE, BPF_REG_A, BPF_REG_CTX, 
insn);
+   insn += cnt - 1;
break;

case SKF_AD_OFF + SKF_AD_VLAN_TAG:
@@ -1147,13 +1171,55 @@ sk_filter_func_proto(enum bpf_func_id func_id)

...

+static u32 sk_filter_convert_ctx_access(int dst_reg, int src_reg, int ctx_off,
+   struct bpf_insn *insn_buf)
+{
+   struct bpf_insn *insn = insn_buf;
+
+   switch (ctx_off) {
+   case offsetof(struct __sk_buff, len):
+   BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
+
+   *insn++ = BPF_LDX_MEM(BPF_W, dst_reg, src_reg,
+ offsetof(struct sk_buff, len));
+   break;
+
+   case offsetof(struct __sk_buff, mark):
+   return convert_skb_access(SKF_AD_MARK, dst_reg, src_reg, insn);
+
+   case offsetof(struct __sk_buff, pkt_type):
+   return convert_skb_access(SKF_AD_PKTTYPE, dst_reg, src_reg, 
insn);
+
+   case offsetof(struct __sk_buff, queue_mapping):
+   return convert_skb_access(SKF_AD_QUEUE, dst_reg, src_reg, insn);
+   }
+
+   return insn - insn_buf;
  }


Hmm, I actually liked the previous version much better. :(

Now, some members use convert_skb_access() and some skb members are
converted directly in-place in both, convert_bpf_extensions() _and_
in sk_f

[PATCH] selftests: Fix kcmp build to not require headers install

2015-03-13 Thread Shuah Khan
Change CFLAGS to look in uapi to allow kcmp to be built without
requiring headers install. This will make it easier to run tests
without going through the headers install step.

Signed-off-by: Shuah Khan 
---
 tools/testing/selftests/kcmp/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kcmp/Makefile 
b/tools/testing/selftests/kcmp/Makefile
index ff0eefd..d405ad4 100644
--- a/tools/testing/selftests/kcmp/Makefile
+++ b/tools/testing/selftests/kcmp/Makefile
@@ -1,5 +1,5 @@
 CC := $(CROSS_COMPILE)$(CC)
-CFLAGS += -I../../../../usr/include/
+CFLAGS += -I../../../../include/uapi -I../../../../usr/include/
 
 all: kcmp_test
 
-- 
2.1.0

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


[PATCH] selftests: Fix build failures when invoked from kselftest target

2015-03-13 Thread Shuah Khan
Several tests that rely on implicit build rules fail to build,
when invoked from the main Makefile kselftest target. These
failures are due to --no-builtin-rules and --no-builtin-variables
options set in the inherited MAKEFLAGS.

--no-builtin-rules eliminates the use of built-in implicit rules
and --no-builtin-variables is for not defining built-in variables.
These two options override the use of implicit rules resulting in
build failures. In addition, inherited LDFLAGS result in build
failures and there is no need to define LDFLAGS.  Clear LDFLAGS
and MAKEFLAG when make is invoked from the main Makefile kselftest
target. Fixing this at selftests Makefile avoids changing the main
Makefile and keeps this change self contained at selftests level.

Signed-off-by: Shuah Khan 
---
 tools/testing/selftests/Makefile | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 4e51122..8e09db7 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -22,6 +22,15 @@ TARGETS += vm
 TARGETS_HOTPLUG = cpu-hotplug
 TARGETS_HOTPLUG += memory-hotplug
 
+# Clear LDFLAGS and MAKEFLAGS if called from main
+# Makefile to avoid test build failures when test
+# Makefile doesn't have explicit build rules.
+ifeq (1,$(MAKELEVEL))
+undefine LDFLAGS
+override define MAKEFLAGS =
+endef
+endif
+
 all:
for TARGET in $(TARGETS); do \
make -C $$TARGET; \
-- 
2.1.0

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


[PATCH] cpqarray: simplify bitops usages

2015-03-13 Thread Akinobu Mita
Remove unnecessary adjustment for bit number and address of bitmask.
This change just simplifies the code a bit.

Signed-off-by: Akinobu Mita 
Cc: Don Brace 
Cc: iss_storage...@hp.com
---
 drivers/block/cpqarray.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/block/cpqarray.c b/drivers/block/cpqarray.c
index 2b94403..34dde22 100644
--- a/drivers/block/cpqarray.c
+++ b/drivers/block/cpqarray.c
@@ -422,8 +422,8 @@ static int cpqarray_register_ctlr(int i, struct pci_dev 
*pdev)
hba[i]->cmd_pool = pci_alloc_consistent(
hba[i]->pci_dev, NR_CMDS * sizeof(cmdlist_t),
&(hba[i]->cmd_pool_dhandle));
-   hba[i]->cmd_pool_bits = kcalloc(
-   DIV_ROUND_UP(NR_CMDS, BITS_PER_LONG), sizeof(unsigned long),
+   hba[i]->cmd_pool_bits = kcalloc(BITS_TO_LONGS(NR_CMDS),
+   sizeof(unsigned long),
GFP_KERNEL);
 
if (!hba[i]->cmd_pool_bits || !hba[i]->cmd_pool)
@@ -1373,7 +1373,7 @@ static cmdlist_t * cmd_alloc(ctlr_info_t *h, int 
get_from_pool)
i = find_first_zero_bit(h->cmd_pool_bits, NR_CMDS);
if (i == NR_CMDS)
return NULL;
-   } while(test_and_set_bit(i&(BITS_PER_LONG-1), 
h->cmd_pool_bits+(i/BITS_PER_LONG)) != 0);
+   } while (test_and_set_bit(i, h->cmd_pool_bits) != 0);
c = h->cmd_pool + i;
cmd_dhandle = h->cmd_pool_dhandle + i*sizeof(cmdlist_t);
h->nr_allocs++;
@@ -1393,7 +1393,7 @@ static void cmd_free(ctlr_info_t *h, cmdlist_t *c, int 
got_from_pool)
c->busaddr);
} else {
i = c - h->cmd_pool;
-   clear_bit(i&(BITS_PER_LONG-1), 
h->cmd_pool_bits+(i/BITS_PER_LONG));
+   clear_bit(i, h->cmd_pool_bits);
h->nr_frees++;
}
 }
-- 
1.9.1

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


[PATCH] hpsa: cleanup bitops usage

2015-03-13 Thread Akinobu Mita
Remove unnecessary adjustment for bit number and address of bitmask,
and use BITS_TO_LONGS macro to calculate bitmap size.  This change
just simplifies the code a bit.

Signed-off-by: Akinobu Mita 
Cc: Don Brace 
Cc: iss_storage...@hp.com
Cc: storage...@pmcs.com
Cc: "James E.J. Bottomley" 
Cc: linux-s...@vger.kernel.org
---
 drivers/scsi/hpsa.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index a1cfbd3..73a282b 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -4697,8 +4697,7 @@ static struct CommandList *cmd_alloc(struct ctlr_info *h)
offset = (i + 1) % h->nr_cmds;
continue;
}
-   set_bit(i & (BITS_PER_LONG - 1),
-   h->cmd_pool_bits + (i / BITS_PER_LONG));
+   set_bit(i, h->cmd_pool_bits);
break; /* it's ours now. */
}
h->last_allocation = i; /* benignly racy */
@@ -4729,8 +4728,7 @@ static void cmd_free(struct ctlr_info *h, struct 
CommandList *c)
int i;
 
i = c - h->cmd_pool;
-   clear_bit(i & (BITS_PER_LONG - 1),
- h->cmd_pool_bits + (i / BITS_PER_LONG));
+   clear_bit(i, h->cmd_pool_bits);
}
 }
 
@@ -6410,8 +6408,7 @@ out_disable:
 
 static int hpsa_allocate_cmd_pool(struct ctlr_info *h)
 {
-   h->cmd_pool_bits = kzalloc(
-   DIV_ROUND_UP(h->nr_cmds, BITS_PER_LONG) *
+   h->cmd_pool_bits = kcalloc(BITS_TO_LONGS(h->nr_cmds),
sizeof(unsigned long), GFP_KERNEL);
h->cmd_pool = pci_alloc_consistent(h->pdev,
h->nr_cmds * sizeof(*h->cmd_pool),
-- 
1.9.1

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


[PATCH] pktcdvd: convert char array to bitmap

2015-03-13 Thread Akinobu Mita
The written[] array in pkt_gather_data() can be converted to bitmap.
It can reduce stack usage and simplify the code a bit.

Signed-off-by: Akinobu Mita 
Cc: Jiri Kosina 
---
 drivers/block/pktcdvd.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 09e628da..1aff5ca 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -1019,7 +1019,7 @@ static void pkt_gather_data(struct pktcdvd_device *pd, 
struct packet_data *pkt)
int frames_read = 0;
struct bio *bio;
int f;
-   char written[PACKET_MAX_SIZE];
+   DECLARE_BITMAP(written, PACKET_MAX_SIZE);
 
BUG_ON(bio_list_empty(&pkt->orig_bios));
 
@@ -1029,7 +1029,7 @@ static void pkt_gather_data(struct pktcdvd_device *pd, 
struct packet_data *pkt)
/*
 * Figure out which frames we need to read before we can write.
 */
-   memset(written, 0, sizeof(written));
+   bitmap_zero(written, PACKET_MAX_SIZE);
spin_lock(&pkt->lock);
bio_list_for_each(bio, &pkt->orig_bios) {
int first_frame = (bio->bi_iter.bi_sector - pkt->sector) /
@@ -1038,8 +1038,7 @@ static void pkt_gather_data(struct pktcdvd_device *pd, 
struct packet_data *pkt)
pd->stats.secs_w += num_frames * (CD_FRAMESIZE >> 9);
BUG_ON(first_frame < 0);
BUG_ON(first_frame + num_frames > pkt->frames);
-   for (f = first_frame; f < first_frame + num_frames; f++)
-   written[f] = 1;
+   bitmap_set(written, first_frame, num_frames);
}
spin_unlock(&pkt->lock);
 
@@ -1052,12 +1051,9 @@ static void pkt_gather_data(struct pktcdvd_device *pd, 
struct packet_data *pkt)
/*
 * Schedule reads for missing parts of the packet.
 */
-   for (f = 0; f < pkt->frames; f++) {
+   for_each_clear_bit(f, written, pkt->frames) {
int p, offset;
 
-   if (written[f])
-   continue;
-
bio = pkt->r_bios[f];
bio_reset(bio);
bio->bi_iter.bi_sector = pkt->sector + f * (CD_FRAMESIZE >> 9);
-- 
1.9.1

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


[PATCH] ia64: Use bitmap_weight

2015-03-13 Thread Akinobu Mita
Use bitmap_weight to count the total number of bits set in bitmap.
This change just simplifies the code a bit.

Signed-off-by: Akinobu Mita 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-i...@vger.kernel.org
---
 arch/ia64/hp/common/sba_iommu.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index 344387a..9c944fa 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -33,7 +33,7 @@
 #include 
 #include 
 #include 
-#include  /* hweight64() */
+#include  /* bitmap_weight() */
 #include 
 #include 
 #include 
@@ -1901,8 +1901,7 @@ static int
 ioc_show(struct seq_file *s, void *v)
 {
struct ioc *ioc = v;
-   unsigned long *res_ptr = (unsigned long *)ioc->res_map;
-   int i, used = 0;
+   int used;
 
seq_printf(s, "Hewlett Packard %s IOC rev %d.%d\n",
ioc->name, ((ioc->rev >> 4) & 0xF), (ioc->rev & 0xF));
@@ -1913,8 +1912,8 @@ ioc_show(struct seq_file *s, void *v)
seq_printf(s, "IOVA size   : %ld MB\n", ((ioc->pdir_size >> 3) * 
iovp_size)/(1024*1024));
seq_printf(s, "IOVA page size  : %ld kb\n", iovp_size/1024);
 
-   for (i = 0; i < (ioc->res_size / sizeof(unsigned long)); ++i, ++res_ptr)
-   used += hweight64(*res_ptr);
+   used = bitmap_weight((unsigned long *)ioc->res_map,
+   ioc->res_size * BITS_PER_BYTE);
 
seq_printf(s, "PDIR size   : %d entries\n", ioc->pdir_size >> 3);
seq_printf(s, "PDIR used   : %d entries\n", used);
-- 
1.9.1

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


[PATCH] drbd: use bitmap_weight()

2015-03-13 Thread Akinobu Mita
Use bitmap_weight to count the total number of bits set in bitmap.
This change just simplifies the code a bit.

Signed-off-by: Akinobu Mita 
Cc: Philipp Reisner 
Cc: Lars Ellenberg 
Cc: drbd-...@lists.linbit.com
---
 drivers/block/drbd/drbd_bitmap.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/block/drbd/drbd_bitmap.c b/drivers/block/drbd/drbd_bitmap.c
index 434c77d..39d31af 100644
--- a/drivers/block/drbd/drbd_bitmap.c
+++ b/drivers/block/drbd/drbd_bitmap.c
@@ -24,7 +24,7 @@
 
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -559,21 +559,19 @@ static unsigned long bm_count_bits(struct drbd_bitmap *b)
unsigned long *p_addr;
unsigned long bits = 0;
unsigned long mask = (1UL << (b->bm_bits & BITS_PER_LONG_MASK)) -1;
-   int idx, i, last_word;
+   int idx, last_word;
 
/* all but last page */
for (idx = 0; idx < b->bm_number_of_pages - 1; idx++) {
p_addr = __bm_map_pidx(b, idx);
-   for (i = 0; i < LWPP; i++)
-   bits += hweight_long(p_addr[i]);
+   bits += bitmap_weight(p_addr, PAGE_SIZE * BITS_PER_BYTE);
__bm_unmap(p_addr);
cond_resched();
}
/* last (or only) page */
last_word = ((b->bm_bits - 1) & BITS_PER_PAGE_MASK) >> LN2_BPL;
p_addr = __bm_map_pidx(b, idx);
-   for (i = 0; i < last_word; i++)
-   bits += hweight_long(p_addr[i]);
+   bits += bitmap_weight(p_addr, last_word * BITS_PER_LONG);
p_addr[last_word] &= cpu_to_lel(mask);
bits += hweight_long(p_addr[last_word]);
/* 32bit arch, may have an unused padding long */
@@ -1424,15 +1422,12 @@ int drbd_bm_clear_bits(struct drbd_device *device, 
const unsigned long s, const
 static inline void bm_set_full_words_within_one_page(struct drbd_bitmap *b,
int page_nr, int first_word, int last_word)
 {
-   int i;
-   int bits;
-   int changed = 0;
unsigned long *paddr = kmap_atomic(b->bm_pages[page_nr]);
-   for (i = first_word; i < last_word; i++) {
-   bits = hweight_long(paddr[i]);
-   paddr[i] = ~0UL;
-   changed += BITS_PER_LONG - bits;
-   }
+   int nbits = (last_word - first_word) * BITS_PER_LONG;
+   int changed;
+
+   changed = nbits - bitmap_weight(paddr + first_word, nbits);
+   bitmap_fill(paddr + first_word, nbits);
kunmap_atomic(paddr);
if (changed) {
/* We only need lazy writeout, the information is still in the
@@ -1637,8 +1632,7 @@ int drbd_bm_e_weight(struct drbd_device *device, unsigned 
long enr)
int n = e-s;
p_addr = bm_map_pidx(b, bm_word_to_page_idx(b, s));
bm = p_addr + MLPP(s);
-   while (n--)
-   count += hweight_long(*bm++);
+   count = bitmap_weight(bm, n * BITS_PER_LONG);
bm_unmap(p_addr);
} else {
drbd_err(device, "start offset (%d) too large in 
drbd_bm_e_weight\n", s);
-- 
1.9.1

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


Re: [PATCH 0/6] CLONE_FD: Task exit notification via file descriptor

2015-03-13 Thread Thiago Macieira
On Friday 13 March 2015 14:51:47 Andy Lutomirski wrote:
> In any event, we should find out what FreeBSD does in response to
> read(2) on the fd.

I've just successfully installed FreeBSD and compiled qtbase (main package of 
Qt 5) on it.

I'll test pdfork during the weekend and report its behaviour.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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


[PATCH] include/linux: fix checkpatch issues

2015-03-13 Thread Valentina-Camelia Bojan
Fix checkpatch issues of the following type:
* ERROR: "foo * bar" should be "foo *bar"
* WARNING: space prohibited between function name and open parenthesis 
'('

Signed-off-by: Valentina-Camelia Bojan 
---
 include/linux/acpi.h | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 24c7aa8..2f16a08 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -115,15 +115,15 @@ static inline void acpi_initrd_override(void *data, 
size_t size)
(!entry) || (unsigned long)entry + sizeof(*entry) > end ||  \
((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
 
-char * __acpi_map_table (unsigned long phys_addr, unsigned long size);
+char *__acpi_map_table(unsigned long phys_addr, unsigned long size);
 void __acpi_unmap_table(char *map, unsigned long size);
 int early_acpi_boot_init(void);
-int acpi_boot_init (void);
-void acpi_boot_table_init (void);
-int acpi_mps_check (void);
-int acpi_numa_init (void);
+int acpi_boot_init(void);
+void acpi_boot_table_init(void);
+int acpi_mps_check(void);
+int acpi_numa_init(void);
 
-int acpi_table_init (void);
+int acpi_table_init(void);
 int acpi_table_parse(char *id, acpi_tbl_table_handler handler);
 int __init acpi_parse_entries(char *id, unsigned long table_size,
  acpi_tbl_entry_handler handler,
@@ -136,14 +136,14 @@ int __init acpi_table_parse_entries(char *id, unsigned 
long table_size,
 int acpi_table_parse_madt(enum acpi_madt_type id,
  acpi_tbl_entry_handler handler,
  unsigned int max_entries);
-int acpi_parse_mcfg (struct acpi_table_header *header);
-void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
+int acpi_parse_mcfg(struct acpi_table_header *header);
+void acpi_table_print_madt_entry(struct acpi_subtable_header *madt);
 
 /* the following four functions are architecture-dependent */
-void acpi_numa_slit_init (struct acpi_table_slit *slit);
-void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
+void acpi_numa_slit_init(struct acpi_table_slit *slit);
+void acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa);
 void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
-int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
+int acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma);
 void acpi_numa_arch_fixup(void);
 
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
@@ -166,9 +166,9 @@ extern u32 acpi_irq_not_handled;
 extern int sbf_port;
 extern unsigned long acpi_realmode_flags;
 
-int acpi_register_gsi (struct device *dev, u32 gsi, int triggering, int 
polarity);
-int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
-int acpi_isa_irq_to_gsi (unsigned isa_irq, u32 *gsi);
+int acpi_register_gsi(struct device *dev, u32 gsi, int triggering, int 
polarity);
+int acpi_gsi_to_irq(u32 gsi, unsigned int *irq);
+int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi);
 
 #ifdef CONFIG_X86_IO_APIC
 extern int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity);
@@ -180,14 +180,14 @@ extern int acpi_get_override_irq(u32 gsi, int *trigger, 
int *polarity);
  * If this matches the last registration, any IRQ resources for gsi
  * are freed.
  */
-void acpi_unregister_gsi (u32 gsi);
+void acpi_unregister_gsi(u32 gsi);
 
 struct pci_dev;
 
-int acpi_pci_irq_enable (struct pci_dev *dev);
+int acpi_pci_irq_enable(struct pci_dev *dev);
 void acpi_penalize_isa_irq(int irq, int active);
 
-void acpi_pci_irq_disable (struct pci_dev *dev);
+void acpi_pci_irq_disable(struct pci_dev *dev);
 
 extern int ec_read(u8 addr, u8 *val);
 extern int ec_write(u8 addr, u8 val);
-- 
1.9.1

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


[PATCH] ARM: dts: rockchip: disable gmac by default in rk3288.dtsi

2015-03-13 Thread Alexandru M Stan
This block should not be enabled by default or else if the kconfig is set,
it will try to load/probe even if there's no phy connected.

Signed-off-by: Alexandru M Stan 
---
 arch/arm/boot/dts/rk3288.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index d771f68..eccc78d 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -411,6 +411,7 @@
"mac_clk_rx", "mac_clk_tx",
"clk_mac_ref", "clk_mac_refout",
"aclk_mac", "pclk_mac";
+   status = "disabled";
};
 
usb_host0_ehci: usb@ff50 {
-- 
2.2.0.rc0.207.ga3a616c

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


[PATCH 0/1] ARM: dts: rockchip: disable gmac by default in rk3288.dtsi

2015-03-13 Thread Alexandru M Stan
The way it is right now, each board using rk3288.dtsi has to disable
it or else (given CONFIG_DWMAC_RK is set) it will try loading the driver
and looking for phy's even though none are connected.

The status should be "disabled".

PS: I'm ok with "the big relicensing"
(http://www.spinics.net/lists/arm-kernel/msg403629.html) to GPLv2/X11.


Alexandru M Stan (1):
  ARM: dts: rockchip: disable gmac by default in rk3288.dtsi

 arch/arm/boot/dts/rk3288.dtsi | 1 +
 1 file changed, 1 insertion(+)

-- 
2.2.0.rc0.207.ga3a616c

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


Re: [PATCH 3/4] workqueue: Create low-level unbound workqueues cpumask

2015-03-13 Thread Kevin Hilman
Kevin Hilman  writes:

> Lai Jiangshan  writes:
>
>> From: Frederic Weisbecker 
>>
>> Create a cpumask that limit the affinity of all unbound workqueues.
>> This cpumask is controlled though a file at the root of the workqueue
>> sysfs directory.
>>
>> It works on a lower-level than the per WQ_SYSFS workqueues cpumask files
>> such that the effective cpumask applied for a given unbound workqueue is
>> the intersection of /sys/devices/virtual/workqueue/$WORKQUEUE/cpumask and
>> the new /sys/devices/virtual/workqueue/cpumask_unbounds file.
>>
>> This patch implements the basic infrastructure and the read interface.
>> cpumask_unbounds is initially set to cpu_possible_mask.
>>
>> Cc: Christoph Lameter 
>> Cc: Kevin Hilman 
>> Cc: Lai Jiangshan 
>> Cc: Mike Galbraith 
>> Cc: Paul E. McKenney 
>> Cc: Tejun Heo 
>> Cc: Viresh Kumar 
>> Signed-off-by: Frederic Weisbecker 
>> Signed-off-by: Lai Jiangshan 
>
> [...]
>
>> @@ -5094,6 +5116,9 @@ static int __init init_workqueues(void)
>>  
>>  WARN_ON(__alignof__(struct pool_workqueue) < __alignof__(long long));
>>  
>> +BUG_ON(!alloc_cpumask_var(&wq_unbound_cpumask, GFP_KERNEL));
>> +cpumask_copy(wq_unbound_cpumask, cpu_possible_mask);
>> +
>
> As I mentioned in an earlier discussion[1], I still think this could
> default too the housekeeping CPUs in the NO_HZ_FULL case:
>
> #ifdef CONFIG_NO_HZ_FULL
>   cpumask_complement(wq_unbound_cpumask, tick_nohz_full_mask);
> #else
>   cpumask_copy(wq_unbound_cpumask, cpu_possible_mask);
> #endif
>
> But that could also be left to a future optimization as well.

I meant to add:

Acked-by: Kevin Hilman 

as well, as the NO_HZ_FULL bit could be added as an add-on patch.

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


Re: [patch 1/2] mm, mempool: poison elements backed by slab allocator

2015-03-13 Thread David Rientjes
On Thu, 12 Mar 2015, Andrew Morton wrote:

> > Mempools keep elements in a reserved pool for contexts in which
> > allocation may not be possible.  When an element is allocated from the
> > reserved pool, its memory contents is the same as when it was added to
> > the reserved pool.
> > 
> > Because of this, elements lack any free poisoning to detect
> > use-after-free errors.
> > 
> > This patch adds free poisoning for elements backed by the slab allocator.
> > This is possible because the mempool layer knows the object size of each
> > element.
> > 
> > When an element is added to the reserved pool, it is poisoned with
> > POISON_FREE.  When it is removed from the reserved pool, the contents are
> > checked for POISON_FREE.  If there is a mismatch, a warning is emitted to
> > the kernel log.
> > 
> > This is only effective for configs with CONFIG_DEBUG_VM.
> 
> At present CONFIG_DEBUG_VM is pretty lightweight (I hope) and using it
> for mempool poisoning might be inappropriately costly.  Would it be
> better to tie this to something else?  Either standalone or reuse some
> slab debug option, perhaps.
> 

Ok, I agree.  I'll use CONFIG_DEBUG_SLAB and CONFIG_SLUB_DEBUG_ON and 
allow it to be enabled by slub debugging when that is enabled.  It 
probably doesn't make a lot of sense to do mempool poisoning without slab 
poisoning.

> Did you measure the overhead btw?  It might be significant with fast
> devices.
> 

It's certainly costly: with a new 128-byte slab cache, allocating 64 
objects took about 480 cycles longer per object to do the poison checking 
and in-use poisoning on one of my 2.2GHz machines (~90 cycles/object 
without CONFIG_DEBUG_VM).  To do the free poisoning, it was about ~130 
cycles longer per object (~140 cycles/object without CONFIG_DEBUG_VM).

For cache cold pages from the page allocator, it's more expensive, 
allocating and freeing 64 pages, it's ~620 cycles longer per page and 
freeing is an additional ~60 cycles/page.

Keep in mind that overhead is only incurred when the mempool alloc 
function fails to allocate memory directly from the slab allocator or page 
allocator in the given context and on mempool_create() to create the new 
mempool.

I didn't benchmark high-order page poisoning, but that's only used by 
bcache and I'm looking at that separately: allocating high-order pages 
from a mempool sucks.

> > --- a/mm/mempool.c
> > +++ b/mm/mempool.c
> > @@ -16,16 +16,77 @@
> >  #include 
> >  #include 
> >  
> > +#ifdef CONFIG_DEBUG_VM
> > +static void poison_error(mempool_t *pool, void *element, size_t size,
> > +size_t byte)
> > +{
> > +   const int nr = pool->curr_nr;
> > +   const int start = max_t(int, byte - (BITS_PER_LONG / 8), 0);
> > +   const int end = min_t(int, byte + (BITS_PER_LONG / 8), size);
> > +   int i;
> > +
> > +   pr_err("BUG: mempool element poison mismatch\n");
> > +   pr_err("Mempool %p size %ld\n", pool, size);
> > +   pr_err(" nr=%d @ %p: %s0x", nr, element, start > 0 ? "... " : "");
> > +   for (i = start; i < end; i++)
> > +   pr_cont("%x ", *(u8 *)(element + i));
> > +   pr_cont("%s\n", end < size ? "..." : "");
> > +   dump_stack();
> > +}
> 
> "byte" wasn't a very useful identifier, and it's called "i" in
> check_slab_element().  Rename it to "offset" in both places?
> 
> > +static void check_slab_element(mempool_t *pool, void *element)
> > +{
> > +   if (pool->free == mempool_free_slab || pool->free == mempool_kfree) {
> > +   size_t size = ksize(element);
> > +   u8 *obj = element;
> > +   size_t i;
> > +
> > +   for (i = 0; i < size; i++) {
> > +   u8 exp = (i < size - 1) ? POISON_FREE : POISON_END;
> > +
> > +   if (obj[i] != exp) {
> > +   poison_error(pool, element, size, i);
> > +   return;
> > +   }
> > +   }
> > +   memset(obj, POISON_INUSE, size);
> > +   }
> > +}
> 
> I question the reuse of POISON_FREE/POISON_INUSE.  If this thing
> triggers, it may be hard to tell if it was due to a slab thing or to a
> mempool thing.  Using a distinct poison pattern for mempool would clear
> that up?
> 

Hmm, I think it would actually make it more confusing: mempools only 
allocate from the reserved pool (those poisoned by this patchset) when 
doing kmalloc() or kmem_cache_free() in context fails.  Normally, the 
reserved pool isn't used because there are free objects sitting on slab 
free or partial slabs and the context is irrelevant.  If slab poisoning is 
enabled, they are already POISON_FREE as anticipated.  We only fallback to 
the reserved pool when new slab needs to be allocated and fails in the 
given context, so the poison value would differ depending on where the 
objects came from.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.htm

Re: + lib-vsprintfc-even-faster-decimal-conversion.patch added to -mm tree

2015-03-13 Thread Rasmus Villemoes
On Fri, Mar 13 2015, Alexey Dobriyan  wrote:

> On Thu, Mar 12, 2015 at 12:54 AM,   wrote:
>> Subject: lib/vsprintf.c: even faster binary to decimal conversion
>
> I spent some time to microbenchmark changes in userspace (audience: fool!).
> Results are below.
>
> Legend is "number avg+-1sigma min-max". Every number is CPU cycles.
> Great care was taken to remove interrupt noise.
>
> Number of measurements is 100 millions per line.
> CPU is Intel Core 2 Duo E6550 in 64-bit mode.
>
> 3.19.1:
>
> 0 98.015369 +- 0.512937   91-616
> 42   116.000193 +- 3.523826  112-868
> 27182137.009008 +- 3.515725  133-1043
> 65535137.008262 +- 3.521761  133-840
> 4294967295   201.019966 +- 3.278608  196-1050
> 3141592653589793238  289.996882 +- 3.489376  287-1148
> 18446744073709551615 295.065274 +- 2.860187  287-1029
> -
> 3.19.1+patch
> 0 94.444063 +- 3.518922   84-630
> 42   116.428533 +- 18.539093 105-1036
> 42   116.316904 +- 18.234484 105-833
> 27182136.172398 +- 3.737113  133-980
> 65535136.014742 +- 3.537882  133-714
> 4294967295   172.009618 +- 3.507473  168-826
> 3141592653589793238  207.001114 +- 3.492724  196-1120
> 18446744073709551615 208.018154 +- 3.220185  203-1246
> -

This seems to measure lfence+rdtsc overhead more than anything else. On
my presumably rather similar Core2 Duo T5870, I get an average of 22
cycles for the old code and 11 cycles for the new when converting 42 two
million times in a loop, and I'm not even trying to take interrupts into
account.

Since you seem to be dirtying 800 MB of memory, I'm guessing you get
quite a few page faults/TLB misses, which might explain the rather huge
max numbers.

> New code is somewhat faster for huge numbers.
> But top and ps don't show huge numbers normally --
> it is either PIDs (2^16) or moderately high numbers in a range of millions
> (see /proc/stat)

I said much the same thing in the commit log, and accordingly I've done
(micro)benchmarks with distributions biased to various degrees towards
smaller numbers, all of which showed 25+% improvement.

> * variance for new code is bigger

Seems to depend on how you measure...

> I even tried N=42 twice because I thought 18.5 variance is a glitch
> but it is not.

That does seem odd. But I think your numbers are caused by the huge
memory use. In any case, I modified my test program to record the
cycle count for each individual call (using lfence+rdtsc), but I used a
frequency table instead of a gigantic array, ignoring excessively large
cycle counts (I used > 1023). On the Core 2, I then get

90 90 90 80 80 80 80 80 80 80 80 80 90 80 80
Distribution  Function cycles/conv  std.dev. (ignored) 
uniform([10, 2^64-1]) linux_put_dec  224.83 9.80 (156)
uniform([10, 2^64-1]) rv_put_dec 147.87 7.44 (86)
3 + neg_binom(0.05)   linux_put_dec  138.9739.48 (87)
3 + neg_binom(0.05)   rv_put_dec 123.7627.33 (77)
3 + neg_binom(0.10)   linux_put_dec  115.4927.27 (84)
3 + neg_binom(0.10)   rv_put_dec 108.2220.14 (71)
3 + neg_binom(0.15)   linux_put_dec  105.2120.52 (59)
3 + neg_binom(0.15)   rv_put_dec 101.7517.21 (54)
3 + neg_binom(0.20)   linux_put_dec  100.7917.25 (65)
3 + neg_binom(0.20)   rv_put_dec  98.3416.22 (64)
3 + neg_binom(0.50)   linux_put_dec   87.84 7.75 (44)
3 + neg_binom(0.50)   rv_put_dec  85.37 8.26 (45)

[first line is just deltas between a few lfence+rdtsc reads in quick
succession, to get a sense of the overhead]. For each distribution I'm
generating 2048 random numbers and then iterate over that 1000 times. So
almost none of the ~2M observations are being ignored. Here, the new
code is always faster (but computing a percentage from numbers including
the rdtsc overhead is meaningless), and in all but the last case (where
the numbers are almost exclusively 2-digit) the std. deviation is also
smaller. An an Intel Xeon, I get

48 32 32 32 32 32 32 32 32 32 32 32 32 32 32
Distribution  Function cycles/conv  std.dev. (ignored) 
uniform([10, 2^64-1]) linux_put_dec  152.58 8.54 (26)
uniform([10, 2^64-1]) rv_put_dec  89.33 3.02 (16)
3 + neg_binom(0.05)   linux_put_dec   91.8834.46 (17)
3 + neg_binom(0.05)   rv_put_dec  71.5921.19 (10)
3 + neg_binom(0.10)   linux_put_dec   72.5025.30 (12)
3 + neg_binom(0.10)   rv_put_dec  60.1017.51 (11)
3 + neg_binom(0.15)   linux_put_dec   63.8120.68 (8)
3 + neg_binom(0.15)   rv_put_dec  55.5715.74 (6)
3 + neg_binom(0.20)

Re: [PATCH 3/4] workqueue: Create low-level unbound workqueues cpumask

2015-03-13 Thread Kevin Hilman
Lai Jiangshan  writes:

> From: Frederic Weisbecker 
>
> Create a cpumask that limit the affinity of all unbound workqueues.
> This cpumask is controlled though a file at the root of the workqueue
> sysfs directory.
>
> It works on a lower-level than the per WQ_SYSFS workqueues cpumask files
> such that the effective cpumask applied for a given unbound workqueue is
> the intersection of /sys/devices/virtual/workqueue/$WORKQUEUE/cpumask and
> the new /sys/devices/virtual/workqueue/cpumask_unbounds file.
>
> This patch implements the basic infrastructure and the read interface.
> cpumask_unbounds is initially set to cpu_possible_mask.
>
> Cc: Christoph Lameter 
> Cc: Kevin Hilman 
> Cc: Lai Jiangshan 
> Cc: Mike Galbraith 
> Cc: Paul E. McKenney 
> Cc: Tejun Heo 
> Cc: Viresh Kumar 
> Signed-off-by: Frederic Weisbecker 
> Signed-off-by: Lai Jiangshan 

[...]

> @@ -5094,6 +5116,9 @@ static int __init init_workqueues(void)
>  
>   WARN_ON(__alignof__(struct pool_workqueue) < __alignof__(long long));
>  
> + BUG_ON(!alloc_cpumask_var(&wq_unbound_cpumask, GFP_KERNEL));
> + cpumask_copy(wq_unbound_cpumask, cpu_possible_mask);
> +

As I mentioned in an earlier discussion[1], I still think this could
default too the housekeeping CPUs in the NO_HZ_FULL case:

#ifdef CONFIG_NO_HZ_FULL
cpumask_complement(wq_unbound_cpumask, tick_nohz_full_mask);
#else
cpumask_copy(wq_unbound_cpumask, cpu_possible_mask);
#endif

But that could also be left to a future optimization as well.

Kevin

[1] https://lkml.org/lkml/2014/2/14/666
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs/pstore/ram.c: Fix the ramoops module parameters update

2015-03-13 Thread Kees Cook
On Mon, Mar 9, 2015 at 12:39 AM, Wang Long  wrote:
> In the function ramoops_probe, the console_size, pmsg_size,
> ftrace_size may be update because the value is not the power
> of two. We should update the module parameter variables
> as well so they are visible through /sys/module/ramoops/parameters
> correctly.
>
> Signed-off-by: Wang Long 
> ---
>  fs/pstore/ram.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 5df325e..1aaa8dc 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -559,6 +559,9 @@ pr_info("[%s] pstore_register", __func__);
> mem_address = pdata->mem_address;
> record_size = pdata->record_size;
> dump_oops = pdata->dump_oops;
> +   ramoops_console_size = pdata->console_size;
> +   ramoops_pmsg_size = pdata->pmsg_size;
> +   ramoops_ftrace_size = pdata->ftrace_size;
>
> pr_info("attached 0x%lx@0x%llx, ecc: %d/%d\n",
> cxt->size, (unsigned long long)cxt->phys_addr,

I swear this had been fixed before. Thanks for catching it!

Acked-by: Kees Cook 

-Kees

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



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


Re: [PATCH V5] Allow compaction of unevictable pages

2015-03-13 Thread Rik van Riel
On 03/13/2015 07:18 PM, David Rientjes wrote:
> On Fri, 13 Mar 2015, Eric B Munson wrote:
> 
 --- a/mm/compaction.c
 +++ b/mm/compaction.c
 @@ -1046,6 +1046,8 @@ typedef enum {
ISOLATE_SUCCESS,/* Pages isolated, migrate */
  } isolate_migrate_t;
  
 +int sysctl_compact_unevictable;
 +
  /*
   * Isolate all pages that can be migrated from the first suitable block,
   * starting at the block pointed to by the migrate scanner pfn within
>>>
>>> I suspect that the use cases where users absolutely do not want
>>> unevictable pages migrated are special cases, and it may make
>>> sense to enable sysctl_compact_unevictable by default.
>>
>> Given that sysctl_compact_unevictable=0 is the way the kernel behaves
>> now and the push back against always enabling compaction on unevictable
>> pages, I left the default to be the behavior as it is today.  I agree
>> that this is likely the minority case, but I'd really like Peter Z or
>> someone else from real time to say that they are okay with the default
>> changing.
>>
> 
> It would be really disappointing to not enable this by default for !rt 
> kernels.  We haven't migrated mlocked pages in the past by way of memory 
> compaction because it can theoretically result in consistent minor page 
> faults, but I haven't yet heard a !rt objection to enabling this.
> 
> If the rt patchset is going to carry a patch to disable this

It does not have to carry a patch to disable something that can be
disabled at run time.

The smaller the realtime patchset has to be, the better.

-- 
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] checkpatch: match more world writable permissions

2015-03-13 Thread Joe Perches
Currently checkpatch will fuss if one uses world writable
settings in debugfs files and DEVICE_ATTR uses by testing
S_IWUGO but not testing S_IWOTH, S_IRWXUGO or S_IALLUGO.

Extend the check to catch all cases exporting world writable
permissions including octal values.

Original-patch-by: Nicholas Mc Guire 
Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 6b79beb..4f07d50 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -443,6 +443,14 @@ foreach my $entry (@mode_permission_funcs) {
$mode_perms_search .= $entry->[0];
 }
 
+$our $mode_perms_world_writable = qr{
+   S_IWUGO |
+   S_IWOTH |
+   S_IRWXUGO   |
+   S_IALLUGO   |
+   0[0-7][0-7][2367]
+}x;
+
 our $allowed_asm_includes = qr{(?x:
irq|
memory|
@@ -5356,8 +5364,8 @@ sub process {
}
}
 
-   if ($line =~ /debugfs_create_file.*S_IWUGO/ ||
-   $line =~ /DEVICE_ATTR.*S_IWUGO/ ) {
+   if ($line =~ 
/debugfs_create_\w+.*\b$mode_perms_world_writable\b/ ||
+   $line =~ /DEVICE_ATTR.*\b$mode_perms_world_writable\b/) {
WARN("EXPORTED_WORLD_WRITABLE",
 "Exporting world writable files is usually an 
error. Consider more restrictive permissions.\n" . $herecurr);
}


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


Re: [PATCH v3 1/2] remoteproc: use a flag to detect the presence of IOMMU

2015-03-13 Thread Suman Anna
On 03/12/2015 04:04 AM, Ohad Ben-Cohen wrote:
> On Fri, Jan 9, 2015 at 11:21 PM, Suman Anna  wrote:
>> The remoteproc driver core currently relies on iommu_present() on
>> the bus the device is on, to perform MMU management. However, this
>> logic doesn't scale for multi-arch, especially for processors that
>> do not have an IOMMU. Replace this logic instead by using a h/w
>> capability flag for the presence of IOMMU in the rproc structure.
>>
>> This issue is seen on OMAP platforms when trying to add a remoteproc
>> driver for a small Cortex M3 called the WkupM3 used for suspend /
>> resume management on TI AM335/AM437x SoCs. This processor does not
>> have an MMU. Same is the case with another processor subsystem
>> PRU-ICSS on AM335/AM437x. All these are platform devices, and the
>> current iommu_present check will not scale for the same kernel image
>> to support OMAP4/OMAP5 and AM335/AM437x.
>>
>> The existing platform implementation drivers - OMAP remoteproc, STE
>> Modem remoteproc and DA8xx remoteproc, are updated as well to properly
>> configure the newly added rproc field.
>>
>> Cc: Robert Tivy 
>> Cc: Linus Walleij 
>> Signed-off-by: Suman Anna 
> 
> Applied to remoteproc's for-next branch.
> 

Thanks Ohad. Can you pick up the minor checkpatch fixes I posted as well
for 4.1?

regards
Suman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: panel: change struct bits to a bit array

2015-03-13 Thread Isaac Lleida
This path implements a bit array representing the LCD signal states instead of 
the old "struct bits", which used char to represent a single bit. This will 
reduce the memory usage.

Signed-off-by: Isaac Lleida >= 1;
@@ -814,7 +826,7 @@ static void lcd_backlight(int on)
 
/* The backlight is activated by setting the AUTOFEED line to +5V  */
spin_lock_irq(&pprt_lock);
-   bits.bl = on;
+   BIT_MOD(bits, LCD_BIT_BL_MASK, on);
panel_set_bits();
spin_unlock_irq(&pprt_lock);
 }
@@ -849,14 +861,14 @@ static void lcd_write_cmd_p8(int cmd)
w_dtr(pprt, cmd);
udelay(20); /* maintain the data during 20 us before the strobe */
 
-   bits.e = BIT_SET;
-   bits.rs = BIT_CLR;
-   bits.rw = BIT_CLR;
+   BIT_ON(bits, LCD_BIT_E_MASK);
+   BIT_ON(bits, LCD_BIT_RS_MASK);
+   BIT_OFF(bits, LCD_BIT_RW_MASK);
set_ctrl_bits();
 
udelay(40); /* maintain the strobe during 40 us */
 
-   bits.e = BIT_CLR;
+   BIT_OFF(bits, LCD_BIT_E_MASK);
set_ctrl_bits();
 
udelay(120);/* the shortest command takes at least 120 us */
@@ -871,14 +883,14 @@ static void lcd_write_data_p8(int data)
w_dtr(pprt, data);
udelay(20); /* maintain the data during 20 us before the strobe */
 
-   bits.e = BIT_SET;
-   bits.rs = BIT_SET;
-   bits.rw = BIT_CLR;
+   BIT_ON(bits, LCD_BIT_E_MASK);
+   BIT_ON(bits, LCD_BIT_RS_MASK);
+   BIT_OFF(bits, LCD_BIT_RW_MASK);
set_ctrl_bits();
 
udelay(40); /* maintain the strobe during 40 us */
 
-   bits.e = BIT_CLR;
+   BIT_OFF(bits, LCD_BIT_E_MASK);
set_ctrl_bits();
 
udelay(45); /* the shortest data takes at least 45 us */
@@ -968,15 +980,15 @@ static void lcd_clear_fast_p8(void)
/* maintain the data during 20 us before the strobe */
udelay(20);
 
-   bits.e = BIT_SET;
-   bits.rs = BIT_SET;
-   bits.rw = BIT_CLR;
+   BIT_ON(bits, LCD_BIT_E_MASK);
+   BIT_OFF(bits, LCD_BIT_RS_MASK);
+   BIT_OFF(bits, LCD_BIT_RW_MASK);
set_ctrl_bits();
 
/* maintain the strobe during 40 us */
udelay(40);
 
-   bits.e = BIT_CLR;
+   BIT_OFF(bits, LCD_BIT_E_MASK);
set_ctrl_bits();
 
/* the shortest data takes at least 45 us */
-- 
2.3.2

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


[PATCH 4/4] drm/msm/mdp5: Enable DSI connector in msm drm driver

2015-03-13 Thread Hai Li
This change adds the support in mdp5 kms driver for single
and dual DSI. Dual DSI case depends on the framework API
and sequence change to support dual data path.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |   4 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  11 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 268 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  69 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  12 +-
 drivers/gpu/drm/msm/msm_drv.c   |   2 +
 6 files changed, 353 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 6c467fb..2c9a9dc 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -68,6 +68,8 @@ const struct mdp5_cfg_hw msm8x74_config = {
},
.intfs = {
[0] = INTF_eDP,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
[3] = INTF_HDMI,
},
.max_clk = 2,
@@ -125,6 +127,8 @@ const struct mdp5_cfg_hw apq8084_config = {
},
.intfs = {
[0] = INTF_eDP,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
[3] = INTF_HDMI,
},
.max_clk = 32000,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 9b38cde..f877e1d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -626,7 +626,16 @@ void mdp5_crtc_set_intf(struct drm_crtc *crtc, struct 
mdp5_interface *intf)
 
/* now that we know what irq's we want: */
mdp5_crtc->err.irqmask = intf2err(intf->num);
-   mdp5_crtc->vblank.irqmask = intf2vblank(lm, intf);
+
+   /* Register command mode Pingpong done as vblank for now,
+* so that atomic commit should wait for it to finish.
+* Ideally, in the future, we should take rd_ptr done as vblank,
+* and let atomic commit wait for pingpong done for commond mode.
+*/
+   if (intf->mode == MDP5_INTF_DSI_MODE_COMMAND)
+   mdp5_crtc->vblank.irqmask = lm2ppdone(lm);
+   else
+   mdp5_crtc->vblank.irqmask = intf2vblank(lm, intf);
mdp_irq_update(&mdp5_kms->base);
 
mdp5_ctl_set_intf(mdp5_crtc->ctl, intf);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index a17eb9c..efe7aaf 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -98,6 +98,221 @@ static void bs_fini(struct mdp5_encoder *mdp5_encoder) {}
 static void bs_set(struct mdp5_encoder *mdp5_encoder, int idx) {}
 #endif
 
+/*
+ * Command mode encoder, used by DSI command mode path.
+ * Should move to a separate file, once global bandwidth
+ * functions are available.
+ */
+#define VSYNC_CLK_RATE 1920
+static int pingpong_tearcheck_setup(struct drm_encoder *encoder,
+   struct drm_display_mode *mode)
+{
+   struct mdp5_kms *mdp5_kms = get_kms(encoder);
+   struct device *dev = encoder->dev->dev;
+   u32 total_lines_x100, vclks_line, cfg;
+   long vsync_clk_speed;
+   int pp_id = GET_PING_PONG_ID(mdp5_crtc_get_lm(encoder->crtc));
+
+   if (IS_ERR_OR_NULL(mdp5_kms->vsync_clk)) {
+   dev_err(dev, "vsync_clk is not initialized\n");
+   return -EINVAL;
+   }
+
+   total_lines_x100 = mode->vtotal * mode->vrefresh;
+   if (!total_lines_x100) {
+   dev_err(dev, "%s: vtotal(%d) or vrefresh(%d) is 0\n",
+   __func__, mode->vtotal, mode->vrefresh);
+   return -EINVAL;
+   }
+
+   vsync_clk_speed = clk_round_rate(mdp5_kms->vsync_clk, VSYNC_CLK_RATE);
+   if (vsync_clk_speed <= 0) {
+   dev_err(dev, "vsync_clk round rate failed %ld\n",
+   vsync_clk_speed);
+   return -EINVAL;
+   }
+   vclks_line = vsync_clk_speed * 100 / total_lines_x100;
+
+   cfg = MDP5_PP_SYNC_CONFIG_VSYNC_COUNTER_EN
+   | MDP5_PP_SYNC_CONFIG_VSYNC_IN_EN;
+   cfg |= MDP5_PP_SYNC_CONFIG_VSYNC_COUNT(vclks_line);
+
+   mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg);
+   mdp5_write(mdp5_kms,
+   REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0);
+   mdp5_write(mdp5_kms,
+   REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay);
+   mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), mode->vdisplay + 1);
+   mdp5_write(mdp5_kms, REG_MDP5_PP_START_POS(pp_id), mode->vdisplay);
+   mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_THRESH(pp_id),
+   MDP5_PP_SYNC_THRESH_START(4) |
+   MDP5_PP_SYNC_THRESH_CONTINUE(4));
+
+   return 0;
+}
+
+static int pingpong_tearcheck_enable(struct dr

[PATCH 3/4] drm/msm: Initial add DSI connector support

2015-03-13 Thread Hai Li
This change adds the DSI connector support in msm drm driver.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/Kconfig   |   11 +
 drivers/gpu/drm/msm/Makefile  |4 +
 drivers/gpu/drm/msm/dsi/dsi.c |  203 
 drivers/gpu/drm/msm/dsi/dsi.h |  115 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 1997 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  706 
 drivers/gpu/drm/msm/dsi/dsi_phy.c |  352 ++
 drivers/gpu/drm/msm/msm_drv.h |   20 +
 8 files changed, 3408 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1e6a907..5ba5631 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -35,3 +35,14 @@ config DRM_MSM_REGISTER_LOGGING
  Compile in support for logging register reads/writes in a format
  that can be parsed by envytools demsm tool.  If enabled, register
  logging can be switched on via msm.reglog=y module param.
+
+config DRM_MSM_DSI
+   bool "Enable DSI support in MSM DRM driver"
+   depends on DRM_MSM
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   default y
+   help
+ Choose this option if you have a need for MIPI DSI connector
+ support.
+
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 674a132..5c144cc 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -50,5 +50,9 @@ msm-y := \
 
 msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
 msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
+msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
+   dsi/dsi_host.o \
+   dsi/dsi_manager.o \
+   dsi/dsi_phy.o
 
 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
new file mode 100644
index 000..de77260
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "dsi.h"
+
+int msm_dsi_modeset_init(struct msm_drm_sub_dev *base, struct drm_device *dev)
+{
+   struct msm_dsi *msm_dsi = container_of(base, struct msm_dsi, base);
+   struct msm_drm_private *priv = dev->dev_private;
+   int ret, i;
+
+   if (WARN_ON((base->num_encoders != MSM_DSI_ENCODER_NUM) ||
+   !base->encoders[MSM_DSI_VIDEO_ENCODER_ID] ||
+   !base->encoders[MSM_DSI_CMD_ENCODER_ID]))
+   return -EINVAL;
+
+   msm_dsi->dev = dev;
+
+   ret = msm_dsi_host_modeset_init(msm_dsi->host, dev);
+   if (ret) {
+   dev_err(dev->dev, "failed to modeset init host: %d\n", ret);
+   goto fail;
+   }
+
+   msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
+   if (IS_ERR(msm_dsi->bridge)) {
+   ret = PTR_ERR(msm_dsi->bridge);
+   dev_err(dev->dev, "failed to create dsi bridge: %d\n", ret);
+   msm_dsi->bridge = NULL;
+   goto fail;
+   }
+
+   msm_dsi->connector = msm_dsi_manager_connector_init(msm_dsi->id);
+   if (IS_ERR(msm_dsi->connector)) {
+   ret = PTR_ERR(msm_dsi->connector);
+   dev_err(dev->dev, "failed to create dsi connector: %d\n", ret);
+   msm_dsi->connector = NULL;
+   goto fail;
+   }
+
+   for (i = 0; i < base->num_encoders; i++)
+   base->encoders[i]->bridge = msm_dsi->bridge;
+
+   priv->bridges[priv->num_bridges++]   = msm_dsi->bridge;
+   priv->connectors[priv->num_connectors++] = msm_dsi->connector;
+
+   return 0;
+fail:
+   if (msm_dsi) {
+   /* bridge/connector are normally destroyed by drm: */
+   if (msm_dsi->bridge) {
+   msm_dsi_manager_bridge_destroy(msm_dsi->bridge);
+   msm_dsi->bridge = NULL;
+   }
+   if (msm_dsi->connector) {
+   msm_dsi->connector->funcs->destroy(msm_dsi->connector);
+   msm_dsi->connector = NULL;
+   }
+   }
+
+   return ret;
+}
+
+static void dsi_destroy(struct msm_dsi *msm_dsi)
+{
+   if (!msm_dsi)
+   return

[PATCH 1/4] drm/msm/dsi: Update generated DSI header file

2015-03-13 Thread Hai Li
Prepare for initial DSI implementation

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/dsi/dsi.xml.h | 418 ++
 1 file changed, 376 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index abf1bba..1dcfae2 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -8,19 +8,10 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git
 
 The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
676 bytes, from 2014-12-05 15:34:49)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2013-03-31 16:51:27)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(  
20908 bytes, from 2014-12-08 16:13:00)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml  (   
2357 bytes, from 2014-12-08 16:13:00)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(  
27208 bytes, from 2015-01-13 23:56:11)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
11712 bytes, from 2013-08-17 17:13:43)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
344 bytes, from 2013-08-11 19:26:32)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1686 bytes, from 2014-10-31 16:48:57)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2013-07-05 19:21:12)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
26848 bytes, from 2015-01-13 23:55:57)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (   
8253 bytes, from 2014-12-08 16:13:00)
-
-Copyright (C) 2013 by the following authors:
+- /usr2/hali/local/envytools/envytools/rnndb/dsi/dsi.xml (  18681 
bytes, from 2015-03-04 23:08:31)
+- /usr2/hali/local/envytools/envytools/rnndb/freedreno_copyright.xml (   1453 
bytes, from 2015-01-28 21:43:22)
+
+Copyright (C) 2013-2015 by the following authors:
 - Rob Clark  (robclark)
 
 Permission is hereby granted, free of charge, to any person obtaining
@@ -51,11 +42,11 @@ enum dsi_traffic_mode {
BURST_MODE = 2,
 };
 
-enum dsi_dst_format {
-   DST_FORMAT_RGB565 = 0,
-   DST_FORMAT_RGB666 = 1,
-   DST_FORMAT_RGB666_LOOSE = 2,
-   DST_FORMAT_RGB888 = 3,
+enum dsi_vid_dst_format {
+   VID_DST_FORMAT_RGB565 = 0,
+   VID_DST_FORMAT_RGB666 = 1,
+   VID_DST_FORMAT_RGB666_LOOSE = 2,
+   VID_DST_FORMAT_RGB888 = 3,
 };
 
 enum dsi_rgb_swap {
@@ -69,20 +60,63 @@ enum dsi_rgb_swap {
 
 enum dsi_cmd_trigger {
TRIGGER_NONE = 0,
+   TRIGGER_SEOF = 1,
TRIGGER_TE = 2,
TRIGGER_SW = 4,
TRIGGER_SW_SEOF = 5,
TRIGGER_SW_TE = 6,
 };
 
+enum dsi_cmd_dst_format {
+   CMD_DST_FORMAT_RGB111 = 0,
+   CMD_DST_FORMAT_RGB332 = 3,
+   CMD_DST_FORMAT_RGB444 = 4,
+   CMD_DST_FORMAT_RGB565 = 6,
+   CMD_DST_FORMAT_RGB666 = 7,
+   CMD_DST_FORMAT_RGB888 = 8,
+};
+
+enum dsi_lane_swap {
+   LANE_SWAP_0123 = 0,
+   LANE_SWAP_3012 = 1,
+   LANE_SWAP_2301 = 2,
+   LANE_SWAP_1230 = 3,
+   LANE_SWAP_0321 = 4,
+   LANE_SWAP_1032 = 5,
+   LANE_SWAP_2103 = 6,
+   LANE_SWAP_3210 = 7,
+};
+
 #define DSI_IRQ_CMD_DMA_DONE   0x0001
 #define DSI_IRQ_MASK_CMD_DMA_DONE  0x0002
 #define DSI_IRQ_CMD_MDP_DONE   0x0100
 #define DSI_IRQ_MASK_CMD_MDP_DONE  0x0200
 #define DSI_IRQ_VIDEO_DONE 0x0001
 #define DSI_IRQ_MASK_VIDEO_DONE
0x0002
+#define DSI_IRQ_BTA_DONE   0x0010
+#define DSI_IRQ_MASK_BTA_DONE  0x0020
 #define DSI_IRQ_ERROR  0x0100
 #define DSI_IRQ_MASK_ERROR 0x0200
+#define REG_DSI_6G_HW_VERSION  0x
+#define DSI_6G_HW_VERSION_MAJOR__MASK  0xf000
+#define DSI_6G_HW_VERSION_MAJOR__SHIFT 28
+static inline uint32_t DSI_6G_HW_VERSION_MAJOR(uint32_t val)
+{
+   return ((val) << DSI_6G_HW_VERSION_MAJOR__SHIFT) & 
DSI_6G_HW_VERSION_MAJOR__MASK;
+}
+#define DSI_6G_HW_VERSION_MINOR__MASK  0x0fff
+#define DSI_6G_HW_VERSION_MINOR__SHIFT 16
+static inline uint32_t DSI_6G_HW_VERSION_MINOR(uint32_t val)
+{
+   return ((val) << DSI_6G_HW_VERSION_MINOR__SHIFT) & 
DSI_6G_HW_VERSION_MINOR__MASK;
+}
+#define DSI_6G_HW_VERSION_STEP__MASK   0x
+#define DSI_6G_HW_VERSION_STEP__SHIFT  0
+static i

[PATCH 2/4] drm/msm: Add split display interface

2015-03-13 Thread Hai Li
This change is to add an interface to MDP for connector devices
setting split display information.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/msm_kms.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 3a78cb4..a9f17bd 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -47,6 +47,10 @@ struct msm_kms_funcs {
const struct msm_format *(*get_format)(struct msm_kms *kms, uint32_t 
format);
long (*round_pixclk)(struct msm_kms *kms, unsigned long rate,
struct drm_encoder *encoder);
+   int (*set_split_display)(struct msm_kms *kms,
+   struct drm_encoder *encoder,
+   struct drm_encoder *slave_encoder,
+   bool is_cmd_mode);
/* cleanup: */
void (*preclose)(struct msm_kms *kms, struct drm_file *file);
void (*destroy)(struct msm_kms *kms);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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


Re: [patch 1/2] block, drbd: fix drbd_req_new() initialization

2015-03-13 Thread David Rientjes
On Sat, 7 Mar 2015, David Rientjes wrote:

> > >>> mempool_alloc() does not support __GFP_ZERO since elements may come from
> > >>> memory that has already been released by mempool_free().
> > >>>
> > >>> Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly
> > >>> initialize it to 0.
> > >>
> > >> You should add it to mempool instead, avoid having this issue show up for
> > >> other folks as well. It'd be trivial to do. Normal ->alloc() should honor
> > >> __GFP_ZERO, just do the same manually for removing an item from the 
> > >> internal
> > >> pool.
> > >>
> > > 
> > > Umm, it's not trivial to do and wouldn't make sense to do it.  Mempools 
> > 
> > Uhm, it would make sense, though.
> > 
> 
> Disagree, I don't think we should extend mempool to know the element size, 
> modify every user of mempool to pass it in, and keep it consistent with 
> mempool_alloc_t for the benefit of __GFP_ZERO for this one buggy caller.  
> Most users don't need __GFP_ZERO and just overwrite the entire element 
> after mempool_alloc() and it would be an unnecessary overhead to even 
> check for the bit set.  So it wouldn't make sense in terms of performance 
> or maintainability.
> 
> > > don't know the element size, in other words it wouldn't know the length 
> > > to 
> > > memset() to 0 for mempool_alloc().  It shouldn't be modified to know the 
> > > element size since elements are allocated by the implementation of 
> > > mempool_alloc_t and they could easily become inconsistent.  This patch is 
> > > what you want to merge, really.
> > > 
> > 
> > I forgot we don't have the size in there. Then I would suggest adding a
> > WARN_ON() for __GFP_ZERO being set in mempool_alloc(), at the very least.
> > 
> 
> There is, it's a VM_WARN_ON_ONCE() that will show up if you configure 
> CONFIG_DEBUG_VM.
> 

Jens, are these two patches going to be merged into linux-block?

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


[PATCH 0/4] drm/msm: Initial add DSI support

2015-03-13 Thread Hai Li
DSI is supported by both mdp4 and mdp5. This patch series adds the common DSI
controller driver and also enable it in mdp5.

Hai Li (4):
  drm/msm/dsi: Update generated DSI header file
  drm/msm: Add split display interface
  drm/msm: Initial add DSI connector support
  drm/msm/mdp5: Enable DSI connector in msm drm driver

 drivers/gpu/drm/msm/Kconfig |   11 +
 drivers/gpu/drm/msm/Makefile|4 +
 drivers/gpu/drm/msm/dsi/dsi.c   |  203 +++
 drivers/gpu/drm/msm/dsi/dsi.h   |  115 ++
 drivers/gpu/drm/msm/dsi/dsi.xml.h   |  418 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c  | 1997 +++
 drivers/gpu/drm/msm/dsi/dsi_manager.c   |  706 ++
 drivers/gpu/drm/msm/dsi/dsi_phy.c   |  352 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |4 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|   11 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  268 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |   69 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |   12 +-
 drivers/gpu/drm/msm/msm_drv.c   |2 +
 drivers/gpu/drm/msm/msm_drv.h   |   20 +
 drivers/gpu/drm/msm/msm_kms.h   |4 +
 16 files changed, 4141 insertions(+), 55 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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


[PATCH] rnndb: Update DSI core and PHY registers for 8084

2015-03-13 Thread Hai Li
DSI core registers in DSI6G are compatible with the old versions.
The offsets are 4-byte shift down because of the addition of a
HW_VERSION register. This difference will be handled in source code.

DSI PHY registers are incompatible. This change adds a new domain
for 28nm PHY and PHY regulator, which are used in 8084 and some other
chips.

Signed-off-by: Hai Li 
---
 rnndb/dsi/dsi.xml | 212 --
 1 file changed, 191 insertions(+), 21 deletions(-)

diff --git a/rnndb/dsi/dsi.xml b/rnndb/dsi/dsi.xml
index 19898e1..480ec46 100644
--- a/rnndb/dsi/dsi.xml
+++ b/rnndb/dsi/dsi.xml
@@ -10,11 +10,11 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
-   
-   
-   
-   
+   
+   
+   
+   
+   



@@ -26,11 +26,30 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+   





+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   



@@ -38,10 +57,18 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+   
+   



 
+   
+   
+   
+   
+   
+



@@ -56,15 +83,20 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">

 

+   

+   

  
+   

 
-   
+   
+   
+   

  

-   
+   



@@ -74,11 +106,10 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
-   
-   
-   
-   
+   
+   
+   
+   



@@ -96,27 +127,53 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
+   
+   
+   
+   
+   



 

+   



-   
-   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   


+   
+   
+   
+   
+   
+   
+   
+   
+   





-   
-   
-   
+   
+   
+   
+   



@@ -130,12 +187,34 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
+   
+   
+   



-   
-   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
 


@@ -272,4 +351,95 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">

 
 
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+
+   
+   
+
+   
+   
+   
+   
+   
+   
+
+   
+   
+
+
+
+   
+   
+   
+   
+   
+   
+   
+
+
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the 

Re: [PATCH 01/32] do_fork(): Rename 'stack_size' argument to reflect actual use

2015-03-13 Thread David Rientjes
On Fri, 13 Mar 2015, j...@joshtriplett.org wrote:

> On Fri, Mar 13, 2015 at 08:04:16PM +0200, Alex Dowad wrote:
> > The 'stack_size' argument is never used to pass a stack size. It's only 
> > used when
> > forking a kernel thread, in which case it is an argument which should be 
> > passed
> > to the 'main' function which the kernel thread executes. Hence, rename it to
> > 'kthread_arg'.
> 
> That's not the only use of stack_size.  Take a look at the clone2 system
> call (very minimally documented in the clone manpage) and the
> implementation of copy_thread on ia64, which does use stack_size in the
> non-kthread path.
> 

Exactly, and it seems like Alex just disregarded this early feedback when 
this was first raised that suggested it just be named "arg" and to comment 
the individual usage in the functions that get called with the formal.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH V5] Allow compaction of unevictable pages

2015-03-13 Thread David Rientjes
On Fri, 13 Mar 2015, Eric B Munson wrote:

> > > --- a/mm/compaction.c
> > > +++ b/mm/compaction.c
> > > @@ -1046,6 +1046,8 @@ typedef enum {
> > >   ISOLATE_SUCCESS,/* Pages isolated, migrate */
> > >  } isolate_migrate_t;
> > >  
> > > +int sysctl_compact_unevictable;
> > > +
> > >  /*
> > >   * Isolate all pages that can be migrated from the first suitable block,
> > >   * starting at the block pointed to by the migrate scanner pfn within
> > 
> > I suspect that the use cases where users absolutely do not want
> > unevictable pages migrated are special cases, and it may make
> > sense to enable sysctl_compact_unevictable by default.
> 
> Given that sysctl_compact_unevictable=0 is the way the kernel behaves
> now and the push back against always enabling compaction on unevictable
> pages, I left the default to be the behavior as it is today.  I agree
> that this is likely the minority case, but I'd really like Peter Z or
> someone else from real time to say that they are okay with the default
> changing.
> 

It would be really disappointing to not enable this by default for !rt 
kernels.  We haven't migrated mlocked pages in the past by way of memory 
compaction because it can theoretically result in consistent minor page 
faults, but I haven't yet heard a !rt objection to enabling this.

If the rt patchset is going to carry a patch to disable this, then the 
question arises: why not just carry an ISOLATE_UNEVICTABLE patch instead?  
I think you've done the due diligence required to allow this to be 
disabled at any time in a very easy way from userspace by the new tunable.  
I think it should be enabled and I'd be very surprised to hear any other 
objection about it other than it's different from the status quo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] n_tty: 4.0-rc3+: Unable to handle kernel paging request at virtual address 000044d0

2015-03-13 Thread Ming Lei
On Fri, Mar 13, 2015 at 8:59 PM, Peter Hurley  wrote:
> [ +cc Will Deacon, linux-arm ]
>
> Hi Ming,
>
> On 03/13/2015 02:02 AM, Ming Lei wrote:
>> Hi Guys,
>>
>> Just found the following oops during kernel booting when I
>> test the latest linus tree on one arm64 VM booted from uefi
>> plus grub2:
>
> Thanks for the bug report.
>
> This looks like a compiler bug when generating code for
> smp_load_acquire() (see below); what compiler are you using?

It is one gcc-4.7 based compiler from one customer, and when I switch
to aarch64-linux-gnu, the bug does disappear.

Thanks for your help!

>
>
>> Unable to handle kernel paging request at virtual address 44d0
>> pgd = ffc0007fb000
>> [44d0] *pgd=79407003, *pud=79407003,
>> *pmd=79408003, *pte=006008004707
>> Internal error: Oops: 9405 [#1] PREEMPT SMP
>> Modules linked in:
>> CPU: 1 PID: 632 Comm: kworker/1:1 Not tainted 4.0.0-rc3+ #121
>> Hardware name: linux,dummy-virt (DT)
>> Workqueue: events flush_to_ldisc
>> task: ffc0395eac00 ti: ffc038cb task.ti: ffc038cb
>> PC is at n_tty_receive_buf_common+0x60/0xa28
>> LR is at n_tty_receive_buf_common+0x4c/0xa28
>> pc : [] lr : [] pstate: 2145
>> sp : ffc038cb3c70
>> x29: ffc038cb3c70 x28: ffc0385ab400
>> x27: ffc03ffe3380 x26: 0008
>> x25: ffc0006a5260 x24: ffc0385b0e28
>> x23: ffc038557340 x22: ffc0385ab400
>> x21: ffc0385b0e08 x20: ffc0385b0e00
>> x19: ffc03854c800 x18: 007fda9ad810
>> x17: 007f8291ee7c x16: ffc000185540
>> x15: 007f8298f590 x14: 007472617473
>> x13: 2d657279 x12: 0020
>> x11: 002c x10: 007fb1e23360
>> x9 : ffc038cb3d40 x8 : ffc00079cb10
>> x7 : ffc000362e58 x6 : ffc03854c820
>> x5 : 44d0 x4 : ff8000278000
>> x3 : 002e x2 : 
>> x1 : 0001 x0 : ffc00058f250
>>
>> Process kworker/1:1 (pid: 632, stack limit = 0xffc038cb0028)
>> Stack: (0xffc038cb3c70 to 0xffc038cb4000)
>> 3c60: 38cb3d20 ffc0 00362e68 ffc0
>> 3c80: 3854c800 ffc0 385b0e00 ffc0 385b0e08 ffc0 385ab400 ffc0
>> 3ca0: 38557340 ffc0 385b0e28 ffc0 006a5260 ffc0 0008 
>> 3cc0: 3ffe3380 ffc0   3946c200 ffc0 3946c268 ffc0
>> 3ce0: 385ab4d8 ffc0 0001  00278000 ff80 3854c820 ffc0
>> 3d00:   002e ffc0 385b0e58 ffc0 0058f250 ffc0
>> 3d20: 38cb3d30 ffc0 00365b68 ffc0 38cb3d80 ffc0 000b522c ffc0
>> 3d40: 38b84540 ffc0 385b0e08 ffc0 3ffe3380 ffc0 3ffe7600 ffc0
>> 3d60:     006a5260 ffc0 000b5220 ffc0
>> 3d80: 38cb3dd0 ffc0 000b5974 ffc0 38b84540 ffc0 3ffe3398 ffc0
>> 3da0: 3ffe3380 ffc0 38b84570 ffc0 007c641d ffc0 0001 
>> 3dc0: 006a5260 ffc0 0008  38cb3e30 ffc0 000ba900 ffc0
>> 3de0: 38c7d8c0 ffc0 007cced0 ffc0 006a3ee8 ffc0 38b84540 ffc0
>> 3e00: 000b5828 ffc0      
>> 3e20:       00085bf0 ffc0
>> 3e40: 000ba828 ffc0 38c7d8c0 ffc0    
>> 3e60:   000c0fbc ffc0 000ba828 ffc0  
>> 3e80:   38b84540 ffc0    
>> 3ea0: 38cb3ea0 ffc0 38cb3ea0 ffc0  ffc0  ffc0
>> 3ec0: 38cb3ec0 ffc0 38cb3ec0 ffc0    
>> 3ee0:        
>> 3f00:        
>> 3f20:        
>> 3f40:        
>> 3f60:        
>> 3f80:        
>> 3fa0:        
>> 3fc0:       0005 
>> 3fe0:     afafafaf afafafaf afafafaf afafafaf
>> Call trace:
>> [] n_tty_receive_buf_common+0x60/0xa28
>> [] n_tty_receive_buf2+0xc/0x18
>> [] flush_to_ldisc+0xec/0x140
>> [] process_one_work+0x138/0x338
>> [] worker_thread+0x148/0x420
>> [] kthread+0xd4/0xf0
>> Code: 91094000 f90057a0 d2844d05 8b0500a5 (c8dffca3)
>
> This code disassembles as:
>
>0:   91094000add x0, x0, #0x250
>4:   f90057a0str x0, [x29,#168]
>8:   d2844d05mov x5, #0x2268 // #8808
>c:   8b0500a5add x5, x5, x5
>   10:   c8dffca3ldarx3, [x5]   <

Re: [PATCH v4 4/9] selftests: Add install target

2015-03-13 Thread Shuah Khan
On 03/13/2015 03:32 PM, Shuah Khan wrote:
> On 03/13/2015 11:20 AM, Shuah Khan wrote:
>> On 03/10/2015 10:06 PM, Michael Ellerman wrote:
>>> This adds make install support to selftests. The basic usage is:
>>>
>>> $ cd tools/testing/selftests
>>> $ make install
>>>
>>> That installs into tools/testing/selftests/install, which can then be
>>> copied where ever necessary.
>>>
>>> The install destination is also configurable using eg:
>>>
>>> $ INSTALL_PATH=/mnt/selftests make install
>>>
>>> The implementation uses two targets in the child makefiles. The first
>>> "install" is expected to install all files into $(INSTALL_PATH).
>>>
>>> The second, "emit_tests", is expected to emit the test instructions (ie.
>>> bash script) on stdout. Separating this from install means the child
>>> makefiles need no knowledge of the location of the test script.
>>>
>>> Signed-off-by: Michael Ellerman 
>>
>> Thanks for doing the work. This patch will be applied to next and will
>> be queued for 4.1
>>
> 
> ok. linux-kselftest next has both shared logic and install patches
> now. As I mentioned in my reply to shared logic patch, I had to drop
> the changes to timers Makefile to add shared logic, hence timers progs
> don't get installed at the moment.
> 
> Could you please review to make sure, it looks right.
> 
> As I said in the other email, if lib.mk could provide a way to run
> additional programs that require arguments in addition to RUN_TESTS.
> In the case of timers, there is one test that requires arguments. In
> some cases, e.g: memory hotplug, override works well since it is just
> one executable. In this case, there is a mix of executables that don't
> need any special handling and some that need it.
> 
> You are welcome to add shared logic and install to timers if you would
> like.
> 

I managed to get this taken care of before my weekend. You will see two
patches one with changes to lib.mk to add additional variables to avoid
overrides for cases like timers, and the other that updates timers to
use shared logic.

I did quick test running both make run_tests and make install to verify
timers programs are installed and run_tests works correctly.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] radeon: Update Kaveri MEC firmware to #396

2015-03-13 Thread Oded Gabbay
This patch updates the Kaveri MEC firmware to #396 (from #391).
The MEC firmware is mainly used for amdkfd - AMD's HSA Linux kernel driver.

Signed-off-by: Oded Gabbay 
---
 radeon/kaveri_mec.bin  | Bin 17024 -> 17024 bytes
 radeon/kaveri_mec2.bin | Bin 17024 -> 17024 bytes
 2 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/radeon/kaveri_mec.bin b/radeon/kaveri_mec.bin
index 
96322d60199a472d61c9b9b209ebb8e9b4a7c8dd..431630f6498c68efdf680140e5ee9f8fdc8b0c27
 100644
GIT binary patch
delta 3226
zc${rkeQ=cJ5#PO!+;?)v-Q{xm;O=s{+$Bf6j|9UJLf(TRF=MGlES3_Aj8?IZADw|J
z(|o*95nF=7EFmEgm9K$;2xS6O7+`!e9@b1nw4x>&W=xeD+jPXSDrn@o&m~hM?H|8)
z-*>
z0O@=iEJ(G{F>J?QQcM+b4)a2*8anj=!zfEFv!TyZe9{WK^V<
z{Q#XsU`_uCvkmkq8-D|Q
z@CJg{_)Qvm_aew`u+FcBgK;-?=$2V7F-Q2A!#-W2OS*f|L`l8huoin7g)E02(BF^8
z>219q57Srr)A}5MKCyz18%oTNvYH;`%rR-yaEot>0p~d;TUW*{DO47>j>Da9Biv~l
zhta&1lr-9-Yg8cL&p5<5!#K-$pW%Tw3RlJl-&hs5r9MY%U{xG5mZ-=0IKDtOQ#J0T
zM$;oWLZ?hY?J5pKf-aka&Jnf9MTuenrOOM^)KyQk;0XE5l^LD)X@$8Ob+pYK!88q;
zKlaU0k83$~Pe)lAV=Q5uWQfhwp!AH;Ig1~U&}SCEL0FjLIkPL7*O+||K1?rXH{etB
zRdxh-4Fqy@s1*@>k78C2=1`OMPiP>6Er?Ev*;e9Bw8gf}Ry-+nccf2xnz=3j^rMI9
z3tIupEVEn~punt%Ph`CgWG)b;s}7XmJ_E?o^tZ&{S7`mLu=7DpDC7Jlu9k-x>oQey
zVpa`qpf6_Kg{!I2{s?F5l>J5g2d!{y#x-==akQdb3$hUo=H`L?CRfF4YJlF`w9t7@
zBO)J7Ess~E0IM`+cqV;Gw+9PojXTWtx42JZJvHWsS$}DVNnZ8i&{kVc4UFf`IZkeJvaUSBGb31slbkd^s9mho}jLRI^0k17A(W9
zR95K6O|-NyjAOK+a1$347S*Abl0~cW_q3az2MA|3REXWh8QY?@DUjm|sH5R^Fj=6w
zrgS?%KEE=K7ZAoPuU}QVOKJV=(@VDL4rZa8Y(XWN@h!@C>X;7X(~Q3`E;62Hyf}>m
zjH9|KpS>{Jln*boCTP9Kg9+;Lcnk?%?*s4a2|DZX7{wRBo}q-Eo^|Kaq$k8`0k5B*
zjot?_M%(=MvI(6~nxg@TYPi~aRRGFEJnNq!VO})W
zpNPbM%zMnBQJ2BsZR4@NV>8@NSIBUW%1WS-3GKf_Gy~1P`oya?eZ)
z9VK?Hkkr%8lDfGwufTPENUH)zNOWmYURu7&0;Xx|W`qRD5;)BDa4JxTNxBxO2ui6%tnWkkykS>u{H6Dt*vLYl2U5%r6HU@Df#o{QPVR)p5hx7IIlKgOE>f+ypYwiBM3p
zk{zc{LRI+mfV(WH5@RYHbXrwX7th`u;#5LoYJj$eJ*cK#;R2i-I2HaF@yUT*6(%%D
zDD9{Qd1M0}yGgX1clo)2uHEF}cX#BU?&)?r-QtvyEBsx~7x^$1MHgq9%||Ba4D)b3
zKo3P5@GPB(erR=p)E#7*6C@Fd9(q1DhYb$J3b-F!j){(Ci;FE{{Je{r;-a6m#vAZH
zIu}39(vC_$9-{q~!FB_fQ`{LG0E;hKdFtz7PMHIgH=E;$)Gtu(70$G=&O}<-o`#o7
zESyj+nCGjYYM}-~aicQc0=T_I5Bq{q=n0BHkFm7UU58TdLX^7eQQkT5rPA|vkaogH
z&lIX4FD|ILW+4bZCU
zn#QHsTwy$O2RQAjX{wo~dZwG0stX@aUJyW6qr7xYfDKCmz|2wHy+!i4hdJnLE4*TroAo@Vs(G(A)
zZjbwTJeH+stJ`s(7w)|yUn*^r;NE)c*8Y4@O_UdMmS%(WS6(nIjM&6RY3Q?a7dCT&
z>LFA=r6Xr_evlWw&PUjp11E#xzhEC1JUggVnQ37nAN8~%v6_eAsYG=$^{ph#gn5K;
zL6oJeP^_fUTP_l4g@fh1{LOE0BHslQvy2dF%jRXs7DPP(OL9`;j5
zjmy85KlgtpZ_ni$-5f7Uy_y~^YK{+{|DBP4Of&JCORv-v`A{Bg6DGJrbqN#A@mPv;
z5N^(lK&$d9;ev+jMJy465#Vn_t{hsvU=c2&oeSPUD?L=}T5IDLB7Cw!)b)K@>YEh4
zLDdpaT?rQgT;RCBBVwut$C5ne{}5a2>n7e<$nDH41$bKr|8{9$T{r;Jg&?mD@j3_F
zPqW>D{@S}$?fcCdxMtA7=LQ4x8jP?JOmMHx4Br|o@B(B*uh|OO8YgVgy5P9B2m)EN
z;Wbk+Y|5&J53&;QiD>~G*3`i>Itj-0x5HI^J);p`G5#Fx*Q|xDn%}}M&Ev3HvjMuy
zt&!2~dh>30+`I>#GVg@K?tyRysf@^D!e+{Kmb0}znchlbFMLla}P>4>4$(KbzO>g1tL
zd3?m8HYFzZ@DNa|Bsyp@(V;fA=yYjUM;%c!!2~MlXfz`1GojhEgkF_hS7sjoH&^rk#VnIQ*pVc!Y)i!yw*&mR+yXrppfLbgdOwn$$YS+gG0Ap_3=
z{&p52E%r_rI^RJM>){or9C`v)YE&)OTw;ly{kcR}R4Xx-D%4J8L`G}XKf)t4qIP00
zO{n`7I)E+;YBCgR5YN*s&3C9cHs!e`vN7dP;ez#+>aO(;Ub8YEo0iEyT+P_e=w}>b
ze9Wj06o%4ZyGsRPhaJwQEDH>rT^=xoZlWP`c>o8Q$G5|9)?LH8v?F#s?j*A|AG@ha
z`w|Y*aji>P%|Bj1<60Nbjk*LpNSV5vi1cGxuFJ<5YSnr1YdWF3>hQ?Nl#)AMUiC2^
zXMDhrwvj_{`!Jo>JK4ewy;CDun3UP#a#&Usw-VRT;kZiNNcZBrxT7yCUWH1Dsf(0n
zu%n)q7(PHX>5VQlQJ!%bX45v~;%w(bp}jHuM|(A&J%D<2uO37LTrlN;HKc)*kOH8?
z3_^#MImjmC3=3vZ)(o#hI`1+Nhh-3KErZ~2rv^kJIv03;lQzuon17;hM}BD&$H^MT
z%aM3FI->~J(^oUThtE@0!b^C7jwk#U$7#9g*Z4ykH@$DmQi2!@J&C;QIgW>ua)8e7
zDxo<2=Cr5fG~2Ct|WSK9~mu@p5J28oVgEeQdFIy
zMHVj}qeja@bkm^aI!@3Lt37LiceL>?9RI_t=RU`CKa5(LfetBSAdCeJDEK#r^ph>AapbB0QTV-Cckc
zLw}(clD+r`>PRl*{YR1)<2K4papD$Ql;Xk5RF|@u15cS+hIXn*tzr3IZugOLW+nSx
zHPd32-wU>zKpb2a!1D-WIpMp(b{B1!*&d*NBr{g?K;F44BH>o27zTyP1Qc`aQREseBM!B
zIXSmI#jz&wTcMuhu7>-cGu~i4!>A{7x)bB5Fnt}~qQmL=_!*6-d+-x7I~z)#_!hRh
z|Boz2)msRvZ~W<|51k1m(#mwUB-wPfBv}E==1!H7BV*FSbOs}`X$(rT=?r$$+KdES
z#N%mfNwNysnNgNE_0~)uELYuYR?-_C8kHX2=XfiT3$vGX+=m{o(nB8SU`XXr^+GIr7`
z*G9ZZUOE6s>*48
z3te;P;?h1_mP^L9t=!`>$IFD)|M`~cJa&}PPERsE=sW7Uiuiip&TK7e_^;aXK^$36
zhaZ!&)J1OB)4j*+Jhpkiutl?UG*1RcZt{FKXS@TH>RS-WPnWgOJelX#_$oP19`Rk$
zC4$iI;x%Tsi+20xu(3gZGAE32zm(w20m*zGw@YbBKuUj&fl6FOrvv@G+LYtO{j@*F
z)gWzD54zCpaIhr|yE6b5e5&UIGw^dk4Rbhs1xlW|F`a;3WWtsc5w548p$m}WuG~3u}rfSgie6Q(F|IfUzF#J?@@S9I
zexUvq4Hj5zDIlHisPZaH{~7*foJbP|&MGDQ(ZF#Byk{C$4vDHT_*@5d(re6+RR%t%
z2_TZElOG73(w(Rdq=sIALtMFX`4NVH=Wi7pL7fJ|c{OOJ74!15Zrm5z)Zq4Tj%UiV
z*ly2kegT||;r)i?mrf#VR}Ra22fZ{h&&$WEDRSb^D7$E(nrnThsCeiiv1krj=wMM%
zn*Hlwi;0~JhoQ?LYn~k&e8?%x8g#@%GeUVCDT)j55|tENTpkt;JrG+Gxu{EihQgz%
z)q#P*U&MmAD3BR?I*=Et4)|$ZacZVyM#bh(9H^JZ{QsV6{!h*Vt&^q=!4^7FTp4HP
znN+O+K0E!7IEpQq&%aq!@)0V@QEG9k!BpXis94!YvBLm~rxi@Q6_QTy(}vS*TjVL%
zx4ZNQGP+QDyWw4(0`6&4@Gp%9IyAA+1X@_B(!qU=9(F+-bm$DASD2w$X@NdvDrCgW
zgp=BI*c6iwBQb?=OqNtA9*6ZU;ZHl
H%N73xjQpB5

diff --git a/radeon/kaveri_mec2.bin b/radeon/kaveri_mec2.bin
index 
a11fc0ebcdab4b5951b6fd8f444d399d9ff9ee8a..1f7597eb7d94ca9cce3b6db27753e75961610578
 100644
GIT binary patch
delta 3138
zc${rkdvH|M8UN1Rd$X^bWS8A!ck>|0?k1b3*}Vxy@*p=VZ(k6M50Ww{RVr$05g#?#

[PATCH v3] led/led-class: Handle LEDs with the same name

2015-03-13 Thread Ricardo Ribalda Delgado
The current code expected that every LED had an unique name. This is a
legit expectation when the device tree can no be modified or extended.
But with device tree overlays this requirement can be easily broken.

This patch finds out if the name is already in use and adds the suffix
_1, _2... if not.

Signed-off-by: Ricardo Ribalda Delgado 
---
v3: Suggested by Bryan Wu 

-Do not allocate dynamically the name
 drivers/leds/led-class.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 768d33a..4ca37b8 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -212,6 +212,26 @@ static const struct dev_pm_ops leds_class_dev_pm_ops = {
.resume = led_resume,
 };
 
+static int match_name(struct device *dev, const void *data)
+{
+   if (!dev_name(dev))
+   return 0;
+   return !strcmp(dev_name(dev), (char *)data);
+}
+
+static int led_classdev_next_name(const char *init_name, char *name,
+ size_t len)
+{
+   int i = 0;
+
+   strncpy(name, init_name, len);
+
+   while (class_find_device(leds_class, NULL, name, match_name))
+   snprintf(name, len, "%s_%d", init_name, ++i);
+
+   return i;
+}
+
 /**
  * led_classdev_register - register a new object of led_classdev class.
  * @parent: The device to register.
@@ -219,12 +239,19 @@ static const struct dev_pm_ops leds_class_dev_pm_ops = {
  */
 int led_classdev_register(struct device *parent, struct led_classdev *led_cdev)
 {
+   char name[64];
+   int ret;
+
+   ret = led_classdev_next_name(led_cdev->name, name, sizeof(name));
led_cdev->dev = device_create_with_groups(leds_class, parent, 0,
-   led_cdev, led_cdev->groups,
-   "%s", led_cdev->name);
+   led_cdev, led_cdev->groups, name);
if (IS_ERR(led_cdev->dev))
return PTR_ERR(led_cdev->dev);
 
+   if (ret)
+   dev_info(parent, "Led %s renamed to %s due to name collision",
+   led_cdev->name, dev_name(led_cdev->dev));
+
 #ifdef CONFIG_LEDS_TRIGGERS
init_rwsem(&led_cdev->trigger_lock);
 #endif
-- 
2.1.4

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


Re: [PATCH 01/32] do_fork(): Rename 'stack_size' argument to reflect actual use

2015-03-13 Thread josh
On Fri, Mar 13, 2015 at 08:04:16PM +0200, Alex Dowad wrote:
> The 'stack_size' argument is never used to pass a stack size. It's only used 
> when
> forking a kernel thread, in which case it is an argument which should be 
> passed
> to the 'main' function which the kernel thread executes. Hence, rename it to
> 'kthread_arg'.

That's not the only use of stack_size.  Take a look at the clone2 system
call (very minimally documented in the clone manpage) and the
implementation of copy_thread on ia64, which does use stack_size in the
non-kthread path.

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


Re: [PATCH 2/6] x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit

2015-03-13 Thread josh
On Fri, Mar 13, 2015 at 03:45:16PM -0700, Andy Lutomirski wrote:
> On Fri, Mar 13, 2015 at 3:43 PM,   wrote:
> > On Fri, Mar 13, 2015 at 03:38:31PM -0700, Andy Lutomirski wrote:
> >> On Fri, Mar 13, 2015 at 3:31 PM,   wrote:
> >> > On Fri, Mar 13, 2015 at 03:01:16PM -0700, Andy Lutomirski wrote:
> >> >> On Thu, Mar 12, 2015 at 6:40 PM, Josh Triplett  
> >> >> wrote:
> >> >> > For 32-bit userspace on a 64-bit kernel, this requires modifying
> >> >> > stub32_clone to actually swap the appropriate arguments to match
> >> >> > CONFIG_CLONE_BACKWARDS, rather than just leaving the C argument for 
> >> >> > tls
> >> >> > broken.
> >> >> >
> >> >> > Signed-off-by: Josh Triplett 
> >> >> > Signed-off-by: Thiago Macieira 
> >> >> > ---
> >> >> >  arch/x86/Kconfig | 1 +
> >> >> >  arch/x86/ia32/ia32entry.S| 2 +-
> >> >> >  arch/x86/kernel/process_32.c | 6 +++---
> >> >> >  arch/x86/kernel/process_64.c | 8 
> >> >> >  4 files changed, 9 insertions(+), 8 deletions(-)
> >> >> >
> >> >> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> >> > index b7d31ca..4960b0d 100644
> >> >> > --- a/arch/x86/Kconfig
> >> >> > +++ b/arch/x86/Kconfig
> >> >> > @@ -124,6 +124,7 @@ config X86
> >> >> > select MODULES_USE_ELF_REL if X86_32
> >> >> > select MODULES_USE_ELF_RELA if X86_64
> >> >> > select CLONE_BACKWARDS if X86_32
> >> >> > +   select HAVE_COPY_THREAD_TLS
> >> >> > select ARCH_USE_BUILTIN_BSWAP
> >> >> > select ARCH_USE_QUEUE_RWLOCK
> >> >> > select OLD_SIGSUSPEND3 if X86_32 || IA32_EMULATION
> >> >> > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> >> >> > index 156ebca..0286735 100644
> >> >> > --- a/arch/x86/ia32/ia32entry.S
> >> >> > +++ b/arch/x86/ia32/ia32entry.S
> >> >> > @@ -487,7 +487,7 @@ GLOBAL(\label)
> >> >> > ALIGN
> >> >> >  GLOBAL(stub32_clone)
> >> >> > leaq sys_clone(%rip),%rax
> >> >> > -   mov %r8, %rcx
> >> >> > +   xchg %r8, %rcx
> >> >> > jmp  ia32_ptregs_common
> >> >>
> >> >> Do I understand correct that whatever function this is a stub for just
> >> >> takes its arguments in the wrong order?  If so, can we just fix it
> >> >> instead of using xchg here?
> >> >
> >> > 32-bit x86 and 64-bit x86 take the arguments to clone in a different
> >> > order, and stub32_clone fixes up the argument order then calls the
> >> > 64-bit sys_clone.
> >> >
> >> > I'd love to see *all* the 32-on-64 compat stubs for clone rewritten in C
> >> > under CONFIG_COMPAT.  However, doing so would require encoding the
> >> > knowledge for each 64-bit architecture for how its corresponding 32-bit
> >> > architecture accepts arguments to clone, which is information that the
> >> > current CONFIG_CLONE_BACKWARDS{1,2,3} don't include; it would then
> >> > require cleaning up all the architecture-specific assembly stubs for
> >> > 32-bit clone entry points.
> >> >
> >> > In the meantime, doing that *just* for 32-bit x86 on 64-bit x86 doesn't
> >> > seem worth it, since it would require adding a new C entry point for
> >> > compat_sys_clone under arch/x86 somewhere.
> >> >
> >> > One cleanup at a time. :)
> >>
> >> Fine w/ me.
> >
> > Thanks.
> >
> >> >
> >> >> In general, I much prefer C code to new asm where it makes sense to
> >> >> make this tradeoff.
> >> >
> >> > Agreed completely.  However, this is at least conservation-of-asm, or
> >> > reduction if you consider the pt_regs argument-grabbing hack to be
> >> > asm-esque code.
> >> >
> >> >> Other than that, this is a huge improvement.  You'll have minor
> >> >> conflicts against -tip, though.
> >> >
> >> > Right, I've seen your current changes there.  Should be a trivial merge
> >> > though.
> >> >
> >> > Would you mind providing an ack for the series, or at least for the
> >> > first two patches?
> >>
> >> I can give you an ok-in-principle on the first two.  I'd need to stare
> >> at the awful code for a bit to understand the @!*&! clone variants to
> >> really ack them convincingly.
> >
> > I'd definitely appreciate the staring. :)
> >
> >> OTOH, it would be rather surprising if you messed it up in a way that
> >> still boots on all three variants (native 32-bit, native 64-bit, and
> >> compat).
> >>
> >> So, for the first two patches:
> >>
> >> Acked-by: Andy Lutomirski  # assuming all bitnesses boot
> >
> > I did test all three, not just with booting but with a thread-local
> > storage test.
> 
> And it's fairly clear that no one ever tested clone-based TLS in 32
> bits from a 64-bit ELF binary, because it was broken until very
> recently :-/

I'm not sure *anyone* other than exploit-seekers test 32-bit system
calls from a 64-bit binary. :)

> This stuff is too magical and too poorly documented for my tastes.

Agreed.  That was my reaction when I figured out what was happening with
CLONE_SETTLS and pt_regs, and my goal with the first two patches in this
series was precisely to make it *less* magical. :)

- Josh Triplett
--
To unsubscrib

Re: [RFCv3 PATCH 30/48] sched: Calculate energy consumption of sched_group

2015-03-13 Thread Sai Gurrappadi
On 02/04/2015 10:31 AM, Morten Rasmussen wrote:
> For energy-aware load-balancing decisions it is necessary to know the
> energy consumption estimates of groups of cpus. This patch introduces a
> basic function, sched_group_energy(), which estimates the energy
> consumption of the cpus in the group and any resources shared by the
> members of the group.
> 
> NOTE: The function has five levels of identation and breaks the 80
> character limit. Refactoring is necessary.
> 
> cc: Ingo Molnar 
> cc: Peter Zijlstra 
> 
> Signed-off-by: Morten Rasmussen 
> ---
>  kernel/sched/fair.c | 143 
> 
>  1 file changed, 143 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 872ae0e..d12aa63 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4609,6 +4609,149 @@ static inline bool energy_aware(void)
>   return sched_feat(ENERGY_AWARE);
>  }
>  
> +/*
> + * cpu_norm_usage() returns the cpu usage relative to it's current capacity,
> + * i.e. it's busy ratio, in the range [0..SCHED_LOAD_SCALE] which is useful 
> for
> + * energy calculations. Using the scale-invariant usage returned by
> + * get_cpu_usage() and approximating scale-invariant usage by:
> + *
> + *   usage ~ (curr_freq/max_freq)*1024 * capacity_orig/1024 * 
> running_time/time
> + *
> + * the normalized usage can be found using capacity_curr.
> + *
> + *   capacity_curr = capacity_orig * curr_freq/max_freq
> + *
> + *   norm_usage = running_time/time ~ usage/capacity_curr
> + */
> +static inline unsigned long cpu_norm_usage(int cpu)
> +{
> + unsigned long capacity_curr = capacity_curr_of(cpu);
> +
> + return (get_cpu_usage(cpu) << SCHED_CAPACITY_SHIFT)/capacity_curr;
> +}
> +
> +static unsigned group_max_usage(struct sched_group *sg)
> +{
> + int i;
> + int max_usage = 0;
> +
> + for_each_cpu(i, sched_group_cpus(sg))
> + max_usage = max(max_usage, get_cpu_usage(i));
> +
> + return max_usage;
> +}
> +
> +/*
> + * group_norm_usage() returns the approximated group usage relative to it's
> + * current capacity (busy ratio) in the range [0..SCHED_LOAD_SCALE] for use 
> in
> + * energy calculations. Since task executions may or may not overlap in time 
> in
> + * the group the true normalized usage is between max(cpu_norm_usage(i)) and
> + * sum(cpu_norm_usage(i)) when iterating over all cpus in the group, i. The
> + * latter is used as the estimate as it leads to a more pessimistic energy
> + * estimate (more busy).
> + */
> +static unsigned group_norm_usage(struct sched_group *sg)
> +{
> + int i;
> + unsigned long usage_sum = 0;
> +
> + for_each_cpu(i, sched_group_cpus(sg))
> + usage_sum += cpu_norm_usage(i);
> +
> + if (usage_sum > SCHED_CAPACITY_SCALE)
> + return SCHED_CAPACITY_SCALE;
> + return usage_sum;
> +}
> +
> +static int find_new_capacity(struct sched_group *sg,
> + struct sched_group_energy *sge)
> +{
> + int idx;
> + unsigned long util = group_max_usage(sg);
> +
> + for (idx = 0; idx < sge->nr_cap_states; idx++) {
> + if (sge->cap_states[idx].cap >= util)
> + return idx;
> + }
> +
> + return idx;
> +}
> +
> +/*
> + * sched_group_energy(): Returns absolute energy consumption of cpus 
> belonging
> + * to the sched_group including shared resources shared only by members of 
> the
> + * group. Iterates over all cpus in the hierarchy below the sched_group 
> starting
> + * from the bottom working it's way up before going to the next cpu until all
> + * cpus are covered at all levels. The current implementation is likely to
> + * gather the same usage statistics multiple times. This can probably be 
> done in
> + * a faster but more complex way.
> + */
> +static unsigned int sched_group_energy(struct sched_group *sg_top)
> +{
> + struct sched_domain *sd;
> + int cpu, total_energy = 0;
> + struct cpumask visit_cpus;
> + struct sched_group *sg;
> +
> + WARN_ON(!sg_top->sge);
> +
> + cpumask_copy(&visit_cpus, sched_group_cpus(sg_top));
> +
> + while (!cpumask_empty(&visit_cpus)) {
> + struct sched_group *sg_shared_cap = NULL;
> +
> + cpu = cpumask_first(&visit_cpus);
> +
> + /*
> +  * Is the group utilization affected by cpus outside this
> +  * sched_group?
> +  */
> + sd = highest_flag_domain(cpu, SD_SHARE_CAP_STATES);
> + if (sd && sd->parent)
> + sg_shared_cap = sd->parent->groups;

The above bit looks like it avoids supporting SD_SHARE_CAP_STATES for
the top level sd (!sd->parent). Is it because there is no group that
spans all the CPUs spanned by this sd? It seems like sg_cap is just
being used as a proxy for the cpumask of CPUs to check for max_usage.

> +
> + for_each_domain(cpu, sd) {
> + sg = sd->groups;
> +
> + /* 

[PATCH 2/4] CLK: TI: OMAP5: Correct the DT clock aliases for timers

2015-03-13 Thread Suman Anna
The DT clock aliases for Timers use the legacy (non-DT) device
names and a source clock named sys_ck. OMAP5 is DT-boot only,
so correct the DT clock aliases to use the DT device names
instead. Also, the source clock name is corrected from 'sys_ck'
to 'timer_sys_ck', the name used by the OMAP dmtimer driver.

Signed-off-by: Suman Anna 
---
 drivers/clk/ti/clk-54xx.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/ti/clk-54xx.c b/drivers/clk/ti/clk-54xx.c
index 14160b223548..96c69a335975 100644
--- a/drivers/clk/ti/clk-54xx.c
+++ b/drivers/clk/ti/clk-54xx.c
@@ -208,17 +208,17 @@ static struct ti_dt_clk omap54xx_clks[] = {
DT_CLK("usbhs_omap", "usbtll_fck", "dummy_ck"),
DT_CLK("omap_wdt", "ick", "dummy_ck"),
DT_CLK(NULL, "timer_32k_ck", "sys_32k_ck"),
-   DT_CLK("omap_timer.1", "sys_ck", "sys_clkin"),
-   DT_CLK("omap_timer.2", "sys_ck", "sys_clkin"),
-   DT_CLK("omap_timer.3", "sys_ck", "sys_clkin"),
-   DT_CLK("omap_timer.4", "sys_ck", "sys_clkin"),
-   DT_CLK("omap_timer.9", "sys_ck", "sys_clkin"),
-   DT_CLK("omap_timer.10", "sys_ck", "sys_clkin"),
-   DT_CLK("omap_timer.11", "sys_ck", "sys_clkin"),
-   DT_CLK("omap_timer.5", "sys_ck", "dss_syc_gfclk_div"),
-   DT_CLK("omap_timer.6", "sys_ck", "dss_syc_gfclk_div"),
-   DT_CLK("omap_timer.7", "sys_ck", "dss_syc_gfclk_div"),
-   DT_CLK("omap_timer.8", "sys_ck", "dss_syc_gfclk_div"),
+   DT_CLK("4ae18000.timer", "timer_sys_ck", "sys_clkin"),
+   DT_CLK("48032000.timer", "timer_sys_ck", "sys_clkin"),
+   DT_CLK("48034000.timer", "timer_sys_ck", "sys_clkin"),
+   DT_CLK("48036000.timer", "timer_sys_ck", "sys_clkin"),
+   DT_CLK("4803e000.timer", "timer_sys_ck", "sys_clkin"),
+   DT_CLK("48086000.timer", "timer_sys_ck", "sys_clkin"),
+   DT_CLK("48088000.timer", "timer_sys_ck", "sys_clkin"),
+   DT_CLK("40138000.timer", "timer_sys_ck", "dss_syc_gfclk_div"),
+   DT_CLK("4013a000.timer", "timer_sys_ck", "dss_syc_gfclk_div"),
+   DT_CLK("4013c000.timer", "timer_sys_ck", "dss_syc_gfclk_div"),
+   DT_CLK("4013e000.timer", "timer_sys_ck", "dss_syc_gfclk_div"),
{ .node_name = NULL },
 };
 
-- 
2.3.2

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


[PATCH 4/4] CLK: TI: DRA7: Add timer_sys_ck aliases for Timers 13 through 16

2015-03-13 Thread Suman Anna
The OMAP DMTimer API, omap_dm_timer_set_source(), uses the clock name
timer_sys_ck for setting a timer's clock source for the source index
OMAP_TIMER_SRC_SYS_CLK. There is currently no clock alias data for
the Timers 13 through 16 for this clock name, so add the same.

Signed-off-by: Suman Anna 
---
 drivers/clk/ti/clk-7xx.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 256295eb5157..5d2217ae4478 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -300,6 +300,10 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK("48822000.timer", "timer_sys_ck", "timer_sys_clk_div"),
DT_CLK("48824000.timer", "timer_sys_ck", "timer_sys_clk_div"),
DT_CLK("48826000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+   DT_CLK("48828000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+   DT_CLK("4882a000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+   DT_CLK("4882c000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+   DT_CLK("4882e000.timer", "timer_sys_ck", "timer_sys_clk_div"),
DT_CLK(NULL, "sys_clkin", "sys_clkin1"),
{ .node_name = NULL },
 };
-- 
2.3.2

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


[PATCH 0/4] CLK: TI: Timer clock alias fixes

2015-03-13 Thread Suman Anna
Hi Tero,

Please find couple of cleanup/fixes on the DT clock aliases
for the GPTimers. Patches are based on 4.0-rc1 and following
is the summary of the changes,

1. Patch 1 is a cleanup for OMAP4
2. Patch 2 fixes the failures for OMAP5 if omap_dm_timer_set_source() API is
   called to set the parent of any timer using OMAP_TIMER_SRC_SYS_CLK.
3. Patch 3 is for DRA7 and fixes the parent to be set to timer_sys_clk_div
   and not sys_clkin2, which is an optional clock input.
4. Patch 4 adds the DT CLK aliases for GPTimers 13 through 16 on DRA7. These
   timer nodes are currently missing in DTS, and I will be sending the patches
   for them soon.

regards
Suman

Suman Anna (4):
  CLK: TI: OMAP4: Remove the legacy timer DT clock aliases
  CLK: TI: OMAP5: Correct the DT clock aliases for timers
  CLK: TI: DRA7: Correct timer_sys_ck clock aliases for Timers
  CLK: TI: DRA7: Add timer_sys_ck aliases for Timers 13 through 16

 drivers/clk/ti/clk-44xx.c | 11 ---
 drivers/clk/ti/clk-54xx.c | 22 +++---
 drivers/clk/ti/clk-7xx.c  | 18 +++---
 3 files changed, 22 insertions(+), 29 deletions(-)

-- 
2.3.2

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


[PATCH 3/4] CLK: TI: DRA7: Correct timer_sys_ck clock aliases for Timers

2015-03-13 Thread Suman Anna
The OMAP DMTimer API, omap_dm_timer_set_source(), can set the parent
of a timer node using 3 different values that use fixed parent names
for the clocks. The parent name, timer_sys_ck, is used for setting the
parent when used with the source index OMAP_TIMER_SRC_SYS_CLK. This
should point to the TIMER_SYS_CLK and not the SYSCLKIN2, so correct
the clock aliases appropriately. SYSCLKIN2 is not a mandatory clock
input.

Signed-off-by: Suman Anna 
---
 drivers/clk/ti/clk-7xx.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index ee32f4deebf4..256295eb5157 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -289,13 +289,13 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK("usbhs_omap", "usbtll_fck", "dummy_ck"),
DT_CLK("omap_wdt", "ick", "dummy_ck"),
DT_CLK(NULL, "timer_32k_ck", "sys_32k_ck"),
-   DT_CLK("4ae18000.timer", "timer_sys_ck", "sys_clkin2"),
-   DT_CLK("48032000.timer", "timer_sys_ck", "sys_clkin2"),
-   DT_CLK("48034000.timer", "timer_sys_ck", "sys_clkin2"),
-   DT_CLK("48036000.timer", "timer_sys_ck", "sys_clkin2"),
-   DT_CLK("4803e000.timer", "timer_sys_ck", "sys_clkin2"),
-   DT_CLK("48086000.timer", "timer_sys_ck", "sys_clkin2"),
-   DT_CLK("48088000.timer", "timer_sys_ck", "sys_clkin2"),
+   DT_CLK("4ae18000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+   DT_CLK("48032000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+   DT_CLK("48034000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+   DT_CLK("48036000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+   DT_CLK("4803e000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+   DT_CLK("48086000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+   DT_CLK("48088000.timer", "timer_sys_ck", "timer_sys_clk_div"),
DT_CLK("4882.timer", "timer_sys_ck", "timer_sys_clk_div"),
DT_CLK("48822000.timer", "timer_sys_ck", "timer_sys_clk_div"),
DT_CLK("48824000.timer", "timer_sys_ck", "timer_sys_clk_div"),
-- 
2.3.2

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


[PATCH 1/4] CLK: TI: OMAP4: Remove the legacy timer DT clock aliases

2015-03-13 Thread Suman Anna
The DT clock aliases for timers using the legacy OMAP timer
device names have been cleaned up. These device names reflect
the names used in legacy boot, and are no longer applicable
as OMAP4 is DT boot only now.

Signed-off-by: Suman Anna 
---
 drivers/clk/ti/clk-44xx.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index 4f4c87751db5..581db7711f51 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -249,17 +249,6 @@ static struct ti_dt_clk omap44xx_clks[] = {
DT_CLK("usbhs_tll", "usbtll_fck", "dummy_ck"),
DT_CLK("omap_wdt", "ick", "dummy_ck"),
DT_CLK(NULL, "timer_32k_ck", "sys_32k_ck"),
-   DT_CLK("omap_timer.1", "timer_sys_ck", "sys_clkin_ck"),
-   DT_CLK("omap_timer.2", "timer_sys_ck", "sys_clkin_ck"),
-   DT_CLK("omap_timer.3", "timer_sys_ck", "sys_clkin_ck"),
-   DT_CLK("omap_timer.4", "timer_sys_ck", "sys_clkin_ck"),
-   DT_CLK("omap_timer.9", "timer_sys_ck", "sys_clkin_ck"),
-   DT_CLK("omap_timer.10", "timer_sys_ck", "sys_clkin_ck"),
-   DT_CLK("omap_timer.11", "timer_sys_ck", "sys_clkin_ck"),
-   DT_CLK("omap_timer.5", "timer_sys_ck", "syc_clk_div_ck"),
-   DT_CLK("omap_timer.6", "timer_sys_ck", "syc_clk_div_ck"),
-   DT_CLK("omap_timer.7", "timer_sys_ck", "syc_clk_div_ck"),
-   DT_CLK("omap_timer.8", "timer_sys_ck", "syc_clk_div_ck"),
DT_CLK("4a318000.timer", "timer_sys_ck", "sys_clkin_ck"),
DT_CLK("48032000.timer", "timer_sys_ck", "sys_clkin_ck"),
DT_CLK("48034000.timer", "timer_sys_ck", "sys_clkin_ck"),
-- 
2.3.2

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


[PATCH 1/2] selftests: add ability to run and emit script for tests args to lib.mk

2015-03-13 Thread Shuah Khan
Add ability to run, emit, install tests take arguments to the
shared logic in lib.mk. lib.mk provides a way to override the
default RUN_TESTS and EMIT_TESTS, however in the cases where a
test has several executables that don't require any special args
and/or handling and some that do, overrding will be cumbersome.
Add variables RUN_TESTS_WITH_ARGS, and EMIT_TESTS_WITH_ARGS to
enable a test to run and exmit script for such special executables.

Signed-off-by: Shuah Khan 
---
 tools/testing/selftests/lib.mk | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 7bd3dab..78cdf91 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -6,6 +6,9 @@ endef
 
 run_tests: all
$(RUN_TESTS)
+ifdef RUN_TESTS_WITH_ARGS
+   $(RUN_TESTS_WITH_ARGS)
+endif
 
 define INSTALL_RULE
mkdir -p $(INSTALL_PATH)
@@ -27,5 +30,8 @@ endef
 
 emit_tests:
$(EMIT_TESTS)
+ifdef EMIT_TESTS_WITH_ARGS
+   $(EMIT_TESTS_WITH_ARGS)
+endif
 
 .PHONY: run_tests all clean install emit_tests
-- 
2.1.0

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


[PATCH 2/2] selftests/timers: change to use shared logic to run and install tests

2015-03-13 Thread Shuah Khan
Change the timers Makefile to make use of shared run and install
logic in lib.mk. Destructive tests are installed. Regular tests
are emited to run_kselftest script to match the run_tests behavior.

Signed-off-by: Shuah Khan 
---
 tools/testing/selftests/timers/Makefile | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/tools/testing/selftests/timers/Makefile 
b/tools/testing/selftests/timers/Makefile
index 9da3498..61e7284 100644
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@ -7,19 +7,21 @@ bins = posix_timers nanosleep inconsistency-check nsleep-lat 
raw_skew \
alarmtimer-suspend change_skew skew_consistency clocksource-switch \
leap-a-day leapcrash set-tai set-2038
 
+TEST_PROGS = posix_timers nanosleep nsleep-lat set-timer-lat mqueue-lat \
+   inconsistency-check raw_skew
+TEST_FILES = threadtest alarmtimer-suspend valid-adjtimex change_skew \
+   skew_consistency clocksource-switch leap-a-day leapcrash \
+   set-tai set-2038
+
+RUN_TESTS_WITH_ARGS := ./threadtest -t 30 -n 8 || echo "selftests: threadtest 
[FAIL]"
+
+EMIT_TESTS_WITH_ARGS := echo "$(RUN_TESTS_WITH_ARGS)"
+
 all: ${bins}
 
 # these are all "safe" tests that don't modify
 # system time or require escalated privledges
-run_tests: all
-   ./posix_timers
-   ./nanosleep
-   ./nsleep-lat
-   ./set-timer-lat
-   ./mqueue-lat
-   ./inconsistency-check
-   ./raw_skew
-   ./threadtest -t 30 -n 8
+include ../lib.mk
 
 # these tests require escalated privledges
 # and may modify the system time or trigger
-- 
2.1.0

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


[PATCH 0/2] Changes to timers Maefile to use shared logic for run_tests and install

2015-03-13 Thread Shuah Khan
This patch set:

adds ability to run and emit script for tests args to lib.mk.
lib.mk provides a way to override the default RUN_TESTS and
EMIT_TESTS, however in the cases where a test has several
executables that don't require any special args and/or handling
and some that do, overrding will be cumbersome. Add variables
RUN_TESTS_WITH_ARGS, and EMIT_TESTS_WITH_ARGS to enable a test to
run and exmit script for such special executables.

Timers test Makefile is changed to use the shared logic for running
and installing tests.

Shuah Khan (2):
  selftests: add ability to run and emit script for tests args to lib.mk
  selftests/timers: change to use shared logic to run and install tests

 tools/testing/selftests/lib.mk  |  6 ++
 tools/testing/selftests/timers/Makefile | 20 +++-
 2 files changed, 17 insertions(+), 9 deletions(-)

-- 
2.1.0

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


[PATCH V2 2/5] MIPS: Allow platforms to specify the decompressor load address

2015-03-13 Thread Andrew Bresticker
Platforms which use raw zboot images may need to link the image at
a fixed address if there is no other way to communicate the load
address to the bootloader.  Allow the per-platform Kbuild files
to specify an optional zboot image load address (zload-y) and fall
back to calc_vmlinuz_load_addr if unset.

Signed-off-by: Andrew Bresticker 
Cc: Lars-Peter Clausen 
---
No changes from v1.
---
 arch/mips/boot/compressed/Makefile | 6 --
 arch/mips/jz4740/Platform  | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/mips/boot/compressed/Makefile 
b/arch/mips/boot/compressed/Makefile
index 61af6b6..82d0b13 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -12,6 +12,8 @@
 # Author: Wu Zhangjin 
 #
 
+include $(srctree)/arch/mips/Kbuild.platforms
+
 # set the default size of the mallocing area for decompressing
 BOOT_HEAP_SIZE := 0x40
 
@@ -66,8 +68,8 @@ $(obj)/piggy.o: $(obj)/dummy.o $(obj)/vmlinux.bin.z FORCE
 # Calculate the load address of the compressed kernel image
 hostprogs-y := calc_vmlinuz_load_addr
 
-ifeq ($(CONFIG_MACH_JZ4740),y)
-VMLINUZ_LOAD_ADDRESS := 0x8060
+ifneq ($(zload-y),)
+VMLINUZ_LOAD_ADDRESS := $(zload-y)
 else
 VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \
$(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS))
diff --git a/arch/mips/jz4740/Platform b/arch/mips/jz4740/Platform
index ba91be9..c41d300 100644
--- a/arch/mips/jz4740/Platform
+++ b/arch/mips/jz4740/Platform
@@ -1,3 +1,4 @@
 platform-$(CONFIG_MACH_JZ4740) += jz4740/
 cflags-$(CONFIG_MACH_JZ4740)   += 
-I$(srctree)/arch/mips/include/asm/mach-jz4740
 load-$(CONFIG_MACH_JZ4740) += 0x8001
+zload-$(CONFIG_MACH_JZ4740)+= 0x8060
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] MIPS: Create a common

2015-03-13 Thread Andrew Bresticker
From: Kevin Cernekee 

11 platforms require at least one of these workarounds to be enabled; 22
platforms do not.  In the latter case we can fall back to a generic version.

Note that this also deletes an orphaned reference to RM9000_CDEX_SMP_WAR.

Suggested-by: Arnd Bergmann 
Signed-off-by: Kevin Cernekee 
Signed-off-by: Andrew Bresticker 
---
No changes from v1.
Changes from Kevin's v6:
 - Left cavium-octeon's war.h in-tact
---
 arch/mips/include/asm/mach-ar7/war.h   | 24 
 arch/mips/include/asm/mach-ath25/war.h | 25 -
 arch/mips/include/asm/mach-ath79/war.h | 24 
 arch/mips/include/asm/mach-au1x00/war.h| 24 
 arch/mips/include/asm/mach-bcm3384/war.h   | 24 
 arch/mips/include/asm/mach-bcm47xx/war.h   | 24 
 arch/mips/include/asm/mach-bcm63xx/war.h   | 24 
 arch/mips/include/asm/mach-cobalt/war.h| 24 
 arch/mips/include/asm/mach-dec/war.h   | 24 
 arch/mips/include/asm/mach-emma2rh/war.h   | 24 
 arch/mips/include/asm/mach-generic/war.h   | 24 
 arch/mips/include/asm/mach-jazz/war.h  | 24 
 arch/mips/include/asm/mach-jz4740/war.h| 24 
 arch/mips/include/asm/mach-lantiq/war.h| 23 ---
 arch/mips/include/asm/mach-lasat/war.h | 24 
 arch/mips/include/asm/mach-loongson/war.h  | 24 
 arch/mips/include/asm/mach-loongson1/war.h | 24 
 arch/mips/include/asm/mach-netlogic/war.h  | 25 -
 arch/mips/include/asm/mach-paravirt/war.h  | 25 -
 arch/mips/include/asm/mach-pnx833x/war.h   | 24 
 arch/mips/include/asm/mach-ralink/war.h| 24 
 arch/mips/include/asm/mach-tx39xx/war.h| 24 
 arch/mips/include/asm/mach-vr41xx/war.h| 24 
 23 files changed, 24 insertions(+), 530 deletions(-)
 delete mode 100644 arch/mips/include/asm/mach-ar7/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath25/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath79/war.h
 delete mode 100644 arch/mips/include/asm/mach-au1x00/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm3384/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm47xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm63xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-cobalt/war.h
 delete mode 100644 arch/mips/include/asm/mach-dec/war.h
 delete mode 100644 arch/mips/include/asm/mach-emma2rh/war.h
 create mode 100644 arch/mips/include/asm/mach-generic/war.h
 delete mode 100644 arch/mips/include/asm/mach-jazz/war.h
 delete mode 100644 arch/mips/include/asm/mach-jz4740/war.h
 delete mode 100644 arch/mips/include/asm/mach-lantiq/war.h
 delete mode 100644 arch/mips/include/asm/mach-lasat/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson1/war.h
 delete mode 100644 arch/mips/include/asm/mach-netlogic/war.h
 delete mode 100644 arch/mips/include/asm/mach-paravirt/war.h
 delete mode 100644 arch/mips/include/asm/mach-pnx833x/war.h
 delete mode 100644 arch/mips/include/asm/mach-ralink/war.h
 delete mode 100644 arch/mips/include/asm/mach-tx39xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-vr41xx/war.h

diff --git a/arch/mips/include/asm/mach-ar7/war.h 
b/arch/mips/include/asm/mach-ar7/war.h
deleted file mode 100644
index 99071e5..000
--- a/arch/mips/include/asm/mach-ar7/war.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 2002, 2004, 2007 by Ralf Baechle 
- */
-#ifndef __ASM_MIPS_MACH_AR7_WAR_H
-#define __ASM_MIPS_MACH_AR7_WAR_H
-
-#define R4600_V1_INDEX_ICACHEOP_WAR0
-#define R4600_V1_HIT_CACHEOP_WAR   0
-#define R4600_V2_HIT_CACHEOP_WAR   0
-#define R5432_CP0_INTERRUPT_WAR0
-#define BCM1250_M3_WAR 0
-#define SIBYTE_1956_WAR0
-#define MIPS4K_ICACHE_REFILL_WAR   0
-#define MIPS_CACHE_SYNC_WAR0
-#define TX49XX_ICACHE_INDEX_INV_WAR0
-#define ICACHE_REFILLS_WORKAROUND_WAR  0
-#define R1_LLSC_WAR0
-#define MIPS34K_MISSED_ITLB_WAR0
-
-#endif /* __ASM_MIPS_MACH_AR7_WAR_H */
diff --git a/arch/mips/include/asm/mach-ath25/war.h 
b/arch/mips/include/asm/mach-ath25/war.h
deleted file mode 100644
index e3a5250..000
--- a/arch/mips/include/asm/mach-ath25/war.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See 

[PATCH V2 4/5] MIPS: Add support for the IMG Pistachio SoC

2015-03-13 Thread Andrew Bresticker
Add initial support for boards based on the Imagination Pistachio SoC.
Pistachio is based on a dual-core MIPS interAptiv CPU and will boot
using device-tree.

Signed-off-by: James Hartley 
Signed-off-by: Andrew Bresticker 
---
Changes from v1:
 - switched to MIPS UHI hand-off protocol
---
 arch/mips/Kbuild.platforms  |   1 +
 arch/mips/Kconfig   |  27 ++
 arch/mips/include/asm/mach-pistachio/gpio.h |  21 +
 arch/mips/include/asm/mach-pistachio/irq.h  |  18 
 arch/mips/pistachio/Makefile|   1 +
 arch/mips/pistachio/Platform|   8 ++
 arch/mips/pistachio/init.c  | 131 
 arch/mips/pistachio/irq.c   |  28 ++
 arch/mips/pistachio/time.c  |  52 +++
 9 files changed, 287 insertions(+)
 create mode 100644 arch/mips/include/asm/mach-pistachio/gpio.h
 create mode 100644 arch/mips/include/asm/mach-pistachio/irq.h
 create mode 100644 arch/mips/pistachio/Makefile
 create mode 100644 arch/mips/pistachio/Platform
 create mode 100644 arch/mips/pistachio/init.c
 create mode 100644 arch/mips/pistachio/irq.c
 create mode 100644 arch/mips/pistachio/time.c

diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
index e5fc463..2298baa 100644
--- a/arch/mips/Kbuild.platforms
+++ b/arch/mips/Kbuild.platforms
@@ -23,6 +23,7 @@ platforms += netlogic
 platforms += paravirt
 platforms += pmcs-msp71xx
 platforms += pnx833x
+platforms += pistachio
 platforms += ralink
 platforms += rb532
 platforms += sgi-ip22
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index c7a1690..343b238 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -352,6 +352,33 @@ config MACH_LOONGSON1
  the ICT (Institute of Computing Technology) and the Chinese Academy
  of Sciences.
 
+config MACH_PISTACHIO
+   bool "IMG Pistachio SoC based boards"
+   select ARCH_REQUIRE_GPIOLIB
+   select BOOT_ELF32
+   select BOOT_RAW
+   select CEVT_R4K
+   select CLKSRC_MIPS_GIC
+   select COMMON_CLK
+   select CSRC_R4K
+   select DMA_MAYBE_COHERENT
+   select IRQ_CPU
+   select LIBFDT
+   select MFD_SYSCON
+   select MIPS_CPU_SCACHE
+   select MIPS_GIC
+   select PINCTRL
+   select REGULATOR
+   select SYS_HAS_CPU_MIPS32_R2
+   select SYS_SUPPORTS_32BIT_KERNEL
+   select SYS_SUPPORTS_LITTLE_ENDIAN
+   select SYS_SUPPORTS_MIPS_CPS
+   select SYS_SUPPORTS_MULTITHREADING
+   select SYS_SUPPORTS_ZBOOT
+   select USE_OF
+   help
+ This enables support for the IMG Pistachio SoC platform.
+
 config MIPS_MALTA
bool "MIPS Malta board"
select ARCH_MAY_HAVE_PC_FDC
diff --git a/arch/mips/include/asm/mach-pistachio/gpio.h 
b/arch/mips/include/asm/mach-pistachio/gpio.h
new file mode 100644
index 000..6c1649c
--- /dev/null
+++ b/arch/mips/include/asm/mach-pistachio/gpio.h
@@ -0,0 +1,21 @@
+/*
+ * Pistachio IRQ setup
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MACH_PISTACHIO_GPIO_H
+#define __ASM_MACH_PISTACHIO_GPIO_H
+
+#include 
+
+#define gpio_get_value __gpio_get_value
+#define gpio_set_value __gpio_set_value
+#define gpio_cansleep  __gpio_cansleep
+#define gpio_to_irq__gpio_to_irq
+
+#endif /* __ASM_MACH_PISTACHIO_GPIO_H */
diff --git a/arch/mips/include/asm/mach-pistachio/irq.h 
b/arch/mips/include/asm/mach-pistachio/irq.h
new file mode 100644
index 000..b94a09a
--- /dev/null
+++ b/arch/mips/include/asm/mach-pistachio/irq.h
@@ -0,0 +1,18 @@
+/*
+ * Pistachio IRQ setup
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MACH_PISTACHIO_IRQ_H
+#define __ASM_MACH_PISTACHIO_IRQ_H
+
+#define NR_IRQS 256
+
+#include_next 
+
+#endif /* __ASM_MACH_PISTACHIO_IRQ_H */
diff --git a/arch/mips/pistachio/Makefile b/arch/mips/pistachio/Makefile
new file mode 100644
index 000..32189c6
--- /dev/null
+++ b/arch/mips/pistachio/Makefile
@@ -0,0 +1 @@
+obj-y  += init.o irq.o time.o
diff --git a/arch/mips/pistachio/Platform b/arch/mips/pistachio/Platform
new file mode 100644
index 000..d80cd61
--- /dev/null
+++ b/arch/mips/pistachio/Platform
@@ -0,0 +1,8 @@
+#
+# IMG Pistachio SoC
+#
+platform-$(CONFIG_MACH_PISTACHIO)  += pistachio/
+cflags-$(CONFIG_MACH_PISTACHIO)+=  
\
+   -I$(srctree)/arch/mips/include/asm/mach-pistachio
+load-$(CONFIG_MACH_PISTACHIO)  += 0x8040
+zload-$(CONFIG_MACH_PISTACHIO) += 0x8100
diff --git a/arch/m

[PATCH V2 5/5] MIPS: pistachio: Add an initial defconfig

2015-03-13 Thread Andrew Bresticker
From: Govindraj Raja 

Add a defconfig for Pistachio which enables drivers for all the
currently supported peripherals on the SoC.

Signed-off-by: Govindraj Raja 
Signed-off-by: Andrew Bresticker 
---
No changes from v1.
---
 arch/mips/configs/pistachio_defconfig | 336 ++
 1 file changed, 336 insertions(+)
 create mode 100644 arch/mips/configs/pistachio_defconfig

diff --git a/arch/mips/configs/pistachio_defconfig 
b/arch/mips/configs/pistachio_defconfig
new file mode 100644
index 000..f22e92e
--- /dev/null
+++ b/arch/mips/configs/pistachio_defconfig
@@ -0,0 +1,336 @@
+CONFIG_MACH_PISTACHIO=y
+CONFIG_MIPS_MT_SMP=y
+CONFIG_MIPS_CPS=y
+# CONFIG_COMPACTION is not set
+CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
+CONFIG_ZSMALLOC=y
+CONFIG_NR_CPUS=4
+CONFIG_PREEMPT_VOLUNTARY=y
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_DEFAULT_HOSTNAME="localhost"
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_IKCONFIG=m
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=18
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_CFS_BANDWIDTH=y
+CONFIG_NAMESPACES=y
+CONFIG_USER_NS=y
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_EMBEDDED=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_PROFILING=y
+CONFIG_CC_STACKPROTECTOR_STRONG=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_PM_DEBUG=y
+CONFIG_PM_ADVANCED_DEBUG=y
+CONFIG_CPU_IDLE=y
+# CONFIG_MIPS_CPS_CPUIDLE is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_NET_KEY=m
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_PIMSM_V1=y
+CONFIG_IP_PIMSM_V2=y
+CONFIG_SYN_COOKIES=y
+CONFIG_INET_AH=m
+CONFIG_INET_ESP=m
+CONFIG_INET_IPCOMP=m
+CONFIG_INET_XFRM_MODE_TRANSPORT=m
+CONFIG_INET_XFRM_MODE_TUNNEL=m
+CONFIG_INET_XFRM_MODE_BEET=m
+# CONFIG_INET_DIAG is not set
+CONFIG_TCP_CONG_ADVANCED=y
+# CONFIG_TCP_CONG_BIC is not set
+# CONFIG_TCP_CONG_WESTWOOD is not set
+# CONFIG_TCP_CONG_HTCP is not set
+CONFIG_TCP_CONG_LP=m
+CONFIG_TCP_MD5SIG=y
+CONFIG_IPV6=y
+CONFIG_INET6_AH=m
+CONFIG_INET6_ESP=m
+CONFIG_INET6_XFRM_MODE_TRANSPORT=m
+CONFIG_INET6_XFRM_MODE_TUNNEL=m
+CONFIG_INET6_XFRM_MODE_BEET=m
+CONFIG_IPV6_SIT=m
+CONFIG_NETWORK_SECMARK=y
+CONFIG_NETFILTER=y
+# CONFIG_BRIDGE_NETFILTER is not set
+CONFIG_NF_CONNTRACK=y
+CONFIG_NF_CT_NETLINK=y
+CONFIG_NETFILTER_XT_MARK=m
+CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
+CONFIG_NETFILTER_XT_TARGET_DSCP=y
+CONFIG_NETFILTER_XT_TARGET_NFLOG=y
+CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
+CONFIG_NETFILTER_XT_TARGET_SECMARK=y
+CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
+CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
+CONFIG_NETFILTER_XT_MATCH_DSCP=y
+CONFIG_NETFILTER_XT_MATCH_POLICY=y
+CONFIG_NETFILTER_XT_MATCH_STATE=y
+CONFIG_NF_CONNTRACK_IPV4=y
+CONFIG_NF_NAT_IPV4=m
+CONFIG_IP_NF_IPTABLES=y
+CONFIG_IP_NF_FILTER=y
+CONFIG_IP_NF_TARGET_REJECT=y
+CONFIG_IP_NF_MANGLE=y
+CONFIG_NF_CONNTRACK_IPV6=m
+CONFIG_NF_NAT_IPV6=m
+CONFIG_IP6_NF_IPTABLES=m
+CONFIG_IP6_NF_MATCH_IPV6HEADER=m
+CONFIG_IP6_NF_FILTER=m
+CONFIG_IP6_NF_TARGET_REJECT=m
+CONFIG_IP6_NF_MANGLE=m
+CONFIG_BRIDGE=m
+CONFIG_VLAN_8021Q=m
+CONFIG_NET_SCHED=y
+CONFIG_NET_SCH_HTB=m
+CONFIG_NET_SCH_CODEL=m
+CONFIG_NET_SCH_FQ_CODEL=m
+CONFIG_NET_CLS_U32=m
+CONFIG_CLS_U32_MARK=y
+CONFIG_BT=m
+CONFIG_BT_RFCOMM=m
+CONFIG_BT_HCIBTUSB=m
+CONFIG_BT_HCIBFUSB=m
+CONFIG_BT_HCIVHCI=m
+CONFIG_CFG80211=m
+CONFIG_NL80211_TESTMODE=y
+CONFIG_CFG80211_DEBUGFS=y
+CONFIG_CFG80211_WEXT=y
+CONFIG_MAC80211=m
+CONFIG_MAC80211_LEDS=y
+CONFIG_MAC80211_DEBUGFS=y
+CONFIG_MAC80211_DEBUG_MENU=y
+CONFIG_MAC80211_VERBOSE_DEBUG=y
+CONFIG_RFKILL=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_DEBUG_DEVRES=y
+CONFIG_CONNECTOR=y
+CONFIG_MTD=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_BLOCK=y
+CONFIG_ZRAM=m
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_DEV_SR=m
+CONFIG_SCSI_SPI_ATTRS=y
+CONFIG_MD=y
+CONFIG_BLK_DEV_DM=y
+CONFIG_DM_CRYPT=y
+CONFIG_DM_VERITY=y
+CONFIG_NETDEVICES=y
+CONFIG_TUN=m
+CONFIG_VETH=m
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+CONFIG_STMMAC_ETH=y
+# CONFIG_NET_VENDOR_VIA is not set
+CONFIG_PPP=m
+CONFIG_PPP_ASYNC=m
+CONFIG_USB_PEGASUS=m
+CONFIG_USB_RTL8150=m
+CONFIG_USB_RTL8152=m
+CONFIG_USB_NET_DM9601=m
+CONFIG_USB_NET_SMSC75XX=m
+CONFIG_USB_NET_SMSC95XX=m
+CONFIG_USB_NET_MCS7830=m
+# CONFIG_USB_NET_CDC_SUBSET is not set
+# CONFIG_USB_NET_ZAURUS is not set
+CONFIG_LIBERTAS_THINFIRM=m
+CONFIG_USB_NET_RNDIS_WLAN=m
+CONFIG_MAC80211_HWSIM=m
+CONFIG_HOSTAP=m
+CONFIG_HOSTAP_FIRMWARE=y

[PATCH V2 3/5] MIPS: Document Pistachio boot protocol and device-tree bindings

2015-03-13 Thread Andrew Bresticker
The Pistachio SoC boots only with device-tree.  Document the required
properties and nodes as well as the boot protocol between the bootlaoder
and the kernel.

Signed-off-by: Andrew Bresticker 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
---
Changes from v1:
 - switched to MIPS UHI hand-off protocol
---
 .../devicetree/bindings/mips/img/pistachio.txt | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/img/pistachio.txt

diff --git a/Documentation/devicetree/bindings/mips/img/pistachio.txt 
b/Documentation/devicetree/bindings/mips/img/pistachio.txt
new file mode 100644
index 000..a736d88
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/img/pistachio.txt
@@ -0,0 +1,42 @@
+Imagination Pistachio SoC
+=
+
+Required properties:
+
+ - compatible: Must include "img,pistachio".
+
+CPU nodes:
+--
+A "cpus" node is required.  Required properties:
+ - #address-cells: Must be 1.
+ - #size-cells: Must be 0.
+A CPU sub-node is also required for at least CPU 0.  Since the topology may
+be probed via CPS, it is not necessary to specify secondary CPUs.  Required
+propertis:
+ - device_type: Must be "cpu".
+ - compatible: Must be "mti,interaptiv".
+ - reg: CPU number.
+ - clocks: Must include the CPU clock.  See ../../clock/clock-bindings.txt for
+   details on clock bindings.
+Example:
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "mti,interaptiv";
+   reg = <0>;
+   clocks = <&clk_core CLK_MIPS>;
+   };
+   };
+
+
+Boot protocol:
+--
+In accordance with the MIPS UHI specification[1], the bootloader must pass the
+following arguments to the kernel:
+ - $a0: -2.
+ - $a1: KSEG0 address of the flattened device-tree blob.
+
+[1] http://prplfoundation.org/wiki/MIPS_documentation
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/5] MIPS: Initial IMG Pistachio SoC support

2015-03-13 Thread Andrew Bresticker
This series adds basic support for the Imagination Technologies Pistachio
SoC.  Pistachio will boot using device-tree only.  v4.0-rc1 already includes
support for several of the peripherals on Pistachio, including MMC, SPI,
I2C, DMA, watchdog timer, PWM, and IR.  Clock and pinctrl support for
Pistachio is coming soon, as well as an initial device-tree and support
for USB and ethernet.

Patches 1 and 2 are cleanups in preparation for adding Pistachio support,
with patch 1 having been posted by Kevin late last year [1].  Patch 3
documents Pistachio's required device-tree properties/nodes and its boot
protocol.  Patch 4 adds support for Pistachio itself and finally patch 5
adds a defconfig for Pistachio.

Boot tested on an IMG Pistachio BuB ("bring-up board") and build tested
for all other affected platforms.  Based on v4.0-rc3.  A tree with these
changes is available at [2].

Changes from v1:
 - Switched to MIPS UHI hand-off protocol

Cc: Ezequiel Garcia 
Cc: James Hartley 
Cc: James Hogan 

[1] http://patchwork.linux-mips.org/patch/8837/
[2] https://github.com/abrestic/linux/tree/pistachio-platform-v2

Andrew Bresticker (3):
  MIPS: Allow platforms to specify the decompressor load address
  MIPS: Document Pistachio boot protocol and device-tree bindings
  MIPS: Add support for the IMG Pistachio SoC

Govindraj Raja (1):
  MIPS: pistachio: Add an initial defconfig

Kevin Cernekee (1):
  MIPS: Create a common 

 .../devicetree/bindings/mips/img/pistachio.txt |  42 +++
 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  27 ++
 arch/mips/boot/compressed/Makefile |   6 +-
 arch/mips/configs/pistachio_defconfig  | 336 +
 arch/mips/include/asm/mach-ar7/war.h   |  24 --
 arch/mips/include/asm/mach-ath25/war.h |  25 --
 arch/mips/include/asm/mach-ath79/war.h |  24 --
 arch/mips/include/asm/mach-au1x00/war.h|  24 --
 arch/mips/include/asm/mach-bcm3384/war.h   |  24 --
 arch/mips/include/asm/mach-bcm47xx/war.h   |  24 --
 arch/mips/include/asm/mach-bcm63xx/war.h   |  24 --
 arch/mips/include/asm/mach-cobalt/war.h|  24 --
 arch/mips/include/asm/mach-dec/war.h   |  24 --
 arch/mips/include/asm/mach-emma2rh/war.h   |  24 --
 arch/mips/include/asm/mach-generic/war.h   |  24 ++
 arch/mips/include/asm/mach-jazz/war.h  |  24 --
 arch/mips/include/asm/mach-jz4740/war.h|  24 --
 arch/mips/include/asm/mach-lantiq/war.h|  23 --
 arch/mips/include/asm/mach-lasat/war.h |  24 --
 arch/mips/include/asm/mach-loongson/war.h  |  24 --
 arch/mips/include/asm/mach-loongson1/war.h |  24 --
 arch/mips/include/asm/mach-netlogic/war.h  |  25 --
 arch/mips/include/asm/mach-paravirt/war.h  |  25 --
 arch/mips/include/asm/mach-pistachio/gpio.h|  21 ++
 arch/mips/include/asm/mach-pistachio/irq.h |  18 ++
 arch/mips/include/asm/mach-pnx833x/war.h   |  24 --
 arch/mips/include/asm/mach-ralink/war.h|  24 --
 arch/mips/include/asm/mach-tx39xx/war.h|  24 --
 arch/mips/include/asm/mach-vr41xx/war.h|  24 --
 arch/mips/jz4740/Platform  |   1 +
 arch/mips/pistachio/Makefile   |   1 +
 arch/mips/pistachio/Platform   |   8 +
 arch/mips/pistachio/init.c | 131 
 arch/mips/pistachio/irq.c  |  28 ++
 arch/mips/pistachio/time.c |  52 
 36 files changed, 694 insertions(+), 532 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mips/img/pistachio.txt
 create mode 100644 arch/mips/configs/pistachio_defconfig
 delete mode 100644 arch/mips/include/asm/mach-ar7/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath25/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath79/war.h
 delete mode 100644 arch/mips/include/asm/mach-au1x00/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm3384/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm47xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm63xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-cobalt/war.h
 delete mode 100644 arch/mips/include/asm/mach-dec/war.h
 delete mode 100644 arch/mips/include/asm/mach-emma2rh/war.h
 create mode 100644 arch/mips/include/asm/mach-generic/war.h
 delete mode 100644 arch/mips/include/asm/mach-jazz/war.h
 delete mode 100644 arch/mips/include/asm/mach-jz4740/war.h
 delete mode 100644 arch/mips/include/asm/mach-lantiq/war.h
 delete mode 100644 arch/mips/include/asm/mach-lasat/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson1/war.h
 delete mode 100644 arch/mips/include/asm/mach-netlogic/war.h
 delete mode 100644 arch/mips/include/asm/mach-paravirt/war.h
 create mode 10

Re: [RFCv3 PATCH 33/48] sched: Energy-aware wake-up task placement

2015-03-13 Thread Sai Gurrappadi
On 02/04/2015 10:31 AM, Morten Rasmussen wrote:
> Let available compute capacity and estimated energy impact select
> wake-up target cpu when energy-aware scheduling is enabled.
> energy_aware_wake_cpu() attempts to find group of cpus with sufficient
> compute capacity to accommodate the task and find a cpu with enough spare
> capacity to handle the task within that group. Preference is given to
> cpus with enough spare capacity at the current OPP. Finally, the energy
> impact of the new target and the previous task cpu is compared to select
> the wake-up target cpu.
> 
> cc: Ingo Molnar 
> cc: Peter Zijlstra 
> 
> Signed-off-by: Morten Rasmussen 
> ---
>  kernel/sched/fair.c | 90 
> +
>  1 file changed, 90 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index b371f32..8713310 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5091,6 +5091,92 @@ static int select_idle_sibling(struct task_struct *p, 
> int target)
>  done:
>   return target;
>  }
> +
> +static unsigned long group_max_capacity(struct sched_group *sg)
> +{
> + int max_idx;
> +
> + if (!sg->sge)
> + return 0;
> +
> + max_idx = sg->sge->nr_cap_states-1;
> +
> + return sg->sge->cap_states[max_idx].cap;
> +}
> +
> +static inline unsigned long task_utilization(struct task_struct *p)
> +{
> + return p->se.avg.utilization_avg_contrib;
> +}
> +
> +static int cpu_overutilized(int cpu, struct sched_domain *sd)
> +{
> + return (capacity_orig_of(cpu) * 100) <
> + (get_cpu_usage(cpu) * sd->imbalance_pct);
> +}
> +
> +static int energy_aware_wake_cpu(struct task_struct *p)
> +{
> + struct sched_domain *sd;
> + struct sched_group *sg, *sg_target;
> + int target_max_cap = SCHED_CAPACITY_SCALE;
> + int target_cpu = task_cpu(p);
> + int i;
> +
> + sd = rcu_dereference(per_cpu(sd_ea, task_cpu(p)));
> +
> + if (!sd)
> + return -1;
> +
> + sg = sd->groups;
> + sg_target = sg;
> + /* Find group with sufficient capacity */
> + do {
> + int sg_max_capacity = group_max_capacity(sg);
> +
> + if (sg_max_capacity >= task_utilization(p) &&
> + sg_max_capacity <= target_max_cap) {
> + sg_target = sg;
> + target_max_cap = sg_max_capacity;
> + }
> + } while (sg = sg->next, sg != sd->groups);

If a 'small' task suddenly becomes 'big' i.e close to 100% util, the
above loop would still pick the little/small cluster because
task_utilization(p) is upper-bounded by the arch-invariant capacity of
the little CPU/group right?

Also, this heuristic for determining sg_target is a big little
assumption. I don't think it is necessarily correct to assume that this
is true for all platforms. This heuristic should be derived from the
energy model for the platform instead.

> +
> + /* Find cpu with sufficient capacity */
> + for_each_cpu_and(i, tsk_cpus_allowed(p), sched_group_cpus(sg_target)) {
> + int new_usage = get_cpu_usage(i) + task_utilization(p);

Isn't this double accounting the task's usage in case task_cpu(p)
belongs to sg_target?

> +
> + if (new_usage > capacity_orig_of(i))
> + continue;
> +
> + if (new_usage < capacity_curr_of(i)) {
> + target_cpu = i;
> + if (!cpu_rq(i)->nr_running)
> + break;
> + }
> +
> + /* cpu has capacity at higher OPP, keep it as fallback */
> + if (target_cpu == task_cpu(p))
> + target_cpu = i;
> + }
> +
> + if (target_cpu != task_cpu(p)) {
> + struct energy_env eenv = {
> + .usage_delta= task_utilization(p),
> + .src_cpu= task_cpu(p),
> + .dst_cpu= target_cpu,
> + };
> +
> + /* Not enough spare capacity on previous cpu */
> + if (cpu_overutilized(task_cpu(p), sd))
> + return target_cpu;
> +
> + if (energy_diff(&eenv) >= 0)
> + return task_cpu(p);
> + }
> +
> + return target_cpu;
> +}
> +
>  /*
>   * select_task_rq_fair: Select target runqueue for the waking task in domains
>   * that have the 'sd_flag' flag set. In practice, this is SD_BALANCE_WAKE,
> @@ -5138,6 +5224,10 @@ select_task_rq_fair(struct task_struct *p, int 
> prev_cpu, int sd_flag, int wake_f
>   prev_cpu = cpu;
>  
>   if (sd_flag & SD_BALANCE_WAKE) {
> + if (energy_aware()) {
> + new_cpu = energy_aware_wake_cpu(p);
> + goto unlock;
> + }
>   new_cpu = select_idle_sibling(p, prev_cpu);
>   goto unlock;
>   }
> 

-Sai
--
To unsubscribe from this list: send the line "unsubscribe lin

Re: [PATCH 2/6] x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit

2015-03-13 Thread Andy Lutomirski
On Fri, Mar 13, 2015 at 3:43 PM,   wrote:
> On Fri, Mar 13, 2015 at 03:38:31PM -0700, Andy Lutomirski wrote:
>> On Fri, Mar 13, 2015 at 3:31 PM,   wrote:
>> > On Fri, Mar 13, 2015 at 03:01:16PM -0700, Andy Lutomirski wrote:
>> >> On Thu, Mar 12, 2015 at 6:40 PM, Josh Triplett  
>> >> wrote:
>> >> > For 32-bit userspace on a 64-bit kernel, this requires modifying
>> >> > stub32_clone to actually swap the appropriate arguments to match
>> >> > CONFIG_CLONE_BACKWARDS, rather than just leaving the C argument for tls
>> >> > broken.
>> >> >
>> >> > Signed-off-by: Josh Triplett 
>> >> > Signed-off-by: Thiago Macieira 
>> >> > ---
>> >> >  arch/x86/Kconfig | 1 +
>> >> >  arch/x86/ia32/ia32entry.S| 2 +-
>> >> >  arch/x86/kernel/process_32.c | 6 +++---
>> >> >  arch/x86/kernel/process_64.c | 8 
>> >> >  4 files changed, 9 insertions(+), 8 deletions(-)
>> >> >
>> >> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> >> > index b7d31ca..4960b0d 100644
>> >> > --- a/arch/x86/Kconfig
>> >> > +++ b/arch/x86/Kconfig
>> >> > @@ -124,6 +124,7 @@ config X86
>> >> > select MODULES_USE_ELF_REL if X86_32
>> >> > select MODULES_USE_ELF_RELA if X86_64
>> >> > select CLONE_BACKWARDS if X86_32
>> >> > +   select HAVE_COPY_THREAD_TLS
>> >> > select ARCH_USE_BUILTIN_BSWAP
>> >> > select ARCH_USE_QUEUE_RWLOCK
>> >> > select OLD_SIGSUSPEND3 if X86_32 || IA32_EMULATION
>> >> > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
>> >> > index 156ebca..0286735 100644
>> >> > --- a/arch/x86/ia32/ia32entry.S
>> >> > +++ b/arch/x86/ia32/ia32entry.S
>> >> > @@ -487,7 +487,7 @@ GLOBAL(\label)
>> >> > ALIGN
>> >> >  GLOBAL(stub32_clone)
>> >> > leaq sys_clone(%rip),%rax
>> >> > -   mov %r8, %rcx
>> >> > +   xchg %r8, %rcx
>> >> > jmp  ia32_ptregs_common
>> >>
>> >> Do I understand correct that whatever function this is a stub for just
>> >> takes its arguments in the wrong order?  If so, can we just fix it
>> >> instead of using xchg here?
>> >
>> > 32-bit x86 and 64-bit x86 take the arguments to clone in a different
>> > order, and stub32_clone fixes up the argument order then calls the
>> > 64-bit sys_clone.
>> >
>> > I'd love to see *all* the 32-on-64 compat stubs for clone rewritten in C
>> > under CONFIG_COMPAT.  However, doing so would require encoding the
>> > knowledge for each 64-bit architecture for how its corresponding 32-bit
>> > architecture accepts arguments to clone, which is information that the
>> > current CONFIG_CLONE_BACKWARDS{1,2,3} don't include; it would then
>> > require cleaning up all the architecture-specific assembly stubs for
>> > 32-bit clone entry points.
>> >
>> > In the meantime, doing that *just* for 32-bit x86 on 64-bit x86 doesn't
>> > seem worth it, since it would require adding a new C entry point for
>> > compat_sys_clone under arch/x86 somewhere.
>> >
>> > One cleanup at a time. :)
>>
>> Fine w/ me.
>
> Thanks.
>
>> >
>> >> In general, I much prefer C code to new asm where it makes sense to
>> >> make this tradeoff.
>> >
>> > Agreed completely.  However, this is at least conservation-of-asm, or
>> > reduction if you consider the pt_regs argument-grabbing hack to be
>> > asm-esque code.
>> >
>> >> Other than that, this is a huge improvement.  You'll have minor
>> >> conflicts against -tip, though.
>> >
>> > Right, I've seen your current changes there.  Should be a trivial merge
>> > though.
>> >
>> > Would you mind providing an ack for the series, or at least for the
>> > first two patches?
>>
>> I can give you an ok-in-principle on the first two.  I'd need to stare
>> at the awful code for a bit to understand the @!*&! clone variants to
>> really ack them convincingly.
>
> I'd definitely appreciate the staring. :)
>
>> OTOH, it would be rather surprising if you messed it up in a way that
>> still boots on all three variants (native 32-bit, native 64-bit, and
>> compat).
>>
>> So, for the first two patches:
>>
>> Acked-by: Andy Lutomirski  # assuming all bitnesses boot
>
> I did test all three, not just with booting but with a thread-local
> storage test.

And it's fairly clear that no one ever tested clone-based TLS in 32
bits from a 64-bit ELF binary, because it was broken until very
recently :-/

This stuff is too magical and too poorly documented for my tastes.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit

2015-03-13 Thread josh
On Fri, Mar 13, 2015 at 03:38:31PM -0700, Andy Lutomirski wrote:
> On Fri, Mar 13, 2015 at 3:31 PM,   wrote:
> > On Fri, Mar 13, 2015 at 03:01:16PM -0700, Andy Lutomirski wrote:
> >> On Thu, Mar 12, 2015 at 6:40 PM, Josh Triplett  
> >> wrote:
> >> > For 32-bit userspace on a 64-bit kernel, this requires modifying
> >> > stub32_clone to actually swap the appropriate arguments to match
> >> > CONFIG_CLONE_BACKWARDS, rather than just leaving the C argument for tls
> >> > broken.
> >> >
> >> > Signed-off-by: Josh Triplett 
> >> > Signed-off-by: Thiago Macieira 
> >> > ---
> >> >  arch/x86/Kconfig | 1 +
> >> >  arch/x86/ia32/ia32entry.S| 2 +-
> >> >  arch/x86/kernel/process_32.c | 6 +++---
> >> >  arch/x86/kernel/process_64.c | 8 
> >> >  4 files changed, 9 insertions(+), 8 deletions(-)
> >> >
> >> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> > index b7d31ca..4960b0d 100644
> >> > --- a/arch/x86/Kconfig
> >> > +++ b/arch/x86/Kconfig
> >> > @@ -124,6 +124,7 @@ config X86
> >> > select MODULES_USE_ELF_REL if X86_32
> >> > select MODULES_USE_ELF_RELA if X86_64
> >> > select CLONE_BACKWARDS if X86_32
> >> > +   select HAVE_COPY_THREAD_TLS
> >> > select ARCH_USE_BUILTIN_BSWAP
> >> > select ARCH_USE_QUEUE_RWLOCK
> >> > select OLD_SIGSUSPEND3 if X86_32 || IA32_EMULATION
> >> > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> >> > index 156ebca..0286735 100644
> >> > --- a/arch/x86/ia32/ia32entry.S
> >> > +++ b/arch/x86/ia32/ia32entry.S
> >> > @@ -487,7 +487,7 @@ GLOBAL(\label)
> >> > ALIGN
> >> >  GLOBAL(stub32_clone)
> >> > leaq sys_clone(%rip),%rax
> >> > -   mov %r8, %rcx
> >> > +   xchg %r8, %rcx
> >> > jmp  ia32_ptregs_common
> >>
> >> Do I understand correct that whatever function this is a stub for just
> >> takes its arguments in the wrong order?  If so, can we just fix it
> >> instead of using xchg here?
> >
> > 32-bit x86 and 64-bit x86 take the arguments to clone in a different
> > order, and stub32_clone fixes up the argument order then calls the
> > 64-bit sys_clone.
> >
> > I'd love to see *all* the 32-on-64 compat stubs for clone rewritten in C
> > under CONFIG_COMPAT.  However, doing so would require encoding the
> > knowledge for each 64-bit architecture for how its corresponding 32-bit
> > architecture accepts arguments to clone, which is information that the
> > current CONFIG_CLONE_BACKWARDS{1,2,3} don't include; it would then
> > require cleaning up all the architecture-specific assembly stubs for
> > 32-bit clone entry points.
> >
> > In the meantime, doing that *just* for 32-bit x86 on 64-bit x86 doesn't
> > seem worth it, since it would require adding a new C entry point for
> > compat_sys_clone under arch/x86 somewhere.
> >
> > One cleanup at a time. :)
> 
> Fine w/ me.

Thanks.

> >
> >> In general, I much prefer C code to new asm where it makes sense to
> >> make this tradeoff.
> >
> > Agreed completely.  However, this is at least conservation-of-asm, or
> > reduction if you consider the pt_regs argument-grabbing hack to be
> > asm-esque code.
> >
> >> Other than that, this is a huge improvement.  You'll have minor
> >> conflicts against -tip, though.
> >
> > Right, I've seen your current changes there.  Should be a trivial merge
> > though.
> >
> > Would you mind providing an ack for the series, or at least for the
> > first two patches?
> 
> I can give you an ok-in-principle on the first two.  I'd need to stare
> at the awful code for a bit to understand the @!*&! clone variants to
> really ack them convincingly.

I'd definitely appreciate the staring. :)

> OTOH, it would be rather surprising if you messed it up in a way that
> still boots on all three variants (native 32-bit, native 64-bit, and
> compat).
> 
> So, for the first two patches:
> 
> Acked-by: Andy Lutomirski  # assuming all bitnesses boot

I did test all three, not just with booting but with a thread-local
storage test.

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


Re: [PATCH 6/6] clone4: Introduce new CLONE_FD flag to get task exit notification via fd

2015-03-13 Thread Andy Lutomirski
On Fri, Mar 13, 2015 at 3:34 PM,   wrote:
> On Fri, Mar 13, 2015 at 03:28:26PM -0700, Andy Lutomirski wrote:
>> On Fri, Mar 13, 2015 at 3:20 PM,   wrote:
>> > On Fri, Mar 13, 2015 at 02:34:58PM -0700, Andy Lutomirski wrote:
>> >> On Fri, Mar 13, 2015 at 12:57 PM,   wrote:
>> >> > A process launching a new process with CLONE_FD is explicitly requesting
>> >> > that the process be automatically reaped without any other process
>> >> > having to wait on it.  The task needs to not become a zombie, because
>> >> > otherwise, it'll show up in waitpid(-1, ...) calls in the parent
>> >> > process, which would break the ability to use this to completely
>> >> > encapsulate process management within a library and not interfere with
>> >> > the parent's process handling via SIGCHLD and wait{pid,3,4}.
>> >>
>> >> Wouldn't the correct behavior be to keep it alive as a zombie but
>> >> *not* show it in waitpid, etc?
>> >
>> > That's a significant change to the semantics of waitpid.  And then
>> > someone would still need to wait on the process, which we'd like to
>> > avoid.  (We don't want to have magic "reap on read(2)" semantics,
>> > because among other things, what if we add a means in the future to get
>> > an additional file descriptor corresponding to an existing process?)
>>
>> Do we not already have a state "dead, successfully waited on by
>> parent, but still around because ptraced"?  If not, shouldn't we?
>> Isn't that what PTRACE_SEIZE does?  Or am I just confused?
>
> I don't think that affects the task's exit_state though.
>

That's a question for Oleg.  I have no idea how ptrace is actually implemented.

--Andy

> - Josh Triplett



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit

2015-03-13 Thread Andy Lutomirski
On Fri, Mar 13, 2015 at 3:31 PM,   wrote:
> On Fri, Mar 13, 2015 at 03:01:16PM -0700, Andy Lutomirski wrote:
>> On Thu, Mar 12, 2015 at 6:40 PM, Josh Triplett  wrote:
>> > For 32-bit userspace on a 64-bit kernel, this requires modifying
>> > stub32_clone to actually swap the appropriate arguments to match
>> > CONFIG_CLONE_BACKWARDS, rather than just leaving the C argument for tls
>> > broken.
>> >
>> > Signed-off-by: Josh Triplett 
>> > Signed-off-by: Thiago Macieira 
>> > ---
>> >  arch/x86/Kconfig | 1 +
>> >  arch/x86/ia32/ia32entry.S| 2 +-
>> >  arch/x86/kernel/process_32.c | 6 +++---
>> >  arch/x86/kernel/process_64.c | 8 
>> >  4 files changed, 9 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> > index b7d31ca..4960b0d 100644
>> > --- a/arch/x86/Kconfig
>> > +++ b/arch/x86/Kconfig
>> > @@ -124,6 +124,7 @@ config X86
>> > select MODULES_USE_ELF_REL if X86_32
>> > select MODULES_USE_ELF_RELA if X86_64
>> > select CLONE_BACKWARDS if X86_32
>> > +   select HAVE_COPY_THREAD_TLS
>> > select ARCH_USE_BUILTIN_BSWAP
>> > select ARCH_USE_QUEUE_RWLOCK
>> > select OLD_SIGSUSPEND3 if X86_32 || IA32_EMULATION
>> > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
>> > index 156ebca..0286735 100644
>> > --- a/arch/x86/ia32/ia32entry.S
>> > +++ b/arch/x86/ia32/ia32entry.S
>> > @@ -487,7 +487,7 @@ GLOBAL(\label)
>> > ALIGN
>> >  GLOBAL(stub32_clone)
>> > leaq sys_clone(%rip),%rax
>> > -   mov %r8, %rcx
>> > +   xchg %r8, %rcx
>> > jmp  ia32_ptregs_common
>>
>> Do I understand correct that whatever function this is a stub for just
>> takes its arguments in the wrong order?  If so, can we just fix it
>> instead of using xchg here?
>
> 32-bit x86 and 64-bit x86 take the arguments to clone in a different
> order, and stub32_clone fixes up the argument order then calls the
> 64-bit sys_clone.
>
> I'd love to see *all* the 32-on-64 compat stubs for clone rewritten in C
> under CONFIG_COMPAT.  However, doing so would require encoding the
> knowledge for each 64-bit architecture for how its corresponding 32-bit
> architecture accepts arguments to clone, which is information that the
> current CONFIG_CLONE_BACKWARDS{1,2,3} don't include; it would then
> require cleaning up all the architecture-specific assembly stubs for
> 32-bit clone entry points.
>
> In the meantime, doing that *just* for 32-bit x86 on 64-bit x86 doesn't
> seem worth it, since it would require adding a new C entry point for
> compat_sys_clone under arch/x86 somewhere.
>
> One cleanup at a time. :)

Fine w/ me.

>
>> In general, I much prefer C code to new asm where it makes sense to
>> make this tradeoff.
>
> Agreed completely.  However, this is at least conservation-of-asm, or
> reduction if you consider the pt_regs argument-grabbing hack to be
> asm-esque code.
>
>> Other than that, this is a huge improvement.  You'll have minor
>> conflicts against -tip, though.
>
> Right, I've seen your current changes there.  Should be a trivial merge
> though.
>
> Would you mind providing an ack for the series, or at least for the
> first two patches?

I can give you an ok-in-principle on the first two.  I'd need to stare
at the awful code for a bit to understand the @!*&! clone variants to
really ack them convincingly.

OTOH, it would be rather surprising if you messed it up in a way that
still boots on all three variants (native 32-bit, native 64-bit, and
compat).

So, for the first two patches:

Acked-by: Andy Lutomirski  # assuming all bitnesses boot

--Andy

>
> (I'm wondering whose tree this series ought to go through, for that
> matter.)
>
> - Josh Triplett



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


[PATCH] staging: vt6656: don't return zero on failure path in vt6656_probe()

2015-03-13 Thread Alexey Khoroshilov
If ieee80211_alloc_hw() fails in vt6656_probe(), it breaks off
initialization, but returns zero.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/staging/vt6656/main_usb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/vt6656/main_usb.c 
b/drivers/staging/vt6656/main_usb.c
index 71adc1f61838..ab3ab84cb0a7 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -963,6 +963,7 @@ vt6656_probe(struct usb_interface *intf, const struct 
usb_device_id *id)
hw = ieee80211_alloc_hw(sizeof(struct vnt_private), &vnt_mac_ops);
if (!hw) {
dev_err(&udev->dev, "could not register ieee80211_hw\n");
+   rc = -ENOMEM;
goto err_nomem;
}
 
-- 
1.9.1

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


Re: [PATCH 6/6] clone4: Introduce new CLONE_FD flag to get task exit notification via fd

2015-03-13 Thread josh
On Fri, Mar 13, 2015 at 03:28:26PM -0700, Andy Lutomirski wrote:
> On Fri, Mar 13, 2015 at 3:20 PM,   wrote:
> > On Fri, Mar 13, 2015 at 02:34:58PM -0700, Andy Lutomirski wrote:
> >> On Fri, Mar 13, 2015 at 12:57 PM,   wrote:
> >> > A process launching a new process with CLONE_FD is explicitly requesting
> >> > that the process be automatically reaped without any other process
> >> > having to wait on it.  The task needs to not become a zombie, because
> >> > otherwise, it'll show up in waitpid(-1, ...) calls in the parent
> >> > process, which would break the ability to use this to completely
> >> > encapsulate process management within a library and not interfere with
> >> > the parent's process handling via SIGCHLD and wait{pid,3,4}.
> >>
> >> Wouldn't the correct behavior be to keep it alive as a zombie but
> >> *not* show it in waitpid, etc?
> >
> > That's a significant change to the semantics of waitpid.  And then
> > someone would still need to wait on the process, which we'd like to
> > avoid.  (We don't want to have magic "reap on read(2)" semantics,
> > because among other things, what if we add a means in the future to get
> > an additional file descriptor corresponding to an existing process?)
> 
> Do we not already have a state "dead, successfully waited on by
> parent, but still around because ptraced"?  If not, shouldn't we?
> Isn't that what PTRACE_SEIZE does?  Or am I just confused?

I don't think that affects the task's exit_state though.

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


Re: [PATCH 2/6] x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit

2015-03-13 Thread josh
On Fri, Mar 13, 2015 at 03:01:16PM -0700, Andy Lutomirski wrote:
> On Thu, Mar 12, 2015 at 6:40 PM, Josh Triplett  wrote:
> > For 32-bit userspace on a 64-bit kernel, this requires modifying
> > stub32_clone to actually swap the appropriate arguments to match
> > CONFIG_CLONE_BACKWARDS, rather than just leaving the C argument for tls
> > broken.
> >
> > Signed-off-by: Josh Triplett 
> > Signed-off-by: Thiago Macieira 
> > ---
> >  arch/x86/Kconfig | 1 +
> >  arch/x86/ia32/ia32entry.S| 2 +-
> >  arch/x86/kernel/process_32.c | 6 +++---
> >  arch/x86/kernel/process_64.c | 8 
> >  4 files changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index b7d31ca..4960b0d 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -124,6 +124,7 @@ config X86
> > select MODULES_USE_ELF_REL if X86_32
> > select MODULES_USE_ELF_RELA if X86_64
> > select CLONE_BACKWARDS if X86_32
> > +   select HAVE_COPY_THREAD_TLS
> > select ARCH_USE_BUILTIN_BSWAP
> > select ARCH_USE_QUEUE_RWLOCK
> > select OLD_SIGSUSPEND3 if X86_32 || IA32_EMULATION
> > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> > index 156ebca..0286735 100644
> > --- a/arch/x86/ia32/ia32entry.S
> > +++ b/arch/x86/ia32/ia32entry.S
> > @@ -487,7 +487,7 @@ GLOBAL(\label)
> > ALIGN
> >  GLOBAL(stub32_clone)
> > leaq sys_clone(%rip),%rax
> > -   mov %r8, %rcx
> > +   xchg %r8, %rcx
> > jmp  ia32_ptregs_common
> 
> Do I understand correct that whatever function this is a stub for just
> takes its arguments in the wrong order?  If so, can we just fix it
> instead of using xchg here?

32-bit x86 and 64-bit x86 take the arguments to clone in a different
order, and stub32_clone fixes up the argument order then calls the
64-bit sys_clone.

I'd love to see *all* the 32-on-64 compat stubs for clone rewritten in C
under CONFIG_COMPAT.  However, doing so would require encoding the
knowledge for each 64-bit architecture for how its corresponding 32-bit
architecture accepts arguments to clone, which is information that the
current CONFIG_CLONE_BACKWARDS{1,2,3} don't include; it would then
require cleaning up all the architecture-specific assembly stubs for
32-bit clone entry points.

In the meantime, doing that *just* for 32-bit x86 on 64-bit x86 doesn't
seem worth it, since it would require adding a new C entry point for
compat_sys_clone under arch/x86 somewhere.

One cleanup at a time. :)

> In general, I much prefer C code to new asm where it makes sense to
> make this tradeoff.

Agreed completely.  However, this is at least conservation-of-asm, or
reduction if you consider the pt_regs argument-grabbing hack to be
asm-esque code.

> Other than that, this is a huge improvement.  You'll have minor
> conflicts against -tip, though.

Right, I've seen your current changes there.  Should be a trivial merge
though.

Would you mind providing an ack for the series, or at least for the
first two patches?

(I'm wondering whose tree this series ought to go through, for that
matter.)

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


Re: [PATCH 6/6] clone4: Introduce new CLONE_FD flag to get task exit notification via fd

2015-03-13 Thread Andy Lutomirski
On Fri, Mar 13, 2015 at 3:20 PM,   wrote:
> On Fri, Mar 13, 2015 at 02:34:58PM -0700, Andy Lutomirski wrote:
>> On Fri, Mar 13, 2015 at 12:57 PM,   wrote:
>> > A process launching a new process with CLONE_FD is explicitly requesting
>> > that the process be automatically reaped without any other process
>> > having to wait on it.  The task needs to not become a zombie, because
>> > otherwise, it'll show up in waitpid(-1, ...) calls in the parent
>> > process, which would break the ability to use this to completely
>> > encapsulate process management within a library and not interfere with
>> > the parent's process handling via SIGCHLD and wait{pid,3,4}.
>>
>> Wouldn't the correct behavior be to keep it alive as a zombie but
>> *not* show it in waitpid, etc?
>
> That's a significant change to the semantics of waitpid.  And then
> someone would still need to wait on the process, which we'd like to
> avoid.  (We don't want to have magic "reap on read(2)" semantics,
> because among other things, what if we add a means in the future to get
> an additional file descriptor corresponding to an existing process?)
>

Do we not already have a state "dead, successfully waited on by
parent, but still around because ptraced"?  If not, shouldn't we?
Isn't that what PTRACE_SEIZE does?  Or am I just confused?

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


[PATCH 13/13] builtin-sched.c %ld in format string %ld in format string requires 'long' but the argument type is 'unsigned long'.

2015-03-13 Thread Ameen Ali
Signed-off-by: Ameen Ali 
---
 tools/perf/builtin-sched.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 891c393..dbc417a 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -351,7 +351,7 @@ static struct task_desc *register_pid(struct perf_sched 
*sched,
sched->tasks[task->nr] = task;
 
if (verbose)
-   printf("registered task #%ld, PID %ld (%s)\n", sched->nr_tasks, 
pid, comm);
+   printf("registered task #%lu, PID %lu (%s)\n", sched->nr_tasks, 
pid, comm);
 
return task;
 }
@@ -364,7 +364,7 @@ static void print_task_traces(struct perf_sched *sched)
 
for (i = 0; i < sched->nr_tasks; i++) {
task = sched->tasks[i];
-   printf("task %6ld (%20s:%10ld), nr_events: %ld\n",
+   printf("task %6lu (%20s:%10lu), nr_events: %lu\n",
task->nr, task->comm, task->pid, task->nr_events);
}
 }
@@ -612,7 +612,7 @@ static void run_one_test(struct perf_sched *sched)
sched->run_avg = delta;
sched->run_avg = (sched->run_avg * 9 + delta) / 10;
 
-   printf("#%-3ld: %0.3f, ", sched->nr_runs, (double)delta / 100.0);
+   printf("#%-3lu: %0.3f, ", sched->nr_runs, (double)delta / 100.0);
 
printf("ravg: %0.2f, ", (double)sched->run_avg / 1e6);
 
@@ -632,7 +632,7 @@ static void run_one_test(struct perf_sched *sched)
printf("\n");
 
if (sched->nr_sleep_corrections)
-   printf(" (%ld sleep corrections)\n", 
sched->nr_sleep_corrections);
+   printf(" (%lu sleep corrections)\n", 
sched->nr_sleep_corrections);
sched->nr_sleep_corrections = 0;
 }
 
@@ -1493,17 +1493,17 @@ out_delete:
 static void print_bad_events(struct perf_sched *sched)
 {
if (sched->nr_unordered_timestamps && sched->nr_timestamps) {
-   printf("  INFO: %.3f%% unordered timestamps (%ld out of %ld)\n",
+   printf("  INFO: %.3f%% unordered timestamps (%lu out of %lu)\n",

(double)sched->nr_unordered_timestamps/(double)sched->nr_timestamps*100.0,
sched->nr_unordered_timestamps, sched->nr_timestamps);
}
if (sched->nr_lost_events && sched->nr_events) {
-   printf("  INFO: %.3f%% lost events (%ld out of %ld, in %ld 
chunks)\n",
+   printf("  INFO: %.3f%% lost events (%lu out of %lu, in %lu 
chunks)\n",
(double)sched->nr_lost_events/(double)sched->nr_events 
* 100.0,
sched->nr_lost_events, sched->nr_events, 
sched->nr_lost_chunks);
}
if (sched->nr_context_switch_bugs && sched->nr_timestamps) {
-   printf("  INFO: %.3f%% context switch bugs (%ld out of %ld)",
+   printf("  INFO: %.3f%% context switch bugs (%lu out of %lu)",

(double)sched->nr_context_switch_bugs/(double)sched->nr_timestamps*100.0,
sched->nr_context_switch_bugs, sched->nr_timestamps);
if (sched->nr_lost_events)
@@ -1575,16 +1575,16 @@ static int perf_sched__replay(struct perf_sched *sched)
if (perf_sched__read_events(sched, NULL))
return -1;
 
-   printf("nr_run_events:%ld\n", sched->nr_run_events);
-   printf("nr_sleep_events:  %ld\n", sched->nr_sleep_events);
-   printf("nr_wakeup_events: %ld\n", sched->nr_wakeup_events);
+   printf("nr_run_events:%lu\n", sched->nr_run_events);
+   printf("nr_sleep_events:  %lu\n", sched->nr_sleep_events);
+   printf("nr_wakeup_events: %lu\n", sched->nr_wakeup_events);
 
if (sched->targetless_wakeups)
-   printf("target-less wakeups:  %ld\n", 
sched->targetless_wakeups);
+   printf("target-less wakeups:  %lu\n", 
sched->targetless_wakeups);
if (sched->multitarget_wakeups)
-   printf("multi-target wakeups: %ld\n", 
sched->multitarget_wakeups);
+   printf("multi-target wakeups: %lu\n", 
sched->multitarget_wakeups);
if (sched->nr_run_events_optimized)
-   printf("run atoms optimized: %ld\n",
+   printf("run atoms optimized: %lu\n",
sched->nr_run_events_optimized);
 
print_task_traces(sched);
-- 
2.1.0

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


Re: [PATCH v2] mce: use safe MSR accesses

2015-03-13 Thread Borislav Petkov
On Fri, Mar 13, 2015 at 11:03:39AM -0500, jesse.lar...@amd.com wrote:
> From: Jesse Larrew 
> 
> Certain MSRs are only relevant to a kernel in host mode, and kvm had
> chosen not to implement these MSRs at all for guests. If a guest kernel
> ever tried to access these MSRs, the result was a general protection
> fault.
> 
> KVM will be separately patched to return 0 when these MSRs are read,
> and this patch ensures that MSR accesses are tolerant of exceptions.
> 
> Signed-off-by: Jesse Larrew 
> ---
>  arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] powercap/rapl: handle domain energy unit

2015-03-13 Thread Rafael J. Wysocki
On Friday, March 13, 2015 03:48:56 AM Jacob Pan wrote:
> The current driver assumes all RAPL domains within a CPU package
> have the same energy unit. This is no longer true for HSW server
> CPUs since DRAM domain has is own fixed energy unit which can be
> different than the package energy unit enumerated by package
> power MSR. In fact, the default HSW EP package power unit is 61uJ
> whereas DRAM domain unit is 15.3uJ. The result is that DRAM power
> consumption is counted 4x more than real power reported by energy
> counters, similarly for max_energy_range_uj of DRAM domain.
> 
> This patch adds domain specific energy unit per cpu type, it allows
> domain energy unit to override package energy unit if non zero.
> 
> Please see this document for details.
> "Intel Xeon Processor E5-1600 and E5-2600 v3 Product Families, Volume 2
> of 2. Datasheet, September 2014, Reference Number: 330784-001 "
> 
> Signed-off-by: Jacob Pan 

Queued up this one for 4.0-rc5, thanks!

> ---
>  drivers/powercap/intel_rapl.c | 54 
> +++
>  1 file changed, 39 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
> index 97b5e4e..63d4033 100644
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@ -73,7 +73,7 @@
>  
>  #define TIME_WINDOW_MAX_MSEC 4
>  #define TIME_WINDOW_MIN_MSEC 250
> -
> +#define ENERGY_UNIT_SCALE1000 /* scale from driver unit to powercap unit 
> */
>  enum unit_type {
>   ARBITRARY_UNIT, /* no translation */
>   POWER_UNIT,
> @@ -158,6 +158,7 @@ struct rapl_domain {
>   struct rapl_power_limit rpl[NR_POWER_LIMITS];
>   u64 attr_map; /* track capabilities */
>   unsigned int state;
> + unsigned int domain_energy_unit;
>   int package_id;
>  };
>  #define power_zone_to_rapl_domain(_zone) \
> @@ -190,6 +191,7 @@ struct rapl_defaults {
>   void (*set_floor_freq)(struct rapl_domain *rd, bool mode);
>   u64 (*compute_time_window)(struct rapl_package *rp, u64 val,
>   bool to_raw);
> + unsigned int dram_domain_energy_unit;
>  };
>  static struct rapl_defaults *rapl_defaults;
>  
> @@ -227,7 +229,8 @@ static int rapl_read_data_raw(struct rapl_domain *rd,
>  static int rapl_write_data_raw(struct rapl_domain *rd,
>   enum rapl_primitives prim,
>   unsigned long long value);
> -static u64 rapl_unit_xlate(int package, enum unit_type type, u64 value,
> +static u64 rapl_unit_xlate(struct rapl_domain *rd, int package,
> + enum unit_type type, u64 value,
>   int to_raw);
>  static void package_power_limit_irq_save(int package_id);
>  
> @@ -305,7 +308,9 @@ static int get_energy_counter(struct powercap_zone 
> *power_zone, u64 *energy_raw)
>  
>  static int get_max_energy_counter(struct powercap_zone *pcd_dev, u64 *energy)
>  {
> - *energy = rapl_unit_xlate(0, ENERGY_UNIT, ENERGY_STATUS_MASK, 0);
> + struct rapl_domain *rd = power_zone_to_rapl_domain(pcd_dev);
> +
> + *energy = rapl_unit_xlate(rd, 0, ENERGY_UNIT, ENERGY_STATUS_MASK, 0);
>   return 0;
>  }
>  
> @@ -639,6 +644,11 @@ static void rapl_init_domains(struct rapl_package *rp)
>   rd->msrs[4] = MSR_DRAM_POWER_INFO;
>   rd->rpl[0].prim_id = PL1_ENABLE;
>   rd->rpl[0].name = pl1_name;
> + rd->domain_energy_unit =
> + rapl_defaults->dram_domain_energy_unit;
> + if (rd->domain_energy_unit)
> + pr_info("DRAM domain energy unit %dpj\n",
> + rd->domain_energy_unit);
>   break;
>   }
>   if (mask) {
> @@ -648,11 +658,13 @@ static void rapl_init_domains(struct rapl_package *rp)
>   }
>  }
>  
> -static u64 rapl_unit_xlate(int package, enum unit_type type, u64 value,
> +static u64 rapl_unit_xlate(struct rapl_domain *rd, int package,
> + enum unit_type type, u64 value,
>   int to_raw)
>  {
>   u64 units = 1;
>   struct rapl_package *rp;
> + u64 scale = 1;
>  
>   rp = find_package_by_id(package);
>   if (!rp)
> @@ -663,7 +675,12 @@ static u64 rapl_unit_xlate(int package, enum unit_type 
> type, u64 value,
>   units = rp->power_unit;
>   break;
>   case ENERGY_UNIT:
> - units = rp->energy_unit;
> + scale = ENERGY_UNIT_SCALE;
> + /* per domain unit takes precedence */
> + if (rd && rd->domain_energy_unit)
> + units = rd->domain_energy_unit;
> + else
> + units = rp->energy_unit;
>   break;
>   case TIME_UNIT:
>   return rapl_defaults->compute_time_window(rp, value, to_raw);
> @@ -673,11 +690,11 @@ static u64 rapl_unit_xlate(int package, enum u

Re: [PATCH 6/6] clone4: Introduce new CLONE_FD flag to get task exit notification via fd

2015-03-13 Thread josh
On Fri, Mar 13, 2015 at 02:34:58PM -0700, Andy Lutomirski wrote:
> On Fri, Mar 13, 2015 at 12:57 PM,   wrote:
> > A process launching a new process with CLONE_FD is explicitly requesting
> > that the process be automatically reaped without any other process
> > having to wait on it.  The task needs to not become a zombie, because
> > otherwise, it'll show up in waitpid(-1, ...) calls in the parent
> > process, which would break the ability to use this to completely
> > encapsulate process management within a library and not interfere with
> > the parent's process handling via SIGCHLD and wait{pid,3,4}.
> 
> Wouldn't the correct behavior be to keep it alive as a zombie but
> *not* show it in waitpid, etc?

That's a significant change to the semantics of waitpid.  And then
someone would still need to wait on the process, which we'd like to
avoid.  (We don't want to have magic "reap on read(2)" semantics,
because among other things, what if we add a means in the future to get
an additional file descriptor corresponding to an existing process?)

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


Re: [Patch v4 2/2] dmaengine: Add ADM driver

2015-03-13 Thread Andy Gross
On Fri, Mar 13, 2015 at 02:27:45PM +0530, Vinod Koul wrote:
> On Wed, Feb 11, 2015 at 11:46:05PM -0600, Andy Gross wrote:
> > +++ b/drivers/dma/qcom_adm.c
> > @@ -0,0 +1,901 @@
> > +/*
> > + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> shouldn't this be 15 :)

yeah, need to update.

> 
>  +/* ADM registers - calculated from channel number and security domain */
> > +#define HI_CH_CMD_PTR(chan, ee)(4*chan + 0x20800*ee)
> > +#define HI_CH_RSLT(chan, ee)   (0x40 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE0(chan, ee)   (0x80 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE1(chan, ee)   (0xc0 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE2(chan, ee)   (0x100 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE3(chan, ee)   (0x140 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE4(chan, ee)   (0x180 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE5(chan, ee)   (0x1c0 + 4*chan + 0x20800*ee)
> > +#define HI_CH_STATUS_SD(chan, ee)  (0x200 + 4*chan + 0x20800*ee)
> > +#define HI_CH_CONF(chan)   (0x240 + 4*chan)
> > +#define HI_CH_RSLT_CONF(chan, ee)  (0x300 + 4*chan + 0x20800*ee)
> > +#define HI_SEC_DOMAIN_IRQ_STATUS(ee)   (0x380 + 0x20800*ee)
> > +#define HI_CI_CONF(ci) (0x390 + 4*ci)
> > +#define HI_CRCI_CONF0  0x3d0
> > +#define HI_CRCI_CONF1  0x3d4
> > +#define HI_GP_CTL  0x3d8
> > +#define HI_CRCI_CTL(crci, ee)  (0x400 + 0x4*crci + 0x20800*ee)
> two things, one the names are quite generic and may cause conflicts so pls
> fix that. Second the values, what is the deal with 4*chan, should that be a
> define as well. Also rather than copy pasting a macros would be better for
> this expansion

Yeah there are sets of registers that have both channel and execution
environment offsets.  It is messy.  I'll try to make it more sane.

> 
> > +
> > +/* channel status */
> > +#define CH_STATUS_VALIDBIT(1)
> > +
> > +/* channel result */
> > +#define CH_RSLT_VALID  BIT(31)
> > +#define CH_RSLT_ERRBIT(3)
> > +#define CH_RSLT_FLUSH  BIT(2)
> > +#define CH_RSLT_TPDBIT(1)
> > +
> > +/* channel conf */
> > +#define CH_CONF_MPU_DISABLEBIT(11)
> > +#define CH_CONF_PERM_MPU_CONF  BIT(9)
> > +#define CH_CONF_FLUSH_RSLT_EN  BIT(8)
> > +#define CH_CONF_FORCE_RSLT_EN  BIT(7)
> > +#define CH_CONF_IRQ_EN BIT(6)
> > +
> > +/* channel result conf */
> > +#define CH_RSLT_CONF_FLUSH_EN  BIT(1)
> > +#define CH_RSLT_CONF_IRQ_ENBIT(0)
> > +
> > +/* CRCI CTL */
> > +#define CRCI_CTL_MUX_SEL   BIT(18)
> > +#define CRCI_CTL_RST   BIT(17)
> > +
> > +/* CI configuration */
> > +#define CI_RANGE_END(x)(x << 24)
> > +#define CI_RANGE_START(x)  (x << 16)
> > +#define CI_BURST_4_WORDS   0x4
> > +#define CI_BURST_8_WORDS   0x8
> shouldn't you be consistent is usage of BIT()

good catch

> > +
> > +/* GP CTL */
> > +#define GP_CTL_LP_EN   BIT(12)
> > +#define GP_CTL_LP_CNT(x)   (x << 8)
> > +
> > +/* Command pointer list entry */
> > +#define CPLE_LPBIT(31)
> > +#define CPLE_CMD_PTR_LIST  BIT(29)
> > +
> > +/* Command list entry */
> > +#define CMD_LC BIT(31)
> > +#define CMD_DST_CRCI(n)(((n) & 0xf) << 7)
> > +#define CMD_SRC_CRCI(n)(((n) & 0xf) << 3)
> > +
> > +#define CMD_TYPE_SINGLE0x0
> > +#define CMD_TYPE_BOX   0x3a
> naming issues...

ok. will try to come up with something better

> > +static int adm_alloc_chan(struct dma_chan *chan)
> > +{
> > +   return 0;
> > +}
> This is no longer mandatory, so can be dropped

will remove

> 
> > +static int adm_get_blksize(unsigned int burst)
> > +{
> > +   int ret;
> > +
> > +   switch (burst) {
> > +   case 16:
> > +   ret = 0;
> > +   break;
> > +   case 32:
> > +   ret = 1;
> > +   break;
> > +   case 64:
> > +   ret = 2;
> > +   break;
> > +   case 128:
> > +   ret = 3;
> > +   break;
> > +   case 192:
> > +   ret = 4;
> > +   break;
> > +   case 256:
> > +   ret = 5;
> > +   break;
> ffs(burst>>4) ?

that should work nicely.  thanks.

> > +static struct dma_async_tx_descriptor *adm_prep_slave_sg(struct dma_chan 
> > *chan,
> > +   struct scatterlist *sgl, unsigned int sg_len,
> > +   enum dma_transfer_direction direction, unsigned long flags,
> > +   void *context)
> > +{
> > +   struct adm_chan *achan = to_adm_chan(chan);
> > +   struct adm_device *adev = achan->adev;
> > +   struct adm_async_desc *async_desc;
> > +   struct scatterlist *sg;
> > +   u32 i;
> > +   u32 single_count = 0, box_count = 0, desc_offset = 0, crci = 0;
> > +   struct adm_desc_hw_box *box_desc;
> > +   struct adm_desc_hw_single *single_desc;
> > +   void *desc;
> > +   u32 *cple, *last_cmd;
> > +   u32 burst;
> > +   int blk_size = 0;
> > +
> 

Re: [PATCH v3 0/7] Switch mach-at91 to multiplatform

2015-03-13 Thread Alexandre Belloni
Nicolas,

On 13/03/2015 at 22:57:17 +0100, Alexandre Belloni wrote :
> AT91 is now ready to switch to multiplatform. Do it and clean the remaining 
> mach
> includes.
> 
> Changes in v3:
>  - use a menu structure as asked by Arnd
>  - remove useless selects as pointed by Rob
>  - drop a patch that has already been applied
>  - add a patch to remove AT91_TIMER_HZ

I forgot to add that I rebased it on your at91-4.1-cleanup branch as the
merge conflict in arch/arm/mach-at91/Kconfig was not easy to solve.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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 2/6] x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit

2015-03-13 Thread Andy Lutomirski
On Thu, Mar 12, 2015 at 6:40 PM, Josh Triplett  wrote:
> For 32-bit userspace on a 64-bit kernel, this requires modifying
> stub32_clone to actually swap the appropriate arguments to match
> CONFIG_CLONE_BACKWARDS, rather than just leaving the C argument for tls
> broken.
>
> Signed-off-by: Josh Triplett 
> Signed-off-by: Thiago Macieira 
> ---
>  arch/x86/Kconfig | 1 +
>  arch/x86/ia32/ia32entry.S| 2 +-
>  arch/x86/kernel/process_32.c | 6 +++---
>  arch/x86/kernel/process_64.c | 8 
>  4 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index b7d31ca..4960b0d 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -124,6 +124,7 @@ config X86
> select MODULES_USE_ELF_REL if X86_32
> select MODULES_USE_ELF_RELA if X86_64
> select CLONE_BACKWARDS if X86_32
> +   select HAVE_COPY_THREAD_TLS
> select ARCH_USE_BUILTIN_BSWAP
> select ARCH_USE_QUEUE_RWLOCK
> select OLD_SIGSUSPEND3 if X86_32 || IA32_EMULATION
> diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> index 156ebca..0286735 100644
> --- a/arch/x86/ia32/ia32entry.S
> +++ b/arch/x86/ia32/ia32entry.S
> @@ -487,7 +487,7 @@ GLOBAL(\label)
> ALIGN
>  GLOBAL(stub32_clone)
> leaq sys_clone(%rip),%rax
> -   mov %r8, %rcx
> +   xchg %r8, %rcx
> jmp  ia32_ptregs_common

Do I understand correct that whatever function this is a stub for just
takes its arguments in the wrong order?  If so, can we just fix it
instead of using xchg here?

In general, I much prefer C code to new asm where it makes sense to
make this tradeoff.

Other than that, this is a huge improvement.  You'll have minor
conflicts against -tip, though.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3 7/7] ARM: at91: drop AT91_TIMER_HZ

2015-03-13 Thread Alexandre Belloni
Drop AT91_TIMER_HZ as this can be handled using HZ_FIXED. Initial help message
was:

On AT91rm9200 chips where you're using a system clock derived
from the 32768 Hz hardware clock, this tick rate should divide
it exactly: use a power-of-two value, such as 128 or 256, to
reduce timing errors caused by rounding.

Signed-off-by: Alexandre Belloni 
---
 arch/arm/Kconfig   |  2 +-
 arch/arm/mach-at91/Kconfig | 18 --
 2 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a1d153098001..8d5c4f9c15f9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1502,7 +1502,7 @@ config HZ_FIXED
int
default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
ARCH_S5PV210 || ARCH_EXYNOS4
-   default AT91_TIMER_HZ if ARCH_AT91
+   default 128 if SOC_AT91RM9200
default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY
default 0
 
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 4662eae06753..da977699c037 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -100,22 +100,4 @@ config SOC_SAMA5
select SOC_SAM_V7
select SRAM if PM
 
-comment "Atmel SoCs Feature Selections"
-
-config AT91_TIMER_HZ
-   int "Kernel HZ (jiffies per second)"
-   range 32 1024
-   depends on ARCH_AT91
-   default "128" if SOC_AT91RM9200
-   default "100"
-   help
- On AT91rm9200 chips where you're using a system clock derived
- from the 32768 Hz hardware clock, this tick rate should divide
- it exactly: use a power-of-two value, such as 128 or 256, to
- reduce timing errors caused by rounding.
-
- On AT91sam926x chips, or otherwise when using a higher precision
- system clock (of at least several MHz), rounding is less of a
- problem so it can be safer to use a decimal values like 100.
-
 endif
-- 
2.1.0

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


[PATCH v3 4/7] ARM: at91: remove useless mach/cpu.h

2015-03-13 Thread Alexandre Belloni
mach/cpu.h is not used anymore, remove it.

Signed-off-by: Alexandre Belloni 
---
 arch/arm/mach-at91/include/mach/at91sam9_smc.h |   2 -
 arch/arm/mach-at91/include/mach/cpu.h  | 216 -
 arch/arm/mach-at91/pm.c|   1 -
 3 files changed, 219 deletions(-)
 delete mode 100644 arch/arm/mach-at91/include/mach/cpu.h

diff --git a/arch/arm/mach-at91/include/mach/at91sam9_smc.h 
b/arch/arm/mach-at91/include/mach/at91sam9_smc.h
index 175e1fdd9fe8..ff54a0ce90e3 100644
--- a/arch/arm/mach-at91/include/mach/at91sam9_smc.h
+++ b/arch/arm/mach-at91/include/mach/at91sam9_smc.h
@@ -16,8 +16,6 @@
 #ifndef AT91SAM9_SMC_H
 #define AT91SAM9_SMC_H
 
-#include 
-
 #ifndef __ASSEMBLY__
 struct sam9_smc_config {
/* Setup register */
diff --git a/arch/arm/mach-at91/include/mach/cpu.h 
b/arch/arm/mach-at91/include/mach/cpu.h
deleted file mode 100644
index ce7c80a44983..
--- a/arch/arm/mach-at91/include/mach/cpu.h
+++ /dev/null
@@ -1,216 +0,0 @@
-/*
- * arch/arm/mach-at91/include/mach/cpu.h
- *
- * Copyright (C) 2006 SAN People
- * Copyright (C) 2011 Jean-Christophe PLAGNIOL-VILLARD 
- *
- * 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.
- *
- */
-
-#ifndef __MACH_CPU_H__
-#define __MACH_CPU_H__
-
-#define ARCH_ID_AT91RM9200 0x09290780
-#define ARCH_ID_AT91SAM92600x019803a0
-#define ARCH_ID_AT91SAM92610x019703a0
-#define ARCH_ID_AT91SAM92630x019607a0
-#define ARCH_ID_AT91SAM9G100x019903a0
-#define ARCH_ID_AT91SAM9G200x019905a0
-#define ARCH_ID_AT91SAM9RL64   0x019b03a0
-#define ARCH_ID_AT91SAM9G450x819b05a0
-#define ARCH_ID_AT91SAM9G45MRL 0x819b05a2  /* aka 9G45-ES2 & non ES lots */
-#define ARCH_ID_AT91SAM9G45ES  0x819b05a1  /* 9G45-ES (Engineering Sample) 
*/
-#define ARCH_ID_AT91SAM9X5 0x819a05a0
-#define ARCH_ID_AT91SAM9N120x819a07a0
-
-#define ARCH_ID_AT91SAM9XE128  0x329973a0
-#define ARCH_ID_AT91SAM9XE256  0x329a93a0
-#define ARCH_ID_AT91SAM9XE512  0x329aa3a0
-
-#define ARCH_ID_AT91M40800 0x14080044
-#define ARCH_ID_AT91R40807 0x44080746
-#define ARCH_ID_AT91M40807 0x14080745
-#define ARCH_ID_AT91R40008 0x44000840
-
-#define ARCH_ID_SAMA5  0x8A5C07C0
-
-#define ARCH_EXID_AT91SAM9M11  0x0001
-#define ARCH_EXID_AT91SAM9M10  0x0002
-#define ARCH_EXID_AT91SAM9G46  0x0003
-#define ARCH_EXID_AT91SAM9G45  0x0004
-
-#define ARCH_EXID_AT91SAM9G15  0x
-#define ARCH_EXID_AT91SAM9G35  0x0001
-#define ARCH_EXID_AT91SAM9X35  0x0002
-#define ARCH_EXID_AT91SAM9G25  0x0003
-#define ARCH_EXID_AT91SAM9X25  0x0004
-
-#define ARCH_EXID_SAMA5D3  0x4300
-#define ARCH_EXID_SAMA5D31 0x00444300
-#define ARCH_EXID_SAMA5D33 0x00414300
-#define ARCH_EXID_SAMA5D34 0x00414301
-#define ARCH_EXID_SAMA5D35 0x00584300
-#define ARCH_EXID_SAMA5D36 0x4301
-
-#define ARCH_EXID_SAMA5D4  0x0007
-#define ARCH_EXID_SAMA5D41 0x0001
-#define ARCH_EXID_SAMA5D42 0x0002
-#define ARCH_EXID_SAMA5D43 0x0003
-#define ARCH_EXID_SAMA5D44 0x0004
-
-#define ARCH_FAMILY_AT91SAM9   0x0190
-#define ARCH_FAMILY_AT91SAM9XE 0x0290
-
-/* RM9200 type */
-#define ARCH_REVISON_9200_BGA  (0 << 0)
-#define ARCH_REVISON_9200_PQFP (1 << 0)
-
-#ifndef __ASSEMBLY__
-enum at91_soc_type {
-   /* 920T */
-   AT91_SOC_RM9200,
-
-   /* SAM92xx */
-   AT91_SOC_SAM9260, AT91_SOC_SAM9261, AT91_SOC_SAM9263,
-
-   /* SAM9Gxx */
-   AT91_SOC_SAM9G10, AT91_SOC_SAM9G20, AT91_SOC_SAM9G45,
-
-   /* SAM9RL */
-   AT91_SOC_SAM9RL,
-
-   /* SAM9X5 */
-   AT91_SOC_SAM9X5,
-
-   /* SAM9N12 */
-   AT91_SOC_SAM9N12,
-
-   /* SAMA5D3 */
-   AT91_SOC_SAMA5D3,
-
-   /* SAMA5D4 */
-   AT91_SOC_SAMA5D4,
-
-   /* Unknown type */
-   AT91_SOC_UNKNOWN,
-};
-
-enum at91_soc_subtype {
-   /* RM9200 */
-   AT91_SOC_RM9200_BGA, AT91_SOC_RM9200_PQFP,
-
-   /* SAM9260 */
-   AT91_SOC_SAM9XE,
-
-   /* SAM9G45 */
-   AT91_SOC_SAM9G45ES, AT91_SOC_SAM9M10, AT91_SOC_SAM9G46, 
AT91_SOC_SAM9M11,
-
-   /* SAM9X5 */
-   AT91_SOC_SAM9G15, AT91_SOC_SAM9G35, AT91_SOC_SAM9X35,
-   AT91_SOC_SAM9G25, AT91_SOC_SAM9X25,
-
-   /* SAMA5D3 */
-   AT91_SOC_SAMA5D31, AT91_SOC_SAMA5D33, AT91_SOC_SAMA5D34,
-   AT91_SOC_SAMA5D35, AT91_SOC_SAMA5D36,
-
-   /* SAMA5D4 */
-   AT91_SOC_SAMA5D41, AT91_SOC_SAMA5D42, AT91_SOC_SAMA5D43,
-   AT91_SOC_SAMA5D44,
-
-   /* No subtype for this SoC */
-   AT91_SOC_SUBTYPE_NONE,
-
-   /* Unknown subtype */
-   AT91_SOC_SUBTYPE_UNKNOWN,
-};
-
-struct at91_socinfo {
-   unsigned int type, subtype;
-   unsigned int cidr, exid;
-};
-
-extern struct at91_socinfo at91_soc_initdata;
-const char *at91_get_soc_type(stru

[PATCH v3 5/7] ARM: at91: remove SoC headers

2015-03-13 Thread Alexandre Belloni
Remove the now useless SoC headers.

Signed-off-by: Alexandre Belloni 
---
 arch/arm/mach-at91/include/mach/at91rm9200.h  | 103 ---
 arch/arm/mach-at91/include/mach/at91sam9260.h | 129 ---
 arch/arm/mach-at91/include/mach/at91sam9261.h |  99 --
 arch/arm/mach-at91/include/mach/at91sam9263.h | 117 -
 arch/arm/mach-at91/include/mach/at91sam9g45.h | 143 --
 arch/arm/mach-at91/include/mach/at91sam9n12.h |  65 
 arch/arm/mach-at91/include/mach/at91sam9rl.h  | 105 ---
 arch/arm/mach-at91/include/mach/at91sam9x5.h  |  71 -
 arch/arm/mach-at91/include/mach/hardware.h|  11 --
 arch/arm/mach-at91/include/mach/sama5d3.h |  86 
 arch/arm/mach-at91/include/mach/sama5d4.h |  33 --
 11 files changed, 962 deletions(-)
 delete mode 100644 arch/arm/mach-at91/include/mach/at91rm9200.h
 delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9260.h
 delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9261.h
 delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9263.h
 delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9g45.h
 delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9n12.h
 delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9rl.h
 delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9x5.h
 delete mode 100644 arch/arm/mach-at91/include/mach/sama5d3.h
 delete mode 100644 arch/arm/mach-at91/include/mach/sama5d4.h

diff --git a/arch/arm/mach-at91/include/mach/at91rm9200.h 
b/arch/arm/mach-at91/include/mach/at91rm9200.h
deleted file mode 100644
index e67317c67761..
--- a/arch/arm/mach-at91/include/mach/at91rm9200.h
+++ /dev/null
@@ -1,103 +0,0 @@
-/*
- * arch/arm/mach-at91/include/mach/at91rm9200.h
- *
- * Copyright (C) 2005 Ivan Kokshaysky
- * Copyright (C) SAN People
- *
- * Common definitions.
- * Based on AT91RM9200 datasheet revision E.
- *
- * 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.
- */
-
-#ifndef AT91RM9200_H
-#define AT91RM9200_H
-
-/*
- * Peripheral identifiers/interrupts.
- */
-#define AT91RM9200_ID_PIOA 2   /* Parallel IO Controller A */
-#define AT91RM9200_ID_PIOB 3   /* Parallel IO Controller B */
-#define AT91RM9200_ID_PIOC 4   /* Parallel IO Controller C */
-#define AT91RM9200_ID_PIOD 5   /* Parallel IO Controller D */
-#define AT91RM9200_ID_US0  6   /* USART 0 */
-#define AT91RM9200_ID_US1  7   /* USART 1 */
-#define AT91RM9200_ID_US2  8   /* USART 2 */
-#define AT91RM9200_ID_US3  9   /* USART 3 */
-#define AT91RM9200_ID_MCI  10  /* Multimedia Card Interface */
-#define AT91RM9200_ID_UDP  11  /* USB Device Port */
-#define AT91RM9200_ID_TWI  12  /* Two-Wire Interface */
-#define AT91RM9200_ID_SPI  13  /* Serial Peripheral Interface */
-#define AT91RM9200_ID_SSC0 14  /* Serial Synchronous Controller 0 */
-#define AT91RM9200_ID_SSC1 15  /* Serial Synchronous Controller 1 */
-#define AT91RM9200_ID_SSC2 16  /* Serial Synchronous Controller 2 */
-#define AT91RM9200_ID_TC0  17  /* Timer Counter 0 */
-#define AT91RM9200_ID_TC1  18  /* Timer Counter 1 */
-#define AT91RM9200_ID_TC2  19  /* Timer Counter 2 */
-#define AT91RM9200_ID_TC3  20  /* Timer Counter 3 */
-#define AT91RM9200_ID_TC4  21  /* Timer Counter 4 */
-#define AT91RM9200_ID_TC5  22  /* Timer Counter 5 */
-#define AT91RM9200_ID_UHP  23  /* USB Host port */
-#define AT91RM9200_ID_EMAC 24  /* Ethernet MAC */
-#define AT91RM9200_ID_IRQ0 25  /* Advanced Interrupt Controller (IRQ0) 
*/
-#define AT91RM9200_ID_IRQ1 26  /* Advanced Interrupt Controller (IRQ1) 
*/
-#define AT91RM9200_ID_IRQ2 27  /* Advanced Interrupt Controller (IRQ2) 
*/
-#define AT91RM9200_ID_IRQ3 28  /* Advanced Interrupt Controller (IRQ3) 
*/
-#define AT91RM9200_ID_IRQ4 29  /* Advanced Interrupt Controller (IRQ4) 
*/
-#define AT91RM9200_ID_IRQ5 30  /* Advanced Interrupt Controller (IRQ5) 
*/
-#define AT91RM9200_ID_IRQ6 31  /* Advanced Interrupt Controller (IRQ6) 
*/
-
-
-/*
- * Peripheral physical base addresses.
- */
-#define AT91RM9200_BASE_TCB0   0xfffa
-#define AT91RM9200_BASE_TC00xfffa
-#define AT91RM9200_BASE_TC10xfffa0040
-#define AT91RM9200_BASE_TC20xfffa0080
-#define AT91RM9200_BASE_TCB1   0xfffa4000
-#define AT91RM9200_BASE_TC30xfffa4000
-#define AT91RM9200_BASE_TC40xfffa4040
-#define AT91RM9200_BASE_TC50xfffa4080
-#define AT91RM9200_BASE_UDP0xfffb
-#define AT91RM9200_BASE_MCI0xfffb4000
-#define AT91RM9200_BASE_TWI0xfffb8000
-#define AT91RM9200_BASE_EMAC   0xfffbc000
-#defin

[PATCH v3 6/7] ARM: at91: remove hardware.h

2015-03-13 Thread Alexandre Belloni
hardware.h is now mostyl unused, move the remaining declarations to pm.c and
remove it.

Signed-off-by: Alexandre Belloni 
---
 arch/arm/mach-at91/include/mach/hardware.h | 123 -
 arch/arm/mach-at91/pm.c|  11 ++-
 arch/arm/mach-at91/pm_suspend.S|   1 -
 arch/arm/mach-at91/sama5.c |   2 -
 4 files changed, 9 insertions(+), 128 deletions(-)
 delete mode 100644 arch/arm/mach-at91/include/mach/hardware.h

diff --git a/arch/arm/mach-at91/include/mach/hardware.h 
b/arch/arm/mach-at91/include/mach/hardware.h
deleted file mode 100644
index 2f8ce2d69fdb..
--- a/arch/arm/mach-at91/include/mach/hardware.h
+++ /dev/null
@@ -1,123 +0,0 @@
-/*
- * arch/arm/mach-at91/include/mach/hardware.h
- *
- *  Copyright (C) 2003 SAN People
- *  Copyright (C) 2003 ATMEL
- *
- * 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.
- *
- */
-
-#ifndef __ASM_ARCH_HARDWARE_H
-#define __ASM_ARCH_HARDWARE_H
-
-#include 
-
-/* DBGU base */
-/* rm9200, 9260/9g20, 9261/9g10, 9rl */
-#define AT91_BASE_DBGU00xf200
-/* 9263, 9g45, sama5d3 */
-#define AT91_BASE_DBGU10xee00
-/* sama5d4 */
-#define AT91_BASE_DBGU20xfc069000
-
-/*
- * On all at91 except rm9200 and x40 have the System Controller starts
- * at address 0xc000 and has a size of 16KiB.
- *
- * On rm9200 it's start at 0xfffe4000 of 111KiB with non reserved data starting
- * at 0xf000
- *
- * Removes the individual definitions of AT91_BASE_SYS and
- * replaces them with a common version at base 0xfc000 and size 16KiB
- * and map the same memory space
- */
-#define AT91_BASE_SYS  0xc000
-
-/*
- * On sama5d4 there is no system controller, we map some needed peripherals
- */
-#define AT91_ALT_BASE_SYS  0xfc069000
-
-/*
- * On all at91 have the Advanced Interrupt Controller starts at address
- * 0xf000 and the Power Management Controller starts at 0xfc00
- */
-#define AT91_AIC   0xf000
-#define AT91_PMC   0xfc00
-
-/*
- * Peripheral identifiers/interrupts.
- */
-#define AT91_ID_FIQ0   /* Advanced Interrupt Controller (FIQ) 
*/
-#define AT91_ID_SYS1   /* System Peripherals */
-
-#ifdef CONFIG_MMU
-/*
- * Remap the peripherals from address 0xFFF78000 .. 0x
- * to 0xFEF78000 .. 0xFF00.  (544Kb)
- */
-#define AT91_IO_PHYS_BASE  0xFFF78000
-#define AT91_IO_VIRT_BASE  IOMEM(0xFF00 - AT91_IO_SIZE)
-
-/*
- * On sama5d4, remap the peripherals from address 0xFC069000 .. 0xFC06F000
- * to 0xFB069000 .. 0xFB06F000.  (24Kb)
- */
-#define AT91_ALT_IO_PHYS_BASE  AT91_ALT_BASE_SYS
-#define AT91_ALT_IO_VIRT_BASE  IOMEM(0xFB069000)
-#else
-/*
- * Identity mapping for the non MMU case.
- */
-#define AT91_IO_PHYS_BASE  AT91_BASE_SYS
-#define AT91_IO_VIRT_BASE  IOMEM(AT91_IO_PHYS_BASE)
-
-#define AT91_ALT_IO_PHYS_BASE  AT91_ALT_BASE_SYS
-#define AT91_ALT_IO_VIRT_BASE  IOMEM(AT91_ALT_BASE_SYS)
-#endif
-
-#define AT91_IO_SIZE   (0x - AT91_IO_PHYS_BASE + 1)
-
- /* Convert a physical IO address to virtual IO address */
-#define AT91_IO_P2V(x) ((x) - AT91_IO_PHYS_BASE + AT91_IO_VIRT_BASE)
-#define AT91_ALT_IO_P2V(x) ((x) - AT91_ALT_IO_PHYS_BASE + 
AT91_ALT_IO_VIRT_BASE)
-
-/*
- * Virtual to Physical Address mapping for IO devices.
- */
-#define AT91_VA_BASE_SYS   AT91_IO_P2V(AT91_BASE_SYS)
-#define AT91_ALT_VA_BASE_SYS   AT91_ALT_IO_P2V(AT91_ALT_BASE_SYS)
-
- /* Internal SRAM is mapped below the IO devices */
-#define AT91_SRAM_MAX  SZ_1M
-#define AT91_VIRT_BASE (AT91_IO_VIRT_BASE - AT91_SRAM_MAX)
-
-/* External Memory Map */
-#define AT91_CHIPSELECT_0  0x1000
-#define AT91_CHIPSELECT_1  0x2000
-#define AT91_CHIPSELECT_2  0x3000
-#define AT91_CHIPSELECT_3  0x4000
-#define AT91_CHIPSELECT_4  0x5000
-#define AT91_CHIPSELECT_5  0x6000
-#define AT91_CHIPSELECT_6  0x7000
-#define AT91_CHIPSELECT_7  0x8000
-
-/* Clocks */
-#define AT91_SLOW_CLOCK32768   /* slow clock */
-
-/*
- * FIXME: this is needed to communicate between the pinctrl driver and
- * the PM implementation in the machine. Possibly part of the PM
- * implementation should be moved down into the pinctrl driver and get
- * called as part of the generic suspend/resume path.
- */
-#ifndef __ASSEMBLY__
-extern void at91_pinctrl_gpio_suspend(void);
-extern void at91_pinctrl_gpio_resume(void);
-#endif
-
-#endif
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 2a12c01afc67..f93a735ba327 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -32,11 +32,18 @@
 #include 
 #include 
 
-#include 
-
 #include "generic.h"
 #include "pm.h"
 
+/*
+ * FIXME: this is needed to communicate be

  1   2   3   4   5   6   7   8   9   >