summaryrefslogtreecommitdiff
path: root/drivers/soc
diff options
context:
space:
mode:
authorConor Dooley <conor.dooley@microchip.com>2023-04-03 21:21:09 +0300
committerConor Dooley <conor.dooley@microchip.com>2023-04-03 21:27:06 +0300
commit5ee40e8d7630b9f3665c9cd990ac00e6e4bc7957 (patch)
tree8b9edf46333c8d25b00e5d08722db9a82848f301 /drivers/soc
parent49f965b6fbca63904d7397ce96066fa992f401a3 (diff)
parent8f943dd12eeff71857b9a1ca45adbaaba379bf30 (diff)
downloadlinux-5ee40e8d7630b9f3665c9cd990ac00e6e4bc7957.tar.xz
Merge patch series "mailbox,soc: mpfs: add support for fallible services"
Conor Dooley <conor@kernel.org> says: Here are some fixes for the system controller on PolarFire SoC that I ran into while implementing support for using the system controller to re-program the FPGA. A few are just minor bits that I fixed in passing, but the bulk of the patchset is changes to how the mailbox figures out if a "service" has completed. Prior to implementing this particular functionality, the services requested from the system controller, via its mailbox interface, always triggered an interrupt when the system controller was finished with the service. Unfortunately some of the services used to validate the FPGA images before programming them do not trigger an interrupt if they fail. For example, the service that checks whether an FPGA image is actually a newer version than what is already programmed, does not trigger an interrupt, unless the image is actually newer than the one currently programmed. If it has an earlier version, no interrupt is triggered and a status is set in the system controller's status register to signify the reason for the failure. In order to differentiate between the service succeeding & the system controller being inoperative or otherwise unable to function, I had to switch the controller to poll a busy bit in the system controller's registers to see if it has completed a service. This makes sense anyway, as the interrupt corresponds to "data ready" rather than "tx done", so I have changed the mailbox controller driver to do that & left the interrupt solely for signalling data ready. It just so happened that all of the services that I had worked with and tested up to this point were "infallible" & did not set a status, so the particular code paths were never tested. Link: https://lore.kernel.org/r/20230307202257.1762151-1-conor@kernel.org Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Diffstat (limited to 'drivers/soc')
-rw-r--r--drivers/soc/microchip/mpfs-sys-controller.c52
1 files changed, 36 insertions, 16 deletions
diff --git a/drivers/soc/microchip/mpfs-sys-controller.c b/drivers/soc/microchip/mpfs-sys-controller.c
index 6e20207b5756..ceaeebc1fc6b 100644
--- a/drivers/soc/microchip/mpfs-sys-controller.c
+++ b/drivers/soc/microchip/mpfs-sys-controller.c
@@ -11,12 +11,19 @@
#include <linux/slab.h>
#include <linux/kref.h>
#include <linux/module.h>
+#include <linux/jiffies.h>
#include <linux/interrupt.h>
#include <linux/of_platform.h>
#include <linux/mailbox_client.h>
#include <linux/platform_device.h>
#include <soc/microchip/mpfs.h>
+/*
+ * This timeout must be long, as some services (example: image authentication)
+ * take significant time to complete
+ */
+#define MPFS_SYS_CTRL_TIMEOUT_MS 30000
+
static DEFINE_MUTEX(transaction_lock);
struct mpfs_sys_controller {
@@ -28,28 +35,40 @@ struct mpfs_sys_controller {
int mpfs_blocking_transaction(struct mpfs_sys_controller *sys_controller, struct mpfs_mss_msg *msg)
{
- int ret, err;
+ unsigned long timeout = msecs_to_jiffies(MPFS_SYS_CTRL_TIMEOUT_MS);
+ int ret;
- err = mutex_lock_interruptible(&transaction_lock);
- if (err)
- return err;
+ ret = mutex_lock_interruptible(&transaction_lock);
+ if (ret)
+ return ret;
reinit_completion(&sys_controller->c);
ret = mbox_send_message(sys_controller->chan, msg);
- if (ret >= 0) {
- if (wait_for_completion_timeout(&sys_controller->c, HZ)) {
- ret = 0;
- } else {
- ret = -ETIMEDOUT;
- dev_warn(sys_controller->client.dev,
- "MPFS sys controller transaction timeout\n");
- }
+ if (ret < 0) {
+ dev_warn(sys_controller->client.dev, "MPFS sys controller service timeout\n");
+ goto out;
+ }
+
+ /*
+ * Unfortunately, the system controller will only deliver an interrupt
+ * if a service succeeds. mbox_send_message() will block until the busy
+ * flag is gone. If the busy flag is gone but no interrupt has arrived
+ * to trigger the rx callback then the service can be deemed to have
+ * failed.
+ * The caller can then interrogate msg::response::resp_status to
+ * determine the cause of the failure.
+ * mbox_send_message() returns positive integers in the success path, so
+ * ret needs to be cleared if we do get an interrupt.
+ */
+ if (!wait_for_completion_timeout(&sys_controller->c, timeout)) {
+ ret = -EBADMSG;
+ dev_warn(sys_controller->client.dev, "MPFS sys controller service failed\n");
} else {
- dev_err(sys_controller->client.dev,
- "mpfs sys controller transaction returned %d\n", ret);
+ ret = 0;
}
+out:
mutex_unlock(&transaction_lock);
return ret;
@@ -66,8 +85,8 @@ static void rx_callback(struct mbox_client *client, void *msg)
static void mpfs_sys_controller_delete(struct kref *kref)
{
- struct mpfs_sys_controller *sys_controller = container_of(kref, struct mpfs_sys_controller,
- consumers);
+ struct mpfs_sys_controller *sys_controller =
+ container_of(kref, struct mpfs_sys_controller, consumers);
mbox_free_channel(sys_controller->chan);
kfree(sys_controller);
@@ -104,6 +123,7 @@ static int mpfs_sys_controller_probe(struct platform_device *pdev)
sys_controller->client.dev = dev;
sys_controller->client.rx_callback = rx_callback;
sys_controller->client.tx_block = 1U;
+ sys_controller->client.tx_tout = msecs_to_jiffies(MPFS_SYS_CTRL_TIMEOUT_MS);
sys_controller->chan = mbox_request_channel(&sys_controller->client, 0);
if (IS_ERR(sys_controller->chan)) {