target: Have dev/enable show if TCM device is configured

User tools need to know if the device is properly configured, since if
not, some other attributes are invalid.

Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
iscsi-target: Fix NULL pointer dereference in iscsit_send_reject

Fix up a NULL pointer dereference regression in iscsit_send_reject()
introduced by from commit 2ec5a8c11.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
iscsi-target: Make buf param of iscsit_do_crypto_hash_buf() const void *

Make the "buf" input param of iscsit_do_crypto_hash_buf() "const void *".
This allows to remove lots of casts in its callers.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
rcu: Fix full dynticks' dependency on wide RCU nocb mode

Commit 0637e029392386e6996f5d6574aadccee8315efa
("nohz: Select wide RCU nocb for full dynticks") intended
to force CONFIG_RCU_NOCB_CPU_ALL=y when full dynticks is
enabled.

However this option is part of a choice menu and Kconfig's
"select" instruction has no effect on such targets.

Fix this by using reverse dependencies on the targets we
don't want instead.

Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Hakan Akkan <hakanakkan@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
sched: Keep at least 1 tick per second for active dynticks tasks

The scheduler doesn't yet fully support environments
with a single task running without a periodic tick.

In order to ensure we still maintain the duties of scheduler_tick(),
keep at least 1 tick per second.

This makes sure that we keep the progression of various scheduler
accounting and background maintainance even with a very low granularity.
Examples include cpu load, sched average, CFS entity vruntime,
avenrun and events such as load balancing, amongst other details
handled in sched_class::task_tick().

This limitation will be removed in the future once we get
these individual items to work in full dynticks CPUs.

Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Hakan Akkan <hakanakkan@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
perf/x86: Blacklist all MEM_*_RETIRED events for Ivy Bridge

Errata BV98 states that all MEM_*_RETIRED events corrupt the
counter value of the SMT sibling's counters. Blacklist these
events

Reported-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: <stable@kernel.org>
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/20130503121256.083340271@chello.nl
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/n/tip-jwra43mujrv1oq9xk6mfe57v@git.kernel.org
perf/x86/intel/lbr: Fix LBR filter

The LBR 'from' adddress is under full userspace control; ensure
we validate it before reading from it.

Note: is_module_text_address() can potentially be quite
expensive; for those running into that with high overhead
in modules optimize it using an RCU backed rb-tree.

Reported-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: <stable@kernel.org>
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/20130503121256.158211806@chello.nl
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/n/tip-mk8i82ffzax01cnqo829iy1q@git.kernel.org
Revert "drm/i915: revert eDP bpp clamping code changes"

This reverts commit 57c219633275c7e7413f8bc7be250dc092887458.

It's an ugly hack for a Haswell SDV platform where the vbt doesn't
seem to fully agree with the panel. Since it seems to cause issues on
real eDP platform let's just kill this hack again.

Reported-and-tested-by: Josh Boyer <jwboyer@gmail.com>
References: https://lkml.org/lkml/2013/5/3/467
Cc: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: hsw: fix link training for eDP on port-A

According to BSpec the link training sequence for eDP on HSW port-A
should be as follows:

1. link training: clock recovery
2. link training: equalization
3. link training: set idle transmission mode
4. display pipe enable
5. link training: disable (set normal mode)

Contrary to this at the moment we don't do step 3. and we do step 5.
before step 4. Fix this by setting idle transmission mode for eDP at
the end of intel_dp_complete_link_train and adding a new
intel_dp_stop_link_training function to disable link training. With
these changes we'll end up with the following functions corresponding
to the above steps:

intel_dp_start_link_train    -> step 1.
intel_dp_complete_link_train -> step 2., step 3.
intel_dp_stop_link_train     -> step 5.

For port-A we'll call intel_dp_stop_link_train only after enabling the
pipe, for everything else we'll call it right after
intel_dp_complete_link_train to preserve the current behavior.

Tested on HSW/HSW-ULT.

In v2:
- Due to a HW issue we must set idle transmission mode for port-A too
  before enabling the pipe. Thanks for Arthur Runyan for explaining
  this.
- Update the patch subject to make it clear that it's an eDP fix, DP is
  not affected.

