When remapping a block to the cache's fast device that is larger than
2TB we must not truncate the destination sector to 32bits.  The 32bit
temporary result of from_cblock() was being overflowed in
remap_to_cache() due to the logical left shift.

Use an intermediate 64bit type to store the 32bit from_cblock() result
to fix the overflow.
Signed-off-by: NHeinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

It was always intended that a user could provide a thin metadata device
that is larger than the max supported by the on-disk format.  The extra
space would just go unused.

Unfortunately that never worked.  If the user attempted to use a larger
metadata device on creation they would get an error like the following:

 device-mapper: space map common: space map too large
 device-mapper: transaction manager: couldn't create metadata space map
 device-mapper: thin metadata: tm_create_with_sm failed
 device-mapper: table: 252:17: thin-pool: Error creating metadata object
 device-mapper: ioctl: error adding target to table

Fix this by allowing the initial metadata space map creation to cap its
size at the max number of blocks supported (DM_SM_METADATA_MAX_BLOCKS).
get_metadata_dev_size() must also impose DM_SM_METADATA_MAX_BLOCKS (via
THIN_METADATA_MAX_SECTORS), otherwise extending metadata would cap at
THIN_METADATA_MAX_SECTORS_WARNING (which is larger than supported).

Also, the calculation for THIN_METADATA_MAX_SECTORS didn't account for
the sizeof the disk_bitmap_header.  So the supported maximum metadata
size is a bit smaller (reduced from 33423360 to 33292800 sectors).

Lastly, remove the "excess space will not be used" warning message from
get_metadata_dev_size(); it resulted in printing the warning multiple
times.  Factor out warn_if_metadata_device_too_big(), call it from
pool_ctr() and maybe_resize_metadata_dev().
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Acked-by: NJoe Thornber <ejt@redhat.com>

Fix a memory leak in the lp3943_pwm_request_map() error handling path.
Make sure already allocated pwm map memory is freed correctly.
Detected by Coverity: CID 1162829.
Signed-off-by: NChristian Engelmayer <cengelma@gmx.at>
Acked-by: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

An invalid ioctl will never be valid, irrespective of whether multipath
has active paths or not.  So for invalid ioctls we do not have to wait
for multipath to activate any paths, but can rather return an error
code immediately.  This fix resolves numerous instances of:

 udevd[]: worker [] unexpectedly returned with status 0x0100

that have been seen during testing.
Signed-off-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

This 444 should have been octal.
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: Alessandro Rubini <rubini@gnudd.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

These should have been octal.
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix irq_set_affinity callbacks in the Meta IRQ chip drivers to AND
cpu_online_mask into the cpumask when picking a CPU to vector the
interrupt to.

As Thomas pointed out, the /proc/irq/$N/smp_affinity interface doesn't
filter out offline CPUs, so without this patch if you offline CPU0 and
set an IRQ affinity to 0x3 it vectors the interrupt onto CPU0 even
though it is offline.
Reported-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-metag@vger.kernel.org
Cc: stable@vger.kernel.org

Since commit 77873803 "net_dma: mark broken" we no longer pin dma
engines active for the network-receive-offload use case.  As a result
the ->free_chan_resources() that occurs after the driver self test no
longer has a NET_DMA induced ->alloc_chan_resources() to back it up.  A
late firing irq can lead to ksoftirqd spinning indefinitely due to the
tasklet_disable() performed by ->free_chan_resources().  Only
->alloc_chan_resources() can clear this condition in affected kernels.

This problem has been present since commit 3e037454 "I/OAT: Add
support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the
NET_DMA use case is deprecated we can revisit moving the driver to use
threaded irqs.  For now, just tear down the irq and tasklet properly by:

1/ Disable the irq from triggering the tasklet

2/ Disable the irq from re-arming

3/ Flush inflight interrupts

4/ Flush the timer

5/ Flush inflight tasklets

