This adds the "iommu-addresses" property to reserved-memory nodes, which
allow describing the interaction of memory regions with IOMMUs. Two use-
cases are supported:
1. Static mappings can be described by pairing the "iommu-addresses"
property with a "reg" property. This is mostly useful for adopting
firmware-allocated buffers via identity mappings. One common use-
case where this is required is if early firmware or bootloaders
have set up a bootsplash framebuffer that a display controller is
actively scanning out from during the operating system boot
process.
2. If an "iommu-addresses" property exists without a "reg" property,
the reserved-memory node describes an IOVA reservation. Such memory
regions are excluded from the IOVA space available to operating
system drivers and can be used for regions that must not be used to
map arbitrary buffers.
Each mapping or reservation is tied to a specific device via a phandle
to the device's device tree node. This allows a reserved-memory region
to be reused across multiple devices.
Bug: 257546262
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Change-Id: I9cdd29d056896b9cbb9fdbbc0c6cbd824f1be78e
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20230120174251.4004100-3-thierry.reding@gmail.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit af0d81357c)
Add rockchip fragment and build.config for build symbol list and abi update.
Bug: 300024866
Change-Id: I05f9b2cdba8b558be68a3f93330cd072cd341d71
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Add initial symbol list for rockchip in android/abi_gki_aarch64_rockchip
Bug: 300024866
Change-Id: I4fd44b33141dfbdcd5b8d0d7c5d0fbc5aa2758cc
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Commit 95158a89dd ("sched,rt: Use the full cpumask for balancing")
allows find_lock_lowest_rq() to pick a task with migration disabled.
The purpose of the commit is to push the current running task on the
CPU that has the migrate_disable() task away.
However, there is a race which allows a migrate_disable() task to be
migrated. Consider:
CPU0 CPU1
push_rt_task
check is_migration_disabled(next_task)
task not running and
migration_disabled == 0
find_lock_lowest_rq(next_task, rq);
_double_lock_balance(this_rq, busiest);
raw_spin_rq_unlock(this_rq);
double_rq_lock(this_rq, busiest);
<<wait for busiest rq>>
<wakeup>
task become running
migrate_disable();
<context out>
deactivate_task(rq, next_task, 0);
set_task_cpu(next_task, lowest_rq->cpu);
WARN_ON_ONCE(is_migration_disabled(p));
Fixes: 95158a89dd ("sched,rt: Use the full cpumask for balancing")
Signed-off-by: Schspa Shi <schspa@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Reviewed-by: Valentin Schneider <vschneid@redhat.com>
Tested-by: Dwaine Gonyier <dgonyier@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bug: 300418678
(cherry picked from commit feffe5bb27)
[quic_dickey@quicinc.com: Port only]
Change-Id: I3e7953aeb3edf3f1a5d03e355297d7b1541ff7c8
Signed-off-by: Stephen Dickey <quic_dickey@quicinc.com>
create the ASUS symbol list of HID symbols for the USB HID Fan driver which requires them
6 function symbol(s) added
'int __hid_register_driver(struct hid_driver*, struct module*, const char*)'
'int hid_hw_raw_request(struct hid_device*, unsigned char, __u8*, size_t, enum hid_report_type, enum hid_class_request)'
'int hid_hw_start(struct hid_device*, unsigned int)'
'void hid_hw_stop(struct hid_device*)'
'int hid_open_report(struct hid_device*)'
'void hid_unregister_driver(struct hid_driver*)'
Bug: 300220786
Change-Id: I422c3b82754921c530e9afc32529a1dbf2f6c38e
Signed-off-by: Steve2 Yang <steve2_yang@asus.com>
Update whitelist for the symbols used by the unisoc device and
update the ABI representation accordingly.
1 function symbol(s) added
'int pvclock_gtod_register_notifier(struct notifier_block*)'
Bug: 300019103
Change-Id: Ice320a418069f24a27d14939a143ce01f50c0de8
Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>
Add vendor hook to determine if the memory of a process
that received the SIGKILL can be reaped.
Partial cherry-pick of aosp/1724512 & aosp/2093626.
Bug: 232062955
Change-Id: I75072bd264df33caff67d083821ee6f33ca83af9
Signed-off-by: Tangquan Zheng <zhengtangquan@oppo.com>
Whitelist the below symbols that can be used to decide if overshooting
of kswapd reclaim is allowed.
Symbols added:
__traceiter_android_vh_scan_abort_check_wmarks
__tracepoint_android_vh_scan_abort_check_wmarks
Bug: 224956008
Change-Id: I185a570b345d2db0a1426075faa4d9c6325fb0e8
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Allow vendor hook to enable checking of the high water marks to
decide if reclaim should continue scanning.
Bug: 224956008
Change-Id: I63fe1fd386e7599451c2df0a04c8440b4fc142fc
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
When ufshcd_clk_scaling_suspend_work(Thread A) running and new command
coming, ufshcd_clk_scaling_start_busy(Thread B) may get host_lock
after Thread A first time release host_lock. Then Thread A second time
get host_lock will set clk_scaling.window_start_t = 0 which scale up
clock abnormal next polling_ms time.
Also inlines another __ufshcd_suspend_clkscaling calls.
Below is racing step:
1 hba->clk_scaling.suspend_work (Thread A)
ufshcd_clk_scaling_suspend_work
2 spin_lock_irqsave(hba->host->host_lock, irq_flags);
3 hba->clk_scaling.is_suspended = true;
4 spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
__ufshcd_suspend_clkscaling
7 spin_lock_irqsave(hba->host->host_lock, flags);
8 hba->clk_scaling.window_start_t = 0;
9 spin_unlock_irqrestore(hba->host->host_lock, flags);
ufshcd_send_command (Thread B)
ufshcd_clk_scaling_start_busy
5 spin_lock_irqsave(hba->host->host_lock, flags);
....
6 spin_unlock_irqrestore(hba->host->host_lock, flags);
Bug: 298004596
Link: https://lore.kernel.org/all/20230831130826.5592-3-peter.wang@mediatek.com/
Change-Id: Ib208b1265107769005c4ae3f72d46b12c072b5c7
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
When no active_reqs, devfreq_monitor(Thread A) will suspend clock scaling.
But it may have racing with clk_scaling.suspend_work(Thread B) and
actually not suspend clock scaling(requue after suspend).
Next time after polling_ms, devfreq_monitor read
clk_scaling.window_start_t = 0 then scale up clock abnormal.
Below is racing step:
devfreq->work (Thread A)
devfreq_monitor
update_devfreq
.....
ufshcd_devfreq_target
queue_work(hba->clk_scaling.workq,
1 &hba->clk_scaling.suspend_work)
.....
5 queue_delayed_work(devfreq_wq, &devfreq->work,
msecs_to_jiffies(devfreq->profile->polling_ms));
2 hba->clk_scaling.suspend_work (Thread B)
ufshcd_clk_scaling_suspend_work
__ufshcd_suspend_clkscaling
devfreq_suspend_device(hba->devfreq);
3 cancel_delayed_work_sync(&devfreq->work);
4 hba->clk_scaling.window_start_t = 0;
.....
Bug: 298004596
Link: https://lore.kernel.org/all/20230831130826.5592-4-peter.wang@mediatek.com/
Change-Id: I3ea77255f1b3845e9dd7bf6b050f3e9ba1f5f3f2
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Regenerate ABU definition file to resolve ABI breakage caused by a
private struct zs_pool:
INFO: ABI DIFFERENCES HAVE BEEN DETECTED!
INFO: type 'struct zs_pool' changed
member 'atomic_t compaction_in_progress' was added
Bug: 296365608
Change-Id: I477b6dbbdaf464b2fdf3e666b9696f1a79095a63
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
zsmalloc pool can be compacted concurrently by many contexts,
e.g.
cc1 handle_mm_fault()
do_anonymous_page()
__alloc_pages_slowpath()
try_to_free_pages()
do_try_to_free_pages(
lru_gen_shrink_node()
shrink_slab()
do_shrink_slab()
zs_shrinker_scan()
zs_compact()
Pool compaction is currently (basically) single-threaded as
it is performed under pool->lock. Having multiple compaction
threads results in unnecessary contention, as each thread
competes for pool->lock. This, in turn, affects all zsmalloc
operations such as zs_malloc(), zs_map_object(), zs_free(), etc.
Introduce the pool->compaction_in_progress atomic variable,
which ensures that only one compaction context can run at a
time. This reduces overall pool->lock contention in (corner)
cases when many contexts attempt to shrink zspool simultaneously.
Link: https://lkml.kernel.org/r/20230418074639.1903197-1-senozhatsky@chromium.org
Fixes: c0547d0b6a ("zsmalloc: consolidate zs_pool's migrate_lock and size_class's locks")
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Yosry Ahmed <yosryahmed@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit cb440cecb2)
Bug: 296365608
Change-Id: Ic7878e08c3484ade8c766d051a8f17cc8179eedf
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Update whitelist for the symbols used by qcom socs in
abi_gki_aarch64_qcom.
1 function symbol(s) added
'vhost_dev_flush'
Bug: 299585715
Change-Id: I403394331953c9cfee54b4b0c2a0365a3df5f0af
Signed-off-by: Prathu Baronia <quic_pbaronia@quicinc.com>
Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>
When sending Discover Identity messages to a Port Partner that uses Power
Delivery v2 and SVDM v1, we currently send PD v2 messages with SVDM v2.0,
expecting the port partner to respond with its highest supported SVDM
version as stated in Section 6.4.4.2.3 in the Power Delivery v3
specification. However, sending SVDM v2 to some Power Delivery v2 port
partners results in a NAK whereas sending SVDM v1 does not.
NAK messages can be handled by the initiator (PD v3 section 6.4.4.2.5.1),
and one solution could be to resend Discover Identity on a lower SVDM
version if possible. But, Section 6.4.4.3 of PD v2 states that "A NAK
response Should be taken as an indication not to retry that particular
Command."
Instead, we can set the SVDM version to the maximum one supported by the
negotiated PD revision. When operating in PD v2, this obeys Section
6.4.4.2.3, which states the SVDM field "Shall be set to zero to indicate
Version 1.0." In PD v3, the SVDM field "Shall be set to 01b to indicate
Version 2.0."
Fixes: c34e85fa69 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230731165926.1815338-1-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 289437937
(cherry picked from commit c97cd0b4b5)
Signed-off-by: RD Babiera <rdbabiera@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:d02aef1ae51a03b9ab20c8e01ed32593a7ffc6fc)
Merged-In: Ie919c29bab68cb08cb659471ff6106bae502c8dd
Change-Id: Ie919c29bab68cb08cb659471ff6106bae502c8dd
Share/unshare initiated by host doesn't change memory permission, and
as currently pKVM doesn't support device assignment, there is no need
to update the IOMMU unnecessarily as it waste cycles.
Once device assignment is enabled, this assumption will not be valid
as guests have access to DMA.
Bug: 291843613
Change-Id: I28c69ec8f721711d5b59fa2784386fa61654fe5a
Signed-off-by: Mostafa Saleh <smostafa@google.com>
There are some corner cases where we do worse in power because the
threshold is too low. Until these cases are better understood and
addressed upstream, provide a function for vendors to override this
value with something more suitable in their modules.
Bug: 289293494
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: I95dd36718a317f3fcb2a9f4bc87dd3390a4f7d7d
Vendor may have need to track rt util.
Bug: 201261299
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I2f4e5142c6bc8574ee3558042e1fb0dae13b702d
Vendor may have the need to implement their own util tracking.
Bug: 297343949
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I973902e6ff82a85ecd029ac5a78692d629df1ebe
Upstream moved the sugov to DEADLINE class which has higher prio than RT
so it can potentially block many RT use case in Android.
Also currently iowait doesn't distinguish background/foreground tasks
and we have seen cases where device run to high frequency unnecessarily
when running some background I/O.
Bug: 297343949
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: I21e9bfe9ef75a4178279574389e417c3f38e65ac
We want to add more special values, specifically for uclamp_max so that
it can be set automatically to the most efficient value based on the
core it's running on.
Bug: 297343949
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: I57343c4544f6cac621c855cbb94de0b8d80c51fa
Vendors could decide to use amu fie feature or not, such as if they
have some feature that needs amu fie to be disabled.
Bug: 297343949
Change-Id: I6b44ee899c58e7d5a8b2db03a30e3ab14b08f101
Signed-off-by: Rick Yiu <rickyiu@google.com>
Update symbol list for Exynos Auto SoCs
Bug: 299219798
Signed-off-by: Bumyong Lee <bumyong.lee@samsung.com>
Change-Id: I2a6a58cdfceb28186ee6a5778ce78e872d06c04f
[ Upstream commit 90e5b3462e ]
When flushing, individual set elements are disabled in the next
generation via the ->flush callback.
Catchall elements are not disabled. This is incorrect and may lead to
double-deactivations of catchall elements which then results in memory
leaks:
WARNING: CPU: 1 PID: 3300 at include/net/netfilter/nf_tables.h:1172 nft_map_deactivate+0x549/0x730
CPU: 1 PID: 3300 Comm: nft Not tainted 6.5.0-rc5+ #60
RIP: 0010:nft_map_deactivate+0x549/0x730
[..]
? nft_map_deactivate+0x549/0x730
nf_tables_delset+0xb66/0xeb0
(the warn is due to nft_use_dec() detecting underflow).
Bug: 298710879
Fixes: aaa31047a6 ("netfilter: nftables: add catch-all set element support")
Reported-by: lonial con <kongln9170@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 00ea7eb1c6)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I870613042789da3ab44f5f34a240f5dc8c4b25a2
step 1: export the follow symbols in file net/core/net-trace.c
EXPORT_TRACEPOINT_SYMBOL_GPL(net_dev_queue);
EXPORT_TRACEPOINT_SYMBOL_GPL(net_dev_xmit);
EXPORT_TRACEPOINT_SYMBOL_GPL(netif_receive_skb);
EXPORT_TRACEPOINT_SYMBOL_GPL(netif_rx);
step 2: update to symbol list, see link:
https://android-review.googlesource.com/c/kernel/common/+/2742633
Bug: 193384408
Change-Id: I5a247d04000289809db89b609ddaec9af33db041
Signed-off-by: Wei Liu <liuwei.a@oppo.com>
