From: Eddie James <eajames@linux.ibm.com>
To: linux-aspeed@lists.ozlabs.org
Cc: joel@jms.id.au, andrew@codeconstruct.com.au,
devicetree@vger.kernel.org, linux-fsi@lists.ozlabs.org,
robh@kernel.org, conor+dt@kernel.org, krzk+dt@kernel.org,
jk@ozlabs.org, alistair@popple.id.au, eajames@linux.ibm.com,
lakshmiy@us.ibm.com
Subject: [PATCH v3 2/3] fsi: sbefifo: Prevent async FFDC collection for Odyssey SBEFIFOs
Date: Fri, 19 Apr 2024 16:11:42 -0500 [thread overview]
Message-ID: <20240419211143.1039868-3-eajames@linux.ibm.com> (raw)
In-Reply-To: <20240419211143.1039868-1-eajames@linux.ibm.com>
A new type of SBE, found on the Odyssey chip, will return any async FFDC in
the next transaction, so collecting the FFDC is unnecessary and results in
unexpected behavior. This difference in behavior between the Odyssey SBE
and the POWER9/10 SBEs wasn't apparent when support for the Odyssey was
added. To fix the unexpected behavior, turn off the async collection fot
Odyssey SBEFIFOs.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
---
Changes since v2:
- Update commit message
Changes since v1:
- Change "ody" to "odyssey"
drivers/fsi/fsi-sbefifo.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/fsi/fsi-sbefifo.c b/drivers/fsi/fsi-sbefifo.c
index 0385476bfb03..b8add20e05ec 100644
--- a/drivers/fsi/fsi-sbefifo.c
+++ b/drivers/fsi/fsi-sbefifo.c
@@ -125,6 +125,7 @@ struct sbefifo {
struct mutex lock;
bool broken;
bool dead;
+ bool need_async;
bool async_ffdc;
bool timed_out;
u32 timeout_in_cmd_ms;
@@ -141,6 +142,10 @@ struct sbefifo_user {
u32 read_timeout_ms;
};
+struct sbefifo_data {
+ bool need_async;
+};
+
static DEFINE_MUTEX(sbefifo_ffdc_mutex);
static ssize_t timeout_show(struct device *dev, struct device_attribute *attr,
@@ -317,6 +322,10 @@ static int sbefifo_check_sbe_state(struct sbefifo *sbefifo)
return -ESHUTDOWN;
}
+ /* Newer SBEFIFOs don't need async FFDC collection */
+ if (!sbefifo->need_async)
+ return 0;
+
/* Is there async FFDC available ? Remember it */
if (sbm & CFAM_SBM_SBE_ASYNC_FFDC)
sbefifo->async_ffdc = true;
@@ -1031,6 +1040,7 @@ static void sbefifo_free(struct device *dev)
static int sbefifo_probe(struct device *dev)
{
+ const struct sbefifo_data *md = of_device_get_match_data(dev);
struct fsi_device *fsi_dev = to_fsi_dev(dev);
struct sbefifo *sbefifo;
struct device_node *np;
@@ -1044,6 +1054,11 @@ static int sbefifo_probe(struct device *dev)
if (!sbefifo)
return -ENOMEM;
+ if (md)
+ sbefifo->need_async = md->need_async;
+ else
+ sbefifo->need_async = true;
+
/* Grab a reference to the device (parent of our cdev), we'll drop it later */
if (!get_device(dev)) {
kfree(sbefifo);
@@ -1128,6 +1143,27 @@ static int sbefifo_remove(struct device *dev)
return 0;
}
+static const struct sbefifo_data p9_sbefifo_data = {
+ .need_async = true,
+};
+
+static const struct sbefifo_data odyssey_sbefifo_data = {
+ .need_async = false,
+};
+
+static const struct of_device_id sbefifo_of_ids[] = {
+ {
+ .compatible = "ibm,p9-sbefifo",
+ .data = &p9_sbefifo_data,
+ },
+ {
+ .compatible = "ibm,odyssey-sbefifo",
+ .data = &odyssey_sbefifo_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sbefifo_of_ids);
+
static const struct fsi_device_id sbefifo_ids[] = {
{
.engine_type = FSI_ENGID_SBE,
@@ -1141,6 +1177,7 @@ static struct fsi_driver sbefifo_drv = {
.drv = {
.name = DEVICE_NAME,
.bus = &fsi_bus_type,
+ .of_match_table = sbefifo_of_ids,
.probe = sbefifo_probe,
.remove = sbefifo_remove,
}
--
2.39.3
next prev parent reply other threads:[~2024-04-19 21:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 21:11 [PATCH v3 0/3] fsi: sbefifo: Prevent async FFDC collection for Odyssey SBEFIFOs Eddie James
2024-04-19 21:11 ` [PATCH v3 1/3] dt-bindings: fsi: Document the IBM SBEFIFO engine Eddie James
2024-04-20 10:54 ` Conor Dooley
2024-04-21 23:02 ` Andrew Jeffery
2024-04-25 21:38 ` Eddie James
2024-04-26 0:05 ` Andrew Jeffery
2024-04-19 21:11 ` Eddie James [this message]
2024-04-19 21:11 ` [PATCH v3 3/3] ARM: dts: aspeed: Update Odyssey SBEFIFO compatible strings Eddie James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240419211143.1039868-3-eajames@linux.ibm.com \
--to=eajames@linux.ibm.com \
--cc=alistair@popple.id.au \
--cc=andrew@codeconstruct.com.au \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jk@ozlabs.org \
--cc=joel@jms.id.au \
--cc=krzk+dt@kernel.org \
--cc=lakshmiy@us.ibm.com \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-fsi@lists.ozlabs.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.