Add logic in enable_thermal_genl_check to avoid
thermal-hal being woken up all the time by on-die sensor.
When the temperature of the on-die sensor thermal_zone updates,
the thermal_zone_device_update() will be called to handle thermal
and then the netlink events will be sent
through thermal_notify_tz_trip_().
But there is currently no way to filter thermal_zone
in the thermal_netlink, so many netlink events will be sent
in a short amount of time. Because the on-die sensors
are very sensitive. Their temperature may jump up and down
quickly in a few ms.
Bug: 170682696
Test: boot and thermal-hal can receive thermal genl events from kernel
Change-Id: Idb3f4b07a2a2740c01d8785910878bfe6edc832d
Signed-off-by: davidchao <davidchao@google.com>
Currently when an MMC host driver declares crypto support, the MMC core
passes a keyslot and 32-bit DUN down to the driver in each request.
This is enough for the "standard" eMMC v5.2 crypto (cqhci-crypto).
However some SoCs don't follow this standard. They don't have keyslots
but rather take keys directly, and they support longer DUNs.
To allow such hardware to be supported, modify the MMC core to pass a
pointer to the bio_crypt_ctx along with each request, replacing the
crypto_enabled and data_unit_num fields. This way is more flexible.
Also update cqhci-crypto accordingly to keep it working.
(Not being sent upstream yet because this isn't really useful by itself;
it would need support for hardware that needs it to be upstreamed too.)
Bug: 180886435
Bug: 182283899
Change-Id: I8faf3135f570ca3f2798cf812b4245a5df5515ba
Signed-off-by: Eric Biggers <ebiggers@google.com>
commit 0d8359620d9b ("zram: support page writeback") introduced two
problems. It overwrites writeback_store's return value as kstrtol's
return value, which makes return value zero so user could see zero as
return value of write syscall even though it wrote data successfully.
It also breaks index value in the loop in that it doesn't increase the
index any longer. It means it can write only first starting block index
so user couldn't write all idle pages in the zram so lose memory saving
chance.
This patch fixes those issues.
Link: https://lkml.kernel.org/r/20210312173949.2197662-2-minchan@kernel.org
Fixes: 0d8359620d9b("zram: support page writeback")
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reported-by: Amos Bianchi <amosbianchi@google.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: John Dias <joaodias@google.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 2766f1821600cc7562bae2128ad0b163f744c5d9)
Bug: 182850185
Signed-off-by: Amos Bianchi <amosbianchi@google.com>
Change-Id: I9836b6350727dc4fffc1cc939647235781f0a4ee
Vendor may have its own estimated utilization.
Bug: 170508405
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I6055907de75ace4586c3ad854d40f42e3bf40147
Enable DTPM framework, so that userspace daemons can control the max
power cap for a device.
Bug: 182396925
Change-Id: I7a1bdb658289843af8f4bb6824b424eb76b32143
Signed-off-by: Ram Chandrasekar <quic_rkumbako@quicinc.com>
This change adds the symbols that allow subsystems to collect minidumps.
Bug: 180426943
Change-Id: Idfda557600606aeca0c912ca0b3cedab8ff7c23e
Signed-off-by: Siddharth Gupta <quic_sidgup@quicinc.com>
Commit b0841eefd9 ("configfs: provide exclusion between IO and removals")
uses ->frag_dead to mark the fragment state, thus no bothering with extra
refcount on config_item when opening a file. The configfs_get_config_item
was removed in __configfs_open_file, but not with config_item_put. So the
refcount on config_item will lost its balance, causing use-after-free
issues in some occasions like this:
Test:
1. Mount configfs on /config with read-only items:
drwxrwx--- 289 root root 0 2021-04-01 11:55 /config
drwxr-xr-x 2 root root 0 2021-04-01 11:54 /config/a
--w--w--w- 1 root root 4096 2021-04-01 11:53 /config/a/1.txt
......
2. Then run:
for file in /config
do
echo $file
grep -R 'key' $file
done
3. __configfs_open_file will be called in parallel, the first one
got called will do:
if (file->f_mode & FMODE_READ) {
if (!(inode->i_mode & S_IRUGO))
goto out_put_module;
config_item_put(buffer->item);
kref_put()
package_details_release()
kfree()
the other one will run into use-after-free issues like this:
BUG: KASAN: use-after-free in __configfs_open_file+0x1bc/0x3b0
Read of size 8 at addr fffffff155f02480 by task grep/13096
CPU: 0 PID: 13096 Comm: grep VIP: 00 Tainted: G W 4.14.116-kasan #1
TGID: 13096 Comm: grep
Call trace:
dump_stack+0x118/0x160
kasan_report+0x22c/0x294
__asan_load8+0x80/0x88
__configfs_open_file+0x1bc/0x3b0
configfs_open_file+0x28/0x34
do_dentry_open+0x2cc/0x5c0
vfs_open+0x80/0xe0
path_openat+0xd8c/0x2988
do_filp_open+0x1c4/0x2fc
do_sys_open+0x23c/0x404
SyS_openat+0x38/0x48
Allocated by task 2138:
kasan_kmalloc+0xe0/0x1ac
kmem_cache_alloc_trace+0x334/0x394
packages_make_item+0x4c/0x180
configfs_mkdir+0x358/0x740
vfs_mkdir2+0x1bc/0x2e8
SyS_mkdirat+0x154/0x23c
el0_svc_naked+0x34/0x38
Freed by task 13096:
kasan_slab_free+0xb8/0x194
kfree+0x13c/0x910
package_details_release+0x524/0x56c
kref_put+0xc4/0x104
config_item_put+0x24/0x34
__configfs_open_file+0x35c/0x3b0
configfs_open_file+0x28/0x34
do_dentry_open+0x2cc/0x5c0
vfs_open+0x80/0xe0
path_openat+0xd8c/0x2988
do_filp_open+0x1c4/0x2fc
do_sys_open+0x23c/0x404
SyS_openat+0x38/0x48
el0_svc_naked+0x34/0x38
To fix this issue, remove the config_item_put in
__configfs_open_file to balance the refcount of config_item.
Fixes: b0841eefd9 ("configfs: provide exclusion between IO and removals")
Signed-off-by: Daiyue Zhang <zhangdaiyue1@huawei.com>
Signed-off-by: Yi Chen <chenyi77@huawei.com>
Signed-off-by: Ge Qiu <qiuge@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Bug: 174049066
(cherry picked from commit 14fbbc8297728e880070f7b077b3301a8c698ef9
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master)
Cc: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I745711ed546c1be97360670b77aedfb929bffcec
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add vendor hook for module init, so we can get memory type and
use it to do memory type check for architecture
dependent page table setting.
Bug: 181639260
Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Change-Id: I95b70d7a57994f2548fddfb2290d4c9136f58785
Add vendor hook for bpf, so we can get memory type and
use it to do memory type check for architecture
dependent page table setting.
Bug: 181639260
Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Change-Id: Icac325a040fb88c7f6b04b2409029b623bd8515f
Add vendor hook for creds, so we get the cred information
to monitor cred lifetime.
Bug: 181639260
Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Change-Id: I8f254464e07f9c88336995152479ce91deb13c75
Add vendor hook for avc, so we can get avc_node information
to monitor avc lifetime.
Bug: 181639260
Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Change-Id: Idbebeca926c2cb407264f2872b032e1f18462697
When registering a memslot, we check the size and location of that
memslot against the IPA size to ensure that we can provide guest
access to the whole of the memory.
Unfortunately, this check rejects memslot that end-up at the exact
limit of the addressing capability for a given IPA size. For example,
it refuses the creation of a 2GB memslot at 0x8000000 with a 32bit
IPA space.
Fix it by relaxing the check to accept a memslot reaching the
limit of the IPA space.
Fixes: c3058d5da2 ("arm/arm64: KVM: Ensure memslots are within KVM_PHYS_SIZE")
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Reviewed-by: Andrew Jones <drjones@redhat.com>
Link: https://lore.kernel.org/r/20210311100016.3830038-3-maz@kernel.org
(cherry picked from commit 262b003d059c6671601a19057e9fe1a5e7f23722)
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 178098380
Test: atest VirtualizationHostTestCases on an EL2-enabled device
Change-Id: I82fcfb372b375c2e35997fdc4b33dbd33f056887
KVM/arm64 has forever used a 40bit default IPA space, partially
due to its 32bit heritage (where the only choice is 40bit).
However, there are implementations in the wild that have a *cough*
much smaller *cough* IPA space, which leads to a misprogramming of
VTCR_EL2, and a guest that is stuck on its first memory access
if userspace dares to ask for the default IPA setting (which most
VMMs do).
Instead, blundly reject the creation of such VM, as we can't
satisfy the requirements from userspace (with a one-off warning).
Also clarify the boot warning, and document that the VM creation
will fail when an unsupported IPA size is provided.
Although this is an ABI change, it doesn't really change much
for userspace:
- the guest couldn't run before this change, but no error was
returned. At least userspace knows what is happening.
- a memory slot that was accepted because it did fit the default
IPA space now doesn't even get a chance to be registered.
The other thing that is left doing is to convince userspace to
actually use the IPA space setting instead of relying on the
antiquated default.
Fixes: 233a7cb235 ("kvm: arm64: Allow tuning the physical address size for VM")
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Link: https://lore.kernel.org/r/20210311100016.3830038-2-maz@kernel.org
(cherry picked from commit 7d717558dd5ef10d28866750d5c24ff892ea3778)
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 178098380
Test: atest VirtualizationHostTestCases on an EL2-enabled device
Change-Id: I36332fbe5606affd151976a6354f3e9c45fc214a
This header file is to be used for various macros to help make keeping
the kernel ABI "stable" during an "ABI Freeze" period.
They are to be used both before the freeze (to anticipate places where
there will be changes), and after the freeze (to keep the abi stable for
structures where there were changes due to LTS or other changes to the
kernel tree.)
Strongly based on rh_kabi.h from Red Hat's RHEL kernel tree.
This adds support for "real" padding and the ability to replace fields
with other fields.
But, note that ABI changes will still be caught by libabigail at this
point in time, work on that is still ongoing. When that is completed,
all that will be needed is to modify the _ANDROID_KABI_RESERVE() macro
in this file. No other file changes should be needed.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I77038cc251c819c3ed22a9cb8843b185416b6727
This commit leaves a TODO in the code so we can more easily keep track
of the workaround.
Bug: 182572011
Fixes: be409db652 ("ANDROID: Clang LTO: Only set -fvisibility=hidden for x86")
Signed-off-by: Giuliano Procida <gprocida@google.com>
Change-Id: I0277a8c0704e5caf8885884ec4e3642ebe03667f
Pages containing buffer_heads that are in one of the per-CPU
buffer_head LRU caches will be pinned and thus cannot be migrated.
This can prevent CMA allocations from succeeding, which are often used
on platforms with co-processors (such as a DSP) that can only use
physically contiguous memory. It can also prevent memory
hot-unplugging from succeeding, which involves migrating at least
MIN_MEMORY_BLOCK_SIZE bytes of memory, which ranges from 8 MiB to 1
GiB based on the architecture in use.
Correspondingly, invalidate the BH LRU caches before a migration
starts and stop any buffer_head from being cached in the LRU caches,
until migration has finished.
Bug: 180018981
Link: https://lore.kernel.org/linux-mm/20210310161429.399432-3-minchan@kernel.org/
Signed-off-by: Chris Goldsworthy <cgoldswo@codeaurora.org>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I7ac085c2ec14a81c3c4d7b65a7eeedb0cfba4ea6
LRU pagevec holds refcount of pages until the pagevec are drained.
It could prevent migration since the refcount of the page is greater
than the expection in migration logic. To mitigate the issue,
callers of migrate_pages drains LRU pagevec via migrate_prep or
lru_add_drain_all before migrate_pages call.
However, it's not enough because pages coming into pagevec after the
draining call still could stay at the pagevec so it could keep
preventing page migration. Since some callers of migrate_pages have
retrial logic with LRU draining, the page would migrate at next trail
but it is still fragile in that it doesn't close the fundamental race
between upcoming LRU pages into pagvec and migration so the migration
failure could cause contiguous memory allocation failure in the end.
To close the race, this patch disables lru caches(i.e, pagevec)
during ongoing migration until migrate is done.
Since it's really hard to reproduce, I measured how many times
migrate_pages retried with force mode(it is about a fallback to a
sync migration) with below debug code.
int migrate_pages(struct list_head *from, new_page_t get_new_page,
..
..
if (rc && reason == MR_CONTIG_RANGE && pass > 2) {
printk(KERN_ERR, "pfn 0x%lx reason %d\n", page_to_pfn(page), rc);
dump_page(page, "fail to migrate");
}
The test was repeating android apps launching with cma allocation
in background every five seconds. Total cma allocation count was
about 500 during the testing. With this patch, the dump_page count
was reduced from 400 to 30.
The new interface is also useful for memory hotplug which currently
drains lru pcp caches after each migration failure. This is rather
suboptimal as it has to disrupt others running during the operation.
With the new interface the operation happens only once. This is also in
line with pcp allocator cache which are disabled for the offlining as
well.
Bug: 180018981
Link: https://lore.kernel.org/linux-mm/20210310161429.399432-2-minchan@kernel.org/
[minchan: Resolved conflict in mm/memory_hotplug.c, mm/swap.c]
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ie1e09cf26e3105b674a9aed4ac65070efee608af
Currently, migrate_prep is merely a wrapper of lru_cache_add_all.
There is not much to gain from having additional abstraction.
Use lru_add_drain_all instead of migrate_prep, which would be more
descriptive.
note: migrate_prep_local in compaction.c changed into lru_add_drain
to avoid CPU schedule cost with involving many other CPUs to keep
keep old behavior.
Bug: 180018981
Link: https://lore.kernel.org/linux-mm/20210310161429.399432-1-minchan@kernel.org/
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I1bd3fcb13993e8a7a7961ceec817ac17304364cb
Defining one macro instead of two for tcpc_presenting_*_rd.
This is a follow up of the comment left by Heikki Krogerus.
https://patchwork.kernel.org/project/linux-usb/patch/
20210304070931.1947316-1-badhri@google.com/
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20210310223536.3471243-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit aecb1e452d9e9de593b58330eb0279671be04436)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iffee064c4aba766d9819673282ffe62835f1fb5d
GKI has CONFIG_DYNAMIC_DEBUG_CORE. Thus, to enable only the
specific alloc_contig_dump_pages without needing all pr_debug
in every source files is using -DCONFIG_DYNAMIC_MODULE
when the page_alloc.o compiled.
Bug: 182195592
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I93266eb4161b3653389c737d4c767fd5d1083339
Currently, debugging CMA allocation failures is quite limited.
The most common source of these failures seems to be page
migration which doesn't provide any useful information on the
reason of the failure by itself. alloc_contig_range can report
those failures as it holds a list of migrate-failed pages.
The information logged by dump_page() has already proven helpful
for debugging allocation issues, like identifying long-term
pinnings on ZONE_MOVABLE or MIGRATE_CMA.
Let's use the dynamic debugging infrastructure, such that we
avoid flooding the logs and creating a lot of noise on frequent
alloc_contig_range() calls. This information is helpful for
debugging only.
There are two ifdefery conditions to support common dyndbg options:
- CONFIG_DYNAMIC_DEBUG_CORE && DYNAMIC_DEBUG_MODULE
It aims for supporting the feature with only specific file
with adding ccflags.
- CONFIG_DYNAMIC_DEBUG
It aims for supporting the feature with system wide globally.
A simple example to enable the feature:
Admin could enable the dump like this(by default, disabled)
echo "func alloc_contig_dump_pages +p" > control
Admin could disable it.
echo "func alloc_contig_dump_pages =_" > control
Detail goes Documentation/admin-guide/dynamic-debug-howto.rst
A concern is utility functions in dump_page use inconsistent
loglevels. In the future, we might want to make the loglevels
used inside dump_page() consistent and eventually rework the way
we log the information here. See [1].
[1] https://lore.kernel.org/linux-mm/YEh4doXvyuRl5BDB@google.com/
Bug: 182195592
Link: https://lore.kernel.org/linux-mm/20210311194042.825152-1-minchan@kernel.org/
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Change-Id: I4db99a76a543d559a05515d6800c66ab48196978
Vendor may have their own behavior for determing uclamp value. Also
uclamp_eff_get() is used in uclamp_rq_inc_id() when task is enqueued,
and it is contained in uclamp_eff_value(), there is no much benefit to
hook uclamp_eff_value(), so remove the hook in uclamp_eff_value().
Bug: 170507972
Bug: 180859906
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: Ibf7c043188a77c40baf5b4040b198a4197236089
cpu_down() checks for num_active_cpus() to ensure that at least one
cpu is left active. If there are two online CPUs, but one of these
is paused this check will fail indicating that only one active
CPU is available. This will prevent the online but inactive cpu
from being offlined.
Correct cpu_down() to ensure that if there is only one active CPU
and that is the CPU being requested, the offline is blocked, allowing
the second to last CPU that is inactive but online to be offlined.
Bug: 182362445
Change-Id: I5b26cb6c5fdba4f2e69e5201e25bfe987d30c405
Signed-off-by: Stephen Dickey <dickey@codeaurora.org>
Add devm_blk_ksm_init to qcom symbol list for crypto engine.
Bug: 182453339
Change-Id: Ibb015293a66a31a8754aafe26b4fc680b7b977d7
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
Add hooks to gather data of unsual aborts and summarize it with
other information.
Bug: 177483057
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Change-Id: I5f44b12770ae4976a6e3b098bd95a05dea347764
The kzalloc allocation for dtpm_cpu is currently allocating the size
of the pointer and not the size of the structure. Fix this by using
the correct sizeof argument.
Addresses-Coverity: ("Wrong sizeof argument")
Fixes: 0e8f68d7f048 ("powercap/drivers/dtpm: Add CPU energy model based support")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://www.spinics.net/lists/linux-kernel-janitors/msg56960.html
Bug: 182396925
Change-Id: Iac5e069ca027136d85089b8eab9ba6dfe10034b7
(cherry picked from commit 66e713fbbbc6c259559d4937a3b016d36ab529ff)
Signed-off-by: Ram Chandrasekar <quic_rkumbako@quicinc.com>
The DTPM_POWER_LIMIT_FLAG is used for test_bit() etc which take a bit
number so it should be bit 0. But currently it's set to BIT(0) then
that is double shifted equivalent to BIT(BIT(0)). This doesn't cause a
run time problem because it's done consistently.
Fixes: a20d0ef97abf ("powercap/drivers/dtpm: Add API for dynamic thermal power management")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://www.spinics.net/lists/linux-kernel-janitors/msg57003.html
Bug: 182396925
Change-Id: I4245d8d0de695fa4c07916113df2097ec8ab8bcf
(cherry picked from commit 2185c23071e2c1f26fbccb323aa831732540cfcc)
Signed-off-by: Ram Chandrasekar <quic_rkumbako@quicinc.com>
32-bit architectures do not support u64 divisions, so the macro
DIV_ROUND_CLOSEST is not adequate as the compiler will replace the
call to an unexisting function for the platform, leading to
unresolved references to symbols.
Fix this by using the compatible macros:
DIV64_U64_ROUND_CLOSEST and DIV_ROUND_CLOSEST_ULL.
Fixes: a20d0ef97abf ("powercap/drivers/dtpm: Add API for dynamic thermal power management")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lkml.org/lkml/2020/12/30/304
Bug: 182396925
Change-Id: I1a67791b071acb2fe6ed0d348f4462985ebabdc3
(cherry picked from commit 8f50db4b5c79af2ba54f5fbe8a5173fd7f37a493)
Signed-off-by: Ram Chandrasekar <quic_rkumbako@quicinc.com>
With the powercap dtpm controller, we are able to plug devices with
power limitation features in the tree.
The following patch introduces the CPU power limitation based on the
energy model and the performance states.
The power limitation is done at the performance domain level. If some
CPUs are unplugged, the corresponding power will be subtracted from
the performance domain total power.
It is up to the platform to initialize the dtpm tree and add the CPU.
Here is an example to create a simple tree with one root node called
"pkg" and the CPU's performance domains.
static int dtpm_register_pkg(struct dtpm_descr *descr)
{
struct dtpm *pkg;
int ret;
pkg = dtpm_alloc(NULL);
if (!pkg)
return -ENOMEM;
ret = dtpm_register(descr->name, pkg, descr->parent);
if (ret)
return ret;
return dtpm_register_cpu(pkg);
}
static struct dtpm_descr descr = {
.name = "pkg",
.init = dtpm_register_pkg,
};
DTPM_DECLARE(descr);
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Tested-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lkml.org/lkml/2020/12/8/736
Bug: 182396925
Change-Id: I01f949c0cb685806de1194fef3ad8a740301046d
(cherry picked from commit 0e8f68d7f04856a9e2ad4817b477fa35124888bd)
Signed-off-by: Ram Chandrasekar <quic_rkumbako@quicinc.com>
On the embedded world, the complexity of the SoC leads to an
increasing number of hotspots which need to be monitored and mitigated
as a whole in order to prevent the temperature to go above the
normative and legally stated 'skin temperature'.
Another aspect is to sustain the performance for a given power budget,
for example virtual reality where the user can feel dizziness if the
GPU performance is capped while a big CPU is processing something
else. Or reduce the battery charging because the dissipated power is
too high compared with the power consumed by other devices.
The userspace is the most adequate place to dynamically act on the
different devices by limiting their power given an application
profile: it has the knowledge of the platform.
These userspace daemons are in charge of the Dynamic Thermal Power
Management (DTPM).
Nowadays, the dtpm daemons are abusing the thermal framework as they
act on the cooling device state to force a specific and arbitrary
state without taking care of the governor decisions. Given the closed
loop of some governors that can confuse the logic or directly enter in
a decision conflict.
As the number of cooling device support is limited today to the CPU
and the GPU, the dtpm daemons have little control on the power
dissipation of the system. The out of tree solutions are hacking
around here and there in the drivers, in the frameworks to have
control on the devices. The common solution is to declare them as
cooling devices.
There is no unification of the power limitation unit, opaque states
are used.
This patch provides a way to create a hierarchy of constraints using
the powercap framework. The devices which are registered as power
limit-able devices are represented in this hierarchy as a tree. They
are linked together with intermediate nodes which are just there to
propagate the constraint to the children.
The leaves of the tree are the real devices, the intermediate nodes
are virtual, aggregating the children constraints and power
characteristics.
Each node have a weight on a 2^10 basis, in order to reflect the
percentage of power distribution of the children's node. This
percentage is used to dispatch the power limit to the children.
The weight is computed against the max power of the siblings.
This simple approach allows to do a fair distribution of the power
limit.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Tested-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lkml.org/lkml/2020/12/8/736
Bug: 182396925
Change-Id: I1786b8f4de45e8f0abbdb9bac99da80245a4d7f7
(cherry picked from commit a20d0ef97abf486a917aff066c457bdb930425af)
Signed-off-by: Ram Chandrasekar <quic_rkumbako@quicinc.com>
The dynamic thermal and power management is a technique to dynamically
adjust the power consumption of different devices in order to ensure a
global thermal constraint.
An userspace daemon is usually monitoring the temperature and the
power to take immediate action on the device.
The DTPM framework provides an unified API to userspace to act on the
power.
Document this framework.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lkml.org/lkml/2020/12/8/736
Bug: 182396925
Change-Id: I72d7326f3f1f97bb367fd0b6efd6af6776e512b3
(cherry picked from commit f5ad1c747956d501516610ee7900f4a6d57ee2f5)
Signed-off-by: Ram Chandrasekar <quic_rkumbako@quicinc.com>
If port terminations are detected in suspend, but link never reaches U0
then xHCI may have an internal uncleared wake state that will cause an
immediate wake after suspend.
This wake state is normally cleared when driver clears the PORT_CSC bit,
which is set after a device is enabled and in U0.
Write 1 to clear PORT_CSC for ports that don't have anything connected
when suspending. This makes sure any pending internal wake states in
xHCI are cleared.
Cc: stable@vger.kernel.org
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210311115353.2137560-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d26c00e7276fc92b18c253d69e872f6b03832bad)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I26c39851c5c3c646c4d8ea84d2e608e2ddfebb9d
I've confirmed that both the ASMedia ASM1042A and ASM3242 have the same
problem as the ASM1142 and ASM2142/ASM3142, where they lose some of the
upper bits of 64-bit DMA addresses. As with the other chips, this can
cause problems on systems where the upper bits matter, and adding the
XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue.
Cc: stable@vger.kernel.org
Signed-off-by: Forest Crossman <cyrozap@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210311115353.2137560-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b71c669ad8390dd1c866298319ff89fe68b45653)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5d8ed7834b15a4415a1dfeb778f616e235172046
A xHC USB 3 port might miss the first wake signal from a USB 3 device
if the port LFPS reveiver isn't enabled fast enough after xHC resume.
xHC host will anyway be resumed by a PME# signal, but will go back to
suspend if no port activity is seen.
The device resends the U3 LFPS wake signal after a 100ms delay, but
by then host is already suspended, starting all over from the
beginning of this issue.
USB 3 specs say U3 wake LFPS signal is sent for max 10ms, then device
needs to delay 100ms before resending the wake.
Don't suspend immediately if port activity isn't detected in resume.
Instead add a retry. If there is no port activity then delay for 120ms,
and re-check for port activity.
Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210311115353.2137560-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 253f588c70f66184b1f3a9bbb428b49bbda73e80)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I30e4e5f6859e4e4605a32c03a1090ccb5222ae0e
On some systems rt2800usb and mt7601u devices are unable to operate since
commit f8f80be501 ("xhci: Use soft retry to recover faster from
transaction errors")
Seems that some xHCI controllers can not perform Soft Retry correctly,
affecting those devices.
To avoid the problem add xhci->quirks flag that restore pre soft retry
xhci behaviour for affected xHCI controllers. Currently those are
AMD_PROMONTORYA_4 and AMD_PROMONTORYA_2, since it was confirmed
by the users: on those xHCI hosts issue happen and is gone after
disabling Soft Retry.
[minor commit message rewording for checkpatch -Mathias]
Fixes: f8f80be501 ("xhci: Use soft retry to recover faster from transaction errors")
Cc: <stable@vger.kernel.org> # 4.20+
Reported-by: Bernhard <bernhard.gebetsberger@gmx.at>
Tested-by: Bernhard <bernhard.gebetsberger@gmx.at>
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202541
Link: https://lore.kernel.org/r/20210311115353.2137560-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a4a251f8c23518899d2078c320cf9ce2fa459c9f)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie909d0e08b51795ad3db0975881157a04aafc8a7
This commit adds a trace event which allows tracing the beginnings of RCU
CPU stall warnings on systems where sysctl_panic_on_rcu_stall is disabled.
The first parameter is the name of RCU flavor like other trace events.
The second parameter indicates whether this is a stall of an expedited
grace period, a self-detected stall of a normal grace period, or a stall
of a normal grace period detected by some CPU other than the one that
is stalled.
RCU CPU stall warnings are often caused by external-to-RCU issues,
for example, in interrupt handling or task scheduling. Therefore,
this event uses TRACE_EVENT, not TRACE_EVENT_RCU, to avoid requiring
those interested in tracing RCU CPU stalls to rebuild their kernels
with CONFIG_RCU_TRACE=y.
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Reviewed-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
(cherry picked from commit 71580d6503f747f1b06ef8dbb7cdbbe20400a2ec
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev)
Bug: 177483057
Change-Id: Ie2f0340725a2fb582d026ecfaf5e1d35cc90fece
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Export the following xhci symbols which will allow vendor modules
to perform their own ring management. These will be used to create
and manage additional secondary rings that are used to offload to a
separate coprocessor which interacts with the xHC controller.
xhci_ring_alloc
- Allocate a struct xhci_ring.
xhci_alloc_erst
xhci_free_erst
- Allocate and free event ring segment tables.
xhci_trb_virt_to_dma
- Used to retrieve the DMA address of a TRB
xhci_ring_cmd_db
- Notify the controller when a new command is issued
xhci_alloc_command
xhci_free_command
- Allocate and free a struct xhci_command
xhci_queue_stop_endpoint
- Issue a stop endpoint command to the controller
Bug: 182336717
Change-Id: I9d4c5884108e656e890aca8137d4ef580bcd7a12
Signed-off-by: Jack Pham <jackp@codeaurora.org>
