Currently llist_for_each_entry() and llist_for_each_entry_safe() iterate
until &pos->member != NULL. But when building the kernel with Clang,
the compiler assumes &pos->member cannot be NULL if the member's offset
is greater than 0 (which would be equivalent to the object being
non-contiguous in memory). Therefore the loop condition is always true,
and the loops become infinite.
To work around this, introduce the member_address_is_nonnull() macro,
which casts object pointer to uintptr_t, thus letting the member pointer
to be NULL.
Change-Id: I1f9541591bba1f2ca16ecbb0248555298df4bee5
Fixes: 64082472
Signed-off-by: Alexander Potapenko <glider@google.com>
Tested-by: Sodagudi Prasad <psodagud@codeaurora.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Original patch was cherry-picked from 3.18 kernel,
commit 324181821c790ca02a2180ff01576d3c4d15fa6d
("Move sync logic to be run always") and reworked to account for
differences in want_affine calculations.
Lift sync logic out of select_energy_cpu_brute() and run that logic before
select_idle_sibling() or select_energy_cpu_brute().
At high CPU utilization, the scheduler falls back to
select_idle_sibling(). On Marlin, select_idle_sibling() wasn't
respecting the sync flag to force the task to be scheduled on the same
CPU. This caused the sync flag to be ignored and thrash on binder with
sync enabled. This fixes the thrash we saw.
Bug 38260530
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I1ecd8de6af010248ebc9daa5f80689f521500fc9
When CONFIG_THREAD_INFO_IN_TASK is selected, the current_thread_info()
macro relies on current having been defined prior to its use. However,
not all users of current_thread_info() include <asm/current.h>, and thus
current is not guaranteed to be defined.
When CONFIG_THREAD_INFO_IN_TASK is not selected, it's possible that
get_current() / current are based upon current_thread_info(), and
<asm/current.h> includes <asm/thread_info.h>. Thus always including
<asm/current.h> would result in circular dependences on some platforms.
To ensure both cases work, this patch includes <asm/current.h>, but only
when CONFIG_THREAD_INFO_IN_TASK is selected.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 64672701
Change-Id: Ia981a829798d60a54d4e3eb679d8e24b01228357
(cherry picked from commit dc3d2a679cd8631b8a570fc8ca5f4712d7d25698)
Signed-off-by: Zubin Mithra <zsm@google.com>
Since commit f56141e3e2 ("all arches, signal: move restart_block
to struct task_struct"), thread_info and restart_block have been
logically distinct, yet struct restart_block is still defined in
<linux/thread_info.h>.
At least one architecture (erroneously) uses restart_block as part of
its thread_info, and thus the definition of restart_block must come
before the include of <asm/thread_info>. Subsequent patches in this
series need to shuffle the order of includes and definitions in
<linux/thread_info.h>, and will make this ordering fragile.
This patch moves the definition of restart_block out to its own header.
This serves as generic cleanup, logically separating thread_info and
restart_block, and also makes it easier to avoid fragility.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 64672701
Change-Id: I4283c87072c092179e2b6c02cbf7248b4a1c2d22
(cherry picked from commit 53d74d056a4e306a72b8883d325b5d853c0618e6)
Signed-off-by: Zubin Mithra <zsm@google.com>
The INIT_TASK() initializer was similarly confused about the stack vs
thread_info allocation that the allocators had, and that were fixed in
commit b235beea9e99 ("Clarify naming of thread info/stack allocators").
The task ->stack pointer only incidentally ends up having the same value
as the thread_info, and in fact that will change.
So fix the initial task struct initializer to point to 'init_stack'
instead of 'init_thread_info', and make sure the ia64 definition for
that exists.
This actually makes the ia64 tsk->stack pointer be sensible for the
initial task, but not for any other task. As mentioned in commit
b235beea9e99, that whole pointer isn't actually used on ia64, since
task_stack_page() there just points to the (single) allocation.
All the other architectures seem to have copied the 'init_stack'
definition, even if it tended to be generally unusued.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 64672701
Change-Id: Ia96e9225b07e38df2f4af2b9a7eb2aa972d8845a
(cherry picked from commit 7f1a00b6fcd0e3c19beba2e92d157dc0c2cf3494)
Signed-off-by: Zubin Mithra <zsm@google.com>
We've had the thread info allocated together with the thread stack for
most architectures for a long time (since the thread_info was split off
from the task struct), but that is about to change.
But the patches that move the thread info to be off-stack (and a part of
the task struct instead) made it clear how confused the allocator and
freeing functions are.
Because the common case was that we share an allocation with the thread
stack and the thread_info, the two pointers were identical. That
identity then meant that we would have things like
ti = alloc_thread_info_node(tsk, node);
...
tsk->stack = ti;
which certainly _worked_ (since stack and thread_info have the same
value), but is rather confusing: why are we assigning a thread_info to
the stack? And if we move the thread_info away, the "confusing" code
just gets to be entirely bogus.
So remove all this confusion, and make it clear that we are doing the
stack allocation by renaming and clarifying the function names to be
about the stack. The fact that the thread_info then shares the
allocation is an implementation detail, and not really about the
allocation itself.
This is a pure renaming and type fix: we pass in the same pointer, it's
just that we clarify what the pointer means.
The ia64 code that actually only has one single allocation (for all of
task_struct, thread_info and kernel thread stack) now looks a bit odd,
but since "tsk->stack" is actually not even used there, that oddity
doesn't matter. It would be a separate thing to clean that up, I
intentionally left the ia64 changes as a pure brute-force renaming and
type change.
Acked-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 64672701
Change-Id: I870b5476fc900c9145134f9dd3ed18a32a490162
(cherry picked from commit b235beea9e996a4d36fed6cfef4801a3e7d7a9a5)
Signed-off-by: Zubin Mithra <zsm@google.com>
Adds:
-Per task nodes in /proc/PID/time_in_state showing per
frequency(state)/cluster(policy) times
-Global /proc/uid_time_in_state showing per uid/frequency/cluster
times including uid removal from /proc/uid_cputime/remove_uid_range
-Global all_time_in_state showing per frequency/cluster/cpu times
Bug: 62303881
Bug: 62340637
Tests: Reading /proc/$$/time_in_state, /proc/uid_time_in_state, and
/sys/devices/system/cpu/cpufreq/all_time_in_state. Writing
/proc/uid_cputime/remove_uid_range
Change-Id: I222843b6f714717da9377817c19ac0d5400cb41a
Signed-off-by: Andres Oportus <andresoportus@google.com>
When the charger is connected, ta_detect_pin setting high.
When the charger is disconnected, ta_detect_pin setting low.
Bug: 63785418
Change-Id: Iff4e735eac9eb344bfa2734a981f45be6e38a458
Signed-off-by: jonghyun26.kim <jonghyun26.kim@lge.com>
Signed-off-by; Devin Kim <dojip.kim@lge.com>
If the first parameter of container_of() is a pointer to a
non-const-qualified array type (and the third parameter names a
non-const-qualified array member), the local variable __mptr will be
defined with a const-qualified array type. In ISO C, these types are
incompatible. They work as expected in GNU C, but some versions will
issue warnings. For example, GCC 4.9 produces the warning
"initialization from incompatible pointer type".
Here is an example of where the problem occurs:
-------------------------------------------------------
MODULE_LICENSE("GPL");
struct st {
int a;
char b[16];
};
static int __init example_init(void) {
struct st t = { .a = 101, .b = "hello" };
char (*p)[16] = &t.b;
struct st *x = container_of(p, struct st, b);
printk(KERN_DEBUG "%p %p\n", (void *)&t, (void *)x);
return 0;
}
static void __exit example_exit(void) {
}
module_init(example_init);
module_exit(example_exit);
-------------------------------------------------------
Building the module with gcc-4.9 results in these warnings (where '{m}'
is the module source and '{k}' is the kernel source):
-------------------------------------------------------
In file included from {m}/example.c:1:0:
{m}/example.c: In function `example_init':
{k}/include/linux/kernel.h:854:48: warning: initialization from
incompatible pointer type
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
{m}/example.c:14:17: note: in expansion of macro `container_of'
struct st *x = container_of(p, struct st, b);
^
{k}/include/linux/kernel.h:854:48: warning: (near initialization
for `x')
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
{m}/example.c:14:17: note: in expansion of macro `container_of'
struct st *x = container_of(p, struct st, b);
^
-------------------------------------------------------
Replace the type checking performed by the macro to avoid these
warnings. Make sure `*(ptr)` either has type compatible with the
member, or has type compatible with `void`, ignoring qualifiers.
Raise
compiler errors if this is not true. This is stronger than the
previous
behaviour, which only resulted in compiler warnings for a type
mismatch.
[arnd@arndb.de: fix new warnings for container_of()]
Link: http://lkml.kernel.org/r/20170620200940.90557-1-arnd@arndb.de
Link: http://lkml.kernel.org/r/20170525120316.24473-7-abbotti@mev.co.uk
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Michal Nazarewicz <mina86@mina86.com>)
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Alexander Potapenko <glider@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 62057517
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: Idab195e2b20ae0ca2e405dd8a0c6744f5e381ef8
jiffies_64 is defined in kernel/time/timer.c with
____cacheline_aligned_in_smp, however this macro is not part of the
declaration of jiffies and jiffies_64 in jiffies.h.
As a result clang generates the following warning:
kernel/time/timer.c:57:26: error: section does not match previous declaration [-Werror,-Wsection]
__visible u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;
^
include/linux/cache.h:39:36: note: expanded from macro '__cacheline_aligned_in_smp'
^
include/linux/cache.h:34:4: note: expanded from macro '__cacheline_aligned'
__section__(".data..cacheline_aligned")))
^
include/linux/jiffies.h:77:12: note: previous attribute is here
extern u64 __jiffy_data jiffies_64;
^
include/linux/jiffies.h:70:38: note: expanded from macro '__jiffy_data'
Change-Id: I1fa0d6640f9d3a3624c7b3cff5765095fbe89455
Link: http://lkml.kernel.org/r/20170403190200.70273-1-mka@chromium.org
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Cc: "Jason A . Donenfeld" <Jason@zx2c4.com>
Cc: Grant Grundler <grundler@chromium.org>
Cc: Michael Davidson <md@google.com>
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 62057517
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Introduce POWER_SUPPLY_PROP_PR_SWAP to notify if the device is in
power role swap.
Bug: 63171186
Change-Id: I8d0cb3a71ec1a646b7ec37405e66cb00ddc40e0d
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
This patch allows the ramoops to read previous logs from an
AES encrypted location while still allowing writes to the
current log.
This is used to allow the backing store to be encrypted and
then written to disk by the bootloader. The keys to decrypt
are loaded by userspace and then pstore is remounted to
force a reload of the now decrypted backing store.
Bug: 37554629
Bug: 37553996
Change-Id: Ieb7615d22bdfbf2130a0f6ca1b4038ffdf2fe338
Signed-off-by: Patrick Tjin <pattjin@google.com>
Disable the SMMU stalls on faulty transactions by terminating it using
the CB.SCTLR register. Faulty transaction on a CB causes the back
pressure on the QSMMU transaction pipe which inturn affect the other
masters using the same SMMU. Pass the DOMAIN_ATTR_CB_STALL_DISABLE flag
to iommu_domain_set_attr api in order to use this feature.
Bug: 63539182
Change-Id: Ib8fa35854ff24e0295d330c5fb79375f58c3e841
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
cherry-picked from 3.18 kernel, commit 324181821c790ca02a2180ff01576d3c4d15fa6d ("Move sync logic to be run always")
Lift sync logic out of select_energy_cpu_brute() and run that logic before
select_idle_sibling() or select_energy_cpu_brute().
At high CPU utilization, the scheduler falls back to
select_idle_sibling(). On Marlin, select_idle_sibling() wasn't
respecting the sync flag to force the task to be scheduled on the same
CPU. This caused the sync flag to be ignored and thrash on binder with
sync enabled. This fixes the thrash we saw.
Bug 38260530
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I5b5552e87b76028328b6f6439f11dc7de43fdfc0
Signed-off-by: Joel Fernandes <joelaf@google.com>
For some time critical tasks, the thread priority
might need to be upgraded to Real-Time Thread
priority level. Expose an interface from APR layer
so that clients can vote for a priority upgrade
whenever needed.
Bug: 38234822
Change-Id: Ieb4afa914905750eccdf7672020a8751fdcf6462
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Debugging patch to help look for freezing issues
that are speculatively blamed (based on previous
examples) on the kernel failing to schedule some
threads for long periods of time.
Bug: 63331203
Change-Id: I2c48362aa948275f31776478daf6751f29cd11d0
Signed-off-by: John Dias <joaodias@google.com>
commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.
Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.
This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.
Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.
One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications. For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).
Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.
Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.
Original-patch-by: Oleg Nesterov <oleg@redhat.com>
Original-patch-by: Michal Hocko <mhocko@suse.com>
Bug: 38413813
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Tested-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[wt: backport to 4.11: adjust context]
[wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide]
[wt: backport to 4.4: adjust context ; drop ppc hugetlb_radix changes]
Signed-off-by: Willy Tarreau <w@1wt.eu>
[gkh: minor build fixes for 4.4]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I9b4bb1015ae7604736ce3d9526b34fe9536522c5
Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused
static inline functions") just caused more warnings due to re-defining
the 'inline' macro.
So undef it before re-defining it, and also add the 'notrace'
attribute like the gcc version that this is overriding does.
Maybe this makes clang happier.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 32455818
BUg: 33244601
Change-Id: I8346d290a8d766445c84261a4334db876bb2e014
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
GCC explicitly does not warn for unused static inline functions for
-Wunused-function. The manual states:
Warn whenever a static function is declared but not defined or a
non-inline static function is unused.
Clang does warn for static inline functions that are unused.
It turns out that suppressing the warnings avoids potentially
complex #ifdef directives, which also reduces LOC.
Suppress the warning for clang.
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 32455818
BUg: 33244601
Change-Id: I31a7ff4b828538a66d439203be8965c3d53e6763
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
The motivation for commit abb2ea7dfd82 ("compiler, clang: suppress
warning for unused static inline functions") was to suppress clang's
warnings about unused static inline functions.
For configs without CONFIG_OPTIMIZE_INLINING enabled, such as any
non-x86
architecture, `inline' in the kernel implies that
__attribute__((always_inline)) is used.
Some code depends on that behavior, see
https://lkml.org/lkml/2017/6/13/918:
net/built-in.o: In function `__xchg_mb':
arch/arm64/include/asm/cmpxchg.h:99: undefined reference to
`__compiletime_assert_99'
arch/arm64/include/asm/cmpxchg.h:99: undefined reference to
`__compiletime_assert_99
The full fix would be to identify these breakages and annotate the
functions with __always_inline instead of `inline'. But since we are
late in the 4.12-rc cycle, simply carry forward the forced inlining
behavior and work toward moving arm64, and other architectures, toward
CONFIG_OPTIMIZE_INLINING behavior.
Link:
http://lkml.kernel.org/r/alpine.DEB.2.10.1706261552200.1075@chino.kir.corp.google.com
Signed-off-by: David Rientjes <rientjes@google.com>
Reported-by: Sodagudi Prasad <psodagud@codeaurora.org>
Tested-by: Sodagudi Prasad <psodagud@codeaurora.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>`
Bug: 32455818
Change-Id: I0a8c688970440a80c907b257ed8ac57aaffbff8e
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
fix power on sequence
touch_1.8v high -> >10ms delay -> reset_pin high
Bug: 63576441
Change-Id: Ifd8387a4b8a6c49a4e7fbaa376e7c3430391bffb
Signed-off-by: keunyoung1.park <keunyoung1.park@lge.com>
Signed-off-by: Steve Pfetsch <spfetsch@google.com>
This function allows the port's scheduling policy to be changed. Some
tty ports (like Bluetooth ones), need a higher priority to reduce
jitter.
Bug: 36106419
Test: Bluetooth audio
Change-Id: If11e21c55924314910d602573c735c6afae09709
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This makes each tty_port have their own kthread, hopefully allowing them
a bit more freedom in scheduling when they reveive data.
Based on a patch from Philip Cuadra <philipcuadra@google.com>
Based on a patch from Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 36106419
Test: run Bluetooth audio, ensure separate tty thread is created.
Signed-off-by: Philip Cuadra <philipcuadra@google.com>
Change-Id: I9fd25235b26a66acb37a40304c356209b74ad46c
Allows thermal max freq notification to the scheduler without
interfacing it with the thermal driver. Adds a new "transient"
field in the cpufreq policy to be notified by thermals and consumed
by the scheduler. Note that this could be expanded for other
notifiers and consumers, in this CL though the intent is
only to allow thermals including a HW engine to notify
a transient value to be used by the scheduler but not by
the governor.
Signed-off-by: Andres Oportus <andresoportus@google.com>
Bug: 37716228
Test: Check that under thermal throttling the scheduler reports
less capacity in use as in:
2017-06-13 17:23:05>as 'dmesg|grep CPU|tail -1'
[ 449.193273] CPU7: update max cpu_capacity 984
Change-Id: I13ddd3d62db765dc3b47ccaddeacfd92f79c5a2a
Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use
tty_port_close") created a case where a port used for a console does not
get shutdown on tty closing. Then a call to uart_tx_stopped() segfaults
because the tty is NULL. This could be fixed to restore old behavior,
but we also want to allow tty_ports to work without a tty attached. So
this change to allow a NULL tty_struct is needed either way.
Bug: 62912956
Change-Id: Ia44bff00c1136bc7d7c7489638344860c819de99
Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close")
Reported-by: kernel test robot <xiaolong.ye@intel.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Siqi Lin <siqilin@google.com>
The clang compiler treats the memory address of a structure field as
tautologically true when compared to non-NULL. This breaks the macros
in llist.h when compiled using clang. Fix this by not comparing the
address of a structure field to NULL when determining the end of the
llist. Refer to -Wtautological-pointer-compare in clang for more
information.
Bug: 32455818
Change-Id: I1732c543bebcd5c012b9a3e84d6613a973c82ae0
Signed-off-by: Hans Petter Selasky <hps@selasky.org>
Signed-off-by: Bernhard Rosenkränzer <bero@linaro.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
While executing tuning in case CMD19 fails, the driver sends CMD13
multiple times to ensure the card is ready to receive the next tuning
command. If this status command fails with CRC error, it will trigger
tuning. This will result in back to back tuning multiple times.
To avoid this situation, ignore CRCs error generated with CMD13 while
executing tuning.
Change-Id: Ife338768264ebebebc655fe11874e905abdf7482
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
This commit syncs the version of type-c stack including TCPM,
Type-C connector class to align with commit
4cec1d769e7be15b335484565d712b85a993c9b1 in marlin tree, which
further aligns with mainline staging tree commit
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/
commit/?h=typec&id=8edc2421f1fa24dd4d8055b8df7ad651d3002c92,
plus commits in marlin tree that is pending upstreaming:
4cec1d769e7b usb: typec: allow tcpm logs to overflow
487d4d6b5d47 usb: typec: Check for port type for Try.SRC/Try.SNK
335c421a423e usb: typec: tcpm set port type callback
439432bfb5ee usb: typec: Add a sysfs node to manage port type
(This commit has been upstreamed: https://git.kernel.org/pub/scm/
linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=
bab3548078237706f53baafe43ae58257225549d)
Bug: 62272992
Change-Id: I9a209d95328f9439c5aed6c9509128d9f4f2610b
Signed-off-by: Yueyao Zhu <yueyao@google.com>
Use a separate table to store the platform specific clock-scaling
frequencies.
The generic table where these frequencies used to be stored, would
get updated (in some cases) during clock scaling initialization.
But when a new card is inserted (In the case of a removable card),
the frequencies supported by the card should be compared against the
platform specific frequencies.
By storing these values in a separate table, these values would
remain intact and this table can be used for initializing the
generic table during clock-scaling initialization.
Change-Id: I5729f18a975f849bc2965a946473a9cdbd81e94a
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
