Olof Johansson [Tue, 16 Apr 2013 22:15:27 +0000 (15:15 -0700)]
CHROMIUM: config: re-sync kernel config
TBR=sonnyrao,dianders
BUG=none
Change-Id: I60be015dc64c639ef5715b256a3d55298cdafdd7
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48272
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
Dylan Reid [Wed, 17 Apr 2013 03:02:34 +0000 (20:02 -0700)]
BACKPORT: ASoC: max98088: Fix logging of hardware revision.
The hardware revision of the codec is based at 0x40. Subtract that
before convering to ASCII. The same as it is done for 98095.
BUG=chrome-os-partner:18551
TEST=check dmesg and see revision = 'A'
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
(cherry picked from commit
98682063549bedd6e2d2b6b7222f150c6fbce68c)
Change-Id: I942d832bceb9c42370a0dd8364040b157d7ffd77
Reviewed-on: https://gerrit.chromium.org/gerrit/48462
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Owen Lin [Wed, 3 Apr 2013 07:26:48 +0000 (15:26 +0800)]
Raises the limit of number of decodes in mfc_dec.
BUG=chromium:221501
TEST=Run a modified video_decode_accelerator_unittest on daisy and link
Signed-off-by: Owen Lin <owenlin@chromium.org>
Change-Id: If047c5aee937c51cbe57bda4a1b5feca975e9b12
Reviewed-on: https://gerrit.chromium.org/gerrit/48215
Reviewed-by: John Sheu <sheu@chromium.org>
Tested-by: Owen Lin <owenlin@chromium.org>
Commit-Queue: Owen Lin <owenlin@chromium.org>
Chee Kin Cheong [Mon, 15 Apr 2013 22:25:49 +0000 (15:25 -0700)]
CHROMIIM: ALSA: hda/ca0132 - Add AEC level control.
When tuning controls are enabled, export a control to tune the level
of the echo canceller running on the ca0132 DSP.
Change-Id: Ie7717e88c8f5f10dc159f978f8fa5bff77e2a709
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48166
Reviewed-by: Hsinyu Chao <hychao@chromium.org>
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
John Sheu [Wed, 27 Feb 2013 23:18:15 +0000 (15:18 -0800)]
[media] s5p-mfc: Fix frame skip bug
The issue was seen in VP8 decoding where the last frame was
skipped by the driver. This patch gets the correct frame_type value
to fix the bug.
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Signed-off-by: Arun Mankuzhi <arun.m@samsung.com>
BUG=220645
Change-Id: I1784803e3b692afa22d4aa8c966c9f325a20aafd
Reviewed-on: https://gerrit.chromium.org/gerrit/44437
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Todd Broch [Tue, 26 Mar 2013 22:53:49 +0000 (15:53 -0700)]
CHROMIUM: Strengthen ghosting algorithm.
Previous commit added the interpretation of the virtual keystroke from
EC's MKBP, KEY_BATTERY, to allow EC to signal change in USB power for
Spring.
While the edit did address suppressing the input event the virtual
keystroke still plays into the ghosting calculation. This exposed
that the ghosting algorithm was too conservative as ctrl + u +
KEY_BATTERY triggered ghosting logic.
New algorithm correctly identifies all ghosting (3 or more) keystrokes
by factoring in whether the ghost key is valid.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:18354
TEST=manual
1. using evtest I now see ctrl-U
2. escape sequence ctrl-U correctly display 'webpage source'
3. w/ #define DEBUG in mkbp.c no longer see below when ctrl-U pressed
chromeos-ec-i2c 4-001e: ghost found at: r7 c6, pressed 2, teeth 0x4
Change-Id: I693bee2d0e54081c267f449f4b2c7f20a20749ff
Reviewed-on: https://gerrit.chromium.org/gerrit/46585
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Benson Leung [Wed, 30 Jan 2013 00:23:05 +0000 (16:23 -0800)]
CHROMIUM: chromeos_laptop: Add MODULE_DEVICE_TABLE
If chromeos_laptop is built as a module, this will register
this driver as handling the various systems by dmi match,
so input devices, light sensors, and keyboard backlight are
still autoloaded on boot.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chromium-os:38363
TEST=Modify chromeos/config/x86_64/common.config to set
CONFIG_CHROMEOS_LAPTOP=m
build, load this kernel and modules onto Lumpy.
Check that on boot, trackpad works without modprobing
for chromeos_laptop.
Change-Id: Ib0a8f2b1228fc208e17c716d545818ab8b823952
Reviewed-on: https://gerrit.chromium.org/gerrit/42269
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Chung-yih Wang <cywang@chromium.org>
Tested-by: Chung-yih Wang <cywang@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Daniel Kurtz [Wed, 10 Apr 2013 17:43:28 +0000 (01:43 +0800)]
CHROMIUM: drm/exynos: hdmi: remove unused enabled variable
It is set but never checked.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:189108
TEST=builds clean
Change-Id: I60c98a41138d5ae5c7d2876abd02b0cb8b3f57b8
Reviewed-on: https://gerrit.chromium.org/gerrit/47754
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Daniel Kurtz [Wed, 10 Apr 2013 17:42:06 +0000 (01:42 +0800)]
CHROMIUM: drm/exynos: Always DPMS Off in encoder prepare and train dp link in DPMS On
In drm_crtc_helper_set_mode(), the basic sequence for encoders and crtcs
is:
->prepare()
->mode_set()
->commit()
For other drm drivers, .prepare does dpms(Off), and .commit does dpms(On).
Thus, the intention is for the .mode_set() callback is supposed to operate properly
in the dpms(Off) state.
For some reason, exynos was not doing dpms(Off) in .prepare, but it was
doing the dpms(On) in .commit, before calling an explicit
panel_ops->commit().
However, the dpms(On) in encoder .commit() never actually does anything,
since the .dpms routines call power on/off routines that are smart and
silently ignore requests that don't change the power state.
In particular, this dpms(On) wasn't able to actually commit changes,
such as enabling video and training the DP link. Instead, we were
essentially relying on a explicit call to panel_ops->commit() in
encoder->commit() to do the commit.
Also, this means that when exynos_drm_encoder_mode_set calls
panel_ops->set_mode(), the current dpms/power state is whatever it was
before the call to drm_crtc_helper_set_mode(). This is almost always
DPMS(On).
DP link training uses the AUX channel which is only available when
DPMS(On). A recent change to the dp driver to move link training to the
dp panel_ops->mode_set() seemed to work because, as noted above, we are
almost always in DPMS(On) for DP when we do mode_sets.
There is, however, one exception. It is possible for userspace to explicit
turn DPMS(Off) the DP pipe. To save power, for instance. If this is
followed by a suspend/resume cycle, the resume path, will end up
calling DP mode_set() with dpms(Off). This causes a soft lockup since the
AUX channel is not enabled when we try to do link training.
Instead, we just always do DPMS(Off) in .prepare(), get rid of the
explicit DP mode_set(), and let the encoder .commit call our DPMS(On)
which will train the link.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:189108
TEST=(1) On daisy:
set_short_powerd_timeouts ; echo 1 > /var/lib/power_manager/disable_idle_suspend
wait ~20 seconds for powerd to turn off the LCD
./run_remote_tests.sh --board=daisy --remote=$IP power_Resume/control$
TEST=(2) Same as (1) but with HDMI monitor attached too
=> In this case powerd will switch to "presentation mode", so the turn
LCD off time is ~45 seconds (and it takes two timeouts).
TEST=(3) suspend_stress_test should survive even after LCD powers off
Change-Id: I3cd09d5b9555a9e05efc5a66478ab86f2216fc6b
Reviewed-on: https://gerrit.chromium.org/gerrit/47753
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Mike Frysinger [Thu, 11 Apr 2013 18:03:45 +0000 (14:03 -0400)]
CHROMIUM: config: disable OABI support for exynos platforms
We've never shipped a device with userland code using OABI afaik, so
this is enabling code paths that is purely bloat. Disable it like we
have for all other arm platforms.
BUG=None
TEST=`emerge-daisy chromeos-kernel` works and doesn't have OABI enabled
Change-Id: Ie8a67b3db7faba3ac430e1de678e60b1fba1ffb5
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47911
Reviewed-by: Olof Johansson <olofj@chromium.org>
Stéphane Marchesin [Fri, 12 Apr 2013 00:23:44 +0000 (17:23 -0700)]
CHROMIUM: drm/i915: repin bound framebuffers on resume
During suspend/resume all fences are reset, including their pin
count which is reset to 0. However a framebuffer can be bound across
suspend/resume, which means that after the buffer is unbound on
resume, the pin count for the buffer will be negative. Since the
fence pin count is now negative when available and zero when in use,
the buffer's fence will get recycled when the fence is in use which
is the opposite of what we want. The adverse effect is that since the
fence is recycled the tiling mode goes away while the buffer is being
displayed and we get lines/screens of garbage.
To fix this, we reallocate and repin the fences for all bound fbs on
resume, which ensures the pin count is right.
BUG=chromium:219172,chromium:225056
TEST=by hand, suspend/resume on alex, the artifacts are gone
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Change-Id: I9113078b0eb56e671dcca8dc9557a0c0c37f12e0
Reviewed-on: https://gerrit.chromium.org/gerrit/47933
Sonny Rao [Wed, 10 Apr 2013 22:11:10 +0000 (15:11 -0700)]
CHROMIUM: config: turn off KDS and dma-buf on x86 systems
This is only required for Exynos based systems and makes no sense on
x86. This should save some memory.
BUG=none
TEST=kernel builds, boots on lumpy
Change-Id: I929f4205c2c050dab070311e577b88d8c2e1a7fe
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47784
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Mandeep Singh Baines [Wed, 10 Apr 2013 22:38:31 +0000 (15:38 -0700)]
CHROMIUM: config: disable rfkill
We don't use rfkill in ChromeOS.
The rfkill_poll causes 1 wakeup / 5 seconds / per device.
BUG=chromium:227114
TEST=More details in the bug.
TEST=But I verified that wifi still works and verified that wakeups are reduced.
Change-Id: I92aa7fe4e0dbf806fb63ead7f3ba883f79a1a213
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47808
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Andrew de los Reyes [Tue, 9 Apr 2013 16:21:10 +0000 (09:21 -0700)]
CHROMEOS: HACK: Work around bluetooth kernel panic.
This patch is originally from Doron Keren <doronkeren@ti.com>
http://www.spinics.net/lists/linux-bluetooth/msg15564.html . Original
description:
The patch fixes kernel panic which is due to race condition
between the setup of incomming connection and clean-up of the
dead one. Observed in the following case: attached HID device
disconnects unexpectedly (without performing ACL disconnect ),
the device tries to connect again before the ACL link time-out
fires, this translates to the HCI_DISCONNECT, HCI_CONNECT_REQ
events on the same handle, since HCI_DISCONNECT trigers the clean
up of the HID device and handled in different context, the
linking/unlinking connection object to sysfs, may mess up.
BUG=chromium:228937
TEST=The following used to cause a panic reliably, but now doesn't:
- have Apple Magic Trackpad connected and working
- sleep/wake computer
- immediately click/rub fingers on trackpad
Change-Id: I63e0e37afe572641d7bda593887d2e3269043b5a
Signed-off-by: Ilia Kolominsky <iliak@ti.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47653
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Bernie Thompson [Wed, 10 Apr 2013 18:40:34 +0000 (11:40 -0700)]
Adjust the MIF ASV logic to set the voltage to either ASV group
In the case the U-Boot sets the MIF voltage to 1.05v we need to set the
MIF voltage to the 1.00v if the MIF ASV group allows for it. In this case
we can now handle either MIF ASV voltage setting used by U-Boot.
BUG=chrome-os-partner:16895
TEST=Manual, run new kernel on DUT, verify MIF voltage.
Change-Id: I589844034889f0e9ddd55a62226dd4963a4d0eb4
Signed-off-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47757
Paul Taysom [Wed, 10 Apr 2013 17:03:40 +0000 (10:03 -0700)]
CHROMIUM: md: dm-verity fixed setting error_behavior
Need to be able to set the error behavior from either the device table
or from the linux command line.
The code only handled setting from the linux command line which
broke the platform_DMVetiryCorruption test. This was not noticed
earlier because of another bug in error handling that was just
recently was fixed which exposed this problem.
Now the code defaults to the command line but overrides from
the device table.
BUG=chromium:229621
TEST=platform_DMVerityCorruption
Signed-off-by: Paul Taysom <taysom@chromium.org>
Change-Id: I32a516deb2bd564b599e73177e479cddec789dfb
Reviewed-on: https://gerrit.chromium.org/gerrit/47744
Tested-by: Paul Taysom <taysom@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>
Catalin Marinas [Fri, 5 Apr 2013 16:24:56 +0000 (09:24 -0700)]
BACKPORT: arm: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)
On Cortex-A15 (r0p0..r3p2) the TLBI/DSB are not adequately shooting down
all use of the old entries. This patch implements the erratum workaround
which consists of:
1. Dummy TLBIMVAIS and DSB on the CPU doing the TLBI operation.
2. Send IPI to the CPUs that are running the same mm (and ASID) as the
one being invalidated (or all the online CPUs for global pages).
3. CPU receiving the IPI executes a DMB and CLREX (part of the exception
return code already).
The switch_mm() code includes a DMB operation since the IPI is only sent
to CPUs running the same ASID.
BUG=chromium:226280
TEST=There's unfortunately no simple test to trigger this bug, since it
normally manifests vaguely by random crashes or bad data later during
runtime. General testing to make sure it doesn't add new problems (i.e,
BVT, regression suites) is the best approach, followed by observations
of crash rates from the field.
Change-Id: I8fa68bdac9594a90d29079244efa93750f4319e3
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47427
Reviewed-by: Doug Anderson <dianders@chromium.org>
Olof Johansson [Fri, 5 Apr 2013 17:08:36 +0000 (10:08 -0700)]
Revert "UPSTREAM: ARM: Remove current_mm per-cpu variable"
This originally removed some not-needed code, but the recent A15 errata
workaround actually needs current_mm still around. So for bring this
code back for that reason.
This reverts commit
696cfa01f12ec85ac7122eb57d77c8598f79ff71.
BUG=chromium:226280
TEST=build kernel for daisy
Change-Id: Ie44c6bfea7137ca185eb568f9047bca39f3e1b5c
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47426
Reviewed-by: Doug Anderson <dianders@chromium.org>
Bing Zhao [Tue, 9 Apr 2013 21:23:29 +0000 (14:23 -0700)]
mwifiex: remove redundant initialization for bss_descriptor
Initialization of bss_descriptor is unnecessary as the entire
structure will be overwritten by a memcpy.
BUG=chrome-os-partner:18602
TEST=able to associate to AP with and without
slub_debug=FZPUA kernel option.
Change-Id: I4e8cecbf862b75f94fa717007111d0d9f9c0a2e3
Reported-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47690
Reviewed-by: Doug Anderson <dianders@chromium.org>
Bing Zhao [Tue, 9 Apr 2013 00:55:58 +0000 (17:55 -0700)]
mwifiex: fix use-after-free in beacon_ie processing
beacon_ie buffer is allocated in mwifiex_fill_new_bss_desc()
and the buffer pointer is saved in bss_desc->beacon_buf.
beacon_ie is freed before the function returns. However,
bss_desc->beacon_buf is still being accessed afterwards.
Fix it by allocating and freeing the beacon_ie buffer in
caller's scope.
BUG=chrome-os-partner:18602
TEST=able to associate to AP with and without
slub_debug=FZPUA kernel option.
Change-Id: If6ba90dc3a6d6890a4c891a0c4ab06d46f8cdcc9
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47621
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Charlie Mooney [Mon, 8 Apr 2013 17:16:36 +0000 (10:16 -0700)]
Add fallback power config values for Atmel T7
On suspend the atmel driver backs up the power configuration (T7) so
that it can restore it later on resume. If the i2c transaction fails
when it's trying to read the current T7 config it sets a flag saying
that it was unable to back up the config, and then won't try to restore
it when the machine resumes.
A problem occurs if the i2c transaction to read the current config to
back it up on suspend fails, but the driver is still able to turn off
the touchpad. Then on resume, it sees that it had failed to backup the
old values and never restores the T7 object. As a result the
touchscreen/pad never wakes up.
Suspend:
1) Read current T7 config and back it up
2) Overwrite current config with suspend config
Resume
3) restore value stored in step 1
So if step 1 fails, but step 2 succedes we run into a dead touch device
on resume. Reboot fixes everything, however.
This patch adds in some default values in the event that a failed backup
config is detected and makes sure the device actually gets turned on no
matter what on resume.
BUG=chrome-os-partner:17621
TEST=manually tested on Link
Change-Id: I325efae0eb2d801d07898ad29a09e3162e5b79e5
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47564
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Chih-Chung Chang [Wed, 3 Apr 2013 08:39:12 +0000 (16:39 +0800)]
CHROMIUM: ALSA: hda/realtek - Check mic jack state when headphone jack state changes.
Usually the mic jack state changes will generate an unsol mic event,
and we can do auto-mic-switching at that time. But if the mic jack state
is gated by the headphone jack state, there may be no unsol mic event,
and we need to do auto-mic-switching in the unsol headphone event handler.
BUG=chromium:221938
TEST=plug/unplug 3.5mm headset and observe the capture source is switched correctly.
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Change-Id: If057cc20b951fff05af1d6842cbc8e197a93a3f3
Reviewed-on: https://gerrit.chromium.org/gerrit/47231
Paul Taysom [Wed, 27 Mar 2013 17:59:26 +0000 (10:59 -0700)]
CHROMIUM: md: dm-verity: error handling for bad block
In the legacy version of dm-verity, verity_error handled
many different errors. Now it only has to handle bad
hash errors. Simplified to the code to handle only that
case.
BUG=chromium:222545
TEST=./run_remote_tests.sh --board=$B --remote=$IP platform_CorruptRootfs/control
Change-Id: Iaef19a17bd46429cae3589096a8b21ea2d6b70b7
Signed-off-by: Paul Taysom <taysom@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46652
Paul Taysom [Mon, 25 Mar 2013 02:58:17 +0000 (19:58 -0700)]
CHROMIUM: md: dm-verity: call to verity_error missing
The code path going through verity_work, was not calling
verity_error. This meant invalid block errors were not
being passed to the verity-chromeos error handler.
BUG=chromium:222545
TEST=manually corrupt root file system, reboot
Change-Id: I1f1c81feccc6ca5654dc81de3edfc97f240bea01
Signed-off-by: Paul Taysom <taysom@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46376
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Julius Werner [Thu, 4 Apr 2013 16:50:31 +0000 (09:50 -0700)]
TEMP: uvcvideo: Choose first (not last) of equal-sized alt settings
The LiteOn camera built into Spring boards has a weird bug: it reports
three alternate settings on its USB interface that all have the same
transfer size. Linux arbitrarily chooses the last of them, which seems
to work with EHCI but not with XHCI host controllers for reasons beyond
human understanding. Anyway, the first alternate setting seems to work
with both, so let's change the order for now until the vendor can fix
their firmware.
BUG=chrome-os-partner:18460
TEST=Make sure camera works on Spring EVT.
Change-Id: I7734a43b0383cb1d74f30e99a40cbce9db85c7c2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47319
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Laurent Pinchart [Tue, 17 Jul 2012 11:58:48 +0000 (08:58 -0300)]
UPSTREAM: [media] uvcvideo: Support super speed endpoints
Compute the maximum number of bytes per interval using the burst and
multiplier values for super speed endpoints.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
(cherry picked from commit
6fd90db8df379e215f2d495d0b4f3d2553c00277)
BUG=chrome-os-partner:18460
TEST=None
Change-Id: I0ad74ce6edb7316e51a7f5fb7f1d41b4f6e3880c
Reviewed-on: https://gerrit.chromium.org/gerrit/47318
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Doug Anderson [Tue, 2 Apr 2013 16:21:05 +0000 (09:21 -0700)]
arm: exynos: Don't print out warning about negative ASV group
We have seen CPUs that end up with a calculated ASV group of -1.
According to Samsung these should be assigned group 0 and are no
problem, so we shouldn't warn about them. We'll also stop warning
about other negative ASV groups. If we need to find out the
calculated ASV group we can use the "EXYNOS5250: ORIG: %d MOD: %d
RESULT: %d" message and just to the math ourselves (ORIG-MOD).
BUG=chrome-os-partner:18505
TEST=Boot up a device with ASV group -1 and see the warning go away.
Change-Id: I7c20445b1fb5afc233614faace5f387e5c182a03
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47126
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Stéphane Marchesin [Wed, 3 Apr 2013 20:21:45 +0000 (13:21 -0700)]
Revert "drm/exynos: mixer: support for 800x600 resolution"
This reverts commit
ed244d6a805b3c11a72dbce6307ed752e7c15848.
The 800x600 resolution does not work, so let's not expose it as
it causes black screens, especially with projectors where this mode
is very common (we don't have 1024x768 so it falls back to 800x600).
BUG=chromium:225983
TEST=by hand: the 24 inch Dell monitor now picks 640x480 and works fine
Conflicts:
drivers/gpu/drm/exynos/exynos_drm_hdmi.c
Change-Id: I0337a63767b8ed10f1879f8251f54ac6649b604b
Reviewed-on: https://gerrit.chromium.org/gerrit/47268
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stuart Abercrombie <sabercrombie@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Will Drewry [Thu, 21 Mar 2013 22:00:53 +0000 (17:00 -0500)]
CHROMIUM: Restrict swapon() to "zram" devices / lock down zram
This cl contains three distinct changes collapsed into
one CL as per semenzato's request:
1. Restrict CONFIG_SWAP to ensure that only zram devices
may be used.
2. Restrict zram to disallow open calls, even from root, if
the device is claimed (e.g., by sys_swapon)
3. Add swapoff fallback when filp_open fails to use the path lookup.
I don't believe swapoff needs filp_open() since kern_path()
provides the data needed without a file object.
4. Add an open counter to zram to ensure that it is not opened more
times than swapon(2) will claim it -- twice:
- blkdev_get and filp_open (for swap_file)
Signed-off-by: Will Drewry <wad@chromium.org>
TEST=tested on lumpy; swapon, swapoff, change zram during swapon fails, change withotu swapon succeeds.
BUG=chromium:220974
Change-Id: Ic281a7004a81b2897cf0bf1c5d334351061261f1
Reviewed-on: https://gerrit.chromium.org/gerrit/46168
Tested-by: Will Drewry <wad@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Will Drewry <wad@chromium.org>
Luigi Semenzato [Wed, 27 Mar 2013 23:45:14 +0000 (16:45 -0700)]
CHROMIUM: detect GPU memory mapped at < 1MB physaddr.
We want to check if we ever map GPU memory at < 1MB,
because of problems in Sandy Bridge (and possibly Ivy Bridge).
BUG=chromium:224320
TEST=compiled, booted
BRANCH=none
Change-Id: I731da19f2a4d5230f84b54dbfd3993a5cb8dfe72
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46716
Vincent Palatin [Tue, 2 Apr 2013 18:19:09 +0000 (11:19 -0700)]
CHROMIUM: xhci: Ignore spurious successful event on DWC3 controller
The DesignWare USB3 controller behaves the same as the Panther Point
chipset regarding success on short packets.
Let's define the same quirk (see original explanation below).
As DWC3 IP is the only xhci platform driver so far (both in our tree and
tip of upstream kernel), we can simply define it for all platform XHCI
controller.
This quirk was originally added to xhci-pci driver with the following
message in commit
ad80833:
The xHCI host controller in the Panther Point chipset sometimes produces
spurious events on the event ring. If it receives a short packet, it
first puts a Transfer Event with a short transfer completion code on the
event ring. Then it puts a Transfer Event with a successful completion
code on the ring for the same TD. The xHCI driver correctly processes the
short transfer completion code, gives the URB back to the driver, and then
prints a warning in dmesg about the spurious event. These warning
messages really fill up dmesg when an HD webcam is plugged into xHCI.
This spurious successful event behavior isn't technically disallowed by
the xHCI specification, so make the xHCI driver just ignore the spurious
completion event.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:18460
TEST=on Spring EVT board, use camera preview and get an image.
Change-Id: I2857226a763613109da767513f350db4081e45e2
Reviewed-on: https://gerrit.chromium.org/gerrit/47152
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Vivek Gautam [Thu, 21 Mar 2013 06:36:48 +0000 (12:06 +0530)]
BACKPORT: usb: xhci: Fix TRB transfer length macro used for Event TRB.
Use proper macro while extracting TRB transfer length from
Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
for the same, and use it instead of TRB_LEN (bits 0:16) in
case of event TRBs.
This patch should be backported to kernels as old as 2.6.31, that
contain the commit
b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci:
Bulk transfer support". This patch will have issues applying to older
kernels.
Signed-off-by: Vivek gautam <gautam.vivek@samsung.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:18460
TEST=on Spring EVT board, use camera preview and get an image.
Change-Id: Id33eaf62d67edcc5c79a187dd415b914133a58d3
Reviewed-on: https://gerrit.chromium.org/gerrit/47141
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Tue, 8 May 2012 16:22:49 +0000 (09:22 -0700)]
BACKPORT: xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:18460
TEST=on Spring EVT board, use camera preview and get an image.
Change-Id: I5d9ddabd5e8bddd6c2fd2acee2eb8251628f2b9d
Reviewed-on: https://gerrit.chromium.org/gerrit/47140
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Anatol Pomozov [Mon, 1 Apr 2013 16:47:56 +0000 (09:47 -0700)]
UPSTREAM: loop: prevent bdev freeing while device in use
struct block_device lifecycle is defined by its inode (see fs/block_dev.c) -
block_device allocated first time we access /dev/loopXX and deallocated on
bdev_destroy_inode. When we create the device "losetup /dev/loopXX afile"
we want that block_device stay alive until we destroy the loop device
with "losetup -d".
But because we do not hold /dev/loopXX inode its counter goes 0, and
inode/bdev can be destroyed at any moment. Usually it happens at memory
pressure or when user drops inode cache (like in the test below). When later in
loop_clr_fd() we want to use bdev we have use-after-free error with following
stack:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000280
bd_set_size+0x10/0xa0
loop_clr_fd+0x1f8/0x420 [loop]
lo_ioctl+0x200/0x7e0 [loop]
lo_compat_ioctl+0x47/0xe0 [loop]
compat_blkdev_ioctl+0x341/0x1290
do_filp_open+0x42/0xa0
compat_sys_ioctl+0xc1/0xf20
do_sys_open+0x16e/0x1d0
sysenter_dispatch+0x7/0x1a
To prevent use-after-free we need to grab the device in loop_set_fd()
and put it later in loop_clr_fd().
The issue is reprodusible on current Linus head and v3.3. Here is the test:
dd if=/dev/zero of=loop.file bs=1M count=1
while [ true ]; do
losetup /dev/loop0 loop.file
echo 2 > /proc/sys/vm/drop_caches
losetup -d /dev/loop0
done
[ Doing bdgrab/bput in loop_set_fd/loop_clr_fd is safe, because every
time we call loop_set_fd() we check that loop_device->lo_state is
Lo_unbound and set it to Lo_bound If somebody will try to set_fd again
it will get EBUSY. And if we try to loop_clr_fd() on unbound loop
device we'll get ENXIO.
loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under
loop_device->lo_ctl_mutex. ]
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
BUG=chromium:221466
TEST=link build, manual testing
(cherry picked from upstream commit
c1681bf8a7b1b98edee8b862a42c19c4e53205fd)
Change-Id: Ic728f6f5dc6664bbc06e0265345208a862130bac
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47072
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Nicolas Pitre [Tue, 12 Mar 2013 12:00:42 +0000 (13:00 +0100)]
UPSTREAM: ARM: 7670/1: fix the memset fix
Commit
455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value. However the memset itself became broken
by that patch for misaligned pointers.
This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.
Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.
While at it, the entry instructions are slightly reworked to help dual
issue pipelines.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit
418df63adac56841ef6b0f1fcf435bc64d4ed177)
Change-Id: I30ffc36e387901ab33739325ce22b6ee9da52da4
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47028
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Ivan Djelic [Wed, 6 Mar 2013 19:09:27 +0000 (20:09 +0100)]
UPSTREAM: ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations
Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.
For instance in the following function:
void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
{
memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
waiter->magic = waiter;
INIT_LIST_HEAD(&waiter->list);
}
compiled as:
800554d0 <debug_mutex_lock_common>:
800554d0:
e92d4008 push {r3, lr}
800554d4:
e1a00001 mov r0, r1
800554d8:
e3a02010 mov r2, #16 ; 0x10
800554dc:
e3a01011 mov r1, #17 ; 0x11
800554e0:
eb04426e bl
80165ea0 <memset>
800554e4:
e1a03000 mov r3, r0
800554e8:
e583000c str r0, [r3, #12]
800554ec:
e5830000 str r0, [r3]
800554f0:
e5830004 str r0, [r3, #4]
800554f4:
e8bd8008 pop {r3, pc}
GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.
This patch fixes the return value of the assembly version of memset.
It adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:
Step 1
======
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).
Step 2
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:
save r8:
- str lr, [sp, #-4]!
+ stmfd sp!, {r8, lr}
and restore r8 on both exit paths:
- ldmeqfd sp!, {pc} @ Now <64 bytes to go.
+ ldmeqfd sp!, {r8, pc} @ Now <64 bytes to go.
(...)
tst r2, #16
stmneia ip!, {r1, r3, r8, lr}
- ldr lr, [sp], #4
+ ldmfd sp!, {r8, lr}
Step 3
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:
save r8:
- stmfd sp!, {r4-r7, lr}
+ stmfd sp!, {r4-r8, lr}
and restore r8 on both exit paths:
bgt 3b
- ldmeqfd sp!, {r4-r7, pc}
+ ldmeqfd sp!, {r4-r8, pc}
(...)
tst r2, #16
stmneia ip!, {r4-r7}
- ldmfd sp!, {r4-r7, lr}
+ ldmfd sp!, {r4-r8, lr}
Step 4
======
Rewrite register list "r4-r7, r8" as "r4-r8".
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit
455bd4c430b0c0a361f38e8658a0d6cb469942b5)
Change-Id: Idfbebdd48103e5fa4ae7faeae78dfabace28f0a7
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47027
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Pawel Osciak [Fri, 22 Mar 2013 14:40:25 +0000 (07:40 -0700)]
CHROMIUM: config: Add vivi to base config for testing purposes
vivi is a virtual capture driver that acts like a camera. Add it to the default
build for testing purposes.
Eventually we'd like to have it built for testing images only.
BUG=chromium:223099
TEST=manual build and test
Signed-off-by: Pawel Osciak <posciak@chromium.org>
Change-Id: Ic9b4f95eb10ee609d8e070cb93891164da37f4f4
Reviewed-on: https://gerrit.chromium.org/gerrit/46269
Commit-Queue: Pawel Osciak <posciak@google.com>
Reviewed-by: Pawel Osciak <posciak@google.com>
Tested-by: Pawel Osciak <posciak@google.com>
Joonyoung Shim [Wed, 27 Jun 2012 05:27:06 +0000 (14:27 +0900)]
BACKPORT: drm/exynos: add property for plane zpos
The exynos drm driver used a specific ioctl - DRM_EXYNOS_PLANE_SET_ZPOS
to set zpos of plane. It can be substitute to property of plane. This
patch adds a property for plane zpos and removes
DRM_EXYNOS_PLANE_SET_ZPOS ioctl.
BUG=chromium:222980
TEST=Verified that cursor works when using property to set zpos.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
(cherry picked from commit
00ae67cf26fad3889e71e3bdbec012b1f938dc0e)
Change-Id: I018b6475916f6bbff416d0313fe0c7c3c68217b8
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46957
Reviewed-by: John Sheu <sheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Joonyoung Shim [Wed, 27 Jun 2012 05:27:04 +0000 (14:27 +0900)]
BACKPORT: drm/exynos: use private plane for crtc
The crtc can use private plane instead it has overlay struct. It will be
helpful use plane feature from crtc later.
BUG=chromium:222980
TEST=By hand.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
(cherry picked from commit
b5d2eb3bd691c0b6869a2013e719a61c595d73a6)
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Change-Id: I3385e40cac26ebb2d71670f71eb1d3f91638437e
Reviewed-on: https://gerrit.chromium.org/gerrit/46956
Reviewed-by: John Sheu <sheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Dylan Reid [Fri, 29 Mar 2013 22:42:06 +0000 (15:42 -0700)]
CHROMIUM: ASoC: max98088 - expose digital mic enable switches.
Add a control for enable right and left digital mic. This control
routes the digital mic input through the ADC. It must be disabled for
analog input to work.
BUG=chrome-os-partner:18454
TEST=toggle switches, see changes with i2cdump.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I8ed493ce9aea4f94f4feda23172e2e3251e27b51
Reviewed-on: https://gerrit.chromium.org/gerrit/46904
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Dylan Reid [Fri, 29 Mar 2013 21:55:52 +0000 (14:55 -0700)]
CHROMIUM: ASoC: daisy - different mic bias for spring.
Spring's mic bias control is "MICBIAS" not "MICBIAS2", set
appropriately.
BUG=chrome-os-partner:18454
TEST=boot; check mic bias register.
Change-Id: Ibd67346dbec153c2635b6a318143766f3f98155a
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46932
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tai-Hsu Lin [Thu, 21 Mar 2013 07:54:02 +0000 (15:54 +0800)]
CHROMIUM: input: cyapa - fix power mode switch problems
We have found that some commands may fail if the touchpad is
not running at the full mode. Moreover, setting new power modes
would take the amount of time roughly equal to the old scanrate
to complete. The patch fixes several places where the unsafe
commands might be run before completely returning to the full
mode. Meanwhile, the cyapa_set_power_mode function now returns
early if the mode to set is the same as the current one.
Signed-off-by: Tai-Hsu Lin <sheckylin@chromium.org>
BUG=chromium:196520
TEST=Repeatedly suspend/resume the device with Cypress touchpad for
a few hundred times. One should see errors about reading query data
in the /var/log/messages.
With the fix, one shouldn't see the error.
Change-Id: I95a843a077d5840c57cc24daf85b6549550fa73d
Reviewed-on: https://gerrit.chromium.org/gerrit/46115
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Tai-Hsu Lin <sheckylin@chromium.org>
Tested-by: Tai-Hsu Lin <sheckylin@chromium.org>
Daniel Kurtz [Mon, 25 Mar 2013 13:00:40 +0000 (21:00 +0800)]
CHROMIUM: drm/exynos: Propagate controller's enable_vblank() result
The controller enable_vblank() can fail if, for example, it is requested
while suspended (fimd) or before the mixer is powered on.
In these cases, the error could should be propagated up to the higher
layers so they can deal with it appropriately (i.e., try again later).
In particular, this solves a race at HDMI hotplug where a userspace
WaitVBlank ioctl races with the hdmi/mixer power on sequence.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:223501
TEST=boot w/ HDMI disconnected. Login as guest. Plug HDMI cable.
Should see extended desktop, pointer should move on external monitor.
Change-Id: Id2c54ce8c1c500bc95321a6b00fa147348c29125
Reviewed-on: https://gerrit.chromium.org/gerrit/46399
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Andrew de los Reyes [Sun, 24 Feb 2013 18:45:11 +0000 (10:45 -0800)]
CHROMEOS: HID: Support for Logitech T651 Touchpad
This touchpad is similar to the T650, but has a few notable
differences:
- It connects via Bluetooth as opposed to the Unifying Receiver
- The raw data reports are in a unique format appended to normal mouse
reports. The mouse reports must be ignored. Putting this pad into
raw data mode will work as the T650 does, but Nestor Lopez Casado of
Logitech advises against as that mode as it's not officially
supported.
BUG=chromium:223138
TEST=Manually tested on device. Will add base regression tests.
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I9c6e3359f08508c54c47e79bec1bbc0121d0b06c
Reviewed-on: https://gerrit.chromium.org/gerrit/46683
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Rob Clark [Thu, 17 May 2012 08:23:27 +0000 (02:23 -0600)]
UPSTREAM: drm: add plane properties
The omapdrm driver uses this for setting per-overlay rotation. It
is likely also useful for setting YUV->RGB colorspace conversion
matrix, etc.
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
4d93914ae3db4a897ead4b1e33eca7cdfff4c6f7)
BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.
Change-Id: I8f50d93443cc6c51f06d553cd0286fff11de3269
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40516
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Paulo Zanoni [Tue, 15 May 2012 21:09:04 +0000 (18:09 -0300)]
UPSTREAM: drm: add 'count' to struct drm_object_properties
This way, we don't need to count every time, so we're a little bit
faster and code is a little bit smaller.
Change suggested by Ville Syrjälä.
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
7f88a9bedfb814a2d4d537db8295c524298256cb)
BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.
Change-Id: Ic184b52fb6d587a69943744e38f8f73bad2cb6e1
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40514
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Paulo Zanoni [Tue, 15 May 2012 21:09:03 +0000 (18:09 -0300)]
UPSTREAM: drm: make the connector properties code use the object properties code
In the future, we may want to kill the internal functions:
- drm_connector_attach_property
- drm_connector_property_set_value
- drm_connector_property_get_value
It seems the IOCTL drm_mode_connector_property_set_ioctl will have to live, but
we may change libdrm to not use it anymore, if we want.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
0057d8dd8d378bf88f75736496d779f3c9454b5f)
BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.
Change-Id: Id7f04a7b9e5b0dc40ef08e13405fe76f003ab898
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40513
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Paulo Zanoni [Tue, 15 May 2012 21:09:02 +0000 (18:09 -0300)]
UPSTREAM: drm: add generic ioctls to get/set properties on any object
Useless for connector properties (since they already have their own
ioctls), but useful when we add properties to CRTCs, planes and other
objects.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
c543188afb7a83e66161c026dc6fd5eb38dc0b63)
BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.
Change-Id: Ia187a647bedeee39d16902c6df22e2cac04a74bc
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40512
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Paulo Zanoni [Tue, 15 May 2012 21:09:01 +0000 (18:09 -0300)]
UPSTREAM: drm: create struct drm_object_properties and use it
For now, only connectors have it. In the future, all objects that need
properties should use it. Since the structure is referenced inside
struct drm_mode_object, we will be able to deal with object properties
without knowing the real type of the object.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
7e3bdf4a6dca9eb153cc20d69d717308a68bec00)
BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.
Change-Id: Ic125db59d6c7a4d11671f5f3529a7bf409367e87
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40511
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Paulo Zanoni [Tue, 15 May 2012 21:09:00 +0000 (18:09 -0300)]
UPSTREAM: drm: WARN() when drm_connector_attach_property fails
Also return void instead of int. We have more than 100 callers and
no one checks for the return value.
If this function fails the property won't be exposed by the get/set
ioctls, but we should probably survive. If this starts happening,
the solution will be to increase DRM_CONNECTOR_MAX_PROPERTY and
recompile the Kernel.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
afea2ad53f1fef0b57d0e59fa062f54797158b14)
BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.
Change-Id: Ibcf34e79c3f310a53345bfde5ee7853495171ced
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40510
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Paulo Zanoni [Tue, 15 May 2012 21:08:59 +0000 (18:08 -0300)]
UPSTREAM: drm: add drm_property_change_is_valid
Move code from drm_mode_connector_property_set_ioctl to a new
function, so we can reuse this code when we add crtc properties.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
26a3481586eb1918a75d338e31c990deab06fb5b)
BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.
Change-Id: I09b99bf3cc8ad332c9129e59d4c030314a70da79
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40509
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Paul Taysom [Mon, 25 Mar 2013 02:47:07 +0000 (19:47 -0700)]
CHROMIUM: md: dm-verity-chromeos: changed how kernel parititon is corrupted
Changed the error handling to use the linux cmdline
to find the kernel partition to corrupt it so when
an error is detected in the root volume, the bios
will know to switch partitions.
BUG=chromium:222954
TEST=1. manually corrupt root partition and bootcache and reboot 2. manually corrupted root paritions with no bootcache
Signed-off-by: Paul Taysom <taysom@chromium.org>
Change-Id: I9ea8c5462d573fc8599be36b4c6eaf1f4c7eb99c
Reviewed-on: https://gerrit.chromium.org/gerrit/46375
Tested-by: Paul Taysom <taysom@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>
Benson Leung [Tue, 26 Mar 2013 00:21:56 +0000 (17:21 -0700)]
CHROMIUM: Input: atmel_mxt_ts - Disregard matrix size for config update check
The config update's header check function compares the x size and y size bytes
in the raw config file with the corresponding bytes from the device.
Unfortunately, these bytes may be changed by changing T46 byte 1, so they
should not be treated as an immutable quality of the device.
We've run into several situations where a firmware update or an invalid
config update blows away the correct value in the device's registers,
and the driver refuses to update to restore the correct register config.
This change skips over the check of the x size and y size, and skips over
the info block crc check in case the size is different, as the crc comparison
with the device's info block crc will also fail.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:18386
TEST=Follow the steps below to write an incorrect value into the XYMode reg:
cd /sys/bus/i2c/devices/1-004b
echo "
2e000100" > object
echo 1 > backupnv
echo "
06000001" > object
shutdown -P now
Boot the system again.
With this fix, the trackpad should be functional, and the following should
be in /var/log/messages:
chromeos-touch-config-update[285]-atmel_mxt_tp: Device config checksum : a9ffd4
chromeos-touch-config-update[285]-atmel_mxt_tp: New config checksum : a84914
atmel_mxt_ts 1-004b: Using config file maxtouch-tp.cfg (size = 1102)
atmel_mxt_ts 1-004b: Config File: Version = OBP_RAW V1
atmel_mxt_ts 1-004b: Config File: Chip ID = 82 01 10 aa 13 0b 16
atmel_mxt_ts 1-004b: Matrix Xsize and Ysize mismatch. Updating.
atmel_mxt_ts 1-004b: Chip Info: 82 01 10 aa 10 0e 16
atmel_mxt_ts 1-004b: Config File: Config CRC = 56506a
Followed by the normal config update output, then confirmation the update worked:
chromeos-touch-config-update[285]-atmel_mxt_tp: Try #1: Checking new device csum a84914
chromeos-touch-config-update[285]-atmel_mxt_tp: Config update succeeded
Change-Id: I22046b6709bfbfc38e9105543cae9d5ff5e6e183
Reviewed-on: https://gerrit.chromium.org/gerrit/46471
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Derek Basehore [Tue, 19 Mar 2013 00:58:26 +0000 (17:58 -0700)]
backlight: don't resume backlight for dark resume
For an idle suspend, we set the resume backlight sysfs file which is used during
resume in the kernel. This causes the screen to flash on for a moment during a
dark resume. This change prevents the backlight resume from doing anything
during a dark resume.
BUG=chrome-os-partner:9812
TEST=idle suspend system with dark resume (see backlight doesn't turn on)
Change-Id: Iccd02b99bdd682853fc9b184817c4d43028afcf6
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45824
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Shawn Nematbakhsh [Fri, 22 Mar 2013 23:24:10 +0000 (16:24 -0700)]
Revert "CHROMIUM: Input: synaptics - skip trackpoint reconnect"
This reverts commit
6e600b92ec9ff57a6e4935ae31f3b6425c4c3344.
Due to the new trackpoint driver optimization, we no longer need this
workaround. The long trackpoint connect / reconnect sequence has been
mostly replaced by a power-on reset command which speeds things up
considerably.
TEST=Manual. Run powerd_suspend + wake, verify long trackpoint reconnect
delay no longer exists.
BUG=chrome-os-partner:18349
Change-Id: I52ff4515b5048ac836ac6c70cdb0140a89b9bb9b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46323
Reviewed-by: Chung-yih Wang <cywang@chromium.org>
Shawn Nematbakhsh [Fri, 22 Mar 2013 02:52:55 +0000 (19:52 -0700)]
CHROMIUM: input: mouse - Optimize trackpoint init sequence.
The trackpoint driver sets various parameter default values, all of
which happen to be power-on defaults (Source: IBM TrackPoint Engineering
Specification. Version 4.0, also confirmed by empirical data).
By sending the power-on reset command to reset all parameters to
power-on state, we can skip the lengthy process of programming all
parameters. In testing, ~3 secs of time writing parameters was reduced
to .35 seconds waiting for power-on reset to complete.
TEST=Manual. Verify power-on reset initializes values to desired
defaults.
BUG=chrome-os-partner:18349
Change-Id: Ia16ae32c3ea1e67681b1e9154847119e24fa832d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46221
Reviewed-by: Chung-yih Wang <cywang@chromium.org>
Shawn Nematbakhsh [Thu, 21 Mar 2013 21:34:05 +0000 (14:34 -0700)]
CHROMIUM: input: serio - Remove unnecessary port rescans.
When a serio_interrupt is received, if no driver is attached to the
port, a rescan event will be queued. Between the time the event is
queued and processed, it is possible that a driver will become attached
to the port (ex. through a previously queued ATTACH_DRIVER event). In
this case, the the driver / device will needlessly be initialized twice.
This change clears the queue of rescan events for a port if a driver
becomes attached to the port.
TEST=Manual. Verify that rescan does not occur due to trackpad interrupt
received in early boot on Stout platform.
BUG=chrome-os-partner:18327
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I43baf609e65c716628d37d157b26194085440850
Reviewed-on: https://gerrit.chromium.org/gerrit/46183
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Chung-yih Wang <cywang@chromium.org>
Che-Liang Chiou [Wed, 16 Jan 2013 00:06:52 +0000 (16:06 -0800)]
HID: magicmouse: Set multi-touch keybits for Magic Mouse
(This was reverted because this causes Chrome to consider Magic Mouse as
a touchpad. But once we switch mice to gestures library, I think it
should be fine to merge this change.)
The driver emits multi-touch events for Magic Trackpad as well as Magic
Mouse, but it does not set keybits that are related to multi-touch event
for Magic Mouse; so set these keybits.
The keybits that are not set cause trouble because user programs often
probe these keybits for self-configuration and thus they cannot operate
properly if the keybits are not set.
One of such troubles is that libevdev will not be able to emit correct
touch count, causing gestures library failed to do fling stop.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chromium-os:36322
TEST=On Snow, connect Magic Mouse and touch it; evtest should show
BTN_TOUCH and BTN_TOOL_FINGER.
Event: time
1363905613.064416, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time
1363905613.064421, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time
1363905613.064423, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Then test scroll and fling stop; it should work now.
Finally, check /var/log/Xorg.0.log and does not see error
message of "Too many fingers! Max is 1, but I got 2"
Original-Change-Id: Ie7fd4327935555f41577e2c8c6d6d78b52934f1a
Reviewed-on: https://gerrit.chromium.org/gerrit/41322
Commit-Queue: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
(cherry picked from commit
5c1386506de5237373db16f470d54e8a83afe318)
Change-Id: I6702dbf400aa28296308a467d065fd5a326ac30a
Reviewed-on: https://gerrit.chromium.org/gerrit/46169
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Commit-Queue: Che-Liang Chiou <clchiou@chromium.org>
Andrew de los Reyes [Mon, 4 Feb 2013 01:55:26 +0000 (17:55 -0800)]
CHROMEOS: Enable HID_LOGITECH_WTP
BUG=chromium-os:39354
TEST=manually tested on Link
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I102167f48fb1c4a2fefedd388af92455c2dba3dc
Reviewed-on: https://gerrit.chromium.org/gerrit/46011
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Andrew de los Reyes [Sun, 6 Jan 2013 01:50:20 +0000 (17:50 -0800)]
CHROMEOS: HID: MT-B driver for Logitech wireless touchpads
This is part of the next iteration of Nestor Lopez Casado's
introduction of HID++ support to the kernel from his patch "[PATCH
1/1] HID: Add full MT support for Logitech Wireless Touchpad"
This driver provides an MT-B driver for Logitech wireless
touchpads. It currently supports two models:
- Logitech Wireless Touchpad
- Logitech Wireless Rechargeable Touchpad T650
Documentation is provided at
https://drive.google.com/a/logitech.com/?tab=mo#folders/0BxbRzx7vEV7eWmgwazJ3NUFfQ28
BUG=chromium-os:39354
TEST=manually tested on Link
Change-Id: I0085dfb053f7b9c0931c39c0d28ba1608216a2a5
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46010
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Andrew de los Reyes [Sun, 6 Jan 2013 01:49:05 +0000 (17:49 -0800)]
CHROMEOS: HID: Helper functions for Logitech HID++
This is part of the next iteration of Nestor Lopez Casado's
introduction of HID++ support to the kernel from his patch "[PATCH
1/1] HID: Add full MT support for Logitech Wireless Touchpad"
HID++ is a Logitech-specific protocol for communicating with HID
devices. It can be used, for example, to probe properties of devices
(like touch surface dimensions, battery status, and more), and to set
state on a device (like a request to put the device into raw mode).
Documentation is provided at
https://drive.google.com/a/logitech.com/?tab=mo#folders/0BxbRzx7vEV7eWmgwazJ3NUFfQ28
BUG=chromium-os:39354
TEST=manually tested on Link
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I1b87558cc31cb77ef277820f0b00f3ea6e1b367e
Reviewed-on: https://gerrit.chromium.org/gerrit/46009
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Andrew de los Reyes [Sun, 6 Jan 2013 01:26:00 +0000 (17:26 -0800)]
CHROMEOS: HID: logitech-dj: move .h file info .c file.
This is part of the next iteration of Nestor Lopez Casado's
introduction of HID++ support to the kernel from his patch "[PATCH
1/1] HID: Add full MT support for Logitech Wireless Touchpad"
These definitions are only used by the .c file.
BUG=chromium-os:39354
TEST=manually tested on Link
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: Ie745aad4dd782214725c0930ec3b82feed5554cd
Reviewed-on: https://gerrit.chromium.org/gerrit/46008
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Andrew de los Reyes [Sat, 5 Jan 2013 22:06:32 +0000 (14:06 -0800)]
CHROMEOS: HID: logitech-dj: Delay creation of enumerated devices until connected.
This is necessary because it's impossible to communicate with devices
that aren't connected and future patches will need to communicate with
devices during probe().
By waiting until the device is connected, we ensure that we only
register the device when it's active and ready for use.
BUG=chromium-os:39354
TEST=manually tested on Link
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: Id5f2ae88839d1c39362cf0f9246a39d1f6e6238a
Reviewed-on: https://gerrit.chromium.org/gerrit/46007
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Andrew de los Reyes [Sat, 5 Jan 2013 20:31:12 +0000 (12:31 -0800)]
CHROMEOS: Revert "HID: Fix logitech-dj: missing Unifying device issue"
This reverts commit
596264082f10dd4a567c43d4526b2f54ac5520bc.
The reverted commit was a workaround needed when drivers became unable
to communicate with devices during probe(). Now that such
communication is possible, the workaround is not needed.
BUG=chromium-os:39354
TEST=manually tested on Link
Change-Id: I75e27afbd1acfcb2fea2a7a645b4fcec3e31c417
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46006
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Andrew de los Reyes [Sat, 5 Jan 2013 19:41:09 +0000 (11:41 -0800)]
CHROMEOS: HID: Fix logitech-dj: Allow incoming packets during probe().
Historically, logitech-dj communicated with the device during probe()
to query the list of devices attached. Later, a change was introduced
to hid-core that prevented incoming packets for a device during
probe(), as many drivers are unable to handle such input. That change
broke the device enumeration in logitech-dj, so commit
596264082f10dd4a56 was introduced to workaround that by waiting for
normal input before enumerating devices.
Now that drivers can opt-in to receive input during probe, this patch
changes logitech-dj to do that, so that it can successfully complete
enumeration of devices during probe().
BUG=chromium-os:39354
TEST=manually tested on Link
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I2dca10a5c64f6c3e90ffb00547b47eaf94546eb6
Reviewed-on: https://gerrit.chromium.org/gerrit/46005
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Andrew de los Reyes [Sun, 25 Nov 2012 01:06:11 +0000 (17:06 -0800)]
CHERRY-PICK: UPSTREAM: HID: Separate struct hid_device's driver_lock into two locks.
This patch separates struct hid_device's driver_lock into two. The
goal is to allow hid device drivers to receive input during their
probe() or remove() function calls. This is necessary because some
drivers need to communicate with the device to determine parameters
needed during probe (e.g., size of a multi-touch surface), and if
possible, may perfer to communicate with a device on host-initiated
disconnect (e.g., to put it into a low-power state).
Historically, three functions used driver_lock:
- hid_device_probe: blocks to acquire lock
- hid_device_remove: blocks to acquire lock
- hid_input_report: if locked returns -EBUSY, else acquires lock
This patch adds another lock (driver_input_lock) which is used to
block input from occurring. The lock behavior is now:
- hid_device_probe: blocks to acq. driver_lock, then driver_input_lock
- hid_device_remove: blocks to acq. driver_lock, then driver_input_lock
- hid_input_report: if driver_input_lock locked returns -EBUSY, else
acquires driver_input_lock
This patch also adds two helper functions to be called during probe()
or remove(): hid_device_io_start() and hid_device_io_stop(). These
functions lock and unlock, respectively, driver_input_lock; they also
make a note of whether they did so that hid-core knows if a driver has
changed the lock state.
This patch results in no behavior change for existing devices and
drivers. However, during a probe() or remove() function call in a
driver, that driver may now selectively call hid_device_io_start() to
let input events come through, then optionally call
hid_device_io_stop() to stop them.
BUG=chromium-os:39354
TEST=manually tested on Link
(Hasn't quite landed upstream, yet, but this has passed review on linux-input)
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I737f6fc15911134b51273acf8d3de92fa5cc0f85
Reviewed-on: https://gerrit.chromium.org/gerrit/46004
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Nestor Lopez Casado [Fri, 21 Sep 2012 10:21:34 +0000 (12:21 +0200)]
CHERRY-PICK: UPSTREAM: HID: Fix logitech-dj: missing Unifying device issue
This patch fixes an issue introduced after commit
4ea5454203d991ec
("HID: Fix race condition between driver core and ll-driver").
After that commit, hid-core discards any incoming packet that arrives while
hid driver's probe function is being executed.
This broke the enumeration process of hid-logitech-dj, that must receive
control packets in-band with the mouse and keyboard packets. Discarding mouse
or keyboard data at the very begining is usually fine, but it is not the case
for control packets.
This patch forces a re-enumeration of the paired devices when a packet arrives
that comes from an unknown device.
Based on a patch originally written by Benjamin Tissoires.
BUG=chromium-os:39354
TEST=manually tested on Link
(cherry picked from upstream commit
596264082f10dd4a567c43d4526b2f54ac5520bc)
Change-Id: I03408c97bb295599306ec74e55698076d5112f81
Cc: stable@vger.kernel.org # v3.2+
Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://gerrit.chromium.org/gerrit/46003
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Alan Cox [Tue, 4 Sep 2012 14:10:08 +0000 (15:10 +0100)]
CHERRY-PICK: UPSTREAM: dj: memory scribble in logi_dj
Allocate a structure not a pointer to it !
BUG=chromium-os:39354
TEST=manually tested on Link
(cherry picked from upstream commit
8a55ade76551e3927b4e41ee9e7751875d18bc25)
Change-Id: I36d4c6eec346aeb24d323cd6bcd426520d4dfdbd
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46002
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Marc Dionne [Fri, 1 Jun 2012 22:12:14 +0000 (18:12 -0400)]
CHERRY-PICK: UPSTREAM: HID: logitech: don't use stack based dj_report structures
On a system with a logitech wireless keyboard/mouse and DMA-API debugging
enabled, this warning appears at boot:
kernel: WARNING: at lib/dma-debug.c:929 check_for_stack.part.12+0x70/0xa7()
kernel: Hardware name: MS-7593
kernel: uhci_hcd 0000:00:1d.1: DMA-API: device driver maps memory fromstack [addr=
ffff8801b0079c29]
Make logi_dj_recv_query_paired_devices and logi_dj_recv_switch_to_dj_mode
use a structure allocated with kzalloc rather than a stack based one.
BUG=chromium-os:39354
TEST=manually tested on Link
(cherry picked from upstream commit
d8dc3494f77a5cc3b274bae36f7e74e85cf8a407)
Change-Id: I47b321dd07480bf39bd06c740163506153d83d08
Signed-off-by: Marc Dionne <marc.c.dionne@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://gerrit.chromium.org/gerrit/46001
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Jonathan Nieder [Fri, 11 May 2012 14:17:16 +0000 (16:17 +0200)]
CHERRY-PICK: UPSTREAM: HID: logitech: read all 32 bits of report type bitfield
On big-endian systems (e.g., Apple PowerBook), trying to use a
logitech wireless mouse with the Logitech Unifying Receiver does not
work with v3.2 and later kernels. The device doesn't show up in
/dev/input. Older kernels work fine.
That is because the new hid-logitech-dj driver claims the device. The
device arrival notification appears:
20 00 41 02 00 00 00 00 00 00 00 00 00 00 00
and we read the report_types bitfield (02 00 00 00) to find out what
kind of device it is. Unfortunately the driver only reads the first 8
bits and treats that value as a 32-bit little-endian number, so on a
powerpc the report type seems to be 0x02000000 and is not recognized.
Even on little-endian machines, connecting a media center remote
control (report type 00 01 00 00) with this driver loaded would
presumably fail for the same reason.
Fix both problems by using get_unaligned_le32() to read all four
bytes, which is a little clearer anyway. After this change, the
wireless mouse works on Hugo's PowerBook again.
Based on a patch by Nestor Lopez Casado.
Addresses http://bugs.debian.org/671292
BUG=chromium-os:39354
TEST=manually tested on Link
(cherry picked from upstream commit
44d27f7dfedd9aadc082cda31462f6600f56e4ec)
Change-Id: I1658d00ed657950b094f88170d065f5bdab8a898
Reported-by: Hugo Osvaldo Barrera <hugo@osvaldobarrera.com.ar>
Inspired-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://gerrit.chromium.org/gerrit/46000
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Henrik Rydberg [Sun, 22 Apr 2012 12:21:39 +0000 (14:21 +0200)]
CHERRY-PICK: UPSTREAM: HID: hid-logitech: Collect report descriptors before sending
The current code allows several consecutive calls to hid_parse_report(),
which may have happened to work before, but would cause a memory leak
and generally be incorrect. This patch collects all the reports
before sending them once.
BUG=chromium-os:39354
TEST=manually tested on Link
(cherry picked from upstream commit
2a039bf5a6caa6b41c3839c1e3a19b20fb38270b)
Change-Id: Ide9e8c95c99e27a9cb28e1f88c54a12c65098aa6
Cc: Nestor Lopez Casado <nlopezcasad@logitech.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://gerrit.chromium.org/gerrit/45999
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Alan Stern [Thu, 17 Jan 2013 15:32:16 +0000 (10:32 -0500)]
UPSTREAM: USB: XHCI: fix memory leak of URB-private data
commit
48c3375c5f69b1c2ef3d1051a0009cb9bce0ce24 upstream.
This patch (as1640) fixes a memory leak in xhci-hcd. The urb_priv
data structure isn't always deallocated in the handle_tx_event()
routine for non-control transfers. The patch adds a kfree() call so
that all paths end up freeing the memory properly.
This patch should be backported to kernels as old as 2.6.36, that
contain the commit
8e51adccd4c4b9ffcd509d7f2afce0a906139f75 "USB: xHCI:
Introduce urb_priv structure"
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-and-tested-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
235b62026c1f73decda124912930e322dc8ec57d)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: Ib3911cd54ced66358b84d939ed037bfbd2add257
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46080
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Fri, 11 Jan 2013 21:36:35 +0000 (13:36 -0800)]
UPSTREAM: xhci: Fix TD size for isochronous URBs.
commit
f18f8ed2a9adc41c2d9294b85b6af115829d2af1 upstream.
To calculate the TD size for a particular TRB in an isoc TD, we need
know the endpoint's max packet size. Isochronous endpoints also encode
the number of additional service opportunities in their wMaxPacketSize
field. The TD size calculation did not mask off those bits before using
the field. This resulted in incorrect TD size information for
isochronous TRBs when an URB frame buffer crossed a 64KB boundary.
For example:
- an isoc endpoint has 2 additional service opportunites and
a max packet size of 1020 bytes
- a frame transfer buffer contains 3060 bytes
- one frame buffer crosses a 64KB boundary, and must be split into
one 1276 byte TRB, and one 1784 byte TRB.
The TD size is is the number of packets that remain to be transferred
for a TD after processing all the max packet sized packets in the
current TRB and all previous TRBs.
For this TD, the number of packets to be transferred is (3060 / 1020),
or 3. The first TRB contains 1276 bytes, which means it contains one
full packet, and a 256 byte remainder. After processing all the max
packet-sized packets in the first TRB, the host will have 2 packets left
to transfer.
The old code would calculate the TD size for the first TRB as:
total packet count = DIV_ROUND_UP (TD length / endpoint wMaxPacketSize)
total packet count - (first TRB length / endpoint wMaxPacketSize)
The math should have been:
total packet count = DIV_ROUND_UP (3060 / 1020) = 3
3 - (1276 / 1020) = 2
Since the old code didn't mask off the additional service interval bits
from the wMaxPacketSize field, the math ended up as
total packet count = DIV_ROUND_UP (3060 / 5116) = 1
1 - (1276 / 5116) = 1
Fix this by masking off the number of additional service opportunities
in the wMaxPacketSize field.
This patch should be backported to stable kernels as old as 3.0, that
contain the commit
4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0:
Update TD size field format." It may not apply well to kernels older
than 3.2 because of commit
29cc88979a8818cd8c5019426e945aed118b400e
"USB: use usb_endpoint_maxp() instead of le16_to_cpu()".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
d018dbbf6e7e3d588b09273c38ea57bc666d474c)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I5018bc1e163c6e6267aa50c9f7734a7cdf2729d4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46079
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Fri, 11 Jan 2013 19:19:07 +0000 (11:19 -0800)]
UPSTREAM: xhci: Fix isoc TD encoding.
commit
760973d2a74b93eb1697981f7448f0e62767cfc4 upstream.
An isochronous TD is comprised of one isochronous TRB chained to zero or
more normal TRBs. Only the isoc TRB has the TBC and TLBPC fields. The
normal TRBs must set those fields to zeroes. The code was setting the
TBC and TLBPC fields for both isoc and normal TRBs. Fix this.
This should be backported to stable kernels as old as 3.0, that contain
the commit
b61d378f2da41c748aba6ca19d77e1e1c02bcea5 " xhci 1.0: Set
transfer burst last packet count field."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
1757e241ae2c9758bd983250b94328bddeff8760)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I78f2d1bdd0eb04b1c98d9c34e265498125fe346a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46078
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Nickolai Zeldovich [Tue, 8 Jan 2013 03:39:31 +0000 (22:39 -0500)]
UPSTREAM: drivers: xhci: fix incorrect bit test
commit
ba7b5c22d33136a5612ca5ef8d31564dcc501126 upstream.
Fix incorrect bit test that originally showed up in
4ee823b83bc9851743fab756c76b27d6a1e2472b "USB/xHCI: Support
device-initiated USB 3.0 resume."
Use '&' instead of '&&'.
This should be backported to kernels as old as 3.4.
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
5c59de0a37d7721221550c2be2b07ea41966bf40)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I09d3572b30dbf8922a8894bc0dcddc71e6c64833
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46077
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Lan Tianyu [Thu, 24 Jan 2013 02:31:28 +0000 (10:31 +0800)]
UPSTREAM: usb: Using correct way to clear usb3.0 device's remote wakeup feature.
commit
54a3ac0c9e5b7213daa358ce74d154352657353a upstream.
Usb3.0 device defines function remote wakeup which is only for interface
recipient rather than device recipient. This is different with usb2.0 device's
remote wakeup feature which is defined for device recipient. According usb3.0
spec 9.4.5, the function remote wakeup can be modified by the SetFeature()
requests using the FUNCTION_SUSPEND feature selector. This patch is to use
correct way to disable usb3.0 device's function remote wakeup after suspend
error and resuming.
This should be backported to kernels as old as 3.4, that contain the
commit
623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote
wakeup for USB3 devices."
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
7ad8ac9444d54af92c61c2fa7d02cbf96c990bc5)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: Ie97c1e706ee05560b9f8d9db4100c190951d6983
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46076
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Oliver Neukum [Thu, 29 Nov 2012 14:05:57 +0000 (15:05 +0100)]
UPSTREAM: USB: hub: handle claim of enabled remote wakeup after reset
commit
07e72b95f5038cc82304b9a4a2eb7f9fc391ea68 upstream.
Some touchscreens have buggy firmware which claims
remote wakeup to be enabled after a reset. They nevertheless
crash if the feature is cleared by the host.
Add a check for reset resume before checking for
an enabled remote wakeup feature. On compliant
devices the feature must be cleared after a reset anyway.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
7dd830b8315230e29f958fd0e039e9eecad28c5d)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: Id8e558bc8c8a9bfd108ad12ebdea55f7a4c8da98
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46075
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Alan Stern [Wed, 30 Jan 2013 21:36:40 +0000 (16:36 -0500)]
UPSTREAM: USB: EHCI: fix bug in scheduling periodic split transfers
commit
3e619d04159be54b3daa0b7036b0ce9e067f4b5d upstream.
This patch (as1654) fixes a very old bug in ehci-hcd, connected with
scheduling of periodic split transfers. The calculations for
full/low-speed bus usage are all carried out after the correction for
bit-stuffing has been applied, but the values in the max_tt_usecs
array assume it hasn't been. The array should allow for allocation of
up to 90% of the bus capacity, which is 900 us, not 780 us.
The symptom caused by this bug is that any isochronous transfer to a
full-speed device with a maxpacket size larger than about 980 bytes is
always rejected with a -ENOSPC error.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
5b70af1c0b0088151a1e7a8917527e190ddd76d7)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I610be3b44ef6c3006050491029520834121964be
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46074
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Alan Stern [Fri, 25 Jan 2013 22:17:43 +0000 (17:17 -0500)]
UPSTREAM: USB: EHCI: fix timer bug affecting port resume
commit
ee74290b7853db9d5fd64db70e5c175241c59fba upstream.
This patch (as1652) fixes a long-standing bug in ehci-hcd. The driver
relies on status polls to know when to stop port-resume signalling.
It uses the root-hub status timer to schedule these status polls. But
when the driver for the root hub is resumed, the timer is rescheduled
to go off immediately -- before the port is ready. When this happens
the timer does not get re-enabled, which prevents the port resume from
finishing until some other event occurs.
The symptom is that when a new device is plugged in, it doesn't get
recognized or enumerated until lsusb is run or something else happens.
The solution is to re-enable the root-hub status timer after every
status poll while a port resume is in progress.
This bug hasn't surfaced before now because we never used to try to
suspend the root hub in the middle of a port resume (except by
coincidence).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Norbert Preining <preining@logic.at>
Tested-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
f4cc7a1602ed1bb673cf86b6ccc10f72e1cfaae4)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I50a29840acf80ffca3f830b64679c36605f2808e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46073
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Alan Stern [Wed, 7 Nov 2012 15:31:30 +0000 (10:31 -0500)]
UPSTREAM: USB: fix endpoint-disabling for failed config changes
commit
36caff5d795429c572443894e8789c2150dd796b upstream.
This patch (as1631) fixes a bug that shows up when a config change
fails for a device under an xHCI controller. The controller needs to
be told to disable the endpoints that have been enabled for the new
config. The existing code does this, but before storing the
information about which endpoints were enabled! As a result, any
second attempt to install the new config is doomed to fail because
xhci-hcd will refuse to enable an endpoint that is already enabled.
The patch optimistically initializes the new endpoints' device
structures before asking the device to switch to the new config. If
the request fails then the endpoint information is already stored, so
we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no
trouble. The rest of the error path is slightly more complex now; we
have to disable the new interfaces and call put_device() rather than
simply deallocating them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Matthias Schniedermeyer <ms@citd.de>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
828b18866ce0907fdb67afe143d5d851deb9fec6)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I4ba9bc75d096711a354580f2d562123b52b05bcc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46072
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Mon, 17 Dec 2012 22:12:35 +0000 (14:12 -0800)]
UPSTREAM: xhci: Handle HS bulk/ctrl endpoints that don't NAK.
commit
55c1945edaac94c5338a3647bc2e85ff75d9cf36 upstream.
A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK. If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).
The xHCI code to compute the NAK interval does not handle the special
case of zero properly. The current code unconditionally subtracts one
from bInterval and uses it as an exponent. This causes a very large
bInterval to be used, and warning messages like these will be printed:
usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes
This may cause the xHCI host hardware to reject the Configure Endpoint
command, which means the HS device will be unusable under xHCI ports.
This patch should be backported to kernels as old as 2.6.31, that contain
commit
dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in
xhci_get_endpoint_interval()".
Reported-by: Vincent Pelletier <plr.vincent@gmail.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
74abeffd733e53f83e94fc0d90c0a105af7c58ae)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: If1ef3a44f4961e9be6614b71677a3285602c8b7d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46071
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Tue, 27 Nov 2012 20:30:23 +0000 (12:30 -0800)]
UPSTREAM: xhci: Avoid "dead ports", add roothub port polling.
commit
c52804a472649b2e5005342308739434cbd51119 upstream.
The USB core hub thread (khubd) is designed with external USB hubs in
mind. It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.
The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits. When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event. If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.
This means that the hub code may lose port status changes because of
race conditions between clearing change bits. The user sees this as a
"dead port" that doesn't react to device connects.
The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.
We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's. Instead, stop the port polling timer, and
unconditionally restart it when the host resumes. If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.
This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a79300a1471cf92ab43af165ea13555c8b0a5 "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
4ceac47e41f4d587fa71a26dc87335d639a32520)
Conflicts:
drivers/usb/host/xhci.c
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I8321f0042abac5c0fef2adf6df6bfbfee0ddced5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46070
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Thu, 15 Nov 2012 22:58:04 +0000 (14:58 -0800)]
UPSTREAM: USB: Ignore port state until reset completes.
commit
4f43447e62b37ee19c82a13f72f35b1ca60a74d3 upstream.
The port reset code bails out early if the current connect status is
cleared (device disconnected). If we're issuing a hot reset, it may
also look at the link state before the reset is finished.
Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the
Error state or Resetting state, the port connection bit retains the
value from the previous state. Therefore we can't trust it until the
reset finishes. Also, the xHCI spec section 4.19.1.2.5 says software
shall ignore the link state while the port is resetting, as it can be in
an unknown state.
The port state during reset is also unknown for USB 2.0 hubs. The hub
sends a reset signal by driving the bus into an SE0 state. This
overwhelms the "connect" signal from the device, so the port can't tell
whether anything is connected or not.
Fix the port reset code to ignore the port link state and current
connect bit until the reset finishes, and USB_PORT_STAT_RESET is
cleared.
Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case,
because it's redundant. When the warm reset finishes, the port reset
bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set.
Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit
in the code to deal with the finished reset.
This patch should be backported to all stable kernels.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
870826a75318bfee80967140ce3eb6b55e1e9759)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I2699fe3afa20155dcbb7b3eb3b2bfffca9eab2ed
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46069
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Thu, 15 Nov 2012 00:42:32 +0000 (16:42 -0800)]
UPSTREAM: USB: Allow USB 3.0 ports to be disabled.
commit
41e7e056cdc662f704fa9262e5c6e213b4ab45dd upstream.
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID
75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
a723a6cf79aa2e283d5134adf2787b8a35e0b8f3)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: Ib0c7bdbed2ea1369cb01a4b3448054b7e54800ca
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46068
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Thu, 15 Nov 2012 00:10:49 +0000 (16:10 -0800)]
UPSTREAM: USB: Ignore xHCI Reset Device status.
commit
8b8132bc3d1cc3d4c0687e4d638a482fa920d98a upstream.
When the USB core finishes reseting a USB device, the xHCI driver sends
a Reset Device command to the host. The xHC then updates its internal
representation of the USB device to the 'Default' device state. If the
device was already in the Default state, the xHC will complete the
command with an error status.
If a device needs to be reset several times during enumeration, the
second reset will always fail because of the xHCI Reset Device command.
This can cause issues during enumeration.
For example, usb_reset_and_verify_device calls into hub_port_init in a
loop. Say that on the first call into hub_port_init, the device is
successfully reset, but doesn't respond to several set address control
transfers. Then the port will be disabled, but the udev will remain in
tact. usb_reset_and_verify_device will call into hub_port_init again.
On the second call into hub_port_init, the device will be reset, and the
xHCI driver will issue a Reset Device command. This command will fail
(because the device is already in the Default state), and
usb_reset_and_verify_device will fail. The port will be disabled, and
the device won't be able to enumerate.
Fix this by ignoring the return value of the HCD reset_device callback.
This commit should be backported to kernels as old as 3.2, that contain
the commit
75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
36f037316ff169ca111917d6b1d2546d243a2f78)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I1a841c3e85b81bec2c7d957e82e1ebec30193033
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46067
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Wed, 14 Nov 2012 23:58:52 +0000 (15:58 -0800)]
UPSTREAM: USB: Handle auto-transition from hot to warm reset.
commit
1c7439c61fa6516419c32a9824976334ea969d47 upstream.
USB 3.0 hubs and roothubs will automatically transition a failed hot
reset to a warm (BH) reset. In that case, the warm reset change bit
will be set, and the link state change bit may also be set. Change
hub_port_finish_reset to unconditionally clear those change bits for USB
3.0 hubs. If these bits are not cleared, we may lose port change events
from the roothub.
This commit should be backported to kernels as old as 3.2, that contain
the commit
75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
98e5587b9abe155e356d9eef3be6b1472c508c96)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I6ad1fa529a0e4a30a881dd2a07f4958f5947835c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46066
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Thu, 25 Oct 2012 22:56:40 +0000 (15:56 -0700)]
UPSTREAM: xHCI: Fix TD Size calculation on 1.0 hosts.
commit
4525c0a10dff7ad3669763c28016c7daffc3900e upstream.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit
4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
ceb58b9ffa579690f6124fd49dc1734071544f50)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I8d33194d1fd45b3efe00545fa526966154bf93ac
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46065
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Thu, 25 Oct 2012 20:44:12 +0000 (13:44 -0700)]
UPSTREAM: xhci: Fix conditional check in bandwidth calculation.
commit
392a07ae3316f2b90b39ce41e66d6f6b5c95de90 upstream.
David reports that at drivers/usb/host/xhci.c:2257:
static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
return (ep_type == ISOC_IN_EP || ep_type != INT_IN_EP);
}
The static analyser cppcheck says
[linux-3.7-rc2/drivers/usb/host/xhci.c:2257]: (style) Redundant condition: If ep_type == 5, the comparison ep_type != 7 is always true.
Maybe the original programmer intention was something like
static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP);
}
Fix this.
This patch should be backported to stable kernels as old as 3.2, that
contain the commit
2b69899934c63b7b9432568584fb4c4a2924f40c "xhci: USB
3.0 BW checking."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
363cfe8903364aed741cc5c7f31610581a135be8)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: Id9c36819ac8ef396719975bc0f6bf50c4c7dec3c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46064
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Octavian Purdila [Mon, 1 Oct 2012 19:21:12 +0000 (22:21 +0300)]
UPSTREAM: usb hub: send clear_tt_buffer_complete events when canceling TT clear work
commit
3b6054da68f9b0d5ed6a7ed0f42a79e61904352c upstream.
There is a race condition in the USB hub code with regard to handling
TT clear requests that can get the HCD driver in a deadlock. Usually
when an TT clear request is scheduled it will be executed immediately:
<7>[ 6.077583] usb 2-1.3: unlink qh1-0e01/
f4d4db00 start 0 [1/2 us]
<3>[ 6.078041] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d82
<7>[ 6.078299] hub_tt_work:731
<7>[ 9.309089] usb 2-1.5: link qh1-0e01/
f4d506c0 start 0 [1/2 us]
<7>[ 9.324526] ehci_hcd 0000:00:1d.0: reused qh
f4d4db00 schedule
<7>[ 9.324539] usb 2-1.3: link qh1-0e01/
f4d4db00 start 0 [1/2 us]
<7>[ 9.341530] usb 1-1.1: link qh4-0e01/
f397aec0 start 2 [1/2 us]
<7>[ 10.116159] usb 2-1.3: unlink qh1-0e01/
f4d4db00 start 0 [1/2 us]
<3>[ 10.116459] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d82
<7>[ 10.116537] hub_tt_work:731
However, if a suspend operation is triggered before hub_tt_work is
scheduled, hub_quiesce will cancel the work without notifying the HCD
driver:
<3>[ 35.033941] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d80
<5>[ 35.034022] sd 0:0:0:0: [sda] Stopping disk
<7>[ 35.034039] hub 2-1:1.0: hub_suspend
<7>[ 35.034067] usb 2-1: unlink qh256-0001/
f3b1ab00 start 1 [1/0 us]
<7>[ 35.035085] hub 1-0:1.0: hub_suspend
<7>[ 35.035102] usb usb1: bus suspend, wakeup 0
<7>[ 35.035106] ehci_hcd 0000:00:1a.0: suspend root hub
<7>[ 35.035298] hub 2-0:1.0: hub_suspend
<7>[ 35.035313] usb usb2: bus suspend, wakeup 0
<7>[ 35.035315] ehci_hcd 0000:00:1d.0: suspend root hub
<6>[ 35.250017] PM: suspend of devices complete after 216.979 msecs
<6>[ 35.250822] PM: late suspend of devices complete after 0.799 msecs
<7>[ 35.252343] ehci_hcd 0000:00:1d.0: wakeup: 1
<7>[ 35.262923] ehci_hcd 0000:00:1d.0: --> PCI D3hot
<7>[ 35.263302] ehci_hcd 0000:00:1a.0: wakeup: 1
<7>[ 35.273912] ehci_hcd 0000:00:1a.0: --> PCI D3hot
<6>[ 35.274254] PM: noirq suspend of devices complete after 23.442 msecs
<6>[ 35.274975] ACPI: Preparing to enter system sleep state S3
<6>[ 35.292666] PM: Saving platform NVS memory
<7>[ 35.295030] Disabling non-boot CPUs ...
<6>[ 35.297351] CPU 1 is now offline
<6>[ 35.300345] CPU 2 is now offline
<6>[ 35.303929] CPU 3 is now offline
<7>[ 35.303931] lockdep: fixing up alternatives.
<6>[ 35.304825] Extended CMOS year: 2000
When the device will resume the EHCI driver will get stuck in
ehci_endpoint_disable waiting for the tt_clearing flag to reset:
<0>[ 47.610967] usb 2-1.3: **** DPM device timeout ****
<7>[ 47.610972]
f2f11c60 00000092 f2f11c0c c10624a5 00000003 f4c6e880 c1c8a4c0 c1c8a4c0
<7>[ 47.610983]
15c55698 0000000b f56b34c0 f2a45b70 f4c6e880 00000082 f2a4602c f2f11c30
<7>[ 47.610993]
c10787f8 f4cac000 f2a45b70 00000000 f4cac010 f2f11c58 00000046 00000001
<7>[ 47.611004] Call Trace:
<7>[ 47.611006] [<
c10624a5>] ? sched_clock_cpu+0xf5/0x160
<7>[ 47.611019] [<
c10787f8>] ? lock_release_holdtime.part.22+0x88/0xf0
<7>[ 47.611026] [<
c103ed46>] ? lock_timer_base.isra.35+0x26/0x50
<7>[ 47.611034] [<
c17592d3>] ? schedule_timeout+0x133/0x290
<7>[ 47.611044] [<
c175b43e>] schedule+0x1e/0x50
<7>[ 47.611051] [<
c17592d8>] schedule_timeout+0x138/0x290
<7>[ 47.611057] [<
c10624a5>] ? sched_clock_cpu+0xf5/0x160
<7>[ 47.611063] [<
c103e560>] ? usleep_range+0x40/0x40
<7>[ 47.611070] [<
c1759445>] schedule_timeout_uninterruptible+0x15/0x20
<7>[ 47.611077] [<
c14935f4>] ehci_endpoint_disable+0x64/0x160
<7>[ 47.611084] [<
c147d1ee>] ? usb_hcd_flush_endpoint+0x10e/0x1d0
<7>[ 47.611092] [<
c1165663>] ? sysfs_add_file+0x13/0x20
<7>[ 47.611100] [<
c147d5a9>] usb_hcd_disable_endpoint+0x29/0x40
<7>[ 47.611107] [<
c147fafc>] usb_disable_endpoint+0x5c/0x80
<7>[ 47.611111] [<
c147fb57>] usb_disable_interface+0x37/0x50
<7>[ 47.611116] [<
c1477650>] usb_reset_and_verify_device+0x4b0/0x640
<7>[ 47.611122] [<
c1474665>] ? hub_port_status+0xb5/0x100
<7>[ 47.611129] [<
c147a975>] usb_port_resume+0xd5/0x220
<7>[ 47.611136] [<
c148877f>] generic_resume+0xf/0x30
<7>[ 47.611142] [<
c14821a3>] usb_resume+0x133/0x180
<7>[ 47.611147] [<
c1473b10>] ? usb_dev_thaw+0x10/0x10
<7>[ 47.611152] [<
c1473b1d>] usb_dev_resume+0xd/0x10
<7>[ 47.611157] [<
c13baa60>] dpm_run_callback+0x40/0xb0
<7>[ 47.611164] [<
c13bdb03>] ? pm_runtime_enable+0x43/0x70
<7>[ 47.611171] [<
c13bafc6>] device_resume+0x1a6/0x2c0
<7>[ 47.611177] [<
c13ba940>] ? dpm_show_time+0xe0/0xe0
<7>[ 47.611183] [<
c13bb0f9>] async_resume+0x19/0x40
<7>[ 47.611189] [<
c10580c4>] async_run_entry_fn+0x64/0x160
<7>[ 47.611196] [<
c104a244>] ? process_one_work+0x104/0x480
<7>[ 47.611203] [<
c104a24c>] ? process_one_work+0x10c/0x480
<7>[ 47.611209] [<
c104a2c0>] process_one_work+0x180/0x480
<7>[ 47.611215] [<
c104a244>] ? process_one_work+0x104/0x480
<7>[ 47.611220] [<
c1058060>] ? async_schedule+0x10/0x10
<7>[ 47.611226] [<
c104c15c>] worker_thread+0x11c/0x2f0
<7>[ 47.611233] [<
c104c040>] ? manage_workers.isra.27+0x1f0/0x1f0
<7>[ 47.611239] [<
c10507f8>] kthread+0x78/0x80
<7>[ 47.611244] [<
c1750000>] ? timer_cpu_notify+0xd6/0x20d
<7>[ 47.611253] [<
c1050780>] ? __init_kthread_worker+0x60/0x60
<7>[ 47.611258] [<
c176357e>] kernel_thread_helper+0x6/0xd
<7>[ 47.611283] ------------[ cut here ]------------
This patch changes hub_quiesce behavior to flush the TT clear work
instead of canceling it, to make sure that no TT clear request remains
uncompleted before suspend.
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
891fe9688fbd2ef1c04d8314b74c0037be2adb89)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I0f4493f639cd8add900846e0f41bd99f108e97ee
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46063
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Tue, 16 Oct 2012 20:17:43 +0000 (13:17 -0700)]
UPSTREAM: xhci: Fix potential NULL ptr deref in command cancellation.
commit
43a09f7fb01fa1e091416a2aa49b6c666458c1ee upstream.
The command cancellation code doesn't check whether find_trb_seg()
couldn't find the segment that contains the TRB to be canceled. This
could cause a NULL pointer deference later in the function when next_trb
is called. It's unlikely to happen unless something is wrong with the
command ring pointers, so add some debugging in case it happens.
This patch should be backported to stable kernels as old as 3.0, that
contain the commit
b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d "xHCI:
handle command after aborting the command ring".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
325c6bf91fd3c2e4fea473e9ca4eb30666dadb52)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I1006d7b5c8cdfc2ca373a0fbb8967a19368d91ae
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46062
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Elric Fu [Wed, 27 Jun 2012 08:55:43 +0000 (16:55 +0800)]
UPSTREAM: xHCI: handle command after aborting the command ring
commit
b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d upstream.
According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
after aborting a command on the command ring, xHC will
generate a command completion event with its completion
code set to Command Ring Stopped at least. If a command is
currently executing at the time of aborting a command, xHC
also generate a command completion event with its completion
code set to Command Abort. When the command ring is stopped,
software may remove, add, or rearrage Command Descriptors.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci. When the command ring is stopped,
software will find the command trbs described by command
descriptors in cancel_cmd_list and modify it to No Op
command. If software can't find the matched trbs, we can
think it had been finished.
This patch should be backported to kernels as old as 3.0, that contain
the commit
7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
c4f132c4c23d6b822242c98def8be15182c24ff4)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I4ace36faa890373143277d43aa6b91d678c6cf45
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46061
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Elric Fu [Wed, 27 Jun 2012 08:31:52 +0000 (16:31 +0800)]
UPSTREAM: xHCI: cancel command after command timeout
commit
6e4468b9a0793dfb53eb80d9fe52c739b13b27fd upstream.
The patch is used to cancel command when the command isn't
acknowledged and a timeout occurs.
This patch should be backported to kernels as old as 3.0, that contain
the commit
7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
75382341d888ba0132c5eeb94711840acf972034)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I36f4ea343230e394d99a0e081ce5738a8d68a886
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46060
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Elric Fu [Wed, 27 Jun 2012 08:31:12 +0000 (16:31 +0800)]
UPSTREAM: xHCI: add aborting command ring function
commit
b92cc66c047ff7cf587b318fe377061a353c120f upstream.
Software have to abort command ring and cancel command
when a command is failed or hang. Otherwise, the command
ring will hang up and can't handle the others. An example
of a command that may hang is the Address Device Command,
because waiting for a SET_ADDRESS request to be acknowledged
by a USB device is outside of the xHC's ability to control.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci.
Sarah: Fixed missing newline on "Have the command ring been stopped?"
debugging statement.
This patch should be backported to kernels as old as 3.0, that contain
the commit
7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
2818247b6565b7adfbcd53b74509448a8e1fad84)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: Iac376fec030eae1d2f85598c48fc136080fac129
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46059
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Elric Fu [Wed, 27 Jun 2012 08:30:57 +0000 (16:30 +0800)]
UPSTREAM: xHCI: add cmd_ring_state
commit
c181bc5b5d5c79b71203cd10cef97f802fb6f9c1 upstream.
Adding cmd_ring_state for command ring. It helps to verify
the current command ring state for controlling the command
ring operations.
This patch should be backported to kernels as old as 3.0. The commit
7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an assertion to
check for virt_dev=0 bug." papers over the NULL pointer dereference that
I now believe is related to a timed out Set Address command. This (and
the four patches that follow it) contain the real fix that also allows
VIA USB 3.0 hubs to consistently re-enumerate during the plug/unplug
stress tests.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
1976fffe9dc839e9d25c903a65723600f7641a50)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: Ib07ee436e4288ddcd9d13776ff8bcd2c44d99217
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46058
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Wed, 19 Sep 2012 23:27:26 +0000 (16:27 -0700)]
UPSTREAM: xhci: Intel Panther Point BEI quirk.
commit
80fab3b244a22e0ca539d2439bdda50e81e5666f upstream.
When a device with an isochronous endpoint is behind a hub plugged into
the Intel Panther Point xHCI host controller, and the driver submits
multiple frames per URB, the xHCI driver will set the Block Event
Interrupt (BEI) flag on all but the last TD for the URB. This causes
the host controller to place an event on the event ring, but not send an
interrupt. When the last TD for the URB completes, BEI is cleared, and
we get an interrupt for the whole URB.
However, under a Panther Point xHCI host controller, if the parent hub
is unplugged when one or more events from transfers with BEI set are on
the event ring, a port status change event is placed on the event ring,
but no interrupt is generated. This means URBs stop completing, and the
USB device disconnect is not noticed. Something like a USB headset will
cause mplayer to hang when the device is disconnected.
If another transfer is sent (such as running `sudo lsusb -v`), the next
transfer event seems to "unstick" the event ring, the xHCI driver gets
an interrupt, and the disconnect is reported to the USB core.
The fix is not to use the BEI flag under the Panther Point xHCI host.
This will impact power consumption and system responsiveness, because
the xHCI driver will receive an interrupt for every frame in all
isochronous URBs instead of once per URB.
Intel chipset developers confirm that this bug will be hit if the BEI
flag is used on any endpoint, not just ones that are behind a hub.
This patch should be backported to kernels as old as 3.0, that contain
the commit
69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
59b91d284b24d4ec17f917421b169fcb40805544)
Conflicts:
drivers/usb/host/xhci-pci.c
drivers/usb/host/xhci.h
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: Ifdd43eaccc32480f62eff51601f006e36e2e0aa7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46057
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Takashi Iwai [Fri, 1 Jun 2012 08:06:23 +0000 (10:06 +0200)]
UPSTREAM: xhci: Fix invalid loop check in xhci_free_tt_info()
commit
46ed8f00d8982e49f8fe2c1a9cea192f640cb3ba upstream.
xhci_free_tt_info() may access the invalid memory when it removes the
last entry but the list is not empty. Then tt_next reaches to the
list head but it still tries to check the tt_info of that entry.
This patch fixes the bug and cleans up the messy code by rewriting
with a simple list_for_each_entry_safe().
This patch should be backported to kernels as old as 3.2, that contain
the commit
839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store
information about roothubs and TTs."
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reviewed-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
b063a624f08cfa64c2d9162d1525da95519e6156)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I6b86ca835e1a915cbbbbf47356d696efe86a96d8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46056
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Andiry Xu [Fri, 4 May 2012 16:50:10 +0000 (00:50 +0800)]
UPSTREAM: usbcore: enable USB2 LPM if port suspend fails
commit
c3e751e4f4754793bb52bd5ae30e9cc027edbb12 upstream.
USB2 LPM is disabled when device begin to suspend and enabled after device
is resumed. That's because USB spec does not define the transition from
U1/U2 state to U3 state.
If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM
is disabled in this situation. Enable USB2 LPM if port suspend fails.
This patch should be backported to kernels as old as 3.2, that contain
the commit
65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
hardware LPM".
Signed-off-by: Andiry Xu <andiry.xu@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
edad2199132a88f160c4939d1ad3eecc4c33b211)
BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)
Change-Id: I3762df7d8d42c3d8228b1f19ce5f1439e19457e1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46055
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Grant Grundler [Thu, 21 Mar 2013 16:13:41 +0000 (09:13 -0700)]
Revert "Revert "UPSTREAM: mmc: dw_mmc: correct the calculation for CLKDIV""
This reverts commit
f786fcc8d52e5a7d15a90cf266f2ac1d40f54a5e
Cannot reproduce "won't boot" with "normal" FW versions. See bug for details.
Change-Id: Ibb2730ecef525831883ff26bc04c72a55f47f06d
Reviewed-on: https://gerrit.chromium.org/gerrit/46128
Reviewed-by: Grant Grundler <grundler@chromium.org>
Tested-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Doug Anderson [Tue, 11 Sep 2012 16:10:08 +0000 (09:10 -0700)]
CHROMIUM: CONFIG: Add debug info
This was default on all builds but got lost in a kernel rebase. It
adds no-overhead to release builds since they are stripped but means
the vmlinux we get from the bots has symbols.
BUG=chromium:222294
TEST=Build the kernel and run with it. Use kgdb with this kernel.
Change-Id: Ief705b2a1a09917b6885ed84c7a405cb12e105f2
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33566
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Doug Anderson [Mon, 18 Mar 2013 23:12:42 +0000 (16:12 -0700)]
samsung: snow: bitfix: Don't bail if we can't recover unused memory
The bitfix code has the requirement that you can only recover an
entire 8K chunk of memory at a time, even though memory can be
"skipped" (not processed by bitfix) in 4K chunks. If we ever detect
corruption in a 8K chunk that contained skipped pages then we'd bail
and reboot.
The original concept of "skipping" pages was there for sacred areas of
memory: the stack, console buffer, MMU structures, etc. For these
areas of memory the above logic makes a lot of sense. Dealing with a
page at a time meant that we could still _detect_ corruption on that
page. ...and we could even fix it! ...but since evidence suggested
that if one half of a chunk was corrupted that there's a good chance
of corruption in the other half, we chose to bail and reboot.
The above logic didn't take into account that we added another reason
for skipping a page: if it was unused. For part of a chunk is unused
then we should just recover the half of the chunk that we care about
and not worry about corruption in the other half.
BUG=chromium-os:39522
TEST=suspend_stress_test
Change-Id: I57ad2fe24755e8867fdd4a5b729521b0ddb1d5fc
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45807
Reviewed-by: Olof Johansson <olofj@chromium.org>
projects / cascardo / linux.git / log