mfd: wm8994: Export symbols ready for built-in => modular build

We'd like to be able to build the WM8994 family as modules, but the
build will fail if the external symbols aren't exported first.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: menelaus: Remove null pointer dereference

If vtg is NULL, it is not possible to access its mode_reg field. At all
sites where the static function menelaus_set_voltage is called, the first
argument is the address of a structure defined in the file. So, the null
test is unnecessary and is removed. Also, a label is done away with.

This problem was found using the following Coccinelle semantic match:

// <smpl>
@@
expression E, E1;
identifier f;
statement S1,S2,S3;
@@

* if (E == NULL)
{
  ... when != if (E == NULL) S1 else S2
      when != E = E1
* E->f
  ... when any
  return ...;
}
else S3
// </smpl>

Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: wm8994: Allow modular build

The interfaces that used to be built in only (interrupts IIRC) no longer
are so allow the driver to be built as a module fixing arm64 allmodconfig
builds.

Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: twl6040: Fix error return code

Convert a zero return value on error to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}

// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: rtsx_usb: Fix decimal printf format specifiers prefixed with 0x

The prefix suggests the number should be printed in hex, so use
the %x specifier to do that.

Found by using regex suggested by Joe Perches.

Signed-off-by: Hans Wennborg <hans@hanshq.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: wm5102: Mark register write sequencer control 3 readable

During init the core checks if the wm5102 has finished starting by reading
register 0x19 and looking at the value. This read always fails since this
is not a readable register, mark it as being one. While we're at it provide
a constant for the register name (as supplied by Charles Keepax).

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: arizona: Mark additional registers as volatile

Mark some additional registers as volatile. The write sequencer control
registers should not be cached, as we don't ever want their value
synchronised as this might cause a write sequence to be accidentally
initiated.

Additionally, the DAC_COMP registers require special preconditions to
write so there values wouldn't be updated accurately during a register
sync.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: arizona: Avoid use of legacy IRQ mapping

regmap_add_irq_chip is called from arizona_irq_init with the irq_base
specified as -1 and regmap_add_irq_chip uses if (irq_base) to check if
it should use legacy IRQ mapping. As such the irq mappings are currently
added with irq_domain_add_legacy, rather than irq_domain_add_linear.
This is clearly a typo as there is no reason why this driver can't use
irq_domain_add_linear.

This patch corrects this by passing the irq_base as zero to
regmap_add_irq_chip.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: menelaus: Fix error return code

Convert a zero return value on error to a negative one, as returned
elsewhere in the function.

Additionally, converted 1 << 7 to BIT(7) at the suggestion of Lee Jones.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}

// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: da9052-i2c: Remove duplicate test for I2C_FUNC_SMBUS_BYTE_DATA functionality

