Allocating a large number of elements in atomic context could quickly
deplete memory reserves, so just disallow atomic resizing entirely.

Nothing currently uses mempool_resize() with anything other than
GFP_KERNEL, so convert existing callers to drop the gfp_mask.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Acked-by: Steffen Maier <maier@linux.vnet.ibm.com>	[zfcp]
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Steve French <sfrench@samba.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently, cleancache_register_ops returns the previous value of
cleancache_ops to allow chaining.  However, chaining, as it is
implemented now, is extremely dangerous due to possible pool id
collisions.  Suppose, a new cleancache driver is registered after the
previous one assigned an id to a super block.  If the new driver assigns
the same id to another super block, which is perfectly possible, we will
have two different filesystems using the same id.  No matter if the new
driver implements chaining or not, we are likely to get data corruption
with such a configuration eventually.

This patch therefore disables the ability to override cleancache_ops
altogether as potentially dangerous.  If there is already cleancache
driver registered, all further calls to cleancache_register_ops will
return EBUSY.  Since no user of cleancache implements chaining, we only
need to make minor changes to the code outside the cleancache core.
Signed-off-by: NVladimir Davydov <vdavydov@parallels.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Stefan Hengelein <ilendir@googlemail.com>
Cc: Florian Schmaus <fschmaus@gmail.com>
Cc: Andor Daam <andor.daam@googlemail.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Bob Liu <lliubbo@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch replaces cancel_dirty_page() with a helper function
account_page_cleaned() which only updates counters.  It's called from
truncate_complete_page() and from try_to_free_buffers() (hack for ext3).
Page is locked in both cases, page-lock protects against concurrent
dirtiers: see commit 2d6d7f98 ("mm: protect set_page_dirty() from
ongoing truncation").

Delete_from_page_cache() shouldn't be called for dirty pages, they must
be handled by caller (either written or truncated).  This patch treats
final dirty accounting fixup at the end of __delete_from_page_cache() as
a debug check and adds WARN_ON_ONCE() around it.  If something removes
dirty pages without proper handling that might be a bug and unwritten
data might be lost.

Hugetlbfs has no dirty pages accounting, ClearPageDirty() is enough
here.

cancel_dirty_page() in nfs_wb_page_cancel() is redundant.  This is
helper for nfs_invalidate_page() and it's called only in case complete
invalidation.

The mess was started in v2.6.20 after commits 46d2277c ("Clean up
and make try_to_free_buffers() not race with dirty pages") and
3e67c098 ("truncate: clear page dirtiness before running
try_to_free_buffers()") first was reverted right in v2.6.20 in commit
ecdfc978 ("Resurrect 'try_to_free_buffers()' VM hackery"), second in
v2.6.25 commit a2b34564 ("Fix dirty page accounting leak with ext3
data=journal").

Custom fixes were introduced between these points.  NFS in v2.6.23, commit
1b3b4a1a ("NFS: Fix a write request leak in nfs_invalidate_page()").
Kludge in __delete_from_page_cache() in v2.6.24, commit 3a692790 ("Do
dirty page accounting when removing a page from the page cache").  Since
v2.6.25 all of them are redundant.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There's a deadlock when concurrently hot-adding memory through the probe
interface and switching a memory block from offline to online.

When hot-adding memory via the probe interface, add_memory() first takes
mem_hotplug_begin() and then device_lock() is later taken when registering
the newly initialized memory block.  This creates a lock dependency of (1)
mem_hotplug.lock (2) dev->mutex.

When switching a memory block from offline to online, dev->mutex is first
grabbed in device_online() when the write(2) transitions an existing
memory block from offline to online, and then online_pages() will take
mem_hotplug_begin().

This creates a lock inversion between mem_hotplug.lock and dev->mutex.
Vitaly reports that this deadlock can happen when kworker handling a probe
event races with systemd-udevd switching a memory block's state.

This patch requires the state transition to take mem_hotplug_begin()
before dev->mutex.  Hot-adding memory via the probe interface creates a
memory block while holding mem_hotplug_begin(), there is no way to take
dev->mutex first in this case.

online_pages() and offline_pages() are only called when transitioning
memory block state.  We now require that mem_hotplug_begin() is taken
before calling them -- this requires exporting the mem_hotplug_begin() and
mem_hotplug_done() to generic code.  In all hot-add and hot-remove cases,
mem_hotplug_begin() is done prior to device_online().  This is all that is
needed to avoid the deadlock.
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Reported-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Zhang Zhen <zhenzhang.zhang@huawei.com>
Cc: Vladimir Davydov <vdavydov@parallels.com>
Cc: Wang Nan <wangnan0@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use macro section_nr_to_pfn() to switch between section and pfn, instead
of open-coding it.  No semantic changes.
Signed-off-by: NSheng Yong <shengyong1@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 297d716f ("power_supply: Change ownership from driver to
core") inverted the logic in battery_notify().  As an effect already
present battery was re-added on each system suspend or hibernation.

    WARNING: CPU: 0 PID: 303 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80()
    sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0A:00/power_supply/BAT0'
    CPU: 0 PID: 303 Comm: rtcwake Not tainted 4.0.0-ARCH-02621-g07e6253af953 #48
    Call Trace:
      sysfs_create_dir_ns+0x8d/0xa0
      kobject_add_internal+0xb6/0x370
      kobject_add+0x6f/0xd0
      device_add+0x120/0x6c0
      __power_supply_register+0x145/0x290
      power_supply_register_no_ws+0x10/0x20
      sysfs_add_battery+0x84/0xc5 [battery]
      battery_notify+0x45/0x6b [battery]
      notifier_call_chain+0x4f/0x80
      __blocking_notifier_call_chain+0x4b/0x70
      blocking_notifier_call_chain+0x16/0x20
      pm_notifier_call_chain+0x1a/0x40
      pm_suspend+0x3ed/0x4e0
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

pwm_config() must be called with a duty cycle of 0 prior to calling
pwm_disable() to ensure that the pwm signal is set to low.
Reported-by: NMarkus Reichl <m.reichl@fivetechno.de>
Tested-by: NMarkus Reichl <m.reichl@fivetechno.de>
Reviewed-by: NLukasz Majewski <l.majewski@samsung.com>
Reviewed-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: NAnand Moon <linux.amoon@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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

unfortunately, allowing an arbitrary 16bit value means a possibility of
overflow in the calculation of total number of pages in bio_map_user_iov() -
we rely on there being no more than PAGE_SIZE members of sum in the
first loop there.  If that sum wraps around, we end up allocating
too small array of pointers to pages and it's easy to overflow it in
the second loop.

X-Coverup: TINC (and there's no lumber cartel either)
Cc: stable@vger.kernel.org # way, way back
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This reverts commit ecc19d17.

It added a new warning to try to encourage driver writers to set the
device capabities properly, but drivers haven't been updated and in the
meantime it just generaters a scary message that users cannot actually
do anything about.

Warnings like these are appropriate if you actually expect to fix the
code that causes them.  They are not appropriate for releases.
Requested-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add missing directions, residue_granularity,
srd_addr_widths and dst_addr_widths bitfields.

Without those we will see a kernel WARN()
when loading musb on am335x devices.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The code was using an normal completion, but that caused stuck
task errors after a while.  Use an interruptible one to avoid that.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

If ipmi_powernv_recv(...) is called without a current message it
prints a warning and returns. However it fails to release the message
lock causing the system to dead lock during any subsequent IPMI
operations.

This error path should never normally be taken unless there are bugs
elsewhere in the system.
Signed-off-by: NAlistair Popple <alistair@popple.id.au>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Some BMCs don't let you clear the receive irq bit in the global
enables.  This is kind of silly, but they give an error if you
try to clear it.  Compensate for this by detecting the situation
and working around it.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NThomas D <whissi@whissi.de>
Reviewed-by: NThomas D <whissi@whissi.de>

HID Sensor Spec defines two usage ids for custom sensors

	HID_USAGE_SENSOR_TYPE_OTHER_CUSTOM (0x09, 0xE1)
	HID_USAGE_SENSOR_TYPE_OTHER_GENERIC(0x09, 0xE2)

	In addition the standard also defines usage ids for custom fields.
The purpose of these sensors is to extend the functionality or provide a way to
obfuscate the data being communicated by a sensor. Without knowing the mapping
between the data and its encapsulated form, it is difficult for an driver to
determine what data is being communicated by the sensor.  This allows some
differentiating use cases, where vendor can provide applications.  Since these
can't be represented by standard sensor interfaces like IIO, we present these
as fields with

- type (input/output)
- units
- min/max
- get/set value

In addition an dev interface to transfer report events. Details about this
interface is described in /Documentation/hid/hid-sensor.txt.  Manufacturers
should not use these ids for any standard sensors, otherwise the the
product/vendor id can be added to black list.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This fixes a oops due to a double list add when adding a reject PDU for
iscsit_allocate_iovecs allocation failures. The cmd has already been
added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call
iscsit_reject_cmd.

Note that for ERL0 the reject PDU is not actually sent, so this patch
is not completely tested. Just verified we do not oops. The problem is the
add reject functions return -1 which is returned all the way up to
iscsi_target_rx_thread which for ERL0 will drop the connection.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

In cases of short transfer times the CPU is spending lots of time
in the interrupt handler and scheduler to reschedule the worker thread.

Measurements show that we have times where it takes 29.32us to between
the last clock change and the time that the worker-thread is running again
returning from wait_for_completion_timeout().

During this time the interrupt-handler is running calling complete()
and then also the scheduler is rescheduling the worker thread.

This time can vary depending on how much of the code is still in
CPU-caches, when there is a burst of spi transfers the subsequent delays
are in the order of 25us, so the value of 30us seems reasonable.

With polling the whole transfer of 4 bytes at 10MHz finishes after 6.16us
(CS down to up) with the real transfer (clock running) taking 3.56us.
So the efficiency has much improved and is also freeing CPU cycles,
reducing interrupts and context switches.

Because of the above 30us seems to be a reasonable limit for polling.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Transforms the bcm-2835 native SPI-chip select to their gpio-cs equivalent.

This allows for some support of some optimizations that are not
possible due to HW-gliches on the CS line - especially filling
the FIFO before enabling SPI interrupts (by writing to CS register)
while the transfer is already in progress (See commit: e3a2be30)

This patch also works arround some issues in bcm2835-pinctrl which does not
set the value when setting the GPIO as output - it just sets up output and
(typically) leaves the GPIO as low.  When a fix for this is merged then this
gpio_set_value can get removed from bcm2835_spi_setup.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

It is not necessary to have regulator init data for a regulator. This
patch removes the necessity of this data and handles a NULL pointer
properly.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

In the unlikely case of hdev vanishing while hid_debug_events_read() was
sleeping, we can't really break out of the case switch as with other cases,
as on the way out we'll try to remove ourselves from the hdev waitqueue.

Fix this by taking a shortcut exit path and avoiding cleanup that doesn't
make sense in case hdev doesn't exist any more anyway.
Reported-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Voltage regulators can have (unregulated) current limits too, so we should
probably output both voltage and current for all regulators.

Holding the rdev->mutex actually conflicts with _regulator_get_current_limit
but also is not really necessary, as the global regulator_list_mutex already
protects us from the regulator vanishing while we go through the list.

On the rk3288-firefly the summary now looks like:

 regulator                      use open bypass voltage current     min     max
-------------------------------------------------------------------------------
 vcc_sys                          0   12      0  5000mV     0mA  5000mV  5000mV
    vcc_lan                       1    1      0  3300mV     0mA  3300mV  3300mV
       ff290000.ethernet                                            0mV     0mV
    vcca_33                       0    0      0  3300mV     0mA  3300mV  3300mV
    vcca_18                       0    0      0  1800mV     0mA  1800mV  1800mV
    vdd10_lcd                     0    0      0  1000mV     0mA  1000mV  1000mV
 [...]
Suggested-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

On modern systems the regulator hierarchy can get quite long and nested
with regulators supplying other regulators. In some cases when debugging
it might be nice to get a tree of these regulators, their consumers
and the regulation constraints in one go.

To achieve this add a regulator_summary sysfs node, similar to
clk_summary in the common clock framework, that walks the regulator
list and creates a tree out of the regulators, their consumers and
core per-regulator settings.

On a rk3288-firefly the regulator_summary would for example look
something like:

 regulator                      use open bypass   value     min     max
-----------------------------------------------------------------------
 vcc_sys                          0   12      0  5000mV  5000mV  5000mV
    vcc_lan                       1    1      0  3300mV  3300mV  3300mV
       ff290000.ethernet                                    0mV     0mV
    vcca_33                       0    0      0  3300mV  3300mV  3300mV
    vcca_18                       0    0      0  1800mV  1800mV  1800mV
    vdd10_lcd                     0    0      0  1000mV  1000mV  1000mV
    vccio_sd                      0    0      0  3300mV  3300mV  3300mV
    vcc_20                        0    3      0  2000mV  2000mV  2000mV
       vcc18_lcd                  0    0      0  1800mV  1800mV  1800mV
       vcc_18                     0    2      0  1800mV  1800mV  1800mV
          ff100000.saradc                                   0mV     0mV
          ff0d0000.dwmmc                                 1650mV  1950mV
       vdd_10                     0    0      0  1000mV  1000mV  1000mV
    vdd_log                       0    0      0  1100mV  1100mV  1100mV
    vcc_io                        0    3      0  3300mV  3300mV  3300mV
       ff0f0000.dwmmc                                    3300mV  3400mV
       vcc_flash                  1    1      0  1800mV  1800mV  1800mV
          ff0f0000.dwmmc                                 1700mV  1950mV
       vcc_sd                     1    1      0  3300mV  3300mV  3300mV
          ff0c0000.dwmmc                                 3300mV  3400mV
    vcc_ddr                       0    0      0  1200mV  1200mV  1200mV
    vdd_gpu                       0    0      0  1000mV   850mV  1350mV
    vdd_cpu                       0    1      0   900mV   850mV  1350mV
       cpu0                                               900mV   900mV
    vcc_5v                        0    2      0  5000mV  5000mV  5000mV
       vcc_otg_5v                 0    0      0  5000mV  5000mV  5000mV
       vcc_host_5v                0    0      0  5000mV  5000mV  5000mV
 regulator-dummy                  0    0      0     0mV     0mV     0mV
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Ran checkpatch.pl on file and removed a warning about an unwanted space before
a tab.
Signed-off-by: NChase Metzger <chasemetzger15@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

msleep(USB_RESUME_TIMEOUT) must be done when the controller drives
the resume. This is true after HPRT0_RES is written.
Moreover, restore the delay after controller power is up.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some additional quirks need to be enabled now we support UHS
modes. This avoids some spurious warnings like

"Got data interrupt 0x00000002 even though no data operation was in progress"

Testing on stih410-b2120 board achieves the following speeds
with HS200 eMMC card.

max-frequency = 200Mhz
/dev/mmcblk0p1:
 Timing buffered disk reads: 270 MB in  3.02 seconds =  89.54 MB/sec

max-frequency = 100Mhz
root@debian-armhf:~# hdparm -t /dev/mmcblk0p1
/dev/mmcblk0p1:
 Timing buffered disk reads: 210 MB in  3.00 seconds =  70.00 MB/sec

max-frequency = 50Mhz
root@debian-armhf:~# hdparm -t /dev/mmcblk0p1
/dev/mmcblk0p1:
 Timing buffered disk reads: 118 MB in  3.00 seconds =  39.28 MB/sec

This is better than the 3.10 kernel which achieves 77.59 MB/sec
at 200Mhz clock (same board/soc/eMMC).
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

To allow UHS modes to work properly we need to provide the st specific
set_uhs_signaling callback function. This function differs from the
generic sdhci_set_uhs_signaling callback in that we need to configure
the correct delay depending on the UHS mode, and also set the V18_EN
bit.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

STiH407 family SoC's have glue registers in the flashSS subsystem which
are used to configure the Arasan HC. This patch configures these glue
registers according to what has been specified in the DT.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Due to the tight timing constraints in some UHS modes, it is required to have
some delay management in the design. Two types of delay management are supported
in the HW: -

1) Static delay management
2) Dynamic delay management

NB: The delay management is only there when eMMC interface is selected.

1: Static delay management: is used to provide PVT dependent static delay on the
clock/data lines to manage setup/hold requirements of the interface. The maximum
delay possible is 3.25ns. These delays are PVT dependent, and thus delay values
applied are not accurate and vary across provcess voltage and temperature range.
Due to this these delays must not be used on the very time critical paths.

2. Dynamic delay locked loop (DLL): is used to provide dynamic delay management.
The advantage of DLL is that it provides accurate & PVT indepedent delay.

The DLL is used to provide delay on the loopback clock on "Read Path" to capture
read data reliably. On TX path the clock on which output data is transmitted is
delayed, resulting in delay of TX data.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

STiH407 family SoC's can have a reset signal for the controller which needs to
be managed. Also the eMMC controller has some additional 'top' memory mapped
registers which are used to manage the dynamic and static delay required for
UHS modes. This patch adds support for creating the mapping, which will be used
by subsequent patches.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The stih407 family SoC's have additional glue registers in the flashSS which
are used to configure the Arasan controller.

This patch adds macros for the register offsets and bitfields which will be
used by subsequent patches to support stih407 family SoC's.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since commit 20d0189b
in v3.14-rc1 RAID0 has performed incorrect calculations
when the chunksize is not a power of 2.

This happens because "sector_div()" modifies its first argument, but
this wasn't taken into account in the patch.

So restore that first arg before re-using the variable.
Reported-by: NJoe Landman <joe.landman@gmail.com>
Reported-by: NDave Chinner <david@fromorbit.com>
Fixes: 20d0189b
Cc: stable@vger.kernel.org (3.14 and later).
Signed-off-by: NNeilBrown <neilb@suse.de>

Reading both the capability ID and "next" pointer at the same time lets us
parse the list with half the number of config reads.
Signed-off-by: NSean O. Stalley <sean.stalley@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

devm_ioremap_resource() validates the resource it receives, so if we check
for devm_ioremap_resource() failure, we need not check for failure of the
preceding platform_get_resource().
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Check for failure from platform_get_resource() (this check actually happens
inside devm_ioremap_resource()) before dereferencing the pointer returned
from platform_get_resource().
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Check for failure of devm_ioremap_resource().

devm_ioremap_resource() validates the resource it receives, so if we check
for devm_ioremap_resource() failure, we need not check for failure of the
preceding platform_get_resource().

[bhelgaas: changelog]
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Communications with a hardware vendor confirm that the expected behaviour
on systems that set the FADT ASPM disable bit but which still grant full
PCIe control is for the OS to leave any BIOS configuration intact and
refuse to touch the ASPM bits.  This mimics the behaviour of Windows.
Signed-off-by: NMatthew Garrett <mjg59@coreos.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Feature macros work on sio_data as well, so use them there.
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Array of platform_device_id elements should be terminated
with empty element.
Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

of_find_node_by_name() calls of_node_put() on its "from" parameter.
To counter this, pm860x_backlight_dt_init() calls of_node_get() first.

Use of_get_child_by_name() instead to get rid of the refcount hack.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The RTC on S2MPS11 is the same as S2MPS14. However interrupt numbers of
RTC alarms 0 and 1 were inversed between these two devices. So when
rtc-s5m driver requested S2MPS14_IRQ_RTCA0 interrupt, it matched to
S2MPS11_IRQ_RTCA1, not RTCA0.

Fix this by using consistent RTC alarm interrupt numbers and adding a
BUILD_BUG_ON for future generations.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>