Signed-off-by: NKent Overstreet <kmo@daterainc.com>

There's no point in blocking on these allocations, since our fallback paths will
probably go faster than blocking.

Change-Id: I733ca202c25cb36bde02607a0a60552229a4241c

this was very wrong - mempool_alloc() only guarantees success with GFP_WAIT.
bcache uses GFP_NOWAIT in various other places where we have a fallback,
circuits must've gotten crossed when writing this code or something.
Signed-off-by: NKent Overstreet <kmo@daterainc.com>

There were two issues here:

- writeback thread did not start until the device first became dirty
- writeback thread used uninterruptible sleep once running

Without this patch I see kernel warnings printed and a load average of
1.52 after booting my test VM. With this patch the warnings are gone and
the load average is near 0.00 as expected.
Signed-off-by: NKent Overstreet <kmo@daterainc.com>

Tested:
- sometimes bcache_tier test would hang on startup with a failure
  to allocate the btree root -- no longer seeing this
Signed-off-by: NKent Overstreet <kmo@daterainc.com>

We never started the writeback thread in this case, so don't stop it.

while loop was executing infinitely.
This fix ends the while loop gracefully.
Signed-off-by: NSurbhi Palande <sap@daterainc.com>
Signed-off-by: NKent Overstreet <kmo@daterainc.com>

journal replay wansn't validating pointers with bch_extent_invalid() before
derefing, fixed
Signed-off-by: NKent Overstreet <kmo@daterainc.com>

After detaching a backing device from a cache set, a bit wasn't getting
reset meaning the second detach wouldn't work correctly.
Signed-off-by: NKent Overstreet <kmo@daterainc.com>

On uniprocessor preemptible kernel, target core deadlocks on unload. The
following events happen:
* iscsit_del_np is called
* it calls send_sig(SIGINT, np->np_thread, 1);
* the scheduler switches to the np_thread
* the np_thread is woken up, it sees that kthread_should_stop() returns
  false, so it doesn't terminate
* the np_thread clears signals with flush_signals(current); and goes back
  to sleep in iscsit_accept_np
* the scheduler switches back to iscsit_del_np
* iscsit_del_np calls kthread_stop(np->np_thread);
* the np_thread is waiting in iscsit_accept_np and it doesn't respond to
  kthread_stop

The deadlock could be resolved if the administrator sends SIGINT signal to
the np_thread with killall -INT iscsi_np

The reproducible deadlock was introduced in commit
db6077fd, but the thread-stopping code was
racy even before.

This patch fixes the problem. Using kthread_should_stop to stop the
np_thread is unreliable, so we test np_thread_state instead. If
np_thread_state equals ISCSI_NP_THREAD_SHUTDOWN, the thread exits.
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch changes iscsit_check_dataout_hdr() to dump the incoming
Data-Out payload when the received ITT is not associated with a
WRITE, instead of calling iscsit_reject_cmd() for the non WRITE
ITT descriptor.

This addresses a bug where an initiator sending an Data-Out for
an ITT associated with a READ would end up generating a reject
for the READ, eventually resulting in list corruption.
Reported-by: NSantosh Kulkarni <santosh.kulkarni@calsoftinc.com>
Reported-by: NArshad Hussain <arshad.hussain@calsoftinc.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

In generic_id the long int timestamp is multiplied by 100000 and needs
an explicit cast to u64.

Without that the id in the resulting pstore filename is wrong and
userspace may have problems parsing it, but more importantly files in
pstore can never be deleted and may fill the EFI flash (brick device?).
This happens because when generic pstore code wants to delete a file,
it passes the id to the EFI backend which reinterpretes it and a wrong
variable name is attempted to be deleted.  There's no error message but
after remounting pstore, deleted files would reappear.
Signed-off-by: NAndrew Zaborowski <andrew.zaborowski@intel.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

This patch fixes a tcm_loop_cmd descriptor memory leak in the
tcm_loop_submission_work() error path, and would result in
warnings about leaked tcm_loop_cmd_cache objects at module
unload time.

Go ahead and invoke kmem_cache_free() to release tl_cmd back to
tcm_loop_cmd_cache before calling sc->scsi_done().
Reported-by: NSebastian Herbszt <herbszt@gmx.de>
Tested-by: NSebastian Herbszt <herbszt@gmx.de>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch adds a explicit memset to the login response PDU
exception path in iscsit_tx_login_rsp().

