linux-stable.git/drivers/mailbox, branch v4.19.321 Linux kernel stable tree mailbox: ti-msgmgr: Fill non-message tx data fields with 0x0 2023-08-11T09:45:13+00:00 Nishanth Menon nm@ti.com 2023-06-21T01:00:22+00:00 391dcc9204560e1b5c2275f67f9cb26d5a48e511 [ Upstream commit 1b712f18c461bd75f018033a15cf381e712806b5 ] Sec proxy/message manager data buffer is 60 bytes with the last of the registers indicating transmission completion. This however poses a bit of a challenge. The backing memory for sec_proxy / message manager is regular memory, and all sec proxy does is to trigger a burst of all 60 bytes of data over to the target thread backing ring accelerator. It doesn't do a memory scrub when it moves data out in the burst. When we transmit multiple messages, remnants of previous message is also transmitted which results in some random data being set in TISCI fields of messages that have been expanded forward. The entire concept of backward compatibility hinges on the fact that the unused message fields remain 0x0 allowing for 0x0 value to be specially considered when backward compatibility of message extension is done. So, instead of just writing the completion register, we continue to fill the message buffer up with 0x0 (note: for partial message involving completion, we already do this). This allows us to scale and introduce ABI changes back also work with other boot stages that may have left data in the internal memory. While at this, be consistent and explicit with the data_reg pointer increment. Fixes: aace66b170ce ("mailbox: Introduce TI message manager driver") Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 1b712f18c461bd75f018033a15cf381e712806b5 ]

Sec proxy/message manager data buffer is 60 bytes with the last of the
registers indicating transmission completion. This however poses a bit
of a challenge.

The backing memory for sec_proxy / message manager is regular memory,
and all sec proxy does is to trigger a burst of all 60 bytes of data
over to the target thread backing ring accelerator. It doesn't do a
memory scrub when it moves data out in the burst. When we transmit
multiple messages, remnants of previous message is also transmitted
which results in some random data being set in TISCI fields of
messages that have been expanded forward.

The entire concept of backward compatibility hinges on the fact that
the unused message fields remain 0x0 allowing for 0x0 value to be
specially considered when backward compatibility of message extension
is done.

So, instead of just writing the completion register, we continue
to fill the message buffer up with 0x0 (note: for partial message
involving completion, we already do this).

This allows us to scale and introduce ABI changes back also work with
other boot stages that may have left data in the internal memory.

While at this, be consistent and explicit with the data_reg pointer
increment.

Fixes: aace66b170ce ("mailbox: Introduce TI message manager driver")
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mailbox: mailbox-test: fix a locking issue in mbox_test_message_write() 2023-06-09T08:24:01+00:00 Dan Carpenter dan.carpenter@linaro.org 2023-05-05T09:22:09+00:00 b1fc302c934d3a9497d339c3f7a93a4e076f5f02 [ Upstream commit 8fe72b76db79d694858e872370df49676bc3be8c ] There was a bug where this code forgot to unlock the tdev->mutex if the kzalloc() failed. Fix this issue, by moving the allocation outside the lock. Fixes: 2d1e952a2b8e ("mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write()") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Lee Jones <lee@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8fe72b76db79d694858e872370df49676bc3be8c ]

There was a bug where this code forgot to unlock the tdev->mutex if the
kzalloc() failed.  Fix this issue, by moving the allocation outside the
lock.

