Doug Anderson [Sat, 26 Jan 2013 00:01:00 +0000 (16:01 -0800)]
CHERRY-PICK: arm: exynos: Fix the ISP Power down sequence
This totally moves the ISP power down configuration to its own
function so we can make sure power sequencing is exactly as the
Samsung HW team suggests. At the moment we're not using the ISP for
anything, so this should be fine.
Following is the suggested power down sequence for ISP:
- 0x10042288 --> 0x10000 (ISP A5 Disable WFE)
- 0x10042280 --> 0x0 (ISP A5 Power Off)
- 0x10041584 --> 0x0 (SYS_PWR_CFG off for CMU_RESET_ISP)
- 0x10044020 --> 0x0 (ISP Block Power Off)
Before this patch our order looks more like:
- 0x10044020 --> 0x0 (ISP Block Power Off)
- 0x10042280 --> 0x0 (ISP A5 Power Off)
- 0x10042288 --> 0x0 (ISP A5 Disable WFI / WFE)
- 0x10041584 --> 0x0 (SYS_PWR_CFG off for CMU_RESET_ISP)
We now match the suggested order except that we actually write
0x10042288 as 0x0 to disable WFE and WFI. This matches what was set
to the register before this patch and has been OKed by the Samsung LSI
hardware team.
BUG=chrome-os-partner:15327
BUG=chrome-os-partner:17442
TEST=Revert 0.8 ABB (see Ic48ee710b623d72670db965700c215dfe280d6ea)
and then use suspend_at_boot.conf script from chrome-os-partner:15327
comment #71 to test on a device that had suspend/resume problems
without this.
Change-Id: I3ce50683e50dabd42d49d5c3d33c36dd1d24dced
Original-Change-Id: Ia3bb141a6c94a6b3656944b6b3a2f1e0645adf8d Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Doug Anderson <dianders@chromium.org>
(cherry picked from commit 2b3c6353074a62f8b58e6abd53f9821aaa391b32)
CHERRY-PICK: UPSTREAM: SCSI & usb-storage: add try_rc_10_first flag
Several bug reports have been received recently for USB mass-storage
devices that don't handle READ CAPACITY(16) commands properly. They
report bogus sizes, in some cases becoming unusable as a result.
The bugs were triggered by commit 09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add
flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
overriding the SCSI level reported by devices. By default, the sd
driver will try READ CAPACITY(16) first for any device whose level is
above SCSI_SPC_2.
It seems likely that any device large enough to require the use of
READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
CAPACITY(10) commands properly. Indeed, I don't know of any devices
that don't handle READ CAPACITY(10) properly.
Therefore this patch (as1559) adds a new flag telling the sd driver
to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
for every USB mass-storage device. If a device really is larger than
2 TB, sd will fall back to READ CAPACITY(16) just as it used to.
This fixes Bugzilla #43391.
BUG=chrome-os-partner:16619
TEST=Manual. Build recovery image on previously failing USB disk, verify
recovery install on generic x86 platform.
Change-Id: I0ab1718a573076caa8a3433791371245a8b9c656
Original-Change-Id: I82899c04e2f2b65292a8f55505b347a2b72f8f6e Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Hans de Goede <hdegoede@redhat.com> CC: "James E.J. Bottomley" <JBottomley@parallels.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41913
Reviewed-on: https://gerrit.chromium.org/gerrit/42229 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The original change had the undesired side-effect of delaying link
status detection, and no acceptable solution was found.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
BUG=chrome-os-partner:16247.
TEST=manual. Test ethernet plug/unplug, verify no delay in link status
detect.
This patch caused a deadlock between khubd and the suspend process.
This was reliably reproducible when we did a suspend immediately after
a resume, and the khubd kernel thread was busy probing USB devices.
The sequence was that khubd would be running and probing USB devices
when we try to suspend and the freezer would activate, and eventually
khubd would call request_firmware() while holding a device lock, and
request_firmware would call usermodehelper_read_trylock().
Because the UMH is in state UMH_FREEZING, usermode_helper_read_trylock
would end up calling try_to_freeze() and would then be frozen while
holding a device lock. After the freezer finished, it would then try
to suspend each device and would deadlock on the USB hub device that
was being held by khubd.
Reverting this merely results in a WARN_ON from request_firmware() and
no deadlock, and upon the subsequent resume, khubd will successfully
get the firmware and the devices work correctly.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
BUG=chrome-os-partner:17270
TEST=(needs an autotest test) currently manual:
use the set_short_powerd_timeouts script to all the device to
idle-suspend quickly, wait for an idle suspend with the lid open
(about 30 seconds). Then hit the trackpad and quickly close the lid.
The device should resume and then suspend again within a few seconds.
Benson Leung [Mon, 28 Jan 2013 23:26:25 +0000 (15:26 -0800)]
CHROMIUM: Input: atmel_mxt_ts - Set T9 in mxt_resume based on lid state
This is an x86 specific change for the short term.
When the lid is closed on resume, make sure T9 is disabled.
to prevent the lid from affecting the touch device and causing
stray touches. If lid is open, restore operational settings for T9.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17465
TEST=Close the lid to suspend in guest mode.
Open the lid slowly, until you see the lights indicating resuming.
Close the lid immediately upon seeing the system resume from
the status light.
The system should stay in S0. Check via ssh:
cat /sys/kernel/debug/atmel_mxt_ts/2-004a/object
Check that T9 is 0x00.
On a normal suspend/resume, where the lid is opened,
check that touch device is functional.
Benson Leung [Mon, 28 Jan 2013 23:31:26 +0000 (15:31 -0800)]
CHROMIUM: Input: atmel_mxt_ts - Disable T9 on mxt_stop
Instead of using 0x81 to keep the object enabled,
disable T9 on mxt_stop by writing 0x00 to it.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17465
TEST=stop powerd (on R25 also stop powerm)
close the lid, or use a magnet to trigger the lid sensor.
cat /sys/kernel/debug/atmel_mxt_ts/2-004a/object
Look for Type: 9, byte 0. Check that this is 0x00
when lid is closed. When opened, this should return
to 0x83.
Benson Leung [Sat, 26 Jan 2013 01:45:56 +0000 (17:45 -0800)]
CHROMIUM: Input: atmel_mxt_ts - mxt_stop on lid close
This is an x86 specific change for the short term.
When the lid is closed, issue an mxt_stop to turn off scanning
to prevent the lid from affecting the touch device and causing
stray touches.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17465
TEST=From test mode, run evtest, and watch the atmel_mxt device.
Close and open the lid. Make sure there are no touch data comes
from the atmel driver when the lid is being closed.
Chee Kin Cheong [Wed, 23 Jan 2013 12:44:28 +0000 (04:44 -0800)]
CHROMIUM: ALSA: hda/ca0132 - configure DMIC gain block.
Configure the DMIC input gain block when switching to use DMIC. This
provides 20dB of additional input gain when using the built-in digital
microphone.
This should be changed to export a control to user-space, but keep it
simple for the R25 release.
BUG=chrome-os-partner:16865
TEST=arecord a reference signal and check that there is now 20dB of
gain applied. Hangout and check that the participant on the other
side can hear you.
Sean Paul [Fri, 25 Jan 2013 22:09:04 +0000 (17:09 -0500)]
CHERRY-PICK: CHROMIUM: drm/exynos: dp: Add force_connected flag
Add a new flag to the DisplayPort platform data to optionally force
is_connected to return true. This is useful for cases such as ours where
we don't have a proper DP monitor connected, but rather a noisy bridge
that doesn't know when it's actually ready to assert hotplug.
This will also prevent drm from assuming we're disconnected and detaching
our encoder from the connector (thus losing us forever as a result of
the interrupt scheme in the driver, which needs to be fixed).
BUG=chromium-os:38006
TEST=Tested manually using Doug's reproduction instructions in c17 on the bug
Change-Id: I5d71248ca8e4506cdae09f55b331a2582deb7267
Original-Change-Id: If2034458d9de93259e92a0f3eb8f386c340b0d7d Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
(cherry picked from commit 657dd039a241ae12510fe126329ac9f03aec4bbe)
Reviewed-on: https://gerrit.chromium.org/gerrit/42144
Commit-Queue: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org>
Abhilash Kesavan [Fri, 18 Jan 2013 06:47:43 +0000 (12:17 +0530)]
CHERRY-PICK: HACK: arm: exynos: Force 0.8x instead of bypass for VDD_INT
Increase the INT voltage margins for all speed groups. According to
the h/w guys at Samsung this is fine except for a power increase. At
the moment this is considered an interrim (but safe) fix while Samsung
looks for a root cause.
Side notes:
* ABB 1.0x appears to work better than bypass (which makes no sense)
but still doesn't work as well as ABB 0.8x (this patch).
* ABB 1.2x also appears to work. It ran 690 cycles of the test below
before I stopped it.
* Leaving ABB off and increasing VDD_INT also appears to work to some
extent, but not as well as this patch.
BUG=chrome-os-partner:15327
TEST=Run the following test on a device that fails 100% without
this patch:
1. Reboot
2. suspend_stress_test -c5 --backup_rtc
3. Goto step 1
With this patch I went through 728 cycles of the above with no
hangs at suspend. Testing was done via an init script that is
attached at comment #71 of the referenced bug.
TEST=Run the above test on several devices that have no problems
without this patch. Confirm that this patch doesn't introduce
additional suspend/resume problems.
TEST=General stability testing should be performed.
Change-Id: Ibe26b8e6805d7206b3d98ae2a72704ef9633eeb3
Original-Change-Id: I5925ace16e7bc00207f2218c4ccb4cc6453ec44a Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Doug Anderson <dianders@chromium.org>
(cherry picked from commit 466db2af679e46c5ab65c53e38b802a1e4ae3351)
Benson Leung [Sat, 19 Jan 2013 01:35:52 +0000 (17:35 -0800)]
CHROMIUM: Input: atmel_mxt_ts : Set power/wakeup to disabled by default.
Userspace will change it to enabled if needed.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17336
TEST=cat /sys/bus/i2c/devices/2-004a/power/wakeup
Check that it returns "disabled"
Suspend the system using powerd_suspend.
Check that the touch device 2-004a does not wake the system.
Benson Leung [Sat, 19 Jan 2013 01:35:19 +0000 (17:35 -0800)]
CHROMIUM: Input: atmel_mxt_ts : On Tpads, enable T42, disable T19 on suspend
To work around an issue where an idle-suspended system may wake
unnecessarily when the lid is closed because the B panel comes close to
the trackpad, enable touch suppression (t42) when suspending. Also
disable T19, for the button, to allow the button to be pressed if
the case is flexed without the system waking.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17336
TEST=1. Suspend the system with powerd_suspend with lid open.
2. Touch the touchpad. Make sure the system still wakes.
3. Suspend again with powerd_suspend
4. Close the lid. Ensure the system does not wake by observing the system
status light.
Sameer Nanda [Wed, 16 Jan 2013 22:27:37 +0000 (14:27 -0800)]
drm/i915: Honor i915_min_freq post resume
The i915_min_freq setting was not getting honored on the resume path.
Fixed it.
BUG=chrome-os-partner:16439
TEST="cat /sys/kernel/debug/dri/0/i915_min_freq" and remember the value
returned. Do a suspend/resume cycle. cat the i915_min_freq file again,
it must return the same value as read earlier.
Yufeng Shen [Thu, 10 Jan 2013 20:00:42 +0000 (15:00 -0500)]
CHROMIUM: Input: atmel_mxt_ts: Use correct max touch_major in mxt_release_all_fingers()
We hard-coded the maximal touch_major value to be 255 in mxt_release_all_fingers().
Fixing this by using the queried actual maximal touch_major value.
Signed-off-by: Yufeng Shen <miletus@chromium.org>
BUG=chrome-os-partner:17176
TEST=1. Run evtest on the touch device
2. Keep touching the device while closing the lid.
3. Release the touch after the system suspends.
4. Open the lid to resume the system
5. Check evtest result and see that there is release events with correct
touch major value.
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:16279
TEST=Associate with Android AP
Change-Id: Id20b77139ae2b07139ea1fde01446810d404f0d1
Reviewed-on: https://gerrit.chromium.org/gerrit/41469
Commit-Queue: Paul Stewart <pstew@chromium.org> Reviewed-by: Paul Stewart <pstew@chromium.org> Tested-by: Paul Stewart <pstew@chromium.org>
Abhilash Kesavan [Fri, 21 Dec 2012 04:14:39 +0000 (09:44 +0530)]
CHERRY-PICK: exynos5: asv: Call the core ASV code early
Change the priority of ASV code initialization. The core ASV code
finds the speed group, lot id and exposes it to various consumer
drivers like busfreq, G3D and CPUfreq. Among these, the G3D driver
is getting called before the core code and thus is always getting
the ASV speed group as 0. Fix this by calling the core ASV early.
BUG=chrome-os-partner:16796
TEST=Checked that G3D, ARM and INT drivers are all getting the same
ASV group on 2 different boards (1 MP and 1 PVT). Also, verified that
the voltages match that speed group.
Change-Id: Ib2ba155cdd968f7ca74d122d6716fb0a9a228c99
Original-Change-Id: I1ca234a770bbd8b2d590a83377ee44527327066b Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org>
(cherry picked from commit 0947da07a809fe38b056ca0618a071cbb198a0e9)
Reviewed-on: https://gerrit.chromium.org/gerrit/40952 Reviewed-by: Olof Johansson <olofj@chromium.org>
Abhilash Kesavan [Fri, 14 Dec 2012 06:02:19 +0000 (11:32 +0530)]
CHERRY-PICK: arm: exynos: Enable CHIP ID clock
The bootloader may gate the CLK_CHIPID_APBIF which will cause
an invalid value to be read for the Package ID in ASV. Explicitly
enable the clock in the ASV driver.
BUG=chrome-os-partner:16796
TEST=Boot 5 different snows to the login screen. Verify that the clock
is enabled and the appropriate speed group is being selected. Do a few
suspend/resume cycles with reboots.
Change-Id: Id5a0ec599c7aedc9ae98297fbc035fce887c8bd5
Original-Change-Id: Ib094b748301b7e882a50ae056bd9f0f795c133e5 Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Doug Anderson <dianders@chromium.org>
(cherry picked from commit eeb5bd2fd266d9980fa4ee73be4c37ff732f0f3b)
Reviewed-on: https://gerrit.chromium.org/gerrit/40951 Reviewed-by: Olof Johansson <olofj@chromium.org>
Doug Anderson [Fri, 14 Dec 2012 19:21:12 +0000 (11:21 -0800)]
CHERRY-PICK: arm: exynos: Use MIF ASV group
The original code doesn't use the MIF ASV group. Add code to read it.
There are 2 ASV groups for the fused chips ASV0 at 1.05V and ASV1 at
1V. For the non-fused chips the MIF voltage remains at 1V.
BUG=chrome-os-partner:16820
TEST=Verified that we never change MIF voltage, so this doesn't affect
us right now.
TEST=Saw printout about MIF ASV group at bootup.
Change-Id: Ifaf5d2437a7a24964ed5eae2be6704e95d7b7f29
Original-Change-Id: Ia264991c11469a22a986c385a03b2a0478fb237f Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
(cherry picked from commit abb563d27cc5be426dcfd1467a52b7c029d46345)
Reviewed-on: https://gerrit.chromium.org/gerrit/40950 Reviewed-by: Olof Johansson <olofj@chromium.org>
Some adapters return DEFER indefinitely, which results in being stuck in the
kernel, which triggers the watchdog, which reboots. To avoid this, limit to
100 tries, after which we return an error and pring a message.
BUG=chrome-os-partner:15612
TEST=by hand, use the apple miniDP to dual-link adapter, plug a 30 inch
TEST=monitor, the machine shouldn't reboot spontaneously (the monitor still
TEST=won't work, but that is a separate bug).
Doug Anderson [Fri, 14 Dec 2012 19:21:12 +0000 (11:21 -0800)]
arm: exynos: Don't force ASV group 0 to ASV group 1
The old ASV code had a bug where it would never use group 0. That
makes sense for the "original" table, but not for the new table and
not for any fused values.
BUG=chrome-os-partner:16820
TEST=Test across a wide variety of devices
Change-Id: Ifc44ed51c9d6f2effee4f0134160f74c320f4335 Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39711 Reviewed-by: Abhilash Kesavan <a.kesavan@samsung.com> Tested-by: Abhilash Kesavan <a.kesavan@samsung.com> Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Doug Anderson [Fri, 14 Dec 2012 21:19:04 +0000 (13:19 -0800)]
arm: exynos: Call ABB code when using a fused speed group
The previous checkin titled "Add Adaptive Body Bias Control for
exynos5" only added ABB when not using a fused speed group. Fix it to
also use ABB when using a non-fused speed group.
BUG=chrome-os-partner:16820
TEST=Test this plus the CHIP_ID patch on a wide variety of devices,
including those that had suspend/resume problems.
Benson Leung [Sun, 16 Dec 2012 00:29:51 +0000 (16:29 -0800)]
CHROMIUM: Input: cyapa - Allow filename to be changed in update_fw
Allow the name of the designated firmware to be passed as the
argument to update_fw from user space. This will allow user space
to specify which firmware to load.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chromium-os:36911,chromium-os:37150
TEST=Make sure you are using chromeos-touch-firmware-daisy-2.4-r2
which contains firmware 2.4 stable, but 3 trial firmwares linked
from /lib/firmware/cyapa.bin-trial[1-3]
Check by manually issuing the command from user space:
1. echo -n cyapa.bin-trial1 > /sys/bus/i2c/devices/1-0067/update_fw
2. cat /sys/bus/i2c/devices/1-0067/firmware_version
3. double check that that returns 2.7
4. echo -n cyapa.bin-trial3 > /sys/bus/i2c/devices/1-0067/update_fw
5. cat /sys/bus/i2c/devices/1-0067/firmware_version
6. double check that that returns 2.9
7. echo -n cyapa.bin > /sys/bus/i2c/devices/1-0067/update_fw
8. cat /sys/bus/i2c/devices/1-0067/firmware_version
9. Check that that returns 2.4
Sonny Rao [Fri, 14 Dec 2012 22:48:30 +0000 (14:48 -0800)]
CHROMIUM: cpufreq: cpu_thermal only allows lower max frequency, fix it
The cpu_thermal generic thermal management code has a bug where once
max cpu frequency has been lowered in sysfs (scaling_max_freq) it is
not possible to raise the max back up later. The bug is that the
notifer gets called by __cpufreq_set_policy() before the user policy
max is raised, and is incorrectly trying to enforce the max frequency
policy even when we are trying to change the policy.
agnescheng [Thu, 13 Dec 2012 08:44:05 +0000 (16:44 +0800)]
CHROMIUM: rts_pstor: fix formatting, writing, copying failures with
specific SDSDB cards.
Patch from Realtek to correct init option for specific SD cards -
Realtek found those cards cannot be successfully written (read is OK)
because current mount option causes writes(maybe to update the access time) when read.
TEST=insert SDSDB/SDSC card, format and cannot copy files to the card.
CHROMIUM: atkbd: Fix scancode handling on reconnect / resume from suspend.
On resume from suspend there is a possibility for multi-byte scancodes
to be handled incorrectly. atkbd_reconnect disables the processing of
scancodes in software by calling atkbd_disable, but the keyboard may
still be active because no disconnect command was sent. Later, software
handling is re-enabled. If a multi-byte scancode sent from the keyboard
straddles the re-enable, only the latter byte(s) will be handled.
In practice, this leads to cases where multi-byte break codes (ex. "e0
4d" - break code for right-arrow) are misread as make codes ("4d" - make
code for numeric 6), leading to one or more unwanted, untyped characters
being interpreted.
The solution implemented here involves sending command f5 (reset
disable) to the keyboard prior to disabling software handling of codes.
Later, the command to re-enable the keyboard is sent only after we are
prepared to handle scancodes.
TEST=spam right/left arrow keys during resume for many iterations,
verify that no phantom characters are seen.
BUG=chrome-os-partner:16605
Change-Id: Ieba1e42398c2f4f6a1623afa3ed82903dc393045 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39690 Reviewed-by: Derek Basehore <dbasehore@chromium.org> Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Doug Anderson [Fri, 14 Dec 2012 16:56:34 +0000 (08:56 -0800)]
arm: exynos: Fix potential buffer overrun in printk with asv
The asv code stores 5 characters in in a 5-byte array. It properly
compares against this with strncmp, but then goes and passes the
character array to printk() which could read off the end.
Terminate the array properly, then go ahead and promote the printout
to print all the details we have every time.
BUG=chrome-os-partner:16820
TEST=Boot and see message printed out.
Ray Smith [Tue, 20 Nov 2012 12:53:23 +0000 (12:53 +0000)]
MALI: Allow kbase to cancel a lock before it is acquired
This is based on Ib42b8e5c8039fd5f900885f097418b87d9614225,
most of which has been integrated into the wk45 release but
this particular commit is to account for local changes to
KDS in this repo.
Michael Spang [Wed, 14 Nov 2012 22:51:39 +0000 (17:51 -0500)]
CHROMIUM: gobi: Take clients_lock in qc_deregister
It is not legal to access the clients list without taking
clients_lock. This change makes qc_deregister take the lock while
finding new clients to free.
This fixes a crash when qc_deregister races devqmi_release.
Sonny Rao [Mon, 10 Dec 2012 19:06:02 +0000 (11:06 -0800)]
CHROMIUM: sysrq: add ability for sysrq-x to signal chrome/X
Because we weren't getting reports of actual kernel issues, and
we've already trained some users to hit sysrq-x when the system
appears to freeze, we decided to have sysrq-x try a few other things
in addition to crashing the kernel. For the first keypress it will
try to find the Chrome browser process, by looking for the one which
has the session_manager as a parent, and send a SIGABRT to that. If
there is a second sysrq-x within 5 seconds, it will send a SIGABRT to
the X process, and if there's a third then it will crash the kernel as
before.
BUG=chromium-os:36901
TEST=manual (debugging feature):
hold down alt-volup then x - chrome should crash
repeat immediately afterward - session should restart
repeat and machine should reboot
Daniel Kurtz [Mon, 10 Dec 2012 07:34:24 +0000 (15:34 +0800)]
CHROMIUM: drm/exynos: fbdev: Offset is always zero
A freshly filled fb_info will always have .xoffset and .yoffset = 0.
So, computing an offset during during fbdev_update is not necessary,
since it is only called in the fbdev_probe/fbdev_create path.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:37097
TEST=compile test; manual check fbdev created and shows chromeball at boot
Change-Id: I648e16200cf3840a69e59a8f8d4dea69541c9cf7
Reviewed-on: https://gerrit.chromium.org/gerrit/39479 Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Daniel Kurtz [Mon, 10 Dec 2012 05:53:11 +0000 (13:53 +0800)]
CHROMIUM: drm/exynos: gem: Remove useless size field
exynos_drm_gem_obj, drm_gem_object, the dma_buf and the exynos_drm_gem_buf
all store a buffer's size. This seems a bit excessive.
Remove the exynos_drm_gem_obj copy, since it is written to but never read.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:37097
TEST=compile test
Change-Id: I5bf057964351d08f40146f0e928e6eb8414f164f
Reviewed-on: https://gerrit.chromium.org/gerrit/39475
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Daniel Kurtz [Mon, 10 Dec 2012 05:51:40 +0000 (13:51 +0800)]
CHROMIUM: drm/exynos: Remove vaddr from drm_overlay
Consumers of the drm_overlay vaddr object only care about the dma_addr,
so they can program DMA in a display controller. They never need to know
the corresponding vaddr.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:37097
TEST=compile test; booted w/ debug enabled and verified debug messages
no longer include vaddr
Change-Id: Ia96ebea8f39d4a733bc6732b6cc9be85f1a8c0e3
Reviewed-on: https://gerrit.chromium.org/gerrit/39474
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org>
CHROMIUM: drm/exynos: don't warn about non-kds modeset
Now that the page_flip logic is shared with the mode_set code,
it's possible for us to call page_flip on a non-kds buffer.
Modify the warning to only check the non-modeset case.
Olof Johansson [Fri, 7 Dec 2012 19:42:19 +0000 (11:42 -0800)]
CHROMIUM: LSM: allow old style loads when locking disabled
This is needed when our kernel is used with other userspaces, i.e. Ubuntu
and other distros.
Enabling old-style module init when locking is explicitly disabled doesn't
open up any security exposure for users unless they have disabled
rootfs_verification AND module load restrictions. I.e. default users have
no added exposure.
BUG=chromium-os:37055
TEST=needs a new testcase (crosbug.com/37056)
This patch switches zcache and zram dependency to ZSMALLOC
rather than X86. There is no net change since ZSMALLOC
depends on X86, however, this prevent further changes to
these files as zsmalloc dependencies change.
Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
BUG=chromium-os:36829
TEST=compile, verify that zram module is updated and /boot/config is correct
Change-Id: I91f6ed46549fe62a9fe3035063d98beb2f5d966a Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39289 Tested-by: Luigi Semenzato <semenzato@google.com> Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Ready: Luigi Semenzato <semenzato@google.com>
John Sheu [Thu, 6 Dec 2012 01:23:26 +0000 (17:23 -0800)]
CHROMIUM: exynos: keep exynos_plane zpos on disable
Exynos DRM planes are implemented using overlay hardware. Presently we
reset the overlay zpos back to default every time a plane is disabled.
Don't do this anymore.
Signed-off-by: John Sheu <sheu@chromium.org>
BUG=chromium-os:36991
TEST=local build, run on exynos
Change-Id: I4c3490ef05d1ecdfeea6cbf26f020b9a19ebe764
Reviewed-on: https://gerrit.chromium.org/gerrit/39296 Tested-by: John Sheu <sheu@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Ready: John Sheu <sheu@chromium.org>
Michael Spang [Fri, 9 Nov 2012 19:33:47 +0000 (14:33 -0500)]
CHROMIUM: serial: exynos: Resume UART earlier with SAMSUNG_PM_DEBUG
Even with SAMSUNG_PM_DEBUG enabled, we're losing lots of console UART
output during resume. This patch makes SAMSUNG_PM_DEBUG correcly
resume the UART as early as possible, so that no output is lost.
BUG=chrome-os-partner:10932
TEST=powerd_suspend with no_console_suspend and SAMSUNG_PM_DEBUG
Change-Id: Ic892ed225c9075e8d72d851a4f2e22263ee6047d Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37734 Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Dylan Reid [Mon, 19 Nov 2012 06:56:40 +0000 (22:56 -0800)]
BACKPORT: ALSA: hda - Fix Acer Aspire models with analog mics.
The Acer Aspire AO756 has an analog built-in mic on nid 0x1b and an
external mic on nid 0x19. The BIOS doesn't set this up.
The mic detect on this Acer Aspire netbook and Acer C7 ChromeBook is
only valid when the headphone is plugged. The detect circuit relies on
the tip detect switch being closed on the jack. Tell hda_jack to ignore
the mic sense unless the headphones are plugged.
Dylan Reid [Mon, 19 Nov 2012 18:48:07 +0000 (19:48 +0100)]
BACKPORT: ALSA: hda - Allow jack state to depend on another jack
Introduce the concept of a "gated" jack. The gated jack's pin sense
is
only valid when the "gating" jack is plugged. This requires checking
the gating jack when the gated jack changes and re-checking the gated
jack when the gating jack is plugged/unplugged.
This allows handling of devices where the mic jack detect floats when
the headphone jack is unplugged.
[Rewritten for fixing the possible snd_array reallocation, covering
the missing callback calls and jack sync operations, as well as some
code cleanups -- tiwai]
Michael Spang [Fri, 9 Nov 2012 01:06:06 +0000 (20:06 -0500)]
CHROMIUM: serial: samsung: Avoid waiting forever for TX ready
The no_console_suspend option allows the console to write to the UART
during early resume, before the serial port itself is resumed. Such
writes hang indefinitely waiting for TX ready.
This adds a check to the console putchar function to drop characters
instead of hanging if the port hasn't been initialized. That way, we
can use no_console_suspend without risk of hanging.
BUG=chrome-os-partner:10932
TEST=powerd_suspend with no_console_suspend but not SAMSUNG_PM_DEBUG
Change-Id: I64e8def33fe984b97776206451e6030d6c761355 Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37714
Vincent Palatin [Fri, 16 Nov 2012 17:32:27 +0000 (09:32 -0800)]
CHROMIUM: exynos: dts: update configuration for Spring proto-1
- we have now an HDMI output, re-activate it.
- disable the OHCI controller until the hardware is fixed :
This OHCI controller has no individual port power support,
so activating the controller always enables the port power on port 0
independantly of the EHCI state or the port power bit. This will then
turn on the VBUS regulator and might create an electrical conflict
with the USB boost.
- disable port 0 on EHCI to keep the VBUS regular off.
- tune the eDP bridge regulator configuration :
it needs to be on even if the bootloader is not using the screen.
- disable high-speed mode on Wifi SDIO until we find the issue.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14489
TEST=boot on Spring.
Change-Id: Ibcfc2848d932026a711833471af908867659f74b
Reviewed-on: https://gerrit.chromium.org/gerrit/38223
Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org>
Vincent Palatin [Fri, 16 Nov 2012 20:22:44 +0000 (12:22 -0800)]
CHROMIUM: usb: allow to de-activate some ports on EHCI root hub
To optimize power consumption and sometimes avoid electrical conflicts
on the board, we might want to avoid activating some of the ports on
the root hub.
The platform specific part of the driver can optionally provide a bitmap
of the enabled ports. By default, all ports are enabled.
This might be reverted once we have another mechanism to control VBUS
regulator on the next hardware revision.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14490
TEST=boot on Spring, verify that port 0 regulator is not enabled and
port 1 is detecting a USB key correctly.
boot on Snow, verify that port 0 is detecting a USB key
Change-Id: Ib08d18a105e366b37f5117a6f7c0e1e56e04dce5
Reviewed-on: https://gerrit.chromium.org/gerrit/38222
Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org>
Benson Leung [Tue, 20 Nov 2012 07:16:54 +0000 (23:16 -0800)]
CHROMIUM: Input: cyapa - More reliable cyapa_get_state.
In cyapa_get_state, add an additional check for OP_STATUS_SRC bit
in REG_OP_STATUS. This bit should only be set when in operational
mode.
Under some conditions, the REG_OP_STATUS may return 0x89,
with the device status bits being 0b01, indicating the operational
mode firmware is busy executing a command from the host. Handle this
status and return state CYAPA_STATE_OP if we are not in bootloader based
on OP_STATUS_SRC.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:16217
TEST=Test Lumpy (Samsung Series 5 550) and Snow (Samsung Chromebook ARM)
using this driver.
1. Cold boot the system (power on the system from full on)
2. Warm reboot the system (reboot the system using command sudo reboot)
Check that the touchpad is detected in both cases and is functional.
3. Force a firmware update and check that it succeeds.
/opt/google/touchpad/firmware/chromeos_touch_firmwareupdate -d cyapa -f
Furthermore, see crosbug.com/p/16217 for detailed repro steps.
System with this patch should survive the suspend/resume test
with a grounded metal probe touching the touchpad generating activity.
suspend_stress_test --wake_min 0 --wake_max 0 --backup_rtc
Change-Id: Ie2d513a3a868c6914776355222fad21935af88a5
Reviewed-on: https://gerrit.chromium.org/gerrit/38364 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Dudley Du <dudl@cypress.com>
Commit-Ready: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org>
Bing Zhao [Mon, 3 Dec 2012 19:52:13 +0000 (11:52 -0800)]
Bluetooth: btmrvl: enable RESET_ON_CLOSE quirk
When user brings down the HCI interface without explicitly
disconnecting the HID device(s) or resetting the HCI interface,
SD8797 firmware won't get the indication of "interface down".
This results that the SD8797 Wi-Fi stays at 1x1 mode without
switching back to 2x2 mode.
Work it around by setting RESET_ON_CLOSE bit to have the stack
reset the HCI interface upon close.
BUG=chrome-os-partner:14937
TEST=WiFi associates to 2.4GHz AP close enough; Bluetooth connects
to HID mouse; "iw mlan0 link" shows WiFi link tx bitrates at MCS7.
Uncheck "Enable bluetooth" checkbox, or issue "hciconfig hci0 down"
command, "iw mlan0 link" shows tx bitrates at MCS15 or MCS14.
Change-Id: Ic1468c3f60b504aa2efe80cbc72a22872b256f04 Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/39163 Reviewed-by: Paul Stewart <pstew@chromium.org> Reviewed-by: Scott James Remnant <keybuk@chromium.org>
Bing Zhao [Mon, 3 Dec 2012 19:38:10 +0000 (11:38 -0800)]
UPSTREAM: Bluetooth: Rename HCI_QUIRK_NO_RESET to HCI_QUIRK_RESET_ON_CLOSE
HCI_QUIRK_NO_RESET name is misleading - purpose of this quirk is to
reset device on close instead of init, not to not reset at all.
Rename it to HCI_QUIRK_RESET_ON_CLOSE to avoid confusion.
Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:14937
TEST=WiFi associates to 2.4GHz AP close enough; Bluetooth connects
to HID mouse; "iw mlan0 link" shows WiFi link tx bitrates at MCS7.
Uncheck "Enable bluetooth" checkbox, or issue "hciconfig hci0 down"
command, "iw mlan0 link" shows tx bitrates at MCS15 or MCS14.
Change-Id: Ib83bdea24c9820efe321c02f10ffce43c42368e5
Reviewed-on: https://gerrit.chromium.org/gerrit/39162 Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Bing Zhao <bzhao@marvell.com> Tested-by: Bing Zhao <bzhao@marvell.com> Reviewed-by: Scott James Remnant <keybuk@chromium.org>
According to Creative there are some extreme circumstances where the
DSP can take > 1second to respond to a command. I have asked them to
investigate further and eliminate this possibility. Until the DSP
side can be fixed, lengthen the timeout to 2 seconds so the system
avoid resuming without audio.
BUG=chrome-os-partner:14465
TEST=suspend/resume for 4k cycles, never see DSP load failure.
Doug Anderson [Mon, 3 Dec 2012 19:00:29 +0000 (11:00 -0800)]
CHROMIUM: scripts: Make genconfig clean configs
Right now genconfig just dumps out the raw output of concatenating all
of the relevant configs. This makes it hard to diff. Make it easier
by running "oldconfig" over this and also providing a savedefconfig.
BUG=None
TEST=Run ./chromeos/scripts/kernelconfig genconfig and look at
CONFIGS directory; try this even when the configs aren't normalized.
Change-Id: I19da6d54d5e550682737f0a23440fd2cc05dbd16 Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39094 Reviewed-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
CHROMIUM: UPSTREAM: staging: zsmalloc: remove x86 dependency
This patch replaces the page table assisted object mapping
method, which has x86 dependencies, with a arch-independent
method that does a simple copy into a temporary per-cpu
buffer.
While a copy seems like it would be worse than mapping the pages,
tests demonstrate the copying is always faster and, in the case of
running inside a KVM guest, roughly 4x faster.
Ben Hutchings [Wed, 20 Jun 2012 01:31:11 +0000 (02:31 +0100)]
CHROMIUM: BACKPORT: staging: zsmalloc: Finish conversion to a separate module
Need BACKPORT, rather than UPSTREAM, since it won't apply cleanly because
we had already fixed the MODULE_LICENSE problem.
---original comment:
ZSMALLOC is tristate, but the code has no MODULE_LICENSE and since it
depends on GPL-only symbols it cannot be loaded as a module. This in
turn breaks zram which now depends on it. I assume it's meant to be
Dual BSD/GPL like the other z-stuff.
There is also no module_exit, which will make it impossible to unload.
Add the appropriate module_init and module_exit declarations suggested
by comments.
Reported-by: Christian Ohm <chr.ohm@gmx.net>
References: http://bugs.debian.org/677273 Cc: stable@vger.kernel.org # v3.4 Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Conflicts:
By chance, struct attribute's "attr" field is first, so its address is the
address of the struct attribute, so this typo has no functional effect, it
just suppresses this compiler warning:
drivers/input/touchscreen/atmel_mxt_ts.c:2059:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/input/touchscreen/atmel_mxt_ts.c:2059:2: warning: (near initialization for 'mxt_power_attrs[0]') [enabled by default]
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:36877
TEST=builds clean
Change-Id: If79a410afb82984472893673b97aa784249a3ca5
Reviewed-on: https://gerrit.chromium.org/gerrit/39069 Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Benson Leung [Fri, 30 Nov 2012 23:26:49 +0000 (15:26 -0800)]
CHROMIUM: Input: atmel_mxt_ts - Prevent null dereferences when in bootloader
When we are in bootloader mode, the input_dev is not valid, and neither is
the object table. Several paths may result in something trying to dereference
these. This patch addresses the following :
1) mxt_resume calls input_unregister_device on input_dev.
2) mxt_suspend/resume reads and writes from the object table.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:16507
TEST=First, get the touch device into a bad state by doing the following:
1. Modify chromeos/config/base.config and set CONFIG_TOUCHSCREEN_ATMEL_MXT=m
2. Build, boot this kernel, and make sure that the touch device works.
3. /opt/google/touch/firmware/chromeos-touch-firmwareupdate.sh \
-d atmel_mxt_ts -n maxtouch-ts.fw -f
4. Before it can finish, CTRL-C to interrupt the firmware update.
This will ensure that the touch device is stuck in bootloader mode.
Now, test that mxt_remove is not vulnerable:
1. rmmod atmel_mxt_ts
2. check that the system does not reboot.
3. modprobe chromeos_mxt_ts
Test that suspend/resume does is not vulnerable:
1. Close the lid to suspend the system.
2. Open the lid to suspend the system.
3. Check that the system did not reboot.
CHROMIUM: sound / hda: Fix D0 power state checking.
Power state checking for HDA cards is broken. According to the HDA spec, the
lower four bits of the power state register define the "set" power state and
the next four bits define the "actual" state. Subsequent bits have different
meanings. When we check the power state of our card during transition to D0,
we read the entire register and compare to AC_PWRST_D0 (0). This leads to
timeout of the wait loop and ~500ms wasted during resume if some upper
status bits are set.
Solution is to mask off all upper bits and compare only get + set state. If
these states are 0, it means the transition has completed.
This is fixed differently in the mainstream kernel repo, but there are some
extra dependencies involved. Therefore, this patch should NOT be carried
forward through the next kernel rebase.
DO NOT CARRY FORWARD.
TEST=Run power_Resume test on HDA card that reports PS-ClkStopOk status.
Confirm that resume time is no longer ~500 ms.
BUG=chrome-os-partner:15729
Vincent Palatin [Fri, 30 Nov 2012 17:33:44 +0000 (09:33 -0800)]
BACKPORT: x86, fpu: avoid FPU lazy restore after suspend
When a cpu enters S3 state, the FPU state is lost.
After resuming for S3, if we try to lazy restore the FPU for a process running
on the same CPU, this will result in a corrupted FPU context.
Ensure that "fpu_owner_task" is properly invalided when (re-)initializing a CPU,
so nobody will try to lazy restore a state which doesn't exist in the hardware.
Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Olof Johansson <olofj@chromium.org> Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:16295
TEST=On Link, run thousands of suspend/resume cycles with 4 processes doing FPU
operations running as described in the bug.
Without the patch, a process is killed after a few hundreds cycles by a SIGFPE.
Change-Id: I33ee884dea6cad048cbe1aa60c64cbb5141d3f66
Reviewed-on: https://gerrit.chromium.org/gerrit/39006
Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org>
Shan Wei [Wed, 28 Nov 2012 02:54:31 +0000 (10:54 +0800)]
UPSTREAM: staging: gdm72xx: use %pI4 format to print IPv4 address and remove last usage of NIP6
commit cf4ca4874fc45 removed the definition of NIPQUAD and NIPQUAD_FMT,
and NIP6 also is out of date.
commit 2874762b31d8d replace deprecated NIPQUAD marco to C code, but we can use %pI4 to
print IPv4 address more simply. And remove constant condition judge.
Because DEBUG_SDU is not defined in gdm_wimax.h, no error message when compiling.
Ben Chan [Tue, 27 Nov 2012 04:18:45 +0000 (20:18 -0800)]
UPSTREAM: staging: gdm72xx: fix unused variable warning in gdm_usb_send
This patch fixes an unused variable warning in gdm_usb_send
(when CONFIG_WIMAX_GDM72XX_K_MODE=n), which was introduced in
commit 1a276b80466bbd195cf94ec7178f68f2ab351467 (staging:
gdm72xx: protect access of rx / tx structs).
Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Ben Chan <benchan@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a7e4a982fe2a9375952798294ebfb38dc0ed6782)
Change-Id: Ifcc7f122a8342f51d697a48b55d604f71a582f52 Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38962 Reviewed-by: Olof Johansson <olofj@chromium.org>
YAMANE Toshiaki [Mon, 29 Oct 2012 11:05:57 +0000 (20:05 +0900)]
UPSTREAM: staging/gdm72xx: Use dev_ printks in usb_boot.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
YAMANE Toshiaki [Mon, 29 Oct 2012 11:05:43 +0000 (20:05 +0900)]
UPSTREAM: staging/gdm72xx: Use dev_ printks in gdm_usb.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
YAMANE Toshiaki [Mon, 29 Oct 2012 11:05:30 +0000 (20:05 +0900)]
UPSTREAM: staging/gdm72xx: Use dev_ printks in sdio_boot.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
YAMANE Toshiaki [Mon, 29 Oct 2012 11:05:16 +0000 (20:05 +0900)]
UPSTREAM: staging/gdm72xx: Use dev_ printks in gdm_sdio.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
YAMANE Toshiaki [Mon, 29 Oct 2012 11:04:42 +0000 (20:04 +0900)]
UPSTREAM: staging/gdm72xx: Use netdev_ or pr_ printks in gdm_qos.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
- WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ...
YAMANE Toshiaki [Mon, 29 Oct 2012 11:03:47 +0000 (20:03 +0900)]
UPSTREAM: staging/gdm72xx: Use netdev_ or pr_ printks in gdm_wimax.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_emerg(netdev, ... then dev_emerg(dev, ... then pr_emerg(... to printk(KERN_EMERG ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
"Intel xhci: Support EHCI/xHCI port switching."
Signed-off-by: Russell Webb <russell.webb@linux.intel.com>
BUG=None
TEST=Boot from USB3 key in a USB3 port with Lynx Point LP Chipset
Change-Id: Id2406402f53dccd98c5b4916c55b69cf3ea7179e
Reviewed-on: https://gerrit.chromium.org/gerrit/37927
Commit-Ready: Russell Webb <russell.webb@intel.com> Tested-by: Russell Webb <russell.webb@intel.com> Reviewed-by: Olof Johansson <olofj@chromium.org>
Sarah Sharp [Thu, 9 Feb 2012 23:55:13 +0000 (15:55 -0800)]
UPSTREAM: xhci: Add Lynx Point to list of Intel switchable hosts.
The upcoming Intel Lynx Point chipset includes an xHCI host controller
that can have ports switched from the EHCI host controller, just like
the Intel Panther Point xHCI host. This time, ports from both EHCI
hosts can be switched to the xHCI host controller. The PCI config
registers to do the port switching are in the exact same place in the
xHCI PCI configuration registers, with the same semantics.
Hooray for shipping patches for next-gen hardware before the current gen
hardware is even available for purchase!
This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
"Intel xhci: Support EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
BUG=None
TEST=Boot from USB3 key in a USB3 port with Lynx Point Chipset
Change-Id: I38de395b5c7812bbc61fd11e0d27c3ec12514978
Reviewed-on: https://gerrit.chromium.org/gerrit/37926
Commit-Ready: Russell Webb <russell.webb@intel.com> Tested-by: Russell Webb <russell.webb@intel.com> Reviewed-by: Olof Johansson <olofj@chromium.org>
projects / people / aperard / linux-chromebook.git / log