v3:
- rename intel_dp_link_train() to intel_dp_set_link_train(), use 'val'
  instead 'l' as var name. (Paulo)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ALSA: hda - Fix 3.9 regression of EAPD init on Conexant codecs

The older Conexant codecs have up to two EAPDs and these are supposed
to be rather statically turned on.  The new generic parser code
assumes the dynamic on/off per path usage, thus it resulted in the
silent output on some machines.

This patch fixes the problem by simply assuming the static EAPD on for
such old Conexant codecs as we did until 3.8 kernel.

Reported-and-tested-by: Christopher K. <c.krooss@gmail.com>
Cc: <stable@vger.kernel.org> [v3.9]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
hwmon: (lm75) Per-chip configuration register initialization

There is no standard for the configuration register bits of LM75-like
chips. We shouldn't blindly clear bits setting the resolution as they
are either unused or used for something else on some of the supported
chips.

So, switch to per-chip configuration initialization. This will allow
for better tuning later, for example using more resolution bits when
available.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
hwmon: (lm75) Prepare to support per-chip resolution and sample time

Prepare the lm75 driver to support per-chip resolution and sample
time. For now we only make the code generic enough to support it, but
we still use the same, unchanged resolution (9-bit) and sample time
(1.5 s) for all chips.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
hwmon: (lm75) Tune resolution and sample time per chip

Most LM75-compatible chips can either sample much faster or with a
much better resolution than the original LM75 chip. So far the lm75
driver did not let the user take benefit of these improvements. Do it
now.

I decided to almost always configure the chip to use the best
resolution possible, which also means the longest sample time. The
only chips for which I didn't are the DS75, DS1775 and STDS75, because
they are really too slow in 12-bit mode (1.2 to 1.5 second worst case)
so I went for 11-bit mode as a more reasonable tradeoff. This choice is
dictated by the fact that the hwmon subsystem is meant for system
monitoring, it has never been supposed to be ultra-fast, and as a
matter of fact we do cache the sampled values in almost all drivers.

If anyone isn't pleased with these default settings, they can always
introduce a platform data structure or DT support for the lm75. That
being said, it seems nobody ever complained that the driver wouldn't
refresh the value faster than every 1.5 second, and the change made
it faster for all chips even in 12-bit mode, so I don't expect any
complaint.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
hwmon: (lm75) Add support for the Dallas/Maxim DS7505

Basically it's the same as the original DS75 but much faster.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
ARM: finally enable IRQ time accounting config

We've had IRQ time accounting for the last six months, except for the
Kconfig symbol.  This somehow got missed out of the original patch.
Add this now.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ipc: move rcu_read_unlock() out of sem_unlock() and into callers

The IPC locking is a mess, and sem_unlock() unlocks not only the
semaphore spinlock, it also drops the rcu read lock.  Unlike sem_lock(),
which just gets the spin-lock, and expects the caller to get the rcu
read lock.

This all makes things very hard to follow, and it's very confusing when
you take the rcu read lock in one function, and then release it in
another.  And it has caused actual bugs: the sem_obtain_lock() function
ended up dropping the RCU read lock twice in one error path, because it
first did the sem_unlock(), and then did a rcu_read_unlock() to match
the rcu_read_lock() it had done.

This is just a totally mindless "remove rcu_read_unlock() from
sem_unlock() and add it immediately after each caller" (except for the
aforementioned bug where we did too many rcu_read_unlock(), and in
find_alloc_undo() where we just got the rcu_read_lock() to correct for
the fact that sem_unlock would immediately drop it again).

We can (and should) clean things up further, but this fixes the bug with
the minimal amount of subtlety.

Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ipc: sem_putref() does not need the semaphore lock any more

ipc_rcu_putref() uses atomics for the refcount, and the games to lock
and unlock the semaphore just to try to keep the reference counting
working are no longer useful.

Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
do_mount(): fix a leak introduced in 3.9 ("mount: consolidate permission checks")

Cc: stable@vger.kernel.org
Bisected-by: Michael Leun <lkml20130126@newton.leun.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
do_coredump(): don't wait for thaw if coredump has already been interrupted

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
more mode_t whack-a-mole...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>