| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables wiphy device to suspend/resume asynchronously. This can
take advantage of multicore and improve system suspend/resume speed.
Comparison of power_Resume test results (by cywang):
w/o patch
seconds_system_resume_kernel{perf}=0.879189
seconds_system_resume{perf}=1.31215405464
w/ patch
seconds_system_resume_kernel{perf}=0.634252
seconds_system_resume{perf}=1.07773995399
This shows an improvement of overall resume time of ~230 ms.
BUG=chrome-os-partner:46185
TEST=run the power_Resume test with and without this patch and check
that the total wake-up time is shorter with this patch.
Change-Id: I5c09b78ffcc4c315ddc698a6e95b60174b7865b5
Signed-off-by: Zhonghui Fu <zhonghui.fu@linux.intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry-picked from 9f0e13546ef5773b7059b531a667ec47a5f897ee)
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/304337
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
BUG=chromium:539965
TEST=update_kernel, verify that /dev/dri/renderD128 is present
Signed-off-by: Haixia Shi <hshi@chromium.org>
Change-Id: I8ceabfc8d0be94388b76f1b0e288e95bc836e61b
Reviewed-on: https://chromium-review.googlesource.com/304322
Commit-Ready: Haixia Shi <hshi@chromium.org>
Tested-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Ilja Friedel <ihf@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
|
|
usbhid->intf->needs_remote_wakeup is set when a device is
opened, and is cleared when a device is closed.
When a usbhid device that does not support remote wake
( i.e. !device_can_wakeup() ) is closed, we fail out of
autosuspend_check() because the autosuspend check is called
before the flag is cleared as a result of usb_kill_urb(usbhid->urbin);
The result is that a device that may otherwise autosuspend will
fail to enter suspend again after all handles to it are closed.
In usbhid_open, usb_autopm_get_interface is called
before setting the needs_remote_wakeup flag, and
usb_autopm_put_interface is called after hid_start_in.
However, when the device is closed in usbhid_close, the same
protection isn't there when clearing needs_remote_wakeup. This will
add that to usbhid_close as well as usbhid_stop.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chromium:431886
TEST=Whitelist security key devices using crosreview.com/229105
Plug in the security key. After a second, touch the device.
Verify that it has entered suspend (doesn't light up).
Bring up a 2 factor prompt that uses security key.
Touch the key to proceed through the prompt.
Check that it succeeds.
Check that after 2 seconds, the device returns to suspended state.
Reviewed-on: https://chromium-review.googlesource.com/229176
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Trybot-Ready: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
(cherry picked from commit 96b27c117496dc8ec885e4cbff39346e7aa57a6e)
Signed-off-by: Benson Leung <bleung@chromium.org>
Change-Id: If462785d61b0e8f4d592ed064ce48d06c3e478b9
Reviewed-on: https://chromium-review.googlesource.com/303932
Commit-Ready: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Add quirk to make sure that a device is always polled for input events
even if it hasn't been opened.
This is needed for devices that disconnects from the bus unless the
interrupt endpoint has been polled at least once or when not responding
to an input event (e.g. after having shut down X).
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
(cherry picked from commit 0b750b3baa2d64f1b77aecc10f20deeb28efe60d)
[bleung : pulled in this patch verbatim upstream to resolve upstream conflicts]
Signed-off-by: Benson Leung <bleung@chromium.org>
Conflicts:
include/linux/hid.h
[bleung : Minor context conflict fix]
BUG=chromium:431886
TEST=None.
Change-Id: I948519c4a74ab37e36f291fd3dc9c46ae9600e1d
Reviewed-on: https://chromium-review.googlesource.com/303931
Commit-Ready: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
memcpy_fromiovecend
Check for cases when the caller requests 0 bytes instead of running off
and dereferencing potentially invalid iovecs.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 06ebb06d49486676272a3c030bfeef4bd969a8e6)
Signed-off-by: Alexander Potapenko <glider@google.com>
BUG=chromium:539371
TEST=no KASan reports in memcpy_fromiovecend
Change-Id: I28ffd50c9f1c2b5b0cd12643bb5582b68294f3db
Reviewed-on: https://chromium-review.googlesource.com/303611
Commit-Ready: Alexander Potapenko <glider@chromium.org>
Tested-by: Alexander Potapenko <glider@chromium.org>
Reviewed-by: Filipe Brandenburger <filbranden@chromium.org>
|
|
Bump up the clocks of jpeg from 200MHz to 300MHz can improve 30%
decode latency.
BUG=chromium:426383
TEST=run jpeg standalone test and decode latency is from 4.66ms to
3.209 ms for 720p image.
Change-Id: I7785f9a92031be1d01b522306eb0aea047d31bb6
Signed-off-by: Heng-Ruey Hsu <henryhsu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304063
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Arjun K V <arjun.kv@samsung.com>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
There should only be one DAI link named Primary.
BUG=chromium:455751
TEST=`aplay -l` to check there is only one device named Primary.
TEST=Check playback/record functions on peach_pit are fine.
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Change-Id: I2cd15f759a0f514cf6b63dbd91274368579bf66e
Reviewed-on: https://chromium-review.googlesource.com/303597
|
|
Add a new clock type CLOCK_SYSTEM_TRACE to retrieve the current trace
clock value (if CONFIG_TRACING is not defined then CLOCK_SYSTEM_TRACE
returns the same value as CLOCK_MONOTONIC_RAW). This allows user event
tracing to timestamp data with the same clock as the kernel. This is
in-lieu of sending event data through trace_write (which is not a viable
option when there are lots of user-space events).
BUG=chromium:324025
TEST=Chrome tracing works
Signed-off-by: Sam Leffler <sleffler@chromium.org>
Change-Id: If2167ed99291e05f8c298638f4118b10b3e710f8
Reviewed-on: https://gerrit.chromium.org/gerrit/21404
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
[SR: we'll need this to be in place to avoid breaking Chrome while we
transition to monotonic clock]
Conflicts:
include/linux/kernel.h
Reviewed-on: https://chromium-review.googlesource.com/303497
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
|
|
Expose the new NMI safe accessor to clock monotonic to the tracer.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 1b3e5c0936046e7e023149ddc8946d21c2ea20eb)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: context, 3.8 doesn't have as many clock types]
Conflicts:
kernel/trace/trace.c
Change-Id: I39001b72a011974a6393e809a6df3fe76e933d10
Reviewed-on: https://chromium-review.googlesource.com/300784
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Tracers want a correlated time between the kernel instrumentation and
user space. We really do not want to export sched_clock() to user
space, so we need to provide something sensible for this.
Using separate data structures with an non blocking sequence count
based update mechanism allows us to do that. The data structure
required for the readout has a sequence counter and two copies of the
timekeeping data.
On the update side:
smp_wmb();
tkf->seq++;
smp_wmb();
update(tkf->base[0], tk);
smp_wmb();
tkf->seq++;
smp_wmb();
update(tkf->base[1], tk);
On the reader side:
do {
seq = tkf->seq;
smp_rmb();
idx = seq & 0x01;
now = now(tkf->base[idx]);
smp_rmb();
} while (seq != tkf->seq)
So if a NMI hits the update of base[0] it will use base[1] which is
still consistent, but this timestamp is not guaranteed to be monotonic
across an update.
The timestamp is calculated by:
now = base_mono + clock_delta * slope
So if the update lowers the slope, readers who are forced to the
not yet updated second array are still using the old steeper slope.
tmono
^
| o n
| o n
| u
| o
|o
|12345678---> reader order
o = old slope
u = update
n = new slope
So reader 6 will observe time going backwards versus reader 5.
While other CPUs are likely to be able observe that, the only way
for a CPU local observation is when an NMI hits in the middle of
the update. Timestamps taken from that NMI context might be ahead
of the following timestamps. Callers need to be aware of that and
deal with it.
V2: Got rid of clock monotonic raw and reorganized the data
structures. Folded in the barrier fix from Mathieu.
BUG=chromium:324025
TEST=build/boot 3.10 on squawks
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 4396e058c52e167729729cf64ea3dfa229637086)
[SR: conflicts from not having CONFIG_GENERIC_TIME_VSYSCALL_OLD code
or include/linux/timekeeping.h -- instead I moved to ktime.h]
Conflicts:
include/linux/timekeeping.h
kernel/time/timekeeping.c
Change-Id: Ib485185104a388fd63fdaaa55f0b15b4acef9a7b
Reviewed-on: https://chromium-review.googlesource.com/302846
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
For NMI safe access to clock monotonic we use the seqcount LSB as
index of a timekeeper array. The update sequence looks like this:
smp_wmb(); <- prior stores to a[1]
seq++;
smp_wmb(); <- seq increment before update of a[0]
update(a[0]);
smp_wmb(); <- update of a[0]
seq++;
smp_wmb(); <- seq increment before update of a[1]
update(a[1]);
To avoid open coded barriers, provide a helper function.
[ tglx: Split out of a combo patch against the first implementation of
the NMI safe accessor ]
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 9b0fd802e8c0545148324916055e7b40d97963fa)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I1f8bfd65661df5d556a53cc278aa2a6730c329dd
Reviewed-on: https://chromium-review.googlesource.com/300783
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
raw_read_seqcount opens a read critical section of the given seqcount
without any lockdep checking and without checking or masking the
LSB. Calling code is responsible for handling that.
Preparatory patch to provide a NMI safe clock monotonic accessor
function.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 0ea5a520f73ca31abc4c10b6d5bc14a884a0641b)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: trivial context differences]
Conflicts:
include/linux/seqlock.h
Change-Id: I828689f442b60d33c7bea7869d816afe9e94cab0
Reviewed-on: https://chromium-review.googlesource.com/300782
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
All the function needs is in the tk_read_base struct. No functional
change for the current code, just a preparatory patch for the NMI safe
accessor to clock monotonic which will use struct tk_read_base as well.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 0e5ac3a8b100469ea154f87dd57b685fbdd356f6)
[SR: conflicts from new ktime_* functions we don't have and
restructuring of ktime_get_update_offsets() function and
restructuring of get_monotonic_bootime() function]
Conflicts:
kernel/time/timekeeping.c
Change-Id: If2b0bd3c0d1e04449cb7872f00f54e434d6be8f1
Reviewed-on: https://chromium-review.googlesource.com/300781
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
timekeeper
The members of the new struct are the required ones for the new NMI
safe accessor to clcok monotonic. In order to reuse the existing
timekeeping code and to make the update of the fast NMI safe
timekeepers a simple memcpy use the struct for the timekeeper as well
and convert all users.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit d28ede83791defee9a81e558540699dc46dbbe13)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: several non-trivial differences from refactoring timekeeping.c
and vsyscall code in x86 vsyscall_64.c -> vsyscall_gtod.c]
[SR: 3.8: tile doesn't have vsyscall in 3.8 and fix up timekeeper_resume()]
Conflicts:
arch/s390/kernel/time.c
arch/tile/kernel/time.c
arch/x86/kernel/vsyscall_gtod.c
arch/x86/kvm/x86.c
include/linux/timekeeper_internal.h
kernel/time/timekeeping.c
Change-Id: Ie11521ead23722087f03e4ec3538cbdf34dc943a
Reviewed-on: https://chromium-review.googlesource.com/300780
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
timekeeping_notify() can fail due cs->enable() failure. Though the
caller does not notice and happily keeps the wrong clocksource as the
current one.
Let the caller know about failure, so the current clocksource will be
shown correctly in sysfs.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <john.stultz@linaro.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Link: http://lkml.kernel.org/r/20130425143435.696321912@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit ba919d1caa2e624eb8c6cae1f2ce0a253e697d45)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: Ic312eebae1bd2d8ea3f56931656c2ab13294e114
Reviewed-on: https://chromium-review.googlesource.com/300779
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Update wall-to-monotonic fields in the VDSO data page
unconditionally. These are used to service CLOCK_MONOTONIC_COARSE,
which is not guarded by use_syscall.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit d4022a335271a48cce49df35d825897914fbffe3)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: Iebce00f5aa1c53b7c15dc23677ee435f9c86a0f9
Reviewed-on: https://chromium-review.googlesource.com/300778
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Access to time requires to touch two cachelines at minimum
1) The timekeeper data structure
2) The clocksource data structure
The access to the clocksource data structure can be avoided as almost
all clocksource implementations ignore the argument to the read
callback, which is a pointer to the clocksource.
But the core needs to touch it to access the members @read and @mask.
So we are better off by copying the @read function pointer and the
@mask from the clocksource to the core data structure itself.
For the most used ktime_get() access all required data including the
@read and @mask copies fits together with the sequence counter into a
single 64 byte cacheline.
For the other time access functions we touch in the current code three
cache lines in the worst case. But with the clocksource data copies we
can reduce that to two adjacent cachelines, which is more efficient
than disjunct cache lines.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 6d3aadf3e180e09dbefab16478c6876b584ce16e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: fix timekeeping_resume() again due to lack of e445cf1c4]
Conflicts:
kernel/time/timekeeping.c
Change-Id: I628664f3c063144e1a4035a6ece33a59f403b77d
Reviewed-on: https://chromium-review.googlesource.com/300777
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
cycle_last was added to the clocksource to support the TSC
validation. We moved that to the core code, so we can get rid of the
extra copy.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 4a0e637738f06673725792d74eed67f8779b62c7)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: missing new code in timekeeping.c and code in vsyscall_gtod.c moved from
vsyscall_64.c]
[SR: 3.8: tile doesn't have vsyscall code in 3.8 and needed to fix up
timekeeping_resume because we don't have e445cf1c4]
Conflicts:
arch/tile/kernel/time.c
arch/x86/kernel/vsyscall_gtod.c
kernel/time/timekeeping.c
Change-Id: Icc7150363704b62ddaf3321abf1d2bd98af007e4
Reviewed-on: https://chromium-review.googlesource.com/300776
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Add a module refcount, so the current clocksource cannot be removed
unconditionally.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Link: http://lkml.kernel.org/r/20130425143435.762417789@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 09ac369c825d9d593404306d59062d854b321e9b)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I8bc3af42129ec8993db02e757aac2d750e7ee3a3
Reviewed-on: https://chromium-review.googlesource.com/300775
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Switch to the improved update_vsyscall interface that provides
sub-nanosecond precision for gettimeofday and clock_gettime.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
(cherry picked from commit 79c74ecbebf76732f91b82a62ce7fc8a88326962)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: trivial context conflict in Kconfig]
Conflicts:
arch/s390/Kconfig
Change-Id: I88661fff354edc7f8ee1f88354b3e45e3d345a48
Reviewed-on: https://chromium-review.googlesource.com/300774
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
The only user of the cycle_last validation is the x86 TSC. In order to
provide NMI safe accessor functions for clock monotonic and
monotonic_raw we need to do that in the core.
We can't do the TSC specific
if (now < cycle_last)
now = cycle_last;
for the other wrapping around clocksources, but TSC has
CLOCKSOURCE_MASK(64) which actually does not mask out anything so if
now is less than cycle_last the subtraction will give a negative
result. So we can check for that in clocksource_delta() and return 0
for that case.
Implement and enable it for x86
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 09ec54429c6d10f87d1f084de53ae2c1c3a81108)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: trivial conflict in Kconfig]
[SR: 3.10: fix conflict in timekeeping_internal.h]
[SR: 3.8: fix context conflict in tsc.c from 82f9c080]
Conflicts:
arch/x86/Kconfig
arch/x86/kernel/tsc.c
kernel/time/timekeeping_internal.h
Change-Id: Ib980b5ef4733e9f73f8c5222221ad439f8b306f6
Reviewed-on: https://chromium-review.googlesource.com/300773
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
We want to move the TSC sanity check into core code to make NMI safe
accessors to clock monotonic[_raw] possible. For this we need to
sanity check the delta calculation. Create a helper function and
convert all sites to use it.
[ Build fix from jstultz ]
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 3a97837784acbf9fed699fc04d1799b0eb742fdf)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: added timekeeping_internal.h to 3.8 in this patch and skipped
patch to timekeeping_resume because we don't have e445cf1c4]
Conflicts:
kernel/time/clocksource.c
kernel/time/timekeeping.c
kernel/time/timekeeping_internal.h
Change-Id: I1319957806100c460d48d8b09bd44ec67f1a4ef3
Reviewed-on: https://chromium-review.googlesource.com/300772
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Speed up ktime_get() by using ktime_t based data. Text size shrinks by
64 bytes on x8664.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit a016a5bd62e29a738531d9d4d925037a1fdb52f5)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: conflict due to 24e4a8c3e8 related to timespec64/2038 changes]
Conflicts:
kernel/time/timekeeping.c
Change-Id: I059234d54d9501148e3a59dee68350637922751e
Reviewed-on: https://chromium-review.googlesource.com/300771
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
The ktime_t based interfaces are used a lot in performance critical
code pathes. Add ktime_t based data so the interfaces don't have to
convert from the xtime/timespec based data.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 7c032df5570388044b4efda3d9f4d2ffb96a3116)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I27d2c32baacd4086eb8e68bb818b89842c6eb793
Reviewed-on: https://chromium-review.googlesource.com/300770
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
struct timekeeper is quite badly sorted for the hot readout path. Most
time access functions need to load two cache lines.
Rearrange it so ktime_get() and getnstimeofday() are happy with a
single cache line.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 3fdb14fd1df70325e1e91e1203a699a4803ed741)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: mostly conflicts from not having timespec64]
Conflicts:
include/linux/timekeeper_internal.h
kernel/time/timekeeping.c
Change-Id: If2af5962d354f02c5d2a6c801326456898b52918
Reviewed-on: https://chromium-review.googlesource.com/300769
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Since 48cdc135d4840 (Implement a shadow timekeeper), we have to
call timekeeping_update() after any adjustment to the timekeeping
structure in order to make sure that any adjustments to the structure
persist.
In the timekeeping suspend path, we udpate the timekeeper
structure, so we should be sure to update the shadow-timekeeper
before releasing the timekeeping locks. Currently this isn't done.
In most cases, the next time related code to run would be
timekeeping_resume, which does update the shadow-timekeeper, but
in an abundence of caution, this patch adds the call to
timekeeping_update() in the suspend path.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: stable <stable@vger.kernel.org> #3.10+
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 330a1617b0a6268d427aa5922c94d082b1d3e96d)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I5a94dffc3e9ff22658d6fae612efc7eeb003338a
Reviewed-on: https://chromium-review.googlesource.com/300768
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
In 780427f0e11 (Indicate that clock was set in the pvclock
gtod notifier), logic was added to pass a CLOCK_WAS_SET
notification to the pvclock notifier chain.
While that patch added a action flag returned from
accumulate_nsecs_to_secs(), it only uses the returned value
in one location, and not in the logarithmic accumulation.
This means if a leap second triggered during the logarithmic
accumulation (which is most likely where it would happen),
the notification that the clock was set would not make it to
the pv notifiers.
This patch extends the logarithmic_accumulation pass down
that action flag so proper notification will occur.
This patch also changes the varialbe action -> clock_set
per Ingo's suggestion.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: <xen-devel@lists.xen.org>
Cc: stable <stable@vger.kernel.org> #3.11+
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 5258d3f25c76f6ab86e9333abf97a55a877d3870)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: If36e6d46560e13d54bc6d126aecf561fe624b853
Reviewed-on: https://chromium-review.googlesource.com/300767
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Since 48cdc135d4840 (Implement a shadow timekeeper), we have to
call timekeeping_update() after any adjustment to the timekeeping
structure in order to make sure that any adjustments to the structure
persist.
Unfortunately, the updates to the tai offset via adjtimex do not
trigger this update, causing adjustments to the tai offset to be
made and then over-written by the previous value at the next
update_wall_time() call.
This patch resovles the issue by calling timekeeping_update()
right after setting the tai offset.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: stable <stable@vger.kernel.org> #3.10+
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit f55c07607a38f84b5c7e6066ee1cfe433fa5643c)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: Ifb9ff7c4111a6bf303442cade90fbeeeaace46a3
Reviewed-on: https://chromium-review.googlesource.com/300766
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
If the clock was set (stepped), set the action parameter to functions
in the pvclock gtod notifier chain to non-zero. This allows the
callee to only do work if the clock was stepped.
This will be used on Xen as the synchronization of the Xen wallclock
to the control domain's (dom0) system time will be done with this
notifier and updating on every timer tick is unnecessary and too
expensive.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: <xen-devel@lists.xen.org>
Link: http://lkml.kernel.org/r/1372329348-20841-4-git-send-email-david.vrabel@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 780427f0e113b4c77dfff4d258c05a902cdb0eb9)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I1a684a074ef9e1ceff587261fb45e6468f985408
Reviewed-on: https://chromium-review.googlesource.com/300765
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
timekeeping_update()
Instead of passing multiple bools to timekeeping_updated(), define
flags and use a single 'action' parameter. It is then more obvious
what each timekeeping_update() call does.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: <xen-devel@lists.xen.org>
Link: http://lkml.kernel.org/r/1372329348-20841-3-git-send-email-david.vrabel@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 04397fe94ad65289884b9862b6a0c722ececaadf)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I70491002c5477d54f6dd5f7b36fded884e20ba0c
Reviewed-on: https://chromium-review.googlesource.com/300764
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
commit 7bd36014460f793c19e7d6c94dab67b0afcfcb7f upstream.
Gerlando Falauto reported that when HRTICK is enabled, it is
possible to trigger system deadlocks. These were hard to
reproduce, as HRTICK has been broken in the past, but seemed
to be connected to the timekeeping_seq lock.
Since seqlock/seqcount's aren't supported w/ lockdep, I added
some extra spinlock based locking and triggered the following
lockdep output:
[ 15.849182] ntpd/4062 is trying to acquire lock:
[ 15.849765] (&(&pool->lock)->rlock){..-...}, at: [<ffffffff810aa9b5>] __queue_work+0x145/0x480
[ 15.850051]
[ 15.850051] but task is already holding lock:
[ 15.850051] (timekeeper_lock){-.-.-.}, at: [<ffffffff810df6df>] do_adjtimex+0x7f/0x100
<snip>
[ 15.850051] Chain exists of: &(&pool->lock)->rlock --> &p->pi_lock --> timekeeper_lock
[ 15.850051] Possible unsafe locking scenario:
[ 15.850051]
[ 15.850051] CPU0 CPU1
[ 15.850051] ---- ----
[ 15.850051] lock(timekeeper_lock);
[ 15.850051] lock(&p->pi_lock);
[ 15.850051] lock(timekeeper_lock);
[ 15.850051] lock(&(&pool->lock)->rlock);
[ 15.850051]
[ 15.850051] *** DEADLOCK ***
The deadlock was introduced by 06c017fdd4dc48451a ("timekeeping:
Hold timekeepering locks in do_adjtimex and hardpps") in 3.10
This patch avoids this deadlock, by moving the call to
schedule_delayed_work() outside of the timekeeper lock
critical section.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Reported-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Tested-by: Lin Ming <minggr@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: http://lkml.kernel.org/r/1378943457-27314-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 63946e8616205dafe39b4d88f9fc3dc7c4fd79aa)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I374ddc1fca8fd03d76d14e8062ee8dac65c8e530
Reviewed-on: https://chromium-review.googlesource.com/300763
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Since commit 31ade30692dc9680bfc95700d794818fa3f754ac, timekeeping_init()
checks for presence of persistent clock by attempting to read a non-zero
time value. This is an issue on platforms where persistent_clock (instead
is implemented as a free-running counter (instead of an RTC) starting
from zero on each boot and running during suspend. Examples are some ARM
platforms (e.g. PandaBoard).
An attempt to read such a clock during timekeeping_init() may return zero
value and falsely declare persistent clock as missing. Additionally, in
the above case suspend times may be accounted twice (once from
timekeeping_resume() and once from rtc_resume()), resulting in a gradual
drift of system time.
This patch does a run-time correction of the issue by doing the same check
during timekeeping_suspend().
A better long-term solution would have to return error when trying to read
non-existing clock and zero when trying to read an uninitialized clock, but
that would require changing all persistent_clock implementations.
This patch addresses the immediate breakage, for now.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
[jstultz: Tweaked commit message and subject]
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 0d6bd9953f739dad96d9a0de65383e479ab4e10d)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: Ib0480d086e88d954afd4612d8775042bb7f84ba3
Reviewed-on: https://chromium-review.googlesource.com/300762
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
commit 7ec98e15aa (timekeeping: Delay update of clock->cycle_last)
forgot to update tk->cycle_last in the resume path. This results in a
stale value versus clock->cycle_last and prevents resume in the worst
case.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Reported-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-tested-by: Borislav Petkov <bp@alien8.de>
Acked-by: John Stultz <john.stultz@linaro.org>
Cc: Linux-pm mailing list <linux-pm@lists.linux-foundation.org>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304211648150.21884@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 77c675ba18836802f6b73d2d773481d06ebc0f04)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: don't have e445cf1c4 so I adapted this for the older version of the
function that doesn't cache the value of clock->read() in variable
cycle_now]
Change-Id: I71f76a4a9c3f246a7968a3ec2120198a04578935
Reviewed-on: https://chromium-review.googlesource.com/300761
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Now that we have CLOCK_TAI timers, make sure we notify hrtimer
code when TAI offset is changed.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: John Stultz <john.stultz@linaro.org>
Link: http://lkml.kernel.org/r/1365622909-953-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 4e8f8b34b92b6514cc070aeb94d317cadd5071d7)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: Ie29ee57073ee1efce1d39f1e374b1736b2dab287
Reviewed-on: https://chromium-review.googlesource.com/300760
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Shorten the seqcount write hold region to the actual update of the
timekeeper and the related data (e.g vsyscall).
On a contemporary x86 system this reduces the maximum latencies on
Preempt-RT from 8us to 4us on the non-timekeeping cores.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit ca4523cda429712fc135c5db50920d90eb776a6c)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: Ia773616e9c47425466935b5af41fcbb760947aee
Reviewed-on: https://chromium-review.googlesource.com/300759
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Use the shadow timekeeper to do the update_wall_time() adjustments and
then copy it over to the real timekeeper.
Keep the shadow timekeeper in sync when updating stuff outside of
update_wall_time().
This allows us to limit the timekeeper_seq hold time to the update of
the real timekeeper and the vsyscall data in the next patch.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 48cdc135d4840aab8efd2fc3bacb5d7dfd94a9c8)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I037ba87fda6cab98e7acdd486cc253518052e693
Reviewed-on: https://chromium-review.googlesource.com/300758
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
For calculating the new timekeeper values store the new cycle_last
value in the timekeeper and update the clock->cycle_last just when we
actually update the new values.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 7ec98e15aa049b7a2ca73485f31cf4f90c34e2dd)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: Ie4a58e6c14d90da2328b872fd749e2f73ddb2c8a
Reviewed-on: https://chromium-review.googlesource.com/300757
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
For implementing a shadow timekeeper and a split calculation/update
region we need to store the cycle_last value in the timekeeper and
update the value in the clocksource struct only in the update region.
Add the extra storage to the timekeeper.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 14a3b6abe98c8f53a13522610c257accef7321df)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I4603ca2760aa5ae2a101a00621c1ebc499ea8f50
Reviewed-on: https://chromium-review.googlesource.com/300756
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Since we are taking the timekeeping locks, just go ahead
and update any tai change directly, rather then dropping
the lock and calling a function that will just take it again.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 0b5154fb9040cca94e7d9893384c0e78bfe2d296)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: Ieb4885ce44f4d381b7f208a6f3862f334df5e920
Reviewed-on: https://chromium-review.googlesource.com/300755
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
In moving the NTP state to be protected by the timekeeping locks,
be sure to acquire the timekeeping locks prior to calling
ntp functions.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 06c017fdd4dc48451a29ac37fc1db4a3f86b7f40)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I2ee60cfe2a7c15981606083b23ff557845b963d2
Reviewed-on: https://chromium-review.googlesource.com/300754
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Since ADJ_SETOFFSET adjusts the timekeeping state, process
it as part of the top level do_adjtimex() function in
timekeeping.c.
This avoids deadlocks that could occur once we change the
ntp locking rules.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit cef90377fab488bd1f959efda178fb83250cf61d)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I43a9d63862adb100b089068123fe240f6c70829e
Reviewed-on: https://chromium-review.googlesource.com/300753
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
In order to change the locking rules, we need to provide
the timespec and tai values rather then having the ntp
logic acquire these values itself.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 87ace39b7168bd9d352c1c52b6f5d88eb1876cf8)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I2847af458dc24ac9fcf3d46ec3ba687da05dc69b
Reviewed-on: https://chromium-review.googlesource.com/300752
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
seconds_overflow() is called from hard interrupt context even on
Preempt-RT. This requires the lock to be a raw_spinlock.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit a6c0c943a15d0b3d6ac33760cb8f95c75f395895)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I1cd542a23dd5c4cbe05bb78f427441ef5346d836
Reviewed-on: https://chromium-review.googlesource.com/300751
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Move logic that does not need the ntp state to be done
in the timekeeping do_adjtimex() call.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit e4085693f629ded8ac8c35b5cdd324d20242990b)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: If05e612c4b43920aa64715b84d90196741c3f385
Reviewed-on: https://chromium-review.googlesource.com/300750
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
In preparation for changing the ntp locking rules, move
do_adjtimex and hardpps accessor functions to timekeeping.c,
but keep the code logic in ntp.c.
This patch also introduces a ntp_internal.h file so timekeeping
specific interfaces of ntp.c can be more limitedly shared with
timekeeping.c.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit aa6f9c595d857328e5d815e5b94c0e7cd31a6b59)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: I60910c1f4ea8cffbecb58cfe594d9b887892e651
Reviewed-on: https://chromium-review.googlesource.com/300749
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Split out the timex validation done in do_adjtimex into a separate
function. This will help simplify logic in following patches.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit ad460967a2953496ad76b1c22091ea99f21b4e86)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: Ib5ad8697cffb5f0486b6ef3b8795b028b67e3715
Reviewed-on: https://chromium-review.googlesource.com/300748
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Yet again, the kbuild test robot saves the day, noting
I left out defining __timekeeping_set_tai_offset as
static. It even sent me this patch.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit dd5d70e869f960bde6376f4447fff59f16186cf5)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Change-Id: If59339cb8702069429e8ba6b567ba0f6dc7c4453
Reviewed-on: https://chromium-review.googlesource.com/300747
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
We want to shorten the seqcount write hold time. So split the seqlock
into a lock and a seqcount.
Open code the seqwrite_lock in the places which matter and drop the
sequence counter update where it's pointless.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[jstultz: Merge fixups from CLOCK_TAI collisions]
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 9a7a71b1d0968fc2bd602b7481cde1d4872e01ff)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: missing CLOCK_TAI stuff in 3.8]
Change-Id: I8976692f1b517ee23065ca82543de37458205846
Reviewed-on: https://chromium-review.googlesource.com/300746
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Make the lock a separate entity. Preparatory patch for shadow
timekeeper structure.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[Merged with CLOCK_TAI changes]
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 7e40672d930b369c1984457233ec5557aa53bfb8)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: missing CLOCK_TAI stuff in 3.8]
Change-Id: I6caa38374063fcb6ca4051082fd2453984321c97
Reviewed-on: https://chromium-review.googlesource.com/300745
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Nothing outside of the timekeeping core needs that lock.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit eb93e4d93093615c60cb7dd3dcb24e46bd7d62d4)
Signed-off-by: Sonny Rao <sonnyrao@google.com>
Change-Id: I525c1b0b2b9b8793c459bb5a51ffbe6cc2846d4b
Reviewed-on: https://chromium-review.googlesource.com/300742
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Calculate the cycle interval shifted value once. No functional change,
just makes the code more readable.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 23a9537a6999fce16f06ca61fc6cac52c8fbdc86)
Signed-off-by: Sonny Rao <sonnyrao@google.com>
Change-Id: I538953ca62ab453c9fb475870b439cb07d9f62fc
Reviewed-on: https://chromium-review.googlesource.com/300741
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Currently NTP manages the TAI offset. Since there's plans for a
CLOCK_TAI clockid, push the TAI management into the timekeeping
core.
BUG=chromium:324025
TEST=build/boot 3.8 on link
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit cc244ddae6d4c6902ac9d7d64023534f8c44a7eb)
Signed-off-by: Sonny Rao <sonnyrao@google.com>
Change-Id: I956705435141c2a32accb68637f9d31d6f411072
Reviewed-on: https://chromium-review.googlesource.com/300740
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
In current kernel, there are several places which need to check
whether there is a persistent clock for the platform. Current check
is done by calling the read_persistent_clock() and validating its
return value.
So one optimization is to do the check only once in timekeeping_init(),
and use a flag persistent_clock_exist to record it.
v2: Add a has_persistent_clock() helper function, as suggested by John.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 31ade30692dc9680bfc95700d794818fa3f754ac)
Signed-off-by: Sonny Rao <sonnyrao@google.com>
Change-Id: Iea1365a1ba0ab5038f9dfe198280ba418f2441ef
Reviewed-on: https://chromium-review.googlesource.com/300598
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
The pstore RAM backend can get called during resume, and must be defensive
against a suspended time source. Expose getnstimeofday logic that returns
an error instead of a WARN. This can be detected and the timestamp can
be zeroed out.
BUG=chromium:324025
TEST=build/boot 3.8 on link
Reported-by: Doug Anderson <dianders@chromium.org>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 1e817fb62cd185a2232ad4302579491805609489)
Signed-off-by: Sonny Rao <sonnyrao@google.com>
Change-Id: Ib5d063e449a30867c528ec96d5a1761f4bca46e2
Reviewed-on: https://chromium-review.googlesource.com/300597
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
|
|
space."
CQ-DEPEND=CL:303497
BUG=chromium:324025
TEST=build/boot 3.8 on link
This reverts commit 8cea67ed158537c3d6cdd8ad01c4ee73bd2dbcf7.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: trivial, conflicted with 0c3b86472c trace: allow ftrace to be
disabled/enabled per cpu]
Conflicts:
include/linux/kernel.h
Change-Id: Iad71fd4557de16ec4f97b8f896237d01ec8d3f94
Reviewed-on: https://chromium-review.googlesource.com/300596
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
|
|
Changes from kernel repo may affect everything, so add subsystem:all to
kernel repo to skip the subsystem logic.
BUG=None
TEST=None
Change-Id: Ie8133fc29017885e126fa7cda773bfd91fad7515
Reviewed-on: https://chromium-review.googlesource.com/303742
Commit-Ready: Shuqian Zhao <shuqianz@chromium.org>
Tested-by: Shuqian Zhao <shuqianz@chromium.org>
Reviewed-by: Aviv Keshet <akeshet@chromium.org>
|
|
Add device quirk for Logitech PTZ Pro Camera and its sibling the
ConferenceCam CC3000e Camera.
This fixes the failed camera enumeration on some boot, particularly on
fast Haswell Core i7 Chromeboxes.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chromium:533608
TEST=Connect a Logitech PTZ Pro Camera to Panther i7 SKU, and do some
reboot testing while recording the kernel logs and taking camera
picture after each boot. Before the patch, more than 7% of the boots
(over thousand iterations) show some enumeration (and in a few of them, the
kernel is giving up before actually enumerating the webcam. After the
patch, the enumeration is correct on every reboot.
Change-Id: I551b2e10dc3196db1542b98fca15920a191c0f4a
Reviewed-on: https://chromium-review.googlesource.com/303172
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
success_ratio is actually 128 * SR in percentage while
IWL_MVM_RS_SR_NO_DECREASE is 85%. Fix this by using RS_PERCENT().
This bug caused the if branch to be always executed. This in turn
led to always selecting a rate, following a column switch, in which
the expected throughput would exceed the best expected current throughput.
In some scenarios where the success ratio isn't >85% such a rate
could be too aggressive leading us to avoid the new column.
This has the potential of causing sub optimal performance.
BUG=N/A
TEST=difficult to test, code observation
Change-Id: Ib5abd422e48ddff31115ae17d02b4331ab1d52a3
Reported-by: Moshe Harel <moshe.harel@intel.com>
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/303600
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
|
|
If an active DRM-Master closes its device, we deauthenticate all clients
on that master. However, if an inactive DRM-Master closes its device, we
do nothing. This is quite inconsistent and breaks several scenarios:
1) If this was used as security mechanism, it fails horribly if a master
closes a device while VT switched away. Furthermore, none of the few
drivers using ->master_*() callbacks seems to require it, anyway.
2) If you spawn weston (or any other non-UMS compositor) in background
while another compositor is active, both will get assigned to the
same "drm_master" object. If the foreground compositor now exits, all
clients of both the foreground AND background compositor will be
de-authenticated leading to unexpected behavior.
Stop this non-sense and keep clients authenticated. We don't do this when
dropping DRM-Master (i.e., switching VTs) so don't do it on active-close
either!
BUG=chromium:535334
TEST=run graphics_SanAngeles on Rambi or Squawks
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
(cherry picked from commit 3cb01a980461506f9ec4e4e1dc2dab6314236fb7)
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Conflicts:
drivers/gpu/drm/drm_fops.c
include/drm/drmP.h
Change-Id: I97b33ab56e658122050c2ef814eceafedab7eb0d
(cherry picked from commit 7fd5f2ea2c2a0eaad5e68e081684bf90853734cd)
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/303543
Reviewed-by: Ilja Friedel <ihf@chromium.org>
Reviewed-by: Haixia Shi <hshi@chromium.org>
|
|
According to Intel SNB HW has an issue with dereferencing resources
correctly through PPGTT space, which causes HW to read through GGTT
when it wasn't supposed to.
BUG=chromium:521249
TEST=follow bug report and verify that GPU hang no longer happens
Signed-off-by: Haixia Shi <hshi@chromium.org>
Change-Id: I53bfdaa9f00fc2f047b111415514251a8b98af36
Reviewed-on: https://chromium-review.googlesource.com/302850
Commit-Ready: Haixia Shi <hshi@chromium.org>
Tested-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Sean V Kelley <sean.v.kelley@intel.com>
|
|
If there are no supported rates in the rate mask with the required
flags, we warn, but it's not clear which part causes the warning.
Add the relevant data to the warning to understand why it happens.
BUG=chrome-os-partner:44539
TEST=N/A, debug patch
Change-Id: Ibdff2007da55051047767fbb27dd019a7af2a17f
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/301911
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
|
|
This NULL pointer dereference is observed during suspend resume
stress test. All pending commands are cancelled when system goes
into suspend state. There a corner case in which host may receive
response for last scan command after this and try to trigger extra
active scan for hidden SSIDs.
The issue is fixed by adding a NULL check to skip that extra scan.
Fixes: 2375fa2b36feaf34 (mwifiex: fix unable to connect hidden SSID..)
Signed-off-by: Aniket Nagarnaik <aniketn@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
BUG=chrome-os-partner:45042
TEST=We could recreate the crash after 100-150 iterations of suspend
stress test on Lucas2. Test successfully completed 10000 iterations
after this fix
Change-Id: I3030c665250eef5307d2dee596eb959ba6292bc8
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/301491
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
|
|
This NULL pointer dereference is observed during suspend resume
stress test. All pending commands are cancelled when system goes
into suspend state. There a corner case in which host may receive
response for last scan command after this and try to trigger extra
active scan for hidden SSIDs.
The issue is fixed by adding a NULL check to skip that extra scan.
Fixes: 2375fa2b36feaf34 (mwifiex: fix unable to connect hidden SSID..)
Signed-off-by: Aniket Nagarnaik <aniketn@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
BUG=chrome-os-partner:45042
TEST=We could recreate the crash after 100-150 iterations of suspend
stress test on Lucas2. Test successfully completed 10000 iterations
after this fix
Change-Id: I3f03bf7a535beb396c9584a84e4a97d4345a2d3d
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/301222
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
|
|
I'm working on address sanitizer project for kernel. Recently we
started experiments with stack instrumentation, to detect out-of-bounds
read/write bugs on stack.
Just after booting I've hit out-of-bounds read on stack in idr_for_each
(and in __idr_remove_all as well):
struct idr_layer **paa = &pa[0];
while (id >= 0 && id <= max) {
...
while (n < fls(id)) {
n += IDR_BITS;
p = *--paa; <--- here we are reading pa[-1] value.
}
}
Despite the fact that after this dereference we are exiting out of loop
and never use p, such behaviour is undefined and should be avoided.
Fix this by moving pointer derference to the beggining of the loop,
right before we will use it.
BUG=chromium:534863
TEST=boot 3.8 on link
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Reviewed-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Alexey Preobrazhensky <preobr@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 93b7aca35dd7bf0c3ba7ea0542b556bcfdb28e76)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: 3.8: non-trivial conflicts due to some missing idr patches like
326cf0f0 idr: fix top layer handling]
Conflicts:
lib/idr.c
Change-Id: Ica9026f3490c182841431da146d934d23e1eeb35
Reviewed-on: https://chromium-review.googlesource.com/301594
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Alexander Potapenko <glider@chromium.org>
|
|
Adds support for decoding 411 subsampling format.
BUG=chrome-os-partner:40139
TEST=Run the jpeg test with images with 411 subsampling and
see decoded image generated correctly.
Change-Id: Ia802cc06aa581f909e3c267090eb4a8b05378f8f
Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/289751
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Heng-ruey Hsu <henryhsu@chromium.org>
|
|
Corrects the WARN_ON statement for subsampling based on the
JPEG Hardware version.
BUG=chrome-os-partner:40139
TEST=Run the jpeg test with 411 subsampling and see decoded image
is correctly generated.
Change-Id: Idc64162f64c02bf3255a34df4aa9cd5f39e54afc
Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/289750
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Heng-ruey Hsu <henryhsu@chromium.org>
|
|
The last argument of vb2_dc_get_user_pages() is of type enum
dma_data_direction, but the caller, vb2_dc_get_userptr() passes a value
which is the result of comparison dma_dir == DMA_FROM_DEVICE. This results
in the write parameter to get_user_pages() being zero in all cases, i.e.
that the caller has no intent to write there.
This was broken by patch "vb2: replace 'write' by 'dma_dir'".
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
(am from https://patchwork.linuxtv.org/patch/28210)
Signed-off-by: Pawel Osciak <posciak@chromium.org>
BUG=None
TEST=vdatest
Reviewed-on: https://chromium-review.googlesource.com/250722
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Pawel Osciak <posciak@chromium.org>
Trybot-Ready: Pawel Osciak <posciak@chromium.org>
(cherry picked from commit 85945c6644201d86aad10b28db6a01174d0cb732)
BUG=chromium:426383
TEST=mjpeg stand alone test with iommu
Change-Id: I1642f89703e00587ac5a7e871dd20c595d36cbaf
Signed-off-by: Heng-Ruey Hsu <henryhsu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299597
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Heng-ruey Hsu <henryhsu@chromium.org>
|
|
The code to send the RX PN data (for each TID) to the firmware
has a devastating bug: it overwrites the data for TID 0 with
all the TID data, leaving the remaining TIDs zeroed. This will
allow replays to actually be accepted by the firmware, which
could allow waking up the system.
BUG=N/A
TEST=attempt to replay wakeup packet while in suspend
Change-Id: I5eb36646e89afe62007ef733cf47fd553c87eb3f
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/300645
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
|
|
multitouch
Fields like HID_DG_CONTACTCOUNT are outside of the physical collection,
but within the application collection and report ID. Make sure to catch
those fields that are not part of the mt_report_id and return 0 so they
can be processed with the pen. Otherwise, the wrong HID_DG_CONTACTCOUNT
will be applied to cc_index and result in dereferencing a null pointer in
mt_touch_report.
backport from git.kernel.org commit 1cc1cc92c4c4891abc48a777fb9fbc69077d5673
BUG=chromium:485103
TEST=Backport commit above, compiled board=link and tested.
Change-Id: Ic16ce2358a37c3ae40c42f63bdf36a07dd24c013
Signed-off-by: Brent Adam <brentadam@smarttech.com>
Reviewed-on: https://chromium-review.googlesource.com/301120
Reviewed-by: Michael Spang <spang@chromium.org>
|
|
The fix for deadlock in PM in commit [1ee23fe07ee8: ALSA: usb-audio:
Fix deadlocks at resuming] introduced a new check of in_pm flag.
However, the brainless patch author evaluated it in a wrong way
(logical AND instead of logical OR), thus usb_autopm_get_interface()
is wrongly called at probing, leading to unbalance of runtime PM
refcount.
This patch fixes it by correcting the logic.
Reported-by: Hans Yang <hansy@nvidia.com>
Fixes: 1ee23fe07ee8 ('ALSA: usb-audio: Fix deadlocks at resuming')
Cc: <stable@vger.kernel.org> [v3.15+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
BUG=chrmoium:530829
BUG=chromium:520917
TEST=None
Change-Id: I1d50fc84105c2245ecc3c58eb9e8216ee243938f
Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299667
Commit-Ready: Hsinyu Chao <hychao@chromium.org>
Tested-by: Hsinyu Chao <hychao@chromium.org>
Reviewed-by: Cheng-Yi Chiang <cychiang@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
|
|
The recent addition of the USB audio mixer suspend/resume may lead to
deadlocks when the driver tries to call usb_autopm_get_interface()
recursively, since the function tries to sync with the finish of the
other calls. For avoiding it, introduce a flag indicating the resume
operation and avoids the recursive usb_autopm_get_interface() calls
during the resume.
Reported-and-tested-by: Bryan Quigley <gquigs@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
BUG=chrmoium:530829
BUG=chromium:520917
TEST=None
Change-Id: If6600fdf05a9e526c27bb971625f6cc516acac93
Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299666
Commit-Ready: Hsinyu Chao <hychao@chromium.org>
Tested-by: Hsinyu Chao <hychao@chromium.org>
Reviewed-by: Cheng-Yi Chiang <cychiang@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
|
|
Adds logic for parsing for Huffman Table in the JPEG header.
BUG=chrome-os-partner:40139
TEST=Run the jpeg test with images with and without jpeg header.
See that the driver returns error back to userspace in case of
missing header.
Change-Id: I593e0f76aaa8a9587b6ec21b0caf01e40d018940
Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/288231
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Heng-ruey Hsu <henryhsu@chromium.org>
|
|
In commit 9276c17 "CHROMIUM: input: Add "inhibited" property for input
devices", input_inhibit() and input_uninhibit() were added without
event_lock spinlock protection and without interrupt disabled, when
calling input_dev_release_keys() which expects them.
input_dev_release_keys() will call the .events() callback in evdev.c
which also expects interrupt is already disabled. Since the .events()
callback in evdev.c holds buffer_lock in evdev_pass_values() which may
be acquired in hardirq context, lockdep will complain when userspace
tries to do "echo 1 > /sys/devices/gpio-keys/input/inputX/inhibited"
which will acquire this same buffer_lock when interrupt is still
enabled.
Fix by adding spin_lock_irqsave/spin_unlock_irqrestore in both
functions. This will fix the following 2 lockdep complaint:
[ INFO: inconsistent lock state ]
3.18.0-06881-g540102b #1 Tainted: G U W
---------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
PhotonicModulat/583 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&(&client->buffer_lock)->rlock){?.....}, at: [<ffffffc000796538>] evdev_pass_values+0x70/0x190
{IN-HARDIRQ-W} state was registered at:
[<ffffffc000257ddc>] mark_lock+0x2dc/0x6a8
[<ffffffc000259ee0>] __lock_acquire+0x8c8/0x191c
[<ffffffc00025b6b8>] lock_acquire+0xec/0x128
[<ffffffc000a8a798>] _raw_spin_lock+0x2c/0x44
[<ffffffc000796534>] evdev_pass_values+0x6c/0x190
[<ffffffc0007968e8>] evdev_events+0xb0/0xe8
...
irq event stamp: 35847
hardirqs last enabled at (35847): [<ffffffc000278e6c>] ktime_mono_to_any+0x84/0xc8
hardirqs last disabled at (35846): [<ffffffc000278e28>] ktime_mono_to_any+0x40/0xc8
softirqs last enabled at (35840): [<ffffffc000220b78>] __do_softirq+0x2b4/0x330
softirqs last disabled at (35825): [<ffffffc000220e98>] irq_exit+0x74/0xd0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&client->buffer_lock)->rlock);
<Interrupt>
lock(&(&client->buffer_lock)->rlock);
*** DEADLOCK ***
Call trace:
...
[<ffffffc000a8a798>] _raw_spin_lock+0x2c/0x44
[<ffffffc000796534>] evdev_pass_values+0x6c/0x190
...
[<ffffffc00079064c>] input_dev_release_keys+0x7c/0xc4
[<ffffffc000790778>] input_dev_store_inhibited+0x60/0x104
and
[ INFO: possible irq lock inversion dependency detected ]
3.18.0-06881-g540102b #1 Tainted: G U W
---------------------------------------------------------
kworker/0:5/2661 just changed the state of lock:
(&(&dev->event_lock)->rlock){-.....}, at: [<ffffffc000790ee8>] input_event+0x40/0x74
but this lock took another, HARDIRQ-unsafe lock in the past:
(&(&client->buffer_lock)->rlock){+.+...}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&(&client->buffer_lock)->rlock);
local_irq_disable();
lock(&(&dev->event_lock)->rlock);
lock(&(&client->buffer_lock)->rlock);
<Interrupt>
lock(&(&dev->event_lock)->rlock);
*** DEADLOCK ***
Call trace:
...
[<ffffffc000a8a7ec>] _raw_spin_lock_irqsave+0x3c/0x58
[<ffffffc000790ee4>] input_event+0x3c/0x74
...
[<ffffffc000734e88>] usb_hcd_giveback_urb+0x38/0xe4
[<ffffffc000762ef0>] xhci_irq+0x1080/0x1234
BUG=none
TEST=test with usb mouse and suspend/resume for few loops, no more
lockdep warnings seen in kernel
Change-Id: I97fd08d661daa55b9adc18fa5eb14d98a50984a9
Signed-off-by: Mark Kuo <mkuo@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/297686
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
(cherry picked from commit 7453d62c571745da22153b1021103b4e43fcddb4)
Reviewed-on: https://chromium-review.googlesource.com/299535
Commit-Ready: Dmitry Torokhov <dtor@chromium.org>
Tested-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
|
|
The check of cval->cached should be zero-based (including master channel).
Signed-off-by: Yao-Wen Mao <yaowen@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 6aa6925cad06159dc6e25857991bbc4960821242)
Signed-off-by: Yao-Wen Mao <yaowen@google.com>
BUG=chromium:520917
TEST=None
Change-Id: Ie094fc0661f7347cc4207b1b800369263777de9f
Reviewed-on: https://chromium-review.googlesource.com/298791
Commit-Ready: Yao-Wen Mao <yaowen@google.com>
Tested-by: Yao-Wen Mao <yaowen@google.com>
Reviewed-by: Hsinyu Chao <hychao@chromium.org>
|
|
Implement reset_resume callback so that the mixer values are properly
restored. Still no boot quirks are called, so it might not work well
on some devices.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 6a4fd914069a65143e176de24c6fca421ac77e17)
Signed-off-by: Yao-Wen Mao <yaowen@google.com>
BUG=chromium:520917
TEST=None
Change-Id: I32006a1134f85be6744259dbeab01effc0b37dae
Reviewed-on: https://chromium-review.googlesource.com/298790
Commit-Ready: Yao-Wen Mao <yaowen@google.com>
Tested-by: Yao-Wen Mao <yaowen@google.com>
Reviewed-by: Hsinyu Chao <hychao@chromium.org>
|
|
This event indicates that the video device has encountered a
pixelformat change during runtime. This event can be detected by a
decoder or a capture device.
Take decoder for example, input pixelformat change may affect
output format change.
This needs to be notified to the userspace and the application must
be expected to get format and reallocate buffers before proceeding.
If multiple events occurred before application could dequeue them,
then the changes will have the ORed value of all the events generated.
BUG=chromium:426383
TEST=build kernel and pass
Change-Id: Idb3f74adb662a4f897fb4323ab72e162d063f76a
Signed-off-by: Henry-Ruey Hsu <henryhsu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/294147
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
|
|
This reverts commit c4652416d7e75df41f6170912458f9109366bc10.
Conflicts:
include/uapi/linux/videodev2.h
BUG=chromium:409725
TEST=build kernel and pass
Change-Id: I3d28555e3ee2cb8d5ddabcd1a90ca906831302ed
Signed-off-by: Heng-Ruey Hsu <henryhsu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/294389
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
|
|
We remove it since no platform in 3.8 uses this driver.
go2001 is used in 3.14 kernel version.
BUG=chromium:409725
TEST=buidl kernel and pass
CQ-DEPEND=CL:296903
Change-Id: Ia107d5d9f8bcad176e02071a79fbc6e6c849b8d9
Signed-off-by: Heng-Ruey Hsu <henryhsu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/296861
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Remove GO2001 since no platform in 3.8 use this.
BUG=chromium:409725
TEST=build kernel and pass
Change-Id: I7f36e6419e55980d85ab5d52e09071a472485f64
Signed-off-by: Heng-Ruey Hsu <henryhsu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/296903
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Queued frames aren't processed during scan, which results in an inability
to complete the BA session establishment until the scan ends. Since we
can't tx frames until the BA agreement setup is complete, it might result
in a very large latency during scan.
Fix this by allowing to process queued skbs while scanning in HW. This
should be ok since the devices which support hw scan should be able
to handle tx/rx while scanning.
During SW scan, mac80211 drops any txed frames besides probes and NDPs,
so it is still needed to delay processing of the queued frames till the
SW scan is done.
BUG=chrome-os-partner:37530
TEST=network_WiFi_OverlappingBSSScan
Change-Id: Icce3b9584b806cd33b3471d09dac3d2da9619c73
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/297486
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
|
|
Currently, when trying to connect to already paired device that just
rotated its RPA MAC address, old address would be used and connection
would fail. In order to fix that, kernel must scan and receive
advertisement with fresh RPA before connecting.
This patch enables new connection establishment procedure. Instead of just
sending HCI_OP_LE_CREATE_CONN to controller, "connect" will add device to
kernel whitelist and start scan. If advertisement is received, it'll be
compared against whitelist and then trigger connection if it matches.
That fixes mentioned reconnect issue for already paired devices. It also
make whole connection procedure more robust. We can try to connect to
multiple devices at same time now, even though controller allow only one.
BUG=chromium:495402
TEST='connect <MAC_ADDR>' in bluetoothctl console
(cherry-picked from commit fa1422207756833096b54356a539e3a7d7edec4f from
repo git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git)
Change-Id: I9fde9e43a696d1f598c83df3a98d458cc700d9f2
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-on: https://chromium-review.googlesource.com/292731
Commit-Ready: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Tested-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Reviewed-by: Arman Uguray <armansito@chromium.org>
Reviewed-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
|
|
Currently, when trying to connect to already paired device that just
rotated its RPA MAC address, old address would be used and connection
would fail. In order to fix that, kernel must scan and receive
advertisement with fresh RPA before connecting.
This patch makes sure that when new procedure is in use, and we're stuck
in scan phase because no advertisement was received and timeout happened,
or app decided to close socket, scan whitelist gets properly cleaned up.
BUG=chromium:495402
TEST='connect <MAC_ADDR>' in bluetoothctl console
(cherry-picked from commit cc2b6911a205b327b29c1d771925f8ab2f80295f from
repo git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git)
Change-Id: I5c7881d40d07243f660519a196797a081bbf07b4
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-on: https://chromium-review.googlesource.com/292730
Commit-Ready: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Tested-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Reviewed-by: Arman Uguray <armansito@chromium.org>
Reviewed-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
|
|
Currently, when trying to connect to already paired device that just
rotated its RPA MAC address, old address would be used and connection
would fail. In order to fix that, kernel must scan and receive
advertisement with fresh RPA before connecting.
This path makes sure that after advertisement is received from device that
we try to connect to, it is properly handled in check_pending_le_conn and
trigger connect attempt.
It also modifies hci_le_connect to make sure that connect attempt will be
properly continued.
BUG=chromium:495402
TEST='connect <MAC_ADDR>' in bluetoothctl console
(cherry-picked from commit 28a667c9c279df5a6467842ee2b3b73ddf874732 from
repo git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git)
Change-Id: I3553250584157d27f441c8aadf618c010a37b24b
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-on: https://chromium-review.googlesource.com/292479
Commit-Ready: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Tested-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Reviewed-by: Arman Uguray <armansito@chromium.org>
Reviewed-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
|
|
Currently, when trying to connect to already paired device that just
rotated its RPA MAC address, old address would be used and connection
would fail. In order to fix that, kernel must scan and receive
advertisement with fresh RPA before connecting.
This patch adds hci_connect_le_scan with dependencies, new method that
will be used to connect to remote LE devices. Instead of just sending
connect request, it adds a device to whitelist. Later patches will make
use of this whitelist to send conenct request when advertisement is
received, and properly handle timeouts.
BUG=chromium:495402
TEST='connect <MAC_ADDR>' in bluetoothctl console
(cherry-picked from commit f75113a26008980ca13834fb6573145523596776 from
repo git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git)
Change-Id: I862c04cd7698b93b55e36d9094d5e5df3787850f
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-on: https://chromium-review.googlesource.com/292478
Commit-Ready: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Tested-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Reviewed-by: Arman Uguray <armansito@chromium.org>
Reviewed-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
|
|
This patch adds hci_lookup_le_connect method, that will be used to check
wether outgoing le connection attempt is in progress.
BUG=chromium:495402
TEST='connect <MAC_ADDR>' in bluetoothctl console
(cherry-picked from commit e7d9ab731ac7babaf2e1b7b5e2280f5f555d263f from
repo git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git)
Change-Id: Ibe6a9f6fe03c20057c146d0657187d0465ed103c
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-on: https://chromium-review.googlesource.com/292477
Commit-Ready: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Tested-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Reviewed-by: Arman Uguray <armansito@chromium.org>
Reviewed-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
|
|
Currently, when trying to connect to already paired device that just
rotated its RPA MAC address, old address would be used and connection
would fail. In order to fix that, kernel must scan and receive
advertisement with fresh RPA before connecting.
This patch adds some fields to hci_conn_params, in preparation to new
connect procedure.
explicit_connect will be used to override any current auto_connect action,
and connect to device when ad is received.
HCI_AUTO_CONN_EXPLICIT was added to auto_connect enum. When this value
will be used, explicit connect is the only action, and params can be
removed after successful connection.
HCI_CONN_SCANNING is added to hci_conn flags. When it's set, connect is
scan phase. It gets cleared when advertisement is received, and
HCI_OP_LE_CREATE_CONN is sent.
BUG=chromium:495402
TEST='connect <MAC_ADDR>' in bluetoothctl console
(cherry-picked from commit 158e92185075184ebc5f25bab61fdd598693e28d from
repo git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git)
Change-Id: I16f9585961aaa1ec299ecb326100782b1e03a8b9
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-on: https://chromium-review.googlesource.com/292476
Commit-Ready: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Tested-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Reviewed-by: Arman Uguray <armansito@chromium.org>
Reviewed-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
|
|
method
Move IRK checking logic in preparation to new connect method. Also
make sure that MGMT_STATUS_INVALID_PARAMS is returned when non
identity address is passed to ADD_DEVICE. Right now MGMT_STATUS_FAILED
is returned, which might be misleading.
BUG=chromium:495402
TEST='connect <MAC_ADDR>' in bluetoothctl console
(cherry-picked from commit 9a0a8a8e852dabeda848baafac19627cb469d5e9 from
repo git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git)
Change-Id: I32ba8469350475b2045c2be177e3941d5dccaec4
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/292475
Commit-Ready: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Tested-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
Reviewed-by: Arman Uguray <armansito@chromium.org>
Reviewed-by: Jakub x Jakub Pawlowski <jpawlowski@chromium.org>
|
|
We will check if any hidden SSID found in passive scan channels
and do specific SSID active scan for those channels.
Signed-off-by: chunfan chen <jeffc@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/294060
Reviewed-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:40751
TEST=On Peach-Pit, ran tests to confirm we can successfully connect
to hidden AP on DFS/passive channels. No regressions seen
for auto tests.
Change-Id: I83026b3fab84c43b69bb260dcf6cf76dd0b8f46f
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/296466
Reviewed-by: Paul Stewart <pstew@chromium.org>
|
|
Newer versions of udev require this. It has very little overhead:
- CONFIG_FHANDLE is used to build fs/fhandle.c
- it enables CONFIG_EXPORTFS
- CONFIG_EXPORTFS is used to build fs/exportfs/expfs.c
In total, it adds <4KB .text and <1KB .data on an x86_64 build.
Security wise, it exposes two new syscalls:
- name_to_handle_at
- open_by_handle_at
BUG=chromium:455336
TEST=precq passes
Change-Id: I48735b797d2e5aecf60b03cc6cf04b82e37f1e70
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/296100
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
|
|
This reverts commit 5b5d27f04e378890cc7c188d8a03416d5aec5200.
BUG=chromium:499817
Change-Id: I3cbbe4db8d605110aa62084a9c6f2a4855bbe701
Reviewed-on: https://chromium-review.googlesource.com/296601
Commit-Ready: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
|
|
This reverts commit d2bed66bdaafd05d1db475370d2e94e6ade3a23c.
BUG=chromium:499817
Change-Id: I04bfe1cb98ecead617dc6c09e9c4bbab778b69a2
Reviewed-on: https://chromium-review.googlesource.com/296584
Commit-Ready: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
|
|
registration"
This reverts commit 61d4dc150714cdfda0aa7c930f09751dbbc362a1.
BUG=chromium:499817
Change-Id: Ifebc987471a51b9ce5dbbddf19dae1e61dab396d
Reviewed-on: https://chromium-review.googlesource.com/296591
Commit-Ready: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
|
|
This commit reverted two commits and add support for resolution change
event for new definition from upstream.
When a resolution change point is reached, queue an event to signal the
userspace that a new set of buffers is required before decoding can
continue.
Revert "CHROMIUM: [media] s5p-mfc: Send event after resolution change is processed"
This reverts commit f95e1b0aaa092ced021605ff1f27bc56f5bb56b7.
Revert "CHROMIUM: s5p-mfc: add support for resolution change event"
This reverts commit 7a18d9c61e617e09f3c6b8a6688d20042667ba1a.
BUG=chromium:409725
TEST=build kernel and pass onm peach_pi board. Play video with
resolution change and make sure events are posted from driver.
Change-Id: Ib50c978ba5c60da5ed128c8a8a3d9fba4437d1b8
Signed-off-by: Heng-Ruey Hsu <henryhsu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/294212
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
|
|
This event indicates that the video device has encountered
a source parameter change during runtime. This can typically be a
resolution change detected by a video decoder OR a format change
detected by an input connector.
This needs to be nofified to the userspace and the application may
be expected to reallocate buffers before proceeding. The application
can subscribe to events on a specific pad or input port which
it is interested in.
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
(cherry picked from commit 3cbe6e5bcad0b102c06b9c6029fda75630045475)
Conflicts:
drivers/media/v4l2-core/v4l2-event.c
include/media/v4l2-event.h
BUG=chromium:409725
TEST=build kernel and pass
Change-Id: I958a9b65de96af89bacef32dd7d49afb9307ce58
Signed-off-by: Heng-Ruey Hsu <henryhsu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/294039
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
|
|
The bit was not according to ieee80211 specification.
Fix that.
BUG=N/A
TEST=N/A
Change-Id: Ic43d0a507e81fce49d2186aa479ff1f7ea661617
Reviewed-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/294724
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
EAC release of the r6p0-02rel0 version of this part:
TX011-SW-99002
The chromebook platform files have been updated to be compatible with
the r6p0.
BUG=chrome-os-partner:41911
TEST=Boot Daisy to UI
TEST=General browsing. Run Aquarium.
TEST=Run graphics_GLBench
Change-Id: I9de89d2e767119802f8e809d4197b1d9f126490c
Reviewed-on: https://chromium-review.googlesource.com/289171
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
|
|
A recent change means that we no longer have Chrome pre-builts
for board 'slippy', but COMMIT-QUEUE.ini still relied on
slippy-pre-cq for testing. The result was that attempts to
commit CLs would loop forever with slippy-pre-cq failures.
This changes 'slippy' to 'wolf', which is still supported.
BUG=chromium:525733
TEST=Run this through the pre-cq
Signed-off-by: jrbarnette@chromium.org
Change-Id: Ieefe38c82d46bc3fdad801bb427f0af077c81273
Reviewed-on: https://chromium-review.googlesource.com/295782
|
|
The default was meant to be FALSE all along.
Also remove selftest from the list of commands which may change the NV state.
BUG=chromium:519324
TEST=none
BRANCH=none
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Change-Id: Ib911644b7b3e994ab376278e26cf0c8fcd070424
Reviewed-on: https://chromium-review.googlesource.com/294730
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
|
|
This makes some Kensington trackballs work on Chrome OS.
BUG=chromium:383944
TEST=Manual on link with Kenginston trackball.
Change-Id: Iba9dc2dddd3d260f40efbb756e7e4a14a09f0e58
Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293850
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
|
|
We will check if any hidden SSID found in passive scan channels
and do specific SSID active scan for those channels.
Signed-off-by: chunfan chen <jeffc@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
BUG=chrome-os-partner:40751
TEST=On Daisy, ran tests to confirm we can successfully connect
to hidden AP on DFS/passive channels. No regressions seen
for auto tests.
Change-Id: I41ab8323d84be9f963233339439d1822a0693d02
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/294060
Reviewed-by: Paul Stewart <pstew@chromium.org>
|
|
NM10_GPIO is outdated and it conflicts with LPC_ICH driver. GPIO_ICH
exposes the same GPIOs while cooperating with LPC_ICH driver.
BUG=chromium:491407
TEST=boot xgb-x86_freon with HDMI monitor attached
CQ-DEPEND=CL:293574
Change-Id: I898ae4cfad45b5cc487541b527f46e4732e4af57
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293583
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
|
|
MFC watchdog timeout was 10 seconds and interrupt timeout was 2
seconds. One MFC command shouldn't take such a long time. Change
both timeouts to 1 second.
BUG=chromium:481462
TEST=Run apprtc loopback and play a video. Run VDA and VEA tests.
Change-Id: I20995b015216906032cddb8c96d7aec0d7e33bbe
Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/292055
|
|
BUG=chromium:491407
TEST=bood zgb-x86_freon with HDMI monitor attached
Change-Id: I20e3f4564e9e1593babfc3fc617cd8775077025c
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293582
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
|
|
The NM10's GPIO is compatible with ICH v7 GPIO.
BUG=chromium:491407
TEST=boot zgb-x86_freon with HDMI monitor attached
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Tested-by: Dan Weinlader <danw@vs-networks.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
(cherry picked from commit 117bbfe25cfc2e968be1f7976ac460a5cd3d734e)
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Change-Id: I38bc2dd587fedd5395246ff30992f7e1eff3577c
Reviewed-on: https://chromium-review.googlesource.com/293581
Commit-Queue: Dominik Behr <dbehr@chromium.org>
Trybot-Ready: Dominik Behr <dbehr@chromium.org>
Tested-by: Dominik Behr <dbehr@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
|
|
Needed for recent bluez
BUG=chromium:462835
TEST=kernel_CryptoAPI; booted with snow
Change-Id: I0221daf735710c0de8bfd222244f17425c6a1660
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/290237
Reviewed-by: Kees Cook <keescook@chromium.org>
|
|
Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
changed the automatic module loading when requesting crypto algorithms
to prefix all module requests with "crypto-". This requires all crypto
modules to have a crypto specific module alias even if their file name
would otherwise match the requested crypto algorithm.
Even though commit 5d26a105b5a7 added those aliases for a vast amount of
modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
annotations to those files to make them get loaded automatically, again.
This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
with kernels v3.18 and below.
Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.
Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf)
Conflicts:
arch/powerpc/crypto/sha1.c
arch/x86/crypto/sha-mb/sha1_mb.c
crypto/crc32c_generic.c [--> crypto/crc32c.c]
crypto/crct10dif_generic.c
BUG=chromium:462835
TEST=kernel_CryptoAPI
Change-Id: Id7f097499122263aa422429eeee5b27c033f4084
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/290236
Reviewed-by: Kees Cook <keescook@chromium.org>
|
|
This adds the module loading prefix "crypto-" to the template lookup
as well.
For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the "crypto-" prefix at every level, correctly rejecting "vfat":
net-pf-38
algif-hash
crypto-vfat(blowfish)
crypto-vfat(blowfish)-all
crypto-vfat
Reported-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 4943ba16bbc2db05115707b3ff7b4874e9e3c560)
Conflicts:
crypto/mcryptd.c
BUG=chromium:462835
TEST=kernel_CryptoAPI
Change-Id: Ie8888816cb3872e15d2166888e9c3c9974b3f826
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/290235
Reviewed-by: Kees Cook <keescook@chromium.org>
|
|
This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:
https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b)
Conflicts:
arch/arm/crypto/sha1_neon_glue.c
arch/arm/crypto/sha512_neon_glue.c
arch/arm64/crypto/aes-ce-ccm-glue.c
arch/arm64/crypto/aes-glue.c
arch/powerpc/crypto/sha1.c
arch/x86/crypto/camellia_aesni_avx2_glue.c
arch/x86/crypto/crc32-pclmul_glue.c
arch/x86/crypto/crct10dif-pclmul_glue.c
arch/x86/crypto/des3_ede_glue.c
arch/x86/crypto/serpent_avx2_glue.c
arch/x86/crypto/sha256_ssse3_glue.c
arch/x86/crypto/sha512_ssse3_glue.c
crypto/crc32.c
crypto/crc32c_generic.c
crypto/crct10dif_generic.c
crypto/lz4.c
crypto/lz4hc.c
drivers/crypto/qat/qat_common/adf_ctl_drv.c
drivers/s390/crypto/ap_bus.c
BUG=chromium:462835
TEST=kernel_CryptoAPI
Change-Id: Iaa441ab00413bfba7dd77f31894b1374eff6892c
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/290234
Reviewed-by: Kees Cook <keescook@chromium.org>
|
|
The template lookup interface does not provide a way to use format
strings, so make sure that the interface cannot be abused accidentally.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 1c8fca1d92e14859159a82b8a380d220139b7344)
BUG=chromium:462835
TEST=kernel_CryptoAPI
Change-Id: I13fc93b40403e97fe7b300f880a57dad05f3eaad
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/290233
Reviewed-by: Kees Cook <keescook@chromium.org>
|
|
The "select LEDS_CLAS" should of course be "select LEDS_CLASS"
and the symbol shouldn't have the same name as the iwlwifi one.
BUG=chromium:519130
TEST=make oldconfig and make sure it doesn't report any warnings
about this symbol
Change-Id: I623e4ab907e85ca639f86229f73dd6350c1ca113
Reported-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/292372
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
(This patch has no effect unless the module parameter
tpm.tpm_early_savestate is set to 1.)
Some TPM models can throttle the TPM_Savestate command under certain
conditions, to prevent wear. This results in suspend-time increases
which, if ignored, may hide other regressions during automated tests.
It can also interfere with the suspend and make it fail.
This problem is made more acute by the over-throttling behavior
of a subset of those models (which seems to be an error). In
those models the throttling can be seen even when TPM_Savestate
commands are issued far apart from each other.
The workaround suggested in the bug discussion is to issue a TPM_Savestate
command within some time interval after a command which may change the
volatile state of the TPM. A TPM_Savestate following such command
requires the TPM to actually write data to the nvram, which
may trigger the throttling. (If the TPM state has not changed
since the last TPM_Savestate, the TPM doesn't need to save it
again.)
We would also like to avoid issuing unnecessary savestate commands.
If NO commands are issued following the last TPM_Savestate, it
should be OK in general to skip the savestate at suspend.
Unfortunately at this time we rely on this command to help decrement
the dictionary attack counter on some systems, so we leave this
behavior configurable via a module parameter.
BUG=chrome-os-partner:26289
TEST=boot, suspend, resume
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Change-Id: Id062df884d7f37d017041f68af75dd03c12a0b26
Reviewed-on: https://chromium-review.googlesource.com/277726
Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
|
|
Update the iwl7000 driver to the Core11 release.
This also changes our release model slightly - the code now has
more ifdefs on the CFG80211_VERSION and the KERNEL_VERSION so
that the same code can be used against multiple versions.
BUG=N/A
TEST=AVL tests
Change-Id: Iec640580610118dce1b3307407302512ca31a820
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/282776
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
The ignore check that got added in 6ce901eb61 ("HID: input: fix confusion
on conflicting mappings") needs to properly check for VARIABLE reports
as well (ARRAY reports should be ignored), otherwise legitimate keyboards
might break.
Cc: <stable@vger.kernel.org>
Fixes: 6ce901eb61 ("HID: input: fix confusion on conflicting mappings")
Reported-by: Fredrik Hallenberg <megahallon@gmail.com>
Reported-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
(cherry picked from commit 8e7b341037db1835ee6eea64663013cbfcf33575)
Signed-off-by: Adam Goode <agoode@chromium.org>
BUG=chromium:476215
TEST=Test that backslash "\" key repeats in N-key rollover mode
Reviewed-on: https://chromium-review.googlesource.com/291141
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
(cherry picked from commit c45d0f2ee47e085724464fa4d1ea29fa3b31a002)
Change-Id: Iaf4d0c96b36bb48138aa83e2784d1add17760493
Reviewed-on: https://chromium-review.googlesource.com/291501
Commit-Ready: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
|
|
Stout firmware reserves the IO region for ACPI, but never access it.
BUG=chromium:516371
TEST=Manual on Stout. Verify that gpiochip is successfully probed.
Change-Id: I9067397eb9999b56abf9611da384c64d63ff89aa
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/290430
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
neighbours look like this:
+---+ +---+ +-------+
| 1 | | 2 | | 5 |
+---+ +---+ +-------+
+---+ +-----------+
| 3 | | 4 |
+---+ +-----------+
On a PC-102/105 keyboard (European layout) it looks like this:
+---+ +---+ +-------+
| 1 | | 2 | | |
+---+ +---+ +-+ 4 |
+---+ +---+ | |
| 3 | | 5 | | |
+---+ +---+ +-----+
(Note that the number of keys is the same, but key '5' is moved down and
the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)
The keys 1-4 report the same scan-code in HID in both layouts, even though
the keysym they produce is usually different depending on the XKB-keymap
used by user-space.
However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
and 0x32 for the lower layout, as defined by the HID spec. This is highly
confusing as the linux-input API uses a single keycode for both.
So far, this was never a problem as there never has been a keyboard with
both of those keys present at the same time. It would have to look
something like this:
+---+ +---+ +-------+
| 1 | | 2 | | x31 |
+---+ +---+ +-------+
+---+ +---+ +-----+
| 3 | |x32| | 4 |
+---+ +---+ +-----+
HID can represent such a keyboard, but the linux-input API cannot.
Furthermore, any user-space mapping would be confused by this and,
luckily, no-one ever produced such hardware.
Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
is present on a hardware, this works just fine.
Lets introduce hardware-vendors into this:
------------------------------------------
Unfortunately, it seems way to expensive to produce a different device for
American and European layouts. Therefore, hardware-vendors put both keys,
(0x31 and 0x32) on the same keyboard, but only one of them is hooked up
to the physical button, the other one is 'dead'.
This means, they can use the same hardware, with a different button-layout
and automatically produce the correct HID events for American *and*
European layouts. This is unproblematic for normal keyboards, as the
'dead' key will never report any KEY-DOWN events. But RollOver keyboards
send the whole matrix on each key-event, allowing n-key roll-over mode.
This means, we get a 0x31 and 0x32 event on each key-press. One of them
will always be 0, the other reports the real state. As we map both to the
same keycode, we will get spurious key-events, even though the real
key-state never changed.
The easiest way would be to blacklist 'dead' keys and never handle those.
We could simply read the 'country' tag of USB devices and blacklist either
key according to the layout. But... hardware vendors... want the same
device for all countries and thus many of them set 'country' to 0 for all
devices. Meh..
So we have to deal with this properly. As we cannot know which of the keys
is 'dead', we either need a heuristic and track those keys, or we simply
make use of our value-tracking for HID fields. We simply ignore HID events
for absolute data if the data didn't change. As HID tracks events on the
HID level, we haven't done the keycode translation, yet. Therefore, the
'dead' key is tracked independently of the real key, therefore, any events
on it will be ignored.
This patch simply discards any HID events for absolute data if it didn't
change compared to the last report. We need to ignore relative and
buffered-byte reports for obvious reasons. But those cannot be affected by
this bug, so we're fine.
Preferably, we'd do this filtering on the HID-core level. But this might
break a lot of custom drivers, if they do not follow the HID specs.
Therefore, we do this late in hid-input just before we inject it into the
input layer (which does the exact same filtering, but on the keycode
level).
If this turns out to break some devices, we might have to limit filtering
to EV_KEY events. But lets try to do the Right Thing first, and properly
filter any absolute data that didn't change.
This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
hardware. We might wanna wait with backporting for a while, before we know
it doesn't break anything else, though.
Cc: <stable@vger.kernel.org>
Reported-by: Adam Goode <adam@spicenitz.org>
Reported-by: Fredrik Hallenberg <megahallon@gmail.com>
Tested-by: Fredrik Hallenberg <megahallon@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
(cherry picked from commit 6ce901eb61aa30ba8565c62049ee80c90728ef14)
Signed-off-by: Adam Goode <agoode@chromium.org>
BUG=chromium:476215
TEST=Test that backslash "\" key repeats in N-key rollover mode
Reviewed-on: https://chromium-review.googlesource.com/291140
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
(cherry picked from commit 409be6946f6a84bfe0a61ce47c8d721f4df095b3)
Change-Id: Ie8dd87bf450b511e770bb7f237772bc26945344c
Reviewed-on: https://chromium-review.googlesource.com/291500
Commit-Ready: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
|
|
Variable pos is u8 here, so memcpy is needed to store u16 aid.
At the same time, aid should be platform independent, upper layer
utility(wpa_supplicant,etc.,) parse it as le16, so keep it le16
here.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
BUG=chrome-os-partner:40462
TEST=network_WiFi_TDLSPing test consistently passed with
this fix.
Change-Id: Iaf08b5b0e83fb71f1412d8b88be8bc092d159093
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/291094
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
Add the correct dB ranges of Bose Companion 5 and Drangonfly DAC 1.2.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 2d1cb7f658fb9c3ba8f9dab8aca297d4dfdec835)
Signed-off-by: Yao-Wen Mao <yaowen@google.com>
BUG=chromium:309459
TEST=Connect with Bose Companion 5 and use amixer to verify that
the volume range is from -50.06dB to -0.06dB.
Change-Id: I0bd0b5665d0d7598724f45e13fa9dda564e33021
Reviewed-on: https://chromium-review.googlesource.com/290486
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Yao-Wen Mao <yaowen@google.com>
Tested-by: Yao-Wen Mao <yaowen@google.com>
|
|
Since we're calling request_module() asynchronously now, we can get
rid of the autoload lock in snd_seq_device_register_driver(), as well
as in the snd-seq driver registration itself. This enables the
automatic loading of dependent sequencer modules, such as
snd-seq-virmidi from snd-emu10k1-synth.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit d5129f33a0d155d69cb0652cfc87bbc4d132ca17)
BUG=chromium:499817
TEST=build and boot
Change-Id: I595569ea9c2349660f8007b78a24b1cddda22694
Reviewed-on: https://chromium-review.googlesource.com/277492
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
|
|
Currently the sequencer module binding is performed independently from
the card module itself. The reason behind it is to keep the sequencer
stuff optional and allow the system running without it (e.g. for using
PCM or rawmidi only). This works in most cases, but a remaining
problem is that the binding isn't done automatically when a new driver
module is probed. Typically this becomes visible when a hotplug
driver like usb audio is used.
This patch tries to address this and other potential issues. First,
the seq-binder (seq_device.c) tries to load a missing driver module at
creating a new device object. This is done asynchronously in a workq
for avoiding the deadlock (modprobe call in module init path).
This action, however, should be enabled only when the sequencer stuff
was already initialized, i.e. snd-seq module was already loaded. For
that, a new function, snd_seq_autoload_init() is introduced here; this
clears the blocking of autoloading, and also tries to load all pending
driver modules.
Reported-by: Adam Goode <agoode@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 68ab61084de3220e2fb0a698c890ba91decddc85)
BUG=chromium:499817
TEST=Boot with no MIDI devices attached. Go to http://webaudiodemos.appspot.com/midi-synth/index.html and connect a device. Verify that it appears in the MIDI_IN menu on the page.
Change-Id: Ia2d44461cab9682332053d71f96f03c75ce3ccbf
Reviewed-on: https://chromium-review.googlesource.com/277491
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
|
|
... just to robustify for races.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 54841a06c54eb55918948c12ab9b5f02cacb6ab3)
Signed-off-by: Adam Goode <agoode@chromium.org>
BUG=chromium:499817
TEST=Build and boot
Change-Id: If30a694294bf9663040b807200d82982a572ac7e
Reviewed-on: https://chromium-review.googlesource.com/277490
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
|
|
With few upstream patches, ICH-GPIO works on Panther Point with kernel 3.8,
so we are able to bring LPC_ICH and WDT back and disable NM10-GPIO now.
ICH-GPIO uses the same ACPI resources with ACPI-GPIO, so
'acpi_enforce_resources=lax' is required in kernel command line to bypass
the resource checking during initialization.
BUG=chromium:434755
BRANCH=None
TEST=manual on Stout. Check gpiochip exsits in /sys/calss/gpio.
CQ-DEPEND=CL:232503,CL:232504,CL:232462
Change-Id: Ie2a98f0edb841086c7b567e8bc92a893189b1701
Signed-off-by: Wei Shun Chang <wei.shun.chang@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/235832
Reviewed-by: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>
|
|
expect
ichx_gpio_check_available() returns either 0 or -ENXIO depending on whether
the given GPIO is available or not. However, callers of this function treat
the return value as boolean:
...
if (!ichx_gpio_check_available(gpio, nr))
return -ENXIO;
which erroneusly fails when the GPIO is available and not vice versa.
Fix this by making the function return boolean as expected by the callers.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
(cherry picked from commit e97f9b5277afeabb54892ebc6f68500098467ba1)
BUG=chromium:434755
TEST=Manual on Stout.
1. Export a gpio pin by echoing a pin number (base+pin) to
/sys/class/gpio/export.
2. Modify the direction of the exported pin (echo 'out'|'in'
to direction).
3. No error message 'No such device or address' is output.
Change-Id: I08386b35791a9c293767e3b9a075ff4042234979
Reviewed-on: https://chromium-review.googlesource.com/232504
Reviewed-by: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Trybot-Ready: Grant Grundler <grundler@chromium.org>
Tested-by: Wei Shun Chang <wei.shun.chang@intel.com>
Commit-Queue: Shawn N <shawnn@chromium.org>
|
|
Panther Point PCH GPIO configuration is similar to V5 PCHs.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
(cherry picked from commit 62cf2cdb99c7e870ab857bdd617e728790f8c43c)
BUG=chromium:434755
TEST=Manual on Stout. Check gpiochip exists in /sys/class/gpio.
Change-Id: Ie0c49241f6b60e70c63bd9e5fe7e0b441ddb908e
Reviewed-on: https://chromium-review.googlesource.com/232503
Reviewed-by: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Trybot-Ready: Grant Grundler <grundler@chromium.org>
Tested-by: Wei Shun Chang <wei.shun.chang@intel.com>
Commit-Queue: Shawn N <shawnn@chromium.org>
|
|
BUG=chromium:495774
TEST=Built x86-mario image and confirmed that ath3k-1.fw is in /lib/firmware
Change-Id: I4b1a9bfea75de2b6d6c0ec77f6fc84482117fd40
Signed-off-by: Vince Laviano <vlaviano@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/2194
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
(cherry picked from commit 337a216266fc25c1f0c24457810e83b89ab97d97)
Reviewed-on: https://chromium-review.googlesource.com/286899
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Haixia Shi <hshi@chromium.org>
Trybot-Ready: Haixia Shi <hshi@chromium.org>
Commit-Queue: Haixia Shi <hshi@chromium.org>
|
|
The command DPB_FLUSH is not supported in RES_CHANGE_FLUSH state.
So, we just finish the whole resolution change sequence before
stopping the stream (STREAMOFF).
BUG=chromium:415030
TEST=video_VideoSeek.(h264|vp8).switchres
Change-Id: I720f9fe04c7c51d74ddfe2f3782ee0d052a27e89
Signed-off-by: Owen Lin <owenlin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/285764
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
|
|
The command codes (ordinals) macros TPM_ORD_... are inconsistently
defined in either native byte order or TPM byte order. This cleans
up in preparation for other CLs that need to use them in native
order. The inconsistencies are still there in kernel 3.18, but
they are gone in kernel 4.0.
BUG=none
TEST=compiled
BRANCH=none
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Change-Id: Ic13abe8ccb43b4d34f580b3a64ed25e7e00004f0
Reviewed-on: https://chromium-review.googlesource.com/280591
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
|
|
With compilers which follow the C99 standard (like modern versions of gcc and
clang), "extern inline" does the wrong thing (emits code for an externally
linkable version of the inline function). In this case using static inline
and removing the NULL version of return_address in return_address.c does
the right thing.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit aeea3592a13bf12861943e44fc48f1f270941f8d)
BUG=chrome-os-partner:41878
TEST=With series, compile with archlinux arm's cross compiler
(which is gcc5.1 based now)
Change-Id: I8d0529c689e6adeb302e7c5b2144e57c1aac26b0
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/282367
Reviewed-by: Luis Lozano <llozano@chromium.org>
|
|
We're missing include/linux/compiler-gcc5.h which is required now
because gcc branched off to v5 in trunk.
Just copy the relevant bits out of include/linux/compiler-gcc4.h,
no new code is added as of now.
This fixes a build error when using gcc 5.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 71458cfc782eafe4b27656e078d379a34e472adf)
BUG=chrome-os-partner:41878
TEST=With series, compile with archlinux arm's cross compiler
(which is gcc5.1 based now)
Change-Id: Ib90d8a6d1962e4237463688db69100f04a941653
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/282366
Reviewed-by: Luis Lozano <llozano@chromium.org>
|
|
Adding support to copy the timestamp and timecode of the
source buffers of the mfc encoder into its destination
buffers.
BUG=chrome-os-partner:30604
TEST= Tested using mainline application v4l2-mfc-encoder.
Altered the test application at the v4l_enq_buf call to add
the timestamp for the source buffer. Added prints to check
the timestamp of source buffer and destination buffer and
confirmed with values obtained, copying was successful.
Change-Id: I0d44d6b7b867ce0adee213591185051ccfd715fc
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/261880
Reviewed-by: Haixia Shi <hshi@chromium.org>
Commit-Queue: Haixia Shi <hshi@chromium.org>
Tested-by: Haixia Shi <hshi@chromium.org>
|
|
Update Kconfig with enhanced help text for hid-plantronics driver.
Update hid-plantronics.c to identify device type and correctly map
either the vendor unique or consumer control volume up/down usages
to KEY_VOLUMEUP and KEY_VOLUMEDOWN events. Unmapped usages are ignored
to prevent core mapping of unknown usages to random mouse events.
Tested on ChromeBox/ChromeBook with various Plantronics devices.
Signed-off-by: Terry Junge <terry.junge@plantronics.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
BUG=chromium:417438
TEST=Use Plantronics device, observe volume keys affect system volume.
(cherry picked from commit 81bb773faed7f5f0e82f14cdfcfe4e89fbea0e19)
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Change-Id: I376d67939235c6b5781ec977b5516c773ec1b8a0
Reviewed-on: https://chromium-review.googlesource.com/284671
Tested-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
(cherry picked from commit f5ca59e1eb804f7699b55cede4bc36d0e58044ad)
Reviewed-on: https://chromium-review.googlesource.com/284946
|
|
Remove redundant probe() callback, as it isn't doing anything extra
that HID core wouldn't do by default.
Reported-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
BUG=chromium:417438
TEST=Use Plantronics device.
(cherry picked from commit 1e48d542e751f766d0ff03aa97bef22d90a98041)
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Change-Id: I6573cfcc462077f1e2d75c9ebfdb15b079c9e283
Reviewed-on: https://chromium-review.googlesource.com/284670
Tested-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
(cherry picked from commit 358bd9ece523a9da0f76f8896fa070b0b87f7847)
Reviewed-on: https://chromium-review.googlesource.com/284945
|
|
The new USBDEVFS_DROP_PRIVILEGES ioctl allows a process to voluntarily
relinquish the ability to issue other ioctls that may interfere with
other processes and drivers that have claimed an interface on the
device.
(Cross-port of I2c865027a1b1071c7f03f0b9d24c925b64631996 from v3.10.)
BUG=chromium:496469
TEST=Built chromeos-kernel-3_8 for amd64-generic.
Change-Id: I5a0c0d75251b5094e410ddee3b8bb5957b8fdfaa
Signed-off-by: Reilly Grant <reillyg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/283622
Reviewed-by: Kees Cook <keescook@chromium.org>
|
|
Instead of doing the bit operations manually and having multiple
different error handling schemes scattered around the driver (WARN_ON(),
mfc_err(), no handling at all), this patch adds respective helper
functions and modifies existing code to stop using dev->hw_lock
directly.
BUG=chromium:495960
TEST=youtube;apprtc;video_VideoSeek;vda_unittest;vea_unittest
Change-Id: I6542a327ac55f3d31980703625c76c8711874107
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/261540
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Current implementation of stop_streaming of both encoder and decoder are
very racy, because they check context state without any locking.
Moreover, certain state combinations are not even handled, leading to
the hardware not being stopped at all and DPB buffers not flushed
correctly. The race also leads to crashes with seeking while resolution
change is being processed.
This patch reimplements stop_streaming callbacks in a way that handles
all states and does not race with interrupt handler. Moreover, buffer
flushing code is updated to make sure that DPB buffers are flushed
correctly when stopping the CAPTURE queue, on all supported hardware
versions, reusing the MFCINST_FLUSH state for doing the traditional
flushing mechanism (used also in MFCINST_FINISHING state) on MFCv5.x.
BUG=chromium:495960
TEST=youtube;apprtc;video_VideoSeek with Chrome fixes
Change-Id: Iea9c38975680e6bd0859be3f2287cbdd82a975e4
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256911
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Currently the driver does not try running scheduled contexts after
resume automatically, so the hardware will be stuck until the userspace
queues more work. However the correct handling of suspend/resume
requires the hardware to be restored to the same state as before
suspend, so if further runs are available the hardware should continue
processing them.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: Ib1883f4e83635aeb5d76580ba6aa09dc56372931
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/282452
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Current code for waiting for context/device is racy - it relies on
unprotected condition variables, which are just integer flags, which are
reset before running a hardware command and set after the command
completes. However if another command is executed before the waiting
thread wakes up, the flag will get reset before and such thread will not
notice it.
Looking at how the waiting functions are used through the driver,
s5p_mfc_wait_for_done_ctx() should always wait for any available work of
given context to be done (i.e. stop streaming, get format, open
instance, close instance, which are all guaranteed to end in finite
time), while s5p_mfc_wait_for_done_dev() should wait only for single
command - it is used only for initial setup which is done sequentially.
Using the above assumptions, this patch simplifies all waiting cases
in the driver. Timeout for per context waits are handled using watchdog
timer, while global waiting has local timeout, to avoid dealing with
re-entrancy of watchdog handler, which calls hardware commands itself.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I3b9de13bbf7a18983a47bd159e3078f27364d5e7
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256910
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Current code does not acquire hw_lock for sending initialization and
power management commands, which makes the interrupt handling command
asymmetric. Moreover dev->hw_lock could be used to simplify waiting
for initialization commands.
This patch makes the driver acquire hw_lock before issuing initialization
commands. To avoid code duplication, in case of error, the lock is released
by the top level caller of the initialization sequence.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: If6aa7c10bca5fd1bace2a67826378db6d2694333
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256888
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Current watchdog code does not fully prevent races between the watchdog
work and threads running ioctls and other file operations, because it
does not ensure that dev->mutex is actually locked.
BUG=chromium:495960
TEST=simulated MFC firmware crashes by skipping interrupts randomly
Change-Id: I863f025daabafba2f810f30f023821d0ff959919
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272100
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
CONFIG_SCHED_DEBUG is mandatory for getting the cpu wakeup stats into
the task manager. These stats could be used into building an improved
power usage monitor. This flag doesn't add any additional
runtime overhead. This functionality is already present in the Linux
version of Chromium if this flag is enabled in the kernel.
BUG=chromium:120488
TEST=after enabling CONFIG_SCHED_DEBUG, /proc/self/sched
reports scheduler info. ChromiumOS task manager reports correct number
of idle wake ups.
Change-Id: I74313afc56bf23e5e542b5acb12bfb5b429e0ec8
Signed-off-by: Valentin Ilie <valentin.ilie@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/283310
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Commit-Queue: Alexandru Stan <amstan@chromium.org>
|
|
When MFC encounters a critical error, the driver should not issue new
commands to it anymore, but instead fail any ongoing operations and
completely reinitialize the hardware.
This patch adds a hw_error flag to struct s5p_mfc_dev, which is set
on critical hardware error and cleared on deinitialization, to make sure
that new commands will be issued only after next initialization.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: Ia6c08daf9def48781459c6f78cc9ce8b55eed758
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/281847
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
To simplify error handling and factor out some common code, this patch
moves MFC startup and shutdown handling code from s5p_mfc_open() and
s5p_mfc_release() into separate helper functions.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I860b959df61f1af55faa7ca283b3300d50bafe7f
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/282451
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
In few places of the driver the s5p_mfc_wait_for_done_ctx() is called to
assure that scheduled operation has completed before returning from an
IOCTL. However not all of them check the state after the waiting
function returns.
This patch adds necessary checks in places where the code relies on
successful completion of queued command. While at it, error handling in
reqbufs_capture() is refactored to use common error path for buffer
allocation sequence.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I2ac0009ed3d443d746222b96426999206f4c1e74
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/281846
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
The resolution change event should be sent to userspace only after new
header have been parsed and new format is available to be fetched using
G_FMT ioctl. This patch modifies the driver to follow this convention
and moves the code signalling the event to SEQ_DONE event handler. While
at it, the CAPTURE queue state setting is also moved there, so that it
is happenning in a synchronized manner under dev->irqlock.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I7e813c4527fa798667dbb84d601aae7221a297d2
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256909
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
This patch makes the driver use pointers instead of some artificial
indices into a static array in driver data to refer to contexts. This
has the benefit of code simplification and allows to remove the
hardcoded instance limit in future. In addition, it removes a potential
race point of updating the arrays of pointers with context pointers on
open and NULL on release.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I12a0bd414b92e3abac3355747ff63661db4f9c1a
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256908
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Currently the driver has different ways of checking whether given
context should be scheduled. In s5p_mfc_{enc,dec}.c there are
s5p_mfc_ctx_ready() functions, which are used in these files to check if
set_work_bit_*() should be set on that context. However in interrupt and
error handling code the conditions checked in s5p_mfc_ctx_ready() are
replicated (sometimes in a buggy way, missing some checks) and scattered
around code handling particular interrupts. This makes it hard to follow
the flow and easy to make mistakes, because of unnecessary redundancy.
This patch greatly simplifies the decision making logic by keeping all
the condition checks inside s5p_mfc_ctx_ready() which is now made a
callback that could be also called from interrupt handler. Moreover, the
hard to follow model with work bits without clear synchronizatiom model
is replaced with a simple list, which works as a round robin queue and is
easier to follow. In addition, duplicated context finishing and
rescheduling code is moved into new helper functions to be used in
ioctls, interrupt handlers and error handling code.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: Ie3e5205c773ab433034f117aa5b8a8a8eb61f174
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256907
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
If running selected context fails, current implementation of
s5p_mfc_try_run() will just clean-up and bail out, breaking the
scheduling loop, because no further contexts will be run until some
ioctl handler calls s5p_mfc_try_run() again. Moreover, the error will
not be signalled to the userspace.
This patch fixes the issue by following the same model as used in
hardware error interrupt handling to abort failed context, signal the
userspace and retry with another one.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: If7882c4a4e73f841cc681d2ee37f3a9ec4ad0216
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256906
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Instead of providing codec ops for encoder only, equivalent callbacks
can be provided for decoder as well, allowing us to make the interrupt
handling code more symmetric. An alternative would be removing the ops
completely, but they will become more useful after further patches.
While at it, drop unused call_cop() macro and add more meaningful
documentation.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I8f189d94d3acf8120808631a8319209c649e75c4
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256905
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
The pre_seq_start and pre_frame_start ops of s5p_mfc_codec_ops have been
populated on encoder side but noone actually called them. This patch
removes this dead code.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: If080d7681c44aa5c57461133693d644286d899b2
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256904
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Current code implements the check as a series of if-else statements,
each one including a condition checking state together with other
conditions. To make the code more readable, this patch reimplements
these functions using switch statement on context state and then
additional condition checks using if statements inside particular cases.
In addition the functions are changed to return boolean type instead of
integer.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I69c5d4049fe3e44db163321726ab6add9fffb8cf
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256903
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
To separate interrupt handling logic from state machine logic and
improve code readability, this patch moves code handling particular
interrupt reasons into helper functions keeping only interrupt handling
logic inside the main interrupt handler.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I4ecb4e9a544fabba40713f6978d6eed81528e339
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256902
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Presence of irqlock spinlock in s5p_mfc_dev struct and various elements
of driver design suggests that interrupt handler should run exclusive to
any code running with irqlock acquired (which held true before SMP SoCs
with MFC entered the market).
This patch makes interrupt handler always run with irqlock held.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: Ic46f69aa03bd0dcb879f8c3bd8dbaab1e4cf64cf
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256901
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Scattering the assignment over all the code executing hardware commands
is not justified in any way, makes it more difficult to read the code
and easier to make mistakes. In fact there is already one code path
which leads to driver loop trying to run the same context again and
again if issuing command fails.
This patch fixes the problem by setting current context as soon as it is
selected for next hardware run.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: If4873a700e58f9e167fb164adf95dec927ec1997
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256900
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Current code has multiple exit paths from IRQ handler leading to heavy
duplication of code clearing interrupt flags, waking up wait queues,
unlocking hardware lock, gating the clock and scheduling another
context. This patch intends to fix this by introducing common exit path
into s5p_mfc_irq() which handles all the above tasks after proper event
handling function returns.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: Iee14a917557a09a678d0a5cc4589868130a0e3a5
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256889
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Current implementation of enc_post_seq_start() tries to reschedule
execution for MFC versions older than 6. However this cannot succeed,
because hw_lock is still held, so s5p_mfc_try_run() will fail. Moreover,
the call to set_work_bit_irqsave() is useless, because as soon as the
callback returns, the bit is cleared again before other code could make
use of it.
As the code has no effect, this patch removes it.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I3617b2be39fd7a6be1afd4c48321921b41bf7606
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/261499
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Even though there is a clear_int_flag op provided for particular MFC
versions, existing code used old function written for MFCv5 in case of
stream complete event. This patch removes the old function and replaces
its users with calls to proper op.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I31b77b314b2c67ce3ab800ea05c871de6a38b4fc
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/261498
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Even if one context fails, we should just mark it as failed and never
try to execute again, without affecting other contexts. This code
modifies the error interrupt handling code to try scheduling next
context, even if last one failed.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: Ib7624ef75819b96fe41c660e8bbbe12f7390bec0
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/261497
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Extract the common part of try_run from s5p_mfc_opr_v5.c and
s5p_mfc_opr_v6.c into s5p_mfc_opr.c.
Signed-off-by: Owen Lin <owenlin@chromium.org>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: Ie5a937481edf7f9027b72c9fec5d83dd4520cced
Reviewed-on: https://chromium-review.googlesource.com/256887
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
|
|
This state was only defined in enum and not referenced anywhere in the
driver. This patch removes it.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I6649eac93174bff96bdf3f1dea4efbeb503df6c3
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256886
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Requesting buffers using REQBUFS should commit the format on given queue
as allocated buffers are valid only with this format. This means that we
need to disallow S_FMT calls while the queue has buffers requested. This
patch adds additional checks to driver's S_FMT implementations using
vb2_is_busy() helper.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I6e2e58465bbfc091503488c756d1883431085ef9
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256885
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
Instead of accessing internal queue members directly, this patch makes
the driver use vb2_is_streaming() to get streaming status of the queue.
BUG=chromium:495960
TEST=youtube;apprtc
Change-Id: I53d7b7cdd319894b4999be07edcb95642db75d73
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256884
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
By mistake the NL80211_ATTR_SCHED_SCAN_DELAY got a wrong value in the
enumeration. Fix that by adding the attributes that come before it.
It's not a problem to change this value at this point since it's not
used in official builds yet.
BUG=n/a
TEST=compile test
Change-Id: Ibf87683f216c818cdd9dfe5e284946c4d542dc28
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/282862
Reviewed-by: Paul Stewart <pstew@chromium.org>
|
|
In case of s5p-mfc, neither OUTPUT nor CAPTURE buffers need to be
accessed from the kernel, so there is no point in wasting vmalloc
address space.
This patch uses recently introduced API to specify DMA attributes for
stream buffer allocations bypassing kernel mapping creation.
BUG=none
TEST=4 instances of 1080p video decode do not fail with out of vmalloc space
Change-Id: Ie52f9240f2f183e7f020b9569878cb2fd1aaca5e
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/282670
Reviewed-by: Pawel Osciak <posciak@chromium.org>
|
|
DMA allocations might be subject to certain reqiurements specific to the
hardware using the buffers, such as availability of kernel mapping (for
contents fix-ups in the driver). The only entity that knows them is the
driver, so it must share this knowledge with vb2-dc.
This patch extends the alloc_ctx initialization interface to let the
driver specify DMA attrs, which are then stored inside the allocation
context and will be used for all allocations with that context.
As a side effect, all dma_*_coherent() calls are turned into
dma_*_attrs() calls, because the attributes need to be carried over
through all DMA operations.
BUG=chrome-os-partner:38873
TEST=compile
Change-Id: I0e6c040cf820c194b6ca6f3e6355217496bd1532
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265363
Reviewed-by: Pawel Osciak <posciak@chromium.org>
(cherry picked from commit 07ce6d791cfab87542b7f66c7d884325efd02440)
Reviewed-on: https://chromium-review.googlesource.com/282456
|
|
The warnings are a known issue because the bios doesn't reset the GPU state
properly.
BUG=chromium:504003
TEST=Suspend and resume Alex by closing and opening lid.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Change-Id: Ieffee3a0cedeb6ffbfb2baddb4ba5339ef45a7cd
Reviewed-on: https://chromium-review.googlesource.com/281650
Commit-Queue: Haixia Shi <hshi@chromium.org>
Trybot-Ready: Haixia Shi <hshi@chromium.org>
Tested-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
|
|
For some reason b72ad8c27b18a740669f265cf8eb508e8cfe3a38 (CL:195617,
"CHROMIUM: drm: Replace crtc fb with primary plane fb") did not
update the _lvds.c files, which breaks kernel 3.8 compilation
on amd64-generic platform.
BUG=chromium:502886
TEST=USE="-video_cards_radeon -kernel-3_14 kernel-3_8" \
emerge-amd64-generic -av linux-sources chromeos-kernel-3_8
Kernel boots in a VM
Change-Id: I912f264df6c2544fa6d00db3ce15896d5ffbb359
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/280967
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
Trybot-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
|
|
A few spots were missed in the change to mwifiex_dbg namely in usb.c for
mwifiex, so change them so that CONFIG_MWIFIEX_USB being enabled builds.
This doesn't affect ChromiumOS at all, since MWIFIEX_USB isn't enabled,
but may affect others who use the ChromiumOS kernel sources for their
devices.
BUG=None
TEST=With this patch applied, enable CONFIG_MWIFIEX_USB and verify that
the kernel compiles.
Change-Id: I77abdb4bf2d000429fd3374bb8e96a891d72adc4
Signed-off-by: Steev Klimaszewski <threeway@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/280593
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
Upstream commit ad2b26abc157460ca6fac1a53a2bfeade283adfa.
Add the necessary feature flags and a scan flag to support using
random MAC addresses for scan while unassociated.
The configuration for this supports an arbitrary MAC address
value and mask, so that any kind of configuration (e.g. fixed
OUI or full 46-bit random) can be requested. Full 46-bit random
is the default when no other configuration is passed.
Also add a small helper function to use the addr/mask correctly.
Change-Id: I12462764973081fd9403e816c9bf2710203c5549
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/280351
Reviewed-by: Paul Stewart <pstew@chromium.org>
|
|
This doesn't actually work anyway, so change it from a tristate to a bool
to avoid breaking allmodconfig:
make[1]: *** No rule to make target `security/chromiumos/built-in.c', needed by `security/chromiumos/built-in.o'. Stop.
make[1]: *** Waiting for unfinished jobs....
make: *** [security] Error 2
make: *** Waiting for unfinished jobs....
Even if our code compiled with CONFIG_SECURITY_CHROMIUMOS=m,
register_security() is marked __init so it is unsafe to call it from a
module.
TEST=compile tested
BUG=chromium:474744
Change-Id: I9d69f252d696e7757c1f4e16018e4ebab0c17c1e
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264866
Reviewed-by: Lee Campbell <leecam@chromium.org>
|
|
d_walk()"
Steven Rostedt reported:
> Porting -rt to the latest 3.2 stable tree I triggered this bug:
>
> =====================================
> [ BUG: bad unlock balance detected! ]
> -------------------------------------
> rm/1638 is trying to release lock (rcu_read_lock) at:
> [<c04fde6c>] rcu_read_unlock+0x0/0x23
> but there are no more locks to release!
>
> other info that might help us debug this:
> 2 locks held by rm/1638:
> #0: (&sb->s_type->i_mutex_key#9/1){+.+.+.}, at: [<c04f93eb>] do_rmdir+0x5f/0xd2
> #1: (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<c04f9329>] vfs_rmdir+0x49/0xac
>
> stack backtrace:
> Pid: 1638, comm: rm Not tainted 3.2.66-test-rt96+ #2
> Call Trace:
> [<c083f390>] ? printk+0x1d/0x1f
> [<c0463cdf>] print_unlock_inbalance_bug+0xc3/0xcd
> [<c04653a8>] lock_release_non_nested+0x98/0x1ec
> [<c046228d>] ? trace_hardirqs_off_caller+0x18/0x90
> [<c0456f1c>] ? local_clock+0x2d/0x50
> [<c04fde6c>] ? d_hash+0x2f/0x2f
> [<c04fde6c>] ? d_hash+0x2f/0x2f
> [<c046568e>] lock_release+0x192/0x1ad
> [<c04fde83>] rcu_read_unlock+0x17/0x23
> [<c04ff344>] shrink_dcache_parent+0x227/0x270
> [<c04f9348>] vfs_rmdir+0x68/0xac
> [<c04f9424>] do_rmdir+0x98/0xd2
> [<c04f03ad>] ? fput+0x1a3/0x1ab
> [<c084dd42>] ? sysenter_exit+0xf/0x1a
> [<c0465b58>] ? trace_hardirqs_on_caller+0x118/0x149
> [<c04fa3e0>] sys_unlinkat+0x2b/0x35
> [<c084dd13>] sysenter_do_call+0x12/0x12
>
>
>
>
> There's a path to calling rcu_read_unlock() without calling
> rcu_read_lock() in have_submounts().
>
> goto positive;
>
> positive:
> if (!locked && read_seqretry(&rename_lock, seq))
> goto rename_retry;
>
> rename_retry:
> rcu_read_unlock();
>
> in the above path, rcu_read_lock() is never done before calling
> rcu_read_unlock();
I reviewed locking contexts in all three functions that I changed when
backporting "deal with deadlock in d_walk()". It's actually worse
than this:
- We don't hold this_parent->d_lock at the 'positive' label in
have_submounts(), but it is unlocked after 'rename_retry'.
- There is an rcu_read_unlock() after the 'out' label in
select_parent(), but it's not held at the 'goto out'.
Fix all three lock imbalances.
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
(cherry picked from v3.2.67 commit 20defcec264ceab2630356fb9d397f3d237b5e6d)
TEST=cbuildbot + manual boot
BUG=chromium:432061
Change-Id: Id992045f0a8faf9788b3388d066818e08870cc52
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264865
Reviewed-by: Lee Campbell <leecam@chromium.org>
|
|
commit ca5358ef75fc69fee5322a38a340f5739d997c10 upstream.
... by not hitting rename_retry for reasons other than rename having
happened. In other words, do _not_ restart when finding that
between unlocking the child and locking the parent the former got
into __dentry_kill(). Skip the killed siblings instead...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[bwh: Backported to 3.2:
- As we only have try_to_ascend() and not d_walk(), apply this
change to all callers of try_to_ascend()
- Adjust context to make __dentry_kill() apply to d_kill()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from v3.2.66 commit 2d5a2e6775fadc4ac5b7a1a5cbcdec1bffc0b142)
TEST=cbuildbot + manual boot
BUG=chromium:432061
Change-Id: I984affe072d113833da0380b15ce5efb7cbc3ea7
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264864
Reviewed-by: Lee Campbell <leecam@chromium.org>
|
|
commit 946e51f2bf37f1656916eb75bd0742ba33983c28 upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
TEST=compiled a custom kernel that includes all changed files
BUG=chromium:432061
Change-Id: Idc8a85c34556803320e66a92e3a0d3b72ce2e30e
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
[cernekee: Backported to 3.8 using 026181647a6262 from 3.2.y as a reference.
- Apply name changes in all the different places we use d_alias and d_child
- Move the WARN_ON() in __d_free() to d_free() as we don't have dentry_free()]
Reviewed-on: https://chromium-review.googlesource.com/264863
Reviewed-by: Kees Cook <keescook@chromium.org>
|
|
BTUSB_ATH3012"
This CL reverts the upstream commit 3d50d51a530d7c672cfbac03fef365b1fa7a244e
"Bluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_ATH3012". This commit
was merged to the tree in the most recent kernel driver backport CL
227f925d83c0d909740eaf26a60f12ae6b1f8143 "CHROMIUM: Bluetooth: update stack to
bluetooth-next".
The revert fixes an issue with ATH3012 controllers on chromeos-kernel-3_8 where
successive attempts at powering the controller on/off causes the controller the
hang on HCI_Reset and occasionally crash entirely and disconnect from USB.
Reverting this CL seems to fix the issue.
BUG=chrome-os-partner:40975
TEST=manually enable/disable Bluetooth from the ash UI. The power state should
always successfully switch on and off.
Signed-off-by: Arman Uguray <armansito@chromium.com>
Change-Id: I9c9aa76875225522021d087626595ed72c60c7dd
Reviewed-on: https://chromium-review.googlesource.com/280912
Reviewed-by: Scott Remnant <keybuk@chromium.org>
Tested-by: Arman Uguray <arman.uguray@gmail.com>
Commit-Queue: Arman Uguray <arman.uguray@gmail.com>
|
|
Needed for swap experiments in the field.
BUG=chromium:490724
TEST="modprobe brd rd_size=3000000; dd if=/dev/zero of=/dev/ram0 bs=1024 count=3000000"
BRANCH=none
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Change-Id: I90894f80b4dbaa6b19a68681789515abaa64c886
Reviewed-on: https://chromium-review.googlesource.com/272633
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
|
|
This is for (limited) field experiments.
BUG=chromium:490724
TEST="mkswap /dev/ram0; swapon /dev/ram0" and then actually swapped to it.
BRANCH=none
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Change-Id: Ieaa143453d7837200cf7735965ffee6018a597d6
Reviewed-on: https://chromium-review.googlesource.com/272634
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
|
|
We will reset more_task_flag at the end of main process
routine. This optimization will help to remove spinlock
operations at couple of places in the code.
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/271442
Reviewed-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I41a81c37be88a0734a91bf18821bc8639b92d389
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/278001
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
This patch handles a corner case where TX packet would remain in
driver queue till next packet comes in.
Here is sequence:
1. TX packet is queued via hard_start_xmit and main_work is queued
2. SDIO interrupt comes in which directly call mwifiex_main_process.
This starts executing main superloop.
3. Now work from step1 is scheduled but at first check itself it sees
mwifiex_processing is set and exits.
4. Now if superloop from step2 has passed TX processing part of superloop
this packet would remain in queue until next packet/command/SDIO interrupt
arrives and queues main_work.
This patch fixes this corner case by defining more_task flag which is set when
mwifiex_processing is found to be true. At end of superloop we again check if
more_task flag is set and if set, execute superloop again.
Signed-off-by: Shengzhen Li <szli@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/260764
Reviewed-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: Ie95e0459ff821292cc2f2417def2e7b3d1b515fc
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/278000
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
When driver is waiting for command response, meanwhile if user
issues card reset command, sometimes kernel crash is seen. This
patch fixes the problem by cancelling pending commands before card
reset.
BUG=chrome-os-partner:37185
TEST=We could hit page fault crash in association path using
procedure mentioned in the bug. It is no more seen with this
fix now.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/256320
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/258020
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I05d977abdc307831117c6bc781ee7a1f550fd5e1
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277999
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
It has introduced by recent commit 6b41f941d7cd: "mwifiex:
handle driver initialization error paths" which adds error
path handling for mwifiex_fw_dpc().
release_firmware(adapter->*) is called for success as well
as failure paths. In failure paths, adapter is already freed
at this point.
The issue is fixed by moving mwifiex_free_adapter() call.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/250213
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252594
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I4bd96da2b101e687ed9bdc6e3c59cf1f3513a723
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277998
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
mwifiex_fw_dpc() asynchronously takes care of firmware download
and initialization. Currently the error paths in mwifiex_fw_dpc()
are not handled. So if wrong firmware is downloaded, required
cleanup work is not performed. memory is leaked and workqueue
remains unterminated in this case.
mwifiex_terminate_workqueue() is moved to avoid forward
declaration.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/250212
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252593
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: If969ff0c7a8906d21712c9053ae616bb59ab4d10
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277997
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
During tear down (e.g. mwifiex_sdio_remove during system suspend),
mwifiex left IRQs enabled for a significant period of time when it was
unable to handle them correctly. This caused interrupt storms and
interfered with the bluetooth interface on the same SDIO card.
Solve this by disabling interrupts at the point when they can no longer
be handled correctly, which is at the start of mwifiex_remove_card().
For cleanliness, we now enable interrupts in the mwifiex_add_card() path,
to be symmetrical with the disabling of interrupts. We also couple the
registration of the sdio IRQ handler with the actual enable/disable of
interrupts at the hardware level.
I also removed a write to this register in mwifiex_init_sdio which seemed
pointless and won't cause any ill effects now that we only register
the SDIO IRQ handler when we are ready to accept interrupts.
Includes some corrections from Amitkumar Karwar.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/250211
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252592
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: Id4276ddf5b8221186f6503ab520c318619ed54fe
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277996
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
This patch makes sure that skb is freed after downloading
NULL packet in error cases. Also, USB chipsets return
-EINPROGRESS after downloading packets, they are freed in
USB completion handler later. We will add missing change
to set tx_lock_flag for USB which blocks further packets.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/246006
Reviewed-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I999e3fa4f23c7547518d179d3a48470affeedb34
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277995
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
commit 086ba77a6db00ed858ff07451bedee197df868c9 upstream.
ARM has some private syscalls (for example, set_tls(2)) which lie
outside the range of NR_syscalls. If any of these are called while
syscall tracing is being performed, out-of-bounds array access will
occur in the ftrace and perf sys_{enter,exit} handlers.
# trace-cmd record -e raw_syscalls:* true && trace-cmd report
...
true-653 [000] 384.675777: sys_enter: NR 192 (0, 1000, 3, 4000022, ffffffff, 0)
true-653 [000] 384.675812: sys_exit: NR 192 = 1995915264
true-653 [000] 384.675971: sys_enter: NR 983045 (76f74480, 76f74000, 76f74b28, 76f74480, 76f76f74, 1)
true-653 [000] 384.675988: sys_exit: NR 983045 = 0
...
# trace-cmd record -e syscalls:* true
[ 17.289329] Unable to handle kernel paging request at virtual address aaaaaace
[ 17.289590] pgd = 9e71c000
[ 17.289696] [aaaaaace] *pgd=00000000
[ 17.289985] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 17.290169] Modules linked in:
[ 17.290391] CPU: 0 PID: 704 Comm: true Not tainted 3.18.0-rc2+ #21
[ 17.290585] task: 9f4dab00 ti: 9e710000 task.ti: 9e710000
[ 17.290747] PC is at ftrace_syscall_enter+0x48/0x1f8
[ 17.290866] LR is at syscall_trace_enter+0x124/0x184
Fix this by ignoring out-of-NR_syscalls-bounds syscall numbers.
Commit cd0980fc8add "tracing: Check invalid syscall nr while tracing syscalls"
added the check for less than zero, but it should have also checked
for greater than NR_syscalls.
Link: http://lkml.kernel.org/p/1414620418-29472-1-git-send-email-rabin@rab.in
Fixes: cd0980fc8add "tracing: Check invalid syscall nr while tracing syscalls"
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from v3.10.y commit 3ad3add775181f56f51ed14324ed4e7f1c9d3d1e)
TEST=cbuildbot + manual boot
BUG=chromium:432061c
Change-Id: I2f1d759caf93d8bf528587b7fd4d6acc7fad604c
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264862
Reviewed-by: Lee Campbell <leecam@chromium.org>
|
|
commit a1480dcc3c706e309a88884723446f2e84fedd5b upstream.
Accessing do_remount_sb should require global CAP_SYS_ADMIN, but
only one of the two call sites was appropriately protected.
Fixes CVE-2014-7975.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from v3.10.y commit a7dbb3e347aa3916f681b10cfbc7d12ed6ae7b34)
TEST=cbuildbot + manual boot
BUG=chromium:438972b
Change-Id: Icf3f86d886682e730b9511a36a85a24cea4f6ed3
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264861
Reviewed-by: Lee Campbell <leecam@chromium.org>
|
|
commit 0d0826019e529f21c84687521d03f60cd241ca7d upstream.
Andy Lutomirski recently demonstrated that when chroot is used to set
the root path below the path for the new ``root'' passed to pivot_root
the pivot_root system call succeeds and leaks mounts.
In examining the code I see that starting with a new root that is
below the current root in the mount tree will result in a loop in the
mount tree after the mounts are detached and then reattached to one
another. Resulting in all kinds of ugliness including a leak of that
mounts involved in the leak of the mount loop.
Prevent this problem by ensuring that the new mount is reachable from
the current root of the mount tree.
[Added stable cc. Fixes CVE-2014-7970. --Andy]
Reported-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>
Link: http://lkml.kernel.org/r/87bnpmihks.fsf@x220.int.ebiederm.org
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from v3.10.y commit 315a75ea5d19a4cbc68b96024de8e36eb1db68b0)
TEST=cbuildbot + manual boot
BUG=chromium:438972a
Change-Id: Ie4f92483831e0254da8c7326ffcfc8228edfea7f
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264860
Reviewed-by: Lee Campbell <leecam@chromium.org>
|
|
commit 4e2024624e678f0ebb916e6192bd23c1f9fdf696 upstream.
We didn't check length of rock ridge ER records before printing them.
Thus corrupted isofs image can cause us to access and print some memory
behind the buffer with obvious consequences.
Reported-and-tested-by: Carl Henrik Lunde <chlunde@ping.uio.no>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from v3.10.y commit 684f4c093f182756a1c1f582c415d3120cc7f5e8)
TEST=cbuildbot + manual boot
BUG=chromium:448687b
Change-Id: I84cdb0d2698d5adb07b1d8bb9e548d8af07f6eb5
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264859
Reviewed-by: Lee Campbell <leecam@chromium.org>
|
|
commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream.
When a key is being garbage collected, it's key->user would get put before
the ->destroy() callback is called, where the key is removed from it's
respective tracking structures.
This leaves a key hanging in a semi-invalid state which leaves a window open
for a different task to try an access key->user. An example is
find_keyring_by_name() which would dereference key->user for a key that is
in the process of being garbage collected (where key->user was freed but
->destroy() wasn't called yet - so it's still present in the linked list).
This would cause either a panic, or corrupt memory.
Fixes CVE-2014-9529.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from v3.10.y commit a7033e302dcd38bb4333f46b3fdcd930955e402d)
TEST=cbuildbot + manual boot
BUG=chromium:448687a
Change-Id: I044a50991c0dcbfc6a1048bd0e2b2df52acf9a32
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264858
Reviewed-by: Lee Campbell <leecam@chromium.org>
|
|
commit ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce upstream.
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.
This disallows anybody without CAP_SYS_ADMIN to read the pagemap.
[1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
[ Eventually we might want to do anything more finegrained, but for now
this is the simple model. - Linus ]
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mark Seaborn <mseaborn@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(backported from v3.14.y commit 26f7f4d46a2cbfa6fbb633d228ec34cf969589d5)
TEST=cbuildbot + manual boot
BUG=chromium:468842
Change-Id: I4fb406112524d4cbe1fdb52cdb23d31c640536fc
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264857
Reviewed-by: Kees Cook <keescook@chromium.org>
|
|
Memory is leaked after downloading already processed packet. This
patch fixes the problem by freeing returned skb. Other transmit
paths don't have this problem.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/246005
Reviewed-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I8e681ea3cfcd547cd0becfda62b00d1f34071c25
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277994
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
Ignore scan and connection requests from cfg80211 when driver
unload is in process or previous command has timed out due to
a firmware bug. This patch fixes corner case system crash
issues.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/243473
Reviewed-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I81f838a43786bcfe51cd2e7cc0c2f7d5ef6ce43a
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277993
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
As we are releasing the lock, during next iteration we may end
up getting page fault if other thread has already deleted that
node.
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/239148
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Amitkumar Karwar <akarwar@marvell.com>
Commit-Queue: Amitkumar Karwar <akarwar@marvell.com>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I9bebacd53b0382ce2c553b7a4b3a5a6eadfd62e5
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277992
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
Wakeup pending wait queues in unload path. This will help to avoid
soft lockup issues in corner cases.
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/239147
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Amitkumar Karwar <akarwar@marvell.com>
Commit-Queue: Amitkumar Karwar <akarwar@marvell.com>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I1cc02c4e9573f097166be4a7d95388fc017eb96c
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277991
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
Workqueue needs to be flushed early when removing card, otherwise
soft lockup issue may happen because main_process is triggered by
interrupt while card is being removed.
Signed-off-by: Marc Yang <yangyang@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/239145
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Amitkumar Karwar <akarwar@marvell.com>
Commit-Queue: Amitkumar Karwar <akarwar@marvell.com>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I58c4a7033614c8ef7bf1acd03e9b9a75c0a33804
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277990
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
CL 205831 has missed this line. Add it to match upstream patch:
http://marc.info/?l=linux-wireless&m=140425083601658&w=4
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/206660
Reviewed-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: Ic64b4c2f0733e6a1eec9c2e6eb4c115209a1ed4b
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277839
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
It is observed that when wrong firmware is downloaded for
PCIe card, system hangs for 10 seconds. The reason is mdelay()
is used when firmware status is polled.
Replace mdelay with msleep(non-blocking API) to fix the issue.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
(cherry picked from commit a76b20e5ca8a9ec0b45a4150b4ad19e27dd19699)
Reviewed-on: https://chromium-review.googlesource.com/206432
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Chih-Chung Chang <chihchung@chromium.org>
Commit-Queue: Chih-Chung Chang <chihchung@chromium.org>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: Ic3d7335342c6a8ca4dbea03c4d0eacd54e1a2d01
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277895
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
There are few places at the begining of Tx/Rx paths where
tx_info/rx_info is not correctly initialized. This patch
takes care of it.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/205831
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I9912f9f95f4ebfdbea5d5f35b3bdeb98951a7d37
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277894
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
While receiving a packet on SDIO interface, we allocate skb with
size multiple of SDIO block size. We need to resize this skb
after RX using packet length from RX header.
Cc: <stable@vger.kernel.org>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewed-on: https://chromium-review.googlesource.com/203425
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I3403477feca603d6a5355d50cfa415dd8ece6467
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277893
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
When command timeout occurs due to a firmware/hardware bug,
there is no chance of next command being successful. We will
keep cmd_sent flag on so that next command won't be sent to
firmware.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/195744
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I59a1a9eb87b7d7396756362e56e5347cc4832d58
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277892
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
This patch adds a check in command preparation routine.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewed-on: https://chromium-review.googlesource.com/195743
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: Idac9b999e153fab2449794cb7f8afb34dfc77069
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277891
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
IE's are parsed from beacon buffer and stored locally using
mwifiex_update_bss_desc_with_ie() function.
Sometimes the local pointers point to the data inside IE, but
while using them it is assumed that they are pointing to the IE
itself.
These issues are fixed in this patch.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/195668
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: I40fc4cdfb5926f99b7a79d888068feca82631a51
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277890
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
|
[ 6630.450908] BUG: spinlock bad magic on CPU#1,
ksdioirqd/mmc1/355
[ 6630.450914] Unable to handle kernel NULL pointer dereference
at virtual address 0000004f
[ 6630.450919] pgd = ecbd8000
[ 6630.450926] [0000004f] *pgd=00000000
[ 6630.450936] lock: 0xeea4ab08, .magic: 00000000,
.owner: <none>/-1, .owner_cpu: 0
[ 6630.450939] Backtrace:
[ 6630.450956] [<c010d354>] (unwind_backtrace+0x0/0x118) from
[<c060c238>] (dump_stack+0x28/0x30)
[ 6630.450960] Internal error: Oops: 5 [#1] SMP ARM
[ 6630.450964] Modules linked in: uvcvideo videobuf2_vmalloc
[ 6630.450980] [<c060c238>] (dump_stack+0x28/0x30) from
[<c0315ab4>] (spin_dump+0x80/0x94)
[ 6630.450988] [<c0315ab4>] (spin_dump+0x80/0x94) from
[<c0315af4>] (spin_bug+0x2c/0x30)
[ 6630.450996] [<c0315af4>] (spin_bug+0x2c/0x30) from
[<c0315b80>] (do_raw_spin_lock+0x28/0x15c)
[ 6630.451004] [<c0315b80>] (do_raw_spin_lock+0x28/0x15c) from
[<c0610c24>] (_raw_spin_lock_irqsave+0x20/0x28)
[ 6630.451016] [<c0610c24>] (_raw_spin_lock_irqsave+0x20/0x28)
from [<bf07a7f4>] (mwifiex_exec_next_cmd
+0x6c/0x45c [mwifiex])
[ 6630.451030] [<bf07a7f4>] (mwifiex_exec_next_cmd+0x6c/0x45c
[mwifiex]) from [<bf07834c>]
(mwifiex_main_process+0x2c8/0x464 [mwifiex])
[ 6630.451047] [<bf07834c>] (mwifiex_main_process+0x2c8/0x464
[mwifiex]) from [<bf0a093c>]
(mwifiex_sdio_interrupt+0xc8/0x1cc [mwifiex_sdio]
[ 6630.451064] [<bf0a093c>] (mwifiex_sdio_interrupt+0xc8/0x1cc
[mwifiex_sdio]) from [<c04bbde0>]
(sdio_irq_thread+0x178/0x31c)
[ 6630.451079] [<c04bbde0>] (sdio_irq_thread+0x178/0x31c) from
[<c0145514>] (kthread+0xc8/0xd8)
[ 6630.451095] [<c0145514>] (kthread+0xc8/0xd8) from
[<c0106118>] (ret_from_fork+0x14/0x20)
This bug has introduced/exposed due to recent patch in which we
cancel pending commands before suspend (using hs_enabling flag).
The NULL pointer is dereferenced when both
mwifiex_cancel_all_pending_cmd() and mwifiex_exec_next_cmd()
try to access cmd pending queue simultaneously.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/192050
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: hyuckjoo lee <hyuckjoolee345@gmail.com>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:40159
TEST=We have ported some critical fixes from wireless-3.8 to
wireless-3.4. With this patch series applied, ran autotests and
no regression found.
Change-Id: Ia4bcc8b642d18dfacf9c70086d9f2d5692cf1ab8
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/277889
Reviewed-by: Rebecca Silberstein <silberst@chromium.org>
|
