date:20150216

It is absolutely not clear why attach_to_pi_owner() returns -EAGAIN which
triggers retry if the lock owner is PF_EXITING but not PF_EXITPIDONE.
This burns CPU for no reason and this can even livelock if the rt_task()
caller preempts a PF_EXITING owner.

Remove the PF_EXITING check altogether. We do not care if it is exiting,
all we need to know is can we rely on exit_pi_state_list() or not. So we
also need to set PF_EXITPIDONE before we flush -pi_state_list and call
exit_pi_state_list() unconditionally.

Perhaps we can add the fast-path list_empty() check in mm_release() back,
but lets fix the problem first. Besides, in theory this check is already
not correct, at least it should be list_empty_careful() to avoid the race
with free_pi_state() in progress.

Signed-off-by: Oleg Nesterov o...@redhat.com
---
 kernel/exit.c  |   22 +-
 kernel/fork.c  |3 +--
 kernel/futex.c |   40 ++--
 3 files changed, 12 insertions(+), 53 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 6806c55..bc969ed 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -683,27 +683,13 @@ void do_exit(long code)
 */
if (unlikely(tsk-flags  PF_EXITING)) {
pr_alert(Fixing recursive fault but reboot is needed!\n);
-   /*
-* We can do this unlocked here. The futex code uses
-* this flag just to verify whether the pi state
-* cleanup has been done or not. In the worst case it
-* loops once more. We pretend that the cleanup was
-* done as there is no way to return. Either the
-* OWNER_DIED bit is set by now or we push the blocked
-* task into the wait for ever nirwana as well.
-*/
+   /* Avoid the new additions to -pi_state_list at least */
tsk-flags |= PF_EXITPIDONE;
set_current_state(TASK_UNINTERRUPTIBLE);
schedule();
}
 
exit_signals(tsk);  /* sets PF_EXITING */
-   /*
-* tsk-flags are checked in the futex code to protect against
-* an exiting task cleaning up the robust pi futexes.
-*/
-   smp_mb();
-   raw_spin_unlock_wait(tsk-pi_lock);
 
if (unlikely(in_atomic()))
pr_info(note: %s[%d] exited with preempt_count %d\n,
@@ -779,12 +765,6 @@ void do_exit(long code)
 * Make sure we are holding no locks:
 */
debug_check_no_locks_held();
-   /*
-* We can do this unlocked here. The futex code uses this flag
-* just to verify whether the pi state cleanup has been done
-* or not. In the worst case it loops once more.
-*/
-   tsk-flags |= PF_EXITPIDONE;
 
if (tsk-io_context)
exit_io_context(tsk);
diff --git a/kernel/fork.c b/kernel/fork.c
index 4dc2dda..ec3208e 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -803,8 +803,7 @@ void mm_release(struct task_struct *tsk, struct mm_struct 
*mm)
tsk-compat_robust_list = NULL;
}
 #endif
-   if (unlikely(!list_empty(tsk-pi_state_list)))
-   exit_pi_state_list(tsk);
+   exit_pi_state_list(tsk);
 #endif
 
uprobe_free_utask(tsk);
diff --git a/kernel/futex.c b/kernel/futex.c
index b101381..c1104a8 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -716,11 +716,13 @@ void exit_pi_state_list(struct task_struct *curr)
 
if (!futex_cmpxchg_enabled)
return;
+
/*
-* We are a ZOMBIE and nobody can enqueue itself on
-* pi_state_list anymore, but we have to be careful
-* versus waiters unqueueing themselves:
+* attach_to_pi_owner() can no longer add the new entry. But
+* we have to be careful versus waiters unqueueing themselves.
 */
