-
Notifications
You must be signed in to change notification settings - Fork 73
Support for OP-TEE generic linux driver #11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This patch add a config to support to create multi buffer for cma fbdev. Such as double buffer and triple buffer. Cma fbdev is convient to add a legency fbdev. And still many Android devices use fbdev now and at least double buffer is needed for these Android devices, so that a buffer flip can be operated. It will need some time for Android device vendors to abondon legency fbdev. So multi buffer for fbdev is needed. Signed-off-by: Xinliang Liu <[email protected]>
Add the device tree binding documentation for hi6220 SoC display subsystem. drm master device binding doc. ADE display controller binding doc. DSI controller binding doc. Signed-off-by: Xinliang Liu <[email protected]>
Add DRM master driver for hi6220 SoC which used in HiKey board. Add dumb buffer feature. Add prime dmabuf feature. Signed-off-by: Xinliang Liu <[email protected]>
Add crtc funcs and helper funcs for ADE. Signed-off-by: Xinliang Liu <[email protected]>
Add plane funcs and helper funcs for ADE. Signed-off-by: Xinliang Liu <[email protected]>
Add vblank handle for ADE. Signed-off-by: Xinliang Liu <[email protected]>
Add cma Fbdev, Fbdev is legency and optional, you can enable/disable it by configuring DRM_FBDEV_EMULATION. Add hotplug. Signed-off-by: Xinliang Liu <[email protected]>
Add dsi encoder driver for hi6220 SoC. Signed-off-by: Xinliang Liu <[email protected]>
Add dsi host driver for hi6220 SoC. Signed-off-by: Xinliang Liu <[email protected]>
Add support for external HDMI bridge. Signed-off-by: Xinliang Liu <[email protected]>
ion_buffer_create() will allocate a buffer and then create a DMA mapping for it, but it forgot to set the length of the page entries. Signed-off-by: Liviu Dudau <[email protected]> [jstultz: Cherrypicked to 4.4] Signed-off-by: John Stultz <[email protected]>
Early at boot, during the sys_clk initialization, make sure UART1 uses the higher frequency clock. This enables support for higher baud rates (up to 3Mbps) required to support faster bluetooth transfers. Signed-off-by: Jorge Ramirez-Ortiz <[email protected]> Conflicts: drivers/clk/hisilicon/clk-hi6220.c
Adds clk support for the pl031 RTC on hi6220 Signed-off-by: John Stultz <[email protected]>
Add DT bindings documentation for hi6220 SoC reset controller. Signed-off-by: Chen Feng <[email protected]> Signed-off-by: Philipp Zabel <[email protected]> Acked-by: Rob Herring <[email protected]>
Add reset driver for hi6220-hikey board,this driver supply deassert of IP on hi6220 SoC. Signed-off-by: Chen Feng <[email protected]> Signed-off-by: Philipp Zabel <[email protected]>
We need to include <linux/module.h> to build the driver as a loadable module: drivers/reset/hisilicon/hi6220_reset.c:108:1: warning: data definition has no type or storage class postcore_initcall(hi6220_reset_init); Signed-off-by: Arnd Bergmann <[email protected]>
Workaround/Hack Disable hispeed to make usb host mode work with mice/keyboard Signed-off-by: John Stultz <[email protected]>
Add Hi6220 gpio configuration nodes Signed-off-by: Zhong Kaihua <[email protected]> Signed-off-by: Kong Xinwei <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Wei Xu <[email protected]>
Add Hi6220 pinctrl configuration nodes Signed-off-by: Zhong Kaihua <[email protected]>
Add Hi6220 spi configuration nodes Signed-off-by: Zhong Kaihua <[email protected]> Signed-off-by: Wei Xu <[email protected]>
This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc use this I2C IP of Synopsys Designware for HiKey board. Signed-off-by: Xinwei Kong <[email protected]> Signed-off-by: Chen Feng <[email protected]> Signed-off-by: Wei Xu <[email protected]>
…ards Signed-off-by: Guodong Xu <[email protected]> Conflicts: arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
Signed-off-by: Zhangfei Gao <[email protected]> Signed-off-by: Wei Xu <[email protected]>
This patch add device mailbox node for Hi6220 in DT. Signed-off-by: Leo Yan <[email protected]> Signed-off-by: Wei Xu <[email protected]>
Enable SRAM node and stub clock node for Hi6220, which uses mailbox channel 1 for CPU's frequency change. Furthermore, add the CPU clock phandle in CPU's node and using operating-points-v2 to register operating points. So can be used by cpufreq-dt driver. Signed-off-by: Leo Yan <[email protected]> Signed-off-by: Wei Xu <[email protected]>
Add pinctrl for uart2 uart3 and uart4. Enable uart1 uart2 and uart3. Signed-off-by: Guodong Xu <[email protected]>
Signed-off-by: Guodong Xu <[email protected]>
Add all three dwmmc nodes description for hi6220 Signed-off-by: Guodong Xu <[email protected]> Signed-off-by: Xinwei Kong <[email protected]>
Add resets property into dwmmc_0, dwmmc_1 and dwmmc_2 for hi6220 Signed-off-by: Guodong Xu <[email protected]> arm64: dts: hi6220: add resets in dwmmc_2 Signed-off-by: Guodong Xu <[email protected]>
Add wifi nodes support for hi6220-hikey Signed-off-by: Guodong Xu <[email protected]>
Configures foundation-v8 with OP-TEE. Signed-off-by: Jens Wiklander <[email protected]>
Adds qemu-v8 with OP-TEE and PSCI. Signed-off-by: Jens Wiklander <[email protected]>
Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Reviewed-by: Pascal Brand <[email protected]>
This PR is based on following topic branch: https://github.com/linaro-swg/linux/commits/optee |
Add @jenswi-linaro @jbech-linaro @rsalveti |
Configures Juno with OP-TEE. Reviewed-by: Pascal Brand <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
Signed-off-by: Joakim Bech <[email protected]> Reviewed-by: Pascal Brand <[email protected]>
Signed-off-by: Victor Chong <[email protected]>
In HiKey project, I don't want to include modifications to other dt. d8813b6 arm64: dt: Add OP-TEE firmware to mt8173 not for mainline Victor, and @jenswi-linaro @jbech-linaro @rsalveti -Guodong |
@docularxu That's fine. I have them here for consistency sake with the https://github.com/linaro-swg/linux/commits/optee reference branch, but if you don't want those, do you want me to remove them, or you will remove them yourself? These changes are already merged by @idlethread (Amit) to RPK (https://github.com/96boards/linux/commits/96b/releases/2016.06) on April 21st. Thanks! |
Since SWG doesn't want to maintain an OP-TEE branch on a vanilla 4.4 and I On Fri, Apr 29, 2016 at 3:00 PM, Victor [email protected] wrote:
|
f5d0b7f
to
8ad4c62
Compare
4d18c02
to
55b65ae
Compare
55b65ae
to
f841975
Compare
4ac587b
to
3828f09
Compare
212b200
to
3a75664
Compare
Closing this PR as it's not required anymore due to this repo now having its own op-tee tracking branch @ https://github.com/96boards-hikey/linux/commits/hikey-tracking-optee. |
Starting with commit d94a461 ("ath9k: use ieee80211_tx_status_noskb where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls and suspicious RCU usage: =============================== [ INFO: suspicious RCU usage. ] 4.9.0-rc8 #11 Not tainted ------------------------------- kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 0 RCU used illegally from extended quiescent state! 1 lock held by swapper/7/0: #0: ( rcu_read_lock ){......} , at: [<ffffffffa06ed110>] ath_tx_edma_tasklet+0x0/0x450 [ath9k] stack backtrace: CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11 Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013 ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001 ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8 ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4 Call Trace: <IRQ> [<ffffffff8132b1e5>] dump_stack+0x68/0x93 [<ffffffff810a25f7>] lockdep_rcu_suspicious+0xd7/0x110 [<ffffffff810c3cd4>] rcu_eqs_enter_common.constprop.85+0x154/0x200 [<ffffffff810c5a54>] rcu_irq_exit+0x44/0xa0 [<ffffffff81058631>] irq_exit+0x61/0xd0 [<ffffffff81018d25>] do_IRQ+0x65/0x110 [<ffffffff81672189>] common_interrupt+0x89/0x89 <EOI> [<ffffffff814ffe11>] ? cpuidle_enter_state+0x151/0x200 [<ffffffff814ffee2>] cpuidle_enter+0x12/0x20 [<ffffffff8109a6ae>] call_cpuidle+0x1e/0x40 [<ffffffff8109a8f6>] cpu_startup_entry+0x146/0x220 [<ffffffff810336f8>] start_secondary+0x148/0x170 Signed-off-by: Tobias Klausmann <[email protected]> Fixes: d94a461 ("ath9k: use ieee80211_tx_status_noskb where possible") Cc: <[email protected]> # v4.9 Acked-by: Felix Fietkau <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Tested-by: Gabriel Craciunescu <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
[ Upstream commit 45caeaa ] As Eric Dumazet pointed out this also needs to be fixed in IPv6. v2: Contains the IPv6 tcp/Ipv6 dccp patches as well. We have seen a few incidents lately where a dst_enty has been freed with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that dst_entry. If the conditions/timings are right a crash then ensues when the freed dst_entry is referenced later on. A Common crashing back trace is: #8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . #9 [] tcp_rcv_established at ffffffff81580b64 #10 [] tcp_v4_do_rcv at ffffffff8158b54a #11 [] tcp_v4_rcv at ffffffff8158cd02 #12 [] ip_local_deliver_finish at ffffffff815668f4 #13 [] ip_local_deliver at ffffffff81566bd9 #14 [] ip_rcv_finish at ffffffff8156656d #15 [] ip_rcv at ffffffff81566f06 #16 [] __netif_receive_skb_core at ffffffff8152b3a2 #17 [] __netif_receive_skb at ffffffff8152b608 #18 [] netif_receive_skb at ffffffff8152b690 #19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] #20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] #21 [] net_rx_action at ffffffff8152bac2 #22 [] __do_softirq at ffffffff81084b4f #23 [] call_softirq at ffffffff8164845c #24 [] do_softirq at ffffffff81016fc5 #25 [] irq_exit at ffffffff81084ee5 #26 [] do_IRQ at ffffffff81648ff8 Of course it may happen with other NIC drivers as well. It's found the freed dst_entry here: 224 static bool tcp_in_quickack_mode(struct sock *sk)↩ 225 {↩ 226 ▹ const struct inet_connection_sock *icsk = inet_csk(sk);↩ 227 ▹ const struct dst_entry *dst = __sk_dst_get(sk);↩ 228 ↩ 229 ▹ return (dst && dst_metric(dst, RTAX_QUICKACK)) ||↩ 230 ▹ ▹ (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);↩ 231 }↩ But there are other backtraces attributed to the same freed dst_entry in netfilter code as well. All the vmcores showed 2 significant clues: - Remote hosts behind the default gateway had always been redirected to a different gateway. A rtable/dst_entry will be added for that host. Making more dst_entrys with lower reference counts. Making this more probable. - All vmcores showed a postitive LockDroppedIcmps value, e.g: LockDroppedIcmps 267 A closer look at the tcp_v4_err() handler revealed that do_redirect() will run regardless of whether user space has the socket locked. This can result in a race condition where the same dst_entry cached in sk->sk_dst_entry can be decremented twice for the same socket via: do_redirect()->__sk_dst_check()-> dst_release(). Which leads to the dst_entry being prematurely freed with another socket pointing to it via sk->sk_dst_cache and a subsequent crash. To fix this skip do_redirect() if usespace has the socket locked. Instead let the redirect take place later when user space does not have the socket locked. The dccp/IPv6 code is very similar in this respect, so fixing it there too. As Eric Garver pointed out the following commit now invalidates routes. Which can set the dst->obsolete flag so that ipv4_dst_check() returns null and triggers the dst_release(). Fixes: ceb3320 ("ipv4: Kill routes during PMTU/redirect updates.") Cc: Eric Garver <[email protected]> Cc: Hannes Sowa <[email protected]> Signed-off-by: Jon Maxwell <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 4dfce57 upstream. There have been several reports over the years of NULL pointer dereferences in xfs_trans_log_inode during xfs_fsr processes, when the process is doing an fput and tearing down extents on the temporary inode, something like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 PID: 29439 TASK: ffff880550584fa0 CPU: 6 COMMAND: "xfs_fsr" [exception RIP: xfs_trans_log_inode+0x10] #9 [ffff8800a57bbbe0] xfs_bunmapi at ffffffffa037398e [xfs] #10 [ffff8800a57bbce8] xfs_itruncate_extents at ffffffffa0391b29 [xfs] #11 [ffff8800a57bbd88] xfs_inactive_truncate at ffffffffa0391d0c [xfs] #12 [ffff8800a57bbdb8] xfs_inactive at ffffffffa0392508 [xfs] #13 [ffff8800a57bbdd8] xfs_fs_evict_inode at ffffffffa035907e [xfs] #14 [ffff8800a57bbe00] evict at ffffffff811e1b67 #15 [ffff8800a57bbe28] iput at ffffffff811e23a5 #16 [ffff8800a57bbe58] dentry_kill at ffffffff811dcfc8 #17 [ffff8800a57bbe88] dput at ffffffff811dd06c #18 [ffff8800a57bbea8] __fput at ffffffff811c823b #19 [ffff8800a57bbef0] ____fput at ffffffff811c846e #20 [ffff8800a57bbf00] task_work_run at ffffffff81093b27 #21 [ffff8800a57bbf30] do_notify_resume at ffffffff81013b0c #22 [ffff8800a57bbf50] int_signal at ffffffff8161405d As it turns out, this is because the i_itemp pointer, along with the d_ops pointer, has been overwritten with zeros when we tear down the extents during truncate. When the in-core inode fork on the temporary inode used by xfs_fsr was originally set up during the extent swap, we mistakenly looked at di_nextents to determine whether all extents fit inline, but this misses extents generated by speculative preallocation; we should be using if_bytes instead. This mistake corrupts the in-memory inode, and code in xfs_iext_remove_inline eventually gets bad inputs, causing it to memmove and memset incorrect ranges; this became apparent because the two values in ifp->if_u2.if_inline_ext[1] contained what should have been in d_ops and i_itemp; they were memmoved due to incorrect array indexing and then the original locations were zeroed with memset, again due to an array overrun. Fix this by properly using i_df.if_bytes to determine the number of extents, not di_nextents. Thanks to dchinner for looking at this with me and spotting the root cause. [nborisov: backported to 4.4] Cc: [email protected] Signed-off-by: Eric Sandeen <[email protected]> Reviewed-by: Brian Foster <[email protected]> Signed-off-by: Dave Chinner <[email protected]> Signed-off-by: Nikolay Borisov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> -- fs/xfs/xfs_bmap_util.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
On powerpc we can build the kernel with two different ABIs for mcount(), which is used by ftrace. Kernels built with one ABI do not know how to load modules built with the other ABI. The new style ABI is called "mprofile-kernel", for want of a better name. Currently if we build a module using the old style ABI, and the kernel with mprofile-kernel, when we load the module we'll oops something like: # insmod autofs4-no-mprofile-kernel.ko ftrace-powerpc: Unexpected instruction f8810028 around bl _mcount ------------[ cut here ]------------ WARNING: CPU: 6 PID: 3759 at ../kernel/trace/ftrace.c:2024 ftrace_bug+0x2b8/0x3c0 CPU: 6 PID: 3759 Comm: insmod Not tainted 4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 #11 ... NIP [c0000000001eaa48] ftrace_bug+0x2b8/0x3c0 LR [c0000000001eaff8] ftrace_process_locs+0x4a8/0x590 Call Trace: alloc_pages_current+0xc4/0x1d0 (unreliable) ftrace_process_locs+0x4a8/0x590 load_module+0x1c8c/0x28f0 SyS_finit_module+0x110/0x140 system_call+0x38/0xfc ... ftrace failed to modify [<d000000002a31024>] 0xd000000002a31024 actual: 35:65:00:48 We can avoid this by including in the vermagic whether the kernel/module was built with mprofile-kernel. Which results in: # insmod autofs4-pg.ko autofs4: version magic '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 SMP mod_unload modversions ' should be '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269-dirty SMP mod_unload modversions mprofile-kernel' insmod: ERROR: could not insert module autofs4-pg.ko: Invalid module format Fixes: 8c50b72 ("powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel") Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Balbir Singh <[email protected]> Acked-by: Jessica Yu <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
Thomas reported that 'perf buildid-list' gets a SEGFAULT due to NULL pointer deref when he ran it on a data with namespace events. It was because the buildid_id__mark_dso_hit_ops lacks the namespace event handler and perf_too__fill_default() didn't set it. Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () Missing separate debuginfos, use: dnf debuginfo-install audit-libs-2.7.7-1.fc25.s390x bzip2-libs-1.0.6-21.fc25.s390x elfutils-libelf-0.169-1.fc25.s390x +elfutils-libs-0.169-1.fc25.s390x libcap-ng-0.7.8-1.fc25.s390x numactl-libs-2.0.11-2.ibm.fc25.s390x openssl-libs-1.1.0e-1.1.ibm.fc25.s390x perl-libs-5.24.1-386.fc25.s390x +python-libs-2.7.13-2.fc25.s390x slang-2.3.0-7.fc25.s390x xz-libs-5.2.3-2.fc25.s390x zlib-1.2.8-10.fc25.s390x (gdb) where #0 0x0000000000000000 in ?? () #1 0x00000000010fad6a in machines__deliver_event (machines=<optimized out>, machines@entry=0x2c6fd18, evlist=<optimized out>, event=event@entry=0x3fffdf00470, sample=0x3ffffffe880, sample@entry=0x3ffffffe888, tool=tool@entry=0x1312968 <build_id.mark_dso_hit_ops>, file_offset=1136) at util/session.c:1287 #2 0x00000000010fbf4e in perf_session__deliver_event (file_offset=1136, tool=0x1312968 <build_id.mark_dso_hit_ops>, sample=0x3ffffffe888, event=0x3fffdf00470, session=0x2c6fc30) at util/session.c:1340 #3 perf_session__process_event (session=0x2c6fc30, session@entry=0x0, event=event@entry=0x3fffdf00470, file_offset=file_offset@entry=1136) at util/session.c:1522 #4 0x00000000010fddde in __perf_session__process_events (file_size=11880, data_size=<optimized out>, data_offset=<optimized out>, session=0x0) at util/session.c:1899 #5 perf_session__process_events (session=0x0, session@entry=0x2c6fc30) at util/session.c:1953 #6 0x000000000103b2ac in perf_session__list_build_ids (with_hits=<optimized out>, force=<optimized out>) at builtin-buildid-list.c:83 #7 cmd_buildid_list (argc=<optimized out>, argv=<optimized out>) at builtin-buildid-list.c:115 #8 0x00000000010a026c in run_builtin (p=0x1311f78 <commands+24>, argc=argc@entry=2, argv=argv@entry=0x3fffffff3c0) at perf.c:296 #9 0x000000000102bc00 in handle_internal_command (argv=<optimized out>, argc=2) at perf.c:348 #10 run_argv (argcp=<synthetic pointer>, argv=<synthetic pointer>) at perf.c:392 #11 main (argc=<optimized out>, argv=0x3fffffff3c0) at perf.c:536 (gdb) Fix it by adding a stub event handler for namespace event. Committer testing: Further clarifying, plain using 'perf buildid-list' will not end up in a SEGFAULT when processing a perf.data file with namespace info: # perf record -a --namespaces sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 2.024 MB perf.data (1058 samples) ] # perf buildid-list | wc -l 38 # perf buildid-list | head -5 e2a171c7b905826fc8494f0711ba76ab6abbd604 /lib/modules/4.14.0-rc3+/build/vmlinux 874840a02d8f8a31cedd605d0b8653145472ced3 /lib/modules/4.14.0-rc3+/kernel/arch/x86/kvm/kvm-intel.ko ea7223776730cd8a22f320040aae4d54312984bc /lib/modules/4.14.0-rc3+/kernel/drivers/gpu/drm/i915/i915.ko 5961535e6732a8edb7f22b3f148bb2fa2e0be4b9 /lib/modules/4.14.0-rc3+/kernel/drivers/gpu/drm/drm.ko f045f54aa78cf1931cc893f78b6cbc52c72a8cb1 /usr/lib64/libc-2.25.so # It is only when one asks for checking what of those entries actually had samples, i.e. when we use either -H or --with-hits, that we will process all the PERF_RECORD_ events, and since tools/perf/builtin-buildid-list.c neither explicitely set a perf_tool.namespaces() callback nor the default stub was set that we end up, when processing a PERF_RECORD_NAMESPACE record, causing a SEGFAULT: # perf buildid-list -H Segmentation fault (core dumped) ^C # Reported-and-Tested-by: Thomas-Mich Richter <[email protected]> Signed-off-by: Namhyung Kim <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Hari Bathini <[email protected]> Cc: Hendrik Brueckner <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas-Mich Richter <[email protected]> Fixes: f3b3614 ("perf tools: Add PERF_RECORD_NAMESPACES to include namespaces related info") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Hi @docularxu,
As discussed with @fboudra last night, here are the patches required to support OP-TEE's new generic linux driver. Please review.
Thanks!