[PATCH] staging: lustre: replace static value with define

[Tristan Lelong]

This patch replace the value '80' used in several files in the lustre source 
code
with a define LUSTRE_MDT_MAXNAMELEN.

This value is used in 4 different structures as the maximum len for a service 
name.
According to the comments, these names follow a convention which make it 
possible
to use the same define for LCS, LSS, LCF, and LSF names.

Signed-off-by: Tristan Lelong 
---
Note:
This modification answers Joe Perches suggestion: 
https://lkml.org/lkml/2014/12/5/107
The patch has to be applied on top of https://lkml.org/lkml/2014/12/6/17
---
 drivers/staging/lustre/lustre/fld/fld_internal.h  | 2 +-
 drivers/staging/lustre/lustre/fld/lproc_fld.c | 2 +-
 drivers/staging/lustre/lustre/include/lustre/lustre_idl.h | 5 +
 drivers/staging/lustre/lustre/include/lustre_fid.h| 4 ++--
 drivers/staging/lustre/lustre/include/lustre_fld.h| 4 ++--
 5 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/fld/fld_internal.h 
b/drivers/staging/lustre/lustre/fld/fld_internal.h
index 8806b60..6125bbe 100644
--- a/drivers/staging/lustre/lustre/fld/fld_internal.h
+++ b/drivers/staging/lustre/lustre/fld/fld_internal.h
@@ -111,7 +111,7 @@ struct fld_cache {
 
/**
 * Cache name used for debug and messages. */
-   char fci_name[80];
+   char fci_name[LUSTRE_MDT_MAXNAMELEN];
unsigned int fci_no_shrink:1;
 };
 
diff --git a/drivers/staging/lustre/lustre/fld/lproc_fld.c 
b/drivers/staging/lustre/lustre/fld/lproc_fld.c
index 74b4db9..7a55941 100644
--- a/drivers/staging/lustre/lustre/fld/lproc_fld.c
+++ b/drivers/staging/lustre/lustre/fld/lproc_fld.c
@@ -96,7 +96,7 @@ fld_proc_hash_seq_write(struct file *file,
char *name;
int i;
 
-   if (count > 80)
+   if (count > LUSTRE_MDT_MAXNAMELEN)
return -ENAMETOOLONG;
 
name = kmalloc(count, GFP_KERNEL);
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index 7b7457c..305ecbe 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -105,6 +105,11 @@
  * FOO_BULK_PORTALis for incoming bulk on the FOO
  */
 
+/* Lustre service names are following the format
+ * service name + MDT + seq name
+ */
+#define LUSTRE_MDT_MAXNAMELEN  80
+
 #define CONNMGR_REQUEST_PORTAL   1
 #define CONNMGR_REPLY_PORTAL   2
 //#define OSC_REQUEST_PORTAL   3
diff --git a/drivers/staging/lustre/lustre/include/lustre_fid.h 
b/drivers/staging/lustre/lustre/include/lustre_fid.h
index 2d6fbb4..0a0929f 100644
--- a/drivers/staging/lustre/lustre/include/lustre_fid.h
+++ b/drivers/staging/lustre/lustre/include/lustre_fid.h
@@ -358,7 +358,7 @@ struct lu_client_seq {
 * Service uuid, passed from MDT + seq name to form unique seq name to
 * use it with procfs.
 */
-   charlcs_name[80];
+   charlcs_name[LUSTRE_MDT_MAXNAMELEN];
 
/*
 * Sequence width, that is how many objects may be allocated in one
@@ -408,7 +408,7 @@ struct lu_server_seq {
 * Service uuid, passed from MDT + seq name to form unique seq name to
 * use it with procfs.
 */
-   charlss_name[80];
+   charlss_name[LUSTRE_MDT_MAXNAMELEN];
 
/*
 * Allocation chunks for super and meta sequences. Default values are
diff --git a/drivers/staging/lustre/lustre/include/lustre_fld.h 
b/drivers/staging/lustre/lustre/include/lustre_fld.h
index 64c5048..5ee4b1e 100644
--- a/drivers/staging/lustre/lustre/include/lustre_fld.h
+++ b/drivers/staging/lustre/lustre/include/lustre_fld.h
@@ -93,7 +93,7 @@ struct lu_server_fld {
 
/**
 * Fld service name in form "fld-srv-lustre-MDTXXX" */
-   char lsf_name[80];
+   char lsf_name[LUSTRE_MDT_MAXNAMELEN];
 
 };
 
@@ -124,7 +124,7 @@ struct lu_client_fld {
 
/**
 * Client fld proc entry name. */
-   char lcf_name[80];
+   char lcf_name[LUSTRE_MDT_MAXNAMELEN];
 
int   lcf_flags;
 };
-- 
2.1.1

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

Re: [PATCH v5 0/6] fix hw_random stuck

[Herbert Xu]

On Sat, Dec 06, 2014 at 12:16:36PM +0800, Amos Kong wrote:
> When I hotunplug a busy virtio-rng device or try to access
> hwrng attributes in non-smp guest, it gets stuck.

Please resend these via the linux-crypto mailing list so they
can be picked up by patchwork.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: lustre: fix sparse warning on LPROC_SEQ_FOPS macros

[Tristan Lelong]

This patch fix a sparse warning in lustre sources

warning: incorrect type in argument 1 (different address spaces)
expected void [noderef] *to
got char *

This is done by adding the missing __user attribute on userland pointers inside 
the LPROC_SEQ_FOPS like macros:
- LPROC_SEQ_FOPS
- LPROC_SEQ_FOPS_RW_TYPE
- LPROC_SEQ_FOPS_WR_ONLY
- LDLM_POOL_PROC_WRITER

The patch also updates all the functions that are used by this macro:
- lprocfs_wr_*
- *_seq_write

as well as some helpers used by the previously modified functions (otherwise 
fixing the sparse warning add some new ones):
- lprocfs_write_frac_helper
- lprocfs_write_helper
- lprocfs_write_u64_helper

The patch also fixes one __user pointer direct dereference by strncmp in 
function fld_proc_hash_seq_write.

Signed-off-by: Tristan Lelong 
---
Changes in v2:
Use dynamic allocation for 'name' variable instead of having it on the 
stack, per Greg K-H suggestion.
---
 drivers/staging/lustre/lustre/fld/lproc_fld.c  | 19 ++--
 .../staging/lustre/lustre/include/lprocfs_status.h | 44 +
 drivers/staging/lustre/lustre/ldlm/ldlm_internal.h |  5 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_pool.c |  4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_resource.c |  7 +--
 drivers/staging/lustre/lustre/lov/lproc_lov.c  | 20 +---
 drivers/staging/lustre/lustre/mdc/lproc_mdc.c  |  7 +--
 .../lustre/lustre/obdclass/linux/linux-module.c|  5 +-
 .../lustre/lustre/obdclass/lprocfs_status.c|  2 +-
 drivers/staging/lustre/lustre/osc/lproc_osc.c  | 57 +-
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c| 25 +-
 11 files changed, 119 insertions(+), 76 deletions(-)

diff --git a/drivers/staging/lustre/lustre/fld/lproc_fld.c 
b/drivers/staging/lustre/lustre/fld/lproc_fld.c
index 95e7de1..74b4db9 100644
--- a/drivers/staging/lustre/lustre/fld/lproc_fld.c
+++ b/drivers/staging/lustre/lustre/fld/lproc_fld.c
@@ -87,13 +87,25 @@ fld_proc_hash_seq_show(struct seq_file *m, void *unused)
 }
 
 static ssize_t
-fld_proc_hash_seq_write(struct file *file, const char *buffer,
-   size_t count, loff_t *off)
+fld_proc_hash_seq_write(struct file *file,
+   const char __user *buffer,
+   size_t count, loff_t *off)
 {
struct lu_client_fld *fld;
struct lu_fld_hash *hash = NULL;
+   char *name;
int i;
 
+   if (count > 80)
+   return -ENAMETOOLONG;
+
+   name = kmalloc(count, GFP_KERNEL);
+   if (!name)
+   return -ENOMEM;
+
+   if (copy_from_user(name, buffer, count) != 0)
+   return -EFAULT;
+
fld = ((struct seq_file *)file->private_data)->private;
LASSERT(fld != NULL);
 
@@ -101,7 +113,7 @@ fld_proc_hash_seq_write(struct file *file, const char 
*buffer,
if (count != strlen(fld_hash[i].fh_name))
continue;
 
-   if (!strncmp(fld_hash[i].fh_name, buffer, count)) {
+   if (!strncmp(fld_hash[i].fh_name, name, count)) {
hash = _hash[i];
break;
}
@@ -116,6 +128,7 @@ fld_proc_hash_seq_write(struct file *file, const char 
*buffer,
   fld->lcf_name, hash->fh_name);
}
 
+   kfree(name);
return count;
 }
 
diff --git a/drivers/staging/lustre/lustre/include/lprocfs_status.h 
b/drivers/staging/lustre/lustre/include/lprocfs_status.h
index cfe503b..8a25cf6 100644
--- a/drivers/staging/lustre/lustre/include/lprocfs_status.h
+++ b/drivers/staging/lustre/lustre/include/lprocfs_status.h
@@ -627,16 +627,16 @@ struct adaptive_timeout;
 extern int lprocfs_at_hist_helper(struct seq_file *m,
  struct adaptive_timeout *at);
 extern int lprocfs_rd_timeouts(struct seq_file *m, void *data);
-extern int lprocfs_wr_timeouts(struct file *file, const char *buffer,
+extern int lprocfs_wr_timeouts(struct file *file, const char __user *buffer,
   unsigned long count, void *data);
-extern int lprocfs_wr_evict_client(struct file *file, const char *buffer,
+extern int lprocfs_wr_evict_client(struct file *file, const char __user 
*buffer,
size_t count, loff_t *off);
-extern int lprocfs_wr_ping(struct file *file, const char *buffer,
+extern int lprocfs_wr_ping(struct file *file, const char __user *buffer,
   size_t count, loff_t *off);
-extern int lprocfs_wr_import(struct file *file, const char *buffer,
+extern int lprocfs_wr_import(struct file *file, const char __user *buffer,
  size_t count, loff_t *off);
 extern int lprocfs_rd_pinger_recov(struct seq_file *m, void *n);
-extern int lprocfs_wr_pinger_recov(struct file *file, const char *buffer,
+extern int lprocfs_wr_pinger_recov(struct file *file, const char __user 
*buffer,
   size_t count, 

Re: Interested in bcache

[Adam Brenner]

On Fri, Dec 5, 2014 at 6:55 PM, Kent Overstreet  wrote:
> What did you have in mind?
>
> On Fri, Dec 5, 2014 at 6:55 PM, nick  wrote:
>> Greetings fellow Maintainers,
>> I am wondering about how to get started with bcache. This is due to be 
>> reading the documentation in the kernel tree and being interested in started 
>> to help out.
>> Cheers Nick

FYI: https://lkml.org/lkml/2014/8/4/206

/adam

-- 
Adam Brenner
Computer Science, Undergraduate Student
Donald Bren School of Information and Computer Sciences

System Administrator, HPC Cluster
Office of Information Technology
http://hpc.oit.uci.edu/

University of California, Irvine
www.ics.uci.edu/~aebrenne/
aebre...@uci.edu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: include text files in SPACE_BEFORE_TAB test

[Frank Rowand]

From: Frank Rowand 

git-am whined about a patch that I submitted for the Documentation
subtree, (https://lkml.org/lkml/2014/11/24/636) but checkpatch does
not.  Make checkpatch just as whiney.

This patch moves the SPACE_BEFORE_TAB test before the check that
excludes text files and also before the test that excludes
assembly files.  It seems to me that both CODE_INDENT and
SPACE_BEFORE_TAB are valid tests for assembly files, but I
added an if around the moved CODE_INDENT test to include only
source files, not including assembly files.  Thus this patch
does not change which files are subject to CODE_INDENT.

The CODE_INDENT test is moved along with the SPACE_BEFORE_TAB
test because the c76f4cb3d25e commit log says:

This SPACE_BEFORE_TAB test is done after CODE_INDENT.

If there are spaces used at the beginning of a line that should be
converted to tabs, please make sure that the CODE_INDENT test and
conversion is done before this SPACE_BEFORE_TAB test and conversion.

Signed-off-by: Frank Rowand 
---


Andy, Joe,

Assembly files are still excluded from the CODE_INDENT test -- do you
want to make another change to include them?


---
 scripts/checkpatch.pl |   56 ++
 1 file changed, 30 insertions(+), 26 deletions(-)

Index: b/scripts/checkpatch.pl
===
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2389,6 +2389,36 @@ sub process {
}
}
 
+# at the beginning of a line any tabs must come first and anything
+# more than 8 must use tabs.
+# do CODE_INDENT test before SPACE_BEFORE_TAB test (c76f4cb3d25e)
+   if ($realfile =~ /\.(h|c|pl|dtsi|dts)$/) {
+   if ($rawline =~ /^\+\s* \t\s*\S/ ||
+   $rawline =~ /^\+\s*\s*/) {
+   my $herevet = "$here\n" . cat_vet($rawline) . 
"\n";
+   $rpt_cleaners = 1;
+   if (ERROR("CODE_INDENT",
+ "code indent should use tabs where 
possible\n" . $herevet) &&
+   $fix) {
+   $fixed[$fixlinenr] =~ s/^\+([ 
\t]+)/"\+" . tabify($1)/e;
+   }
+   }
+   }
+
+# check for space before tabs.
+   if ($rawline =~ /^\+/ && $rawline =~ / \t/) {
+   my $herevet = "$here\n" . cat_vet($rawline) . "\n";
+   if (WARN("SPACE_BEFORE_TAB",
+   "please, no space before tabs\n" . $herevet) &&
+   $fix) {
+   while ($fixed[$fixlinenr] =~
+  s/(^\+.*) {8,8}\t/$1\t\t/) {}
+   while ($fixed[$fixlinenr] =~
+  s/(^\+.*) +\t/$1\t/) {}
+   }
+   }
+
+
 # check we are in a valid source file if not then ignore this hunk
next if ($realfile !~ /\.(h|c|s|S|pl|sh|dtsi|dts)$/);
 
@@ -2453,32 +2483,6 @@ sub process {
 # check we are in a valid source file C or perl if not then ignore this hunk
next if ($realfile !~ /\.(h|c|pl|dtsi|dts)$/);
 
-# at the beginning of a line any tabs must come first and anything
-# more than 8 must use tabs.
-   if ($rawline =~ /^\+\s* \t\s*\S/ ||
-   $rawline =~ /^\+\s*\s*/) {
-   my $herevet = "$here\n" . cat_vet($rawline) . "\n";
-   $rpt_cleaners = 1;
-   if (ERROR("CODE_INDENT",
- "code indent should use tabs where 
possible\n" . $herevet) &&
-   $fix) {
-   $fixed[$fixlinenr] =~ s/^\+([ \t]+)/"\+" . 
tabify($1)/e;
-   }
-   }
-
-# check for space before tabs.
-   if ($rawline =~ /^\+/ && $rawline =~ / \t/) {
-   my $herevet = "$here\n" . cat_vet($rawline) . "\n";
-   if (WARN("SPACE_BEFORE_TAB",
-   "please, no space before tabs\n" . $herevet) &&
-   $fix) {
-   while ($fixed[$fixlinenr] =~
-  s/(^\+.*) {8,8}\t/$1\t\t/) {}
-   while ($fixed[$fixlinenr] =~
-  s/(^\+.*) +\t/$1\t/) {}
-   }
-   }
-
 # check for && or || at the start of a line
if ($rawline =~ /^\+\s*(&&|\|\|)/) {
CHK("LOGICAL_CONTINUATIONS",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH v2 net-next 0/6] allow eBPF programs to be attached to sockets

[David Miller]

From: Alexei Starovoitov 
Date: Mon,  1 Dec 2014 15:06:33 -0800

> V1->V2:
> 
> fixed comments in sample code to state clearly that packet data is accessed
> with LD_ABS instructions and not internal skb fields.
> Also replaced constants in:
> BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
> with:
> BPF_LD_ABS(BPF_B, ETH_HLEN + offsetof(struct iphdr, protocol) /* R0 = 
> ip->proto */),
> 
> V1 cover:
> 
> Introduce BPF_PROG_TYPE_SOCKET_FILTER type of eBPF programs that can be
> attached to sockets with setsockopt().
> Allow such programs to access maps via lookup/update/delete helpers.
> 
> This feature was previewed by bpf manpage in commit b4fc1a460f30("Merge 
> branch 'bpf-next'")
> Now it can actually run.
> 
> 1st patch adds LD_ABS/LD_IND instruction verification and
> 2nd patch adds new setsockopt() flag.
> Patches 3-6 are examples in assembler and in C.
> 
> Though native eBPF programs are way more powerful than classic filters
> (attachable through similar setsockopt() call), they don't have skb field
> accessors yet. Like skb->pkt_type, skb->dev->ifindex are not accessible.
> There are sevaral ways to achieve that. That will be in the next set of 
> patches.
> So in this set native eBPF programs can only read data from packet and
> access maps.
> 
> The most powerful example is sockex2_kern.c from patch 6 where ~200 lines of C
> are compiled into ~300 of eBPF instructions.
> It shows how quite complex packet parsing can be done.
> 
> LLVM used to build examples is at https://github.com/iovisor/llvm
> which is fork of llvm trunk that I'm cleaning up for upstreaming.

Series applied, 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/

Re: [PATCH V4 net-next] tun/macvtap: use consume_skb() instead of kfree_skb() when needed

[David Miller]

From: Jason Wang 
Date: Mon,  1 Dec 2014 16:53:15 +0800

> To be more friendly with drop monitor, we should only call kfree_skb() when
> the packets were dropped and use consume_skb() in other cases.
> 
> Cc: Eric Dumazet 
> Signed-off-by: Jason Wang 

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

Re: [PATCH] uapi: fix to export linux/vm_sockets.h

[David Miller]

From: Masahiro Yamada 
Date: Mon,  1 Dec 2014 10:16:17 +0900

> A typo "header=y" was introduced by commit 7071cf7fc435
> (uapi: add missing network related headers to kbuild).
> 
> Signed-off-by: Masahiro Yamada 
> Cc: Stephen Hemminger 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] skge: Unmask interrupts in case of spurious interrupts

[David Miller]

From: Lino Sanfilippo 
Date: Sun, 30 Nov 2014 12:51:31 +0100

> In case of a spurious interrupt dont forget to reenable the interrupts that
> have been masked by reading the interrupt source register.
> 
> Signed-off-by: Lino Sanfilippo 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sky2: avoid pci write posting after disabling irqs

[David Miller]

From: Lino Sanfilippo 
Date: Sun, 30 Nov 2014 12:56:51 +0100

> In sky2_change_mtu setting B0_IMSK to 0 may be delayed due to PCI write 
> posting
> which could result in irqs being still active when synchronize_irq is called.
> Since we are not prepared to handle any further irqs after synchronize_irq
> (our resources are freed after that) force the write by a consecutive read 
> from
> the same register.
> Similar situation in sky2_all_down: Here we disabled irqs by a write to 
> B0_IMSK
> but did not ensure that this write took place before synchronize_irq. Fix that
> too.
> 
> Signed-off-by: Lino Sanfilippo 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pxa168: close race between napi and irq activation

[David Miller]

From: Lino Sanfilippo 
Date: Sun, 30 Nov 2014 11:49:36 +0100

> In pxa168_eth_open() the irqs are enabled before napi. This opens a tiny time
> window in which the irq handler is processed, disables irqs but then is not 
> able
> to schedule the not yet activated napi, leaving irqs disabled forever (since
> irqs are reenabled in napi poll function).
> Fix this race by activating napi before irqs are activated.
> 
> Signed-off-by: Lino Sanfilippo 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bpf: x86: fix epilogue generation for eBPF programs

[David Miller]

From: Alexei Starovoitov 
Date: Sat, 29 Nov 2014 14:46:13 -0800

> classic BPF has a restriction that last insn is always BPF_RET.
> eBPF doesn't have BPF_RET instruction and this restriction.
> It has BPF_EXIT insn which can appear anywhere in the program
> one or more times and it doesn't have to be last insn.
> Fix eBPF JIT to emit epilogue when first BPF_EXIT is seen
> and all other BPF_EXIT instructions will be emitted as jump.
> 
> Since jump offset to epilogue is computed as:
> jmp_offset = ctx->cleanup_addr - addrs[i]
> we need to change type of cleanup_addr to signed to compute the offset as:
> (long long) ((int)20 - (int)30)
> instead of:
> (long long) ((unsigned int)20 - (int)30)
> 
> Fixes: 622582786c9e ("net: filter: x86: internal BPF JIT")
> Signed-off-by: Alexei Starovoitov 

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

Re: [PATCH 3.17 000/122] 3.17.5-stable review

[Guenter Roeck]

On 12/05/2014 07:44 PM, Greg Kroah-Hartman wrote:

On Fri, Dec 05, 2014 at 07:30:48PM -0800, Guenter Roeck wrote:

On 12/05/2014 02:42 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.17.5 release.
There are 122 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Dec  7 22:32:17 UTC 2014.
Anything received after that time might be too late.



Build results:
total: 133 pass: 132 fail: 1
Failed builds:
avr32:atngw100mkii_evklcd101_defconfig


Bah, it looks like no one cares about avr32 anymore :(



Hard to imagine that anyone working on a new design would select an atmel chip
with avr32 core instead of one with arm core. So that isn't really surprising.

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 1/1] net-ipvlan: Deletion of an unnecessary check before the function call "free_percpu"

[David Miller]

From: SF Markus Elfring 
Date: Sat, 29 Nov 2014 16:30:27 +0100

> From: Markus Elfring 
> Date: Sat, 29 Nov 2014 16:23:20 +0100
> 
> The free_percpu() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

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

Re: [PATCH 1/1] net-PA Semi: Deletion of unnecessary checks before the function call "pci_dev_put"

[David Miller]

From: SF Markus Elfring 
Date: Sat, 29 Nov 2014 19:00:17 +0100

> From: Markus Elfring 
> Date: Sat, 29 Nov 2014 18:55:40 +0100
> 
> The pci_dev_put() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call
> is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: frequent lockups in 3.18rc4

[Gene Heskett]

On Friday 05 December 2014, Linus Torvalds wrote:
>On Fri, Dec 5, 2014 at 9:15 AM, Dave Jones  wrote:
>> A bisect later, and I landed on a kernel that ran for a day, before
>> spewing NMI messages, recovering, and then..
>> 
>> http://codemonkey.org.uk/junk/log.txt
>
>I have to admit I'm seeing absolutely nothing sensible in there.
>
>Call it bad, and see if bisection ends up slowly -oh so slowly -
>pointing to some direction. Because I don't think it's the hardware,
>considering that apparently 3.16 is solid. And the spews themselves
>are so incomprehensible that I'm not seeing any pattern what-so-ever.
>
> Linus

Sort of in the FWIW category, may not mean a thing.

I did find something in 3.16.0 that is troubling me at times, causing a 
very busy quad core Phenom.  But I have located the culprit in my case. 

Look at your Xorg.0.log. Because the nouveau bits in the 3.16.0 kernel I'm 
using are no longer 100% compatible with an Xorg install thats now 5 years 
old, I am generating Xorg.0.logs that can reach 500 megabyte or more in a 
couple weeks. I am trying to run down the latest Xorg I can build here on 
this *buntu 10.04.4 LTS box, but haven't located a URL to get the tarball 
from. Yet, its been busy here.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] net: cassini: Deletion of an unnecessary check before the function call "vfree"

[David Miller]

From: SF Markus Elfring 
Date: Sat, 29 Nov 2014 15:05:33 +0100

> From: Markus Elfring 
> Date: Sat, 29 Nov 2014 14:34:59 +0100
> 
> The vfree() function performs also input parameter validation.
> Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

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

Re: [PATCH 1/1] Drivers: hv: vmbus: Implement a clockevent device

[Greg KH]

On Fri, Dec 05, 2014 at 07:58:44PM -0800, K. Y. Srinivasan wrote:
> Implement a clockevent device based on the timer support available on
> Hyper-V.
> In this version of the patch I have addressed Jason's review comments.
> 
> Signed-off-by: K. Y. Srinivasan 
> Reviewed-by: Jason Wang 
> ---

Why did you resend the 1st version of this patch?

If you didn't send the first version, why is there no more "vX" on the
Subject line?

confused.

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

Re: PROBLEM: [Launchpad #1396889] [Lenovo ThinkPad T400] kexec reboot fails

[Baoquan He]

On 12/06/14 at 04:10am, MegaBrutal wrote:
> 2014-12-01 23:59 GMT+01:00 Kees Cook :
> >
> > I suspect you're encountering a subset of the same problems as
> > described in this thread:
> > https://lkml.org/lkml/2014/9/30/90
> >
> > If you can test those patches, that may help demonstrate their utility.
> >
> > Thanks!
> 
> Bang ji le! It works with the patch you linked, xiexie!
> I suggest it to be merged into mainline.
> 
> Anyway, is there a way to get sure that KASLR actually works now?
> (I.e. how do I know if the kernel is really loaded to a random
> address?)

I usually check the elf header of /proc/kcore which represents the
physical memory of the system and is stored in the ELF core file format.
Without kaslr, the kernel text mapping should be in virtual addr
0x8100. With kaslr enabled, the addr would be anywhere
between 0x8000 and 0xc000.

> Do you have any idea what might be different with my ThinkPad T400
> that it is the only one of my machines affected?

That's weird. I suggest you check the config file for that running
kernel in your ThinkPad T400. If you have below config, that means your
kernel support kaslr and enable it by default, unless you specify
nokaslr in cmdline to disalbe it.
CONFIG_RANDOMIZE_BASE=y
CONFIG_RANDOMIZE_BASE_MAX_OFFSET=0x4000 

Different kind of machines should not affect this.

Thanks
Baoquan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dell-smo8800: Add more ACPI ids and change description of driver

[Darren Hart]

On Fri, Dec 05, 2014 at 01:05:46PM +0100, Pali Rohár wrote:
> This patch adds other ACPI ids from Windows inf driver which should be handled
> by dell-smo8800 driver. ACPI devices have same structure -- one IRQ number.
> 
> This patch also updates description of module.
> 
> Signed-off-by: Pali Rohár 

Queued to testing, thanks Pali.

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

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Jike Song]

On 12/05/2014 09:54 PM, Daniel Vetter wrote:

Yeah done a quick read-through of just the i915 bits too, same comment. I
guess this is just the first RFC and the redesign we've discussed about
already with xengt is in progress somewhere?


Yes, it's marching on with Xen now. The KVM implementation is
currently not even feature complete - we still have PPGTT missing.




Thanks, Daniel



--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] dell-wmi: Don't send unneeded keypresses

[Darren Hart]

On Fri, Dec 05, 2014 at 10:07:35PM +0100, Pali Rohár wrote:
> On Friday 05 December 2014 21:41:22 Pavel Machek wrote:
> > On Fri 2014-12-05 21:31:34, Pali Rohár wrote:
> > > On Wednesday 03 December 2014 14:34:32 Darren Hart wrote:
> > > > On Thu, Dec 04, 2014 at 12:16:20AM +0100, Gabriele
> > > > Mazzotta
> > > 
> > > wrote:
> > > > > Currently dell-wmi reports keypresses for WMI events
> > > > > that are notifications of changes performed by the
> > > > > BIOS. This patch series make sure that no keypresses
> > > > > are sent for those events so that nothing is done from
> > > > > userspace.
> > > > > 
> > > > > Gabriele Mazzotta (3):
> > > > >   dell-wmi: Use appropriate keycode for radio state
> > > > >   changes dell-wmi: Don't report keypresses for radio
> > > > >   state changes
> > > > 
> > > > Merged into one patch, queued.
> > > > 
> > > > >   dell-wmi: Don't report keypresses on keybord
> > > > >   illumination change
> > > > 
> > > > Queued.
> > > > 
> > > > Thanks Gabriele.
> > > 
> > > Darren, what do you think about sending patch into stable
> > > kernel?
> > 
> > I'd suggest against that. -stable is for "serious" bugs, and
> > we don't want to change this kind of behaviour in -stable
> > kernel.
> > 
> > Pavel
> 
> Ok, I agree that it is subjective how serious it is...
> Just to remind that patch fixing problem described in
> 
> http://www.spinics.net/lists/platform-driver-x86/msg05922.html
> http://www.spinics.net/lists/platform-driver-x86/msg05924.html

I don't have any objection to sending this back to stable. Stable is for fixing
REAL bugs, as opposed to theorhetical races, etc. This is a "real" bug.

As to not chaning behavior, if it's OK for mainline, it's OK for stable. At
least that is my understanding of it. Folks are free to verify with Greg if they
disagree.

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

Re: [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Jike Song]

CC Andy :)

On 12/05/2014 09:03 PM, Paolo Bonzini wrote:


On 05/12/2014 09:50, Gerd Hoffmann wrote:

A few comments on the kernel stuff (brief look so far, also
compile-tested only, intel gfx on my test machine is too old).

  * Noticed the kernel bits don't even compile when configured as
module.  Everything (vgt, i915, kvm) must be compiled into the
kernel.


I'll add that the patch is basically impossible to review with all the
XenGT bits still in.  For example, the x86 emulator seems to be
unnecessary for KVMGT, but I am not 100% sure.



This is not ready for merge yet, please wait for a while, we'll have
Xen/KVM specific code separated.

BTW, definitely you are right, the emulator is unnecessary for KVMGT,
and ... unnecessary for XenGT :)


I would like a clear understanding of why/how Andrew Barnes was able to
do i915 passthrough (GVT-d) without hacking the ISA bridge, and why this
does not apply to GVT-g.


AFAIK, the graphics drivers need to figure out the offset of
some MMIO registers, by the IDs of this ISA bridge. It simply won't work
without this information.

Talked with Andy about the pass-through but I don't have his implementation,
CC Andy for his advice :)



Paolo



Thanks for review. Would you please also have a look at the issues I mentioned
in the original email? they are most KVM-related: the SRCU trickiness, domid,
and the memslot created in kernel.

Thank you!

--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] platform: x86: dell-laptop: Add support for keyboard backlight

[Darren Hart]

On Fri, Dec 05, 2014 at 12:53:31PM +0100, Pali Rohár wrote:
> This patch adds support for configuring keyboard backlight settings on 
> supported
> Dell laptops. It exports kernel leds interface and uses Dell SMBIOS tokens or
> keyboard class interface.
> 
> With this patch it is possible to set:
> * keyboard backlight level
> * timeout after which will be backlight automatically turned off
> * input activity triggers (keyboard, touchpad, mouse) which enable backlight
> * ambient light settings
> 
> Settings are exported via sysfs:
> /sys/class/leds/dell::kbd_backlight/
> 
> Code is based on newly released documentation by Dell in libsmbios project.
> 
> Thanks to Dan Carpenter who reported bug about unpredictable results in
> quirks->kbd_timeouts for loop. His fix adds needs_kbd_timeouts flag to
> quirk structure to indicate if kbd_timeouts array is empty or not.
> 
> Signed-off-by: Pali Rohár 
> Signed-off-by: Gabriele Mazzotta 
> Cc: Dan Carpenter 

Applied to testing with minor English corrections to the new comments.

Thank you Pali.

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

Re: [PATCH] PM / Kconfig: Replace PM_RUNTIME with PM in dependencies

[Greg Kroah-Hartman]

On Sat, Dec 06, 2014 at 03:54:35AM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
> selected) PM_RUNTIME is always set if PM is set, so Kconfig options
> depending on CONFIG_PM_RUNTIME may now be changed to depend on
> CONFIG_PM.
> 
> Replace PM_RUNTIME with PM in Kconfig dependencies throughout the
> tree.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
> PM_SLEEP is selected) which is only in linux-next at the moment (via the
> linux-pm tree).
> 
> Please let me know if it is OK to take this one into linux-pm.

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

Re: [PATCH] tty / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[Greg Kroah-Hartman]

On Sat, Dec 06, 2014 at 03:33:47AM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
> selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
> depending on CONFIG_PM_RUNTIME may now be changed to depend on
> CONFIG_PM.
> 
> Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
> drivers/tty/.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
> PM_SLEEP is selected) which is only in linux-next at the moment (via the
> linux-pm tree).
> 
> Please let me know if it is OK to take this one into linux-pm.

Acked-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: Cygnus: add GPIO driver

[Joe Perches]

On Fri, 2014-12-05 at 19:41 -0800, Ray Jui wrote:
> On 12/5/2014 6:34 PM, Joe Perches wrote:
> > On Fri, 2014-12-05 at 18:14 -0800, Ray Jui wrote:
> >> On 12/5/2014 5:28 PM, Joe Perches wrote:
> >>> On Fri, 2014-12-05 at 16:40 -0800, Ray Jui wrote:
>  +for_each_set_bit(bit, , 32) {
[]
> Actually, by reviewing the code more deeply, I'm not sure why using 
> for_each_set_bit here is 'endian unsafe'.

It's not.  The 32 confused me as it was long
and sizeof(long) isn't necessarily 32.

Maybe the 32 should be a #define



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Jike Song]

On 12/05/2014 04:50 PM, Gerd Hoffmann wrote:

A few comments on the kernel stuff (brief look so far, also
compile-tested only, intel gfx on my test machine is too old).

  * Noticed the kernel bits don't even compile when configured as
module.  Everything (vgt, i915, kvm) must be compiled into the
kernel.


Yes, that's planned to be done along with separating hypervisor-related
code from vgt.


  * Design approach still seems to be i915 on vgt not the other way
around.


So far yes.



Qemu/SeaBIOS bits:

I've seen the host bridge changes identity from i440fx to
copy-pci-ids-from-host.  Guess the reason for this is that seabios uses
this device to figure whenever it is running on i440fx or q35.  Correct?



I did some trick in seabios/qemu. The purpose is to make qemu:

- provide IDs of an old host bridge to SeaBIOS
- provide IDs of new host bridge(the physical ones) to guest OS

So I made seabios to tell qemu that POST is done before jumping to guest
OS context.

This may be the simplest method to make things work, but yes, q35 emulation
of qemu may have this unnecessary, see below.


What are the exact requirements for the device?  Must it match the host
exactly, to not confuse the guest intel graphics driver?  Or would
something more recent -- such as the q35 emulation qemu has -- be good
enough to make things work (assuming we add support for the
graphic-related pci config space registers there)?



I don't know that is exactly needed, we also need to have Windows
driver considered.  However, I'm quite confident that, if things gonna
work for IGD passthrough, it gonna work for GVT-g.


The patch also adds a dummy isa bridge at 0x1f.  Simliar question here:
What exactly is needed here?  Would things work if we simply use the q35
lpc device here?



Ditto.


more to come after I've read the paper linked above ...


Thanks for review :)



cheers,
   Gerd



--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] fix hw_random stuck

