All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] crypto: caam/jr - Convert to platform remove callback returning void
@ 2023-07-26  7:59 Uwe Kleine-König
  2023-07-26  8:02 ` Uwe Kleine-König
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Uwe Kleine-König @ 2023-07-26  7:59 UTC (permalink / raw)
  To: Horia Geantă,
	Pankaj Gupta, Gaurav Jain, Herbert Xu, David S. Miller
  Cc: linux-crypto, kernel

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

The driver adapted here suffers from this wrong assumption. Returning
-EBUSY if there are still users results in resource leaks and probably a
crash. Also further down passing the error code of caam_jr_shutdown() to
the caller only results in another error message and has no further
consequences compared to returning zero.

Still convert the driver to return no value in the remove callback. This
also allows to drop caam_jr_platform_shutdown() as the only function
called by it now has the same prototype.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,

note that the problems described above and in the extended comment isn't
introduced by this patch. It's as old as
313ea293e9c4d1eabcaddd2c0800f083b03c2a2e at least.

Also orthogonal to this patch I wonder about the use of a shutdown
callback. What makes this driver special to require extra handling at
shutdown time?

Best regards
Uwe

 drivers/crypto/caam/jr.c | 22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 96dea5304d22..66b1eb3eb4a4 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -162,7 +162,7 @@ static int caam_jr_shutdown(struct device *dev)
 	return ret;
 }
 
-static int caam_jr_remove(struct platform_device *pdev)
+static void caam_jr_remove(struct platform_device *pdev)
 {
 	int ret;
 	struct device *jrdev;
@@ -175,11 +175,14 @@ static int caam_jr_remove(struct platform_device *pdev)
 		caam_rng_exit(jrdev->parent);
 
 	/*
-	 * Return EBUSY if job ring already allocated.
+	 * If a job ring is still allocated there is trouble ahead. Once
+	 * caam_jr_remove() returned, jrpriv will be freed and the registers
+	 * will get unmapped. So any user of such a job ring will probably
+	 * crash.
 	 */
 	if (atomic_read(&jrpriv->tfm_count)) {
-		dev_err(jrdev, "Device is busy\n");
-		return -EBUSY;
+		dev_warn(jrdev, "Device is busy, fasten your seat belts, a crash is ahead.\n");
+		return;
 	}
 
 	/* Unregister JR-based RNG & crypto algorithms */
@@ -194,13 +197,6 @@ static int caam_jr_remove(struct platform_device *pdev)
 	ret = caam_jr_shutdown(jrdev);
 	if (ret)
 		dev_err(jrdev, "Failed to shut down job ring\n");
-
-	return ret;
-}
-
-static void caam_jr_platform_shutdown(struct platform_device *pdev)
-{
-	caam_jr_remove(pdev);
 }
 
 /* Main per-ring interrupt handler */
@@ -657,8 +653,8 @@ static struct platform_driver caam_jr_driver = {
 		.of_match_table = caam_jr_match,
 	},
 	.probe       = caam_jr_probe,
-	.remove      = caam_jr_remove,
-	.shutdown    = caam_jr_platform_shutdown,
+	.remove_new  = caam_jr_remove,
+	.shutdown    = caam_jr_remove,
 };
 
 static int __init jr_driver_init(void)

base-commit: dd105461ad15ea930d88aec1e4fcfc1f3186da43
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] crypto: caam/jr - Convert to platform remove callback returning void
  2023-07-26  7:59 [PATCH] crypto: caam/jr - Convert to platform remove callback returning void Uwe Kleine-König
@ 2023-07-26  8:02 ` Uwe Kleine-König
  2023-07-31  9:56 ` [EXT] " Gaurav Jain
  2023-08-01  5:01 ` Gaurav Jain
  2 siblings, 0 replies; 6+ messages in thread
From: Uwe Kleine-König @ 2023-07-26  8:02 UTC (permalink / raw)
  To: Horia Geantă,
	Pankaj Gupta, Gaurav Jain, Herbert Xu, David S. Miller
  Cc: linux-crypto, kernel

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

Hello,

On Wed, Jul 26, 2023 at 09:59:38AM +0200, Uwe Kleine-König wrote:
> -		dev_err(jrdev, "Device is busy\n");
> +		dev_warn(jrdev, "Device is busy, fasten your seat belts, a crash is ahead.\n");

