ACPI / sysfs: Fix incorrect ACPI tables walk in acpi_tables_sysfs_init()

When executing on an ACPI Hardware Reduced hardware, all the ACPI
tables are not exposed in sysfs due to the fact that FACS is
silently ignored by the kernel in the ACPI hardware reduced mode
and, moreover, the acpi_tables_sysfs_init() ACPI table walk
is buggy and stops too soon.

The acpi_tables_sysfs_init() function should rely on the acpi_status
return value from acpi_get_table_by_index() to decide whether or not
to stop the iteration (the walk should only be terminated when that
value is AE_BAD_PARAMETER).  This way, when running in an ACPI Harware
Reduced environment (where the FACS table is silently ignored by the
kernel) or if some ACPI tables are not correctly memory mapped or
have bad checksums, it will still walk through the remaining tables
that may be correct.

[rjw: Changelog]
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
regmap: make sure we unlock on failure in regmap_bulk_write

Signed-off-by: Courtney Cavin <courtney.cavin@sonymobile.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
drm/i915/ddi: set sink to power down mode on dp disable

Similar to
commit fdbc3b1f639bb2cbfb32c612b2699e0ba373317d
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Nov 12 17:10:13 2013 +0200

    drm/i915/dp: set sink to power down mode on dp disable

but for DDI, where we've never done this.

Signed-off-by: Jani Nikula <jani.nikula@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>
gpio: davinci: fix check for unbanked gpio

This patch fixes a check for offset in gpio_to_irq_unbanked()
and also assigns gpio_irq, gpio_unbanked of chips[0] to
appropriate values which is used in gpio_to_irq_unbanked()
function.

Without this patch, unbanked IRQ handling is broken.

Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: davinci: fix number of resources passed to davinci_gpio_register()

The davinci_gpio_register() function expects the number of
resources as the second parameter, but sizeof() resources
was passed to it due to which it was causing unexpected
behaviour. This patch fixes the same by passing the
ARRAY_SIZE() of resources.

Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
spi: core: invert success test in devm_spi_register_master

devres_add() should be called when the action to be undone succeeded,
not when it failed. Fix the inverted test in devm_spi_register_master()
which was doing the opposite.

The user-visible issue without this fix is:
insmod spi-tegra114.ko
  Assume there's an MTD device on that SPI bus, which creates /dev/mtd0.
rmmod spi-tegra114
  Doesn't remove devices on the SPI bus.
insmod spi-tegra114.ko
  Creates a duplicate SPI device which creates /dev/mtd1.
hexdump -C /dev/mtd0
  That's the old device, which uses an SPI bus hosted by a non-existent
  module, which causes the oops below.

Unable to handle kernel paging request at virtual address bf0017c0
pgd = c0004000
[bf0017c0] *pgd=ad51b811, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
...
PC is at 0xbf0017c0
LR is at spi_pump_messages+0x15c/0x204
pc : [<bf0017c0>] lr : [<c02f0af8>] psr: 60000113
...

Fixes: 666d5b4c742b ("spi: core: Add devm_spi_register_master()")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
ALSA: firewire-lib: fix wrong value for FDF field as an empty packet

This commit fix out of specification about the value of FDF field in out packet
with 'no data'. This affects blocking mode.

According to IEC 61883-6, there is two way to generate AMDTP packets include no
data in blocking mode.

Way 1. an empty packet defined in IEC 61883-1
 - Size of packet is 2 quadlets.
 - The value of FDF is sfc.
 - The packet includes only CIP headers

Way 2. a special non-empty packet defined in IEC 61883-6
 - Size of packet is following to blocking mode
 - The value of FDF is 0xff. This value is 'NO-DATA'. This means 'The receiver'
   must ignore all the data in a CIP with this FDF code'.
 - The packet includes dummy data.

But current implementation is a combination of them.
 - Size of packet is 2 (way 1)
 - FDF = 0xff (way 2)
This causes BeBoB chipset cannot sound.

This patch applies Way 1.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
time: Fix 1ns/tick drift w/ GENERIC_TIME_VSYSCALL_OLD