Fixes: 2d1e952a2b8e ("mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write()")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write() 2023-06-09T08:23:57+00:00 Lee Jones lee@kernel.org 2023-04-20T07:27:18+00:00 aa0e6dd395061196e6e6aa57774c320e05fb7798 [ Upstream commit 2d1e952a2b8e5e92d8d55ac88a7cf7ca5ea591ad ] If a user can make copy_from_user() fail, there is a potential for UAF/DF due to a lack of locking around the allocation, use and freeing of the data buffers. This issue is not theoretical. I managed to author a POC for it: BUG: KASAN: double-free in kfree+0x5c/0xac Free of addr ffff29280be5de00 by task poc/356 CPU: 1 PID: 356 Comm: poc Not tainted 6.1.0-00001-g961aa6552c04-dirty #20 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x64/0x80 print_report+0x188/0x48c kasan_report_invalid_free+0xa0/0xc0 ____kasan_slab_free+0x174/0x1b0 __kasan_slab_free+0x18/0x24 __kmem_cache_free+0x130/0x2e0 kfree+0x5c/0xac mbox_test_message_write+0x208/0x29c full_proxy_write+0x90/0xf0 vfs_write+0x154/0x440 ksys_write+0xcc/0x180 __arm64_sys_write+0x44/0x60 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x40/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xf4/0x120 el0t_64_sync+0x18c/0x190 Allocated by task 356: kasan_save_stack+0x3c/0x70 kasan_set_track+0x2c/0x40 kasan_save_alloc_info+0x24/0x34 __kasan_kmalloc+0xb8/0xc0 kmalloc_trace+0x58/0x70 mbox_test_message_write+0x6c/0x29c full_proxy_write+0x90/0xf0 vfs_write+0x154/0x440 ksys_write+0xcc/0x180 __arm64_sys_write+0x44/0x60 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x40/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xf4/0x120 el0t_64_sync+0x18c/0x190 Freed by task 357: kasan_save_stack+0x3c/0x70 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/0x5c ____kasan_slab_free+0x13c/0x1b0 __kasan_slab_free+0x18/0x24 __kmem_cache_free+0x130/0x2e0 kfree+0x5c/0xac mbox_test_message_write+0x208/0x29c full_proxy_write+0x90/0xf0 vfs_write+0x154/0x440 ksys_write+0xcc/0x180 __arm64_sys_write+0x44/0x60 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x40/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xf4/0x120 el0t_64_sync+0x18c/0x190 Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2d1e952a2b8e5e92d8d55ac88a7cf7ca5ea591ad ]

If a user can make copy_from_user() fail, there is a potential for
UAF/DF due to a lack of locking around the allocation, use and freeing
of the data buffers.

