erofs_inode_datablocks() has the only one caller, let's just get
rid of it entirely. No logic changes.
Bug: 303691233
Change-Id: I15f4e5df8ddd53c570408cc80b255b6934c06fdb
Reviewed-by: Yue Hu <huyue2@coolpad.com>
Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Change-Id: I96195a960204c313649c510766e6a54d49a01784
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20230204093040.97967-1-hsiangkao@linux.alibaba.com
(cherry picked from commit 4efdec36dc9907628e590a68193d6d8e5e74d032)
Signed-off-by: Sandeep Dhavale <dhavale@google.com>
Actually we could pass in inodes directly to clean up all callers.
Also rename iloc() as erofs_iloc().
Bug: 303691233
Link: https://lore.kernel.org/r/20230114150823.432069-1-xiang@kernel.org
Reviewed-by: Yue Hu <huyue2@coolpad.com>
Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
(cherry picked from commit b780d3fc6107464dcc43631a6208c43b6421f1e6)
[dhavale: resolved minor conflict in fs/erofs/zmap.c]
Signed-off-by: Sandeep Dhavale <dhavale@google.com>
Change-Id: Iea7a97040cebdc984e2956d421755230263c97ae
Adding the following symbols:
- reserve_iova
Bug: 303000855
Change-Id: I84b0eeb179b4194d0d8294b789f2cecc388f0963
Signed-off-by: Junghoon Jang <junghoonjang@google.com>
To monitor the reclaiming ability of kswapd, add vendor hook recording when the kswapd finish the reclaiming job and the reclaim progress.
android_vh_vmscan_kswpad_done(int, unsigned int, unsigned int, unsigned int)
Bug: 301044280
Change-Id: Id6e0a97003f0a156cff4d0996bc38bcd89b1dc69
Signed-off-by: John Hsu <john.hsu@mediatek.com>
To monitor the efficiency of memory relciaming in __alloc_pages_slowpath, add vendor hooks in each stages of __alloc_pages_slowpath including __alloc_pages_may_oom and __alloc_pages_direct_reclaim.
android_vh_mm_alloc_pages_direct_reclaim_enter()
android_vh_mm_alloc_pages_direct_reclaim_exit(unsigned long, int)
android_vh_mm_alloc_pages_may_oom_exit(struct oom_control *, unsigned long)
Bug: 301044280
Change-Id: Ic5b5f1c2ad31b16e7339f539fcf54659e9acaba7
Signed-off-by: John Hsu <john.hsu@mediatek.com>
To monitor the efficiency of each action about compaction.
Add the vendor_hook function and call it in kcompactd_do_work() and
try_to_compact_pages()
ANDROID vendor hook
android_vh_compaction_exit(int, int, const int)
android_vh_compaction_try_to_compact_pages_exit(enum *compact result)
Bug: 301044280
Change-Id: I4c3f94e77eb2b16ba154ba88a9f75095536de916
Signed-off-by: John Hsu <john.hsu@mediatek.com>
Consider a case where gserial_disconnect has already cleared
gser->ioport. And if gserial_suspend gets called afterwards,
it will lead to accessing of gser->ioport and thus causing
null pointer dereference.
Avoid this by adding a null pointer check. Added a static
spinlock to prevent gser->ioport from becoming null after
the newly added null pointer check.
Fixes: aba3a8d01d ("usb: gadget: u_serial: add suspend resume callbacks")
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Link: https://lore.kernel.org/r/1683278317-11774-1-git-send-email-quic_prashk@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 285495243
(cherry picked from commit 2f6ecb89fe8feb2b60a53325b0eeb9866d88909a
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-next)
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Change-Id: I2c5b58eaaa1e3428952ffdbf7f1a39cad519cc5a
(cherry picked from commit f51f079fe30f53aca027aca2c7a517e79c45b67f)
Some usb hubs will negotiate DisplayPort Alt mode with the device
but will then negotiate a data role swap after entering the alt
mode. The data role swap causes the device to unregister all alt
modes, however the usb hub will still send Attention messages
even after failing to reregister the Alt Mode. type_altmode_attention
currently does not verify whether or not a device's altmode partner
exists, which results in a NULL pointer error when dereferencing
the typec_altmode and typec_altmode_ops belonging to the altmode
partner.
Verify the presence of a device's altmode partner before sending
the Attention message to the Alt Mode driver.
Fixes: 8a37d87d72 ("usb: typec: Bus type for alternate modes")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20230814180559.923475-1-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 288952921
(cherry picked from commit f23643306430f86e2f413ee2b986e0773e79da31)
[rd: changed return type of typec_altmode_attention to void to not break
kmi, moved tcpm_log from error return to typec_altmode_attention as
dev_warn]
Signed-off-by: RD Babiera <rdbabiera@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:e23c89c0b76305f9f264ba113d647710b956a540)
Merged-In: I054a6ef56b9b2d7c4e8167e8630a8c277910da88
Change-Id: I054a6ef56b9b2d7c4e8167e8630a8c277910da88
smaps_pte_hole_lookup() is calling shmem_partial_swap_usage() with page
table lock held: but shmem_partial_swap_usage() does cond_resched_rcu() if
need_resched(): "BUG: sleeping function called from invalid context".
Since shmem_partial_swap_usage() is designed to count across a range, but
smaps_pte_hole_lookup() only calls it for a single page slot, just break
out of the loop on the last or only page, before checking need_resched().
Bug: 302977171
Link: https://lkml.kernel.org/r/6fe3b3ec-abdf-332f-5c23-6a3b3a3b11a9@google.com
(cherry picked from commit e5548f85b4527c4c803b7eae7887c10bf8f90c97)
Fixes: 2301003215 ("mm/smaps: simplify shmem handling of pte holes")
Change-Id: I1b59341c954cb7eb31709ba0dcc65ec6e67c58c6
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Peter Xu <peterx@redhat.com>
Cc: <stable@vger.kernel.org> [5.16+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Since commit a78418e6a0 ("block: Always initialize bio IO priority on
submit"), bio->bi_ioprio will never be IOPRIO_CLASS_NONE when calling
blkcg_set_ioprio(), so there will be no way to promote the io-priority
of one cgroup to IOPRIO_CLASS_RT, because bi_ioprio will always be
greater than or equals to IOPRIO_CLASS_RT.
It seems possible to call blkcg_set_ioprio() first then try to
initialize bi_ioprio later in bio_set_ioprio(), but this doesn't work
for bio in which bi_ioprio is already initialized (e.g., direct-io), so
introduce a new promote-to-rt policy to promote the iopriority of bio to
IOPRIO_CLASS_RT if the ioprio is not already RT.
For none-to-rt policy, although it doesn't work now, but considering
that its purpose was also to override the io-priority to RT and allowing
for a smoother transition, just keep it and treat it as an alias of
the promote-to-rt policy.
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Change-Id: I1f511e8dca604fdb3249562ea73adb69b93a8aec
Signed-off-by: Hou Tao <houtao1@huawei.com>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Link: https://lore.kernel.org/r/20230428074404.280532-1-houtao@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit ddf63516d8d37528dc6834c7f19b55084e956068)
Bug: 186902601
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Prepare for supporting I/O priority in the storage stack.
Bug: 186902601
Change-Id: I387ac4792c89d88d131c5146b116a0393c01b096
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Crosvm thread can get interrupted while making a call to the Resource
Manager. If we wait on mutext_lock_interruptible, the RM call might be
incomplete and as part of the cleanup if there are further RM calls that
need to be made, they will also return without making the RM call
because there is a signal on the thread. Use mutex_lock while making the
RM calls to ensure the RM call completes and only if there is a geniune
error, we can clean up.
Bug: 302322730
Change-Id: I961aa917588a72bb8733e6f80d80f3ceed179076
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
[ Upstream commit ed17aa92dc56b6d8883e4b7a8f1c6fbf5ed6cd29 ]
When huang uses sched_switch tracepoint, the tracepoint
does only one thing in the mounted ebpf program, which
deletes the fixed elements in sockhash ([0])
It seems that elements in sockhash are rarely actively
deleted by users or ebpf program. Therefore, we do not
pay much attention to their deletion. Compared with hash
maps, sockhash only provides spin_lock_bh protection.
This causes it to appear to have self-locking behavior
in the interrupt context.
[0]:https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/
Bug: 293551383
Reported-by: Hsin-Wei Hung <hsinweih@uci.edu>
Fixes: 604326b41a ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Xin Liu <liuxin350@huawei.com>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/r/20230406122622.109978-1-liuxin350@huawei.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit f333854dce4a079783f00c201869b9ee8f7ff3c3)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I913aa014f16e294ab9f9fec04d3e63afb8aa803f
Since commit 4e57a4ddf6 ("ARM: 9107/1: syscall: always store
thread_info->abi_syscall"), the seccomp selftests "syscall_errno"
and "syscall_faked" have been broken. Both seccomp and PTRACE depend
on using the special value of "-1" for skipping syscalls. This value
wasn't working because it was getting masked by __NR_SYSCALL_MASK in
both PTRACE_SET_SYSCALL and get_syscall_nr().
Explicitly test for -1 in PTRACE_SET_SYSCALL and get_syscall_nr(),
leaving it exposed when present, allowing tracers to skip syscalls
again.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org
Fixes: 4e57a4ddf6 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall")
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230810195422.2304827-2-keescook@chromium.org
Change-Id: I5b13c06a9cca85d13beec809a695198a7696df45
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 4697b5848bd933f68ebd04836362c8de0cacaf71)
Bug: 289991100
Signed-off-by: Edward Liaw <edliaw@google.com>
Since commit 4e57a4ddf6 ("ARM: 9107/1: syscall: always store
thread_info->abi_syscall"), the seccomp selftests "syscall_restart" has
been broken. This was caused by the restart syscall not being stored to
"abi_syscall" during restart setup before branching to the "local_restart"
label. Tracers would see the wrong syscall, and scno would get overwritten
while returning from the TIF_WORK path. Add the missing store.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org
Fixes: 4e57a4ddf6 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall")
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230810195422.2304827-1-keescook@chromium.org
Change-Id: If78d334ed46335cf8eff33a4bbcb1da5e86de016
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit cf007647475b5090819c5fe8da771073145c7334)
Bug: 289991100
Signed-off-by: Edward Liaw <edliaw@google.com>
This reverts commit 251aa28d16.
Reason for revert: b/301670242
The connect_lock mutex is not being released in error path. This patch was reverted upstream.
Signed-off-by: Neill Kapron <nkapron@google.com>
Change-Id: I802a9a8afc9f23b1bf91fa4df4bfb5d207373b04
They don't have device-specific modules. They are just generic configs
that are different from GKI.
Bug: 301852599
Test: run following commands
tools/bazel run //common:kernel_aarch64_microdroid_dist
tools/bazel run //common:kernel_x86_64_microdroid_dist
tools/bazel run //common:kernel_aarch64_microdroid_config -- menuconfig
tools/bazel run //common:kernel_x86_64_microdroid_config -- menuconfig
tools/bazel run //common:kernel_aarch64_crashdump_dist
tools/bazel run //common:kernel_x86_64_crashdump_dist
tools/bazel run //common:kernel_aarch64_crashdump_config -- menuconfig
tools/bazel run //common:kernel_x86_64_crashdump_config -- menuconfig
Change-Id: I8908a7499451ace0740979b694eb5fcc68398c61
Signed-off-by: Jiyong Park <jiyong@google.com>
Recently we have discovered many lag issues caused by percpu_rwsem
lock-holding tasks not being scheduled for a long time. we need to
identify them and provide appropriate scheduling protection in our
oem scheduler.
To support this, we add one hook below:
trace_android_vh_percpu_rwsem_wq_add
Bug: 301066838
Change-Id: Id770c1a7978842abfc62d3fa9aeb5ac7a1904972
Signed-off-by: xieliujie <xieliujie@oppo.com>
Add hooks to support oem's binder feature of improving binder_thread->task sched priority
1) Check if it is a specific task in trace_android_vh_binder_transaction_buffer() and store the flag to t->android_vendor_data1
2) If it is a specific binder task and binder_thread selected, raise the sched priority of binder_thread->task in runqueue.
3) If it is a specific binder task but no binder_thread selected (e.g pending_async or no free threads), insert t->work to the appropriate position in the list.
4) Reset the sched priority when BR_TRANSACTION or BC_FREE_BUFFER.
Some high-priority async binder task reset the sched priority when BC_FREE_BUFFER in trace_android_vh_binder_free_buf().
Some middle-priority async binder task reset the sched priority when driver return server "BR_TRANSACTION" in trace_android_vh_binder_transaction_received().
Bug: 299328919
Change-Id: Iab4939fe4a4881b31961aaa2fef500b51c944743
Signed-off-by: lfc <lfc@oppo.com>
Update_io_stats_uid_locked would take a long lock-time of uid_lock due to
call do_each_thread to compute uid_entry->io, which would cause to lock
competition sometime.
Using uid_entry_tmp to get the result of update_io_stats_uid, so that we
can unlock_uid during update_io_stats_uid, in order to avoid the
unnecessary lock-time of uid_lock.
Bug: 278138377
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
(cherry picked from https://android-review.googlesource.com/q/commit:c1fa53f3cf85c0a1c23f0e0a944986b4aa049073)
Merged-In: I5be62105e57e2a896a95d906e3c14e17c7f8077d
Change-Id: I5be62105e57e2a896a95d906e3c14e17c7f8077d
locks for each hlist in hash_table.
1.Hash_table in uid_sys_stat is protected by a global lock named id_lock,
which causes some lock competition issue. Actually, uid_lock can be split to
several file-grained locks for each hlist in hash_table, which avoid
the unnecessary lock competition when get different-uid process info.
2. Switching rt-mutex to spinlock, in order to operate with read_rcu_lock.
Bug: 278138377
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
(cherry picked from https://android-review.googlesource.com/q/commit:c949fbdce0bc792dea206c709d909094be579c3a)
Merged-In: Ib252b65e9aebe3a594e6edf075f7aa01f8e6105d
Change-Id: Ib252b65e9aebe3a594e6edf075f7aa01f8e6105d
Some IOMMU devices might be deferred after the driver being
loaded early, so we need to flush the deferred probe list,
this will work if all dependencies already exist.
Bug: 290582379
Change-Id: I5fb3af9b0f7d1b4dbf57078707112dfdb8a3dc23
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Commit d096d35445 ("ANDROID: KVM: arm64: Have different callbacks for
PTE manipulation") accidentally forces the use of pte-level mappings for
the guest stage-2 page-table when not using pKVM.
This confuses user_mem_abort() when the guest takes a permission fault
trying to execute from a huge page. Since the fault is reported at the
pte-level, we end up handling it as a translation fault by calling
kvm_pgtable_stage2_map() which dutifully returns -EAGAIN when it finds
the RW PTE. Consequently, the guest appears to hang randomly during boot.
Fix the issue by inverting stage2_force_pte_cb() so that the host is in
complete control of the mapping granularity of the guest when pKVM is
not being used.
Cc: Fuad Tabba <tabba@google.com>
Cc: Mostafa Saleh <smostafa@google.com>
Fixes: d096d35445 ("ANDROID: KVM: arm64: Have different callbacks for PTE manipulation")
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 222044487
Change-Id: Ideab281ae6d1d5c0fd29fba03ad8ed1cae521a1e
If gs_close has cleared port->port.tty and gs_start_io is called
afterwards, then the function tty_wakeup will attempt to access the value
of the pointer port->port.tty which will cause a null pointer
dereference error.
To avoid this, add a null pointer check to gs_start_io before attempting
to access the value of the pointer port->port.tty.
Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
Message-ID: <20230602070009.1353946-1-khtsai@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 283247551
(cherry picked from commit ffd603f214237e250271162a5b325c6199a65382)
Change-Id: I782ef328b0d49810d3fb23c002a86439e6728542
Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
(cherry picked from commit ca0cd377615866a0253c6e495f99fad57bbaab86)
With the introduction of task_struct::saved_state in commit
5f220be214 ("sched/wakeup: Prepare for RT sleeping spin/rwlocks")
matching the task state has gotten more complicated. That same commit
changed try_to_wake_up() to consider both states, but
wait_task_inactive() has been neglected.
Sebastian noted that the wait_task_inactive() usage in
ptrace_check_attach() can misbehave when ptrace_stop() is blocked on
the tasklist_lock after it sets TASK_TRACED.
Therefore extract a common helper from ttwu_state_match() and use that
to teach wait_task_inactive() about the PREEMPT_RT locks.
Originally-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20230601091234.GW83892@hirez.programming.kicks-ass.net
(cherry picked from commit 1c06918788e8ae6e69e4381a2806617312922524)
Bug: 292064955
Change-Id: I2cc02dfdf3c04be146078f80d09c3a87979d79a6
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
While modifying wait_task_inactive() for PREEMPT_RT; the build robot
noted that UP got broken. This led to audit and consideration of the
UP implementation of wait_task_inactive().
It looks like the UP implementation is also broken for PREEMPT;
consider task_current_syscall() getting preempted between the two
calls to wait_task_inactive().
Therefore move the wait_task_inactive() implementation out of
CONFIG_SMP and unconditionally use it.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20230602103731.GA630648%40hirez.programming.kicks-ass.net
(cherry picked from commit d5e1586617be7093ea3419e3fa9387ed833cdbb1)
Bug: 292064955
Change-Id: Ief91cf48c27533fee47d5bd049c8a9be4010e6f6
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
commit 3c4f8333b582487a2d1e02171f1465531cde53e3 upstream.
In commit 9b9c8195f3f0 ("tty: n_gsm: fix UAF in gsm_cleanup_mux"), the UAF
problem is not completely fixed. There is a race condition in
gsm_cleanup_mux(), which caused this UAF.
The UAF problem is triggered by the following race:
task[5046] task[5054]
----------------------- -----------------------
gsm_cleanup_mux();
dlci = gsm->dlci[0];
mutex_lock(&gsm->mutex);
gsm_cleanup_mux();
dlci = gsm->dlci[0]; //Didn't take the lock
gsm_dlci_release(gsm->dlci[i]);
gsm->dlci[i] = NULL;
mutex_unlock(&gsm->mutex);
mutex_lock(&gsm->mutex);
dlci->dead = true; //UAF
Fix it by assigning values after mutex_lock().
Bug: 291178675
Link: https://syzkaller.appspot.com/text?tag=CrashReport&x=176188b5a80000
Cc: stable <stable@kernel.org>
Fixes: 9b9c8195f3f0 ("tty: n_gsm: fix UAF in gsm_cleanup_mux")
Fixes: aa371e96f0 ("tty: n_gsm: fix restart handling via CLD command")
Signed-off-by: Yi Yang <yiyang13@huawei.com>
Co-developed-by: Qiumiao Zhang <zhangqiumiao1@huawei.com>
Signed-off-by: Qiumiao Zhang <zhangqiumiao1@huawei.com>
Link: https://lore.kernel.org/r/20230811031121.153237-1-yiyang13@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 31311a9a4b)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I460a0f21f4121531d7732e09643a451382dfa2da
When CONFIG_OF_ADDRESS is not set, there is a build warning/error
about an unused function.
Annotate the function to quieten the warning/error.
../drivers/iommu/of_iommu.c:176:29: warning: 'iommu_resv_region_get_type' defined but not used [-Wunused-function]
176 | static enum iommu_resv_type iommu_resv_region_get_type(struct device *dev, struct resource *phys,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Bug: 257546262
Fixes: a5bf3cfce8cb ("iommu: Implement of_iommu_get_resv_regions()")
Change-Id: Ice815df046c06efa7351351e3886e925c27ca57f
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Will Deacon <will@kernel.org>
Cc: iommu@lists.linux.dev
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20230209010359.23831-1-rdunlap@infradead.org
[joro: Improve code formatting]
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 4762315d1c971312d55848fdc85eee7f0b09c8f2)
For device tree nodes, use the standard of_iommu_get_resv_regions()
implementation to obtain the reserved memory regions associated with a
device.
Bug: 257546262
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: devicetree@vger.kernel.org
Acked-by: Robin Murphy <robin.murphy@arm.com>
Change-Id: I142fa2ef8639b604701f8d0bc70429288a5e8491
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20230120174251.4004100-5-thierry.reding@gmail.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 5cef282e295f7cf623672470d040716d1e3eacf2)
This is an implementation that IOMMU drivers can use to obtain reserved
memory regions from a device tree node. It uses the reserved-memory DT
bindings to find the regions associated with a given device. If these
regions are marked accordingly, identity mappings will be created for
them in the IOMMU domain that the devices will be attached to.
Bug: 257546262
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Change-Id: I68367e556cfd822a5802d7ff579f6dc12f54f6a6
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20230120174251.4004100-4-thierry.reding@gmail.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit a5bf3cfce8cb77d9d24613ab52d520896f83dd48)
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 af0d81357cc558ff40968b4e04131e08ae540127)
This function is similar to of_translate_dma_address() but also reads a
length in addition to an address from a device tree property.
Bug: 257546262
Reviewed-by: Rob Herring <robh@kernel.org>
Change-Id: I04eb9ee382b4a6db998b0bf34545f2bddef7a00e
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20230120174251.4004100-2-thierry.reding@gmail.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit e251c21372c07694f547afe3c9828f7f6ef01267)
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>
