Rock Pi S enable and fix tsadc #3

piter75 · 2019-09-05T18:32:05Z

Enabled tsadc and fixed channels assignment for thermal zones.

RK3308 TRM Part 1
26.5.1 Channel Select
The system has two Temperature Sensors, channel 0 is for logic power domain and channel 1 is for core power domain.

According to RK3308 TRM Part 1: 26.5.1 Channel Select The system has two Temperature Sensors, channel 0 is for logic power domain and channel 1 is for core power domain.

commit cf3591e upstream. Revert the commit bd293d0. The proper fix has been made available with commit d0a255e ("loop: set PF_MEMALLOC_NOIO for the worker thread"). Note that the fix offered by commit bd293d0 doesn't really prevent the deadlock from occuring - if we look at the stacktrace reported by Junxiao Bi, we see that it hangs in bit_wait_io and not on the mutex - i.e. it has already successfully taken the mutex. Changing the mutex from mutex_lock to mutex_trylock won't help with deadlocks that happen afterwards. PID: 474 TASK: ffff8813e11f4600 CPU: 10 COMMAND: "kswapd0" #0 [ffff8813dedfb938] __schedule at ffffffff8173f405 radxa#1 [ffff8813dedfb990] schedule at ffffffff8173fa27 radxa#2 [ffff8813dedfb9b0] schedule_timeout at ffffffff81742fec radxa#3 [ffff8813dedfba60] io_schedule_timeout at ffffffff8173f186 radxa#4 [ffff8813dedfbaa0] bit_wait_io at ffffffff8174034f radxa#5 [ffff8813dedfbac0] __wait_on_bit at ffffffff8173fec8 radxa#6 [ffff8813dedfbb10] out_of_line_wait_on_bit at ffffffff8173ff81 radxa#7 [ffff8813dedfbb90] __make_buffer_clean at ffffffffa038736f [dm_bufio] radxa#8 [ffff8813dedfbbb0] __try_evict_buffer at ffffffffa0387bb8 [dm_bufio] radxa#9 [ffff8813dedfbbd0] dm_bufio_shrink_scan at ffffffffa0387cc3 [dm_bufio] radxa#10 [ffff8813dedfbc40] shrink_slab at ffffffff811a87ce radxa#11 [ffff8813dedfbd30] shrink_zone at ffffffff811ad778 radxa#12 [ffff8813dedfbdc0] kswapd at ffffffff811ae92f radxa#13 [ffff8813dedfbec0] kthread at ffffffff810a8428 radxa#14 [ffff8813dedfbf50] ret_from_fork at ffffffff81745242 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Fixes: bd293d0 ("dm bufio: fix deadlock with loop device") Depends-on: d0a255e ("loop: set PF_MEMALLOC_NOIO for the worker thread") Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The locking in lirc needs improvement, but for now just fix this potential deadlock. ====================================================== [ INFO: possible circular locking dependency detected ] 4.10.0-rc1+ #1 Not tainted ------------------------------------------------------- bash/2502 is trying to acquire lock: (ir_raw_handler_lock){+.+.+.}, at: [<ffffffffc06f6a5e>] ir_raw_encode_scancode+0x3e/0xb0 [rc_core] but task is already holding lock: (&dev->lock){+.+.+.}, at: [<ffffffffc06f511f>] store_filter+0x9f/0x240 [rc_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dev->lock){+.+.+.}: [<ffffffffa110adad>] lock_acquire+0xfd/0x200 [<ffffffffa1921327>] mutex_lock_nested+0x77/0x6d0 [<ffffffffc06f436a>] rc_open+0x2a/0x80 [rc_core] [<ffffffffc07114ca>] lirc_dev_fop_open+0xda/0x1e0 [lirc_dev] [<ffffffffa12975e0>] chrdev_open+0xb0/0x210 [<ffffffffa128eb5a>] do_dentry_open+0x20a/0x2f0 [<ffffffffa128ffcc>] vfs_open+0x4c/0x80 [<ffffffffa12a35ec>] path_openat+0x5bc/0xc00 [<ffffffffa12a5271>] do_filp_open+0x91/0x100 [<ffffffffa12903f0>] do_sys_open+0x130/0x220 [<ffffffffa12904fe>] SyS_open+0x1e/0x20 [<ffffffffa19278c1>] entry_SYSCALL_64_fastpath+0x1f/0xc2 -> #1 (lirc_dev_lock){+.+.+.}: [<ffffffffa110adad>] lock_acquire+0xfd/0x200 [<ffffffffa1921327>] mutex_lock_nested+0x77/0x6d0 [<ffffffffc0711f47>] lirc_register_driver+0x67/0x59b [lirc_dev] [<ffffffffc06db7f4>] ir_lirc_register+0x1f4/0x260 [ir_lirc_codec] [<ffffffffc06f6cac>] ir_raw_handler_register+0x7c/0xb0 [rc_core] [<ffffffffc0398010>] 0xffffffffc0398010 [<ffffffffa1002192>] do_one_initcall+0x52/0x1b0 [<ffffffffa11ef5c8>] do_init_module+0x5f/0x1fa [<ffffffffa11566b5>] load_module+0x2675/0x2b00 [<ffffffffa1156dcf>] SYSC_finit_module+0xdf/0x110 [<ffffffffa1156e1e>] SyS_finit_module+0xe/0x10 [<ffffffffa1003f5c>] do_syscall_64+0x6c/0x1f0 [<ffffffffa1927989>] return_from_SYSCALL_64+0x0/0x7a -> #0 (ir_raw_handler_lock){+.+.+.}: [<ffffffffa110a7b7>] __lock_acquire+0x10f7/0x1290 [<ffffffffa110adad>] lock_acquire+0xfd/0x200 [<ffffffffa1921327>] mutex_lock_nested+0x77/0x6d0 [<ffffffffc06f6a5e>] ir_raw_encode_scancode+0x3e/0xb0 [rc_core] [<ffffffffc0b0f492>] loop_set_wakeup_filter+0x62/0xbd [rc_loopback] [<ffffffffc06f522a>] store_filter+0x1aa/0x240 [rc_core] [<ffffffffa15e46f8>] dev_attr_store+0x18/0x30 [<ffffffffa13318e5>] sysfs_kf_write+0x45/0x60 [<ffffffffa1330b55>] kernfs_fop_write+0x155/0x1e0 [<ffffffffa1290797>] __vfs_write+0x37/0x160 [<ffffffffa12921f8>] vfs_write+0xc8/0x1e0 [<ffffffffa12936e8>] SyS_write+0x58/0xc0 [<ffffffffa19278c1>] entry_SYSCALL_64_fastpath+0x1f/0xc2 other info that might help us debug this: Chain exists of: ir_raw_handler_lock --> lirc_dev_lock --> &dev->lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(lirc_dev_lock); lock(&dev->lock); lock(ir_raw_handler_lock); *** DEADLOCK *** 4 locks held by bash/2502: #0: (sb_writers#4){.+.+.+}, at: [<ffffffffa12922c5>] vfs_write+0x195/0x1e0 #1: (&of->mutex){+.+.+.}, at: [<ffffffffa1330b1f>] kernfs_fop_write+0x11f/0x1e0 #2: (s_active#215){.+.+.+}, at: [<ffffffffa1330b28>] kernfs_fop_write+0x128/0x1e0 #3: (&dev->lock){+.+.+.}, at: [<ffffffffc06f511f>] store_filter+0x9f/0x240 [rc_core] stack backtrace: CPU: 3 PID: 2502 Comm: bash Not tainted 4.10.0-rc1+ #1 Hardware name: /DG45ID, BIOS IDG4510H.86A.0135.2011.0225.1100 02/25/2011 Call Trace: dump_stack+0x86/0xc3 print_circular_bug+0x1be/0x210 __lock_acquire+0x10f7/0x1290 lock_acquire+0xfd/0x200 ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core] ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core] mutex_lock_nested+0x77/0x6d0 ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core] ? loop_set_wakeup_filter+0x44/0xbd [rc_loopback] ir_raw_encode_scancode+0x3e/0xb0 [rc_core] loop_set_wakeup_filter+0x62/0xbd [rc_loopback] ? loop_set_tx_duty_cycle+0x70/0x70 [rc_loopback] store_filter+0x1aa/0x240 [rc_core] dev_attr_store+0x18/0x30 sysfs_kf_write+0x45/0x60 kernfs_fop_write+0x155/0x1e0 __vfs_write+0x37/0x160 ? rcu_read_lock_sched_held+0x4a/0x80 ? rcu_sync_lockdep_assert+0x2f/0x60 ? __sb_start_write+0x10c/0x220 ? vfs_write+0x195/0x1e0 ? security_file_permission+0x3b/0xc0 vfs_write+0xc8/0x1e0 SyS_write+0x58/0xc0 entry_SYSCALL_64_fastpath+0x1f/0xc2 Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> (cherry picked from commit db5b15b) Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com> (cherry picked from commit ae7d753) Signed-off-by: Lin Jianhua <linjh@rock-chips.com>

