cascardo/linux.git
11 years agoCHROMIUM: exynos5: add support for LCD on Spring
Vincent Palatin [Mon, 22 Oct 2012 17:18:34 +0000 (10:18 -0700)]
CHROMIUM: exynos5: add support for LCD on Spring

Allow to configure DP output for either NXP or Parade eDP-LVDS bridge.
Set sensible LCD panel settings for Spring.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14491
TEST=run on Spring and Snow and see display coming up on ChromeOS
startup on both machines.

Change-Id: I3cd46327a9d8fd6010c8d308111c6c0267fedae4
Reviewed-on: https://gerrit.chromium.org/gerrit/36233
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: config: enable Parade bridge
Vincent Palatin [Thu, 18 Oct 2012 17:40:54 +0000 (10:40 -0700)]
CHROMIUM: config: enable Parade bridge

Compile Parade PS8622 eDP/LVDS.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14491
TEST=on Spring, boot and see the ps8622 initializing with the right
device tree configuration.

Change-Id: I7eb8cb13ee2a742cb5dd025266e4e1db52ee7656
Reviewed-on: https://gerrit.chromium.org/gerrit/36232
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: auxdisplay/ps8620: Add driver for Parade PS8622 bridge
Vincent Palatin [Sat, 4 Aug 2012 16:12:33 +0000 (09:12 -0700)]
CHROMIUM: auxdisplay/ps8620: Add driver for Parade PS8622 bridge

Add a new driver to handle the Parade PS8622 eDP/LVDS bridge chip.
The driver sets properly the SLP_N and RST_N pins and configure the
bridge through I2C.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14491
TEST=Tested on Spring, see the screen coming up on boot.

Change-Id: I3fd15f9780abe45b1cc93f9234db7d79c65ac5a3
Reviewed-on: https://gerrit.chromium.org/gerrit/36231
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agodrm/exynos: Don't enable vblank irq early
Sean Paul [Thu, 18 Oct 2012 21:12:01 +0000 (17:12 -0400)]
drm/exynos: Don't enable vblank irq early

This patch fixes a bug where the vsync interrupt was being enabled right
from the win_reset routine. If enable_vblank wasn't called before that,
we would finish pageflip on crtc 0 which would cause tearing on fimd.

BUG=chrome-os-partner:15054
TEST=Tested on snow, tested with boot/hotplug/suspend/resume

Change-Id: I067b2d18dcc48ce5d6cdcfc147d64b7e31f47475
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35979
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agodrm/exynos: hdmi: support for interlaced mode
Akshay Saraswat [Wed, 10 Oct 2012 09:47:10 +0000 (18:47 +0900)]
drm/exynos: hdmi: support for interlaced mode

This patch adds interlaced mode support for exynos 5 HDMI IP
as per the spec requirement and differing quirk register
values between progressive and interlaced in exynos drm
hdmi driver.

BUG=chrome-os-partner:12642
TEST=Tested with two differnet monitors and
        Agilent Technologies N5998A HDMI
        protocol analyzer and generator
        for 1080i modes at 60Hz and 50Hz
        frequencies.

Change-Id: I61743b91d4553089c72c376cfc94b4bb96f1edf6
Signed-off-by: Shirish S <s.shirish@samsung.com>
Signed-off-by: Akshay Saraswat <Akshay.s@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/33427
Tested-by: Akshay Saraswat <akshay.s@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Akshay Saraswat <akshay.s@samsung.com>

11 years agoCHROMIUM: ALSA: hda/ca0132: Stop streaming when turning on/off Crystal Voice.
Chih-Chung Chang [Tue, 23 Oct 2012 03:57:00 +0000 (11:57 +0800)]
CHROMIUM: ALSA: hda/ca0132: Stop streaming when turning on/off Crystal Voice.

Similar to the previous fix for switching between microphones, if an
active recording stream is running, it has to be stopped before turning
on/off Crystal Voice, otherwise the parameters won't be applied correctly.

The patch is provided by Creative.

BUG=chrome-os-partner:14920
TEST=use "arecord -f cd -B 10000 -d 20 1.wav"
to record audio, and plug/unplug headphone while recording.

Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Change-Id: Ic9296b07942cfaeb66c58cc1024dd20bf924a231
Reviewed-on: https://gerrit.chromium.org/gerrit/36314
Reviewed-by: Dylan Reid <dgreid@chromium.org>
11 years agoUPSTREAM: mwifiex: minor cleanup and a fix in scan semaphore usage
Amitkumar Karwar [Sat, 20 Oct 2012 01:27:23 +0000 (21:27 -0400)]
UPSTREAM: mwifiex: minor cleanup and a fix in scan semaphore usage

mwifiex_request_scan() takes care of synchronous internal scan
performed by driver during association.
Currently the semaphore acquired for the scan is unnecessarily
released at the end of different paths. Also, failure paths
returning error code other than "-1" are not considered.

We will release it at the end of routine to fix above issues.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15390
TEST="iw mlan0 scan trigger; ifconfig mlan0 down"

Change-Id: I5b305ad3eca54659e764008bc2373c6dc7d08be8
Reviewed-on: https://gerrit.chromium.org/gerrit/36160
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: ath9k_hw: fix signal strength / noise measurements on ar9462
Felix Fietkau [Wed, 17 Oct 2012 22:57:35 +0000 (00:57 +0200)]
CHROMIUM: ath9k_hw: fix signal strength / noise measurements on ar9462

The nominal noise floor for most channels is -120, though on some it can
reach -127. Use -120 for converting noise floor to channel noise to avoid
overestimating rx signal strength and channel noise.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:13074
TEST=Compare RSSI to neighboring device

Change-Id: I88f0e700097a3961ef5e1bb6400f4d84e13d6ffc
Reviewed-on: https://gerrit.chromium.org/gerrit/36149
Commit-Ready: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: i915: Allow 0 level when turning on backlight.
Daniel Erat [Thu, 18 Oct 2012 23:11:49 +0000 (16:11 -0700)]
CHROMIUM: i915: Allow 0 level when turning on backlight.

Previously, the i915 panel driver would set the backlight to
its maximum level if the level was 0 when turning the
display on.  We don't need this (powerd already does it),
and removing it avoids a potential race where we jump to
100% brightness when the brightness-up key is pressed due to
Chrome turning on the display before powerd sets a non-zero
level.

BUG=chromium-os:31795,chromium-os:32447,chromium-os:35481
TEST=manual: no bright flash when increasing the backlight
     from 0% on lumpy or resuming from suspend
CQ-DEPEND=I26f11562df8e01927c0220cddd91e665fe087be9
CQ-DEPEND=Ia961baae656044c3713fb967d8ad173d317c4217

Signed-off-by: Daniel Erat <derat@chromium.org>
Change-Id: I4bafa1c2e1254b09906245b59c935a4be1088d71
Reviewed-on: https://gerrit.chromium.org/gerrit/36135
Reviewed-by: Simon Que <sque@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoUPSTREAM: ath9k: fix queuing MCI work twice
Rajkumar Manoharan [Wed, 12 Sep 2012 12:41:12 +0000 (18:11 +0530)]
UPSTREAM: ath9k: fix queuing MCI work twice

Right now MCI work is being queued twice by profile and status
updation. Queue MCI work once when it is needed.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15083
TEST=Use bluetooth and WiFi

Change-Id: I6b6bebbef160ab0f68ab56c08d57732dab65507f
Reviewed-on: https://gerrit.chromium.org/gerrit/36148
Commit-Ready: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoUPSTREAM: ath9k: move coex param updation within mci work
Rajkumar Manoharan [Tue, 11 Sep 2012 08:42:47 +0000 (14:12 +0530)]
UPSTREAM: ath9k: move coex param updation within mci work

Update all coex parameters in sigle place. So that we can avoid
redoing the same operation in mutiple places and it eases debugging.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15083
TEST=Use bluetooth and WiFi

Change-Id: Ia694a641418647b90012b891b873aae9b9aa8f26
Reviewed-on: https://gerrit.chromium.org/gerrit/36147
Commit-Ready: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoUPSTREAM: ath9k: flush bt profile whenever it is requested
Rajkumar Manoharan [Wed, 12 Sep 2012 17:38:52 +0000 (23:08 +0530)]
UPSTREAM: ath9k: flush bt profile whenever it is requested

Before processing BT profiles or status messages, check whether
it is requested to flush BT profile. Otherwise it might increase
number of BT profiles that affects the WLAN performance. Also
flush the profiles when MCI is recovering from broken rx. After
flushing BT profiles, query BT topology to refetch them.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15083
TEST=Use bluetooth and WiFi

Change-Id: If6b1d76594407dbddc0b6549491846247fe1c3ca
Reviewed-on: https://gerrit.chromium.org/gerrit/36146
Commit-Ready: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoUPSTREAM: ath9k: Fix BTCOEX timer triggering comparision
Mohammed Shafi Shajakhan [Wed, 12 Sep 2012 17:33:44 +0000 (23:03 +0530)]
UPSTREAM: ath9k: Fix BTCOEX timer triggering comparision

Its more correct to convert btcoex_period to 'us' while
comparing with btcoex_no_stomp which is in 'us'.
Did not find any functionality issues being fixed,
as the generic hardware timer triggers are usually
refreshed with the newer duty cycle.

Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15083
TEST=Use bluetooth and WiFi

Change-Id: I98778ad94bf4affd2b7e0443fda6f25950a89488
Reviewed-on: https://gerrit.chromium.org/gerrit/36144
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: mwifiex: Abort scan when interface is down
Paul Stewart [Fri, 19 Oct 2012 21:51:37 +0000 (14:51 -0700)]
CHROMIUM: mwifiex: Abort scan when interface is down