Since commit 1e75fa8be9f (time: Condense timekeeper.xtime
into xtime_sec - merged in v3.6), there has been an problem
with the error accounting in the timekeeping code, such that
when truncating to nanoseconds, we round up to the next nsec,
but the balancing adjustment to the ntp_error value was dropped.

This causes 1ns per tick drift forward of the clock.

In 3.7, this logic was isolated to only GENERIC_TIME_VSYSCALL_OLD
architectures (s390, ia64, powerpc).

The fix is simply to balance the accounting and to subtract the
added nanosecond from ntp_error. This allows the internal long-term
clock steering to keep the clock accurate.

While this fix removes the regression added in 1e75fa8be9f, the
ideal solution is to move away from GENERIC_TIME_VSYSCALL_OLD
and use the new VSYSCALL method, which avoids entirely the
nanosecond granular rounding, and the resulting short-term clock
adjustment oscillation needed to keep long term accurate time.

[ jstultz: Many thanks to Martin for his efforts identifying this
  	   subtle bug, and providing the fix. ]

Originally-from: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Paul Turner <pjt@google.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable <stable@vger.kernel.org>  #v3.6+
Link: http://lkml.kernel.org/r/1385149491-20307-1-git-send-email-john.stultz@linaro.org
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
cgroup: use a dedicated workqueue for cgroup destruction