+   curr-flags |= PF_EXITPIDONE;
+
raw_spin_lock_irq(curr-pi_lock);
while (!list_empty(head)) {
 
@@ -905,24 +907,12 @@ static int attach_to_pi_owner(u32 uval, union futex_key 
*key,
return -EPERM;
}
 
-   /*
-* We need to look at the task state flags to figure out,
-* whether the task is exiting. To protect against the do_exit
-* change of the task flags, we do this protected by
-* p-pi_lock:
-*/
raw_spin_lock_irq(p-pi_lock);
-   if (unlikely(p-flags  PF_EXITING)) {
-   /*
-* The task is on the way out. When PF_EXITPIDONE is
-* set, we know that the task has finished the
-* cleanup:
-*/
-   int ret = (p-flags  PF_EXITPIDONE) ? -ESRCH : -EAGAIN;
-
+   if (unlikely(p-flags  PF_EXITPIDONE)) {
+   /* exit_pi_state_list() was already called */
raw_spin_unlock_irq(p-pi_lock);
put_task_struct(p);
-   return ret;
+   return -ESRCH;
}
 
/*
@@

Re: [PATCH RFC 01/12] Documentation: Introduce Linux Kernel Thermal Framework DocBook

2015-02-16 Thread Eduardo Valentin

On Tue, Feb 10, 2015 at 02:50:36PM -0800, Randy Dunlap wrote:
 On 02/09/15 13:34, Eduardo Valentin wrote:
 
  +   chapter id=introduction
  +   titleIntroduction/title
  +   paraThermal management is any method or technique implied to
  +   mitigate emergencies caused by operating devices within
  +   unsupported temperatures. The challenge consists of designing a
 
 I would flip the ending of that sentence:
caused by operating devices outside of
   supported temperatures.
 
  +   product keeping the junction temperature of the IC components.
  +   The operating temperature of IC components used on products must
  +   operate within their design limits. Besides, temperature towards
  +   device enclosure must be in a comfort level for the user.
  +   Therefore, thermal management, by the time of this writing,
  +   starts in very early device design phase. Managing thermal may
  +   involve different disciplines, at different stages, such as
  +   temperature monitoring, floorplanning, microarchitectural
  +   techniques, compiler techniques, OS techniques, liquid cooling,
  +   and thermal reliability or security. This document covers what
  +   the Linux Kernel Thermal Framework provides as abstraction to
  +   users with respect to thermal management.  
  +   /para
  +   paraOne of the first proposals to provide a solution to cover
  +   the thermal problem appears in the Advanced Configuration and
  +   Power Interface (ACPI) specification. ACPI provides an open
  +   standard for device configuration and power management by the
  +   operating system. However, several computing devices which may
  +   have thermal issues in the market disregard the ACPI standard.
  +   Therefore, the Linux Kernel Thermal Framework has been designed
  +   to serve as abstraction for ACPI and non-ACPI systems. The core
  +   concepts applies in both types of systems. 
  +   /para
  +   paraThe Linux Kernel Thermal Framework has a design which
  +   represents the different thermal constraints found in an
 
 drop:   an^^
 
  +   end-products. The thermal constraints exist to serve different
  +   purposes. There two major types of thermal constraints. The
 
 There are two
 
  +   first is related to components junction temperature. The second
  +   is related to the level of comfort while end users are handling
  +   devices.
  +   /para
  +
  +  /chapter
  +/book
  
 
 
 -- 
 ~Randy

Thanks Randy for checking this up. I apologize for forgetting Ccing you
in my original post. I will fix the text as per your suggestions and
also copy you in next version.

Thanks for you time.

Eduardo Valentin



signature.asc
Description: Digital signature

[PATCH 0/1] futex: don't spin waiting for PF_EXITING - PF_EXITPIDONE transition

On 02/02, Oleg Nesterov wrote:

 And another question. Lets forget about this -mm check. I simply can not
 understand this

   ret = (p-flags  PF_EXITPIDONE) ? -ESRCH : -EAGAIN

 logic in attach_to_pi_owner(). First of all, why do we need to retry if
 PF_EXITING is set but PF_EXITPIDONE is not? Why we can not simply ignore
 PF_EXITING and rely on exit_pi_state_list() if PF_EXITPIDONE is not set?

 I must have missed something but this looks buggy, I do not see any
 preemption point
  ^^

I meant synchronization point, sorry for confusion.

 in this retry loop. Suppose that max_cpus=1 and rt_task()
 preempts the non-rt PF_EXITING owner. Looks like futex_lock_pi() can spin
 forever in this case? (OK, ignoring RT throttling).

Finally I forced myself to try to make the 1st patch ;) To remind, we have
more problems with robust+pi futexes, this needs another patch(es). Otherwise
we could (probably) even kill PF_EXITPIDONE.

Peter. I have no idea how to test it (except it obviously fixes the test-
case I sent before). IOW: please review.

And I still fail to understand why this PF_EXITING logic was added in the
first place. So I also have the problem with the changelog, it merely says
don't do this because this is not needed.



On top of check PF_KTHREAD rather than !p-mm to filter out kthreads but
doesn't depend on it.

Oleg.

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

Re: [PATCH 2/8] x86, fpu: unlazy_fpu: don't do __thread_fpu_end() if use_eager_fpu()

2015-02-16 Thread Borislav Petkov

On Fri, Feb 06, 2015 at 03:01:59PM -0500, r...@redhat.com wrote:
 From: Oleg Nesterov o...@redhat.com
 
 unlazy_fpu()-__thread_fpu_end() doesn't look right if use_eager_fpu().
 Unconditional __thread_fpu_end() is only correct if we know that this
 thread can't return to user-mode and use FPU.
 
 Fortunately it has only 2 callers. fpu_copy() checks use_eager_fpu(),
 and init_fpu(current) can be only called by the coredumping thread via
 regset-get(). But it is exported to modules, and imo this should be
 fixed anyway.
 
 And if we check use_eager_fpu() we can use __save_fpu() like fpu_copy()
 and save_init_fpu() do.
 
 - It seems that even !use_eager_fpu() case doesn't need the unconditional
   __thread_fpu_end(), we only need it if __save_init_fpu() returns 0.

I can follow so far.

 - It is still not clear to me if __save_init_fpu() can safely nest with
   another save + restore from __kernel_fpu_begin(). If not, we can use
   kernel_fpu_disable() to fix the race.

Well, my primitive understanding would say no, not safely, for the
simple reason that we have only one XSAVE state area per thread.
However, __kernel_fpu_begin() is called with preemption disabled so ...
I guess I'm still not seeing the race.

Btw, what is kernel_fpu_disable()? Can't find it here.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sched: Fix preempt_schedule_common() triggering tracing recursion

2015-02-16 Thread Frederic Weisbecker

Since the function graph tracer needs to disable preemption, it might
call preempt_schedule() after reenabling  it if something triggered the
need for rescheduling in between.

Therefore we can't trace preempt_schedule() itself because we would
face a function tracing recursion otherwise as the tracer is always
called before PREEMPT_ACTIVE gets set to prevent that recursion. This is
why preempt_schedule() is tagged as notrace.

But the same issue applies to every function called by preempt_schedule()
before PREEMPT_ACTIVE is actually set. And preempt_schedule_common() is
one such example. Unfortunately we forgot to tag it as notrace as well
and as a result we are encountering tracing recursion since it got
introduced by a18b5d01819235629289212ad428a5ee2b40f0d9
(sched: Fix missing preemption opportunity).

Let's fix that by applying the appropriate function tag to
preempt_schedule_common().

Reported-by: Huang Ying ying.hu...@intel.com
Acked-by: Steven Rostedt rost...@goodmis.org
Cc: Huang Ying ying.hu...@intel.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Steven Rostedt rost...@goodmis.org
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
 kernel/sched/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 13049aa..683e850 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2899,7 +2899,7 @@ void __sched schedule_preempt_disabled(void)
preempt_disable();
 }
 
-static void preempt_schedule_common(void)
+static void __sched notrace preempt_schedule_common(void)
 {
do {
__preempt_count_add(PREEMPT_ACTIVE);
-- 
2.1.4

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

[PATCH 0/2] bmc150-accel driver optimizations

Adds optimization of i2c transactions in trigger handler and
usage of available_scan_masks for bmc150-accel.

Irina Tirdea (2):
  iio: accel: bmc150: use available_scan_masks
  iio: accel: bmc150: optimize i2c transfers in trigger handler

 drivers/iio/accel/bmc150-accel.c | 49 +++-
 1 file changed, 38 insertions(+), 11 deletions(-)

-- 
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 1/1] pty: BREAK for pseudoterminals

2015-02-16 Thread Peter Hurley

On 02/16/2015 12:16 PM, Petr Tesarik wrote:
 On Mon, 16 Feb 2015 11:24:16 -0500
 Peter Hurley pe...@hurleysoftware.com wrote:
 
 Hi Petr,

 On 02/16/2015 08:22 AM, Petr Tesarik wrote:
 On Mon, 16 Feb 2015 08:04:02 -0500
 Peter Hurley pe...@hurleysoftware.com wrote:

 On 02/05/2015 02:11 PM, Nan Li wrote:
 This will greatly enhance the usefulness of QEMU virtual serial ports, 
 because the Linux kernel interprets a break on the serial console as a 
 SysRq, but there is currently no way to pass this signal over a 
 pseudo-terminal. This patch will work for transmitting BREAK from master 
 to slave through pseudo-terminal.

 pty is an IPC mechanism, not a virtualization driver.

 No, but it can be used as a TTY. Teletypes have always had the capacity
 to send and receive BREAK.

 In some general-purpose but restricted capacity, the *slave* end _mimics_
 a tty. That doesn't mean that it is suitable for every conceivable
 use as a tty, nor should it.
 
 Unless there's some specification of what should and what should not be
 implemented, this question is open for discussion, methinks.

This question is open for discussion regardless of specifications.
I thought that's what these emails were. :)

FWIW, here's the relevant excerpt from SUSv4 regarding tcsendbreak():

If the terminal is not using asynchronous serial data transmission,
it is implementation-defined whether tcsendbreak() sends data to
generate a break condition or returns without taking any action.


 If BREAK was actually useful for real terminal i/o, the pty driver
 would already support this.
 
 If I strictly followed this statement, no improvement would ever be
 possible. Or did I miss something? Are Linux PTYs a legacy subsystem
 that never gets any new features?

I'm not opposed to new features, but I do think that new kernel features
should only address those requirements which cannot be met in userspace
(whether that's functionality or performance or whatever the requirements).


 [...]
 Well, the default termios includes IGNBRK, so unless they bothered
 to do anything about BREAKs, they won't see any change.

 Userspace programs are sloppy, especially with terminal i/o and
 settings. Unlikely is not the same as not possible.
 
 Sure. New features may break sloppy programs. OTOH, the obvious
 workaround is not using such programs together with new programs that
 actually use tcsendbreak() for something... until those sloppy programs
 are fixed. It's not like the whole system stops working once this patch
 is applied.

Userspace breakage is not an acceptable outcome, even if the program is
provably buggy (other than for security-related issues).


 Anyway, the current kernel behaviour is clearly suboptimal. Calling
 tcsendbreak() on a pty descriptor does nothing but reports success.
 There are obviously two ways to fix it: either report an error, or
 deliver the BREAK for real.

 The pty master end is even less of a tty than the slave end, but this
 isn't really about errno. This patch doesn't address either of your
 points wrt tcsendbreak() on the slave descriptor which is the actual
 terminal end.
 
 That's a valid point. And, indeed, the terminal end actually needs the
 handling of BREAK to make it useful.

There's two problems with adding this to the slave end:

1. The master pty termios is not programmable, so it can't set IGNBRK.
2. It creates a security maintenance burden because the unprivileged slave
   pty end must not be allowed to terminate the privileged master end,
   such as accidentally via BRKINT.


 This patch implements the latter, adding at least one valid use case
 to explain why it is better than the former.

 I disagree that this is a valid use case for the _pty driver_.

 AFAICT this is simply for convenience, as sysrq functionality is
 already available via sendkey.
 
 That's a completely different story. This patch (after fixing it to
 work with the terminal end) would allow me to set up a QEMU emulated
 serial port using a pty (i.e. -chardev pty) and send a BREAK signal
 to it, no matter what is running in the guest.


 I mean, I can run an emulated MIPS64 as a QEMU guest on an x86_64 host,
 and still somehow pass SysRq to it. IIUC this will never be possible
 with KVP.



 Another use case: In my job, I'm struggling with different serial
 consoles (some using ipmi SoL, some using telnet to a service
 processor, some connected with a real RS-232 link). If I could send
 BREAK over a pty, I could extend ipmiconsole to translate it to the SOL
 message, telnet to translate it to the telnet escape, amtterm to send a
 corresponding message... Then I could send a BREAK to any of my systems
 simply by pressing 'C-A b' in screen(1) without having to think how is
 this particular machine connected and what the correct sequence is for
 that protocol.
 
 Just my two cents,
 Petr Tesarik
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More

Re: [PATCH 1/4] mm: cma: add currently allocated CMA buffers list to debugfs

2015-02-16 Thread Stefan Strogin

Hello,

On 13/02/15 06:10, Joonsoo Kim wrote:
 On Fri, Feb 13, 2015 at 01:15:41AM +0300, Stefan Strogin wrote:
 
 This linear searching make cma_release() slow if we have many allocated
 cma buffers. It wouldn't cause any problem?
 
 Thanks.
 
 

On my board the usual number of CMA buffers is about 20, and releasing a
buffer isn't a very frequent operation.
But if there could be systems with much more CMA buffers and/or frequent
allocating/releasing them, maybe it would be useful to convert buffers
list to rb_trees?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] lib/vsprintf.c:Avoid extra operation in dentry_name

2015-02-16 Thread Richard Weinberger

On Mon, Feb 16, 2015 at 7:49 PM, Anshul Garg aksgarg1...@gmail.com wrote:
 From: Anshul Garg aksgarg1...@gmail.com

 Remove unnecessary increment and decrement operation
 in dentry_name function as after increment operation
 loop is breaked and then decrement operation is
 performed. So remove increment and decrement operation
 from the function.

 Signed-off-by: Anshul Garg aksgarg1...@gmail.com
 ---
  lib/vsprintf.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/lib/vsprintf.c b/lib/vsprintf.c
 index ec337f6..2a38105 100644
 --- a/lib/vsprintf.c
 +++ b/lib/vsprintf.c
 @@ -576,11 +576,10 @@ char *dentry_name(char *buf, char *end, const struct 
 dentry *d, struct printf_sp
 if (p == d) {
 if (i)
 array[i] = ;
 -   i++;
 break;
 }
 }
 -   s = array[--i];
 +   s = array[i];
 for (n = 0; n != spec.precision; n++, buf++) {
 char c = *s++;
 if (!c) {

What if the if (d == d) branch is not taken?
Does the code then really behave exactly as before?

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

Re: [PATCH 0/2] kxcjk-1013 driver optimizations


 Adds optimization of i2c transactions in trigger handler and
 usage of available_scan_masks for kxcjk-1013.

the 'optimization' changes the capabilities of the driver, reading 
individual channel is not possible anymore

 Adriana Reus (2):
   iio: accel: kxcjk-1013: use available_scan_masks
   iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler
 
  drivers/iio/accel/kxcjk-1013.c | 50 
 --
  1 file changed, 39 insertions(+), 11 deletions(-)
 
 

-- 

Peter Meerwald
+43-664-218 (mobile)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/3] staging: lustre: Remove use of return val of seq_printf

2015-02-16 Thread Joe Perches

seq_printf should eventually be converted to a void function.

Remove the uses of seq_printf return values and use seq_has_overflowed()
instead.

Joe Perches (3):
  staging: lustre: Convert return seq_printf(...) uses to seq_has_overflowed
  staging: lustre: Convert uses of int rc = seq_printf(...)
  staging: lustre: Convert remaining uses of = seq_printf(...)

 drivers/staging/lustre/lustre/fid/lproc_fid.c  |  23 ++--
 drivers/staging/lustre/lustre/libcfs/hash.c|  11 +-
 drivers/staging/lustre/lustre/llite/lproc_llite.c  | 127 -
 drivers/staging/lustre/lustre/lmv/lproc_lmv.c  |  18 ++-
 drivers/staging/lustre/lustre/lov/lproc_lov.c  |  30 +++--
 drivers/staging/lustre/lustre/mdc/lproc_mdc.c  |   6 +-
 .../lustre/lustre/obdclass/linux/linux-module.c|  40 ---
 .../lustre/lustre/obdclass/lprocfs_status.c| 120 ++-
 drivers/staging/lustre/lustre/obdclass/lu_object.c |  25 ++--
 drivers/staging/lustre/lustre/osc/lproc_osc.c  |  67 +--
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c|  25 ++--
 drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c|  82 +++--
 12 files changed, 313 insertions(+), 261 deletions(-)

-- 
2.1.2

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

Re: make mandocs build failure with next-20150210

2015-02-16 Thread Jonathan Corbet

On Mon, 16 Feb 2015 16:21:30 +
Alan Cox a...@linux.intel.com wrote:

  This warning started to appear on Linus's tree, after staging pull
  request was merged.  
 
 I sent GregKH a fix for it a while ago

He seemed to indicate that he doesn't have it.  The following would seem
to fit the bill; unless somebody objects I'll send it upward so that docs
builds start working again.

Thanks,

jon

From a984e29fbe72371b203c43a33b66df44b4c8a948 Mon Sep 17 00:00:00 2001
From: Jonathan Corbet cor...@lwn.net
Date: Mon, 16 Feb 2015 12:21:42 -0700
Subject: [PATCH] Fix docs build failure caused by i2o removal

The movement of the I2O tree into staging broke the DocBook build.  Rather
than redirect the i2o references into staging, it seems better to just
remove them since this code is on its way out anyway.

Signed-off-by: Jonathan Corbet cor...@lwn.net
---
 Documentation/DocBook/device-drivers.tmpl | 17 -
 1 file changed, 17 deletions(-)

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index f2130586ef5d..faf09d4a0ea8 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -190,23 +190,6 @@ X!Edrivers/pnp/system.c
 !Idrivers/message/fusion/mptfc.c
 !Idrivers/message/fusion/mptlan.c
  /sect1
- sect1titleI2O message devices/title
-!Iinclude/linux/i2o.h
-!Idrivers/message/i2o/core.h
-!Edrivers/message/i2o/iop.c
-!Idrivers/message/i2o/iop.c
-!Idrivers/message/i2o/config-osm.c
-!Edrivers/message/i2o/exec-osm.c
-!Idrivers/message/i2o/exec-osm.c
-!Idrivers/message/i2o/bus-osm.c
-!Edrivers/message/i2o/device.c
-!Idrivers/message/i2o/device.c
-!Idrivers/message/i2o/driver.c
-!Idrivers/message/i2o/pci.c
-!Idrivers/message/i2o/i2o_block.c
-!Idrivers/message/i2o/i2o_scsi.c
-!Idrivers/message/i2o/i2o_proc.c
- /sect1
   /chapter
 
   chapter id=snddev
-- 
2.1.0

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

Re: [PATCH 0/4] mm: cma: add some debug information for CMA

2015-02-16 Thread Stefan Strogin

Hello Gioh,

Thank you for your answer.

On 14/02/15 10:40, Gioh Kim wrote:

 If this tracer is justifiable, I think that making it conditional is
 better than just enabling always on CONFIG_CMA_DEBUGFS. Some users
 don't want to this feature although they enable CONFIG_CMA_DEBUGFS.

 Thanks.

 
 Hello,
 
 Thanks for your work. It must be helpful to me.
 
 What about add another option to activate stack-trace?
 In my platform I know all devices using cma area, so I usually don't
 need stack-trace.
 

So Joonsoo suggests to add an option for buffer list, and you suggest to
add another in addition to the first one (and also add CONFIG_STACKTRACE
to dependences) right?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] x86, kaslr: propagate base load address calculation

2015-02-16 Thread Kees Cook

On Mon, Feb 16, 2015 at 3:55 AM, Borislav Petkov b...@alien8.de wrote:
 On Fri, Feb 13, 2015 at 03:25:26PM -0800, Kees Cook wrote:
 No, no; I agree: a malicious boot loader is a lost cause. I mean
 mostly from a misbehavior perspective. Like, someone sees kaslr in
 the setup args and thinks they can set it to 1 and boot a kernel, etc.
 Or they set it to 0, but they lack HIBERNATION and 1 gets appended,
 but the setup_data parser sees the boot-loader one set to 0, etc. I'm
 just curious if we should avoid getting some poor system into a
 confusing state.

 Well, we can apply the rule of the last setting sticks and since the
 kernel is always going to be adding the last setup_data element of
 type SETUP_KASLR (the boot loader ones will be somewhere on the list
 in-between and we add to the end), we're fine, no?

Sounds good to me!

-Kees


 --
 Regards/Gruss,
 Boris.

 ECO tip #101: Trim your mails when you reply.
 --



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

Re: [PATCH] x86, irq: Fix regression caused by commit b568b8601f05

2015-02-16 Thread Pavel Machek

On Mon 2015-02-16 10:11:13, Jiang Liu wrote:
 Commit b568b8601f05 (Treat SCI interrupt as normal GSI interrupt)
 accidently removes support of legacy PIC interrupt when fixing a

accidentaly?

 regression for Xen, which causes a nasty regression on HP/Compaq
 nc6000 where we fail to register the ACPI interrupt, and thus
 lose eg. thermal notifications leading a potentially overheated
 machine.
 
 So reintroduce support of legacy PIC based ACPI SCI interrupt.
 
 Reported-by: Ville Syrjälä syrj...@sci.fi
 Signed-off-by: Jiang Liu jiang@linux.intel.com

Acked-by: Pavel Machek pa...@ucw.cz

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] x86, kaslr: propagate base load address calculation

2015-02-16 Thread Borislav Petkov

On Mon, Feb 16, 2015 at 11:27:42AM -0800, Kees Cook wrote:
  Well, we can apply the rule of the last setting sticks and since the
  kernel is always going to be adding the last setup_data element of
  type SETUP_KASLR (the boot loader ones will be somewhere on the list
  in-between and we add to the end), we're fine, no?
 
 Sounds good to me!

Ok, thanks. I'll pick it up and route it through the proper channels.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER

2015-02-16 Thread Robert Abel


Hi Tony,

On 16 Feb 2015 18:10, Tony Lindgren wrote:

* Robert ABEL ra...@cit-ec.uni-bielefeld.de [150216 07:52]:

GPMC uses GPMCFCLKDIVIDER during synchronous as well as asynchronous accesses
in conjunction with WAITMONITORINGTIME. Thus, it's wrong to only program it for
synchronous accesses. Remove the conditional.

Do you have some test case that gets fixed by this? Or does this
fix some regression?

The reason why I'm asking is that AFAIK we've had async access
working all along?
Maybe to clarify: This is only affects asynchronous accesses with 
WAITREADMONITORING and/or WAITWRITEMONITORING enabled. Regular 
asynchronous accesses without WAIT pin monitoring were never affected to 
begin with and are not affected by this change.


I don't have an off-hand test case and seeing as the current 
implementation is faulty, it's probable nobody actively uses this 
feature. Cf. OMAP35xx TRM (SPRUF98X) pp. 1103. Basically, 
WAITMONITORINGTIME extends the number of cycles from the end of WAIT 
asserted to when the data is provided/sampled and the read/write access 
(should) take place. While this behavior is esoteric, it's not a reason 
not to fix this oversight.


Regards,

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

Re: [PATCH 4/4] perf tools: add JVMTI agent library

2015-02-16 Thread Stephane Eranian

On Mon, Feb 16, 2015 at 2:01 AM, Adrian Hunter adrian.hun...@intel.com wrote:
 On 11/02/15 01:42, Stephane Eranian wrote:
 This is a standalone JVMTI library to help  profile Java jitted
 code with perf record/perf report. The library is not installed
 or compiled automatically by perf Makefile. It is not used
 directly by perf. It is arch agnostic and has been tested on
 X86 and ARM. It needs to be used with a Java runtime, such
 as OpenJDK, as follows:

 $ java -agentpath:libjvmti.so ...

 When used this way, java will generate a jitdump binary file in
 $HOME/.debug/java/jit/java-jit-*

 This binary dump file contains information to help symbolize and
 annotate jitted code.

 The next step is to inject the jitdump information into the
 perf.data file:
 $ perf inject -j $HOME/.debug/java/jit/java-jit-/jit-ZZZ.dump \
   -i perf.data -o perf.data.jitted

 This injects the MMAP records to cover the jitted code and also generates
 one ELF image for each jitted function. The ELF images are created in the
 same subdir as the jitdump file. The MMAP records point there too.

 Then to visualize the function or asm profile, simply use the regular
 perf commands:
 $ perf report -i perf.data.jitted
 or
 $ perf annotate -i perf.data.jitted

 JVMTI agent code adapted from OProfile's opagent code.

 Signed-off-by: Stephane Eranian eran...@google.com
 ---
  tools/perf/jvmti/Makefile  |  70 +
  tools/perf/jvmti/jvmti_agent.c | 349 
 +
  tools/perf/jvmti/jvmti_agent.h |  23 +++
  tools/perf/jvmti/libjvmti.c| 149 ++
  4 files changed, 591 insertions(+)
  create mode 100644 tools/perf/jvmti/Makefile
  create mode 100644 tools/perf/jvmti/jvmti_agent.c
  create mode 100644 tools/perf/jvmti/jvmti_agent.h
  create mode 100644 tools/perf/jvmti/libjvmti.c

 diff --git a/tools/perf/jvmti/Makefile b/tools/perf/jvmti/Makefile
 new file mode 100644
 index 000..9eda64b
 --- /dev/null
 +++ b/tools/perf/jvmti/Makefile
 @@ -0,0 +1,70 @@
 +ARCH=$(shell uname -m)
 +
 +ifeq ($(ARCH), x86_64)
 +JARCH=amd64
 +endif
 +ifeq ($(ARCH), armv7l)
 +JARCH=armhf
 +endif
 +ifeq ($(ARCH), armv6l)
 +JARCH=armhf
 +endif
 +ifeq ($(ARCH), ppc64)
 +JARCH=powerpc
 +endif
 +ifeq ($(ARCH), ppc64le)
 +JARCH=powerpc
 +endif
 +
 +DESTDIR=/usr/local
 +
 +VERSION=1
 +REVISION=0
 +AGE=0
 +
 +LN=ln -sf
 +RM=rm
 +
 +SJVMTI=libjvmti.so.$(VERSION).$(REVISION).$(AGE)
 +VJVMTI=libjvmti.so.$(VERSION)
 +SLDFLAGS=-shared -Wl,-soname -Wl,$(VLIBPFM)
 +SOLIBEXT=so
 +
 +JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | cut -d ' ' 
 -f 3)
 +# -lrt required in 32-bit mode for clock_gettime()
 +LIBS=-lelf -lrt
 +INCDIR=-I $(JDIR)/include -I $(JDIR)/include/linux
 +
 +TARGETS=$(SJVMTI)
 +
 +SRCS=libjvmti.c jvmti_agent.c
 +OBJS=$(SRCS:.c=.o)
 +SOBJS=$(OBJS:.o=.lo)
 +OPT=-O2 -g -Werror -Wall
 +
 +CFLAGS=$(INCDIR) $(OPT)
 +
 +all: $(TARGETS)
 +
 +.c.o:
 + $(CC) $(CFLAGS) -c $*.c
 +.c.lo:
 + $(CC) -fPIC -DPIC $(CFLAGS) -c $*.c -o $*.lo
 +
 +$(OBJS) $(SOBJS): Makefile jvmti_agent.h ../util/jitdump.h
 +
 +$(SJVMTI):  $(SOBJS)
 + $(CC) $(CFLAGS) $(SLDFLAGS)  -o $@ $(SOBJS) $(LIBS)
 + $(LN) $@ libjvmti.$(SOLIBEXT)
 +
 +clean:
 + $(RM) -f *.o *.so.* *.so *.lo
 +
 +install:
 + -mkdir -p $(DESTDIR)/lib
 + install -m 755 $(SJVMTI) $(DESTDIR)/lib/
 + (cd $(DESTDIR)/lib; $(LN) $(SJVMTI) $(VJVMTI))
 + (cd $(DESTDIR)/lib; $(LN) $(SJVMTI) libjvmti.$(SOLIBEXT))
 + ldconfig
 +
 +.SUFFIXES: .c .S .o .lo
 diff --git a/tools/perf/jvmti/jvmti_agent.c b/tools/perf/jvmti/jvmti_agent.c
 new file mode 100644
 index 000..d2d5215
 --- /dev/null
 +++ b/tools/perf/jvmti/jvmti_agent.c
 @@ -0,0 +1,349 @@
 +/*
 + * jvmti_agent.c: JVMTI agent interface
 + *
 + * Adapted from the Oprofile code in opagent.c:
 + * This library is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU Lesser General Public
 + * License as published by the Free Software Foundation; either
 + * version 2.1 of the License, or (at your option) any later version.
 + *
 + * This library 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
 + * Lesser General Public License for more details.
 + *
 + * You should have received a copy of the GNU Lesser General Public
 + * License along with this library; if not, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 + *
 + * Copyright 2007 OProfile authors
 + * Jens Wilke
 + * Daniel Hansel
 + * Copyright IBM Corporation 2007
 + */
 +#include sys/types.h
 +#include sys/stat.h /* for mkdir() */
 +#include stdio.h
 +#include errno.h
 +#include string.h
 +#include stdlib.h
 +#include stdint.h
 +#include limits.h
 +#include fcntl.h
 +#include unistd.h
 +#include time.h
 +#include syscall.h /* for gettid() */
 +#include err.h
 +

RE: chelsio: Use a more common const struct pci_device_id foo[] style

2015-02-16 Thread Casey Leedom

  I can't quite tell if this is a patch request being sent to netdev/David 
Miller or if it's a suggestion sent to Chelsio that you'd like Chelsio to 
adopt.  I ~think~ it's the latter because the subject doesn't include the 
standard formatting for a patch request but I'm not 100% familiar with the 
netdev/kernel.org conventions for this.  My apologies if I'm misinterpreting 
your message.

1.  The use of const certainly seems like a win.

 2. Thanks for catching the redundant use of 
CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN to guard
the actual contents of t4_pci_id_tbl.h.  That's already being handled via 
the check for
__T4_PCI_ID_TBL_H__ — no idea why I put that in there ...

 3. The use of the CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN and
CH_PCI_DEVICE_ID_TABLE_DEFINE_END are used to make the t4_pci_id_tbl.h
accommodate different driver needs.  The header file is only concerned with 
providing
a common enumeration of existing PCI Device Identifiers associated with 
adapters.
The files including the header are only concerned with providing the 
necessary context
for the header file.  The header file ai an OS-independent header file 
which is
shared across six existing OS driver implementations; similar to our 
OS-independent
register definitions file.

 4. The CH_PCI_ID_TABLE_ENTRY() macro is similarly used to strictly partition
the roles of t4_pci_id_tbl.h and the files which include it.  
t4_pci_id_tbl.h is
exactly what it's name implies: solely an enumeration of assigned hardware
adapter PCI Device Identifiers.

 5. Because of the above change in the original abstraction layering, a new 
macro
CH_PCI_ID_TABLE_ENTRY_DATA is introduced in this patch which passes in
a desired value for the dev parameter of the PCI_VDEVICE() macro.  But the
documentation for this new macro in t4_pci_id_tbl.h is incorrectly given the
documentation of the original CH_PCI_ID_TABLE_ENTRY() macro which
was originally supplied by the file including t4_pci_id_tbl.h.  This leaves 
its
usage confusing for anyone reading the header file.

In conclusion:

 A. I like the use of const in the table.

 B. I like removing the redundant content inclusion check of
CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN.

 C. I'm uncomfortable with all the other changes.

Casey


From: Joe Perches [j...@perches.com]
Sent: Friday, February 13, 2015 6:05 PM
To: Hariprasad S; Casey Leedom; James E.J. Bottomley
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-scsi
Subject: chelsio: Use a more common const struct pci_device_id foo[] style

Chelsio code shares a pci_device_table from an #include file.
Make the include guard simpler and make the arrays const.

Reduces data by moving tables to text.

Removed unnecessary macros:
o CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
o CH_PCI_DEVICE_ID_TABLE_DEFINE_END
o CH_PCI_ID_TABLE_ENTRY (moved to the .h file)
Added new macro define:
o CH_PCI_ID_TABLE_ENTRY_DATA

  text data bss dec hex filename
  50550 923 172   51645c9bd 
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o.new
  469354531 172   51638c9b6 
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o.old
  27864 355   8   282276e43 
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o.new
  260722203   8   282836e7b 
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o.old
   9734 450  24   1020827e0 drivers/scsi/csiostor/csio_init.o.new
   79422242  24   1020827e0 drivers/scsi/csiostor/csio_init.o.old

Signed-off-by: Joe Perches j...@perches.com
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 17 --
 drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 38 --
 .../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c| 10 ++
 drivers/scsi/csiostor/csio_init.c  | 11 +++
 4 files changed, 27 insertions(+), 49 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index a22cf93..8a01eeb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -123,23 +123,18 @@ struct filter_entry {

 /* Macros needed to support the PCI Device ID Table ...
  */
-#define CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN \
-   static struct pci_device_id cxgb4_pci_tbl[] = {
-#define CH_PCI_DEVICE_ID_FUNCTION 0x4
+
+#define CH_PCI_DEVICE_ID_FUNCTION  0x4
+#define CH_PCI_ID_TABLE_ENTRY_DATA 4

 /* Include PCI Device IDs for both PF4 and PF0-3 so our PCI probe() routine is
  * called for both.
  */
-#define CH_PCI_DEVICE_ID_FUNCTION2 0x0
-
-#define CH_PCI_ID_TABLE_ENTRY(devid) \
-   {PCI_VDEVICE(CHELSIO, (devid)), 4}
-
-#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END \
-   { 0, } \
-   }
+#define CH_PCI_DEVICE_ID_FUNCTION2 0x0

+static const struct pci_device_id cxgb4_pci_tbl[] = {
 #include

[PATCH 1/2] iio: accel: kxcjk-1013: use available_scan_masks

From: Adriana Reus adriana.r...@intel.com

Use available_scan_masks to allow the iio core to select
the data to send to userspace depending on which axes are
enabled, instead of doing this in the driver's interrupt
handler.

This also fixes the issue of accessing the buffer scan_mask
instead of active_scan_mask, since these might not be the
same due to client devices.

Signed-off-by: Adriana Reus adriana.r...@intel.com
Signed-off-by: Irina Tirdea irina.tir...@intel.com
Reviewed-by: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com
---
 drivers/iio/accel/kxcjk-1013.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
index 567de26..5f27787 100644
--- a/drivers/iio/accel/kxcjk-1013.c
+++ b/drivers/iio/accel/kxcjk-1013.c
@@ -115,6 +115,7 @@ enum kxcjk1013_axis {
AXIS_X,
AXIS_Y,
AXIS_Z,
+   AXIS_MAX,
 };
 
 enum kxcjk1013_mode {
@@ -947,6 +948,8 @@ static const struct iio_info kxcjk1013_info = {
.driver_module  = THIS_MODULE,
 };
 
+static const unsigned long kxcjk1013_scan_masks[] = {0x7, 0};
+
 static irqreturn_t kxcjk1013_trigger_handler(int irq, void *p)
 {
struct iio_poll_func *pf = p;
@@ -955,9 +958,7 @@ static irqreturn_t kxcjk1013_trigger_handler(int irq, void 
*p)
int bit, ret, i = 0;
 
mutex_lock(data-mutex);
-
-   for_each_set_bit(bit, indio_dev-buffer-scan_mask,
-indio_dev-masklength) {
+   for (bit = 0; bit  AXIS_MAX; bit++) {
ret = kxcjk1013_get_acc_reg(data, bit);
if (ret  0) {
mutex_unlock(data-mutex);
@@ -1228,6 +1229,7 @@ static int kxcjk1013_probe(struct i2c_client *client,
indio_dev-dev.parent = client-dev;
indio_dev-channels = kxcjk1013_channels;
indio_dev-num_channels = ARRAY_SIZE(kxcjk1013_channels);
+   indio_dev-available_scan_masks = kxcjk1013_scan_masks;
indio_dev-name = name;
indio_dev-modes = INDIO_DIRECT_MODE;
indio_dev-info = kxcjk1013_info;
-- 
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: chelsio: Use a more common const struct pci_device_id foo[] style

2015-02-16 Thread Joe Perches

On Mon, 2015-02-16 at 18:05 +, Casey Leedom wrote:
   I can't quite tell if this is a patch request being sent to
 netdev/David Miller or if it's a suggestion sent to Chelsio that you'd
 like Chelsio to adopt.  I ~think~ it's the latter because the subject
 doesn't include the standard formatting for a patch request but I'm
 not 100% familiar with the netdev/kernel.org conventions for this.  My
 apologies if I'm misinterpreting your message.

Hi Casey.

Nah, that's not it.

I just forgot/neglected to prefix [PATCH] on the email when I
sent it.

The patch touches drivers/net/ethernet and drivers/scsi which
generally means that it's better for the company maintainers
to apply rather than coordinating between David and James,
the linux networking and scsi maintainers.  Those guys for
most part don't like touching each others code areas.

 1.  The use of const certainly seems like a win.

I think so.

My goal here was to make obvious the use of
const struct pci_device_id which in the original is very
obfuscated/unclear.

  2. Thanks for catching the redundant use of 
 CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN to guard
 the actual contents of t4_pci_id_tbl.h.  That's already being handled via 
 the check for
 __T4_PCI_ID_TBL_H__ — no idea why I put that in there ...

That didn't matter much to me.

  3. The use of the CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN and
 CH_PCI_DEVICE_ID_TABLE_DEFINE_END are used to make the t4_pci_id_tbl.h
 accommodate different driver needs.  The header file is only concerned 
 with providing
 a common enumeration of existing PCI Device Identifiers associated with 
 adapters.
 The files including the header are only concerned with providing the 
 necessary context
 for the header file.  The header file ai an OS-independent header file 
 which is
 shared across six existing OS driver implementations; similar to our 
 OS-independent
 register definitions file.

I think that OS independent bit is not useful here.

  4. The CH_PCI_ID_TABLE_ENTRY() macro is similarly used to strictly partition
 the roles of t4_pci_id_tbl.h and the files which include it.  
 t4_pci_id_tbl.h is
 exactly what it's name implies: solely an enumeration of assigned hardware
 adapter PCI Device Identifiers.

Which is how it's used both before and after this change.

  5. Because of the above change in the original abstraction layering, a new 
 macro
 CH_PCI_ID_TABLE_ENTRY_DATA is introduced in this patch which passes in
 a desired value for the dev parameter of the PCI_VDEVICE() macro.  But 
 the
 documentation for this new macro in t4_pci_id_tbl.h is incorrectly given 
 the
 documentation of the original CH_PCI_ID_TABLE_ENTRY() macro which
 was originally supplied by the file including t4_pci_id_tbl.h.  This 
 leaves its
 usage confusing for anyone reading the header file.

Do you have any clarifying text to suggest?

cheers, Joe

 In conclusion:
 
  A. I like the use of const in the table.
 
  B. I like removing the redundant content inclusion check of
 CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN.
 
  C. I'm uncomfortable with all the other changes.

 Casey
 
 
 From: Joe Perches [j...@perches.com]
 Sent: Friday, February 13, 2015 6:05 PM
 To: Hariprasad S; Casey Leedom; James E.J. Bottomley
 Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-scsi
 Subject: chelsio: Use a more common const struct pci_device_id foo[] style
 
 Chelsio code shares a pci_device_table from an #include file.
 Make the include guard simpler and make the arrays const.
 
 Reduces data by moving tables to text.
 
 Removed unnecessary macros:
 o CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
 o CH_PCI_DEVICE_ID_TABLE_DEFINE_END
 o CH_PCI_ID_TABLE_ENTRY (moved to the .h file)
 Added new macro define:
 o CH_PCI_ID_TABLE_ENTRY_DATA
 
   text data bss dec hex filename
   50550 923 172   51645c9bd 
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o.new
   469354531 172   51638c9b6 
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o.old
   27864 355   8   282276e43 
 drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o.new
   260722203   8   282836e7b 
 drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.o.old
9734 450  24   1020827e0 drivers/scsi/csiostor/csio_init.o.new
79422242  24   1020827e0 drivers/scsi/csiostor/csio_init.o.old


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] kxcjk-1013 driver optimizations

Adds optimization of i2c transactions in trigger handler and
usage of available_scan_masks for kxcjk-1013.

Adriana Reus (2):
  iio: accel: kxcjk-1013: use available_scan_masks
  iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler

 drivers/iio/accel/kxcjk-1013.c | 50 --
 1 file changed, 39 insertions(+), 11 deletions(-)

-- 
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: [RFC PATCH 3/8] kmod - teach call_usermodehelper() to use a namespace

On 02/16, Oleg Nesterov wrote:

 On 02/16, Ian Kent wrote:
 
  On Tue, 2015-02-10 at 17:55 +0100, Oleg Nesterov wrote:
   On 02/10, Ian Kent wrote:
   
On Mon, 2015-02-09 at 17:03 +0100, Oleg Nesterov wrote:

 I understand. but I still can't understand why we can't implement 
 something
 like
   enter_ns(struct nsproxy *p)
   {
   new_nsproxy = create_new_namespaces(...);

   p-mnt_ns-ns-ops-install(new_nsproxy, ...);
   p-pid_ns_for_children-ns-ops-install(new_nsproxy, 
 ...);
   ...

   switch_task_namespaces(new_nsproxy);
   }

 Why we should abuse fs/proc ?
   
That sounds like a much better approach.
Your saying just take a reference to the nsproxy from the located
process and use it instead, right?
  
   Yes,
 
  I'm still not sure if this can be done (at least without surgery to the
  namespace implementation) and I think I've been here before which is
  what lead to the file_open_root() approach.
 
  The difficulty is the second parameter to the install() call above, the
  struct ns_common. In setns() it's obtained from the procfs file inode
  and the file open is what's used to obtain each namespace type (in the
  form of a struct ns_common) from a process context different from
  current, current being the thread runner process.
 
  I might still be able to work out a (viable) way to obtain the
  appropriate ns_common struct in each case without a file open but it's
  hard to see how.

 Not sure I understand... Every namespace pointer struct nsproxy has
 the struct ns_common ns you need? So you can do (for example)

   p-mnt_ns-ns-ops-install(new_nsproxy, p-mnt_ns-ns);

 or I missed something? (userns differs, you need cred-user_ns, of course).


 Perhaps I missed something, but this doesn't look like a problem...

And in case this wasn't clear we obviously need to pass nsproxy/cred to
sub_info-init().

There is nothing magical in /proc or I am totally confused. Look at 
ns_get_path(),
it (to simplify) does

inode-i_private = ns_ops-get(task);

and every -get() method returns ns-ns.


But again, again:

 The real problem is that , let me repeat, is that pidns_install() does not
 and can't change active_pid_ns. So I think that kernel_thread_in_ns() probably
 make more sense.

Yes...

Oleg.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [LKP] [sched] BUG: kernel boot hang

2015-02-16 Thread Steven Rostedt

On Mon, 16 Feb 2015 19:22:38 +0100
Frederic Weisbecker fweis...@gmail.com wrote:
 
 Huang Ying hasn't yet reported a Tested-by but I could reproduce (with both 
 function and function_graph tracers btw)
 and the patch fixed it.

Ah right, it's not the recursion from the function tracer that kills
us, it's the recursion from the preempt_enable_notrace() that does...

preempt_schedule_common()
  -- traced
 preempt_disable_notrace();
 preempt_enable_notrace();
 (see's NEED_RESCHED set)
preempt_schedule_context();
preempt_schedule_common();
-- traced

etc, etc till boom.

-- Steve

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

Re: [GIT PULL] please pull file-locking related changes for v3.20

2015-02-16 Thread Linus Torvalds

On Mon, Feb 16, 2015 at 6:00 AM, Jeff Layton jlay...@poochiereds.net wrote:

 I'll look at it  again and also see if I can reproduce it with trinity.
 So far, I haven't been able to, but maybe I'll get lucky this time.

Can you please also remove the completely broken counters?

The f*ckers aren't even initialized, they are never used outside of
completely broken cifs code (hint: it doesn't take the spinlock, so it
just uses the counters as a random-number-generator), and even there
it would be better to just count the list instead of maintaining a
count of list entries - and doing it *wrong*.

The lock counters are broken. Get rid of them. Seriously. The reason I
care is that I tried to read the code to manage the locks in
fs/locks.c, and just passing the pointer to the counter around made it
unreadable. And when I actually tried to read it, and look at the
initialization, I see that they are never initialized.

This code is so broken that my initial reaction is We need to just
revert the crap.

And no. The fix is *not* to just initialize those stupid things to
zero. The fix is to remove them.

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

Re: brcmsmac: TX power blocked in BCM4313

2015-02-16 Thread Nikita N.

Hi Arend,
first of all, thank you for your answer.

I'm very sorry to hear that negative feedback.
So, AFAIU, there is no support in brcmsmac for regdom and power
settings.

I don't know how much Broadcom Corp. is complaint with IEEE Standard
802.11-2007 (page 531), along that decision.
Missing also the support for a complete functioning of tools such as
iwconfig and iw, doesn't put Broadcom Corp. very much Linux supporting.
When in fact in the Windows driver, the TX power control is explicitly
enabled and fully operational.

Now, I googled around, and found the following page:
http://www.broadcom.com/support/802.11/linux_sta.php
the README states explicitly:
iwconfig eth1 txpower  iwlist eth1 txpower set and get the drivers
user-requested transmit power level. This can go up to 32 dbm and allows
the user to lower the tx power to levels below the regulatory limit.
Internally, the actual tx power is always kept within regulatory limits
no matter what the user request is set to.

Unfortunately, I don't know if also that STA driver works or not,
because I was not even able to successfully compileinstall it over
latest Ubuntu shipped backports, even if applied all bug patches.
Whose patches, BTW, are coming open-source also from contributors out of
Broadcom Corp, driven simply by the wish to help the community, for
free.

So I would like to ask 3 questions:
1) Why the same STA redgom and power support (shipped with that STA
driver) was not applied also over the latest Linux backports?
2) What exact Ubuntu core version and backports version, have been
adapted by responsibility of Broadcom QA Testing team, to verify the
correctness of specifications advertized officially on that Broadcom
Corp. web page README?

Finally I would like to take the opportunity to ask you Arend, about a
issue I raised a year ago, here a remind FYI:
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/117985

After more than *ONE* year, still the brcmsmac driver can not detect 11n
modulated frames in monitor mode.
Question:
3) Can (at least) that STA driver detect 11n modulated frames in monitor
mode?

I hope you or someone here will be able to answer those questions,
because I'm not going to replicate them elsewhere.
Since I got really frustrated by all those unsatisfactory products and
results from Broadcom Corp., the unsatisfactory support towards Linux
community, and the unsatisfactory Customers care.

Thanks for your attention. 
-- 
  Nikita N.
  niki...@operamail.com


On Mon, Feb 16, 2015, at 07:45 AM, Arend van Spriel wrote:
 On 02/16/15 14:53, Nikita N. wrote:
  Hi Dear brcmsmac Devs,
  following up my previous email, since I didn't receive any feedback, I
  took the trouble to test my understandings myself.
  First of all, I want to report the following fact: the TX power is
  blocked/fixed to 19dbm, no matter what local regdom or power setting.
 
 Hi Nikita,
 
 We saw your previous email just this morning. Basically, tx power 
 control is explicitly disabled in brcmsmac. I think it was one of the 
 internal requirements to get approval for this open-source effort.
 
  If that is an issue or bug or else I leave the decision to you.
  Another fact is that, the Windows driver for that same interface, is
  capable to push the transceiver at least 10 RSSI points higher than
  linux backports brcmsmac driver, which means it is *DO* possible to
  change the TX power.
  In my personal case I want to lower it, but even that is not possible:
  no setting is working, neither changing the regdom (iw reg set) nor the
  power (iwconfig wlan0 txpower, iw dev wlan0 set txpower fixed, iw phy
  wlan0 set txpower fixed).
 
  Now, as for my tests, I just tried to hard-code few values into the
  brcmsmac driver module, only to see if anything changes.
  In details I zeroed the values of all tx_power_offsets in the table
  populated in wlc_lcnphy_txpower_recalc_target (phy_lcn.c), and called
  wlc_lcnphy_set_target_tx_pwr with a value of 40 (minor that 52, which is
  the minimum I found debugging that function).
  Again, nothing changed (even if further calls to
  wlc_lcnphy_set_target_tx_pwr =40)
 
  It is my wish to create a patch for that issue, which I want first to
  test here locally to me, and if workinginteresting, I can propose it
  for merging in next release.
  But, AMOF, now I'm just stuck.
 
  In case anybody feels like giving away any hint/feedback, I would have
  few questions:
  1) is it brcmsmac linux backports driver still supported or
  deprecated?
  2) if deprecated, what is the supported driver for BCM4313?
  3) About my tests, was it correct zeroing all tx_power_offsets in the
  table and call wlc_lcnphy_set_target_tx_pwr=40, to get a TX power less
  that 19dbm?
  4) if it was not correct, or partially correct, what am I missing or
  doing wrong, in order to push the TX transceiver power less than 19dbm?
 
 Sorry to say but I can not help you. I can not encourage (nor 
 discourage) changing the phy code.