This addresses a regression bug introduced in commit baa4d64b
where the initiator would end up not receiving the login
response and associated status class + detail, before closing
the login connection.
Reported-by: NChristophe Vu-Brugier <cvubrugier@yahoo.fr>
Tested-by: NChristophe Vu-Brugier <cvubrugier@yahoo.fr>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes a left-over se_lun->lun_sep pointer OOPs when one
of the /sys/kernel/config/target/$FABRIC/$WWPN/$TPGT/lun/$LUN/alua*
attributes is accessed after the $DEVICE symlink has been removed.

To address this bug, go ahead and clear se_lun->lun_sep memory in
core_dev_unexport(), so that the existing checks for show/store
ALUA attributes in target_core_fabric_configfs.c work as expected.
Reported-by: NSebastian Herbszt <herbszt@gmx.de>
Tested-by: NSebastian Herbszt <herbszt@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch adds a check in chap_server_compute_md5() to enforce a
1024 byte maximum for the CHAP_C key value following the requirement
in RFC-3720 Section 11.1.4:

   "..., C and R are large-binary-values and their binary length (not
   the length of the character string that represents them in encoded
   form) MUST not exceed 1024 bytes."
Reported-by: Nrahul.rane <rahul.rane@calsoftinc.com>
Tested-by: Nrahul.rane <rahul.rane@calsoftinc.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch converts chap_server_compute_md5() from simple_strtoul() to
kstrtoul usage().

This addresses the case where a empty 'CHAP_I=' key value received during
mutual authentication would be converted to a '0' by simple_strtoul(),
instead of failing the login attempt.
Reported-by: NTejas Vaykole <tejas.vaykole@calsoftinc.com>
Tested-by: NTejas Vaykole <tejas.vaykole@calsoftinc.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

The AD8500 defines itself as interrupt-controller in DT,
but it doesn't assign DT node to IRQ domain when creates it.
As result, of_irq_xx() helpers don't work because they can't
find necessary IRQ domain.

Hence, fix it by assigning AD8500 core device DT node to IRQ
domain when it's created.

This patch fixes STE u8500 Snowball boot failure reported by Kevin Hilman
https://lkml.org/lkml/2014/5/27/624Reported-and-tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Without REGMAP_MMIO, building that driver results in a link error:

drivers/built-in.o: In function `davinci_vc_probe':
:(.init.text+0x3c1c): undefined reference to `devm_regmap_init_mmio_clk'

This adds a Kconfig 'select' statement as the usual way to ensure
that REGMAP_MMIO is enabled.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This driver depends on I2C, which may be a loadable module.
While you'd probably want both to be built-in in practice,
allowing a modular build avoids possible randconfig link
errors.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The UCB1200 / UCB1300 driver uses the MCP_SA11X0 driver, which
can be a loadable module, but this results in a link error
when UCB1200 itself is built-in:

drivers/built-in.o: In function `ucb1x00_io_set_dir':
:(.text+0x4a364): undefined reference to `mcp_reg_write'
drivers/built-in.o: In function `ucb1x00_io_write':
:(.text+0x4a3dc): undefined reference to `mcp_reg_write'
drivers/built-in.o: In function `ucb1x00_io_read':
:(.text+0x4a400): undefined reference to `mcp_reg_read'
drivers/built-in.o: In function `ucb1x00_adc_enable':
:(.text+0x4a460): undefined reference to `mcp_enable'
...

This can easily be resolved by making CONFIG_MCP_UCB1200 itself
a tristate option, since that causes Kconfig to track the
dependency correctly.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Make the TURBOchannel driver bail out if the call to device_register()
failed.
Signed-off-by: NLevente Kurusa <levex@linux.com>
Acked-by: NMaciej W. Rozycki <macro@linux-mips.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: Linux MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/6673/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