Since commit b42261078a91 ("regmap: i2c: fallback to SMBus if the adapter
does not support standard I2C"), regmap-i2c will check the
I2C_FUNC_SMBUS_[BYTE|WORD]_DATA functionality based on the regmap_config
setting if the adapter does not support standard I2C.

So remove the I2C_FUNC_SMBUS_BYTE_DATA functionality check in the driver code.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: lpc_ich: Add PCI ID for Intel Braswell

This is the same as used in Baytrail so add the new PCI ID to the driver's
list of supported IDs.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
CIFS: Fix wrong restart readdir for SMB1

The existing code calls server->ops->close() that is not
right. This causes XFS test generic/310 to fail. Fix this
by using server->ops->closedir() function.

Cc: <stable@vger.kernel.org> # v3.7+
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: Steve French <smfrench@gmail.com>
CIFS: Fix wrong filename length for SMB2

The existing code uses the old MAX_NAME constant. This causes
XFS test generic/013 to fail. Fix it by replacing MAX_NAME with
PATH_MAX that SMB1 uses. Also remove an unused MAX_NAME constant
definition.

Cc: <stable@vger.kernel.org> # v3.7+
Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: Steve French <smfrench@gmail.com>
Input: fix used slots detection breakage

Commit f8ec894945e7d205ce62be59e55e72c4304e4739 allowed external callers
use slot dropping logic, unfortunately it also broke external users of
input_mt_is_used() as we stopped incrementing frame count unless input
device was set up to automatically drop unused slots.

Fixes: f8ec894945e7d ("Input: MT - make slot cleanup callable outside
mt_sync_frame()")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=83081

Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Clarify Kconfig help text for CIFS and SMB2/SMB3

Clarify descriptions of SMB2 and SMB3 support in Kconfig

Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: Pavel Shilovsky <pshilovsky@samba.org>
ACPI / scan: Allow ACPI drivers to bind to PNP device objects

We generally don't allow ACPI drivers to bind to ACPI device objects
that companion "physical" device objects are created for to avoid
situations in which two different drivers may attempt to handle one
device at the same time.  Recent ACPI device enumeration rework
extended that approach to ACPI PNP devices by starting to use a scan
handler for enumerating them.  However, we previously allowed ACPI
drivers to bind to ACPI device objects with existing PNP device
companions and changing that led to functional regressions on some
systems.

For this reason, add a special check for PNP devices in
acpi_device_probe() so that ACPI drivers can bind to ACPI device
objects having existing PNP device companions as before.

Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81511
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971
Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-by: Dirk Griesbach <spamthis@freenet.de>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: Run fixed event device notifications in process context

Currently, notify callbacks for fixed button events are run from
interrupt context.  That is not necessary and after commit 0bf6368ee8f2
(ACPI / button: Add ACPI Button event via netlink routine) it causes
netlink routines to be called from interrupt context which is not
correct.

Also, that is different from non-fixed device events (including
non-fixed button events) whose notify callbacks are all executed from
process context.

For the above reasons, make fixed button device notify callbacks run
in process context which will avoid the deadlock when using netlink
to report button events to user space.

Fixes: 0bf6368ee8f2 (ACPI / button: Add ACPI Button event via netlink routine)
Link: https://lkml.org/lkml/2014/8/21/606
Reported-by: Benjamin Block <bebl@mageta.org>
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
[rjw: Function names, subject and changelog.]
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ext4: fix incorect journal credits reservation in ext4_zero_range

Currently we reserve only 4 blocks but in worst case scenario
ext4_zero_partial_blocks() may want to zeroout and convert two
non adjacent blocks.

Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
ACPI / OSL: Make acpi_os_map_cleanup() use call_rcu() to avoid deadlocks

Deadlock is possible when CPU hotplug and evaluating ACPI method happen
at the same time.

During CPU hotplug, acpi_cpu_soft_notify() is called under the CPU hotplug
lock.  Then, acpi_cpu_soft_notify() calls acpi_bus_get_device() to obtain
the struct acpi_device attached to the given ACPI handle.  The ACPICA's
namespace lock will be acquired by acpi_bus_get_device() in the process.
Thus it is possible to hold the ACPICA's namespace lock under the CPU
hotplug lock.

Evaluating an ACPI method may involve accessing an operation region in
system memory and the associated address space will be unmapped under
the ACPICA's namespace lock after completing the access. Currently, osl.c
uses RCU to protect memory ranges used by AML.  When unmapping them it
calls synchronize_rcu() in acpi_os_map_cleanup(), but that blocks
CPU hotplug by acquiring the CPU hotplug lock.  Thus it is possible to
hold the CPU hotplug lock under the ACPICA's namespace lock.

This leads to deadlocks like the following one if AML accessing operation
regions in memory is executed in parallel with CPU hotplug.

INFO: task bash:741 blocked for more than 30 seconds.
      Not tainted 3.16.0-rc5+ #671
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash            D ffff88014e214140     0   741    716 0x00000080
 ffff88009b9f3a10 0000000000000086 ffff88009dcfb840 ffff88009b9f3fd8
 0000000000014140 0000000000014140 ffffffff81c18460 ffffffff81c40fc8
 ffffffff81c40fcc ffff88009dcfb840 00000000ffffffff ffffffff81c40fd0
Call Trace:
 [<ffffffff817a1b29>] schedule_preempt_disabled+0x29/0x70
 [<ffffffff817a34fa>] __mutex_lock_slowpath+0xca/0x1c0
 [<ffffffff817a360f>] mutex_lock+0x1f/0x2f
 [<ffffffff810bc8cc>] get_online_cpus+0x2c/0x50
 [<ffffffff8111bbd4>] synchronize_sched_expedited+0x64/0x1c0
 [<ffffffff8111bb65>] synchronize_sched+0x45/0x50
 [<ffffffff81431498>] acpi_os_map_cleanup.part.7+0x14/0x3e
 [<ffffffff81795c54>] acpi_os_unmap_iomem+0xe2/0xea
 [<ffffffff81795c6a>] acpi_os_unmap_memory+0xe/0x14
 [<ffffffff814459bc>] acpi_ev_system_memory_region_setup+0x2d/0x97
 [<ffffffff81459504>] acpi_ut_update_ref_count+0x24d/0x2de
 [<ffffffff814596af>] acpi_ut_update_object_reference+0x11a/0x18b
 [<ffffffff81459282>] acpi_ut_remove_reference+0x2e/0x31
 [<ffffffff8144ffdf>] acpi_ns_detach_object+0x7b/0x80
 [<ffffffff8144ef11>] acpi_ns_delete_namespace_subtree+0x47/0x81
 [<ffffffff81440488>] acpi_ds_terminate_control_method+0x85/0x11b
 [<ffffffff81454625>] acpi_ps_parse_aml+0x164/0x289
 [<ffffffff81454da6>] acpi_ps_execute_method+0x1c1/0x26c
 [<ffffffff8144f764>] acpi_ns_evaluate+0x1c1/0x258
 [<ffffffff81451f86>] acpi_evaluate_object+0x126/0x22f
 [<ffffffff8144d1ac>] acpi_hw_execute_sleep_method+0x3d/0x68
 [<ffffffff8144d5cf>] ? acpi_hw_enable_all_runtime_gpes+0x17/0x19
 [<ffffffff8144deb0>] acpi_hw_legacy_wake+0x4d/0x9d
 [<ffffffff8144e599>] acpi_hw_sleep_dispatch+0x2a/0x2c
 [<ffffffff8144e5cb>] acpi_leave_sleep_state+0x17/0x19
 [<ffffffff8143335c>] acpi_pm_finish+0x3f/0x99
 [<ffffffff81108c49>] suspend_devices_and_enter+0x139/0x560
 [<ffffffff81109162>] pm_suspend+0xf2/0x370
 [<ffffffff81107e69>] state_store+0x79/0xf0
 [<ffffffff813bc4af>] kobj_attr_store+0xf/0x20
 [<ffffffff81284f3d>] sysfs_kf_write+0x3d/0x50
 [<ffffffff81284580>] kernfs_fop_write+0xe0/0x160
 [<ffffffff81210f47>] vfs_write+0xb7/0x1f0
 [<ffffffff81211ae6>] SyS_write+0x46/0xb0
 [<ffffffff8114d986>] ? __audit_syscall_exit+0x1f6/0x2a0
 [<ffffffff817a4ea9>] system_call_fastpath+0x16/0x1b
INFO: task async-enable-no:749 blocked for more than 30 seconds.
      Not tainted 3.16.0-rc5+ #671
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
async-enable-no D ffff88014e254140     0   749      2 0x00000080
 ffff88009de83bf0 0000000000000046 ffff88009b850000 ffff88009de83fd8
 0000000000014140 0000000000014140 ffff880148305dc0 ffff880149804160
 7fffffffffffffff 0000000000000002 0000000000000000 ffff88009b850000
Call Trace:
 [<ffffffff817a1689>] schedule+0x29/0x70
 [<ffffffff817a0b49>] schedule_timeout+0x1f9/0x270
 [<ffffffff81284bfe>] ? __kernfs_create_file+0x7e/0xa0
 [<ffffffff8128546b>] ? sysfs_add_file_mode_ns+0x9b/0x160
 [<ffffffff817a36b2>] __down_common+0x93/0xd8
 [<ffffffff817a376a>] __down_timeout+0x16/0x18
 [<ffffffff8110546c>] down_timeout+0x4c/0x60
 [<ffffffff81431f97>] acpi_os_wait_semaphore+0x43/0x57
 [<ffffffff8145a8f4>] acpi_ut_acquire_mutex+0x48/0x88
 [<ffffffff81435d1b>] ? acpi_match_device+0x4f/0x4f
 [<ffffffff8145250f>] acpi_get_data_full+0x3a/0x8e
 [<ffffffff81435b30>] acpi_bus_get_device+0x23/0x40
 [<ffffffff8145d839>] acpi_cpu_soft_notify+0x50/0xe6
 [<ffffffff810e1ddc>] notifier_call_chain+0x4c/0x70
 [<ffffffff810e1eee>] __raw_notifier_call_chain+0xe/0x10
 [<ffffffff810bc993>] cpu_notify+0x23/0x50
 [<ffffffff810bcb98>] _cpu_up+0x168/0x180
 [<ffffffff810bcc5c>] _cpu_up_with_trace+0x2c/0xe0
 [<ffffffff810bd050>] ? disable_nonboot_cpus+0x1c0/0x1c0
 [<ffffffff810bd06f>] async_enable_nonboot_cpus+0x1f/0x70
 [<ffffffff810dda02>] kthread+0xd2/0xf0
 [<ffffffff810dd930>] ? insert_kthread_work+0x40/0x40
 [<ffffffff817a4dfc>] ret_from_fork+0x7c/0xb0

To avoid such deadlocks, modify acpi_os_map_cleanup() to use call_rcu()
for the unmapping of memory regions that aren't used any more.

Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
[rjw: Subject and changelog.]
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set

There is a platform refusing to respond QR_EC when SCI_EVT isn't set
(Acer Aspire V5-573G).

Currently, we rely on the behaviour that the EC firmware can respond
something (for example, 0x00 to indicate "no outstanding events") to
QR_EC even when SCI_EVT is not set, but the reporter has complained
about AC/battery pluging/unpluging and video brightness change delay
on that platform.

This is because the work item that has issued QR_EC has to wait until
timeout in this case, and the _Qxx method evaluation work item queued
after QR_EC one is delayed.

It sounds reasonable to fix this issue by:
 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC
    driver's main state machine.
 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation
    to a seperate IRQ handling thread.

This patch fixes this issue using solution 1.

By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to
handle such platform in the EC driver's main state machine. This patch
enhances the state machine in this way to survive with such malfunctioning
EC firmware.

Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies
on the assumption that the platforms are able to respond even when SCI_EVT
isn't set.

Fixes: c0d653412fc8 ACPI / EC: Fix race condition in ec_transaction_completed()
Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>