References:
https://lkml.org/lkml/2014/1/27/282
https://lkml.org/lkml/2014/2/19/672

Cc: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: <stable@vger.kernel.org>
Reported-by: NMike Galbraith <bitbucket@online.de>
Reported-by: NStanislav Fomichev <stfomichev@yandex-team.ru>
Tested-by: NMike Galbraith <bitbucket@online.de>
Tested-by: NStanislav Fomichev <stfomichev@yandex-team.ru>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

pci_get_device() decrements the reference count of "from" (last
argument) so when we break off the loop successfully we have only one
device reference - and we don't know which device we have. If we want
a reference to each device, we must take them explicitly and let
the pci_get_device() walk complete to avoid duplicate references.

This is serious, as over-putting device references will cause
the device to eventually disappear. Without this fix, the kernel
crashes after a few insmod/rmmod cycles.

Tested on an Intel S7000FC4UR system with a 7300 chipset.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Link: http://lkml.kernel.org/r/20140224111656.09bbb7ed@endymion.delvare
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Cc: stable@vger.kernel.org
Signed-off-by: NBorislav Petkov <bp@suse.de>

The reference count changes done by pci_get_device can be a little
misleading when the usage diverges from the most common scheme. The
reference count of the device passed as the last parameter is always
decreased, even if the function returns no new device. So if we are
going to try alternative device IDs, we must manually increment the
device reference count before each retry. If we don't, we end up
decreasing the reference count, and after a few modprobe/rmmod cycles
the PCI devices will vanish.

In other words and as Alan put it: without this fix the EDAC code
corrupts the PCI device list.

This fixes kernel bug #50491:
https://bugzilla.kernel.org/show_bug.cgi?id=50491Signed-off-by: NJean Delvare <jdelvare@suse.de>
Link: http://lkml.kernel.org/r/20140224093927.7659dd9d@endymion.delvareReviewed-by: NAlan Cox <alan@linux.intel.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Cc: stable@vger.kernel.org
Signed-off-by: NBorislav Petkov <bp@suse.de>

dm_pool_close_thin_device() must be called if dm_set_target_max_io_len()
fails in thin_ctr().  Otherwise __pool_destroy() will fail because the
pool will still have an open thin device:

 device-mapper: thin metadata: attempt to close pmd when 1 device(s) are still open
 device-mapper: thin: __pool_destroy: dm_pool_metadata_close() failed.

Also, must establish error code if failing thin_ctr() because the pool
is in fail_io mode.
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Acked-by: NJoe Thornber <ejt@redhat.com>
Cc: stable@vger.kernel.org

This patch excludes reserved-marker byte-position from oobfree->length
calculation. Thus all bytes from oobfree->offset till end of OOB are free.

CC: <stable@vger.kernel.org> # 3.13.x+
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

1) In current implementation, ecclayout->oobfree->offset is calculated with
 respect to ecclayout->eccpos[0] which is incorrect because ECC bytes may not
 be stored contiguously in OOB.
 So, this patch calculates ecclayout->oobfree->offset with respect to last
 ECC byte-position 'eccpos[ecclayout->eccbytes-1]'.

2) ECC layout of some ecc-schemes expects reserved-markers at specific eccpos[]
 which should not be over-written by any file-system metadata.
 So this patch aligns oobfree->offset taking into account of such markers.

CC: <stable@vger.kernel.org> # 3.13.x+
Tested-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Fixes: commit a919e511
       mtd: nand: omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe

Fixes ecclayout mismatch introduced in above commit for following ecc-schemes:
 - OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
 - OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
 However, this patch also touches other ecc-schemes as the fix required
 refactoring common code, into ecc-scheme specific code.