Re: [PATCH 1/3] Documentation: minor spelling and grammar fixes

2015-02-16 Thread Jonathan Corbet

On Fri, 13 Feb 2015 16:19:35 -0600
Chris J Arges chris.j.ar...@canonical.com wrote:

  Documentation/vm/slub.txt | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

This one has been applied to the docs tree, thanks.

jon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] usb: plusb: Add support for National Instruments host-to-host cable

2015-02-16 Thread Ben Shelton

The National Instruments USB Host-to-Host Cable is based on the Prolific
PL-25A1 chipset.  Add its VID/PID so the plusb driver will recognize it.

Signed-off-by: Ben Shelton ben.shel...@ni.com
---
 drivers/net/usb/plusb.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 3d18bb0..1bfe0fc 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -134,6 +134,11 @@ static const struct usb_device_id  products [] = {
 }, {
USB_DEVICE(0x050d, 0x258a), /* Belkin F5U258/F5U279 (PL-25A1) */
.driver_info =  (unsigned long) prolific_info,
+}, {
+   USB_DEVICE(0x3923, 0x7825), /* National Instruments USB
+* Host-to-Host Cable
+*/
+   .driver_info =  (unsigned long) prolific_info,
 },
 
{ },// END
-- 
2.3.0

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

Re: [GIT PULL] please pull file-locking related changes for v3.20

2015-02-16 Thread Jeff Layton

On Mon, 16 Feb 2015 11:24:03 -0800
Linus Torvalds torva...@linux-foundation.org wrote:

 On Mon, Feb 16, 2015 at 10:46 AM, Linus Torvalds
 torva...@linux-foundation.org wrote:
 
  This code is so broken that my initial reaction is We need to just
  revert the crap.

Sure, no problem reverting the lock counters. They were an optional
thing anyway...

 
 How the hell is flock_lock_file() supposed to work at all, btw?
 
 Say we have an existing flock, and now do a new one that conflicts. I
 see what looks like three separate bugs.
 
  - We go through the first loop, find a lock of another type, and
 delete it in preparation for replacing it
 
  - we *drop* the lock context spinlock.
 
  - BUG #1? So now there is no lock at all, and somebody can come in
 and see that unlocked state. Is that really valid?
 
  - another thread comes in while the first thread dropped the lock
 context lock, and wants to add its own lock. It doesn't see the
 deleted or pending locks, so it just adds it
 
  - the first thread gets the context spinlock again, and adds the lock
 that replaced the original
 
  - BUG #2? So now there are *two* locks on the thing, and the next
 time you do an unlock (or when you close the file), it will only
 remove/replace the first one.
 
 Both of those bugs are due to the whole drop the lock in the middle,
 which is pretty much always a mistake.  BUG#2 could easily explain the
 warning Kirill reports, afaik.
 

Ahh, well spotted.

That drop the lock in the middle thing has always looked a little fishy
to me, but I had convinced myself a while back that it was OK. I think
you're correct that it's not, however.

I'll spin up a patch to remove it and we can see if that helps the
problem that Kirill saw.

 BUG#3 seems to be independent, and is about somebody replacing an
 existing lock, but the new lock conflicts. Again, the first loop will
 remove the old lock, and then the second loop will see the conflict,
 and return an error (and we may then end up waiting for it for the
 FILE_LOCK_DEFERRED case). Now the original lock is gone. Is that
 really right? That sounds bogus. *Failing* to insert a flock causing
 the old flock to go away?
 

No, I think you're correct here.

The main problem is a LOCK_SH - LOCK_EX upgrade. If there are other
LOCK_SH locks on the file, then you'll both lose your lock and fail to
get the LOCK_EX lock.

I think that's fixable by ensuring that we don't actually remove the
lock until we're sure that we can replace it. I'll see about fixing
that up as well. Give me a couple of days to get those cleaned up and
tested and I'll post some patches that clean up the holes here.

At that point we can see if that fixes Kirill's problem.

 Now, flock semantics are pretty much insane, so maybe all these bugs
 except for #2 aren't actually bugs, and are features of flock. But
 bug #2 can't be a semantic feature.
 
 Is there something I'm missing here?
 

No, I think they're all bugs. flock semantics aren't great, but I'm
pretty sure you shouldn't lose your lock just because you tried to
upgrade one and failed to do so.

 This was all just looking at a *single* function. Quite frankly, I
 hate how the code also just does
 
 if (filp-f_op-flock)
 filp-f_op-flock(filp, F_SETLKW, fl);
 else
 flock_lock_file(filp, fl);
 
 and blithely assumes that some random filesystem will get the flock
 semantics right, when even the code code screwed it up this badly.
 

Sigh yeah. Most of the filesystems that define -flock (or -lock for
that matter) are remote or distributed filesystems, where we leave it
up to the server or lock manager (e.g. DLM) to get it right. I think we
don't have much choice but to assume that they do...

 And maybe I'm wrong, and there's some reason why none of the things
 above can actually happen, but it looks really bad to me.
 
  Linus

Thanks for helping sanity check this stuff. 
-- 
Jeff Layton jlay...@poochiereds.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] 3.18.7-rt1

2015-02-16 Thread Richard Cochran

On Mon, Feb 16, 2015 at 12:18:22PM +0100, Sebastian Andrzej Siewior wrote:
   - CPU hotplug works in general. Steven's test script however
 deadlocks usually on the second invocation.

Where can I find Steve's hotplug test script?

Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [patchlet] rt,locking: fix __ww_mutex_lock_interruptible() lockdep annotation

2015-02-16 Thread Mike Galbraith

On Mon, 2015-02-16 at 18:24 +0100, Sebastian Andrzej Siewior wrote:

 umgwanakikbuti? The good ones were taken, right?

Yup, I have a low tolerance for Taken, try again.  My next may well be
gimmeafuckingaccountdamnit :)

-Mike

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

Re: [PATCH 1/8] x86, fpu: unlazy_fpu: don't reset thread.fpu_counter

On 02/16, Rik van Riel wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 02/16/2015 12:04 PM, Borislav Petkov wrote:

  ... and so by looking at the unlazy_fpu() call sites, I think this
  makes sense.
 
  So how's that for a commit message instead:
 
  --- x86, fpu, unlazy_fpu: Don't reset thread.fpu_counter
 
  The else branch clears -fpu_counter as a remnant of the lazy
  FPU usage counting:
 
  e07e23e1fd30 ([PATCH] non lazy sleazy fpu implementation)
 
  However, switch_fpu_prepare() does this now so that else branch is
  superfluous.
 
  If we do use_eager_fpu(), then this has no effect. Otherwise, if
  we actually wanted to prevent fpu preload after the context switch
  we would need to reset it unconditionally, even if
  __thread_has_fpu(). ---
 
  ?

 Good detective work.

 Your changelog makes sense to me.

And to me, thanks.

Should I resend?

Oleg.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [patchlet] rt,locking: fix __ww_mutex_lock_interruptible() lockdep annotation

2015-02-16 Thread Steven Rostedt

On Mon, 16 Feb 2015 18:24:32 +0100
Sebastian Andrzej Siewior bige...@linutronix.de wrote:

\
 Signed-off-by: Mike Galbraith umgwanakikb...@gmail.com
 
 umgwanakikbuti? The good ones were taken, right?

I think Mike threw up on the keyboard while creating his user name.

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

[PATCH 2/2] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler

From: Adriana Reus adriana.r...@intel.com

Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
enable/disable the bus at each i2c transfer and must wait for
the enable/disable to happen before sending the data.

When reading data in the trigger handler, the kxcjk-1013 accel driver
does one i2c transfer for each axis. This has an impact on the
frequency of the accelerometer at high sample rates due to additional
delays introduced by the i2c bus at each transfer.

Reading all axis values in one i2c transfer reduces the delays
introduced by the i2c bus. In case i2c block read is not supported,
fallback to reading each axis as a separate word.

Signed-off-by: Adriana Reus adriana.r...@intel.com
Signed-off-by: Irina Tirdea irina.tir...@intel.com
Reviewed-by: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com
---
 drivers/iio/accel/kxcjk-1013.c | 44 +-
 1 file changed, 35 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
index 5f27787..bfa2899 100644
--- a/drivers/iio/accel/kxcjk-1013.c
+++ b/drivers/iio/accel/kxcjk-1013.c
@@ -109,6 +109,8 @@ struct kxcjk1013_data {
int64_t timestamp;
enum kx_chipset chipset;
bool is_smo8500_device;
+   s32 (*read_block_data)(const struct i2c_client *client, u8 command,
+  u8 length, u8 *values);
 };
 
 enum kxcjk1013_axis {
@@ -216,6 +218,23 @@ static const struct {
 {800, 0, 0x06},
 {1600, 0, 0x06} };
 
+static s32 kxcjk1013_read_block_data(const struct i2c_client *client,
+u8 command, u8 length, u8 *values)
+{
+   s32 data;
+   u8 i;
+
+   for (i = 0; i  length; i += 2) {
+   data = i2c_smbus_read_word_data(client, command + i);
+   if (data  0)
+   return data;
+
+   values[i] = data  0xFF;
+   values[i+1] = data  8;
+   }
+   return i;
+}
+
 static int kxcjk1013_set_mode(struct kxcjk1013_data *data,
  enum kxcjk1013_mode mode)
 {
@@ -955,18 +974,14 @@ static irqreturn_t kxcjk1013_trigger_handler(int irq, 
void *p)
struct iio_poll_func *pf = p;
struct iio_dev *indio_dev = pf-indio_dev;
struct kxcjk1013_data *data = iio_priv(indio_dev);
-   int bit, ret, i = 0;
+   int ret;
 
mutex_lock(data-mutex);
-   for (bit = 0; bit  AXIS_MAX; bit++) {
-   ret = kxcjk1013_get_acc_reg(data, bit);
-   if (ret  0) {
-   mutex_unlock(data-mutex);
-   goto err;
-   }
-   data-buffer[i++] = ret;
-   }
+   ret = data-read_block_data(data-client, KXCJK1013_REG_XOUT_L,
+   AXIS_MAX * 2, (u8 *) data-buffer);
mutex_unlock(data-mutex);
+   if (ret  0)
+   goto err;
 
iio_push_to_buffers_with_timestamp(indio_dev, data-buffer,
   data-timestamp);
@@ -1196,6 +1211,11 @@ static int kxcjk1013_probe(struct i2c_client *client,
const char *name;
int ret;
 
+   if (!i2c_check_functionality(client-adapter,
+I2C_FUNC_SMBUS_BYTE_DATA |
+I2C_FUNC_SMBUS_READ_WORD_DATA))
+   return -ENODEV;
+
indio_dev = devm_iio_device_alloc(client-dev, sizeof(*data));
if (!indio_dev)
return -ENOMEM;
@@ -1204,6 +1224,12 @@ static int kxcjk1013_probe(struct i2c_client *client,
i2c_set_clientdata(client, indio_dev);
data-client = client;
 
+   if (i2c_check_functionality(client-adapter,
+   I2C_FUNC_SMBUS_READ_I2C_BLOCK))
+   data-read_block_data = i2c_smbus_read_i2c_block_data;
+   else
+   data-read_block_data = kxcjk1013_read_block_data;
+
pdata = dev_get_platdata(client-dev);
if (pdata)
data-active_high_intr = pdata-active_high_intr;
-- 
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: [LKP] [sched] BUG: kernel boot hang

2015-02-16 Thread Frederic Weisbecker

On Mon, Feb 16, 2015 at 04:07:33PM +0100, Peter Zijlstra wrote:
 On Sun, Feb 15, 2015 at 01:18:07PM -0500, Steven Rostedt wrote:
  On Sun, 15 Feb 2015 16:46:22 +0100
  Frederic Weisbecker fweis...@gmail.com wrote:
   diff --git a/kernel/sched/core.c b/kernel/sched/core.c
   index c017a5f..a6d4d6c 100644
   --- a/kernel/sched/core.c
   +++ b/kernel/sched/core.c
   @@ -2879,7 +2879,7 @@ void __sched schedule_preempt_disabled(void)
 preempt_disable();
}

   -static void preempt_schedule_common(void)
   +static void __sched notrace preempt_schedule_common(void)
{
 do {
 preempt_count_add(PREEMPT_ACTIVE);
  
  Ah, since I added better recursion protection code in function tracer
  this didn't break that. But unfortunately, function graph tracer
  doesn't have that protection.
  
  If it traces between preempt_schedule() and where it sets
  PREEMPT_ACTIVE, it can indeed go into an infinite recursion. Yeah,
  preempt_schedule_common() should be notrace, at least until we change
  function_graph to have that recursion protection.
  
  Acked-by: Steven Rostedt rost...@goodmis.org
 
 
 Can someone shoot me a proper patch with Changelog and such?

Sure, I just sent it as: [PATCH] sched: Fix preempt_schedule_common() 
triggering tracing recursion

Huang Ying hasn't yet reported a Tested-by but I could reproduce (with both 
function and function_graph tracers btw)
and the patch fixed it.

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

Re: [patchlet] rt,locking: fix __ww_mutex_lock_interruptible() lockdep annotation

2015-02-16 Thread Mike Galbraith

On Mon, 2015-02-16 at 13:16 -0500, Steven Rostedt wrote:
 On Mon, 16 Feb 2015 18:24:32 +0100
 Sebastian Andrzej Siewior bige...@linutronix.de wrote:
 
 \
  Signed-off-by: Mike Galbraith umgwanakikb...@gmail.com
  
  umgwanakikbuti? The good ones were taken, right?
 
 I think Mike threw up on the keyboard while creating his user name.

Ooook, 'nuff crack'n on little ole /me, get back to work ;-)

-Mike

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

Re: [PATCH 1/1] kernel/fork.c: avoid division by zero

2015-02-16 Thread Guenter Roeck


On 02/16/2015 10:45 AM, Heinrich Schuchardt wrote:

I am resending this mail because the linux-kernel list was not CCed.


Yes, sorry, that got lost. The forward feature on lkml.org doesn't work
as well as it used to, unfortunately, and I keep forgetting.


On 16.02.2015 19:23, Guenter Roeck wrote:

On Mon, Feb 16, 2015 at 07:00:44PM +0100, Heinrich Schuchardt wrote:

PAGE_SIZE is not guaranteed to be equal to or less than 8 times the
THREAD_SIZE.

E.g. architecture hexagon may have page size 1M and thread size 4096.

This would lead to a division by zero.

Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de
---
  kernel/fork.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index cf65139..71e2583 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -273,7 +273,8 @@ void __init fork_init(unsigned long mempages)
 * value: the thread structures can take up at most half
 * of memory.
 */
-   max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
+   max_threads = (u64) PAGE_SIZE * (u64) mempages
+   / (u64) THREAD_SIZE / 8UL;


How about
max_threads = mempages / (8 * THREAD_SIZE) * PAGE_SIZE;

instead ? That would avoid the u64.


We have to consider the case mempages  8 * THREAD_SIZE.

Let
   mempages = 1024
   THREAD_SIZE = 4096
   PAGE_SIZE = 1M

Your code gives 0.
Mine gives 8192.


Makes sense.

Thanks,
Guenter


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

Re: [PATCH 1/1] pty: BREAK for pseudoterminals

2015-02-16 Thread Peter Hurley

On 02/16/2015 01:30 PM, Peter Hurley wrote:
 On 02/16/2015 12:16 PM, Petr Tesarik wrote:
 On Mon, 16 Feb 2015 11:24:16 -0500
 Peter Hurley pe...@hurleysoftware.com wrote:
 On 02/16/2015 08:22 AM, Petr Tesarik wrote:
 On Mon, 16 Feb 2015 08:04:02 -0500
 Peter Hurley pe...@hurleysoftware.com wrote:
 On 02/05/2015 02:11 PM, Nan Li wrote:

[...]

 AFAICT this is simply for convenience, as sysrq functionality is
 already available via sendkey.

 That's a completely different story. This patch (after fixing it to
 work with the terminal end) would allow me to set up a QEMU emulated
 serial port using a pty (i.e. -chardev pty) and send a BREAK signal
 to it, no matter what is running in the guest.
 
 
 I mean, I can run an emulated MIPS64 as a QEMU guest on an x86_64 host,
 and still somehow pass SysRq to it. IIUC this will never be possible
 with KVP.

Sorry about that; accidentally pressed send :/

I see this as a shortcoming of the emulation, not of the underlying
IPC used. I don't see why this couldn't be done in-band with any IPC.


 Another use case: In my job, I'm struggling with different serial
 consoles (some using ipmi SoL, some using telnet to a service
 processor, some connected with a real RS-232 link). If I could send
 BREAK over a pty, I could extend ipmiconsole to translate it to the SOL
 message, telnet to translate it to the telnet escape, amtterm to send a
 corresponding message... Then I could send a BREAK to any of my systems
 simply by pressing 'C-A b' in screen(1) without having to think how is
 this particular machine connected and what the correct sequence is for
 that protocol.

I need to think more on this.

Regards,
Peter Hurley

PS - it's interesting that you mention a service processor, because the
hacked support for remote supervisor adapter is and has been the #1
barrier to splitting the 8250 driver. I literally have spent days trying
to come up with an acceptable solution.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] bmc150-accel driver optimizations


 Adds optimization of i2c transactions in trigger handler and
 usage of available_scan_masks for bmc150-accel.

same comments as for kxcjk-1013, this changes the capabilities of the 
driver
 
 Irina Tirdea (2):
   iio: accel: bmc150: use available_scan_masks
   iio: accel: bmc150: optimize i2c transfers in trigger handler
 
  drivers/iio/accel/bmc150-accel.c | 49 
 +++-
  1 file changed, 38 insertions(+), 11 deletions(-)
 
 

-- 

Peter Meerwald
+43-664-218 (mobile)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/2] bmg160 driver optimizations


 Adds optimization of i2c transactions in trigger handler and
 usage of available_scan_masks for bmg160.