[Amos Kong]

When I hotunplug a busy virtio-rng device or try to access
hwrng attributes in non-smp guest, it gets stuck.

My hotplug tests:

| test 0:
|   hotunplug rng device from qemu monitor
|
| test 1:
|   guest) # dd if=/dev/hwrng of=/dev/null &
|   hotunplug rng device from qemu monitor
|
| test 2:
|   guest) # dd if=/dev/random of=/dev/null &
|   hotunplug rng device from qemu monitor
|
| test 4:
|   guest) # dd if=/dev/hwrng of=/dev/null &
|   cat /sys/devices/virtual/misc/hw_random/rng_*
|
| test 5:
|   guest) # dd if=/dev/hwrng of=/dev/null
|   cancel dd process after 10 seconds
|   guest) # dd if=/dev/hwrng of=/dev/null &
|   hotunplug rng device from qemu monitor
|
| test 6:
|   use a fifo as rng backend, execute test 0 ~ 5 with no input of fifo

V5: reset cleanup_done flag, drop redundant init of reference count, use
compiler barrier to prevent recording.
V4: update patch 4 to fix corrupt, decrease last reference for triggering
the cleanup, fix unregister race pointed by Herbert
V3: initialize kref to 1
V2: added patch 2 to fix a deadlock, update current patch 3 to fix reference
counting issue

Amos Kong (1):
  hw_random: move some code out mutex_lock for avoiding underlying
deadlock

Rusty Russell (5):
  hw_random: place mutex around read functions and buffers.
  hw_random: use reference counts on each struct hwrng.
  hw_random: fix unregister race.
  hw_random: don't double-check old_rng.
  hw_random: don't init list element we're about to add to list.

 drivers/char/hw_random/core.c | 173 ++
 include/linux/hw_random.h |   3 +
 2 files changed, 126 insertions(+), 50 deletions(-)

-- 
1.9.3

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

[PATCH v5 3/6] hw_random: use reference counts on each struct hwrng.

[Amos Kong]

From: Rusty Russell 

current_rng holds one reference, and we bump it every time we want
to do a read from it.

This means we only hold the rng_mutex to grab or drop a reference,
so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't
block on read of /dev/hwrng.

Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.

This also solves the problem that the hwrng_fillfn thread was
accessing current_rng without a lock, which could change (eg. to NULL)
underneath it.

v5: drop redundant kref_init()
v4: decrease last reference for triggering the cleanup
v3: initialize kref (thanks Amos Kong)
v2: fix missing put_rng() on exit path (thanks Amos Kong)
Signed-off-by: Rusty Russell 
Signed-off-by: Amos Kong 
---
 drivers/char/hw_random/core.c | 135 --
 include/linux/hw_random.h |   2 +
 2 files changed, 94 insertions(+), 43 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index a0905c8..83516cb 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -91,6 +92,60 @@ static void add_early_randomness(struct hwrng *rng)
add_device_randomness(bytes, bytes_read);
 }
 
+static inline void cleanup_rng(struct kref *kref)
+{
+   struct hwrng *rng = container_of(kref, struct hwrng, ref);
+
+   if (rng->cleanup)
+   rng->cleanup(rng);
+}
+
+static void set_current_rng(struct hwrng *rng)
+{
+   BUG_ON(!mutex_is_locked(_mutex));
+   kref_get(>ref);
+   current_rng = rng;
+}
+
+static void drop_current_rng(void)
+{
+   BUG_ON(!mutex_is_locked(_mutex));
+   if (!current_rng)
+   return;
+
+   /* decrease last reference for triggering the cleanup */
+   kref_put(_rng->ref, cleanup_rng);
+   current_rng = NULL;
+}
+
+/* Returns ERR_PTR(), NULL or refcounted hwrng */
+static struct hwrng *get_current_rng(void)
+{
+   struct hwrng *rng;
+
+   if (mutex_lock_interruptible(_mutex))
+   return ERR_PTR(-ERESTARTSYS);
+
+   rng = current_rng;
+   if (rng)
+   kref_get(>ref);
+
+   mutex_unlock(_mutex);
+   return rng;
+}
+
+static void put_rng(struct hwrng *rng)
+{
+   /*
+* Hold rng_mutex here so we serialize in case they set_current_rng
+* on rng again immediately.
+*/
+   mutex_lock(_mutex);
+   if (rng)
+   kref_put(>ref, cleanup_rng);
+   mutex_unlock(_mutex);
+}
+
 static inline int hwrng_init(struct hwrng *rng)
 {
if (rng->init) {
@@ -113,12 +168,6 @@ static inline int hwrng_init(struct hwrng *rng)
return 0;
 }
 
-static inline void hwrng_cleanup(struct hwrng *rng)
-{
-   if (rng && rng->cleanup)
-   rng->cleanup(rng);
-}
-
 static int rng_dev_open(struct inode *inode, struct file *filp)
 {
/* enforce read-only access to this chrdev */
@@ -154,21 +203,22 @@ static ssize_t rng_dev_read(struct file *filp, char 
__user *buf,
ssize_t ret = 0;
int err = 0;
int bytes_read, len;
+   struct hwrng *rng;
 
while (size) {
-   if (mutex_lock_interruptible(_mutex)) {
-   err = -ERESTARTSYS;
+   rng = get_current_rng();
+   if (IS_ERR(rng)) {
+   err = PTR_ERR(rng);
goto out;
}
-
-   if (!current_rng) {
+   if (!rng) {
err = -ENODEV;
-   goto out_unlock;
+   goto out;
}
 
mutex_lock(_mutex);
if (!data_avail) {
-   bytes_read = rng_get_data(current_rng, rng_buffer,
+   bytes_read = rng_get_data(rng, rng_buffer,
rng_buffer_size(),
!(filp->f_flags & O_NONBLOCK));
if (bytes_read < 0) {
@@ -200,8 +250,8 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
ret += len;
}
 
-   mutex_unlock(_mutex);
mutex_unlock(_mutex);
+   put_rng(rng);
 
if (need_resched())
schedule_timeout_interruptible(1);
@@ -213,12 +263,11 @@ static ssize_t rng_dev_read(struct file *filp, char 
__user *buf,
}
 out:
return ret ? : err;
-out_unlock:
-   mutex_unlock(_mutex);
-   goto out;
+
 out_unlock_reading:
mutex_unlock(_mutex);
-   goto out_unlock;
+   put_rng(rng);
+   goto out;
 }
 
 
@@ -257,8 +306,8 @@ static ssize_t hwrng_attr_current_store(struct device *dev,
err = hwrng_init(rng);
if (err)
break;
-   hwrng_cleanup(current_rng);
-  

[PATCH v5 6/6] hw_random: don't init list element we're about to add to list.

[Amos Kong]

From: Rusty Russell 

Another interesting anti-pattern.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index a9286bf..4d13ac5 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -489,7 +489,6 @@ int hwrng_register(struct hwrng *rng)
goto out_unlock;
}
}
-   INIT_LIST_HEAD(>list);
list_add_tail(>list, _list);
 
if (old_rng && !rng->init) {
-- 
1.9.3

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

[PATCH v5 5/6] hw_random: don't double-check old_rng.

[Amos Kong]

From: Rusty Russell 

Interesting anti-pattern.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 067270b..a9286bf 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -476,14 +476,13 @@ int hwrng_register(struct hwrng *rng)
}
 
old_rng = current_rng;
+   err = 0;
if (!old_rng) {
err = hwrng_init(rng);
if (err)
goto out_unlock;
set_current_rng(rng);
-   }
-   err = 0;
-   if (!old_rng) {
+
err = register_miscdev();
if (err) {
drop_current_rng();
-- 
1.9.3

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

[PATCH v5 2/6] hw_random: move some code out mutex_lock for avoiding underlying deadlock

[Amos Kong]

In next patch, we use reference counting for each struct hwrng,
changing reference count also needs to take mutex_lock. Before
releasing the lock, if we try to stop a kthread that waits to
take the lock to reduce the referencing count, deadlock will
occur.

Signed-off-by: Amos Kong 
---
 drivers/char/hw_random/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index b1b6042..a0905c8 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -474,12 +474,12 @@ void hwrng_unregister(struct hwrng *rng)
}
}
if (list_empty(_list)) {
+   mutex_unlock(_mutex);
unregister_miscdev();
if (hwrng_fill)
kthread_stop(hwrng_fill);
-   }
-
-   mutex_unlock(_mutex);
+   } else
+   mutex_unlock(_mutex);
 }
 EXPORT_SYMBOL_GPL(hwrng_unregister);
 
-- 
1.9.3

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

[PATCH v5 1/6] hw_random: place mutex around read functions and buffers.

[Amos Kong]

From: Rusty Russell 

There's currently a big lock around everything, and it means that we
can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
while the rng is reading.  This is a real problem when the rng is slow,
or blocked (eg. virtio_rng with qemu's default /dev/random backend)

This doesn't help (it leaves the current lock untouched), just adds a
lock to protect the read function and the static buffers, in preparation
for transition.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aa30a25..b1b6042 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -53,7 +53,10 @@
 static struct hwrng *current_rng;
 static struct task_struct *hwrng_fill;
 static LIST_HEAD(rng_list);
+/* Protects rng_list and current_rng */
 static DEFINE_MUTEX(rng_mutex);
+/* Protects rng read functions, data_avail, rng_buffer and rng_fillbuf */
+static DEFINE_MUTEX(reading_mutex);
 static int data_avail;
 static u8 *rng_buffer, *rng_fillbuf;
 static unsigned short current_quality;
@@ -81,7 +84,9 @@ static void add_early_randomness(struct hwrng *rng)
unsigned char bytes[16];
int bytes_read;
 
+   mutex_lock(_mutex);
bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
+   mutex_unlock(_mutex);
if (bytes_read > 0)
add_device_randomness(bytes, bytes_read);
 }
@@ -128,6 +133,7 @@ static inline int rng_get_data(struct hwrng *rng, u8 
*buffer, size_t size,
int wait) {
int present;
 
+   BUG_ON(!mutex_is_locked(_mutex));
if (rng->read)
return rng->read(rng, (void *)buffer, size, wait);
 
@@ -160,13 +166,14 @@ static ssize_t rng_dev_read(struct file *filp, char 
__user *buf,
goto out_unlock;
}
 
+   mutex_lock(_mutex);
if (!data_avail) {
bytes_read = rng_get_data(current_rng, rng_buffer,
rng_buffer_size(),
!(filp->f_flags & O_NONBLOCK));
if (bytes_read < 0) {
err = bytes_read;
-   goto out_unlock;
+   goto out_unlock_reading;
}
data_avail = bytes_read;
}
@@ -174,7 +181,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
if (!data_avail) {
if (filp->f_flags & O_NONBLOCK) {
err = -EAGAIN;
-   goto out_unlock;
+   goto out_unlock_reading;
}
} else {
len = data_avail;
@@ -186,7 +193,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
if (copy_to_user(buf + ret, rng_buffer + data_avail,
len)) {
err = -EFAULT;
-   goto out_unlock;
+   goto out_unlock_reading;
}
 
size -= len;
@@ -194,6 +201,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
}
 
mutex_unlock(_mutex);
+   mutex_unlock(_mutex);
 
if (need_resched())
schedule_timeout_interruptible(1);
@@ -208,6 +216,9 @@ out:
 out_unlock:
mutex_unlock(_mutex);
goto out;
+out_unlock_reading:
+   mutex_unlock(_mutex);
+   goto out_unlock;
 }
 
 
@@ -348,13 +359,16 @@ static int hwrng_fillfn(void *unused)
while (!kthread_should_stop()) {
if (!current_rng)
break;
+   mutex_lock(_mutex);
rc = rng_get_data(current_rng, rng_fillbuf,
  rng_buffer_size(), 1);
+   mutex_unlock(_mutex);
if (rc <= 0) {
pr_warn("hwrng: no data available\n");
msleep_interruptible(1);
continue;
}
+   /* Outside lock, sure, but y'know: randomness. */
add_hwgenerator_randomness((void *)rng_fillbuf, rc,
   rc * current_quality * 8 >> 10);
}
-- 
1.9.3

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

[PATCH v5 4/6] hw_random: fix unregister race.

[Amos Kong]

From: Rusty Russell 

The previous patch added one potential problem: we can still be
reading from a hwrng when it's unregistered.  Add a wait for zero
in the hwrng_unregister path.

v5: reset cleanup_done flag, use compiler barrier to prevent recording.
v4: add cleanup_done flag to insure that cleanup is done

Signed-off-by: Rusty Russell 
Signed-off-by: Amos Kong 
---
 drivers/char/hw_random/core.c | 12 
 include/linux/hw_random.h |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 83516cb..067270b 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -60,6 +60,7 @@ static DEFINE_MUTEX(rng_mutex);
 static DEFINE_MUTEX(reading_mutex);
 static int data_avail;
 static u8 *rng_buffer, *rng_fillbuf;
+static DECLARE_WAIT_QUEUE_HEAD(rng_done);
 static unsigned short current_quality;
 static unsigned short default_quality; /* = 0; default to "off" */
 
@@ -98,6 +99,11 @@ static inline void cleanup_rng(struct kref *kref)
 
if (rng->cleanup)
rng->cleanup(rng);
+
+   /* cleanup_done should be updated after cleanup finishes */
+   smp_wmb();
+   rng->cleanup_done = true;
+   wake_up_all(_done);
 }
 
 static void set_current_rng(struct hwrng *rng)
@@ -498,6 +504,8 @@ int hwrng_register(struct hwrng *rng)
add_early_randomness(rng);
}
 
+   rng->cleanup_done = false;
+
 out_unlock:
mutex_unlock(_mutex);
 out:
@@ -529,6 +537,10 @@ void hwrng_unregister(struct hwrng *rng)
kthread_stop(hwrng_fill);
} else
mutex_unlock(_mutex);
+
+   /* Just in case rng is reading right now, wait. */
+   wait_event(rng_done, rng->cleanup_done &&
+  atomic_read(>ref.refcount) == 0);
 }
 EXPORT_SYMBOL_GPL(hwrng_unregister);
 
diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
index c212e71..7832e50 100644
--- a/include/linux/hw_random.h
+++ b/include/linux/hw_random.h
@@ -46,6 +46,7 @@ struct hwrng {
/* internal. */
struct list_head list;
struct kref ref;
+   bool cleanup_done;
 };
 
 /** Register a new Hardware Random Number Generator driver. */
-- 
1.9.3

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

Re: syscall: introduce sendfd() syscall (v.2)

[Alex Dubov]

On Sat, Dec 6, 2014 at 12:22 AM, One Thousand Gnomes
 wrote:
>
>> 2.a. If task A has sufficient capabilities to send signals to task B, then
>> task A is already in position to do anything it wants with task B, including
>> killing it outright.
>
> Not entirely true.
>
> - We have securirty models like SELinux
> - We have namespaces and being able to send an fd between namespaces is
>   not quite as flexible as you would make it
>
> I suspect therefore it needs security hooks but otherwise looks more sane
> than the current AF_UNIX approach.
>

The best part about signal transport compared to anything in net/ is
that it adheres to very straightforward and simple API contract. That
is, you can tweak it here and there and still keep everything working.

1. adding an additional capability flag to selinux does not appear to
be that complicated (it's got 4 capabilities related to signal
handling already, fifth is not going to make much difference)

2. sending fds between namespaces may be prohibited outright; this
would not be an unreasonable prohibition. A more flexible model may
also be feasible, but I wonder if necessary.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 0/2] i2c-designware: Baytrail bus locking driver

[Shinya Kuribayashi]

On 14/12/02 9:09, David E. Box wrote:

Select Intel Baytrail platforms support PMIC's whose i2c bus may be controlled
exclusively by platform hardware. This patch set adds support for i2c bus
locking to the designware core and provides a driver module for managing
the lock on these platforms. Since the lock on these systems isn't enumerable
outside of the i2c platform driver, the locking functions are assigned at
compile time.


Have you ever look into the hwspinlock framework?  It seems to me that
such an exclusive operation between CPUs and external hardware blocks
is exactly what hwspinlock is for.  Further more hwspinlock takes care
of exclusiveness between SMP cores.

Ideally I would expect i2c-designware to have hwspinlock lock/unlock
API calls on one I2C transaction, but it's not necessarily the case.
Introducing such platform hooks (acquire_lock and release_lock) and
keeping actual exclusive operataion outside the driver might be good
for various usecases/platforms.

  Shinya

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] syscall: introduce sendfd() syscall (v.2)

[Alex Dubov]

On Sat, Dec 6, 2014 at 6:23 AM, Bastien ROUCARIES
 wrote:
>
>
> See senfd recvfd in gnulib. It wirk even under solaris
>

What's so special about a thin wrapper around domain sockets/named
fifos (solaris style)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/6] hw_random: fix unregister race.

[Amos Kong]

On Wed, Nov 12, 2014 at 02:33:00PM +1030, Rusty Russell wrote:
> Amos Kong  writes:
> > From: Rusty Russell 
> >
> > The previous patch added one potential problem: we can still be
> > reading from a hwrng when it's unregistered.  Add a wait for zero
> > in the hwrng_unregister path.
> >
> > v4: add cleanup_done flag to insure that cleanup is done
> 
> That's a bit weird.  The usual pattern would be to hold a reference
> until we're actually finished, but this reference is a bit weird.
> 
> We hold the mutex across cleanup, so we could grab that but we have to
> take care sleeping inside wait_event, otherwise Peter will have to fix
> my code again :)
> 
> AFAICT the wake_woken() stuff isn't merged yet, so your patch will
> have to do for now.
> 
> > @@ -98,6 +99,8 @@ static inline void cleanup_rng(struct kref *kref)
> >  
> > if (rng->cleanup)
> > rng->cleanup(rng);
> > +   rng->cleanup_done = true;
> > +   wake_up_all(_done);
> >  }
> >  
> >  static void set_current_rng(struct hwrng *rng)
> > @@ -536,6 +539,11 @@ void hwrng_unregister(struct hwrng *rng)
> > kthread_stop(hwrng_fill);
> > } else
> > mutex_unlock(_mutex);
> > +
> > +   /* Just in case rng is reading right now, wait. */
> > +   wait_event(rng_done, rng->cleanup_done &&
> > +  atomic_read(>ref.refcount) == 0);
> > +
> 
> The atomic_read() isn't necessary here.

At least, we need it to convert refcount from atomic_t to int.
Otherwise, we will touch this error:

  error: invalid operands to binary == (have 'atomic_t' and 'int')
 
> However, you should probably init cleanup_done in hwrng_register().
> (Probably noone does unregister then register, but let's be clear).
> 
> Thanks,
> Rusty.

-- 
Amos.


signature.asc
Description: Digital signature

Re: [PATCH 3.17 000/122] 3.17.5-stable review

[Greg Kroah-Hartman]

On Fri, Dec 05, 2014 at 07:30:48PM -0800, Guenter Roeck wrote:
> On 12/05/2014 02:42 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.17.5 release.
> >There are 122 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Sun Dec  7 22:32:17 UTC 2014.
> >Anything received after that time might be too late.
> >
> 
> Build results:
>   total: 133 pass: 132 fail: 1
> Failed builds:
>   avr32:atngw100mkii_evklcd101_defconfig

Bah, it looks like no one cares about avr32 anymore :(

Anyway, thanks for testing all of these and letting me know.

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

Re: [PATCH 2/5] gpio: Cygnus: add GPIO driver

[Ray Jui]

On 12/5/2014 6:34 PM, Joe Perches wrote:

On Fri, 2014-12-05 at 18:14 -0800, Ray Jui wrote:

On 12/5/2014 5:28 PM, Joe Perches wrote:

On Fri, 2014-12-05 at 16:40 -0800, Ray Jui wrote:

+static void bcm_cygnus_gpio_irq_handler(unsigned int irq,
+   struct irq_desc *desc)
+{
+   struct bcm_cygnus_gpio *cygnus_gpio;
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   int i, bit;
+
+   chained_irq_enter(chip, desc);
+
+   cygnus_gpio = irq_get_handler_data(irq);
+
+   /* go through the entire GPIO banks and handle all interrupts */
+   for (i = 0; i < cygnus_gpio->num_banks; i++) {
+   unsigned long val = readl(cygnus_gpio->base +
+   (i * GPIO_BANK_SIZE) +
+   CYGNUS_GPIO_INT_MSTAT_OFFSET);
+   if (val) {


This if (val) and indentation isn't really necessary



Note for_each_set_bit in this case iterates 32 times searching for bits
that are set.


No it doesn't.

#define for_each_set_bit(bit, addr, size) \
for ((bit) = find_first_bit((addr), (size));\
 (bit) < (size); \
 (bit) = find_next_bit((addr), (size), (bit) + 1))

find_first_bit:

  * Returns the bit number of the first set bit.
  * If no bits are set, returns @size.



You are right. I reviewed for_each_set_bit but didn't notice 
find_next_bit may simply return 32 in our case without doing any 
iterative processing. I will get rid of the redundant if (val) check below.



  By having the if (val) check here, it can potentially save
some of such processing in the ISR. I agree with you that it introduces
one extra indent here but I think it's required.


+   for_each_set_bit(bit, , 32) {


for_each_set_bit will effectively do the if above.

32 bit only code?
otherwise isn't this endian unsafe?



Will change 'unsigned long val' to 'u32 val'.


All the bit operations only work on long *




Actually, by reviewing the code more deeply, I'm not sure why using 
for_each_set_bit here is 'endian unsafe'. Isn't that already taken care 
of by macros in bitops.h? Sorry if I'm still missing something here...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.17 000/122] 3.17.5-stable review

[Guenter Roeck]

On 12/05/2014 02:42 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.17.5 release.
There are 122 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Dec  7 22:32:17 UTC 2014.
Anything received after that time might be too late.



Build results:
total: 133 pass: 132 fail: 1
Failed builds:
avr32:atngw100mkii_evklcd101_defconfig

Qemu tests:
total: 30 pass: 30 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

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 3.14 00/73] 3.14.26-stable review

[Guenter Roeck]

On 12/05/2014 02:44 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.14.26 release.
There are 73 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Dec  7 22:44:19 UTC 2014.
Anything received after that time might be too late.



Build results:
total: 137 pass: 137 fail: 0
Qemu tests:
total: 30 pass: 30 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

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 3.10 00/45] 3.10.62-stable review

[Guenter Roeck]

On 12/05/2014 02:44 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.10.62 release.
There are 45 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Dec  7 22:32:54 UTC 2014.
Anything received after that time might be too late.



Build results:
total: 137 pass: 137 fail: 0
Qemu tests:
total: 27 pass: 27 fail: 0

Details are available at http://server.roeck-us.net:8010/builders..

Guenter

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

[PATCH v2] VERIFY_OCTAL_PERMISSIONS: Move to where it belongs

[George Spelvin]

It's the only user of  in kernel.h, so that reduces
the compile-time cost of #include 

Only one user has to change: .  The 
there is needed for one function prototype that passes s16 parameters.
My first reaction is to wonder if that can be gotten rid of, too.

Some other extraneous header files pruned while I was at it.
Tested with allyesconfig & allmodconfig on x86-64, just to
be sure.

Suggested-by: Andrew Morton 
Signed-off-by: George Spelvin 
---
Look, even more header pruning.

 include/linux/kernel.h  | 10 --
 include/linux/moduleparam.h |  4 ++--
 include/linux/sysfs.h   | 15 ---
 3 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3d770f55..07080aa2 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -804,14 +804,4 @@ static inline void ftrace_dump(enum ftrace_dump_mode 
oops_dump_mode) { }
 # define REBUILD_DUE_TO_FTRACE_MCOUNT_RECORD
 #endif
 
-/* Permissions on a sysfs file: you didn't miss the 0 prefix did you? */
-#define VERIFY_OCTAL_PERMISSIONS(perms)
\
-   (BUILD_BUG_ON_ZERO((perms) < 0) +   \
-BUILD_BUG_ON_ZERO((perms) > 0777) +\
-/* User perms >= group perms >= other perms */ \
-BUILD_BUG_ON_ZERO(((perms) >> 6) < (((perms) >> 3) & 7)) + \
-BUILD_BUG_ON_ZEROperms) >> 3) & 7) < ((perms) & 7)) +  \
-/* Other writable?  Generally considered a bad idea. */\
-BUILD_BUG_ON_ZERO((perms) & 2) +   \
-(perms))
 #endif
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 1c9effa2..974097df 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -1,9 +1,9 @@
 #ifndef _LINUX_MODULE_PARAMS_H
 #define _LINUX_MODULE_PARAMS_H
 /* (C) Copyright 2001, 2002 Rusty Russell IBM Corporation */
-#include 
 #include 
-#include 
+#include 
+#include 
 
 /* You can override this manually, but generally this should match the
module name. */
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index f97d0dbb..3562f331 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -14,12 +14,10 @@
 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
+#include 
 
 struct kobject;
 struct module;
@@ -70,6 +68,17 @@ struct attribute_group {
  * for examples..
  */
 
+/* Permissions on a sysfs file: you didn't miss the 0 prefix did you? */
+#define VERIFY_OCTAL_PERMISSIONS(perms)
\
+   (BUILD_BUG_ON_ZERO((perms) < 0) +   \
+BUILD_BUG_ON_ZERO((perms) > 0777) +\
+/* User perms >= group perms >= other perms */ \
+BUILD_BUG_ON_ZERO(((perms) >> 6) < (((perms) >> 3) & 7)) + \
+BUILD_BUG_ON_ZEROperms) >> 3) & 7) < ((perms) & 7)) +  \
+/* Other writable?  Generally considered a bad idea. */\
+BUILD_BUG_ON_ZERO((perms) & 2) +   \
+(perms))
+
 #define __ATTR(_name, _mode, _show, _store) {  \
.attr = {.name = __stringify(_name),\
 .mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \
-- 
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: [Launchpad #1396889] [Lenovo ThinkPad T400] kexec reboot fails

[MegaBrutal]

2014-12-01 23:59 GMT+01:00 Kees Cook :
>
> I suspect you're encountering a subset of the same problems as
> described in this thread:
> https://lkml.org/lkml/2014/9/30/90
>
> If you can test those patches, that may help demonstrate their utility.
>
> Thanks!

Bang ji le! It works with the patch you linked, xiexie!
I suggest it to be merged into mainline.

Anyway, is there a way to get sure that KASLR actually works now?
(I.e. how do I know if the kernel is really loaded to a random
address?)
Do you have any idea what might be different with my ThinkPad T400
that it is the only one of my machines affected?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM / Kconfig: Replace PM_RUNTIME with PM in dependencies

[Felipe Balbi]

On Sat, Dec 06, 2014 at 03:54:35AM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
> selected) PM_RUNTIME is always set if PM is set, so Kconfig options
> depending on CONFIG_PM_RUNTIME may now be changed to depend on
> CONFIG_PM.
> 
> Replace PM_RUNTIME with PM in Kconfig dependencies throughout the
> tree.
> 
> Signed-off-by: Rafael J. Wysocki 

for drivers/usb/phy:

Acked-by: Felipe Balbi 

> ---
> 
> Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
> PM_SLEEP is selected) which is only in linux-next at the moment (via the
> linux-pm tree).
> 
> Please let me know if it is OK to take this one into linux-pm.
> 
> ---
>  arch/arm/mach-exynos/Kconfig  |2 +-
>  arch/ia64/Kconfig |2 +-
>  drivers/ata/Kconfig   |2 +-
>  drivers/media/platform/Kconfig|2 +-
>  drivers/media/platform/s5p-tv/Kconfig |2 +-
>  drivers/staging/gdm72xx/Kconfig   |2 +-
>  drivers/usb/core/Kconfig  |2 +-
>  drivers/usb/phy/Kconfig   |4 ++--
>  drivers/usb/storage/Kconfig   |2 +-
>  9 files changed, 10 insertions(+), 10 deletions(-)
> 
> Index: linux-pm/arch/arm/mach-exynos/Kconfig
> ===
> --- linux-pm.orig/arch/arm/mach-exynos/Kconfig
> +++ linux-pm/arch/arm/mach-exynos/Kconfig
> @@ -21,7 +21,7 @@ menuconfig ARCH_EXYNOS
>   select HAVE_S3C_RTC if RTC_CLASS
>   select PINCTRL
>   select PINCTRL_EXYNOS
> - select PM_GENERIC_DOMAINS if PM_RUNTIME
> + select PM_GENERIC_DOMAINS if PM
>   select S5P_DEV_MFC
>   select SRAM
>   help
> Index: linux-pm/arch/ia64/Kconfig
> ===
> --- linux-pm.orig/arch/ia64/Kconfig
> +++ linux-pm/arch/ia64/Kconfig
> @@ -232,7 +232,7 @@ config IA64_SGI_UV
>  config IA64_HP_SIM
>   bool "Ski-simulator"
>   select SWIOTLB
> - depends on !PM_RUNTIME
> + depends on !PM
>  
>  endchoice
>  
> Index: linux-pm/drivers/ata/Kconfig
> ===
> --- linux-pm.orig/drivers/ata/Kconfig
> +++ linux-pm/drivers/ata/Kconfig
> @@ -61,7 +61,7 @@ config ATA_ACPI
>  
>  config SATA_ZPODD
>   bool "SATA Zero Power Optical Disc Drive (ZPODD) support"
> - depends on ATA_ACPI && PM_RUNTIME
> + depends on ATA_ACPI && PM
>   default n
>   help
> This option adds support for SATA Zero Power Optical Disc
> Index: linux-pm/drivers/media/platform/Kconfig
> ===
> --- linux-pm.orig/drivers/media/platform/Kconfig
> +++ linux-pm/drivers/media/platform/Kconfig
> @@ -112,7 +112,7 @@ config VIDEO_OMAP3_DEBUG
>  config VIDEO_S3C_CAMIF
>   tristate "Samsung S3C24XX/S3C64XX SoC Camera Interface driver"
>   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
> - depends on PM_RUNTIME
> + depends on PM
>   depends on ARCH_S3C64XX || PLAT_S3C24XX || COMPILE_TEST
>   depends on HAS_DMA
>   select VIDEOBUF2_DMA_CONTIG
> Index: linux-pm/drivers/media/platform/s5p-tv/Kconfig
> ===
> --- linux-pm.orig/drivers/media/platform/s5p-tv/Kconfig
> +++ linux-pm/drivers/media/platform/s5p-tv/Kconfig
> @@ -8,7 +8,7 @@
>  
>  config VIDEO_SAMSUNG_S5P_TV
>   bool "Samsung TV driver for S5P platform"
> - depends on PM_RUNTIME
> + depends on PM
>   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
>   default n
>   ---help---
> Index: linux-pm/drivers/staging/gdm72xx/Kconfig
> ===
> --- linux-pm.orig/drivers/staging/gdm72xx/Kconfig
> +++ linux-pm/drivers/staging/gdm72xx/Kconfig
> @@ -53,7 +53,7 @@ if WIMAX_GDM72XX_USB
>  
>  config WIMAX_GDM72XX_USB_PM
>   bool "Enable power management support"
> - depends on PM_RUNTIME
> + depends on PM
>   help
> Enable USB power management in order to reduce power consumption
> while the interface is not in use.
> Index: linux-pm/drivers/usb/core/Kconfig
> ===
> --- linux-pm.orig/drivers/usb/core/Kconfig
> +++ linux-pm/drivers/usb/core/Kconfig
> @@ -43,7 +43,7 @@ config USB_DYNAMIC_MINORS
>  
>  config USB_OTG
>   bool "OTG support"
> - depends on PM_RUNTIME
> + depends on PM
>   default n
>   help
> The most notable feature of USB OTG is support for a
> Index: linux-pm/drivers/usb/phy/Kconfig
> ===
> --- linux-pm.orig/drivers/usb/phy/Kconfig
> +++ linux-pm/drivers/usb/phy/Kconfig
> @@ -20,7 +20,7 @@ config AB8500_USB
>  
>  config FSL_USB2_OTG
>   bool "Freescale USB OTG Transceiver Driver"
> - depends on 

Re: Block layer projects that I haven't had time for

[Kent Overstreet]

On Thu, Dec 04, 2014 at 12:00:27PM +0100, Dongsu Park wrote:
> Hi Kent,
> 
> On 23.11.2014 20:16, Kent Overstreet wrote:
> > Since I'm starting to resign myself to the fact that I'm probably not going 
> > to
> > have much time for upstream development again any time soon, I figured 
> > maybe I
> > should try writing down all the things I was working on or planning on 
> > working
> > on in case someone else is feeling ambitious and looking for things to work 
> > on.
> > 
> > If anyone wants to take up any of this stuff, feel free to take my half 
> > baked
> > code and do whatever you want with it, or ping me for ideas/guidance.
> 
> I'm interested in taking up your work and further implement it.
> IMHO the 1st and 2nd items, making generic_make_request() take arbitrarily
> sized bios, are the essential ones. With those changes, individual block
> drivers wouldn't have to define ->merge_bvec_fn() any more.

Cool! Yeah, things get a lot simpler for a lot of code.

> Playing a little with your block_stuff tree based on 3.15, however,
> I think there still seems to be a couple of issues.
> First of all, it doesn't work with virtio-blk. A testing Qemu VM panics
> at the very early stage of booting. This issue should be addressed as
> the first step, so that other parts can be tested.

Really? I was testing with virtio-blk, that's odd..

> Moreover, I've already tried to rebase these patches on top of current
> mainline, 3.18-rc7. It's now compilable, but it seems to introduce
> more bugs about direct-IO. I didn't manage to find out the reason.
> I'd need to also look at the previous review comments in [1], [2].
> 
> Don't you have other trees based on top of 3.17 or higher?
> If not, can I create my own tree based on 3.18-rc7 to publish?

Yeah, I'd post what you have now and I'll try and take a look.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH] VERIFY_OCTAL_PERMISSIONS: Move to where it belongs

[Jeff Kirsher]

On Fri, 2014-12-05 at 18:53 -0800, Joe Perches wrote:
> On Fri, 2014-12-05 at 21:49 -0500, George Spelvin wrote:
> > I found some other alarming things, but nothing related to this.
> > 
> > E.g.
> > drivers/net/ethernet/intel/i40e/i40e_debugfs.c: In function 
> > 'i40e_dbg_dump_desc':
> > drivers/net/ethernet/intel/i40e/i40e_debugfs.c:855:1: warning: the frame 
> > size of 8192 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> 
> Patched.
> Waiting for Jeff Kirsher to get 'round to applying it.
> 
> http://patchwork.ozlabs.org/patch/411356/
> 
> 

