power: ds2782_battery: Typo in comment

Change missleading comment to actual shift value provided by the chip.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
isp1704_charger: remove useless check in isp1704_charger_probe()

Neither devm_usb_get_phy_by_phandle() nor devm_usb_get_phy() can
return a NULL result, so remove the useless !isp->phy check.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
dt: binding documentation for bq2415x charger

Add devicetree binding documentation for bq2415x charger.

Signed-off-by: Sebastian Reichel <sre@debian.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
spi: spi.h: clarify the documentation of transfer_one

Explicitly note the transfer_one and transfer_one_message are mutually
exclusive, to make the text a little more newcomers friendly.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Mark Brown <broonie@linaro.org>
spi: document the transfer_one spi_master callback

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Mark Brown <broonie@linaro.org>
spi: correct the transfer_one_message documentation wording

The transfer_one_message callback handles messages, not transfers.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Mark Brown <broonie@linaro.org>
spi: Fix crash with double message finalisation on error handling

This reverts commit e120cc0dcf2880a4c5c0a6cb27b655600a1cfa1d.

It causes a NULL pointer dereference with drivers using the generic
spi_transfer_one_message(), which always calls
spi_finalize_current_message(), which zeroes master->cur_msg.

Drivers implementing transfer_one_message() theirselves must always call
spi_finalize_current_message(), even if the transfer failed:

 * @transfer_one_message: the subsystem calls the driver to transfer a single
 *      message while queuing transfers that arrive in the meantime. When the
 *      driver is finished with this message, it must call
 *      spi_finalize_current_message() so the subsystem can issue the next
 *      transfer

Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
s390/qdio: for_each macro correctness

I observed that there are for_each macros that do an extra memory access
beyond the defined area.
Normally this does not cause problems.
But, this can cause exceptions. For example: if the area is allocated at
the end of a page and the next page is not accessible.

For correctness, I suggest changing the arguments of the 'for loop' like
others 'for_each' do in the kernel.

Signed-off-by: Jose Alonso <joalonsof@gmail.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/qdio: correct program-controlled interruption checking

Get rid of compile warning in qdio_int_handler_pci() when checking
for program-controlled interruption on outbound queues.

Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/appldata: restore missing init_virt_timer()

Commit 27f6b416 "s390/vtimer: rework virtual timer interface" removed
the call to init_virt_timer() by mistake, which is added again by this
patch.

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
can: flexcan: fix flexcan driver build for big endian on ARM and little endian on PowerPc

There is no reason to disallow building the driver on big-endian ARM kernels.
Furthermore, the current behavior is actually broken on little-endian PowerPC
as well.

The choice of register accessor functions must purely depend on the CPU
architecture, not which endianess the CPU is running on. Note that we nowadays
allow both big-endian ARM and little-endian PowerPC kernels.

With this patch applied, we will do the right thing in all four combinations.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: Propagate SO_PRIORITY of raw sockets to skbs

This allows controlling certain queueing disciplines by setting the
socket's SO_PRIORITY option.

For example, with the default pfifo_fast queueing discipline, which
provides three priorities, socket priority TC_PRIO_CONTROL means
higher than default and TC_PRIO_BULK means lower than default.

Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: janz-ican3: fix uninitialized variable warnings

Analysis of the code shows that the struct ican3_msg variable cannot be
used uninitialized. Error conditions are checked and the loop terminates
before calling the ican3_handle_message() function with an uninitialized
value.

Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
bcache: fix BUG_ON due to integer overflow with GC_SECTORS_USED

The BUG_ON at the end of __bch_btree_mark_key can be triggered due to
an integer overflow error:

BITMASK(GC_SECTORS_USED, struct bucket, gc_mark, 2, 13);
...
SET_GC_SECTORS_USED(g, min_t(unsigned,
	     GC_SECTORS_USED(g) + KEY_SIZE(k),
	     (1 << 14) - 1));
BUG_ON(!GC_SECTORS_USED(g));

In bcache.h, the SECTORS_USED bitfield is defined to be 13 bits wide.
While the SET_ code tries to ensure that the field doesn't overflow by
clamping it to (1<<14)-1 == 16383, this is incorrect because 16383
requires 14 bits.  Therefore, if GC_SECTORS_USED() + KEY_SIZE() =
8192, the SET_ statement tries to store 8192 into a 13-bit field.  In
a 13-bit field, 8192 becomes zero, thus triggering the BUG_ON.

Therefore, create a field width constant and a max value constant, and
use those to create the bitfield and check the inputs to
SET_GC_SECTORS_USED.  Arguably the BITMASK() template ought to have
BUG_ON checks for too-large values, but that's a separate patch.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
bcache: Minor fixes from kbuild robot

Signed-off-by: Kent Overstreet <kmo@daterainc.com>
bcache: bugfix - gc thread now gets woken when cache is full

Signed-off-by: Nicholas Swenson <nks@daterainc.com>
drm/i915: vlv: fix DP PHY lockup due to invalid PP sequencer setup

Atm we setup the HW panel power sequencer logic both for eDP and DP
ports. On eDP we then go on and start the power on sequence and commence
with link training when it's ready. On DP we don't do the power on
sequencing but do the link training immediately. At this point the DP
PHY block gets stuck, since - supposedly - it is waiting for the power
on sequence to finish. The actual register write that seems to hold off
the PHY is PIPEX_PP_ON_DELAYS[Panel Control Port Select]. Writing here
a non-0 value eventually sets PIPEX_PP_STATUS[Require Asset Status] to
1 and blocks the PHY until the panel power on is ready.

Fix this by not doing any PP sequencing setup for DP ports.

Thanks to Ville Syrjälä, Jesse Barnes and Todd Previte for the help in
tracking this down.

Note that on older gmch platforms (where we have lvds instead of edp)
we've hacked around this by writing the magic ABCD unlock key to PP
registers, which disables the hw sanity checks.

For edp all platforms thus far had the pch split, with the edp port in
the north display complex and the PP registers on the pch the hw
sanity checks (expressed through the "Require Asset Status" bit) was
never functional, hence never a real issue.

This regression has been introduce in

commit bf13e81b904a37d94d83dd6c3b53a147719a3ead
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Sep 6 07:40:05 2013 +0300

    drm/i915: add support for per-pipe power sequencing on vlv

Signed-off-by: Imre Deak <imre.deak@intel.com>
[danvet: Add note about the bigger story here.]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
iwlwifi: mvm: make local pointer non-static

The address pointer used in the function shouldn't be static
since it's local data only. Having it static causes races if
a single machine has two devices, as the pointer would be
shared between instances.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
iwlwifi: mvm: disable scheduled scan

The iwlwifi scheduled scan implementation doesn't adhere to the
userspace API correctly - the API assumes that any new incoming
'incompatible' request (like scan or remain-on-channel for this
driver) will just cancel the scheduled scan. Instead our driver
relies on userspace cancelling it, thus breaking existing wpa_s
versions.

Cc: stable@vger.kernel.org [3.13]
Fixes: 35a000b7c1bb ("iwlwifi: mvm: support sched scan if supported by the fw")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
iwlwifi: mvm: print the version of the firmware when it asserts

This can be useful to be able to spot the firmware version
from the error reports without needing to fetch it from
another place.

Cc: <stable@vger.kernel.org> [3.10+]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>