ARM: dts: omap3-beagle: Add omap-twl4030 audio support

This adds typical McBSP2-TWL4030 audio description to the legacy
Beagle Board.

Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: dts: omap4-sdp: Fix pin muxing for wl12xx

Mux mode for wlan/sdmmc5 should be MODE0 in pinmux_wl12xx_pins and
Enable Pull up on sdmmc5_clk to detect SDIO card.

This fixes WLAN on omap4-sdp that got broken in v3.10 when we
moved omap4 to boot using device tree only as I did not have
the WL12XX card in my omap4 SDP to test with. The commit that
attempted to make WL12XX working on omap4 SDP was 775d2418f309
(ARM: dts: Fix muxing and regulator for wl12xx on the SDIO
bus for blaze).

Signed-off-by: Balaji T K <balajitk@ti.com>
[tony@atomide.com: updated comments for the regression]
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx

pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core
and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core.

Fix the following error message:
pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_wl12xx_pins 56x

SDIO card is not detected after moving pin mux to omap4_pmx_core since
sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO card.

This fixes a regression where WLAN did not work after a warm reset
or after one up/down cycle that happened when we move omap4 to boot
using device tree only. For reference, the kernel bug is described at:

https://bugzilla.kernel.org/show_bug.cgi?id=63821

Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Balaji T K <balajitk@ti.com>
[tony@atomide.com: update comments to describe the regression]
Signed-off-by: Tony Lindgren <tony@atomide.com>

[SCSI] enclosure: fix WARN_ON in dual path device removing

Bug report from: wenxiong@linux.vnet.ibm.com

The issue is happened in dual controller configuration. We got the
sysfs warnings when rmmod the ipr module.

enclosure_unregister() in drivers/msic/enclosure.c, call device_unregister()
for each componment deivce, device_unregister() ->device_del()->kobject_del()
->sysfs_remove_dir(). In sysfs_remove_dir(), set kobj->sd = NULL.

For each componment device,
enclosure_component_release()->enclosure_remove_links()->sysfs_remove_link()
in which checking kobj->sd again, it has been set as NULL when doing
device_unregister. So we saw all these sysfs WARNING.

Tested-by: wenxiong@linux.vnet.ibm.com
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

[SCSI] pm80xx: Tasklets synchronization fix.

When multiple vectors are used, the vector variable is over written,
resulting in unhandled operation for those vectors.
This fix prevents the problem by maitaining HBA instance and
vector values for each irq.

[jejb: checkpatch fixes]
Signed-off-by: Nikith.Ganigarakoppal@pmcs.com
Signed-off-by: Anandkumar.Santhanam@pmcs.com
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

[SCSI] pm80xx: Resetting the phy state.

Setting the phy state for hard reset response.
After sending hard reset for a device ,phy down event sets
the phy state to zero but for phy up event it will not set
the phy state again.This will cause problem to successive
hard resets.

Signed-off-by: Nikith.Ganigarakoppal@pmcs.com
Signed-off-by: Anandkumar.Santhanam@pmcs.com
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

[SCSI] pm80xx: Fix for direct attached device.

In case of direct attached SATA device delay is not enough.
It will give crash for set device state command response and
wait_for_completion is the best solution for this.

Signed-off-by: Nikith.Ganigarakoppal@pmcs.com
Signed-off-by: Anandkumar.Santhanam@pmcs.com
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

[SCSI] pm80xx: Module author addition

Signed-off-by: Nikith.Ganigarakoppal@pmcs.com
Signed-off-by: Anandkumar.Santhanam@pmcs.com
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

Merge branch 'irq-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull irq fixes from Thomas Gleixner:
 - Correction of fuzzy and fragile IRQ_RETVAL macro
 - IRQ related resume fix affecting only XEN
 - ARM/GIC fix for chained GIC controllers

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip: Gic: fix boot for chained gics
  irq: Enable all irqs unconditionally in irq_resume
  genirq: Correct fuzzy and fragile IRQ_RETVAL() definition

Merge branch 'sched-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull scheduler fixes from Ingo Molnar:
 "Various smaller fixlets, all over the place"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/doc: Fix generation of device-drivers
  sched: Expose preempt_schedule_irq()
  sched: Fix a trivial typo in comments
  sched: Remove unused variable in 'struct sched_domain'
  sched: Avoid NULL dereference on sd_busy
  sched: Check sched_domain before computing group power
  MAINTAINERS: Update file patterns in the lockdep and scheduler entries

Merge branch 'perf-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull perf fixes from Ingo Molnar:
 "Misc kernel and tooling fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  tools lib traceevent: Fix conversion of pointer to integer of different size
  perf/trace: Properly use u64 to hold event_id
  perf: Remove fragile swevent hlist optimization
  ftrace, perf: Avoid infinite event generation loop
  tools lib traceevent: Fix use of multiple options in processing field
  perf header: Fix possible memory leaks in process_group_desc()
  perf header: Fix bogus group name
  perf tools: Tag thread comm as overriden

Merge tag 'stable/for-linus-3.13-rc2-tag' of git://git./linux/kernel/git/xen/tip

Pull Xen bug-fixes from Konrad Rzeszutek Wilk:
 "Fixes to patches that went in this merge window along with a latent
  bug:
   - Fix lazy flushing in case m2p override fails.
   - Fix module compile issues with ARM/Xen
   - Add missing call to DMA map page for Xen SWIOTLB for ARM"

* tag 'stable/for-linus-3.13-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/gnttab: leave lazy MMU mode in the case of a m2p override failure
  xen/arm: p2m_init and p2m_lock should be static
  arm/xen: Export phys_to_mach to fix Xen module link errors
  swiotlb-xen: add missing xen_dma_map_page call

Merge tag 'spi-v3.13-rc2' of git://git./linux/kernel/git/broonie/spi

Pull spi fixes from Mark Brown:
 "A smattering of driver specific fixes here, including a bunch for a
  long standing common pattern in the error handling paths, and a fix
  for an embarrassing thinko in the new devm master registration code"

* tag 'spi-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi/pxa2xx: Restore private register bits.
  spi/qspi: Fix qspi remove path.
  spi/qspi: cleanup pm_runtime error check.
  spi/qspi: set correct platform drvdata in ti_qspi_probe()
  spi/pxa2xx: add new ACPI IDs
  spi: core: invert success test in devm_spi_register_master
  spi: spi-mxs: fix reference leak to master in mxs_spi_remove()
  spi: bcm63xx: fix reference leak to master in bcm63xx_spi_remove()
  spi: txx9: fix reference leak to master in txx9spi_remove()
  spi: mpc512x: fix reference leak to master in mpc512x_psc_spi_do_remove()
  spi: rspi: use platform drvdata correctly in rspi_remove()
  spi: bcm2835: fix reference leak to master in bcm2835_spi_remove()

Merge git://git./linux/kernel/git/davem/net

Pull networking updates from David Miller:
 "Here is a pile of bug fixes that accumulated while I was in Europe"

 1) In fixing kernel leaks to userspace during copying of socket
    addresses, we broke a case that used to work, namely the user
    providing a buffer larger than the in-kernel generic socket address
    structure.  This broke Ruby amongst other things.  Fix from Dan
    Carpenter.

 2) Fix regression added by byte queue limit support in 8139cp driver,
    from Yang Yingliang.

 3) The addition of MSG_SENDPAGE_NOTLAST buggered up a few sendpage
    implementations, they should just treat it the same as MSG_MORE.
    Fix from Richard Weinberger and Shawn Landden.

 4) Handle icmpv4 errors received on ipv6 SIT tunnels correctly, from
    Oussama Ghorbel.  In particular we should send an ICMPv6 unreachable
    in such situations.

 5) Fix some regressions in the recent genetlink fixes, in particular
    get the pmcraid driver to use the new safer interfaces correctly.
    From Johannes Berg.

 6) macvtap was converted to use a per-cpu set of statistics, but some
    code was still bumping tx_dropped elsewhere.  From Jason Wang.

 7) Fix build failure of xen-netback due to missing include on some
    architectures, from Andy Whitecroft.

 8) macvtap double counts received packets in statistics, fix from Vlad
    Yasevich.

 9) Fix various cases of using *_STATS_BH() when *_STATS() is more
    appropriate.  From Eric Dumazet and Hannes Frederic Sowa.

10) Pktgen ipsec mode doesn't update the ipv4 header length and checksum
    properly after encapsulation.  Fix from Fan Du.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (61 commits)
  net/mlx4_en: Remove selftest TX queues empty condition
  {pktgen, xfrm} Update IPv4 header total len and checksum after tranformation
  virtio_net: make all RX paths handle erors consistently
  virtio_net: fix error handling for mergeable buffers
  virtio_net: Fixed a trivial typo (fitler --> filter)
  netem: fix gemodel loss generator
  netem: fix loss 4 state model
  netem: missing break in ge loss generator
  net/hsr: Support iproute print_opt ('ip -details ...')
  net/hsr: Very small fix of comment style.
  MAINTAINERS: Added net/hsr/ maintainer
  ipv6: fix possible seqlock deadlock in ip6_finish_output2
  ixgbe: Make ixgbe_identify_qsfp_module_generic static
  ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default
  ixgbe: ixgbe_fwd_ring_down needs to be static
  e1000: fix possible reset_task running after adapter down
  e1000: fix lockdep warning in e1000_reset_task
  e1000: prevent oops when adapter is being closed and reset simultaneously
  igb: Fixed Wake On LAN support
  inet: fix possible seqlock deadlocks
  ...

vfs: fix subtle use-after-free of pipe_inode_info

The pipe code was trying (and failing) to be very careful about freeing
the pipe info only after the last access, with a pattern like:

        spin_lock(&inode->i_lock);
        if (!--pipe->files) {
                inode->i_pipe = NULL;
                kill = 1;
        }
        spin_unlock(&inode->i_lock);
        __pipe_unlock(pipe);
        if (kill)
                free_pipe_info(pipe);

where the final freeing is done last.