If the mdio probe function fails in emac_open, the interrupt we just requested
isn't freed. If emac_open is called again, for example because we try to set up
the interface again, the kernel will oops because the interrupt wasn't properly
released.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Cc: <stable@vger.kernel.org> # 3.11+
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 3f85944f ("net: Add sysfs file
for port number") introduce dev_port to network devices. cxgb4 adapters
have multiple ports on the same PCI function, and used dev_id to
identify those ports. That use was removed by commit
8c367fcb ("cxgb4: Do not set
net_device::dev_id to VI index"), since dev_id should be used only when
devices share the same MAC address.

Using dev_port for cxgb4 allows different ports on the same PCI function
to be identified.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The original code uses netdev->real_num_tx_queues to bookkeep number of
queues and invokes netif_set_real_num_tx_queues to set the number of
queues. However, netif_set_real_num_tx_queues doesn't allow
real_num_tx_queues to be smaller than 1, which means setting the number
to 0 will not work and real_num_tx_queues is untouched.

This is bogus when xenvif_free is invoked before any number of queues is
allocated. That function needs to iterate through all queues to free
resources. Using the wrong number of queues results in NULL pointer
dereference.

So we bookkeep the number of queues in xen-netback to solve this
problem. This fixes a regression introduced by multiqueue patchset in
3.16-rc1.

There's another bug in original code that the real number of RX queues
is never set. In current Xen multiqueue design, the number of TX queues
and RX queues are in fact the same. We need to set the numbers of TX and
RX queues to the same value.

Also remove xenvif_select_queue and leave queue selection to core
driver, as suggested by David Miller.
Reported-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: NWei Liu <wei.liu2@citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 506724c4 "tg3: Override clock,
link aware and link idle mode during NVRAM dump" changed the timeout
value for nvram command execution from 100ms to 1ms. But the 1ms
timeout value was only sufficient for nvram read operations but not
write operations for most of the devices supported by tg3 driver.
This patch sets the MAX to 50ms. Also it uses usleep_range instead
of udelay.
Signed-off-by: NPrashant Sreedharan <prashant@broadcom.com>
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Suggested-by: NDavid Miller <davem@davemloft.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since commit 648cd48c
The hwmon name attributes must not include '-' so the name must be
rename from gpio-fan to gpio_fan
Signed-off-by: NJulien D'Ascenzio <jdascenzio@yahoo.fr>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Discards don't have any payload.
But the scsi layer still expects a bio_vec it can use internally,
see sd_setup_discard_cmnd() and blk_add_request_payload().
Signed-off-by: NPhilipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: NLars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

In commit 4cab259f, the emc1403 driver was converted to use regmap but the
necessary Kconfig option was not added.
Signed-off-by: NJosef Gajdusek <atx@atx.name>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Murata Manufacturing Co., Ltd is the vendor for
NTC (Negative Temperature coefficient) based Thermistors.
But, the driver extensively uses "NTC" as the vendor name.

This patch corrects the vendor name also updates the
compatibility strings according to the vendor-prefix.txt

Note: Drivers continue to support the previous compatible strings
but further addition of these compatible strings in device tree
is deprecated.
Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Current code is buggy, it shows the current fan speed as minimum fan speed.
Fix up show_fan_reg macro to correctly report fan and fan_min speed.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NKevin Lo <kevlo@kevlo.org>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

AT91 symbols AT91SAM9263, AT91SAM9RL, and AT91SAM9G45 do not exist and this
patch changes them to their correct ARCH_* version.
These symbols are chosen instead of the SOC_* ones because this driver is not
converted to DT.
Anyway, the ATMEL_PWM symbol and the associated driver will be removed soon,
during the move to the PWM sub-system.
Reported-by: NPaul Bolle <pebolle@tiscali.nl>
Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

For MIPI, DSI PLL is configured separately in vlv_configure_dsi_pll
during the DSI enable sequence

Causing WARN dump otherwise in dpio_reads

v2: Add IS_CHERRYVIEW check as suggested by Ville
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If user uses wrong ioctl command with _IOC_NONE and argument size
greater than 0, it can cause NULL pointer access from memset of line
463. If _IOC_NONE, don't memset to 0 for kdata.
Signed-off-by: NZhaowei Yuan <zhaowei.yuan@samsung.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

cxgb4_netdev maybe lead to dead lock, since it uses a spin lock, and be called
in both thread and softirq context, but not disable BH, the lockdep report is
below; In fact, cxgb4_netdev only reads adap_rcu_list with RCU protection, so
not need to hold spin lock again.
	=================================
	[ INFO: inconsistent lock state ]
	3.14.7+ #24 Tainted: G         C O
	---------------------------------
	inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
	radvd/3794 [HC0[0]:SC1[1]:HE1:SE0] takes:
	 (adap_rcu_lock){+.?...}, at: [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4]
	{SOFTIRQ-ON-W} state was registered at:
	  [<ffffffff810fca81>] __lock_acquire+0x34a/0xe48
	  [<ffffffff810fd98b>] lock_acquire+0x82/0x9d
	  [<ffffffff815d6ff8>] _raw_spin_lock+0x34/0x43
	  [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4]
	  [<ffffffffa0998beb>] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4]
	  [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c
	  [<ffffffff815da9f9>] __atomic_notifier_call_chain+0x44/0x6e
	  [<ffffffff815daa32>] atomic_notifier_call_chain+0xf/0x11
	  [<ffffffff815b1356>] inet6addr_notifier_call_chain+0x16/0x18
	  [<ffffffffa01f72e5>] ipv6_add_addr+0x404/0x46e [ipv6]
	  [<ffffffffa01f8df0>] addrconf_add_linklocal+0x5f/0x95 [ipv6]
	  [<ffffffffa01fc3e9>] addrconf_notify+0x632/0x841 [ipv6]
	  [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c
	  [<ffffffff810e09a1>] __raw_notifier_call_chain+0x9/0xb
	  [<ffffffff810e09b2>] raw_notifier_call_chain+0xf/0x11
	  [<ffffffff8151b3b7>] call_netdevice_notifiers_info+0x4e/0x56
	  [<ffffffff8151b3d0>] call_netdevice_notifiers+0x11/0x13
	  [<ffffffff8151c0a6>] netdev_state_change+0x1f/0x38
	  [<ffffffff8152f004>] linkwatch_do_dev+0x3b/0x49
	  [<ffffffff8152f184>] __linkwatch_run_queue+0x10b/0x144
	  [<ffffffff8152f1dd>] linkwatch_event+0x20/0x27
	  [<ffffffff810d7bc0>] process_one_work+0x1cb/0x2ee
	  [<ffffffff810d7e3b>] worker_thread+0x12e/0x1fc
	  [<ffffffff810dd391>] kthread+0xc4/0xcc
	  [<ffffffff815dc48c>] ret_from_fork+0x7c/0xb0
	irq event stamp: 3388
	hardirqs last  enabled at (3388): [<ffffffff810c6c85>]
	__local_bh_enable_ip+0xaa/0xd9
	hardirqs last disabled at (3387): [<ffffffff810c6c2d>]
	__local_bh_enable_ip+0x52/0xd9
	softirqs last  enabled at (3288): [<ffffffffa01f1d5b>]
	rcu_read_unlock_bh+0x0/0x2f [ipv6]
	softirqs last disabled at (3289): [<ffffffff815ddafc>]
	do_softirq_own_stack+0x1c/0x30

	other info that might help us debug this:
	 Possible unsafe locking scenario:

	       CPU0
	       ----
	  lock(adap_rcu_lock);
	  <Interrupt>
	    lock(adap_rcu_lock);

	 *** DEADLOCK ***

	5 locks held by radvd/3794:
	 #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffffa020b85a>]
	rawv6_sendmsg+0x74b/0xa4d [ipv6]
	 #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff8151ac6b>]
	rcu_lock_acquire+0x0/0x29
	 #2:  (rcu_read_lock){.+.+..}, at: [<ffffffffa01f4cca>]
	rcu_lock_acquire.constprop.16+0x0/0x30 [ipv6]
	 #3:  (rcu_read_lock){.+.+..}, at: [<ffffffff810e09b4>]
	rcu_lock_acquire+0x0/0x29
	 #4:  (rcu_read_lock){.+.+..}, at: [<ffffffffa0998782>]
	rcu_lock_acquire.constprop.40+0x0/0x30 [cxgb4]

	stack backtrace:
	CPU: 7 PID: 3794 Comm: radvd Tainted: G         C O 3.14.7+ #24
	Hardware name: Supermicro X7DBU/X7DBU, BIOS 6.00 12/03/2007
	 ffffffff81f15990 ffff88012fdc36a8 ffffffff815d0016 0000000000000006
	 ffff8800c80dc2a0 ffff88012fdc3708 ffffffff815cc727 0000000000000001
	 0000000000000001 ffff880100000000 ffffffff81015b02 ffff8800c80dcb58
	Call Trace:
	 <IRQ>  [<ffffffff815d0016>] dump_stack+0x4e/0x71
	 [<ffffffff815cc727>] print_usage_bug+0x1ec/0x1fd
	 [<ffffffff81015b02>] ? save_stack_trace+0x27/0x44
	 [<ffffffff810fbfaa>] ? check_usage_backwards+0xa0/0xa0
	 [<ffffffff810fc640>] mark_lock+0x11b/0x212
	 [<ffffffff810fca0b>] __lock_acquire+0x2d4/0xe48
	 [<ffffffff810fbfaa>] ? check_usage_backwards+0xa0/0xa0
	 [<ffffffff810fbff6>] ? check_usage_forwards+0x4c/0xa6
	 [<ffffffff810c6c8a>] ? __local_bh_enable_ip+0xaf/0xd9
	 [<ffffffff810fd98b>] lock_acquire+0x82/0x9d
	 [<ffffffffa09989ea>] ? clip_add+0x2c/0x116 [cxgb4]
	 [<ffffffffa0998782>] ? rcu_read_unlock+0x23/0x23 [cxgb4]
	 [<ffffffff815d6ff8>] _raw_spin_lock+0x34/0x43
	 [<ffffffffa09989ea>] ? clip_add+0x2c/0x116 [cxgb4]
	 [<ffffffffa09987b0>] ? rcu_lock_acquire.constprop.40+0x2e/0x30 [cxgb4]
	 [<ffffffffa0998782>] ? rcu_read_unlock+0x23/0x23 [cxgb4]
	 [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4]
	 [<ffffffffa0998beb>] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4]
	 [<ffffffff810fd99d>] ? lock_acquire+0x94/0x9d
	 [<ffffffff810e09b4>] ? raw_notifier_call_chain+0x11/0x11
	 [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c
	 [<ffffffff815da9f9>] __atomic_notifier_call_chain+0x44/0x6e
	 [<ffffffff815daa32>] atomic_notifier_call_chain+0xf/0x11
	 [<ffffffff815b1356>] inet6addr_notifier_call_chain+0x16/0x18
	 [<ffffffffa01f72e5>] ipv6_add_addr+0x404/0x46e [ipv6]
	 [<ffffffff810fde6a>] ? trace_hardirqs_on+0xd/0xf
	 [<ffffffffa01fb634>] addrconf_prefix_rcv+0x385/0x6ea [ipv6]
	 [<ffffffffa0207950>] ndisc_rcv+0x9d3/0xd76 [ipv6]
	 [<ffffffffa020d536>] icmpv6_rcv+0x592/0x67b [ipv6]
	 [<ffffffff810c6c85>] ? __local_bh_enable_ip+0xaa/0xd9
	 [<ffffffff810c6c85>] ? __local_bh_enable_ip+0xaa/0xd9
	 [<ffffffff810fd8dc>] ? lock_release+0x14e/0x17b
	 [<ffffffffa020df97>] ? rcu_read_unlock+0x21/0x23 [ipv6]
	 [<ffffffff8150df52>] ? rcu_read_unlock+0x23/0x23
	 [<ffffffffa01f4ede>] ip6_input_finish+0x1e4/0x2fc [ipv6]
	 [<ffffffffa01f540b>] ip6_input+0x33/0x38 [ipv6]
	 [<ffffffffa01f5557>] ip6_mc_input+0x147/0x160 [ipv6]
	 [<ffffffffa01f4ba3>] ip6_rcv_finish+0x7c/0x81 [ipv6]
	 [<ffffffffa01f5397>] ipv6_rcv+0x3a1/0x3e2 [ipv6]
	 [<ffffffff8151ef96>] __netif_receive_skb_core+0x4ab/0x511
	 [<ffffffff810fdc94>] ? mark_held_locks+0x71/0x99
	 [<ffffffff8151f0c0>] ? process_backlog+0x69/0x15e
	 [<ffffffff8151f045>] __netif_receive_skb+0x49/0x5b
	 [<ffffffff8151f0cf>] process_backlog+0x78/0x15e
	 [<ffffffff8151f571>] ? net_rx_action+0x1a2/0x1cc
	 [<ffffffff8151f47b>] net_rx_action+0xac/0x1cc
	 [<ffffffff810c69b7>] ? __do_softirq+0xad/0x218
	 [<ffffffff810c69ff>] __do_softirq+0xf5/0x218
	 [<ffffffff815ddafc>] do_softirq_own_stack+0x1c/0x30
	 <EOI>  [<ffffffff810c6bb6>] do_softirq+0x38/0x5d
	 [<ffffffffa01f1d5b>] ? ip6_copy_metadata+0x156/0x156 [ipv6]
	 [<ffffffff810c6c78>] __local_bh_enable_ip+0x9d/0xd9
	 [<ffffffffa01f1d88>] rcu_read_unlock_bh+0x2d/0x2f [ipv6]
	 [<ffffffffa01f28b4>] ip6_finish_output2+0x381/0x3d8 [ipv6]
	 [<ffffffffa01f49ef>] ip6_finish_output+0x6e/0x73 [ipv6]
	 [<ffffffffa01f4a70>] ip6_output+0x7c/0xa8 [ipv6]
	 [<ffffffff815b1bfa>] dst_output+0x18/0x1c
	 [<ffffffff815b1c9e>] ip6_local_out+0x1c/0x21
	 [<ffffffffa01f2489>] ip6_push_pending_frames+0x37d/0x427 [ipv6]
	 [<ffffffff81558af8>] ? skb_orphan+0x39/0x39
	 [<ffffffffa020b85a>] ? rawv6_sendmsg+0x74b/0xa4d [ipv6]
	 [<ffffffffa020ba51>] rawv6_sendmsg+0x942/0xa4d [ipv6]
	 [<ffffffff81584cd2>] inet_sendmsg+0x3d/0x66
	 [<ffffffff81508930>] __sock_sendmsg_nosec+0x25/0x27
	 [<ffffffff8150b0d7>] sock_sendmsg+0x5a/0x7b
	 [<ffffffff810fd8dc>] ? lock_release+0x14e/0x17b
	 [<ffffffff8116d756>] ? might_fault+0x9e/0xa5
	 [<ffffffff8116d70d>] ? might_fault+0x55/0xa5
	 [<ffffffff81508cb1>] ? copy_from_user+0x2a/0x2c
	 [<ffffffff8150b70c>] ___sys_sendmsg+0x226/0x2d9
	 [<ffffffff810fcd25>] ? __lock_acquire+0x5ee/0xe48
	 [<ffffffff810fde01>] ? trace_hardirqs_on_caller+0x145/0x1a1
	 [<ffffffff8118efcb>] ? slab_free_hook.isra.71+0x50/0x59
	 [<ffffffff8115c81f>] ? release_pages+0xbc/0x181
	 [<ffffffff810fd99d>] ? lock_acquire+0x94/0x9d
	 [<ffffffff81115e97>] ? read_seqcount_begin.constprop.25+0x73/0x90
	 [<ffffffff8150c408>] __sys_sendmsg+0x3d/0x5b
	 [<ffffffff8150c433>] SyS_sendmsg+0xd/0x19
	 [<ffffffff815dc53d>] system_call_fastpath+0x1a/0x1f
Reported-by: NBen Greear <greearb@candelatech.com>
Cc: Casey Leedom <leedom@chelsio.com>
Cc: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Acked-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Correct the the config register for LDO1.

Fixes: 90e7d526 (regulator: tps65218: Add Regulator driver for
TPS65218 PMIC)
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: <stable@vger.kernel.org> # v3.15

Add the missing of_node assignment in probe.

Fixes: 90e7d526 (regulator: tps65218: Add Regulator driver for TPS65218 PMIC)
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: <stable@vger.kernel.org> # v3.15

mixer_wait_for_vblank function expects that the upcoming
vsync interrupt handler routine will clear the
wait_vsync_event atomic variable.

For this to happen, interrupts should be enabled and
disabled properly.
Signed-off-by: NRahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>