UBUNTU: [Config] added qlcnic driver to d-i modules

BugLink: http://bugs.launchpad.net/bugs/1196597

Signed-off-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
hp-wmi: add more definitions for new event_id's

BugLink: http://bugs.launchpad.net/bugs/1152458

New HP laptops start generating new events, and hp-wmi prints unknown
event_ids for them. This patch also removes these messages

Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
(cherry picked from commit d9e290a0ff16aaa51d968e7a0714ea5e2ca2407d)

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
MFD: rtsx_pcr: Fix probe fail path

BugLink: http://bugs.launchpad.net/bugs/1201321

When rtsx_pci_acquire_irq fails in rtsx_pci_probe, we forget to
disable an MSI (if we enabled it). This results in this warning on the
next attempt to load the module:
WARNING: at drivers/pci/msi.c:834 pci_enable_msi_block+0x2a4/0x2b0()
Hardware name: HP EliteBook 840 G1
Modules linked in: rtsx_pci(+) ...
Pid: 4056, comm: modprobe Tainted: G          I  3.8.0-9405-gd895cb1-1-vanilla #1
Call Trace:
 [<ffffffff81045c6a>] warn_slowpath_common+0x7a/0xc0
 [<ffffffff81045cc5>] warn_slowpath_null+0x15/0x20
 [<ffffffff81302544>] pci_enable_msi_block+0x2a4/0x2b0
 [<ffffffffa05e335a>] rtsx_pci_probe+0x55a/0x720 [rtsx_pci]
...

So properly disable MSI in that case.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
(cherry picked from commit 9d66b568a215fe2da2a9db736ebf9b8d66082d88)
Signed-off-by: Adam Lee <adam.lee@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
mfd: rtsx: Add support for RTL8411B

BugLink: http://bugs.launchpad.net/bugs/1201321

Adding support of model RTL8411B. Since the model is similar to RTL8411,
differences are implemented in rtl8411.c.

Signed-off-by: Roger Tseng <rogerable@realtek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
(back ported from commit 9032eabdd3fcfc00aa513a9eef54002cbabb8c9a)

Conflicts:
	drivers/mfd/rtsx_pcr.c
	drivers/mfd/rtsx_pcr.h

Signed-off-by: Adam Lee <adam.lee@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
veth: reduce stat overhead

BugLink: http://bugs.launchpad.net/bugs/1201869

veth stats are a bit bloated. There is no need to account transmit
and receive stats, since they are absolutely symmetric.

Also use a per device atomic64_t for the dropped counter, as it
should never be used in fast path.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 2681128f0ced8aa4e66f221197e183cc16d244fe)

Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
veth: extend device features

BugLink: http://bugs.launchpad.net/bugs/1201869

veth is lacking most modern facilities, like SG, checksums, TSO.

It makes sense to extend dev->features to get them, or GRO aggregation
is defeated by a forced segmentation.

Reported-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8093315a91340bca52549044975d8c7f673b28a1)

Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
veth: avoid a NULL deref in veth_stats_one

BugLink: http://bugs.launchpad.net/bugs/1201869

commit 2681128f0ced8a (veth: extend device features) added a NULL deref
in veth_stats_one(), as veth_get_stats64() was not testing if the peer
device was setup or not.

At init time, we call dev_get_stats() before veth pair is fully setup.

[  178.854758]  [<ffffffffa00f5677>] veth_get_stats64+0x47/0x70 [veth]
[  178.861013]  [<ffffffff814f0a2d>] dev_get_stats+0x6d/0x130
[  178.866486]  [<ffffffff81504efc>] rtnl_fill_ifinfo+0x47c/0x930
[  178.872299]  [<ffffffff81505b93>] rtmsg_ifinfo+0x83/0x100
[  178.877678]  [<ffffffff81505cc6>] rtnl_configure_link+0x76/0xa0
[  178.883580]  [<ffffffffa00f52fa>] veth_newlink+0x16a/0x350 [veth]
[  178.889654]  [<ffffffff815061cc>] rtnl_newlink+0x4dc/0x5e0
[  178.895128]  [<ffffffff81505e1e>] ? rtnl_newlink+0x12e/0x5e0
[  178.900769]  [<ffffffff8150587d>] rtnetlink_rcv_msg+0x11d/0x310
[  178.906669]  [<ffffffff81505760>] ? __rtnl_unlock+0x20/0x20
[  178.912225]  [<ffffffff81521f89>] netlink_rcv_skb+0xa9/0xd0
[  178.917779]  [<ffffffff81502d55>] rtnetlink_rcv+0x25/0x40
[  178.923159]  [<ffffffff815218d1>] netlink_unicast+0x1b1/0x230
[  178.928887]  [<ffffffff81521c4e>] netlink_sendmsg+0x2fe/0x3b0
[  178.934615]  [<ffffffff814dbe22>] sock_sendmsg+0xd2/0xf0