commit dea37a9 upstream. Syzkaller report this: BUG: KASAN: use-after-free in sysfs_remove_file_ns+0x5f/0x70 fs/sysfs/file.c:468 Read of size 8 at addr ffff8881f59a6b70 by task syz-executor.0/8363 CPU: 0 PID: 8363 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xfa/0x1ce lib/dump_stack.c:113 print_address_description+0x65/0x270 mm/kasan/report.c:187 kasan_report+0x149/0x18d mm/kasan/report.c:317 sysfs_remove_file_ns+0x5f/0x70 fs/sysfs/file.c:468 sysfs_remove_file include/linux/sysfs.h:519 [inline] driver_remove_file+0x40/0x50 drivers/base/driver.c:122 usb_remove_newid_files drivers/usb/core/driver.c:212 [inline] usb_deregister+0x12a/0x3b0 drivers/usb/core/driver.c:1005 cpia2_exit+0xa/0x16 [cpia2] __do_sys_delete_module kernel/module.c:1018 [inline] __se_sys_delete_module kernel/module.c:961 [inline] __x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f86f3754c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000300 RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f86f37556bc R13: 00000000004bcca9 R14: 00000000006f6b48 R15: 00000000ffffffff Allocated by task 8363: set_track mm/kasan/common.c:85 [inline] __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:495 kmalloc include/linux/slab.h:545 [inline] kzalloc include/linux/slab.h:740 [inline] bus_add_driver+0xc0/0x610 drivers/base/bus.c:651 driver_register+0x1bb/0x3f0 drivers/base/driver.c:170 usb_register_driver+0x267/0x520 drivers/usb/core/driver.c:965 0xffffffffc1b4817c do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 8363: set_track mm/kasan/common.c:85 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:457 slab_free_hook mm/slub.c:1430 [inline] slab_free_freelist_hook mm/slub.c:1457 [inline] slab_free mm/slub.c:3005 [inline] kfree+0xe1/0x270 mm/slub.c:3957 kobject_cleanup lib/kobject.c:662 [inline] kobject_release lib/kobject.c:691 [inline] kref_put include/linux/kref.h:67 [inline] kobject_put+0x146/0x240 lib/kobject.c:708 bus_remove_driver+0x10e/0x220 drivers/base/bus.c:732 driver_unregister+0x6c/0xa0 drivers/base/driver.c:197 usb_register_driver+0x341/0x520 drivers/usb/core/driver.c:980 0xffffffffc1b4817c do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8881f59a6b40 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 48 bytes inside of 256-byte region [ffff8881f59a6b40, ffff8881f59a6c40) The buggy address belongs to the page: page:ffffea0007d66980 count:1 mapcount:0 mapping:ffff8881f6c02e00 index:0x0 flags: 0x2fffc0000000200(slab) raw: 02fffc0000000200 dead000000000100 dead000000000200 ffff8881f6c02e00 raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881f59a6a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881f59a6a80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc >ffff8881f59a6b00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff8881f59a6b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881f59a6c00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc cpia2_init does not check return value of cpia2_init, if it failed in usb_register_driver, there is already cleanup using driver_unregister. No need call cpia2_usb_cleanup on module exit. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…emove commit d27e5e0 upstream. With this early return due to zfcp_unit child(ren), we don't use the zfcp_port reference from the earlier zfcp_get_port_by_wwpn() anymore and need to put it. Signed-off-by: Steffen Maier <maier@linux.ibm.com> Fixes: d99b601 ("[SCSI] zfcp: restore refcount check on port_remove") Cc: <stable@vger.kernel.org> #3.7+ Reviewed-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 347ab94 ] This patch fixes deadlock warning if removing PWM device when CONFIG_PROVE_LOCKING is enabled. This issue can be reproceduced by the following steps on the R-Car H3 Salvator-X board if the backlight is disabled: # cd /sys/class/pwm/pwmchip0 # echo 0 > export # ls device export npwm power pwm0 subsystem uevent unexport # cd device/driver # ls bind e6e31000.pwm uevent unbind # echo e6e31000.pwm > unbind [ 87.659974] ====================================================== [ 87.666149] WARNING: possible circular locking dependency detected [ 87.672327] 5.0.0 #7 Not tainted [ 87.675549] ------------------------------------------------------ [ 87.681723] bash/2986 is trying to acquire lock: [ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0 [ 87.694528] [ 87.694528] but task is already holding lock: [ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.707405] [ 87.707405] which lock already depends on the new lock. [ 87.707405] [ 87.715574] [ 87.715574] the existing dependency chain (in reverse order) is: [ 87.723048] [ 87.723048] -> #1 (pwm_lock){+.+.}: [ 87.728017] __mutex_lock+0x70/0x7e4 [ 87.732108] mutex_lock_nested+0x1c/0x24 [ 87.736547] pwm_request_from_chip.part.6+0x34/0x74 [ 87.741940] pwm_request_from_chip+0x20/0x40 [ 87.746725] export_store+0x6c/0x1f4 [ 87.750820] dev_attr_store+0x18/0x28 [ 87.754998] sysfs_kf_write+0x54/0x64 [ 87.759175] kernfs_fop_write+0xe4/0x1e8 [ 87.763615] __vfs_write+0x40/0x184 [ 87.767619] vfs_write+0xa8/0x19c [ 87.771448] ksys_write+0x58/0xbc [ 87.775278] __arm64_sys_write+0x18/0x20 [ 87.779721] el0_svc_common+0xd0/0x124 [ 87.783986] el0_svc_compat_handler+0x1c/0x24 [ 87.788858] el0_svc_compat+0x8/0x18 [ 87.792947] [ 87.792947] -> #0 (kn->count#58){++++}: [ 87.798260] lock_acquire+0xc4/0x22c [ 87.802353] __kernfs_remove+0x258/0x2c4 [ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0 [ 87.811836] remove_files.isra.1+0x38/0x78 [ 87.816447] sysfs_remove_group+0x48/0x98 [ 87.820971] sysfs_remove_groups+0x34/0x4c [ 87.825583] device_remove_attrs+0x6c/0x7c [ 87.830197] device_del+0x11c/0x33c [ 87.834201] device_unregister+0x14/0x2c [ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c [ 87.843509] pwmchip_remove+0xf4/0x13c [ 87.847773] rcar_pwm_remove+0x28/0x34 [ 87.852039] platform_drv_remove+0x24/0x64 [ 87.856651] device_release_driver_internal+0x18c/0x21c [ 87.862391] device_release_driver+0x14/0x1c [ 87.867175] unbind_store+0xe0/0x124 [ 87.871265] drv_attr_store+0x20/0x30 [ 87.875442] sysfs_kf_write+0x54/0x64 [ 87.879618] kernfs_fop_write+0xe4/0x1e8 [ 87.884055] __vfs_write+0x40/0x184 [ 87.888057] vfs_write+0xa8/0x19c [ 87.891887] ksys_write+0x58/0xbc [ 87.895716] __arm64_sys_write+0x18/0x20 [ 87.900154] el0_svc_common+0xd0/0x124 [ 87.904417] el0_svc_compat_handler+0x1c/0x24 [ 87.909289] el0_svc_compat+0x8/0x18 [ 87.913378] [ 87.913378] other info that might help us debug this: [ 87.913378] [ 87.921374] Possible unsafe locking scenario: [ 87.921374] [ 87.927286] CPU0 CPU1 [ 87.931808] ---- ---- [ 87.936331] lock(pwm_lock); [ 87.939293] lock(kn->count#58); [ 87.945120] lock(pwm_lock); [ 87.950599] lock(kn->count#58); [ 87.953908] [ 87.953908] *** DEADLOCK *** [ 87.953908] [ 87.959821] 4 locks held by bash/2986: [ 87.963563] #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c [ 87.971044] #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8 [ 87.978872] #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c [ 87.988001] #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.995481] [ 87.995481] stack backtrace: [ 87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7 [ 88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT) [ 88.012791] Call trace: [ 88.015235] dump_backtrace+0x0/0x190 [ 88.018891] show_stack+0x14/0x1c [ 88.022204] dump_stack+0xb0/0xec [ 88.025514] print_circular_bug.isra.32+0x1d0/0x2e0 [ 88.030385] __lock_acquire+0x1318/0x1864 [ 88.034388] lock_acquire+0xc4/0x22c [ 88.037958] __kernfs_remove+0x258/0x2c4 [ 88.041874] kernfs_remove_by_name_ns+0x50/0xa0 [ 88.046398] remove_files.isra.1+0x38/0x78 [ 88.050487] sysfs_remove_group+0x48/0x98 [ 88.054490] sysfs_remove_groups+0x34/0x4c [ 88.058580] device_remove_attrs+0x6c/0x7c [ 88.062671] device_del+0x11c/0x33c [ 88.066154] device_unregister+0x14/0x2c [ 88.070070] pwmchip_sysfs_unexport+0x40/0x4c [ 88.074421] pwmchip_remove+0xf4/0x13c [ 88.078163] rcar_pwm_remove+0x28/0x34 [ 88.081906] platform_drv_remove+0x24/0x64 [ 88.085996] device_release_driver_internal+0x18c/0x21c [ 88.091215] device_release_driver+0x14/0x1c [ 88.095478] unbind_store+0xe0/0x124 [ 88.099048] drv_attr_store+0x20/0x30 [ 88.102704] sysfs_kf_write+0x54/0x64 [ 88.106359] kernfs_fop_write+0xe4/0x1e8 [ 88.110275] __vfs_write+0x40/0x184 [ 88.113757] vfs_write+0xa8/0x19c [ 88.117065] ksys_write+0x58/0xbc [ 88.120374] __arm64_sys_write+0x18/0x20 [ 88.124291] el0_svc_common+0xd0/0x124 [ 88.128034] el0_svc_compat_handler+0x1c/0x24 [ 88.132384] el0_svc_compat+0x8/0x18 The sysfs unexport in pwmchip_remove() is completely asymmetric to what we do in pwmchip_add_with_polarity() and commit 0733424 ("pwm: Unexport children before chip removal") is a strong indication that this was wrong to begin with. We should just move pwmchip_sysfs_unexport() where it belongs, which is right after pwmchip_sysfs_unexport_children(). In that case, we do not need separate functions anymore either. We also really want to remove sysfs irrespective of whether or not the chip will be removed as a result of pwmchip_remove(). We can only assume that the driver will be gone after that, so we shouldn't leave any dangling sysfs files around. This warning disappears if we move pwmchip_sysfs_unexport() to the top of pwmchip_remove(), pwmchip_sysfs_unexport_children(). That way it is also outside of the pwm_lock section, which indeed doesn't seem to be needed. Moving the pwmchip_sysfs_export() call outside of that section also seems fine and it'd be perfectly symmetric with pwmchip_remove() again. So, this patch fixes them. Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com> [shimoda: revise the commit log and code] Fixes: 76abbdd ("pwm: Add sysfs interface") Fixes: 0733424 ("pwm: Unexport children before chip removal") Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Hoan Nguyen An <na-hoan@jinso.co.jp> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 5518424 ] ifmsh->csa is an RCU-protected pointer. The writer context in ieee80211_mesh_finish_csa() is already mutually exclusive with wdev->sdata.mtx, but the RCU checker did not know this. Use rcu_dereference_protected() to avoid a warning. fixes the following warning: [ 12.519089] ============================= [ 12.520042] WARNING: suspicious RCU usage [ 12.520652] 5.1.0-rc7-wt+ #16 Tainted: G W [ 12.521409] ----------------------------- [ 12.521972] net/mac80211/mesh.c:1223 suspicious rcu_dereference_check() usage! [ 12.522928] other info that might help us debug this: [ 12.523984] rcu_scheduler_active = 2, debug_locks = 1 [ 12.524855] 5 locks held by kworker/u8:2/152: [ 12.525438] #0: 00000000057be08c ((wq_completion)phy0){+.+.}, at: process_one_work+0x1a2/0x620 [ 12.526607] #1: 0000000059c6b07a ((work_completion)(&sdata->csa_finalize_work)){+.+.}, at: process_one_work+0x1a2/0x620 [ 12.528001] #2: 00000000f184ba7d (&wdev->mtx){+.+.}, at: ieee80211_csa_finalize_work+0x2f/0x90 [ 12.529116] #3: 00000000831a1f54 (&local->mtx){+.+.}, at: ieee80211_csa_finalize_work+0x47/0x90 [ 12.530233] #4: 00000000fd06f988 (&local->chanctx_mtx){+.+.}, at: ieee80211_csa_finalize_work+0x51/0x90 Signed-off-by: Thomas Pedersen <thomas@eero.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit b387e9b ] When system memory is in heavy pressure, bch_gc_thread_start() from run_cache_set() may fail due to out of memory. In such condition, c->gc_thread is assigned to -ENOMEM, not NULL pointer. Then in following failure code path bch_cache_set_error(), when cache_set_flush() gets called, the code piece to stop c->gc_thread is broken, if (!IS_ERR_OR_NULL(c->gc_thread)) kthread_stop(c->gc_thread); And KASAN catches such NULL pointer deference problem, with the warning information: [ 561.207881] ================================================================== [ 561.207900] BUG: KASAN: null-ptr-deref in kthread_stop+0x3b/0x440 [ 561.207904] Write of size 4 at addr 000000000000001c by task kworker/15:1/313 [ 561.207913] CPU: 15 PID: 313 Comm: kworker/15:1 Tainted: G W 5.0.0-vanilla+ #3 [ 561.207916] Hardware name: Lenovo ThinkSystem SR650 -[7X05CTO1WW]-/-[7X05CTO1WW]-, BIOS -[IVE136T-2.10]- 03/22/2019 [ 561.207935] Workqueue: events cache_set_flush [bcache] [ 561.207940] Call Trace: [ 561.207948] dump_stack+0x9a/0xeb [ 561.207955] ? kthread_stop+0x3b/0x440 [ 561.207960] ? kthread_stop+0x3b/0x440 [ 561.207965] kasan_report+0x176/0x192 [ 561.207973] ? kthread_stop+0x3b/0x440 [ 561.207981] kthread_stop+0x3b/0x440 [ 561.207995] cache_set_flush+0xd4/0x6d0 [bcache] [ 561.208008] process_one_work+0x856/0x1620 [ 561.208015] ? find_held_lock+0x39/0x1d0 [ 561.208028] ? drain_workqueue+0x380/0x380 [ 561.208048] worker_thread+0x87/0xb80 [ 561.208058] ? __kthread_parkme+0xb6/0x180 [ 561.208067] ? process_one_work+0x1620/0x1620 [ 561.208072] kthread+0x326/0x3e0 [ 561.208079] ? kthread_create_worker_on_cpu+0xc0/0xc0 [ 561.208090] ret_from_fork+0x3a/0x50 [ 561.208110] ================================================================== [ 561.208113] Disabling lock debugging due to kernel taint [ 561.208115] irq event stamp: 11800231 [ 561.208126] hardirqs last enabled at (11800231): [<ffffffff83008538>] do_syscall_64+0x18/0x410 [ 561.208127] BUG: unable to handle kernel NULL pointer dereference at 000000000000001c [ 561.208129] #PF error: [WRITE] [ 561.312253] hardirqs last disabled at (11800230): [<ffffffff830052ff>] trace_hardirqs_off_thunk+0x1a/0x1c [ 561.312259] softirqs last enabled at (11799832): [<ffffffff850005c7>] __do_softirq+0x5c7/0x8c3 [ 561.405975] PGD 0 P4D 0 [ 561.442494] softirqs last disabled at (11799821): [<ffffffff831add2c>] irq_exit+0x1ac/0x1e0 [ 561.791359] Oops: 0002 [#1] SMP KASAN NOPTI [ 561.791362] CPU: 15 PID: 313 Comm: kworker/15:1 Tainted: G B W 5.0.0-vanilla+ #3 [ 561.791363] Hardware name: Lenovo ThinkSystem SR650 -[7X05CTO1WW]-/-[7X05CTO1WW]-, BIOS -[IVE136T-2.10]- 03/22/2019 [ 561.791371] Workqueue: events cache_set_flush [bcache] [ 561.791374] RIP: 0010:kthread_stop+0x3b/0x440 [ 561.791376] Code: 00 00 65 8b 05 26 d5 e0 7c 89 c0 48 0f a3 05 ec aa df 02 0f 82 dc 02 00 00 4c 8d 63 20 be 04 00 00 00 4c 89 e7 e8 65 c5 53 00 <f0> ff 43 20 48 8d 7b 24 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 [ 561.791377] RSP: 0018:ffff88872fc8fd10 EFLAGS: 00010286 [ 561.838895] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838916] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838934] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838948] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838966] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838979] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838996] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 563.067028] RAX: 0000000000000000 RBX: fffffffffffffffc RCX: ffffffff832dd314 [ 563.067030] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000297 [ 563.067032] RBP: ffff88872fc8fe88 R08: fffffbfff0b8213d R09: fffffbfff0b8213d [ 563.067034] R10: 0000000000000001 R11: fffffbfff0b8213c R12: 000000000000001c [ 563.408618] R13: ffff88dc61cc0f68 R14: ffff888102b94900 R15: ffff88dc61cc0f68 [ 563.408620] FS: 0000000000000000(0000) GS:ffff888f7dc00000(0000) knlGS:0000000000000000 [ 563.408622] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 563.408623] CR2: 000000000000001c CR3: 0000000f48a1a004 CR4: 00000000007606e0 [ 563.408625] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 563.408627] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 563.904795] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 563.915796] PKRU: 55555554 [ 563.915797] Call Trace: [ 563.915807] cache_set_flush+0xd4/0x6d0 [bcache] [ 563.915812] process_one_work+0x856/0x1620 [ 564.001226] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 564.033563] ? find_held_lock+0x39/0x1d0 [ 564.033567] ? drain_workqueue+0x380/0x380 [ 564.033574] worker_thread+0x87/0xb80 [ 564.062823] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 564.118042] ? __kthread_parkme+0xb6/0x180 [ 564.118046] ? process_one_work+0x1620/0x1620 [ 564.118048] kthread+0x326/0x3e0 [ 564.118050] ? kthread_create_worker_on_cpu+0xc0/0xc0 [ 564.167066] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 564.252441] ret_from_fork+0x3a/0x50 [ 564.252447] Modules linked in: msr rpcrdma sunrpc rdma_ucm ib_iser ib_umad rdma_cm ib_ipoib i40iw configfs iw_cm ib_cm libiscsi scsi_transport_iscsi mlx4_ib ib_uverbs mlx4_en ib_core nls_iso8859_1 nls_cp437 vfat fat intel_rapl skx_edac x86_pkg_temp_thermal coretemp iTCO_wdt iTCO_vendor_support crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ses raid0 aesni_intel cdc_ether enclosure usbnet ipmi_ssif joydev aes_x86_64 i40e scsi_transport_sas mii bcache md_mod crypto_simd mei_me ioatdma crc64 ptp cryptd pcspkr i2c_i801 mlx4_core glue_helper pps_core mei lpc_ich dca wmi ipmi_si ipmi_devintf nd_pmem dax_pmem nd_btt ipmi_msghandler device_dax pcc_cpufreq button hid_generic usbhid mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect xhci_pci sysimgblt fb_sys_fops xhci_hcd ttm megaraid_sas drm usbcore nfit libnvdimm sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs [ 564.299390] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 564.348360] CR2: 000000000000001c [ 564.348362] ---[ end trace b7f0e5cc7b2103b0 ]--- Therefore, it is not enough to only check whether c->gc_thread is NULL, we should use IS_ERR_OR_NULL() to check both NULL pointer and error value. This patch changes the above buggy code piece in this way, if (!IS_ERR_OR_NULL(c->gc_thread)) kthread_stop(c->gc_thread); Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>