When the interface is marked down, scans should be aborted,
otherwise we risk memory leaks and code paths that may cause
a crash.

Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15390
TEST="iw mlan0 scan trigger; ifconfig mlan0 down"

Change-Id: I7a9010ce3086a19fbcd143db60dee27290f1e78b
Reviewed-on: https://gerrit.chromium.org/gerrit/36151
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: gobi: fix a crash due to use-after-free of the qcusbnet object
Ben Chan [Sat, 20 Oct 2012 02:56:58 +0000 (19:56 -0700)]
CHROMIUM: gobi: fix a crash due to use-after-free of the qcusbnet object

usbnet_disconnect() calls qcnet_unbind(), which accesses the qcusbnet
object. This patch makes sure that the qcusbnet object is freed after
usbnet_disconnect() is called.

BUG=chrome-os-partner:14889
TEST=Tested the following:
1. emerge-lumpy chromeos-kernel
2. Turn on full SLUB debugging and run suspend_stress_test on a system
   with a Gobi 3000 modem.

Change-Id: I3172565bc0df0c3a283d239424d59b58ae1c262f
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36177
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: cdc_ether: handle Novatel E362 modem with updated firmware
Ben Chan [Sat, 13 Oct 2012 21:53:03 +0000 (14:53 -0700)]
CHROMIUM: cdc_ether: handle Novatel E362 modem with updated firmware

This patch is suggested by Novatel Wireless to allow cdc_ether to
correctly detect a Novatel E362 modem with updated firmware.

BUG=chromium-os:15365
TEST=Verified that the cdc_ether driver correctly detects Novatel E362
modem with firmware 1.41 and 4.08.

Change-Id: If880d26140448fcbdaf89ea1fc546ee861882a19
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36043
Reviewed-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: usb: option: handle identity morphing on Novatel E362 modem
Ben Chan [Sat, 13 Oct 2012 20:41:16 +0000 (13:41 -0700)]
CHROMIUM: usb: option: handle identity morphing on Novatel E362 modem

This patch is suggested by Novatel Wireless to address identity morphing
on Novatel E362 modem such that the correct USB configuration is
selected and detected by the option driver.

BUG=chromium-os:15365
TEST=Verified that the option driver correctly detects Novatel E362
modem with firmware 1.41 and 4.08.

Change-Id: I3449de2327e2b42417e26ff6024f84b72b140853
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36042
Reviewed-by: Paul Stewart <pstew@chromium.org>
11 years agodrm/exynos: Switch debug message DRM_DEBUG_KMS.
Stéphane Marchesin [Mon, 15 Oct 2012 18:43:33 +0000 (11:43 -0700)]
drm/exynos: Switch debug message DRM_DEBUG_KMS.

BUG=none
TEST=by hand; boots, works, doesn't display debug message.

Change-Id: I5f798f352a5455059dcf9241b1dd1ebc02924352
Reviewed-on: https://gerrit.chromium.org/gerrit/35596
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>

11 years agoCHROMIUM: Log RTM_NEWLINK messages broadcast from the kernel (temporary)
Julius Werner [Fri, 19 Oct 2012 20:37:36 +0000 (13:37 -0700)]
CHROMIUM: Log RTM_NEWLINK messages broadcast from the kernel (temporary)

Several recent bug reports document a problem where attached USB
Ethernet adapters are not correctly detected by shill. The issue
persists until reboot once it has happened, but is not generally
reproducable. Logs show that the kernel correctly loads the appropriate
driver, so the issue is believed to be caused by communication problems
between the kernel and shill (via NETLINK_ROUTE sockets).

This patch logs every broadcast of a netlink message with the
RTM_NEWLINK type from the kernel. The surrounding code is slightly
augmented to gather a little more information about the amount of
receipients, but preserves the overall program logic in all cases.

This patch is intended to be temporary. It shall run on production
systems until more reports of the problem (with now more detailed info)
show up, which will hopefully help us nail it down. It should be rolled
back as soon as enough data is available. The additional log burden is
expected to be small (one message per addition, removal and flags change
of a network interface).

BUG=chrome-os-partner:14952,chromium-os:35479
TEST=Add new network interfaces to the system (e.g. by plugging in a USB
Ethernet adapter). Watch RTM_NEWLINK(...) messages appear in dmesg.

Change-Id: I5cf47d0991451679b8a52f9e982d1d695a4f2810
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36150
Reviewed-by: Sameer Nanda <snanda@chromium.org>
11 years agoBACKPORT: e1000e: update driver version number
Bruce Allan [Fri, 17 Aug 2012 06:18:23 +0000 (06:18 +0000)]
BACKPORT: e1000e: update driver version number

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 076d807024052a2c0d76050edd89cd94d0515684)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I60ff19e8f775efa79df42ae406a2a0c7049684c9
Reviewed-on: https://gerrit.chromium.org/gerrit/36132
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup - remove unnecessary variable
Bruce Allan [Fri, 17 Aug 2012 06:18:13 +0000 (06:18 +0000)]
BACKPORT: e1000e: cleanup - remove unnecessary variable

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 70443ae9d07f1c1de2431327814b2594b86a99bb)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I702db3cc922690b83b364c829bbcf3d60751bdb8
Reviewed-on: https://gerrit.chromium.org/gerrit/36131
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup - remove inapplicable comment
Bruce Allan [Fri, 17 Aug 2012 06:18:02 +0000 (06:18 +0000)]
BACKPORT: e1000e: cleanup - remove inapplicable comment

Early Receive has been disabled in the driver so this comment is no longer
applicable.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 419e551caa9e9689aa2f68a8897f9eaf44958eb3)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I9dda059f86d3cc49ccbe031fb06b78800524c46a
Reviewed-on: https://gerrit.chromium.org/gerrit/36130
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup strict checkpatch check
Bruce Allan [Fri, 17 Aug 2012 06:17:57 +0000 (06:17 +0000)]
BACKPORT: e1000e: cleanup strict checkpatch check

CHECK: multiple assignments should be avoided

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 06a402ef51b374f2308b0a6c790b301311df786f)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: If5583527e5abab52556e983e204c6395a8eccae5
Reviewed-on: https://gerrit.chromium.org/gerrit/36129
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup strict checkpatch MEMORY_BARRIER checks
Bruce Allan [Fri, 17 Aug 2012 06:18:07 +0000 (06:18 +0000)]
BACKPORT: e1000e: cleanup strict checkpatch MEMORY_BARRIER checks

Add comments to memory barriers per strict checkpatch.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit bc76329d4a788b1c5f2de7208b2fae4e9204223c)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ia389d29fab4068e1130a8d77aede0f7f3f94bce2
Reviewed-on: https://gerrit.chromium.org/gerrit/36128
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: use correct type for read of 32-bit register
Bruce Allan [Fri, 17 Aug 2012 06:17:51 +0000 (06:17 +0000)]
BACKPORT: e1000e: use correct type for read of 32-bit register

The POEMB register is 32 bits, not 16.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit efc38d2af55d80b4420dab71f6634ad7aa34a38c)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ic86f71b0f7f36c989b9b5dbefa693617331392d7
Reviewed-on: https://gerrit.chromium.org/gerrit/36127
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: DoS while TSO enabled caused by link partner with small MSS
Bruce Allan [Fri, 24 Aug 2012 20:38:11 +0000 (20:38 +0000)]
BACKPORT: e1000e: DoS while TSO enabled caused by link partner with small MSS

With a low enough MSS on the link partner and TSO enabled locally, the
networking stack can periodically send a very large (e.g.  64KB) TCP
message for which the driver will attempt to use more Tx descriptors than
are available by default in the Tx ring.  This is due to a workaround in
the code that imposes a limit of only 4 MSS-sized segments per descriptor
which appears to be a carry-over from the older e1000 driver and may be
applicable only to some older PCI or PCIx parts which are not supported in
e1000e.  When the driver gets a message that is too large to fit across the
configured number of Tx descriptors, it stops the upper stack from queueing
any more and gets stuck in this state.  After a timeout, the upper stack
assumes the adapter is hung and calls the driver to reset it.

Remove the unnecessary limitation of using up to only 4 MSS-sized segments
per Tx descriptor, and put in a hard failure test to catch when attempting
to check for message sizes larger than would fit in the whole Tx ring.
Refactor the remaining logic that limits the size of data per Tx descriptor
from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
Tx packet buffer as described in the hardware specification.

Also, fix the logic in the check for space in the Tx ring for the next
largest possible packet after the current one has been successfully queued
for transmit, and use the appropriate defines for default ring sizes in
e1000_probe instead of magic values.

This issue goes back to the introduction of e1000e in 2.6.24 when it was
split off from e1000.

Reported-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Cc: Stable <stable@vger.kernel.org> [2.6.24+]
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit d821a4c4d11ad160925dab2bb009b8444beff484)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I74b2ec062acf7236a5617d2cc5bc09e2206245ec
Reviewed-on: https://gerrit.chromium.org/gerrit/36126
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: implement MDI/MDI-X control
Jesse Brandeburg [Thu, 26 Jul 2012 02:31:14 +0000 (02:31 +0000)]
BACKPORT: e1000e: implement MDI/MDI-X control

Some users report issues with link failing when connected to certain
switches.  This gives the user the ability to control the MDI state
from the driver, allowing users to work around some improperly
behaving switches.

Forcing in this driver is for now only allowed when auto-neg is
enabled.

