Add a doc to describe the Xen ARM device tree bindings
Changes in v5:
- add a comment about the size of the grant table memory region;
- add a comment about the required presence of a GIC node;
- specify that the described properties are part of a top-level
"hypervisor" node;
- specify #address-cells and #size-cells for the example.
Changes in v4:
- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Rob Herring <rob.herring@calxeda.com> CC: devicetree-discuss@lists.ozlabs.org CC: David Vrabel <david.vrabel@citrix.com> CC: Rob Herring <robherring2@gmail.com> CC: Dave Martin <dave.martin@linaro.org>
sync_bitops functions are equivalent to the SMP implementation of the
original functions, independently from CONFIG_SMP being defined.
We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
under Xen you might be communicating with a completely external entity
who might be on another CPU (e.g. two uniprocessor guests communicating
via event channels and grant tables). So we need a variant of the bit
ops which are SMP safe even on a UP kernel.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Use r12 to pass the hypercall number to the hypervisor.
We need a register to pass the hypercall number because we might not
know it at compile time and HVC only takes an immediate argument.
Among the available registers r12 seems to be the best choice because it
is defined as "intra-procedure call scratch register".
Use the ISS to pass an hypervisor specific tag.
Changes in v2:
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
at the moment is unused;
- use ldm instead of pop;
- fix up comments.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
- Basic hypervisor.h and interface.h definitions.
- Skeleton enlighten.c, set xen_start_info to an empty struct.
- Make xen_initial_domain dependent on the SIF_PRIVILIGED_BIT.
The new code only compiles when CONFIG_XEN is set, that is going to be
added to arch/arm/Kconfig in patch #11 "xen/arm: introduce CONFIG_XEN on
ARM".
Changes in v3:
- improve comments.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
irq_startup, that is responsible for calling irq_unmask at startup time.
As a result event channels remain masked.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This patch removes the "return -ENOSYS" for auto_translated_physmap
guests from privcmd_mmap, thus it allows ARM guests to issue privcmd
mmap calls. However privcmd mmap calls are still going to fail for HVM
and hybrid guests on x86 because the xen_remap_domain_mfn_range
implementation is currently PV only.
Changes in v2:
- better commit message;
- return -EINVAL from xen_remap_domain_mfn_range if
auto_translated_physmap.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
All the original Xen headers have xen_pfn_t as mfn and pfn type, however
when they have been imported in Linux, xen_pfn_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_pfn_t and let each architecture define xen_pfn_t as they
see fit.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen/events: fix unmask_evtchn for PV on HVM guests
When unmask_evtchn is called, if we already have an event pending, we
just set evtchn_pending_sel waiting for local_irq_enable to be called.
That is because PV guests set the irq_enable pvops to
xen_irq_enable_direct in xen_setup_vcpu_info_placement:
xen_irq_enable_direct is implemented in assembly in
arch/x86/xen/xen-asm.S and call xen_force_evtchn_callback if
XEN_vcpu_info_pending is set.
However HVM guests (and ARM guests) do not change or do not have the
irq_enable pvop, so evtchn_unmask cannot work properly for them.
Considering that having the pending_irq bit set when unmask_evtchn is
called is not very common, and it is simpler to keep the
native_irq_enable implementation for HVM guests (and ARM guests), the
best thing to do is just use the EVTCHNOP_unmask hypercall (Xen
re-injects pending events in response).
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
David Vrabel [Mon, 17 Dec 2012 12:30:58 +0000 (12:30 +0000)]
HACK! arm: set v7 translation table entries as uncachable
There appears to be a bug in the model where the MMU does not
correctly see updates to translation table entries if they are marked
as cachable. This bug only happens when running under the Xen
hypervisor.
As a workaround, mark the entries as uncachable. This decreases
performance.
[ijc - rebase, applying to both proc-v7-{2,3}level.S]
Dave Martin [Mon, 3 Sep 2012 12:49:25 +0000 (13:49 +0100)]
ARM: 7511/1: opcodes: Opcode definitions for the Virtualization Extensions
For now, this patch just adds a definition for the HVC instruction.
More can be added here later, as needed.
Now that we have a real example of how to use the opcode injection
macros properly, this patch also adds a cross-reference from the
explanation in opcodes.h (since without an example, figuring out
how to use the macros is not that easy).
Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Conflicts:
arch/arm/include/asm/opcodes.h
Since trackpoint properties are probed in the boot time, it should
be safe to skip the reconnect function as we don't need to
probe the properties again to reduce the latency of unresponsiveness.
BUG=chrome-os-partner:15015
TEST=on device; use powerd_suspend and then hit a key to wake it up
see if the trackpoint/trackpoint could be active in 3~4 seconds
after resume instead of 7 seconds long
Signed-off-by: Chung-yih Wang <cywang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43510 Tested-by: Agnes Cheng <agnescheng@google.com> Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Gediminas Ramanauskas <gedis@chromium.org>
(cherry picked from commit 6e600b92ec9ff57a6e4935ae31f3b6425c4c3344)
Change-Id: Ibb4f979d0aacad9f66ef4bd1047e97f6343446ab Signed-off-by: Chung-yih Wang <cywang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43766 Reviewed-by: Gediminas Ramanauskas <gedis@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org>
Sonny Rao [Thu, 21 Feb 2013 01:45:06 +0000 (17:45 -0800)]
CHROMIUM: bluetooth/usb: hack to cover up dma after free corruption
This is a horrible, gross hack to cover up the fact that we
sometimes get an apparent DMA from the interrupt endpoint on the
bluetooth module after shutting it down. This ends up manifesting as
random kernel crashes, often from other users of kmalloc-16.
Since we don't have root cause (yet?) and can't do much about it, put
in this band-aid which will leak around 64 bytes of memory every time we
suspend/resume a usb bluetooth device. We make no attempt to free
this memory because we don't know when the DMA could come in and it's
a relatively small amount so probably not worth trying to free it
later.
Another issue is that SLUB will mix together objects from different
slabs if they are all the same size. So, in order to get a separate
slab in /proc/slabinfo, we turn on some of the slab debugging options.
The main reason for doing this is to let us track how much memory got
leaked through slabinfo. This will trigger a BUG_ON() in
kmem_cache_create() if the kernel is compiled with
CONFIG_SLAB && !CONFIG_DEBUG_SLAB.
One day, when we have a real fix, we should remove this abomination.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
BUG=chrome-os-partner:12507
BUG=chrome-os-partner:17614
TEST=repeated suspend resume, should not see a kernel crash
Mathias Krause [Sat, 23 Feb 2013 18:29:07 +0000 (10:29 -0800)]
CHERRY-PICK: CHROMIUM: sock_diag: Fix out-of-bounds access to sock_diag_handlers[]
Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY
with a family greater or equal then AF_MAX -- the array size of
sock_diag_handlers[]. The current code does not test for this
condition therefore is vulnerable to an out-of-bound access opening
doors for a privilege escalation.
Ben Chan [Thu, 21 Feb 2013 01:33:43 +0000 (17:33 -0800)]
CHROMIUM: USB: option: don't show error when urb is killed in an expected way
When a device supported by the option driver is suspended, the interrupt
urb is killed and option_instat_callback() is invoked with the urb's
status set to -ENOENT. The patch prevents the option driver from
spamming the log with a message 'option_instat_callback: error -2' under
such scenario.
BUG=chrome-os-partner:17918
TEST=Tested the following on link:
1. Put the system on battery so that USB auto-suspend is turned on for
the Novatel E362 modem.
2. Verify that the option kernel drive no longer prints the following
error to /var/log/messages:
Yongqiang Yang [Wed, 5 Sep 2012 05:21:50 +0000 (01:21 -0400)]
CHERRY-PICK: UPSTREAM: ext4: ignore last group w/o enough space when resizing instead of BUG'ing
If the last group does not have enough space for group tables, ignore
it instead of calling BUG_ON().
Reported-by: Daniel Drake <dsd@laptop.org> Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: stable@vger.kernel.org
BUG=chromium-os:36118
TEST=link build, resize still works
(cherry picked from upstream commit 03c1c29053f678234dbd51bf3d65f3b7529021de) Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42679 Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Change-Id: I36ce1c515b951b84e77de96fb00cf1acc6c6c25e
(cherry picked from ToT commit 7f6b7cb382b190fc491459f9928916f8b387b4b4) Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43859 Reviewed-by: Olof Johansson <olofj@chromium.org>
Oleg Nesterov [Mon, 21 Jan 2013 19:48:00 +0000 (20:48 +0100)]
CHERRY-PICK: UPSTREAM: ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL
putreg() assumes that the tracee is not running and pt_regs_access() can
safely play with its stack. However a killed tracee can return from
ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
that debugger can actually read/modify the kernel stack until the tracee
does SAVE_REST again.
set_task_blockstep() can race with SIGKILL too and in some sense this
race is even worse, the very fact the tracee can be woken up breaks the
logic.
As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
call, this ensures that nobody can ever wakeup the tracee while the
debugger looks at it. Not only this fixes the mentioned problems, we
can do some cleanups/simplifications in arch_ptrace() paths.
Probably ptrace_unfreeze_traced() needs more callers, for example it
makes sense to make the tracee killable for oom-killer before
access_process_vm().
While at it, add the comment into may_ptrace_stop() to explain why
ptrace_stop() still can't rely on SIGKILL and signal_pending_state().
Oleg Nesterov [Mon, 21 Jan 2013 19:47:41 +0000 (20:47 +0100)]
CHERRY-PICK: UPSTREAM: ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up()
Cleanup and preparation for the next change.
signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
necessary mask.
Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
which adds __TASK_TRACED.
This way ptrace_signal_wake_up() can work "inside" ptrace_request()
even if the tracee doesn't have the TASK_WAKEKILL bit set.
Kees Cook [Fri, 8 Feb 2013 01:01:21 +0000 (17:01 -0800)]
CHERRY-PICK: CHROMIUM: msr: whitelist the i915 thermal control for wrmsr
Deny all userspace MSR writes except those explicitly whitelisted for
i915 thermal controls. Without this, processes with CAP_SYS_RAWIO can
run arbitrary kernel code via MSR writing.
BUG=chromium-os:38756
TEST=link build, wrmsr works only on i915 thermal registers
At the moment the MSR driver only relies upon file system
checks. This means that anything as root with any capability set
can write to MSRs. Historically that wasn't very interesting but
on modern processors the MSRs are such that writing to them
provides several ways to execute arbitary code in kernel space.
Sample code and documentation on doing this is circulating and
MSR attacks are used on Windows 64bit rootkits already.
In the Linux case you still need to be able to open the device
file so the impact is fairly limited and reduces the security of
some capability and security model based systems down towards
that of a generic "root owns the box" setup.
Therefore they should require CAP_SYS_RAWIO to prevent an
elevation of capabilities. The impact of this is fairly minimal
on most setups because they don't have heavy use of
capabilities. Those using SELinux, SMACK or AppArmor rules might
want to consider if their rulesets on the MSR driver could be
tighter.
Signed-off-by: Alan Cox <alan@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Horses <stable@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org>
BUG=chromium-os:38633
TEST=link build, reading MSR correctly fails as uid 0 without caps:
(can't use iotools with minijail because iotools is statically linked)
`minijail0 -c 0 /usr/local/bin/python -c 'from struct import *; \
m = open("/dev/cpu/0/msr"); m.seek(0x3a); \
print "0x%016x" % (unpack("Q", m.read(8)))'`
Luigi Semenzato [Thu, 14 Feb 2013 20:36:50 +0000 (12:36 -0800)]
CHROMIUM: atkbd: improve workaround for chromeos EC bug
This makes the workaround for commit b483f9730b97ba8812340cf1584b491d5aa1e774
(https://gerrit.chromium.org/gerrit/43049, "CHROMIUM: atkbd: workaround
for ChromeOS EC keyboard enable bug") work properly by re-enabling the
keyboard IRQ which was accidentally disabled.
BUG=chrome-os-partner:17810
TEST=tested with > 200 power cycles and > 30 workaround triggers
BRANCH=none
Change-Id: Ia8a817f665a3575eebeb1ba2ec3aa89f80c3e0e3 Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43301
Luigi Semenzato [Mon, 11 Feb 2013 19:47:48 +0000 (11:47 -0800)]
CHROMIUM: atkbd: workaround for ChromeOS EC keyboard enable bug
The ChromeOS EC enables keystrokes too early, and the driver
can get scancodes when it's expecting a response from the
GETID request. The workaround consists of repeating the request
a few times if it fails.
BUG=chrome-os-partner:17005
TEST=verified that the workaround works around the bug
BRANCH=none
When the CPU is loaded and the GPU tries to switch RC6p modes, the GPU
sometimes gets stuck in RC6p mode and doesn't come out of it. I suspect
that our voltage rail is too weak and sometimes falls behind.
This change throttles down the number of RC6p transitions we do to appease it.
The change also disables clock gating which seems to help. Upstream commit
which does that is 0f846f81a154cc1818416918d22939bda73da194
(drm/i915: disable RCBP and VDS unit clock gating on SNB and VL)
I tested this on multiple Link machines for hours. The number of RC6 problems
went down from ~ one every 15 minutes to ~ one every 25 hours. So this is not
a complete solution, but I suspect there might be another, more difficult to
reproduce, problem. In any case it reduces the issue significantly, to the
point where we might be able to forget about it.
I measured the power usage on idle before/after this patch and saw no
difference. Obviously when the GPU load varies, it will consume more power
since it now takes more time to adapt.
Also note that not all machines seem to react equally. Some crash fairly
often, and some less often. So this will improve the situation to different
extents for different people.
BUG=chrome-os-partner:16886,chrome-os-partner:11474
TEST=ran the factory stress test (RunIn.Stress) on multiple Link machines for
TEST=about 100 hours, saw only 4 RC6 crashes.
Julius Werner [Thu, 31 Jan 2013 02:02:45 +0000 (18:02 -0800)]
CHROMIUM: xhci: crude USB resume fix for Stout (temporary)
Stout's USB 3.0 ports show a variety of nasty issues after resume, some
of which are more reproducible than others. They all have in common that
the host controller bails with "Device not responding to set address."
during enumeration. A trace pulled from a USB cable showed that the host
controller just fills the bus with garbage and does not even generate
correct SOF sequences.
This seems like a large and time-consuming problem that could hide
anywhere in the USB software or hardware stack. With Stout being close
to release, we need an interim solution to make it usable while we find
the underlying problem.
This patch sets the XHCI_RESET_ON_RESUME quirk flag on Stout, which
makes device reenumeration after resume work, but it creates a new
issue that makes the host controller hang on the next suspend while
trying to save its state. This looks like an unrelated hardware bug...
but since we don't actually need to save state when we will reset
anyway, we can just add some code to skip that step in xhci_suspend().
This patch is intended to be temporary, and should be reverted as soon
as the root cause for this is found and fixed.
BUG=chrome-os-partner:16781
TEST=Plug a USB device into the yellow port on the right. Run lsusb. Run
powerd_suspend and wake the machine. Run lsusb again and ensure that the
output stayed the same.
Original-Change-Id: Id21ab972c698d02c14937509f699c9bc659b70c0 Signed-off-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 8b145d803ef366508c212072db0cd01718247241)
Applied without conflicts to R25. Tested on 3428.124.0 stout canary image.
Change-Id: I10bbe5414f1f52762ddd6a97e4231ab544b8e3b4
Reviewed-on: https://gerrit.chromium.org/gerrit/42541 Reviewed-by: Paul Taysom <taysom@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org> Tested-by: Julius Werner <jwerner@chromium.org>
Kees Cook [Tue, 18 Dec 2012 00:03:14 +0000 (16:03 -0800)]
CHERRY-PICK: UPSTREAM: /proc/pid/status: add "Seccomp" field
It is currently impossible to examine the state of seccomp for a given
process. While attaching with gdb and attempting "call
prctl(PR_GET_SECCOMP,...)" will work with some situations, it is not
reliable. If the process is in seccomp mode 1, this query will kill the
process (prctl not allowed), if the process is in mode 2 with prctl not
allowed, it will similarly be killed, and in weird cases, if prctl is
filtered to return errno 0, it can look like seccomp is disabled.
When reviewing the state of running processes, there should be a way to
externally examine the seccomp mode. ("Did this build of Chrome end up
using seccomp?" "Did my distro ship ssh with seccomp enabled?")
This adds the "Seccomp" line to /proc/$pid/status.
Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: James Morris <jmorris@namei.org> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from upstream commit 2f4b3bf6b2318cfaa177ec5a802f4d8d6afbd816) Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41959 Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
BUG=chromium-os:38441
TEST=link build, "Seccomp" field visible in "status" file
Change-Id: Iba02cd3323908bd2c761393ce3ccef3cc85f2bd6
(cherry picked from ToT commit 9283927e50378bb8bb2fbfc53b615b02d546f090) Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42411 Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org>
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.
projects / people / aperard / linux-chromebook.git / log