Channel halt with unknown reason happens in the following case: DWC2 + USB 2.0 HUB + HS Device + FS Device The HS Device is an optical fingerprint: usb 1-1.4: USB disconnect, device number 5 usb 1-1.4: new high-speed USB device number 6 using dwc2 usb 1-1.4: New USB device found, idVendor=28ed, idProduct=7000 usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.4: Product: Aratek Capture Device usb 1-1.4: Manufacturer: Aratek The FS Device is an ID card identification module: usb 1-1.3: new full-speed USB device number 9 using dwc2 usb 1-1.3: New USB device found, idVendor=0400, idProduct=c35a usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 When the issuse occurs, it always dump the error log: dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 13 - ChHltd set, but reason is unknown dwc2 ff540000.usb: hcint 0x00000002, intsts 0x04000021 dwc2 ff540000.usb: dwc2_update_urb_state_abn(): trimming xfer length ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/hcd.c:2796 dwc2_assign_and_init_hc+0x554/0x8e4() Modules linked in: bcmdhd CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.143 #3 Hardware name: Generic DT based system [<c010f854>] (unwind_backtrace) from [<c010bb84>] (show_stack+0x10/0x14) [<c010bb84>] (show_stack) from [<c03ed8b4>] (dump_stack+0x7c/0x9c) [<c03ed8b4>] (dump_stack) from [<c012737c>] (warn_slowpath_common+0x88/0xb4) [<c012737c>] (warn_slowpath_common) from [<c0127488>] (warn_slowpath_null+0x18/0x20) [<c0127488>] (warn_slowpath_null) from [<c05c8314>] (dwc2_assign_and_init_hc+0x554/0x8e4) [<c05c8314>] (dwc2_assign_and_init_hc) from [<c05c8788>] (dwc2_hcd_select_transactions+0xe4/0x178) [<c05c8788>] (dwc2_hcd_select_transactions) from [<c05ca0e4>] (dwc2_release_channel+0x1b8/0x1cc) [<c05ca0e4>] (dwc2_release_channel) from [<c05cbaa8>] (dwc2_hc_n_intr+0x4a0/0x728) [<c05cbaa8>] (dwc2_hc_n_intr) from [<c05cc1dc>] (dwc2_handle_hcd_intr+0x4ac/0x4d8) [<c05cc1dc>] (dwc2_handle_hcd_intr) from [<c05b247c>] (usb_hcd_irq+0x24/0x38) [<c05b247c>] (usb_hcd_irq) from [<c017dea4>] (handle_irq_event_percpu+0xa8/0x28c) [<c017dea4>] (handle_irq_event_percpu) from [<c017e0c0>] (handle_irq_event+0x38/0x5c) [<c017e0c0>] (handle_irq_event) from [<c0181560>] (handle_fasteoi_irq+0xa8/0x124) [<c0181560>] (handle_fasteoi_irq) from [<c017d5cc>] (generic_handle_irq+0x18/0x28) [<c017d5cc>] (generic_handle_irq) from [<c017d890>] (__handle_domain_irq+0x88/0xb0) [<c017d890>] (__handle_domain_irq) from [<c010142c>] (gic_handle_irq+0x44/0x74) [<c010142c>] (gic_handle_irq) from [<c010c554>] (__irq_svc+0x54/0x90) This patch only clears the unmask interrupts to avoid trigger unknown Channel Halted interrupt. However, if the Channel Halted interrupt happens unexpected, we need to check if the urb->length is 4-byte alignment in dwc2_update_urb_state_abn(), this can help to avoid the above warning. Change-Id: I501e7d2e5194d5fe3ad797b05cf400ecc95387f0 Signed-off-by: William Wu <william.wu@rock-chips.com>

