Update struct xen_add_to_physmap to be in sync with Xen's version of the
structure.
The size field was introduced by:
changeset: 24164:707d27fe03e7
user: Jean Guyader <jean.guyader@eu.citrix.com>
date: Fri Nov 18 13:42:08 2011 +0000
summary: mm: New XENMEM space, XENMAPSPACE_gmfn_range
According to the comment:
"This new field .size is located in the 16 bits padding between .domid
and .space in struct xen_add_to_physmap to stay compatible with older
versions."
Changes in v2:
- remove erroneous comment in the commit message.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Ian Campbell [Wed, 17 Oct 2012 08:39:17 +0000 (09:39 +0100)]
xen: arm: make p2m operations NOPs
This makes common code less ifdef-y and is consistent with PVHVM on
x86.
Also note that phys_to_machine_mapping_valid should take a pfn
argument and make it do so.
Add __set_phys_to_machine, make set_phys_to_machine a simple wrapper
(on systems with non-nop implementations the outer one can allocate
new p2m pages).
Make __set_phys_to_machine check for identity mapping or invalid only.
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Ian Campbell [Wed, 3 Oct 2012 11:17:50 +0000 (12:17 +0100)]
xen: balloon: allow PVMMU interfaces to be compiled out
The ARM platform has no concept of PVMMU and therefor no
HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out
when not required.
In some similar situations (e.g. P2M) we have defined dummy functions
to avoid this, however I think we can/should draw the line at dummying
out actual hypercalls.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Conflicts:
drivers/xen/Kconfig
Mukesh Rathor [Thu, 18 Oct 2012 00:11:21 +0000 (17:11 -0700)]
xen: privcmd: support autotranslated physmap guests.
PVH and ARM only support the batch interface. To map a foreign page to
a process, the PFN must be allocated and the autotranslated path uses
ballooning for that purpose.
The returned PFN is then mapped to the foreign page.
xen_unmap_domain_mfn_range() is introduced to unmap these pages via the
privcmd close call.
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
[v1: Fix up privcmd_close] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
[v2: used for ARM too]
Ian Campbell [Wed, 17 Oct 2012 20:37:49 +0000 (13:37 -0700)]
xen: add pages parameter to xen_remap_domain_mfn_range
Also introduce xen_unmap_domain_mfn_range. These are the parts of
Mukesh's "xen/pvh: Implement MMU changes for PVH" which are also
needed as a baseline for ARM privcmd support.
The original patch was:
Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This derivative is also:
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Mats Petersson [Fri, 16 Nov 2012 18:36:49 +0000 (18:36 +0000)]
xen/privcmd: Correctly return success from IOCTL_PRIVCMD_MMAPBATCH
This is a regression introduced by ceb90fa0 (xen/privcmd: add
PRIVCMD_MMAPBATCH_V2 ioctl). It broke xentrace as it used
xc_map_foreign() instead of xc_map_foreign_bulk().
Most code-paths prefer the MMAPBATCH_V2, so this wasn't very obvious
that it broke. The return value is set early on to -EINVAL, and if all
goes well, the "set top bits of the MFN's" never gets called, so the
return value is still EINVAL when the function gets to the end, causing
the caller to think it went wrong (which it didn't!)
Now also including Andres "move the ret = -EINVAL into the error handling
path, as this avoids other similar errors in future.
Signed-off-by: Mats Petersson <mats.petersson@citrix.com> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> Acked-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Dan Carpenter [Sat, 8 Sep 2012 09:57:35 +0000 (12:57 +0300)]
xen/privcmd: return -EFAULT on error
__copy_to_user() returns the number of bytes remaining to be copied but
we want to return a negative error code here.
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen/privcmd: Fix mmap batch ioctl error status copy back.
Copy back of per-slot error codes is only necessary for V2. V1 does not provide
an error array, so copyback will unconditionally set the global rc to EFAULT.
Only copyback for V2.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
field for reporting the error code for every frame that could not be
mapped. libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
in the mfn array.
Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen_init_IRQ should be marked __init because it calls other functions
marked __init and is always called by functions marked __init (on both
x86 and arm).
Also remove the unused EXPORT_SYMBOL_GPL(xen_init_IRQ).
Both changes were introduced by "xen/arm: receive Xen events on ARM".
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen/xen_initial_domain: check that xen_start_info is initialized
Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm:
initial Xen support") PV on HVM guests can be xen_initial_domain.
However PV on HVM guests might have an unitialized xen_start_info, so
check before accessing its fields.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Ian Campbell <Ian.Campbell@citrix.com> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen/arm: Fix compile errors when drivers are compiled as modules (export more).
The commit 911dec0db4de6ccc544178a8ddaf9cec0a11d533
"xen/arm: Fix compile errors when drivers are compiled as modules." exports
the neccessary functions. But to guard ourselves against out-of-tree modules
and future drivers hitting this, lets export all of the relevant
hypercalls.
arm: introduce a DTS for Xen unprivileged virtual machines
Given that the xenvm machine is based on vexpress but with an extremely
limited selection of peripherals (the guest is supposed to use virtual
devices instead), add "xen,xenvm" to the list of compatible machines in
mach-vexpress.
Changes in v3:
- add comments to mark fields that are likely to be changed by the
hypervisor.
Changes in v2:
- remove include skeleton;
- use #address-cells = <2> and #size-cells = <2>;
- remove the debug bootargs;
- use memory@80000000 instead of memory;
- remove the ranges and interrupt-map from the motherboard node;
- set the machine compatible to "xen,xenvm-4.2", "xen,xenvm";
- rename the dts file to xenvm-4.2.dts;
- add "xen,xenvm" to the list of compatible DT strings to mach-vexpress.
Initialize the grant table mapping at the address specified at index 0
in the DT under the /xen node.
After the grant table is initialized, call xenbus_probe (if not dom0).
Changes in v2:
- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames.
All the original Xen headers have xen_ulong_t as unsigned long type, however
when they have been imported in Linux, xen_ulong_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_ulong_t and let each architecture define xen_ulong_t as they
see fit.
Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit.
Changes in v3:
- remove the incorrect changes to multicall_entry;
- remove the change to apic_physbase.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
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).
projects / people / aperard / linux-chromebook.git / log