This patch aligns ecc-layout for below ecc-schemes as per reference [1],[2],[3]

 +---+------------+-------------++-------------+-------------+
 |OOB|BCH8_CODE_HW|BCH8_CODE_HW_||HAM1_CODE_HW |HAM1_CODE_HW |
 |pos|            | DETECTION_SW||(x8 device)  |(x16 device) |
 +---+------------+-------------++-------------+-------------+
 | 0 |BADBLK_MARK | BADBLK_MARK || BADBLK_MARK | BADBLK_MARK |
 | 1 |BADBLK_MARK | BADBLK_MARK || eccpos[0]   | BADBLK_MARK |
 | 2 | eccpos[0]  | eccpos[0]   || eccpos[1]   | eccpos[0]   |
 | 3 | eccpos[1]  | eccpos[1]   || eccpos[2]   | eccpos[1]   |
 | 4 | eccpos[2]  | eccpos[2]   || eccpos[3]   | eccpos[2]   |
 | 5 | eccpos[3]  | eccpos[3]   || eccpos[4]   | eccpos[3]   |
 | 6 | eccpos[4]  | eccpos[4]   || eccpos[5]   | eccpos[4]   |
 | 7 | eccpos[5]  | eccpos[5]   || eccpos[6]   | eccpos[5]   |
 | 8 | eccpos[6]  | eccpos[6]   || eccpos[7]   | eccpos[6]   |
 | 9 | eccpos[7]  | eccpos[7]   || eccpos[8]   | eccpos[7]   |
 |10 | eccpos[8]  | eccpos[8]   || eccpos[9]   | eccpos[8]   |
 |11 | eccpos[9]  | eccpos[9]   || eccpos[10]  | eccpos[9]   |
 |12 | eccpos[10] | eccpos[10]  || eccpos[11]  | eccpos[10]  |
 |13 | eccpos[11] | eccpos[11]  || oobfree[0]  | eccpos[11]  |
 |14 | eccpos[12] | eccpos[12]  || oobfree[1]  | oobfree[0]  |
 |15 | eccpos[13] | <reserved>  || oobfree[2]  | oobfree[1]  |
 +---+------------+-------------++-------------+-------------+
 |16 | eccpos[14] | eccpos[13]  || oobfree[3]  | oobfree[2]  |
 |...| [...]      | [...]       || [...]       | [...]       |
 |56 | eccpos[54] | eccpos[51]  || oobfree[43] | oobfree[42] |
 |57 | eccpos[55] | <reserved>  || oobfree[44] | oobfree[43] |
 +===+============+=============+==============+=============+
 |58 | oobfree[0] | oobfree[0]  || oobfree[45] | oobfree[44] |
 |59 | oobfree[1] | oobfree[1]  || oobfree[46] | oobfree[45] |
 |60 | oobfree[2] | oobfree[2]  || oobfree[47] | oobfree[46] |
 |61 | oobfree[3] | oobfree[3]  || oobfree[48] | oobfree[47] |
 |62 | oobfree[4] | oobfree[4]  || oobfree[49] | oobfree[48] |
 |63 | oobfree[5] | oobfree[5]  || oobfree[50] | oobfree[49] |
 +---+------------+-------------+--------------+-------------+

[1] ecc-layout expected by ROM code, as specified in SoC TRM under:
      Chapter="Initialization"
        Section="Device Initialization by ROM code"
            Sub-Section="Memory Booting"
                Heading="NAND"
                Figure="ECC Locations in NAND Spare Areas"

[2] ecc-layout updates in u-boot
    http://lists.denx.de/pipermail/u-boot/2013-November/167551.html

[3] u-boot configurations to match above ecc-layout are documented at
    https://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide

CC: <stable@vger.kernel.org> # 3.13.x+
Reported-by: NEnric Balletbo Serra <eballetbo@iseebcn.com>
Tested-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This reverts commit d8a5dc30.