Channel halt with unknown reason happens in the following case: DWC2 + USB 2.0 HUB + HS Device + FS Device The HS Device is an optical fingerprint: usb 1-1.4: USB disconnect, device number 5 usb 1-1.4: new high-speed USB device number 6 using dwc2 usb 1-1.4: New USB device found, idVendor=28ed, idProduct=7000 usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.4: Product: Aratek Capture Device usb 1-1.4: Manufacturer: Aratek The FS Device is an ID card identification module: usb 1-1.3: new full-speed USB device number 9 using dwc2 usb 1-1.3: New USB device found, idVendor=0400, idProduct=c35a usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 When the issuse occurs, it always dump the error log: dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 13 - ChHltd set, but reason is unknown dwc2 ff540000.usb: hcint 0x00000002, intsts 0x04000021 dwc2 ff540000.usb: dwc2_update_urb_state_abn(): trimming xfer length ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/hcd.c:2796 dwc2_assign_and_init_hc+0x554/0x8e4() Modules linked in: bcmdhd CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.143 #3 Hardware name: Generic DT based system [<c010f854>] (unwind_backtrace) from [<c010bb84>] (show_stack+0x10/0x14) [<c010bb84>] (show_stack) from [<c03ed8b4>] (dump_stack+0x7c/0x9c) [<c03ed8b4>] (dump_stack) from [<c012737c>] (warn_slowpath_common+0x88/0xb4) [<c012737c>] (warn_slowpath_common) from [<c0127488>] (warn_slowpath_null+0x18/0x20) [<c0127488>] (warn_slowpath_null) from [<c05c8314>] (dwc2_assign_and_init_hc+0x554/0x8e4) [<c05c8314>] (dwc2_assign_and_init_hc) from [<c05c8788>] (dwc2_hcd_select_transactions+0xe4/0x178) [<c05c8788>] (dwc2_hcd_select_transactions) from [<c05ca0e4>] (dwc2_release_channel+0x1b8/0x1cc) [<c05ca0e4>] (dwc2_release_channel) from [<c05cbaa8>] (dwc2_hc_n_intr+0x4a0/0x728) [<c05cbaa8>] (dwc2_hc_n_intr) from [<c05cc1dc>] (dwc2_handle_hcd_intr+0x4ac/0x4d8) [<c05cc1dc>] (dwc2_handle_hcd_intr) from [<c05b247c>] (usb_hcd_irq+0x24/0x38) [<c05b247c>] (usb_hcd_irq) from [<c017dea4>] (handle_irq_event_percpu+0xa8/0x28c) [<c017dea4>] (handle_irq_event_percpu) from [<c017e0c0>] (handle_irq_event+0x38/0x5c) [<c017e0c0>] (handle_irq_event) from [<c0181560>] (handle_fasteoi_irq+0xa8/0x124) [<c0181560>] (handle_fasteoi_irq) from [<c017d5cc>] (generic_handle_irq+0x18/0x28) [<c017d5cc>] (generic_handle_irq) from [<c017d890>] (__handle_domain_irq+0x88/0xb0) [<c017d890>] (__handle_domain_irq) from [<c010142c>] (gic_handle_irq+0x44/0x74) [<c010142c>] (gic_handle_irq) from [<c010c554>] (__irq_svc+0x54/0x90) This patch only clears the unmask interrupts to avoid trigger unknown Channel Halted interrupt. However, if the Channel Halted interrupt happens unexpected, we need to check if the urb->length is 4-byte alignment in dwc2_update_urb_state_abn(), this can help to avoid the above warning. Change-Id: I501e7d2e5194d5fe3ad797b05cf400ecc95387f0 Signed-off-by: William Wu <william.wu@rock-chips.com> (cherry picked from commit dc94bc2) Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>

