aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/firmware/arm_scmi/mailbox.c
AgeCommit message (Collapse)Author
2024-03-26firmware: arm_scmi: Add message dump traces for bad and unexpected repliesCristian Marussi
It is useful to have message dump traces for any invalid/bad/unexpected replies. Let us add traces for the same as well as late-timed-out, out-of-order and unexpected/spurious messages. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240325204620.1437237-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-01-22firmware: arm_scmi: Check mailbox/SMT channel for consistencyCristian Marussi
On reception of a completion interrupt the shared memory area is accessed to retrieve the message header at first and then, if the message sequence number identifies a transaction which is still pending, the related payload is fetched too. When an SCMI command times out the channel ownership remains with the platform until eventually a late reply is received and, as a consequence, any further transmission attempt remains pending, waiting for the channel to be relinquished by the platform. Once that late reply is received the channel ownership is given back to the agent and any pending request is then allowed to proceed and overwrite the SMT area of the just delivered late reply; then the wait for the reply to the new request starts. It has been observed that the spurious IRQ related to the late reply can be wrongly associated with the freshly enqueued request: when that happens the SCMI stack in-flight lookup procedure is fooled by the fact that the message header now present in the SMT area is related to the new pending transaction, even though the real reply has still to arrive. This race-condition on the A2P channel can be detected by looking at the channel status bits: a genuine reply from the platform will have set the channel free bit before triggering the completion IRQ. Add a consistency check to validate such condition in the A2P ISR. Reported-by: Xinglong Yang <xinglong.yang@cixtech.com> Closes: https://lore.kernel.org/all/PUZPR06MB54981E6FA00D82BFDBB864FBF08DA@PUZPR06MB5498.apcprd06.prod.outlook.com/ Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Xinglong Yang <xinglong.yang@cixtech.com> Link: https://lore.kernel.org/r/20231220172112.763539-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-07-19firmware: arm_scmi: Drop OF node reference in the transport channel setupKrzysztof Kozlowski
The OF node reference obtained from of_parse_phandle() should be dropped if node is not compatible with arm,scmi-shmem. Fixes: 507cd4d2c5eb ("firmware: arm_scmi: Add compatibility checks for shmem node") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230719061652.8850-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-04-05firmware: arm_scmi: Add support for unidirectional mailbox channelsCristian Marussi
Extend the SCMI transport layer to support mailbox controllers that expose communication channels that are unidirectional by nature. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230404115026.2828149-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-03-08firmware: arm_scmi: Fix device node validation for mailbox transportCristian Marussi
When mailboxes are used as a transport it is possible to setup the SCMI transport layer, depending on the underlying channels configuration, to use one or two mailboxes, associated, respectively, to one or two, distinct, shared memory areas: any other combination should be treated as invalid. Add more strict checking of SCMI mailbox transport device node descriptors. Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Cc: <stable@vger.kernel.org> # 4.19 Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230307162324.891866-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-01-19firmware: arm_scmi: Use dedicated devices to initialize channelsCristian Marussi
Refactor channels initialization to use dedicated transport devices instead of using devices borrowed from the SCMI drivers. Initialize all channels, as described in the device tree, upfront during SCMI core stack probe phase and free all of them, including the underlying devices, when the SCMI core is removed. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-01-19firmware: arm_scmi: Simplify chan_available transport operationCristian Marussi
SCMI transport operation .chan_available determines in a transport specific way if an SCMI channel is still available and to be configured. Such information is derived by analyzing bits of device node in a transport specific way, all it needs is a device node to operate up on, not necessarily a full blown device. Simplify the helper to receive in input a reference to a device_node instead of a device carrying a pointer to such device_node. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-11-01firmware: arm_scmi: Make tx_prepare time out eventuallyCristian Marussi
SCMI transports based on shared memory, at start of transmissions, have to wait for the shared Tx channel area to be eventually freed by the SCMI platform before accessing the channel. In fact the channel is owned by the SCMI platform until marked as free by the platform itself and, as such, cannot be used by the agent until relinquished. As a consequence a badly misbehaving SCMI platform firmware could lock the channel indefinitely and make the kernel side SCMI stack loop forever waiting for such channel to be freed, possibly hanging the whole boot sequence. Add a timeout to the existent Tx waiting spin-loop so that, when the system ends up in this situation, the SCMI stack can at least bail-out, nosily warn the user, and abort the transmission. Reported-by: YaxiongTian <iambestgod@outlook.com> Suggested-by: YaxiongTian <iambestgod@outlook.com> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Etienne Carriere <etienne.carriere@linaro.org> Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221028140833.280091-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-12-21firmware: arm_scmi: Add new parameter to mark_txdoneCristian Marussi
Add a new xfer parameter to mark_txdone transport operation which enables the SCMI core to optionally pass back into the transport layer a reference to the xfer descriptor that is being handled. Link: https://lore.kernel.org/r/20211220195646.44498-9-cristian.marussi@arm.com Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add priv parameter to scmi_rx_callbackCristian Marussi
Add a new opaque void *priv parameter to scmi_rx_callback which can be optionally provided by the transport layer when invoking scmi_rx_callback and that will be passed back to the transport layer in xfer->priv. This can be used by transports that needs to keep track of their specific data structures together with the valid xfers. Link: https://lore.kernel.org/r/20210803131024.40280-15-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-06-08firmware: arm_scmi: Add compatibility checks for shmem nodeSudeep Holla
The shared memory node used for communication between the firmware and the OS should be compatible with "arm,scmi-shmem". Add the check for the same while parsing the node before fetching the memory regions. Link: https://lore.kernel.org/r/20210602073851.1005607-2-sudeep.holla@arm.com Cc: Rob Herring <robh+dt@kernel.org> Cc: Cristian Marussi <cristian.marussi@arm.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Jim Quinlan <jim2101024@gmail.com> Cc: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-09-09firmware: arm_scmi: Fix NULL pointer dereference in mailbox_chan_freeSudeep Holla
scmi_mailbox is obtained from cinfo->transport_info and the first call to mailbox_chan_free frees the channel and sets cinfo->transport_info to NULL. Care is taken to check for non NULL smbox->chan but smbox can itself be NULL. Fix it by checking for it without which, kernel crashes with below NULL pointer dereference and eventually kernel panic. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Modules linked in: scmi_module(-) Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 2 2020 pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--) pc : mailbox_chan_free+0x2c/0x70 [scmi_module] lr : idr_for_each+0x6c/0xf8 Call trace: mailbox_chan_free+0x2c/0x70 [scmi_module] idr_for_each+0x6c/0xf8 scmi_remove+0xa8/0xf0 [scmi_module] platform_drv_remove+0x34/0x58 device_release_driver_internal+0x118/0x1f0 driver_detach+0x58/0xe8 bus_remove_driver+0x64/0xe0 driver_unregister+0x38/0x68 platform_driver_unregister+0x1c/0x28 scmi_driver_exit+0x38/0x44 [scmi_module] ---[ end trace 17bde19f50436de9 ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs Kernel Offset: 0x1d0000 from 0xffff800010000000 PHYS_OFFSET: 0x80000000 CPU features: 0x0240022,25806004 Memory Limit: none ---[ end Kernel panic - not syncing: Fatal exception ]--- Link: https://lore.kernel.org/r/20200908112611.31515-1-sudeep.holla@arm.com Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Cc: Cristian Marussi <cristian.marussi@arm.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-09-07firmware: arm_scmi: Constify static scmi-opsRikard Falkeborn
These are never modified, so make them const to allow the compiler to put them in read-only memory. Link: https://lore.kernel.org/r/20200906230452.33410-4-rikard.falkeborn@gmail.com Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-20firmware: arm_scmi: Rename .clear_notification() transport_opsCristian Marussi
SCMI transport operation .clear_notification() is indeed a generic method to clear the channel in a transport dependent way, as such it could be a useful helper also in other contexts. Rename such method as .clear_channel(), renaming accordingly also its already existent call-sites. No functional change. Link: https://lore.kernel.org/r/20200420152315.21008-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14firmware: arm_scmi: Add notifications support in transport layerCristian Marussi
Add common transport-layer methods to: - fetch a notification instead of a response - clear a pending notification Add also all the needed support in mailbox/shmem transports. Link: https://lore.kernel.org/r/20200327143438.5382-4-cristian.marussi@arm.com Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-02-10firmware: arm_scmi: Make scmi core independent of the transport typeViresh Kumar
The SCMI specification is fairly independent of the transport protocol, which can be a simple mailbox (already implemented) or anything else. The current Linux implementation however is very much dependent on the mailbox transport layer. This patch makes the SCMI core code (driver.c) independent of the mailbox transport layer and moves all mailbox related code to a new file: mailbox.c and all struct shared_mem related code to a new file: shmem.c. We can now implement more transport protocols to transport SCMI messages. The transport protocols just need to provide struct scmi_transport_ops, with its version of the callbacks to enable exchange of SCMI messages. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/8698a3cec199b8feab35c2339f02dc232bfd773b.1580448239.git.viresh.kumar@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>