This issue is not theoretical.  I managed to author a POC for it:

    BUG: KASAN: double-free in kfree+0x5c/0xac
    Free of addr ffff29280be5de00 by task poc/356
    CPU: 1 PID: 356 Comm: poc Not tainted 6.1.0-00001-g961aa6552c04-dirty #20
    Hardware name: linux,dummy-virt (DT)
    Call trace:
     dump_backtrace.part.0+0xe0/0xf0
     show_stack+0x18/0x40
     dump_stack_lvl+0x64/0x80
     print_report+0x188/0x48c
     kasan_report_invalid_free+0xa0/0xc0
     ____kasan_slab_free+0x174/0x1b0
     __kasan_slab_free+0x18/0x24
     __kmem_cache_free+0x130/0x2e0
     kfree+0x5c/0xac
     mbox_test_message_write+0x208/0x29c
     full_proxy_write+0x90/0xf0
     vfs_write+0x154/0x440
     ksys_write+0xcc/0x180
     __arm64_sys_write+0x44/0x60
     invoke_syscall+0x60/0x190
     el0_svc_common.constprop.0+0x7c/0x160
     do_el0_svc+0x40/0xf0
     el0_svc+0x2c/0x6c
     el0t_64_sync_handler+0xf4/0x120
     el0t_64_sync+0x18c/0x190

    Allocated by task 356:
     kasan_save_stack+0x3c/0x70
     kasan_set_track+0x2c/0x40
     kasan_save_alloc_info+0x24/0x34
     __kasan_kmalloc+0xb8/0xc0
     kmalloc_trace+0x58/0x70
     mbox_test_message_write+0x6c/0x29c
     full_proxy_write+0x90/0xf0
     vfs_write+0x154/0x440
     ksys_write+0xcc/0x180
     __arm64_sys_write+0x44/0x60
     invoke_syscall+0x60/0x190
     el0_svc_common.constprop.0+0x7c/0x160
     do_el0_svc+0x40/0xf0
     el0_svc+0x2c/0x6c
     el0t_64_sync_handler+0xf4/0x120
     el0t_64_sync+0x18c/0x190

    Freed by task 357:
     kasan_save_stack+0x3c/0x70
     kasan_set_track+0x2c/0x40
     kasan_save_free_info+0x38/0x5c
     ____kasan_slab_free+0x13c/0x1b0
     __kasan_slab_free+0x18/0x24
     __kmem_cache_free+0x130/0x2e0
     kfree+0x5c/0xac
     mbox_test_message_write+0x208/0x29c
     full_proxy_write+0x90/0xf0
     vfs_write+0x154/0x440
     ksys_write+0xcc/0x180
     __arm64_sys_write+0x44/0x60
     invoke_syscall+0x60/0x190
     el0_svc_common.constprop.0+0x7c/0x160
     do_el0_svc+0x40/0xf0
     el0_svc+0x2c/0x6c
     el0t_64_sync_handler+0xf4/0x120
     el0t_64_sync+0x18c/0x190

Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mailbox: bcm-ferxrm-mailbox: Fix error check for dma_map_sg 2022-10-26T11:19:34+00:00 Jack Wang jinpu.wang@ionos.com 2022-08-26T10:13:35+00:00 83d4f013c17471085a13f8ffba3585f149d395d4 [ Upstream commit 6b207ce8a96a71e966831e3a13c38143ba9a73c1 ] dma_map_sg return 0 on error, fix the error check, and return -EIO to caller. Fixes: dbc049eee730 ("mailbox: Add driver for Broadcom FlexRM ring manager") Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6b207ce8a96a71e966831e3a13c38143ba9a73c1 ]

dma_map_sg return 0 on error, fix the error check, and return -EIO
to caller.

Fixes: dbc049eee730 ("mailbox: Add driver for Broadcom FlexRM ring manager")
Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mailbox: forward the hrtimer if not queued and under a lock 2022-06-14T14:59:25+00:00 Björn Ardö bjorn.ardo@axis.com 2022-03-31T07:01:15+00:00 16b5013fa14beb872b3ca91af3b99a5a985177c5 [ Upstream commit bca1a1004615efe141fd78f360ecc48c60bc4ad5 ] This reverts commit c7dacf5b0f32957b24ef29df1207dc2cd8307743, "mailbox: avoid timer start from callback" The previous commit was reverted since it lead to a race that caused the hrtimer to not be started at all. The check for hrtimer_active() in msg_submit() will return true if the callback function txdone_hrtimer() is currently running. This function could return HRTIMER_NORESTART and then the timer will not be restarted, and also msg_submit() will not start the timer. This will lead to a message actually being submitted but no timer will start to check for its compleation. The original fix that added checking hrtimer_active() was added to avoid a warning with hrtimer_forward. Looking in the kernel another solution to avoid this warning is to check hrtimer_is_queued() before calling hrtimer_forward_now() instead. This however requires a lock so the timer is not started by msg_submit() inbetween this check and the hrtimer_forward() call. Fixes: c7dacf5b0f32 ("mailbox: avoid timer start from callback") Signed-off-by: Björn Ardö <bjorn.ardo@axis.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit bca1a1004615efe141fd78f360ecc48c60bc4ad5 ]

This reverts commit c7dacf5b0f32957b24ef29df1207dc2cd8307743,
"mailbox: avoid timer start from callback"

The previous commit was reverted since it lead to a race that
caused the hrtimer to not be started at all. The check for
hrtimer_active() in msg_submit() will return true if the
callback function txdone_hrtimer() is currently running. This
function could return HRTIMER_NORESTART and then the timer
will not be restarted, and also msg_submit() will not start
the timer. This will lead to a message actually being submitted
but no timer will start to check for its compleation.