I have it queued up for the next series of i40e/i40evf patches I will be
pushing.  Just waiting on the acceptance of my latest series I pushed
this morning, then I will be pushing this and other i40e patches.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] [PATCH] VERIFY_OCTAL_PERMISSIONS: Move to where it belongs

[Andrew Morton]

On 5 Dec 2014 21:49:52 -0500 "George Spelvin"  wrote:

> >> -
> 
> > This shouldn't be here because "^---" is considered "end of changelog".
> 
> Damn it, I couldn't remember how to add not-for-commit comments to a patch.
> I RTFMed and thought that was what "git mailinfo --scissors" wanted.
> 
> (Normally, I put it down with the diffstat, but preferred a more
> prominent place for this conversation.)

I think in 100% of cases I find the stuff that people put below the
^--- was useful info, so I move it into the changelog.  Yours was no
exception ;) 

> > Let's include bug.h into sysfs.h.
> 
> It worked without, but yeah... since I can't figure *how* it works.

heh.  `KCPPFLAGS=-H make foo.o' will show the include graph.  I usually
do `make foo.i' then go poke around in foo.i to work out how foo.c
received a particular definition.

> >> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> >> index 1c9effa2..974097df 100644
> >> --- a/include/linux/moduleparam.h
> >> +++ b/include/linux/moduleparam.h
> >> @@ -1,9 +1,9 @@
> >>  #ifndef _LINUX_MODULE_PARAMS_H
> >>  #define _LINUX_MODULE_PARAMS_H
> >>  /* (C) Copyright 2001, 2002 Rusty Russell IBM Corporation */
> >> -#include 
> >>  #include 
> >> -#include 
> >> +#include 
> >> +#include 
> 
> > Removing the kernel.h inclusion is good, but risky.  Are you sure
> > there's nothing in moduleparam.h which uses kernel.h things?
> 
> Well, I did a quick eyeball-scan, then did my usual build, then
> an allyesconfig and an allmodconfig.
> 
> I found some other alarming things, but nothing related to this.
> 
> E.g.
> drivers/net/ethernet/intel/i40e/i40e_debugfs.c: In function 
> 'i40e_dbg_dump_desc':
> drivers/net/ethernet/intel/i40e/i40e_debugfs.c:855:1: warning: the frame size 
> of 8192 bytes is larger than 2048 bytes [-Wframe-larger-than=]
>  }
> 
> (Honestly, I didn't wait for the allmodconfig to finish, since I
> expected it to fail within the first few hundred modules if it was going to
> fail at all, but it has finished now.)

OK, let's run with it and see what happens.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Interested in bcache

[Kent Overstreet]

What did you have in mind?

On Fri, Dec 5, 2014 at 6:55 PM, nick  wrote:
> Greetings fellow Maintainers,
> I am wondering about how to get started with bcache. This is due to be 
> reading the documentation in the kernel tree and being interested in started 
> to help out.
> Cheers Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] OHCI: add a quirk for ULi M5237 blocking on reset

[Arseny Solokha]

From: Arseny Solokha 

Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
board. The code path that was previously specific to NVIDIA controllers
had then become taken for all chips.

However, the M5237 installed on the board wedges solid when accessing
its base+OHCI_FMINTERVAL register, making it impossible to boot any
kernel newer than 3.1.8 on this particular and apparently other similar
machines.

Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237.

The patch is suitable for the -next tree as well as all maintained
kernels up to 3.2 inclusive.

Signed-off-by: Arseny Solokha 
---
Changes in v2:
- review comments applied
---
 drivers/usb/host/pci-quirks.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 2f3aceb..f4e6b94 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -571,7 +571,8 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
 {
void __iomem *base;
u32 control;
-   u32 fminterval;
+   u32 fminterval = 0;
+   bool no_fminterval = false;
int cnt;
 
if (!mmio_resource_enabled(pdev, 0))
@@ -581,6 +582,13 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
if (base == NULL)
return;
 
+   /*
+* ULi M5237 OHCI controller locks the whole system when accessing
+* the OHCI_FMINTERVAL offset.
+*/
+   if (pdev->vendor == PCI_VENDOR_ID_AL && pdev->device == 0x5237)
+   no_fminterval = true;
+
control = readl(base + OHCI_CONTROL);
 
 /* On PA-RISC, PDC can leave IR set incorrectly; ignore it there. */
@@ -619,7 +627,9 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
}
 
/* software reset of the controller, preserving HcFmInterval */
-   fminterval = readl(base + OHCI_FMINTERVAL);
+   if (!no_fminterval)
+   fminterval = readl(base + OHCI_FMINTERVAL);
+
writel(OHCI_HCR, base + OHCI_CMDSTATUS);
 
/* reset requires max 10 us delay */
@@ -628,7 +638,9 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
break;
udelay(1);
}
-   writel(fminterval, base + OHCI_FMINTERVAL);
+
+   if (!no_fminterval)
+   writel(fminterval, base + OHCI_FMINTERVAL);
 
/* Now the controller is safely in SUSPEND and nothing can wake it up */
iounmap(base);
-- 
2.2.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] [PATCH] VERIFY_OCTAL_PERMISSIONS: Move to where it belongs

[Joe Perches]

On Fri, 2014-12-05 at 21:49 -0500, George Spelvin wrote:
> I found some other alarming things, but nothing related to this.
> 
> E.g.
> drivers/net/ethernet/intel/i40e/i40e_debugfs.c: In function 
> 'i40e_dbg_dump_desc':
> drivers/net/ethernet/intel/i40e/i40e_debugfs.c:855:1: warning: the frame size 
> of 8192 bytes is larger than 2048 bytes [-Wframe-larger-than=]

Patched.
Waiting for Jeff Kirsher to get 'round to applying it.

http://patchwork.ozlabs.org/patch/411356/


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH] VERIFY_OCTAL_PERMISSIONS: Move to where it belongs

[George Spelvin]

>> -

> This shouldn't be here because "^---" is considered "end of changelog".

Damn it, I couldn't remember how to add not-for-commit comments to a patch.
I RTFMed and thought that was what "git mailinfo --scissors" wanted.

(Normally, I put it down with the diffstat, but preferred a more
prominent place for this conversation.)

> Let's include bug.h into sysfs.h.

It worked without, but yeah... since I can't figure *how* it works.

>> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
>> index 1c9effa2..974097df 100644
>> --- a/include/linux/moduleparam.h
>> +++ b/include/linux/moduleparam.h
>> @@ -1,9 +1,9 @@
>>  #ifndef _LINUX_MODULE_PARAMS_H
>>  #define _LINUX_MODULE_PARAMS_H
>>  /* (C) Copyright 2001, 2002 Rusty Russell IBM Corporation */
>> -#include 
>>  #include 
>> -#include 
>> +#include 
>> +#include 

> Removing the kernel.h inclusion is good, but risky.  Are you sure
> there's nothing in moduleparam.h which uses kernel.h things?

Well, I did a quick eyeball-scan, then did my usual build, then
an allyesconfig and an allmodconfig.

I found some other alarming things, but nothing related to this.

E.g.
drivers/net/ethernet/intel/i40e/i40e_debugfs.c: In function 
'i40e_dbg_dump_desc':
drivers/net/ethernet/intel/i40e/i40e_debugfs.c:855:1: warning: the frame size 
of 8192 bytes is larger than 2048 bytes [-Wframe-larger-than=]
 }

(Honestly, I didn't wait for the allmodconfig to finish, since I
expected it to fail within the first few hundred modules if it was going to
fail at all, but it has finished now.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] Drivers: hv: vmbus: Implement a clockevent device

[K. Y. Srinivasan]

Implement a clockevent device based on the timer support available on
Hyper-V.
In this version of the patch I have addressed Jason's review comments.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Jason Wang 
---
 arch/x86/include/uapi/asm/hyperv.h |   11 +
 drivers/hv/hv.c|   78 
 drivers/hv/hyperv_vmbus.h  |   21 ++
 drivers/hv/vmbus_drv.c |   37 -
 4 files changed, 145 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/uapi/asm/hyperv.h 
b/arch/x86/include/uapi/asm/hyperv.h
index 462efe7..90c458e 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -187,6 +187,17 @@
 #define HV_X64_MSR_SINT14  0x409E
 #define HV_X64_MSR_SINT15  0x409F
 
+/*
+ * Synthetic Timer MSRs. Four timers per vcpu.
+ */
+#define HV_X64_MSR_STIMER0_CONFIG  0x40B0
+#define HV_X64_MSR_STIMER0_COUNT   0x40B1
+#define HV_X64_MSR_STIMER1_CONFIG  0x40B2
+#define HV_X64_MSR_STIMER1_COUNT   0x40B3
+#define HV_X64_MSR_STIMER2_CONFIG  0x40B4
+#define HV_X64_MSR_STIMER2_COUNT   0x40B5
+#define HV_X64_MSR_STIMER3_CONFIG  0x40B6
+#define HV_X64_MSR_STIMER3_COUNT   0x40B7
 
 #define HV_X64_MSR_HYPERCALL_ENABLE0x0001
 #define HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT12
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 3e4235c..50e51a5 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -28,7 +28,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include "hyperv_vmbus.h"
 
 /* The one and only */
@@ -37,6 +39,10 @@ struct hv_context hv_context = {
.hypercall_page = NULL,
 };
 
+#define HV_TIMER_FREQUENCY (10 * 1000 * 1000) /* 100ns period */
+#define HV_MAX_MAX_DELTA_TICKS 0x
+#define HV_MIN_DELTA_TICKS 1
+
 /*
  * query_hypervisor_info - Get version info of the windows hypervisor
  */
@@ -144,6 +150,8 @@ int hv_init(void)
   sizeof(int) * NR_CPUS);
memset(hv_context.event_dpc, 0,
   sizeof(void *) * NR_CPUS);
+   memset(hv_context.clk_evt, 0,
+  sizeof(void *) * NR_CPUS);
 
max_leaf = query_hypervisor_info();
 
@@ -258,10 +266,63 @@ u16 hv_signal_event(void *con_id)
return status;
 }
 
+static int hv_ce_set_next_event(unsigned long delta,
+   struct clock_event_device *evt)
+{
+   cycle_t current_tick;
+
+   WARN_ON(evt->mode != CLOCK_EVT_MODE_ONESHOT);
+
+   rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
+   current_tick += delta;
+   wrmsrl(HV_X64_MSR_STIMER0_COUNT, current_tick);
+   return 0;
+}
+
+static void hv_ce_setmode(enum clock_event_mode mode,
+ struct clock_event_device *evt)
+{
+   union hv_timer_config timer_cfg;
+
+   switch (mode) {
+   case CLOCK_EVT_MODE_PERIODIC:
+   /* unsupported */
+   break;
+
+   case CLOCK_EVT_MODE_ONESHOT:
+   timer_cfg.enable = 1;
+   timer_cfg.auto_enable = 1;
+   timer_cfg.sintx = VMBUS_MESSAGE_SINT;
+   wrmsrl(HV_X64_MSR_STIMER0_CONFIG, timer_cfg.as_uint64);
+   break;
+
+   case CLOCK_EVT_MODE_UNUSED:
+   case CLOCK_EVT_MODE_SHUTDOWN:
+   wrmsrl(HV_X64_MSR_STIMER0_COUNT, 0);
+   wrmsrl(HV_X64_MSR_STIMER0_CONFIG, 0);
+   break;
+   case CLOCK_EVT_MODE_RESUME:
+   break;
+   }
+}
+
+static void hv_init_clockevent_device(struct clock_event_device *dev, int cpu)
+{
+   dev->name = "Hyper-V clockevent";
+   dev->features = CLOCK_EVT_FEAT_ONESHOT;
+   dev->cpumask = cpumask_of(cpu);
+   dev->rating = 1000;
+   dev->owner = THIS_MODULE;
+
+   dev->set_mode = hv_ce_setmode;
+   dev->set_next_event = hv_ce_set_next_event;
+}
+
 
 int hv_synic_alloc(void)
 {
size_t size = sizeof(struct tasklet_struct);
+   size_t ced_size = sizeof(struct clock_event_device);
int cpu;
 
for_each_online_cpu(cpu) {
@@ -272,6 +333,13 @@ int hv_synic_alloc(void)
}
tasklet_init(hv_context.event_dpc[cpu], vmbus_on_event, cpu);
 
+   hv_context.clk_evt[cpu] = kzalloc(ced_size, GFP_ATOMIC);
+   if (hv_context.clk_evt[cpu] == NULL) {
+   pr_err("Unable to allocate clock event device\n");
+   goto err;
+   }
+   hv_init_clockevent_device(hv_context.clk_evt[cpu], cpu);
+
hv_context.synic_message_page[cpu] =
(void *)get_zeroed_page(GFP_ATOMIC);
 
@@ -305,6 +373,7 @@ err:
 static void hv_synic_free_cpu(int cpu)
 {
kfree(hv_context.event_dpc[cpu]);
+   kfree(hv_context.clk_evt[cpu]);
if 

RE: drivers:scsi:storvsc: Fix a bug in handling ring buffer failures that may result in I/O freeze

[KY Srinivasan]

> -Original Message-
> From: Long Li [mailto:lon...@microsoft.com]
> Sent: Friday, December 5, 2014 7:38 PM
> To: linux-s...@vger.kernel.org
> Cc: KY Srinivasan; Haiyang Zhang; jbottom...@parallels.com;
> de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; Long Li
> Subject: drivers:scsi:storvsc: Fix a bug in handling ring buffer failures 
> that may
> result in I/O freeze
> 
> When ring buffer returns an error indicating retry, storvsc may not return a
> proper error code to SCSI when bounce buffer is not used. This has
> introduced I/O freeze on RAID running atop storvsc devices. This patch fixes
> it by always returning a proper error code.
> 
> Signed-off-by: Long Li 
> Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
cc: sta...@vger.kernel.org

> ---
>  drivers/scsi/storvsc_drv.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index
> e3ba251..4cff0dd 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1688,13 +1688,12 @@ static int storvsc_queuecommand(struct
> Scsi_Host *host, struct scsi_cmnd *scmnd)
>   if (ret == -EAGAIN) {
>   /* no more space */
> 
> - if (cmd_request->bounce_sgl_count) {
> + if (cmd_request->bounce_sgl_count)
>   destroy_bounce_buffer(cmd_request->bounce_sgl,
>   cmd_request->bounce_sgl_count);
> 
> - ret = SCSI_MLQUEUE_DEVICE_BUSY;
> - goto queue_error;
> - }
> + ret = SCSI_MLQUEUE_DEVICE_BUSY;
> + goto queue_error;
>   }
> 
>   return 0;
> --
> 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/

drivers:scsi:storvsc: Fix a bug in handling ring buffer failures that may result in I/O freeze

[Long Li]

When ring buffer returns an error indicating retry, storvsc may not return a 
proper error code to SCSI when bounce buffer is not used. This has introduced 
I/O freeze on RAID running atop storvsc devices. This patch fixes it by always 
returning a proper error code.

Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
---
 drivers/scsi/storvsc_drv.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index e3ba251..4cff0dd 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1688,13 +1688,12 @@ static int storvsc_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *scmnd)
if (ret == -EAGAIN) {
/* no more space */
 
-   if (cmd_request->bounce_sgl_count) {
+   if (cmd_request->bounce_sgl_count)
destroy_bounce_buffer(cmd_request->bounce_sgl,
cmd_request->bounce_sgl_count);
 
-   ret = SCSI_MLQUEUE_DEVICE_BUSY;
-   goto queue_error;
-   }
+   ret = SCSI_MLQUEUE_DEVICE_BUSY;
+   goto queue_error;
}
 
return 0;
-- 
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 2/5] gpio: Cygnus: add GPIO driver

[Joe Perches]