This is in regards to the related ethtool app patch and
bugzilla.kernel.org bug 11998

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: bruce.w.allan@intel.com
CC: n.poppelier@xs4all.nl
CC: bastien@durel.org
CC: jsveiga@it.eng.br
Tested-by: Aaron Brown aaron.f.brown@intel.com
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 4e8186b68fb944ad9e7fd4080cd8bd8f10eb7cbd)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Id19381f7f9233f5d44d4cf9ceeb7cbb339fe9b2f
Reviewed-on: https://gerrit.chromium.org/gerrit/36125
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: implement 82577/579 MDI setting support
Bruce W Allan [Thu, 26 Jul 2012 02:30:59 +0000 (02:30 +0000)]
BACKPORT: e1000e: implement 82577/579 MDI setting support

In order for e1000e to support MDI setting support via
ethtool this code is needed to allow setting the MDI state
via software.

This is in regards to the related ethtool patch and
fixes bugzilla.kernel.org bug 11998

Signed-off-by: Bruce W Allan <bruce.w.allan@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Aaron Brown aaron.f.brown@intel.com
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e86fd89188abcc3288ca760a064000054110b2bb)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I69a6ca5367e05cc73551c65857497b41080efc67
Reviewed-on: https://gerrit.chromium.org/gerrit/36124
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: fix panic while dumping packets on Tx hang with IOMMU
Emil Tantilov [Wed, 1 Aug 2012 08:12:21 +0000 (08:12 +0000)]
BACKPORT: e1000e: fix panic while dumping packets on Tx hang with IOMMU

This patch resolves a "BUG: unable to handle kernel paging request at ..."
oops while dumping packet data. The issue occurs with IOMMU enabled due to
the address provided by phys_to_virt().

This patch avoids phys_to_virt() by using skb->data and the address of the
pages allocated for Rx.

Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
(cherry picked from commit f0c5dadff3fbda77a65b8577fee437c3d771233d)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I1631ae1da604c1c805deb5119319599903989e32
Reviewed-on: https://gerrit.chromium.org/gerrit/36123
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: 82571 Tx Data Corruption during Tx hang recovery
Tushar Dave [Wed, 1 Aug 2012 02:11:15 +0000 (02:11 +0000)]
BACKPORT: e1000e: 82571 Tx Data Corruption during Tx hang recovery

A bus trace shows that while executing e1000e_down, TCTL is cleared except
for the PSP bit.  This occurs while in the middle of fetching a TSO packet
since the Tx packet buffer is full at that point. Before the device is
reset, the e1000_watchdog_task starts to run from the middle (it was
apparently pre-empted earlier, although that is not in the trace) and sets
TCTL.EN.  At that point, 82571 transmits the corrupted packet, apparently
because TCTL.MULR was cleared in the middle of fetching a packet, which is
forbidden.

Driver should just clear TCTL.EN in e1000_reset_hw_82571 instead of
clearing the entire register, so as not to change any settings in the
middle of fetching a packet.

Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
(cherry picked from commit eca90f550494171f54f8a700caee65ec16455a5b)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ie6c609dda317b0abcb3ded958a04d31f18040914
Reviewed-on: https://gerrit.chromium.org/gerrit/36122
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: NIC goes up and immediately goes down
Tushar Dave [Tue, 31 Jul 2012 02:02:43 +0000 (02:02 +0000)]
BACKPORT: e1000e: NIC goes up and immediately goes down

commit b7ec70be01a87f2c85df3ae11046e74f9b67e323 upstream.

Found that commit d478eb44 was a bad commit.
If the link partner is transmitting codeword (even if NULL codeword),
then the RXCW.C bit will be set so check for RXCW.CW is unnecessary.
Ref: RH BZ 840642

Reported-by: Fabio Futigami <ffutigam@redhat.com>
Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
CC: Marcelo Ricardo Leitner <mleitner@redhat.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 733e9ad978a1530328ff78aff3186c20000e5b4e)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I3b2347514d74ec7dff07a3cb73bebc91f26c016d
Reviewed-on: https://gerrit.chromium.org/gerrit/36121
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Program the correct register for ITR when using MSI-X.
Matthew Vick [Thu, 12 Jul 2012 00:02:42 +0000 (00:02 +0000)]
BACKPORT: e1000e: Program the correct register for ITR when using MSI-X.

When configuring interrupt throttling on 82574 in MSI-X mode, we need to
be programming the EITR registers instead of the ITR register.

-rc2: Renamed e1000_write_itr() to e1000e_write_itr(), fixed whitespace
      issues, and removed unnecessary !! operation.
-rc3: Reduced the scope of the loop variable in e1000e_write_itr().

Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 22a4cca2f4c2d60c703cdc42158c907570f508e6)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I884a0620d5a87dd3a493b09a27227d084a7419d1
Reviewed-on: https://gerrit.chromium.org/gerrit/36120
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Cleanup code logic in e1000_check_for_serdes_link_82571()
Tushar Dave [Thu, 12 Jul 2012 08:00:15 +0000 (08:00 +0000)]
BACKPORT: e1000e: Cleanup code logic in e1000_check_for_serdes_link_82571()

Cleanup code to make it more clean and readable.

Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 18115f82bc93094a3554f3013cc314ee366a6e7a)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Iac1ad06a179c454a5ae88a676f24bfb3112df1de
Reviewed-on: https://gerrit.chromium.org/gerrit/36119
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: fix test for PHY being accessible on 82577/8/9 and I217
Bruce Allan [Sat, 14 Jul 2012 04:23:58 +0000 (04:23 +0000)]
BACKPORT: e1000e: fix test for PHY being accessible on 82577/8/9 and I217

Occasionally, the PHY can be initially inaccessible when the first read of
a PHY register, e.g. PHY_ID1, happens (signified by the returned value
0xFFFF) but subsequent accesses of the PHY work as expected.  Add a retry
counter similar to how it is done in the generic e1000_get_phy_id().

Also, when the PHY is completely inaccessible (i.e. when subsequent reads
of the PHY_IDx registers returns all F's) and the MDIO access mode must be
set to slow before attempting to read the PHY ID again, the functions that
do these latter two actions expect the SW/FW/HW semaphore is not already
set so the semaphore must be released before and re-acquired after calling
them otherwise there is an unnecessarily inordinate amount of delay during
device initialization.

Reported-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit a52359b56c29f55aaadf1dab80a0e1043b982676)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I464fb0f854f1b77749a54e72622af23f8cefe123
Reviewed-on: https://gerrit.chromium.org/gerrit/36118
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Correct link check logic for 82571 serdes
Tushar Dave [Thu, 12 Jul 2012 08:56:56 +0000 (08:56 +0000)]
BACKPORT: e1000e: Correct link check logic for 82571 serdes

commit d0efa8f23a644f7cb7d1f8e78dd9a223efa412a3 upstream.

SYNCH bit and IV bit of RXCW register are sticky. Before examining these bits,
RXCW should be read twice to filter out one-time false events and have correct
values for these bits. Incorrect values of these bits in link check logic can
cause weird link stability issues if auto-negotiation fails.

Reported-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
Reviewed-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3cc4e0e187e4187a6ec13a79dafc1b0f72e31afa)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I8e72c4b8430345d5abb0c15f6887710ba50baf1b
Reviewed-on: https://gerrit.chromium.org/gerrit/36117
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: remove use of IP payload checksum
Bruce Allan [Sat, 30 Jun 2012 20:02:42 +0000 (20:02 +0000)]
BACKPORT: e1000e: remove use of IP payload checksum

commit 2e1706f234f86ff71056ef69683d734fbf7e9e40 upstream.

Currently only used when packet split mode is enabled with jumbo frames,
IP payload checksum (for fragmented UDP packets) is mutually exclusive with
receive hashing offload since the hardware uses the same space in the
receive descriptor for the hardware-provided packet checksum and the RSS
hash, respectively.  Users currently must disable jumbos when receive
hashing offload is enabled, or vice versa, because of this incompatibility.
Since testing has shown that IP payload checksum does not provide any real
benefit, just remove it so that there is no longer a choice between jumbos
or receive hashing offload but not both as done in other Intel GbE drivers
(e.g. e1000, igb).

Also, add a missing check for IP checksum error reported by the hardware;
let the stack verify the checksum when this happens.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e10e76db80d80227dea2a55ea83613c6a4023e67)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I11aed1e04df72a2f2a47c2934624915765ca0f1c
Reviewed-on: https://gerrit.chromium.org/gerrit/36116
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: use more informative logging macros when netdev not yet registered
Bruce Allan [Thu, 7 Jun 2012 02:23:37 +0000 (02:23 +0000)]
BACKPORT: e1000e: use more informative logging macros when netdev not yet registered

Based on a report from Ethan Zhao, before calling register_netdev() the
driver should be using logging macros that do not display the potentially
confusing "(unregistered net_device)" yet still display the useful driver
name and PCI bus/device/function.

Reported-by: Ethan Zhao <ethan.kernel@gmail.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 185095fb80ce57c0f3db8738e36ad7c02dc34d33)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I3daf6ec165251830e364ee3aea010b5f6e199098
Reviewed-on: https://gerrit.chromium.org/gerrit/36115
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: test for valid check_reset_block function pointer
Bruce Allan [Sat, 26 May 2012 06:08:48 +0000 (06:08 +0000)]
BACKPORT: e1000e: test for valid check_reset_block function pointer

commit 470a54207ccf7045a59df727573bd9d148988582 upstream.

commit 44abd5c12767a8c567dc4e45fd9aec3b13ca85e0 introduced NULL pointer
dereferences when attempting to access the check_reset_block function
pointer on 8257x and 80003es2lan non-copper devices.

This fix should be applied back through 3.4.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e831cf2d290e1ecf7825d2ecfabeb0d6733b133d)

Conflicts:
drivers/net/ethernet/intel/e1000e/ethtool.c

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I487be15ace5bdf6ffdebbf0a699dcbcb3132ef91
Reviewed-on: https://gerrit.chromium.org/gerrit/36114
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: fix Rapid Start Technology support for i217
Bruce Allan [Thu, 10 May 2012 02:51:17 +0000 (02:51 +0000)]
BACKPORT: e1000e: fix Rapid Start Technology support for i217