HOWEVER.  The above is actually broken, because while the freeing is
done at the end, if we have two racing processes releasing the pipe
inode info, the one that *doesn't* free it will decrement the ->files
count, and unlock the inode i_lock, but then still use the
"pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".

This is *very* hard to trigger in practice, since the race window is
very small, and adding debug options seems to just hide it by slowing
things down.

Simon originally reported this way back in July as an Oops in
kmem_cache_allocate due to a single bit corruption (due to the final
"spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
allocation that had re-used the free'd pipe-info), it's taken this long
to figure out.

Since the 'pipe->files' accesses aren't even protected by the pipe lock
(we very much use the inode lock for that), the simple solution is to
just drop the pipe lock early.  And since there were two users of this
pattern, create a helper function for it.

Introduced commit ba5bb147330a ("pipe: take allocation and freeing of
pipe_inode_info out of ->i_mutex").

Reported-by: Simon Kirby <sim@hostway.ca>
Reported-by: Ian Applegate <ia@cloudflare.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org # v3.10+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

ALSA: hda - Use always amps for auto-mute on AD1986A codec

It seems that AD1986A cannot manage the dynamic pin on/off for
auto-muting, but rather gets confused.  Since each output has own amp,
let's use it instead.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971
Cc: <stable@vger.kernel.org> [v3.11+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/analog - Handle inverted EAPD properly in vmaster hook

ad_vmaster_eapd_hook() needs to handle the inverted EAPD case
properly, too.  Otherwise the output gets broken on Lenovo N100 with
AD1986A codec.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - Another fixup for ASUS laptop with ALC660 codec

ASUS Z35HL laptop also needs the very same fix as the previous one
that was applied to ASUS W7J.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66231
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: atmel: Fix possible array overflow

The static checker found a possible array overflow in atmel/abdac.c:
  static checker warning: "sound/atmel/abdac.c:373 set_sample_rates()
        error: buffer overflow 'dac->rates' 6 <= 6"

This patch papers over the buggy point, by ensuring that dac->rates[]
update not overflowing the actual array size.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ARM: at91: fixed unresolved symbol "at91_pm_set_standby" when built without CONFIG_PM

If CONFIG_PM is not defined, then arch/arm/mach-at91/pm.c is not
compiled in.  This patch creates an inline function that does nothing
if CONFIG_PM is not defined.

Signed-off-by: Brent Taylor <motobud@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>

ARM: at91: add usart3 alias to dtsi

Alias was missing for SoC of the at91sam9x5 familly that embed USART3.

Reported-by: Jiri Prchal <jiri.prchal@aksignal.cz>
[b.brezillon@overkiz.com: advised to place changes in at91sam9x5_usart3.dtsi]
Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>

ARM: at91: sama5d3: reduce TWI internal clock frequency

With some devices, transfer hangs during I2C frame transmission. This issue
disappears when reducing the internal frequency of the TWI IP. Even if it is
indicated that internal clock max frequency is 66MHz, it seems we have
oversampling on I2C signals making TWI believe that a transfer in progress
is done.

This fix has no impact on the I2C bus frequency.

Cc: <stable@vger.kernel.org> #3.10+
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>

ALSA: hda - Fix complete_all() timing in deferred probes

When the probe of snd-hda-intel driver is deferred due to f/w loading
or the nested module loading, complete_all() should be also delayed
until the initialization really finished.  Otherwise, vga-switcheroo
client would start switching before the actual init is done.

Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - Fix bad EAPD setup for HP machines with AD1984A

It seems that EAPD on NID 0x16 is the only control over all outputs on
HP machines with AD1984A while turning EAPD on NID 0x12 breaks the
output.  Thus we need to avoid fiddling EAPD on NID.  As a quick
workaround, just set own_eapd_ctrl flag for the wrong EAPD, then
implement finer EAPD controls.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66321
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: core: fix devres parameter in devm_snd_soc_register_card()

Since devm_card_release() expects parameter 'res' to be a pointer to
struct snd_soc_card, devm_snd_soc_register_card() should really pass
such a pointer rather than the one to struct device.

This bug causes the kernel Oops below with imx-sgtl500 driver when we
remove the module.  It happens because with 'card' pointing to the wrong
structure, card->num_rtd becomes 0 in function soc_remove_dai_links().
Consequently, soc_remove_link_components() and in turn
soc_cleanup_codec[platform]_debugfs() will not be called on card
removal.  It results in that debugfs_card_root is being removed while
its child entries debugfs_codec_root and debugfs_platform_root are still
there, and thus the kernel Oops.

Fix the bug by correcting the parameter 'res' to be the pointer to
struct snd_soc_card.

$ lsmod
Module                  Size  Used by
snd_soc_imx_sgtl5000     3506  0
snd_soc_sgtl5000       13677  2
snd_soc_imx_audmux      5324  1 snd_soc_imx_sgtl5000
snd_soc_fsl_ssi         8139  2
imx_pcm_dma             1380  1 snd_soc_fsl_ssi
$ rmmod snd_soc_imx_sgtl5000
Unable to handle kernel paging request at virtual address e594025c
pgd = be134000
[e594025c] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: snd_soc_imx_sgtl5000(-) snd_soc_sgtl5000 snd_soc_imx_audmux snd_soc_fsl_ssi imx_pcm_dma
CPU: 0 PID: 1793 Comm: rmmod Not tainted 3.13.0-rc1 #1570
task: bee28900 ti: bfbec000 task.ti: bfbec000
PC is at debugfs_remove_recursive+0x28/0x154
LR is at snd_soc_unregister_card+0xa0/0xcc
pc : [<80252b38>]    lr : [<80496ac4>]    psr: a0000013
sp : bfbede00  ip : bfbede28  fp : bfbede24
r10: 803281d4  r9 : bfbec000  r8 : 803271ac
r7 : bef54440  r6 : 00000004  r5 : bf9a4010  r4 : bf9a4010
r3 : e5940224  r2 : 00000000  r1 : bef54450  r0 : 803271ac
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c53c7d  Table: 4e13404a  DAC: 00000015
Process rmmod (pid: 1793, stack limit = 0xbfbec240)
Stack: (0xbfbede00 to 0xbfbee000)
de00: 00000000 bf9a4010 bf9a4010 00000004 bef54440 bec89000 bfbede44 bfbede28
de20: 80496ac4 80252b1c 804a4b60 bfbede60 bf9a4010 00000004 bfbede54 bfbede48
de40: 804a4b74 80496a30 bfbede94 bfbede58 80328728 804a4b6c bfbede94 a0000013
de60: bf1b5800 bef54440 00000002 bf9a4010 7f0169f8 bf9a4044 00000081 8000e9c4
de80: bfbec000 00000000 bfbedeac bfbede98 80328cb0 80328618 7f016000 bf9a4010
dea0: bfbedec4 bfbedeb0 8032561c 80328c84 bf9a4010 7f0169f8 bfbedee4 bfbedec8
dec0: 80325e84 803255a8 bee28900 7f0169f8 00000000 78208d30 bfbedefc bfbedee8
dee0: 80325410 80325dd4 beca8100 7f0169f8 bfbedf14 bfbedf00 803264f8 803253c8
df00: 7f01635c 7f016a3c bfbedf24 bfbedf18 80327098 803264d4 bfbedf34 bfbedf28
df20: 7f016370 80327090 bfbedfa4 bfbedf38 80085ef0 7f016368 bfbedf54 5f646e73
df40: 5f636f73 5f786d69 6c746773 30303035 00000000 78208008 bfbedf84 bfbedf68
df60: 800613b0 80061194 fffffffe 78208d00 7efc2f07 00000081 7f016a3c 00000800
df80: bfbedf84 00000000 00000000 fffffffe 78208d00 7efc2f07 00000000 bfbedfa8
dfa0: 8000e800 80085dcc fffffffe 78208d00 78208d30 00000800 a8c82400 a8c82400
dfc0: fffffffe 78208d00 7efc2f07 00000081 00000002 00000000 78208008 00000800
dfe0: 7efc2e1c 7efc2ba8 76f5ca47 76edec7c 80000010 78208d30 00000000 00000000
Backtrace:
[<80252b10>] (debugfs_remove_recursive+0x0/0x154) from [<80496ac4>] (snd_soc_unregister_card+0xa0/0xcc)
 r8:bec89000 r7:bef54440 r6:00000004 r5:bf9a4010 r4:bf9a4010
r3:00000000
[<80496a24>] (snd_soc_unregister_card+0x0/0xcc) from [<804a4b74>] (devm_card_release+0x14/0x18)
 r6:00000004 r5:bf9a4010 r4:bfbede60 r3:804a4b60
[<804a4b60>] (devm_card_release+0x0/0x18) from [<80328728>] (release_nodes+0x11c/0x1dc)
[<8032860c>] (release_nodes+0x0/0x1dc) from [<80328cb0>] (devres_release_all+0x38/0x54)
[<80328c78>] (devres_release_all+0x0/0x54) from [<8032561c>] (__device_release_driver+0x80/0xd4)
 r4:bf9a4010 r3:7f016000
[<8032559c>] (__device_release_driver+0x0/0xd4) from [<80325e84>] (driver_detach+0xbc/0xc0)
 r5:7f0169f8 r4:bf9a4010
[<80325dc8>] (driver_detach+0x0/0xc0) from [<80325410>] (bus_remove_driver+0x54/0x98)
 r6:78208d30 r5:00000000 r4:7f0169f8 r3:bee28900
[<803253bc>] (bus_remove_driver+0x0/0x98) from [<803264f8>] (driver_unregister+0x30/0x50)
 r4:7f0169f8 r3:beca8100
[<803264c8>] (driver_unregister+0x0/0x50) from [<80327098>] (platform_driver_unregister+0x14/0x18)
 r4:7f016a3c r3:7f01635c
[<80327084>] (platform_driver_unregister+0x0/0x18) from [<7f016370>] (imx_sgtl5000_driver_exit+0x14/0x1c [snd_soc_imx_sgtl5000])
[<7f01635c>] (imx_sgtl5000_driver_exit+0x0/0x1c [snd_soc_imx_sgtl5000]) from [<80085ef0>] (SyS_delete_module+0x130/0x18c)
[<80085dc0>] (SyS_delete_module+0x0/0x18c) from [<8000e800>] (ret_fast_syscall+0x0/0x48)
 r6:7efc2f07 r5:78208d00 r4:fffffffe
Code: 889da9f8 e5983020 e3530000 089da9f8 (e5933038)
---[ end trace 825e7e125251a225 ]---

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: omap: n810: Convert to clk_prepare_enable/clk_disable_unprepare

N810 audio driver has stopped working at some point. Probably when
OMAP2 was converted to common clock framework since now call to clk_enable
dumps the stack trace in drivers/clk/clk.c: __clk_enable() due
clk->prepare_count is zero.

Fix this by converting clk_enable/_disable calls to those that take care
of clock prepare/unprepare.

I'm not queueing this to linux-stable since OMAP2 common clock framework
conversion in commit ed1ebc4948fd ("ARM: OMAP2: clock: Convert to common clk")
happened before N810 was really usable in mainline and user base for N810 is
anyway small. Potential linux-stable candidates are only those after
commit 3d3a6d18abc6 ("watchdog: introduce retu_wdt driver").

Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: fsl: set correct platform drvdata in pcm030_fabric_probe()

platform_set_drvdata(op, pdata) in pcm030_fabric_probe()
will be overwrited when calling snd_soc_register_card(card),
but cm030_fabric_remove() use drvdata as a type of struct
pcm030_audio_data, so we should move platform_set_drvdata()
below snd_soc_register_card() call.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: fsl: imx-pcm-fiq: Remove unused 'runtime' variable

Commit 68f9672b (ASoC: fsl: imx-pcm-fiq: remove bogus period delta calculation)
introduced the following build warning:

sound/soc/fsl/imx-pcm-fiq.c:53:26: warning: unused variable 'runtime' [-Wunused-variable]

Remove the unused 'runtime' variable.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Oskar Schirmer <oskar@scara.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: fsl: imx-pcm-fiq: remove bogus period delta calculation

Originally snd_hrtimer_callback() used iprtd->period_time for
some jiffies based estimation to determine the right moment
to call snd_pcm_period_elapsed(). As timer drifts may well be a
problem, this was changed in commit b4e82b5b785670b6 to be based
on buffer transmission progress, using iprtd->offset and
runtime->buffer_size to calculate the amount of data since last
period had elapsed.

Unfortunately, iprtd->offset counts in bytes, while
runtime->buffer_size counts frames, so adding these to find some
delta is like comparing apples and oranges, and eventually results
in negative delta values every now and then. This is no big harm,
because it simply causes snd_pcm_period_elapsed() being called
more often than necessary, as negative delta is taken for a
large unsigned value by implicit conversion rule.
Nonetheless, the calculation is broken, so one would replace
the runtime->buffer_size by its equivalent in bytes.

But then, there are chances snd_pcm_period_elapsed() is called
late, because calculating the moment for the elapsed period
into delta is based against the iprtd->last_offset, which is not
necessarily the first byte of the period in question, but some
random byte which the FIQ handler left us with in r8/r9 by
accident. Again, negative impact is low, as there are plenty of
periods already prefilled with data, and snd_pcm_period_elapsed()
will probably be called latest when the following period is
reached. However, the calculation is conceptually broken, and we
are best off removing the clever stuff altogether.

snd_pcm_period_elapsed() is now simply called once everytime
snd_hrtimer_callback() is run, which may not be most accurate,
but at least this way we are quite sure we dont miss an end of
period. There is not much extra effort wasted by superfluous
calls to snd_pcm_period_elapsed(), as the timer frequency
closely matches the period size anyway.

Signed-off-by: Oskar Schirmer <oskar@scara.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

pinctrl: abx500: Fix header file include guard

Fix a trivial typo.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

net/mlx4_en: Remove selftest TX queues empty condition

Remove waiting for TX queues to become empty during selftest.
This check is not necessary for any purpose, and might put
the driver into an infinite loop.

Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

{pktgen, xfrm} Update IPv4 header total len and checksum after tranformation

commit a553e4a6317b2cfc7659542c10fe43184ffe53da ("[PKTGEN]: IPSEC support")
tried to support IPsec ESP transport transformation for pktgen, but acctually
this doesn't work at all for two reasons(The orignal transformed packet has
bad IPv4 checksum value, as well as wrong auth value, reported by wireshark)

- After transpormation, IPv4 header total length needs update,
  because encrypted payload's length is NOT same as that of plain text.

- After transformation, IPv4 checksum needs re-caculate because of payload
  has been changed.

With this patch, armmed pktgen with below cofiguration, Wireshark is able to
decrypted ESP packet generated by pktgen without any IPv4 checksum error or
auth value error.

pgset "flag IPSEC"
pgset "flows 1"

Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

virtio_net: make all RX paths handle erors consistently

receive mergeable now handles errors internally.
Do same for big and small packet paths, otherwise
the logic is too hard to follow.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

virtio_net: fix error handling for mergeable buffers

Eric Dumazet noticed that if we encounter an error
when processing a mergeable buffer, we don't
dequeue all of the buffers from this packet,
the result is almost sure to be loss of networking.

Jason Wang noticed that we also leak a page and that we don't decrement
the rq buf count, so we won't repost buffers (a resource leak).

Fix both issues.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michael Dalton <mwdalton@google.com>
Reported-by: Eric Dumazet <edumazet@google.com>
Reported-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'for-linus' of git://git./linux/kernel/git/rw/uml

Pull UML fixes from Richard Weinberger:
 "Fixes two regressions which got introduced this merge window"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml:
  um: Build always with -mcmodel=large on 64bit
  um: Rename print_stack_trace to do_stack_trace

Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

Pull ARM fixes from Russell King:
 "Some ARM fixes, the biggest of which is the fix for the signal return
  codes; this came up due to an interaction between the V7M nommu
  changes and the BE8 changes.  Dave Martin spotted that the kexec
  trampoline wasn't being correctly copied (in a way which allows
  Thumb-2 to work).

  I've also fixed a number of breakages on footbridge platforms as I've
  upgraded one of my machines to v3.12...  one which had a 1200 day
  uptime"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 7907/1: lib: delay-loop: Add align directive to fix BogoMIPS calculation
  ARM: 7897/1: kexec: Use the right ISA for relocate_new_kernel
  ARM: 7895/1: signal: fix armv7-m build issue in sigreturn_codes.S
  ARM: footbridge: fix EBSA285 LEDs
  ARM: footbridge: fix VGA initialisation
  ARM: fix booting low-vectors machines
  ARM: dma-mapping: check DMA mask against available memory

um: Build always with -mcmodel=large on 64bit

On UML SUBARCH can be x86, x86_64 and i386 and if it is x86
we use uname -m to select a defconfig.
Therefore we can no longer use -mcmodel=large only if SUBARCH
is x86_64.

Reported-and-tested-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: Richard Weinberger <richard@nod.at>

um: Rename print_stack_trace to do_stack_trace

We cannot use print_stack_trace because the name conflicts
with linux/stacktrace.h.

Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Richard Weinberger <richard@nod.at>

[SCSI] hpsa: return 0 from driver probe function on success, not 1

A return value of 1 is interpreted as an error.  See pci_driver.
in local_pci_probe().  If you're wondering how this ever could
have worked, it's because it used to be the case that only return
values less than zero were interpreted as failure.  But even in
the current kernel if the driver registers its various entry
points with the kernel, and then returns a value which is
interpreted as failure, those registrations aren't undone, so
the driver still mostly works.  However, the driver's remove
function wouldn't be called on rmmod, and pci power management
functions wouldn't work.  In the case of Smart Array, since it
has a battery backed cache (or else no cache) even if the driver
is not shut down properly as long as there is no outstanding
i/o, nothing too bad happens, which is why it took so long to
notice.

Requesting backport to stable because the change to pci-driver.c
which requires driver probe functions to return 0 occurred between
2.6.35 and 2.6.36 (the pci power management breakage) and again
between 3.7 and 3.8 (pci_dev->driver getting set to NULL in
local_pci_probe() preventing driver remove function from being
called on rmmod.)

Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

ARM: 7907/1: lib: delay-loop: Add align directive to fix BogoMIPS calculation

Currently mx53 (CortexA8) running at 1GHz reports:
Calibrating delay loop... 663.55 BogoMIPS (lpj=3317760)

Tom Evans verified that alignments of 0x0 and 0x8 run the two instructions of __loop_delay in one clock cycle (1 clock/loop), while alignments of 0x4 and 0xc take 3 clocks to run the loop twice. (1.5 clock/loop)

The original object code looks like this:

00000010 <__loop_const_udelay>:
  10: e3e01000  mvn r1, #0
  14: e51f201c  ldr r2, [pc, #-28] ; 0 <__loop_udelay-0x8>
  18: e5922000  ldr r2, [r2]
  1c: e0800921  add r0, r0, r1, lsr #18
  20: e1a00720  lsr r0, r0, #14
  24: e0822b21  add r2, r2, r1, lsr #22
  28: e1a02522  lsr r2, r2, #10
  2c: e0000092  mul r0, r2, r0
  30: e0800d21  add r0, r0, r1, lsr #26
  34: e1b00320  lsrs r0, r0, #6
  38: 01a0f00e  moveq pc, lr

0000003c <__loop_delay>:
  3c: e2500001  subs r0, r0, #1
  40: 8afffffe  bhi 3c <__loop_delay>
  44: e1a0f00e  mov pc, lr

After adding the 'align 3' directive to __loop_delay (align to 8 bytes):

00000010 <__loop_const_udelay>:
  10: e3e01000  mvn r1, #0
  14: e51f201c  ldr r2, [pc, #-28] ; 0 <__loop_udelay-0x8>
  18: e5922000  ldr r2, [r2]
  1c: e0800921  add r0, r0, r1, lsr #18
  20: e1a00720  lsr r0, r0, #14
  24: e0822b21  add r2, r2, r1, lsr #22
  28: e1a02522  lsr r2, r2, #10
  2c: e0000092  mul r0, r2, r0
  30: e0800d21  add r0, r0, r1, lsr #26
  34: e1b00320  lsrs r0, r0, #6
  38: 01a0f00e  moveq pc, lr
  3c: e320f000  nop {0}

00000040 <__loop_delay>:
  40: e2500001  subs r0, r0, #1
  44: 8afffffe  bhi 40 <__loop_delay>
  48: e1a0f00e  mov pc, lr
  4c: e320f000  nop {0}

, which now reports:
Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)

Some more test results:

On mx31 (ARM1136) running at 532 MHz, before the patch:
Calibrating delay loop... 351.43 BogoMIPS (lpj=1757184)

On mx31 (ARM1136) running at 532 MHz after the patch:
Calibrating delay loop... 528.79 BogoMIPS (lpj=2643968)

Also tested on mx6 (CortexA9) and on mx27 (ARM926), which shows the same
BogoMIPS value before and after this patch.

Reported-by: Tom Evans <tom_usenet@optusnet.com.au>
Suggested-by: Tom Evans <tom_usenet@optusnet.com.au>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7897/1: kexec: Use the right ISA for relocate_new_kernel

Copying a function with memcpy() and then trying to execute the
result isn't trivially portable to Thumb.

This patch modifies the kexec soft restart code to copy its
assembler trampoline relocate_new_kernel() using fncpy() instead,
so that relocate_new_kernel can be in the same ISA as the rest of
the kernel without problems.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Reported-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Tested-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7895/1: signal: fix armv7-m build issue in sigreturn_codes.S

After "ARM: signal: sigreturn_codes should be endian neutral to
work in BE8" commit, thumb only platforms, like armv7m, fails to
compile sigreturn_codes.S. The reason is that for such arch
values '.arm' directive and arm opcodes are not allowed.

Fix conditionally enables arm opcodes only if no CONFIG_CPU_THUMBONLY
defined and it uses .org instructions to keep sigreturn_codes
layout.

Suggested-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: footbridge: fix EBSA285 LEDs

- The LEDs register is write-only: it can't be read-modify-written.
- The LEDs are write-1-for-off not 0.
- The check for the platform was inverted.

Fixes: cf6856d693dd ("ARM: mach-footbridge: retire custom LED code")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: stable@vger.kernel.org

[SCSI] hpsa: do not discard scsi status on aborted commands

We inadvertantly discarded the scsi status for aborted commands.
For some commands (e.g. reads from tape drives) these can't be retried,
and if we discarded the scsi status, the scsi mid layer couldn't notice
anything was wrong and the error was not reported.

Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

parisc: remove CONFIG_MLONGCALLS=y from defconfigs

Signed-off-by: Helge Deller <deller@gmx.de>

virtio_net: Fixed a trivial typo (fitler --> filter)

"MAC filter" sounds more reasonable than "MAC fitler".

Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

parisc: fix kernel memory layout in vmlinux.ld.S

When building a 64bit kernel sometimes functions in the .init section were not
able to reach the standard kernel function. Main reason for this problem is,
that the linkage tables (.plt, .opd, .dlt) tend to become pretty huge and thus
the distance gets too big for short calls.

One option to avoid this is to use the -mlong-calls compiler option, but this
increases the binary size and introduces a performance penalty.

Instead, with this patch we just lay out the binary differently.  Init code is
stored first, followed by text, R/O and finally R/W data. This means, that init
and text code is now much closer to each other, which is sufficient to reach
each other by short calls.

Signed-off-by: Helge Deller <deller@gmx.de>

parisc: use kernel_text_address() in unwind functions

Signed-off-by: Helge Deller <deller@gmx.de>

parisc: remove empty SERIAL_PORT_DFNS in serial.h

If architectures don't support SERIAL_PORT_DFNS, they need not define it
to "nothing", the related drivers need do it by themselves (e.g.  8250
serial driver).

Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Helge Deller <deller@gmx.de>

parisc: add some more machine names to hardware database

Sadly the correct names for machines which end with a question-mark aren't
known, so let's give it a best-guessed-name.

Signed-off-by: Helge Deller <deller@gmx.de>

parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address

locale-gen on Debian showed a strange problem on parisc:
mmap2(NULL, 536870912, PROT_NONE, MAP_SHARED, 3, 0) = 0x42a54000
mmap2(0x42a54000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)

Basically it was just trying to re-mmap() a file at the same address
which it was given by a previous mmap() call. But this remapping failed
with EINVAL.

The problem is, that when MAP_FIXED and MAP_SHARED flags were used, we didn't
included the mapping-based offset when we verified the alignment of the given
fixed address against the offset which we calculated it in the previous call.

Signed-off-by: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # 3.10+

netem: fix gemodel loss generator

Patch from developers of the alternative loss models, downloaded from:
   http://netgroup.uniroma2.it/twiki/bin/view.cgi/Main/NetemCLG

 "in case 2, of the switch we change the direction of the inequality to
  net_random()>clg->a3, because clg->a3 is h in the GE model and when h
  is 0 all packets will be lost."

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

netem: fix loss 4 state model

Patch from developers of the alternative loss models, downloaded from:
   http://netgroup.uniroma2.it/twiki/bin/view.cgi/Main/NetemCLG

 "In the case 1 of the switch statement in the if conditions we
   need to add clg->a4 to clg->a1, according to the model."

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

netem: missing break in ge loss generator

There is a missing break statement in the Gilbert Elliot loss model
generator which makes state machine behave incorrectly.

Reported-by: Martin Burri <martin.burri@ch.abb.com
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

net/hsr: Support iproute print_opt ('ip -details ...')

This implements the rtnl_link_ops fill_info routine for HSR.

Signed-off-by: Arvid Brodin <arvid.brodin@alten.se>
Signed-off-by: David S. Miller <davem@davemloft.net>

net/hsr: Very small fix of comment style.

Signed-off-by: Arvid Brodin <arvid.brodin@alten.se>
Signed-off-by: David S. Miller <davem@davemloft.net>

MAINTAINERS: Added net/hsr/ maintainer

Signed-off-by: Arvid Brodin <arvid.brodin@alten.se>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: fix possible seqlock deadlock in ip6_finish_output2

IPv6 stats are 64 bits and thus are protected with a seqlock. By not
disabling bottom-half we could deadlock here if we don't disable bh and
a softirq reentrantly updates the same mib.

Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'master' of git://git./linux/kernel/git/jkirsher/net

Jeff Kirsher says:

====================
Intel Wired LAN Driver Updates

This series contains updates to igb, e1000 and ixgbe.

Akeem provides a igb fix where WOL was being reported as supported on
some ethernet devices which did not have that capability.

Yanjun provides a fix for e1000 which is similar to a previous fix
for e1000e commit bb9e44d0d0f4 ("e1000e: prevent oops when adapter is
being closed and reset simultaneously"), where the same issue was
observed on the older e1000 cards.

Vladimir Davydov provides 2 e1000 fixes.  The first fixes a lockdep
warning e1000_down() tries to synchronously cancel e1000 auxiliary
works (reset_task, watchdog_task, phy_info_task and fifo_stall_task)
which take adapter->mutex in their handlers.  The second patch is to
fix a possible race condition where reset_task() would be running
after adapter down.

John provides 2 fixes for ixgbe.  First turns ixgbe_fwd_ring_down
to static and the second disables NETIF_F_HW_L2FW_DOFFLOAD by default
because it allows upper layer net devices to use queues in the hardware
to directly submit and receive skbs.

Mark Rustad provides a single patch for ixgbe to make
ixgbe_identify_qsfp_module_generic static to resolve compile
warnings.

v2: Drop igb patch "igb: Update queue reinit function to call dev_close
    when init of queues fails" from Carolyn, so that the solution can
    be re-worked based on feedback from David Miller.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

ARM: footbridge: fix VGA initialisation

It's no good setting vga_base after the VGA console has been
initialised, because if we do that we get this:

Unable to handle kernel paging request at virtual address 000b8000
pgd = c0004000
[000b8000] *pgd=07ffc831, *pte=00000000, *ppte=00000000
0Internal error: Oops: 5017 [#1] ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0+ #49
task: c03e2974 ti: c03d8000 task.ti: c03d8000
PC is at vgacon_startup+0x258/0x39c
LR is at request_resource+0x10/0x1c
pc : [<c01725d0>]    lr : [<c0022b50>]    psr: 60000053
sp : c03d9f68  ip : 000b8000  fp : c03d9f8c
r10: 000055aa  r9 : 4401a103  r8 : ffffaa55
r7 : c03e357c  r6 : c051b460  r5 : 000000ff  r4 : 000c0000
r3 : 000b8000  r2 : c03e0514  r1 : 00000000  r0 : c0304971
Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel

which is an access to the 0xb8000 without the PCI offset required to
make it work.

Fixes: cc22b4c18540 ("ARM: set vga memory base at run-time")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: <stable@vger.kernel.org>

ARM: fix booting low-vectors machines

Commit f6f91b0d9fd9 (ARM: allow kuser helpers to be removed from the
vector page) required two pages for the vectors code.  Although the
code setting up the initial page tables was updated, the code which
allocates page tables for new processes wasn't, neither was the code
which tears down the mappings.  Fix this.

Fixes: f6f91b0d9fd9 ("ARM: allow kuser helpers to be removed from the vector page")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: <stable@vger.kernel.org>

ARM: dma-mapping: check DMA mask against available memory

Some buses have negative offsets, which causes the DMA mask checks to
falsely fail.  Fix this by using the actual amount of memory fitted in
the system.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ixgbe: Make ixgbe_identify_qsfp_module_generic static

Correct a namespace complaint by making the function static
and moving the prototype into the .c file.

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default

NETIF_F_HW_L2FW_DOFFLOAD allows upper layer net devices such
as macvlan to use queues in the hardware to directly submit and
receive skbs.

This creates a subtle change in the datapath though. One change
being the skb may no longer use the root devices qdisc.

Because users may not expect this we can't enable the feature
by default unless the hardware can offload all the software
functionality above it. So for now disable it by default and
let users opt in.

Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

ixgbe: ixgbe_fwd_ring_down needs to be static

When compiling with -Wstrict-prototypes gcc catches a static
I missed.

./ixgbe_main.c:4254: warning: no previous prototype for 'ixgbe_fwd_ring_down'

Reported-by: Phillip Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

e1000: fix possible reset_task running after adapter down

On e1000_down(), we should ensure every asynchronous work is canceled
before proceeding. Since the watchdog_task can schedule other works
apart from itself, it should be stopped first, but currently it is
stopped after the reset_task. This can result in the following race
leading to the reset_task running after the module unload:

e1000_down_and_stop(): e1000_watchdog():
---------------------- -----------------

cancel_work_sync(reset_task)
schedule_work(reset_task)
cancel_delayed_work_sync(watchdog_task)

The patch moves cancel_delayed_work_sync(watchdog_task) at the beginning
of e1000_down_and_stop() thus ensuring the race is impossible.

Cc: Tushar Dave <tushar.n.dave@intel.com>
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

e1000: fix lockdep warning in e1000_reset_task

The patch fixes the following lockdep warning, which is 100%
reproducible on network restart:

======================================================
[ INFO: possible circular locking dependency detected ]
3.12.0+ #47 Tainted: GF
-------------------------------------------------------
kworker/1:1/27 is trying to acquire lock:
 ((&(&adapter->watchdog_task)->work)){+.+...}, at: [<ffffffff8108a5b0>] flush_work+0x0/0x70

but task is already holding lock:
 (&adapter->mutex){+.+...}, at: [<ffffffffa0177c0a>] e1000_reset_task+0x4a/0xa0 [e1000]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&adapter->mutex){+.+...}:
       [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
       [<ffffffff816b8cbc>] mutex_lock_nested+0x4c/0x390
       [<ffffffffa017233d>] e1000_watchdog+0x7d/0x5b0 [e1000]
       [<ffffffff8108b972>] process_one_work+0x1d2/0x510
       [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
       [<ffffffff81092c1e>] kthread+0xee/0x110
       [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0

-> #0 ((&(&adapter->watchdog_task)->work)){+.+...}:
       [<ffffffff810bd9c0>] __lock_acquire+0x1710/0x1810
       [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
       [<ffffffff8108a5eb>] flush_work+0x3b/0x70
       [<ffffffff8108b5d8>] __cancel_work_timer+0x98/0x140
       [<ffffffff8108b693>] cancel_delayed_work_sync+0x13/0x20
       [<ffffffffa0170cec>] e1000_down_and_stop+0x3c/0x60 [e1000]
       [<ffffffffa01775b1>] e1000_down+0x131/0x220 [e1000]
       [<ffffffffa0177c12>] e1000_reset_task+0x52/0xa0 [e1000]
       [<ffffffff8108b972>] process_one_work+0x1d2/0x510
       [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
       [<ffffffff81092c1e>] kthread+0xee/0x110
       [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&adapter->mutex);
                               lock((&(&adapter->watchdog_task)->work));
                               lock(&adapter->mutex);
  lock((&(&adapter->watchdog_task)->work));

 *** DEADLOCK ***

3 locks held by kworker/1:1/27:
 #0:  (events){.+.+.+}, at: [<ffffffff8108b906>] process_one_work+0x166/0x510
 #1:  ((&adapter->reset_task)){+.+...}, at: [<ffffffff8108b906>] process_one_work+0x166/0x510
 #2:  (&adapter->mutex){+.+...}, at: [<ffffffffa0177c0a>] e1000_reset_task+0x4a/0xa0 [e1000]

stack backtrace:
CPU: 1 PID: 27 Comm: kworker/1:1 Tainted: GF            3.12.0+ #47
Hardware name: System manufacturer System Product Name/P5B-VM SE, BIOS 0501    05/31/2007
Workqueue: events e1000_reset_task [e1000]
 ffffffff820f6000 ffff88007b9dba98 ffffffff816b54a2 0000000000000002
 ffffffff820f5e50 ffff88007b9dbae8 ffffffff810ba936 ffff88007b9dbac8
 ffff88007b9dbb48 ffff88007b9d8f00 ffff88007b9d8780 ffff88007b9d8f00
Call Trace:
 [<ffffffff816b54a2>] dump_stack+0x49/0x5f
 [<ffffffff810ba936>] print_circular_bug+0x216/0x310
 [<ffffffff810bd9c0>] __lock_acquire+0x1710/0x1810
 [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
 [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
 [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
 [<ffffffff8108a5eb>] flush_work+0x3b/0x70
 [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
 [<ffffffff8108b5d8>] __cancel_work_timer+0x98/0x140
 [<ffffffff8108b693>] cancel_delayed_work_sync+0x13/0x20
 [<ffffffffa0170cec>] e1000_down_and_stop+0x3c/0x60 [e1000]
 [<ffffffffa01775b1>] e1000_down+0x131/0x220 [e1000]
 [<ffffffffa0177c12>] e1000_reset_task+0x52/0xa0 [e1000]
 [<ffffffff8108b972>] process_one_work+0x1d2/0x510
 [<ffffffff8108b906>] ? process_one_work+0x166/0x510
 [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
 [<ffffffff8108c960>] ? manage_workers+0x2c0/0x2c0
 [<ffffffff81092c1e>] kthread+0xee/0x110
 [<ffffffff81092b30>] ? __init_kthread_worker+0x70/0x70
 [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0
 [<ffffffff81092b30>] ? __init_kthread_worker+0x70/0x70

== The issue background ==

The problem occurs, because e1000_down(), which is called under
adapter->mutex by e1000_reset_task(), tries to synchronously cancel
e1000 auxiliary works (reset_task, watchdog_task, phy_info_task,
fifo_stall_task), which take adapter->mutex in their handlers. So the
question is what does adapter->mutex protect there?

The adapter->mutex was introduced by commit 0ef4ee ("e1000: convert to
private mutex from rtnl") as a replacement for rtnl_lock() taken in the
asynchronous handlers. It targeted on fixing a similar lockdep warning
issued when e1000_down() was called under rtnl_lock(), and it fixed it,
but unfortunately it introduced the lockdep warning described above.
Anyway, that said the source of this bug is that the asynchronous works
were made to take rtnl_lock() some time ago, so let's look deeper and
find why it was added there.

The rtnl_lock() was added to asynchronous handlers by commit 338c15
("e1000: fix occasional panic on unload") in order to prevent
asynchronous handlers from execution after the module is unloaded
(e1000_down() is called) as it follows from the comment to the commit:

> Net drivers in general have an issue where timers fired
> by mod_timer or work threads with schedule_work are running
> outside of the rtnl_lock.
>
> With no other lock protection these routines are vulnerable
> to races with driver unload or reset paths.
>
> The longer term solution to this might be a redesign with
> safer locks being taken in the driver to guarantee no
> reentrance, but for now a safe and effective fix is
> to take the rtnl_lock in these routines.

I'm not sure if this locking scheme fixed the problem or just made it
unlikely, although I incline to the latter. Anyway, this was long time
ago when e1000 auxiliary works were implemented as timers scheduling
real work handlers in their routines. The e1000_down() function only
canceled the timers, but left the real handlers running if they were
running, which could result in work execution after module unload.
Today, the e1000 driver uses sane delayed works instead of the pair
timer+work to implement its delayed asynchronous handlers, and the
e1000_down() synchronously cancels all the works so that the problem
that commit 338c15 tried to cope with disappeared, and we don't need any
locks in the handlers any more. Moreover, any locking there can
potentially result in a deadlock.

So, this patch reverts commits 0ef4ee and 338c15.

Fixes: 0ef4eedc2e98 ("e1000: convert to private mutex from rtnl")
Fixes: 338c15e470d8 ("e1000: fix occasional panic on unload")
Cc: Tushar Dave <tushar.n.dave@intel.com>
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

e1000: prevent oops when adapter is being closed and reset simultaneously

This change is based on a similar change made to e1000e support in
commit bb9e44d0d0f4 ("e1000e: prevent oops when adapter is being closed
and reset simultaneously").  The same issue has also been observed
on the older e1000 cards.

Here, we have increased the RESET_COUNT value to 50 because there are too
many accesses to e1000 nic on stress tests to e1000 nic, it is not enough
to set RESET_COUT 25. Experimentation has shown that it is enough to set
RESET_COUNT 50.

Signed-off-by: yzhu1 <yanjun.zhu@windriver.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

igb: Fixed Wake On LAN support

This patch fixes Wake on LAN being reported as supported on some Ethernet
ports, in contrary to Hardware capability.

Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

ima: store address of template_fmt_copy in a pointer before calling strsep

This patch stores the address of the 'template_fmt_copy' variable in a new
variable, called 'template_fmt_ptr', so that the latter is passed as an
argument of strsep() instead of the former. This modification is needed
in order to correctly free the memory area referenced by
'template_fmt_copy' (strsep() modifies the pointer of the passed string).

Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
Reported-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>

inet: fix possible seqlock deadlocks

In commit c9e9042994d3 ("ipv4: fix possible seqlock deadlock") I left
another places where IP_INC_STATS_BH() were improperly used.

udp_sendmsg(), ping_v4_sendmsg() and tcp_v4_connect() are called from
process context, not from softirq context.

This was detected by lockdep seqlock support.

Reported-by: jongman heo <jongman.heo@samsung.com>
Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

team: fix master carrier set when user linkup is enabled

When user linkup is enabled and user sets linkup of individual port,
we need to recompute linkup (carrier) of master interface so the change
is reflected. Fix this by calling __team_carrier_check() which does the
needed work.

Please apply to all stable kernels as well. Thanks.

Reported-by: Jan Tluka <jtluka@redhat.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST

Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
added an internal flag MSG_SENDPAGE_NOTLAST, similar to
MSG_MORE.

algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages()
and need to see the new flag as identical to MSG_MORE.

This fixes sendfile() on AF_ALG.

v3: also fix udp

Cc: Tom Herbert <therbert@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: <stable@vger.kernel.org> # 3.4.x + 3.2.x
Reported-and-tested-by: Shawn Landden <shawnlandden@gmail.com>
Original-patch: Richard Weinberger <richard@nod.at>
Signed-off-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

sfc: Convert to use hwmon_device_register_with_groups

Simplify the code. Avoid race conditions caused by attributes
being created after hwmon device registration. Implicitly
(through hwmon API) add mandatory 'name' sysfs attribute.

Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: smc91: fix crash regression on the versatile

After commit e9e4ea74f06635f2ffc1dffe5ef40c854faa0a90
"net: smc91x: dont't use SMC_outw for fixing up halfword-aligned data"
The Versatile SMSC LAN91C111 is crashing like this:

------------[ cut here ]------------
kernel BUG at /home/linus/linux/drivers/net/ethernet/smsc/smc91x.c:599!
Internal error: Oops - BUG: 0 [#1] ARM
Modules linked in:
CPU: 0 PID: 43 Comm: udhcpc Not tainted 3.13.0-rc1+ #24
task: c6ccfaa0 ti: c6cd0000 task.ti: c6cd0000
PC is at smc_hardware_send_pkt+0x198/0x22c
LR is at smc_hardware_send_pkt+0x24/0x22c
pc : [<c01be324>]    lr : [<c01be1b0>]    psr: 20000013
sp : c6cd1d08  ip : 00000001  fp : 00000000
r10: c02adb08  r9 : 00000000  r8 : c6ced802
r7 : c786fba0  r6 : 00000146  r5 : c8800000  r4 : c78d6000
r3 : 0000000f  r2 : 00000146  r1 : 00000000  r0 : 00000031
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: 06cf4000  DAC: 00000015
Process udhcpc (pid: 43, stack limit = 0xc6cd01c0)
Stack: (0xc6cd1d08 to 0xc6cd2000)
1d00:                   00000010 c8800000 c78d6000 c786fba0 c78d6000 c01be868
1d20: c01be7a4 00004000 00000000 c786fba0 c6c12b80 c0208554 000004d0 c780fc60
1d40: 00000220 c01fb734 00000000 00000000 00000000 c6c9a440 c6c12b80 c78d6000
1d60: c786fba0 c6c9a440 00000000 c021d1d8 00000000 00000000 c6c12b80 c78d6000
1d80: c786fba0 00000001 c6c9a440 c02087f8 c6c9a4a0 00080008 00000000 00000000
1da0: c78d6000 c786fba0 c78d6000 00000138 00000000 00000000 00000000 00000000
1dc0: 00000000 c027ba74 00000138 00000138 00000001 00000010 c6cedc00 00000000
1de0: 00000008 c7404400 c6cd1eec c6cd1f14 c067a73c c065c0b8 00000000 c067a740
1e00: 01ffffff 002040d0 00000000 00000000 00000000 00000000 00000000 ffffffff
1e20: 43004400 00110022 c6cdef20 c027ae8c c6ccfaa0 be82d65c 00000014 be82d3cc
1e40: 00000000 00000000 00000000 c01f2870 00000000 00000000 00000000 c6cd1e88
1e60: c6ccfaa0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1e80: 00000000 00000000 00000031 c7802310 c7802300 00000138 c7404400 c0771da0
1ea0: 00000000 c6cd1eec c7800340 00000138 be82d65c 00000014 be82d3cc c6cd1f08
1ec0: 00000014 00000000 c7404400 c7404400 00000138 c01f4628 c78d6000 00000000
1ee0: 00000000 be82d3cc 00000138 c6cd1f08 00000014 c6cd1ee4 00000001 00000000
1f00: 00000000 00000000 00080011 00000002 06000000 ffffffff 0000ffff 00000002
1f20: 06000000 ffffffff 0000ffff c00928c8 c065c520 c6cd1f58 00000003 c009299c
1f40: 00000003 c065c520 c7404400 00000000 c7404400 c01f2218 c78106b0 c7441cb0
1f60: 00000000 00000006 c06799fc 00000000 00000000 00000006 00000000 c01f3ee0
1f80: 00000000 00000000 be82d678 be82d65c 00000014 00000001 00000122 c00139c8
1fa0: c6cd0000 c0013840 be82d65c 00000014 00000006 be82d3cc 00000138 00000000
1fc0: be82d65c 00000014 00000001 00000122 00000000 00000000 00018cb1 00000000
1fe0: 00003801 be82d3a8 0003a0c7 b6e9af08 60000010 00000006 00000000 00000000
[<c01be324>] (smc_hardware_send_pkt+0x198/0x22c) from [<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8)
[<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8) from [<c0208554>] (dev_hard_start_xmit+0x460/0x4cc)
[<c0208554>] (dev_hard_start_xmit+0x460/0x4cc) from [<c021d1d8>] (sch_direct_xmit+0x94/0x18c)
[<c021d1d8>] (sch_direct_xmit+0x94/0x18c) from [<c02087f8>] (dev_queue_xmit+0x238/0x42c)
[<c02087f8>] (dev_queue_xmit+0x238/0x42c) from [<c027ba74>] (packet_sendmsg+0xbe8/0xd28)
[<c027ba74>] (packet_sendmsg+0xbe8/0xd28) from [<c01f2870>] (sock_sendmsg+0x84/0xa8)
[<c01f2870>] (sock_sendmsg+0x84/0xa8) from [<c01f4628>] (SyS_sendto+0xb8/0xdc)
[<c01f4628>] (SyS_sendto+0xb8/0xdc) from [<c0013840>] (ret_fast_syscall+0x0/0x2c)
Code: e3130002 1a000001 e3130001 0affffcd (e7f001f2)
---[ end trace 81104fe70e8da7fe ]---
Kernel panic - not syncing: Fatal exception in interrupt

This is because the macro operations in smc91x.h defined
for Versatile are missing SMC_outsw() as used in this
commit.

The Versatile needs and uses the same accessors as the other
platforms in the first if(...) clause, just switch it to using
that and we have one problem less to worry about.

This includes a hunk of a patch from Will Deacon fixin
the other 32bit platforms as well: Innokom, Ramses, PXA,
PCM027.

Checkpatch complains about spacing, but I have opted to
follow the style of this .h-file.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Revert "net: smc91: fix crash regression on the versatile"

This reverts commit b268daffdcb9762ad9aa3898096570a9dd92aa9b.

I applied the wrong version of this patch, the proper version
is coming up next.

Signed-off-by: David S. Miller <davem@davemloft.net>

net: smc91: fix crash regression on the versatile

After commit e9e4ea74f06635f2ffc1dffe5ef40c854faa0a90
"net: smc91x: dont't use SMC_outw for fixing up halfword-aligned data"
The Versatile SMSC LAN91C111 is crashing like this:

------------[ cut here ]------------
kernel BUG at /home/linus/linux/drivers/net/ethernet/smsc/smc91x.c:599!
Internal error: Oops - BUG: 0 [#1] ARM
Modules linked in:
CPU: 0 PID: 43 Comm: udhcpc Not tainted 3.13.0-rc1+ #24
task: c6ccfaa0 ti: c6cd0000 task.ti: c6cd0000
PC is at smc_hardware_send_pkt+0x198/0x22c
LR is at smc_hardware_send_pkt+0x24/0x22c
pc : [<c01be324>]    lr : [<c01be1b0>]    psr: 20000013
sp : c6cd1d08  ip : 00000001  fp : 00000000
r10: c02adb08  r9 : 00000000  r8 : c6ced802
r7 : c786fba0  r6 : 00000146  r5 : c8800000  r4 : c78d6000
r3 : 0000000f  r2 : 00000146  r1 : 00000000  r0 : 00000031
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: 06cf4000  DAC: 00000015
Process udhcpc (pid: 43, stack limit = 0xc6cd01c0)
Stack: (0xc6cd1d08 to 0xc6cd2000)
1d00:                   00000010 c8800000 c78d6000 c786fba0 c78d6000 c01be868
1d20: c01be7a4 00004000 00000000 c786fba0 c6c12b80 c0208554 000004d0 c780fc60
1d40: 00000220 c01fb734 00000000 00000000 00000000 c6c9a440 c6c12b80 c78d6000
1d60: c786fba0 c6c9a440 00000000 c021d1d8 00000000 00000000 c6c12b80 c78d6000
1d80: c786fba0 00000001 c6c9a440 c02087f8 c6c9a4a0 00080008 00000000 00000000
1da0: c78d6000 c786fba0 c78d6000 00000138 00000000 00000000 00000000 00000000
1dc0: 00000000 c027ba74 00000138 00000138 00000001 00000010 c6cedc00 00000000
1de0: 00000008 c7404400 c6cd1eec c6cd1f14 c067a73c c065c0b8 00000000 c067a740
1e00: 01ffffff 002040d0 00000000 00000000 00000000 00000000 00000000 ffffffff
1e20: 43004400 00110022 c6cdef20 c027ae8c c6ccfaa0 be82d65c 00000014 be82d3cc
1e40: 00000000 00000000 00000000 c01f2870 00000000 00000000 00000000 c6cd1e88
1e60: c6ccfaa0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1e80: 00000000 00000000 00000031 c7802310 c7802300 00000138 c7404400 c0771da0
1ea0: 00000000 c6cd1eec c7800340 00000138 be82d65c 00000014 be82d3cc c6cd1f08
1ec0: 00000014 00000000 c7404400 c7404400 00000138 c01f4628 c78d6000 00000000
1ee0: 00000000 be82d3cc 00000138 c6cd1f08 00000014 c6cd1ee4 00000001 00000000
1f00: 00000000 00000000 00080011 00000002 06000000 ffffffff 0000ffff 00000002
1f20: 06000000 ffffffff 0000ffff c00928c8 c065c520 c6cd1f58 00000003 c009299c
1f40: 00000003 c065c520 c7404400 00000000 c7404400 c01f2218 c78106b0 c7441cb0
1f60: 00000000 00000006 c06799fc 00000000 00000000 00000006 00000000 c01f3ee0
1f80: 00000000 00000000 be82d678 be82d65c 00000014 00000001 00000122 c00139c8
1fa0: c6cd0000 c0013840 be82d65c 00000014 00000006 be82d3cc 00000138 00000000
1fc0: be82d65c 00000014 00000001 00000122 00000000 00000000 00018cb1 00000000
1fe0: 00003801 be82d3a8 0003a0c7 b6e9af08 60000010 00000006 00000000 00000000
[<c01be324>] (smc_hardware_send_pkt+0x198/0x22c) from [<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8)
[<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8) from [<c0208554>] (dev_hard_start_xmit+0x460/0x4cc)
[<c0208554>] (dev_hard_start_xmit+0x460/0x4cc) from [<c021d1d8>] (sch_direct_xmit+0x94/0x18c)
[<c021d1d8>] (sch_direct_xmit+0x94/0x18c) from [<c02087f8>] (dev_queue_xmit+0x238/0x42c)
[<c02087f8>] (dev_queue_xmit+0x238/0x42c) from [<c027ba74>] (packet_sendmsg+0xbe8/0xd28)
[<c027ba74>] (packet_sendmsg+0xbe8/0xd28) from [<c01f2870>] (sock_sendmsg+0x84/0xa8)
[<c01f2870>] (sock_sendmsg+0x84/0xa8) from [<c01f4628>] (SyS_sendto+0xb8/0xdc)
[<c01f4628>] (SyS_sendto+0xb8/0xdc) from [<c0013840>] (ret_fast_syscall+0x0/0x2c)
Code: e3130002 1a000001 e3130001 0affffcd (e7f001f2)
---[ end trace 81104fe70e8da7fe ]---
Kernel panic - not syncing: Fatal exception in interrupt

This is because the macro operations in smc91x.h defined
for Versatile are missing SMC_outsw() as used in this
commit.

The Versatile needs and uses the same accessors as the other
platforms in the first if(...) clause, just switch it to using
that and we have one problem less to worry about.

Checkpatch complains about spacing, but I have opted to
follow the style of this .h-file.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: 8139cp: fix a BUG_ON triggered by wrong bytes_compl

Using iperf to send packets(GSO mode is on), a bug is triggered:

[  212.672781] kernel BUG at lib/dynamic_queue_limits.c:26!
[  212.673396] invalid opcode: 0000 [#1] SMP
[  212.673882] Modules linked in: 8139cp(O) nls_utf8 edd fuse loop dm_mod ipv6 i2c_piix4 8139too i2c_core intel_agp joydev pcspkr hid_generic intel_gtt floppy sr_mod mii button sg cdrom ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore sd_mod usb_common crc_t10dif crct10dif_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata scsi_mod [last unloaded: 8139cp]
[  212.676084] CPU: 0 PID: 4124 Comm: iperf Tainted: G           O 3.12.0-0.7-default+ #16
[  212.676084] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[  212.676084] task: ffff8800d83966c0 ti: ffff8800db4c8000 task.ti: ffff8800db4c8000
[  212.676084] RIP: 0010:[<ffffffff8122e23f>]  [<ffffffff8122e23f>] dql_completed+0x17f/0x190
[  212.676084] RSP: 0018:ffff880116e03e30  EFLAGS: 00010083
[  212.676084] RAX: 00000000000005ea RBX: 0000000000000f7c RCX: 0000000000000002
[  212.676084] RDX: ffff880111dd0dc0 RSI: 0000000000000bd4 RDI: ffff8800db6ffcc0
[  212.676084] RBP: ffff880116e03e48 R08: 0000000000000992 R09: 0000000000000000
[  212.676084] R10: ffffffff8181e400 R11: 0000000000000004 R12: 000000000000000f
[  212.676084] R13: ffff8800d94ec840 R14: ffff8800db440c80 R15: 000000000000000e
[  212.676084] FS:  00007f6685a3c700(0000) GS:ffff880116e00000(0000) knlGS:0000000000000000
[  212.676084] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  212.676084] CR2: 00007f6685ad6460 CR3: 00000000db714000 CR4: 00000000000006f0
[  212.676084] Stack:
[  212.676084]  ffff8800db6ffc00 000000000000000f ffff8800d94ec840 ffff880116e03eb8
[  212.676084]  ffffffffa041509f ffff880116e03e88 0000000f16e03e88 ffff8800d94ec000
[  212.676084]  00000bd400059858 000000050000000f ffffffff81094c36 ffff880116e03eb8
[  212.676084] Call Trace:
[  212.676084]  <IRQ>
[  212.676084]  [<ffffffffa041509f>] cp_interrupt+0x4ef/0x590 [8139cp]
[  212.676084]  [<ffffffff81094c36>] ? ktime_get+0x56/0xd0
[  212.676084]  [<ffffffff8108cf73>] handle_irq_event_percpu+0x53/0x170
[  212.676084]  [<ffffffff8108d0cc>] handle_irq_event+0x3c/0x60
[  212.676084]  [<ffffffff8108fdb5>] handle_fasteoi_irq+0x55/0xf0
[  212.676084]  [<ffffffff810045df>] handle_irq+0x1f/0x30
[  212.676084]  [<ffffffff81003c8b>] do_IRQ+0x5b/0xe0
[  212.676084]  [<ffffffff8142beaa>] common_interrupt+0x6a/0x6a
[  212.676084]  <EOI>
[  212.676084]  [<ffffffffa0416a21>] ? cp_start_xmit+0x621/0x97c [8139cp]
[  212.676084]  [<ffffffffa0416a09>] ? cp_start_xmit+0x609/0x97c [8139cp]
[  212.676084]  [<ffffffff81378ed9>] dev_hard_start_xmit+0x2c9/0x550
[  212.676084]  [<ffffffff813960a9>] sch_direct_xmit+0x179/0x1d0
[  212.676084]  [<ffffffff813793f3>] dev_queue_xmit+0x293/0x440
[  212.676084]  [<ffffffff813b0e46>] ip_finish_output+0x236/0x450
[  212.676084]  [<ffffffff810e59e7>] ? __alloc_pages_nodemask+0x187/0xb10
[  212.676084]  [<ffffffff813b10e8>] ip_output+0x88/0x90
[  212.676084]  [<ffffffff813afa64>] ip_local_out+0x24/0x30
[  212.676084]  [<ffffffff813aff0d>] ip_queue_xmit+0x14d/0x3e0
[  212.676084]  [<ffffffff813c6fd1>] tcp_transmit_skb+0x501/0x840
[  212.676084]  [<ffffffff813c8323>] tcp_write_xmit+0x1e3/0xb20
[  212.676084]  [<ffffffff81363237>] ? skb_page_frag_refill+0x87/0xd0
[  212.676084]  [<ffffffff813c8c8b>] tcp_push_one+0x2b/0x40
[  212.676084]  [<ffffffff813bb7e6>] tcp_sendmsg+0x926/0xc90
[  212.676084]  [<ffffffff813e1d21>] inet_sendmsg+0x61/0xc0
[  212.676084]  [<ffffffff8135e861>] sock_aio_write+0x101/0x120
[  212.676084]  [<ffffffff81107cf1>] ? vma_adjust+0x2e1/0x5d0
[  212.676084]  [<ffffffff812163e0>] ? timerqueue_add+0x60/0xb0
[  212.676084]  [<ffffffff81130b60>] do_sync_write+0x60/0x90
[  212.676084]  [<ffffffff81130d44>] ? rw_verify_area+0x54/0xf0
[  212.676084]  [<ffffffff81130f66>] vfs_write+0x186/0x190
[  212.676084]  [<ffffffff811317fd>] SyS_write+0x5d/0xa0
[  212.676084]  [<ffffffff814321e2>] system_call_fastpath+0x16/0x1b
[  212.676084] Code: ca 41 89 dc 41 29 cc 45 31 db 29 c2 41 89 c5 89 d0 45 29 c5 f7 d0 c1 e8 1f e9 43 ff ff ff 66 0f 1f 44 00 00 31 c0 e9 7b ff ff ff <0f> 0b eb fe 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 c7 47 40 00
[  212.676084] RIP  [<ffffffff8122e23f>] dql_completed+0x17f/0x190
------------[ cut here ]------------

When a skb has frags, bytes_compl plus skb->len nr_frags times in cp_tx().
It's not the correct value(actually, it should plus skb->len once) and it
will trigger the BUG_ON(bytes_compl > num_queued - dql->num_completed).
So only increase bytes_compl when finish sending all frags. pkts_compl also
has a wrong value, fix it too.

It's introduced by commit 871f0d4c ("8139cp: enable bql").

Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

r8169: check ALDPS bit and disable it if enabled for the 8168g

Windows driver will enable ALDPS function, but linux driver and firmware
do not have any configuration related to ALDPS function for 8168g.
So restart system to linux and remove the NIC cable, LAN enter ALDPS,
then LAN RX will be disabled.

This issue can be easily reproduced on dual boot windows and linux
system with RTL_GIGA_MAC_VER_40 chip.

Realtek said, ALDPS function can be disabled by configuring to PHY,
switch to page 0x0A43, reg0x10 bit2=0.

Signed-off-by: David Chang <dchang@suse.com>
Acked-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: clamp ->msg_namelen instead of returning an error

If kmsg->msg_namelen > sizeof(struct sockaddr_storage) then in the
original code that would lead to memory corruption in the kernel if you
had audit configured.  If you didn't have audit configured it was
harmless.

There are some programs such as beta versions of Ruby which use too
large of a buffer and returning an error code breaks them.  We should
clamp the ->msg_namelen value instead.

Fixes: 1661bf364ae9 ("net: heap overflow in __audit_sockaddr()")
Reported-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Tested-by: Eric Wong <normalperson@yhbt.net>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

af_packet: block BH in prb_shutdown_retire_blk_timer()

Currently we're using plain spin_lock() in prb_shutdown_retire_blk_timer(),
however the timer might fire right in the middle and thus try to re-aquire
the same spinlock, leaving us in a endless loop.

To fix that, use the spin_lock_bh() to block it.

Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
CC: "David S. Miller" <davem@davemloft.net>
CC: Daniel Borkmann <dborkman@redhat.com>
CC: Willem de Bruijn <willemb@google.com>
CC: Phil Sutter <phil@nwl.cc>
CC: Eric Dumazet <edumazet@google.com>
Reported-by: Jan Stancek <jstancek@redhat.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

macvtap: Do not double-count received packets

Currently macvlan will count received packets after calling each
vlans receive handler.   Macvtap attempts to count the packet
yet again when the user reads the packet from the tap socket.
This code doesn't do this consistently either.  Remove the
counting from macvtap and let only macvlan count received
packets.

Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Linux 3.13-rc2

Merge tag 'arm64-stable' of git://git./linux/kernel/git/cmarinas/linux-aarch64

Pull ARM64 fixes from Catalin Marinas:
 - Remove preempt_count modifications in the arm64 IRQ handling code
   since that's already dealt with in generic irq_enter/irq_exit
 - PTE_PROT_NONE bit moved higher up to avoid overlapping with the
   hardware bits (for PROT_NONE mappings which are pte_present)
 - Big-endian fixes for ptrace support
 - Asynchronous aborts unmasking while in the kernel
 - pgprot_writecombine() change to create Normal NonCacheable memory
   rather than Device GRE

* tag 'arm64-stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64:
  arm64: Move PTE_PROT_NONE higher up
  arm64: Use Normal NonCacheable memory for writecombine
  arm64: debug: make aarch32 bkpt checking endian clean
  arm64: ptrace: fix compat registes get/set to be endian clean
  arm64: Unmask asynchronous aborts when in kernel mode
  arm64: dts: Reserve the memory used for secondary CPU release address
  arm64: let the core code deal with preempt_count

Merge branch 'for-linus' of git://git./linux/kernel/git/s390/linux

Pull s390 updates from Martin Schwidefsky:
 "One performance improvement and a few bug fixes.  Two of the fixes
  deal with the clock related problems we have seen on recent kernels"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/mm: handle asce-type exceptions as normal page fault
  s390,time: revert direct ktime path for s390 clockevent device
  s390/time,vdso: convert to the new update_vsyscall interface
  s390/uaccess: add missing page table walk range check
  s390/mm: optimize copy_page
  s390/dasd: validate request size before building CCW/TCW request
  s390/signal: always restore saved runtime instrumentation psw bit

Merge branch 'i2c/for-current' of git://git./linux/kernel/git/wsa/linux

Pull i2c fixes from Wolfram Sang:
 "Some easy but needed fixes for i2c drivers since rc1"

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: bcm2835: Linking platform nodes to adapter nodes
  i2c: omap: raw read and write endian fix
  i2c: i2c-bcm-kona: Fix module build
  i2c: i2c-diolan-u2c: different usb endpoints for DLN-2-U2C
  i2c: bcm-kona: remove duplicated include
  i2c: davinci: raw read and write endian fix

Merge branch 'for-3.13-fixes' of git://git./linux/kernel/git/tj/wq

Pull workqueue fixes from Tejun Heo:
 "This contains one important fix.  The NUMA support added a while back
  broke ordering guarantees on ordered workqueues.  It was enforced by
  having single frontend interface with @max_active == 1 but the NUMA
  support puts multiple interfaces on unbound workqueues on NUMA
  machines thus breaking the ordered guarantee.  This is fixed by
  disabling NUMA support on ordered workqueues.

  The above and a couple other patches were sitting in for-3.12-fixes
  but I forgot to push that out, so they ended up waiting a bit too
  long.  My aplogies.

  Other fixes are minor"

* 'for-3.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
  workqueue: fix pool ID allocation leakage and remove BUILD_BUG_ON() in init_workqueues
  workqueue: fix comment typo for __queue_work()
  workqueue: fix ordered workqueues in NUMA setups
  workqueue: swap set_cpus_allowed_ptr() and PF_NO_SETAFFINITY

Merge branch 'for-3.13-fixes' of git://git./linux/kernel/git/tj/libata

Pull libata fixes from Tejun Heo:
 "libata device removal path was removing parent device node before its
  child, which is mostly harmless but triggers warning after recent
  sysfs changes.  Rafael's patch fixes the order.

  Other than that, minor controller-specific fixes and device ID
  additions"

* 'for-3.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  ATA: Fix port removal ordering
  ahci: add Marvell 9230 to the AHCI PCI device list
  ata: fix acpi_bus_get_device() return value check
  pata_arasan_cf: add missing clk_disable_unprepare() on error path
  ahci: add support for IBM Akebono platform device

Merge branch 'for-3.13-fixes' of git://git./linux/kernel/git/tj/cgroup

Pull cgroup fixes from Tejun Heo:
 "Fixes for three issues.

   - cgroup destruction path could swamp system_wq possibly leading to
     deadlock.  This actually seems to happen in the wild with memcg
     because memcg destruction path adds nested dependency on system_wq.

     Resolved by isolating cgroup destruction work items on its
     dedicated workqueue.

   - Possible locking context deadlock through seqcount reported by
     lockdep

   - Memory leak under certain conditions"

* 'for-3.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cgroup: fix cgroup_subsys_state leak for seq_files
  cpuset: Fix memory allocator deadlock
  cgroup: use a dedicated workqueue for cgroup destruction

Merge tag 'sound-3.13-rc2' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Quite a few HD-Audio fixes, a WUSB audio fix and a fix for FireWire
  audio.  The HD-audio part contains a couple of fixes for the generic
  parser, and these are the only intrusive fixes.  The rest are mostly
  device-specific fixes"

* tag 'sound-3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Add LFE chmap to ASUS ET2700
  ALSA: hda - Initialize missing bass speaker pin for ASUS AIO ET2700
  ALSA: hda - limit mic boost on Asus UX31[A,E]
  ALSA: hda - Check leaf nodes to find aamix amps
  ALSA: hda - Fix hp-mic mode without VREF bits
  ALSA: hda - Create Headhpone Mic Jack Mode when really needed
  ALSA: usb: use multiple packets per urb for Wireless USB inbound audio
  ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec
  ALSA: hda - Drop bus->avoid_link_reset flag
  ALSA: hda/realtek - Set pcbeep amp for ALC668
  ALSA: hda/realtek - Add support of ALC231 codec
  ALSA: firewire-lib: fix wrong value for FDF field as an empty packet

Merge branch 'for-linus' of git://git./linux/kernel/git/viro/vfs

Pull vfs dentry reference count fix from Al Viro.

This fixes a possible inode_permission NULL pointer dereference (and
other problems) that were due to the root dentry count being decremented
too much.  In commit 48a066e72d97 ("RCU'd vfsmounts") the placement of
clearing the LOOKUP_RCU bit changed, and we then returned failure of
incrementing the lockref on the parent dentry with LOOKUP_RCU cleared.

But that meant we needed to go through the same cleanup routines that
the later failures did wrt LOOKUP_ROOT and nd->root.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  fix bogus path_put() of nd->root after some unlazy_walk() failures

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm qxl leak fix from Dave Airlie:
 "As usual 5 mins after I send a trivial pull fix I find a real bug!

  This fixes a memory leak and I'd like to get it into stable queue
  asap"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/qxl: fix memory leak in release list handling

arm64: Move PTE_PROT_NONE higher up

PTE_PROT_NONE means that a pte is present but does not have any
read/write attributes. However, setting the memory type like
pgprot_writecombine() is allowed and such bits overlap with
PTE_PROT_NONE. This causes mmap/munmap issues in drivers that change the
vma->vm_pg_prot on PROT_NONE mappings.

This patch reverts the PTE_FILE/PTE_PROT_NONE shift in commit
59911ca4325d (ARM64: mm: Move PTE_PROT_NONE bit) and moves PTE_PROT_NONE
together with the other software bits.

Signed-off-by: Steve Capper <steve.capper@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Steve Capper <steve.capper@linaro.org>
Cc: <stable@vger.kernel.org> # 3.11+

ALSA: hda - Fix silent output on ASUS W7J laptop

The recent kernels got regressions on ASUS W7J with ALC660 codec where
no sound comes out.  After a long debugging session, we found out that
setting the pin control on the unused NID 0x10 is mandatory for the
outputs.  And, it was found out that another magic of NID 0x0f that is
required for other ASUS laptops isn't needed on this machine.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66081
Reported-and-tested-by: Andrey Lipaev <lipaev@mail.ru>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: core: Use consistent byte ordering in snd_soc_bytes_get

snd_soc_bytes_put treats the data in the binary control as big endian
words, however snd_soc_bytes_get uses the endian of the host machine.
This causes the two functions to be inconsistant with how the mask is
applied on little endian machines.

This patch applies the big_endian format used in snd_soc_bytes_put to
snd_soc_bytes_get.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

arm64: Use Normal NonCacheable memory for writecombine

This provides better performance compared to Device GRE and also allows
unaligned accesses. Such memory is intended to be used with standard RAM
(e.g. framebuffers) and not I/O.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

nohz: Fix another inconsistency between CONFIG_NO_HZ=n and nohz=off

If CONFIG_NO_HZ=n tick_nohz_get_sleep_length() returns NSEC_PER_SEC/HZ.

If CONFIG_NO_HZ=y and the nohz functionality is disabled via the
command line option "nohz=off" or not enabled due to missing hardware
support, then tick_nohz_get_sleep_length() returns 0. That happens
because ts->sleep_length is never set in that case.

Set it to NSEC_PER_SEC/HZ when the NOHZ mode is inactive.

Reported-by: Michal Hocko <mhocko@suse.cz>
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

efi-pstore: Make efi-pstore return a unique id

Pstore fs expects that backends provide a unique id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.

Signed-off-by: Madper Xie <cxie@redhat.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: stable@vger.kernel.org
Signed-off-by: Matt Fleming <matt.fleming@intel.com>

ALSA: dice: fix array limits in dice_proc_read()

The array limits are supposed to be in units of u32 instead of in bytes.
The current code has a potential array overflow.

Fixes: c614475b0ea9 ('ALSA: dice: add a proc file to show device information')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - Add mono speaker quirk for Dell Inspiron 5439

This machine also has mono output if run through DAC node 0x03.

Cc: stable@vger.kernel.org (v3.10+)
BugLink: https://bugs.launchpad.net/bugs/1256212
Tested-by: David Chen <david.chen@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>