Since be44562613851 ("cgroup: remove synchronize_rcu() from
cgroup_diput()"), cgroup destruction path makes use of workqueue.  css
freeing is performed from a work item from that point on and a later
commit, ea15f8ccdb430 ("cgroup: split cgroup destruction into two
steps"), moves css offlining to workqueue too.

As cgroup destruction isn't depended upon for memory reclaim, the
destruction work items were put on the system_wq; unfortunately, some
controller may block in the destruction path for considerable duration
while holding cgroup_mutex.  As large part of destruction path is
synchronized through cgroup_mutex, when combined with high rate of
cgroup removals, this has potential to fill up system_wq's max_active
of 256.

Also, it turns out that memcg's css destruction path ends up queueing
and waiting for work items on system_wq through work_on_cpu().  If
such operation happens while system_wq is fully occupied by cgroup
destruction work items, work_on_cpu() can't make forward progress
because system_wq is full and other destruction work items on
system_wq can't make forward progress because the work item waiting
for work_on_cpu() is holding cgroup_mutex, leading to deadlock.

This can be fixed by queueing destruction work items on a separate
workqueue.  This patch creates a dedicated workqueue -
cgroup_destroy_wq - for this purpose.  As these work items shouldn't
have inter-dependencies and mostly serialized by cgroup_mutex anyway,
giving high concurrency level doesn't buy anything and the workqueue's
@max_active is set to 1 so that destruction work items are executed
one by one on each CPU.

Hugh Dickins: Because cgroup_init() is run before init_workqueues(),
cgroup_destroy_wq can't be allocated from cgroup_init().  Do it from a
separate core_initcall().  In the future, we probably want to reorder
so that workqueue init happens before cgroup_init().

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Hugh Dickins <hughd@google.com>
Reported-by: Shawn Bohrer <shawn.bohrer@gmail.com>
Link: http://lkml.kernel.org/r/20131111220626.GA7509@sbohrermbp13-local.rgmadvisors.com
Link: http://lkml.kernel.org/g/alpine.LNX.2.00.1310301606080.2333@eggly.anvils
Cc: stable@vger.kernel.org # v3.9+
Merge branch 'next' into for-linus

Second round of input updates for 3.13.
ahci: add support for IBM Akebono platform device

The new IBM Akebono board has a PPC476GTR SoC with an AHCI compliant
SATA controller. This patch adds a compatible property for the new SoC
to the AHCI platform driver.

Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
pata_arasan_cf: add missing clk_disable_unprepare() on error path

Add the missing clk_disable_unprepare() before return from cf_init()
in the error handling case.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
powerpc/corenet64: compile with CONFIG_E{5,6}500_CPU well

If CONFIG_ALTIVEC is enabled for CoreNet64, and if we also
select CONFIG_E{5,6}500_CPU this may introduce -mcpu=e500mc64
into $CFLAGS. But Altivec option not allowed with e500mc64,
then some compiling errors occur like this:

      CC      arch/powerpc/lib/xor_vmx.o
    arch/powerpc/lib/xor_vmx.c:1:0: error: AltiVec not supported in this target
    make[1]: *** [arch/powerpc/lib/xor_vmx.o] Error 1
    make: *** [arch/powerpc/lib] Error 2

So we should restrict e500mc64 in altivec scenario.

Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
powerpc/8xx: mfspr SPRN_TBRx in lieu of mftb/mftbu is not supported

Commit beb2dc0a7a84be003ce54e98b95d65cc66e6e536 breaks the MPC8xx which
seems to not support using mfspr SPRN_TBRx instead of mftb/mftbu
despite what is written in the reference manual.

This patch reverts to the use of mftb/mftbu when CONFIG_8xx is
selected.

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Scott Wood <scottwood@freescale.com>
powerpc/85xx: typo in dts: "interupt" (four devices)

These lines were inoperative for four years, which puts some doubt into
their importance, and it's possible the fixed version will regress, but
at the very least they should be removed instead.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Scott Wood <scottwood@freescale.com>
powerpc/booke: Only check for hugetlb in flush if vma != NULL

And in flush_hugetlb_page(), don't check whether vma is NULL after
we've already dereferenced it.

This was found by Dan using static analysis as described here:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-November/113161.html

We currently get away with this because the callers that currently pass
NULL for vma seem to be 32-bit-only (e.g. highmem, and
CONFIG_DEBUG_PGALLOC in pgtable_32.c)  Hugetlb is currently 64-bit only,
so we never saw a NULL vma here.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
workqueue: swap set_cpus_allowed_ptr() and PF_NO_SETAFFINITY

Move the setting of PF_NO_SETAFFINITY up before set_cpus_allowed()
in create_worker(). Otherwise userland can change ->cpus_allowed
in between.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
workqueue: fix ordered workqueues in NUMA setups

An ordered workqueue implements execution ordering by using single
pool_workqueue with max_active == 1.  On a given pool_workqueue, work
items are processed in FIFO order and limiting max_active to 1
enforces the queued work items to be processed one by one.

Unfortunately, 4c16bd327c ("workqueue: implement NUMA affinity for
unbound workqueues") accidentally broke this guarantee by applying
NUMA affinity to ordered workqueues too.  On NUMA setups, an ordered
workqueue would end up with separate pool_workqueues for different
nodes.  Each pool_workqueue still limits max_active to 1 but multiple
work items may be executed concurrently and out of order depending on
which node they are queued to.

Fix it by using dedicated ordered_wq_attrs[] when creating ordered
workqueues.  The new attrs match the unbound ones except that no_numa
is always set thus forcing all NUMA nodes to share the default
pool_workqueue.

While at it, add sanity check in workqueue creation path which
verifies that an ordered workqueues has only the default
pool_workqueue.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Libin <huawei.libin@huawei.com>
Cc: stable@vger.kernel.org
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
workqueue: fix comment typo for __queue_work()

It seems the "dying" should be "draining" here.

Signed-off-by: Li Bin <huawei.libin@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
workqueue: fix pool ID allocation leakage and remove BUILD_BUG_ON() in init_workqueues

When one work starts execution, the high bits of work's data contain
pool ID. It can represent a maximum of WORK_OFFQ_POOL_NONE. Pool ID
is assigned WORK_OFFQ_POOL_NONE when the work being initialized
indicating that no pool is associated and get_work_pool() uses it to
check the associated pool. So if worker_pool_assign_id() assigns a
ID greater than or equal WORK_OFFQ_POOL_NONE to a pool, it triggers
leakage, and it may break the non-reentrance guarantee.

This patch fix this issue by modifying the worker_pool_assign_id()
function calling idr_alloc() by setting @end param WORK_OFFQ_POOL_NONE.

Furthermore, in the current implementation, the BUILD_BUG_ON() in
init_workqueues makes no sense. The number of worker pools needed
cannot be determined at compile time, because the number of backing
pools for UNBOUND workqueues is dynamic based on the assigned custom
attributes. So remove it.

tj: Minor comment and indentation updates.

Signed-off-by: Li Bin <huawei.libin@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>