The definition of I217_PROXY_CTRL must use the BM_PHY_REG() macro instead
of the PHY_REG() macro for PHY page 800 register 70 since it is for a PHY
register greater than the maximum allowed by the latter macro, and fix a
typo setting the I217_MEMPWR register in e1000_suspend_workarounds_ich8lan.

Also for clarity, rename a few defines as bit definitions instead of masks.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 6d7407bfba0b4eb21d843ff1f9e9c86156e502b2)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I68b2fc4a603469f39583a24d49f65fc20caabaa8
Reviewed-on: https://gerrit.chromium.org/gerrit/36113
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: fix typo in definition of E1000_CTRL_EXT_FORCE_SMBUS
Bruce Allan [Thu, 10 May 2012 02:34:39 +0000 (02:34 +0000)]
BACKPORT: e1000e: fix typo in definition of E1000_CTRL_EXT_FORCE_SMBUS

This define is needed by i217.

Reported-by: Bjorn Mork <bjorn@mork.no>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit ba9e186faf9f6bffa5a9bb62891bf9beed9dd7ca)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ic74198fa7a7ecc5387755cba0ee3ac9cdd999d14
Reviewed-on: https://gerrit.chromium.org/gerrit/36112
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Fix merge conflict (net->net-next)
Jeff Kirsher [Wed, 9 May 2012 09:23:46 +0000 (02:23 -0700)]
BACKPORT: e1000e: Fix merge conflict (net->net-next)

During merge of net to net-next the changes in patch:

e1000e: Fix default interrupt throttle rate not set in NIC HW

got munged in param.c of the e1000e driver.  This rectifies the
merge issues.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 2e7d21c54adbab6d10481eddc685328f89bb6389)

Conflicts:
drivers/net/ethernet/intel/e1000e/param.c

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I286eb399a70b2004479f2b2594d886d1b5153d80
Reviewed-on: https://gerrit.chromium.org/gerrit/36111
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: increase version number
Bruce Allan [Fri, 4 May 2012 08:52:03 +0000 (08:52 +0000)]
BACKPORT: e1000e: increase version number

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit a61d3d14227eaa70d45a8c13d15cb9f1abe01f73)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I3bc42dbef42a72d9c7335c8f40148955286bc873
Reviewed-on: https://gerrit.chromium.org/gerrit/36110
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: clear REQ and GNT in EECD (82571 && 82572)
Richard Alpe [Fri, 20 Apr 2012 15:24:50 +0000 (15:24 +0000)]
BACKPORT: e1000e: clear REQ and GNT in EECD (82571 && 82572)

Clear the REQ and GNT bit in the eeprom control register (EECD).
This is required if the eeprom is to be accessed with auto read
EERD register.

After a cold reset this doesn't matter but if PBIST MAC test was
executed before booting, the register was left in a dirty state
(the 2 bits where set), which caused the read operation to time out
and returning 0.

Reference (page 312):
http://download.intel.com/design/network/manuals/316080.pdf

Reported-by: Aleksandar Igic <aleksandar.igic@dektech.com.au>
Signed-off-by: Richard Alpe <richard.alpe@ericsson.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 1f56f45df9f19cdb87bb90020163046f09df9b45)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I4550b3d9640cbf27a393b03ee7c0b1a836308cf9
Reviewed-on: https://gerrit.chromium.org/gerrit/36109
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: enable forced master/slave on 82577
Bruce Allan [Tue, 20 Mar 2012 03:47:41 +0000 (03:47 +0000)]
BACKPORT: e1000e: enable forced master/slave on 82577

Like other supported (igp) PHYs, the driver needs to be able to force the
master/slave mode on 82577.  Since the code is the same as what already
exists in the code flow for igp PHYs, move it to a new function to be
called for both flows.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 7b9f7e3500ae118bbd5833425e318647da8901f4)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ie6342a86c219c3bf79c51f4e751cabbe118377ae
Reviewed-on: https://gerrit.chromium.org/gerrit/36108
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: initial support for i217
Bruce Allan [Thu, 19 Apr 2012 03:21:47 +0000 (03:21 +0000)]
BACKPORT: e1000e: initial support for i217

i217 is the next-generation LOM that will be available on systems with the
Lynx Point Platform Controller Hub (PCH) chipset from Intel.  This patch
provides the initial support for the device.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 2fbe4526e5aafc9ffa5d85fa4749a7c5b22af6b2)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ia6f696af8b4dc84829d5b9351e7577265465ef3d
Reviewed-on: https://gerrit.chromium.org/gerrit/36107
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Update driver version number
Matthew Vick [Wed, 25 Apr 2012 04:45:57 +0000 (04:45 +0000)]
BACKPORT: e1000e: Update driver version number

Version bump to 1.11.3-k.

Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d02c70a8ee1738fc2cf6db18df065977bb44fd50)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I13fe87d4087d630d7d1443023c0d5d6b451c4286
Reviewed-on: https://gerrit.chromium.org/gerrit/36106
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Remove special case for 82573/82574 ASPM L1 disablement
Chris Boot [Tue, 24 Apr 2012 07:24:58 +0000 (07:24 +0000)]
BACKPORT: e1000e: Remove special case for 82573/82574 ASPM L1 disablement

commit 59aed95263bdd0e2b48eb9be5a94346d2d4abf90 upstream.

For the 82573, ASPM L1 gets disabled wholesale so this special-case code
is not required. For the 82574 the previous patch does the same as for
the 82573, disabling L1 on the adapter. Thus, this code is no longer
required and can be removed.

Signed-off-by: Chris Boot <bootc@bootc.net>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e60a87bab7ce339c034b7d7dd365d687bbffd091)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Id20cb1076f5cd3ed349b33d654ea6b253c84da8d
Reviewed-on: https://gerrit.chromium.org/gerrit/36105
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Disable ASPM L1 on 82574
Chris Boot [Tue, 24 Apr 2012 07:24:52 +0000 (07:24 +0000)]
BACKPORT: e1000e: Disable ASPM L1 on 82574

commit d4a4206ebbaf48b55803a7eb34e330530d83a889 upstream.

ASPM on the 82574 causes trouble. Currently the driver disables L0s for
this NIC but only disables L1 if the MTU is >1500. This patch simply
causes L1 to be disabled regardless of the MTU setting.

Signed-off-by: Chris Boot <bootc@bootc.net>
Cc: "Wyborny, Carolyn" <carolyn.wyborny@intel.com>
Cc: Nix <nix@esperi.org.uk>
Link: https://lkml.org/lkml/2012/3/19/362
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8d87325fd98f66eceec445bd0d724feb63335c40)

Conflicts:
drivers/net/ethernet/intel/e1000e/82571.c

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I8f10a74aa9c4fbdc638297d1ca4809b7acc4d6cb
Reviewed-on: https://gerrit.chromium.org/gerrit/36104
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Driver workaround for IPv6 Header Extension Erratum.
Matthew Vick [Wed, 25 Apr 2012 08:01:05 +0000 (08:01 +0000)]
BACKPORT: e1000e: Driver workaround for IPv6 Header Extension Erratum.

Previously, IPv6 extension header parsing was disabled for all devices
supported by e1000e when using packet split mode. However, as per a
silicon errata, only certain devices need this restriction and will need
to disable IPv6 extension header parsing for all modes.

Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit f6bd5577a39aed21cefd698bc46f70cfeaa0923c)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I2a8995f20c3343708f0addebc08e7c3ac6a72255
Reviewed-on: https://gerrit.chromium.org/gerrit/36103
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Resolve intermittent negotiation issue on 82574/82583.
Matthew Vick [Wed, 25 Apr 2012 07:25:18 +0000 (07:25 +0000)]
BACKPORT: e1000e: Resolve intermittent negotiation issue on 82574/82583.

For 82574 and 82583 devices, resolve an intermittent link issue where
the link negotiates to 100Mbps rather than 1Gbps when powering off the
PHY and powering on the PHY after several seconds.

Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 885fe7be4b23d8b9e46cdd87148cefbec926868b)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I7ffc927cdea49ace0065d9d3007063de0e34d6bd
Reviewed-on: https://gerrit.chromium.org/gerrit/36102
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup long [read|write]_reg_locked PHY ops function pointers
Bruce Allan [Sat, 14 Apr 2012 04:21:52 +0000 (04:21 +0000)]
BACKPORT: e1000e: cleanup long [read|write]_reg_locked PHY ops function pointers

Calling the locked versions of the read/write PHY ops function pointers
often produces excessively long lines.  Shorten these as is done with
the non-locked versions of the PHY register read/write functions.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit f1430d698d0caa743af61f72fd539726055718d3)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Iae97aa4c22b3196a4bb16047eca28068d05ec4ab
Reviewed-on: https://gerrit.chromium.org/gerrit/36101
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: suggest a possible workaround to a device hang on 82577/8
Bruce Allan [Tue, 20 Mar 2012 03:48:08 +0000 (03:48 +0000)]
BACKPORT: e1000e: suggest a possible workaround to a device hang on 82577/8

There is a known issue in the 82577 and 82578 device that can cause a hang
in the device hardware during traffic stress; the current workaround in the
driver is to disable transmit flow control by default.  If the user enables
transmit flow control and the device hang occurs, provide a message in the
syslog suggesting to re-enable the workaround.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 7c0427ee76dc96e3f67b90959581d0ba4a38aa63)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ief4106919592948cc94c150ae3f8252e37a96ecb
Reviewed-on: https://gerrit.chromium.org/gerrit/36100
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: fix .ndo_set_rx_mode for 82579
Bruce Allan [Sat, 14 Apr 2012 03:28:50 +0000 (03:28 +0000)]
BACKPORT: e1000e: fix .ndo_set_rx_mode for 82579