So we must check if peer was setup in veth_get_stats64()

As pointed out by Ben Hutchings, priv->peer is missing proper
synchronization. Adding RCU protection is a safe and well documented
way to make sure we don't access about to be freed or already
freed data.

Reported-by: Tom Parkin <tparkin@katalix.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit d0e2c55e7c940a3ee91e9e23a2683b593690f1e9)

Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Input: elantech - fix for newer hardware versions (v7)

BugLink: http://bugs.launchpad.net/bugs/1166442

* Fix version recognition in elantech_set_properties

  The new hardware reports itself as v7 but the packets'
  structure is unaltered.

* Fix packet type recognition in elantech_packet_check_v4

  The bitmask used for v6 is too wide, only the last three bits of
  the third byte in a packet (packet[3] & 0x03) are actually used to
  distinguish between packet types.
  Starting from v7, additional information (to be interpreted) is
  stored in the remaining bits (packets[3] & 0x1c).
  In addition, the value stored in (packet[0] & 0x0c) is no longer
  a constant but contains additional information yet to be deciphered.
  This change should be backwards compatible with v6 hardware.

Additional-author: Giovanni Frigione <gio.frigione@gmail.com>
Signed-off-by: Matteo Delfino <kendatsuba@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
(cherry picked from commit 9eebed7de660c0b5ab129a9de4f89d20b60de68c)
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: ARM: highbank: Only touch common coherency control register fields

upstreamed - should appear in 3.11

Midway adds new register fields to the coherency control registers, so
writing absolute values will break on Midway. Change the register
accesses to only modify the necessary and common fields in order to
support both Midway and Highbank.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

BugLink: https://bugs.launchpad.net/bugs/1196946

Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: [Config] add iwldvm to nic-modules

BugLink: http://bugs.launchpad.net/bugs/1204194
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBIFS: correct mount message

BugLink: http://bugs.launchpad.net/bugs/1204666

commit beadadfa5467e09e36891f39cae1f5d8d3bbf17e upstream.

When mounting an UBIFS R/W volume, we have the message:
UBIFS: mounted UBI device 0, volume 1, name "rootfs"(null)
With this patch, we'll have:
UBIFS: mounted UBI device 0, volume 1, name "rootfs"
Which is, I think, what was intended.

Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
zfcp: fix adapter (re)open recovery while link to SAN is down

BugLink: http://bugs.launchpad.net/bugs/1204666

commit f76ccaac4f82c463a037aa4a1e4ccb85c7011814 upstream.

FCP device remains in status ERP_FAILED when device is switched online
or adapter recovery is triggered  while link to SAN is down.

When Exchange Configuration Data command returns the FSF status
FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE it aborts the exchange process.
The only retries are done during the common error recovery procedure
(i.e. max. 3 retries with 8sec sleep between) and remains in status
ERP_FAILED with QDIO down.

This commit reverts the commit 0df138476c8306478d6e726f044868b4bccf411c
(zfcp: Fix adapter activation on link down).
When FSF status FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE is received the
adapter recovery will be finished without any retries. QDIO will be
up now and status changes such as LINK UP will be received now.

Signed-off-by: Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
zfcp: block queue limits with data router

BugLink: http://bugs.launchpad.net/bugs/1204666

commit 5fea4291deacd80188b996d2f555fc6a1940e5d4 upstream.

Commit 86a9668a8d29ea711613e1cb37efa68e7c4db564
"[SCSI] zfcp: support for hardware data router"
reduced the initial block queue limits in the scsi_host_template to the
absolute minimum and adjusted them later on. However, the adjustment was
too late for the BSG devices of Scsi_Host and fc_host.

Therefore, ioctl(..., SG_IO, ...) with request or response size > 4kB to a
BSG device of an fc_host or a Scsi_Host fails with EINVAL. As a result,
users of such ioctl such as HBA_SendCTPassThru() in libzfcphbaapi return
with error HBA_STATUS_ERROR.