This patch add support for DMA-based digital loopback. BACKGROUND Audio Products with AEC require loopback for echo cancellation. the hardware LP is not always available on some products, maybe the HW limitation(such as internal acodec) or HW Cost-down. This patch add support software DLP for such products. Enable: CONFIG_SND_SOC_ROCKCHIP_DLP &i2s { rockchip,digital-loopback; }; Mode List: amixer contents numid=2,iface=MIXER,name='Software Digital Loopback Mode' ; type=ENUMERATED,access=rw------,values=1,items=7 ; Item #0 'Disabled' ; Item #1 '2CH: 1 Loopback + 1 Mic' ; Item #2 '2CH: 1 Mic + 1 Loopback' ; Item #3 '2CH: 1 Mic + 1 Loopback-mixed' ; Item #4 '2CH: 2 Loopbacks' ; Item #5 '4CH: 2 Mics + 2 Loopbacks' ; Item #6 '4CH: 2 Mics + 1 Loopback-mixed' : values=0 Testenv: wired SDO0 --> SDI0 directly to get external digital loopback as reference. Testcase: dlp.sh /#!/bin/sh item=0 id=`amixer contents | grep "Software Digital Loopback" | \ awk -F ',' '{print $1}'` items=`amixer contents | grep -A 1 "Software Digital Loopback" | \ grep items | awk -F 'items=' '{print $2}'` echo "Software Digital Loopback: $id, items: $items" mode_chs() { case $1 in [0-4]) echo "2" ;; [5-6]) echo "4" ;; *) echo "2" ;; esac } while true do ch=`mode_chs $item` amixer -c 0 cset $id $item arecord -D hw:0,0 --period-size=1024 --buffer-size=4096 -r 48000 -c $ch -f s16_le \ -d 15 sine/dlp_$item.wav & sleep 2 for i in $(seq 1 10) do aplay -D hw:0,0 --period-size=1024 --buffer-size=8192 $((ch))ch.wav -d 1 done pid=$(ps | egrep "aplay|arecord" | grep -v grep | awk '{print $1}' | sort -r) for p in $pid do wait $p 2>/dev/null done item=$((item+1)) if [ $item -ge $items ]; then sleep 1 break fi done echo "Done" Result: do shell test and verify dlp_x.wav: * Alignment: ~1 samples shift (loopback <-> mics). * Integrity: no giltch, no data lost. * AEC: align loopback and mics sample and do simple AEC, get clean waveform. Logs: ... numid=2,iface=MIXER,name='Software Digital Loopback Mode' ; type=ENUMERATED,access=rw------,values=1,items=7 ; Item #0 'Disabled' ; Item #1 '2CH: 1 Loopback + 1 Mic' ; Item #2 '2CH: 1 Mic + 1 Loopback' ; Item #3 '2CH: 1 Mic + 1 Loopback-mixed' ; Item #4 '2CH: 2 Loopbacks' ; Item #5 '4CH: 2 Mics + 2 Loopbacks' ; Item #6 '4CH: 2 Mics + 1 Loopback-mixed' : values=2 Recording WAVE 'sine/dlp_2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE '2ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE '2ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE '2ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE '2ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE '2ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE '2ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE '2ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE '2ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE '2ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE '2ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo ... numid=2,iface=MIXER,name='Software Digital Loopback Mode' ; type=ENUMERATED,access=rw------,values=1,items=7 ; Item #0 'Disabled' ; Item #1 '2CH: 1 Loopback + 1 Mic' ; Item #2 '2CH: 1 Mic + 1 Loopback' ; Item #3 '2CH: 1 Mic + 1 Loopback-mixed' ; Item #4 '2CH: 2 Loopbacks' ; Item #5 '4CH: 2 Mics + 2 Loopbacks' ; Item #6 '4CH: 2 Mics + 1 Loopback-mixed' : values=6 Recording WAVE 'sine/dlp_6.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Playing WAVE '4ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Playing WAVE '4ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Playing WAVE '4ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Playing WAVE '4ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Playing WAVE '4ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Playing WAVE '4ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Playing WAVE '4ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Playing WAVE '4ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Playing WAVE '4ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Playing WAVE '4ch.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Done Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com> Change-Id: I5772f0694f7a14a0f0bd1f0777b6c4cdbd781a64