Secondary unicast and multicast addresses are added to the Receive
Address registers (RAR) for most parts supported by the driver.  For
82579, there is only one actual RAR and a number of Shared Receive Address
registers (SHRAR) that are shared among the driver and f/w which can be
reserved and write-protected by the f/w.  On this device, use the SHRARs
that are not taken by f/w for the additional addresses.

Add a MAC ops function pointer infrastructure (similar to other MAC
operations in the driver) for setting RARs, introduce a new rar_set
function for 82579 and convert the existing code that sets RARs on other
devices to a generic rar_set function.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 69e1e0197ce739d86ca33fd275962d6cbd1b107a)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Icb50964adb6a436c662e726e9e24ad74e6f87082
Reviewed-on: https://gerrit.chromium.org/gerrit/36099
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: PHY initialization flow changes for 82577/8/9
Bruce Allan [Fri, 13 Apr 2012 03:16:22 +0000 (03:16 +0000)]
BACKPORT: e1000e: PHY initialization flow changes for 82577/8/9

The PHY initialization flows and assorted workarounds for 82577/8/9 done
during driver load and resume from Sx should be the same yet they are not.
Combine the current flows/workarounds into a common set of functions that
are called during the different code paths.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit cb17aab916b0467faecf241c9b3b396b6da045d9)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Id686eccf9974c3349787c7f3b547c82acd5c95e8
Reviewed-on: https://gerrit.chromium.org/gerrit/36098
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: workaround EEPROM configuration change on 82579
Bruce Allan [Tue, 20 Mar 2012 03:47:57 +0000 (03:47 +0000)]
BACKPORT: e1000e: workaround EEPROM configuration change on 82579

An update to the EEPROM on 82579 will extend a delay in hardware to fix an
issue with WoL not working after a G3->S5 transition which is unrelated to
the driver.  However, this extended delay conflicts with nominal operation
of the device when it is initialized by the driver and after every reset
of the hardware (i.e. the driver starts configuring the device before the
hardware is done with it's own configuration work).  The workaround for
when the driver is in control of the device is to tell the hardware after
every reset the configuration delay should be the original shorter one.

Some pre-existing variables are renamed generically to be re-used with
new register accesses.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 62bc813e48aef39c187bb426ddd5441862f1d8d1)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I3fd436e801092c95f980e4a39cb2cc29ea6eeca1
Reviewed-on: https://gerrit.chromium.org/gerrit/36097
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: add transmit timestamping support
Willem de Bruijn [Fri, 27 Apr 2012 09:04:05 +0000 (09:04 +0000)]
BACKPORT: e1000e: add transmit timestamping support

Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 80be3129d7152fe73b7d5db4595e2f4267497f24)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ie5da825f38f8ef62190fd79db6dfd31c2b6a7584
Reviewed-on: https://gerrit.chromium.org/gerrit/36096
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: 82579 potential system hang on stress when ME enabled
Bruce Allan [Tue, 20 Mar 2012 03:47:52 +0000 (03:47 +0000)]
BACKPORT: e1000e: 82579 potential system hang on stress when ME enabled

Previously, a workaround was added to address a hardware bug in the
PCIm2PCI arbiter where a write by the driver of the Transmit/Receive
Descriptor Tail register could happen concurrently with a write of any
MAC CSR register by the Manageability Engine (ME) which could cause the
Tail register to have an incorrect value.  The arbiter is supposed to
prevent the concurrent writes but there is a bug that can cause the Host
(driver) access to be acknowledged later than it should.
After further investigation, it was discovered that a driver write access
of any MAC CSR register after being idle for some time can be lost when
ME is accessing a MAC CSR register.  When this happens, no further target
access is claimed by the MAC which could hang the system.
The workaround to check bit 24 in the FWSM register (set only when ME is
accessing a MAC CSR register) and delay for a limited amount of time until
it is cleared is now done for all driver writes of MAC CSR registers on
82579 with ME enabled.  In the rare case when the driver is writing the
Tail register and ME is accessing any MAC CSR register for a duration
longer than the maximum delay, write the register and verify it has the
correct value before continuing, otherwise reset the device.

This patch also moves some pre-existing macros from the hardware-specific
header file to the more appropriate generic driver header file.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit bdc125f73f3c810754e858b942d54faf4ba6bffe)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Iaa299878813110ed9a572044efebf83e6e2852ed
Reviewed-on: https://gerrit.chromium.org/gerrit/36095
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: 82579 packet drop workaround
Bruce Allan [Tue, 20 Mar 2012 03:47:47 +0000 (03:47 +0000)]
BACKPORT: e1000e: 82579 packet drop workaround

In K1 mode (a MAC/PHY interconnect power mode), the 82579 device shuts down
the Phase Lock Loop (PLL) of the interconnect to save power.  When the PLL
starts working, the 82579 device may start to transfer the packet through
the interconnect before it is fully functional causing packet drops.  This
workaround disables shutting down the PLL in K1 mode for 1G link speed.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 36ceeb43cecaf98a488b94bb318a1f3dd5a87033)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I6006064e066297979152d753ee5d7f89db75163a
Reviewed-on: https://gerrit.chromium.org/gerrit/36094
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Enable DMA Burst Mode on 82574 by default.
Matthew Vick [Fri, 16 Mar 2012 09:02:59 +0000 (09:02 +0000)]
BACKPORT: e1000e: Enable DMA Burst Mode on 82574 by default.

Performance testing has shown that enabling DMA burst on 82574
improves performance on small packets, so enable it by default.

Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 2cb7a9cc008c25dc03314de563c00c107b3e5432)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I48e2bb29b0a8c0940d279f629036194f8df0bc99
Reviewed-on: https://gerrit.chromium.org/gerrit/36093
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Disable Far-End LoopBack following reset on 80003ES2LAN.
Matthew Vick [Fri, 16 Mar 2012 09:02:58 +0000 (09:02 +0000)]
BACKPORT: e1000e: Disable Far-End LoopBack following reset on 80003ES2LAN.

80003ES2LAN has an errata such that far-end loopback may be activated by
bit errors producing a reserved symbol. In order to disable far-end
loopback quickly enough, disable it immediately following a reset.

Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 1c1093a44fd7f994df981c1c4e79e89d33cdedc5)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I9cec2f1a9203b785e45854f65074fb540b51d669
Reviewed-on: https://gerrit.chromium.org/gerrit/36092
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup boolean logic
Bruce Allan [Fri, 13 Apr 2012 00:08:31 +0000 (00:08 +0000)]
BACKPORT: e1000e: cleanup boolean logic

Replace occurrences of 'if (<bool expr> == <1|0>)' with
'if ([!]<bool expr>)'

Replace occurrences of '<bool var> = (<non-bool expr>) ? true : false'
with '<bool var> = <non-bool expr>'.

Replace occurrence of '<bool var> = <non-bool expr>' with
'<bool var> = !!<non-bool expr>'

While the latter replacement is not really necessary, it is done here for
consistency and clarity.  No functional changes.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 04499ec4ee945dfad9f0afbdd8d6f8ba12dac6d6)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I01fc79efd2c6544e0d33aa232c950eee80b00cb8
Reviewed-on: https://gerrit.chromium.org/gerrit/36091
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup remaining strings split across multiple lines
Bruce Allan [Thu, 12 Apr 2012 05:47:09 +0000 (05:47 +0000)]
BACKPORT: e1000e: cleanup remaining strings split across multiple lines

Now that split strings generate checkpatch warnings (per Chapter 2 of
Documentation/CodingStyle to make it easier to grep the code for the
string) cleanup the remaining instances of them in the driver.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 6ad651456e3c8f3ea77056bc05c85e46ab8ead5a)

Conflicts:
drivers/net/ethernet/intel/e1000e/param.c

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I027c96f301d1ad5f5cc8b5c37e91fc27b9f86db4
Reviewed-on: https://gerrit.chromium.org/gerrit/36090
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: update driver version number
Bruce Allan [Tue, 20 Mar 2012 03:48:29 +0000 (03:48 +0000)]
BACKPORT: e1000e: update driver version number

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit fad59b0d3f43bfdc6a726ef83f5bc54920ae098f)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I2530de4b99bf5d47567eba45ac55cd0016a1f4d2
Reviewed-on: https://gerrit.chromium.org/gerrit/36089
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup indexed register arrays
Bruce Allan [Tue, 20 Mar 2012 03:48:13 +0000 (03:48 +0000)]
BACKPORT: e1000e: cleanup indexed register arrays

Some Rx and Tx specific registers are arrays indexed by the queue number.
For clarity, specify the intended queue rather than obscuring it behind a
define.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 1e36052e44a46e14aa2c061db787b92b2c607f05)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I399fefa4fc95e7cd16b54c784cfb84938aa74a9d
Reviewed-on: https://gerrit.chromium.org/gerrit/36088
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup NAPI routine
Bruce Allan [Tue, 20 Mar 2012 03:48:19 +0000 (03:48 +0000)]
BACKPORT: e1000e: cleanup NAPI routine

Rename NAPI polling routine and a parameter with more appropriate names,
refactor a conditional branch to get rid of an unnecessary goto/label and
fix a line exceeding 80 columns.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit c58c8a784b4a8135d3bfc331dbe9d1a8d98e7993)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: If55be3eeab523165030b37a2aa7c2ddbd64c4641
Reviewed-on: https://gerrit.chromium.org/gerrit/36087
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Minor comment clean-up.
Matthew Vick [Fri, 16 Mar 2012 09:03:01 +0000 (09:03 +0000)]
BACKPORT: e1000e: Minor comment clean-up.