This breaks plymouth installs, either because plymouth is using the file
"incorrectly" or because the patch is incorrect.  Either way, this needs
to be reverted until it is all figured out.
Reported-by: NJosh Boyer <jwboyer@fedoraproject.org>
Reported-by: NRay Strode <halfline@gmail.com>
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Kay Sievers <kay@vrfy.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Werner Fink <werner@suse.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This fixes bug introduced in 667a6b7a (regulator: max14577: Add missing
of_node_put). The DTS parsing function returned number of matched
regulators as success status which then was compared against 0 in probe.

Result was a probe fail after successful parsing the DTS:
max14577-regulator: probe of max14577-regulator failed with error 2
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviwed-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt
handler. The bridge interrupt is implemented using a single generic
chip. Thus the parameter passed to irq_get_domain_generic_chip()
should always be zero.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Acked-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Fixes: 9dbd90f1 ("irqchip: Add support for Marvell Orion SoCs")
Cc: <stable@vger.kernel.org> # v3.11+
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

ENDPTFLUSH and ENDPTPRIME registers are set by software and clear
by hardware. There is a bit for each endpoint. When we are setting
a bit for an endpoint we should make sure we do not touch other
endpoint bit. There is a race condition if the hardware clear the
bit between the read and the write in hw_write.

Cc: stable <stable@vger.kernel.org> # 3.11+
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Tested-by: NMichael Grzeschik <mgrzeschik@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The change (008fa749) that moved the
node release code to a separate function broke death notifications in
some cases. When it encountered a reference without a death
notification request, it would skip looking at the remaining
references, and therefore fail to send death notifications for them.

Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Cc: stable <stable@vger.kernel.org> # 3.10
Signed-off-by: NArve Hjønnevåg <arve@android.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NJeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Most WDT driver modules return ENODEV during modprobe if
no valid device was found, but w83697hf_wdt returns EIO.

Let w83697hf_wdt return ENODEV.
Signed-off-by: NStanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Performing a Channel-Path configure on operation on a Channel-Path ID
(CHPID) does not trigger a scan for subchannels that might have become
available through that CHPID. As a result, some subchannels and
associated I/O devices might be missing. Fix this by adding the missing
scan.

This problem was introduced by commit c820de39, "[S390] cio: Rework
css driver.", but wasn't noticed earlier because the machine usually
also generates a Channel-Report-Word when the first CHPID of a
subchannel is configured on, resulting in a separate scan for that
subchannel. The problem only becomes apparent when this first CHPID is
not working properly and additional working CHPIDs are subsequently
configured on without any effect on the availability of the affected
subchannel.
Reviewed-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

A documentation update exposed the existance of the turbo ratio
register. Update baytrail support to use the turbo range.
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

LFM (max efficiency ratio) is the max frequency at minimum voltage
supported by the processor.  Using LFM as the minimum P state
increases performmance without affecting power. By not using P states
below LFM we avoid using P states that are less power efficient.
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Change "dummy supplies not allowed" error message to warning instead, as this
is a just warning message with no change to the behavior.

[Added a CC to stable since some other bug fixes cause this to come up
more frequently on PCs which is how it was noticed -- broonie]
Signed-off-by: NShuah Khan <shuah.kh@samsung.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

Fix regression caused by commit b072e53b, which breaks loading nouveau
driver on optimus laptops.

On some platforms, ACPI _DSM method (nouveau_op_dsm_muid, function 0)
has special requirements on the fourth parameter, which is different
from ACPI specifications. So revert to the private implementation
to check availability of _DSM functions instead of using common
acpi_check_dsm() interface.

Fixes: b072e53b (ACPI / nouveau: replace open-coded _DSM code with helper functions)
Reported-and-tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
[rjw: Subject]
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

sparc_cpu_model isn't in asm/system.h any more, so remove a comment
about it.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: sparclinux@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

schedule_delayed_work() takes the delay in jiffies, not msecs.

