[PATCH 1/2] mtd: powernv_flash: Use WARN_ON_ONCE() rather than BUG_ON()

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH 1/2] mtd: powernv_flash: Use WARN_ON_ONCE() rather than BUG_ON()

Cyril Bur-2
BUG_ON() should be reserved in situations where we can not longer
guarantee the integrity of the system. In the case where
powernv_flash_async_op() receives an impossible op, we can still
guarantee the integrity of the system.

Signed-off-by: Cyril Bur <[hidden email]>
---
I think patches to powernv_flash have gone through MPE in the past -
is this still correct?

 drivers/mtd/devices/powernv_flash.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/devices/powernv_flash.c b/drivers/mtd/devices/powernv_flash.c
index f5396f26ddb4..a9a20c00687c 100644
--- a/drivers/mtd/devices/powernv_flash.c
+++ b/drivers/mtd/devices/powernv_flash.c
@@ -78,7 +78,8 @@ static int powernv_flash_async_op(struct mtd_info *mtd, enum flash_op op,
  rc = opal_flash_erase(info->id, offset, len, token);
  break;
  default:
- BUG_ON(1);
+ WARN_ON_ONCE(1);
+ return -EIO;
  }
 
  if (rc != OPAL_ASYNC_COMPLETION) {
--
2.13.0

Reply | Threaded
Open this post in threaded view
|

[PATCH 2/2] mtd: powernv_flash: Lock around concurrent access to OPAL

Cyril Bur-2
OPAL can only manage one flash access at a time and will return an
OPAL_BUSY error for each concurrent access to the flash. The simplest
way to prevent this from happening is with a mutex.

Signed-off-by: Cyril Bur <[hidden email]>
---
This is to address https://github.com/open-power/skiboot/issues/80


 drivers/mtd/devices/powernv_flash.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/devices/powernv_flash.c b/drivers/mtd/devices/powernv_flash.c
index a9a20c00687c..7b41af06f4fe 100644
--- a/drivers/mtd/devices/powernv_flash.c
+++ b/drivers/mtd/devices/powernv_flash.c
@@ -38,6 +38,7 @@
 
 struct powernv_flash {
  struct mtd_info mtd;
+ struct mutex lock;
  u32 id;
 };
 
@@ -59,12 +60,15 @@ static int powernv_flash_async_op(struct mtd_info *mtd, enum flash_op op,
  dev_dbg(dev, "%s(op=%d, offset=0x%llx, len=%zu)\n",
  __func__, op, offset, len);
 
+ mutex_lock(&info->lock);
+
  token = opal_async_get_token_interruptible();
  if (token < 0) {
  if (token != -ERESTARTSYS)
  dev_err(dev, "Failed to get an async token\n");
 
- return token;
+ rc = token;
+ goto out;
  }
 
  switch (op) {
@@ -79,18 +83,21 @@ static int powernv_flash_async_op(struct mtd_info *mtd, enum flash_op op,
  break;
  default:
  WARN_ON_ONCE(1);
- return -EIO;
+ rc = -EIO;
+ goto out;
  }
 
  if (rc != OPAL_ASYNC_COMPLETION) {
  dev_err(dev, "opal_flash_async_op(op=%d) failed (rc %d)\n",
  op, rc);
  opal_async_release_token(token);
- return -EIO;
+ rc = -EIO;
+ goto out;
  }
 
  rc = opal_async_wait_response(token, &msg);
  opal_async_release_token(token);
+ mutex_unlock(&info->lock);
  if (rc) {
  dev_err(dev, "opal async wait failed (rc %d)\n", rc);
  return -EIO;
@@ -106,6 +113,9 @@ static int powernv_flash_async_op(struct mtd_info *mtd, enum flash_op op,
  }
 
  return rc;
+out:
+ mutex_unlock(&info->lock);
+ return rc;
 }
 
 /**
@@ -237,6 +247,8 @@ static int powernv_flash_probe(struct platform_device *pdev)
  if (ret)
  goto out;
 
+ mutex_init(&data->lock);
+
  dev_set_drvdata(dev, data);
 
  /*
--
2.13.0

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/2] mtd: powernv_flash: Lock around concurrent access to OPAL

Stewart Smith
Cyril Bur <[hidden email]> writes:
> OPAL can only manage one flash access at a time and will return an
> OPAL_BUSY error for each concurrent access to the flash. The simplest
> way to prevent this from happening is with a mutex.
>
> Signed-off-by: Cyril Bur <[hidden email]>
> ---
> This is to address https://github.com/open-power/skiboot/issues/80

part of me wants to say "let's only take the lock if we ever get back
OPAL_BUSY" or something like that (have a DT property to say the flash
supports concurrent ops?)

Although the other part of me says "you're overthinking this, get back
to the work you're meant to be doing" :)

--
Stewart Smith
OPAL Architect, IBM.