same concerns as with bmc150 and kxcjk-1013
 
 Changes in v2:
  - fallback to i2c word transactions if i2c block transactions are not 
 supported
  - use available_scan_masks to let the iio core choose the values selected
 by the user instead of doing the check in the driver's interrupt handler
  - check functionality for i2c byte and word read
 
 Irina Tirdea (2):
   iio: gyro: bmg160: use available_scan_masks
   iio: gyro: bmg160: optimize i2c transfers in trigger handler
 
  drivers/iio/gyro/bmg160.c | 50 
 ---
  1 file changed, 39 insertions(+), 11 deletions(-)
 
 

-- 

Peter Meerwald
+43-664-218 (mobile)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [torture] INFO: task killall5:262 blocked for more than 120 seconds.

2015-02-16 Thread Paul E. McKenney

On Mon, Feb 16, 2015 at 03:25:28PM +0800, Fengguang Wu wrote:
 Hi Paul,
 
 FYI, this may be very hard to reproduce.

Indeed, I have not seen it.

But was this on a CONFIG_PREEMPT=n kernel?

Thanx, Paul

 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
 revert-d347efeb16d3d5150cb7f8d50b05f388b572840e-ab7d45053f99f44f81a221eb5c9fbe253ee94524
 
 commit ab7d45053f99f44f81a221eb5c9fbe253ee94524
 Author: Paul E. McKenney paul...@linux.vnet.ibm.com
 AuthorDate: Tue Mar 4 11:03:21 2014 -0800
 Commit: Paul E. McKenney paul...@linux.vnet.ibm.com
 CommitDate: Wed May 14 09:46:02 2014 -0700
 
 torture: Increase stutter-end intensity
 
 Currently, all stuttered kthreads block a jiffy at a time, which can
 result in them starting at different times.  (Note: This is not an
 energy-efficiency problem unless you run torture tests in production,
 in which case you have other problems!)  This commit increases the
 intensity of the restart event by causing kthreads to spin through the
 last jiffy, restarting when they see the variable change.
 
 Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
 Reviewed-by: Josh Triplett j...@joshtriplett.org
 
 +---++++
 |   | fff35c4e9f 
 | ab7d45053f | 7afb8886a0 |
 +---++++
 | boot_successes| 1000   
 | 884| 14 |
 | boot_failures | 0  
 | 16 | 2  |
 | INFO:task_blocked_for_more_than#seconds   | 0  
 | 12 | 2  |
 | Kernel_panic-not_syncing:hung_task:blocked_tasks  | 0  
 | 12 | 2  |
 | backtrace:watchdog| 0  
 | 12 | 2  |
 | WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_stats_print() | 0  
 | 4  ||
 | backtrace:rcu_torture_stats   | 0  
 | 4  ||
 | backtrace:rcu_torture_boost   | 0  
 | 0  | 2  |
 +---++++
 
 [  183.290093] rcu-torture: Reader Batch:  7006877 238 0 0 0 0 0 0 0 0 0
 [  183.290093] rcu-torture: Free-Block Circulation:  622 622 621 620 619 618 
 617 616 615 614 0
 [  183.290093] ??? Writer stall state 5 g550 c550 f0x0
 [  240.530125] INFO: task killall5:262 blocked for more than 120 seconds.
 [  240.531833]   Not tainted 3.15.0-rc1-00022-gab7d450 #5
 [  240.550103] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables 
 this message.
 [  240.551948] CPU: 0 PID: 27 Comm: khungtaskd Not tainted 
 3.15.0-rc1-00022-gab7d450 #5
 [  240.553610] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
 1.7.5-20140531_083030-gandalf 04/01/2014
 [  240.555632] task: d1cea290 ti: d1d3e000 task.ti: d1d3e000
 [  240.556741] Stack:
 [  240.557395] Call Trace:
 [  240.558122] Code: 81 00 d3 ff ff f6 c4 10 75 ed c1 e3 18 89 99 10 d3 ff ff 
 89 f0 09 d0 80 ce 04 83 fe 02 0f 45 d0 a1 6c 1b 06 c2 89 90 00 d3 ff ff 89 
 f8 50 9d 8d 74 26 00 83 c4 04 5b 5e 5f 5d c3 ba 70 00 00 00
 [  240.560012] CPU: 1 PID: 64 Comm: rcu_torture_boo Not tainted 
 3.15.0-rc1-00022-gab7d450 #5
 [  240.560012] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
 1.7.5-20140531_083030-gandalf 04/01/2014
 [  240.560012] task: cc4d4310 ti: cc4d8000 task.ti: cc4d8000
 [  240.560012] Stack:
 [  240.560012] Call Trace:
 [  240.560012] Code: 00 00 8b 00 85 c0 0f 85 85 00 00 00 a1 fc 85 7c c2 85 c0 
 74 46 a1 fc 85 7c c2 83 f8 01 74 5c a1 fc 85 7c c2 85 c0 74 23 8d 76 00 31 
 c9 ba 1c 02 00 00 b8 ac d5 eb c1 e8 5f 12 fb ff e8 8a 0c b3
 [  240.598110] Kernel panic - not syncing: hung_task: blocked tasks
 [  240.599315] CPU: 0 PID: 27 Comm: khungtaskd Not tainted 
 3.15.0-rc1-00022-gab7d450 #5
 [  240.600854] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
 1.7.5-20140531_083030-gandalf 04/01/2014
 [  240.602788]  7f95  d1d3fedc c1be7294 d29b6f60 d1d3fef4 
 c1be4f9d 7f95
 [  240.604992]  d29b6f60 7f95 d29b71c8 d1d3ff24 c10a7d1d c1eb744c 
 0395 0078
 [  240.607268]  0002 7f95 d29b6f60 d29b71c8 d1d38e00  
 c10a7a50 d1d3ffac
 [  240.607938] Call Trace:
 [  240.607938]  [c1be7294] dump_stack+0x48/0x69
 [  240.607938]  [c1be4f9d] panic+0x7c/0x184
 [  240.607938]  [c10a7d1d] watchdog+0x2cd/0x2d0
 [  240.607938]  [c10a7a50] ? hung_task_panic+0x20/0x20
 [  240.607938]  [c105fb93] kthread+0xa3/0xc0
 [  240.607938]  [c1bf0701] ret_from_kernel_thread+0x21/0x30

RE: chelsio: Use a more common const struct pci_device_id foo[] style

2015-02-16 Thread Casey Leedom

  Okay, thanks for your patience with my lack of understanding.  I'll work with 
Hariprasad tomorrow to get a revised patch out with the const change and 
eliminate the redundant check of CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN to guard 
the file contents.  Thanks for caching these improvements!

  And given that it's pretty empty at work here on this holiday and how 
beautiful it is outside, I think it's time to head home to enjoy lunch outside!

Casey


From: Joe Perches [j...@perches.com]
Sent: Monday, February 16, 2015 11:18 AM
To: Casey Leedom
Cc: Hariprasad S; James E.J. Bottomley; net...@vger.kernel.org; 
linux-kernel@vger.kernel.org; linux-scsi; David Miller
Subject: Re: chelsio: Use a more common const struct pci_device_id foo[] style

On Mon, 2015-02-16 at 19:07 +, Casey Leedom wrote:
   I understand that OS-independence issues aren't something which are
 normally accommodated, but as long as definitions don't introduce
 unnecessary foreign intrusion I would hope that it would be okay.
 As I noted, our t4_regs.h file is also OS-independent and used by six
 other OS device drivers.  Putting Linux definitions into
 t4_pci_id_tbl.h would be somewhat akin to injecting Linux dependencies
 into t4_regs.h.

   But, if the change must be made, then we'll just maintain a
 translation between our Common Code and the kernel.org code.  If
 that's the case, probably the best documentation for the proposed
 CH_PCI_ID_TABLE_ENTRY_DATA might be something like:

  * CH_PCI_ID_TABLE_ENTRY_DATA
  *   -- Used for the individual PCI Device ID entries for the
 PCI_VDEVICE() dev
  *   -- parameter.

   So it sounds like Chelsio would be required to make this change
 then?  I'm still unclear on the likes of responsibility/authority
 here.  We're being told that we must do this but we have to be the
 ones requesting it?  Sorry for my confusion.

It's just a suggested patch.
It's your code, you don't _have_ to do anything.

 (Which is doubly apparent since I came into work this morning only to
 realize that it's a company holiday.  Color me a moron today.)

Yay for holidays.

It can be personally beneficial to take the day off.
It could also be very productive to work with no distractions.

As always, your choice...

cheers, Joe


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: make mandocs build failure with next-20150210

2015-02-16 Thread Greg Kroah-Hartman

On Mon, Feb 16, 2015 at 12:25:04PM -0700, Jonathan Corbet wrote:
 On Mon, 16 Feb 2015 16:21:30 +
 Alan Cox a...@linux.intel.com wrote:
 
   This warning started to appear on Linus's tree, after staging pull
   request was merged.  
  
  I sent GregKH a fix for it a while ago
 
 He seemed to indicate that he doesn't have it.  The following would seem
 to fit the bill; unless somebody objects I'll send it upward so that docs
 builds start working again.
 
 Thanks,
 
 jon
 
 From a984e29fbe72371b203c43a33b66df44b4c8a948 Mon Sep 17 00:00:00 2001
 From: Jonathan Corbet cor...@lwn.net
 Date: Mon, 16 Feb 2015 12:21:42 -0700
 Subject: [PATCH] Fix docs build failure caused by i2o removal
 
 The movement of the I2O tree into staging broke the DocBook build.  Rather
 than redirect the i2o references into staging, it seems better to just
 remove them since this code is on its way out anyway.
 
 Signed-off-by: Jonathan Corbet cor...@lwn.net

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

Re: make mandocs build failure with next-20150210

2015-02-16 Thread Greg Kroah-Hartman

On Mon, Feb 16, 2015 at 12:25:04PM -0700, Jonathan Corbet wrote:
 On Mon, 16 Feb 2015 16:21:30 +
 Alan Cox a...@linux.intel.com wrote:
 
   This warning started to appear on Linus's tree, after staging pull
   request was merged.  
  
  I sent GregKH a fix for it a while ago
 
 He seemed to indicate that he doesn't have it.  The following would seem
 to fit the bill; unless somebody objects I'll send it upward so that docs
 builds start working again.

I got the second patch, but it was too late for my first round of
patches to send to Linus.  Feel free to send this on yourself as I'm
going to be at a conference all this week and have limited time to do
this.

thanks,

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

[PULL] DocBook build failure fix

2015-02-16 Thread Jonathan Corbet

One quick patch so that building the DocBook documentation works again...

Thanks,

jon

The following changes since commit
1fa185ebcbcefdc5229c783450c9f0439a69f0c1:

  Merge tag 'cris-for-3.20' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris (2015-02-15 18:02:02 
-0800)

are available in the git repository at:

  git://git.lwn.net/linux-2.6.git tags/docs-fix

for you to fetch changes up to c20f29f63ca6271386a568c069e347f65fac7025:

  Fix docs build failure caused by i2o removal (2015-02-16 12:52:08 -0700)


Fix the DocBook build failure caused by the move of the i2o subsystem to
the staging tree.


Jonathan Corbet (1):
  Fix docs build failure caused by i2o removal

 Documentation/DocBook/device-drivers.tmpl | 17 -
 1 file changed, 17 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] kernel/fork.c: avoid division by zero

2015-02-16 Thread Heinrich Schuchardt

PAGE_SIZE is not guaranteed to be equal to or less than 8 times the
THREAD_SIZE.

E.g. architecture hexagon may have page size 1M and thread size 4096.

This would lead to a division by zero.

Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de
---
 kernel/fork.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index cf65139..71e2583 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -273,7 +273,8 @@ void __init fork_init(unsigned long mempages)
 * value: the thread structures can take up at most half
 * of memory.
 */
-   max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
+   max_threads = (u64) PAGE_SIZE * (u64) mempages
+   / (u64) THREAD_SIZE / 8UL;
 
/*
 * we need to allow at least 20 threads to boot a system
-- 
2.1.4

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

Re: [PATCH 01/35] ACPI/acpi_pad: Remove the local apic nonsense

2015-02-16 Thread Rafael J. Wysocki

On Monday, February 16, 2015 01:14:36 PM Peter Zijlstra wrote:
 From: Thomas Gleixner t...@linutronix.de
 
 While looking through the (ab)use of the clockevents_notify() function
 I stumbled over the following gem in the acpi_pad code:
 
   if (lapic_detected_unstable  !lapic_marked_unstable) {
  /* LAPIC could halt in idle, so notify users */
  for_each_online_cpu(i)
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, i);
  lapic_marked_unstable = 1;
   }
 
 This code calls on the cpu which detects the lapic unstable condition
 first clockevents_notify() to tell the core code that the broadcast
 should be enabled on all online cpus. Brilliant stuff that as it
 notifies the core code a num_online_cpus() times that the broadcast
 should be enabled on the current cpu.
 
 This probably has never been noticed because that code got never
 tested with NOHZ=n and HIGHRES_TIMER=n or it just worked by chance
 because one of the other mechanisms told the core in the right way
 that the local apic timer is wreckaged.
 
 Sigh, this is:
 
  - The 4th incarnation of idle drivers which has their own mechanism
to detect and deal with X86_FEATURE_ARAT.
 
  - The 2nd incarnation of fake idle mechanisms with a different set of
brainmelting bugs.
 
  - Has been merged against an explicit NAK of the scheduler