Move the first phrase of a multi-line comment to the second line.

Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 397c020ac2edd6757a9bcec2275e02e1ccbc57bf)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I91ce074f0d6f3a20c073956b7b652282f9f5eeb7
Reviewed-on: https://gerrit.chromium.org/gerrit/36086
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: ethtool.h: MDI setting support
Jesse Brandeburg [Thu, 26 Jul 2012 02:30:53 +0000 (02:30 +0000)]
BACKPORT: ethtool.h: MDI setting support

This change modifies the core ethtool struct to allow a driver to
support setting of MDI/MDI-X state for twisted pair wiring.  This
change uses a previously reserved u8 and should not change any
binary compatibility of ethtool.

Also as per Ben Hutchings' suggestion, the capabilities are
stored in a separate byte so the driver can report if it supports
changing settings.

see thread: http://kerneltrap.org/mailarchive/linux-netdev/2010/11/17/6289820/thread

see ethtool patches titled:
ethtool: allow setting MDI-X state

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
Tested-by: Aaron Brown aaron.f.brown@intel.com
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 6f6bbc186dc8e4e0c628db7decbd1a5e02cb5fd8)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ib2743e12132bc14e3ad5f9f11f059aca4a46e684
Reviewed-on: https://gerrit.chromium.org/gerrit/36085
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: ALSA: hda/ca0132 - Fix divide error when frame_bits not set
Hsin-Yu Chao [Fri, 19 Oct 2012 06:04:00 +0000 (14:04 +0800)]
CHROMIUM: ALSA: hda/ca0132 - Fix divide error when frame_bits not set

When frame_bits hasn't been set in snd_pcm_runtime, skip the calcuation
for latency value.

BUG=chrome-os-partner:12926
TEST=Manual. Boot system on battery, open youtube can play without
crash. Run looptest tool with debug log can see latency value changes
correctly according to effects setting.

Change-Id: Iab2d289d9f33e5d4ed178764217b1a08c30c73c5
Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36047
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
11 years agoUPSTREAM: mwifiex: copy MSDU subframes correctly
Yogesh Ashok Powar [Sat, 4 Aug 2012 01:05:59 +0000 (18:05 -0700)]
UPSTREAM: mwifiex: copy MSDU subframes correctly

All MSDU subframes, except the first one in AMSDU, were being written
wrongly at the location of first MSDU frame. Fixing that by copying
the MSDU at skb->tail of AMSDU.

Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
(cherry picked from commit d92a680359ff3230bd1e68ac8f3ac827639f494e)

BUG=chrome-os-partner:14732
TEST=Over-the-air TCP bitrate increases 14% / 11% downlink/uplink

Change-Id: Ib266721b84ec08f5a7369e8d433929e4232917bb
Reviewed-on: https://gerrit.chromium.org/gerrit/35908
Tested-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>

11 years agoBACKPORT: netlink: use kfree_rcu() in netlink_release()
Eric Dumazet [Thu, 18 Oct 2012 03:21:55 +0000 (03:21 +0000)]
BACKPORT: netlink: use kfree_rcu() in netlink_release()

On some suspend/resume operations involving wimax device, we have
noticed some intermittent memory corruptions in netlink code.

Stéphane Marchesin tracked this corruption in netlink_update_listeners()
and suggested a patch.

It appears netlink_release() should use kfree_rcu() instead of kfree()
for the listeners structure as it may be used by other cpus using RCU
protection.

netlink_release() must set to NULL the listeners pointer when
it is about to be freed.

Also have to protect netlink_update_listeners() and
netlink_has_listeners() if listeners is NULL.

Add a nl_deref_protected() lockdep helper to properly document which
locks protects us.

BUG=chromium-os:35452
TEST=compiles, runs

Change-Id: Ie59bb0c4c9f9b97fa43ce3a49407a88687edb2ef
Reported-by: Jonathan Kliegman <kliegs@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Stéphane Marchesin <marcheu@google.com>
Cc: Sam Leffler <sleffler@google.com>
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35959
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
11 years agodrm/exynos: Complete irq when waiting for vsync
Sean Paul [Tue, 9 Oct 2012 19:39:15 +0000 (15:39 -0400)]
drm/exynos: Complete irq when waiting for vsync

Don't exit the vsync irq handler early when waiting for vsync. Just
because we intend on disabling a window, we still need to update drm on
our vsync.

BUG=None
TEST=Tested on snow, didn't note any regressions

Change-Id: If836cee52c9231ea8112aabdb7518b26789bba70
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35037
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoUPSTREAM: mwifiex: remove extra padding to AMSDU
Yogesh Ashok Powar [Sat, 4 Aug 2012 01:06:00 +0000 (18:06 -0700)]
UPSTREAM: mwifiex: remove extra padding to AMSDU

Since commit: fb3c19bc9687d972b83faf366b38ac807eca8f25, adding
extra padding to AMSDU is redundant since same is being performed at
mwifiex_11n_aggregate_pkt after forming the AMSDU packet. Fixing it
by removing it.

Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
(cherry picked from commit 7d273ef32a0d68f2751f74f7401de78f3c95afa8)

BUG=chrome-os-partner:15302
TEST=Load image, run YouTube, run speedtest

Change-Id: I5a2faf5a4e6bdb7669f3b6c424a150bb1e2199e6
Reviewed-on: https://gerrit.chromium.org/gerrit/35895
Tested-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>

11 years agoMALI: Allow release of kds async waits, when contexts are zapped.
John Rees [Wed, 17 Oct 2012 12:12:46 +0000 (13:12 +0100)]
MALI: Allow release of kds async waits, when contexts are zapped.

If a context was destroyed while waiting for a kds resource to be released, then
the destruction of the context would block until the kds resource was released.

Now keeping track of kds waiters so the waits may be cancelled when the context is
destroyed.

BUG=chrome-os-partner:12480
TEST=Booted daisy with aquarium, test zapping a context while waiting for a kds resource to be released.

Change-Id: Ib42b8e5c8039fd5f900885f097418b87d9614225
Signed-off-by: John Rees <john.rees@arm.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/35829
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Commit-Ready: Anush Elangovan <anush@chromium.org>
Tested-by: Anush Elangovan <anush@chromium.org>
11 years agoKDS: add kds_resource_set_release_sync
John Rees [Tue, 16 Oct 2012 14:11:07 +0000 (15:11 +0100)]
KDS: add kds_resource_set_release_sync

kbase was using kds_resource_set_release to cancel a resource lock before
it was acquired. This could sometimes race with acquiring the resource.

To support this functionality add a new _sync version of
kds_resource_set_release.

BUG=chrome-os-partner:15136
TEST=Booted daisy with Aquarium demo running.  Plus repeatedly kill gpu process

Change-Id: I0d0f3967547907644b4a165cebaaa54c0d0edd22
Signed-off-by: John Rees <john.rees@arm.com>
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35691
Commit-Ready: Anush Elangovan <anush@chromium.org>
Tested-by: Anush Elangovan <anush@chromium.org>
11 years agoCHROMIUM: acpi: thermal: honor "mode" sysfs file setting
Sameer Nanda [Wed, 17 Oct 2012 16:49:28 +0000 (09:49 -0700)]
CHROMIUM: acpi: thermal: honor "mode" sysfs file setting

Under each thermal zone there is a file called "mode". Writing enabled
or disabled to this file allows a given thermal zone to be enabled or
disabled. Honor writes to this file by enabling or disabling the
polling timers.

BUG=chrome-os-partner:15347
TEST=stop the thermal loop (stop temp_metrics). Change directory to
/sys/class/thermal/thermal_zone1. Check that trip_point_2_temp is
90000 (90C). Kick off a few CPU load threads (while true; do true;
done). Monitor CPU temperature by reading the temp file in the same
directory. With "mode" file set to "enabled" trip_point_2_temp should
change to 80000 within 10 seconds of temp exceeding 90000. If "mode" is
set to "disabled", trip_point_2_temp should not change.

Change-Id: If27e8ae048fa572b514bc4fba55cd54e68c1d3f9
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35835
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: staging:rts_pstor: Enable ASPM L0s & L1 by default.
Todd Broch [Tue, 16 Oct 2012 16:41:53 +0000 (09:41 -0700)]
CHROMIUM: staging:rts_pstor: Enable ASPM L0s & L1 by default.

Enable ASPM's L0s and L1 to save power when device is idle.

BUG=chrome-os-partner:15258
TEST=manual,
Boot device &
  lspci -vvv | egrep -i "^[0-9]|lnkctl"

Look for Realtek sdcard reader and that the link control says:
  LnkCtl: ASPM L0s L1 Enabled; ...

Change-Id: Ide6fbdeff0a3212639dc2ba85c7b5c43ba3574fe
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35701
Reviewed-by: Sameer Nanda <snanda@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: fix wdm_find_device* return value
Bjørn Mork [Mon, 10 Sep 2012 20:17:34 +0000 (22:17 +0200)]
UPSTREAM: USB: cdc-wdm: fix wdm_find_device* return value

A logic error made the wdm_find_device* functions
return a bogus pointer into static data instead of
the intended NULL no matching device was found.

Cc: stable <stable@vger.kernel.org> # v3.4+
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6a44886899ef8cc396e230e492e6a56a883889f3)

Change-Id: I80f21db165d6f1791c7dd6bf0f02e6deb25b77b7
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35160
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: fix lockup on error in wdm_read
Bjørn Mork [Mon, 2 Jul 2012 08:33:14 +0000 (10:33 +0200)]
UPSTREAM: USB: cdc-wdm: fix lockup on error in wdm_read

Clear the WDM_READ flag on empty reads to avoid running
forever in an infinite tight loop, causing lockups:

Jul  1 21:58:11 nemi kernel: [ 3658.898647] qmi_wwan 2-1:1.2: Unexpected error -71
Jul  1 21:58:36 nemi kernel: [ 3684.072021] BUG: soft lockup - CPU#0 stuck for 23s! [qmi.pl:12235]
Jul  1 21:58:36 nemi kernel: [ 3684.072212] CPU 0
Jul  1 21:58:36 nemi kernel: [ 3684.072355]
Jul  1 21:58:36 nemi kernel: [ 3684.072367] Pid: 12235, comm: qmi.pl Tainted: P           O 3.5.0-rc2+ #13 LENOVO 2776LEG/2776LEG
Jul  1 21:58:36 nemi kernel: [ 3684.072383] RIP: 0010:[<ffffffffa0635008>]  [<ffffffffa0635008>] spin_unlock_irq+0x8/0xc [cdc_wdm]
Jul  1 21:58:36 nemi kernel: [ 3684.072388] RSP: 0018:ffff88022dca1e70  EFLAGS: 00000282
Jul  1 21:58:36 nemi kernel: [ 3684.072393] RAX: ffff88022fc3f650 RBX: ffffffff811c56f7 RCX: 00000001000ce8c1
Jul  1 21:58:36 nemi kernel: [ 3684.072398] RDX: 0000000000000010 RSI: 000000000267d810 RDI: ffff88022fc3f650
Jul  1 21:58:36 nemi kernel: [ 3684.072403] RBP: ffff88022dca1eb0 R08: ffffffffa063578e R09: 0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072407] R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000002
Jul  1 21:58:36 nemi kernel: [ 3684.072412] R13: 0000000000000246 R14: ffffffff00000002 R15: ffff8802281d8c88
Jul  1 21:58:36 nemi kernel: [ 3684.072418] FS:  00007f666a260700(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072423] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul  1 21:58:36 nemi kernel: [ 3684.072428] CR2: 000000000270d9d8 CR3: 000000022e865000 CR4: 00000000000007f0
Jul  1 21:58:36 nemi kernel: [ 3684.072433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072438] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jul  1 21:58:36 nemi kernel: [ 3684.072444] Process qmi.pl (pid: 12235, threadinfo ffff88022dca0000, task ffff88022ff76380)
Jul  1 21:58:36 nemi kernel: [ 3684.072448] Stack:
Jul  1 21:58:36 nemi kernel: [ 3684.072458]  ffffffffa063592e 0000000100020000 ffff88022fc3f650 ffff88022fc3f6a8
Jul  1 21:58:36 nemi kernel: [ 3684.072466]  0000000000000200 0000000100000000 000000000267d810 0000000000000000
Jul  1 21:58:36 nemi kernel: [ 3684.072475]  0000000000000000 ffff880212cfb6d0 0000000000000200 ffff880212cfb6c0
Jul  1 21:58:36 nemi kernel: [ 3684.072479] Call Trace:
Jul  1 21:58:36 nemi kernel: [ 3684.072489]  [<ffffffffa063592e>] ? wdm_read+0x1a0/0x263 [cdc_wdm]
Jul  1 21:58:36 nemi kernel: [ 3684.072500]  [<ffffffff8110adb7>] ? vfs_read+0xa1/0xfb
Jul  1 21:58:36 nemi kernel: [ 3684.072509]  [<ffffffff81040589>] ? alarm_setitimer+0x35/0x64
Jul  1 21:58:36 nemi kernel: [ 3684.072517]  [<ffffffff8110aec7>] ? sys_read+0x45/0x6e
Jul  1 21:58:36 nemi kernel: [ 3684.072525]  [<ffffffff813725f9>] ? system_call_fastpath+0x16/0x1b
Jul  1 21:58:36 nemi kernel: [ 3684.072557] Code: <66> 66 90 c3 83 ff ed 89 f8 74 16 7f 06 83 ff a1 75 0a c3 83 ff f4

The WDM_READ flag is normally cleared by wdm_int_callback
before resubmitting the read urb, and set by wdm_in_callback
when this urb returns with data or an error.  But a crashing
device may cause both a read error and cancelling all urbs.
Make sure that the flag is cleared by wdm_read if the buffer
is empty.

We don't clear the flag on errors, as there may be pending
data in the buffer which should be processed.  The flag will
instead be cleared on the next wdm_read call.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b086b6b10d9f182cd8d2f0dcfd7fd11edba93fc9)

Change-Id: I4640a3e6d7346a791c874bce8c44bddf30a320f4
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35159
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: QMI devices are now handled by qmi_wwan
Bjørn Mork [Wed, 20 Jun 2012 09:53:23 +0000 (11:53 +0200)]
UPSTREAM: USB: cdc-wdm: QMI devices are now handled by qmi_wwan

qmi_wwan has been changed to drive both the control and data
interface for all QMI/wwan devices, using cdc-wdm as a subdriver.
Remove the stale device ID entries from cdc-wdm.

>From now on new QMI/wwan devices will only need to be added to
the qmi_wwan driver, regardless of the USB descriptor layout

Note that this is not appropriate for stable/longterm kernels
despite being a device ID patch.

Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1a86e156e249e5d5c7b8dd4bf93701bb6ccb3cd9)

Change-Id: Ib8965f9c1983f09ddbef8bdc85bd943192088356
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35158
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: Add Vodafone/Huawei K5005 support
Bjørn Mork [Sat, 19 May 2012 17:19:48 +0000 (19:19 +0200)]
UPSTREAM: USB: cdc-wdm: Add Vodafone/Huawei K5005 support

Tested-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit de102ef41f24a4c251c4a3838796bb27557d4d93)

Change-Id: I5948aadfaa18a649c9e9a2da634e985c1ca553eb
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35157
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: remove from device list on disconnect
Bjørn Mork [Wed, 9 May 2012 11:53:23 +0000 (13:53 +0200)]
UPSTREAM: USB: cdc-wdm: remove from device list on disconnect

Prevents dereferencing an invalid struct usb_interface
pointer.

Always delete entry from device list whether or not the
rest of the device state cleanup is postponed. The device
list uses desc->intf as key, and wdm_open will dereference
this key while searching for a matching device.  A device
should not appear in the list unless probe() has succeeded
and disconnect() has not finished.

Cc: Oliver Neukum <oliver@neukum.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6286d85e8efdb59252d1ceb99a56fa6b0b11526c)

Change-Id: I3e46779ed124230465be74f61d81363d3f218870
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35156
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: cannot use dev_printk when device is gone
Bjørn Mork [Wed, 9 May 2012 11:53:22 +0000 (13:53 +0200)]
UPSTREAM: USB: cdc-wdm: cannot use dev_printk when device is gone

We cannot dereference a removed USB interface for
dev_printk. Use pr_debug instead where necessary.

Flush errors are expected if device is unplugged and are
therefore best ingored at this point.

Move the kill_urbs() call in wdm_release with dev_dbg()
for the non disconnect, as we know it has already been
called if WDM_DISCONNECTING is set.  This does not
actually fix anything, but keeps the code more consistent.

Cc: Oliver Neukum <oliver@neukum.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6b0b79d38806481c1c8fffa7c5842f3c83679a42)

Change-Id: Ibad6db9ffb2232308d615fb348ebdf05efbb6be9
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35155
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: poll must return POLLHUP if device is gone
Bjørn Mork [Wed, 9 May 2012 11:53:21 +0000 (13:53 +0200)]
UPSTREAM: USB: cdc-wdm: poll must return POLLHUP if device is gone

Else the poll will be restarted indefinitely in a tight loop,
preventing final device cleanup.

Cc: Oliver Neukum <oliver@neukum.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 616b6937e348ef2b4c6ea5fef2cd3c441145efb0)

Change-Id: I57a7cec6e8cb87bc58a0f8f83f39e1a7434fc59f
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35154
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: cleanup error codes
Oliver Neukum [Mon, 30 Apr 2012 07:57:31 +0000 (09:57 +0200)]
UPSTREAM: USB: cdc-wdm: cleanup error codes

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The internal error codes returned in the write() code
path cannot be simply passed on to user space.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Tested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 12a98b2bd8050b3cf28b50da612c484cdf174368)

Change-Id: Icec86cb9dc6a2011059024b7688feb5fc10f62f6
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35153
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: add debug messages on cleanup
Bjørn Mork [Mon, 30 Apr 2012 07:26:11 +0000 (09:26 +0200)]
UPSTREAM: USB: cdc-wdm: add debug messages on cleanup

Device state cleanup is done in either wdm_disconnect or
wdm_release depending on the order they are called. Adding
a couple of debug messages to document the program flow.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 880bca3a2a6f159d7453e0cbcbfe2f1d8204d907)

Change-Id: I78c3b7815b42737fdedafe43934c1755157c6f7c
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35152
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: fix memory leak
Oliver Neukum [Fri, 27 Apr 2012 12:36:37 +0000 (14:36 +0200)]
UPSTREAM: USB: cdc-wdm: fix memory leak

cleanup() is not called if the last close() comes after
disconnect(). That leads to a memory leak. Rectified
by checking for an earlier disconnect() in release()

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2f338c8a1904e2e7aa5a8bd12fb0cf2422d17da4)

Change-Id: I38528892473fa517b2b0556351018b39982b487d
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35151
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: USB: cdc-wdm: sanitize error returns
Oliver Neukum [Fri, 27 Apr 2012 12:23:54 +0000 (14:23 +0200)]
UPSTREAM: USB: cdc-wdm: sanitize error returns

wdm_flush() returns unsanitized USB error codes.
They must be cleaned up to before being anded to user space

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 24a85bae5da2b43fed423859c09c5a81ab359473)