The original fix that added checking hrtimer_active() was added to
avoid a warning with hrtimer_forward. Looking in the kernel
another solution to avoid this warning is to check hrtimer_is_queued()
before calling hrtimer_forward_now() instead. This however requires a
lock so the timer is not started by msg_submit() inbetween this check
and the hrtimer_forward() call.

Fixes: c7dacf5b0f32 ("mailbox: avoid timer start from callback")
Signed-off-by: Björn Ardö <bjorn.ardo@axis.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mailbox: avoid timer start from callback 2020-10-30T09:38:21+00:00 Jassi Brar jaswinder.singh@linaro.org 2020-10-16T17:20:56+00:00 8299f4bfa91500e7f648357e9e2a5ef70c0d9d26 [ Upstream commit c7dacf5b0f32957b24ef29df1207dc2cd8307743 ] If the txdone is done by polling, it is possible for msg_submit() to start the timer while txdone_hrtimer() callback is running. If the timer needs recheduling, it could already be enqueued by the time hrtimer_forward_now() is called, leading hrtimer to loudly complain. WARNING: CPU: 3 PID: 74 at kernel/time/hrtimer.c:932 hrtimer_forward+0xc4/0x110 CPU: 3 PID: 74 Comm: kworker/u8:1 Not tainted 5.9.0-rc2-00236-gd3520067d01c-dirty #5 Hardware name: Libre Computer AML-S805X-AC (DT) Workqueue: events_freezable_power_ thermal_zone_device_check pstate: 20000085 (nzCv daIf -PAN -UAO BTYPE=--) pc : hrtimer_forward+0xc4/0x110 lr : txdone_hrtimer+0xf8/0x118 [...] This can be fixed by not starting the timer from the callback path. Which requires the timer reloading as long as any message is queued on the channel, and not just when current tx is not done yet. Fixes: 0cc67945ea59 ("mailbox: switch to hrtimer for tx_complete polling") Reported-by: Da Xue <da@libre.computer> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Jerome Brunet <jbrunet@baylibre.com> Tested-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c7dacf5b0f32957b24ef29df1207dc2cd8307743 ]

If the txdone is done by polling, it is possible for msg_submit() to start
the timer while txdone_hrtimer() callback is running. If the timer needs
recheduling, it could already be enqueued by the time hrtimer_forward_now()
is called, leading hrtimer to loudly complain.

WARNING: CPU: 3 PID: 74 at kernel/time/hrtimer.c:932 hrtimer_forward+0xc4/0x110
CPU: 3 PID: 74 Comm: kworker/u8:1 Not tainted 5.9.0-rc2-00236-gd3520067d01c-dirty #5
Hardware name: Libre Computer AML-S805X-AC (DT)
Workqueue: events_freezable_power_ thermal_zone_device_check
pstate: 20000085 (nzCv daIf -PAN -UAO BTYPE=--)
pc : hrtimer_forward+0xc4/0x110
lr : txdone_hrtimer+0xf8/0x118
[...]

This can be fixed by not starting the timer from the callback path. Which
requires the timer reloading as long as any message is queued on the
channel, and not just when current tx is not done yet.

Fixes: 0cc67945ea59 ("mailbox: switch to hrtimer for tx_complete polling")
Reported-by: Da Xue <da@libre.computer>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mailbox: qcom-apcs: fix max_register value 2020-01-27T13:51:14+00:00 Jorge Ramirez-Ortiz jorge.ramirez-ortiz@linaro.org 2019-09-09T09:08:50+00:00 24d6f60b670d4f63940cc5ff2c28306c47be4b64 [ Upstream commit 556a0964e28c4441dcdd50fb07596fd042246bd5 ] The mailbox length is 0x1000 hence the max_register value is 0xFFC. Fixes: c6a8b171ca8e ("mailbox: qcom: Convert APCS IPC driver to use regmap") Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 556a0964e28c4441dcdd50fb07596fd042246bd5 ]

