Support for WiiU adapter from Mayflash for ODROID XU #150
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mdrjr
added a commit
that referenced
this pull request
Feb 5, 2016
Support for WiiU adapter from Mayflash for ODROID XU
Dmole
pushed a commit
to Dmole/linux
that referenced
this pull request
Apr 19, 2018
commit 87a73eb upstream. It turns out that the loop where we read manufacturer jedec_read_mfd() can under some circumstances get a CFI_MFR_CONTINUATION repeatedly, making the loop go over all banks and eventually hit the end of the map and crash because of an access violation: Unable to handle kernel paging request at virtual address c4980000 pgd = (ptrval) [c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000 Internal error: Oops: 7 [hardkernel#1] PREEMPT ARM CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ hardkernel#150 Hardware name: Gemini (Device Tree) PC is at jedec_probe_chip+0x6ec/0xcd0 LR is at 0x4 pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013 sp : c382dd18 ip : 0000ffff fp : 00000000 r10: c0626388 r9 : 00020000 r8 : c0626340 r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70 r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 0000397f Table: 00004000 DAC: 00000053 Process swapper (pid: 1, stack limit = 0x(ptrval)) Fix this by breaking the loop with a return 0 if the offset exceeds the map size. Fixes: 5c9c11e ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0") Cc: <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Dmole
pushed a commit
to Dmole/linux
that referenced
this pull request
Apr 20, 2018
commit 87a73eb upstream. It turns out that the loop where we read manufacturer jedec_read_mfd() can under some circumstances get a CFI_MFR_CONTINUATION repeatedly, making the loop go over all banks and eventually hit the end of the map and crash because of an access violation: Unable to handle kernel paging request at virtual address c4980000 pgd = (ptrval) [c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000 Internal error: Oops: 7 [hardkernel#1] PREEMPT ARM CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ hardkernel#150 Hardware name: Gemini (Device Tree) PC is at jedec_probe_chip+0x6ec/0xcd0 LR is at 0x4 pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013 sp : c382dd18 ip : 0000ffff fp : 00000000 r10: c0626388 r9 : 00020000 r8 : c0626340 r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70 r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 0000397f Table: 00004000 DAC: 00000053 Process swapper (pid: 1, stack limit = 0x(ptrval)) Fix this by breaking the loop with a return 0 if the offset exceeds the map size. Fixes: 5c9c11e ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0") Cc: <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mdrjr
pushed a commit
that referenced
this pull request
Jun 18, 2018
commit 87a73eb upstream. It turns out that the loop where we read manufacturer jedec_read_mfd() can under some circumstances get a CFI_MFR_CONTINUATION repeatedly, making the loop go over all banks and eventually hit the end of the map and crash because of an access violation: Unable to handle kernel paging request at virtual address c4980000 pgd = (ptrval) [c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000 Internal error: Oops: 7 [#1] PREEMPT ARM CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150 Hardware name: Gemini (Device Tree) PC is at jedec_probe_chip+0x6ec/0xcd0 LR is at 0x4 pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013 sp : c382dd18 ip : 0000ffff fp : 00000000 r10: c0626388 r9 : 00020000 r8 : c0626340 r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70 r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 0000397f Table: 00004000 DAC: 00000053 Process swapper (pid: 1, stack limit = 0x(ptrval)) Fix this by breaking the loop with a return 0 if the offset exceeds the map size. Fixes: 5c9c11e ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0") Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Ben Hutchings <[email protected]>
ardje
pushed a commit
to ardje/linux
that referenced
this pull request
Apr 5, 2020
[ Upstream commit 8ffd573 ] Running the contrib/test/test-media script in v4l-utils with the vivid argument will cause this kernel warning: [ 104.748720] videodev: v4l2_release [ 104.748731] ------------[ cut here ]------------ [ 104.748750] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 104.748790] WARNING: CPU: 6 PID: 1823 at kernel/locking/mutex.c:938 __mutex_lock+0x919/0xc10 [ 104.748800] Modules linked in: rc_cec vivid v4l2_tpg videobuf2_dma_contig cec rc_core v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc vmw_balloon vmw_vmci button vmwgfx [ 104.748845] CPU: 6 PID: 1823 Comm: sleep Not tainted 5.4.0-rc1-test-no hardkernel#150 [ 104.748853] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [ 104.748867] RIP: 0010:__mutex_lock+0x919/0xc10 [ 104.748878] Code: 59 83 e8 9a fc 16 ff 44 8b 05 23 61 38 01 45 85 c0 0f 85 ef f7 ff ff 48 c7 c6 a0 1f 87 82 48 c7 c7 a0 1e 87 82 e8 cd bb f7 fe <0f> 0b e9 d5 f7 ff ff f6 c3 04 0f 84 3b fd ff ff 49 89 df 41 83 e7 [ 104.748886] RSP: 0018:ffff88811a357b80 EFLAGS: 00010286 [ 104.748895] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 104.748902] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffed102346af62 [ 104.748910] RBP: ffff88811a357cf0 R08: ffffffff81217c91 R09: fffffbfff061c271 [ 104.748917] R10: fffffbfff061c270 R11: ffffffff830e1383 R12: ffff8881a46103c0 [ 104.748924] R13: 0000000000000000 R14: ffff8881a4614f90 R15: ffff8881a46153d0 [ 104.748933] FS: 0000000000000000(0000) GS:ffff8881b6780000(0000) knlGS:0000000000000000 [ 104.748940] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 104.748949] CR2: 00007f163fc9ca20 CR3: 0000000003013004 CR4: 00000000001606e0 [ 104.749036] Call Trace: [ 104.749051] ? _raw_spin_unlock+0x1f/0x30 [ 104.749067] ? llist_add_batch+0x33/0x50 [ 104.749081] ? tick_nohz_tick_stopped+0x19/0x30 [ 104.749130] ? v4l2_release.cold+0x6c/0xd6 [videodev] [ 104.749143] ? mutex_lock_io_nested+0xb80/0xb80 [ 104.749153] ? vprintk_emit+0xf2/0x220 [ 104.749191] ? vivid_req_validate+0x40/0x40 [vivid] [ 104.749201] ? printk+0xad/0xde [ 104.749211] ? kmsg_dump_rewind_nolock+0x54/0x54 [ 104.749226] ? locks_remove_file+0x78/0x2b0 [ 104.749248] ? __fsnotify_update_child_dentry_flags.part.0+0x170/0x170 [ 104.749281] ? vivid_req_validate+0x40/0x40 [vivid] [ 104.749321] ? v4l2_release.cold+0x6c/0xd6 [videodev] [ 104.749361] v4l2_release.cold+0x6c/0xd6 [videodev] [ 104.749378] __fput+0x15a/0x390 [ 104.749393] task_work_run+0xb2/0xe0 [ 104.749407] do_exit+0x4d0/0x1200 [ 104.749422] ? do_user_addr_fault+0x367/0x610 [ 104.749431] ? release_task+0x990/0x990 [ 104.749449] ? rwsem_spin_on_owner+0x170/0x170 [ 104.749463] ? vmacache_find+0xb2/0x100 [ 104.749476] do_group_exit+0x85/0x130 [ 104.749487] __x64_sys_exit_group+0x23/0x30 [ 104.749500] do_syscall_64+0x5e/0x1c0 [ 104.749511] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 104.749520] RIP: 0033:0x7f163fc5c9d6 [ 104.749536] Code: Bad RIP value. [ 104.749543] RSP: 002b:00007ffe6f3bec58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 104.749553] RAX: ffffffffffffffda RBX: 00007f163fd4d760 RCX: 00007f163fc5c9d6 [ 104.749560] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 104.749567] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80 [ 104.749574] R10: 00007ffe6f3beb24 R11: 0000000000000246 R12: 00007f163fd4d760 [ 104.749581] R13: 0000000000000002 R14: 00007f163fd56428 R15: 0000000000000000 [ 104.749597] ---[ end trace 66f20f73fc0daf79 ]--- This is caused by media_device_cleanup() which destroys v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock that mutex after media_device_cleanup() is called. By moving media_device_cleanup() to the v4l2_device's release function it is guaranteed that the mutex is valid whenever v4l2_release is called. Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
ardje
pushed a commit
to ardje/linux
that referenced
this pull request
Apr 5, 2020
[ Upstream commit 693c5f1 ] Running the contrib/test/test-media script in v4l-utils with the vicodec argument will cause this kernel warning: [ 372.298824] ------------[ cut here ]------------ [ 372.298848] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 372.298896] WARNING: CPU: 11 PID: 2220 at kernel/locking/mutex.c:938 __mutex_lock+0x919/0xc10 [ 372.298907] Modules linked in: vicodec v4l2_mem2mem vivid rc_cec v4l2_tpg videobuf2_dma_contig cec rc_core v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc vmw_balloon vmw_vmci button vmwgfx [last unloaded: vimc] [ 372.298961] CPU: 11 PID: 2220 Comm: sleep Not tainted 5.4.0-rc1-test-no hardkernel#150 [ 372.298970] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [ 372.298983] RIP: 0010:__mutex_lock+0x919/0xc10 [ 372.298995] Code: 59 83 e8 9a fc 16 ff 44 8b 05 23 61 38 01 45 85 c0 0f 85 ef f7 ff ff 48 c7 c6 a0 1f 87 82 48 c7 c7 a0 1e 87 82 e8 cd bb f7 fe <0f> 0b e9 d5 f7 ff ff f6 c3 04 0f 84 3b fd ff ff 49 89 df 41 83 e7 [ 372.299004] RSP: 0018:ffff8881b400fb80 EFLAGS: 00010286 [ 372.299014] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 372.299022] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffed1036801f62 [ 372.299030] RBP: ffff8881b400fcf0 R08: ffffffff81217c91 R09: fffffbfff061c271 [ 372.299038] R10: fffffbfff061c270 R11: ffffffff830e1383 R12: ffff88814761dc80 [ 372.299046] R13: 0000000000000000 R14: ffff88814761cbf0 R15: ffff88814761d030 [ 372.299055] FS: 0000000000000000(0000) GS:ffff8881b68c0000(0000) knlGS:0000000000000000 [ 372.299063] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 372.299071] CR2: 00007f606d78aa20 CR3: 0000000003013002 CR4: 00000000001606e0 [ 372.299153] Call Trace: [ 372.299176] ? __kasan_slab_free+0x12f/0x180 [ 372.299187] ? kmem_cache_free+0x9b/0x250 [ 372.299200] ? do_exit+0xcdf/0x1200 [ 372.299210] ? do_group_exit+0x85/0x130 [ 372.299220] ? __x64_sys_exit_group+0x23/0x30 [ 372.299231] ? do_syscall_64+0x5e/0x1c0 [ 372.299241] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 372.299295] ? v4l2_release+0xed/0x190 [videodev] [ 372.299309] ? mutex_lock_io_nested+0xb80/0xb80 [ 372.299323] ? find_held_lock+0x85/0xa0 [ 372.299335] ? fsnotify+0x5b0/0x600 [ 372.299351] ? locks_remove_file+0x78/0x2b0 [ 372.299363] ? __fsnotify_update_child_dentry_flags.part.0+0x170/0x170 [ 372.299383] ? vidioc_querycap+0x50/0x50 [vicodec] [ 372.299426] ? v4l2_release+0xed/0x190 [videodev] [ 372.299467] v4l2_release+0xed/0x190 [videodev] [ 372.299484] __fput+0x15a/0x390 [ 372.299499] task_work_run+0xb2/0xe0 [ 372.299512] do_exit+0x4d0/0x1200 [ 372.299528] ? do_user_addr_fault+0x367/0x610 [ 372.299538] ? release_task+0x990/0x990 [ 372.299552] ? rwsem_spin_on_owner+0x170/0x170 [ 372.299567] ? vmacache_find+0xb2/0x100 [ 372.299580] do_group_exit+0x85/0x130 [ 372.299592] __x64_sys_exit_group+0x23/0x30 [ 372.299602] do_syscall_64+0x5e/0x1c0 [ 372.299614] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 372.299624] RIP: 0033:0x7f606d74a9d6 [ 372.299640] Code: Bad RIP value. [ 372.299648] RSP: 002b:00007fff65364468 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 372.299658] RAX: ffffffffffffffda RBX: 00007f606d83b760 RCX: 00007f606d74a9d6 [ 372.299666] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 372.299673] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80 [ 372.299681] R10: 00007fff65364334 R11: 0000000000000246 R12: 00007f606d83b760 [ 372.299689] R13: 0000000000000002 R14: 00007f606d844428 R15: 0000000000000000 [ 372.299704] ---[ end trace add7d62ca4bc65e3 ]--- This is caused by media_device_cleanup() which destroys v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock that mutex after media_device_cleanup() is called. By moving media_device_cleanup() to the v4l2_device's release function it is guaranteed that the mutex is valid whenever v4l2_release is called. Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As I also want to use my WiiU adapter on ODROID XU4 I ask you to merge this request also for this kernel version. It is a copy of this pull request for the 3.8 kernel:
#89