Change-Id: Ie56272c988fb62601bb50ce60753733467cc25f8
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35150
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: exynos: dts: de-activate HDMI on Spring
Vincent Palatin [Fri, 12 Oct 2012 20:54:09 +0000 (13:54 -0700)]
CHROMIUM: exynos: dts: de-activate HDMI on Spring

The board has nothing connected to the HDMI output,
and all sort of badness happen in the HDMI driver during boot since we
have no HDMI PHY.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14489
TEST=boot on Spring and see we no longer have a warning and a backtrace
in hdmiphy_s_power() function or a crash in i2s probing.

Change-Id: I24e384e5ff969ab4c2a25f969bf6d20b94e82ec7
Reviewed-on: https://gerrit.chromium.org/gerrit/35471
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agomkbp: Clear buffered keyscans on resume
Simon Glass [Wed, 10 Oct 2012 21:39:29 +0000 (14:39 -0700)]
mkbp: Clear buffered keyscans on resume

Since the EC buffers key scans, and will do so while in suspend, we should
clear these out on resume if the EC was not a wake device.

BUG=chrome-os-partner:14523
TEST=manual
Login to snow, close lid to suspend, open, see there are no keypresses
Using a magnet, put snow into suspend, type some keys, remove magnet, see
that there are keys.
Using dbus, suspend, resume and see that there are no keys:
$ dbus-send --type=signal --system /org/chromium/PowerManager org.chromium.PowerManager.RequestSuspend

The resume takes a considerable time over i2c if the buffer is full,
since we have no command to clear the keyboard buffer. For example, for
8 keys it takes 55ms:

chromeos-ec-i2c 4-001e: Discarded 16 keyscan(s) in 55000us

Change-Id: Ib315a62e64bb93a51dc8ff9bdcb413940bbb6309
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35198
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
11 years agoCHROMIUM: snow: Change tps65090 power status check to a warning
Michael Spang [Fri, 12 Oct 2012 23:35:25 +0000 (19:35 -0400)]
CHROMIUM: snow: Change tps65090 power status check to a warning

We're occasionally getting false negatives on power status from the
regulator, where power is on but "power good" is not asserted. Since
we can't rely on this status, don't return an error to the caller.
This avoids cases where power is on, but the regulator driver thinks
it's off.

BUG=chrome-os-partner:14663
TEST=suspend repeatedly checking for no regulator errors

Change-Id: Ie70d88ec86d23d29e1cfa28a8dc0135022d7a3fc
Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35576
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
11 years agoCHROMIUM: ALSA: hda/ca0132 - update latency when dsp effect changes
Hsin-Yu Chao [Fri, 12 Oct 2012 01:59:17 +0000 (09:59 +0800)]
CHROMIUM: ALSA: hda/ca0132 - update latency when dsp effect changes

Before this change, latency value is determined at the
time when a stream was created. Now the latency value gets
updated in ca0132_effects_set() when effects setting has
changed.

BUG=chrome-os-partner:12926
TEST=Manual run looptest tool with debug log to monitor capture &
playback latency value. Can see both latency value changes in realtime
according to 'CrystalVoice' and 'Playback Enhancement' toggles.

Change-Id: I7607368c40599c592dba1edc8e9fbb0cc5937223
Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35566
Reviewed-by: Dylan Reid <dgreid@chromium.org>
11 years agoCHROMIUM: config: enable LP TCP congestion algorithm
Olof Johansson [Mon, 15 Oct 2012 22:06:08 +0000 (15:06 -0700)]
CHROMIUM: config: enable LP TCP congestion algorithm

Gilad wants TCP_CONG_LP enabled, so here we go.

BUG=chromium-os:22154
TEST=http://crosbug.com/35341

Change-Id: I6479e4020842dc065d32c65a42e78a349bd06ab7
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35622
Reviewed-by: Gilad Arnold <garnold@chromium.org>
11 years agoCHROMIUMOS: mwifiex: Set timeout for mwifiex_wait_queue_complete
Paul Stewart [Mon, 15 Oct 2012 22:36:52 +0000 (15:36 -0700)]
CHROMIUMOS: mwifiex: Set timeout for mwifiex_wait_queue_complete

Wait 5 seconds for completion in mwifiex_wait_queue_complete.
If this fails, output a warning, and wait another 5 seconds.
If this fails, crash (instead of hanging the system).

Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15129
TEST=Boot and associate to network.

Change-Id: Ifa12beebbc98d96e7aed2cda6e4d94c23306da5d
Reviewed-on: https://gerrit.chromium.org/gerrit/35624
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoasoc: exynos: hdmi-audio use platform data for hpd gpio information
Rahul Sharma [Sun, 14 Oct 2012 02:10:23 +0000 (07:40 +0530)]
asoc: exynos: hdmi-audio use platform data for hpd gpio information

With this patch, hdmi-audio driver gets the gpio pin number from
platform data instead of getting from device tree. Due to that
of_get_named_gpio_flags was resetting the pin function to hpd
instead of external interrupt. This breaks the hotplug detection.

BUG=chrome-os-partner:15274
TEST=1) Boot with/without hdmi plugged.
2) S2R scenarios.
3) Audio playback with hpd scenarios.

Change-Id: I592942347040003cfe550f97436dacc5aa73a95f
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/35514
Commit-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
11 years agoexynos: drm: hdmi driver provide hpd gpio to hdmi audio device
Rahul Sharma [Sun, 14 Oct 2012 02:00:06 +0000 (07:30 +0530)]
exynos: drm: hdmi driver provide hpd gpio to hdmi audio device

With this patch, drm hdmi driver provides the gpio pin number to
the hdmi-audio device through platform data. Earlier, hdmi-audio
was fetching hpd-gpio property from the device-tree itself. Due
to this of_get_named_gpio_flags was resetting the pin function to
hpd instead of external interrupt. This breaks the hotplug detection.

BUG=chrome-os-partner:15274
TEST=1) Booted with/without hdmi plugged.
2) S2R scenarios.
3) Audio playback with hpd scenarios.

Change-Id: If43c552d98f524d01d1a74d47f42c1f967a0bb52
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/35513
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
11 years agoasoc: hdmi: removed unwanted error messages from hdmi audio plugin
Rahul Sharma [Fri, 12 Oct 2012 16:22:30 +0000 (21:52 +0530)]
asoc: hdmi: removed unwanted error messages from hdmi audio plugin

This patch removes unwanted error messages from hdmi-audio plugin.
These messages are printed when hdmi is not plugged in and plugin
functions are called for hdmi audio configuration. This is done for
caching the audio parameters in the hdmi plugin for later use and
not an error situation.

BUG=None
TEST=verified, no print comes.

Change-Id: Idb06520a6e982a6d329d9b963596f1236e090e67
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/35402
Tested-by: Shirish S <shirish@chromium.org>
Reviewed-by: Prashanth Godrehal <prashanth.g@samsung.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Ready: Shirish S <shirish@chromium.org>

11 years agoCHROMIUM: Input: cyapa - Add debugging to watchdog reset path
Benson Leung [Fri, 12 Oct 2012 23:39:27 +0000 (16:39 -0700)]
CHROMIUM: Input: cyapa - Add debugging to watchdog reset path

Identify the case of watchdog reset and enable debugging
as we are cyapa_detect.

BUG=chromium-os:35287
TEST=Builds clean.

Change-Id: I314e36fdd49475d36091d6c5a4b54bae9992d6a2
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35473
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
11 years agoCHROMIUM: mwifiex: cancel pending scan commands if scan is already aborted
Bing Zhao [Sat, 13 Oct 2012 00:48:28 +0000 (17:48 -0700)]
CHROMIUM: mwifiex: cancel pending scan commands if scan is already aborted

The scan could be aborted by cfg80211 core.c.
Driver should not send any pending scan commands to firmware.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15087
TEST=On Wi-Fi Network Settings, enable Wi-Fi and connect to AP,
then disable Wi-Fi. Repeat above test multiple time.
Turn on driver debug and verify the pending scan commands are
cancelled after scan is aborted by cfg80211.

Change-Id: I8d27266bbda150d34ac442149030c8cfd4e663ab
Reviewed-on: https://gerrit.chromium.org/gerrit/35500
Reviewed-by: Ryan Cairns <rtc@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: mwifiex: Clean up scan state on error
Paul Stewart [Fri, 12 Oct 2012 23:55:03 +0000 (16:55 -0700)]
CHROMIUM: mwifiex: Clean up scan state on error

De-reference and deallocate scan state on failure.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15087
TEST=Reproduce enable/disable of WiFi quickly

Change-Id: I660200025abad5d9718c1fdb0bd7ce4ecbef503e
Reviewed-on: https://gerrit.chromium.org/gerrit/35480
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Ryan Cairns <rtc@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: mwifiex: do not call cfg80211_scan_done if scan is already aborted
Bing Zhao [Fri, 12 Oct 2012 22:17:49 +0000 (15:17 -0700)]
CHROMIUM: mwifiex: do not call cfg80211_scan_done if scan is already aborted

The scan could be aborted by cfg80211 core.c:

if (WARN_ON(rdev->scan_req && rdev->scan_req->wdev == wdev)) {
        rdev->scan_req->aborted = true;
        ___cfg80211_scan_done(rdev, true);
}

Driver shouldn't call cfg80211_scan_done in this case, otherwise
it triggers a "Unable to handle kernel paging request at ..."

BUG=chrome-os-partner:15087
TEST=On Wi-Fi Network Settings, enable Wi-Fi and connect to AP,
then disable Wi-Fi. Repeat above test multiple time.

Change-Id: Ib054d27369ade4d0889880be3d77be0eb6513822
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35479
Reviewed-by: Ryan Cairns <rtc@chromium.org>