The mailbox length is 0x1000 hence the max_register value is 0xFFC.

Fixes: c6a8b171ca8e ("mailbox: qcom: Convert APCS IPC driver to use
regmap")
Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mailbox: ti-msgmgr: Off by one in ti_msgmgr_of_xlate() 2020-01-27T13:50:04+00:00 Dan Carpenter dan.carpenter@oracle.com 2018-12-03T14:50:11+00:00 bd8e3189b85c9bac3dfe8a46b97c1c51d203d77a [ Upstream commit 78f3ff524fca63e7d2a57149a34ade23d2c12798 ] The > comparison should be >= or we access one element beyond the end of the array. (The inst->qinsts[] array is allocated in the ti_msgmgr_probe() function and it has ->num_valid_queues elements.) Fixes: a2b79838b891 ("mailbox: ti-msgmgr: Add support for Secure Proxy") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 78f3ff524fca63e7d2a57149a34ade23d2c12798 ]

The > comparison should be >= or we access one element beyond the end
of the array.

(The inst->qinsts[] array is allocated in the ti_msgmgr_probe() function
and it has ->num_valid_queues elements.)

Fixes: a2b79838b891 ("mailbox: ti-msgmgr: Add support for Secure Proxy")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mailbox: mediatek: Add check for possible failure of kzalloc 2020-01-27T13:49:56+00:00 Houlong Wei houlong.wei@mediatek.com 2018-08-21T10:22:44+00:00 e60f60a4cde824604299cb60e83d623b78326ee5 [ Upstream commit 9f0a0a381c5db56e7922dbeea6831f27db58372f ] The patch 623a6143a845("mailbox: mediatek: Add Mediatek CMDQ driver") introduce the following static checker warning: drivers/mailbox/mtk-cmdq-mailbox.c:366 cmdq_mbox_send_data() error: potential null dereference 'task'. (kzalloc returns null) Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Houlong Wei <houlong.wei@mediatek.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9f0a0a381c5db56e7922dbeea6831f27db58372f ]

The patch 623a6143a845("mailbox: mediatek: Add Mediatek CMDQ driver")
introduce the following static checker warning:
  drivers/mailbox/mtk-cmdq-mailbox.c:366 cmdq_mbox_send_data()
  error: potential null dereference 'task'.  (kzalloc returns null)

Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Houlong Wei <houlong.wei@mediatek.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mailbox: imx: Fix Tx doorbell shutdown path 2020-01-04T18:13:17+00:00 Daniel Baluta daniel.baluta@nxp.com 2019-10-09T08:07:18+00:00 e0c0412f478a1d9f323f7fd6189807015e94ddf4 [ Upstream commit bf159d151a0b844be28882f39e316b5800acaa2b ] Tx doorbell is handled by txdb_tasklet and doesn't have an associated IRQ. Anyhow, imx_mu_shutdown ignores this and tries to free an IRQ that wasn't requested for Tx DB resulting in the following warning: [ 1.967644] Trying to free already-free IRQ 26 [ 1.972108] WARNING: CPU: 2 PID: 157 at kernel/irq/manage.c:1708 __free_irq+0xc0/0x358 [ 1.980024] Modules linked in: [ 1.983088] CPU: 2 PID: 157 Comm: kworker/2:1 Tainted: G [ 1.993524] Hardware name: Freescale i.MX8QXP MEK (DT) [ 1.998668] Workqueue: events deferred_probe_work_func [ 2.003812] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 2.008607] pc : __free_irq+0xc0/0x358 [ 2.012364] lr : __free_irq+0xc0/0x358 [ 2.016111] sp : ffff00001179b7e0 [ 2.019422] x29: ffff00001179b7e0 x28: 0000000000000018 [ 2.024736] x27: ffff000011233000 x26: 0000000000000004 [ 2.030053] x25: 000000000000001a x24: ffff80083bec74d4 [ 2.035369] x23: 0000000000000000 x22: ffff80083bec7588 [ 2.040686] x21: ffff80083b1fe8d8 x20: ffff80083bec7400 [ 2.046003] x19: 0000000000000000 x18: ffffffffffffffff [ 2.051320] x17: 0000000000000000 x16: 0000000000000000 [ 2.056637] x15: ffff0000111296c8 x14: ffff00009179b517 [ 2.061953] x13: ffff00001179b525 x12: ffff000011142000 [ 2.067270] x11: ffff000011129f20 x10: ffff0000105da970 [ 2.072587] x9 : 00000000ffffffd0 x8 : 0000000000000194 [ 2.077903] x7 : 612065657266206f x6 : ffff0000111e7b09 [ 2.083220] x5 : 0000000000000003 x4 : 0000000000000000 [ 2.088537] x3 : 0000000000000000 x2 : 00000000ffffffff [ 2.093854] x1 : 28b70f0a2b60a500 x0 : 0000000000000000 [ 2.099173] Call trace: [ 2.101618] __free_irq+0xc0/0x358 [ 2.105021] free_irq+0x38/0x98 [ 2.108170] imx_mu_shutdown+0x90/0xb0 [ 2.111921] mbox_free_channel.part.2+0x24/0xb8 [ 2.116453] mbox_free_channel+0x18/0x28 This bug is present from the beginning of times. Cc: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit bf159d151a0b844be28882f39e316b5800acaa2b ]