Example: RK3588 Use I2S2_2CH as Clk-Gen to serve TDM_MULTI_LANES I2S2_2CH ----> BCLK,I2S_LRCK --------> I2S0_8CH_TX (Slave TRCM-TXONLY) | |--------> BCLK,TDM_SYNC --------> TDM Device (Slave) Note: I2S2_2CH_MCLK: BCLK I2S2_2CH_SCLK: I2S_LRCK (GPIO2_B7) I2S2_2CH_LRCK: TDM_SYNC (GPIO2_C0) DT: &i2s0_8ch { status = "okay"; assigned-clocks = <&cru I2S0_8CH_MCLKOUT>; assigned-clock-parents = <&cru MCLK_I2S0_8CH_TX>; i2s-lrck-gpio = <&gpio1 RK_PC5 GPIO_ACTIVE_HIGH>; tdm-fsync-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_HIGH>; rockchip,tdm-multi-lanes; rockchip,tdm-tx-lanes = <2>; //e.g. TDM16 x 2 rockchip,tdm-rx-lanes = <2>; //e.g. TDM16 x 2 rockchip,clk-src = <&i2s2_2ch>; pinctrl-names = "default"; pinctrl-0 = <&i2s0_lrck &i2s0_sclk &i2s0_sdi0 &i2s0_sdi1 &i2s0_sdo0 &i2s0_sdo1>; }; &i2s2_2ch { status = "okay"; assigned-clocks = <&cru I2S2_2CH_MCLKOUT>; assigned-clock-parents = <&cru MCLK_I2S2_2CH>; pinctrl-names = "default"; pinctrl-0 = <&i2s2m0_mclk &i2s2m0_lrck &i2s2m0_sclk>; }; Usage: TDM16 x 2 Playback amixer contents numid=3,iface=MIXER,name='Receive SDIx Select' ; type=ENUMERATED,access=rw------,values=1,items=5 ; Item #0 'Auto' ; Item radxa#1 'SDIx1' ; Item radxa#2 'SDIx2' ; Item radxa#3 'SDIx3' ; Item radxa#4 'SDIx4' : values=0 numid=2,iface=MIXER,name='Transmit SDOx Select' ; type=ENUMERATED,access=rw------,values=1,items=5 ; Item #0 'Auto' ; Item radxa#1 'SDOx1' ; Item radxa#2 'SDOx2' ; Item radxa#3 'SDOx3' ; Item radxa#4 'SDOx4' : values=0 /# amixer sset "Transmit SDOx Select" "SDOx2" Simple mixer control 'Transmit SDOx Select',0 Capabilities: enum Items: 'Auto' 'SDOx1' 'SDOx2' 'SDOx3' 'SDOx4' Item0: 'SDOx2' /# aplay -D hw:0,0 --period-size=1024 --buffer-size=4096 -r 48000 \ -c 32 -f s32_le /dev/zero Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com> Change-Id: I6996e05c73a9d68bbeb9562eb6e68e4c99b52d85

[ Upstream commit c42b145 ] In idtentry_vc(), vc_switch_off_ist() determines a safe stack to switch to, off of the IST stack. Annotate the new stack switch with ENCODE_FRAME_POINTER in case UNWINDER_FRAME_POINTER is used. A stack walk before looks like this: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc7+ #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl dump_stack kernel_exc_vmm_communication asm_exc_vmm_communication ? native_read_msr ? __x2apic_disable.part.0 ? x2apic_setup ? cpu_init ? trap_init ? start_kernel ? x86_64_start_reservations ? x86_64_start_kernel ? secondary_startup_64_no_verify </TASK> and with the fix, the stack dump is exact: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc7+ #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl dump_stack kernel_exc_vmm_communication asm_exc_vmm_communication RIP: 0010:native_read_msr Code: ... < snipped regs > ? __x2apic_disable.part.0 x2apic_setup cpu_init trap_init start_kernel x86_64_start_reservations x86_64_start_kernel secondary_startup_64_no_verify </TASK> [ bp: Test in a SEV-ES guest and rewrite the commit message to explain what exactly this does. ] Fixes: a13644f ("x86/entry/64: Add entry code for #VC handler") Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20220316041612.71357-1-jiangshanlai@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>

piter75 added 2 commits September 5, 2019 18:23

Enabled tsadc for Rock Pi S

2166932

Fixed tsadc channels for rk3308

0612792

According to RK3308 TRM Part 1: 26.5.1 Channel Select The system has two Temperature Sensors, channel 0 is for logic power domain and channel 1 is for core power domain.

hipboi requested a review from StephenInVamrs September 6, 2019 10:41

StephenInVamrs merged commit 5dbd30f into radxa:stable-4.4-rockpis Sep 6, 2019

piter75 deleted the rock-pi-s-enable-tsadc branch March 22, 2020 19:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rock Pi S enable and fix tsadc #3

Rock Pi S enable and fix tsadc #3

piter75 commented Sep 5, 2019

Rock Pi S enable and fix tsadc #3

Rock Pi S enable and fix tsadc #3

Conversation

piter75 commented Sep 5, 2019