On Fri, 2014-12-05 at 18:14 -0800, Ray Jui wrote:
> On 12/5/2014 5:28 PM, Joe Perches wrote:
> > On Fri, 2014-12-05 at 16:40 -0800, Ray Jui wrote:
> >> +static void bcm_cygnus_gpio_irq_handler(unsigned int irq,
> >> +  struct irq_desc *desc)
> >> +{
> >> +  struct bcm_cygnus_gpio *cygnus_gpio;
> >> +  struct irq_chip *chip = irq_desc_get_chip(desc);
> >> +  int i, bit;
> >> +
> >> +  chained_irq_enter(chip, desc);
> >> +
> >> +  cygnus_gpio = irq_get_handler_data(irq);
> >> +
> >> +  /* go through the entire GPIO banks and handle all interrupts */
> >> +  for (i = 0; i < cygnus_gpio->num_banks; i++) {
> >> +  unsigned long val = readl(cygnus_gpio->base +
> >> +  (i * GPIO_BANK_SIZE) +
> >> +  CYGNUS_GPIO_INT_MSTAT_OFFSET);
> >> +  if (val) {
> >
> > This if (val) and indentation isn't really necessary
> >
> 
> Note for_each_set_bit in this case iterates 32 times searching for bits 
> that are set.

No it doesn't.

#define for_each_set_bit(bit, addr, size) \
for ((bit) = find_first_bit((addr), (size));\
 (bit) < (size);\
 (bit) = find_next_bit((addr), (size), (bit) + 1))

find_first_bit:

 * Returns the bit number of the first set bit.
 * If no bits are set, returns @size.

>  By having the if (val) check here, it can potentially save 
> some of such processing in the ISR. I agree with you that it introduces 
> one extra indent here but I think it's required.
> 
> >> +  for_each_set_bit(bit, , 32) {
> >
> > for_each_set_bit will effectively do the if above.
> >
> > 32 bit only code?
> > otherwise isn't this endian unsafe?
> >
> 
> Will change 'unsigned long val' to 'u32 val'.

All the bit operations only work on long *


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

[PATCH] PM / Kconfig: Replace PM_RUNTIME with PM in dependencies

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so Kconfig options
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

Replace PM_RUNTIME with PM in Kconfig dependencies throughout the
tree.

Signed-off-by: Rafael J. Wysocki 
---

Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).

Please let me know if it is OK to take this one into linux-pm.

---
 arch/arm/mach-exynos/Kconfig  |2 +-
 arch/ia64/Kconfig |2 +-
 drivers/ata/Kconfig   |2 +-
 drivers/media/platform/Kconfig|2 +-
 drivers/media/platform/s5p-tv/Kconfig |2 +-
 drivers/staging/gdm72xx/Kconfig   |2 +-
 drivers/usb/core/Kconfig  |2 +-
 drivers/usb/phy/Kconfig   |4 ++--
 drivers/usb/storage/Kconfig   |2 +-
 9 files changed, 10 insertions(+), 10 deletions(-)

Index: linux-pm/arch/arm/mach-exynos/Kconfig
===
--- linux-pm.orig/arch/arm/mach-exynos/Kconfig
+++ linux-pm/arch/arm/mach-exynos/Kconfig
@@ -21,7 +21,7 @@ menuconfig ARCH_EXYNOS
select HAVE_S3C_RTC if RTC_CLASS
select PINCTRL
select PINCTRL_EXYNOS
-   select PM_GENERIC_DOMAINS if PM_RUNTIME
+   select PM_GENERIC_DOMAINS if PM
select S5P_DEV_MFC
select SRAM
help
Index: linux-pm/arch/ia64/Kconfig
===
--- linux-pm.orig/arch/ia64/Kconfig
+++ linux-pm/arch/ia64/Kconfig
@@ -232,7 +232,7 @@ config IA64_SGI_UV
 config IA64_HP_SIM
bool "Ski-simulator"
select SWIOTLB
-   depends on !PM_RUNTIME
+   depends on !PM
 
 endchoice
 
Index: linux-pm/drivers/ata/Kconfig
===
--- linux-pm.orig/drivers/ata/Kconfig
+++ linux-pm/drivers/ata/Kconfig
@@ -61,7 +61,7 @@ config ATA_ACPI
 
 config SATA_ZPODD
bool "SATA Zero Power Optical Disc Drive (ZPODD) support"
-   depends on ATA_ACPI && PM_RUNTIME
+   depends on ATA_ACPI && PM
default n
help
  This option adds support for SATA Zero Power Optical Disc
Index: linux-pm/drivers/media/platform/Kconfig
===
--- linux-pm.orig/drivers/media/platform/Kconfig
+++ linux-pm/drivers/media/platform/Kconfig
@@ -112,7 +112,7 @@ config VIDEO_OMAP3_DEBUG
 config VIDEO_S3C_CAMIF
tristate "Samsung S3C24XX/S3C64XX SoC Camera Interface driver"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
-   depends on PM_RUNTIME
+   depends on PM
depends on ARCH_S3C64XX || PLAT_S3C24XX || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
Index: linux-pm/drivers/media/platform/s5p-tv/Kconfig
===
--- linux-pm.orig/drivers/media/platform/s5p-tv/Kconfig
+++ linux-pm/drivers/media/platform/s5p-tv/Kconfig
@@ -8,7 +8,7 @@
 
 config VIDEO_SAMSUNG_S5P_TV
bool "Samsung TV driver for S5P platform"
-   depends on PM_RUNTIME
+   depends on PM
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
default n
---help---
Index: linux-pm/drivers/staging/gdm72xx/Kconfig
===
--- linux-pm.orig/drivers/staging/gdm72xx/Kconfig
+++ linux-pm/drivers/staging/gdm72xx/Kconfig
@@ -53,7 +53,7 @@ if WIMAX_GDM72XX_USB
 
 config WIMAX_GDM72XX_USB_PM
bool "Enable power management support"
-   depends on PM_RUNTIME
+   depends on PM
help
  Enable USB power management in order to reduce power consumption
  while the interface is not in use.
Index: linux-pm/drivers/usb/core/Kconfig
===
--- linux-pm.orig/drivers/usb/core/Kconfig
+++ linux-pm/drivers/usb/core/Kconfig
@@ -43,7 +43,7 @@ config USB_DYNAMIC_MINORS
 
 config USB_OTG
bool "OTG support"
-   depends on PM_RUNTIME
+   depends on PM
default n
help
  The most notable feature of USB OTG is support for a
Index: linux-pm/drivers/usb/phy/Kconfig
===
--- linux-pm.orig/drivers/usb/phy/Kconfig
+++ linux-pm/drivers/usb/phy/Kconfig
@@ -20,7 +20,7 @@ config AB8500_USB
 
 config FSL_USB2_OTG
bool "Freescale USB OTG Transceiver Driver"
-   depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM_RUNTIME
+   depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM
select USB_OTG
select USB_PHY
help
@@ -153,7 +153,7 @@ config USB_MSM_OTG
 
 config USB_MV_OTG
tristate "Marvell USB OTG support"
-   

RE: [PATCH V3 1/1] Drivers: hv: vmbus: Implement a clockevent device

[KY Srinivasan]

> -Original Message-
> From: K. Y. Srinivasan [mailto:k...@microsoft.com]
> Sent: Friday, December 5, 2014 4:27 PM
> To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com
> Cc: KY Srinivasan
> Subject: [PATCH V3 1/1] Drivers: hv: vmbus: Implement a clockevent device
> 
> Implement a clockevent device based on the timer support available on
> Hyper-V.
> In This version of the patch I have addressed Jason's review comments.
> 
> Signed-off-by: K. Y. Srinivasan 
> Reviewed-by: Jason Wang 

Greg,

Please drop this patch, I have mailed the wrong patch. I will send the correct 
one shortly.

K. Y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere in the code under
arch/arm/ (the defconfig files will be modified later).

Signed-off-by: Rafael J. Wysocki 
---

Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).

Please let me know if it is OK to take this one into linux-pm.

---
 arch/arm/kernel/perf_event.c   |2 +-
 arch/arm/mach-davinci/pm_domain.c  |2 +-
 arch/arm/mach-keystone/pm_domain.c |2 +-
 arch/arm/mach-omap1/pm_bus.c   |4 ++--
 arch/arm/mach-omap2/io.c   |2 +-
 arch/arm/mach-omap2/omap_device.c  |2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

Index: linux-pm/arch/arm/kernel/perf_event.c
===
--- linux-pm.orig/arch/arm/kernel/perf_event.c
+++ linux-pm/arch/arm/kernel/perf_event.c
@@ -481,7 +481,7 @@ static void armpmu_disable(struct pmu *p
armpmu->stop(armpmu);
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int armpmu_runtime_resume(struct device *dev)
 {
struct arm_pmu_platdata *plat = dev_get_platdata(dev);
Index: linux-pm/arch/arm/mach-davinci/pm_domain.c
===
--- linux-pm.orig/arch/arm/mach-davinci/pm_domain.c
+++ linux-pm/arch/arm/mach-davinci/pm_domain.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int davinci_pm_runtime_suspend(struct device *dev)
 {
int ret;
Index: linux-pm/arch/arm/mach-keystone/pm_domain.c
===
--- linux-pm.orig/arch/arm/mach-keystone/pm_domain.c
+++ linux-pm/arch/arm/mach-keystone/pm_domain.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int keystone_pm_runtime_suspend(struct device *dev)
 {
int ret;
Index: linux-pm/arch/arm/mach-omap1/pm_bus.c
===
--- linux-pm.orig/arch/arm/mach-omap1/pm_bus.c
+++ linux-pm/arch/arm/mach-omap1/pm_bus.c
@@ -21,7 +21,7 @@
 
 #include "soc.h"
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int omap1_pm_runtime_suspend(struct device *dev)
 {
int ret;
@@ -59,7 +59,7 @@ static struct dev_pm_domain default_pm_d
 #define OMAP1_PM_DOMAIN (_pm_domain)
 #else
 #define OMAP1_PM_DOMAIN NULL
-#endif /* CONFIG_PM_RUNTIME */
+#endif /* CONFIG_PM */
 
 static struct pm_clk_notifier_block platform_bus_notifier = {
.pm_domain = OMAP1_PM_DOMAIN,
Index: linux-pm/arch/arm/mach-omap2/io.c
===
--- linux-pm.orig/arch/arm/mach-omap2/io.c
+++ linux-pm/arch/arm/mach-omap2/io.c
@@ -359,7 +359,7 @@ static void __init omap_hwmod_init_posts
u8 postsetup_state;
 
/* Set the default postsetup state for all hwmods */
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
postsetup_state = _HWMOD_STATE_IDLE;
 #else
postsetup_state = _HWMOD_STATE_ENABLED;
Index: linux-pm/arch/arm/mach-omap2/omap_device.c
===
--- linux-pm.orig/arch/arm/mach-omap2/omap_device.c
+++ linux-pm/arch/arm/mach-omap2/omap_device.c
@@ -588,7 +588,7 @@ odbs_exit:
return ERR_PTR(ret);
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int _od_runtime_suspend(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sound / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under sound/.

Signed-off-by: Rafael J. Wysocki 
---

Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).

Please let me know if it is OK to take this one into linux-pm.

---
 sound/pci/hda/hda_controller.c |2 +-
 sound/pci/hda/hda_intel.c  |5 +
 sound/soc/codecs/cs35l32.c |2 +-
 sound/soc/codecs/cs42xx8.c |2 +-
 sound/soc/codecs/max98090.c|2 +-
 sound/soc/codecs/pcm512x.c |2 +-
 sound/soc/codecs/tas2552.c |4 ++--
 sound/soc/codecs/wm2200.c  |2 +-
 sound/soc/codecs/wm5100.c  |2 +-
 sound/soc/codecs/wm8962.c  |2 +-
 sound/soc/fsl/fsl_asrc.c   |4 ++--
 sound/soc/samsung/i2s.c|4 ++--
 12 files changed, 15 insertions(+), 18 deletions(-)

Index: linux-pm/sound/pci/hda/hda_controller.c
===
--- linux-pm.orig/sound/pci/hda/hda_controller.c
+++ linux-pm/sound/pci/hda/hda_controller.c
@@ -1676,7 +1676,7 @@ irqreturn_t azx_interrupt(int irq, void
u8 sd_status;
int i;
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
if (chip->driver_caps & AZX_DCAPS_PM_RUNTIME)
if (!pm_runtime_active(chip->card->dev))
return IRQ_NONE;
Index: linux-pm/sound/pci/hda/hda_intel.c
===
--- linux-pm.orig/sound/pci/hda/hda_intel.c
+++ linux-pm/sound/pci/hda/hda_intel.c
@@ -856,7 +856,7 @@ static int azx_resume(struct device *dev
 }
 #endif /* CONFIG_PM_SLEEP || SUPPORT_VGA_SWITCHEROO */
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int azx_runtime_suspend(struct device *dev)
 {
struct snd_card *card = dev_get_drvdata(dev);
@@ -954,9 +954,6 @@ static int azx_runtime_idle(struct devic
return 0;
 }
 
-#endif /* CONFIG_PM_RUNTIME */
-
-#ifdef CONFIG_PM
 static const struct dev_pm_ops azx_pm = {
SET_SYSTEM_SLEEP_PM_OPS(azx_suspend, azx_resume)
SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, 
azx_runtime_idle)
Index: linux-pm/sound/soc/codecs/cs35l32.c
===
--- linux-pm.orig/sound/soc/codecs/cs35l32.c
+++ linux-pm/sound/soc/codecs/cs35l32.c
@@ -550,7 +550,7 @@ static int cs35l32_i2c_remove(struct i2c
return 0;
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int cs35l32_runtime_suspend(struct device *dev)
 {
struct cs35l32_private *cs35l32 = dev_get_drvdata(dev);
Index: linux-pm/sound/soc/codecs/cs42xx8.c
===
--- linux-pm.orig/sound/soc/codecs/cs42xx8.c
+++ linux-pm/sound/soc/codecs/cs42xx8.c
@@ -537,7 +537,7 @@ err_enable:
 }
 EXPORT_SYMBOL_GPL(cs42xx8_probe);
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int cs42xx8_runtime_resume(struct device *dev)
 {
struct cs42xx8_priv *cs42xx8 = dev_get_drvdata(dev);
Index: linux-pm/sound/soc/codecs/max98090.c
===
--- linux-pm.orig/sound/soc/codecs/max98090.c
+++ linux-pm/sound/soc/codecs/max98090.c
@@ -2492,7 +2492,7 @@ static int max98090_i2c_remove(struct i2
return 0;
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int max98090_runtime_resume(struct device *dev)
 {
struct max98090_priv *max98090 = dev_get_drvdata(dev);
Index: linux-pm/sound/soc/codecs/pcm512x.c
===
--- linux-pm.orig/sound/soc/codecs/pcm512x.c
+++ linux-pm/sound/soc/codecs/pcm512x.c
@@ -517,7 +517,7 @@ void pcm512x_remove(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(pcm512x_remove);
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int pcm512x_suspend(struct device *dev)
 {
struct pcm512x_priv *pcm512x = dev_get_drvdata(dev);
Index: linux-pm/sound/soc/codecs/tas2552.c
===
--- linux-pm.orig/sound/soc/codecs/tas2552.c
+++ linux-pm/sound/soc/codecs/tas2552.c
@@ -115,7 +115,7 @@ static const struct snd_soc_dapm_route t
{"ClassD", NULL, "PLL"},
 };
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static void tas2552_sw_shutdown(struct tas2552_data *tas_data, int sw_shutdown)
 {
u8 cfg1_reg;
@@ -264,7 +264,7 @@ static int tas2552_mute(struct snd_soc_d
return 0;
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int tas2552_runtime_suspend(struct device *dev)
 {
struct tas2552_data *tas2552 = dev_get_drvdata(dev);
Index: linux-pm/sound/soc/codecs/wm2200.c

[PATCH] tracing / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so files that are
build conditionally if CONFIG_PM_RUNTIME is set may now be build
if CONFIG_PM is set.

Replace CONFIG_PM_RUNTIME with CONFIG_PM in kernel/trace/Makefile
for this reason.

Signed-off-by: Rafael J. Wysocki 
---

Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).

Please let me know if it is OK to take this one into linux-pm.

---
 kernel/trace/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-pm/kernel/trace/Makefile
===
--- linux-pm.orig/kernel/trace/Makefile
+++ linux-pm/kernel/trace/Makefile
@@ -55,7 +55,7 @@ obj-$(CONFIG_EVENT_TRACING) += trace_eve
 obj-$(CONFIG_EVENT_TRACING) += trace_events_trigger.o
 obj-$(CONFIG_KPROBE_EVENT) += trace_kprobe.o
 obj-$(CONFIG_TRACEPOINTS) += power-traces.o
-ifeq ($(CONFIG_PM_RUNTIME),y)
+ifeq ($(CONFIG_PM),y)
 obj-$(CONFIG_TRACEPOINTS) += rpm-traces.o
 endif
 ifeq ($(CONFIG_TRACING),y)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] phy / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
drivers/phy/.

Signed-off-by: Rafael J. Wysocki 
---

Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).

Please let me know if it is OK to take this one into linux-pm.

---
 drivers/phy/phy-omap-usb2.c |2 +-
 drivers/phy/phy-ti-pipe3.c  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/phy/phy-omap-usb2.c
===
--- linux-pm.orig/drivers/phy/phy-omap-usb2.c
+++ linux-pm/drivers/phy/phy-omap-usb2.c
@@ -322,7 +322,7 @@ static int omap_usb2_remove(struct platf
return 0;
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 
 static int omap_usb2_runtime_suspend(struct device *dev)
 {
Index: linux-pm/drivers/phy/phy-ti-pipe3.c
===
--- linux-pm.orig/drivers/phy/phy-ti-pipe3.c
+++ linux-pm/drivers/phy/phy-ti-pipe3.c
@@ -423,7 +423,7 @@ static int ti_pipe3_remove(struct platfo
return 0;
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 
 static int ti_pipe3_runtime_suspend(struct device *dev)
 {

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V8] intel_pstate: add kernel parameter to force loading.

[ethan]

Linda，

> 在 2014年12月6日，00:09，Linda Knippers  写道：
> 
>> On 12/5/2014 4:40 AM, Ethan Zhao wrote:
>> To force loading on Oracle Sun X86 servers, provide one kernel command line
>> parameter
>> 
>>  intel_pstate = force
>> 
>> For those who be aware of the risk of no power capping capabily working and
>> try to get better performance with this driver.
>> 
>> Signed-off-by: Ethan Zhao 
>> Tested-by: Alexey Kodanev 
>> ---
>> v2: change to hardware vendor specific naming parameter.
>> v4: refine code and doc.
>> v5: fix a typo in doc.
>> v7: change enum PCC to PPC.
>> v8: change the name of kernel command line parameter to generic one.
>> 
>> Documentation/kernel-parameters.txt | 5 +
>> drivers/cpufreq/intel_pstate.c  | 6 +-
>> 2 files changed, 10 insertions(+), 1 deletion(-)
>> 
>> diff --git a/Documentation/kernel-parameters.txt 
>> b/Documentation/kernel-parameters.txt
>> index 479f332..7d0983e 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -1446,6 +1446,11 @@ bytes respectively. Such letter suffixes can also be 
>> entirely omitted.
>>   disable
>> Do not enable intel_pstate as the default
>> scaling driver for the supported processors
>> +   force
>> + Enable intel_pstate on systems where it may cause problems to
>> + happen due to conflicts with platform firmware attempting to
>> + drive P-states by itself in certain situations (for thermal 
>> + control or power capping in general or other purposes).
> 
> I suggest something like:
>Enable intel_pstate on systems that prohibit it by
>default in favor of acpi-cpufreq.  Forcing the
>intel_pstate driver instead of acpi-cpufreq may disable
>platform features, such as thermal controls and power
>capping, that rely on ACPI p-state information being
 P-States 
> Used by the OS and therefore should be used with care.
   Indicated to OSPM
   caution 
>This option does not work with processors that aren't
>supported by the intel_pstate driver or on platforms
>that use pcc-cpufreq instead of acpi-cpufreq.
> 
> Maybe this is too specific but I believe it is accurate.  Comments?
> 

Looks better to me, except some words commented. 

Thanks,
Ethan
> -- ljk
> 
>> 
>>intremap=[X86-64, Intel-IOMMU]
>>onenable Interrupt Remapping (default)
>> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
>> index 1bb62ca..2654e13 100644
>> --- a/drivers/cpufreq/intel_pstate.c
>> +++ b/drivers/cpufreq/intel_pstate.c
>> @@ -866,6 +866,7 @@ static struct cpufreq_driver intel_pstate_driver = {
>> };
>> 
>> static int __initdata no_load;
>> +static unsigned int  force_load;
>> 
>> static int intel_pstate_msrs_not_valid(void)
>> {
>> @@ -1003,7 +1004,8 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
>>case PSS:
>>return intel_pstate_no_acpi_pss();
>>case PPC:
>> -return intel_pstate_has_acpi_ppc();
>> +return intel_pstate_has_acpi_ppc() &&
>> +(!force_load);
>>}
>>}
>> 
>> @@ -1078,6 +1080,8 @@ static int __init intel_pstate_setup(char *str)
>> 
>>if (!strcmp(str, "disable"))
>>no_load = 1;
>> +if (!strcmp(str, "force"))
>> +force_load = 1;
>>return 0;
>> }
>> early_param("intel_pstate", intel_pstate_setup);
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] video / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

The alternative of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME may be
replaced with CONFIG_PM too.

Make these changes in 2 files under drivers/video/.

Signed-off-by: Rafael J. Wysocki 
---

Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).

Please let me know if it is OK to take this one into linux-pm.

---
 drivers/video/fbdev/s3c-fb.c  |2 +-
 drivers/video/fbdev/sh_mobile_meram.c |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/video/fbdev/sh_mobile_meram.c
===
--- linux-pm.orig/drivers/video/fbdev/sh_mobile_meram.c
+++ linux-pm/drivers/video/fbdev/sh_mobile_meram.c
@@ -569,7 +569,7 @@ EXPORT_SYMBOL_GPL(sh_mobile_meram_cache_
  * Power management
  */
 
-#if defined(CONFIG_PM_SLEEP) || defined(CONFIG_PM_RUNTIME)
+#ifdef CONFIG_PM
 static int sh_mobile_meram_suspend(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -612,7 +612,7 @@ static int sh_mobile_meram_resume(struct
meram_write_reg(priv->base, common_regs[i], priv->regs[i]);
return 0;
 }
-#endif /* CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME */
+#endif /* CONFIG_PM */
 
 static UNIVERSAL_DEV_PM_OPS(sh_mobile_meram_dev_pm_ops,
sh_mobile_meram_suspend,
Index: linux-pm/drivers/video/fbdev/s3c-fb.c
===
--- linux-pm.orig/drivers/video/fbdev/s3c-fb.c
+++ linux-pm/drivers/video/fbdev/s3c-fb.c
@@ -1630,7 +1630,7 @@ static int s3c_fb_resume(struct device *
 }
 #endif
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int s3c_fb_runtime_suspend(struct device *dev)
 {
struct s3c_fb *sfb = dev_get_drvdata(dev);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: Cygnus: add GPIO driver

[Ray Jui]

Thanks for your review, Joe:

On 12/5/2014 5:28 PM, Joe Perches wrote:

On Fri, 2014-12-05 at 16:40 -0800, Ray Jui wrote:

This GPIO driver supports all 3 GPIO controllers in the Broadcom Cygnus
SoC. The 3 GPIO controllers are 1) the ASIU GPIO controller
("brcm,cygnus-asiu-gpio"), 2) the chipCommonG GPIO controller
("brcm,cygnus-ccm-gpio"), and 3) the ALWAYS-ON GPIO controller
("brcm,cygnus-crmu-gpio")


trivia:


diff --git a/drivers/gpio/gpio-bcm-cygnus.c b/drivers/gpio/gpio-bcm-cygnus.c



+static inline struct bcm_cygnus_gpio *to_bcm_cygnus_gpio(
+   struct gpio_chip *gc)
+{
+   return container_of(gc, struct bcm_cygnus_gpio, gc);
+}


Probably all of these inlines can just be static.

The compiler does a pretty good job these days
of inlining where appropriate.


Okay I can remove all inlines.





+static void bcm_cygnus_gpio_irq_handler(unsigned int irq,
+   struct irq_desc *desc)
+{
+   struct bcm_cygnus_gpio *cygnus_gpio;
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   int i, bit;
+
+   chained_irq_enter(chip, desc);
+
+   cygnus_gpio = irq_get_handler_data(irq);
+
+   /* go through the entire GPIO banks and handle all interrupts */
+   for (i = 0; i < cygnus_gpio->num_banks; i++) {
+   unsigned long val = readl(cygnus_gpio->base +
+   (i * GPIO_BANK_SIZE) +
+   CYGNUS_GPIO_INT_MSTAT_OFFSET);
+   if (val) {


This if (val) and indentation isn't really necessary



Note for_each_set_bit in this case iterates 32 times searching for bits 
that are set. By having the if (val) check here, it can potentially save 
some of such processing in the ISR. I agree with you that it introduces 
one extra indent here but I think it's required.



+   for_each_set_bit(bit, , 32) {


for_each_set_bit will effectively do the if above.

32 bit only code?
otherwise isn't this endian unsafe?



Will change 'unsigned long val' to 'u32 val'.


+   unsigned pin = NGPIOS_PER_BANK * i + bit;
+   int child_irq = bcm_cygnus_gpio_to_irq(
+   _gpio->gc, pin);
+
+   /*
+* Clear the interrupt before invoking the
+* handler, so we do not leave any window
+*/
+   writel(1 << bit,
+   cygnus_gpio->base +
+   (i * GPIO_BANK_SIZE) +
+   CYGNUS_GPIO_INT_CLR_OFFSET);
+
+   generic_handle_irq(child_irq);
+   }
+
+   }
+   }
+
+   chained_irq_exit(chip, desc);
+}
+
+static void bcm_cygnus_gpio_irq_ack(struct irq_data *d)
+{
+   struct bcm_cygnus_gpio *cygnus_gpio = irq_data_get_irq_chip_data(d);
+   unsigned gpio = d->hwirq;
+   unsigned int offset, shift;
+   u32 val;
+
+   offset = __gpio_reg_offset(cygnus_gpio, gpio) +
+   CYGNUS_GPIO_INT_CLR_OFFSET;
+   shift = __gpio_bitpos(cygnus_gpio, gpio);
+
+   val = 1 << shift;
+   writel(val, cygnus_gpio->base + offset);
+
+   dev_dbg(cygnus_gpio->dev, "gpio:%u offset:0x%04x shift:%u\n", gpio,
+   offset, shift);
+}



+static struct irq_chip bcm_cygnus_gpio_irq_chip = {
+   .name = "bcm-cygnus-gpio",
+   .irq_ack = bcm_cygnus_gpio_irq_ack,
+   .irq_mask = bcm_cygnus_gpio_irq_mask,
+   .irq_unmask = bcm_cygnus_gpio_irq_unmask,
+   .irq_set_type = bcm_cygnus_gpio_irq_set_type,
+};


const?




Sure, will add const to bcm_cygnus_gpio_irq_chip


+static struct irq_domain_ops bcm_cygnus_irq_ops = {
+   .map = bcm_cygnus_gpio_irq_map,
+   .unmap = bcm_cygnus_gpio_irq_unmap,
+   .xlate = irq_domain_xlate_twocell,
+};


const here too?



Yes, will make bcm_cygnus_irq_ops const.


+#ifdef CONFIG_OF_GPIO
+static void bcm_cygnus_gpio_set_pull(struct bcm_cygnus_gpio *cygnus_gpio,
+   unsigned gpio, enum gpio_pull pull)
+{
+   unsigned int offset, shift;
+   u32 val, up;


bool up; ?



Okay I'll change the name from 'up' to 'pullup' to make it more readable.


+   unsigned long flags;
+
+   switch (pull) {
+   case GPIO_PULL_NONE:
+   return;
+   case GPIO_PULL_UP:
+   up = 1;
+   break;
+   case GPIO_PULL_DOWN:
+   up = 0;
+   break;
+   case GPIO_PULL_INVALID:
+   default:
+   return;
+   }


Maybe more sensible to group GPIO_PULL_NONE with GPIO_PULL_INVALID




Good suggestion, will do the following:

case GPIO_PULL_NONE:
case GPIO_PULL_INVALID:
default:
   return;


+static int bcm_cygnus_gpio_probe(struct platform_device *pdev)
+{

[]

+   res = platform_get_resource(pdev, 

[PATCH] tty / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
drivers/tty/.

Signed-off-by: Rafael J. Wysocki 
---

Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).

Please let me know if it is OK to take this one into linux-pm.

---
 drivers/tty/serial/8250/8250_dw.c  |2 +-
 drivers/tty/serial/8250/8250_mtk.c |2 +-
 drivers/tty/serial/mfd.c   |7 ++-
 drivers/tty/serial/msm_serial_hs.c |2 +-
 drivers/tty/serial/omap-serial.c   |2 +-
 5 files changed, 6 insertions(+), 9 deletions(-)

Index: linux-pm/drivers/tty/serial/8250/8250_dw.c
===
--- linux-pm.orig/drivers/tty/serial/8250/8250_dw.c
+++ linux-pm/drivers/tty/serial/8250/8250_dw.c
@@ -489,7 +489,7 @@ static int dw8250_resume(struct device *
 }
 #endif /* CONFIG_PM_SLEEP */
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int dw8250_runtime_suspend(struct device *dev)
 {
struct dw8250_data *data = dev_get_drvdata(dev);
Index: linux-pm/drivers/tty/serial/8250/8250_mtk.c
===
--- linux-pm.orig/drivers/tty/serial/8250/8250_mtk.c
+++ linux-pm/drivers/tty/serial/8250/8250_mtk.c
@@ -244,7 +244,7 @@ static int mtk8250_resume(struct device
 }
 #endif /* CONFIG_PM_SLEEP */
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int mtk8250_runtime_suspend(struct device *dev)
 {
struct mtk8250_data *data = dev_get_drvdata(dev);
Index: linux-pm/drivers/tty/serial/msm_serial_hs.c
===
--- linux-pm.orig/drivers/tty/serial/msm_serial_hs.c
+++ linux-pm/drivers/tty/serial/msm_serial_hs.c
@@ -1792,7 +1792,7 @@ static void __exit msm_serial_hs_exit(vo
 }
 module_exit(msm_serial_hs_exit);
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int msm_hs_runtime_idle(struct device *dev)
 {
/*
Index: linux-pm/drivers/tty/serial/mfd.c
===
--- linux-pm.orig/drivers/tty/serial/mfd.c
+++ linux-pm/drivers/tty/serial/mfd.c
@@ -1252,12 +1252,7 @@ static int serial_hsu_resume(struct pci_
}
return 0;
 }
-#else
-#define serial_hsu_suspend NULL
-#define serial_hsu_resume  NULL
-#endif
 
-#ifdef CONFIG_PM_RUNTIME
 static int serial_hsu_runtime_idle(struct device *dev)
 {
pm_schedule_suspend(dev, 500);
@@ -1274,6 +1269,8 @@ static int serial_hsu_runtime_resume(str
return 0;
 }
 #else
+#define serial_hsu_suspend NULL
+#define serial_hsu_resume  NULL
 #define serial_hsu_runtime_idleNULL
 #define serial_hsu_runtime_suspend NULL
 #define serial_hsu_runtime_resume  NULL
Index: linux-pm/drivers/tty/serial/omap-serial.c
===
--- linux-pm.orig/drivers/tty/serial/omap-serial.c
+++ linux-pm/drivers/tty/serial/omap-serial.c
@@ -1799,7 +1799,7 @@ static void serial_omap_mdr1_errataset(s
}
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static void serial_omap_restore_context(struct uart_omap_port *up)
 {
if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] SPI / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
drivers/spi/.

Signed-off-by: Rafael J. Wysocki 
---

Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).

Please let me know if it is OK to take this one into linux-pm.

---
 drivers/spi/spi-coldfire-qspi.c |2 +-
 drivers/spi/spi-orion.c |2 +-
 drivers/spi/spi-pxa2xx.c|2 +-
 drivers/spi/spi-qup.c   |4 ++--
 drivers/spi/spi-rockchip.c  |4 ++--
 drivers/spi/spi-s3c64xx.c   |4 ++--
 6 files changed, 9 insertions(+), 9 deletions(-)

Index: linux-pm/drivers/spi/spi-s3c64xx.c
===
--- linux-pm.orig/drivers/spi/spi-s3c64xx.c
+++ linux-pm/drivers/spi/spi-s3c64xx.c
@@ -1266,7 +1266,7 @@ static int s3c64xx_spi_resume(struct dev
 }
 #endif /* CONFIG_PM_SLEEP */
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int s3c64xx_spi_runtime_suspend(struct device *dev)
 {
struct spi_master *master = dev_get_drvdata(dev);
@@ -1296,7 +1296,7 @@ static int s3c64xx_spi_runtime_resume(st
 
return 0;
 }
-#endif /* CONFIG_PM_RUNTIME */
+#endif /* CONFIG_PM */
 
 static const struct dev_pm_ops s3c64xx_spi_pm = {
SET_SYSTEM_SLEEP_PM_OPS(s3c64xx_spi_suspend, s3c64xx_spi_resume)
Index: linux-pm/drivers/spi/spi-coldfire-qspi.c
===
--- linux-pm.orig/drivers/spi/spi-coldfire-qspi.c
+++ linux-pm/drivers/spi/spi-coldfire-qspi.c
@@ -491,7 +491,7 @@ static int mcfqspi_resume(struct device
 }
 #endif
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int mcfqspi_runtime_suspend(struct device *dev)
 {
struct spi_master *master = dev_get_drvdata(dev);
Index: linux-pm/drivers/spi/spi-qup.c
===
--- linux-pm.orig/drivers/spi/spi-qup.c
+++ linux-pm/drivers/spi/spi-qup.c
@@ -646,7 +646,7 @@ error:
return ret;
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int spi_qup_pm_suspend_runtime(struct device *device)
 {
struct spi_master *master = dev_get_drvdata(device);
@@ -672,7 +672,7 @@ static int spi_qup_pm_resume_runtime(str
writel_relaxed(config, controller->base + QUP_CONFIG);
return 0;
 }
-#endif /* CONFIG_PM_RUNTIME */
+#endif /* CONFIG_PM */
 
 #ifdef CONFIG_PM_SLEEP
 static int spi_qup_suspend(struct device *device)
Index: linux-pm/drivers/spi/spi-orion.c
===
--- linux-pm.orig/drivers/spi/spi-orion.c
+++ linux-pm/drivers/spi/spi-orion.c
@@ -523,7 +523,7 @@ static int orion_spi_remove(struct platf
 
 MODULE_ALIAS("platform:" DRIVER_NAME);
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int orion_spi_runtime_suspend(struct device *dev)
 {
struct spi_master *master = dev_get_drvdata(dev);
Index: linux-pm/drivers/spi/spi-rockchip.c
===
--- linux-pm.orig/drivers/spi/spi-rockchip.c
+++ linux-pm/drivers/spi/spi-rockchip.c
@@ -801,7 +801,7 @@ static int rockchip_spi_resume(struct de
 }
 #endif /* CONFIG_PM_SLEEP */
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int rockchip_spi_runtime_suspend(struct device *dev)
 {
struct spi_master *master = dev_get_drvdata(dev);
@@ -829,7 +829,7 @@ static int rockchip_spi_runtime_resume(s
 
return ret;
 }
-#endif /* CONFIG_PM_RUNTIME */
+#endif /* CONFIG_PM */
 
 static const struct dev_pm_ops rockchip_spi_pm = {
SET_SYSTEM_SLEEP_PM_OPS(rockchip_spi_suspend, rockchip_spi_resume)
Index: linux-pm/drivers/spi/spi-pxa2xx.c
===
--- linux-pm.orig/drivers/spi/spi-pxa2xx.c
+++ linux-pm/drivers/spi/spi-pxa2xx.c
@@ -1307,7 +1307,7 @@ static int pxa2xx_spi_resume(struct devi
 }
 #endif
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
 static int pxa2xx_spi_runtime_suspend(struct device *dev)
 {
struct driver_data *drv_data = dev_get_drvdata(dev);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: 8250: add support for ACPI-probed serial port for X-Gene platform

[Feng Kan]

Enable APM X-Gene SoC serial port functionality when using ACPI table to
initialize serial port.

Signed-off-by: Feng Kan 
---
 drivers/tty/serial/8250/8250_dw.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index beea6ca..e8e6b20 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -310,10 +310,20 @@ static int dw8250_probe_of(struct uart_port *p,
 static int dw8250_probe_acpi(struct uart_8250_port *up,
 struct dw8250_data *data)
 {
+   const struct acpi_device_id *id;
struct uart_port *p = >port;
 
dw8250_setup_port(up);
 
+   id = acpi_match_device(p->dev->driver->acpi_match_table, p->dev);
+   if (!id)
+   return -ENODEV;
+
+   if (!p->uartclk)
+   if (device_property_read_u32(p->dev, "clock-frequency",
+>uartclk))
+   return -EINVAL;
+
p->iotype = UPIO_MEM32;
p->serial_in = dw8250_serial_in32;
p->serial_out = dw8250_serial_out32;
@@ -536,6 +546,7 @@ static const struct acpi_device_id dw8250_acpi_match[] = {
{ "INT3435", 0 },
{ "80860F0A", 0 },
{ "8086228A", 0 },
+   { "APMC0D08", 0},
{ },
 };
 MODULE_DEVICE_TABLE(acpi, dw8250_acpi_match);
-- 
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 v3 2/2] staging: media: lirc: lirc_zilog.c: keep consistency in dev functions

[Mauro Carvalho Chehab]

Em Fri, 05 Dec 2014 12:35:25 +
Luis de Bethencourt  escreveu:

> On 5 December 2014 at 12:28, Dan Carpenter  wrote:
> 
> > On Thu, Dec 04, 2014 at 10:35:24PM +, Luis de Bethencourt wrote:
> > > The previous patch switched some dev functions to move the string to a
> > second
> > > line. Doing this for all similar functions because it makes the driver
> > easier
> > > to read if all similar lines use the same criteria.
> > >
> > > Signed-off-by: Luis de Bethencourt 
> > > ---
> > >  drivers/staging/media/lirc/lirc_zilog.c | 155
> > +---
> > >  1 file changed, 102 insertions(+), 53 deletions(-)
> > >
> > > diff --git a/drivers/staging/media/lirc/lirc_zilog.c
> > b/drivers/staging/media/lirc/lirc_zilog.c
> > > index 8814a7e..af46827 100644
> > > --- a/drivers/staging/media/lirc/lirc_zilog.c
> > > +++ b/drivers/staging/media/lirc/lirc_zilog.c
> > > @@ -322,7 +322,8 @@ static int add_to_buf(struct IR *ir)
> > >   struct IR_tx *tx;
> > >
> > >   if (lirc_buffer_full(rbuf)) {
> > > - dev_dbg(ir->l.dev, "buffer overflow\n");
> > > + dev_dbg(ir->l.dev,
> > > + "buffer overflow\n");
> >
> > No.  Don't do this.  It's better if it is on one line.
> >
> > regards,
> > dan carpenter
> >
> >
> I was following Mauro's suggestions. As replied to the previous version of
> the patch.
> 
> I agree that in short uses of dev_dbg it adds unnecessary lines and
> vertical length to the file.

In the specific case that Dan pointed, the entire statement fits 
on 80 cols. We only add vertical alignments when it doesn't fit on
80 columns.

> 
> Thanks for looking at my patch :)
> 
> Luis


-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: Cygnus: add GPIO driver

[Joe Perches]

On Fri, 2014-12-05 at 16:40 -0800, Ray Jui wrote:
> This GPIO driver supports all 3 GPIO controllers in the Broadcom Cygnus
> SoC. The 3 GPIO controllers are 1) the ASIU GPIO controller
> ("brcm,cygnus-asiu-gpio"), 2) the chipCommonG GPIO controller
> ("brcm,cygnus-ccm-gpio"), and 3) the ALWAYS-ON GPIO controller
> ("brcm,cygnus-crmu-gpio")

trivia:

> diff --git a/drivers/gpio/gpio-bcm-cygnus.c b/drivers/gpio/gpio-bcm-cygnus.c

> +static inline struct bcm_cygnus_gpio *to_bcm_cygnus_gpio(
> + struct gpio_chip *gc)
> +{
> + return container_of(gc, struct bcm_cygnus_gpio, gc);
> +}

Probably all of these inlines can just be static.

The compiler does a pretty good job these days
of inlining where appropriate.


> +static void bcm_cygnus_gpio_irq_handler(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct bcm_cygnus_gpio *cygnus_gpio;
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + int i, bit;
> +
> + chained_irq_enter(chip, desc);
> +
> + cygnus_gpio = irq_get_handler_data(irq);
> +
> + /* go through the entire GPIO banks and handle all interrupts */
> + for (i = 0; i < cygnus_gpio->num_banks; i++) {
> + unsigned long val = readl(cygnus_gpio->base +
> + (i * GPIO_BANK_SIZE) +
> + CYGNUS_GPIO_INT_MSTAT_OFFSET);
> + if (val) {

This if (val) and indentation isn't really necessary

> + for_each_set_bit(bit, , 32) {

for_each_set_bit will effectively do the if above.

32 bit only code?
otherwise isn't this endian unsafe?

> + unsigned pin = NGPIOS_PER_BANK * i + bit;
> + int child_irq = bcm_cygnus_gpio_to_irq(
> + _gpio->gc, pin);
> +
> + /*
> +  * Clear the interrupt before invoking the
> +  * handler, so we do not leave any window
> +  */
> + writel(1 << bit,
> + cygnus_gpio->base +
> + (i * GPIO_BANK_SIZE) +
> + CYGNUS_GPIO_INT_CLR_OFFSET);
> +
> + generic_handle_irq(child_irq);
> + }
> +
> + }
> + }
> +
> + chained_irq_exit(chip, desc);
> +}
> +
> +static void bcm_cygnus_gpio_irq_ack(struct irq_data *d)
> +{
> + struct bcm_cygnus_gpio *cygnus_gpio = irq_data_get_irq_chip_data(d);
> + unsigned gpio = d->hwirq;
> + unsigned int offset, shift;
> + u32 val;
> +
> + offset = __gpio_reg_offset(cygnus_gpio, gpio) +
> + CYGNUS_GPIO_INT_CLR_OFFSET;
> + shift = __gpio_bitpos(cygnus_gpio, gpio);
> +
> + val = 1 << shift;
> + writel(val, cygnus_gpio->base + offset);
> +
> + dev_dbg(cygnus_gpio->dev, "gpio:%u offset:0x%04x shift:%u\n", gpio,
> + offset, shift);
> +}

> +static struct irq_chip bcm_cygnus_gpio_irq_chip = {
> + .name = "bcm-cygnus-gpio",
> + .irq_ack = bcm_cygnus_gpio_irq_ack,
> + .irq_mask = bcm_cygnus_gpio_irq_mask,
> + .irq_unmask = bcm_cygnus_gpio_irq_unmask,
> + .irq_set_type = bcm_cygnus_gpio_irq_set_type,
> +};

const?

> +static struct irq_domain_ops bcm_cygnus_irq_ops = {
> + .map = bcm_cygnus_gpio_irq_map,
> + .unmap = bcm_cygnus_gpio_irq_unmap,
> + .xlate = irq_domain_xlate_twocell,
> +};

const here too?

> +#ifdef CONFIG_OF_GPIO
> +static void bcm_cygnus_gpio_set_pull(struct bcm_cygnus_gpio *cygnus_gpio,
> + unsigned gpio, enum gpio_pull pull)
> +{
> + unsigned int offset, shift;
> + u32 val, up;

bool up; ?

> + unsigned long flags;
> +
> + switch (pull) {
> + case GPIO_PULL_NONE:
> + return;
> + case GPIO_PULL_UP:
> + up = 1;
> + break;
> + case GPIO_PULL_DOWN:
> + up = 0;
> + break;
> + case GPIO_PULL_INVALID:
> + default:
> + return;
> + }

Maybe more sensible to group GPIO_PULL_NONE with GPIO_PULL_INVALID


> +static int bcm_cygnus_gpio_probe(struct platform_device *pdev)
> +{
[]
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(>dev, "unable to get I/O resource");

missing newline


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH] VERIFY_OCTAL_PERMISSIONS: Move to where it belongs

[Andrew Morton]

On 5 Dec 2014 20:18:02 -0500 "George Spelvin"  wrote:

> > VERIFY_OCTAL_PERMISSIONS() sticks out like a sore thumb in kernel.h. 
> > How about we move it into sysfs.h?
> 
> Something like this, you mean?

Kinda.

> The  in moduleparam.h is needed for one function
> prototype that passes s16 parameters.  My first reaction is
> to wonder if that can be gotten rid of, too.
> 
> -

This shouldn't be here because "^---" is considered "end of changelog".

> It's the only user of  in kernel.h, so that reduces
> the compile-time cost of #include 
> 
> One necessary consequent change in .
>
> Suggested-by: Andrew Morton 
> Signed-off-by: George Spelvin 
>
> ...
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 3d770f55..07080aa2 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -804,14 +804,4 @@ static inline void ftrace_dump(enum ftrace_dump_mode 
> oops_dump_mode) { }
>  # define REBUILD_DUE_TO_FTRACE_MCOUNT_RECORD
>  #endif
>  
> -/* Permissions on a sysfs file: you didn't miss the 0 prefix did you? */
> -#define VERIFY_OCTAL_PERMISSIONS(perms)  
> \
> - (BUILD_BUG_ON_ZERO((perms) < 0) +   \
> -  BUILD_BUG_ON_ZERO((perms) > 0777) +\
> -  /* User perms >= group perms >= other perms */ \
> -  BUILD_BUG_ON_ZERO(((perms) >> 6) < (((perms) >> 3) & 7)) + \
> -  BUILD_BUG_ON_ZEROperms) >> 3) & 7) < ((perms) & 7)) +  \
> -  /* Other writable?  Generally considered a bad idea. */\
> -  BUILD_BUG_ON_ZERO((perms) & 2) +   \
> -  (perms))
>  #endif
> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> index f97d0dbb..9f213542 100644
> --- a/include/linux/sysfs.h
> +++ b/include/linux/sysfs.h
> @@ -70,6 +70,17 @@ struct attribute_group {
>   * for examples..
>   */
>  
> +/* Permissions on a sysfs file: you didn't miss the 0 prefix did you? */
> +#define VERIFY_OCTAL_PERMISSIONS(perms)  
> \
> + (BUILD_BUG_ON_ZERO((perms) < 0) +   \
> +  BUILD_BUG_ON_ZERO((perms) > 0777) +\
> +  /* User perms >= group perms >= other perms */ \
> +  BUILD_BUG_ON_ZERO(((perms) >> 6) < (((perms) >> 3) & 7)) + \
> +  BUILD_BUG_ON_ZEROperms) >> 3) & 7) < ((perms) & 7)) +  \
> +  /* Other writable?  Generally considered a bad idea. */\
> +  BUILD_BUG_ON_ZERO((perms) & 2) +   \
> +  (perms))
> +

Let's include bug.h into sysfs.h.

>  #define __ATTR(_name, _mode, _show, _store) {
> \
>   .attr = {.name = __stringify(_name),\
>.mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index 1c9effa2..974097df 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -1,9 +1,9 @@
>  #ifndef _LINUX_MODULE_PARAMS_H
>  #define _LINUX_MODULE_PARAMS_H
>  /* (C) Copyright 2001, 2002 Rusty Russell IBM Corporation */
> -#include 
>  #include 
> -#include 
> +#include 
> +#include 

Removing the kernel.h inclusion is good, but risky.  Are you sure
there's nothing in moduleparam.h which uses kernel.h things?


>  /* You can override this manually, but generally this should match the
> module name. */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH] VERIFY_OCTAL_PERMISSIONS: Move to where it belongs

[George Spelvin]

> VERIFY_OCTAL_PERMISSIONS() sticks out like a sore thumb in kernel.h. 
> How about we move it into sysfs.h?

Something like this, you mean?

The  in moduleparam.h is needed for one function
prototype that passes s16 parameters.  My first reaction is
to wonder if that can be gotten rid of, too.

-
It's the only user of  in kernel.h, so that reduces
the compile-time cost of #include 

One necessary consequent change in .

Suggested-by: Andrew Morton 
Signed-off-by: George Spelvin 
---
 include/linux/kernel.h  | 10 --
 include/linux/sysfs.h   | 11 +++
 include/linux/moduleparam.h |  4 ++--
 3 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3d770f55..07080aa2 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -804,14 +804,4 @@ static inline void ftrace_dump(enum ftrace_dump_mode 
oops_dump_mode) { }
 # define REBUILD_DUE_TO_FTRACE_MCOUNT_RECORD
 #endif
 
-/* Permissions on a sysfs file: you didn't miss the 0 prefix did you? */
-#define VERIFY_OCTAL_PERMISSIONS(perms)
\
-   (BUILD_BUG_ON_ZERO((perms) < 0) +   \
-BUILD_BUG_ON_ZERO((perms) > 0777) +\
-/* User perms >= group perms >= other perms */ \
-BUILD_BUG_ON_ZERO(((perms) >> 6) < (((perms) >> 3) & 7)) + \
-BUILD_BUG_ON_ZEROperms) >> 3) & 7) < ((perms) & 7)) +  \
-/* Other writable?  Generally considered a bad idea. */\
-BUILD_BUG_ON_ZERO((perms) & 2) +   \
-(perms))
 #endif
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index f97d0dbb..9f213542 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -70,6 +70,17 @@ struct attribute_group {
  * for examples..
  */
 
+/* Permissions on a sysfs file: you didn't miss the 0 prefix did you? */
+#define VERIFY_OCTAL_PERMISSIONS(perms)
\
+   (BUILD_BUG_ON_ZERO((perms) < 0) +   \
+BUILD_BUG_ON_ZERO((perms) > 0777) +\
+/* User perms >= group perms >= other perms */ \
+BUILD_BUG_ON_ZERO(((perms) >> 6) < (((perms) >> 3) & 7)) + \
+BUILD_BUG_ON_ZEROperms) >> 3) & 7) < ((perms) & 7)) +  \
+/* Other writable?  Generally considered a bad idea. */\
+BUILD_BUG_ON_ZERO((perms) & 2) +   \
+(perms))
+
 #define __ATTR(_name, _mode, _show, _store) {  \
.attr = {.name = __stringify(_name),\
 .mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 1c9effa2..974097df 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -1,9 +1,9 @@
 #ifndef _LINUX_MODULE_PARAMS_H
 #define _LINUX_MODULE_PARAMS_H
 /* (C) Copyright 2001, 2002 Rusty Russell IBM Corporation */
-#include 
 #include 
-#include 
+#include 
+#include 
 
 /* You can override this manually, but generally this should match the
module name. */
-- 
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH V2 0/4] Reducing parameters of alloc_pages* family of functions

[Linus Torvalds]

On Fri, Dec 5, 2014 at 11:59 AM, Vlastimil Babka  wrote:
> Hey all,
>
> this is a V2 of attempting something that has been discussed when Minchan
> proposed to expand the x86 kernel stack [1], namely the reduction of huge
> number of parameters that the alloc_pages* family and get_page_from_freelist()
> functions have.

So I generally like this, but looking at that "struct alloc_context",
one member kind of stands out: the "order" parameter doesn't fit in
with all the other members.

Most everything else is describing where or what kind of pages to work
with. The "order" in contrast, really is separate.

So conceptually, my reaction is that it looks like a good cleanup even
aside from the code/stack size reduction, but that the alloc_context
definition is a bit odd.

Quite frankly, I think the :"order" really fits much more closely with
"alloc_flags", not with the alloc_context. Because like alloc_flags,.
it really describes how we need to allocate things within the context,
I'd argue.

In fact, I think that the order could actually be packed with the
alloc_flags in a single register, even on 32-bit (using a single-word
structure, perhaps). If we really care about number of parameters.

I'd rather go for "makes conceptual sense" over "packs order in
because it kind of works" and we don't modify it".

Hmm?

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

[PATCH 3/5] ARM: mach-bcm: Enable GPIO support for Cygnus

[Ray Jui]

Enable GPIO driver for Broadcom Cygnus SoC by selecting GPIO_BCM_CYGNUS

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/mach-bcm/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index aaeec78..5066d5d 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -29,6 +29,7 @@ config ARCH_BCM_IPROC
 config ARCH_BCM_CYGNUS
bool "Broadcom Cygnus Support" if ARCH_MULTI_V7
select ARCH_BCM_IPROC
+   select GPIO_BCM_CYGNUS
help
  Enable support for the Cygnus family,
  which includes the following variants:
-- 
1.7.9.5

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

[PATCH 2/5] gpio: Cygnus: add GPIO driver

[Ray Jui]

This GPIO driver supports all 3 GPIO controllers in the Broadcom Cygnus
SoC. The 3 GPIO controllers are 1) the ASIU GPIO controller
("brcm,cygnus-asiu-gpio"), 2) the chipCommonG GPIO controller
("brcm,cygnus-ccm-gpio"), and 3) the ALWAYS-ON GPIO controller
("brcm,cygnus-crmu-gpio")

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/gpio/Kconfig   |   11 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-bcm-cygnus.c |  719 
 3 files changed, 731 insertions(+)
 create mode 100644 drivers/gpio/gpio-bcm-cygnus.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 633ec21..3e3b0342 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -126,6 +126,17 @@ config GPIO_74XX_MMIO
8 bits: 74244 (Input), 74273 (Output)
16 bits:741624 (Input), 7416374 (Output)
 
+config GPIO_BCM_CYGNUS
+   bool "Broadcom Cygnus GPIO support"
+   depends on ARCH_BCM_CYGNUS && OF_GPIO
+   help
+ Say yes here to turn on GPIO support for Broadcom Cygnus SoC
+
+ The Broadcom Cygnus SoC has 3 GPIO controllers including the ASIU
+ GPIO controller (ASIU), the chipCommonG GPIO controller (CCM), and
+ the always-ON GPIO controller (CRMU). All 3 GPIO controllers are
+ supported by this driver
+
 config GPIO_CLPS711X
tristate "CLPS711X GPIO support"
depends on ARCH_CLPS711X || COMPILE_TEST
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 81755f1..31eb7e0 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_GPIO_ADP5520)+= gpio-adp5520.o
 obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
 obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
 obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
+obj-$(CONFIG_GPIO_BCM_CYGNUS)  += gpio-bcm-cygnus.o
 obj-$(CONFIG_GPIO_BCM_KONA)+= gpio-bcm-kona.o
 obj-$(CONFIG_GPIO_BT8XX)   += gpio-bt8xx.o
 obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
diff --git a/drivers/gpio/gpio-bcm-cygnus.c b/drivers/gpio/gpio-bcm-cygnus.c
new file mode 100644
index 000..1549ea8
--- /dev/null
+++ b/drivers/gpio/gpio-bcm-cygnus.c
@@ -0,0 +1,719 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CYGNUS_GPIO_DATA_IN_OFFSET   0x00
+#define CYGNUS_GPIO_DATA_OUT_OFFSET  0x04
+#define CYGNUS_GPIO_OUT_EN_OFFSET0x08
+#define CYGNUS_GPIO_IN_TYPE_OFFSET   0x0c
+#define CYGNUS_GPIO_INT_DE_OFFSET0x10
+#define CYGNUS_GPIO_INT_EDGE_OFFSET  0x14
+#define CYGNUS_GPIO_INT_MSK_OFFSET   0x18
+#define CYGNUS_GPIO_INT_STAT_OFFSET  0x1c
+#define CYGNUS_GPIO_INT_MSTAT_OFFSET 0x20
+#define CYGNUS_GPIO_INT_CLR_OFFSET   0x24
+#define CYGNUS_GPIO_PAD_RES_OFFSET   0x34
+#define CYGNUS_GPIO_RES_EN_OFFSET0x38
+
+/* drive strength control for ASIU GPIO */
+#define CYGNUS_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
+
+/* drive strength control for CCM GPIO */
+#define CYGNUS_GPIO_CCM_DRV0_CTRL_OFFSET  0x00
+
+#define GPIO_BANK_SIZE 0x200
+#define NGPIOS_PER_BANK 32
+#define GPIO_BIT(pin) ((pin) % NGPIOS_PER_BANK)
+#define GPIO_BANK(pin) ((pin) / NGPIOS_PER_BANK)
+
+#define GPIO_FLAG_BIT_MASK   0x
+#define GPIO_PULL_BIT_SHIFT  16
+#define GPIO_PULL_BIT_MASK   0x3
+
+#define GPIO_DRV_STRENGTH_BIT_SHIFT  20
+#define GPIO_DRV_STRENGTH_BITS   3
+#define GPIO_DRV_STRENGTH_BIT_MASK   ((1 << GPIO_DRV_STRENGTH_BITS) - 1)
+
+/*
+ * For GPIO internal pull up/down registers
+ */
+enum gpio_pull {
+   GPIO_PULL_NONE = 0,
+   GPIO_PULL_UP,
+   GPIO_PULL_DOWN,
+   GPIO_PULL_INVALID,
+};
+
+/*
+ * GPIO drive strength
+ */
+enum gpio_drv_strength {
+   GPIO_DRV_STRENGTH_2MA = 0,
+   GPIO_DRV_STRENGTH_4MA,
+   GPIO_DRV_STRENGTH_6MA,
+   GPIO_DRV_STRENGTH_8MA,
+   GPIO_DRV_STRENGTH_10MA,
+   GPIO_DRV_STRENGTH_12MA,
+   GPIO_DRV_STRENGTH_14MA,
+   GPIO_DRV_STRENGTH_16MA,
+   GPIO_DRV_STRENGTH_INVALID,
+};
+
+struct bcm_cygnus_gpio {
+   struct device *dev;
+   void __iomem *base;
+   void __iomem *io_ctrl;
+   spinlock_t lock;
+   struct gpio_chip gc;
+   unsigned num_banks;
+   int irq;
+   struct irq_domain *irq_domain;
+};
+
+static unsigned int gpio_base_index;
+
+static inline struct bcm_cygnus_gpio *to_bcm_cygnus_gpio(
+   struct gpio_chip *gc)
+{
+   return container_of(gc, struct bcm_cygnus_gpio, gc);

[PATCH 5/5] MAINTAINERS: Entry for Cygnus GPIO driver

[Ray Jui]

Signed-off-by: Ray Jui 
---
 MAINTAINERS |7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7b712d8..5d67204 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2174,6 +2174,13 @@ N:   bcm9583*
 N: bcm583*
 N: bcm113*
 
+BROADCOM CYGNUS GPIO DRIVER
+M: Ray Jui 
+L: bcm-kernel-feedback-l...@broadcom.com
+S: Supported
+F: drivers/gpio/gpio-bcm-cygnus.c
+F: Documentation/devicetree/bindings/gpio/brcm,cygnus-gpio.txt
+
 BROADCOM KONA GPIO DRIVER
 M: Ray Jui 
 L: bcm-kernel-feedback-l...@broadcom.com
-- 
1.7.9.5

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

[PATCH 4/5] ARM: dts: enable GPIO for Broadcom Cygnus

[Ray Jui]

This enables all 3 GPIO controllers including the ASIU GPIO, the
chipcommonG GPIO, and the ALWAYS-ON GPIO, for Broadcom Cygnus SoC

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi |   30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5126f9e..c7587c1 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -54,6 +54,36 @@
 
/include/ "bcm-cygnus-clock.dtsi"
 
+   gpio_ccm: gpio@1800a000 {
+   compatible = "brcm,cygnus-ccm-gpio";
+   reg = <0x1800a000 0x50>,
+   <0x0301d164 0x20>;
+   ngpios = <24>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   interrupts = ;
+   interrupt-controller;
+   };
+
+   gpio_asiu: gpio@180a5000 {
+   compatible = "brcm,cygnus-asiu-gpio";
+   reg = <0x180a5000 0x668>;
+   ngpios = <122>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   interrupt-controller;
+   interrupts = ;
+   };
+
+   gpio_crmu: gpio@03024800 {
+   compatible = "brcm,cygnus-crmu-gpio";
+   reg = <0x03024800 0x50>;
+   ngpios = <6>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   no-interrupt;
+   };
+
amba {
#address-cells = <1>;
#size-cells = <1>;
-- 
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 1/5] gpio: Cygnus: define Broadcom Cygnus GPIO binding

[Ray Jui]

Document the GPIO device tree binding for Broadcom Cygnus SoC

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../devicetree/bindings/gpio/brcm,cygnus-gpio.txt  |   85 
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/brcm,cygnus-gpio.txt

diff --git a/Documentation/devicetree/bindings/gpio/brcm,cygnus-gpio.txt 
b/Documentation/devicetree/bindings/gpio/brcm,cygnus-gpio.txt
new file mode 100644
index 000..24a1513
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/brcm,cygnus-gpio.txt
@@ -0,0 +1,85 @@
+Broadcom Cygnus GPIO Controller
+
+Required properties:
+
+- compatible:
+Currently supported Cygnus GPIO controllers include:
+"brcm,cygnus-ccm-gpio": ChipcommonG GPIO controller
+"brcm,cygnus-asiu-gpio": ASIU GPIO controller
+"brcm,cygnus-crmu-gpio": CRMU GPIO controller
+
+- reg:
+Define the base and range of the I/O address space that contain the Cygnus
+GPIO controller registers
+
+- ngpios:
+Total number of GPIOs the controller provides
+
+- #gpio-cells:
+Must be two. The first cell is the GPIO pin number (within the
+controller's domain) and the second cell is used for the following:
+bit[0]: polarity (0 for normal and 1 for inverted)
+bit[18:16]: internal pull up/down: 0 - pull up/down disabled
+   1 - pull up enabled
+   2 - pull down enabled
+bit[22:20]: drive strength: 0 - 2 mA
+1 - 4 mA
+2 - 6 mA
+3 - 8 mA
+4 - 10 mA
+5 - 12 mA
+6 - 14 mA
+7 - 16 mA
+
+- gpio-controller:
+Specifies that the node is a GPIO controller
+
+Optional properties:
+
+- interrupt-controller:
+Specifies that the node is an interrupt controller. Not all Cygnus GPIO
+interfaces support interrupt, e.g., the CRMU GPIO controller does not have its
+interrupt routed to the main processor's GIC
+
+- interrupts:
+The interrupt outputs from the GPIO controller.
+
+- no-interrupt:
+Specifies that the GPIO interface does not support interrupt
+
+Example:
+   gpio_asiu: gpio@180a5000 {
+   compatible = "brcm,cygnus-asiu-gpio";
+   reg = <0x180a5000 0x668>;
+   ngpios = <122>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   interrupt-controller;
+   interrupts = ;
+   };
+
+   gpio_crmu: gpio@03024800 {
+   compatible = "brcm,cygnus-crmu-gpio";
+   reg = <0x03024800 0x50>;
+   ngpios = <6>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   no-interrupt;
+   };
+
+   /*
+* Touchscreen that uses the ASIU GPIO 100, with internal pull-up
+* enabled
+*/
+   tsc {
+   ...
+   ...
+   gpio-event = <_asiu 100 0x1>;
+   };
+
+   /* Bluetooth that uses the CRMU GPIO 2, with polarity inverted */
+   bluetooth {
+   ...
+   ...
+   bcm,rfkill-bank-sel = <_crmu 2 1>
+   }
-- 
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 0/5] Add gpio support to Broadcom Cygnus SoC

[Ray Jui]

This patchset contains the initial GPIO support for the Broadcom Cygnus SoC.
Cygnus has 3 GPIO controllers: 1) the ASIU GPIO; 2) the chipCommonG GPIO;
and 3) the ALWAYS-ON GPIO. All 3 types of GPIO controllers are supported by
the same Cygnus GPIO driver

Ray Jui (5):
  gpio: Cygnus: define Broadcom Cygnus GPIO binding
  gpio: Cygnus: add GPIO driver
  ARM: mach-bcm: Enable GPIO support for Cygnus
  ARM: dts: enable GPIO for Broadcom Cygnus
  MAINTAINERS: Entry for Cygnus GPIO driver

 .../devicetree/bindings/gpio/brcm,cygnus-gpio.txt  |   85 +++
 MAINTAINERS|7 +
 arch/arm/boot/dts/bcm-cygnus.dtsi  |   30 +
 arch/arm/mach-bcm/Kconfig  |1 +
 drivers/gpio/Kconfig   |   11 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-bcm-cygnus.c |  719 
 7 files changed, 854 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/brcm,cygnus-gpio.txt
 create mode 100644 drivers/gpio/gpio-bcm-cygnus.c

-- 
1.7.9.5

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

Re: [PATCH] VERIFY_OCTAL_PERMISSIONS needs

[Andrew Morton]

On 5 Dec 2014 19:07:59 -0500 "George Spelvin"  wrote:

> It is possible to include  and try to use
> VERIFY_OCTAL_PERMISSIONS, then puke because BUILD_BUG_ON_ZERO
> isn't defined.
> 
> I hit this via:
> 
> #include 
> module_param(verbose, bool, 0);
> 
> IMHO, except in documented special cases, header files should
> #include their own macros' dependencies.
> 
> Signed-off-by: George Spelvin 
> ---
>  include/linux/kernel.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> I'm not quite sure who to send this via.  Rusty, you touched
> VERIFY_OCTAL_PERMISSIONS last.  Should I send this via you, or collect
> acks and include it in the patch series I'm working on that wants this?
> 
> The workaround is easy enough, but I'd rather fix it than let cruft
> like this accumulate.
> 
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 3d770f55..afb81c1a 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 

Absolutely everything includes kernel.h so this might have measurable
build-time impact.

VERIFY_OCTAL_PERMISSIONS() sticks out like a sore thumb in kernel.h. 
How about we move it into sysfs.h?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] VERIFY_OCTAL_PERMISSIONS needs

[Randy Dunlap]

On 12/05/14 16:07, George Spelvin wrote:
> It is possible to include  and try to use
> VERIFY_OCTAL_PERMISSIONS, then puke because BUILD_BUG_ON_ZERO
> isn't defined.
> 
> I hit this via:
> 
> #include 
> module_param(verbose, bool, 0);
> 
> IMHO, except in documented special cases, header files should
> #include their own macros' dependencies.

Yes.  Documentation/SubmitChecklist #1:

1: If you use a facility then #include the file that defines/declares
   that facility.  Don't depend on other header files pulling in ones
   that you use.


Thanks.

> Signed-off-by: George Spelvin 
> ---
>  include/linux/kernel.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> I'm not quite sure who to send this via.  Rusty, you touched
> VERIFY_OCTAL_PERMISSIONS last.  Should I send this via you, or collect
> acks and include it in the patch series I'm working on that wants this?
> 
> The workaround is easy enough, but I'd rather fix it than let cruft
> like this accumulate.
> 
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 3d770f55..afb81c1a 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> 


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

[George Spelvin]

It is possible to include  and try to use
VERIFY_OCTAL_PERMISSIONS, then puke because BUILD_BUG_ON_ZERO
isn't defined.

I hit this via:

#include 
module_param(verbose, bool, 0);

IMHO, except in documented special cases, header files should
#include their own macros' dependencies.

Signed-off-by: George Spelvin 
---
 include/linux/kernel.h | 1 +
 1 file changed, 1 insertion(+)

I'm not quite sure who to send this via.  Rusty, you touched
VERIFY_OCTAL_PERMISSIONS last.  Should I send this via you, or collect
acks and include it in the patch series I'm working on that wants this?

The workaround is easy enough, but I'd rather fix it than let cruft
like this accumulate.

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3d770f55..afb81c1a 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-- 
2.1.3

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

[PATCH 2/2] MPILIB: Deobfuscate mpi_cmp

[Rasmus Villemoes]

The condition preceding 'return 1;' makes my head hurt. At this point,
we know that u and v have the same sign; if they are negative, they
compare opposite to how their absolute values compare (which
mpihelp_cmp found for us), otherwise cmp itself is the
answer. Negating cmp is ok since mpihelp_cmp returns {-1,0,1};
-INT_MIN==INT_MIN won't bite us.

Signed-off-by: Rasmus Villemoes 
---
 lib/mpi/mpi-cmp.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/lib/mpi/mpi-cmp.c b/lib/mpi/mpi-cmp.c
index 3801694240d8..d25e9e96c310 100644
--- a/lib/mpi/mpi-cmp.c
+++ b/lib/mpi/mpi-cmp.c
@@ -61,10 +61,8 @@ int mpi_cmp(MPI u, MPI v)
if (!usize)
return 0;
cmp = mpihelp_cmp(u->d, v->d, usize);
-   if (!cmp)
-   return 0;
-   if ((cmp < 0 ? 1 : 0) == (u->sign ? 1 : 0))
-   return 1;
-   return -1;
+   if (u->sign)
+   return -cmp;
+   return cmp;
 }
 EXPORT_SYMBOL_GPL(mpi_cmp);
-- 
2.1.3

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

[PATCH 1/2] MPILIB: Fix comparison of negative MPIs

[Rasmus Villemoes]

If u and v both represent negative integers and their limb counts
happen to differ, mpi_cmp will always return a positive value - this
is obviously bogus. u is smaller than v if and only if it is larger in
absolute value.

Signed-off-by: Rasmus Villemoes 
---
 lib/mpi/mpi-cmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/mpi/mpi-cmp.c b/lib/mpi/mpi-cmp.c
index 1871e7b61ca0..3801694240d8 100644
--- a/lib/mpi/mpi-cmp.c
+++ b/lib/mpi/mpi-cmp.c
@@ -57,7 +57,7 @@ int mpi_cmp(MPI u, MPI v)
if (usize != vsize && !u->sign && !v->sign)
return usize - vsize;
if (usize != vsize && u->sign && v->sign)
-   return vsize + usize;
+   return vsize - usize;
if (!usize)
return 0;
cmp = mpihelp_cmp(u->d, v->d, usize);
-- 
2.1.3

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

Re: [PATCH v3] mmc: dw_mmc: add quirk for broken data transfer over scheme

[Alexandru Stan]

Seems like the BROKEN_DTO also affects EVENT_DATA_COMPLETE, sometimes we don't
see that (but we do see EVENT_XFER_COMPLETE), leave the state machine and never
come back to it to timeout. I have this happening on emmc specifically, haven't
seen it on sdmmc yet.

The fix is to also start the timer when we don't see a EVENT_DATA_COMPLETE.

More details for how I debugged this can be found at:
https://chromium-review.googlesource.com/#/c/233691/

In ~100 reboot tests I haven't seen any hangs, whereas before it was
hanging about 20% of the time.

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 50865e7..c678206 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1685,8 +1685,17 @@ static void dw_mci_tasklet_func(unsigned long priv)

case STATE_DATA_BUSY:
if (!test_and_clear_bit(EVENT_DATA_COMPLETE,
-   >pending_events))
+   >pending_events)) {
+   if (host->quirks & DW_MCI_QUIRK_BROKEN_DTO) {
+   drto_clks = mci_readl(host, TMOUT) >> 8;
+   drto_ms = DIV_ROUND_UP(drto_clks * 1000,
+  host->bus_hz);
+
+   mod_timer(>dto_timer, jiffies +
+   msecs_to_jiffies(drto_ms));
+   }
break;
+   }

host->data = NULL;
set_bit(EVENT_DATA_COMPLETE, >completed_events);
Alexandru Stan (amstan)


On Tue, Dec 2, 2014 at 9:08 PM, Doug Anderson  wrote:
> Addy,
>
> On Tue, Dec 2, 2014 at 7:16 PM, Addy Ke  wrote:
>> This patch add a new quirk to add a s/w timer to notify the driver
>> to terminate current transfer and report a data timeout to the core,
>> if DTO interrupt does NOT come within the given time.
>>
>> dw_mmc call mmc_request_done func to finish transfer depends on
>> DTO interrupt. If DTO interrupt does not come in sending data state,
>> the current transfer will be blocked.
>>
>> But this case really exists, when driver reads tuning data from
>> card on RK3288-pink2 board. I measured waveforms by oscilloscope
>> and found that card clock was always on and data lines were always
>> holded high level in sending data state.
>>
>> We got the reply from synopsys:
>> There are two counters but both use the same value of [31:8] bits.
>> Data timeout counter doesn't wait for stop clock and you should get
>> DRTO even when the clock is not stopped.
>> Host Starvation timeout counter is triggered with stop clock condition.
>>
>> This means that host should get DRTO and DTO interrupt.
>>
>> But we really don't get any data-related interrupt in RK3X SoCs.
>> And driver can't get data transfer state, it can do nothing but wait for.
>>
>> We don't know why we have this problem, but we need it to fix this problem 
>> now.
>> And I will post a follow up change when we find the root cause.
>>
>> Signed-off-by: Addy Ke 
>> ---
>> Changes in v2:
>> - fix some typo.
>> - remove extra timeout value (250ms).
>> - remove dw_mci_dto_start_monitor func.
>> - use "broken-dto" for new quirk and change Subject for it.
>>
>> Changes in v3:
>> - Remove dts for broken-dto, just add this quirk in dw_mci_rockchip_init
>>
>>  drivers/mmc/host/dw_mmc-rockchip.c |  3 +++
>>  drivers/mmc/host/dw_mmc.c  | 41 
>> +-
>>  include/linux/mmc/dw_mmc.h |  5 +
>>  3 files changed, 48 insertions(+), 1 deletion(-)
>
> This seems reasonable to me.  I do hope that you can get to a root
> cause, but I don't think this is a terrible bit of code to carry.
> Obviously it's up to the folks who maintain dw_mmc and the mmc
> subsystem, but:
>
> Reviewed-by: Doug Anderson 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.17 012/122] x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

commit af726f21ed8af2cdaa4e93098dc211521218ae65 upstream.

There's nothing special enough about the espfix64 double fault fixup to
justify writing it in assembly.  Move it to C.

This also fixes a bug: if the double fault came from an IST stack, the
old asm code would return to a partially uninitialized stack frame.

Fixes: 3891a04aafd668686239349ea58f3314ea2af86b
Signed-off-by: Andy Lutomirski 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/entry_64.S |   34 ++
 arch/x86/kernel/traps.c|   24 
 2 files changed, 26 insertions(+), 32 deletions(-)

--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -841,6 +841,7 @@ ENTRY(native_iret)
jnz native_irq_return_ldt
 #endif
 
+.global native_irq_return_iret
 native_irq_return_iret:
iretq
_ASM_EXTABLE(native_irq_return_iret, bad_iret)
@@ -935,37 +936,6 @@ ENTRY(retint_kernel)
CFI_ENDPROC
 END(common_interrupt)
 
-   /*
-* If IRET takes a fault on the espfix stack, then we
-* end up promoting it to a doublefault.  In that case,
-* modify the stack to make it look like we just entered
-* the #GP handler from user space, similar to bad_iret.
-*/
-#ifdef CONFIG_X86_ESPFIX64
-   ALIGN
-__do_double_fault:
-   XCPT_FRAME 1 RDI+8
-   movq RSP(%rdi),%rax /* Trap on the espfix stack? */
-   sarq $PGDIR_SHIFT,%rax
-   cmpl $ESPFIX_PGD_ENTRY,%eax
-   jne do_double_fault /* No, just deliver the fault */
-   cmpl $__KERNEL_CS,CS(%rdi)
-   jne do_double_fault
-   movq RIP(%rdi),%rax
-   cmpq $native_irq_return_iret,%rax
-   jne do_double_fault /* This shouldn't happen... */
-   movq PER_CPU_VAR(kernel_stack),%rax
-   subq $(6*8-KERNEL_STACK_OFFSET),%rax/* Reset to original stack */
-   movq %rax,RSP(%rdi)
-   movq $0,(%rax)  /* Missing (lost) #GP error code */
-   movq $general_protection,RIP(%rdi)
-   retq
-   CFI_ENDPROC
-END(__do_double_fault)
-#else
-# define __do_double_fault do_double_fault
-#endif
-
 /*
  * APIC interrupts.
  */
@@ -1137,7 +1107,7 @@ idtentry overflow do_overflow has_error_
 idtentry bounds do_bounds has_error_code=0
 idtentry invalid_op do_invalid_op has_error_code=0
 idtentry device_not_available do_device_not_available has_error_code=0
-idtentry double_fault __do_double_fault has_error_code=1 paranoid=1
+idtentry double_fault do_double_fault has_error_code=1 paranoid=1
 idtentry coprocessor_segment_overrun do_coprocessor_segment_overrun 
has_error_code=0
 idtentry invalid_TSS do_invalid_TSS has_error_code=1
 idtentry segment_not_present do_segment_not_present has_error_code=1
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -259,6 +259,30 @@ dotraplinkage void do_double_fault(struc
static const char str[] = "double fault";
struct task_struct *tsk = current;
 
+#ifdef CONFIG_X86_ESPFIX64
+   extern unsigned char native_irq_return_iret[];
+
+   /*
+* If IRET takes a non-IST fault on the espfix64 stack, then we
+* end up promoting it to a doublefault.  In that case, modify
+* the stack to make it look like we just entered the #GP
+* handler from user space, similar to bad_iret.
+*/
+   if (((long)regs->sp >> PGDIR_SHIFT) == ESPFIX_PGD_ENTRY &&
+   regs->cs == __KERNEL_CS &&
+   regs->ip == (unsigned long)native_irq_return_iret)
+   {
+   struct pt_regs *normal_regs = task_pt_regs(current);
+
+   /* Fake a #GP(0) from userspace. */
+   memmove(_regs->ip, (void *)regs->sp, 5*8);
+   normal_regs->orig_ax = 0;  /* Missing (lost) #GP error code */
+   regs->ip = (unsigned long)general_protection;
+   regs->sp = (unsigned long)_regs->orig_ax;
+   return;
+   }
+#endif
+
exception_enter();
/* Return not checked because double check cannot be ignored */
notify_die(DIE_TRAP, str, regs, error_code, X86_TRAP_DF, SIGSEGV);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.17 013/122] x86_64, traps: Stop using IST for #SS

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

commit 6f442be2fb22be02cafa606f1769fa1e6f894441 upstream.

On a 32-bit kernel, this has no effect, since there are no IST stacks.

On a 64-bit kernel, #SS can only happen in user code, on a failed iret
to user space, a canonical violation on access via RSP or RBP, or a
genuine stack segment violation in 32-bit kernel code.  The first two
cases don't need IST, and the latter two cases are unlikely fatal bugs,
and promoting them to double faults would be fine.

This fixes a bug in which the espfix64 code mishandles a stack segment
violation.

This saves 4k of memory per CPU and a tiny bit of code.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/page_32_types.h |1 -
 arch/x86/include/asm/page_64_types.h |   11 +--
 arch/x86/include/asm/traps.h |1 +
 arch/x86/kernel/dumpstack_64.c   |1 -
 arch/x86/kernel/entry_64.S   |2 +-
 arch/x86/kernel/traps.c  |   18 +-
 6 files changed, 8 insertions(+), 26 deletions(-)

--- a/arch/x86/include/asm/page_32_types.h
+++ b/arch/x86/include/asm/page_32_types.h
@@ -20,7 +20,6 @@
 #define THREAD_SIZE_ORDER  1
 #define THREAD_SIZE(PAGE_SIZE << THREAD_SIZE_ORDER)
 
-#define STACKFAULT_STACK 0
 #define DOUBLEFAULT_STACK 1
 #define NMI_STACK 0
 #define DEBUG_STACK 0
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -14,12 +14,11 @@
 #define IRQ_STACK_ORDER 2
 #define IRQ_STACK_SIZE (PAGE_SIZE << IRQ_STACK_ORDER)
 
-#define STACKFAULT_STACK 1
-#define DOUBLEFAULT_STACK 2
-#define NMI_STACK 3
-#define DEBUG_STACK 4
-#define MCE_STACK 5
-#define N_EXCEPTION_STACKS 5  /* hw limit: 7 */
+#define DOUBLEFAULT_STACK 1
+#define NMI_STACK 2
+#define DEBUG_STACK 3
+#define MCE_STACK 4
+#define N_EXCEPTION_STACKS 4  /* hw limit: 7 */
 
 #define PUD_PAGE_SIZE  (_AC(1, UL) << PUD_SHIFT)
 #define PUD_PAGE_MASK  (~(PUD_PAGE_SIZE-1))
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -39,6 +39,7 @@ asmlinkage void simd_coprocessor_error(v
 
 #ifdef CONFIG_TRACING
 asmlinkage void trace_page_fault(void);
+#define trace_stack_segment stack_segment
 #define trace_divide_error divide_error
 #define trace_bounds bounds
 #define trace_invalid_op invalid_op
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -24,7 +24,6 @@ static char x86_stack_ids[][8] = {
[ DEBUG_STACK-1 ]   = "#DB",
[ NMI_STACK-1   ]   = "NMI",
[ DOUBLEFAULT_STACK-1   ]   = "#DF",
-   [ STACKFAULT_STACK-1]   = "#SS",
[ MCE_STACK-1   ]   = "#MC",
 #if DEBUG_STKSZ > EXCEPTION_STKSZ
[ N_EXCEPTION_STACKS ...
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1272,7 +1272,7 @@ apicinterrupt3 HYPERVISOR_CALLBACK_VECTO
 
 idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
 idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
-idtentry stack_segment do_stack_segment has_error_code=1 paranoid=1
+idtentry stack_segment do_stack_segment has_error_code=1
 #ifdef CONFIG_XEN
 idtentry xen_debug do_debug has_error_code=0
 idtentry xen_int3 do_int3 has_error_code=0
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -233,27 +233,11 @@ DO_ERROR(X86_TRAP_UD, SIGILL,  "inva
 DO_ERROR(X86_TRAP_OLD_MF, SIGFPE,  "coprocessor segment 
overrun",coprocessor_segment_overrun)
 DO_ERROR(X86_TRAP_TS, SIGSEGV, "invalid TSS",  invalid_TSS)
 DO_ERROR(X86_TRAP_NP, SIGBUS,  "segment not present",  
segment_not_present)
-#ifdef CONFIG_X86_32
 DO_ERROR(X86_TRAP_SS, SIGBUS,  "stack segment",stack_segment)
-#endif
 DO_ERROR(X86_TRAP_AC, SIGBUS,  "alignment check",  alignment_check)
 
 #ifdef CONFIG_X86_64
 /* Runs on IST stack */
-dotraplinkage void do_stack_segment(struct pt_regs *regs, long error_code)
-{
-   enum ctx_state prev_state;
-
-   prev_state = exception_enter();
-   if (notify_die(DIE_TRAP, "stack segment", regs, error_code,
-  X86_TRAP_SS, SIGBUS) != NOTIFY_STOP) {
-   preempt_conditional_sti(regs);
-   do_trap(X86_TRAP_SS, SIGBUS, "stack segment", regs, error_code, 
NULL);
-   preempt_conditional_cli(regs);
-   }
-   exception_exit(prev_state);
-}
-
 dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code)
 {
static const char str[] = "double fault";
@@ -802,7 +786,7 @@ void __init trap_init(void)
set_intr_gate(X86_TRAP_OLD_MF, coprocessor_segment_overrun);
set_intr_gate(X86_TRAP_TS, invalid_TSS);

[PATCH 3.17 019/122] sparc64: Fix constraints on swab helpers.

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 5a2b59d3993e8ca4f7788a48a23e5cb303f26954 ]

We are reading the memory location, so we have to have a memory
constraint in there purely for the sake of showing the data flow
to the compiler.

Reported-by: Martin K. Petersen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/sparc/include/uapi/asm/swab.h |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/arch/sparc/include/uapi/asm/swab.h
+++ b/arch/sparc/include/uapi/asm/swab.h
@@ -9,9 +9,9 @@ static inline __u16 __arch_swab16p(const
 {
__u16 ret;
 
-   __asm__ __volatile__ ("lduha [%1] %2, %0"
+   __asm__ __volatile__ ("lduha [%2] %3, %0"
  : "=r" (ret)
- : "r" (addr), "i" (ASI_PL));
+ : "m" (*addr), "r" (addr), "i" (ASI_PL));
return ret;
 }
 #define __arch_swab16p __arch_swab16p
@@ -20,9 +20,9 @@ static inline __u32 __arch_swab32p(const
 {
__u32 ret;
 
-   __asm__ __volatile__ ("lduwa [%1] %2, %0"
+   __asm__ __volatile__ ("lduwa [%2] %3, %0"
  : "=r" (ret)
- : "r" (addr), "i" (ASI_PL));
+ : "m" (*addr), "r" (addr), "i" (ASI_PL));
return ret;
 }
 #define __arch_swab32p __arch_swab32p
@@ -31,9 +31,9 @@ static inline __u64 __arch_swab64p(const
 {
__u64 ret;
 
-   __asm__ __volatile__ ("ldxa [%1] %2, %0"
+   __asm__ __volatile__ ("ldxa [%2] %3, %0"
  : "=r" (ret)
- : "r" (addr), "i" (ASI_PL));
+ : "m" (*addr), "r" (addr), "i" (ASI_PL));
return ret;
 }
 #define __arch_swab64p __arch_swab64p


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.17 015/122] x86: Require exact match for noxsave command line option

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Hansen 

commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3 upstream.

We have some very similarly named command-line options:

arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);

__setup() is designed to match options that take arguments, like
"foo=bar" where you would have:

__setup("foo", x86_foo_func...);

The problem is that "noxsave" actually _matches_ "noxsaves" in
the same way that "foo" matches "foo=bar".  If you boot an old
kernel that does not know about "noxsaves" with "noxsaves" on the
command line, it will interpret the argument as "noxsave", which
is not what you want at all.

This makes the "noxsave" handler only return success when it finds
an *exact* match.

[ tglx: We really need to make __setup() more robust. ]

Signed-off-by: Dave Hansen 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: x...@kernel.org
Link: http://lkml.kernel.org/r/2014220133.fe053...@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/cpu/common.c |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -146,6 +146,8 @@ EXPORT_PER_CPU_SYMBOL_GPL(gdt_page);
 
 static int __init x86_xsave_setup(char *s)
 {
+   if (strlen(s))
+   return 0;
setup_clear_cpu_cap(X86_FEATURE_XSAVE);
setup_clear_cpu_cap(X86_FEATURE_XSAVEOPT);
setup_clear_cpu_cap(X86_FEATURE_XSAVES);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.17 017/122] x86, kaslr: Handle Gold linker for finding bss/brk

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Kees Cook 

commit 70b61e362187b5fccac206506d402f3424e3e749 upstream.

When building with the Gold linker, the .bss and .brk areas of vmlinux
are shown as consecutive instead of having the same file offset. Allow
for either state, as long as things add up correctly.

Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
Reported-by: Markus Trippelsdorf 
Signed-off-by: Kees Cook 
Cc: Junjie Mao 
Link: http://lkml.kernel.org/r/20141118001604.ga25...@www.outflux.net
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/tools/calc_run_size.pl |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

--- a/arch/x86/tools/calc_run_size.pl
+++ b/arch/x86/tools/calc_run_size.pl
@@ -19,7 +19,16 @@ while (<>) {
if ($file_offset == 0) {
$file_offset = $offset;
} elsif ($file_offset != $offset) {
-   die ".bss and .brk lack common file offset\n";
+   # BFD linker shows the same file offset in ELF.
+   # Gold linker shows them as consecutive.
+   next if ($file_offset + $mem_size == $offset + $size);
+
+   printf STDERR "file_offset: 0x%lx\n", $file_offset;
+   printf STDERR "mem_size: 0x%lx\n", $mem_size;
+   printf STDERR "offset: 0x%lx\n", $offset;
+   printf STDERR "size: 0x%lx\n", $size;
+
+   die ".bss and .brk are non-contiguous\n";
}
}
 }


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

[PATCH 3.17 018/122] uprobes, x86: Fix _TIF_UPROBE vs _TIF_NOTIFY_RESUME

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

commit 82975bc6a6df743b9a01810fb32cb65d0ec5d60b upstream.

x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set but
not on non-paranoid returns.  I suspect that this is a mistake and that
the code only works because int3 is paranoid.

Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a workaround
for the x86 bug.  With that bug fixed, we can remove _TIF_NOTIFY_RESUME
from the uprobes code.

Reported-by: Oleg Nesterov 
Acked-by: Srikar Dronamraju 
Acked-by: Borislav Petkov 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/thread_info.h |2 +-
 kernel/events/uprobes.c|1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -141,7 +141,7 @@ struct thread_info {
 /* Only used for 64 bit */
 #define _TIF_DO_NOTIFY_MASK\
(_TIF_SIGPENDING | _TIF_MCE_NOTIFY | _TIF_NOTIFY_RESUME |   \
-_TIF_USER_RETURN_NOTIFY)
+_TIF_USER_RETURN_NOTIFY | _TIF_UPROBE)
 
 /* flags to check in __switch_to() */
 #define _TIF_WORK_CTXSW
\
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1640,7 +1640,6 @@ bool uprobe_deny_signal(void)
if (__fatal_signal_pending(t) || 
arch_uprobe_xol_was_trapped(t)) {
utask->state = UTASK_SSTEP_TRAPPED;
set_tsk_thread_flag(t, TIF_UPROBE);
-   set_tsk_thread_flag(t, TIF_NOTIFY_RESUME);
}
}
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.17 021/122] ipv4: Fix incorrect error code when adding an unreachable route

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Panu Matilainen 

[ Upstream commit 49dd18ba4615eaa72f15c9087dea1c2ab4744cf5 ]

Trying to add an unreachable route incorrectly returns -ESRCH if
if custom FIB rules are present:

[root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
RTNETLINK answers: Network is unreachable
[root@localhost ~]# ip rule add to 55.66.77.88 table 200
[root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
RTNETLINK answers: No such process
[root@localhost ~]#

Commit 83886b6b636173b206f475929e58fac75c6f2446 ("[NET]: Change "not found"
return value for rule lookup") changed fib_rules_lookup()
to use -ESRCH as a "not found" code internally, but for user space it
should be translated into -ENETUNREACH. Handle the translation centrally in
ipv4-specific fib_lookup(), leaving the DECnet case alone.

On a related note, commit b7a71b51ee37d919e4098cd961d59a883fd272d8
("ipv4: removed redundant conditional") removed a similar translation from
ip_route_input_slow() prematurely AIUI.

Fixes: b7a71b51ee37 ("ipv4: removed redundant conditional")
Signed-off-by: Panu Matilainen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv4/fib_rules.c |4 
 1 file changed, 4 insertions(+)

--- a/net/ipv4/fib_rules.c
+++ b/net/ipv4/fib_rules.c
@@ -62,6 +62,10 @@ int __fib_lookup(struct net *net, struct
else
res->tclassid = 0;
 #endif
+
+   if (err == -ESRCH)
+   err = -ENETUNREACH;
+
return err;
 }
 EXPORT_SYMBOL_GPL(__fib_lookup);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.17 002/122] MIPS: lib: memcpy: Restore NOP on delay slot before returning to caller

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Markos Chandras 

commit 51b1029d9966060c6ad02030e6f251425b4f06c1 upstream.

Commit cf62a8b8134dd3 ("MIPS: lib: memcpy: Use macro to build the
copy_user code") switched to a macro in order to build the memcpy
symbols in preparation for the EVA support. However, this commit
also removed the NOP instruction after the 'jr ra' when returning
back to the caller. This had no visible side-effects since the next
instruction was a load to the t0 register which was already in the
clobbered list, but it may have undesired effects in the future
if some other code is introduced in between the .Ldone and
the .Ll_exc_copy labels.

Signed-off-by: Markos Chandras 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8512/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/lib/memcpy.S |1 +
 1 file changed, 1 insertion(+)

--- a/arch/mips/lib/memcpy.S
+++ b/arch/mips/lib/memcpy.S
@@ -503,6 +503,7 @@
STOREB(t0, NBYTES-2(dst), .Ls_exc_p1\@)
 .Ldone\@:
jr  ra
+nop
.if __memcpy == 1
END(memcpy)
.set __memcpy, 0


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

[PATCH 3.17 020/122] inetdevice: fixed signed integer overflow

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Vincent BENAYOUN 

[ Upstream commit 84bc88688e3f6ef843aa8803dbcd90168bb89faf ]

There could be a signed overflow in the following code.

The expression, (32-logmask) is comprised between 0 and 31 included.
It may be equal to 31.
In such a case the left shift will produce a signed integer overflow.
According to the C99 Standard, this is an undefined behavior.
A simple fix is to replace the signed int 1 with the unsigned int 1U.

Signed-off-by: Vincent BENAYOUN 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 include/linux/inetdevice.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -242,7 +242,7 @@ static inline void in_dev_put(struct in_
 static __inline__ __be32 inet_make_mask(int logmask)
 {
if (logmask)
-   return htonl(~((1<<(32-logmask))-1));
+   return htonl(~((1U<<(32-logmask))-1));
return 0;
 }
 


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

[PATCH 3.17 001/122] MIPS: IP27: Fix __node_distances undefined error

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: James Cowgill 

commit 5829b0ecc584d15ae4eeabe69f2ab554bdec4689 upstream.

export the __node_distances symbol in the ip27 memory code to fix the
build error:

  Building modules, stage 2.
  MODPOST 311 modules
ERROR: "__node_distances" [drivers/block/nvme.ko] undefined!
scripts/Makefile.modpost:90: recipe for target '__modpost' failed

when building the kernel with:
 CONFIG_SGI_IP27=y
 CONFIG_BLK_DEV_NVME=m

Signed-off-by: James Cowgill 
Reviewed-by: James Hogan 
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/sgi-ip27/ip27-memory.c |1 +
 1 file changed, 1 insertion(+)

--- a/arch/mips/sgi-ip27/ip27-memory.c
+++ b/arch/mips/sgi-ip27/ip27-memory.c
@@ -107,6 +107,7 @@ static void router_recurse(klrou_t *rout
 }
 
 unsigned char __node_distances[MAX_COMPACT_NODES][MAX_COMPACT_NODES];
+EXPORT_SYMBOL(__node_distances);
 
 static int __init compute_node_distance(nasid_t nasid_a, nasid_t nasid_b)
 {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.17 022/122] ieee802154: fix error handling in ieee802154fake_probe()

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Alexey Khoroshilov 

[ Upstream commit 8c2dd54485ccee7fc4086611e188478584758c8d ]

In case of any failure ieee802154fake_probe() just calls unregister_netdev().
But it does not look safe to unregister netdevice before it was registered.

The patch implements straightforward resource deallocation in case of
failure in ieee802154fake_probe().

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

Signed-off-by: Alexey Khoroshilov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ieee802154/fakehard.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

--- a/drivers/net/ieee802154/fakehard.c
+++ b/drivers/net/ieee802154/fakehard.c
@@ -377,17 +377,20 @@ static int ieee802154fake_probe(struct p
 
err = wpan_phy_register(phy);
if (err)
-   goto out;
+   goto err_phy_reg;
 
err = register_netdev(dev);
-   if (err < 0)
-   goto out;
+   if (err)
+   goto err_netdev_reg;
 
dev_info(>dev, "Added ieee802154 HardMAC hardware\n");
return 0;
 
-out:
-   unregister_netdev(dev);
+err_netdev_reg:
+   wpan_phy_unregister(phy);
+err_phy_reg:
+   free_netdev(dev);
+   wpan_phy_free(phy);
return err;
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.17 024/122] bonding: fix curr_active_slave/carrier with loadbalance arp monitoring

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Nikolay Aleksandrov 

[ Upstream commit b8e4500f42fe4464a33a887579147050bed8fcef ]

Since commit 6fde8f037e60 ("bonding: fix locking in
bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
stale curr_active_slave when using arp monitoring in loadbalance modes. The
reason is that in bond_loadbalance_arp_mon() we can't have
do_failover == true but slave_state_changed == false, whenever do_failover
is true then slave_state_changed is also true. Then the following piece
from bond_loadbalance_arp_mon():
if (slave_state_changed) {
bond_slave_state_change(bond);
if (BOND_MODE(bond) == BOND_MODE_XOR)
bond_update_slave_arr(bond, NULL);
} else if (do_failover) {
block_netpoll_tx();
bond_select_active_slave(bond);
unblock_netpoll_tx();
}

will execute only the first branch, always and regardless of do_failover.
Since these two events aren't related in such way, we need to decouple and
consider them separately.

For example this issue could lead to the following result:
Bonding Mode: load balancing (round-robin)
*MII Status: down*
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
ARP Polling Interval (ms): 100
ARP IP target/s (n.n.n.n form): 192.168.9.2

Slave Interface: ens12
*MII Status: up*
Speed: 1 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: 00:0f:53:01:42:2c
Slave queue ID: 0

Slave Interface: eth1
*MII Status: up*
Speed: Unknown
Duplex: Unknown
Link Failure Count: 70
Permanent HW addr: 52:54:00:2f:0f:8e
Slave queue ID: 0

Since some interfaces are up, then the status of the bond should also be
up, but it will never change unless something invokes bond_set_carrier()
(i.e. enslave, bond_select_active_slave etc). Now, if I force the
calling of bond_select_active_slave via for example changing
primary_reselect (it can change in any mode), then the MII status goes to
"up" because it calls bond_select_active_slave() which should've been done
from bond_loadbalance_arp_mon() itself.

CC: Veaceslav Falico 
CC: Jay Vosburgh 
CC: Andy Gospodarek 
CC: Ding Tianhong 

Fixes: 6fde8f037e60 ("bonding: fix locking in bond_loadbalance_arp_mon()")
Signed-off-by: Nikolay Aleksandrov 
Acked-by: Veaceslav Falico 
Acked-by: Andy Gospodarek 
Acked-by: Ding Tianhong 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/bonding/bond_main.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2498,9 +2498,9 @@ static void bond_loadbalance_arp_mon(str
if (!rtnl_trylock())
goto re_arm;
 
-   if (slave_state_changed) {
+   if (slave_state_changed)
bond_slave_state_change(bond);
-   } else if (do_failover) {
+   if (do_failover) {
/* the bond_select_active_slave must hold RTNL
 * and curr_slave_lock for write.
 */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.17 003/122] MIPS: oprofile: Fix backtrace on 64-bit kernel

[Greg Kroah-Hartman]

3.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Aaro Koskinen 

commit bbaf113a481b6ce32444c125807ad3618643ce57 upstream.

Fix incorrect cast that always results in wrong address for the new
frame on 64-bit kernels.

Signed-off-by: Aaro Koskinen 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8110/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/oprofile/backtrace.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/oprofile/backtrace.c
+++ b/arch/mips/oprofile/backtrace.c
@@ -92,7 +92,7 @@ static inline int unwind_user_frame(stru
/* This marks the end of the previous function,
   which means we overran. */
break;
-   stack_size = (unsigned) stack_adjustment;
+   stack_size = (unsigned long) stack_adjustment;
} else if (is_ra_save_ins()) {
int ra_slot = ip.i_format.simmediate;
if (ra_slot < 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/