summaryrefslogtreecommitdiff
path: root/drivers/mailbox
AgeCommit message (Collapse)AuthorFilesLines
2025-12-07mailbox: pcc: don't zero error registerJamie Iles1-4/+4
[ Upstream commit ff0e4d4c97c94af34cc9cad37b5a5cdbe597a3b0 ] The error status mask for a type 3/4 subspace is used for reading the error status, and the bitwise inverse is used for clearing the error with the intent being to preserve any of the non-error bits. However, we were previously applying the mask to extract the status and then applying the inverse to the result which ended up clearing all bits. Instead, store the inverse mask in the preserve mask and then use that on the original value read from the error status so that only the error is cleared. Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)") Signed-off-by: Jamie Iles <jamie.iles@oss.qualcomm.com> Signed-off-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-12-07mailbox: pcc: Refactor error handling in irq handler into separate functionSudeep Holla1-10/+20
[ Upstream commit 3a675f50415b95f2ae10bfd932e2154ba1a08ee7 ] The existing error handling logic in pcc_mbox_irq() is intermixed with the main flow of the function. The command complete check and the complete complete update/acknowledgment are nicely factored into separate functions. Moves error detection and clearing logic into a separate function called: pcc_mbox_error_check_and_clear() by extracting error-handling logic from pcc_mbox_irq(). This ensures error checking and clearing are handled separately and it improves maintainability by keeping the IRQ handler focused on processing events. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Stable-dep-of: ff0e4d4c97c9 ("mailbox: pcc: don't zero error register") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-12-07mailbox: mailbox-test: Fix debugfs_create_dir error checkingHaotian Zhang1-1/+1
[ Upstream commit 3acf1028f5003731977f750a7070f3321a9cb740 ] The debugfs_create_dir() function returns ERR_PTR() on error, not NULL. The current null-check fails to catch errors. Use IS_ERR() to correctly check for errors. Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19mailbox: zynqmp-ipi: Remove dev.parent check in zynqmp_ipi_free_mboxesHarini T1-4/+2
[ Upstream commit 019e3f4550fc7d319a7fd03eff487255f8e8aecd ] The ipi_mbox->dev.parent check is unreliable proxy for registration status as it fails to protect against probe failures that occur after the parent is assigned but before device_register() completes. device_is_registered() is the canonical and robust method to verify the registration status. Remove ipi_mbox->dev.parent check in zynqmp_ipi_free_mboxes(). Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") Signed-off-by: Harini T <harini.t@amd.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19mailbox: zynqmp-ipi: Remove redundant mbox_controller_unregister() callHarini T1-1/+0
[ Upstream commit 341867f730d3d3bb54491ee64e8b1a0c446656e7 ] The controller is registered using the device-managed function 'devm_mbox_controller_register()'. As documented in mailbox.c, this ensures the devres framework automatically calls mbox_controller_unregister() when device_unregister() is invoked, making the explicit call unnecessary. Remove redundant mbox_controller_unregister() call as device_unregister() handles controller cleanup. Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") Signed-off-by: Harini T <harini.t@amd.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-07-06mailbox: Not protect module_put with spin_lock_irqsavePeng Fan1-1/+1
[ Upstream commit dddbd233e67e792bb0a3f9694a4707e6be29b2c6 ] &chan->lock is not supposed to protect 'chan->mbox'. And in __mbox_bind_client, try_module_get is also not protected by &chan->lock. So move module_put out of the lock protected region. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-04mailbox: use error ret code of of_parse_phandle_with_args()Tudor Ambarus1-3/+4
[ Upstream commit 24fdd5074b205cfb0ef4cd0751a2d03031455929 ] In case of error, of_parse_phandle_with_args() returns -EINVAL when the passed index is negative, or -ENOENT when the index is for an empty phandle. The mailbox core overwrote the error return code with a less precise -ENODEV. Use the error returned code from of_parse_phandle_with_args(). Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-04mailbox: pcc: Use acpi_os_ioremap() instead of ioremap()Sudeep Holla1-2/+6
[ Upstream commit d181acea5b864e91f38f5771b8961215ce5017ae ] The Platform Communication Channel (PCC) mailbox driver currently uses ioremap() to map channel shared memory regions. However it is preferred to use acpi_os_ioremap(), which is mapping function specific to EFI/ACPI defined memory regions. It ensures that the correct memory attributes are applied when mapping ACPI-provided regions. While at it, also add checks for handling any errors with the mapping. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02mailbox: pcc: Always clear the platform ack interrupt firstSudeep Holla1-3/+4
[ Upstream commit cf1338c0e02880cd235a4590eeb15e2039c873bc ] The PCC mailbox interrupt handler (pcc_mbox_irq()) currently checks for command completion flags and any error status before clearing the interrupt. The below sequence highlights an issue in the handling of PCC mailbox interrupts, specifically when dealing with doorbell notifications and acknowledgment between the OSPM and the platform where type3 and type4 channels are sharing the interrupt. ------------------------------------------------------------------------- | T | Platform Firmware | OSPM/Linux PCC driver | |---|---------------------------------|---------------------------------| | 1 | | Build message in shmem | | 2 | | Ring Type3 chan doorbell | | 3 | Receives the doorbell interrupt | | | 4 | Process the message from OSPM | | | 5 | Build response for the message | | | 6 | Ring Platform ACK interrupt on | | | | Type3 chan to OSPM | Received the interrupt | | 7 | Build Notification in Type4 Chan| | | 8 | | Start processing interrupt in | | | | pcc_mbox_irq() handler | | 9 | | Enter PCC handler for Type4 chan| |10 | | Check command complete cleared | |11 | | Read the notification | |12 | | Clear Platform ACK interrupt | | | No effect from the previous step yet as the Platform ACK | | | interrupt has not yet been triggered for this channel | |13 | Ring Platform ACK interrupt on | | | | Type4 chan to OSPM | | |14 | | Enter PCC handler for Type3 chan| |15 | | Command complete is set. | |16 | | Read the response. | |17 | | Clear Platform ACK interrupt | |18 | | Leave PCC handler for Type3 | |19 | | Leave pcc_mbox_irq() handler | |20 | | Re-enter pcc_mbox_irq() handler | |21 | | Enter PCC handler for Type4 chan| |22 | | Leave PCC handler for Type4 chan| |23 | | Enter PCC handler for Type3 chan| |24 | | Leave PCC handler for Type3 chan| |25 | | Leave pcc_mbox_irq() handler | ------------------------------------------------------------------------- The key issue occurs when OSPM tries to acknowledge platform ack interrupt for a notification which is ready to be read and processed but the interrupt itself is not yet triggered by the platform. This ineffective acknowledgment leads to an issue later in time where the interrupt remains pending as we exit the interrupt handler without clearing the platform ack interrupt as there is no pending response or notification. The interrupt acknowledgment order is incorrect. To resolve this issue, the platform acknowledgment interrupt should always be cleared before processing the interrupt for any notifications or response. Reported-by: Robbie King <robbiek@xsightlabs.com> Reviewed-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Tested-by: Robbie King <robbiek@xsightlabs.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02mailbox: pcc: Fix the possible race in updation of chan_in_use flagHuisong Li1-1/+7
[ Upstream commit 9779d45c749340ab461d595c1a4a664cb28f3007 ] The function mbox_chan_received_data() calls the Rx callback of the mailbox client driver. The callback might set chan_in_use flag from pcc_send_data(). This flag's status determines whether the PCC channel is in use. However, there is a potential race condition where chan_in_use is updated incorrectly due to concurrency between the interrupt handler (pcc_mbox_irq()) and the command sender(pcc_send_data()). The 'chan_in_use' flag of a channel is set to true after sending a command. And the flag of the new command may be cleared erroneous by the interrupt handler afer mbox_chan_received_data() returns, As a result, the interrupt being level triggered can't be cleared in pcc_mbox_irq() and it will be disabled after the number of handled times exceeds the specified value. The error log is as follows: | kunpeng_hccs HISI04B2:00: PCC command executed timeout! | kunpeng_hccs HISI04B2:00: get port link status info failed, ret = -110 | irq 13: nobody cared (try booting with the "irqpoll" option) | Call trace: | dump_backtrace+0x0/0x210 | show_stack+0x1c/0x2c | dump_stack+0xec/0x130 | __report_bad_irq+0x50/0x190 | note_interrupt+0x1e4/0x260 | handle_irq_event+0x144/0x17c | handle_fasteoi_irq+0xd0/0x240 | __handle_domain_irq+0x80/0xf0 | gic_handle_irq+0x74/0x2d0 | el1_irq+0xbc/0x140 | mnt_clone_write+0x0/0x70 | file_update_time+0xcc/0x160 | fault_dirty_shared_page+0xe8/0x150 | do_shared_fault+0x80/0x1d0 | do_fault+0x118/0x1a4 | handle_pte_fault+0x154/0x230 | __handle_mm_fault+0x1ac/0x390 | handle_mm_fault+0xf0/0x250 | do_page_fault+0x184/0x454 | do_translation_fault+0xac/0xd4 | do_mem_abort+0x44/0xb4 | el0_da+0x40/0x74 | el0_sync_handler+0x60/0xb4 | el0_sync+0x168/0x180 | handlers: | pcc_mbox_irq | Disabling IRQ #13 To solve this issue, pcc_mbox_irq() must clear 'chan_in_use' flag before the call to mbox_chan_received_data(). Tested-by: Adam Young <admiyo@os.amperecomputing.com> Tested-by: Robbie King <robbiek@xsightlabs.com> Signed-off-by: Huisong Li <lihuisong@huawei.com> (sudeep.holla: Minor updates to the subject, commit message and comment) Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-25mailbox: tegra-hsp: Define dimensioning masks in SoC dataKartik Rajput1-12/+60
commit bf0c9fb462038815f5f502653fb6dba06e6af415 upstream. Tegra264 has updated HSP_INT_DIMENSIONING register as follows: * nSI is now BIT17:BIT21. * nDB is now BIT12:BIT16. Currently, we are using a static macro HSP_nINT_MASK to get the values from HSP_INT_DIMENSIONING register. This results in wrong values for nSI for HSP instances that supports 16 shared interrupts. Define dimensioning masks in soc data and use them to parse nSI, nDB, nAS, nSS & nSM values. Fixes: 602dbbacc3ef ("mailbox: tegra: add support for Tegra264") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-17mailbox: tegra-hsp: Clear mailbox before using messagePekka Pessi1-2/+4
commit 0b7f8328f988178b55ee11d772a6e1238c04d29d upstream. The Tegra RCE (Camera) driver expects the mailbox to be empty before processing the IVC messages. On RT kernel, the threads processing the IVC messages (which are invoked after `mbox_chan_received_data()` is called) may be on a different CPU or running with a higher priority than the HSP interrupt handler thread. This can cause it to act on the message before the mailbox gets cleared in the HSP interrupt handler resulting in a loss of IVC notification. Fix this by clearing the mailbox data register before calling `mbox_chan_received_data()`. Fixes: 8f585d14030d ("mailbox: tegra-hsp: Add tegra_hsp_sm_ops") Fixes: 74c20dd0f892 ("mailbox: tegra-hsp: Add 128-bit shared mailbox support") Cc: stable@vger.kernel.org Signed-off-by: Pekka Pessi <ppessi@nvidia.com> Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-09mailbox: pcc: Check before sending MCTP PCC response ACKAdam Young1-8/+53
[ Upstream commit 7f9e19f207be0c534d517d65e01417ba968cdd34 ] Type 4 PCC channels have an option to send back a response to the platform when they are done processing the request. The flag to indicate whether or not to respond is inside the message body, and thus is not available to the pcc mailbox. If the flag is not set, still set command completion bit after processing message. In order to read the flag, this patch maps the shared buffer to virtual memory. To avoid duplication of mapping the shared buffer is then made available to be used by the driver that uses the mailbox. Signed-off-by: Adam Young <admiyo@os.amperecomputing.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-01-09mailbox: pcc: Support shared interrupt for multiple subspacesHuisong Li1-3/+40
[ Upstream commit 3db174e478cb0bb34888c20a531608b70aec9c1f ] If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Stable-dep-of: 7f9e19f207be ("mailbox: pcc: Check before sending MCTP PCC response ACK") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-01-09mailbox: pcc: Add support for platform notification handlingHuisong Li1-9/+41
[ Upstream commit 60c40b06fa68694dd08a1a0038ea8b9de3f3b1ca ] Currently, PCC driver doesn't support the processing of platform notification for type 4 PCC subspaces. According to ACPI specification, if platform sends a notification to OSPM, it must clear the command complete bit and trigger platform interrupt. OSPM needs to check whether the command complete bit is cleared, clear platform interrupt, process command, and then set the command complete and ring doorbell to the Platform. Let us stash the value of the pcc type and use the same while processing the interrupt of the channel. We also need to set the command complete bit and ring doorbell in the interrupt handler for the type 4 channel to complete the communication flow after processing the notification from the Platform. Signed-off-by: Huisong Li <lihuisong@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Stable-dep-of: 7f9e19f207be ("mailbox: pcc: Check before sending MCTP PCC response ACK") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09mailbox: mtk-cmdq: Move devm_mbox_controller_register() after ↵Jason-JH.Lin1-6/+6
devm_pm_runtime_enable() commit a8bd68e4329f9a0ad1b878733e0f80be6a971649 upstream. When mtk-cmdq unbinds, a WARN_ON message with condition pm_runtime_get_sync() < 0 occurs. According to the call tracei below: cmdq_mbox_shutdown mbox_free_channel mbox_controller_unregister __devm_mbox_controller_unregister ... The root cause can be deduced to be calling pm_runtime_get_sync() after calling pm_runtime_disable() as observed below: 1. CMDQ driver uses devm_mbox_controller_register() in cmdq_probe() to bind the cmdq device to the mbox_controller, so devm_mbox_controller_unregister() will automatically unregister the device bound to the mailbox controller when the device-managed resource is removed. That means devm_mbox_controller_unregister() and cmdq_mbox_shoutdown() will be called after cmdq_remove(). 2. CMDQ driver also uses devm_pm_runtime_enable() in cmdq_probe() after devm_mbox_controller_register(), so that devm_pm_runtime_disable() will be called after cmdq_remove(), but before devm_mbox_controller_unregister(). To fix this problem, cmdq_probe() needs to move devm_mbox_controller_register() after devm_pm_runtime_enable() to make devm_pm_runtime_disable() be called after devm_mbox_controller_unregister(). Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver") Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Bin Lan <bin.lan.cn@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-09mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()Dan Carpenter1-4/+4
[ Upstream commit 192a16a3430ca459c4e986f3d10758c4d6b1aa29 ] Both the inner and outer loops in this code use the "i" iterator. The inner loop should really use a different iterator. It doesn't affect things in practice because the data comes from the device tree. The "protocol" and "windows" variables are going to be zero. That means we're always going to hit the "return &chans[channel];" statement and we're not going to want to iterate through the outer loop again. Still it's worth fixing this for future use cases. Fixes: 5a6338cce9f4 ("mailbox: arm_mhuv2: Add driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-10mailbox: bcm2835: Fix timeout during suspend modeStefan Wahren1-1/+2
[ Upstream commit dc09f007caed3b2f6a3b6bd7e13777557ae22bfd ] During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs Link: https://github.com/raspberrypi/firmware/issues/1894 Fixes: 0bae6af6d704 ("mailbox: Enable BCM2835 mailbox support") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-10mailbox: rockchip: fix a typo in module autoloadingLiao Chen1-1/+1
[ Upstream commit e92d87c9c5d769e4cb1dd7c90faa38dddd7e52e3 ] MODULE_DEVICE_TABLE(of, rockchip_mbox_of_match) could let the module properly autoloaded based on the alias from of_device_id table. It should be 'rockchip_mbox_of_match' instead of 'rockchp_mbox_of_match', just fix it. Fixes: f70ed3b5dc8b ("mailbox: rockchip: Add Rockchip mailbox driver") Signed-off-by: Liao Chen <liaochen4@huawei.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05mailbox: arm_mhuv2: Fix a bug for mhuv2_sender_interruptXiaowu.ding1-1/+2
[ Upstream commit ee01c0b4384d19ecc5dfa7db3fd4303f965c3eba ] Message Handling Unit version is v2.1. When arm_mhuv2 working with the data protocol transfer mode. We have split one mhu into two channels, and every channel include four channel windows, the two channels share one gic spi interrupt. There is a problem with the sending scenario. The first channel will take up 0-3 channel windows, and the second channel take up 4-7 channel windows. When the first channel send the data, and the receiver will clear all the four channels status. Although we only enabled the interrupt on the last channel window with register CH_INT_EN,the register CHCOMB_INT_ST0 will be 0xf, not be 0x8. Currently we just clear the last channel windows int status with the data proctol mode.So after that,the CHCOMB_INT_ST0 status will be 0x7, not be the 0x0. Then the second channel send the data, the receiver read the data, clear all the four channel windows status, trigger the sender interrupt. But currently the CHCOMB_INT_ST0 register will be 0xf7, get_irq_chan_comb function will always return the first channel. So this patch clear all channel windows int status to avoid this interrupt confusion. Signed-off-by: Xiaowu.ding <xiaowu.ding@jaguarmicro.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-05mailbox: qcom-ipcc: fix incorrect num_chans countingJonathan Marek1-3/+1
Breaking out early when a match is found leads to an incorrect num_chans value when more than one ipcc mailbox channel is used by the same device. Fixes: e9d50e4b4d04 ("mailbox: qcom-ipcc: Dynamic alloc for channel arrangement") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-09-05mailbox: Explicitly include correct DT includesRob Herring16-10/+15
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-09-05mailbox: ti-msgmgr: Use devm_platform_ioremap_resource_byname()Li Zetao1-10/+6
Convert platform_get_resource_byname() + devm_ioremap_resource() to a single call to devm_platform_ioremap_resource_byname(), as this is exactly what this function does. Signed-off-by: Li Zetao <lizetao1@huawei.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-09-05mailbox: platform-mhu: Remove redundant dev_err()Ruan Jinjie1-3/+1
There is no need to call the dev_err() function directly to print a custom message when handling an error from platform_get_irq() function as it is going to display an appropriate error message in case of a failure. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-09-05mailbox: bcm-pdc: Fix some kernel-doc commentsYang Li1-3/+3
Fix some kernel-doc comments to silence the warnings: drivers/mailbox/bcm-pdc-mailbox.c:707: warning: Function parameter or member 'pdcs' not described in 'pdc_tx_list_sg_add' drivers/mailbox/bcm-pdc-mailbox.c:707: warning: Excess function parameter 'spu_idx' description in 'pdc_tx_list_sg_add' drivers/mailbox/bcm-pdc-mailbox.c:875: warning: Function parameter or member 'pdcs' not described in 'pdc_rx_list_sg_add' drivers/mailbox/bcm-pdc-mailbox.c:875: warning: Excess function parameter 'spu_idx' description in 'pdc_rx_list_sg_add' drivers/mailbox/bcm-pdc-mailbox.c:966: warning: Function parameter or member 't' not described in 'pdc_tasklet_cb' drivers/mailbox/bcm-pdc-mailbox.c:966: warning: Excess function parameter 'data' description in 'pdc_tasklet_cb' Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-09-05mailbox: mailbox-test: Fix an error check in mbox_test_probe()Minjie Du1-1/+1
mbox_test_request_channel() function returns NULL or error value embedded in the pointer (PTR_ERR). Evaluate the return value using IS_ERR_OR_NULL. Signed-off-by: Minjie Du <duminjie@vivo.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-09-05mailbox: tegra-hsp: Convert to devm_platform_ioremap_resource()Yangtao Li1-3/+1
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-09-05mailbox: rockchip: Use devm_platform_get_and_ioremap_resource()Yangtao Li1-5/+1
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-09-05mailbox: mailbox-test: Use devm_platform_get_and_ioremap_resource()Yangtao Li1-4/+2
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-09-05mailbox: bcm-pdc: Use devm_platform_get_and_ioremap_resource()Yangtao Li1-9/+3
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-09-05mailbox: bcm-ferxrm-mailbox: Use devm_platform_get_and_ioremap_resource()Yangtao Li1-7/+3
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-07-01mailbox: ti-msgmgr: Fill non-message tx data fields with 0x0Nishanth Menon1-3/+9
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>
2023-07-01mailbox: tegra: add support for Tegra264Stefan Kristiansson1-2/+14
Tegra264 has a slightly different doorbell register layout than previous chips. Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stefan Kristiansson <stefank@nvidia.com> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-05-31mailbox: mailbox-test: fix a locking issue in mbox_test_message_write()Dan Carpenter1-4/+6
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>
2023-05-07Merge tag 'mailbox-v6.4' of ↵Linus Torvalds9-99/+136
git://git.linaro.org/landing-teams/working/fujitsu/integration Pull mailbox updates from Jassi Brar: - mailbox api: allow direct registration to a channel and convert omap and pcc to use mbox_bind_client - omap and hi6220 : use of_property_read_bool - test: fix double-free and use spinlock header - rockchip and bcm-pdc: drop of_match_ptr - mpfs: change config symbol - mediatek gce: support MT6795 - qcom apcs: consolidate of_device_id and support IPQ9574 * tag 'mailbox-v6.4' of git://git.linaro.org/landing-teams/working/fujitsu/integration: dt-bindings: mailbox: qcom: add compatible for IPQ9574 SoC mailbox: qcom-apcs-ipc: do not grow the of_device_id dt-bindings: mailbox: qcom,apcs-kpss-global: use fallbacks for few variants dt-bindings: mailbox: mediatek,gce-mailbox: Add support for MT6795 mailbox: mpfs: convert SOC_MICROCHIP_POLARFIRE to ARCH_MICROCHIP_POLARFIRE mailbox: bcm-pdc: drop of_match_ptr for ID table mailbox: rockchip: drop of_match_ptr for ID table mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write() mailbox: mailbox-test: Explicitly include header for spinlock support mailbox: Use of_property_read_bool() for boolean properties mailbox: pcc: Use mbox_bind_client mailbox: omap: Use mbox_bind_client mailbox: Allow direct registration to a channel
2023-05-04mailbox: qcom-apcs-ipc: do not grow the of_device_idKrzysztof Kozlowski1-5/+6
Re-organize the compatible devices and add a comment to avoid unneeded of_device_id growth with every new SoC. These devices have quite a lot of similarities and they can use only one compatible fallback for driver binding. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-05-04mailbox: mpfs: convert SOC_MICROCHIP_POLARFIRE to ARCH_MICROCHIP_POLARFIREConor Dooley1-1/+1
As part of converting RISC-V SOC_FOO symbols to ARCH_FOO to match the use of such symbols on other architectures, convert the Microchip FPGA mailbox driver to use the new symbol. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-05-04mailbox: bcm-pdc: drop of_match_ptr for ID tableKrzysztof Kozlowski1-1/+1
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it might not be relevant here). drivers/mailbox/bcm-pdc-mailbox.c:1474:34: error: ‘pdc_mbox_of_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-05-04mailbox: rockchip: drop of_match_ptr for ID tableKrzysztof Kozlowski1-1/+1
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it might not be relevant here). drivers/mailbox/rockchip-mailbox.c:158:34: error: ‘rockchip_mbox_of_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-05-04mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write()Lee Jones1-0/+7
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>
2023-05-04mailbox: mailbox-test: Explicitly include header for spinlock supportLee Jones1-0/+1
Presently the support appears to be implied. Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-28Merge tag 'modules-6.4-rc1' of ↵Linus Torvalds2-2/+1
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux Pull module updates from Luis Chamberlain: "The summary of the changes for this pull requests is: - Song Liu's new struct module_memory replacement - Nick Alcock's MODULE_LICENSE() removal for non-modules - My cleanups and enhancements to reduce the areas where we vmalloc module memory for duplicates, and the respective debug code which proves the remaining vmalloc pressure comes from userspace. Most of the changes have been in linux-next for quite some time except the minor fixes I made to check if a module was already loaded prior to allocating the final module memory with vmalloc and the respective debug code it introduces to help clarify the issue. Although the functional change is small it is rather safe as it can only *help* reduce vmalloc space for duplicates and is confirmed to fix a bootup issue with over 400 CPUs with KASAN enabled. I don't expect stable kernels to pick up that fix as the cleanups would have also had to have been picked up. Folks on larger CPU systems with modules will want to just upgrade if vmalloc space has been an issue on bootup. Given the size of this request, here's some more elaborate details: The functional change change in this pull request is the very first patch from Song Liu which replaces the 'struct module_layout' with a new 'struct module_memory'. The old data structure tried to put together all types of supported module memory types in one data structure, the new one abstracts the differences in memory types in a module to allow each one to provide their own set of details. This paves the way in the future so we can deal with them in a cleaner way. If you look at changes they also provide a nice cleanup of how we handle these different memory areas in a module. This change has been in linux-next since before the merge window opened for v6.3 so to provide more than a full kernel cycle of testing. It's a good thing as quite a bit of fixes have been found for it. Jason Baron then made dynamic debug a first class citizen module user by using module notifier callbacks to allocate / remove module specific dynamic debug information. Nick Alcock has done quite a bit of work cross-tree to remove module license tags from things which cannot possibly be module at my request so to: a) help him with his longer term tooling goals which require a deterministic evaluation if a piece a symbol code could ever be part of a module or not. But quite recently it is has been made clear that tooling is not the only one that would benefit. Disambiguating symbols also helps efforts such as live patching, kprobes and BPF, but for other reasons and R&D on this area is active with no clear solution in sight. b) help us inch closer to the now generally accepted long term goal of automating all the MODULE_LICENSE() tags from SPDX license tags In so far as a) is concerned, although module license tags are a no-op for non-modules, tools which would want create a mapping of possible modules can only rely on the module license tag after the commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"). Nick has been working on this *for years* and AFAICT I was the only one to suggest two alternatives to this approach for tooling. The complexity in one of my suggested approaches lies in that we'd need a possible-obj-m and a could-be-module which would check if the object being built is part of any kconfig build which could ever lead to it being part of a module, and if so define a new define -DPOSSIBLE_MODULE [0]. A more obvious yet theoretical approach I've suggested would be to have a tristate in kconfig imply the same new -DPOSSIBLE_MODULE as well but that means getting kconfig symbol names mapping to modules always, and I don't think that's the case today. I am not aware of Nick or anyone exploring either of these options. Quite recently Josh Poimboeuf has pointed out that live patching, kprobes and BPF would benefit from resolving some part of the disambiguation as well but for other reasons. The function granularity KASLR (fgkaslr) patches were mentioned but Joe Lawrence has clarified this effort has been dropped with no clear solution in sight [1]. In the meantime removing module license tags from code which could never be modules is welcomed for both objectives mentioned above. Some developers have also welcomed these changes as it has helped clarify when a module was never possible and they forgot to clean this up, and so you'll see quite a bit of Nick's patches in other pull requests for this merge window. I just picked up the stragglers after rc3. LWN has good coverage on the motivation behind this work [2] and the typical cross-tree issues he ran into along the way. The only concrete blocker issue he ran into was that we should not remove the MODULE_LICENSE() tags from files which have no SPDX tags yet, even if they can never be modules. Nick ended up giving up on his efforts due to having to do this vetting and backlash he ran into from folks who really did *not understand* the core of the issue nor were providing any alternative / guidance. I've gone through his changes and dropped the patches which dropped the module license tags where an SPDX license tag was missing, it only consisted of 11 drivers. To see if a pull request deals with a file which lacks SPDX tags you can just use: ./scripts/spdxcheck.py -f \ $(git diff --name-only commid-id | xargs echo) You'll see a core module file in this pull request for the above, but that's not related to his changes. WE just need to add the SPDX license tag for the kernel/module/kmod.c file in the future but it demonstrates the effectiveness of the script. Most of Nick's changes were spread out through different trees, and I just picked up the slack after rc3 for the last kernel was out. Those changes have been in linux-next for over two weeks. The cleanups, debug code I added and final fix I added for modules were motivated by David Hildenbrand's report of boot failing on a systems with over 400 CPUs when KASAN was enabled due to running out of virtual memory space. Although the functional change only consists of 3 lines in the patch "module: avoid allocation if module is already present and ready", proving that this was the best we can do on the modules side took quite a bit of effort and new debug code. The initial cleanups I did on the modules side of things has been in linux-next since around rc3 of the last kernel, the actual final fix for and debug code however have only been in linux-next for about a week or so but I think it is worth getting that code in for this merge window as it does help fix / prove / evaluate the issues reported with larger number of CPUs. Userspace is not yet fixed as it is taking a bit of time for folks to understand the crux of the issue and find a proper resolution. Worst come to worst, I have a kludge-of-concept [3] of how to make kernel_read*() calls for modules unique / converge them, but I'm currently inclined to just see if userspace can fix this instead" Link: https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/ [0] Link: https://lkml.kernel.org/r/025f2151-ce7c-5630-9b90-98742c97ac65@redhat.com [1] Link: https://lwn.net/Articles/927569/ [2] Link: https://lkml.kernel.org/r/20230414052840.1994456-3-mcgrof@kernel.org [3] * tag 'modules-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux: (121 commits) module: add debugging auto-load duplicate module support module: stats: fix invalid_mod_bytes typo module: remove use of uninitialized variable len module: fix building stats for 32-bit targets module: stats: include uapi/linux/module.h module: avoid allocation if module is already present and ready module: add debug stats to help identify memory pressure module: extract patient module check into helper modules/kmod: replace implementation with a semaphore Change DEFINE_SEMAPHORE() to take a number argument module: fix kmemleak annotations for non init ELF sections module: Ignore L0 and rename is_arm_mapping_symbol() module: Move is_arm_mapping_symbol() to module_symbol.h module: Sync code of is_arm_mapping_symbol() scripts/gdb: use mem instead of core_layout to get the module address interconnect: remove module-related code interconnect: remove MODULE_LICENSE in non-modules zswap: remove MODULE_LICENSE in non-modules zpool: remove MODULE_LICENSE in non-modules x86/mm/dump_pagetables: remove MODULE_LICENSE in non-modules ...
2023-04-26Merge tag 'rproc-v6.4' of ↵Linus Torvalds1-4/+9
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull remoteproc updates from Bjorn Andersson: - Unnecessary type casts from the 'void *' rproc->priv pointer are dropped throughout the subsystem. - A kernel-doc error is corrected in the Mediatek SCPI IPI implementation - The firmware loading onto the IMX DSP remote processors is reworked to avoid non-32bit memory operations. A module parameter is introduced to assist development of firmware without communication abilities in place. Error paths in imx_dsp_rproc_mbox_alloc() is cleaned up - The cluster configuration handling in the TI K3 R5 driver is corrected and support for the single-R5 core found in the TI AM62x SoC family is introduced - The TI PRU driver device- to virtual-address translation is updated to avoid compiler warning about the unsigned device-address always being larger than 0 - The ST remoteproc driver is transitioned to use of_property_present() - Issues with kicks arriving after the STM32 remote processor has been shut down are mitigated by checking the processor's state before handling them. - Support for mailbox channels for communication with the remote processors are added to the Xilinx R5 remoteproc driver. The naming of carveouts are corrected and their parsing is reworked. For this a couple of fixes targeting the mailbox subsystem are picked up here as well. - Reference counting of of_nodes are corrected in the ST, STM32, RCAR and IMX remoteproc drivers * tag 'rproc-v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (24 commits) remoteproc: st: Use of_property_present() for testing DT property presence dt-bindings: remoteproc: Drop unneeded quotes remoteproc: imx_dsp_rproc: Fix kernel test robot sparse warning remoteproc: imx_dsp_rproc: Improve exception handling in imx_dsp_rproc_mbox_alloc() remoteproc: pru: Remove always true check positive unsigned value dt-bindings: remoteproc: stm32-rproc: Typo fix remoteproc: stm32_rproc: Add mutex protection for workqueue remoteproc: Remove unnecessary (void*) conversions remoteproc: imx_dsp_rproc: Call of_node_put() on iteration error remoteproc: imx_rproc: Call of_node_put() on iteration error remoteproc: rcar_rproc: Call of_node_put() on iteration error remoteproc: st: Call of_node_put() on iteration error remoteproc: stm32: Call of_node_put() on iteration error remoteproc: k3-r5: Use separate compatible string for TI AM62x SoC family dt-bindings: remoteproc: ti: Add new compatible for AM62 SoC family remoteproc: k3-r5: Simplify cluster mode setting usage remoteproc/mtk_scpi_ipi: Fix one kernel-doc comment remoteproc: xilinx: Add mailbox channels for rpmsg drivers: remoteproc: xilinx: Fix carveout names mailbox: zynqmp: Fix typo in IPI documentation ...
2023-04-18mailbox: Use of_property_read_bool() for boolean propertiesRob Herring2-6/+2
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-18mailbox: pcc: Use mbox_bind_clientElliot Berman1-39/+45
Use generic mbox_bind_client() to bind omap mailbox channel to a client. mbox_bind_client is identical to the replaced lines, except that it: - Does the operation under con_mutex which prevents possible races in removal path - Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows when tx is done. TXDONE_BY_ACK is already set if there's no interrupt, so this is not applicable. - Calls chan->mbox->ops->startup. This is usecase for requesting irq: move the devm_request_irq into the startup callback and unregister it in the shutdown path. Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-18mailbox: omap: Use mbox_bind_clientElliot Berman1-18/+4
Use generic mbox_bind_client() to bind omap mailbox channel to a client. mbox_bind_client is identical to the replaced lines, except that it: - Does the operation under con_mutex which prevents possible races in removal path - Sets TXDONE_BY_ACK if omap uses TXDONE_BY_POLL. omap uses TXDONE_BY_IRQ, so this check is not applicable. - Calls chan->mbox->ops->startup, if available. omap doesn't have, so this is not applicable. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-18mailbox: Allow direct registration to a channelElliot Berman1-28/+68
Support virtual mailbox controllers and clients which are not platform devices or come from the devicetree by allowing them to match client to channel via some other mechanism. Tested-by: Sudeep Holla <sudeep.holla@arm.com> (pcc) Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2023-04-13mailbox: zynq: make modularNick Alcock1-1/+1
This driver has a MODULE_LICENSE but is not tristate so cannot be built as a module, unlike all its peers: make it modular to match. Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Suggested-by: Michal Simek <michal.simek@xilinx.com> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: Jassi Brar <jassisinghbrar@gmail.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-04-13mailbox: rockchip: remove MODULE_LICENSE in non-modulesNick Alcock1-1/+0
Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Suggested-by: Luis Chamberlain <mcgrof@kernel.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: Jassi Brar <jassisinghbrar@gmail.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-04-03mailbox: mpfs: check the service status in .tx_done()Conor Dooley1-16/+16
Services are supposed to generate an interrupt once completed, whether or not they have do so successfully. What appears to be a bug in the system controller means that interrupts are only generated for *successful* services. Currently, the status of a service is only checked in the mpfs_mbox_rx_data() once an interrupt is received. As it turns out, this is not really helpful where the potentially buggy behaviour is present, as we'll only see the status for successes where it is moot anyway. Jassi suggested moving the check to the .tx_done() callback instead. This makes sense, as the busy bit that tx_done() is polling will be lowered on completion, regardless of whether the service passed or failed. That allows us to check the status bits for all services, whether they generate an interrupt or not & pass something more informative than -EBADMSG back to the drivers implementing individual services. Suggested-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: Jassi Brar <jaswinder.singh@linaro.org> Tested-by: Valentina Fernandez <valentina.fernandezalanis@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-21 03:57:35 +0300