I intended to make this higher-priority than dev_err. So this should be
a dev_alert instead of dev_warn. I'll wait a bit before resending to
allow feedback. If you intend to apply it before, please fix-up
accordingly.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [EXT] [PATCH] crypto: caam/jr - Convert to platform remove callback returning void
  2023-07-26  7:59 [PATCH] crypto: caam/jr - Convert to platform remove callback returning void Uwe Kleine-König
  2023-07-26  8:02 ` Uwe Kleine-König
@ 2023-07-31  9:56 ` Gaurav Jain
  2023-08-01  8:14   ` Uwe Kleine-König
  2023-08-01  5:01 ` Gaurav Jain
  2 siblings, 1 reply; 6+ messages in thread
From: Gaurav Jain @ 2023-07-31  9:56 UTC (permalink / raw)
  To: Uwe Kleine-König, Horia Geanta, Pankaj Gupta, Herbert Xu,
	David S. Miller
  Cc: linux-crypto, kernel

Hi

> -----Original Message-----
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Sent: Wednesday, July 26, 2023 1:30 PM
> To: Horia Geanta <horia.geanta@nxp.com>; Pankaj Gupta
> <pankaj.gupta@nxp.com>; Gaurav Jain <gaurav.jain@nxp.com>; Herbert Xu
> <herbert@gondor.apana.org.au>; David S. Miller <davem@davemloft.net>
> Cc: linux-crypto@vger.kernel.org; kernel@pengutronix.de
> Subject: [EXT] [PATCH] crypto: caam/jr - Convert to platform remove callback
> returning void
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
> 
> 
> The .remove() callback for a platform driver returns an int which makes many
> driver authors wrongly assume it's possible to do error handling by returning an
> error code. However the value returned is (mostly) ignored and this typically
> results in resource leaks. To improve here there is a quest to make the remove
> callback return void. In the first step of this quest all drivers are converted
> to .remove_new() which already returns void.
> 
> The driver adapted here suffers from this wrong assumption. Returning -EBUSY
> if there are still users results in resource leaks and probably a crash. Also further
> down passing the error code of caam_jr_shutdown() to the caller only results in
> another error message and has no further consequences compared to returning
> zero.
> 
> Still convert the driver to return no value in the remove callback. This also allows
> to drop caam_jr_platform_shutdown() as the only function called by it now has
> the same prototype.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
> 
> note that the problems described above and in the extended comment isn't
> introduced by this patch. It's as old as
> 313ea293e9c4d1eabcaddd2c0800f083b03c2a2e at least.
> 
> Also orthogonal to this patch I wonder about the use of a shutdown callback.
> What makes this driver special to require extra handling at shutdown time?
> 
> Best regards
> Uwe
> 
>  drivers/crypto/caam/jr.c | 22 +++++++++-------------
>  1 file changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c index
> 96dea5304d22..66b1eb3eb4a4 100644
> --- a/drivers/crypto/caam/jr.c
> +++ b/drivers/crypto/caam/jr.c
> @@ -162,7 +162,7 @@ static int caam_jr_shutdown(struct device *dev)
>         return ret;
>  }
> 
> -static int caam_jr_remove(struct platform_device *pdev)
> +static void caam_jr_remove(struct platform_device *pdev)
>  {
>         int ret;
>         struct device *jrdev;
> @@ -175,11 +175,14 @@ static int caam_jr_remove(struct platform_device
> *pdev)
>                 caam_rng_exit(jrdev->parent);
> 
>         /*
> -        * Return EBUSY if job ring already allocated.
> +        * If a job ring is still allocated there is trouble ahead. Once
> +        * caam_jr_remove() returned, jrpriv will be freed and the registers
> +        * will get unmapped. So any user of such a job ring will probably
> +        * crash.
>          */
>         if (atomic_read(&jrpriv->tfm_count)) {
> -               dev_err(jrdev, "Device is busy\n");
> -               return -EBUSY;
> +               dev_warn(jrdev, "Device is busy, fasten your seat belts, a crash is
> ahead.\n");
Changes are ok. Can you improve the error message or keep it same.

Regards
Gaurav
> +               return;
>         }
> 
>         /* Unregister JR-based RNG & crypto algorithms */ @@ -194,13 +197,6
> @@ static int caam_jr_remove(struct platform_device *pdev)
>         ret = caam_jr_shutdown(jrdev);
>         if (ret)
>                 dev_err(jrdev, "Failed to shut down job ring\n");
> -
> -       return ret;
> -}
> -
> -static void caam_jr_platform_shutdown(struct platform_device *pdev) -{
> -       caam_jr_remove(pdev);
>  }
> 
>  /* Main per-ring interrupt handler */
> @@ -657,8 +653,8 @@ static struct platform_driver caam_jr_driver = {
>                 .of_match_table = caam_jr_match,
>         },
>         .probe       = caam_jr_probe,
> -       .remove      = caam_jr_remove,
> -       .shutdown    = caam_jr_platform_shutdown,
> +       .remove_new  = caam_jr_remove,
> +       .shutdown    = caam_jr_remove,
>  };
> 
>  static int __init jr_driver_init(void)
> 
> base-commit: dd105461ad15ea930d88aec1e4fcfc1f3186da43
> --
> 2.39.2


