Re: [PATCH] avr32: replace simple_strtoul() with kstrtoul()

2014-03-30 Thread Hans-Christian Egtvedt
Around Wed 19 Mar 2014 12:52:35 +0300 or thereabout, Alexey Dobriyan wrote:
>> - val = simple_strtoul(buf, &endp, 0);
>> - if (endp == buf || val > 0x3f)
>> - return -EINVAL;
>> + ret = kstrtoul(buf, 0, &val);
>> + if (ret)
>> + return ret;
>>   val = (val << 12) | (sysreg_read(PCCR) & 0xfffc0fff);
> 
> you removed 0x3f check
> 
> this conversion is not trivial as it seems

Is anybody going to update this patch? I planned to push early this round, as
others are waiting for AVR32 changes.

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


Re: [PATCH] bonding: Inactive slaves should keep inactive flag's value to 1

2014-03-30 Thread zheng.li
Hi Jay,
What's you think about the new patch.

Thanks,
Zheng Li

于 2014年03月28日 17:22, Zheng Li 写道:
> In bond mode tlb and alb, inactive slaves should keep inactive flag to 1 to
> refuse to receive broadcast packets. Now, active slave send broadcast packets
> (for example ARP requests) which will arrive inactive slaves on same host from
> switch, but inactive slave's inactive flag is zero that cause bridge receive 
> the
> broadcast packets to produce a wrong entry in forward table. Typical situation
> is domu send some ARP request which go out from dom0 bond's active slave, then
> the ARP broadcast request packets go back to inactive slave from switch, 
> because
> the inactive slave's inactive flag is zero, kernel will receive the packets 
> and
> pass them to bridge that cause dom0's bridge map domu's MAC address to port of
> bond, bridge should map domu's MAC to port of vif.
> 
> Signed-off-by: Zheng Li 
> ---
>  drivers/net/bonding/bond_main.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index e5628fc..f97d72e 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3058,7 +3058,7 @@ static int bond_open(struct net_device *bond_dev)
>   if (bond_has_slaves(bond)) {
>   read_lock(&bond->curr_slave_lock);
>   bond_for_each_slave(bond, slave, iter) {
> - if ((bond->params.mode == BOND_MODE_ACTIVEBACKUP)
> + if ((bond->params.mode == BOND_MODE_ACTIVEBACKUP || 
> bond_is_lb(bond))
>   && (slave != bond->curr_active_slave)) {
>   bond_set_slave_inactive_flags(slave,
> 
> BOND_SLAVE_NOTIFY_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 v2 3/3] pstore: support current records dump in ramoops

2014-03-30 Thread Liu ShuoX

From: Liu ShuoX 

dump the records in runtime is useful sometime. We could check the
records and understand driver's and device's status.

Signed-off-by: Zhang Yanmin 
Signed-off-by: Liu ShuoX 
---
 fs/pstore/inode.c  | 32 ++--
 fs/pstore/internal.h   |  3 ++-
 fs/pstore/platform.c   | 39 ++-
 fs/pstore/ram.c| 18 ++
 fs/pstore/ram_core.c   | 10 ++
 include/linux/pstore.h |  2 ++
 include/linux/pstore_ram.h | 15 +++
 7 files changed, 103 insertions(+), 16 deletions(-)

diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index a9c9782..64adfb8 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -48,10 +48,11 @@ struct pstore_private {
struct list_head list;
struct pstore_info *psi;
enum pstore_type_id type;
+   int curr;
u64 id;
int count;
ssize_t size;
-   chardata[];
+   char*data;
 };
 
 struct pstore_seq_data {

@@ -220,6 +221,14 @@ static int pstore_file_open(struct inode *inode, struct 
file *file)
sops = zones[ps->id].seq_ops;
else
sops = &pstore_seq_ops;
+   if (ps->curr) {
+   /*
+* Update size again as current buffer
+* size might be changed.
+*/
+   inode->i_size = ps->size =
+   persistent_ram_size(cxt->norm_przs[ps->id]);
+   }
}
 
 	err = seq_open(file, sops);

@@ -256,12 +265,16 @@ static int pstore_unlink(struct inode *dir, struct dentry 
*dentry)
 {
struct pstore_private *p = dentry->d_inode->i_private;
 
+	if (p->curr)

+   goto unlink;
if (p->psi->erase)
p->psi->erase(p->type, p->id, p->count,
  dentry->d_inode->i_ctime, p->psi);
else
return -EPERM;
 
+	kfree(p->data);

+unlink:
return simple_unlink(dir, dentry);
 }
 
@@ -358,7 +371,7 @@ int pstore_is_mounted(void)

  */
 int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
  char *data, bool compressed, size_t size,
- struct timespec time, struct pstore_info *psi)
+ struct timespec time, struct pstore_info *psi, bool curr)
 {
struct dentry   *root = pstore_sb->s_root;
struct dentry   *dentry;
@@ -374,14 +387,15 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, 
u64 id, int count,
list_for_each_entry(pos, &allpstore, list) {
if (pos->type == type &&
pos->id == id &&
-   pos->psi == psi) {
+   pos->psi == psi &&
+   pos->curr == curr) {
rc = -EEXIST;
break;
}
}
spin_unlock_irqrestore(&allpstore_lock, flags);
if (rc)
-   return rc;
+   goto fail;
 
 	rc = -ENOMEM;

inode = pstore_get_inode(pstore_sb);
@@ -389,13 +403,15 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, 
u64 id, int count,
goto fail;
inode->i_mode = S_IFREG | 0444;
inode->i_fop = &pstore_file_operations;
-   private = kmalloc(sizeof *private + size, GFP_KERNEL);
+   private = kmalloc(sizeof(*private), GFP_KERNEL);
if (!private)
goto fail_alloc;
private->type = type;
private->id = id;
private->count = count;
private->psi = psi;
+   private->curr = curr;
+   private->data = data;
 
 	switch (type) {

case PSTORE_TYPE_DMESG:
@@ -434,13 +450,15 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, 
u64 id, int count,
break;
}
 
+	if (curr)

+   strcat(name, "_cur");
+
mutex_lock(&root->d_inode->i_mutex);
 
 	dentry = d_alloc_name(root, name);

if (!dentry)
goto fail_lockedalloc;
 
-	memcpy(private->data, data, size);

inode->i_size = private->size = size;
 
 	inode->i_private = private;

@@ -465,6 +483,7 @@ fail_alloc:
iput(inode);
 
 fail:

+   kfree(data);
return rc;
 }
 
@@ -497,6 +516,7 @@ static int pstore_fill_super(struct super_block *sb, void *data, int silent)

return -ENOMEM;
 
 	pstore_get_records(0);

+   pstore_get_cur_records();
 
 	return 0;

 }
diff --git a/fs/pstore/internal.h b/fs/pstore/internal.h
index 86623ee..ccc0f35 100644
--- a/fs/pstore/internal.h
+++ b/fs/pstore/internal.h
@@ -50,10 +50,11 @@ extern struct pstore_info *psinfo;
 
 extern void	pstore_set_kmsg_bytes(int);

 extern voidpstore_get_records(int);
+extern voidpstore_get_cur_records(void);
 extern int pstore_mkfile(enum pstore_type_id, char *psname, u64 id,
  

[PATCH v2 2/3] pstore: add seq_ops for norm zone

2014-03-30 Thread Liu ShuoX

From: Liu ShuoX 

Some developers want to output the pstore record trace flexible.
So add seq_ops into ramoops_zone in case users would make private output
format.

Signed-off-by: Zhang Yanmin 
Signed-off-by: Liu ShuoX 
---
 fs/pstore/inode.c  | 10 --
 include/linux/pstore_ramoops.h |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index d463481..a9c9782 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -207,14 +207,20 @@ static ssize_t pstore_file_read(struct file *file, char 
__user *userbuf,
 static int pstore_file_open(struct inode *inode, struct file *file)
 {
struct pstore_private *ps = inode->i_private;
+   struct ramoops_context *cxt = ps->psi->data;
+   struct ramoops_zone*zones = cxt ? cxt->zones : NULL;
struct seq_file *sf;
int err;
const struct seq_operations *sops = NULL;
 
 	if (ps->type == PSTORE_TYPE_FTRACE)

sops = &pstore_ftrace_seq_ops;
-   if (ps->type == PSTORE_TYPE_NORM)
-   sops = &pstore_seq_ops;
+   if (ps->type == PSTORE_TYPE_NORM && zones) {
+   if (zones[ps->id].seq_ops)
+   sops = zones[ps->id].seq_ops;
+   else
+   sops = &pstore_seq_ops;
+   }
 
 	err = seq_open(file, sops);

if (err < 0)
diff --git a/include/linux/pstore_ramoops.h b/include/linux/pstore_ramoops.h
index 7c0a64b..9a5a224 100644
--- a/include/linux/pstore_ramoops.h
+++ b/include/linux/pstore_ramoops.h
@@ -32,6 +32,7 @@ struct ramoops_zone {
struct persistent_ram_zone *prz;
int item_size;
void (*print_record)(struct seq_file *s, void *record);
+   struct seq_operations *seq_ops;
 };
 
 /*

--
1.8.3.2

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


[PATCH v2 1/3] pstore: restructure ramoops to support more trace

2014-03-30 Thread Liu ShuoX

On Mon 31.Mar'14 at 11:07:56 +1100, Stephen Rothwell wrote:

Hi all,

After merging the ia64 tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/built-in.o: In function `pstore_file_open':
inode.c:(.text+0xa29e9): undefined reference to `persistent_ram_size'

Caused by commit f5d7e81eda59 ("pstore: Support current records dump in 
ramoops").

I have used the ia64 tree from next-20140328 for today.

Sorry for the compiling failure and thanks for Tony, Fengguang and Stephen 
Rothwell.
We updated the serial patches and i also updated this email's subject.
Changelog v2:
  1) Fix compiling errors when CONFIG_PSTORE_RAM is disabled.
  2) Add some protection in the code in case we disable CONFIG_PSTORE_RAM.

Below are the v2 patches.
---
From: Zhang Yanmin 

The patch restructure ramoops of pstore a little to support more user-defined
tracers through ramoops. Here is reason we enhance ramoops:
pstore ramoops is a very import debug feature for mobile development. At 
present,
ramoops has supported kdump, console and ftrace tracer. Sometimes, we need some
special tracers such as recording cmd and data when driver send/receive. But 
now,
it's hard to add new tracers into ramoops without touching the pstore core 
codes.
So we restructure ramoops to let it more flexiable, more eailier to extend.

With this, we split the pstore codes and new tracers which are based on ramoops.
Developer could add a new tracer based on ramoops standalone and pstore detects
it automatically.

Signed-off-by: Zhang Yanmin 
Signed-off-by: Liu ShuoX 
---
 Documentation/ramoops.txt |  70 ++-
 arch/x86/kernel/vmlinux.lds.S |   9 ++
 drivers/platform/chrome/chromeos_pstore.c |   2 +-
 fs/pstore/inode.c |  85 +-
 fs/pstore/internal.h  |   1 +
 fs/pstore/ram.c   | 145 +++---
 fs/pstore/ram_core.c  |  20 +
 include/linux/pstore.h|   2 +
 include/linux/pstore_ram.h|  21 ++---
 include/linux/pstore_ramoops.h|  65 ++
 10 files changed, 371 insertions(+), 49 deletions(-)
 create mode 100644 include/linux/pstore_ramoops.h

diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 69b3cac..243ce5f 100644
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -49,7 +49,7 @@ Setting the ramoops parameters can be done in 2 different 
manners:
  2. Use a platform device and set the platform data. The parameters can then
  be set through that platform data. An example of doing that is:
 
-#include 

+#include 
 [...]
 
 static struct ramoops_platform_data ramoops_data = {

@@ -117,3 +117,71 @@ file. Here is an example of usage:
  0 811d9c54  8101a7a0  __const_udelay <- 
native_machine_emergency_restart+0x110/0x1e0
  0 811d9c34  811d9c80  __delay <- __const_udelay+0x30/0x40
  0 811d9d14  811d9c3f  delay_tsc <- __delay+0xf/0x20
+
+6. Persistent record tracing
+
+Persistent record tracing might be useful for debugging software of hardware
+related hangs. It has flexible usage allows developer to trace self-defined
+record structure at self-defined tracepoint. After reboot, the record log is
+stored in a "NAME-ramoops" file. Here is an example of usage:
+
+#include 
+[...]
+
+struct norm_zone_test_record {
+   unsigned long val;
+   char str[32];
+};
+
+static void print_record(struct seq_file *s, void *rec)
+{
+   struct norm_zone_test_record *record = rec;
+   seq_printf(s, "%s: %ld\n",
+   record->str, record->val);
+}
+
+DEFINE_PSTORE_RAMZONE(test_zone) = {
+   .size = 4096,
+   .name = "test_zone",
+   .item_size = sizeof(struct norm_zone_test_record),
+   .print_record = print_record,
+};
+
+static void add_test_record(char *str, unsigned long val)
+{
+   struct norm_zone_test_record *record;
+   record = persistent_ram_new_record(test_zone.prz);
+   if (record) {
+   record->val = val;
+   strcpy(record->str, str);
+   }
+}
+
+static int test_cpufreq_transition(struct notifier_block *nb,
+   unsigned long event, void *data)
+{
+   add_test_record("cpufreq transition", event);
+   return 0;
+}
+
+static struct notifier_block freq_transition = {
+   .notifier_call = test_cpufreq_transition,
+};
+
+static int __init norm_zone_test_init(void)
+{
+   cpufreq_register_notifier(&freq_transition,
+   CPUFREQ_TRANSITION_NOTIFIER);
+   return 0;
+}
+module_init(norm_zone_test_init);
+
+Record trace use the reserved memory by ramoops. For the most compatibility,
+user could use Chapter 2's methods to define the ramoops paramters, then
+enlarge the defined mem_size with ramoops_norm_zones_size(), e.g.:
+
+#include 
+#include 
+
+memblock_reserve(ramoops_data.mem_address, ramoops_data.mem_size +
+ 

[PATCH v2] Staging: ft1000-usb: fixed a few code style issues

2014-03-30 Thread Anders Darander
Fixed a few code style issues, particularly:

Add do {} while (0) wrapper around seq_* macros.
Change printk(KERN_WARN...) to netdev_warn(...).

Signed-off-by: Anders Darander 
---
Changes: 
  v2: * Fix syntax errors (adding missing ; and }).

 drivers/staging/ft1000/ft1000-usb/ft1000_proc.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_proc.c 
b/drivers/staging/ft1000/ft1000-usb/ft1000_proc.c
index 2575d0d..e89b5d2 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_proc.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_proc.c
@@ -32,17 +32,20 @@
 
 
 #define seq_putx(m, message, size, var) \
-   seq_printf(m, message); \
-   for (i = 0; i < (size - 1); i++) \
-   seq_printf(m, "%02x:", var[i]); \
-   seq_printf(m, "%02x\n", var[i])
+   do { \
+   seq_printf(m, message); \
+   for (i = 0; i < (size - 1); i++) \
+   seq_printf(m, "%02x:", var[i]); \
+   seq_printf(m, "%02x\n", var[i]);\
+   } while (0)
 
 #define seq_putd(m, message, size, var) \
-   seq_printf(m, message); \
-   for (i = 0; i < (size - 1); i++) \
-   seq_printf(m, "%d.", var[i]); \
-   seq_printf(m, "%d\n", var[i])
-
+   do { \
+   seq_printf(m, message); \
+   for (i = 0; i < (size - 1); i++) \
+   seq_printf(m, "%d.", var[i]); \
+   seq_printf(m, "%d\n", var[i]);\
+   } while (0)
 
 #define FTNET_PROC init_net.proc_net
 
@@ -200,7 +203,7 @@ int ft1000_init_proc(struct net_device *dev)
 
info->ft1000_proc_dir = proc_mkdir(FT1000_PROC_DIR, FTNET_PROC);
if (info->ft1000_proc_dir == NULL) {
-   printk(KERN_WARNING "Unable to create %s dir.\n",
+   netdev_warn(dev, "Unable to create %s dir.\n",
FT1000_PROC_DIR);
goto fail;
}
@@ -210,7 +213,7 @@ int ft1000_init_proc(struct net_device *dev)
 &ft1000_proc_fops, dev);
 
if (!ft1000_proc_file) {
-   printk(KERN_WARNING "Unable to create /proc entry.\n");
+   netdev_warn(dev, "Unable to create /proc entry.\n");
goto fail_entry;
}
 
-- 
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/


[GIT PULL] s390 compat wrapper rework

2014-03-30 Thread Heiko Carstens
Hi Linus,

please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git compat

to get the s390 compat system call wrapper simplification work.

The intention of this work is to get rid of all hand written assembly compat
system call wrappers on s390, which perform proper sign or zero extension, or
pointer conversion of compat system call parameters.  Instead all of this
should be done with C code e.g. by using Al's COMPAT_SYSCALL_DEFINEx() macro.

Therefore all common code and s390 specific compat system calls have been
converted to the COMPAT_SYSCALL_DEFINEx() macro.

In order to generate correct code all compat system calls may only have e.g.
compat_ulong_t parameters, but no unsigned long parameters. Those patches
which change parameter types from unsigned long to compat_ulong_t parameters
are separate in this series, but shouldn't cause any harm.

The only compat system calls which intentionally have 64 bit parameters
(preadv64 and pwritev64) in support of the x86/32 ABI haven't been changed,
but are now only available if an architecture defines
__ARCH_WANT_COMPAT_SYS_PREADV64/PWRITEV64.

System calls which do not have a compat variant but still need proper zero
extension on s390, like e.g. "long sys_brk(unsigned long brk)" will get a
proper wrapper function with the new s390 specific COMPAT_SYSCALL_WRAPx()
macro:

COMPAT_SYSCALL_WRAP1(brk, unsigned long, brk);

which generates the following code (simplified):

asmlinkage long sys_brk(unsigned long brk);
asmlinkage long compat_sys_brk(long brk)
{
return sys_brk((u32)brk);
}

Given that the C file which contains all the COMPAT_SYSCALL_WRAP lines
includes both linux/syscall.h and linux/compat.h, it will generate build
errors, if the declaration of sys_brk() doesn't match, or if there exists a
non-matching compat_sys_brk() declaration.
In addition this will intentionally result in a link error if somewhere else a
compat_sys_brk() function exists, which probably should have been used
instead.
Two more BUILD_BUG_ONs make sure the size and type of each compat syscall
parameter can be handled correctly with the s390 specific macros.

I converted the compat system calls step by step to verify the generated code
is correct and matches the previous code. In fact it did not always match,
however that was always a bug in the hand written asm code.

In result we get less code, less bugs, and much more sanity checking.

Thanks,
Heiko


Heiko Carstens (44):
  compat: let architectures define __ARCH_WANT_COMPAT_SYS_GETDENTS64
  compat: add COMPAT_SYSCALL_DEFINE0 macro
  s390/compat: convert to COMPAT_SYSCALL_DEFINEx part 1
  s390/compat: convert to COMPAT_SYSCALL_DEFINEx part 2
  s390/compat: convert to COMPAT_SYSCALL_DEFINEx part 3
  s390/compat: convert to COMPAT_SYSCALL_DEFINEx part 4
  s390/compat: convert to COMPAT_SYSCALL_DEFINEx part 5
  s390/compat: convert to COMPAT_SYSCALL_DEFINEx part 6
  s390/compat: convert to COMPAT_SYSCALL_DEFINEx part 7
  s390/compat: convert system call wrappers to C part 01
  s390/compat: convert system call wrappers to C part 02
  s390/compat: convert system call wrappers to C part 03
  s390/compat: convert system call wrappers to C part 04
  s390/compat: convert system call wrappers to C part 05
  s390/compat: convert system call wrappers to C part 06
  s390/compat: convert system call wrappers to C part 07
  s390/compat: convert system call wrappers to C part 08
  s390/compat: convert system call wrappers to C part 09
  s390/compat: convert system call wrappers to C part 10
  s390/compat: convert system call wrappers to C part 11
  s390/compat: convert system call wrappers to C part 12
  s390/compat: convert system call wrappers to C part 13
  s390/compat: convert system call wrappers to C part 14
  s390/compat: convert system call wrappers to C part 15
  s390/compat: add sync_file_range and fallocate compat syscalls
  s390/compat: automatic zero, sign and pointer conversion of syscalls
  s390/compat: partial parameter conversion within syscall wrappers
  ipc/compat_sys_msgrcv: change msgtyp type from long to compat_long_t
  fs/compat: optional preadv64/pwrite64 compat system calls
  kernel/compat: convert to COMPAT_SYSCALL_DEFINE
  net/compat: convert to COMPAT_SYSCALL_DEFINE
  mm/compat: convert to COMPAT_SYSCALL_DEFINE
  security/compat: convert to COMPAT_SYSCALL_DEFINE
  fs/compat: convert to COMPAT_SYSCALL_DEFINE
  ipc/compat: convert to COMPAT_SYSCALL_DEFINE
  fs/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types
  ipc/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types
  net/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types
  kexec/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter 
types
  mm/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types
  

Re: [PATCH V4 07/11] ACPI: use platform bus as the default bus for _HID enumeration

2014-03-30 Thread Zhang Rui
On Mon, 2014-03-24 at 12:06 +0800, Zhang Rui wrote:
> On Mon, 2014-03-24 at 03:00 +0100, Rafael J. Wysocki wrote:
> > On Monday, March 17, 2014 03:49:36 PM Zhang Rui wrote:
> > > Because of the growing demand for enumerating ACPI devices to platform 
> > > bus,
> > > this patch changes the code to enumerate ACPI devices with _HID to
> > > platform bus by default, unless the device already has a scan handler 
> > > attached.
> > 
> > I think we need to be more careful here still.
> > 
> > For example, we shouldn't create platform devices for ACPI device objects 
> > that
> > correspond to I2C devices (or any other "simple peripheral bus" devices for 
> > that
> > matter).
> > 
> agreed. Then how about the patch below?
> Note that I've just finished with build test.
> 
updated one attached.
I faked a LPSS device and its child device in DSDT, test result shows
that only the LPSS device is enumerated to platform bus via the LPSS
scan handler.

>From 9ac1537b52e5882e13fd60cb435af56ed04456ac Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Mon, 24 Mar 2014 11:48:05 +0800
Subject: [PATCH] ACPI: introduce .handle_children flag for acpi scan handler

For some devices with scan handler attached, their children devices
are enumerated by the scan handler, indirectly, as well.

In this case, we do not want to enumerate the children devices in
acpi scan code explicitly.

Thus a new flag .handle_children is introduced in this patch.

For scan handlers with this flag set, we will do default enumeration neither
for the attached devices nor for the children of the attached devices.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_lpss.c |2 ++
 drivers/acpi/scan.c  |   28 ++--
 include/acpi/acpi_bus.h  |4 +++-
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index cfbf2c0..6c3e7a8 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -440,6 +440,7 @@ static struct notifier_block acpi_lpss_nb = {
 static struct acpi_scan_handler lpss_handler = {
.ids = acpi_lpss_device_ids,
.attach = acpi_lpss_create_device,
+   .handle_children = true,
 };
 
 #endif /* CONFIG_X86_INTEL_LPSS */
@@ -453,6 +454,7 @@ static int acpi_lpss_dummy_attach(struct acpi_device *adev,
 static struct acpi_scan_handler lpss_dummy_handler = {
.ids = acpi_lpss_device_ids,
.attach = acpi_lpss_dummy_attach,
+   .handle_children = true,
 };
 
 void __init acpi_lpss_init(void)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index c0456e7..cd833f4 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2016,6 +2016,31 @@ static acpi_status acpi_bus_check_add(acpi_handle 
handle, u32 lvl_not_used,
return AE_OK;
 }
 
+static void acpi_do_default_enumeration(struct acpi_device *device)
+{
+   /*
+* Do not do enumeration for device object that
+* its parent doesn't want to
+*/
+   if (device->parent && device->parent->flags.no_child_enumeration) {
+   device->flags.no_child_enumeration = 1;
+   return;
+   }
+
+   /* Do not do enumeration for device object with scan handler attached */
+   if (device->handler) {
+   if (device->handler->handle_children)
+   device->flags.no_child_enumeration = 1;
+   return;
+   }
+
+   /* Do not do enumeration for device object w/o platform_id */
+   if (!device->pnp.type.platform_id)
+   return;
+
+   acpi_create_platform_device(device, NULL);
+}
+
 static int acpi_scan_attach_handler(struct acpi_device *device)
 {
struct acpi_hardware_id *hwid;
@@ -2035,8 +2060,7 @@ static int acpi_scan_attach_handler(struct acpi_device 
*device)
}
}
 end:
-   if (device->pnp.type.platform_id && !device->handler)
-   acpi_create_platform_device(device, NULL);
+   acpi_do_default_enumeration(device);
return ret;
 }
 
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index f998746..bc7235f 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -135,6 +135,7 @@ struct acpi_scan_handler {
int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
void (*detach)(struct acpi_device *dev);
struct acpi_hotplug_profile hotplug;
+   bool handle_children;
 };
 
 /*
@@ -191,7 +192,8 @@ struct acpi_device_flags {
u32 initialized:1;
u32 visited:1;
u32 no_hotplug:1;
-   u32 reserved:24;
+   u32 no_child_enumeration:1;
+   u32 reserved:23;
 };
 
 /* File System */
-- 
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/


linux kernel cross references 3.14, 3.13.7, 3.12.15, 3.10.34, 3.4.84 are added into www.xrefs.info

2014-03-30 Thread John Smith
hello, I added the follow linux kernel cross references into www.xrefs.info:

linux-3.14
linux-3.13.7
linux-3.12.15
linux-3.10.34
linux-3.4.84

Check it out!!!
Thanks.
xrefs.info admin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Adding compression before/above swapcache

2014-03-30 Thread Minchan Kim
Hello Dan,

On Wed, Mar 26, 2014 at 04:28:27PM -0400, Dan Streetman wrote:
> I'd like some feedback on how possible/useful, or not, it might be to
> add compression into the page handling code before pages are added to
> the swapcache.  My thought is that adding a compressed cache at that
> point may have (at least) two advantages over the existing page
> compression, zswap and zram, which are both in the swap path.
> 
> 1) Both zswap and zram are limited in the amount of memory that they
> can compress/store:
> -zswap is limited both in the amount of pre-compressed pages, by the
> total amount of swap configured in the system, and post-compressed
> pages, by its max_pool_percentage parameter.  These limitations aren't
> necessarily a bad thing, just requirements for the user (or distro
> setup tool, etc) to correctly configure them.  And for optimal
> operation, they need to coordinate; for example, with the default
> post-compressed 20% of memory zswap's configured to use, the amount of
> swap in the system must be at least 40% of system memory (if/when
> zswap is changed to use zsmalloc that number would need to increase).
> The point being, there is a clear possibility of misconfiguration, or
> even a simple lack of enough disk space for actual swap, that could
> artificially reduce the amount of total memory zswap is able to

Potentailly, there is risk in tuning knob so admin should be careful.
Surely, kernel should do best effort to prevent such confusion and
I think well-written documentation would be enough.

> compress.  Additionally, most of that real disk swap is wasted space -
> all the pages stored compressed in zswap aren't actually written on
> the disk.

It's same with normal swap. If there isn't memory pressure, it's wasted
space, too.

> -zram is limited only by its pre-compressed size, and of course the
> amount of actual system memory it can use for compressed storage.  If
> using without dm-cache, this could allow essentially unlimited

It's because no requirement until now. If someone ask it or report
the problem, we could support it easily.

> compression until no more compressed pages can be stored; however that
> requires the zram device to be configured as larger than the actual
> system memory.  If using with dm-cache, it may not be obvious what the

Normally, the method we have used is to measure avg compr ratio
and 

> optimal zram size is.

It's not a problem of zram. It seems dm-cache folks pass the decision
to userspace because there would be various choices depends on policy
dm-cache have supported.

> 
> Pre-swapcache compression would theoretically require no user
> configuration, and the amount of compressed pages would be unlimited
> (until there is no more room to store compressed pages).

Could you elaborate it more?
You mean pre-swapcache doesn't need real storage(mkswap + swapn)?

> 
> 2) Both zswap and zram (with dm-cache) write uncompressed pages to disk:
> -zswap rejects any pages being sent to swap that don't compress well
> enough, and they're passed on to the swap disk in uncompressed form.
> Also, once zswap is full it starts uncompressing its old compressed
> pages and writing them back to the swap disk.
> -zram, with dm-cache, can pass pages on to the swap disk, but IIUC
> those pages must be uncompressed first, and then written in compressed
> form on disk.  (Please correct me here if that is wrong).

I didn't look that code but I guess if dm-cache decides moving the page
from zram device to real storage, it would decompress a page from zram
and write it to storage without compressing. So it's not a compressed
form.

> 
> A compressed cache that comes before the swap cache would be able to
> push pages from its compressed storage to the swap disk, that contain
> multiple compressed pages (and/or parts of compressed pages, if
> overlapping page boundries).  I think that would be able to,
> theoretically at least, improve overall read/write times from a
> pre-compressed perspective, simply because less actual data would be
> transferred.  Also, less actual swap disk space would be
> used/required, which on systems with a very large amount of system
> memory may be beneficial.

I agree part of your claim but couldn't.
If we write a page which includes several compressed pages, it surely
enhance write bandwidth but we should give extra pages for *reading*
a page. You might argue swap already have done it via page-cluster.
But the difference is that we could control it by knob so we could
reduce window size if swap readahead hit ratio isn't good.

With your proposal, we couldn't control it so it would be likely to
fail swap-read than old if memory pressure is severe because we 
might need many pages to decompress just a page. For prevent,
we need large buffer to decompress pages and we should limit the
number of pages which put together a page, which can make system
more predictable but it needs serialization of buffer so might hurt
performance, too.

> 
> 
> A

Re: [PATCH] virtio-blk: make the queue depth the max supportable by the hypervisor

2014-03-30 Thread Rusty Russell
Venkatesh Srinivas  writes:
> On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas
>  wrote:
>>> And I rewrote it substantially, mainly to take
>>> VIRTIO_RING_F_INDIRECT_DESC into account.
>>>
>>> As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
>>> have made a change.  This version does (since QEMU also offers
>>> VIRTIO_RING_F_INDIRECT_DESC.
>>
>> That divide-by-2 produced the same queue depth as the prior
>> computation in QEMU was deliberate -- but raising it to 128 seems
>> pretty reasonable.
>>
>> Signed-off-by: Venkatesh Srinivas 
>
> Soft ping about this patch.

It's head of my virtio-next tree.

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


Re: linux-next: build failure after merge of the modules tree

2014-03-30 Thread Rusty Russell
Stephen Rothwell  writes:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

Hmm, I sent Greg KH a separate patch for staging, which rips these out
altogether.  He said he'd apply it "in a bit".

I see it hasn't hit mainline yet, so here it is.

From: Rusty Russell 
Subject: staging: fix up speakup kobject mode

It uses the unnecessary S_IFREG bit which will break when my
stricter-checking-for-mode patch goes in.

Since we're fixing it anyway, the extra level of indirection is
confusing for readers (ROOT_W == rw-r--r-- for example).

Also, many of these are other-writable.  Is that really intended?

Signed-off-by: Rusty Russell 
---
 drivers/staging/speakup/kobjects.c   | 62 
 drivers/staging/speakup/speakup.h|  2 --
 drivers/staging/speakup/speakup_acntpc.c | 22 ++--
 drivers/staging/speakup/speakup_acntsa.c | 22 ++--
 drivers/staging/speakup/speakup_apollo.c | 24 ++---
 drivers/staging/speakup/speakup_audptr.c | 24 ++---
 drivers/staging/speakup/speakup_bns.c| 22 ++--
 drivers/staging/speakup/speakup_decext.c | 24 ++---
 drivers/staging/speakup/speakup_decpc.c  | 24 ++---
 drivers/staging/speakup/speakup_dectlk.c | 24 ++---
 drivers/staging/speakup/speakup_dtlk.c   | 28 +++
 drivers/staging/speakup/speakup_dummy.c  | 22 ++--
 drivers/staging/speakup/speakup_keypc.c  | 18 +-
 drivers/staging/speakup/speakup_ltlk.c   | 28 +++
 drivers/staging/speakup/speakup_soft.c   | 30 
 drivers/staging/speakup/speakup_spkout.c | 24 ++---
 drivers/staging/speakup/speakup_txprt.c  | 22 ++--
 17 files changed, 210 insertions(+), 212 deletions(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index e2f597ee6261..1ca91f7092b1 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -851,75 +851,75 @@ static ssize_t message_store(struct kobject *kobj, struct 
kobj_attribute *attr,
  * Declare the attributes.
  */
 static struct kobj_attribute keymap_attribute =
-   __ATTR(keymap, ROOT_W, keymap_show, keymap_store);
+   __ATTR(keymap, S_IWUSR|S_IRUGO, keymap_show, keymap_store);
 static struct kobj_attribute silent_attribute =
-   __ATTR(silent, USER_W, NULL, silent_store);
+   __ATTR(silent, S_IWUGO, NULL, silent_store);
 static struct kobj_attribute synth_attribute =
-   __ATTR(synth, USER_RW, synth_show, synth_store);
+   __ATTR(synth, S_IWUGO|S_IRUGO, synth_show, synth_store);
 static struct kobj_attribute synth_direct_attribute =
-   __ATTR(synth_direct, USER_W, NULL, synth_direct_store);
+   __ATTR(synth_direct, S_IWUGO, NULL, synth_direct_store);
 static struct kobj_attribute version_attribute =
__ATTR_RO(version);
 
 static struct kobj_attribute delimiters_attribute =
-   __ATTR(delimiters, USER_RW, punc_show, punc_store);
+   __ATTR(delimiters, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute ex_num_attribute =
-   __ATTR(ex_num, USER_RW, punc_show, punc_store);
+   __ATTR(ex_num, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute punc_all_attribute =
-   __ATTR(punc_all, USER_RW, punc_show, punc_store);
+   __ATTR(punc_all, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute punc_most_attribute =
-   __ATTR(punc_most, USER_RW, punc_show, punc_store);
+   __ATTR(punc_most, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute punc_some_attribute =
-   __ATTR(punc_some, USER_RW, punc_show, punc_store);
+   __ATTR(punc_some, S_IWUGO|S_IRUGO, punc_show, punc_store);
 static struct kobj_attribute repeats_attribute =
-   __ATTR(repeats, USER_RW, punc_show, punc_store);
+   __ATTR(repeats, S_IWUGO|S_IRUGO, punc_show, punc_store);
 
 static struct kobj_attribute attrib_bleep_attribute =
-   __ATTR(attrib_bleep, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(attrib_bleep, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute bell_pos_attribute =
-   __ATTR(bell_pos, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(bell_pos, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute bleep_time_attribute =
-   __ATTR(bleep_time, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(bleep_time, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute bleeps_attribute =
-   __ATTR(bleeps, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(bleeps, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute cursor_time_attribute =
-   __ATTR(cursor_time, USER_RW, spk_var_show, spk_var_store);
+   __ATTR(cursor_time, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
 static struct kobj_attribute key_echo_attribute =
-   __ATTR(key_echo

Re: [PATCH] Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE

2014-03-30 Thread Rusty Russell
Takashi Iwai  writes:
> At Thu, 13 Mar 2014 11:30:47 +1030,
> Rusty Russell wrote:
>> 
>> Steven Rostedt  writes:
>> > Mathieu, you should have added a v2 to the subject ie: [PATCH V2]
>> >
>> > Rusty,
>> >
>> > If you want to take this, please add my
>> > Acked-by: Steven Rostedt 
>> 
>> Thanks, I updated my copy and have pushed this into modules-next.
>
> The letter 'X' has been already used for SUSE kernels for very long
> time, to indicate the external supported modules.  Can the new flag be
> changed to another letter for avoiding conflict...?
> (BTW, we also use 'N' for "no support", too.)

Sure...  As I've already applied it, I've had to add this new patch:

Subject: Use 'E' instead of 'X' for unsigned module taint flag.

66cc69e34e86a231fbe68d8918c6119e3b7549a3 added 'X' for unsigned module
taints, but Takashi Iwai  says:

   The letter 'X' has been already used for SUSE kernels for very long
   time, to indicate the external supported modules.  Can the new flag be
   changed to another letter for avoiding conflict...?
   (BTW, we also use 'N' for "no support", too.)

Note: this code should be cleaned up, so we don't have such maps in
three places!

Signed-off-by: Rusty Russell 

diff --git a/Documentation/ABI/testing/sysfs-module 
b/Documentation/ABI/testing/sysfs-module
index b9a29cdbaccb..66a110b4c48a 100644
--- a/Documentation/ABI/testing/sysfs-module
+++ b/Documentation/ABI/testing/sysfs-module
@@ -49,4 +49,4 @@ Description:  Module taint flags:
O - out-of-tree module
F - force-loaded module
C - staging driver module
-   X - unsigned module
+   E - unsigned module
diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt
index b6af42e4d790..db1c49e17aa2 100644
--- a/Documentation/module-signing.txt
+++ b/Documentation/module-signing.txt
@@ -54,7 +54,7 @@ This has a number of options available:
  If this is off (ie. "permissive"), then modules for which the key is not
  available and modules that are unsigned are permitted, but the kernel will
  be marked as being tainted, and the concerned modules will be marked as
- tainted, shown with the character 'X'.
+ tainted, shown with the character 'E'.
 
  If this is on (ie. "restrictive"), only modules that have a valid
  signature that can be verified by a public key in the kernel's possession
diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
index 879abe289523..fa86b85d2821 100644
--- a/Documentation/oops-tracing.txt
+++ b/Documentation/oops-tracing.txt
@@ -265,7 +265,7 @@ characters, each representing a particular tainted value.
 
  13: 'O' if an externally-built ("out-of-tree") module has been loaded.
 
- 14: 'X' if an unsigned module has been loaded in a kernel supporting
+ 14: 'E' if an unsigned module has been loaded in a kernel supporting
  module signature.
 
 The primary reason for the 'Tainted: ' string is to tell kernel
diff --git a/kernel/module.c b/kernel/module.c
index c1acb0c5b637..6d620199b892 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1014,7 +1014,7 @@ static size_t module_flags_taint(struct module *mod, char 
*buf)
if (mod->taints & (1 << TAINT_CRAP))
buf[l++] = 'C';
if (mod->taints & (1 << TAINT_UNSIGNED_MODULE))
-   buf[l++] = 'X';
+   buf[l++] = 'E';
/*
 * TAINT_FORCED_RMMOD: could be added.
 * TAINT_UNSAFE_SMP, TAINT_MACHINE_CHECK, TAINT_BAD_PAGE don't
diff --git a/kernel/panic.c b/kernel/panic.c
index 0e25fe10871e..dbee7fe2a0c0 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -210,7 +210,7 @@ static const struct tnt tnts[] = {
{ TAINT_CRAP,   'C', ' ' },
{ TAINT_FIRMWARE_WORKAROUND,'I', ' ' },
{ TAINT_OOT_MODULE, 'O', ' ' },
-   { TAINT_UNSIGNED_MODULE,'X', ' ' },
+   { TAINT_UNSIGNED_MODULE,'E', ' ' },
 };
 
 /**
@@ -229,7 +229,7 @@ static const struct tnt tnts[] = {
  *  'C' - modules from drivers/staging are loaded.
  *  'I' - Working around severe firmware bug.
  *  'O' - Out-of-tree module has been loaded.
- *  'X' - Unsigned module has been loaded.
+ *  'E' - Unsigned module has been loaded.
  *
  * The string is overwritten by the next call to print_tainted().
  */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: rework new_id interface for known vendor/device values

2014-03-30 Thread Bandan Das

While using the new_id interface, the user can unintentionally feed
incorrect values if the driver static table has a matching entry.
This is possible since only the device and vendor fields are
mandatory and the rest are optional. As a result, store_new_id
will fill in default values that are then passed on to the driver
and can have unintended consequences.

As an example, consider the ixgbe driver and the 82599EB network card :
echo "8086 10fb" > /sys/bus/pci/drivers/ixgbe/new_id

This will pass a driver_data value of 0 to the driver whereas
the index 0 in ixgbe actually points to a different set of card
operations.

This change automatically selects the matching static entry if there
is one for the newly created dynid. However, if the user intentionally
wants a different set of values, she must provide all the 7 fields
and the static entry will be ignored.

In most cases, this use case seems unnecessary, however, this
is a common libvirt/KVM/device assignment scenario where the
user might want to bind a device back to the host driver.

Signed-off-by: Bandan Das 
---
 drivers/pci/pci-driver.c | 42 ++
 1 file changed, 38 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 25f0bc6..187e572 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -90,6 +90,24 @@ static void pci_free_dynids(struct pci_driver *drv)
spin_unlock(&drv->dynids.lock);
 }
 
+static const struct
+pci_device_id *match_id_table_entry(struct device_driver *driver,
+   __u32 vendor, __u32 device)
+{
+   struct pci_driver *pdrv = to_pci_driver(driver);
+   const struct pci_device_id *ids = pdrv->id_table;
+
+   if (ids) {
+   while (ids->vendor || ids->subvendor || ids->class_mask) {
+   if ((ids->vendor == vendor) && (ids->device == device))
+   return ids;
+   ids++;
+   }
+   }
+
+   return NULL;
+}
+
 /**
  * store_new_id - sysfs frontend to pci_add_dynid()
  * @driver: target device driver
@@ -102,7 +120,8 @@ static ssize_t
 store_new_id(struct device_driver *driver, const char *buf, size_t count)
 {
struct pci_driver *pdrv = to_pci_driver(driver);
-   const struct pci_device_id *ids = pdrv->id_table;
+   const struct pci_device_id *ids = pdrv->id_table,
+   *tids = NULL;
__u32 vendor, device, subvendor=PCI_ANY_ID,
subdevice=PCI_ANY_ID, class=0, class_mask=0;
unsigned long driver_data=0;
@@ -115,9 +134,24 @@ store_new_id(struct device_driver *driver, const char 
*buf, size_t count)
if (fields < 2)
return -EINVAL;
 
-   /* Only accept driver_data values that match an existing id_table
-  entry */
-   if (ids) {
+   tids = match_id_table_entry(driver, vendor, device);
+
+   if (tids && (fields != 7)) {
+
+   subvendor = tids->subvendor;
+   subdevice = tids->subdevice;
+   class = tids->class;
+   class_mask = tids->class_mask;
+   driver_data = tids->driver_data;
+
+   pr_warn("pci: Using driver (%s) static DeviceID table entry for 
vendor 0x%04x and device 0x%04x",
+   driver->name, vendor, device);
+
+   } else if (ids) {
+
+   /* Only accept driver_data values that match an existing
+  id_table entry */
+
retval = -EINVAL;
while (ids->vendor || ids->subvendor || ids->class_mask) {
if (driver_data == ids->driver_data) {
-- 
1.8.3.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/3] powernv,cpufreq: Dynamic Frequency Scaling support

2014-03-30 Thread Viresh Kumar
On 29 March 2014 01:41, Gautham R. Shenoy  wrote:
> From: "Gautham R. Shenoy" 
>
> Hi,
>
> This is v5 of the patchset to enable dynamic frequency scaling on IBM
> PowerNV platforms. This patchset does address all the review comments
> obtained for v4 (which can be found at [1]).
>
> Changes from v4:
>
> * Created a separate patch to select the CPUFreq related Config
>   options for PowerNV
>
> * Dropped the per-core locking hunks in
>   drivers/cpufreq/powernv-cpufreq.c since the CPUFreq core takes
>   care of the for us after the following commit which is present in
>   linux-next:
>
> commit 12478cf0c55e5969f740bb38a24b1a0104ae18d8
> Author: Srivatsa S. Bhat 
> Date:   Mon Mar 24 13:35:44 2014 +0530
>
> cpufreq: Make sure frequency transitions are serialized
>
> * [PATCH v5 3/3] gets rid of the powernv_pstate_ids[] array that
>   was being used to record the pstate ids. After the following
>   patch it is safe to use cpufreq_frequency_table.driver_data
>   since it is opaque to the cpufreq core:
>
> From: Viresh Kumar 
> Date: 2014-03-28 13:53:47
> url: http://marc.info/?l=linux-pm&m=139601416804702&w=2
>
> cpufreq: create another field .flags in cpufreq_frequency_table
>
> The patchset is based on the commit
> 201544be8c37dffbf069bb5fc9edb5674f8c1754 of the linux-next tree.
>
> While all the patches in the patchset apply cleanly on linux-next,
> [PATCH v5 3/3] requires the Viresh's patch that was mentioned
> above. Otherwise, the frequency corresponding to pstate id -3 will be
> omited while reporting the "scaling_available_frequencies" in sysfs.
>
> [1]: http://marc.info/?l=linux-pm&m=139585297620612&w=2
>
> Gautham R. Shenoy (2):
>   powernv, cpufreq: Select CPUFreq related Kconfig options for powernv

Make this patch 3/3 (Probably Rafael can do this while applying)

>   powernv,cpufreq: Use cpufreq_frequency_table.driver_data to store
> pstate ids
>
> Vaidyanathan Srinivasan (1):
>   powernv, cpufreq: cpufreq driver for powernv platform

Otherwise,

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


Re: [PATCH v5 1/3] powernv, cpufreq: Select CPUFreq related Kconfig options for powernv

2014-03-30 Thread Viresh Kumar
On 29 March 2014 01:41, Gautham R. Shenoy  wrote:
> From: "Gautham R. Shenoy" 
>
> Enable CPUFreq for PowerNV. Select "performance", "powersave",
> "userspace" and "ondemand" governors. Choose "ondemand" to be the
> default governor.
>
> Signed-off-by: Gautham R. Shenoy 
> Signed-off-by: Srivatsa S. Bhat 
> ---
>  arch/powerpc/configs/pseries_defconfig| 1 +
>  arch/powerpc/configs/pseries_le_defconfig | 1 +
>  arch/powerpc/platforms/powernv/Kconfig| 6 ++
>  3 files changed, 8 insertions(+)

Probably it doesn't make much sense to keep this as the first patch
as you still don't have the driver available yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: update_rq_clock() must skip ONE update

2014-03-30 Thread Mike Galbraith
On Sun, 2014-03-30 at 17:12 -0700, Linus Torvalds wrote: 
> The patch looks fine, but the changelog is so chock-full of odd
> language that I don't know what to do with the patch.
> 
> Is this actually a problem in real life, or just in the drug-induced
> wonderland that Mike was in when writing the changelog?

Point of being verbose was to make sure it was clear exactly how this
harmless little bug selectively kills large IO boxen.. and yeah, I'm
pretty sure this was in the real world, but hey, ya never know, looney
bins are full of people who think they're operating in the real world.

Whatever, I suppose the data suffices.  Magnitudes, their sources and
consequences are irrelevant to the bean counting buglet itself. 

modprobe-134   [000] 5.027903: update_rq_clock <-scheduler_tick
modprobe-134   [000] 5.037857: update_rq_clock <-scheduler_tick
modprobe-134   [000] 5.037864: update_rq_clock <-enqueue_task
modprobe-134   [000] 5.037866: enqueue_task_watchdog: WATCHDOG/0 
enqueue 4915630446
modprobe-134   [000] 5.044965: update_rq_clock <-scheduler_tick
modprobe-134   [000] 5.046275: update_rq_clock <-scheduler_tick
modprobe-134   [000] 5.050274: update_rq_clock <-scheduler_tick
modprobe-134   [000] 5.052862: update_rq_clock <-dequeue_task
modprobe-134   [000] 5.052866: pick_next_task_watchdog: WATCHDOG/0 
select 4915630446
  watchdog/0-7 [000] 5.052868: finish_task_switch: WATCHDOG/0 runs 
5052867644
  watchdog/0-7 [000] 5.052869: watchdog: WATCHDOG/0 DELAYED 
137238048 max: 137238048
  watchdog/0-7 [000] 5.052872: update_rq_clock <-dequeue_task
  watchdog/0-7 [000] 5.052873: dequeue_task_watchdog: WATCHDOG/0 
dequeue 5052872018
  watchdog/0-7 [000] 5.052874: put_prev_task_watchdog: WATCHDOG/0 
STOP trace : delta_exec 137241572 sum_exec 137254287

Cc: 
Signed-off-by:  Mike Galbraith 
---
 kernel/sched/core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -118,7 +118,7 @@ void update_rq_clock(struct rq *rq)
 {
s64 delta;
 
-   if (rq->skip_clock_update > 0)
+   if (rq->skip_clock_update-- > 0)
return;
 
delta = sched_clock_cpu(cpu_of(rq)) - rq->clock;



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


RE: [PATCHv2 2/2] watchdog: imx2_wdt: Add big-endian support

2014-03-30 Thread li.xi...@freescale.com


> Subject: Re: [PATCHv2 2/2] watchdog: imx2_wdt: Add big-endian support
> 
> On 03/25/2014 07:21 PM, Xiubo Li wrote:
> > For the platforms that this IP driver now supports:
> > SoCCPUWatchdog Need 'big-endian'?
> > --
> > Vybird little little   No
> > LS1little big  Yes
> > LS2little little   No
> > IMX+   little little   No
> >
> > So for the LS1 SoCs, we need to do the big endianness converting.
> >
> > And this will also support the following case, for example:
> > SoCCPUWatchdog Need 'big-endian'?
> > --
> > PowerPCbigbig  Yes
> >
> > Signed-off-by: Xiubo Li 
> > Cc: Guenter Roeck 
> 
> Is this patch intended to solve the problem generically ?
> 
> http://www.spinics.net/lists/kernel/msg1714375.html
>

It's actually the following ones first, which will support 16-bits
Values for regmap-mmio:

https://patchwork.kernel.org/patch/3896321/
https://patchwork.kernel.org/patch/3896331/
https://patchwork.kernel.org/patch/3901021/

And the then the following one, which will support the LE endian:
http://www.spinics.net/lists/kernel/msg1714375.html


Thanks :)

BRs
Xiubo




 
> Guenter
> 
> > ---
> >   drivers/watchdog/imx2_wdt.c | 40 +++-
> >   1 file changed, 31 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> > index 1795922..32f8874 100644
> > --- a/drivers/watchdog/imx2_wdt.c
> > +++ b/drivers/watchdog/imx2_wdt.c
> > @@ -30,6 +30,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -64,9 +65,26 @@ static struct {
> > void __iomem *base;
> > unsigned timeout;
> > unsigned long status;
> > +   bool big_endian;
> > struct timer_list timer;/* Pings the watchdog when closed */
> >   } imx2_wdt;
> >
> > +static inline u16 imx2_wdt_readw(void __iomem *addr)
> > +{
> > +   if (imx2_wdt.big_endian)
> > +   return ioread16be(addr);
> > +   else
> > +   return ioread16(addr);
> > +}
> > +
> > +static inline void imx2_wdt_writew(u16 val, void __iomem *addr)
> > +{
> > +   if (imx2_wdt.big_endian)
> > +   iowrite16be(val, addr);
> > +   else
> > +   iowrite16(val, addr);
> > +}
> > +
> >   static struct miscdevice imx2_wdt_miscdev;
> >
> >   static bool nowayout = WATCHDOG_NOWAYOUT;
> > @@ -87,7 +105,7 @@ static const struct watchdog_info imx2_wdt_info = {
> >
> >   static inline void imx2_wdt_setup(void)
> >   {
> > -   u16 val = __raw_readw(imx2_wdt.base + IMX2_WDT_WCR);
> > +   u16 val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WCR);
> >
> > /* Suspend timer in low power mode, write once-only */
> > val |= IMX2_WDT_WCR_WDZST;
> > @@ -100,17 +118,17 @@ static inline void imx2_wdt_setup(void)
> > /* Set the watchdog's Time-Out value */
> > val |= WDOG_SEC_TO_COUNT(imx2_wdt.timeout);
> >
> > -   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> > +   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> >
> > /* enable the watchdog */
> > val |= IMX2_WDT_WCR_WDE;
> > -   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> > +   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> >   }
> >
> >   static inline void imx2_wdt_ping(void)
> >   {
> > -   __raw_writew(IMX2_WDT_SEQ1, imx2_wdt.base + IMX2_WDT_WSR);
> > -   __raw_writew(IMX2_WDT_SEQ2, imx2_wdt.base + IMX2_WDT_WSR);
> > +   imx2_wdt_writew(IMX2_WDT_SEQ1, imx2_wdt.base + IMX2_WDT_WSR);
> > +   imx2_wdt_writew(IMX2_WDT_SEQ2, imx2_wdt.base + IMX2_WDT_WSR);
> >   }
> >
> >   static void imx2_wdt_timer_ping(unsigned long arg)
> > @@ -143,12 +161,12 @@ static void imx2_wdt_stop(void)
> >
> >   static void imx2_wdt_set_timeout(int new_timeout)
> >   {
> > -   u16 val = __raw_readw(imx2_wdt.base + IMX2_WDT_WCR);
> > +   u16 val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WCR);
> >
> > /* set the new timeout value in the WSR */
> > val &= ~IMX2_WDT_WCR_WT;
> > val |= WDOG_SEC_TO_COUNT(new_timeout);
> > -   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> > +   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> >   }
> >
> >   static int imx2_wdt_open(struct inode *inode, struct file *file)
> > @@ -192,7 +210,7 @@ static long imx2_wdt_ioctl(struct file *file, unsigned
> int cmd,
> > return put_user(0, p);
> >
> > case WDIOC_GETBOOTSTATUS:
> > -   val = __raw_readw(imx2_wdt.base + IMX2_WDT_WRSR);
> > +   val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WRSR);
> > new_value = val & IMX2_WDT_WRSR_TOUT ? WDIOF_CARDRESET : 0;
> > return put_user(new_value, p);
> >
> > @@ -257,8 +275,12 @@ static struct miscdevice imx2_wdt_miscdev = {
> >
> >   static int __init imx2_wdt_probe(struct platform_device *pdev)
> >   {
> > -   int ret;
> > +   struct 

Re: [PATCH 6/7] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave

2014-03-30 Thread Hongbo Zhang


On 03/29/2014 09:45 PM, Vinod Koul wrote:

On Fri, Mar 28, 2014 at 02:33:37PM +0800, Hongbo Zhang wrote:

On 03/26/2014 03:01 PM, Vinod Koul wrote:

On Thu, 2014-01-16 at 13:47 +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

The usage of spin_lock_irqsave() is a stronger locking mechanism than is
required throughout the driver. The minimum locking required should be used
instead. Interrupts will be turned off and context will be saved, it is
unnecessary to use irqsave.

This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
manipulation of protected fields is done using tasklet context or weaker, which
makes spin_lock_bh() the correct choice.




  /**
@@ -1124,11 +1120,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
  static void dma_do_tasklet(unsigned long data)
  {
struct fsldma_chan *chan = (struct fsldma_chan *)data;
-   unsigned long flags;
chan_dbg(chan, "tasklet entry\n");
-   spin_lock_irqsave(&chan->desc_lock, flags);
+   spin_lock_bh(&chan->desc_lock);

okay here is the problem :(

You moved to _bh variant. So if you grab the lock in rest of the code
and irq gets triggered then here we will be spinning to grab the lock.
So effectively you made right locking solution into deadlock situation!

If the rest code grabs lock by spin_lock_bh(), and if irq raised,
the tasklet could not be executed because it has been disabled by
the _bh variant function.

yes if you are accessing resources only in tasklet and rest of the code, then
_bh variant works well. The problem here is usage in irq handler



The name dma_do_tasklet may mislead, it is tasklet handler, not irq 
handler, not a trigger to load tasklet.

the irq handler is fsldma_chan_irq, and I don't use lock in it.

If it is the problem, I would like to change dma_do_tasklet to 
dma_tasklet to eliminate misleading.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 for v3.14] AUDIT: Allow login in non-init namespaces

2014-03-30 Thread gaof...@cn.fujitsu.com
On 03/31/2014 07:10 AM, Eric Paris wrote:
> In 3.15 we should have patches to support not only the non-init_net
> (3.14) namespace but also the non-init_pid and non-init_user namespace.
> So all will be right in the world. 

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


Linux 3.14 out

2014-03-30 Thread Linus Torvalds
So we had a few fairly late changes that I could have done without,
but the changelog from -rc8 is still pretty small, and I'm feeling
pretty good about it all. If we did end up with any last-minute
problems due to the final spurt of patches, they'll be pretty
specific, and it really didn't make sense to me to delay the release
without anything known pending. Much of the final spurt were either
marked for stable or known regressions.

So 3.14 is out there, and the merge window for 3.15 is thus open.
Please do spend the time to test out 3.14, though, even if you might
otherwise be in a hurry to send me your pending queue for the next
release.

   Linus

---
Al Viro (6):
  make prepend_name() work correctly when called with negative *buflen
  rcuwalk: recheck mount_lock after mountpoint crossing attempts
  resizable namespace.c hashes
  keep shadowed vfsmounts together
  don't bother with propagate_mnt() unless the target is shared
  switch mnt_hash to hlist

Alex Elder (1):
  rbd: drop an unsafe assertion

Anthony Olech (1):
  Input: da9052_onkey - use correct register bit for key status

Artem Fetishev (1):
  x86: fix boot on uniprocessor systems

Benjamin Tissoires (1):
  Input: synaptics - add manual min/max quirk

Daniel Vetter (1):
  drm/i915: Undo gtt scratch pte unmapping again

Dave Airlie (3):
  drm/udl: take reference to device struct for dma-bufs
  drm/nouveau: fail runtime pm properly.
  drm/radeon: fix runtime suspend breaking secondary GPUs

David Vrabel (1):
  Revert "xen: properly account for _PAGE_NUMA during xen pte translations"

Dmitry Torokhov (1):
  Input: mousedev - fix race when creating mixed device

Elias Vanderstuyft (1):
  Input: don't modify the id of ioctl-provided ff effect on upload failure

Eric Biggers (2):
  vfs: atomic f_pos access in llseek()
  vfs: Don't let __fdget_pos() get FMODE_PATH files

Eric Dumazet (2):
  net: unix: non blocking recvmsg() should not return -EINTR
  tcp: fix get_timewait4_sock() delay computation on 64bit

Eric Paris (1):
  AUDIT: Allow login in non-init namespaces

Flavio Leitner (1):
  openvswitch: fix a possible deadlock and lockdep warning

Hannes Frederic Sowa (1):
  ipv6: move DAD and addrconf_verify processing to workqueue

Hans de Goede (2):
  Input: cypress_ps2 - don't report as a button pads
  Input: synaptics - add manual min/max quirk for ThinkPad X240

J. R. Okajima (1):
  nfsd: fix lost nfserrno() call in nfsd_setattr()

Jan Kara (2):
  fs: Avoid userspace mounting anon_inodefs filesystem
  vfs: Allocate anon_inode_inode in anon_inode_init()

Jason Wang (1):
  virtio-net: correct error handling of virtqueue_kick()

Jay Vosburgh (1):
  MAINTAINERS: bonding: change email address

Jean-Francois Dagenais (1):
  Input: adp5588-keys - get value from data out when dir is out

John Stultz (1):
  time: Revert to calling clock_was_set_delayed() while in irq context

Linus Torvalds (2):
  fs: remove now stale label in anon_inode_init()
  Linux 3.14

Michael S. Tsirkin (2):
  vhost: fix total length when packets are too short
  vhost: validate vhost_get_vq_desc return value

Oliver Neukum (1):
  usbnet: include wait queue head in device structure

Pravin B Shelar (1):
  ip_tunnel: Fix dst ref-count.

Randy Dunlap (1):
  MAINTAINERS: resume as Documentation maintainer

Sasha Levin (3):
  random32: assign to network folks in MAINTAINERS
  random32: avoid attempt to late reseed if in the middle of seeding
  ocfs2: check if cluster name exists before deref

Scott Wood (1):
  i2c: cpm: Fix build by adding of_address.h and of_irq.h

Steven Rostedt (Red Hat) (1):
  tracing: Fix traceon trigger condition to actually turn tracing on

Theodore Ts'o (1):
  ext4: atomically set inode->i_flags in ext4_set_inode_flags()

Thomas Petazzoni (3):
  net: mvneta: rename MVNETA_GMAC2_PSC_ENABLE to MVNETA_GMAC2_PCS_ENABLE
  net: mvneta: fix usage as a module on RGMII configurations
  net: mvneta: use devm_ioremap_resource() instead of of_iomap()

Toshiaki Makita (2):
  bridge: Fix inabillity to retrieve vlan tags when tx offload is disabled
  bridge: Fix handling stacked vlan tags

Veaceslav Falico (1):
  MAINTAINERS: bonding: change email address

Vlad Yasevich (8):
  tg3: Do not include vlan acceleration features in vlan_features
  vlan: Set hard_header_len according to available acceleration
  net: Account for all vlan headers in skb_mac_gso_segment
  bridge: Fix crash with vlan filtering and tcpdump
  qlge: Do not propaged vlan tag offloads to vlans
  ifb: Remove vlan acceleration from vlan_features
  veth: Turn off vlan rx acceleration in vlan_features
  vlan: Warn the user if lowerdev has bad vlan features.

Wei Liu (1):
  xen/balloon: flush persistent kmaps in correct position

Wei Yang (1):
  net/mlx4_core:

Re: Promela/spin model for NO_HZ_FULL_SYSIDLE code

2014-03-30 Thread Paul E. McKenney
On Mon, Mar 31, 2014 at 03:29:25AM +, Mathieu Desnoyers wrote:
> - Original Message -
> > From: "Paul E. McKenney" 
> > To: fweis...@gmail.com, "mathieu desnoyers" 
> > , pet...@infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > Sent: Sunday, March 30, 2014 7:08:56 PM
> > Subject: Promela/spin model for NO_HZ_FULL_SYSIDLE code
> > 
> > For whatever it is worth, the following model claims safety and progress
> > for the sysidle state machine.
> > 
> > Thoughts?
> 
> Hi Paul,
> 
> Please keep in mind that it's been a while since I've looked at Promela
> proofs, but a couple of questions come to mind. First, how is the execution
> script below checking for progress in any way ? I remember that we used
> the negation of a "_np" LTL claim to check for progress in the past.
> Moreover, I'd be much more comfortable seeing ifdefs in the code that inject
> known failures, and let them be triggered by error-triggering runs in the
> scripts (with e.g. -DINJECT_ERROR_XYZ), to confirm that this model actually
> catches known issues.

Well, if I comment out the four "progress_" labels, it complains about
a non-progress cycle.  So at least spin does pay attention to these.  ;-)

If I put the "progress_" labels back in, but change the check so as to
prevent the state machine from ever entering RCU_SYSIDLE_FULL_NOTED,
it cranks through 14M states before complaining about a non-progress cycle,
as expected.

If I revert back to pristine state, and then comment out the statements
that reverts state back to RCU_SYSIDLE_NOT when exiting idle, an assert()
triggers, as expected.

> If we can show that the model can detect a few failure modes, both for safety
> and progress, then my confidence level in the model will start to improve. ;-)

Well, there probably is a bug in there somewhere, Murphy being who he is.  ;-)

Thanx, Paul

> Thanks,
> 
> Mathieu
> 
> > 
> > Thanx, Paul
> > 
> > 
> > sysidle.sh
> > 
> > spin -a sysidle.spin
> > cc -DNP -o pan pan.c
> > # Fair scheduling to focus progress checks in timekeeper.
> > ./pan -f -l -m128 -w22
> > 
> > 
> > sysidle.spin
> > 
> > /*
> >  * Promela model for CONFIG_NO_HZ_FULL_SYSIDLE=y in the Linux kernel.
> >  * This model assumes that the dyntick-idle bit manipulation works based
> >  * on long usage, and substitutes a per-thread boolean "am_busy[]" array
> >  * for the Linux kernel's dyntick-idle masks.  The focus of this model
> >  * is therefore on the state machine itself.  Checks for both safety and
> >  * forward progress.
> >  *
> >  * This program is free software; you can redistribute it and/or modify
> >  * it under the terms of the GNU General Public License as published by
> >  * the Free Software Foundation; either version 2 of the License, or
> >  * (at your option) any later version.
> >  *
> >  * This program is distributed in the hope that it will be useful,
> >  * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >  * GNU General Public License for more details.
> >  *
> >  * You should have received a copy of the GNU General Public License
> >  * along with this program; if not, you can access it online at
> >  * http://www.gnu.org/licenses/gpl-2.0.html.
> >  *
> >  * Copyright IBM Corporation, 2014
> >  *
> >  * Author: Paul E. McKenney 
> >  */
> > 
> > #define NUM_WORKERS 3
> > 
> > byte wakeup_timekeeper = 0; /* Models rcu_kick_nohz_cpu(). */
> > 
> > #define RCU_SYSIDLE_NOT 0   /* Some CPU is not idle. */
> > #define RCU_SYSIDLE_SHORT   1   /* All CPUs idle for brief period. */
> > #define RCU_SYSIDLE_LONG2   /* All CPUs idle for long enough. */
> > #define RCU_SYSIDLE_FULL3   /* All CPUs idle, ready for sysidle. */
> > #define RCU_SYSIDLE_FULL_NOTED  4   /* Actually entered sysidle 
> > state. */
> > 
> > byte full_sysidle_state = RCU_SYSIDLE_NOT;
> > 
> > byte am_busy[NUM_WORKERS];  /* Busy is similar to "not dyntick-idle". */
> > byte am_setup[NUM_WORKERS]; /* Setup means timekeeper knows I am not idle. 
> > */
> > 
> > /*
> >  * Non-timekeeping CPU going into and out of dyntick-idle state.
> >  */
> > proctype worker(byte me)
> > {
> > byte oldstate;
> > 
> > do
> > :: 1 ->
> > /* Go idle. */
> > am_setup[me] = 0;
> > am_busy[me] = 0;
> > 
> > /* Dyntick-idle in the following loop. */
> > do
> > :: 1 -> skip;
> > :: 1 -> break;
> > od;
> > 
> > /* Exit idle loop, model getting out of dyntick idle state.

[PATCH] Documentation/java.txt: add Java 7 support

2014-03-30 Thread Jonathan Callen
The sample wrapper currently fails on some Java 7 .class files.  This
updates the wrapper to properly handle those files.

Signed-off-by: Jonathan Callen 
---
 Documentation/java.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/java.txt b/Documentation/java.txt
index e6a7232..4180205 100644
--- a/Documentation/java.txt
+++ b/Documentation/java.txt
@@ -188,6 +188,9 @@ shift
 #define CP_METHODREF 10
 #define CP_INTERFACEMETHODREF 11
 #define CP_NAMEANDTYPE 12
+#define CP_METHODHANDLE 15
+#define CP_METHODTYPE 16
+#define CP_INVOKEDYNAMIC 18
 
 /* Define some commonly used error messages */
 
@@ -242,14 +245,19 @@ void skip_constant(FILE *classfile, u_int16_t *cur)
break;
case CP_CLASS:
case CP_STRING:
+   case CP_METHODTYPE:
seekerr = fseek(classfile, 2, SEEK_CUR);
break;
+   case CP_METHODHANDLE:
+   seekerr = fseek(classfile, 3, SEEK_CUR);
+   break;
case CP_INTEGER:
case CP_FLOAT:
case CP_FIELDREF:
case CP_METHODREF:
case CP_INTERFACEMETHODREF:
case CP_NAMEANDTYPE:
+   case CP_INVOKEDYNAMIC:
seekerr = fseek(classfile, 4, SEEK_CUR);
break;
case CP_LONG:
-- 
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] Documentation: trivial spelling error changes

2014-03-30 Thread Randy Dunlap
On 03/29/2014 05:54 PM, Carlos wrote:
> Fixed multiple spelling errors.
> 
> Signed-off-by: Carlos E. Garcia 
> ---
>  Documentation/DMA-attributes.txt |  2 +-
>  Documentation/block/biodoc.txt   |  8 
>  Documentation/block/cfq-iosched.txt  |  2 +-
>  Documentation/cgroups/net_prio.txt   |  4 ++--
>  Documentation/devicetree/bindings/arm/omap/omap.txt  |  2 +-
>  Documentation/devicetree/bindings/bus/mvebu-mbus.txt |  2 +-
>  Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt |  2 +-
>  Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt |  2 +-
>  Documentation/devicetree/bindings/mmc/samsung-sdhci.txt  |  2 +-
>  Documentation/devicetree/bindings/mtd/gpmc-nand.txt  |  2 +-
>  Documentation/devicetree/bindings/mtd/gpmc-nor.txt   |  2 +-
>  Documentation/devicetree/bindings/mtd/gpmc-onenand.txt   |  2 +-
>  .../devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt| 12 
> ++--
>  Documentation/devicetree/bindings/powerpc/4xx/reboot.txt |  2 +-
>  Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt   |  2 +-
>  Documentation/devicetree/bindings/regulator/regulator.txt|  2 +-
>  Documentation/devicetree/bindings/spi/spi-bus.txt|  2 +-
>  Documentation/dma-buf-sharing.txt|  2 +-
>  Documentation/dynamic-debug-howto.txt|  2 +-
>  Documentation/edac.txt   |  2 +-
>  Documentation/fb/sm501.txt   |  2 +-
>  Documentation/fb/sstfb.txt   |  2 +-
>  Documentation/filesystems/path-lookup.txt|  2 +-
>  Documentation/filesystems/proc.txt   |  4 ++--
>  Documentation/filesystems/sharedsubtree.txt  |  2 +-
>  Documentation/gpio/consumer.txt  |  2 +-
>  Documentation/hid/uhid.txt   |  2 +-
>  Documentation/input/alps.txt |  2 +-
>  Documentation/input/input.txt|  2 +-
>  Documentation/ioctl/hdio.txt |  4 ++--
>  Documentation/mtd/nand/pxa3xx-nand.txt   |  2 +-
>  Documentation/networking/can.txt | 10 +-
>  Documentation/networking/dccp.txt|  2 +-
>  Documentation/networking/ip-sysctl.txt   | 10 +-
>  Documentation/powerpc/transactional_memory.txt   |  2 +-
>  Documentation/rbtree.txt |  2 +-
>  Documentation/rfkill.txt |  2 +-
>  Documentation/robust-futexes.txt |  2 +-
>  Documentation/s390/monreader.txt |  2 +-
>  Documentation/scsi/53c700.txt|  2 +-
>  Documentation/scsi/dc395x.txt|  2 +-
>  Documentation/scsi/ncr53c8xx.txt |  8 
>  Documentation/scsi/scsi_mid_low_api.txt  |  8 
>  Documentation/scsi/sym53c8xx_2.txt   |  6 +++---
>  Documentation/scsi/tmscsim.txt   | 10 +-
>  Documentation/security/Yama.txt  |  2 +-
>  Documentation/serial/tty.txt |  4 ++--
>  Documentation/sound/alsa/ALSA-Configuration.txt  |  4 ++--
>  Documentation/sysctl/net.txt |  2 +-
>  Documentation/trace/events.txt   |  2 +-
>  Documentation/usb/WUSB-Design-overview.txt   |  2 +-
>  Documentation/usb/mass-storage.txt   |  2 +-
>  Documentation/virtual/kvm/api.txt|  2 +-
>  Documentation/vm/transhuge.txt   |  4 ++--
>  Documentation/workqueue.txt  |  2 +-
>  Documentation/x86/earlyprintk.txt|  2 +-
>  Documentation/x86/i386/IO-APIC.txt   |  2 +-
>  57 files changed, 91 insertions(+), 91 deletions(-)
> 
> diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
> index 2101e71..104589b 100644
> --- a/Documentation/block/biodoc.txt
> +++ b/Documentation/block/biodoc.txt
> @@ -732,7 +732,7 @@ direct access requests which only specify rq->buffer 
> without a valid rq->bio)
>  3.2.5.1 Tag helpers
>  
>  Block now offers some simple generic functionality to help support command
> -queueing (typically known as tagged command queueing), ie manage more than
> +queuing (typically known as tagged command queuing), ie manage more than


Hi,

I think that it's going to be difficult to spell "queu[e]ing" consistently
in all of the ker

Re: Promela/spin model for NO_HZ_FULL_SYSIDLE code

2014-03-30 Thread Mathieu Desnoyers
- Original Message -
> From: "Mathieu Desnoyers" 
> To: paul...@linux.vnet.ibm.com
> Cc: fweis...@gmail.com, pet...@infradead.org, linux-kernel@vger.kernel.org
> Sent: Sunday, March 30, 2014 11:29:25 PM
> Subject: Re: Promela/spin model for NO_HZ_FULL_SYSIDLE code
> 
> - Original Message -
> > From: "Paul E. McKenney" 
> > To: fweis...@gmail.com, "mathieu desnoyers"
> > , pet...@infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > Sent: Sunday, March 30, 2014 7:08:56 PM
> > Subject: Promela/spin model for NO_HZ_FULL_SYSIDLE code
> > 
> > For whatever it is worth, the following model claims safety and progress
> > for the sysidle state machine.
> > 
> > Thoughts?
> 
> Hi Paul,
> 
> Please keep in mind that it's been a while since I've looked at Promela
> proofs, but a couple of questions come to mind. First, how is the execution
> script below checking for progress in any way ? I remember that we used
> the negation of a "_np" LTL claim to check for progress in the past.
> Moreover, I'd be much more comfortable seeing ifdefs in the code that inject
> known failures, and let them be triggered by error-triggering runs in the
> scripts (with e.g. -DINJECT_ERROR_XYZ), to confirm that this model actually
> catches known issues.
> 
> If we can show that the model can detect a few failure modes, both for safety
> and progress, then my confidence level in the model will start to improve.
> ;-)

Digging through the spin documentation, "-l" is indeed another way besides
the _np LTL negation to find non-progress cycles.

Still, injecting known failures would let us learn a lot about the model
error detection abilities.

Thanks!

Mathieu


> 
> Thanks,
> 
> Mathieu
> 
> > 
> > Thanx, Paul
> > 
> > 
> > sysidle.sh
> > 
> > spin -a sysidle.spin
> > cc -DNP -o pan pan.c
> > # Fair scheduling to focus progress checks in timekeeper.
> > ./pan -f -l -m128 -w22
> > 
> > 
> > sysidle.spin
> > 
> > /*
> >  * Promela model for CONFIG_NO_HZ_FULL_SYSIDLE=y in the Linux kernel.
> >  * This model assumes that the dyntick-idle bit manipulation works based
> >  * on long usage, and substitutes a per-thread boolean "am_busy[]" array
> >  * for the Linux kernel's dyntick-idle masks.  The focus of this model
> >  * is therefore on the state machine itself.  Checks for both safety and
> >  * forward progress.
> >  *
> >  * This program is free software; you can redistribute it and/or modify
> >  * it under the terms of the GNU General Public License as published by
> >  * the Free Software Foundation; either version 2 of the License, or
> >  * (at your option) any later version.
> >  *
> >  * This program is distributed in the hope that it will be useful,
> >  * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >  * GNU General Public License for more details.
> >  *
> >  * You should have received a copy of the GNU General Public License
> >  * along with this program; if not, you can access it online at
> >  * http://www.gnu.org/licenses/gpl-2.0.html.
> >  *
> >  * Copyright IBM Corporation, 2014
> >  *
> >  * Author: Paul E. McKenney 
> >  */
> > 
> > #define NUM_WORKERS 3
> > 
> > byte wakeup_timekeeper = 0; /* Models rcu_kick_nohz_cpu(). */
> > 
> > #define RCU_SYSIDLE_NOT 0   /* Some CPU is not idle. */
> > #define RCU_SYSIDLE_SHORT   1   /* All CPUs idle for brief period. */
> > #define RCU_SYSIDLE_LONG2   /* All CPUs idle for long enough. */
> > #define RCU_SYSIDLE_FULL3   /* All CPUs idle, ready for sysidle. */
> > #define RCU_SYSIDLE_FULL_NOTED  4   /* Actually entered sysidle 
> > state. */
> > 
> > byte full_sysidle_state = RCU_SYSIDLE_NOT;
> > 
> > byte am_busy[NUM_WORKERS];  /* Busy is similar to "not dyntick-idle". */
> > byte am_setup[NUM_WORKERS]; /* Setup means timekeeper knows I am not idle.
> > */
> > 
> > /*
> >  * Non-timekeeping CPU going into and out of dyntick-idle state.
> >  */
> > proctype worker(byte me)
> > {
> > byte oldstate;
> > 
> > do
> > :: 1 ->
> > /* Go idle. */
> > am_setup[me] = 0;
> > am_busy[me] = 0;
> > 
> > /* Dyntick-idle in the following loop. */
> > do
> > :: 1 -> skip;
> > :: 1 -> break;
> > od;
> > 
> > /* Exit idle loop, model getting out of dyntick idle state. */
> > am_busy[me] = 1;
> > 
> > /* Get state out of full-system idle states. */
> > atomic {
> > oldstate = full_sysidle_state;
> > if
> >   

Re: [PATCHv2 2/2] watchdog: imx2_wdt: Add big-endian support

2014-03-30 Thread Guenter Roeck

On 03/25/2014 07:21 PM, Xiubo Li wrote:

For the platforms that this IP driver now supports:
SoCCPUWatchdog Need 'big-endian'?
--
Vybird little little   No
LS1little big  Yes
LS2little little   No
IMX+   little little   No

So for the LS1 SoCs, we need to do the big endianness converting.

And this will also support the following case, for example:
SoCCPUWatchdog Need 'big-endian'?
--
PowerPCbigbig  Yes

Signed-off-by: Xiubo Li 
Cc: Guenter Roeck 


Is this patch intended to solve the problem generically ?

http://www.spinics.net/lists/kernel/msg1714375.html

Guenter


---
  drivers/watchdog/imx2_wdt.c | 40 +++-
  1 file changed, 31 insertions(+), 9 deletions(-)

diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 1795922..32f8874 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -30,6 +30,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -64,9 +65,26 @@ static struct {
void __iomem *base;
unsigned timeout;
unsigned long status;
+   bool big_endian;
struct timer_list timer;/* Pings the watchdog when closed */
  } imx2_wdt;

+static inline u16 imx2_wdt_readw(void __iomem *addr)
+{
+   if (imx2_wdt.big_endian)
+   return ioread16be(addr);
+   else
+   return ioread16(addr);
+}
+
+static inline void imx2_wdt_writew(u16 val, void __iomem *addr)
+{
+   if (imx2_wdt.big_endian)
+   iowrite16be(val, addr);
+   else
+   iowrite16(val, addr);
+}
+
  static struct miscdevice imx2_wdt_miscdev;

  static bool nowayout = WATCHDOG_NOWAYOUT;
@@ -87,7 +105,7 @@ static const struct watchdog_info imx2_wdt_info = {

  static inline void imx2_wdt_setup(void)
  {
-   u16 val = __raw_readw(imx2_wdt.base + IMX2_WDT_WCR);
+   u16 val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WCR);

/* Suspend timer in low power mode, write once-only */
val |= IMX2_WDT_WCR_WDZST;
@@ -100,17 +118,17 @@ static inline void imx2_wdt_setup(void)
/* Set the watchdog's Time-Out value */
val |= WDOG_SEC_TO_COUNT(imx2_wdt.timeout);

-   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
+   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);

/* enable the watchdog */
val |= IMX2_WDT_WCR_WDE;
-   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
+   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
  }

  static inline void imx2_wdt_ping(void)
  {
-   __raw_writew(IMX2_WDT_SEQ1, imx2_wdt.base + IMX2_WDT_WSR);
-   __raw_writew(IMX2_WDT_SEQ2, imx2_wdt.base + IMX2_WDT_WSR);
+   imx2_wdt_writew(IMX2_WDT_SEQ1, imx2_wdt.base + IMX2_WDT_WSR);
+   imx2_wdt_writew(IMX2_WDT_SEQ2, imx2_wdt.base + IMX2_WDT_WSR);
  }

  static void imx2_wdt_timer_ping(unsigned long arg)
@@ -143,12 +161,12 @@ static void imx2_wdt_stop(void)

  static void imx2_wdt_set_timeout(int new_timeout)
  {
-   u16 val = __raw_readw(imx2_wdt.base + IMX2_WDT_WCR);
+   u16 val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WCR);

/* set the new timeout value in the WSR */
val &= ~IMX2_WDT_WCR_WT;
val |= WDOG_SEC_TO_COUNT(new_timeout);
-   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
+   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
  }

  static int imx2_wdt_open(struct inode *inode, struct file *file)
@@ -192,7 +210,7 @@ static long imx2_wdt_ioctl(struct file *file, unsigned int 
cmd,
return put_user(0, p);

case WDIOC_GETBOOTSTATUS:
-   val = __raw_readw(imx2_wdt.base + IMX2_WDT_WRSR);
+   val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WRSR);
new_value = val & IMX2_WDT_WRSR_TOUT ? WDIOF_CARDRESET : 0;
return put_user(new_value, p);

@@ -257,8 +275,12 @@ static struct miscdevice imx2_wdt_miscdev = {

  static int __init imx2_wdt_probe(struct platform_device *pdev)
  {
-   int ret;
+   struct device_node *np = pdev->dev.of_node;
struct resource *res;
+   int ret;
+
+   if (np)
+   imx2_wdt.big_endian = of_property_read_bool(np, "big-endian");

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
imx2_wdt.base = devm_ioremap_resource(&pdev->dev, res);



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Promela/spin model for NO_HZ_FULL_SYSIDLE code

2014-03-30 Thread Mathieu Desnoyers
- Original Message -
> From: "Paul E. McKenney" 
> To: fweis...@gmail.com, "mathieu desnoyers" , 
> pet...@infradead.org
> Cc: linux-kernel@vger.kernel.org
> Sent: Sunday, March 30, 2014 7:08:56 PM
> Subject: Promela/spin model for NO_HZ_FULL_SYSIDLE code
> 
> For whatever it is worth, the following model claims safety and progress
> for the sysidle state machine.
> 
> Thoughts?

Hi Paul,

Please keep in mind that it's been a while since I've looked at Promela
proofs, but a couple of questions come to mind. First, how is the execution
script below checking for progress in any way ? I remember that we used
the negation of a "_np" LTL claim to check for progress in the past.
Moreover, I'd be much more comfortable seeing ifdefs in the code that inject
known failures, and let them be triggered by error-triggering runs in the
scripts (with e.g. -DINJECT_ERROR_XYZ), to confirm that this model actually
catches known issues.

If we can show that the model can detect a few failure modes, both for safety
and progress, then my confidence level in the model will start to improve. ;-)

Thanks,

Mathieu

> 
>   Thanx, Paul
> 
> 
> sysidle.sh
> 
> spin -a sysidle.spin
> cc -DNP -o pan pan.c
> # Fair scheduling to focus progress checks in timekeeper.
> ./pan -f -l -m128 -w22
> 
> 
> sysidle.spin
> 
> /*
>  * Promela model for CONFIG_NO_HZ_FULL_SYSIDLE=y in the Linux kernel.
>  * This model assumes that the dyntick-idle bit manipulation works based
>  * on long usage, and substitutes a per-thread boolean "am_busy[]" array
>  * for the Linux kernel's dyntick-idle masks.  The focus of this model
>  * is therefore on the state machine itself.  Checks for both safety and
>  * forward progress.
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
>  * the Free Software Foundation; either version 2 of the License, or
>  * (at your option) any later version.
>  *
>  * This program is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  * GNU General Public License for more details.
>  *
>  * You should have received a copy of the GNU General Public License
>  * along with this program; if not, you can access it online at
>  * http://www.gnu.org/licenses/gpl-2.0.html.
>  *
>  * Copyright IBM Corporation, 2014
>  *
>  * Author: Paul E. McKenney 
>  */
> 
> #define NUM_WORKERS 3
> 
> byte wakeup_timekeeper = 0; /* Models rcu_kick_nohz_cpu(). */
> 
> #define RCU_SYSIDLE_NOT   0   /* Some CPU is not idle. */
> #define RCU_SYSIDLE_SHORT 1   /* All CPUs idle for brief period. */
> #define RCU_SYSIDLE_LONG  2   /* All CPUs idle for long enough. */
> #define RCU_SYSIDLE_FULL  3   /* All CPUs idle, ready for sysidle. */
> #define RCU_SYSIDLE_FULL_NOTED4   /* Actually entered sysidle 
> state. */
> 
> byte full_sysidle_state = RCU_SYSIDLE_NOT;
> 
> byte am_busy[NUM_WORKERS];  /* Busy is similar to "not dyntick-idle". */
> byte am_setup[NUM_WORKERS]; /* Setup means timekeeper knows I am not idle. */
> 
> /*
>  * Non-timekeeping CPU going into and out of dyntick-idle state.
>  */
> proctype worker(byte me)
> {
>   byte oldstate;
> 
>   do
>   :: 1 ->
>   /* Go idle. */
>   am_setup[me] = 0;
>   am_busy[me] = 0;
> 
>   /* Dyntick-idle in the following loop. */
>   do
>   :: 1 -> skip;
>   :: 1 -> break;
>   od;
> 
>   /* Exit idle loop, model getting out of dyntick idle state. */
>   am_busy[me] = 1;
> 
>   /* Get state out of full-system idle states. */
>   atomic {
>   oldstate = full_sysidle_state;
>   if
>   :: oldstate > RCU_SYSIDLE_SHORT ->
>   full_sysidle_state = RCU_SYSIDLE_NOT;
>   :: else -> skip;
>   fi;
>   }
> 
>   /* If needed, wake up the timekeeper. */
>   if
>   :: oldstate == RCU_SYSIDLE_FULL_NOTED ->
>   wakeup_timekeeper = 1;
>   :: else -> skip;
>   fi;
> 
>   /* Mark ourselves fully awake and operational. */
>   am_setup[me] = 1;
> 
>   /* We are fully awake, so timekeeper must not be asleep. */
>   assert(full_sysidle_state < RCU_SYSIDLE_FULL);
> 
>   /* Running in ke

Re: [PATCH v2 16/29] ktap: add amalgamation build(kernel/trace/ktap/amalg.c)

2014-03-30 Thread Jovi Zhangwei
On Mon, Mar 31, 2014 at 10:17 AM, Li Zefan  wrote:
> On 2014/3/28 22:45, Jovi Zhangwei wrote:
>> This compiles the ktapvm as one huge C file and allows
>> GCC to generate faster and shorter code.
>>
>> No amalgamation build in x86_64:
>> ktapvm.ko: 3.1M
>>
>> amalgamation build in x86_64:
>> ktapvm.ko: 1.1M
>>
>> User can set use amalgamation build or not in Makefile.
>>
>> (Need to analyze further why have so big differences)
>>
>
> Let's drop this patch for now to make the patchset smaller ?
>
Sure, I will analyze the size difference and find the root cause offline.

Thanks for this suggestion.

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


linux-next Documentation merge request

2014-03-30 Thread Randy Dunlap
Hi Stephen,

Please include http://www.infradead.org/~rdunlap/Doc/patches/ in linux-next.
This is a quilt patch series (initially empty).

thanks,
-- 
~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] ipc,shm: increase default size for shmmax

2014-03-30 Thread Davidlohr Bueso
From: Davidlohr Bueso 

The default size is, and always has been, 32Mb. Today, in the
XXI century, it seems that this value is rather small, making
users have to increase it via sysctl, which can cause unnecessary
work and userspace application workarounds[1]. I have arbitrarily
chosen a 4x increase, leaving it at 128Mb, and naturally, the
same goes for shmall. While it may make more sense to set the value
based on the system memory, this limit must be the same across all
systems, and left to users to change if needed.

[1]: http://rhaas.blogspot.com/2012/06/absurd-shared-memory-limits.html

Signed-off-by: Davidlohr Bueso 
---
 include/uapi/linux/shm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
index 78b6941..754b605 100644
--- a/include/uapi/linux/shm.h
+++ b/include/uapi/linux/shm.h
@@ -12,7 +12,7 @@
  * be increased by sysctl
  */
 
-#define SHMMAX 0x200/* max shared seg size (bytes) */
+#define SHMMAX 0x800/* max shared seg size (bytes) */
 #define SHMMIN 1/* min shared seg size (bytes) */
 #define SHMMNI 4096 /* max num of segs system wide */
 #ifndef __KERNEL__
-- 
1.8.1.4



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


linux-next: manual merge of the drm tree with Linus' tree

2014-03-30 Thread Stephen Rothwell
Hi Dave,

Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/i915_gem_gtt.c between commit 8ee661b50561
("drm/i915: Undo gtt scratch pte unmapping again") from Linus' tree and
commit 782f149523d3 ("drm/i915: Make clear/insert vfuncs args absolute")
from the drm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem_gtt.c
index d278be110805,63a6dc7a6bb6..
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@@ -840,9 -1337,9 +1337,9 @@@ void i915_gem_suspend_gtt_mappings(stru
i915_check_and_clear_faults(dev);
  
dev_priv->gtt.base.clear_range(&dev_priv->gtt.base,
-  dev_priv->gtt.base.start / PAGE_SIZE,
-  dev_priv->gtt.base.total / PAGE_SIZE,
+  dev_priv->gtt.base.start,
+  dev_priv->gtt.base.total,
 - false);
 + true);
  }
  
  void i915_gem_restore_gtt_mappings(struct drm_device *dev)


pgp9myKkpGqVT.pgp
Description: PGP signature


Re: [PATCH 3.2 153/200] powerpc/le: Ensure that the 'stop-self' RTAS token is handled correctly

2014-03-30 Thread Tony Breeds
On Mon, Mar 31, 2014 at 12:23:35AM +0100, Ben Hutchings wrote:
> 3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

This patch doesn't need to go back beyond 3.10, so it's safe to drop
from your queue.

Thanks Ben.

Yours Tony


pgpWVFxHj6PTy.pgp
Description: PGP signature


Re: [PATCH v2 10/29] ktap: add string handling code(kernel/trace/ktap/kp_[str|mempool].[c|h])

2014-03-30 Thread Jovi Zhangwei
On Mon, Mar 31, 2014 at 1:19 AM, Andi Kleen  wrote:
>> See test/benchmark/cmp_table.sh, that script compare
>
> Is that a realistic tracing scenario?
>
Yes, it's quite common to use string key in dynamic tracing tool,
for example, See samples/userspace/glibc_func_hist.kp

var s = {}

trace probe:/lib64/libc.so.6:* {
s[probename] += 1
}

trace_end {
print_hist(s)
}


Result:

Tracing... Hit Ctrl-C to end.
^C
 value - Distribution - count
  _IO_sputbackc |@@108344
 __GI__IO_sputbackc |@@107768
 _IO_default_xsputn |  46639
__GI__IO_default_xsputn |  46624
   free |  36871
__libc_free |  36841
  cfree |  36841
 __free |  36811
__cfree |  36811
   __GI___libc_free |  36804
strtoull_l_internal |  28670
__GI_strtoul_l_internal |  28670
   __GI_strtoull_l_internal |  28518
 strtoul_l_internal |  28518
  strchrnul |  27763
__strchrnul |  27741
   _IO_putc |  27589
  __GI__IO_putc |  27589
   putc |  27589
... |

Above script output histogram of glibc function call, you will know
which function will be called frequently, a very useful script.

'probename' return probe name string, then insert table as key.
The magic of above script is there have no string copy and string hash
in probe context, because probename string is interned.


>> table operation between ktap with stap, the result is very
>> inspiring, ktap table operation overhead is quite lower than
>> stap, especially when use constant string key.
>
> Ok fair enough.
>
>>
>> But I agree with you partly, because in some cases we don't
>> want/need to interning all string, for example:
>> trace xxx:yyy {
>> var str = cast("char *", arg1)
>> print(str)
>> }
>>
>> In above case, arg1 is a long kernel string, and no table insert,
>> so definitely no need to interned, so we need to add
>> KTAP_TRAWSTR to represent these values.
>
> Please don't make it more complicated. If there's a good rationale
> for interning it' ok to use always.
>
> It would be better to find ways to simplify things.
>
Definitely, the reason I implement ktap based on lua is the simplicity
and efficiency of lua.

The whole bytecode design and value type is very simple, it could
build a complete safe sandbox for kernel scripting, and easy to
extend to fulfill our need(like multi-key table, aggregation)

Thanks.

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


linux-next: manual merge of the net-next tree with the net tree

2014-03-30 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/xen-netback/netback.c between commit 1425c7a4e8d3
("xen-netback: BUG_ON in xenvif_rx_action() not catching overflow") from
the net tree and commit 8f13dd961228 ("xen-netback: Use skb->cb for
pending_idx") from the net-next tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/net/xen-netback/netback.c
index cd0bd95ccc14,cb784fe5220c..
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@@ -531,13 -539,8 +560,11 @@@ static void xenvif_rx_action(struct xen
} else
vif->rx_last_skb_slots = 0;
  
-   sco = (struct skb_cb_overlay *)skb->cb;
- 
 +  old_req_cons = vif->rx.req_cons;
-   sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
+   XENVIF_RX_CB(skb)->meta_slots_used = xenvif_gop_skb(skb, &npo);
 -  BUG_ON(XENVIF_RX_CB(skb)->meta_slots_used > max_slots_needed);
 +  ring_slots_used = vif->rx.req_cons - old_req_cons;
 +
 +  BUG_ON(ring_slots_used > max_slots_needed);
  
__skb_queue_tail(&rxq, skb);
}


pgpM0aL0BEUWL.pgp
Description: PGP signature


Fwd: Re: [PATCH v2] input: misc: Add driver for Intel Bay Trail GPIO buttons

2014-03-30 Thread Zhu, Lejun
Hi Dmitry,

On 3/29/2014 4:47 AM, Dmitry Torokhov wrote:
> Hi Lejun,
> 
> On Fri, Mar 28, 2014 at 02:02:43AM +0800, Zhu, Lejun wrote:
>> +
>> +static struct soc_button_info soc_button_tbl[] = {
>> +{"power", 0, KEY_POWER, 0, 1, -1},
>> +{"home", 1, KEY_HOME, 0, 1, -1},
>> +{"volume_up", 2, KEY_VOLUMEUP, 1, 0, -1},
>> +{"volume_down", 3, KEY_VOLUMEDOWN, 1, 0, -1},
>> +{"rotation_lock", 4, KEY_RO, 0, 0, -1},
> 
> KEY_RO is not for rotating but rather for switching one of Japanese
> layouts. I think we shoudl allow using switchws and use SW_ROTATE_LOCK
> for that.
> 
> Also I do not quite like so many static structures, what do you think
> about the version below?
> 
> Thanks!
> 

Your version looks fine. I have tested it and fixed a couple glitches
(+1 vs ++ at line 87, and check gpio < 0 at line 94).

Also, yu-sheng Chen suggests that we'd better look for PNP0C40, which is
the compatible ID defined in the spec and will probably match a broader
range of devices.

I attached the updated version below. What do you think?

Thanks.
Lejun
--

Input: misc - Add driver for Intel Bay Trail GPIO buttons

From: Lejun Zhu 

This patch adds support for the GPIO buttons on some Intel Bay Trail
tablets originally running Windows 8. The ACPI description of these
buttons follows "Windows ACPI Design Guide for SoC Platforms".

Signed-off-by: Lejun Zhu 
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/misc/Kconfig|  10 ++
 drivers/input/misc/Makefile   |   1 +
 drivers/input/misc/soc_button_array.c | 218
++
 3 files changed, 229 insertions(+)
 create mode 100644 drivers/input/misc/soc_button_array.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7904ab0..c1298af 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -666,4 +666,14 @@ config INPUT_IDEAPAD_SLIDEBAR
  To compile this driver as a module, choose M here: the
  module will be called ideapad_slidebar.

+config INPUT_SOC_BUTTON_ARRAY
+   tristate "Windows-compatible SoC Button Array"
+   depends on KEYBOARD_GPIO
+   help
+ Say Y here if you have a SoC-based tablet that originally
+ runs Windows 8.
+
+ To compile this driver as a module, choose M here: the
+ module will be called soc_button_array.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index cda71fc..4955ad3 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_RETU_PWRBUTTON)+= retu-pwrbutton.o
 obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
 obj-$(CONFIG_INPUT_SGI_BTNS)   += sgi_btns.o
 obj-$(CONFIG_INPUT_SIRFSOC_ONKEY)  += sirfsoc-onkey.o
+obj-$(CONFIG_INPUT_SOC_BUTTON_ARRAY)   += soc_button_array.o
 obj-$(CONFIG_INPUT_SPARCSPKR)  += sparcspkr.o
 obj-$(CONFIG_INPUT_TWL4030_PWRBUTTON)  += twl4030-pwrbutton.o
 obj-$(CONFIG_INPUT_TWL4030_VIBRA)  += twl4030-vibra.o
diff --git a/drivers/input/misc/soc_button_array.c
b/drivers/input/misc/soc_button_array.c
new file mode 100644
index 000..08ead2a
--- /dev/null
+++ b/drivers/input/misc/soc_button_array.c
@@ -0,0 +1,218 @@
+/*
+ * Supports for the button array on SoC tablets originally running
+ * Windows 8.
+ *
+ * (C) Copyright 2014 Intel 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
+ * of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Definition of buttons on the tablet. The ACPI index of each button
+ * is defined in section 2.8.7.2 of "Windows ACPI Design Guide for SoC
+ * Platforms"
+ */
+#define MAX_NBUTTONS   5
+
+struct soc_button_info {
+   const char *name;
+   int acpi_index;
+   unsigned int event_type;
+   unsigned int event_code;
+   bool autorepeat;
+   bool wakeup;
+};
+
+/*
+ * Some of the buttons like volume up/down are auto repeat, while others
+ * are not. To support both, we register two platform devices, and put
+ * buttons into them based on whether the key should be auto repeat.
+ */
+#define BUTTON_TYPES   2
+
+struct soc_button_data {
+   struct platform_device *children[BUTTON_TYPES];
+};
+
+/*
+ * Get the Nth GPIO number from the ACPI object.
+ */
+static int soc_button_lookup_gpio(struct device *dev, int acpi_index)
+{
+   struct gpio_desc *desc;
+   int gpio;
+
+   desc = gpiod_get_index(dev, KBUILD_MODNAME, acpi_index);
+   if (IS_ERR(desc))
+   return PTR_ERR(desc);
+
+   gpio = desc_to_gpio(desc);
+
+   gpiod_put(desc);
+
+   return gpio;
+}
+
+static struct platform_device *
+soc_button_device_create(struct pnp_dev *pdev,
+const struct soc_button_info *button_info,
+  

[PATCH RFC] ACPI: (x86) remove useless initial assignment in gsi_to_irq

2014-03-30 Thread zhouzhouyi
From: Zhouyi Zhou 

I think in function gsi_to_irq, initial assignment to irq is useless although 
compiler
may eliminate it during the compilng. 

Signed-off-by: Zhouyi Zhou 
---
 arch/x86/kernel/acpi/boot.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 1dac942..b93d61e 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -103,7 +103,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = {
 
 static unsigned int gsi_to_irq(unsigned int gsi)
 {
-   unsigned int irq = gsi + NR_IRQS_LEGACY;
+   unsigned int irq;
unsigned int i;
 
for (i = 0; i < NR_IRQS_LEGACY; i++) {
-- 
1.7.10.4

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


linux-next: manual merge of the net-next tree with the arm-soc tree

2014-03-30 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the net-next tree got a conflict in
Documentation/devicetree/bindings/net/stmmac.txt between commit
50b4af414d41 ("dts: stmmac: Document the clocks property in the stmmac
base document") from the arm-soc tree and commit e8f08ee0ad86 ("DT: net:
document Ethernet bindings in one place") from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc Documentation/devicetree/bindings/net/stmmac.txt
index 9a0c1b7bee29,5748351fb9df..
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@@ -31,13 -30,7 +30,11 @@@ Optional properties
  - resets: Should contain a phandle to the STMMAC reset signal, if any
  - reset-names: Should contain the reset signal name "stmmaceth", if a
reset phandle is given
- - max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather
-   than the maximum frame size.
+ - max-frame-size: See ethernet.txt file in the same directory
 +- clocks: If present, the first clock should be the GMAC main clock,
 +  further clocks may be specified in derived bindings.
 +- clocks-names: One name for each entry in the clocks property, the
 +  first one should be "stmmaceth".
  
  Examples:
  


pgpnMiDJC4Z8d.pgp
Description: PGP signature


Re: [PATCH v2 16/29] ktap: add amalgamation build(kernel/trace/ktap/amalg.c)

2014-03-30 Thread Li Zefan
On 2014/3/28 22:45, Jovi Zhangwei wrote:
> This compiles the ktapvm as one huge C file and allows
> GCC to generate faster and shorter code.
> 
> No amalgamation build in x86_64:
> ktapvm.ko: 3.1M
> 
> amalgamation build in x86_64:
> ktapvm.ko: 1.1M
> 
> User can set use amalgamation build or not in Makefile.
> 
> (Need to analyze further why have so big differences)
> 

Let's drop this patch for now to make the patchset smaller ?

> Signed-off-by: Jovi Zhangwei 
> ---
>  kernel/trace/ktap/amalg.c | 37 +
>  1 file changed, 37 insertions(+)
>  create mode 100644 kernel/trace/ktap/amalg.c
> 
> diff --git a/kernel/trace/ktap/amalg.c b/kernel/trace/ktap/amalg.c
> new file mode 100644
> index 000..9935ccf
> --- /dev/null
> +++ b/kernel/trace/ktap/amalg.c
> @@ -0,0 +1,37 @@
> +/*
> + * amalg.c - ktapvm kernel module amalgamation.
> + *
> + * This file is part of ktap by Jovi Zhangwei.
> + *
> + * Copyright (C) 2012-2014 Jovi Zhangwei .
> + *
> + * ktap is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * ktap is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#include "ktap.c"
> +#include "kp_obj.c"
> +#include "kp_bcread.c"
> +#include "kp_str.c"
> +#include "kp_mempool.c"
> +#include "kp_tab.c"
> +#include "kp_transport.c"
> +#include "kp_vm.c"
> +#include "kp_events.c"
> +#include "lib_base.c"
> +#include "lib_ansi.c"
> +#include "lib_kdebug.c"
> +#include "lib_timer.c"
> +#include "lib_table.c"
> +#include "lib_net.c"
> +
> 

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


[PATCH 2/2] nohz, procfs: introduce get_cpu_idle/iowait_time_coarse

2014-03-30 Thread Hidetoshi Seto
This patch is 2/2 of patch set to fix an issue that idle/iowait
of /proc/stat can go backward. Originally reported by Tetsuo and
Fernando at last year, Mar 2013.

Now it is clear that get_cpu_{idle,iowait}_time_us() is not monotonic.
Using this for /proc/stats will cause troubles in innocent userland
who believe these counters are definitely monotonic.

Given that:

  - If observer (=reader of /proc/stats) want to avoid backwarding,
it must update time stats for next observer. It means observer
determine delta to idle/iowait and account it for sleeping cpu.

  - Usually the number of observers will not so many (i.e. running
top on few console or hiring few monitor program will be enough
for average system admin), but we must predict the worst case.
In short, make effort to reduce lock contention.

  - The resolution required in /proc/stats is tick-level, not us.

This patch introduces new function get_cpu_idle/iowait_time_coarse()
that guarantees monotonic return value but resolution is low.

Tricks are here:

  - At first this function obtain latest time stats and calculate
"delta" which indicates duration from time when the time stats
is updated last time to current time.

  - If delta is less than tick length, use obtained time stats
as if it was sampled in tick interrupt recently happened.

  - If delta is greater than tick, perform update of time stats
as if it emulates tick for sleeping observed cpu.

  - As the result the rate of updating time stats by observer is
limited to once per tick. In other words, in case if there is
observer who are monitoring sleeping cpu, we leave tick
emulation job during idle to the observer.

I confirmed this patch fix the monotonicity of /proc/stats, by
running reproducer and stressor for a day. The rate of reproduce
is different for different system, but in my case, running
"git gc" on kernel source repository aside of checker works fine.

Signed-off-by: Hidetoshi Seto 
Reviewed-by: Preeti U Murthy 
Reported-by: Fernando Luis Vazquez Cao 
Reported-by: Tetsuo Handa 
Cc: Frederic Weisbecker 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Oleg Nesterov 
---
 fs/proc/stat.c   |   16 +++--
 include/linux/tick.h |4 ++
 kernel/time/tick-sched.c |   79 ++
 3 files changed, 89 insertions(+), 10 deletions(-)

diff --git a/fs/proc/stat.c b/fs/proc/stat.c
index 6f599c6..3dbe282 100644
--- a/fs/proc/stat.c
+++ b/fs/proc/stat.c
@@ -45,32 +45,28 @@ static cputime64_t get_iowait_time(int cpu)
 
 static u64 get_idle_time(int cpu)
 {
-   u64 idle, idle_time = -1ULL;
+   u64 idle = -1ULL;
 
if (cpu_online(cpu))
-   idle_time = get_cpu_idle_time_us(cpu, NULL);
+   idle = get_cpu_idle_time_coarse(cpu);
 
-   if (idle_time == -1ULL)
+   if (idle == -1ULL)
/* !NO_HZ or cpu offline so we can rely on cpustat.idle */
idle = kcpustat_cpu(cpu).cpustat[CPUTIME_IDLE];
-   else
-   idle = usecs_to_cputime64(idle_time);
 
return idle;
 }
 
 static u64 get_iowait_time(int cpu)
 {
-   u64 iowait, iowait_time = -1ULL;
+   u64 iowait = -1ULL;
 
if (cpu_online(cpu))
-   iowait_time = get_cpu_iowait_time_us(cpu, NULL);
+   iowait = get_cpu_iowait_time_coarse(cpu);
 
-   if (iowait_time == -1ULL)
+   if (iowait == -1ULL)
/* !NO_HZ or cpu offline so we can rely on cpustat.iowait */
iowait = kcpustat_cpu(cpu).cpustat[CPUTIME_IOWAIT];
-   else
-   iowait = usecs_to_cputime64(iowait_time);
 
return iowait;
 }
diff --git a/include/linux/tick.h b/include/linux/tick.h
index f6f4ac1..3b4674d 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -140,6 +140,8 @@ extern void tick_nohz_irq_exit(void);
 extern ktime_t tick_nohz_get_sleep_length(void);
 extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
 extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
+extern u64 get_cpu_idle_time_coarse(int cpu);
+extern u64 get_cpu_iowait_time_coarse(int cpu);
 
 # else /* !CONFIG_NO_HZ_COMMON */
 static inline int tick_nohz_tick_stopped(void)
@@ -158,6 +160,8 @@ static inline ktime_t tick_nohz_get_sleep_length(void)
 }
 static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) { return -1; }
 static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return -1; }
+static inline u64 get_cpu_idle_time_coarse(int cpu) { return -1; }
+static inline u64 get_cpu_iowait_time_coarse(int cpu) { return -1; }
 # endif /* !CONFIG_NO_HZ_COMMON */
 
 #ifdef CONFIG_NO_HZ_FULL
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 6641c56..4bf22d2 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -592,6 +592,85 @@ u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time)
 }
 EXPORT_SYMBOL_

RE: [PATCH] printk: add sleep time into timestamp

2014-03-30 Thread Neil Zhang


> -Original Message-
> From: John Stultz [mailto:john.stu...@linaro.org]
> Sent: 2014年3月29日 1:37
> To: Neil Zhang
> Cc: Andrew Morton; Linux Kernel Mailing List
> Subject: Re: [PATCH] printk: add sleep time into timestamp
> 
> On 03/27/2014 11:45 PM, Neil Zhang wrote:
> > John,
> >
> >> -Original Message-
> >> From: johnstul.l...@gmail.com [mailto:johnstul.l...@gmail.com] On
> >> Behalf Of John Stultz
> >> Sent: 2014年3月28日 11:18
> >> To: Neil Zhang
> >> Cc: Andrew Morton; Linux Kernel Mailing List
> >> Subject: Re: [PATCH] printk: add sleep time into timestamp
> >>
> >> On Thu, Mar 27, 2014 at 1:17 AM, Neil Zhang 
> >> wrote:
> >>> Add sleep time into timestamp to reflect the actual time since
> >>> sched_clock will be stopped during suspend.
> >> So why is this change necessary?
> >>
> >> Further, since the sleep time may be updated a bit late in the resume
> >> cycle (in many cases we cannot access the RTC until irqs are enabled
> >> back on), you may see messages that show pre-suspend times when
> >> really they occur after we resume (but before the sleep time is
> incremented).
> >>
> > Thanks for the comments.
> > Yes, the sleep time will be update in RTC and the print in the resume
> procedure still w/o the sleep time.
> > But I think the messages are not too much at this stage.
> 
> Not sure I understand what you mean by "the messages are not too much",
> could you expand that a bit?

Sorry that I didn't make it clear.
I mean since most of the platform don't have the persistent clock support, 
so there is no good way to reflect the sleep time for the messages in the 
resume procedure before rtc_resume so far.
Fortunately this period only related to the resume procedure.
Anyway, other part of the kernel can benefit from this patch's change.

> 
> >> More comments below
> >>
> >>> This patch depends on the following patch.
> >>> timekeeping: check params before use them
> >>>
> >>> Signed-off-by: Neil Zhang 
> >>> ---
> >>>  kernel/printk/printk.c |   15 +--
> >>>  1 file changed, 13 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index
> >>> 4dae9cb..2dc6145 100644
> >>> --- a/kernel/printk/printk.c
> >>> +++ b/kernel/printk/printk.c
> >>> @@ -250,6 +250,17 @@ static char __log_buf[__LOG_BUF_LEN]
> >>> __aligned(LOG_ALIGN);  static char *log_buf = __log_buf;  static u32
> >>> log_buf_len = __LOG_BUF_LEN;
> >>>
> >>> +static u64 print_clock(void)
> >>> +{
> >>> +   struct timespec ts;
> >>> +   u64 ts_nsec = local_clock();
> >>> +
> >>> +   get_xtime_and_monotonic_and_sleep_offset(NULL, NULL, &ts);
> >> So this will cause deadlocks anytime we print from the timekeeping
> >> core, since we may hold a write on the timekeeper lock, and this
> >> patch makes every printk try to take a read-lock on the timekeeper lock.
> >>
> > Sorry, I don't quite understand why it will cause deadlock.
> > Yes, it will take a read-lock, but it should not be expensive.
> 
> If we call or trigger a printk while holding a write on the timekeeping lock, 
> the
> printk code will then try to aquire a read-lock on the timekeeping lock and 
> this
> will deadlock the machine.
> 
> The printk code already has trouble with the timekeeping code, but this would
> make it worse.
>   
Got it, thanks for the clarification.

> 
> >> I'd suggest you use monotonic_to_bootbased() here instead of hacking
> >> up this hrtimer specific interface, but even so, right now that call
> >> doesn't take the timekeeper lock, but probably should, so its not a good
> long term plan.
> > It maybe doable, or whether we can add another function to only return
> sleep time.
> > Then no read-lock is needed.
> 
> Well, you're returning a timespec, which cannot be read atomically, so it
> would need to take the lock (that's why I was saying
> monotonic_to_bootbased() should probably take the lock, and seems broken).
> 
> But using monotonic_to_bootbased would give you the same functionality
> without having to modify get_xtime_and_monotonic_and_sleep_offset().

Ok, I will use the following functions for printk, thanks for the suggestion.

ns_to_timespec()
monotonic_to_bootbased()
timespec_to_ns()

> 
> >> I'm still not convinced this change needs to be done, but a  better
> >> solution here would be to add infrastructure that when the sleep time
> >> is updated we update an offset that the is adding to the
> >> local_clock() however, you probably want to be careful since you
> >> don't want sleep time in normal local_clock/sched_clock calls since it 
> >> would
> mess up scheduling.
> >>
> > Sometimes we need to compare the kernel log with user space log, so it
> > would be convenient to add the sleep time into kernel timestamp.
> 
> Which userspace log? You can have the syslog capture the kernel messages
> and timestamp them properly. Also, if you are using your own logging, you can
> use CLOCK_MONOTONIC which will provide the closest approximation to the

[PATCH 1/2] nohz: use seqlock to avoid race on idle time stats v2

2014-03-30 Thread Hidetoshi Seto
This patch is 1/2 of patch set to fix an issue that idle/iowait
of /proc/stat can go backward. Originally reported by Tetsuo and
Fernando at last year, Mar 2013.

[BACKGROUNDS]: idle accounting on NO_HZ

If NO_HZ is enabled, cpu stops tick interrupt for itself before
go sleep to be idle. It means that time stats of the sleeping cpu
will not be updated in tick interrupt. Instead when cpu wakes up,
it updates time stats by calculating idle duration time from
timestamp at entering idle and current time as exiting idle.

OTOH, it can happen that there are some kind of observer who want
to know how long the sleeping cpu have been idle. Imagine that
userland runs top command or application who read /proc/stats.
Therefore kernel provides get_cpu_{idle,iowait}_time_us() function
for user to obtain current idle time stats of such sleeping cpu.
This function reads time stats and timestamp at entering idle,
and then return current idle time by adding duration calculated
from timestamp and current time.

There are 2 problems:

[PROBLEM 1]: there is no exclusive control.

It is easy to understand that there are 2 different cpu - an
observing cpu where running a program observing idle cpu's stat
and an observed cpu where performing idle. It means race can
happen if observed cpu wakes up while it is observed. Observer
can accidentally add calculated duration time (say delta) to
time stats which is just updated by woken cpu. Soon correct
idle time is returned in next turn, so it will result in
backward time. Therefore readers must be excluded by writer.

Then time stats are updated by woken cpu so there are only one
writer, right? No, unfortunately no. I'm not sure why are they,
but in some reason the function get_cpu_{idle,iowait}_time_us()
has ability to update sleeping cpu's time stats from observing
cpu. From grep of today's kernel tree, this feature is used by
cpufreq module. Calling this function with this feature in
periodically manner works like emulating tick for sleeping cpu.

In summary there are races between multiple writer and multiple
reader but no exclusive control on this idle time stats dataset.

[PROBLEM 2]: broken iowait accounting.

As historical nature, cpu's idle time was accounted as either
idle or iowait depending on the presence of tasks blocked by
I/O. No one complain about it for a long time. However:

  > Still trying to wrap my head around it, but conceptually
  > get_cpu_iowait_time_us() doesn't make any kind of sense.
  > iowait isn't per cpu since effectively tasks that aren't
  > running aren't assigned a cpu (as Oleg already pointed out).
  -- Peter Zijlstra

Now some kernel folks realized that accounting iowait as per-cpu
does not make sense in SMP world. When we were in traditional
UP era, cpu is considered to be waiting I/O if it is idle while
nr_iowait > 0. But in these days with SMP systems, tasks easily
migrate from a cpu where they issued an I/O to another cpu where
they are queued after I/O completion.

Back to NO_HZ mechanism. Totally terrible thing here is that
observer need to handle duration "delta" without knowing that
nr_iowait of sleeping cpu can be changed easily by migration
even if cpu is sleeping. So it can happen that:

  given:
idle time stats: idle=1000, iowait=100
stamp at idle entry: entry=50
nr tasks waiting io: nr_iowait=1

  observer temporary assigns delta as iowait at 1st place,
  (but does not do update (=account delta to time stats)):
1st reader's query @ now = 60:
  idle=1000
  iowait=110 (=100+(60-50))

  then blocked tasks are migrated all:
nr_iowait=0

  and at last in 2nd turn observer assign delta as idle:
2nd reader's query @ now = 70:
  idle=1020 (=1000+(70-50))
  iowait=100

You will see that iowait is decreased from 110 to 100.

In summary iowait accounting has fundamental problem and needs
to be precisely reworked. It implies that some user interfaces
might be replaced completely.

[WHAT THIS PATCH PROPOSED]: fix problem 1 first.

To fix problem 1, this patch adds seqlock for NO_HZ idle
accounting to avoid possible races between multiple reader/writer.

And to cope with problem 2, I add comments to note that there
are known issues.

References:
  First report from Fernando:
[RFC] iowait/idle time accounting hiccups in NOHZ kernels
https://lkml.org/lkml/2013/3/18/962
  Steps to reproduce guided by Tetsuo:
https://lkml.org/lkml/2013/4/1/201

  1st patchset from Frederic:
[PATCH 0/4] nohz: Fix racy sleeptime stats
https://lkml.org/lkml/2013/8/8/638
[PATCH RESEND 0/4] nohz: Fix racy sleeptime stats
https://lkml.org/lkml/2013/8/16/274

  2nd patchset from Frederic:
[RFC PATCH 0/5] nohz: Fix racy sleeptime stats v2
https://lkml.org/lkml/2013/10/19/86

v2: update comments and description about problem 2.
include fix for minor typo

Signed-off-by: Hidetoshi Seto 
Reviewed-by: Preeti U Murthy 
Reported-by: Fernando Luis Vazquez Cao 
Reported-by: Tetsuo Handa 
Cc: Frederic Weis

Re: [PATCH v2 08/29] ktap: add bytecode reader(kernel/trace/ktap/kp_bcread.[c|h])

2014-03-30 Thread Jovi Zhangwei
On Mon, Mar 31, 2014 at 1:17 AM, Andi Kleen  wrote:
>> That's designed for portability initially, it means we can just run bytecode
>> without compile script file everywhere, especially when compilation  is
>> a heavily task for some embedded platform, even though ktap compilation
>> is extremely fast.
>>
>> I doubt maybe there will have this bytecode portability requirement in 
>> future?
>
> Portability should be on the source level.
>
>
That's fine, I will add one endianness flag in bytecode header, kernel
will reject
loading if find endianness doesn't match.

Thanks.

Jovi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: serqt_usb2: Add blank lines after declarations.

2014-03-30 Thread Joe Perches
On Sun, 2014-03-30 at 23:29 +0200, Thomas Vegas wrote:
> Use a more common kernel coding style.
[]
> diff --git a/drivers/staging/serqt_usb2/serqt_usb2.c 
> b/drivers/staging/serqt_usb2/serqt_usb2.c
[]
> @@ -995,8 +995,8 @@ static void qt_close(struct usb_serial_port *port)
>   struct tty_struct *tty;
>   int status;
>   unsigned int index;
> - status = 0;
>  
> + status = 0;

My preference would be to change the declarations to

struct tty_struct *tty = tty_port_tty_get(&port->port);
unsigned int index = port->port_number;
int status = 0;

>   tty = tty_port_tty_get(&port->port);
>   index = port->port_number;
>  
> @@ -1268,8 +1268,8 @@ static void qt_set_termios(struct tty_struct *tty,
>   if (I_IXOFF(tty) || I_IXON(tty)) {
>   unsigned char stop_char = STOP_CHAR(tty);
>   unsigned char start_char = START_CHAR(tty);
> - status =
> - box_set_sw_flow_ctrl(port->serial, index, stop_char,
> +
> + status = box_set_sw_flow_ctrl(port->serial, index, stop_char,
> start_char);

Please realign start_char to the open parenthesis

status = box_set_sw_flow_ctrl(port->serial, index, stop_char,
  start_char);


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


[PATCH 0/2 v2] nohz: fix idle accounting in NO_HZ kernels

2014-03-30 Thread Hidetoshi Seto
Hi all,

This patch set (rebased on v3.14-rc8) will fix an issue that
idle/iowait of /proc/stat can go backward. Originally reported
by Tetsuo and Fernando at last year, Mar 2013.

v2 have Preeti's Reviewed-by (Thanks!).
Of course still reviews are welcome.

Thanks,
H.Seto


Hidetoshi Seto (2):
  nohz: use seqlock to avoid race on idle time stats v2
  nohz, procfs: introduce get_cpu_idle/iowait_time_coarse

 fs/proc/stat.c   |   16 ++---
 include/linux/tick.h |5 +
 kernel/time/tick-sched.c |  197 --
 3 files changed, 183 insertions(+), 35 deletions(-)

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


Re: [PATCH 15/28] ktap: add built-in functions and library (runtime/lib_*.c)

2014-03-30 Thread Jovi Zhangwei
On Sun, Mar 30, 2014 at 8:58 AM, Andi Kleen  wrote:
>> Maybe in future, after ktap support "include" or "require" to
>> import user defined library in userspace.
>
> Can't you just have some hardcoded standard script for now that is
> always appeneded and provides these functions?
>
Maybe it's fine to hardcoded just for now.

Since we are agreed on review userspace part in another schedule,
so I will remove this ansi library from kernel part in next version.

Thanks for this suggestion.

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


linux-next: build failure after merge of the v4l-dvb tree

2014-03-30 Thread Stephen Rothwell
Hi Mauro,

After merging the v4l-dvb tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_resume':
drivers/media/usb/em28xx/em28xx-dvb.c:1645:7: error: 'client' undeclared (first 
use in this function)
   if (client) {
   ^

Caused by commit 37571b163c15 ("[media] em28xx-dvb: fix PCTV 461e tuner
I2C binding").  Basic build testing is a good idea :-(

I have used the v4v-dvb tree from next-20140328 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpIHYTf1NUNk.pgp
Description: PGP signature


[PATCH] regmap: implement LE formatting/parsing for 16/32-bit values.

2014-03-30 Thread Xiubo Li
Allow busses to request little endianness formatting and
parsing for 16- and 32-bit values. This will be useful to
support regmap-mmio.

For the following the scenarios using the regmap-mmio,
for example:

IndexCPU   Device Endianess flag for values
--
1LELE REGMAP_ENDIAN_DEFAULT/NATIVE
2LEBE REGMAP_ENDIAN_BIG
3BEBE REGMAP_ENDIAN_DEFAULT/NATIVE
4BELE REGMAP_ENDIAN_LITTLE

For one device driver, which will support all the cases above,
needs two boolean properties in DT node like: 'big-endian'
for case 2 and 'little-endian' for case 4, and for cases 1
and 3 they all will be absent.

Signed-off-by: Xiubo Li 
---
 drivers/base/regmap/regmap.c | 52 
 1 file changed, 52 insertions(+)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 6a19515..8e8cea1 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -192,6 +192,13 @@ static void regmap_format_16_be(void *buf, unsigned int 
val, unsigned int shift)
b[0] = cpu_to_be16(val << shift);
 }
 
+static void regmap_format_16_le(void *buf, unsigned int val, unsigned int 
shift)
+{
+   __le16 *b = buf;
+
+   b[0] = cpu_to_le16(val << shift);
+}
+
 static void regmap_format_16_native(void *buf, unsigned int val,
unsigned int shift)
 {
@@ -216,6 +223,13 @@ static void regmap_format_32_be(void *buf, unsigned int 
val, unsigned int shift)
b[0] = cpu_to_be32(val << shift);
 }
 
+static void regmap_format_32_le(void *buf, unsigned int val, unsigned int 
shift)
+{
+   __le32 *b = buf;
+
+   b[0] = cpu_to_le32(val << shift);
+}
+
 static void regmap_format_32_native(void *buf, unsigned int val,
unsigned int shift)
 {
@@ -240,6 +254,13 @@ static unsigned int regmap_parse_16_be(const void *buf)
return be16_to_cpu(b[0]);
 }
 
+static unsigned int regmap_parse_16_le(const void *buf)
+{
+   const __le16 *b = buf;
+
+   return le16_to_cpu(b[0]);
+}
+
 static void regmap_parse_16_be_inplace(void *buf)
 {
__be16 *b = buf;
@@ -247,6 +268,13 @@ static void regmap_parse_16_be_inplace(void *buf)
b[0] = be16_to_cpu(b[0]);
 }
 
+static void regmap_parse_16_le_inplace(void *buf)
+{
+   __le16 *b = buf;
+
+   b[0] = le16_to_cpu(b[0]);
+}
+
 static unsigned int regmap_parse_16_native(const void *buf)
 {
return *(u16 *)buf;
@@ -269,6 +297,13 @@ static unsigned int regmap_parse_32_be(const void *buf)
return be32_to_cpu(b[0]);
 }
 
+static unsigned int regmap_parse_32_le(const void *buf)
+{
+   const __le32 *b = buf;
+
+   return le32_to_cpu(b[0]);
+}
+
 static void regmap_parse_32_be_inplace(void *buf)
 {
__be32 *b = buf;
@@ -276,6 +311,13 @@ static void regmap_parse_32_be_inplace(void *buf)
b[0] = be32_to_cpu(b[0]);
 }
 
+static void regmap_parse_32_le_inplace(void *buf)
+{
+   __le32 *b = buf;
+
+   b[0] = le32_to_cpu(b[0]);
+}
+
 static unsigned int regmap_parse_32_native(const void *buf)
 {
return *(u32 *)buf;
@@ -585,6 +627,11 @@ struct regmap *regmap_init(struct device *dev,
map->format.parse_val = regmap_parse_16_be;
map->format.parse_inplace = regmap_parse_16_be_inplace;
break;
+   case REGMAP_ENDIAN_LITTLE:
+   map->format.format_val = regmap_format_16_le;
+   map->format.parse_val = regmap_parse_16_le;
+   map->format.parse_inplace = regmap_parse_16_le_inplace;
+   break;
case REGMAP_ENDIAN_NATIVE:
map->format.format_val = regmap_format_16_native;
map->format.parse_val = regmap_parse_16_native;
@@ -606,6 +653,11 @@ struct regmap *regmap_init(struct device *dev,
map->format.parse_val = regmap_parse_32_be;
map->format.parse_inplace = regmap_parse_32_be_inplace;
break;
+   case REGMAP_ENDIAN_LITTLE:
+   map->format.format_val = regmap_format_32_le;
+   map->format.parse_val = regmap_parse_32_le;
+   map->format.parse_inplace = regmap_parse_32_le_inplace;
+   break;
case REGMAP_ENDIAN_NATIVE:
map->format.format_val = regmap_format_32_native;
map->format.parse_val = regmap_parse_32_native;
-- 
1.8.4


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


RE: linux-next: build failure after merge of the ia64 tree

2014-03-30 Thread Zhang, Yanmin
Sorry. We would fix it ASAP.

Yanmin

-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au] 
Sent: Monday, March 31, 2014 8:08 AM
To: Luck, Tony
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Liu, ShuoX; 
Zhang, Yanmin
Subject: linux-next: build failure after merge of the ia64 tree

Hi all,

After merging the ia64 tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/built-in.o: In function `pstore_file_open':
inode.c:(.text+0xa29e9): undefined reference to `persistent_ram_size'

Caused by commit f5d7e81eda59 ("pstore: Support current records dump in 
ramoops").

I have used the ia64 tree from next-20140328 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: VDSO pvclock may increase host cpu consumption, is this a problem?

2014-03-30 Thread Zhanghailiang
Hi Marcelo,
The CPU's info is:
processor   : 15
vendor_id   : GenuineIntel
cpu family  : 6
model   : 44
model name  : Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz
stepping: 2
microcode   : 12
cpu MHz : 2400.125
cache size  : 12288 KB
physical id : 1
siblings: 8
core id : 10
cpu cores   : 4
apicid  : 53
initial apicid  : 53
fpu : yes
fpu_exception   : yes
cpuid level : 11
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 
ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm arat dtherm 
tpr_shadow vnmi flexpriority ept vpid
bogomips: 4800.18
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

Thanks
Zhang hailiang

> On Sat, Mar 29, 2014 at 08:47:27AM +, Zhanghailiang wrote:
> > Hi,
> > I found when Guest is idle, VDSO pvclock may increase host consumption.
> > We can calcutate as follow, Correct me if I am wrong.
> >   (Host)250 * update_pvclock_gtod = 1500 * gettimeofday(Guest) In
> > Host, VDSO pvclock introduce a notifier chain, pvclock_gtod_chain in
> timekeeping.c. It consume nearly 900 cycles per call. So in consideration of 
> 250
> Hz, it may consume 225,000 cycles per second, even no VM is created.
> > In Guest, gettimeofday consumes 220 cycles per call with VDSO pvclock. If
> the no-kvmclock-vsyscall is configured, gettimeofday consumes 370 cycles per
> call. The feature decrease 150 cycles consumption per call.
> > When call gettimeofday 1500 times,it decrease 225,000 cycles,equal to the
> host consumption.
> > Both Host and Guest is linux-3.13.6.
> > So, whether the host cpu consumption is a problem?
> 
> Hi,
> 
> How many percents out of the total CPU cycles are 225,000 cycles, for your
> CPU ?

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

2014-03-30 Thread Ben Hutchings
On Sun, 2014-03-30 at 17:49 -0700, Guenter Roeck wrote:
> On Mon, Mar 31, 2014 at 12:23:34AM +0100, Ben Hutchings wrote:
> > This is the start of the stable review cycle for the 3.2.56 release.
> > There are 200 patches in this series, which will be posted as responses
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Apr 02 00:00:00 UTC 2014.
> > Anything received after that time might be too late.
> > 
> Build results:
>   total: 116 pass: 87 skipped: 22 fail: 7
> 
> Qemu tests all passed. Results are as expected.
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Thanks Guenter.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


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


Re: [PATCH for v3.14] AUDIT: Allow login in non-init namespaces

2014-03-30 Thread Serge Hallyn
Quoting Eric Paris (epa...@redhat.com):
> It its possible to configure your PAM stack to refuse login if
> audit messages (about the login) were unable to be sent.  This is common
> in many distros and thus normal configuration of many containers. The
> PAM modules determine if audit is enabled/disabled in the kernel based
> on the return value from sending an audit message on the netlink socket.
> If userspace gets back ECONNREFUSED it believes audit is disabled in the
> kernel.  If it gets any other error else it refuses to let the login
> proceed.
> 
> Just about ever since the introduction of namespaces the kernel audit
> subsystem has returned EPERM if the task sending a message was not in
> the init user or pid namespace.  So many forms of containers have never
> worked if audit was enabled in the kernel.
> 
> BUT if the container was not in net_init then the kernel network code
> would send ECONNREFUSED (instead of the audit code sending EPERM).  Thus
> by pure accident/dumb luck/bug if an admin configured the PAM stack to
> reject all logins that didn't talk to audit, but then ran the login
> untility in the non-init_net namespace, it would work!!  Clearly this
> was a bug, but it is a bug some people expected.
> 
> With the introduction of network namespace support in 3.14-rc1 the two
> bugs stopped cancelling each other out.  Now, containers in the
> non-init_net namespace refused to let users log in (just like PAM was
> configfured!)  Obviously some people were not happy that what used to
> let users log in, now didn't!
> 
> This fix is kinda hacky.  We return ECONNREFUSED for all non-init
> relevant namespaces.  That means that not only will the old broken
> non-init_net setups continue to work, now the broken non-init_pid or
> non-init_user setups will 'work'.  They don't really work, since audit
> isn't logging things.  But it's what most users want.
> 
> In 3.15 we should have patches to support not only the non-init_net
> (3.14) namespace but also the non-init_pid and non-init_user namespace.
> So all will be right in the world.  This just opens the doors wide open
> on 3.14 and hopefully makes users happy, if not the audit system...
> 
> Reported-by: Andre Tomt 
> Reported-by: Adam Richter 
> Signed-off-by: Eric Paris 

Acked-by: Serge E. Hallyn 

> ---
>  kernel/audit.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 3392d3e..95a20f3 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -608,9 +608,19 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 
> msg_type)
>   int err = 0;
>  
>   /* Only support the initial namespaces for now. */
> + /*
> +  * We return ECONNREFUSED because it tricks userspace into thinking
> +  * that audit was not configured into the kernel.  Lots of users
> +  * configure their PAM stack (because that's what the distro does)
> +  * to reject login if unable to send messages to audit.  If we return
> +  * ECONNREFUSED the PAM stack thinks the kernel does not have audit
> +  * configured in and will let login proceed.  If we return EPERM
> +  * userspace will reject all logins.  This should be removed when we
> +  * support non init namespaces!!
> +  */
>   if ((current_user_ns() != &init_user_ns) ||
>   (task_active_pid_ns(current) != &init_pid_ns))
> - return -EPERM;
> + return -ECONNREFUSED;
>  
>   switch (msg_type) {
>   case AUDIT_LIST:
> -- 
> 1.8.5.3
> 
> 
> 
> ___
> Containers mailing list
> contain...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


how to let linux boot my thread tree?

2014-03-30 Thread Joël Krähemann
how to let linux boot my thread tree and schedule it?

Joël


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

2014-03-30 Thread Guenter Roeck
On Mon, Mar 31, 2014 at 12:23:34AM +0100, Ben Hutchings wrote:
> This is the start of the stable review cycle for the 3.2.56 release.
> There are 200 patches in this series, which will be posted as responses
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Apr 02 00:00:00 UTC 2014.
> Anything received after that time might be too late.
> 
Build results:
total: 116 pass: 87 skipped: 22 fail: 7

Qemu tests all passed. Results are as expected.

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: xfs i_lock vs mmap_sem lockdep trace.

2014-03-30 Thread Dave Chinner
On Sun, Mar 30, 2014 at 08:20:30PM -0400, Dave Jones wrote:
> On Mon, Mar 31, 2014 at 10:43:35AM +1100, Dave Chinner wrote:
>  > On Sat, Mar 29, 2014 at 06:31:09PM -0400, Dave Jones wrote:
>  > > Not sure if I've reported this already (it looks familiar, though I've 
> not managed
>  > > to find it in my sent mail folder).  This is rc8 + a diff to fix the 
> stack usage reports
>  > > I was seeing (diff at http://paste.fedoraproject.org/89854/13210913/raw)
>  > > 
>  > >  ==
>  > >  [ INFO: possible circular locking dependency detected ]
>  > >  3.14.0-rc8+ #153 Not tainted
>  > >  ---
>  > >  git/32710 is trying to acquire lock:
>  > >   (&(&ip->i_lock)->mr_lock){.+}, at: [] 
> xfs_ilock+0x122/0x250 [xfs]
>  > >  
>  > > but task is already holding lock:
>  > >   (&mm->mmap_sem){++}, at: [] 
> __do_page_fault+0x14a/0x610
>  > > 
>  > > which lock already depends on the new lock.
>  > 
>  > filldir on a directory inode vs page fault on regular file. Known
>  > issue, definitely a false positive.
> 
> ah yeah, thought it looked familiar. I think I reported this last summer.
> 
>  > We have to change locking
>  > algorithms to avoid such deficiencies of lockdep (a case of "lockdep
>  > considered harmful", perhaps?) so it's not something I'm about to
>  > rush...
> 
> Bummer, as it makes lockdep useless on my test box using xfs because it
> disables itself after hitting this very quickly.
> (I re-enabled it a couple days ago wondering why I'd left it turned off,
>  chances are it was because of this)

Yup, and seeing as SGI haven't shown any indication that they are
going to help fix it any time soon, it won't get fixed until I get
to it (hopefully) sometime soon.

Cheers,

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


Re: xfs i_lock vs mmap_sem lockdep trace.

2014-03-30 Thread Dave Chinner
On Mon, Mar 31, 2014 at 12:57:17AM +0100, Al Viro wrote:
> On Mon, Mar 31, 2014 at 10:43:35AM +1100, Dave Chinner wrote:
> > filldir on a directory inode vs page fault on regular file. Known
> > issue, definitely a false positive. We have to change locking
> > algorithms to avoid such deficiencies of lockdep (a case of "lockdep
> > considered harmful", perhaps?) so it's not something I'm about to
> > rush...
> 
> Give i_lock on directories a separate class, as it's been done for i_mutex...

Already done that. Commit:

93a8614 xfs: fix directory inode iolock lockdep false positive

This just changes where the false positives come from. This
insanity, for example, where shmem instantiates an inode in the page
fault path and so triggers selinux related lockdep fun:

http://oss.sgi.com/archives/xfs/2014-02/msg00618.html

and this with reclaim state contexts:

http://oss.sgi.com/archives/xfs/2014-03/msg00145.html

I even hacked a patch to move the inode classes to per-fstype classes,
and that just pushed the false positive somewhere else. It's just
another horrible game of whack-a-mole, caused by XFS doing something
different. The first possible fix:

http://oss.sgi.com/archives/xfs/2014-03/msg00146.html

is a bit of a big hammer approach, so the approach I'm looking at is
the "don't cache mappings in readdir" solution noted here:

http://oss.sgi.com/archives/xfs/2014-03/msg00163.html

Note that the problem that the additional locking added in 3.13
resolved can not be triggered by anything using the VFS for
directory access. The issues is that one of SGI's plug-ins (CXFS)
can access directories without going through the VFS and so the
internal XFS locking needs to serialise readdir vs directory
modification safely

Cheers,

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


[PATCH 3.2 091/200] mm: __set_page_dirty uses spin_lock_irqsave instead of spin_lock_irq

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: KOSAKI Motohiro 

commit 227d53b397a32a7614667b3ecaf1d89902fb6c12 upstream.

To use spin_{un}lock_irq is dangerous if caller disabled interrupt.
During aio buffer migration, we have a possibility to see the following
call stack.

aio_migratepage  [disable interrupt]
  migrate_page_copy
clear_page_dirty_for_io
  set_page_dirty
__set_page_dirty_buffers
  __set_page_dirty
spin_lock_irq

This mean, current aio migration is a deadlockable.  spin_lock_irqsave
is a safer alternative and we should use it.

Signed-off-by: KOSAKI Motohiro 
Reported-by: David Rientjes rient...@google.com>
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 fs/buffer.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -663,14 +663,16 @@ EXPORT_SYMBOL(mark_buffer_dirty_inode);
 static void __set_page_dirty(struct page *page,
struct address_space *mapping, int warn)
 {
-   spin_lock_irq(&mapping->tree_lock);
+   unsigned long flags;
+
+   spin_lock_irqsave(&mapping->tree_lock, flags);
if (page->mapping) {/* Race with truncate? */
WARN_ON_ONCE(warn && !PageUptodate(page));
account_page_dirtied(page, mapping);
radix_tree_tag_set(&mapping->page_tree,
page_index(page), PAGECACHE_TAG_DIRTY);
}
-   spin_unlock_irq(&mapping->tree_lock);
+   spin_unlock_irqrestore(&mapping->tree_lock, flags);
__mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
 }
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 030/200] staging: r8712u: Set device type to wlan

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Larry Finger 

commit 3a21f00a5002b14e4aab52aef59d33ed28468a13 upstream.

The latest version of NetworkManager does not recognize the device as wireless
without this change.

Signed-off-by: Larry Finger 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/rtl8712/usb_intf.c | 5 +
 1 file changed, 5 insertions(+)

--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -363,6 +363,10 @@ static u8 key_2char2num(u8 hch, u8 lch)
return (hex_to_bin(hch) << 4) | hex_to_bin(lch);
 }
 
+static const struct device_type wlan_type = {
+   .name = "wlan",
+};
+
 /*
  * drv_init() - a device potentially for us
  *
@@ -398,6 +402,7 @@ static int r871xu_drv_init(struct usb_in
padapter->pusb_intf = pusb_intf;
usb_set_intfdata(pusb_intf, pnetdev);
SET_NETDEV_DEV(pnetdev, &pusb_intf->dev);
+   pnetdev->dev.type = &wlan_type;
/* step 2. */
padapter->dvobj_init = &r8712_usb_dvobj_init;
padapter->dvobj_deinit = &r8712_usb_dvobj_deinit;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 020/200] ALSA: rme9652: fix a missing comma in channel_map_9636_ds[]

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit 770bd4bf2e664939a9dacd3d26ec9ff7a3933210 upstream.

The lack of comma leads to the wrong channel for an SPDIF channel.
Unfortunately this wasn't caught by compiler because it's still a
valid expression.

Reported-by: Alexander Aristov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
---
 sound/pci/rme9652/rme9652.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/pci/rme9652/rme9652.c
+++ b/sound/pci/rme9652/rme9652.c
@@ -285,7 +285,7 @@ static char channel_map_9636_ds[26] = {
/* ADAT channels are remapped */
1, 3, 5, 7, 9, 11, 13, 15,
/* channels 8 and 9 are S/PDIF */
-   24, 25
+   24, 25,
/* others don't exist */
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -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/


[PATCH 3.2 015/200] mtd: mxc_nand: remove duplicated ecc_stats counting

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Michael Grzeschik 

commit 0566477762f9e174e97af347ee9c865f908a5647 upstream.

The ecc_stats.corrected count variable will already be incremented in
the above framework-layer just after this callback.

Signed-off-by: Michael Grzeschik 
Signed-off-by: Brian Norris 
Signed-off-by: Ben Hutchings 
---
 drivers/mtd/nand/mxc_nand.c | 1 -
 1 file changed, 1 deletion(-)

--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -596,7 +596,6 @@ static int mxc_nand_correct_data_v2_v3(s
ecc_stat >>= 4;
} while (--no_subpages);
 
-   mtd->ecc_stats.corrected += ret;
pr_debug("%d Symbol Correctable RS-ECC Error\n", ret);
 
return ret;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 016/200] USB: pl2303: fix data corruption on termios updates

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 623c8263376c0b8a4b0c220232e7313d762cd0cc upstream.

Some PL2303 devices are known to lose bytes if you change serial
settings even to the same values as before. Avoid this by comparing the
encoded settings with the previsouly used ones before configuring the
device.

The common case was fixed by commit bf5e5834bffc6 ("pl2303: Fix mode
switching regression"), but this problem was still possible to trigger,
for instance, by using the TCSETS2-interface to repeatedly request
115201 baud, which gets mapped to 115200 and thus always triggers a
settings update.

Cc: Frank Schäfer 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context; use dbg() instead of dev_dbg()]
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/pl2303.c | 34 +-
 1 file changed, 25 insertions(+), 9 deletions(-)

--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -153,6 +153,8 @@ struct pl2303_private {
u8 line_control;
u8 line_status;
enum pl2303_type type;
+
+   u8 line_settings[7];
 };
 
 static int pl2303_vendor_read(__u16 value, __u16 index,
@@ -266,10 +268,6 @@ static void pl2303_set_termios(struct tt
 
dbg("%s -  port %d", __func__, port->number);
 
-   /* The PL2303 is reported to lose bytes if you change
-  serial settings even to the same values as before. Thus
-  we actually need to filter in this specific case */
-
if (old_termios && !tty_termios_hw_change(tty->termios, old_termios))
return;
 
@@ -407,10 +405,29 @@ static void pl2303_set_termios(struct tt
dbg("%s - parity = none", __func__);
}
 
-   i = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
-   SET_LINE_REQUEST, SET_LINE_REQUEST_TYPE,
-   0, 0, buf, 7, 100);
-   dbg("0x21:0x20:0:0  %d", i);
+   /*
+* Some PL2303 are known to lose bytes if you change serial settings
+* even to the same values as before. Thus we actually need to filter
+* in this specific case.
+*
+* Note that the tty_termios_hw_change check above is not sufficient
+* as a previously requested baud rate may differ from the one
+* actually used (and stored in old_termios).
+*
+* NOTE: No additional locking needed for line_settings as it is
+*   only used in set_termios, which is serialised against itself.
+*/
+   if (!old_termios || memcmp(buf, priv->line_settings, 7)) {
+   i = usb_control_msg(serial->dev,
+   usb_sndctrlpipe(serial->dev, 0),
+   SET_LINE_REQUEST, SET_LINE_REQUEST_TYPE,
+   0, 0, buf, 7, 100);
+
+   dbg("0x21:0x20:0:0  %d", i);
+
+   if (i == 7)
+   memcpy(priv->line_settings, buf, 7);
+   }
 
/* change control lines if we are switching to or from B0 */
spin_lock_irqsave(&priv->lock, flags);

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


[PATCH 3.2 006/200] staging: vt6656: [BUG] BBvUpdatePreEDThreshold Always set sensitivity on bScanning

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Malcolm Priestley 

commit 8f248dae133668bfb8e9379b4b3f0571c858b24a upstream.

byBBPreEDIndex value is initially 0, this means that from
cold BBvUpdatePreEDThreshold is never set.

This means that sensitivity may be in an ambiguous state,
failing to scan any wireless points or at least distant ones.

Signed-off-by: Malcolm Priestley 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/vt6656/baseband.c | 3 ---
 1 file changed, 3 deletions(-)

--- a/drivers/staging/vt6656/baseband.c
+++ b/drivers/staging/vt6656/baseband.c
@@ -1656,7 +1656,6 @@ BBvUpdatePreEDThreshold(
 
 if( bScanning )
 {   // need Max sensitivity //RSSI -69, -70,
-if(pDevice->byBBPreEDIndex == 0) break;
 pDevice->byBBPreEDIndex = 0;
 ControlvWriteByte(pDevice, MESSAGE_REQUEST_BBREG, 0xC9, 0x00); 
//CR201(0xC9)
 ControlvWriteByte(pDevice, MESSAGE_REQUEST_BBREG, 0xCE, 0x30); 
//CR206(0xCE)
@@ -1799,7 +1798,6 @@ BBvUpdatePreEDThreshold(
 
 if( bScanning )
 {   // need Max sensitivity  //RSSI -69, -70, ...
-if(pDevice->byBBPreEDIndex == 0) break;
 pDevice->byBBPreEDIndex = 0;
 ControlvWriteByte(pDevice, MESSAGE_REQUEST_BBREG, 0xC9, 0x00); 
//CR201(0xC9)
 ControlvWriteByte(pDevice, MESSAGE_REQUEST_BBREG, 0xCE, 0x24); 
//CR206(0xCE)
@@ -1951,7 +1949,6 @@ BBvUpdatePreEDThreshold(
 case RF_VT3342A0: //RobertYu:20060627, testing table
 if( bScanning )
 {   // need Max sensitivity  //RSSI -67, -68, ...
-if(pDevice->byBBPreEDIndex == 0) break;
 pDevice->byBBPreEDIndex = 0;
 ControlvWriteByte(pDevice, MESSAGE_REQUEST_BBREG, 0xC9, 0x00); 
//CR201(0xC9)
 ControlvWriteByte(pDevice, MESSAGE_REQUEST_BBREG, 0xCE, 0x38); 
//CR206(0xCE)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 004/200] selinux: process labeled IPsec TCP SYN-ACK packets properly in selinux_ip_postroute()

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Paul Moore 

commit 5c6c26813a209e7075baf908e3ad81c1a9d389e8 upstream.

Due to difficulty in arriving at the proper security label for
TCP SYN-ACK packets in selinux_ip_postroute(), we need to check packets
while/before they are undergoing XFRM transforms instead of waiting
until afterwards so that we can determine the correct security label.

Reported-by: Janak Desai 
Signed-off-by: Paul Moore 
[bwh: Backported to 3.2:
 s/selinux_peerlbl_enabled()/netlbl_enabled() || selinux_xfrm_enabled()/]
Signed-off-by: Ben Hutchings 
---
 security/selinux/hooks.c | 42 +++---
 1 file changed, 35 insertions(+), 7 deletions(-)

--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4676,22 +4676,31 @@ static unsigned int selinux_ip_postroute
 * as fast and as clean as possible. */
if (!selinux_policycap_netpeer)
return selinux_ip_postroute_compat(skb, ifindex, family);
+
+   secmark_active = selinux_secmark_enabled();
+   peerlbl_active = netlbl_enabled() || selinux_xfrm_enabled();
+   if (!secmark_active && !peerlbl_active)
+   return NF_ACCEPT;
+
+   sk = skb->sk;
+
 #ifdef CONFIG_XFRM
/* If skb->dst->xfrm is non-NULL then the packet is undergoing an IPsec
 * packet transformation so allow the packet to pass without any checks
 * since we'll have another chance to perform access control checks
 * when the packet is on it's final way out.
 * NOTE: there appear to be some IPv6 multicast cases where skb->dst
-*   is NULL, in this case go ahead and apply access control. */
-   if (skb_dst(skb) != NULL && skb_dst(skb)->xfrm != NULL)
+*   is NULL, in this case go ahead and apply access control.
+* NOTE: if this is a local socket (skb->sk != NULL) that is in the
+*   TCP listening state we cannot wait until the XFRM processing
+*   is done as we will miss out on the SA label if we do;
+*   unfortunately, this means more work, but it is only once per
+*   connection. */
+   if (skb_dst(skb) != NULL && skb_dst(skb)->xfrm != NULL &&
+   !(sk != NULL && sk->sk_state == TCP_LISTEN))
return NF_ACCEPT;
 #endif
-   secmark_active = selinux_secmark_enabled();
-   peerlbl_active = netlbl_enabled() || selinux_xfrm_enabled();
-   if (!secmark_active && !peerlbl_active)
-   return NF_ACCEPT;
 
-   sk = skb->sk;
if (sk == NULL) {
/* Without an associated socket the packet is either coming
 * from the kernel or it is being forwarded; check the packet
@@ -4719,6 +4728,25 @@ static unsigned int selinux_ip_postroute
struct sk_security_struct *sksec = sk->sk_security;
if (selinux_skb_peerlbl_sid(skb, family, &skb_sid))
return NF_DROP;
+   /* At this point, if the returned skb peerlbl is SECSID_NULL
+* and the packet has been through at least one XFRM
+* transformation then we must be dealing with the "final"
+* form of labeled IPsec packet; since we've already applied
+* all of our access controls on this packet we can safely
+* pass the packet. */
+   if (skb_sid == SECSID_NULL) {
+   switch (family) {
+   case PF_INET:
+   if (IPCB(skb)->flags & IPSKB_XFRM_TRANSFORMED)
+   return NF_ACCEPT;
+   break;
+   case PF_INET6:
+   if (IP6CB(skb)->flags & IP6SKB_XFRM_TRANSFORMED)
+   return NF_ACCEPT;
+   default:
+   return NF_DROP_ERR(-ECONNREFUSED);
+   }
+   }
if (selinux_conn_sid(sksec->sid, skb_sid, &peer_sid))
return NF_DROP;
secmark_perm = PACKET__SEND;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 009/200] [media] dib8000: make 32 bits read atomic

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mauro Carvalho Chehab 

commit 5ac64ba12aca3bef18e61c866583155a3bbf81c4 upstream.

As the dvb-frontend kthread can be called anytime, it can race
with some get status ioctl. So, it seems better to avoid one to
race with the other while reading a 32 bits register.
I can't see any other reason for having a mutex there at I2C, except
to provide such kind of protection, as the I2C core already has a
mutex to protect I2C transfers.

Note: instead of this approach, it could eventually remove the dib8000
specific mutex for it, and either group the 4 ops into one xfer or
to manually control the I2C mutex. The main advantage of the current
approach is that the changes are smaller and more puntual.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Patrick Boettcher 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
 drivers/media/dvb/frontends/dib8000.c | 33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

--- a/drivers/media/dvb/frontends/dib8000.c
+++ b/drivers/media/dvb/frontends/dib8000.c
@@ -114,15 +114,10 @@ static u16 dib8000_i2c_read16(struct i2c
return ret;
 }
 
-static u16 dib8000_read_word(struct dib8000_state *state, u16 reg)
+static u16 __dib8000_read_word(struct dib8000_state *state, u16 reg)
 {
u16 ret;
 
-   if (mutex_lock_interruptible(&state->i2c_buffer_lock) < 0) {
-   dprintk("could not acquire lock");
-   return 0;
-   }
-
state->i2c_write_buffer[0] = reg >> 8;
state->i2c_write_buffer[1] = reg & 0xff;
 
@@ -140,6 +135,21 @@ static u16 dib8000_read_word(struct dib8
dprintk("i2c read error on %d", reg);
 
ret = (state->i2c_read_buffer[0] << 8) | state->i2c_read_buffer[1];
+
+   return ret;
+}
+
+static u16 dib8000_read_word(struct dib8000_state *state, u16 reg)
+{
+   u16 ret;
+
+   if (mutex_lock_interruptible(&state->i2c_buffer_lock) < 0) {
+   dprintk("could not acquire lock");
+   return 0;
+   }
+
+   ret = __dib8000_read_word(state, reg);
+
mutex_unlock(&state->i2c_buffer_lock);
 
return ret;
@@ -149,8 +159,15 @@ static u32 dib8000_read32(struct dib8000
 {
u16 rw[2];
 
-   rw[0] = dib8000_read_word(state, reg + 0);
-   rw[1] = dib8000_read_word(state, reg + 1);
+   if (mutex_lock_interruptible(&state->i2c_buffer_lock) < 0) {
+   dprintk("could not acquire lock");
+   return 0;
+   }
+
+   rw[0] = __dib8000_read_word(state, reg + 0);
+   rw[1] = __dib8000_read_word(state, reg + 1);
+
+   mutex_unlock(&state->i2c_buffer_lock);
 
return ((rw[0] << 16) | (rw[1]));
 }

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


[PATCH 3.2 018/200] USB: Nokia 502 is an unusual device

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mikhail Zolotaryov 

commit 0e16114f2db4838251fb64f3b550996ad3585890 upstream.

The USB storage operation of Nokia Asha 502 Dual SIM smartphone running Asha
Platform 1.1.1 is unreliable in respect of data consistency (i.e. transfered
files are corrupted). A similar issue is described here:
http://discussions.nokia.com/t5/Asha-and-other-Nokia-Series-30/Nokia-301-USB-transfers-and-corrupted-files/td-p/1974170

The workaround is (MAX_SECTORS_64):
   rmmod usb_storage && modprobe usb_storage quirks=0421:06aa:m

The patch adds the tested device to the unusual list permanently.

Signed-off-by: Mikhail Zolotaryov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/storage/unusual_devs.h | 7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -226,6 +226,13 @@ UNUSUAL_DEV(  0x0421, 0x0495, 0x0370, 0x
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_MAX_SECTORS_64 ),
 
+/* Patch submitted by Mikhail Zolotaryov  */
+UNUSUAL_DEV(  0x0421, 0x06aa, 0x1110, 0x1110,
+   "Nokia",
+   "502",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_MAX_SECTORS_64 ),
+
 #ifdef NO_SDDR09
 UNUSUAL_DEV(  0x0436, 0x0005, 0x0100, 0x0100,
"Microtech",

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 010/200] serial: add support for 400 and 800 v3 series Titan cards

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Yegor Yefremov 

commit 1e9deb118ed76b9df89d189f27a06522a03cf743 upstream.

add support for 400Hv3, 410Hv3 and 800Hv3

Signed-off-by: Yegor Yefremov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/tty/serial/8250_pci.c | 16 
 1 file changed, 16 insertions(+)

--- a/drivers/tty/serial/8250_pci.c
+++ b/drivers/tty/serial/8250_pci.c
@@ -1147,6 +1147,10 @@ pci_xr17c154_setup(struct serial_private
 #define PCI_DEVICE_ID_TITAN_800E   0xA014
 #define PCI_DEVICE_ID_TITAN_200EI  0xA016
 #define PCI_DEVICE_ID_TITAN_200EISI0xA017
+#define PCI_DEVICE_ID_TITAN_400V3  0xA310
+#define PCI_DEVICE_ID_TITAN_410V3  0xA312
+#define PCI_DEVICE_ID_TITAN_800V3  0xA314
+#define PCI_DEVICE_ID_TITAN_800V3B 0xA315
 #define PCI_DEVICE_ID_OXSEMI_16PCI958  0x9538
 #define PCIE_DEVICE_ID_NEO_2_OX_IBM0x00F6
 #define PCI_DEVICE_ID_PLX_CRONYX_OMEGA 0xc001
@@ -3465,6 +3469,18 @@ static struct pci_device_id serial_pci_t
{   PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_200EISI,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_oxsemi_2_400 },
+   {   PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_400V3,
+   PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   pbn_b0_4_921600 },
+   {   PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_410V3,
+   PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   pbn_b0_4_921600 },
+   {   PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_800V3,
+   PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   pbn_b0_4_921600 },
+   {   PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_800V3B,
+   PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   pbn_b0_4_921600 },
 
{   PCI_VENDOR_ID_SIIG, PCI_DEVICE_ID_SIIG_1S_10x_550,
PCI_ANY_ID, PCI_ANY_ID, 0, 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.2 031/200] ALSA: Enable CONFIG_ZONE_DMA for smaller PCI DMA masks

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit 80ab8eae70e51d578ebbeb228e0f7a562471b8b7 upstream.

The PCI devices with DMA masks smaller than 32bit should enable
CONFIG_ZONE_DMA.  Since the recent change of page allocator, page
allocations via dma_alloc_coherent() with the limited DMA mask bits
may fail more frequently, ended up with no available buffers, when
CONFIG_ZONE_DMA isn't enabled.  With CONFIG_ZONE_DMA, the system has
much more chance to obtain such pages.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68221
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
---
 sound/pci/Kconfig | 12 
 1 file changed, 12 insertions(+)

--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -30,6 +30,7 @@ config SND_ALS300
select SND_PCM
select SND_AC97_CODEC
select SND_OPL3_LIB
+   select ZONE_DMA
help
  Say 'Y' or 'M' to include support for Avance Logic ALS300/ALS300+
 
@@ -54,6 +55,7 @@ config SND_ALI5451
tristate "ALi M5451 PCI Audio Controller"
select SND_MPU401_UART
select SND_AC97_CODEC
+   select ZONE_DMA
help
  Say Y here to include support for the integrated AC97 sound
  device on motherboards using the ALi M5451 Audio Controller
@@ -158,6 +160,7 @@ config SND_AZT3328
select SND_PCM
select SND_RAWMIDI
select SND_AC97_CODEC
+   select ZONE_DMA
help
  Say Y here to include support for Aztech AZF3328 (PCI168)
  soundcards.
@@ -463,6 +466,7 @@ config SND_EMU10K1
select SND_HWDEP
select SND_RAWMIDI
select SND_AC97_CODEC
+   select ZONE_DMA
help
  Say Y to include support for Sound Blaster PCI 512, Live!,
  Audigy and E-mu APS (partially supported) soundcards.
@@ -478,6 +482,7 @@ config SND_EMU10K1X
tristate "Emu10k1X (Dell OEM Version)"
select SND_AC97_CODEC
select SND_RAWMIDI
+   select ZONE_DMA
help
  Say Y here to include support for the Dell OEM version of the
  Sound Blaster Live!.
@@ -511,6 +516,7 @@ config SND_ES1938
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
+   select ZONE_DMA
help
  Say Y here to include support for soundcards based on ESS Solo-1
  (ES1938, ES1946, ES1969) chips.
@@ -522,6 +528,7 @@ config SND_ES1968
tristate "ESS ES1968/1978 (Maestro-1/2/2E)"
select SND_MPU401_UART
select SND_AC97_CODEC
+   select ZONE_DMA
help
  Say Y here to include support for soundcards based on ESS Maestro
  1/2/2E chips.
@@ -602,6 +609,7 @@ config SND_ICE1712
select SND_MPU401_UART
select SND_AC97_CODEC
select BITREVERSE
+   select ZONE_DMA
help
  Say Y here to include support for soundcards based on the
  ICE1712 (Envy24) chip.
@@ -688,6 +696,7 @@ config SND_LX6464ES
 config SND_MAESTRO3
tristate "ESS Allegro/Maestro3"
select SND_AC97_CODEC
+   select ZONE_DMA
help
  Say Y here to include support for soundcards based on ESS Maestro 3
  (Allegro) chips.
@@ -782,6 +791,7 @@ config SND_SIS7019
tristate "SiS 7019 Audio Accelerator"
depends on X86 && !X86_64
select SND_AC97_CODEC
+   select ZONE_DMA
help
  Say Y here to include support for the SiS 7019 Audio Accelerator.
 
@@ -793,6 +803,7 @@ config SND_SONICVIBES
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
+   select ZONE_DMA
help
  Say Y here to include support for soundcards based on the S3
  SonicVibes chip.
@@ -804,6 +815,7 @@ config SND_TRIDENT
tristate "Trident 4D-Wave DX/NX; SiS 7018"
select SND_MPU401_UART
select SND_AC97_CODEC
+   select ZONE_DMA
help
  Say Y here to include support for soundcards based on Trident
  4D-Wave DX/NX or SiS 7018 chips.

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

2014-03-30 Thread Ben Hutchings
This is the start of the stable review cycle for the 3.2.56 release.
There are 200 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Apr 02 00:00:00 UTC 2014.
Anything received after that time might be too late.

A combined patch relative to 3.2.55 will be posted as an additional
response to this.  A shortlog and diffstat can be found below.

Ben.

-

Aisheng Dong (1):
  mmc: sdhci: fix lockdep error in tuning routine
 [2b35bd83467df6f8284b9148d6f768148c3a5e5f]

Al Viro (2):
  hpfs: deadlock and race in directory lseek()
 [31abdab9c11bb1694ecd1476a7edbe8e964d94ac]
  ocfs2 syncs the wrong range...
 [1b56e98990bcdbb20b9fab163654b9315bf158e8]

Alan Stern (4):
  USB: EHCI: add delay during suspend to prevent erroneous wakeups
 [3e8d6d85adedc59115a564c0a54b36e42087c4d9]
  usb-storage: add unusual-devs entry for BlackBerry 9000
 [c5637e5119c43452a00e27c274356b072263ecbb]
  usb-storage: enable multi-LUN scanning when needed
 [823d12c95c666fa7ab7dad208d735f6bc6afabdc]
  usb-storage: restrict bcdDevice range for Super Top in Cypress ATACB
 [a9c143c82608bee2a36410caa56d82cd86bdc7fa]

Aleksander Morgado (1):
  USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8
 [12df84d4a80278a5b1abfec3206795291da52fc9]

Alex Deucher (4):
  drm/radeon/DCE4+: clear bios scratch dpms bit (v2)
 [6802d4bad83f50081b2788698570218aaff8d10e]
  drm/radeon: disable ss on DP for DCE3.x
 [d8e24525094200601236fa64a54cf73e3d682f2e]
  drm/radeon: set the full cache bit for fences on r7xx+
 [d45b964a22cad962d3ede1eba8d24f5cee7b2a92]
  drm/radeon: warn users when hw_i2c is enabled (v2)
 [d195178297de9a91246519dbfa98952b70f9a9b6]

Alex Williamson (1):
  intel-iommu: fix off-by-one in pagetable freeing
 [08336fd218e087cc4fcc458e6b6dcafe8702b098]

Amitkumar Karwar (1):
  mwifiex: copy AP's HT capability info correctly
 [c99b1861c232e1f641f13b8645e0febb3712cc71]

Andy Grover (1):
  target/iscsi: Fix network portal creation race
 [ee291e63293146db64668e8d65eb35c97e8324f4]

Anton Blanchard (2):
  net: unix socket code abuses csum_partial
 [0a13404dd3bf4ea870e3d96270b5a382edca85c0]
  powerpc: Align p_dyn, p_rela and p_st symbols
 [a5b2cf5b1af424ee3dd9e3ce6d5cea18cb927e67]

Arnd Bergmann (1):
  vmxnet3: fix building without CONFIG_PCI_MSI
 [0a8d8c446b5429d15ff2d48f46e00d8a08552303]

Benjamin Herrenschmidt (1):
  of: Fix address decoding on Bimini and js2x machines
 [6dd18e4684f3d188277bbbc27545248487472108]

Bjorn Helgaas (1):
  PCI: Enable INTx if BIOS left them disabled
 [1f42db786b14a31bf807fc41ee5583a00c08fcb1]

Bjørn Mork (1):
  usb: ftdi_sio: add Mindstorms EV3 console adapter
 [67847baee056892dc35efb9c3fd05ae7f075588c]

Boaz Harrosh (1):
  ore: Fix wrong math in allocation of per device BIO
 [aad560b7f63b495f48a7232fd086c5913a676e6f]

Borislav Petkov (2):
  EDAC: Correct workqueue setup path
 [cb6ef42e516cb8948f15e4b70dc03af8020050a2]
  rtc-cmos: Add an alarm disable quirk
 [d5a1c7e3fc38d9c7d629e1e47f32f863acbdec3d]

Chen Gang (1):
  avr32: Makefile: add '-D__linux__' flag for gcc-4.4.7 use
 [8d80390cfc9434d5aa4fb9e5f9768a66b30cb8a6]

Chris Mason (1):
  Btrfs: setup inode location during btrfs_init_inode_locked
 [90d3e592e99b8e374ead2b45148abf506493a959]

Chuansheng Liu (1):
  genirq: Remove racy waitqueue_active check
 [c685689fd24d310343ac33942e9a54a974ae9c43]

Clemens Ladisch (2):
  ALSA: oxygen: Xonar DG(X): modify DAC routing
 [1f91ecc14deea9461aca93273d78871ec4d98fcd]
  ALSA: usb-audio: work around KEF X300A firmware bug
 [624aef494f86ed0c58056361c06347ad62b26806]

Colin Cross (1):
  timekeeping: fix 32-bit overflow in get_monotonic_boottime
 [ec145babe754f9ea1079034a108104b6001e001c]

Colin Leitner (1):
  USB: ftdi_sio: added CS5 quirk for broken smartcard readers
 [c1f15196ac3b541d084dc80a8fbd8a74c6a0bd44]

Dan Carpenter (1):
  KVM: return an error code in kvm_vm_ioctl_register_coalesced_mmio()
 [aac5c4226e7136c331ed384c25d5560204da10a0]

Dan Williams (2):
  [SCSI] isci: fix reset timeout handling
 [ddfadd7736b677de2d4ca2cd5b4b655368c85a7a]
  ioat: fix tasklet tear down
 [da87ca4d4ca101f177fffd84f1f0a5e4c0343557]

Daniel Borkmann (2):
  net: sctp: fix sctp_connectx abi for ia32  emulation/compat mode
 [ffd5939381c609056b33b7585fb05a77b4c695f3]
  net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is  AUTH capable
 [ec0223ec48a90cb605244b45f7c62de856403729]

Daniel J Blueman (1):
  x86/amd/numa: Fix northbridge quirk to assign correct NUMA node
 [847d

[PATCH 3.2 038/200] usb: ehci: add freescale imx28 special write register method

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Peter Chen 

commit feffe09f510c475df082546815f9e4a573f6a233 upstream.

According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
register error issue", All USB register write operations must
use the ARM SWP instruction. So, we implement a special ehci_write
for imx28.

Discussion for it at below:
http://marc.info/?l=linux-usb&m=137996395529294&w=2

Without this patcheset, imx28 works unstable at high AHB bus loading.
If the bus loading is not high, the imx28 usb can work well at the most
of time. There is a IC errata for this problem, usually, we consider
IC errata is a problem not a new feature, and this workaround is needed
for that, so we need to add them to stable tree 3.11+.

Cc: robert.hoda...@digi.com
Signed-off-by: Peter Chen 
Acked-by: Alan Stern 
Signed-off-by: Marc Kleine-Budde 
Tested-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2:adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/usb/host/ehci.h | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -147,6 +147,7 @@ struct ehci_hcd {   /* one per controlle
unsigneduse_dummy_qh:1; /* AMD Frame List table quirk*/
unsignedhas_synopsys_hc_bug:1; /* Synopsys HC */
unsignedframe_index_bug:1; /* MosChip (AKA NetMos) */
+   unsignedimx28_write_fix:1; /* For Freescale i.MX28 */
 
/* required for usb32 quirk */
#define OHCI_CTRL_HCFS  (3 << 6)
@@ -654,6 +655,18 @@ static inline unsigned int ehci_readl(co
 #endif
 }
 
+#ifdef CONFIG_SOC_IMX28
+static inline void imx28_ehci_writel(const unsigned int val,
+   volatile __u32 __iomem *addr)
+{
+   __asm__ ("swp %0, %0, [%1]" : : "r"(val), "r"(addr));
+}
+#else
+static inline void imx28_ehci_writel(const unsigned int val,
+   volatile __u32 __iomem *addr)
+{
+}
+#endif
 static inline void ehci_writel(const struct ehci_hcd *ehci,
const unsigned int val, __u32 __iomem *regs)
 {
@@ -662,7 +675,10 @@ static inline void ehci_writel(const str
writel_be(val, regs) :
writel(val, regs);
 #else
-   writel(val, regs);
+   if (ehci->imx28_write_fix)
+   imx28_ehci_writel(val, regs);
+   else
+   writel(val, regs);
 #endif
 }
 

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


[PATCH 3.2 053/200] b43: fix the wrong assignment of status.freq in b43_rx()

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: ZHAO Gang 

commit 64e5acb09ca6b50c97299cff9ef51299470b29f2 upstream.

Use the right function to update frequency value.

If rx skb is probe response or beacon, the wrong frequency value can
cause problem that bss info can't be updated when it should be.

Fixes: 8318d78a44d4 ("cfg80211 API for channels/bitrates, mac80211
and driver conversion")
Signed-off-by: ZHAO Gang 
Acked-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/b43/xmit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/b43/xmit.c
+++ b/drivers/net/wireless/b43/xmit.c
@@ -819,10 +819,10 @@ void b43_rx(struct b43_wldev *dev, struc
 * channel number in b43. */
if (chanstat & B43_RX_CHAN_5GHZ) {
status.band = IEEE80211_BAND_5GHZ;
-   status.freq = b43_freq_to_channel_5ghz(chanid);
+   status.freq = b43_channel_to_freq_5ghz(chanid);
} else {
status.band = IEEE80211_BAND_2GHZ;
-   status.freq = b43_freq_to_channel_2ghz(chanid);
+   status.freq = b43_channel_to_freq_2ghz(chanid);
}
break;
default:

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


[PATCH 3.2 032/200] staging:iio:ad799x fix error_free_irq which was freeing an irq that may not have been requested

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Hartmut Knaack 

commit 38408d056188be29a6c4e17f3703c796551bb330 upstream.

Only free an IRQ in error_free_irq, if it has been requested previously.

Signed-off-by: Hartmut Knaack 
Acked-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/iio/adc/ad799x_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/staging/iio/adc/ad799x_core.c
+++ b/drivers/staging/iio/adc/ad799x_core.c
@@ -873,7 +873,8 @@ static int __devinit ad799x_probe(struct
return 0;
 
 error_free_irq:
-   free_irq(client->irq, indio_dev);
+   if (client->irq > 0)
+   free_irq(client->irq, indio_dev);
 error_cleanup_ring:
ad799x_ring_cleanup(indio_dev);
 error_disable_reg:

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 014/200] slub: Fix calculation of cpu slabs

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Li Zefan 

commit 8afb1474db4701d1ab80cd8251137a3260e6913e upstream.

  /sys/kernel/slab/:t-048 # cat cpu_slabs
  231 N0=16 N1=215
  /sys/kernel/slab/:t-048 # cat slabs
  145 N0=36 N1=109

See, the number of slabs is smaller than that of cpu slabs.

The bug was introduced by commit 49e2258586b423684f03c278149ab46d8f8b6700
("slub: per cpu cache for partial pages").

We should use page->pages instead of page->pobjects when calculating
the number of cpu partial slabs. This also fixes the mapping of slabs
and nodes.

As there's no variable storing the number of total/active objects in
cpu partial slabs, and we don't have user interfaces requiring those
statistics, I just add WARN_ON for those cases.

Acked-by: Christoph Lameter 
Reviewed-by: Wanpeng Li 
Signed-off-by: Li Zefan 
Signed-off-by: Pekka Enberg 
Signed-off-by: Ben Hutchings 
---
 mm/slub.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/mm/slub.c
+++ b/mm/slub.c
@@ -4483,7 +4483,13 @@ static ssize_t show_slab_objects(struct
page = c->partial;
 
if (page) {
-   x = page->pobjects;
+   node = page_to_nid(page);
+   if (flags & SO_TOTAL)
+   WARN_ON_ONCE(1);
+   else if (flags & SO_OBJECTS)
+   WARN_ON_ONCE(1);
+   else
+   x = page->pages;
total += x;
nodes[node] += x;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 003/200] NFSv4: OPEN must handle the NFS4ERR_IO return code correctly

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Trond Myklebust 

commit c7848f69ec4a8c03732cde5c949bd2aa711a9f4b upstream.

decode_op_hdr() cannot distinguish between an XDR decoding error and
the perfectly valid errorcode NFS4ERR_IO. This is normally not a
problem, but for the particular case of OPEN, we need to be able
to increment the NFSv4 open sequence id when the server returns
a valid response.

Reported-by: J Bruce Fields 
Link: http://lkml.kernel.org/r/20131204210356.ga19...@fieldses.org
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings 
---
 fs/nfs/nfs4xdr.c | 47 +++
 1 file changed, 31 insertions(+), 16 deletions(-)

--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -3056,7 +3056,8 @@ out_overflow:
return -EIO;
 }
 
-static int decode_op_hdr(struct xdr_stream *xdr, enum nfs_opnum4 expected)
+static bool __decode_op_hdr(struct xdr_stream *xdr, enum nfs_opnum4 expected,
+   int *nfs_retval)
 {
__be32 *p;
uint32_t opnum;
@@ -3066,19 +3067,32 @@ static int decode_op_hdr(struct xdr_stre
if (unlikely(!p))
goto out_overflow;
opnum = be32_to_cpup(p++);
-   if (opnum != expected) {
-   dprintk("nfs: Server returned operation"
-   " %d but we issued a request for %d\n",
-   opnum, expected);
-   return -EIO;
-   }
+   if (unlikely(opnum != expected))
+   goto out_bad_operation;
nfserr = be32_to_cpup(p);
-   if (nfserr != NFS_OK)
-   return nfs4_stat_to_errno(nfserr);
-   return 0;
+   if (nfserr == NFS_OK)
+   *nfs_retval = 0;
+   else
+   *nfs_retval = nfs4_stat_to_errno(nfserr);
+   return true;
+out_bad_operation:
+   dprintk("nfs: Server returned operation"
+   " %d but we issued a request for %d\n",
+   opnum, expected);
+   *nfs_retval = -EREMOTEIO;
+   return false;
 out_overflow:
print_overflow_msg(__func__, xdr);
-   return -EIO;
+   *nfs_retval = -EIO;
+   return false;
+}
+
+static int decode_op_hdr(struct xdr_stream *xdr, enum nfs_opnum4 expected)
+{
+   int retval;
+
+   __decode_op_hdr(xdr, expected, &retval);
+   return retval;
 }
 
 /* Dummy routine */
@@ -4744,11 +4758,12 @@ static int decode_open(struct xdr_stream
uint32_t savewords, bmlen, i;
int status;
 
-   status = decode_op_hdr(xdr, OP_OPEN);
-   if (status != -EIO)
-   nfs_increment_open_seqid(status, res->seqid);
-   if (!status)
-   status = decode_stateid(xdr, &res->stateid);
+   if (!__decode_op_hdr(xdr, OP_OPEN, &status))
+   return status;
+   nfs_increment_open_seqid(status, res->seqid);
+   if (status)
+   return status;
+   status = decode_stateid(xdr, &res->stateid);
if (unlikely(status))
return status;
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 017/200] USB: serial: add support for iBall 3.5G connect usb modem

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Rahul Bedarkar 

commit 7d5c1b9c7cb5ec8e52b1adc65c484a923a8ea6c3 upstream.

Add support for iBall 3.5G connect usb modem.

$lsusb
Bus 002 Device 006: ID 1c9e:9605 OMEGA TECHNOLOGY

$usb-devices
T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1c9e ProdID=9605 Rev=00.00
S:  Manufacturer=USB Modem
S:  Product=USB Modem
S:  SerialNumber=1234567890ABCDEF
C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Signed-off-by: Rahul Bedarkar 
Suggested-by: Bjørn Mork 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/option.c | 4 
 1 file changed, 4 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -325,6 +325,9 @@ static void option_instat_callback(struc
  * It seems to contain a Qualcomm QSC6240/6290 chipset*/
 #define FOUR_G_SYSTEMS_PRODUCT_W14 0x9603
 
+/* iBall 3.5G connect wireless modem */
+#define IBALL_3_5G_CONNECT 0x9605
+
 /* Zoom */
 #define ZOOM_PRODUCT_4597  0x9607
 
@@ -1520,6 +1523,7 @@ static const struct usb_device_id option
  .driver_info = (kernel_ulong_t)&four_g_w14_blacklist
},
{ USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
+   { USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
{ USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },
/* Pirelli  */
{ USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_1)},

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


[PATCH 3.2 052/200] ore: Fix wrong math in allocation of per device BIO

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Boaz Harrosh 

commit aad560b7f63b495f48a7232fd086c5913a676e6f upstream.

At IO preparation we calculate the max pages at each device and
allocate a BIO per device of that size. The calculation was wrong
on some unaligned corner cases offset/length combination and would
make prepare return with -ENOMEM. This would be bad for pnfs-objects
that would in that case IO through MDS. And fatal for exofs were it
would fail writes with EIO.

Fix it by doing the proper math, that will work in all cases. (I
ran a test with all possible offset/length combinations this time
round).

Also when reading we do not need to allocate for the parity units
since we jump over them.

Also lower the max_io_length to take into account the parity pages
so not to allocate BIOs bigger than PAGE_SIZE

Signed-off-by: Boaz Harrosh 
Signed-off-by: Ben Hutchings 
---
 fs/exofs/ore.c | 37 +
 include/scsi/osd_ore.h |  1 +
 2 files changed, 26 insertions(+), 12 deletions(-)

--- a/fs/exofs/ore.c
+++ b/fs/exofs/ore.c
@@ -103,7 +103,7 @@ int ore_verify_layout(unsigned total_com
 
layout->max_io_length =
(BIO_MAX_PAGES_KMALLOC * PAGE_SIZE - layout->stripe_unit) *
-   layout->group_width;
+   (layout->group_width - layout->parity);
if (layout->parity) {
unsigned stripe_length =
(layout->group_width - layout->parity) *
@@ -286,7 +286,8 @@ int  ore_get_rw_state(struct ore_layout
if (length) {
ore_calc_stripe_info(layout, offset, length, &ios->si);
ios->length = ios->si.length;
-   ios->nr_pages = (ios->length + PAGE_SIZE - 1) / PAGE_SIZE;
+   ios->nr_pages = ((ios->offset & (PAGE_SIZE - 1)) +
+ios->length + PAGE_SIZE - 1) / PAGE_SIZE;
if (layout->parity)
_ore_post_alloc_raid_stuff(ios);
}
@@ -536,6 +537,7 @@ void ore_calc_stripe_info(struct ore_lay
u64 H = LmodS - G * T;
 
u32 N = div_u64(H, U);
+   u32 Nlast;
 
/* "H - (N * U)" is just "H % U" so it's bound to u32 */
u32 C = (u32)(H - (N * U)) / stripe_unit + G * group_width;
@@ -568,6 +570,10 @@ void ore_calc_stripe_info(struct ore_lay
si->length = T - H;
if (si->length > length)
si->length = length;
+
+   Nlast = div_u64(H + si->length + U - 1, U);
+   si->maxdevUnits = Nlast - N;
+
si->M = M;
 }
 EXPORT_SYMBOL(ore_calc_stripe_info);
@@ -583,13 +589,16 @@ int _ore_add_stripe_unit(struct ore_io_s
int ret;
 
if (per_dev->bio == NULL) {
-   unsigned pages_in_stripe = ios->layout->group_width *
-   (ios->layout->stripe_unit / PAGE_SIZE);
-   unsigned nr_pages = ios->nr_pages * ios->layout->group_width /
-   (ios->layout->group_width -
-ios->layout->parity);
-   unsigned bio_size = (nr_pages + pages_in_stripe) /
-   ios->layout->group_width;
+   unsigned bio_size;
+
+   if (!ios->reading) {
+   bio_size = ios->si.maxdevUnits;
+   } else {
+   bio_size = (ios->si.maxdevUnits + 1) *
+(ios->layout->group_width - ios->layout->parity) /
+ios->layout->group_width;
+   }
+   bio_size *= (ios->layout->stripe_unit / PAGE_SIZE);
 
per_dev->bio = bio_kmalloc(GFP_KERNEL, bio_size);
if (unlikely(!per_dev->bio)) {
@@ -609,8 +618,12 @@ int _ore_add_stripe_unit(struct ore_io_s
added_len = bio_add_pc_page(q, per_dev->bio, pages[pg],
pglen, pgbase);
if (unlikely(pglen != added_len)) {
-   ORE_DBGMSG("Failed bio_add_pc_page bi_vcnt=%u\n",
-  per_dev->bio->bi_vcnt);
+   /* If bi_vcnt == bi_max then this is a SW BUG */
+   ORE_DBGMSG("Failed bio_add_pc_page bi_vcnt=0x%x "
+  "bi_max=0x%x BIO_MAX=0x%x cur_len=0x%x\n",
+  per_dev->bio->bi_vcnt,
+  per_dev->bio->bi_max_vecs,
+  BIO_MAX_PAGES_KMALLOC, cur_len);
ret = -ENOMEM;
goto out;
}
@@ -1099,7 +1112,7 @@ int ore_truncate(struct ore_layout *layo
size_attr->attr = g_attr_logical_length;
size_attr->attr.val_ptr = &size_attr->newsize;
 
-   ORE_DBGM

[PATCH 3.2 033/200] mmc: atmel-mci: fix timeout errors in SDIO mode when using DMA

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ludovic Desroches 

commit 66b512eda74d59b17eac04c4da1b38d82059e6c9 upstream.

With some SDIO devices, timeout errors can happen when reading data.
To solve this issue, the DMA transfer has to be activated before sending
the command to the device. This order is incorrect in PDC mode. So we
have to take care if we are using DMA or PDC to know when to send the
MMC command.

Signed-off-by: Ludovic Desroches 
Acked-by: Nicolas Ferre 
Signed-off-by: Chris Ball 
Signed-off-by: Ben Hutchings 
---
 drivers/mmc/host/atmel-mci.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -1014,11 +1014,22 @@ static void atmci_start_request(struct a
iflags |= ATMCI_CMDRDY;
cmd = mrq->cmd;
cmdflags = atmci_prepare_command(slot->mmc, cmd);
-   atmci_send_command(host, cmd, cmdflags);
+
+   /*
+* DMA transfer should be started before sending the command to avoid
+* unexpected errors especially for read operations in SDIO mode.
+* Unfortunately, in PDC mode, command has to be sent before starting
+* the transfer.
+*/
+   if (host->submit_data != &atmci_submit_data_dma)
+   atmci_send_command(host, cmd, cmdflags);
 
if (data)
host->submit_data(host, data);
 
+   if (host->submit_data == &atmci_submit_data_dma)
+   atmci_send_command(host, cmd, cmdflags);
+
if (mrq->stop) {
host->stop_cmdr = atmci_prepare_command(slot->mmc, mrq->stop);
host->stop_cmdr |= ATMCI_CMDR_STOP_XFER;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 044/200] mmc: sdhci: fix lockdep error in tuning routine

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Aisheng Dong 

commit 2b35bd83467df6f8284b9148d6f768148c3a5e5f upstream.

The sdhci_execute_tuning routine gets lock separately by
disable_irq(host->irq);
spin_lock(&host->lock);
It will cause the following lockdep error message since the &host->lock
could also be got in irq context.
Use spin_lock_irqsave/spin_unlock_restore instead to get rid of
this error message.

[ INFO: inconsistent lock state ]
3.13.0-rc1+ #287 Not tainted
-
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
kworker/u2:1/33 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&(&host->lock)->rlock){?.-...}, at: [<8045f7f4>] 
sdhci_execute_tuning+0x4c/0x710
{IN-HARDIRQ-W} state was registered at:
  [<8005f030>] mark_lock+0x140/0x6ac
  [<80060760>] __lock_acquire+0xb30/0x1cbc
  [<800620d0>] lock_acquire+0x70/0x84
  [<8061d1c8>] _raw_spin_lock+0x30/0x40
  [<804605cc>] sdhci_irq+0x24/0xa68
  [<8006b1d4>] handle_irq_event_percpu+0x54/0x18c
  [<8006b350>] handle_irq_event+0x44/0x64
  [<8006e50c>] handle_fasteoi_irq+0xa0/0x170
  [<8006a8f0>] generic_handle_irq+0x30/0x44
  [<8000f238>] handle_IRQ+0x54/0xbc
  [<8000864c>] gic_handle_irq+0x30/0x64
  [<80013024>] __irq_svc+0x44/0x5c
  [<80329bf4>] dev_vprintk_emit+0x50/0x58
  [<80329c24>] dev_printk_emit+0x28/0x30
  [<80329fec>] __dev_printk+0x4c/0x90
  [<8032a180>] dev_err+0x3c/0x48
  [<802dd4f0>] _regulator_get+0x158/0x1cc
  [<802dd5b4>] regulator_get_optional+0x18/0x1c
  [<80461df4>] sdhci_add_host+0x42c/0xbd8
  [<80464820>] sdhci_esdhc_imx_probe+0x378/0x67c
  [<8032ee88>] platform_drv_probe+0x20/0x50
  [<8032d48c>] driver_probe_device+0x118/0x234
  [<8032d690>] __driver_attach+0x9c/0xa0
  [<8032b89c>] bus_for_each_dev+0x68/0x9c
  [<8032cf44>] driver_attach+0x20/0x28
  [<8032cbc8>] bus_add_driver+0x148/0x1f4
  [<8032dce0>] driver_register+0x80/0x100
  [<8032ee54>] __platform_driver_register+0x50/0x64
  [<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
  [<80008980>] do_one_initcall+0x108/0x16c
  [<8081cca4>] kernel_init_freeable+0x10c/0x1d0
  [<80611b28>] kernel_init+0x10/0x120
  [<8000e9c8>] ret_from_fork+0x14/0x2c
irq event stamp: 805
hardirqs last  enabled at (805): [<8061d43c>] 
_raw_spin_unlock_irqrestore+0x38/0x4c
hardirqs last disabled at (804): [<8061d2c8>] _raw_spin_lock_irqsave+0x24/0x54
softirqs last  enabled at (570): [<8002b824>] __do_softirq+0x1c4/0x290
softirqs last disabled at (561): [<8002bcf4>] irq_exit+0xb4/0x10c

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(&(&host->lock)->rlock);
  
lock(&(&host->lock)->rlock);

 *** DEADLOCK ***

2 locks held by kworker/u2:1/33:
 #0:  (kmmcd){.+.+..}, at: [<8003db18>] process_one_work+0x128/0x468
 #1:  ((&(&host->detect)->work)){+.+...}, at: [<8003db18>] 
process_one_work+0x128/0x468

stack backtrace:
CPU: 0 PID: 33 Comm: kworker/u2:1 Not tainted 3.13.0-rc1+ #287
Workqueue: kmmcd mmc_rescan
Backtrace:
[<80012160>] (dump_backtrace+0x0/0x10c) from [<80012438>] (show_stack+0x18/0x1c)
 r6:bfad0900 r5: r4:8088ecc8 r3:bfad0900
[<80012420>] (show_stack+0x0/0x1c) from [<806169ec>] (dump_stack+0x84/0x9c)
[<80616968>] (dump_stack+0x0/0x9c) from [<806147b4>] 
(print_usage_bug+0x260/0x2d0)
 r5:8076ba88 r4:80977410
[<80614554>] (print_usage_bug+0x0/0x2d0) from [<8005f0d0>] 
(mark_lock+0x1e0/0x6ac)
 r9:8005e678 r8: r7:bfad0900 r6:1015 r5:bfad0cd0
r4:0002
[<8005eef0>] (mark_lock+0x0/0x6ac) from [<80060234>] 
(__lock_acquire+0x604/0x1cbc)
[<8005fc30>] (__lock_acquire+0x0/0x1cbc) from [<800620d0>] 
(lock_acquire+0x70/0x84)
[<80062060>] (lock_acquire+0x0/0x84) from [<8061d1c8>] 
(_raw_spin_lock+0x30/0x40)
 r7: r6:bfb63000 r5: r4:bfb60568
[<8061d198>] (_raw_spin_lock+0x0/0x40) from [<8045f7f4>] 
(sdhci_execute_tuning+0x4c/0x710)
 r4:bfb6
[<8045f7a8>] (sdhci_execute_tuning+0x0/0x710) from [<80453454>] 
(mmc_sd_init_card+0x5f8/0x660)
[<80452e5c>] (mmc_sd_init_card+0x0/0x660) from [<80453748>] 
(mmc_attach_sd+0xb4/0x180)
 r9:bf92d400 r8:8065f364 r7:00061a80 r6:bfb6 r5:8065f358
r4:bfb6
[<80453694>] (mmc_attach_sd+0x0/0x180) from [<8044d9f8>] 
(mmc_rescan+0x284/0x2f0)
 r5:8065f358 r4:bfb602f8
[<8044d774>] (mmc_rescan+0x0/0x2f0) from [<8003db94>] 
(process_one_work+0x1a4/0x468)
 r8: r7:bfb55eb0 r6:bf80dc00 r5:bfb602f8 r4:bfb35980
r3:8044d774
[<8003d9f0>] (process_one_work+0x0/0x468) from [<8003e850>] 
(worker_thread+0x118/0x3e0)
[<8003e738>] (worker_thread+0x0/0x3e0) from [<80044de0>] (kthread+0xd4/0xf0)
[<80044d0c>] (kthread+0x0/0xf0) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
 r7: r6: r5:80044d0c r4:bfb37b40

Signed-off-by: Dong Aisheng 
Signed-off-by: Chris Ball 
[bwh: Backported to 3.2:
 - Adjust context
 - There's no platform_execute_tuning hook]
Signed-off-by: Ben Hutchings 
---
 drivers/mmc/host/sdhci.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

--- a/drivers/mmc

[PATCH 3.2 070/200] alpha: fix broken network checksum

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mikulas Patocka 

commit 0ef38d70d4118b2ce1a538d14357be5ff9dc2bbd upstream.

The patch 3ddc5b46a8e90f3c9251338b60191d0a804b0d92 breaks networking on
alpha (there is a follow-up fix 5cfe8f1ba5eebe6f4b6e5858cdb1a5be4f3272a6,
but networking is still broken even with the second patch).

The patch 3ddc5b46a8e90f3c9251338b60191d0a804b0d92 makes
csum_partial_copy_from_user check the pointer with access_ok. However,
csum_partial_copy_from_user is called also from csum_partial_copy_nocheck
and csum_partial_copy_nocheck is called on kernel pointers and it is
supposed not to check pointer validity.

This bug results in ssh session hangs if the system is loaded and bulk
data are printed to ssh terminal.

This patch fixes csum_partial_copy_nocheck to call set_fs(KERNEL_DS), so
that access_ok in csum_partial_copy_from_user accepts kernel-space
addresses.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Matt Turner 
Signed-off-by: Ben Hutchings 
---
 arch/alpha/lib/csum_partial_copy.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/arch/alpha/lib/csum_partial_copy.c
+++ b/arch/alpha/lib/csum_partial_copy.c
@@ -373,6 +373,11 @@ csum_partial_copy_from_user(const void _
 __wsum
 csum_partial_copy_nocheck(const void *src, void *dst, int len, __wsum sum)
 {
-   return csum_partial_copy_from_user((__force const void __user *)src,
-   dst, len, sum, NULL);
+   __wsum checksum;
+   mm_segment_t oldfs = get_fs();
+   set_fs(KERNEL_DS);
+   checksum = csum_partial_copy_from_user((__force const void __user *)src,
+   dst, len, sum, NULL);
+   set_fs(oldfs);
+   return checksum;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 007/200] [SCSI] bfa: Chinook quad port 16G FC HBA claim issue

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Vijaya Mohan Guvva 

commit dcaf9aed995c2b2a49fb86bbbcfa2f92c797ab5d upstream.

Bfa driver crash is observed while pushing the firmware on to chinook
quad port card due to uninitialized bfi_image_ct2 access which gets
initialized only for CT2 ASIC based cards after request_firmware().
For quard port chinook (CT2 ASIC based), bfi_image_ct2 is not getting
initialized as there is no check for chinook PCI device ID before
request_firmware and instead bfi_image_cb is initialized as it is the
default case for card type check.

This patch includes changes to read the right firmware for quad port chinook.

Signed-off-by: Vijaya Mohan Guvva 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings 
---
 drivers/scsi/bfa/bfad.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -1613,7 +1613,7 @@ out:
 static u32 *
 bfad_load_fwimg(struct pci_dev *pdev)
 {
-   if (pdev->device == BFA_PCI_DEVICE_ID_CT2) {
+   if (bfa_asic_id_ct2(pdev->device)) {
if (bfi_image_ct2_size == 0)
bfad_read_firmware(pdev, &bfi_image_ct2,
&bfi_image_ct2_size, BFAD_FW_FILE_CT2);
@@ -1623,12 +1623,14 @@ bfad_load_fwimg(struct pci_dev *pdev)
bfad_read_firmware(pdev, &bfi_image_ct,
&bfi_image_ct_size, BFAD_FW_FILE_CT);
return bfi_image_ct;
-   } else {
+   } else if (bfa_asic_id_cb(pdev->device)) {
if (bfi_image_cb_size == 0)
bfad_read_firmware(pdev, &bfi_image_cb,
&bfi_image_cb_size, BFAD_FW_FILE_CB);
return bfi_image_cb;
}
+
+   return NULL;
 }
 
 static void

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 040/200] KVM: x86: limit PIT timer frequency

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Marcelo Tosatti 

commit 9ed96e87c5748de4c2807ef17e81287c7304186c upstream.

Limit PIT timer frequency similarly to the limit applied by
LAPIC timer.

Reviewed-by: Jan Kiszka 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Paolo Bonzini 
[bwh: Backported to 3.2:
 - Adjust context
 - s/ps->period/pt->period/]
Signed-off-by: Ben Hutchings 
---
 arch/x86/kvm/i8254.c | 18 ++
 arch/x86/kvm/lapic.c |  3 ---
 arch/x86/kvm/x86.c   |  3 +++
 arch/x86/kvm/x86.h   |  2 ++
 4 files changed, 23 insertions(+), 3 deletions(-)

--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -38,6 +38,7 @@
 
 #include "irq.h"
 #include "i8254.h"
+#include "x86.h"
 
 #ifndef CONFIG_X86_64
 #define mod_64(x, y) ((x) - (y) * div64_u64(x, y))
@@ -364,6 +365,23 @@ static void create_pit_timer(struct kvm
atomic_set(&pt->pending, 0);
ps->irq_ack = 1;
 
+   /*
+* Do not allow the guest to program periodic timers with small
+* interval, since the hrtimers are not throttled by the host
+* scheduler.
+*/
+   if (ps->is_periodic) {
+   s64 min_period = min_timer_period_us * 1000LL;
+
+   if (pt->period < min_period) {
+   pr_info_ratelimited(
+   "kvm: requested %lld ns "
+   "i8254 timer period limited to %lld ns\n",
+   pt->period, min_period);
+   pt->period = min_period;
+   }
+   }
+
hrtimer_start(&pt->timer, ktime_add_ns(ktime_get(), interval),
  HRTIMER_MODE_ABS);
 }
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -68,9 +68,6 @@
 #define VEC_POS(v) ((v) & (32 - 1))
 #define REG_POS(v) (((v) >> 5) << 4)
 
-static unsigned int min_timer_period_us = 500;
-module_param(min_timer_period_us, uint, S_IRUGO | S_IWUSR);
-
 static inline u32 apic_get_reg(struct kvm_lapic *apic, int reg_off)
 {
return *((u32 *) (apic->regs + reg_off));
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -92,6 +92,9 @@ EXPORT_SYMBOL_GPL(kvm_x86_ops);
 int ignore_msrs = 0;
 module_param_named(ignore_msrs, ignore_msrs, bool, S_IRUGO | S_IWUSR);
 
+unsigned int min_timer_period_us = 500;
+module_param(min_timer_period_us, uint, S_IRUGO | S_IWUSR);
+
 bool kvm_has_tsc_control;
 EXPORT_SYMBOL_GPL(kvm_has_tsc_control);
 u32  kvm_max_guest_tsc_khz;
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -125,4 +125,6 @@ int kvm_write_guest_virt_system(struct x
gva_t addr, void *val, unsigned int bytes,
struct x86_exception *exception);
 
+extern unsigned int min_timer_period_us;
+
 #endif

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


[PATCH 3.2 043/200] libata: disable LPM for some WD SATA-I devices

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit ecd75ad514d73efc1bbcc5f10a13566c3ace5f53 upstream.

For some reason, some early WD drives spin up and down drives
erratically when the link is put into slumber mode which can reduce
the life expectancy of the device significantly.  Unfortunately, we
don't have full list of devices and given the nature of the issue it'd
be better to err on the side of false positives than the other way
around.  Let's disable LPM on all WD devices which match one of the
known problematic model prefixes and are SATA-I.

As horkage list doesn't support matching SATA capabilities, this is
implemented as two horkages - WD_BROKEN_LPM and NOLPM.  The former is
set for the known prefixes and sets the latter if the matched device
is SATA-I.

Note that this isn't optimal as this disables all LPM operations and
partial link power state reportedly works fine on these; however, the
way LPM is implemented in libata makes it difficult to precisely map
libata LPM setting to specific link power state.  Well, these devices
are already fairly outdated.  Let's just disable whole LPM for now.

Signed-off-by: Tejun Heo 
Reported-and-tested-by: Nikos Barkas 
Reported-and-tested-by: Ioannis Barkas 
References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
[bwh: Backported to 3.2:
 - Adjust context
 - Use literal 76 instead of ATA_ID_SATA_CAPABILITY]
Signed-off-by: Ben Hutchings 
---
 drivers/ata/libata-core.c | 27 +++
 drivers/ata/libata-scsi.c | 18 +++---
 include/linux/libata.h|  2 ++
 3 files changed, 44 insertions(+), 3 deletions(-)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -2188,6 +2188,16 @@ int ata_dev_configure(struct ata_device
if (rc)
return rc;
 
+   /* some WD SATA-1 drives have issues with LPM, turn on NOLPM for them */
+   if ((dev->horkage & ATA_HORKAGE_WD_BROKEN_LPM) &&
+   (id[76] & 0xe) == 0x2)
+   dev->horkage |= ATA_HORKAGE_NOLPM;
+
+   if (dev->horkage & ATA_HORKAGE_NOLPM) {
+   ata_dev_warn(dev, "LPM support broken, forcing max_power\n");
+   dev->link->ap->target_lpm_policy = ATA_LPM_MAX_POWER;
+   }
+
/* let ACPI work its magic */
rc = ata_acpi_on_devcfg(dev);
if (rc)
@@ -4143,6 +4153,23 @@ static const struct ata_blacklist_entry
{ "PIONEER DVD-RW  DVR-212D",   NULL,   ATA_HORKAGE_NOSETXFER },
{ "PIONEER DVD-RW  DVR-216D",   NULL,   ATA_HORKAGE_NOSETXFER },
 
+   /*
+* Some WD SATA-I drives spin up and down erratically when the link
+* is put into the slumber mode.  We don't have full list of the
+* affected devices.  Disable LPM if the device matches one of the
+* known prefixes and is SATA-1.  As a side effect LPM partial is
+* lost too.
+*
+* https://bugzilla.kernel.org/show_bug.cgi?id=57211
+*/
+   { "WDC WD800JD-*",  NULL,   ATA_HORKAGE_WD_BROKEN_LPM },
+   { "WDC WD1200JD-*", NULL,   ATA_HORKAGE_WD_BROKEN_LPM },
+   { "WDC WD1600JD-*", NULL,   ATA_HORKAGE_WD_BROKEN_LPM },
+   { "WDC WD2000JD-*", NULL,   ATA_HORKAGE_WD_BROKEN_LPM },
+   { "WDC WD2500JD-*", NULL,   ATA_HORKAGE_WD_BROKEN_LPM },
+   { "WDC WD3000JD-*", NULL,   ATA_HORKAGE_WD_BROKEN_LPM },
+   { "WDC WD3200JD-*", NULL,   ATA_HORKAGE_WD_BROKEN_LPM },
+
/* End Marker */
{ }
 };
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -111,12 +111,14 @@ static const char *ata_lpm_policy_names[
[ATA_LPM_MIN_POWER] = "min_power",
 };
 
-static ssize_t ata_scsi_lpm_store(struct device *dev,
+static ssize_t ata_scsi_lpm_store(struct device *device,
  struct device_attribute *attr,
  const char *buf, size_t count)
 {
-   struct Scsi_Host *shost = class_to_shost(dev);
+   struct Scsi_Host *shost = class_to_shost(device);
struct ata_port *ap = ata_shost_to_port(shost);
+   struct ata_link *link;
+   struct ata_device *dev;
enum ata_lpm_policy policy;
unsigned long flags;
 
@@ -132,10 +134,20 @@ static ssize_t ata_scsi_lpm_store(struct
return -EINVAL;
 
spin_lock_irqsave(ap->lock, flags);
+
+   ata_for_each_link(link, ap, EDGE) {
+   ata_for_each_dev(dev, &ap->link, ENABLED) {
+   if (dev->horkage & ATA_HORKAGE_NOLPM) {
+   count = -EOPNOTSUPP;
+   goto out_unlock;
+   }
+   }
+   }
+
ap->target_lpm_policy = policy;
ata_port_schedule_eh(ap);
+out_unlock:
spin_unlock_irqrestore(ap->lock, flags);
-
return count;
 }
 
--- a/include/linux/libata.h
+++ b/include/lin

[PATCH 3.2 069/200] ata: enable quirk from jmicron JMB350 for JMB394

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Denis V. Lunev" 

commit efb9e0f4f43780f0ae0c6428d66bd03e805c7539 upstream.

Without the patch the kernel generates the following error.

 ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123'
 ata11.15: PMP revalidation failed (errno=-19)
 ata11.15: failed to recover PMP after 5 tries, giving up

This patch helps to bypass this error and the device becomes
functional.

Signed-off-by: Denis V. Lunev 
Signed-off-by: Tejun Heo 
Cc: 
Signed-off-by: Ben Hutchings 
---
 drivers/ata/libata-pmp.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/ata/libata-pmp.c
+++ b/drivers/ata/libata-pmp.c
@@ -447,8 +447,11 @@ static void sata_pmp_quirks(struct ata_p
 * otherwise.  Don't try hard to recover it.
 */
ap->pmp_link[ap->nr_pmp_links - 1].flags |= ATA_LFLAG_NO_RETRY;
-   } else if (vendor == 0x197b && devid == 0x2352) {
-   /* chip found in Thermaltake BlackX Duet, jmicron JMB350? */
+   } else if (vendor == 0x197b && (devid == 0x2352 || devid == 0x0325)) {
+   /*
+* 0x2352: found in Thermaltake BlackX Duet, jmicron JMB350?
+* 0x0325: jmicron JMB394.
+*/
ata_for_each_link(link, ap, EDGE) {
/* SRST breaks detection and disks get misclassified
 * LPM disabled to avoid potential problems

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 083/200] of: fix PCI bus match for PCIe slots

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Kleber Sacilotto de Souza 

commit 14e2abb732e485ee57d9d5b2cb8884652238e5c1 upstream.

On IBM pseries systems the device_type device-tree property of a PCIe
bridge contains the string "pciex". The of_bus_pci_match() function was
looking only for "pci" on this property, so in such cases the bus
matching code was falling back to the default bus, causing problems on
functions that should be using "assigned-addresses" for region address
translation. This patch fixes the problem by also looking for "pciex" on
the PCI bus match function.

v2: added comment

Signed-off-by: Kleber Sacilotto de Souza 
Acked-by: Grant Likely 
Signed-off-by: Rob Herring 
Signed-off-by: Ben Hutchings 
---
 drivers/of/address.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -98,11 +98,12 @@ static unsigned int of_bus_default_get_f
 static int of_bus_pci_match(struct device_node *np)
 {
/*
+* "pciex" is PCI Express
 * "vci" is for the /chaos bridge on 1st-gen PCI powermacs
 * "ht" is hypertransport
 */
-   return !strcmp(np->type, "pci") || !strcmp(np->type, "vci") ||
-   !strcmp(np->type, "ht");
+   return !strcmp(np->type, "pci") || !strcmp(np->type, "pciex") ||
+   !strcmp(np->type, "vci") || !strcmp(np->type, "ht");
 }
 
 static void of_bus_pci_count_cells(struct device_node *np,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 012/200] x86/efi: Fix off-by-one bug in EFI Boot Services reservation

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dave Young 

commit a7f84f03f660d93574ac88835d056c0d6468aebe upstream.

Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.

I see this problem in ovmf + Fedora 19 grub boot:
text start: 100 md start: 80 md size: 80

Signed-off-by: Dave Young 
Acked-by: Borislav Petkov 
Acked-by: Toshi Kani 
Tested-by: Toshi Kani 
Signed-off-by: Matt Fleming 
[bwh: Backported to 3.2: s/__pa_symbol/virt_to_phys/]
Signed-off-by: Ben Hutchings 
---
 arch/x86/platform/efi/efi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -424,7 +424,7 @@ void __init efi_reserve_boot_services(vo
 * - Not within any part of the kernel
 * - Not the bios reserved area
*/
-   if ((start+size >= virt_to_phys(_text)
+   if ((start + size > virt_to_phys(_text)
&& start <= virt_to_phys(_end)) ||
!e820_all_mapped(start, start+size, E820_RAM) ||
memblock_x86_check_reserved_size(&start, &size,

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


[PATCH 3.2 062/200] KVM: return an error code in kvm_vm_ioctl_register_coalesced_mmio()

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit aac5c4226e7136c331ed384c25d5560204da10a0 upstream.

If kvm_io_bus_register_dev() fails then it returns success but it should
return an error code.

I also did a little cleanup like removing an impossible NULL test.

Fixes: 2b3c246a682c ('KVM: Make coalesced mmio use a device per zone')
Signed-off-by: Dan Carpenter 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Ben Hutchings 
---
 virt/kvm/coalesced_mmio.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

--- a/virt/kvm/coalesced_mmio.c
+++ b/virt/kvm/coalesced_mmio.c
@@ -148,17 +148,13 @@ int kvm_vm_ioctl_register_coalesced_mmio
list_add_tail(&dev->list, &kvm->coalesced_zones);
mutex_unlock(&kvm->slots_lock);
 
-   return ret;
+   return 0;
 
 out_free_dev:
mutex_unlock(&kvm->slots_lock);
-
kfree(dev);
 
-   if (dev == NULL)
-   return -ENXIO;
-
-   return 0;
+   return ret;
 }
 
 int kvm_vm_ioctl_unregister_coalesced_mmio(struct kvm *kvm,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 047/200] drm/radeon: set the full cache bit for fences on r7xx+

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Alex Deucher 

commit d45b964a22cad962d3ede1eba8d24f5cee7b2a92 upstream.

Needed to properly flush the read caches for fences.

Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2:
 - Adjust context
 - s/\bring\b/rdev/]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2315,14 +2315,18 @@ int r600_ring_test(struct radeon_device
 void r600_fence_ring_emit(struct radeon_device *rdev,
  struct radeon_fence *fence)
 {
+   u32 cp_coher_cntl = PACKET3_TC_ACTION_ENA | PACKET3_VC_ACTION_ENA |
+   PACKET3_SH_ACTION_ENA;
+
+   if (rdev->family >= CHIP_RV770)
+   cp_coher_cntl |= PACKET3_FULL_CACHE_ENA;
+
if (rdev->wb.use_event) {
u64 addr = rdev->wb.gpu_addr + R600_WB_EVENT_OFFSET +
(u64)(rdev->fence_drv.scratch_reg - 
rdev->scratch.reg_base);
/* flush read cache over gart */
radeon_ring_write(rdev, PACKET3(PACKET3_SURFACE_SYNC, 3));
-   radeon_ring_write(rdev, PACKET3_TC_ACTION_ENA |
-   PACKET3_VC_ACTION_ENA |
-   PACKET3_SH_ACTION_ENA);
+   radeon_ring_write(rdev, cp_coher_cntl);
radeon_ring_write(rdev, 0x);
radeon_ring_write(rdev, 0);
radeon_ring_write(rdev, 10); /* poll interval */
@@ -2336,9 +2340,7 @@ void r600_fence_ring_emit(struct radeon_
} else {
/* flush read cache over gart */
radeon_ring_write(rdev, PACKET3(PACKET3_SURFACE_SYNC, 3));
-   radeon_ring_write(rdev, PACKET3_TC_ACTION_ENA |
-   PACKET3_VC_ACTION_ENA |
-   PACKET3_SH_ACTION_ENA);
+   radeon_ring_write(rdev, cp_coher_cntl);
radeon_ring_write(rdev, 0x);
radeon_ring_write(rdev, 0);
radeon_ring_write(rdev, 10); /* poll interval */
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -838,6 +838,7 @@
 #definePACKET3_INDIRECT_BUFFER 0x32
 #definePACKET3_SURFACE_SYNC0x43
 #  define PACKET3_CB0_DEST_BASE_ENA(1 << 6)
+#  define PACKET3_FULL_CACHE_ENA   (1 << 20) /* r7xx+ only */
 #  define PACKET3_TC_ACTION_ENA(1 << 23)
 #  define PACKET3_VC_ACTION_ENA(1 << 24)
 #  define PACKET3_CB_ACTION_ENA(1 << 25)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 081/200] ALSA: hda/realtek - Avoid invalid COEFs for ALC271X

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit d3c56568f43807135f2c2a09582a69f809f0d8b7 upstream.

We've seen often problems after suspend/resume on Acer Aspire One
AO725 with ALC271X codec as reported in kernel bugzilla, and it turned
out that some COEFs doesn't work and triggers the codec communication
stall.

Since these magic COEF setups are specific to ALC269VB for some PLL
configurations, the machine works even without these manual
adjustment.  So, let's simply avoid applying them for ALC271X.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: return 0]
Signed-off-by: Ben Hutchings 
---
 sound/pci/hda/patch_realtek.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5157,6 +5157,9 @@ static int alc269_fill_coef(struct hda_c
 
if (spec->codec_variant != ALC269_TYPE_ALC269VB)
return 0;
+   /* ALC271X doesn't seem to support these COEFs (bko#52181) */
+   if (!strcmp(codec->chip_name, "ALC271X"))
+   return 0;
 
if ((alc_get_coef0(codec) & 0x00ff) < 0x015) {
alc_write_coef_idx(codec, 0xf, 0x960b);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 078/200] usb-storage: restrict bcdDevice range for Super Top in Cypress ATACB

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Alan Stern 

commit a9c143c82608bee2a36410caa56d82cd86bdc7fa upstream.

The Cypress ATACB unusual-devs entry for the Super Top SATA bridge
causes problems.  Although it was originally reported only for
bcdDevice = 0x160, its range was much larger.  This resulted in a bug
report for bcdDevice 0x220, so the range was capped at 0x219.  Now
Milan reports errors with bcdDevice 0x150.

Therefore this patch restricts the range to just 0x160.

Signed-off-by: Alan Stern 
Reported-and-tested-by: Milan Svoboda 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/storage/unusual_cypress.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/storage/unusual_cypress.h
+++ b/drivers/usb/storage/unusual_cypress.h
@@ -31,7 +31,7 @@ UNUSUAL_DEV(  0x04b4, 0x6831, 0x, 0x
"Cypress ISD-300LP",
USB_SC_CYP_ATACB, USB_PR_DEVICE, NULL, 0),
 
-UNUSUAL_DEV( 0x14cd, 0x6116, 0x, 0x0219,
+UNUSUAL_DEV( 0x14cd, 0x6116, 0x0160, 0x0160,
"Super Top",
"USB 2.0  SATA BRIDGE",
USB_SC_CYP_ATACB, USB_PR_DEVICE, NULL, 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.2 064/200] s390/crypto: Don't panic after crypto instruction failures

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jan Glauber 

commit 36eb2caa7bace31b7868a57f77cb148e58d1c9f9 upstream.

Remove the BUG_ON's that check for failure or incomplete
results of the s390 hardware crypto instructions.
Rather report the errors as -EIO to the crypto layer.

Signed-off-by: Jan Glauber 
Signed-off-by: Martin Schwidefsky 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 arch/s390/crypto/aes_s390.c   | 18 --
 arch/s390/crypto/des_s390.c   | 12 
 arch/s390/crypto/ghash_s390.c | 21 +
 arch/s390/crypto/sha_common.c |  9 ++---
 4 files changed, 39 insertions(+), 21 deletions(-)

--- a/arch/s390/crypto/aes_s390.c
+++ b/arch/s390/crypto/aes_s390.c
@@ -324,7 +324,8 @@ static int ecb_aes_crypt(struct blkciphe
u8 *in = walk->src.virt.addr;
 
ret = crypt_s390_km(func, param, out, in, n);
-   BUG_ON((ret < 0) || (ret != n));
+   if (ret < 0 || ret != n)
+   return -EIO;
 
nbytes &= AES_BLOCK_SIZE - 1;
ret = blkcipher_walk_done(desc, walk, nbytes);
@@ -463,7 +464,8 @@ static int cbc_aes_crypt(struct blkciphe
u8 *in = walk->src.virt.addr;
 
ret = crypt_s390_kmc(func, ¶m, out, in, n);
-   BUG_ON((ret < 0) || (ret != n));
+   if (ret < 0 || ret != n)
+   return -EIO;
 
nbytes &= AES_BLOCK_SIZE - 1;
ret = blkcipher_walk_done(desc, walk, nbytes);
@@ -636,7 +638,8 @@ static int xts_aes_crypt(struct blkciphe
memcpy(pcc_param.tweak, walk->iv, sizeof(pcc_param.tweak));
memcpy(pcc_param.key, xts_ctx->pcc_key, 32);
ret = crypt_s390_pcc(func, &pcc_param.key[offset]);
-   BUG_ON(ret < 0);
+   if (ret < 0)
+   return -EIO;
 
memcpy(xts_param.key, xts_ctx->key, 32);
memcpy(xts_param.init, pcc_param.xts, 16);
@@ -647,7 +650,8 @@ static int xts_aes_crypt(struct blkciphe
in = walk->src.virt.addr;
 
ret = crypt_s390_km(func, &xts_param.key[offset], out, in, n);
-   BUG_ON(ret < 0 || ret != n);
+   if (ret < 0 || ret != n)
+   return -EIO;
 
nbytes &= AES_BLOCK_SIZE - 1;
ret = blkcipher_walk_done(desc, walk, nbytes);
@@ -781,7 +785,8 @@ static int ctr_aes_crypt(struct blkciphe
crypto_inc(ctrblk + i, AES_BLOCK_SIZE);
}
ret = crypt_s390_kmctr(func, sctx->key, out, in, n, 
ctrblk);
-   BUG_ON(ret < 0 || ret != n);
+   if (ret < 0 || ret != n)
+   return -EIO;
if (n > AES_BLOCK_SIZE)
memcpy(ctrblk, ctrblk + n - AES_BLOCK_SIZE,
   AES_BLOCK_SIZE);
@@ -800,7 +805,8 @@ static int ctr_aes_crypt(struct blkciphe
in = walk->src.virt.addr;
ret = crypt_s390_kmctr(func, sctx->key, buf, in,
   AES_BLOCK_SIZE, ctrblk);
-   BUG_ON(ret < 0 || ret != AES_BLOCK_SIZE);
+   if (ret < 0 || ret != AES_BLOCK_SIZE)
+   return -EIO;
memcpy(out, buf, nbytes);
crypto_inc(ctrblk, AES_BLOCK_SIZE);
ret = blkcipher_walk_done(desc, walk, 0);
--- a/arch/s390/crypto/des_s390.c
+++ b/arch/s390/crypto/des_s390.c
@@ -95,7 +95,8 @@ static int ecb_desall_crypt(struct blkci
u8 *in = walk->src.virt.addr;
 
ret = crypt_s390_km(func, key, out, in, n);
-   BUG_ON((ret < 0) || (ret != n));
+   if (ret < 0 || ret != n)
+   return -EIO;
 
nbytes &= DES_BLOCK_SIZE - 1;
ret = blkcipher_walk_done(desc, walk, nbytes);
@@ -121,7 +122,8 @@ static int cbc_desall_crypt(struct blkci
u8 *in = walk->src.virt.addr;
 
ret = crypt_s390_kmc(func, iv, out, in, n);
-   BUG_ON((ret < 0) || (ret != n));
+   if (ret < 0 || ret != n)
+   return -EIO;
 
nbytes &= DES_BLOCK_SIZE - 1;
ret = blkcipher_walk_done(desc, walk, nbytes);
@@ -394,7 +396,8 @@ static int ctr_desall_crypt(struct blkci
crypto_inc(ctrblk + i, DES_BLOCK_SIZE);
}
ret = crypt_s390_kmctr(func, ctx->key, out, in, n, 
ctrblk);
-   BUG_ON((ret < 0) || (ret != n));
+   if (ret < 0 || ret != n)
+   return -EIO;
if (n > DES_BLOCK_SIZE)
memcpy(ctrblk, ctrblk + n - DES_BLOCK_SIZE,
 

[PATCH 3.2 013/200] rtc-cmos: Add an alarm disable quirk

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Borislav Petkov 

commit d5a1c7e3fc38d9c7d629e1e47f32f863acbdec3d upstream.

41c7f7424259f ("rtc: Disable the alarm in the hardware (v2)") added the
functionality to disable the RTC wake alarm when shutting down the box.

However, there are at least two b0rked BIOSes we know about:

https://bugzilla.novell.com/show_bug.cgi?id=812592
https://bugzilla.novell.com/show_bug.cgi?id=805740

where, when wakeup alarm is enabled in the BIOS, the machine reboots
automatically right after shutdown, regardless of what wakeup time is
programmed.

Bisecting the issue lead to this patch so disable its functionality with
a DMI quirk only for those boxes.

Cc: Brecht Machiels 
Cc: Thomas Gleixner 
Cc: John Stultz 
Cc: Rabin Vincent 
Signed-off-by: Borislav Petkov 
[jstultz: Changed variable name for clarity, added extra dmi entry]
Tested-by: Brecht Machiels 
Tested-by: Borislav Petkov 
Signed-off-by: John Stultz 
Signed-off-by: Ben Hutchings 
---
 drivers/rtc/rtc-cmos.c | 52 +-
 1 file changed, 51 insertions(+), 1 deletion(-)

--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -34,11 +34,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
 #include 
@@ -377,6 +377,51 @@ static int cmos_set_alarm(struct device
return 0;
 }
 
+/*
+ * Do not disable RTC alarm on shutdown - workaround for b0rked BIOSes.
+ */
+static bool alarm_disable_quirk;
+
+static int __init set_alarm_disable_quirk(const struct dmi_system_id *id)
+{
+   alarm_disable_quirk = true;
+   pr_info("rtc-cmos: BIOS has alarm-disable quirk. ");
+   pr_info("RTC alarms disabled\n");
+   return 0;
+}
+
+static const struct dmi_system_id rtc_quirks[] __initconst = {
+   /* https://bugzilla.novell.com/show_bug.cgi?id=805740 */
+   {
+   .callback = set_alarm_disable_quirk,
+   .ident= "IBM Truman",
+   .matches  = {
+   DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "4852570"),
+   },
+   },
+   /* https://bugzilla.novell.com/show_bug.cgi?id=812592 */
+   {
+   .callback = set_alarm_disable_quirk,
+   .ident= "Gigabyte GA-990XA-UD3",
+   .matches  = {
+   DMI_MATCH(DMI_SYS_VENDOR,
+   "Gigabyte Technology Co., Ltd."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "GA-990XA-UD3"),
+   },
+   },
+   /* http://permalink.gmane.org/gmane.linux.kernel/1604474 */
+   {
+   .callback = set_alarm_disable_quirk,
+   .ident= "Toshiba Satellite L300",
+   .matches  = {
+   DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Satellite L300"),
+   },
+   },
+   {}
+};
+
 static int cmos_alarm_irq_enable(struct device *dev, unsigned int enabled)
 {
struct cmos_rtc *cmos = dev_get_drvdata(dev);
@@ -385,6 +430,9 @@ static int cmos_alarm_irq_enable(struct
if (!is_valid_irq(cmos->irq))
return -EINVAL;
 
+   if (alarm_disable_quirk)
+   return 0;
+
spin_lock_irqsave(&rtc_lock, flags);
 
if (enabled)
@@ -1166,6 +1214,8 @@ static int __init cmos_init(void)
platform_driver_registered = true;
}
 
+   dmi_check_system(rtc_quirks);
+
if (retval == 0)
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.2 068/200] mm, oom: base root bonus on current usage

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: David Rientjes 

commit 778c14affaf94a9e4953179d3e13a544ccce7707 upstream.

A 3% of system memory bonus is sometimes too excessive in comparison to
other processes.

With commit a63d83f427fb ("oom: badness heuristic rewrite"), the OOM
killer tries to avoid killing privileged tasks by subtracting 3% of
overall memory (system or cgroup) from their per-task consumption.  But
as a result, all root tasks that consume less than 3% of overall memory
are considered equal, and so it only takes 33+ privileged tasks pushing
the system out of memory for the OOM killer to do something stupid and
kill dhclient or other root-owned processes.  For example, on a 32G
machine it can't tell the difference between the 1M agetty and the 10G
fork bomb member.

The changelog describes this 3% boost as the equivalent to the global
overcommit limit being 3% higher for privileged tasks, but this is not
the same as discounting 3% of overall memory from _every privileged task
individually_ during OOM selection.

Replace the 3% of system memory bonus with a 3% of current memory usage
bonus.

By giving root tasks a bonus that is proportional to their actual size,
they remain comparable even when relatively small.  In the example
above, the OOM killer will discount the 1M agetty's 256 badness points
down to 179, and the 10G fork bomb's 262144 points down to 183500 points
and make the right choice, instead of discounting both to 0 and killing
agetty because it's first in the task list.

Signed-off-by: David Rientjes 
Reported-by: Johannes Weiner 
Acked-by: Johannes Weiner 
Cc: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: existing code changes 'points' directly rather
 than using 'adj' variable]
Signed-off-by: Ben Hutchings 
---
 Documentation/filesystems/proc.txt | 4 ++--
 mm/oom_kill.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1293,8 +1293,8 @@ may allocate from based on an estimation
 For example, if a task is using all allowed memory, its badness score will be
 1000.  If it is using half of its allowed memory, its score will be 500.
 
-There is an additional factor included in the badness score: root
-processes are given 3% extra memory over other tasks.
+There is an additional factor included in the badness score: the current memory
+and swap usage is discounted by 3% for root processes.
 
 The amount of "allowed" memory depends on the context in which the oom killer
 was called.  If it is due to the memory assigned to the allocating task's 
cpuset
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -213,7 +213,7 @@ unsigned int oom_badness(struct task_str
 * implementation used by LSMs.
 */
if (has_capability_noaudit(p, CAP_SYS_ADMIN))
-   points -= 30;
+   points -= (points * 3) / 100;
 
/*
 * /proc/pid/oom_score_adj ranges from -1000 to +1000 such that it may

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 071/200] power: max17040: Fix NULL pointer dereference when there is no platform_data

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Krzysztof Kozlowski 

commit ac323d8d807060f7c95a685a9fe861e7b6300993 upstream.

Fix NULL pointer dereference of "chip->pdata" if platform_data was not
supplied to the driver.

The driver during probe stored the pointer to the platform_data:
chip->pdata = client->dev.platform_data;
Later it was dereferenced in max17040_get_online() and
max17040_get_status().

If platform_data was not supplied, the NULL pointer exception would
happen:

[6.626094] Unable to handle kernel  of a at virtual address 
[6.628557] pgd = c0004000
[6.632868] [] *pgd=66262564
[6.634636] Unable to handle kernel paging request at virtual address 
e6262000
[6.642014] pgd = de468000
[6.644700] [e6262000] *pgd=
[6.648265] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[6.653552] Modules linked in:
[6.656598] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 
3.10.14-02717-gc58b4b4 #505
[6.664334] Workqueue: events max17040_work
[6.668488] task: dfa11b80 ti: df9f6000 task.ti: df9f6000
[6.673873] PC is at show_pte+0x80/0xb8
[6.677687] LR is at show_pte+0x3c/0xb8
[6.681503] pc : []lr : []psr: 600f0113
[6.681503] sp : df9f7d58  ip : 600f0113  fp : 0009
[6.692965] r10:   r9 :   r8 : dfa11b80
[6.698171] r7 : df9f7ea0  r6 : e6262000  r5 :   r4 : 
[6.704680] r3 :   r2 : e6262000  r1 : 600f0193  r0 : c05b3750
[6.711194] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[6.718485] Control: 10c53c7d  Table: 5e46806a  DAC: 0015
[6.724218] Process kworker/0:1 (pid: 31, stack limit = 0xdf9f6238)
[6.730465] Stack: (0xdf9f7d58 to 0xdf9f8000)
[6.914325] [] (show_pte+0x80/0xb8) from [] 
(__do_kernel_fault.part.9+0x44/0x74)
[6.923425] [] (__do_kernel_fault.part.9+0x44/0x74) from 
[] (do_page_fault+0x2c4/0x360)
[6.933144] [] (do_page_fault+0x2c4/0x360) from [] 
(do_DataAbort+0x34/0x9c)
[6.941825] [] (do_DataAbort+0x34/0x9c) from [] 
(__dabt_svc+0x38/0x60)
[6.950058] Exception stack(0xdf9f7ea0 to 0xdf9f7ee8)
[6.955099] 7ea0: df0c1790  0002  df0c1794 df0c1790 
df0c1790 0042
[6.963271] 7ec0: df0c1794 0001  0009  df9f7ee8 
c0306268 c0306270
[6.971419] 7ee0: a00f0113 
[6.974902] [] (__dabt_svc+0x38/0x60) from [] 
(max17040_work+0x8c/0x144)
[6.983317] [] (max17040_work+0x8c/0x144) from [] 
(process_one_work+0x138/0x440)
[6.992429] [] (process_one_work+0x138/0x440) from [] 
(worker_thread+0x134/0x3b8)
[7.001628] [] (worker_thread+0x134/0x3b8) from [] 
(kthread+0xa4/0xb0)
[7.009875] [] (kthread+0xa4/0xb0) from [] 
(ret_from_fork+0x14/0x2c)
[7.017943] Code: e1a03005 e2422480 e0826104 e59f002c (e7922104)
[7.024017] ---[ end trace 73bc7006b9cc5c79 ]---

Signed-off-by: Krzysztof Kozlowski 
Fixes: c6f4a42de60b981dd210de01cd3e575835e3158e
Signed-off-by: Ben Hutchings 
---
 drivers/power/max17040_battery.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/power/max17040_battery.c
+++ b/drivers/power/max17040_battery.c
@@ -148,7 +148,7 @@ static void max17040_get_online(struct i
 {
struct max17040_chip *chip = i2c_get_clientdata(client);
 
-   if (chip->pdata->battery_online)
+   if (chip->pdata && chip->pdata->battery_online)
chip->online = chip->pdata->battery_online();
else
chip->online = 1;
@@ -158,7 +158,8 @@ static void max17040_get_status(struct i
 {
struct max17040_chip *chip = i2c_get_clientdata(client);
 
-   if (!chip->pdata->charger_online || !chip->pdata->charger_enable) {
+   if (!chip->pdata || !chip->pdata->charger_online
+   || !chip->pdata->charger_enable) {
chip->status = POWER_SUPPLY_STATUS_UNKNOWN;
return;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 073/200] [media] mxl111sf: Fix compile when CONFIG_DVB_USB_MXL111SF is unset

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dave Jones 

commit 13e1b87c986100169b0695aeb26970943665eda9 upstream.

Fix the following build error:

drivers/media/usb/dvb-usb-v2/
mxl111sf-tuner.h:72:9: error: expected ‘;’, ‘,’ or ‘)’ before ‘struct’
 struct mxl111sf_tuner_config *cfg)

Signed-off-by: Dave Jones 
Signed-off-by: Michael Krufky 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
 drivers/media/dvb/dvb-usb/mxl111sf-tuner.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/dvb/dvb-usb/mxl111sf-tuner.h
+++ b/drivers/media/dvb/dvb-usb/mxl111sf-tuner.h
@@ -69,7 +69,7 @@ struct dvb_frontend *mxl111sf_tuner_atta
 #else
 static inline
 struct dvb_frontend *mxl111sf_tuner_attach(struct dvb_frontend *fe,
-  struct mxl111sf_state *mxl_state
+  struct mxl111sf_state *mxl_state,
   struct mxl111sf_tuner_config *cfg)
 {
printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 066/200] crypto: s390 - fix des and des3_ede cbc concurrency issue

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Harald Freudenberger 

commit adc3fcf1552b6e406d172fd9690bbd1395053d13 upstream.

In s390 des and des3_ede cbc mode the iv value is not protected
against concurrency access and modifications from another running
en/decrypt operation which is using the very same tfm struct
instance. This fix copies the iv to the local stack before
the crypto operation and stores the value back when done.

Signed-off-by: Harald Freudenberger 
Signed-off-by: Herbert Xu 
Signed-off-by: Ben Hutchings 
---
 arch/s390/crypto/des_s390.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

--- a/arch/s390/crypto/des_s390.c
+++ b/arch/s390/crypto/des_s390.c
@@ -106,29 +106,35 @@ static int ecb_desall_crypt(struct blkci
 }
 
 static int cbc_desall_crypt(struct blkcipher_desc *desc, long func,
-   u8 *iv, struct blkcipher_walk *walk)
+   struct blkcipher_walk *walk)
 {
+   struct s390_des_ctx *ctx = crypto_blkcipher_ctx(desc->tfm);
int ret = blkcipher_walk_virt(desc, walk);
unsigned int nbytes = walk->nbytes;
+   struct {
+   u8 iv[DES_BLOCK_SIZE];
+   u8 key[DES3_KEY_SIZE];
+   } param;
 
if (!nbytes)
goto out;
 
-   memcpy(iv, walk->iv, DES_BLOCK_SIZE);
+   memcpy(param.iv, walk->iv, DES_BLOCK_SIZE);
+   memcpy(param.key, ctx->key, DES3_KEY_SIZE);
do {
/* only use complete blocks */
unsigned int n = nbytes & ~(DES_BLOCK_SIZE - 1);
u8 *out = walk->dst.virt.addr;
u8 *in = walk->src.virt.addr;
 
-   ret = crypt_s390_kmc(func, iv, out, in, n);
+   ret = crypt_s390_kmc(func, ¶m, out, in, n);
if (ret < 0 || ret != n)
return -EIO;
 
nbytes &= DES_BLOCK_SIZE - 1;
ret = blkcipher_walk_done(desc, walk, nbytes);
} while ((nbytes = walk->nbytes));
-   memcpy(walk->iv, iv, DES_BLOCK_SIZE);
+   memcpy(walk->iv, param.iv, DES_BLOCK_SIZE);
 
 out:
return ret;
@@ -181,22 +187,20 @@ static int cbc_des_encrypt(struct blkcip
   struct scatterlist *dst, struct scatterlist *src,
   unsigned int nbytes)
 {
-   struct s390_des_ctx *ctx = crypto_blkcipher_ctx(desc->tfm);
struct blkcipher_walk walk;
 
blkcipher_walk_init(&walk, dst, src, nbytes);
-   return cbc_desall_crypt(desc, KMC_DEA_ENCRYPT, ctx->iv, &walk);
+   return cbc_desall_crypt(desc, KMC_DEA_ENCRYPT, &walk);
 }
 
 static int cbc_des_decrypt(struct blkcipher_desc *desc,
   struct scatterlist *dst, struct scatterlist *src,
   unsigned int nbytes)
 {
-   struct s390_des_ctx *ctx = crypto_blkcipher_ctx(desc->tfm);
struct blkcipher_walk walk;
 
blkcipher_walk_init(&walk, dst, src, nbytes);
-   return cbc_desall_crypt(desc, KMC_DEA_DECRYPT, ctx->iv, &walk);
+   return cbc_desall_crypt(desc, KMC_DEA_DECRYPT, &walk);
 }
 
 static struct crypto_alg cbc_des_alg = {
@@ -333,22 +337,20 @@ static int cbc_des3_encrypt(struct blkci
struct scatterlist *dst, struct scatterlist *src,
unsigned int nbytes)
 {
-   struct s390_des_ctx *ctx = crypto_blkcipher_ctx(desc->tfm);
struct blkcipher_walk walk;
 
blkcipher_walk_init(&walk, dst, src, nbytes);
-   return cbc_desall_crypt(desc, KMC_TDEA_192_ENCRYPT, ctx->iv, &walk);
+   return cbc_desall_crypt(desc, KMC_TDEA_192_ENCRYPT, &walk);
 }
 
 static int cbc_des3_decrypt(struct blkcipher_desc *desc,
struct scatterlist *dst, struct scatterlist *src,
unsigned int nbytes)
 {
-   struct s390_des_ctx *ctx = crypto_blkcipher_ctx(desc->tfm);
struct blkcipher_walk walk;
 
blkcipher_walk_init(&walk, dst, src, nbytes);
-   return cbc_desall_crypt(desc, KMC_TDEA_192_DECRYPT, ctx->iv, &walk);
+   return cbc_desall_crypt(desc, KMC_TDEA_192_DECRYPT, &walk);
 }
 
 static struct crypto_alg cbc_des3_alg = {

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 063/200] target/iscsi: Fix network portal creation race

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Andy Grover 

commit ee291e63293146db64668e8d65eb35c97e8324f4 upstream.

When creating network portals rapidly, such as when restoring a
configuration, LIO's code to reuse existing portals can return a false
negative if the thread hasn't run yet and set np_thread_state to
ISCSI_NP_THREAD_ACTIVE. This causes an error in the network stack
when attempting to bind to the same address/port.

This patch sets NP_THREAD_ACTIVE before the np is placed on g_np_list,
so even if the thread hasn't run yet, iscsit_get_np will return the
existing np.

Also, convert np_lock -> np_mutex + hold across adding new net portal
to g_np_list to prevent a race where two threads may attempt to create
the same network portal, resulting in one of them failing.

(nab: Add missing mutex_unlocks in iscsit_add_np failure paths)
(DanC: Fix incorrect spin_unlock -> spin_unlock_bh)

Signed-off-by: Andy Grover 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Ben Hutchings 
---
 drivers/target/iscsi/iscsi_target.c | 34 +-
 1 file changed, 21 insertions(+), 13 deletions(-)

--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -50,7 +50,7 @@
 static LIST_HEAD(g_tiqn_list);
 static LIST_HEAD(g_np_list);
 static DEFINE_SPINLOCK(tiqn_lock);
-static DEFINE_SPINLOCK(np_lock);
+static DEFINE_MUTEX(np_lock);
 
 static struct idr tiqn_idr;
 struct idr sess_idr;
@@ -262,6 +262,9 @@ int iscsit_deaccess_np(struct iscsi_np *
return 0;
 }
 
+/*
+ * Called with mutex np_lock held
+ */
 static struct iscsi_np *iscsit_get_np(
struct __kernel_sockaddr_storage *sockaddr,
int network_transport)
@@ -272,11 +275,10 @@ static struct iscsi_np *iscsit_get_np(
int ip_match = 0;
u16 port;
 
-   spin_lock_bh(&np_lock);
list_for_each_entry(np, &g_np_list, np_list) {
-   spin_lock(&np->np_thread_lock);
+   spin_lock_bh(&np->np_thread_lock);
if (np->np_thread_state != ISCSI_NP_THREAD_ACTIVE) {
-   spin_unlock(&np->np_thread_lock);
+   spin_unlock_bh(&np->np_thread_lock);
continue;
}
 
@@ -309,13 +311,11 @@ static struct iscsi_np *iscsit_get_np(
 * while iscsi_tpg_add_network_portal() is called.
 */
np->np_exports++;
-   spin_unlock(&np->np_thread_lock);
-   spin_unlock_bh(&np_lock);
+   spin_unlock_bh(&np->np_thread_lock);
return np;
}
-   spin_unlock(&np->np_thread_lock);
+   spin_unlock_bh(&np->np_thread_lock);
}
-   spin_unlock_bh(&np_lock);
 
return NULL;
 }
@@ -329,16 +329,22 @@ struct iscsi_np *iscsit_add_np(
struct sockaddr_in6 *sock_in6;
struct iscsi_np *np;
int ret;
+
+   mutex_lock(&np_lock);
+
/*
 * Locate the existing struct iscsi_np if already active..
 */
np = iscsit_get_np(sockaddr, network_transport);
-   if (np)
+   if (np) {
+   mutex_unlock(&np_lock);
return np;
+   }
 
np = kzalloc(sizeof(struct iscsi_np), GFP_KERNEL);
if (!np) {
pr_err("Unable to allocate memory for struct iscsi_np\n");
+   mutex_unlock(&np_lock);
return ERR_PTR(-ENOMEM);
}
 
@@ -361,6 +367,7 @@ struct iscsi_np *iscsit_add_np(
ret = iscsi_target_setup_login_socket(np, sockaddr);
if (ret != 0) {
kfree(np);
+   mutex_unlock(&np_lock);
return ERR_PTR(ret);
}
 
@@ -369,6 +376,7 @@ struct iscsi_np *iscsit_add_np(
pr_err("Unable to create kthread: iscsi_np\n");
ret = PTR_ERR(np->np_thread);
kfree(np);
+   mutex_unlock(&np_lock);
return ERR_PTR(ret);
}
/*
@@ -379,10 +387,10 @@ struct iscsi_np *iscsit_add_np(
 * point because iscsi_np has not been added to g_np_list yet.
 */
np->np_exports = 1;
+   np->np_thread_state = ISCSI_NP_THREAD_ACTIVE;
 
-   spin_lock_bh(&np_lock);
list_add_tail(&np->np_list, &g_np_list);
-   spin_unlock_bh(&np_lock);
+   mutex_unlock(&np_lock);
 
pr_debug("CORE[0] - Added Network Portal: %s:%hu on %s\n",
np->np_ip, np->np_port, (np->np_network_transport == ISCSI_TCP) 
?
@@ -453,9 +461,9 @@ int iscsit_del_np(struct iscsi_np *np)
}
iscsit_del_np_comm(np);
 
-   spin_lock_bh(&np_lock);
+   mutex_lock(&np_lock);
list_del(&np->np_list);
-   spin_unlock_bh(&np_lock);
+   mutex_unlock(&np_lock);
 
pr_debug("CORE[0] - Removed Network Portal: %s:%hu on %s\n",
np->np_ip, np->

Re: xfs i_lock vs mmap_sem lockdep trace.

2014-03-30 Thread Dave Jones
On Mon, Mar 31, 2014 at 10:43:35AM +1100, Dave Chinner wrote:
 > On Sat, Mar 29, 2014 at 06:31:09PM -0400, Dave Jones wrote:
 > > Not sure if I've reported this already (it looks familiar, though I've not 
 > > managed
 > > to find it in my sent mail folder).  This is rc8 + a diff to fix the stack 
 > > usage reports
 > > I was seeing (diff at http://paste.fedoraproject.org/89854/13210913/raw)
 > > 
 > >  ==
 > >  [ INFO: possible circular locking dependency detected ]
 > >  3.14.0-rc8+ #153 Not tainted
 > >  ---
 > >  git/32710 is trying to acquire lock:
 > >   (&(&ip->i_lock)->mr_lock){.+}, at: [] 
 > > xfs_ilock+0x122/0x250 [xfs]
 > >  
 > > but task is already holding lock:
 > >   (&mm->mmap_sem){++}, at: [] 
 > > __do_page_fault+0x14a/0x610
 > > 
 > > which lock already depends on the new lock.
 > 
 > filldir on a directory inode vs page fault on regular file. Known
 > issue, definitely a false positive.

ah yeah, thought it looked familiar. I think I reported this last summer.

 > We have to change locking
 > algorithms to avoid such deficiencies of lockdep (a case of "lockdep
 > considered harmful", perhaps?) so it's not something I'm about to
 > rush...

Bummer, as it makes lockdep useless on my test box using xfs because it
disables itself after hitting this very quickly.
(I re-enabled it a couple days ago wondering why I'd left it turned off,
 chances are it was because of this)

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 065/200] crypto: s390 - fix concurrency issue in aes-ctr mode

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Harald Freudenberger 

commit 0519e9ad89e5cd6e6b08398f57c6a71d9580564c upstream.

The aes-ctr mode uses one preallocated page without any concurrency
protection. When multiple threads run aes-ctr encryption or decryption
this can lead to data corruption.

The patch introduces locking for the page and a fallback solution with
slower en/decryption performance in concurrency situations.

Signed-off-by: Harald Freudenberger 
Signed-off-by: Herbert Xu 
Signed-off-by: Ben Hutchings 
---
 arch/s390/crypto/aes_s390.c | 65 -
 1 file changed, 46 insertions(+), 19 deletions(-)

--- a/arch/s390/crypto/aes_s390.c
+++ b/arch/s390/crypto/aes_s390.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "crypt_s390.h"
 
 #define AES_KEYLEN_128 1
@@ -32,6 +33,7 @@
 #define AES_KEYLEN_256 4
 
 static u8 *ctrblk;
+static DEFINE_SPINLOCK(ctrblk_lock);
 static char keylen_flag;
 
 struct s390_aes_ctx {
@@ -760,43 +762,67 @@ static int ctr_aes_set_key(struct crypto
return aes_set_key(tfm, in_key, key_len);
 }
 
+static unsigned int __ctrblk_init(u8 *ctrptr, unsigned int nbytes)
+{
+   unsigned int i, n;
+
+   /* only use complete blocks, max. PAGE_SIZE */
+   n = (nbytes > PAGE_SIZE) ? PAGE_SIZE : nbytes & ~(AES_BLOCK_SIZE - 1);
+   for (i = AES_BLOCK_SIZE; i < n; i += AES_BLOCK_SIZE) {
+   memcpy(ctrptr + i, ctrptr + i - AES_BLOCK_SIZE,
+  AES_BLOCK_SIZE);
+   crypto_inc(ctrptr + i, AES_BLOCK_SIZE);
+   }
+   return n;
+}
+
 static int ctr_aes_crypt(struct blkcipher_desc *desc, long func,
 struct s390_aes_ctx *sctx, struct blkcipher_walk *walk)
 {
int ret = blkcipher_walk_virt_block(desc, walk, AES_BLOCK_SIZE);
-   unsigned int i, n, nbytes;
-   u8 buf[AES_BLOCK_SIZE];
-   u8 *out, *in;
+   unsigned int n, nbytes;
+   u8 buf[AES_BLOCK_SIZE], ctrbuf[AES_BLOCK_SIZE];
+   u8 *out, *in, *ctrptr = ctrbuf;
 
if (!walk->nbytes)
return ret;
 
-   memcpy(ctrblk, walk->iv, AES_BLOCK_SIZE);
+   if (spin_trylock(&ctrblk_lock))
+   ctrptr = ctrblk;
+
+   memcpy(ctrptr, walk->iv, AES_BLOCK_SIZE);
while ((nbytes = walk->nbytes) >= AES_BLOCK_SIZE) {
out = walk->dst.virt.addr;
in = walk->src.virt.addr;
while (nbytes >= AES_BLOCK_SIZE) {
-   /* only use complete blocks, max. PAGE_SIZE */
-   n = (nbytes > PAGE_SIZE) ? PAGE_SIZE :
-nbytes & ~(AES_BLOCK_SIZE - 1);
-   for (i = AES_BLOCK_SIZE; i < n; i += AES_BLOCK_SIZE) {
-   memcpy(ctrblk + i, ctrblk + i - AES_BLOCK_SIZE,
-  AES_BLOCK_SIZE);
-   crypto_inc(ctrblk + i, AES_BLOCK_SIZE);
-   }
-   ret = crypt_s390_kmctr(func, sctx->key, out, in, n, 
ctrblk);
-   if (ret < 0 || ret != n)
+   if (ctrptr == ctrblk)
+   n = __ctrblk_init(ctrptr, nbytes);
+   else
+   n = AES_BLOCK_SIZE;
+   ret = crypt_s390_kmctr(func, sctx->key, out, in,
+  n, ctrptr);
+   if (ret < 0 || ret != n) {
+   if (ctrptr == ctrblk)
+   spin_unlock(&ctrblk_lock);
return -EIO;
+   }
if (n > AES_BLOCK_SIZE)
-   memcpy(ctrblk, ctrblk + n - AES_BLOCK_SIZE,
+   memcpy(ctrptr, ctrptr + n - AES_BLOCK_SIZE,
   AES_BLOCK_SIZE);
-   crypto_inc(ctrblk, AES_BLOCK_SIZE);
+   crypto_inc(ctrptr, AES_BLOCK_SIZE);
out += n;
in += n;
nbytes -= n;
}
ret = blkcipher_walk_done(desc, walk, nbytes);
}
+   if (ctrptr == ctrblk) {
+   if (nbytes)
+   memcpy(ctrbuf, ctrptr, AES_BLOCK_SIZE);
+   else
+   memcpy(walk->iv, ctrptr, AES_BLOCK_SIZE);
+   spin_unlock(&ctrblk_lock);
+   }
/*
 * final block may be < AES_BLOCK_SIZE, copy only nbytes
 */
@@ -804,14 +830,15 @@ static int ctr_aes_crypt(struct blkciphe
out = walk->dst.virt.addr;
in = walk->src.virt.addr;
ret = crypt_s390_kmctr(func, sctx->key, buf, in,
-  AES_BLOCK_SIZE, ctrblk);
+ 

[PATCH 3.2 067/200] crypto: s390 - fix des and des3_ede ctr concurrency issue

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Harald Freudenberger 

commit ee97dc7db4cbda33e4241c2d85b42d1835bc8a35 upstream.

In s390 des and 3des ctr mode there is one preallocated page
used to speed up the en/decryption. This page is not protected
against concurrent usage and thus there is a potential of data
corruption with multiple threads.

The fix introduces locking/unlocking the ctr page and a slower
fallback solution at concurrency situations.

Signed-off-by: Harald Freudenberger 
Signed-off-by: Herbert Xu 
Signed-off-by: Ben Hutchings 
---
 arch/s390/crypto/des_s390.c | 69 +++--
 1 file changed, 48 insertions(+), 21 deletions(-)

--- a/arch/s390/crypto/des_s390.c
+++ b/arch/s390/crypto/des_s390.c
@@ -25,6 +25,7 @@
 #define DES3_KEY_SIZE  (3 * DES_KEY_SIZE)
 
 static u8 *ctrblk;
+static DEFINE_SPINLOCK(ctrblk_lock);
 
 struct s390_des_ctx {
u8 iv[DES_BLOCK_SIZE];
@@ -376,54 +377,80 @@ static struct crypto_alg cbc_des3_alg =
}
 };
 
+static unsigned int __ctrblk_init(u8 *ctrptr, unsigned int nbytes)
+{
+   unsigned int i, n;
+
+   /* align to block size, max. PAGE_SIZE */
+   n = (nbytes > PAGE_SIZE) ? PAGE_SIZE : nbytes & ~(DES_BLOCK_SIZE - 1);
+   for (i = DES_BLOCK_SIZE; i < n; i += DES_BLOCK_SIZE) {
+   memcpy(ctrptr + i, ctrptr + i - DES_BLOCK_SIZE, DES_BLOCK_SIZE);
+   crypto_inc(ctrptr + i, DES_BLOCK_SIZE);
+   }
+   return n;
+}
+
 static int ctr_desall_crypt(struct blkcipher_desc *desc, long func,
-   struct s390_des_ctx *ctx, struct blkcipher_walk 
*walk)
+   struct s390_des_ctx *ctx,
+   struct blkcipher_walk *walk)
 {
int ret = blkcipher_walk_virt_block(desc, walk, DES_BLOCK_SIZE);
-   unsigned int i, n, nbytes;
-   u8 buf[DES_BLOCK_SIZE];
-   u8 *out, *in;
+   unsigned int n, nbytes;
+   u8 buf[DES_BLOCK_SIZE], ctrbuf[DES_BLOCK_SIZE];
+   u8 *out, *in, *ctrptr = ctrbuf;
+
+   if (!walk->nbytes)
+   return ret;
 
-   memcpy(ctrblk, walk->iv, DES_BLOCK_SIZE);
+   if (spin_trylock(&ctrblk_lock))
+   ctrptr = ctrblk;
+
+   memcpy(ctrptr, walk->iv, DES_BLOCK_SIZE);
while ((nbytes = walk->nbytes) >= DES_BLOCK_SIZE) {
out = walk->dst.virt.addr;
in = walk->src.virt.addr;
while (nbytes >= DES_BLOCK_SIZE) {
-   /* align to block size, max. PAGE_SIZE */
-   n = (nbytes > PAGE_SIZE) ? PAGE_SIZE :
-   nbytes & ~(DES_BLOCK_SIZE - 1);
-   for (i = DES_BLOCK_SIZE; i < n; i += DES_BLOCK_SIZE) {
-   memcpy(ctrblk + i, ctrblk + i - DES_BLOCK_SIZE,
-  DES_BLOCK_SIZE);
-   crypto_inc(ctrblk + i, DES_BLOCK_SIZE);
-   }
-   ret = crypt_s390_kmctr(func, ctx->key, out, in, n, 
ctrblk);
-   if (ret < 0 || ret != n)
+   if (ctrptr == ctrblk)
+   n = __ctrblk_init(ctrptr, nbytes);
+   else
+   n = DES_BLOCK_SIZE;
+   ret = crypt_s390_kmctr(func, ctx->key, out, in,
+  n, ctrptr);
+   if (ret < 0 || ret != n) {
+   if (ctrptr == ctrblk)
+   spin_unlock(&ctrblk_lock);
return -EIO;
+   }
if (n > DES_BLOCK_SIZE)
-   memcpy(ctrblk, ctrblk + n - DES_BLOCK_SIZE,
+   memcpy(ctrptr, ctrptr + n - DES_BLOCK_SIZE,
   DES_BLOCK_SIZE);
-   crypto_inc(ctrblk, DES_BLOCK_SIZE);
+   crypto_inc(ctrptr, DES_BLOCK_SIZE);
out += n;
in += n;
nbytes -= n;
}
ret = blkcipher_walk_done(desc, walk, nbytes);
}
-
+   if (ctrptr == ctrblk) {
+   if (nbytes)
+   memcpy(ctrbuf, ctrptr, DES_BLOCK_SIZE);
+   else
+   memcpy(walk->iv, ctrptr, DES_BLOCK_SIZE);
+   spin_unlock(&ctrblk_lock);
+   }
/* final block may be < DES_BLOCK_SIZE, copy only nbytes */
if (nbytes) {
out = walk->dst.virt.addr;
in = walk->src.virt.addr;
ret = crypt_s390_kmctr(func, ctx->key, buf, in,
-  DES_BLOCK_SIZE, ctrblk);
+  DES_BLOCK_SIZE, ctrbuf);
if (ret < 0 || ret != DES_BLOCK_SIZE)
   

[PATCH 3.2 072/200] sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c upstream.

It's a bit odd to see a newer device showing mod15write; however, the
reported behavior is highly consistent and other factors which could
contribute seem to have been verified well enough.  Also, both
sata_sil itself and the drive are fairly outdated at this point making
the risk of this change fairly low.  It is possible, probably likely,
that other drive models in the same family have the same problem;
however, for now, let's just add the specific model which was tested.

Signed-off-by: Tejun Heo 
Reported-by: matson 
References: 
http://lkml.kernel.org/g/201401211912.s0ljck7f015...@rs103.luxsci.com
Signed-off-by: Ben Hutchings 
---
 drivers/ata/sata_sil.c | 1 +
 1 file changed, 1 insertion(+)

--- a/drivers/ata/sata_sil.c
+++ b/drivers/ata/sata_sil.c
@@ -157,6 +157,7 @@ static const struct sil_drivelist {
{ "ST380011ASL",SIL_QUIRK_MOD15WRITE },
{ "ST3120022ASL",   SIL_QUIRK_MOD15WRITE },
{ "ST3160021ASL",   SIL_QUIRK_MOD15WRITE },
+   { "TOSHIBA MK2561GSYN", SIL_QUIRK_MOD15WRITE },
{ "Maxtor 4D060H3", SIL_QUIRK_UDMA5MAX },
{ }
 };

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 080/200] usb-storage: enable multi-LUN scanning when needed

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Alan Stern 

commit 823d12c95c666fa7ab7dad208d735f6bc6afabdc upstream.

People sometimes create their own custom-configured kernels and forget
to enable CONFIG_SCSI_MULTI_LUN.  This causes problems when they plug
in a USB storage device (such as a card reader) with more than one
LUN.

Fortunately, we can tell fairly easily when a storage device claims to
have more than one LUN.  When that happens, this patch asks the SCSI
layer to probe all the LUNs automatically, regardless of the config
setting.

The patch also updates the Kconfig help text for usb-storage,
explaining that CONFIG_SCSI_MULTI_LUN may be necessary.

Signed-off-by: Alan Stern 
Reported-by: Thomas Raschbacher 
CC: Matthew Dharm 
CC: James Bottomley 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2:
 - Adjust context
 - slave_alloc() already has a us_data pointer]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/usb/storage/Kconfig
+++ b/drivers/usb/storage/Kconfig
@@ -19,7 +19,9 @@ config USB_STORAGE
 
  This option depends on 'SCSI' support being enabled, but you
  probably also need 'SCSI device support: SCSI disk support'
- (BLK_DEV_SD) for most USB storage devices.
+ (BLK_DEV_SD) for most USB storage devices.  Some devices also
+ will require 'Probe all LUNs on each SCSI device'
+ (SCSI_MULTI_LUN).
 
  To compile this driver as a module, choose M here: the
  module will be called usb-storage.
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -116,6 +116,10 @@ static int slave_alloc (struct scsi_devi
if (us->subclass == USB_SC_UFI)
sdev->sdev_target->pdt_1f_for_no_lun = 1;
 
+   /* Tell the SCSI layer if we know there is more than one LUN */
+   if (us->protocol == USB_PR_BULK && us->max_lun > 0)
+   sdev->sdev_bflags |= BLIST_FORCELUN;
+
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.2 097/200] Modpost: fixed USB alias generation for ranges including 0x9 and 0xA

2014-03-30 Thread Ben Hutchings
3.2.56-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jan Moskyto Matejka 

commit 03b56329f9bb5a1cb73d7dc659d529a9a9bf3acc upstream.

Commit afe2dab4f6 ("USB: add hex/bcd detection to usb modalias generation")
changed the routine that generates alias ranges. Before that change, only
digits 0-9 were supported; the commit tried to fix the case when the range
includes higher values than 0x9.

Unfortunately, the commit didn't fix the case when the range includes both
0x9 and 0xA, meaning that the final range must look like [x-9A-y] where
x <= 0x9 and y >= 0xA -- instead the [x-9A-x] range was produced.

Modprobe doesn't complain as it sees no difference between no-match and
bad-pattern results of fnmatch().

Fixing this simple bug to fix the aliases.
Also changing the hardcoded beginning of the range to uppercase as all the
other letters are also uppercase in the device version numbers.

Fortunately, this affects only the dvb-usb-dib0700 module, AFAIK.

Signed-off-by: Jan Moskyto Matejka 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 scripts/mod/file2alias.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -130,8 +130,8 @@ static void do_usb_entry(struct usb_devi
range_lo < 0x9 ? "[%X-9" : "[%X",
range_lo);
sprintf(alias + strlen(alias),
-   range_hi > 0xA ? "a-%X]" : "%X]",
-   range_lo);
+   range_hi > 0xA ? "A-%X]" : "%X]",
+   range_hi);
}
}
if (bcdDevice_initial_digits < (sizeof(id->bcdDevice_lo) * 2 - 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/


  1   2   3   4   >