Initialize the block queue limits in zfcp_scsi_host_template to the
greatest common denominator (GCD).

While we cannot exploit the slightly enlarged maximum request size with
data router, this should be neglectible. Doing so also avoids running into
trouble after live guest relocation (LGR) / migration from a data router
FCP device to an FCP device that does not support data router. In that
case, zfcp would figure out the new limits on adapter recovery, but the
fc_host and Scsi_Host (plus in fact all sdevs) still exist with the old and
now too large queue limits.

It should also OK, not to use half the size as in the DIX case, because
fc_host and Scsi_Host do not transport FCP requests including SCSI commands
using protection data.

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
zfcp: status read buffers on first adapter open with link down

BugLink: http://bugs.launchpad.net/bugs/1204666

commit 9edf7d75ee5f21663a0183d21f702682d0ef132f upstream.

Commit 64deb6efdc5504ce97b5c1c6f281fffbc150bd93
"[SCSI] zfcp: Use status_read_buf_num provided by FCP channel"
started using a value returned by the channel but only evaluated the value
if the fabric link is up.
Commit 8d88cf3f3b9af4713642caeb221b6d6a42019001
"[SCSI] zfcp: Update status read mempool"
introduced mempool resizings based on the above value.
On setting an FCP device online for the very first time since boot, a new
zeroed adapter object is allocated. If the link is down, the number of
status read requests remains zero. Since just the config data exchange is
incomplete, we proceed with adapter open recovery. However, we
unconditionally call mempool_resize with adapter->stat_read_buf_num == 0 in
this case.

This causes a kernel message "kernel BUG at mm/mempool.c:131!" in process
"zfcperp<FCP-device-bus-ID>" with last function mempool_resize in Krnl PSW
and zfcp_erp_thread in the Call Trace.

Don't evaluate channel values which are invalid on link down. The number of
status read requests is always valid, evaluated, and set to a positive
minimum greater than zero. The adapter open recovery can proceed and the
channel has status read buffers to inform us on a future link up event.
While we are not aware of any other code path that could result in mempool
resize attempts of size zero, we still also initialize the number of status
read buffers to be posted to a static minimum number on adapter object
allocation.

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
ahci: Add AMD CZ SATA device ID

BugLink: http://bugs.launchpad.net/bugs/1204666

commit fafe5c3d82a470d73de53e6b08eb4e28d974d895 upstream.

To add AMD CZ SATA controller device ID of IDE mode.

[bhelgaas: drop pci_ids.h update]
Signed-off-by: Shane Huang <shane.huang@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
i2c-piix4: Add AMD CZ SMBus device ID

BugLink: http://bugs.launchpad.net/bugs/1204666

commit b996ac90f595dda271cbd858b136b45557fc1a57 upstream.

To add AMD CZ SMBus controller device ID.

[bhelgaas: drop pci_ids.h update]
Signed-off-by: Shane Huang <shane.huang@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
sata_highbank: increase retry count but shorten duration for Calxeda controller

BugLink: http://bugs.launchpad.net/bugs/1204666

commit ddfef5de3d716f77bad32dbbba6b280158dfd721 upstream.

Increase the retry count for the hard reset function to 100 but
shorten the time out period to 500 ms. See the comment for
ahci_highbank_hardreset for the reasons why those vaulues were
chosen.

Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
clocksource: dw_apb: Fix error check

BugLink: http://bugs.launchpad.net/bugs/1204666

commit 1a33bd2be705cbb3f57d7223b60baea441039307 upstream.

irq_of_parse_and_map() returns 0 on error, while the code checks for NO_IRQ.
This breaks on platforms that have NO_IRQ != 0.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
zram: avoid invalid memory access in zram_exit()

BugLink: http://bugs.launchpad.net/bugs/1204666

commit 6030ea9b35971a4200062f010341ab832e878ac9 upstream.

Memory for zram->disk object may have already been freed after returning
from destroy_device(zram), then it's unsafe for zram_reset_device(zram)
to access zram->disk again.

We can't solve this bug by flipping the order of destroy_device(zram)
and zram_reset_device(zram), that will cause deadlock issues to the
zram sysfs handler.

So fix it by holding an extra reference to zram->disk before calling
destroy_device(zram).

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ luis: backported to 3.8: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>