^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [EXT] [PATCH] crypto: caam/jr - Convert to platform remove callback returning void
  2023-07-26  7:59 [PATCH] crypto: caam/jr - Convert to platform remove callback returning void Uwe Kleine-König
  2023-07-26  8:02 ` Uwe Kleine-König
  2023-07-31  9:56 ` [EXT] " Gaurav Jain
@ 2023-08-01  5:01 ` Gaurav Jain
  2 siblings, 0 replies; 6+ messages in thread
From: Gaurav Jain @ 2023-08-01  5:01 UTC (permalink / raw)
  To: Uwe Kleine-König, Horia Geanta, Pankaj Gupta, Herbert Xu,
	David S. Miller
  Cc: linux-crypto, kernel

Hi

> -----Original Message-----
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Sent: Wednesday, July 26, 2023 1:30 PM
> To: Horia Geanta <horia.geanta@nxp.com>; Pankaj Gupta
> <pankaj.gupta@nxp.com>; Gaurav Jain <gaurav.jain@nxp.com>; Herbert Xu
> <herbert@gondor.apana.org.au>; David S. Miller <davem@davemloft.net>
> Cc: linux-crypto@vger.kernel.org; kernel@pengutronix.de
> Subject: [EXT] [PATCH] crypto: caam/jr - Convert to platform remove callback
> returning void
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
> 
> 
> The .remove() callback for a platform driver returns an int which makes many
> driver authors wrongly assume it's possible to do error handling by returning an
> error code. However the value returned is (mostly) ignored and this typically
> results in resource leaks. To improve here there is a quest to make the remove
> callback return void. In the first step of this quest all drivers are converted
> to .remove_new() which already returns void.
> 
> The driver adapted here suffers from this wrong assumption. Returning -EBUSY
> if there are still users results in resource leaks and probably a crash. Also further
> down passing the error code of caam_jr_shutdown() to the caller only results in
> another error message and has no further consequences compared to returning
> zero.
> 
> Still convert the driver to return no value in the remove callback. This also allows
> to drop caam_jr_platform_shutdown() as the only function called by it now has
> the same prototype.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
> 
> note that the problems described above and in the extended comment isn't
> introduced by this patch. It's as old as
> 313ea293e9c4d1eabcaddd2c0800f083b03c2a2e at least.
> 
> Also orthogonal to this patch I wonder about the use of a shutdown callback.
> What makes this driver special to require extra handling at shutdown time?
This is introduced for kexec boot.
See this https://patchwork.kernel.org/project/linux-crypto/patch/20230316060734.818549-1-meenakshi.aggarwal@nxp.com/

Regards
Gaurav Jain
> 
> Best regards
> Uwe
> 
>  drivers/crypto/caam/jr.c | 22 +++++++++-------------
>  1 file changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c index
> 96dea5304d22..66b1eb3eb4a4 100644
> --- a/drivers/crypto/caam/jr.c
> +++ b/drivers/crypto/caam/jr.c
> @@ -162,7 +162,7 @@ static int caam_jr_shutdown(struct device *dev)
>         return ret;
>  }
> 
> -static int caam_jr_remove(struct platform_device *pdev)
> +static void caam_jr_remove(struct platform_device *pdev)
>  {
>         int ret;
>         struct device *jrdev;
> @@ -175,11 +175,14 @@ static int caam_jr_remove(struct platform_device
> *pdev)
>                 caam_rng_exit(jrdev->parent);
> 
>         /*
> -        * Return EBUSY if job ring already allocated.
> +        * If a job ring is still allocated there is trouble ahead. Once
> +        * caam_jr_remove() returned, jrpriv will be freed and the registers
> +        * will get unmapped. So any user of such a job ring will probably
> +        * crash.
>          */
>         if (atomic_read(&jrpriv->tfm_count)) {
> -               dev_err(jrdev, "Device is busy\n");
> -               return -EBUSY;
> +               dev_warn(jrdev, "Device is busy, fasten your seat belts, a crash is
> ahead.\n");
> +               return;
>         }
> 
>         /* Unregister JR-based RNG & crypto algorithms */ @@ -194,13 +197,6
> @@ static int caam_jr_remove(struct platform_device *pdev)
>         ret = caam_jr_shutdown(jrdev);
>         if (ret)
>                 dev_err(jrdev, "Failed to shut down job ring\n");
> -
> -       return ret;
> -}
> -
> -static void caam_jr_platform_shutdown(struct platform_device *pdev) -{
> -       caam_jr_remove(pdev);
>  }
> 
>  /* Main per-ring interrupt handler */
> @@ -657,8 +653,8 @@ static struct platform_driver caam_jr_driver = {
>                 .of_match_table = caam_jr_match,
>         },
>         .probe       = caam_jr_probe,
> -       .remove      = caam_jr_remove,
> -       .shutdown    = caam_jr_platform_shutdown,
> +       .remove_new  = caam_jr_remove,
> +       .shutdown    = caam_jr_remove,
>  };
> 
>  static int __init jr_driver_init(void)
> 
> base-commit: dd105461ad15ea930d88aec1e4fcfc1f3186da43
> --
> 2.39.2


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [EXT] [PATCH] crypto: caam/jr - Convert to platform remove callback returning void
  2023-07-31  9:56 ` [EXT] " Gaurav Jain
