When powering off the whole system, we should power off some external
subsystems' connection firstly, otherwise some external subsystems
will hold some power and result in powering down abnormally.
bug: 146864653
Signed-off-by: Sherry Zong <sherry.zong@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
(cherry picked from commit 6cdd5b09cbe67365c42aee539f6fd00f2ecfdaab
https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git for-next)
Add the POWER_SUPPLY_PROP_CHARGE_NOW attribute to allow user to get
current battery capacity (uAh) to do measurement.
bug: 146864653
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
(cherry picked from commit 1c5dfc5e3f2df5892a849621d729daa87cfef436
https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git for-next)
There are some deviations between the real resistance and the ideal
resistance of coulomb counter, which will affect the accuracy of
the coulomb counter, thus calibrate the real resistance of coulomb
counter to improve the accuracy.
bug: 146864653
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
(cherry picked from commit 058d42563a5692a4e663df0dc270f4ffd2c70274)
Add a new property to describe the real resistance of coulomb counter chip,
which is used to calibrate the accuracy of the coulomb counter chip.
bug: 146864653
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
(cherry picked from commit 7772d22e4b0681b5d0ff1bf4127c1b35e7641d07)
Optimize the battery internal resistance in a certain temerature to
get a accurate battery internal resistance.
bug: 146864653
Signed-off-by: Yuanjiang Yu <yuanjiang.yu@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
(cherry picked from commit 6af8288834b6a9dfcbe9847b675ff24d39d30679)
Since the battery internal resistance can be changed with the temperature
changes, thus add a resistance temperature table support to look up
the accurate battery internal resistance in a certain temperature.
bug: 146864653
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
(cherry picked from commit 65dbad713d5d6a8581921804ae3f5eb4a9bf032e)
Since the battery internal resistance can be changed as the temperature
changes, thus add one table to describe the battery resistance percent
in different temperatures to get a accurate battery internal resistance.
bug: 146864653
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
(cherry picked from commit 9a056a879111f88149dad428e7cc4f85c87a62bc)
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct icc_path at core.c:50:1' changed:
type size changed from 64 to 128 (in bits)
1 data member insertion:
'const char* icc_path::name', at offset 0 (in bits) at internal.h:37:1
there are data member changes:
'size_t icc_path::num_nodes' offset changed from 0 to 64 (in bits) (by +64 bits)
'icc_req icc_path::reqs[]' offset changed from 64 to 128 (in bits) (by +64 bits)
3 impacted interfaces:
function void icc_put(icc_path*)
function int icc_set_bw(icc_path*, u32, u32)
function icc_path* of_icc_get(device*, const char*)
Bug: 151255205
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I01a15b1dee23268381aa2b8b067c1687054481fa
When we allocate memory, kasprintf() can fail and we must check its
return value.
Bug: 151255205
Fixes: 05309830e1f8 ("interconnect: Add a name to struct icc_path")
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Link: https://lore.kernel.org/r/20200226110420.5357-2-georgi.djakov@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3791163602f7140011a8dc1691cfe6ec0cb1ef07)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3eced73454428bf486e511cb5065f4b75bdfe3c4
The tracepoints can help with understanding the system behavior of a
given interconnect path when the consumer drivers change their bandwidth
demands. This might be interesting when we want to monitor the requested
interconnect bandwidth for each client driver. The paths may share the
same nodes and this will help to understand "who and when is requesting
what". All this is useful for subsystem drivers developers and may also
provide hints when optimizing the power and performance profile of the
system.
Bug: 151255205
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
(cherry picked from commit c46ab9db64979b0875fff79e1b00013343ca8286)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia2276cc83a2a73c66207bdf14b87402b96d623a7
When debugging interconnect things, it turned out that saving the path
name and including it in the traces is quite useful, especially for
devices with multiple paths.
For the path name we use the one specified in DT, or if we use platform
data, the name is based on the source and destination node names.
Bug: 151255205
Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
(cherry picked from commit 05309830e1f869f939e283576dd3684313390062)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I81ef3e94092682e8ca986f4dafce03be46e28218
Move the interconnect framework internal structs into a separate file,
so that it can be included and used by ftrace code. This will allow us
to expose some more useful information in the traces.
Bug: 151255205
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
(cherry picked from commit dd018a9cf9108f9c7d924f6fe09aed745e78a67e)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I913023038160d36c75dec1d04c89cd4671977321
kallsyms_lookup_name() and kallsyms_on_each_symbol() are exported to
modules despite having no in-tree users and being wide open to abuse by
out-of-tree modules that can use them as a method to invoke arbitrary
non-exported kernel functions.
Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol().
Bug: 149978696
Change-Id: I8f3c1b5222939c46901f4d149d4c7bb63916ff04
Link: http://lkml.kernel.org/r/20200221114404.14641-4-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Quentin Perret <qperret@google.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit ab3e66797c7fddbf80fbba31c5bf4574ad52f320
https://github.com/hnaz/linux-mm.git master)
Signed-off-by: Quentin Perret <qperret@google.com>
The 'data_breakpoint' test code is the only modular user of
kallsyms_lookup_name(), which was exported as part of fixing the test in
f60d24d2ad ("hw-breakpoints: Fix broken hw-breakpoint sample module").
In preparation for un-exporting this symbol, switch the test over to using
__symbol_get(), which can be used to place breakpoints on exported
symbols.
Bug: 149978696
Change-Id: I589142af97a34484f9fa551b934148f445b33243
Link: http://lkml.kernel.org/r/20200221114404.14641-3-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Quentin Perret <qperret@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit e108898157d888c827a7176e02648cc3bd87025b
https://github.com/hnaz/linux-mm.git master)
Signed-off-by: Quentin Perret <qperret@google.com>
Patch series "Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()".
Despite having just a single modular in-tree user that I could spot,
kallsyms_lookup_name() is exported to modules and provides a mechanism
for out-of-tree modules to access and invoke arbitrary, non-exported
kernel symbols when kallsyms is enabled.
This patch series fixes up that one user and unexports the symbol along
with kallsyms_on_each_symbol(), since that could also be abused in a
similar manner.
I would like to avoid out-of-tree modules being easily able to call
functions that are not exported. kallsyms_lookup_name() makes this
trivial to the point that there is very little incentive to rework these
modules to either use upstream interfaces correctly or propose
functionality which may be otherwise missing upstream. Both of these
latter solutions would be pre-requisites to upstreaming these modules, and
the current state of things actively discourages that approach.
The background here is that we are aiming for Android devices to be able
to use a generic binary kernel image closely following upstream, with any
vendor extensions coming in as kernel modules. In this case, we (Google)
end up maintaining the binary module ABI within the scope of a single LTS
kernel. Monitoring and managing the ABI surface is not feasible if it
effectively includes all data and functions via kallsyms_lookup_name().
Of course, we could just carry this patch in the Android kernel tree, but
we're aiming to carry as little as possible (ideally nothing) and I think
it's a sensible change in its own right. I'm surprised you object to it,
in all honesty.
Now, you could turn around and say "that's not upstream's problem", but it
still seems highly undesirable to me to have an upstream bypass for
exported symbols that isn't even used by upstream modules. It's ripe for
abuse and encourages people to work outside of the upstream tree. The
usual rule is that we don't export symbols without a user in the tree and
that seems especially relevant in this case.
Joe Lawrence said:
: FWIW, kallsyms was historically used by the out-of-tree kpatch support
: module to resolve external symbols as well as call set_memory_r{w,o}()
: API. All of that support code has been merged upstream, so modern kpatch
: modules* no longer leverage kallsyms by default.
:
: That said, there are still some users who still use the deprecated support
: module with newer kernels, but that is not officially supported by the
: project.
This patch (of 3):
Given the name of a kernel symbol, the 'data_breakpoint' test claims to
"report any write operations on the kernel symbol". However, it creates
the breakpoint using both HW_BREAKPOINT_W and HW_BREAKPOINT_R, which menas
it also fires for read access.
Drop HW_BREAKPOINT_R from the breakpoint attributes.
Bug: 149978696
Change-Id: I12f793136a7187c844841e7dd65b90645d5519f6
Link: http://lkml.kernel.org/r/20200221114404.14641-2-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Quentin Perret <qperret@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 0c1b9251116b972cafa3cf16bd02cb2354535b38
https://github.com/hnaz/linux-mm.git master)
Signed-off-by: Quentin Perret <qperret@google.com>
After FS_IOC_REMOVE_ENCRYPTION_KEY removes a key, it syncs the
filesystem and tries to get and put all inodes that were unlocked by the
key so that unused inodes get evicted via fscrypt_drop_inode().
Normally, the inodes are all clean due to the sync.
However, after the filesystem is sync'ed, userspace can modify and close
one of the files. (Userspace is *supposed* to close the files before
removing the key. But it doesn't always happen, and the kernel can't
assume it.) This causes the inode to be dirtied and have i_count == 0.
Then, fscrypt_drop_inode() failed to consider this case and indicated
that the inode can be dropped, causing the write to be lost.
On f2fs, other problems such as a filesystem freeze could occur due to
the inode being freed while still on f2fs's dirty inode list.
Fix this bug by making fscrypt_drop_inode() only drop clean inodes.
I've written an xfstest which detects this bug on ext4, f2fs, and ubifs.
Fixes: b1c0ec3599 ("fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl")
Cc: <stable@vger.kernel.org> # v5.4+
Link: https://lore.kernel.org/r/20200305084138.653498-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 2b4eae95c7361e0a147b838715c8baa1380a428f)
Bug: 150589360
Test: kvm-xfstests -c ext4,f2fs -g encrypt
Change-Id: Ia32db980c2fffb68caeaf9f38e5cfbe781b45011
Signed-off-by: Eric Biggers <ebiggers@google.com>
This was "default y" but disabled manually because we set
CONFIG_EXPERT=y. Disabling it does not seem to be a big win and we have
had requests to enable it.
Bug: 150871026
Change-Id: I4a7f8da1e8480dc46f168def89016a5152e421ea
Signed-off-by: Alistair Delva <adelva@google.com>
Disable CONFIG_DEBUG_DEVRES to fix ABI differences caused by changes to
devres_alloc_node function when this debug option is enabled.
Bug: 151110905
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I27ba172843c80ffd1dfbcc6cc4d706c5b18eb5d3
Seems no one has done this in a while :(
Leaf changes summary: 5 artifacts changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 4 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
4 Removed functions:
[D] 'function void __this_cpu_preempt_check(const char*)'
[D] 'function unsigned int debug_smp_processor_id()'
[D] 'function void preempt_count_add(int)'
[D] 'function void preempt_count_sub(int)'
'struct task_struct at sched.h:624:1' changed:
type size changed from 29184 to 28672 (in bits)
1 data member deletion:
'unsigned long int task_struct::preempt_disable_ip', at offset 18816 (in bits) at sched.h:1070:1
there are data member changes:
'tlbflush_unmap_batch task_struct::tlb_ubc' offset changed from 18880 to 18816 (in bits) (by -64 bits)
offset changed from 18880 to 18816 (in bits) (by -64 bits)
'pipe_inode_info* task_struct::splice_pipe' offset changed from 19008 to 18944 (in bits) (by -64 bits)
'page_frag task_struct::task_frag' offset changed from 19072 to 19008 (in bits) (by -64 bits)
'int task_struct::nr_dirtied' offset changed from 19200 to 19136 (in bits) (by -64 bits)
'int task_struct::nr_dirtied_pause' offset changed from 19232 to 19168 (in bits) (by -64 bits)
'unsigned long int task_struct::dirty_paused_when' offset changed from 19264 to 19200 (in bits) (by -64 bits)
'u64 task_struct::timer_slack_ns' offset changed from 19328 to 19264 (in bits) (by -64 bits)
'u64 task_struct::default_timer_slack_ns' offset changed from 19392 to 19328 (in bits) (by -64 bits)
'unsigned long int task_struct::trace' offset changed from 19456 to 19392 (in bits) (by -64 bits)
'unsigned long int task_struct::trace_recursion' offset changed from 19520 to 19456 (in bits) (by -64 bits)
'mem_cgroup* task_struct::memcg_in_oom' offset changed from 19584 to 19520 (in bits) (by -64 bits)
'gfp_t task_struct::memcg_oom_gfp_mask' offset changed from 19648 to 19584 (in bits) (by -64 bits)
'int task_struct::memcg_oom_order' offset changed from 19680 to 19616 (in bits) (by -64 bits)
'unsigned int task_struct::memcg_nr_pages_over_high' offset changed from 19712 to 19648 (in bits) (by -64 bits)
'mem_cgroup* task_struct::active_memcg' offset changed from 19776 to 19712 (in bits) (by -64 bits)
'request_queue* task_struct::throttle_queue' offset changed from 19840 to 19776 (in bits) (by -64 bits)
'uprobe_task* task_struct::utask' offset changed from 19904 to 19840 (in bits) (by -64 bits)
'int task_struct::pagefault_disabled' offset changed from 19968 to 19904 (in bits) (by -64 bits)
'task_struct* task_struct::oom_reaper_list' offset changed from 20032 to 19968 (in bits) (by -64 bits)
'vm_struct* task_struct::stack_vm_area' offset changed from 20096 to 20032 (in bits) (by -64 bits)
'refcount_t task_struct::stack_refcount' offset changed from 20160 to 20096 (in bits) (by -64 bits)
'void* task_struct::security' offset changed from 20224 to 20160 (in bits) (by -64 bits)
'thread_struct task_struct::thread' offset changed from 20352 to 20224 (in bits) (by -128 bits)
1372 impacted interfaces:
Change-Id: Ie38f13364e737ee552eb7985e11d6af273c5b12a
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Since cpu_hwcaps and cpu_hwcap_keys are exported symbols, reserve
space in them for any future cpu capabilities or erratas.
Bug: 151154716
Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I35930dd52d98817831d812f35560a2605804a553
Allow charger manager can be built as a module like other charger
drivers.
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/lkml/5e098be25c70e07c37e743f84a901f6f756090e0
.1583461755.git.baolin.wang7@gmail.com/
(cherry picked from commit 241eaabc3c315cdfea505725a43de848f498527f
https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next)
Bug: 148055746
Signed-off-by: Orson Zhai <orson.zhai@unisoc.com>
Change-Id: I2dbe3d09a4779c64ca2508417e819428638a3629
We don't need this. So disable to improve the ABI diff with vendors.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 148870985
Test: compile test
Change-Id: I70690c8be2c3ffcc77f7c8c1d472be0ffffd0587
Looks like there was a merge issue when pulling the following upstream
change:
https://lore.kernel.org/lkml/7239ddd532e94a4371289f3be23c66a3@codeaurora.org/
Fix so that it correctly calls __alloc_and_insert_iova_best_fit when
best_fit is set.
Bug: 149544392
Change-Id: I6b9992dedf4991dee088e77767e0dc077758b581
Signed-off-by: Liam Mark <lmark@codeaurora.org>
WATCHDOG was enabled, but we forgot about the watchdog core code, so
turn it on as well so that all vendors do not have to enable it in their
configs.
Reported-by: Orson Zhai <orsonzhai@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iac14e304b15f774d52fb07aa65df86f3dd71797f
The UNUSED_KSYMS_WHITELIST feature as been merged in ACK as FROMLIST v5,
but the v6 got recently queued with minor changes.
Align the Android code with what will be merged upstream.
Bug: 148277666
Fixes: c5a5b70cff ("FROMLIST: kbuild: allow symbol whitelisting with
TRIM_UNUSED_KSYMS")
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I41726e3fba6e299bb541f93ae9ac31add0c08b60
This fixes the incorrect failure when enabling project quota on
casefold-enabled file.
Cc: Daniel Rosenberg <drosen@google.com>
Cc: kernel-team@android.com
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Link: https://lore.kernel.org/linux-f2fs-devel/20200307002440.GA7944@google.com/
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: Ib2f8db5e20aabf5a4e6e9ebbc071166e8bd3220f
This is a common config across many devices that we'd like to stablize.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 150877929
Change-Id: Id56250664324ecbac2c1497ab5eb49c3306ee535
Some delays may be required either after gating or before ungating
reference clock for device according to vendor requirements.
Note that in UFS 3.0, the delay time after gating reference
clock can be defined by attribute bRefClkGatingWaitTime. Use the
formal value instead if it can be queried from device.
Bug: 151050916
(cherry picked from commit b3222c326c965f94b2e8e8ac73dc395ca82cd088)
Link: https://lore.kernel.org/r/20200220134848.8807-2-stanley.chu@mediatek.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change-Id: I4e5deff2d358ed62bd8a884eb0d186e5651582eb
Many vendors would like to disable host TX LCC during initialization
flow. Introduce a common function for all users to make drivers easier to
read and maintained. This patch does not change any functionality.
Bug: 151050916
(cherry picked from commit 984eaac133e3d6d993ffd4de9e4bdc2c94de742b)
Link: https://lore.kernel.org/r/20200207070357.17169-3-stanley.chu@mediatek.com
Reviewed-by: Can Guo <cang@codeaurora.org>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change-Id: Ib40f9228475e74377178b41f0ffa6f46470c52e3
MediaTek UFS host requires TX LCC to be disabled on both host and device
sides. This can be done by disabling host's local TX LCC before link
startup. Correct TX LCC disabling timing in MediaTek UFS driver.
Bug: 151050916
(cherry picked from commit 618b4d07a4420ca9f01837f183ce7b1ac0b31307)
Link: https://lore.kernel.org/r/20200207070357.17169-2-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change-Id: Ic37378698fee798462142461a8a9276e8dd3d726
In current UFS driver design, hba->uic_link_state will not be changed after
link enters Hibern8 state by Auto-Hibern8 mechanism. In this case,
reference clock gating will be skipped unless special handling is
implemented in vendor's callbacks.
Support reference clock gating during Auto-Hibern8 period in MediaTek
Chipsets: If link state is already in Hibern8 while Auto-Hibern8 feature is
enabled, gate reference clock in setup_clocks callback.
Bug: 151050916
(cherry picked from commit 722adbbd706569bc547aeb2adcd706f55b2ac6f8)
Link: https://lore.kernel.org/r/20200129105251.12466-5-stanley.chu@mediatek.com
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change-Id: I3df8911962ccbcabf07f7a26135fba4fe6c85b8e
Auto-Hibern8 may be disabled by some vendors or sysfs in runtime even if
Auto-Hibern8 capability is supported by host. If Auto-Hibern8 capability is
supported by host but not actually enabled, Auto-Hibern8 error shall not
happen.
To fix this, provide a way to detect if Auto-Hibern8 is actually enabled
first, and bypass Auto-Hibern8 disabling case in
ufshcd_is_auto_hibern8_error().
Bug: 151050916
(cherry picked from commit 5a244e0ea67b293abb1d26c825db2ddde5f2862f)
Fixes: 8217444039 ("scsi: ufs: Add error-handling of Auto-Hibernate")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200129105251.12466-4-stanley.chu@mediatek.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change-Id: I04557ed9ad16a22cdf68e455e78dd0b4a7417d60
If system suspend or runtime suspend mode is configured as linkoff state,
phy can be powered off and reference clock can be gated in MediaTek
Chipsets.
At the same time, remove redundant reference clock control in suspend and
resume callbacks because such control can be well-handled in setup_clocks
callback.
Bug: 151050916
(cherry picked from commit 2a06ff207445ddb7aa643751f85c54e7e3895fb4)
Link: https://lore.kernel.org/r/20200129105251.12466-3-stanley.chu@mediatek.com
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change-Id: Ie20657f1cd249ff6356d4a51f0d4dc6af1c2dd00
MediaTek Chipsets can enter proprietary UniPro low-power mode during
suspend while link is in hibern8 state. Make sure leaving low-power mode
before every link startup to prevent lockup in any possible error recovery
path.
At the same time, re-factor related funcitons to improve code readability.
Bug: 151050916
(cherry picked from commit 7742ca797aa79f280853ffd3e7d2e2af3cd317a5)
Link: https://lore.kernel.org/r/20200129105251.12466-2-stanley.chu@mediatek.com
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change-Id: I98a583a0b3e490465a572e45ba64ae5605bb65e1
ufshcd_get_max_pwr_mode() only need to be called once while booting, take
it out from ufshcd_probe_hba() and inline into ufshcd_device_params_init().
Bug: 151050916
(cherry picked from commit 2b35b2adfecd456c98b9828e03900e7be9f1b33d)
Link: https://lore.kernel.org/r/20200120130820.1737-5-huobean@gmail.com
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Change-Id: I45bcece2be78cb76fe5e48179db43a65fec6f58c
This patch has two major non-functionality changes:
1. Take scanning host if-statement out from ufshcd_probe_hba(), and move
into a new added function ufshcd_add_lus(). In this new function
ufshcd_add_lus(), the main functionalitis include: ICC initialization, add
well-known LUs, devfreq initialization, UFS bsg probe and scsi host
scan. The reason for this change is that these functionalities only being
called during booting stage flow ufshcd_init()->ufshcd_async_scan(). In the
processes of error handling and power management ufshcd_suspend(),
ufshcd_resume(), ufshcd_probe_hba() being called, but these functionalitis
above metioned are not hit.
2. Move context of initialization of parameters associated with the UFS
device to a new added function ufshcd_device_params_init(). The reason of
this change is that all of these parameters are used by driver, but only
need to be initialized once when booting. Combine them into an integral
function, make them easier maintain.
Bug: 151050916
(cherry picked from commit 1b9e21412f72d6f89e2bcc5f24b5e9a010c8a74f)
[ Resolved minor conflict in drivers/scsi/ufshcd.c ]
Link: https://lore.kernel.org/r/20200120130820.1737-4-huobean@gmail.com
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Change-Id: I408417f676dc9d5976b5367f0069b38d220776d0
A previous patch 03324507e66c ("driver core: Allow
fwnode_operations.add_links to differentiate errors") forgot to update
all call sites to fwnode_operations.add_links. This patch fixes that.
Legend:
-> Denotes RHS is an optional/potential supplier for LHS
=> Denotes RHS is a mandatory supplier for LHS
Example:
Device A => Device X
Device A -> Device Y
Before this patch:
1. Device A is added.
2. Device A is marked as waiting for mandatory suppliers
3. Device X is added
4. Device A is left marked as waiting for mandatory suppliers
Step 4 is wrong since all mandatory suppliers of Device A have been
added.
After this patch:
1. Device A is added.
2. Device A is marked as waiting for mandatory suppliers
3. Device X is added
4. Device A is no longer considered as waiting for mandatory suppliers
This is the correct behavior.
Fixes: 03324507e66c ("driver core: Allow fwnode_operations.add_links to differentiate errors")
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200222014038.180923-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1745d299af5b373abad08fa29bff0d31dc6aff21
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-next)
Bug: 150980623
Change-Id: I15210d65db4660dd315a09ff18f4499768f24378
The initial patch that added sync_state() support didn't handle the case
where a supplier has no consumers. This was because when a device is
successfully bound with a driver, only its suppliers were checked to see
if they are eligible to get a sync_state(). This is not sufficient for
devices that have no consumers but still need to do device state clean
up. So fix this.
Fixes: fc5a251d0fd7ca90 (driver core: Add sync_state driver/bus callback)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200221080510.197337-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 21eb93f432b1a785df193df1a56a59e9eb3a985f
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus)
Bug: 150980623
Change-Id: I9bebc164f00d7797501f40080c12a04dbe3095b1
This removes the portion of commit c408992c71 ("ANDROID: cpufreq:
times: track per-uid time in state") adding per-UID tracking, while
preserving an added null check in the per-task tracking code.
Bug: 127641090
Signed-off-by: Connor O'Brien <connoro@google.com>
Change-Id: Iae3e0abef32cbbb9fdc674079973040be0060ac7
This removes the portion of commit 4242998e5b ("ANDROID: cpufreq:
times: add /proc/uid_concurrent_{active,policy}_time") adding new
files for per-UID stats while preserving a change to skip accounting
for idle tasks.
Bug: 127641090
Signed-off-by: Connor O'Brien <connoro@google.com>
Change-Id: I1e334dcc71201118aa62115fa5247263e545e8d6
Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
real CRC value of the last edid data block, and write it back.
Current edid CRC calculates routine adds the last CRC byte,
and check if non-zero.
This behavior is not accurate; actually, we need to return
the actual CRC value when corruption is detected.
This commit changes this issue by returning the calculated CRC,
and initiate the required sequence.
Change since v7
- Fix for CI.CHECKPATCH
Change since v6
- Add return check
Change since v5
- Obtain real CRC value before dumping bad edid
Change since v4
- Fix for CI.CHECKPATCH
Change since v3
- Fix a minor typo.
Change since v2
- Rewrite checksum computation routine to avoid duplicated code.
- Rename to avoid confusion.
Change since v1
- Have separate routine for returning real CRC.
Change-Id: I6a67007357e5176994f54c4f30c07f42a2d57bd7
Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
[abhinavk: resolved conflict with android-5.4's drm_dp_helper.h]
Bug: 139653858
Link: https://patchwork.kernel.org/patch/11375865/
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
A newer version of the patch is now available upstream.
This reverts commit 132de0efda.
Bug: 139653858
Change-Id: I5a1816bf843f81eb484a8f28fac13cf9660f62be
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