maintainer with the promise to improve it over time.
 
  - Another example of featuritis driven trainwreck engineering.
 
  - Another pointless waste of my time.
 
 Fix this nonsense by removing that lapic detection and notification
 logic and simply call into the clockevents code unconditonally. The
 ARAT feature is marked in the lapic clockevent already so the core
 code will just ignore the requests and return.
 
 Signed-off-by: Thomas Gleixner t...@linutronix.de
 Cc: Rafael J. Wysocki r...@rjwysocki.net

Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com

 Cc: Len Brown l...@kernel.org
 Cc: linux-a...@vger.kernel.org
 Cc: Peter Zijlstra pet...@infradead.org
 ---
  drivers/acpi/acpi_pad.c |   26 +-
  1 file changed, 5 insertions(+), 21 deletions(-)
 
 Index: linux/drivers/acpi/acpi_pad.c
 ===
 --- linux.orig/drivers/acpi/acpi_pad.c
 +++ linux/drivers/acpi/acpi_pad.c
 @@ -41,8 +41,6 @@ static unsigned long power_saving_mwait_
  
  static unsigned char tsc_detected_unstable;
  static unsigned char tsc_marked_unstable;
 -static unsigned char lapic_detected_unstable;
 -static unsigned char lapic_marked_unstable;
  
  static void power_saving_mwait_init(void)
  {
 @@ -82,13 +80,10 @@ static void power_saving_mwait_init(void
*/
   if (!boot_cpu_has(X86_FEATURE_NONSTOP_TSC))
   tsc_detected_unstable = 1;
 - if (!boot_cpu_has(X86_FEATURE_ARAT))
 - lapic_detected_unstable = 1;
   break;
   default:
 - /* TSC  LAPIC could halt in idle */
 + /* TSC could halt in idle */
   tsc_detected_unstable = 1;
 - lapic_detected_unstable = 1;
   }
  #endif
  }
 @@ -177,28 +172,17 @@ static int power_saving_thread(void *dat
   mark_tsc_unstable(TSC halts in idle);
   tsc_marked_unstable = 1;
   }
 - if (lapic_detected_unstable  !lapic_marked_unstable) {
 - int i;
 - /* LAPIC could halt in idle, so notify users */
 - for_each_online_cpu(i)
 - clockevents_notify(
 - CLOCK_EVT_NOTIFY_BROADCAST_ON,
 - i);
 - lapic_marked_unstable = 1;
 - }
 + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, cpu);
 +
   local_irq_disable();
   cpu = smp_processor_id();
 - if (lapic_marked_unstable)
 - clockevents_notify(
 - CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
 + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, 
 cpu);
   stop_critical_timings();
  
   mwait_idle_with_hints(power_saving_mwait_eax, 1);
  
   start_critical_timings();
 - if (lapic_marked_unstable)
 - clockevents_notify(
 - CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
 + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, 
 cpu);
   local_irq_enable();
  
   if (time_before(expire_time, jiffies)) {
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-acpi in
 the body of a message to

Re: [PATCH] x86, irq: Fix regression caused by commit b568b8601f05

2015-02-16 Thread Ville Syrjälä

On Mon, Feb 16, 2015 at 10:11:13AM +0800, Jiang Liu wrote:
 Commit b568b8601f05 (Treat SCI interrupt as normal GSI interrupt)
 accidently removes support of legacy PIC interrupt when fixing a
 regression for Xen, which causes a nasty regression on HP/Compaq
 nc6000 where we fail to register the ACPI interrupt, and thus
 lose eg. thermal notifications leading a potentially overheated
 machine.
 
 So reintroduce support of legacy PIC based ACPI SCI interrupt.
 
 Reported-by: Ville Syrjälä syrj...@sci.fi
 Signed-off-by: Jiang Liu jiang@linux.intel.com
 ---
 Hi Ville,
   Could you please help to try this patch instead of revert commit
 b568b8601f05?

Yep, this seems to fix it. Thanks.

Tested-by: Ville Syrjälä syrj...@sci.fi
Cc: sta...@vger.kernel.org # 3.19

That's one regression fixed on this machine, time to go bisect the next one...

 Thanks!
 Gerry
 ---
  arch/x86/kernel/acpi/boot.c |5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
 index ae97ed0873c6..3d525c6124f6 100644
 --- a/arch/x86/kernel/acpi/boot.c
 +++ b/arch/x86/kernel/acpi/boot.c
 @@ -613,6 +613,11 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
  {
   int rc, irq, trigger, polarity;
  
 + if (acpi_irq_model == ACPI_IRQ_MODEL_PIC) {
 + *irqp = gsi;
 + return 0;
 + }
 +
   rc = acpi_get_override_irq(gsi, trigger, polarity);
   if (rc == 0) {
   trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
 -- 
 1.7.10.4
 

-- 
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ppp0: hw csum failure since 3fcb95a84

2015-02-16 Thread Thomas D.

Hi,

on my VPN server (strongswan-5.2.2 + ppp-2.4.7 + xl2tpd-1.3.6) I am
seeing the following errors since linux-3.18 when a client (roadwarrior)
connects (this is not fixed in linux-3.19.0):

 Feb 16 20:36:08 vpn1 kernel: [   90.265403] ppp0: hw csum failure
 Feb 16 20:36:08 vpn1 kernel: [   90.265411] CPU: 7 PID: 0 Comm: swapper/7 
 Tainted: G   O   3.17.0-rc4-00953-g3fcb95a #1
 Feb 16 20:36:08 vpn1 kernel: [   90.265414] Hardware name: FUJITSU SIEMENS 
 PRIMERGY RX200 S4 /D2671, BIOS 4.06  Rev. 1.17.2671 
 02/16/2010
 Feb 16 20:36:08 vpn1 kernel: [   90.265416]  0001 
 88043f9c3b90 816a9c14 880428477000
 Feb 16 20:36:08 vpn1 kernel: [   90.265420]  88043f9c3ba8 
 815bb6ea 8800bb69bd00 88043f9c3bd8
 Feb 16 20:36:08 vpn1 kernel: [   90.265423]  815b3255 
 b49cb2560011 8800bb69bd00 0014
 Feb 16 20:36:08 vpn1 kernel: [   90.265427] Call Trace:
 Feb 16 20:36:08 vpn1 kernel: [   90.265429]  IRQ  [816a9c14] 
 dump_stack+0x45/0x56
 Feb 16 20:36:08 vpn1 kernel: [   90.265444]  [815bb6ea] 
 netdev_rx_csum_fault+0x3a/0x40
 Feb 16 20:36:08 vpn1 kernel: [   90.265447]  [815b3255] 
 __skb_checksum_complete+0xa5/0xb0
 Feb 16 20:36:08 vpn1 kernel: [   90.265451]  [8163c34c] 
 nf_ip_checksum+0xcc/0x100
 Feb 16 20:36:08 vpn1 kernel: [   90.265473]  [a03116b2] 
 udp_error+0x102/0x1f0 [nf_conntrack]
 Feb 16 20:36:08 vpn1 kernel: [   90.265481]  [a030b78c] 
 nf_conntrack_in+0xec/0x9a0 [nf_conntrack]
 Feb 16 20:36:08 vpn1 kernel: [   90.265487]  [815f441f] ? 
 ip_rcv+0x27f/0x380
 Feb 16 20:36:08 vpn1 kernel: [   90.265490]  [815f3ab0] ? 
 inet_del_offload+0x40/0x40
 Feb 16 20:36:08 vpn1 kernel: [   90.265496]  [a0339352] 
 ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4]
 Feb 16 20:36:08 vpn1 kernel: [   90.265499]  [815ed6ba] 
 nf_iterate+0x9a/0xb0
 Feb 16 20:36:08 vpn1 kernel: [   90.265503]  [815f3ab0] ? 
 inet_del_offload+0x40/0x40
 Feb 16 20:36:08 vpn1 kernel: [   90.265506]  [815ed744] 
 nf_hook_slow+0x74/0x130
 Feb 16 20:36:08 vpn1 kernel: [   90.265509]  [815f3ab0] ? 
 inet_del_offload+0x40/0x40
 Feb 16 20:36:08 vpn1 kernel: [   90.265513]  [815f448e] 
 ip_rcv+0x2ee/0x380
 Feb 16 20:36:08 vpn1 kernel: [   90.265516]  [815bd622] 
 __netif_receive_skb_core+0x1e2/0x7c0
 Feb 16 20:36:08 vpn1 kernel: [   90.265519]  [815bdc16] 
 __netif_receive_skb+0x16/0x70
 Feb 16 20:36:08 vpn1 kernel: [   90.265521]  [815be764] 
 process_backlog+0x94/0x150
 Feb 16 20:36:08 vpn1 kernel: [   90.265524]  [815be02a] 
 net_rx_action+0x11a/0x1b0
 Feb 16 20:36:08 vpn1 kernel: [   90.265529]  [810d904c] 
 __do_softirq+0x10c/0x280
 Feb 16 20:36:08 vpn1 kernel: [   90.265532]  [810d9315] 
 irq_exit+0x95/0xa0
 Feb 16 20:36:08 vpn1 kernel: [   90.265536]  [816b2656] 
 do_IRQ+0x56/0xe0
 Feb 16 20:36:08 vpn1 kernel: [   90.265540]  [816b0bea] 
 common_interrupt+0x6a/0x6a
 Feb 16 20:36:08 vpn1 kernel: [   90.265541]  EOI  [8100c95c] ? 
 default_idle+0x1c/0xb0
 Feb 16 20:36:08 vpn1 kernel: [   90.265549]  [8100d23f] 
 arch_cpu_idle+0xf/0x20
 Feb 16 20:36:08 vpn1 kernel: [   90.265553]  [81112547] 
 cpu_startup_entry+0x367/0x3a0
 Feb 16 20:36:08 vpn1 kernel: [   90.265558]  [8102d712] 
 start_secondary+0x1e2/0x220
 Feb 16 20:36:12 vpn1 kernel: [   94.253650] ppp0: hw csum failure
 Feb 16 20:36:12 vpn1 kernel: [   94.253665] CPU: 0 PID: 0 Comm: swapper/0 
 Tainted: G   O   3.17.0-rc4-00953-g3fcb95a #1
 Feb 16 20:36:12 vpn1 kernel: [   94.253667] Hardware name: FUJITSU SIEMENS 
 PRIMERGY RX200 S4 /D2671, BIOS 4.06  Rev. 1.17.2671 
 02/16/2010
 Feb 16 20:36:12 vpn1 kernel: [   94.253670]  0001 
 88043f803b90 816a9c14 880428477000
 Feb 16 20:36:12 vpn1 kernel: [   94.253674]  88043f803ba8 
 815bb6ea 88042646bf00 88043f803bd8
 Feb 16 20:36:12 vpn1 kernel: [   94.253677]  815b3255 
 b39cb3560011 88042646bf00 0014
 Feb 16 20:36:12 vpn1 kernel: [   94.253680] Call Trace:
 Feb 16 20:36:12 vpn1 kernel: [   94.253682]  IRQ  [816a9c14] 
 dump_stack+0x45/0x56
 Feb 16 20:36:12 vpn1 kernel: [   94.253697]  [815bb6ea] 
 netdev_rx_csum_fault+0x3a/0x40
 Feb 16 20:36:12 vpn1 kernel: [   94.253700]  [815b3255] 
 __skb_checksum_complete+0xa5/0xb0
 Feb 16 20:36:12 vpn1 kernel: [   94.253704]  [8163c34c] 
 nf_ip_checksum+0xcc/0x100
 Feb 16 20:36:12 vpn1 kernel: [   94.253725]  [a03116b2] 
 udp_error+0x102/0x1f0 [nf_conntrack]
 Feb 16 20:36:12 vpn1 kernel: [   94.253732]  [a030b78c] 
 nf_conntrack_in+0xec/0x9a0 [nf_conntrack]
 Feb 16 20:36:12 vpn1 kernel: [   94.253739]  [815f441f] ? 
 ip_rcv+0x27f/0x380
 Feb 16 20:36:12 vpn1 kernel: [   94.253742]  [815f3ab0] ? 
 inet_del_offload+0x40/0x40
 Feb

[PATCH] sched,rt,nohz: stop scheduler tick if running realtime task

2015-02-16 Thread Rik van Riel

If the CPU is running a realtime task that does not round-robin with
another realtime task of equal priority, there is no point in keeping
the scheduler tick going. After all, whenever the scheduler tick runs,
the kernel will just decide not to reschedule.

Extend sched_can_stop_tick to recognize these situations, and inform
the rest of the kernel that the scheduler tick can be stopped.

Signed-off-by: Rik van Riel r...@redhat.com
Tested-by: Luiz Capitulino lcapitul...@redhat.com
---
 kernel/sched/core.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ade2958a9197..ad985a632c4d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -745,6 +745,22 @@ static inline bool got_nohz_idle_kick(void)
 bool sched_can_stop_tick(void)
 {
/*
+* FIFO realtime policy runs the highest priority task. Other runnable
+* tasks are of a lower priority. The scheduler tick does nothing.
+*/
+   if (current-policy == SCHED_FIFO)
+   return true;
+
+   /*
+* Round-robin realtime tasks time slice with other tasks at the same
+* realtime priority. Is this task the only one at this priority?
+*/
+   if (current-policy == SCHED_RR) {
+   struct sched_rt_entity *rt_se = current-rt;
+   return rt_se-run_list.prev == rt_se-run_list.next;
+   }
+
+   /*
 * More than one running task need preemption.
 * nr_running update is assumed to be visible
 * after IPI is sent from wakers.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 RESEND] clk: mxs: Fix invalid 32-bit access to frac registers

2015-02-16 Thread Stefan Wahren

Hi Fabio,

 Fabio Estevam feste...@gmail.com hat am 12. Februar 2015 um 20:08
 geschrieben:


 Hi Stefan,

 On Thu, Feb 12, 2015 at 4:59 PM, Stefan Wahren stefan.wah...@i2se.com wrote:
  Hi Fabio,
 
  Fabio Estevam feste...@gmail.com hat am 11. Februar 2015 um 22:10
  geschrieben:
 
 
  On Wed, Feb 11, 2015 at 6:31 PM, Stefan Wahren stefan.wah...@i2se.com
  wrote:
 
   I always get 0x5e5b5513 with or without your patch.
  
   very strange. Do you have any idea why IO1_STABLE is permanent low?
 
  On my case it is always 1.
 
  i expected the same behavior on my hardware.
 
  Do you use u-boot as bootloader?

 Yes, I do.

i will try to test it with u-boot.


 
   Can you confirm the behavior according to your flash issue?
 
  In my tests IO1_STABLE stays the same.
 
  This wasn't the intension of my second question. I wanted to know about the
  state of the SPI NOR flash detection process.
 
  Does it sucessed if you apply the patch, but revert the changes in
  clk_ref_set_rate() from clk-ref.c?

 I don't have my mx28evk setup available at the moment, but when I
 applied your patch and reverted all the changes in clk-ref.c, then the
 SPI flash detection works.

 I haven't tested to only reverting the changes inside
 clk_ref_set_rate(), but I can do it tomorrow.

I think the reason for the problem in the flash detection is caused by the
misaligned access on the frac register.

Maybe you want to try the following after the second patch is reverted.

Stefan

8--
diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
index 9fc9359..87969e3 100644
--- a/drivers/clk/mxs/clk-imx23.c
+++ b/drivers/clk/mxs/clk-imx23.c
@@ -73,8 +73,10 @@ static void __init clk_misc_init(void)
 * 480 MHz seems too high to be ssp clock source directly,
 * so set frac to get a 288 MHz ref_io.
 */
-   writel_relaxed(0x3f  BP_FRAC_IOFRAC, FRAC + CLR);
-   writel_relaxed(30  BP_FRAC_IOFRAC, FRAC + SET);
+   val = readl_relaxed(FRAC);
+   val = ~(0x3f  BP_FRAC_IOFRAC);
+   val |= 30  BP_FRAC_IOFRAC;
+   writel_relaxed(val, FRAC);
 }
 
 static const char *sel_pll[]  __initconst = { pll, ref_xtal, };
diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
index a6c3501..e47ad69 100644
--- a/drivers/clk/mxs/clk-imx28.c
+++ b/drivers/clk/mxs/clk-imx28.c
@@ -118,10 +118,15 @@ static void __init clk_misc_init(void)
/*
 * 480 MHz seems too high to be ssp clock source directly,
 * so set frac0 to get a 288 MHz ref_io0 and ref_io1.
+* According to reference manual we must modify frac bytewise.
 */
val = readl_relaxed(FRAC0);
-   val = ~((0x3f  BP_FRAC0_IO0FRAC) | (0x3f  BP_FRAC0_IO1FRAC));
-   val |= (30  BP_FRAC0_IO0FRAC) | (30  BP_FRAC0_IO1FRAC);
+   val = ~(0x3f  BP_FRAC0_IO0FRAC);
+   val |= 30  BP_FRAC0_IO0FRAC;
+   writel_relaxed(val, FRAC0);
+   val = readl_relaxed(FRAC0);
+   val = ~(0x3f  BP_FRAC0_IO1FRAC);
+   val |= 30  BP_FRAC0_IO1FRAC;
writel_relaxed(val, FRAC0);
 }
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: Tree for Feb 16

2015-02-16 Thread Stephen Rothwell

Hi Guenter,

On Mon, 16 Feb 2015 09:12:13 -0800 Guenter Roeck li...@roeck-us.net wrote:

 On Thu, Feb 16, 2012 at 04:41:44PM +1100, Stephen Rothwell wrote:
  
  Changes since 20120215:
 ---
 [ Trying again, this time hopefully replying to the correct e-mail.
   Sorry for the earlier noise. ]

Did you really mean to reply to a release from 3 years ago?

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


pgpMHUVdVWW8l.pgp
Description: OpenPGP digital signature

Re: [PATCH] ASLR: fix stack randomization on 64-bit systems

2015-02-16 Thread Andy Lutomirski


On 02/14/2015 09:33 AM, Kees Cook wrote:

From: Hector Marco-Gisbert hecma...@upv.es

The issue is that the stack for processes is not properly randomized on 64 bit
architectures due to an integer overflow.

The affected function is randomize_stack_top() in file fs/binfmt_elf.c:

static unsigned long randomize_stack_top(unsigned long stack_top)
{
  unsigned int random_variable = 0;

  if ((current-flags  PF_RANDOMIZE) 
  !(current-personality  ADDR_NO_RANDOMIZE)) {
  random_variable = get_random_int()  STACK_RND_MASK;
  random_variable = PAGE_SHIFT;
  }
  return PAGE_ALIGN(stack_top) + random_variable;
  return PAGE_ALIGN(stack_top) - random_variable;
}

Note that, it declares the random_variable variable as unsigned int. Since
the result of the shifting operation between STACK_RND_MASK (which is
0x3f on x86_64, 22 bits) and PAGE_SHIFT (which is 12 on x86_64):

random_variable = PAGE_SHIFT;

then the two leftmost bits are dropped when storing the result in the
random_variable. This variable shall be at least 34 bits long to hold the
(22+12) result.

These two dropped bits have an impact on the entropy of process stack.
Concretely, the total stack entropy is reduced by four: from 2^28 to 2^30 (One
fourth of expected entropy).

This patch restores back the entropy by correcting the types involved in the
operations in the functions randomize_stack_top() and stack_maxrandom_size().

The successful fix can be tested with:
$ for i in `seq 1 10`; do cat /proc/self/maps | grep stack; done
7ffeda566000-7ffeda587000 rw-p  00:00 0  [stack]
7fff5a332000-7fff5a353000 rw-p  00:00 0  [stack]
7ffcdb7a1000-7ffcdb7c2000 rw-p  00:00 0  [stack]
7ffd5e2c4000-7ffd5e2e5000 rw-p  00:00 0  [stack]
...

Once corrected, the leading bytes should be between 7ffc and 7fff, rather
than always being 7fff.

CVE-2015-1593


Awesome.  So the vdso randomization *and* the stack randomization 
implementations were buggy.  Anyone want to check the mmap and brk 
randomization implementations?


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

Re: [PATCH 02/11] ARM: sunxi: always select RESET_CONTROLLER

2015-02-16 Thread Arnd Bergmann

On Friday 13 February 2015 10:09:19 Maxime Ripard wrote:
 Hi Arnd,
 
 On Thu, Feb 12, 2015 at 08:42:34PM +0100, Arnd Bergmann wrote:
  A lot of drivers for mach-sunxi depend on RESET_CONTROLLER. While
  this is selected for the drivers that have it, we keep running
  into build errors in drivers that are used on both the SoCs with
  and without a reset controller.
  
  This patch moves the select statements into the common sunxi
  Kconfig option, which solves multiple such problems.
  
  Signed-off-by: Arnd Bergmann a...@arndb.de
  Cc: Maxime Ripard maxime.rip...@free-electrons.com
 
 Chen-Yu already submitted the exact same patch a few days ago:
 http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/322806.html
 
 I was waiting for -rc1 to merge it, but I guess your way would work
 too.

It's not urgent, and since he came first, let's use that patch.

Feel free to add my 'Acked-by: Arnd Bergmann a...@arndb.de' if you
haven't already applied it.

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

Re: [PATCH v3 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining

2015-02-16 Thread Maxime Ripard

Hi Robert,

On Mon, Feb 16, 2015 at 09:11:24PM +0100, Robert Jarzmik wrote:
 Maxime Ripard maxime.rip...@free-electrons.com writes:
 
   drivers/mtd/nand/pxa3xx_nand.c | 47 
  --
   1 file changed, 41 insertions(+), 6 deletions(-)
 
  diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
  index 96b0b1d27df1..b2d8d6960765 100644
  --- a/drivers/mtd/nand/pxa3xx_nand.c
  +++ b/drivers/mtd/nand/pxa3xx_nand.c
  @@ -480,6 +480,41 @@ static void disable_int(struct pxa3xx_nand_info *info, 
  uint32_t int_mask)
  nand_writel(info, NDCR, ndcr | int_mask);
   }
   
  +static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
  +{
  +   if (info-ecc_bch) {
  +   int index = 0;
  +
  +   while (index  (len * 4)) {
  +   u32 timeout;
  +
  +   __raw_readsl(info-mmio_base + NDDB, data + index, 8);
  +
  +   /*
  +* According to the datasheet, when reading
  +* from NDDB with BCH enabled, after each 32
  +* bytes reads, we have to make sure that the
  +* NDSR.RDDREQ bit is set
  +*/
  +   for (timeout = 0;
  +!(nand_readl(info, NDSR)  NDSR_RDDREQ);
  +timeout++) {
  +   if (timeout = 5) {
  +   dev_err(info-pdev-dev,
  +   Timeout on RDDREQ while 
  draining the FIFO\n);
  +   return;
  +   }
  +
  +   mdelay(1);
 So in worst case, we'll end up with 4 times mdelay(1) times len / 32.
 For a 2048 page, it is : 256ms where everything is stuck (mdelay and not
 msleep).
 
 I know you had no choice because this is called from interrupt handler (top
 half). But having a irq handler and a irq thread handler would solve that 
 issue,
 and you'll end up with msleep(1) in this code.
 
 I don't think an mdelay(256) is acceptable.

That's very true that this driver would need some love, but
valentine's day was last week.

I'm sorry, but this is a patch targeted for stable. This is a pure
bugfix. I won't rewrite the whole driver solely to make the driver
better, especially since that would make such a patch (or more likely
a whole serie) unsuitable for stable.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH] Clear timestamp kfifo on trigger enabling


 The timestamp kfifo must be cleared once the
 hardware fifo is reset, thus are removed
 timestamps related to unprocessed events from
 hardware fifo - see inv_mpu6050_read_fifo
 method implementation.

comments below
a prefix iio: in the subject would be nice 
 
 Signed-off-by: Viorel Suman viorel.su...@gmail.com
 ---
  drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 28 
 +++
  1 file changed, 16 insertions(+), 12 deletions(-)
 
 diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c 
 b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
 index 926fcce..b617920 100644
 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
 +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
 @@ -42,57 +42,61 @@ static void inv_scan_query(struct iio_dev *indio_dev)
  static int inv_mpu6050_set_enable(struct iio_dev *indio_dev, bool enable)
  {
   struct inv_mpu6050_state *st = iio_priv(indio_dev);
 - int result;
 + int result = 0;

no need to init result

the mutex could be obtained in the caller, i.e. 
inv_mpu_data_rdy_trigger_set_state(), simplifying the code and drastically 
reducing the size of this patch

the patch description does not explain a mutex is (now?) needed; probably 
this should be split out as a separate patch

  
 + mutex_lock(indio_dev-mlock);
   if (enable) {
   result = inv_mpu6050_set_power_itg(st, true);
   if (result)
 - return result;
 + goto write_error;
   inv_scan_query(indio_dev);
   if (st-chip_config.gyro_fifo_enable) {
   result = inv_mpu6050_switch_engine(st, true,
   INV_MPU6050_BIT_PWR_GYRO_STBY);
   if (result)
 - return result;
 + goto write_error;
   }
   if (st-chip_config.accl_fifo_enable) {
   result = inv_mpu6050_switch_engine(st, true,
   INV_MPU6050_BIT_PWR_ACCL_STBY);
   if (result)
 - return result;
 + goto write_error;
   }
 + inv_clear_kfifo(st);
   result = inv_reset_fifo(indio_dev);
   if (result)
 - return result;
 + goto write_error;
   } else {
   result = inv_mpu6050_write_reg(st, st-reg-fifo_en, 0);
   if (result)
 - return result;
 + goto write_error;
  
   result = inv_mpu6050_write_reg(st, st-reg-int_enable, 0);
   if (result)
 - return result;
 + goto write_error;
  
   result = inv_mpu6050_write_reg(st, st-reg-user_ctrl, 0);
   if (result)
 - return result;
 + goto write_error;
  
   result = inv_mpu6050_switch_engine(st, false,
   INV_MPU6050_BIT_PWR_GYRO_STBY);
   if (result)
 - return result;
 + goto write_error;
  
   result = inv_mpu6050_switch_engine(st, false,
   INV_MPU6050_BIT_PWR_ACCL_STBY);
   if (result)
 - return result;
 + goto write_error;
   result = inv_mpu6050_set_power_itg(st, false);
   if (result)
 - return result;
 + goto write_error;
   }
   st-chip_config.enable = enable;
 +write_error:
 + mutex_unlock(indio_dev-mlock);
  
 - return 0;
 + return result;
  }
  
  /**
 

-- 

Peter Meerwald
+43-664-218 (mobile)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] audit.c : Code clean up

2015-02-16 Thread Ameen Ali

Fixed a coding style issue (unnecessary parentheses , unnecessary braces)

Signed-off-by: Ameen-Ali ameenali...@gmail.com
---
 kernel/audit.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 72ab759..0607e12 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -663,7 +663,7 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 
msg_type)
case AUDIT_MAKE_EQUIV:
/* Only support auditd and auditctl in initial pid namespace
 * for now. */
-   if ((task_active_pid_ns(current) != init_pid_ns))
+   if (task_active_pid_ns(current) != init_pid_ns)
return -EPERM;
 
if (!netlink_capable(skb, CAP_AUDIT_CONTROL))
@@ -1759,7 +1759,7 @@ void audit_log_name(struct audit_context *context, struct 
audit_names *n,
} else
audit_log_format(ab,  name=(null));
 
-   if (n-ino != (unsigned long)-1) {
+   if (n-ino != (unsigned long)-1)
audit_log_format(ab,  inode=%lu
  dev=%02x:%02x mode=%#ho
  ouid=%u ogid=%u rdev=%02x:%02x,
@@ -1771,7 +1771,6 @@ void audit_log_name(struct audit_context *context, struct 
audit_names *n,
 from_kgid(init_user_ns, n-gid),
 MAJOR(n-rdev),
 MINOR(n-rdev));
-   }
if (n-osid != 0) {
char *ctx = NULL;
u32 len;
-- 
2.1.0

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

Re: mmc: Driver Strength Device Property

2015-02-16 Thread Adrian Hunter

On 16/02/2015 7:47 p.m., Philip Rakity wrote:

On Feb 16, 2015, at 5:39 PM, Arend van Spriel ar...@broadcom.com wrote:

On 02/16/15 15:25, Adrian Hunter wrote:

I am in the process of adding an ACPI Device Property to specify
the driver strength (aka drive strength, driver type) for use
with eMMC/SD/SDIO cards, however the ACPI Specification Workgroup
requires that Device Properties be sufficiently generic. This
raises several questions as to what is sufficiently generic. That
is covered in a Questions section below and is followed by a draft
ACPI Device Property Definition. Any comments would be greatly
appreciated.

First some background:

What are ACPI Device Properties and how do they relate to Device Tree
-

ACPI Device Properties are key / value pairs that can be recorded
in the ACPI DSDT using a _DSD object with a specific UUID. Refer:
The ACPI specification and

http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf

Linux provides a common API to read ACPI Device Properties and
Device Tree properties. Refer:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/base/property.c
http://marc.info/?l=linux-kernelm=141354745011569w=4

Obviously, the common API only works when the same property name
is not defined differently for the same device or class
of devices.

What is Driver Strength
---

Both the JEDEC eMMC Specification and the SD Association Physical
Layer Specification define Driver Strength. The specifications
also use the terms Drive Strength and Driver Type for the same
thing. While the specifications deal with cards, the Host
Controller can also have a Driver Strength value, for example as
specified in the SD Host Controller Specification.

For eMMC, Driver Strength is an optional setting for the HS200 and
HS400 transfer modes.

Currently JEDEC defines:

Value Nominal Impedance Approx. capability
relative to type 0

0 50 ohm x1
1 33 ohm x1.5
2 66 ohm x0.75
3 100 ohm x0.5
4 40 ohm x1.2

For SD/SDIO, Driver Strength is an optional setting for the
UHS-I transfer modes.

The SD Association defines:

Driver Value Nominal Impedance Approx. capability
Typerelative to type 0

A 1 33 ohm x1.5
B 0 50 ohm x1
C 2 66 ohm x0.75
D 3 100 ohm x0.5

So the values are the same with the exception that eMMCs have the
additional value 4 (40 ohm). It is assumed that the values will
anyway not conflict because eMMC is not removable.

The specifications state that support for Driver Strength 0
(Driver Type B) is both mandatory and the default value.
In addition, cards supply a mask of supported Driver Strength
values. Therefore the Driver Strength value is validated against
the supported values.

Questions
-

Question 1. Should there be separate Driver Strength values for
cards and host controllers?

There is no indication from the specifications that cards and
host controllers need have the same value for Driver Strength.
That suggests that separate properties for the card and host
controller should be provided for.

Originally, I was just proposing driver-strength for the
Driver Strength of the card, but now will separate this into
card-driver-strength and host-driver-strength.

Hi Adrian,

I am not sure if it makes sense to have a 'card-driver-strength'
specification for the host controller. I have been under the
impression that the proper value for this is strongly depending
on the card used in the slot. For this reason and the fact that
it is programmed in our device we added brcm,drive-strength
property in our device-tree bindings [1].

So brcm,drive-strength is drive strength used for SDIO pins on device in mA
(default = 6) and it is written to a brcm register rather than the SDIO
CCCR Driver Strength register. So it is not in conflict, but an example of
a hardware-specific way of doing things.

I agree when you have a brcm value to write to a brcm register, it makes
sense to bind it to the brcm device.

One problem with having the standard property bind to the card is that
removable cards are not usually represented.

Regards,
Arend

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt

Adrian, Arend,

My experience is that the value also depends very much on the board design as
well as the

Re: [PATCH 1/3] sched: add sched_task_call()

2015-02-16 Thread Josh Poimboeuf

On Mon, Feb 16, 2015 at 09:44:36PM +0100, Peter Zijlstra wrote:
 On Mon, Feb 16, 2015 at 12:52:34PM -0600, Josh Poimboeuf wrote:
  +++ b/kernel/sched/core.c
  @@ -1338,6 +1338,23 @@ void kick_process(struct task_struct *p)
   EXPORT_SYMBOL_GPL(kick_process);
   #endif /* CONFIG_SMP */
   
  +/***
  + * sched_task_call - call a function with a task's state locked
  + *
  + * The task is guaranteed to remain either active or inactive during the
  + * function call.
  + */
  +void sched_task_call(sched_task_call_func_t func, struct task_struct *p,
  +void *data)
  +{
  +   unsigned long flags;
  +   struct rq *rq;
  +
  +   rq = task_rq_lock(p, flags);
  +   func(p, data);
  +   task_rq_unlock(rq, p, flags);
  +}
 
 Yeah, I think not. We're so not going to allow running random code under
 rq-lock and p-pi_lock.

Yeah, I can understand that.  I definitely want to avoid touching the
scheduler code.  Basically I'm trying to find a way to atomically do the
following:

if (task is sleeping) {
walk the stack
if (certain set of functions isn't on the stack)
set (or clear) a thread flag for the task
}

Any ideas on how I can achieve that?  So far my ideas are:

1. Use task_rq_lock() -- but rq_lock is internal to sched code.

2. Use wait_task_inactive() -- I could call it twice, with the stack
   checking in between, and use ncsw to ensure that it didn't reschedule
   in the mean time.  But this still seems racy.  i.e., I think the task
   could start running after the second call to wait_task_inactive()
   returns but before setting the thread flag.  Not sure if that's a
   realistic race condition or not.

3. Use set_cpus_allowed() to temporarily pin the task to its current
   CPU, and then call smp_call_function_single() to run the above
   critical section on that CPU.  I'm not sure if there's a race-free
   way to do it but it's a lot more disruptive than I'd like...

Any ideas or guidance would be greatly appreciated!

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

Re: [PATCH 1/3] sched: add sched_task_call()

2015-02-16 Thread Peter Zijlstra

On Mon, Feb 16, 2015 at 12:52:34PM -0600, Josh Poimboeuf wrote:
 +++ b/kernel/sched/core.c
 @@ -1338,6 +1338,23 @@ void kick_process(struct task_struct *p)
  EXPORT_SYMBOL_GPL(kick_process);
  #endif /* CONFIG_SMP */
  
 +/***
 + * sched_task_call - call a function with a task's state locked
 + *
 + * The task is guaranteed to remain either active or inactive during the
 + * function call.
 + */
 +void sched_task_call(sched_task_call_func_t func, struct task_struct *p,
 +  void *data)
 +{
 + unsigned long flags;
 + struct rq *rq;
 +
 + rq = task_rq_lock(p, flags);
 + func(p, data);
 + task_rq_unlock(rq, p, flags);
 +}

Yeah, I think not. We're so not going to allow running random code under
rq-lock and p-pi_lock.

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

[PATCH 05/45] drm.h: include stdlib.h in userspace

Fixes drm/drm.h compilation error:

drm/drm.h:132:2: error: unknown type name ‘size_t’

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/drm/drm.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b0b8556..8f4488f 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -42,6 +42,10 @@
 #include asm/ioctl.h
 typedef unsigned int drm_handle_t;
 
+#ifndef __KERNEL__
+#include stdlib.h
+#endif
+
 #else /* One of the BSDs */
 
 #include sys/ioccom.h
-- 
2.1.4

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

[PATCH 01/45] Makefile: propagate verbose options

Usefull when debugging the make scripts.

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 4e93284..c1b515d 100644
--- a/Makefile
+++ b/Makefile
@@ -912,13 +912,13 @@ quiet_cmd_link-vmlinux = LINK$@
 # execute if the rest of the kernel build went well.
 vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORCE
 ifdef CONFIG_HEADERS_CHECK
-   $(Q)$(MAKE) -f $(srctree)/Makefile headers_check
+   $(Q)$(MAKE) V=$(KBUILD_VERBOSE) -f $(srctree)/Makefile headers_check
 endif
 ifdef CONFIG_SAMPLES
-   $(Q)$(MAKE) $(build)=samples
+   $(Q)$(MAKE) V=$(KBUILD_VERBOSE) $(build)=samples
 endif
 ifdef CONFIG_BUILD_DOCSRC
-   $(Q)$(MAKE) $(build)=Documentation
+   $(Q)$(MAKE) V=$(KBUILD_VERBOSE) $(build)=Documentation
 endif
+$(call if_changed,link-vmlinux)
 
@@ -1069,7 +1069,7 @@ headers_check_all: headers_install_all
 PHONY += headers_check
 headers_check: headers_install
$(Q)$(MAKE) $(hdr-inst)=include/uapi HDRCHECK=1
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) 
HDRCHECK=1
+   $(Q)$(MAKE) V=$(KBUILD_VERBOSE) 
$(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) HDRCHECK=1
 
 # ---
 # Kernel selftest
-- 
2.1.4

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

Re: linux-next: Tree for Feb 16

2015-02-16 Thread Guenter Roeck


On 02/16/2015 12:36 PM, Stephen Rothwell wrote:

Hi Guenter,

On Mon, 16 Feb 2015 09:12:13 -0800 Guenter Roeck li...@roeck-us.net wrote:


On Thu, Feb 16, 2012 at 04:41:44PM +1100, Stephen Rothwell wrote:


Changes since 20120215:

---
[ Trying again, this time hopefully replying to the correct e-mail.
   Sorry for the earlier noise. ]


Did you really mean to reply to a release from 3 years ago?



Sigh. No, of course not :-(. I think I am giving up for today.

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: audit.c patch

2015-02-16 Thread Paul Moore

On Mon, Feb 16, 2015 at 4:07 PM, Ameen Ali ameenali...@gmail.com wrote:
 the following attachment which fix kernel code style issues

Please read Documentation/SubmittingPatches in the kernel sources for
information on how to properly format and submit patches for
consideration.  Posting patches inline, and not as an attachment, is
very important.

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

Re: [PATCH 3/8] x86, fpu: kill save_init_fpu(), change math_error() to use unlazy_fpu()

2015-02-16 Thread Borislav Petkov

On Fri, Feb 06, 2015 at 03:02:00PM -0500, r...@redhat.com wrote:
 From: Oleg Nesterov o...@redhat.com
 
 math_error() calls save_init_fpu() after conditional_sti(), this means
 that the caller can be preempted. If !use_eager_fpu() we can hit the
 WARN_ON_ONCE(!__thread_has_fpu(tsk)) and/or save the wrong FPU state.
 
 Change math_error() to use unlazy_fpu() and kill save_init_fpu().
 
 Signed-off-by: Oleg Nesterov o...@redhat.com
 Signed-off-by: Rik van Riel r...@redhat.com
 ---
  arch/x86/include/asm/fpu-internal.h | 18 --
  arch/x86/kernel/traps.c |  2 +-
  2 files changed, 1 insertion(+), 19 deletions(-)
 
 diff --git a/arch/x86/include/asm/fpu-internal.h 
 b/arch/x86/include/asm/fpu-internal.h
 index 0dbc08282291..27d00e04f911 100644
 --- a/arch/x86/include/asm/fpu-internal.h
 +++ b/arch/x86/include/asm/fpu-internal.h
 @@ -520,24 +520,6 @@ static inline void __save_fpu(struct task_struct *tsk)
  }
  
  /*
 - * These disable preemption on their own and are safe
 - */
 -static inline void save_init_fpu(struct task_struct *tsk)
 -{
 - WARN_ON_ONCE(!__thread_has_fpu(tsk));
 -
 - if (use_eager_fpu()) {
 - __save_fpu(tsk);
 - return;
 - }
 -
 - preempt_disable();
 - __save_init_fpu(tsk);
 - __thread_fpu_end(tsk);
 - preempt_enable();
 -}
 -
 -/*
   * i387 state interaction
   */
  static inline unsigned short get_fpu_cwd(struct task_struct *tsk)
 diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
 index fb4cb6adf225..51c465846f06 100644
 --- a/arch/x86/kernel/traps.c
 +++ b/arch/x86/kernel/traps.c
 @@ -663,7 +663,7 @@ static void math_error(struct pt_regs *regs, int 
 error_code, int trapnr)
   /*
* Save the info for the exception handler and clear the error.
*/
 - save_init_fpu(task);
 + unlazy_fpu(task);

Do I see it correctly that even with this there's a not-so-small hole
*after* conditional_sti() and *before* unlazy_fpu() where caller can
still get preempted?

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression bug in drm/i915, Wrong assumption in commit e11aa36 breaks suspend on at least lenovo x61

2015-02-16 Thread Dave Airlie

ccing some ppl.


On 17 February 2015 at 08:11, Klaus Ethgen klaus+l...@ethgen.de wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 After three days of bisect I found the bug for my problem with a broken
 suspend on x61p of lenovo.

 The problem is commit e11aa36. It seems to be a wrong assumption that
 disabling the interrupts is enough.

 I'll try to revert the commit on top of 3.18.7. (It does not clean
 revert.)

 Regards
Klaus
 - --
 Klaus Ethgen  http://www.ethgen.ch/
 pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen kl...@ethgen.de
 Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQGcBAEBCgAGBQJU4mseAAoJEKZ8CrGAGfas9skMAIeYCOSbbA2kQbC0AQT17y5L
 TUayHwW/4pDYxIOqS8cuCkiSGxokiemBYDdLgtVzPCp90suhB0ZhZY0o1VolwQTP
 CHTqYAGTNarq7c9gXWmpCGlpYyPzce38rlDMzu4fQwOqegziO3TBrAm7m5rwv/mK
 cBtPK4anx6qrXjUrttn8LEt0Qlr5n+HIKVBrbZcPLuLJmxA1KclY742V53Z2uEuz
 CozDMjKrVhAKG3ehRxXhpcWQRRNOplKH7cY74yWLA3eepQg82CjEcM5mP7cZWDPT
 Hv+B1H6wZ38STtKctiXUUukCphaT0AU97saCr7k4xkY/6gM+BNCZNQnQAOGzW0J3
 ybhTT/oZVxY2qPo/hk3x/XGoAkdQq/7axYEYRN/urocklLUcy2Dlc2kuN8K6QRqk
 VY4USl6U3c4mbK3bOB35oPPqrqFzFgbntJ7VHaIRip5VUjEsrHYox5lKFQJOt2Rg
 fHLyD423SuXE5pCQxWiXl+Hq5MC7n80N132SQSxa4Q==
 =9G0k
 -END PGP SIGNATURE-
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mmc: Driver Strength Device Property

2015-02-16 Thread Arend van Spriel

On 02/16/15 22:47, Adrian Hunter wrote:

On 16/02/2015 7:47 p.m., Philip Rakity wrote:

On Feb 16, 2015, at 5:39 PM, Arend van Spriel ar...@broadcom.com wrote:

On 02/16/15 15:25, Adrian Hunter wrote:

First some background:

What are ACPI Device Properties and how do they relate to Device Tree
-

ACPI Device Properties are key / value pairs that can be recorded
in the ACPI DSDT using a _DSD object with a specific UUID. Refer:
The ACPI specification and
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf

http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf

Linux provides a common API to read ACPI Device Properties and
Device Tree properties. Refer:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/base/property.c

http://marc.info/?l=linux-kernelm=141354745011569w=4

Obviously, the common API only works when the same property name
is not defined differently for the same device or class
of devices.

What is Driver Strength
---

For eMMC, Driver Strength is an optional setting for the HS200 and
HS400 transfer modes.

Currently JEDEC defines:

Value Nominal Impedance Approx. capability
relative to type 0

0 50 ohm x1
1 33 ohm x1.5
2 66 ohm x0.75
3 100 ohm x0.5
4 40 ohm x1.2

For SD/SDIO, Driver Strength is an optional setting for the
UHS-I transfer modes.

The SD Association defines:

Driver Value Nominal Impedance Approx. capability
Type relative to type 0

A 1 33 ohm x1.5
B 0 50 ohm x1
C 2 66 ohm x0.75
D 3 100 ohm x0.5

So the values are the same with the exception that eMMCs have the
additional value 4 (40 ohm). It is assumed that the values will
anyway not conflict because eMMC is not removable.

Questions
-

Question 1. Should there be separate Driver Strength values for
cards and host controllers?

Originally, I was just proposing driver-strength for the
Driver Strength of the card, but now will separate this into
card-driver-strength and host-driver-strength.

Hi Adrian,

So brcm,drive-strength is drive strength used for SDIO pins on device
in mA
(default = 6) and it is written to a brcm register rather than the SDIO
CCCR Driver Strength register. So it is not in conflict, but an example of
a hardware-specific way of doing things.

I agree when you have a brcm value to write to a brcm register, it makes
sense to bind it to the brcm device.

Glad to hear. I guess I was wondering how the card-driver-strength
property would be used and by what entity, but that is not directly
relevant for having a definition for it in ACPI/devicetree.

Regards,
Arend

One problem with having the standard property bind to the card is that
removable cards are not usually represented.

Regards,
Arend

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt

Adrian, Arend,

My experience is that the value also depends very much on the board
design as well as the eMMC/sdio chip being used. eMMC chips have
some variation. A DT entry does make sense for eMMC and other wired in
devices but in this case the value is a property of the hardware
and burnt in as a property of the board design.

So it sounds like binding to

Re: [GIT PULL] perf x86 updates for v3.20

2015-02-16 Thread Andy Lutomirski


On 02/15/2015 11:48 PM, Ingo Molnar wrote:

Linus,

Please pull the latest perf-core-for-linus git tree from:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
perf-core-for-linus

# HEAD: a66734297f78707ce39d756b656bfae861d53f62 perf/x86: Add 
/sys/devices/cpu/rdpmc=2 to allow rdpmc for all tasks


[...]


The extra CR4 manipulation adds ~ 50ns to the context
switch cost between rdpmc-capable and rdpmc-non-capable
mms.


That's about the best I could benchmark, too -- if it was more than 
about 50ns, I'm pretty sure I wouldn't seen a difference, but, as it 
stands, it seems to have been lost in the noise.  Maybe I should find a 
better benchmark.


In any event, this series is probably a mixed bag performance-wise.  In 
the best base, there's a small extra cost in context switches, and, when 
switching PCE, there's a CR4 write.  On SVM guests, the CR4 write will suck.


To balance that out, I removed a CR4 read from VMX entry and from global 
TLB flushes.  The former mostly fixes a performance regression from a 
security fix a few releases back, and the I expect that the latter will 
more than offset the added context switch overhead (especially on SVM 
guests, where even CR4 reads exit AFAIK).


Anyway, I tried and failed to detect any difference at all.  Context 
switch timing was very noisy for me.


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

Re: [PATCH v3 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining

2015-02-16 Thread Robert Jarzmik

Maxime Ripard maxime.rip...@free-electrons.com writes:

 I don't think an mdelay(256) is acceptable.

 That's very true that this driver would need some love, but
 valentine's day was last week.
That doesn't cope with the 256ms mdelay. And a potential big mdelay is not what
I'd call a bug fix, see below.

 I'm sorry, but this is a patch targeted for stable. This is a pure
 bugfix. I won't rewrite the whole driver solely to make the driver
 better, especially since that would make such a patch (or more likely
 a whole serie) unsuitable for stable.

This is the rewrite I was asking for (not tested), consider it against your
rewrite the whole driver :

Modified   drivers/mtd/nand/pxa3xx_nand.c
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index e512902..6e569e9 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -576,11 +576,20 @@ static void start_data_dma(struct pxa3xx_nand_info *info)
 {}
 #endif
 
+static irqreturn_t pxa3xx_nand_irq_thread(int irq, void *data)
+{
+   struct pxa3xx_nand_info *info = data;
+
+   handle_data_pio(info);
+   return IRQ_HANDLED;
+}
+
 static irqreturn_t pxa3xx_nand_irq(int irq, void *devid)
 {
struct pxa3xx_nand_info *info = devid;
unsigned int status, is_completed = 0, is_ready = 0;
unsigned int ready, cmd_done;
+   irqreturn_t ret = IRQ_HANDLED;
 
if (info-cs == 0) {
ready   = NDSR_FLASH_RDY;
@@ -622,7 +631,7 @@ static irqreturn_t pxa3xx_nand_irq(int irq, void *devid)
} else {
info-state = (status  NDSR_RDDREQ) ?
  STATE_PIO_READING : STATE_PIO_WRITING;
-   handle_data_pio(info);
+   ret = IRQ_WAKE_THREAD;
}
}
if (status  cmd_done) {
@@ -663,7 +672,7 @@ static irqreturn_t pxa3xx_nand_irq(int irq, void *devid)
if (is_ready)
complete(info-dev_ready);
 NORMAL_IRQ_EXIT:
-   return IRQ_HANDLED;
+   return ret;
 }
 
 static inline int is_buf_blank(uint8_t *buf, size_t len)
@@ -1688,7 +1697,8 @@ static int alloc_nand_resource(struct platform_device 
*pdev)
/* initialize all interrupts to be disabled */
disable_int(info, NDSR_MASK);
 
-   ret = request_irq(irq, pxa3xx_nand_irq, 0, pdev-name, info);
+   ret = request_threaded_irq(irq, pxa3xx_nand_irq,
+  pxa3xx_nand_irq_thread, 0, pdev-name, info);
if (ret  0) {
dev_err(pdev-dev, failed to request IRQ\n);
goto fail_free_buf;

--
Robert

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 RFC v02 00/45] Compile test and fixes for exported header files

v2:
added cross compiler support with CROSS_COMPILE,
detecting libc and GCC headers from compiler,
more header file fixes

v1:
https://lkml.org/lkml/2014/8/21/665

Users of kernel header files would be happier if they did not contain
kernel specific parts and would contain #include statements for all
other header files that they depend on, and in general would compile.

This patch set fixes some headers_install issues, then introduces a
compile test for headers exported to userspace and then fixes many of the
userspace header compilation failures.

Changes are also available in headers_test_v02 branch at github:
https://github.com/mcfrisk/linux/tree/headers_test_v02

Mikko Rapeli (45):
  Makefile: propagate verbose options
  scripts/headers.sh: add verbose option to make calls if defined
  headers_install.sh: enhance error handling
  scripts/headers_compile_test.sh: compile test script for exported
headers
  drm.h: include stdlib.h in userspace
  drm_mode.h: include stdint.h and linux/types.h in userspace
  exynos_drm.h: include stdint.h in userspace
  nouveau_drm.h: include stdint.h in userspace
  radeon_drm.h: include stdint.h in userspace
  r128_drm.h: include drm/drm.h
  via_drm.h: include linux/types.h instead of non-existing
via_drmclient.h
  via_drm.h: hide struct via_file_private in userspace
  savage_drm.h: include drm/drm.h
  sis_drm.h: hide sis_file_private in userspace
  dm-log-userspace.h: include stdint.h in userspace
  hsi_char.h: include stdint.h in userspace
  ebtables.h: include stdint.h in userspace
  cld.h: include stdint.h in userspace
  rds.h: include stdint.h in userspace
  sctp.h: include stdint.h in userspace
  scsi_bsg_fc.h: include stdint.h in userspace
  scsi_netlink.h: include stdint.h in userspace
  scsi_netlink_fc.h: include stdint.h in userspace
  hdspm.h: include stdint.h in userspace
  gntalloc.h: include stdint.h in userspace
  gntdev.h: include stdint.h in userspace
  include/uapi/linux/sysctl.h: include stdlib.h in userspace
  include/uapi/asm-generic/ipcbuf.h: include linux/posix_types.h
  include/uapi/asm-generic/msgbuf.h: include asm/ipcbuf.h
  include/uapi/asm-generic/shmbuf.h: include fixes
  asm-generic/sembuf.h: include asm/posix_types.h and asm/ipcbuf.h
  drm/i810_drm.h: include drm/drm.h
  include/uapi/asm-generic/signal.h: include stdlib.h in userspace
  include/uapi/asm-generic/signal.h: hide sigset_t definition in
userspace
  include/uapi/sound/asound.h: include stdlib.h in userspace
  include/uapi/linux/netfilter.h: include in.h and in6.h
  include/uapi/linux/socket.h: include sys/socket.h in userspace
  include/uapi/linux/agpgart.h: include stdlib.h in userspace
  include/uapi/sound/asequencer.h: include sound/asound.h
  include/uapi/sound/emu10k1.h: include sound/asound.h
  include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and
code_valid in userspace
  include/uapi/linux/rds.h: include linux/socket.h and linux/types.h
always
  include/uapi/linux/netfilter_bridge.h: include if.h
  nf_conntrack_tuple_common.h: include linux/types.h and
linux/netfilter.h
  include/uapi/asm-generic/ucontext.h: include signal.h and sigcontext.h

 Makefile   |   8 +-
 include/uapi/asm-generic/ipcbuf.h  |   2 +
 include/uapi/asm-generic/msgbuf.h  |   2 +
 include/uapi/asm-generic/sembuf.h  |   2 +
 include/uapi/asm-generic/shmbuf.h  |   6 +
 include/uapi/asm-generic/signal.h  |   7 +
 include/uapi/asm-generic/ucontext.h|   3 +
 include/uapi/drm/drm.h |   4 +
 include/uapi/drm/drm_mode.h|   5 +
 include/uapi/drm/exynos_drm.h  |   5 +
 include/uapi/drm/i810_drm.h|   2 +
 include/uapi/drm/nouveau_drm.h |   6 +
 include/uapi/drm/r128_drm.h|   2 +
 include/uapi/drm/radeon_drm.h  |   5 +
 include/uapi/drm/savage_drm.h  |   2 +
 include/uapi/drm/sis_drm.h |   2 +
 include/uapi/drm/via_drm.h |   6 +-
 include/uapi/linux/agpgart.h   |   1 +
 include/uapi/linux/dm-log-userspace.h  |   5 +
 include/uapi/linux/hsi/hsi_char.h  |   7 +-
 include/uapi/linux/netfilter.h |   3 +-
 .../linux/netfilter/nf_conntrack_tuple_common.h|   3 +
 include/uapi/linux/netfilter_bridge.h  |   1 +
 include/uapi/linux/netfilter_bridge/ebtables.h |   5 +
 include/uapi/linux/nfsd/cld.h  |   6 +
 include/uapi/linux/rds.h   |   4 +
 include/uapi/linux/sctp.h  |   4 +
 include/uapi/linux/socket.h|   4 +
 include/uapi/linux/sysctl.h|   4 +
 include/uapi/scsi/scsi_bsg_fc.h|   6 +

[PATCH 07/45] exynos_drm.h: include stdint.h in userspace

Fixes compilation errors like:

drm/exynos_drm.h:30:2: error: unknown type name ‘uint64_t’

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/drm/exynos_drm.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index 5575ed1..03d094d 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -15,6 +15,11 @@
 #ifndef _UAPI_EXYNOS_DRM_H_
 #define _UAPI_EXYNOS_DRM_H_
 
+#ifdef __KERNEL__
+#include linux/types.h
+#else
+#include stdint.h
+#endif
 #include drm/drm.h
 
 /**
-- 
2.1.4

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

[PATCH 04/45] scripts/headers_compile_test.sh: compile test script for exported headers

Users of kernel header files would be happier if they did not contain
kernel specific parts and would contain #include statements for all
other header files that they depend on, and in general would compile.

For each header file exported to userspace, this script creates
a simple .c file which just includes the header file. Then it
tries to compile it together with minimal header files from GCC
and libc, and reports results.

Default libc and GCC header file locations are parsed from compiler
configuration.

Kernel headers depend on GCC headers so their path is included in
the test compiler command line.

Some gcc and kernel headers depend on libc headers which are made available
by copying from the compiler default location to a temporary location and
removing possibly existing kernel headers from this directory. This is a bit
of a hack but seems to work in multiple environments.

Tested natively on:

Debian unstable, i586-linux-gnu and gcc 4.9.2
Raspbian Wheezy, arm-linux-gnueabihf and gcc 4.6.3
Ubuntu 12.04 LTS, x86_64-linux-gnu and gcc 4.6.3

Tested cross compilation using standard CROSS_COMPILE=/path/to/gcc with:

arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 
4.9-2014.09) 4.9.2 20140904 (prerelease)

Execute the script in the directory where kernel header files are installed.
For example:

$ make headers_install
$ cd usr/include
$ ../../scripts/headers_compile_test.sh

Example statistics from 3.18.4 kernel:

130 files failed the compile test.
609 files passed the compile test.

Example error types from 3.18.4 kernel:

$ ../../scripts/headers_compile_test.sh 21 | \
grep error: | sed -e 's/.*error://g' | sort | uniq -c | sort -rn

352  unknown type name ‘uint32_t’
134  unknown type name ‘uint64_t’
103  unknown type name ‘size_t’
 43  unknown type name ‘__kernel_ulong_t’
 38  unknown type name ‘uint8_t’
 24  unknown type name ‘int32_t’
 22  field ‘addr’ has incomplete type
 18  field ‘tstamp’ has incomplete type
 16  unknown type name ‘__kernel_time_t’
 16  field ‘in’ has incomplete type
 16  field ‘in6’ has incomplete type
 14  unknown type name ‘__be16’
 13  ‘IFNAMSIZ’ undeclared here (not in a function)
 12  unknown type name ‘uint16_t’
  9  field ‘ifru_netmask’ has incomplete type
  9  field ‘ifru_hwaddr’ has incomplete type
  9  field ‘ifru_dstaddr’ has incomplete type
  9  field ‘ifru_broadaddr’ has incomplete type
  9  field ‘ifru_addr’ has incomplete type
  8  unknown type name ‘__kernel_pid_t’
  7  unknown type name ‘u_short’
  7  unknown type name ‘pid_t’
  6  invalid application of ‘sizeof’ to incomplete type ‘struct timespec’
  6  field ‘src’ has incomplete type
  6  field ‘audio_tstamp’ has incomplete type
  6  array type has incomplete element type
  5  unknown type name ‘__kernel_long_t’
  5  requested alignment is not an integer constant
  5  field ‘smsk’ has incomplete type
  4  unknown type name ‘__kernel_uid32_t’
  4  unknown type name ‘__kernel_gid32_t’
  4  ‘ETH_ALEN’ undeclared here (not in a function)
  3  unknown type name ‘int64_t’
  3  unknown type name ‘caddr_t’
  3  ‘IPSET_ERR_TYPE_SPECIFIC’ undeclared here (not in a function)
  3  field ‘trigger_tstamp’ has incomplete type
  3  field ‘src_addr’ has incomplete type
  3  field ‘sin_addr’ has incomplete type
  3  field ‘laddr’ has incomplete type
  3  field ‘id’ has incomplete type
  3  field ‘dmsk’ has incomplete type
  3  field ‘bssid’ has incomplete type
  3  expected specifier-qualifier-list before ‘uint64_t’
  2  unknown type name ‘u_long’
  2  unknown type name ‘stack_t’
  2  unknown type name ‘sigset_t’
  2  unknown type name ‘sa_family_t’
  2  unknown type name ‘__kernel_mode_t’
  2  unknown type name ‘__kernel_key_t’
  2  unknown type name ‘elf_gregset_t’
  2  unknown type name ‘bool’
  2  ‘uint64_t’ undeclared here (not in a function)
  2  ‘true’ undeclared (first use in this function)
  2  ‘NAME_MAX’ undeclared here (not in a function)
  2  ‘__kernel_mode_t’ undeclared here (not in a function)
  2  invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr’
  2  field ‘uc_mcontext’ has incomplete type
  2  field ‘tmsk’ has incomplete type
  2  field ‘tgt’ has incomplete type
  2  field ‘shm_perm’ has incomplete type
  2  field ‘sem_perm’ has incomplete type
  2  field ‘raddr’ has incomplete type
  2  field ‘msg_perm’ has incomplete type
  2  field ‘grp’ has incomplete type
  2  field ‘dst’ has incomplete type
  2  field ‘dst_addr’ has incomplete type
  2  field ‘arp_pa’ has incomplete type
  2  field ‘arp_netmask’ has incomplete type
  2  field ‘arp_ha’ has incomplete type
  2  ‘false’ undeclared (first use in this function)
  1  xen/interface/xen.h: No such file or directory
  1

[PATCH 03/45] headers_install.sh: enhance error handling

Exit with error if using undefined variables or if any sub command fails
with error return value. unidef needs special handling since but this can
be done without the trap. Enables exaniming intermediate files if some
commands failed.

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 scripts/headers_install.sh | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh
index fdebd66..072f7d3 100755
--- a/scripts/headers_install.sh
+++ b/scripts/headers_install.sh
@@ -1,4 +1,7 @@
 #!/bin/sh
+set -e
+set -u
+#set -x
 
 if [ $# -lt 2 ]
 then
@@ -26,7 +29,6 @@ shift
 # Iterate through files listed on command line
 
 FILE=
-trap 'rm -f $OUTDIR/$FILE $OUTDIR/$FILE.sed' EXIT
 for i in $@
 do
FILE=$(basename $i)
@@ -37,10 +39,13 @@ do
-e 
's/(^|[^a-zA-Z0-9])__packed([^a-zA-Z0-9_]|$)/\1__attribute__((packed))\2/g' \
-e 's/(^|[ \t(])(inline|asm|volatile)([ \t(]|$)/\1__\2__\3/g' \
-e 's@#(ifndef|define|endif[ \t]*/[*])[ \t]*_UAPI@#\1 @' \
-   $SRCDIR/$i  $OUTDIR/$FILE.sed || exit 1
+   $SRCDIR/$i  $OUTDIR/$FILE.sed || \
+   ( rm -f $OUTDIR/$FILE.sed ; exit 1 )
scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ $OUTDIR/$FILE.sed 
\
-$OUTDIR/$FILE
-   [ $? -gt 1 ]  exit 1
+$OUTDIR/$FILE || \
+   ( if [ $? -gt 1 ]; then \
+   rm -f $OUTDIR/$FILE $OUTDIR/$FILE.sed ; \
+   exit 1 ; \
+ fi )
rm -f $OUTDIR/$FILE.sed
 done
-trap - EXIT
-- 
2.1.4

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

[PATCH 13/45] savage_drm.h: include drm/drm.h

Fixes compiler error:

drm/savage_drm.h:50:24: error: array type has incomplete element type
  struct drm_tex_region texList[SAVAGE_NR_TEX_HEAPS][SAVAGE_NR_TEX_REGIONS +

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/drm/savage_drm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/drm/savage_drm.h b/include/uapi/drm/savage_drm.h
index 818d49b..9dc9dc1 100644
--- a/include/uapi/drm/savage_drm.h
+++ b/include/uapi/drm/savage_drm.h
@@ -26,6 +26,8 @@
 #ifndef __SAVAGE_DRM_H__
 #define __SAVAGE_DRM_H__
 
+#include drm/drm.h
+
 #ifndef __SAVAGE_SAREA_DEFINES__
 #define __SAVAGE_SAREA_DEFINES__
 
-- 
2.1.4

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

[PATCH 17/45] ebtables.h: include stdint.h in userspace

Fixes compilation error:

linux/netfilter_bridge/ebtables.h:38:2: error: unknown type name ‘uint64_t’

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/linux/netfilter_bridge/ebtables.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/netfilter_bridge/ebtables.h 
b/include/uapi/linux/netfilter_bridge/ebtables.h
index ba99336..9e8d6b4 100644
--- a/include/uapi/linux/netfilter_bridge/ebtables.h
+++ b/include/uapi/linux/netfilter_bridge/ebtables.h
@@ -12,6 +12,11 @@
 
 #ifndef _UAPI__LINUX_BRIDGE_EFF_H
 #define _UAPI__LINUX_BRIDGE_EFF_H
+#ifdef __KERNEL__
+#include linux/types.h
+#else
+#include stdint.h
+#endif
 #include linux/if.h
 #include linux/netfilter_bridge.h
 #include linux/if_ether.h
-- 
2.1.4

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

[PATCH 27/45] include/uapi/linux/sysctl.h: include stdlib.h in userspace

Fixes userspace compilation error:

error: unknown type name ‘size_t’

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/linux/sysctl.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 43aaba1..b7b344f 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -26,6 +26,10 @@
 #include linux/types.h
 #include linux/compiler.h
 
+#ifndef __KERNEL__
+#include stdlib.h
+#endif
+
 struct completion;
 
 #define CTL_MAXNAME 10 /* how many path components do we allow in a
-- 
2.1.4

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

[PATCH 14/45] sis_drm.h: hide sis_file_private in userspace

Fixes compiler error:

drm/sis_drm.h:68:19: error: field ‘obj_list’ has incomplete type
  struct list_head obj_list;

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/drm/sis_drm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/drm/sis_drm.h b/include/uapi/drm/sis_drm.h
index df37632..3d0903f 100644
--- a/include/uapi/drm/sis_drm.h
+++ b/include/uapi/drm/sis_drm.h
@@ -64,8 +64,10 @@ typedef struct {
unsigned long offset, size;
 } drm_sis_fb_t;
 
+#ifdef __KERNEL__
 struct sis_file_private {
struct list_head obj_list;
 };
+#endif
 
 #endif /* __SIS_DRM_H__ */
-- 
2.1.4

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

[PATCH 09/45] radeon_drm.h: include stdint.h in userspace

Fixes compiler error:

drm/radeon_drm.h:794:2: error: unknown type name ‘uint64_t’

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/drm/radeon_drm.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 50d0fb4..4d8ed03 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -33,6 +33,11 @@
 #ifndef __RADEON_DRM_H__
 #define __RADEON_DRM_H__
 
+#ifdef __KERNEL__
+#include linux/types.h
+#else
+#include stdint.h
+#endif
 #include drm/drm.h
 
 /* WARNING: If you change any of these defines, make sure to change the
-- 
2.1.4

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

[PATCH 12/45] via_drm.h: hide struct via_file_private in userspace

Fixes compiler error since list_head is not exported to userspace headers.

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/drm/via_drm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/drm/via_drm.h b/include/uapi/drm/via_drm.h
index 791531e..34ce658 100644
--- a/include/uapi/drm/via_drm.h
+++ b/include/uapi/drm/via_drm.h
@@ -272,8 +272,10 @@ typedef struct drm_via_dmablit {
drm_via_blitsync_t sync;
 } drm_via_dmablit_t;
 
+#ifdef __KERNEL__
 struct via_file_private {
struct list_head obj_list;
 };
+#endif
 
 #endif /* _VIA_DRM_H_ */
-- 
2.1.4

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

Re: [PATCH] perf tools: Work around lack of sched_getcpu in glibc 2.6.

2015-02-16 Thread Yann Droneaud

Hi,

Le vendredi 13 février 2015 à 18:06 -0800, Vinson Lee a écrit :
 From: Vinson Lee v...@twitter.com
 
 This patch fixes this build error with glibc  2.6.
 
   CC   util/cloexec.o
 cc1: warnings being treated as errors
 util/cloexec.c: In function ‘perf_flag_probe’:
 util/cloexec.c:24: error: implicit declaration of function
 ‘sched_getcpu’
 util/cloexec.c:24: error: nested extern declaration of ‘sched_getcpu’
 make: *** [util/cloexec.o] Error 1
 
 Cc: sta...@vger.kernel.org # 3.18+
 Signed-off-by: Vinson Lee v...@twitter.com
 ---
  tools/perf/util/cloexec.c | 10 ++
  1 file changed, 10 insertions(+)
 
 diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c
 index 47b78b3..3738924 100644
 --- a/tools/perf/util/cloexec.c
 +++ b/tools/perf/util/cloexec.c
 @@ -7,6 +7,12 @@
  
  static unsigned long flag = PERF_FLAG_FD_CLOEXEC;
  
 +#ifdef __GLIBC_PREREQ
 +#if __GLIBC_PREREQ(2, 6)
 +#define HAVE_SCHED_GETCPU
 +#endif
 +#endif
 +

OK

  static int perf_flag_probe(void)
  {
   /* use 'safest' configuration as used in perf_evsel__fallback() */
 @@ -21,9 +27,13 @@ static int perf_flag_probe(void)
   pid_t pid = -1;
   char sbuf[STRERR_BUFSIZE];
  
 +#ifdef HAVE_SCHED_GETCPU
   cpu = sched_getcpu();
   if (cpu  0)
   cpu = 0;
 +#else
 + cpu = 0;
 +#endif
  
   while (1) {
   /* check cloexec flag */

I've reviewed the use of __GLIBC_PREREQ(2, 6), but not whether using cpu
= 0 is OK if sched_getcpu() is not available.

Reviewed-by: Yann Droneaud ydrone...@opteya.com

Regards.

-- 
Yann Droneaud
OPTEYA



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] ASoC: pcm512x: Add knobs to allow and control overclocking

2015-02-16 Thread Peter Rosin

From: Peter Rosin p...@axentia.se

Hi!

I wasn't sure if I should add Documentation/* for these sysfs knobs
or not? A lot of knobs do not seem to have docs (no specific example,
just a gut feeling). And I'm not sure how I should name the doc-file
since the pcm512x driver handles devices connected with both i2c and
spi. And what KernelVersion should I enter? That depends... So, this
isn't perfect, suggestions welcome.

The first patch is a preparatory patch that makes 2/2 slightly simpler.
I can fold them together if that's desired. Or I could split 2/2 up in
three logical patches, one for each of the independent PLL/DSP/DAC
knobs.

Another feature that one might want, is that attempts to change the
overclocking should fail with EBUSY when the device is already in use.
But I haven't invested enough time to find out how I should determine
when to fail, so for this version the driver accepts the change but
doesn't enforce the new limit until the clock rates are recalculated.

Cheers,
Peter

Peter Rosin (2):
  ASoC: pcm512x: Rearrange to not repeat dacsrc_rate / dac_div
  ASoC: pcm512x: Allow independently overclocking PLL, DAC and DSP

 Documentation/ABI/testing/sysfs-i2c-pcm512x |   35 +
 sound/soc/codecs/pcm512x.c  |  189 ---
 2 files changed, 205 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-i2c-pcm512x

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

Re: RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer)

2015-02-16 Thread Helge Deller


Hello Nicholas,

On 03.02.2015 10:37, Nicholas Mc Guire wrote:

  scanning for  if STATEMENT else STATEMENT  triggered here - and it does look
like it needs a fix-up or at least some comments.

snip?
int hpux_sysfs(int opcode, unsigned long arg1, unsigned long arg2)
{
 int fstype;
 ...
  /* String could be altered by userspace after strlen_user() */
  fsname[len - 1] = '\0';

  printk(KERN_DEBUG that is '%s' as (char *)\n, fsname);
  if ( !strcmp(fsname, hfs) ) {
   fstype = 0;
  } else {
   fstype = 0;
  }

  kfree(fsname);

  printk(KERN_DEBUG returning fstype=%d\n, fstype);
  return fstype; /* something other than default */
snip

  The if-else here has no effect and the printk will not convey any information
as its always fstype==0, finally the return statement comment indicates that it
should not be the default...

  Can't come up with a reasonable cleanup patch here - but this looks like it
needs a review.


The hpux code is broken anyway.
I'm going to remove it from the tree.

Thanks!

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

Re: [PATCH v2 0/4] HID: hid-lg4ff: Improve handling of Logitech multimode gaming wheels

2015-02-16 Thread Elias Vanderstuyft

On Sun, Feb 15, 2015 at 3:03 AM, Michal Malý
madcatxs...@devoid-pointer.net wrote:
 This patch series improves handling of various Logitech gaming wheels and
 allows switching between various compatibility modes which might be useful
 to improve compatibility with very old games and testing purposes.

 Signed-off-by: Michal Malý madcatxs...@devoid-pointer.net

 v2: - Rebased against latest linux-next
 - Document the newly introduced sysfs interfaces in appropriate commits
 - Assume that we are targeting kernel version 4.1
 - Fix a misleading error message regarding unsupported wheel mode

 Michal Malý (4):
   Identify Logitech gaming wheels in compatibility modes accordingly to
 Logitech specifications
   Display the real wheel model and supported alternate modes through
 sysfs. This applies only to multimode wheels.
   Introduce a module parameter to disable automatic switch of Logitech
 gaming wheels from compatibility to native mode. This only applies
 to multimode wheels.
   Allow switching of Logitech gaming wheels between available
 compatibility modes through sysfs. This only applies to multimode
 wheels.

  .../ABI/testing/sysfs-driver-hid-logitech-lg4ff|  45 ++
  drivers/hid/hid-lg.c   |   6 +
  drivers/hid/hid-lg4ff.c| 605 
 ++---
  3 files changed, 580 insertions(+), 76 deletions(-)

 --
 2.3.0


Applied cleanly on kernel 3.18.6, and retested with:
- Logitech Formula Vibration Wheel
- Logitech MOMO (Black) Wheel
Everything keeps working like it was before, which is correct because
these wheels are no multimode wheels.

Tested-by: Elias Vanderstuyft elias@gmail.com

Thanks,
Elias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips

2015-02-16 Thread Matthew Wilcox

On Mon, Feb 16, 2015 at 01:07:07PM +0200, Boaz Harrosh wrote:
 In any way this is a problem for the new type-12 NvDIMM memory chips that
 are circulating around. (It is estimated that there are already 100ds of
 thousands NvDIMM chips in active use)

Hang on.  NV-DIMM chips don't know anyhing about E820 tables.  They don't
have anything in them that says I am type 12!.  How they are reported
is up to the BIOS.  Just because your BIOS vendor has chosen to report
tham as type 12 doesn't mean that any other BIOS vedor is going to have
done the same thing.

Fortunately, the BIOS people have all got together and decided what
they're going to do, and it's not type 12.  Unfortunately, I think
I'm bound by various agreements to not say what they are going to do
until they do.  But putting this temporary workaround in the kernel to
accomodate one BIOS vendor's unreleased experimental code seems like
entirely the wrong idea.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Regression bug in drm/i915, Wrong assumption in commit e11aa36 breaks suspend on at least lenovo x61

2015-02-16 Thread Klaus Ethgen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

After three days of bisect I found the bug for my problem with a broken
suspend on x61p of lenovo.

The problem is commit e11aa36. It seems to be a wrong assumption that
disabling the interrupts is enough.

I'll try to revert the commit on top of 3.18.7. (It does not clean
revert.)

Regards
   Klaus
- -- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen kl...@ethgen.de
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQGcBAEBCgAGBQJU4mseAAoJEKZ8CrGAGfas9skMAIeYCOSbbA2kQbC0AQT17y5L
TUayHwW/4pDYxIOqS8cuCkiSGxokiemBYDdLgtVzPCp90suhB0ZhZY0o1VolwQTP
CHTqYAGTNarq7c9gXWmpCGlpYyPzce38rlDMzu4fQwOqegziO3TBrAm7m5rwv/mK
cBtPK4anx6qrXjUrttn8LEt0Qlr5n+HIKVBrbZcPLuLJmxA1KclY742V53Z2uEuz
CozDMjKrVhAKG3ehRxXhpcWQRRNOplKH7cY74yWLA3eepQg82CjEcM5mP7cZWDPT
Hv+B1H6wZ38STtKctiXUUukCphaT0AU97saCr7k4xkY/6gM+BNCZNQnQAOGzW0J3
ybhTT/oZVxY2qPo/hk3x/XGoAkdQq/7axYEYRN/urocklLUcy2Dlc2kuN8K6QRqk
VY4USl6U3c4mbK3bOB35oPPqrqFzFgbntJ7VHaIRip5VUjEsrHYox5lKFQJOt2Rg
fHLyD423SuXE5pCQxWiXl+Hq5MC7n80N132SQSxa4Q==
=9G0k
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 29/45] include/uapi/asm-generic/msgbuf.h: include asm/ipcbuf.h

Fixes userspace compilation errors like:

error: field ‘msg_perm’ has incomplete type
struct ipc64_perm msg_perm

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/asm-generic/msgbuf.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/asm-generic/msgbuf.h 
b/include/uapi/asm-generic/msgbuf.h
index f55ecc4..f5fbd8e 100644
--- a/include/uapi/asm-generic/msgbuf.h
+++ b/include/uapi/asm-generic/msgbuf.h
@@ -2,6 +2,8 @@
 #define __ASM_GENERIC_MSGBUF_H
 
 #include asm/bitsperlong.h
+#include asm/ipcbuf.h
+
 /*
  * generic msqid64_ds structure.
  *
-- 
2.1.4

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

[PATCH 43/45] include/uapi/linux/netfilter_bridge.h: include if.h

Fixes userspace compilation errors like:

error: field ‘in’ has incomplete type
struct in_addr in;

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/linux/netfilter_bridge.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/netfilter_bridge.h 
b/include/uapi/linux/netfilter_bridge.h
index a5eda6d..5bb0528 100644
--- a/include/uapi/linux/netfilter_bridge.h
+++ b/include/uapi/linux/netfilter_bridge.h
@@ -4,6 +4,7 @@
 /* bridge-specific defines for netfilter. 
  */
 
+#include linux/if.h
 #include linux/netfilter.h
 #include linux/if_ether.h
 #include linux/if_vlan.h
-- 
2.1.4

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

[PATCH 45/45] include/uapi/asm-generic/ucontext.h: include signal.h and sigcontext.h

Fixes userspace compiler errors:

error: unknown type name ‘stack_t’
error: field ‘uc_mcontext’ has incomplete type
struct sigcontext uc_mcontext;
error: unknown type name ‘sigset_t’

Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
 include/uapi/asm-generic/ucontext.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/asm-generic/ucontext.h 
b/include/uapi/asm-generic/ucontext.h
index ad77343..31ece341 100644
--- a/include/uapi/asm-generic/ucontext.h
+++ b/include/uapi/asm-generic/ucontext.h
@@ -1,6 +1,9 @@
 #ifndef __ASM_GENERIC_UCONTEXT_H
 #define __ASM_GENERIC_UCONTEXT_H
 
+#include asm-generic/signal.h
+#include asm/sigcontext.h
+
 struct ucontext {
unsigned long uc_flags;
struct ucontext  *uc_link;
-- 
2.1.4

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

Re: [PATCH 1/3] Slab infrastructure for array operations

2015-02-16 Thread Joonsoo Kim

On Fri, Feb 13, 2015 at 09:47:59AM -0600, Christoph Lameter wrote:
 On Fri, 13 Feb 2015, Joonsoo Kim wrote:
 
  I also think that this implementation is slub-specific. For example,
  in slab case, it is always better to access local cpu cache first than
  page allocator since slab doesn't use list to manage free objects and
  there is no cache line overhead like as slub. I think that,
  in kmem_cache_alloc_array(), just call to allocator-defined
  __kmem_cache_alloc_array() is better approach.
 
 What do you mean by better? Please be specific as to where you would see
 a difference. And slab definititely manages free objects although
 differently than slub. SLAB manages per cpu (local) objects, per node
 partial lists etc. Same as SLUB. The cache line overhead is there but no
 that big a difference in terms of choosing objects to get first.
 
 For a large allocation it is beneficial for both allocators to fist reduce
 the list of partial allocated slab pages on a node.
 
 Going to the local objects first is enticing since these are cache hot but
 there are only a limited number of these available and there are issues
 with acquiring a large number of objects. For SLAB the objects dispersed
 and not spatially local. For SLUB the number of objects is usually much
 more limited than SLAB (but that is configurable these days via the cpu
 partial pages). SLUB allocates spatially local objects from one page
 before moving to the other. This is an advantage. However, it has to
 traverse a linked list instead of an array (SLAB).

Hello,

Hmm...so far, SLAB focus on temporal locality rather than spatial locality
as you know. Why SLAB need to consider spatial locality first in this
kmem_cache_alloc_array() case?

And, although we use partial list first, we can't reduce
fragmentation as much as SLUB. Local cache may keep some free objects
of the partial slab so just exhausting free objects of partial slab doesn't
means that there is no free object left. For SLUB, exhausting free
objects of partial slab means there is no free object left.

If we allocate objects from local cache as much as possible, we can
keep temporal locality and return objects as fast as possible since
returing objects from local cache just needs memcpy from local array
cache to destination array.

This cannot be implemented by using kmem_cache_alloc_array() you
suggested and this is why I think just calling allocator-defined
__kmem_cache_alloc_array() is better approach.

As David said, there is no implementation for SLAB yet and we have
different opinion about implementation for SLAB. It's better
to delay detailed implementation of kmem_cache_alloc_array()
until implementation for SLAB is agreed. Before it, calling
__kmem_cache_alloc_array() in kmem_cache_alloc_array() is sufficient
to provide functionality.

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

[PATCH] mm/memcontrol: fix NULL pointer dereference when use_hierarchy is 0

2015-02-16 Thread Joonsoo Kim

It can be possible to return NULL in parent_mem_cgroup()
if use_hierarchy is 0. So, we need to check NULL in the loop on
mem_cgroup_low(). Without it, following NULL pointer dereference happens.

[   33.607531] BUG: unable to handle kernel NULL pointer dereference at 
00b0
[   33.608008] IP: [811dcf60] mem_cgroup_low+0x40/0x90
[   33.608008] PGD 1d893067 PUD 1cf41067 PMD 0
[   33.608008] Oops:  [#12] SMP
[   33.608008] Modules linked in:
[   33.608008] CPU: 1 PID: 3936 Comm: as Tainted: G  D 
3.19.0-next-20150216 #156
[   33.608008] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Bochs 01/01/2011
[   33.608008] task: 88001d9c8000 ti: 88000cb14000 task.ti: 
88000cb14000
[   33.608008] RIP: 0010:[811dcf60]  [811dcf60] 
mem_cgroup_low+0x40/0x90
[   33.608008] RSP: :88000cb17a88  EFLAGS: 00010286
[   33.608008] RAX:  RBX: 88000cb17bc0 RCX: 
[   33.608008] RDX: 88001f491400 RSI:  RDI: 
[   33.608008] RBP: 88000cb17a88 R08: 0160 R09: 
[   33.608008] R10:  R11: 02b8c101 R12: 
[   33.608008] R13:  R14: 88001fff9e08 R15: 88001da95800
[   33.608008] FS:  2b7a12715380() GS:88001fa4() 
knlGS:
[   33.608008] CS:  0010 DS:  ES:  CR0: 80050033
[   33.608008] CR2: 00b0 CR3: 0762f000 CR4: 07e0
[   33.608008] Stack:
[   33.608008]  88000cb17b18 811838ec 88000cb17cd8 

[   33.608008]   0001 000280da 
88001fff8780
[   33.608008]  88000cb17af8 810e1d7e 88001fff8780 
0003000c
[   33.608008] Call Trace:
[   33.608008]  [811838ec] shrink_zone+0xac/0x2d0
[   33.608008]  [810e1d7e] ? ktime_get+0x3e/0xa0
[   33.608008]  [81183e94] do_try_to_free_pages+0x174/0x440
[   33.608008]  [8117f1a8] ? throttle_direct_reclaim+0x98/0x250
[   33.608008]  [8118421a] try_to_free_pages+0xba/0x150
[   33.608008]  [81176d10] __alloc_pages_nodemask+0x5a0/0x950
[   33.608008]  [811c09ff] alloc_pages_vma+0xaf/0x200
[   33.608008]  [811a0717] handle_mm_fault+0x1287/0x17e0
[   33.608008]  [81059e9e] ? kvm_clock_read+0x1e/0x20
[   33.608008]  [81059e9e] ? kvm_clock_read+0x1e/0x20
[   33.608008]  [8101e6a9] ? sched_clock+0x9/0x10
[   33.608008]  [810605f1] __do_page_fault+0x191/0x440
[   33.608008]  [81060955] trace_do_page_fault+0x45/0x100
[   33.608008]  [8105968e] do_async_page_fault+0x1e/0xd0
[   33.608008]  [8176f628] async_page_fault+0x28/0x30
[   33.608008] Code: 48 8b 15 cc 21 b4 00 48 39 d6 74 53 48 8b 8e b0 00 00 00 
48 39 8e 28 01 00 00 72 43 31 c9 48 39 fe 75 1d eb 35 66 0f 1f 44 00 00 48 8b 
86 b0 00 00 00 48 39 86 28 01 00 00 72 30 48 39 f7 74 1a
[   33.608008] RIP  [811dcf60] mem_cgroup_low+0x40/0x90
[   33.608008]  RSP 88000cb17a88
[   33.608008] CR2: 00b0
[   33.608008] BUG: unable to handle kernel [   33.653499] ---[ end trace 
e264a32717ffda51 ]---

Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
 mm/memcontrol.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index d18d3a6..507cfea 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5431,6 +5431,8 @@ bool mem_cgroup_low(struct mem_cgroup *root, struct 
mem_cgroup *memcg)
 
while (memcg != root) {
memcg = parent_mem_cgroup(memcg);
+   if (!memcg)
+   break;
 
if (memcg == root_mem_cgroup)
break;
-- 
1.9.1

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

[PATCH v4 5/5] usb: dwc3: add Fujitsu Specific Glue layer

This patch adds support for Synopsis DesignWare USB3 IP Core found
on Fujitsu Socs.

Signed-off-by: Sneeker Yeh sneeker@tw.fujitsu.com
---
 .../devicetree/bindings/usb/fujitsu-dwc3.txt   |   33 
 drivers/usb/dwc3/Kconfig   |   11 ++
 drivers/usb/dwc3/Makefile  |1 +
 drivers/usb/dwc3/dwc3-mb86s70.c|  206 
 4 files changed, 251 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
 create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c

diff --git a/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt 
b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
new file mode 100644
index 000..be091eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
@@ -0,0 +1,33 @@
+FUJITSU GLUE COMPONENTS
+
+MB86S7x DWC3 GLUE
+- compatible:  Should be fujitsu,mb86s70-dwc3
+- clocks:  from common clock binding, handle to usb clock.
+- clock-names: Should contain the following:
+  core   Master/Core clock needs to run at a minimum of 125 MHz to
+   support a 4 Gbps IN or 4 Gbps OUT
+   transfer at a given time.
+
+Sub-nodes:
+The dwc3 core should be added as subnode to MB86S7x dwc3 glue.
+- dwc3 :
+   The binding details of dwc3 can be found in:
+   Documentation/devicetree/bindings/usb/dwc3.txt
+
+Example device nodes:
+
+   usb3host: mb86s70_usb3host {
+   compatible = fujitsu,mb86s70-dwc3;
+   clocks = clk_alw_1_1;
+   clock-names = core;
+   #address-cells = 2;
+   #size-cells = 1;
+   ranges;
+
+   dwc3@3220 {
+   compatible = synopsys,dwc3;
+   reg = 0 0x3230 0x10;
+   interrupts = 0 412 0x4,
+   0 414 0x4;
+   };
+   };
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index edbf9c8..8ab0f2c 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -61,6 +61,17 @@ config USB_DWC3_EXYNOS
  Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
  say 'Y' or 'M' if you have one such device.
 
+config USB_DWC3_MB86S70
+   tristate MB86S70 Designware USB3 Platform code
+   default USB_DWC3
+   help
+ MB86S7X SOC ship with DesignWare Core USB3 IP inside,
+ this implementation also integrated Fujitsu USB PHY inside
+ this Core USB3 IP.
+
+ say 'Y' or 'M' if you have one such device.
+
+
 config USB_DWC3_PCI
tristate PCIe-based Platforms
depends on PCI
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 46172f4..76634b7 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_QCOM)+= dwc3-qcom.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_MB86S70) += dwc3-mb86s70.o
diff --git a/drivers/usb/dwc3/dwc3-mb86s70.c b/drivers/usb/dwc3/dwc3-mb86s70.c
new file mode 100644
index 000..301be76
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-mb86s70.c
@@ -0,0 +1,206 @@
+/**
+ * dwc3-mb86s70.c - Fujitsu mb86s70 DWC3 Specific Glue layer
+ *
+ * Copyright (c) 2013 - 2014 FUJITSU SEMICONDUCTOR LIMITED
+ * http://jp.fujitsu.com/group/fsl
+ *
+ * Authors: Alice Chan alice.c...@tw.fujitsu.com
+ * Sneeker Yeh sneeker@tw.fujitsu.com
+ * based on dwc3-exynos.c
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+#include linux/interrupt.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/pm_runtime.h
+#include linux/clk.h
+
+struct dwc3_mb86s70 {
+   struct device   *dev;
+   struct clk  *clks[5];
+   u8  clk_cnt;
+};
+
+static int dwc3_mb86s70_clk_control(struct device *dev, bool on)
+{
+   struct dwc3_mb86s70 *priv = dev_get_drvdata(dev);
+   int ret, i = priv-clk_cnt;
+
+   if (!on)
+   goto clock_off;
+
+   for (i = 0; i  priv-clk_cnt; i++) {
+   ret = clk_prepare_enable(priv-clks[i]);
+   if (ret) {
+   dev_err(dev, failed to enable clock[%d]\n, i);
+   on = ret;
+   goto clock_off;
+   }
+   }
+
+   return 0;
+
+clock_off:
+   for (; i  0;)
+   clk_disable_unprepare(priv-clks[--i]);
+
+   return on;
+}
+
+static int

[PATCH v4 2/5] xhci: Platform: Set Synopsis device disconnection quirk based on platform data

If an xhci platform has Synopsis device disconnection errata then enable
XHCI_DISCONNECT_QUIRK quirk flag.

Signed-off-by: Sneeker Yeh sneeker@tw.fujitsu.com
---
 drivers/usb/host/xhci-plat.c |3 +++
 include/linux/usb/xhci_pdriver.h |4 
 2 files changed, 7 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b..40beb95 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,6 +147,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node  of_property_read_bool(node, usb3-lpm-capable)) ||
(pdata  pdata-usb3_lpm_capable))
xhci-quirks |= XHCI_LPM_SUPPORT;
+
+   if (pdata  pdata-delay_portcsc_clear)
+   xhci-quirks |= XHCI_DISCONNECT_QUIRK;
/*
 * Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
 * is called by usb_add_hcd().
diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..a37a3a5 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,14 @@
  *
  * @usb3_lpm_capable:  determines if this xhci platform supports USB3
  * LPM capability
+ * @delay_portcsc_clear:   determines if Synopsis USB3 core has errata in
+ * DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1 hardware
+ * configuration.
  *
  */
 struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+   unsigneddelay_portcsc_clear:1;
 };
 
 #endif /* __USB_CORE_XHCI_PDRIVER_H */
-- 
1.7.9.5

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

[PATCH v4 0/5] Add support for Fujitsu USB host controller

These patches add support for XHCI compliant Host controller found
on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/
The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 driver
and last four patch is about quirk implementation of errata in Synopsis
DesignWare USB3 IP.

Patch 1 introduces a quirk with device disconnection management necessary
Synopsys Designware USB3 IP with versions  3.00a and hardware configuration
DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the
quirk, that host controller will die after a usb device is disconnected from
port of root hub.

Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci platform
data.

Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare USB3
IP core driver.

Patch 4 introduces using a quirk based on a errata of Synopsis
DesignWare USB3 IP which is versions  3.00a and has hardware configuration
DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a
result this quirk has to be enabled via platform data or device tree.

Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP
driver. 

Successfully tested on Fujitsu mb86s7x board.

Changes since v3 (RFC):
[https://lkml.org/lkml/2014/12/15/929]
 - based on Mathias's comment, fix bug and using xhci_port_state_to_neutral()
   helper function to mask out some RW1C bits, prevent writing back all the
   bits read from the PORTSC register.

Changes since v2 (RFC):
[https://lkml.org/lkml/2014/12/15/929]
 - based on Felipe's comment, re-order patches to avoid breaking bisectability,
 - based on Felipe's comment, add comment to structure's member, and sort it
   alphabetically,
 - based on Felipe's comment, add another v2.90 revision number in dwc3 IP.

Changes since v1 (RFC):
[https://lkml.org/lkml/2014/12/15/929]
 - based on Arnd's comment, remove entire unnecessary Fujitsu EHCI/OHCI glue,
 - based on Felipe's comment, fix mis-using of runtime-pm API and setting dma
   mask, remove unnecessary comment, and refactor suspend/resume handler in
   Fujitsu Specific Glue layer in dwc3,
 - based on Felipe's comment, add more commit log and comments in Synopsis
   quirk implementation, and separate it into four patches.

Sneeker Yeh (5):
  xhci: add a quirk for device disconnection errata for Synopsis
Designware USB3 core
  xhci: Platform: Set Synopsis device disconnection quirk based on
platform data
  usb: dwc3: add revision number DWC3_REVISION_290A and
DWC3_REVISION_300A
  usb: dwc3: Add quirk for Synopsis device disconnection errata
  usb: dwc3: add Fujitsu Specific Glue layer

 Documentation/devicetree/bindings/usb/dwc3.txt |   17 ++
 .../devicetree/bindings/usb/fujitsu-dwc3.txt   |   33 
 drivers/usb/dwc3/Kconfig   |   11 ++
 drivers/usb/dwc3/Makefile  |1 +
 drivers/usb/dwc3/core.c|6 +
 drivers/usb/dwc3/core.h|6 +
 drivers/usb/dwc3/dwc3-mb86s70.c|  206 
 drivers/usb/dwc3/host.c|4 +
 drivers/usb/dwc3/platform_data.h   |8 +
 drivers/usb/host/xhci-hub.c|4 +
 drivers/usb/host/xhci-plat.c   |3 +
 drivers/usb/host/xhci.c|   31 +++
 drivers/usb/host/xhci.h|   24 +++
 include/linux/usb/xhci_pdriver.h   |4 +
 14 files changed, 358 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
 create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c

-- 
1.7.9.5

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

[PATCH v4 4/5] usb: dwc3: Add quirk for Synopsis device disconnection errata