@ 2023-08-01  8:14   ` Uwe Kleine-König
  2023-08-01  8:31     ` Gaurav Jain
  0 siblings, 1 reply; 6+ messages in thread
From: Uwe Kleine-König @ 2023-08-01  8:14 UTC (permalink / raw)
  To: Gaurav Jain
  Cc: Horia Geanta, Pankaj Gupta, Herbert Xu, David S. Miller,
	linux-crypto, kernel

[-- Attachment #1: Type: text/plain, Size: 4212 bytes --]

Hello Gaurav,

On Mon, Jul 31, 2023 at 09:56:22AM +0000, Gaurav Jain wrote:
> > -----Original Message-----
> > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > Sent: Wednesday, July 26, 2023 1:30 PM
> > To: Horia Geanta <horia.geanta@nxp.com>; Pankaj Gupta
> > <pankaj.gupta@nxp.com>; Gaurav Jain <gaurav.jain@nxp.com>; Herbert Xu
> > <herbert@gondor.apana.org.au>; David S. Miller <davem@davemloft.net>
> > Cc: linux-crypto@vger.kernel.org; kernel@pengutronix.de
> > Subject: [EXT] [PATCH] crypto: caam/jr - Convert to platform remove callback
> > returning void
> > 
> > Caution: This is an external email. Please take care when clicking links or
> > opening attachments. When in doubt, report the message using the 'Report this
> > email' button
> > 
> > 
> > The .remove() callback for a platform driver returns an int which makes many
> > driver authors wrongly assume it's possible to do error handling by returning an
> > error code. However the value returned is (mostly) ignored and this typically
> > results in resource leaks. To improve here there is a quest to make the remove
> > callback return void. In the first step of this quest all drivers are converted
> > to .remove_new() which already returns void.
> > 
> > The driver adapted here suffers from this wrong assumption. Returning -EBUSY
> > if there are still users results in resource leaks and probably a crash. Also further
> > down passing the error code of caam_jr_shutdown() to the caller only results in
> > another error message and has no further consequences compared to returning
> > zero.
> > 
> > Still convert the driver to return no value in the remove callback. This also allows
> > to drop caam_jr_platform_shutdown() as the only function called by it now has
> > the same prototype.
> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > Hello,
> > 
> > note that the problems described above and in the extended comment isn't
> > introduced by this patch. It's as old as
> > 313ea293e9c4d1eabcaddd2c0800f083b03c2a2e at least.
> > 
> > Also orthogonal to this patch I wonder about the use of a shutdown callback.
> > What makes this driver special to require extra handling at shutdown time?
> > 
> > Best regards
> > Uwe
> > 
> >  drivers/crypto/caam/jr.c | 22 +++++++++-------------
> >  1 file changed, 9 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c index
> > 96dea5304d22..66b1eb3eb4a4 100644
> > --- a/drivers/crypto/caam/jr.c
> > +++ b/drivers/crypto/caam/jr.c
> > @@ -162,7 +162,7 @@ static int caam_jr_shutdown(struct device *dev)
> >         return ret;
> >  }
> > 
> > -static int caam_jr_remove(struct platform_device *pdev)
> > +static void caam_jr_remove(struct platform_device *pdev)
> >  {
> >         int ret;
> >         struct device *jrdev;
> > @@ -175,11 +175,14 @@ static int caam_jr_remove(struct platform_device
> > *pdev)
> >                 caam_rng_exit(jrdev->parent);
> > 
> >         /*
> > -        * Return EBUSY if job ring already allocated.
> > +        * If a job ring is still allocated there is trouble ahead. Once
> > +        * caam_jr_remove() returned, jrpriv will be freed and the registers
> > +        * will get unmapped. So any user of such a job ring will probably
> > +        * crash.
> >          */
> >         if (atomic_read(&jrpriv->tfm_count)) {
> > -               dev_err(jrdev, "Device is busy\n");
> > -               return -EBUSY;
> > +               dev_warn(jrdev, "Device is busy, fasten your seat belts, a crash is ahead.\n");
>
> Changes are ok. Can you improve the error message or keep it same.

What do you imagine here? "Device is busy" lacks urgency in my eyes and
is hard to rate by a log reader. Mentioning that something bad is about
to happen would be good. Do you want it expressed in a more serious way?
Something like:

	Device is busy; consumers might start to crash

?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [EXT] [PATCH] crypto: caam/jr - Convert to platform remove callback returning void
  2023-08-01  8:14   ` Uwe Kleine-König
@ 2023-08-01  8:31     ` Gaurav Jain
  0 siblings, 0 replies; 6+ messages in thread
From: Gaurav Jain @ 2023-08-01  8:31 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Horia Geanta, Pankaj Gupta, Herbert Xu, David S. Miller,
	linux-crypto, kernel

Hi Uwe

> -----Original Message-----
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Sent: Tuesday, August 1, 2023 1:44 PM
> To: Gaurav Jain <gaurav.jain@nxp.com>
> Cc: Horia Geanta <horia.geanta@nxp.com>; Pankaj Gupta
> <pankaj.gupta@nxp.com>; Herbert Xu <herbert@gondor.apana.org.au>; David
> S. Miller <davem@davemloft.net>; linux-crypto@vger.kernel.org;
> kernel@pengutronix.de
> Subject: Re: [EXT] [PATCH] crypto: caam/jr - Convert to platform remove
> callback returning void
> 
> Hello Gaurav,
> 
> On Mon, Jul 31, 2023 at 09:56:22AM +0000, Gaurav Jain wrote:
> > > -----Original Message-----
> > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > Sent: Wednesday, July 26, 2023 1:30 PM
> > > To: Horia Geanta <horia.geanta@nxp.com>; Pankaj Gupta
> > > <pankaj.gupta@nxp.com>; Gaurav Jain <gaurav.jain@nxp.com>; Herbert
> > > Xu <herbert@gondor.apana.org.au>; David S. Miller
> > > <davem@davemloft.net>
> > > Cc: linux-crypto@vger.kernel.org; kernel@pengutronix.de
> > > Subject: [EXT] [PATCH] crypto: caam/jr - Convert to platform remove
> > > callback returning void
> > >
> > > Caution: This is an external email. Please take care when clicking
> > > links or opening attachments. When in doubt, report the message
> > > using the 'Report this email' button
> > >
> > >
> > > The .remove() callback for a platform driver returns an int which
> > > makes many driver authors wrongly assume it's possible to do error
> > > handling by returning an error code. However the value returned is
> > > (mostly) ignored and this typically results in resource leaks. To
> > > improve here there is a quest to make the remove callback return
> > > void. In the first step of this quest all drivers are converted to .remove_new()
> which already returns void.
> > >
> > > The driver adapted here suffers from this wrong assumption.
> > > Returning -EBUSY if there are still users results in resource leaks
> > > and probably a crash. Also further down passing the error code of
> > > caam_jr_shutdown() to the caller only results in another error
> > > message and has no further consequences compared to returning zero.
> > >
> > > Still convert the driver to return no value in the remove callback.
> > > This also allows to drop caam_jr_platform_shutdown() as the only
> > > function called by it now has the same prototype.
> > >
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > ---
> > > Hello,
> > >
> > > note that the problems described above and in the extended comment
> > > isn't introduced by this patch. It's as old as
> > > 313ea293e9c4d1eabcaddd2c0800f083b03c2a2e at least.
> > >
> > > Also orthogonal to this patch I wonder about the use of a shutdown callback.
> > > What makes this driver special to require extra handling at shutdown time?
> > >
> > > Best regards
> > > Uwe
> > >
> > >  drivers/crypto/caam/jr.c | 22 +++++++++-------------
> > >  1 file changed, 9 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
> > > index
> > > 96dea5304d22..66b1eb3eb4a4 100644
> > > --- a/drivers/crypto/caam/jr.c
> > > +++ b/drivers/crypto/caam/jr.c
> > > @@ -162,7 +162,7 @@ static int caam_jr_shutdown(struct device *dev)
> > >         return ret;
> > >  }
> > >
> > > -static int caam_jr_remove(struct platform_device *pdev)
> > > +static void caam_jr_remove(struct platform_device *pdev)
> > >  {
> > >         int ret;
> > >         struct device *jrdev;
> > > @@ -175,11 +175,14 @@ static int caam_jr_remove(struct
> > > platform_device
> > > *pdev)
> > >                 caam_rng_exit(jrdev->parent);
> > >
> > >         /*
> > > -        * Return EBUSY if job ring already allocated.
> > > +        * If a job ring is still allocated there is trouble ahead. Once
> > > +        * caam_jr_remove() returned, jrpriv will be freed and the registers
> > > +        * will get unmapped. So any user of such a job ring will probably
> > > +        * crash.
> > >          */
> > >         if (atomic_read(&jrpriv->tfm_count)) {
> > > -               dev_err(jrdev, "Device is busy\n");
> > > -               return -EBUSY;
> > > +               dev_warn(jrdev, "Device is busy, fasten your seat
> > > + belts, a crash is ahead.\n");
> >
> > Changes are ok. Can you improve the error message or keep it same.
> 
> What do you imagine here? "Device is busy" lacks urgency in my eyes and is hard
> to rate by a log reader. Mentioning that something bad is about to happen
> would be good. 
Agreed.
Do you want it expressed in a more serious way?
> Something like:
> 
> 	Device is busy; consumers might start to crash
Yes, this is also fine. or
something like:
              Device is busy; System might crash.

Regards
Gaurav Jain

> 
> ?
> 
> Best regards
> Uwe
> 
> --
> Pengutronix e.K.                           | Uwe Kleine-König            |
> Industrial Linux Solutions                 | https://www.pengutronix.de/ |

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-08-01  8:32 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-26  7:59 [PATCH] crypto: caam/jr - Convert to platform remove callback returning void Uwe Kleine-König
2023-07-26  8:02 ` Uwe Kleine-König
2023-07-31  9:56 ` [EXT] " Gaurav Jain
2023-08-01  8:14   ` Uwe Kleine-König
2023-08-01  8:31     ` Gaurav Jain
2023-08-01  5:01 ` Gaurav Jain

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.