Tx doorbell is handled by txdb_tasklet and doesn't
have an associated IRQ.

Anyhow, imx_mu_shutdown ignores this and tries to
free an IRQ that wasn't requested for Tx DB resulting
in the following warning:

[    1.967644] Trying to free already-free IRQ 26
[    1.972108] WARNING: CPU: 2 PID: 157 at kernel/irq/manage.c:1708 __free_irq+0xc0/0x358
[    1.980024] Modules linked in:
[    1.983088] CPU: 2 PID: 157 Comm: kworker/2:1 Tainted: G
[    1.993524] Hardware name: Freescale i.MX8QXP MEK (DT)
[    1.998668] Workqueue: events deferred_probe_work_func
[    2.003812] pstate: 60000085 (nZCv daIf -PAN -UAO)
[    2.008607] pc : __free_irq+0xc0/0x358
[    2.012364] lr : __free_irq+0xc0/0x358
[    2.016111] sp : ffff00001179b7e0
[    2.019422] x29: ffff00001179b7e0 x28: 0000000000000018
[    2.024736] x27: ffff000011233000 x26: 0000000000000004
[    2.030053] x25: 000000000000001a x24: ffff80083bec74d4
[    2.035369] x23: 0000000000000000 x22: ffff80083bec7588
[    2.040686] x21: ffff80083b1fe8d8 x20: ffff80083bec7400
[    2.046003] x19: 0000000000000000 x18: ffffffffffffffff
[    2.051320] x17: 0000000000000000 x16: 0000000000000000
[    2.056637] x15: ffff0000111296c8 x14: ffff00009179b517
[    2.061953] x13: ffff00001179b525 x12: ffff000011142000
[    2.067270] x11: ffff000011129f20 x10: ffff0000105da970
[    2.072587] x9 : 00000000ffffffd0 x8 : 0000000000000194
[    2.077903] x7 : 612065657266206f x6 : ffff0000111e7b09
[    2.083220] x5 : 0000000000000003 x4 : 0000000000000000
[    2.088537] x3 : 0000000000000000 x2 : 00000000ffffffff
[    2.093854] x1 : 28b70f0a2b60a500 x0 : 0000000000000000
[    2.099173] Call trace:
[    2.101618]  __free_irq+0xc0/0x358
[    2.105021]  free_irq+0x38/0x98
[    2.108170]  imx_mu_shutdown+0x90/0xb0
[    2.111921]  mbox_free_channel.part.2+0x24/0xb8
[    2.116453]  mbox_free_channel+0x18/0x28

This bug is present from the beginning of times.

Cc: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>