This bug slipped in with the recent reset logic cleanup
(8ed1fb79: "usb: musb: finish suspend/reset work independently from
musb_hub_control()").
Signed-off-by: NDaniel Mack <daniel@zonque.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
msm_otg_{suspend,resume} routines, however these routines are only being
built when CONFIG_PM_SLEEP.  In addition, msm_otg_{suspend,resume} also
depends on msm_hsusb_config_vddcx(), which is only built when
CONFIG_PM_SLEEP.

Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
preprocessor conditional, and moving msm_hsusb_config_vddcx().

While we're here, eliminate the CONFIG_PM conditional for setting
up the dev_pm_ops.

This address the following errors Russell King has hit doing randconfig
builds:

drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of function 'msm_otg_suspend'
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of function 'msm_otg_resume'

Cc: Ivan T. Ivanov <iivanov@mm-sol.com>
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NJosh Cartwright <joshc@codeaurora.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Fix possible NULL pointer dereference introduced in
commit 219580e6 (usb: f_fs: check quirk to pad epout
buf size when not aligned to maxpacketsize)

In cases we do wait with:

wait_event_interruptible(epfile->wait, (ep = epfile->ep));

for endpoint to be enabled, functionfs_bind() has not been called yet
and epfile->ffs->gadget is still NULL and the automatic variable 'gadget'
has been initialized with NULL at the point of its definition.
Later on it is used as a parameter to:

usb_ep_align_maybe(gadget, ep->ep, len)

which in turn dereferences it.

This patch fixes it by moving the actual assignment to the local 'gadget'
variable after the potential waiting has completed.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We need to use gadget_is_otg to check if the gadget is really
otg support at runtime, other composite gadget drivers have already
followed this method.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As the lock might be used through DMA-API which is allowed
in interrupt context.
Signed-off-by: NJoerg Roedel <joro@8bytes.org>
Acked-by: NWill Deacon <will.deacon@arm.com>

Adds a selftest function for the of_match_node function. of_match_node
is supposed to handle precedence for the compatible property as well as
the name and device_type values. This patch adds some test case data and
a function that makes sure each test node matches against the correct
entry of an of_device_id table.

This code was written to verify the new of_match_node() implementation
that is an earlier part of this series.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Cc: Kevin Hao <haokexin@gmail.com>

The testcase data is usable by any platform. This patch moves it into
the drivers/of directory so it can be included by any architecture.

Using the test cases requires manually adding #include <testcases.dtsi>
to the end of the boards .dtsi file and enabling CONFIG_OF_SELFTEST. Not
pretty though. A useful project would be to make the testcase code
easier to execute.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

In the current implementation of __of_match_node(), it will compare
each given match entry against all the node's compatible strings
with of_device_is_compatible().

To achieve multiple compatible strings per node with ordering from
specific to generic, this requires given matches to be ordered from
specific to generic. For most of the drivers this is not true and
also an alphabetical ordering is more sane there.

Therefore, we define a following priority order for the match, and
then scan all the entries to find the best match.
  1. specific compatible && type && name
  2. specific compatible && type
  3. specific compatible && name
  4. specific compatible
  5. general compatible && type && name
  6. general compatible && type
  7. general compatible && name
  8. general compatible
  9. type && name
  10. type
  11. name

v5: Fix nested locking bug
v4: Short-circuit failure cases instead of mucking with score, and
    remove extra __of_device_is_compatible() wrapper stub.
    Move scoring logic directly into __of_device_is_compatible()
v3: Also need to bail out when there does have a compatible member in match
    entry, but it doesn't match with the device node's compatible.
v2: Fix the bug such as we get the same score for the following two match
    entries with the empty node 'name2 { };'
	struct of_device_id matches[] = {
		{.name = "name2", },
		{.name = "name2", .type = "type1", },
		{}
	};
Signed-off-by: NKevin Hao <haokexin@gmail.com>
[grant.likely: added v4 changes]
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Tested-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Tested-by: NStephen Chivers <schivers@csc.com>
Tested-by: NSachin Kamat <sachin.kamat@linaro.org>

The snd_soc_dapm_xxxx_pin all require the dapm_mutex to be held when
they are called as they edit the dirty list, however very few of the
callers do so.

This patch adds unlocked versions of all the functions replacing the
existing implementations with one that holds the lock internally. We
also fix up the places where the lock was actually held on the caller
side.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take
it externally as well. This patch fixes this.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

This reverts commit 2d4054d8 (ACPI: Blacklist Win8 OSI for some HP
laptop 2013 models) that is not necessary any more after previous
commit 1811fcb029fa (ACPI / video: Add systems that should favour native
backlight interface).
Requested-by: NTakashi Iwai <tiwai@suse.de>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some system's ACPI video backlight control interface is broken and the
native backlight control interface should be used by default. This patch
sets the use_native_backlight parameter to true for those systems so
that video backlight control interface will not be created. For detailed
models that are added here, reference the following list.

Note that the user specified kernel cmdline option will always have the
highest priority, i.e. if use_native_backlight=0 is specified and the
system is in the DMI table, the video module will not skip registering
backlight interface for it.

Thinkpad T430s:
Reported-by: NTheodore Tso <tytso@mit.edu>
Reported-and-tested-by: NPeter Weber <bugs@ttyhoney.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Thinkpad X230:
Reported-and-tested-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=51231
ThinkPad X1 Carbon:
Reported-and-tested-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
Lenovo Yoga 13:
Reported-by: NLennart Poettering <lennart@poettering.net>
Reported-and-tested-by: NKevin Smith <thirdwiggin@gmail.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=63811
Dell Inspiron 7520:
Reported-by: NRinat Ibragimov <ibragimovrinat@mail.ru>
Acer Aspire 5733Z:
Reported-by: <sov.info@mail.ru>
References: https://bugzilla.kernel.org/show_bug.cgi?id=62941
Acer Aspire V5-431:
Reported-by: NThomas Christensen <christensenthomas@gmail.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=68751
HP ProBook 4340s:
Reported-and-tested-by: NVladimir Sherenkov <a_12300@mail.ru>
References: http://redmine.russianfedora.pro/issues/1258
HP EliteBook/ProBook 2013 models, ZBook and some others:
Provided-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some devices have duplicate entries in there brightness levels table, ie
on my Dell Latitude E6430 the table looks like this:

[    3.686060] acpi backlight index   0, val 80
[    3.686095] acpi backlight index   1, val 50
[    3.686122] acpi backlight index   2, val 5
[    3.686147] acpi backlight index   3, val 5
[    3.686172] acpi backlight index   4, val 5
[    3.686197] acpi backlight index   5, val 5
[    3.686223] acpi backlight index   6, val 5
[    3.686248] acpi backlight index   7, val 5
[    3.686273] acpi backlight index   8, val 6
[    3.686332] acpi backlight index   9, val 7
[    3.686356] acpi backlight index  10, val 8
[    3.686380] acpi backlight index  11, val 9
etc.

Notice that brightness values 0-5 are all mapped to 5. This means that
if userspace writes any value between 0 and 5 to the brightness sysfs attribute
and then reads it, it will always return 0, which is somewhat unexpected.

This is a problem for ie gnome-settings-daemon, which uses read-modify-write
logic when the users presses the brightness up or down keys. This is done
this way to take brightness changes from other sources into account.

On this specific laptop what happens once the brightness has been set to 0,
is that gsd reads 0, adds 5, writes 5, and on the next brightness up key press
again reads 0, so things get stuck at the lowest brightness setting.

Filtering out the duplicate table entries, makes any write to brightness
read back as the written value as one would expect, fixing this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If CONFIG_PM_SLEEP=n:

drivers/mfd/sec-core.c:349: warning: ‘sec_pmic_suspend’ defined but not used
drivers/mfd/sec-core.c:371: warning: ‘sec_pmic_resume’ defined but not used
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>