All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] iio: adc: meson_saradc: Better handle BL30 not releaseing the hardware
@ 2023-02-16 14:07 ` Uwe Kleine-König
  0 siblings, 0 replies; 6+ messages in thread
From: Uwe Kleine-König @ 2023-02-16 14:07 UTC (permalink / raw)
  To: Jonathan Cameron, Neil Armstrong, Kevin Hilman, Jerome Brunet,
	Martin Blumenstingl, Andy Shevchenko, Nuno Sá,
	linux-iio, linux-arm-kernel, linux-amlogic, kernel
  Cc: Lars-Peter Clausen

meson_sar_adc_lock() might return an error if BL30 doesn't release its
lock on the hardware. Just returning early from .remove() is wrong
however as this keeps the clocks and regulators on which is never
cleaned up later.

So only skip hardware accesses with an error message if
meson_sar_adc_lock() fails, but disable clocks and regulator and return
zero to suppress another error message by the driver core.

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

maybe someone with more hardware specific knowledge can improve the
procedure here. Maybe some HW access is fine even without the lock to
quiescent it, or maybe the lock can be dropped completely? Or the
ordering can be changed to reduce the number of if blocks.

Best regards
Uwe

 drivers/iio/adc/meson_saradc.c | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 85b6826cc10c..636fee27b6b2 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -957,29 +957,30 @@ static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev)
 	return ret;
 }
 
-static int meson_sar_adc_hw_disable(struct iio_dev *indio_dev)
+static void meson_sar_adc_hw_disable(struct iio_dev *indio_dev)
 {
 	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
 	int ret;
 
 	ret = meson_sar_adc_lock(indio_dev);
 	if (ret)
-		return ret;
+		dev_err(indio_dev->dev.parent, "Failed to lock ADC (%pE)\n", ERR_PTR(ret));
 
 	clk_disable_unprepare(priv->adc_clk);
 
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
-			   MESON_SAR_ADC_REG3_ADC_EN, 0);
+	if (!ret) {
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
+				   MESON_SAR_ADC_REG3_ADC_EN, 0);
 
-	meson_sar_adc_set_bandgap(indio_dev, false);
+		meson_sar_adc_set_bandgap(indio_dev, false);
+	}
 
 	clk_disable_unprepare(priv->core_clk);
 
 	regulator_disable(priv->vref);
 
-	meson_sar_adc_unlock(indio_dev);
-
-	return 0;
+	if (!ret)
+		meson_sar_adc_unlock(indio_dev);
 }
 
 static irqreturn_t meson_sar_adc_irq(int irq, void *data)
@@ -1283,7 +1284,9 @@ static int meson_sar_adc_remove(struct platform_device *pdev)
 
 	iio_device_unregister(indio_dev);
 
-	return meson_sar_adc_hw_disable(indio_dev);
+	meson_sar_adc_hw_disable(indio_dev);
+
+	return 0;
 }
 
 static int meson_sar_adc_suspend(struct device *dev)

base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
-- 
2.39.1


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

* [PATCH] iio: adc: meson_saradc: Better handle BL30 not releaseing the hardware
@ 2023-02-16 14:07 ` Uwe Kleine-König
  0 siblings, 0 replies; 6+ messages in thread
From: Uwe Kleine-König @ 2023-02-16 14:07 UTC (permalink / raw)
  To: Jonathan Cameron, Neil Armstrong, Kevin Hilman, Jerome Brunet,
	Martin Blumenstingl, Andy Shevchenko, Nuno Sá,
	linux-iio, linux-arm-kernel, linux-amlogic, kernel
  Cc: Lars-Peter Clausen

meson_sar_adc_lock() might return an error if BL30 doesn't release its
lock on the hardware. Just returning early from .remove() is wrong
however as this keeps the clocks and regulators on which is never
cleaned up later.

So only skip hardware accesses with an error message if
meson_sar_adc_lock() fails, but disable clocks and regulator and return
zero to suppress another error message by the driver core.

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

maybe someone with more hardware specific knowledge can improve the
procedure here. Maybe some HW access is fine even without the lock to
quiescent it, or maybe the lock can be dropped completely? Or the
ordering can be changed to reduce the number of if blocks.

Best regards
Uwe

 drivers/iio/adc/meson_saradc.c | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 85b6826cc10c..636fee27b6b2 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -957,29 +957,30 @@ static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev)
 	return ret;
 }
 
-static int meson_sar_adc_hw_disable(struct iio_dev *indio_dev)
+static void meson_sar_adc_hw_disable(struct iio_dev *indio_dev)
 {
 	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
 	int ret;
 
 	ret = meson_sar_adc_lock(indio_dev);
 	if (ret)
-		return ret;
+		dev_err(indio_dev->dev.parent, "Failed to lock ADC (%pE)\n", ERR_PTR(ret));
 
 	clk_disable_unprepare(priv->adc_clk);
 
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
-			   MESON_SAR_ADC_REG3_ADC_EN, 0);
+	if (!ret) {
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
+				   MESON_SAR_ADC_REG3_ADC_EN, 0);
 
-	meson_sar_adc_set_bandgap(indio_dev, false);
+		meson_sar_adc_set_bandgap(indio_dev, false);
+	}
 
 	clk_disable_unprepare(priv->core_clk);
 
 	regulator_disable(priv->vref);
 
-	meson_sar_adc_unlock(indio_dev);
-
-	return 0;
+	if (!ret)
+		meson_sar_adc_unlock(indio_dev);
 }
 
 static irqreturn_t meson_sar_adc_irq(int irq, void *data)
@@ -1283,7 +1284,9 @@ static int meson_sar_adc_remove(struct platform_device *pdev)
 
 	iio_device_unregister(indio_dev);
 
-	return meson_sar_adc_hw_disable(indio_dev);
+	meson_sar_adc_hw_disable(indio_dev);
+
+	return 0;
 }
 
 static int meson_sar_adc_suspend(struct device *dev)

base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
-- 
2.39.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH] iio: adc: meson_saradc: Better handle BL30 not releaseing the hardware
@ 2023-02-16 14:07 ` Uwe Kleine-König
  0 siblings, 0 replies; 6+ messages in thread
From: Uwe Kleine-König @ 2023-02-16 14:07 UTC (permalink / raw)
  To: Jonathan Cameron, Neil Armstrong, Kevin Hilman, Jerome Brunet,
	Martin Blumenstingl, Andy Shevchenko, Nuno Sá,
	linux-iio, linux-arm-kernel, linux-amlogic, kernel
  Cc: Lars-Peter Clausen

meson_sar_adc_lock() might return an error if BL30 doesn't release its
lock on the hardware. Just returning early from .remove() is wrong
however as this keeps the clocks and regulators on which is never
cleaned up later.

So only skip hardware accesses with an error message if
meson_sar_adc_lock() fails, but disable clocks and regulator and return
zero to suppress another error message by the driver core.

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

maybe someone with more hardware specific knowledge can improve the
procedure here. Maybe some HW access is fine even without the lock to
quiescent it, or maybe the lock can be dropped completely? Or the
ordering can be changed to reduce the number of if blocks.

Best regards
Uwe

 drivers/iio/adc/meson_saradc.c | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 85b6826cc10c..636fee27b6b2 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -957,29 +957,30 @@ static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev)
 	return ret;
 }
 
-static int meson_sar_adc_hw_disable(struct iio_dev *indio_dev)
+static void meson_sar_adc_hw_disable(struct iio_dev *indio_dev)
 {
 	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
 	int ret;
 
 	ret = meson_sar_adc_lock(indio_dev);
 	if (ret)
-		return ret;
+		dev_err(indio_dev->dev.parent, "Failed to lock ADC (%pE)\n", ERR_PTR(ret));
 
 	clk_disable_unprepare(priv->adc_clk);
 
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
-			   MESON_SAR_ADC_REG3_ADC_EN, 0);
+	if (!ret) {
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
+				   MESON_SAR_ADC_REG3_ADC_EN, 0);
 
-	meson_sar_adc_set_bandgap(indio_dev, false);
+		meson_sar_adc_set_bandgap(indio_dev, false);
+	}
 
 	clk_disable_unprepare(priv->core_clk);
 
 	regulator_disable(priv->vref);
 
-	meson_sar_adc_unlock(indio_dev);
-
-	return 0;
+	if (!ret)
+		meson_sar_adc_unlock(indio_dev);
 }
 
 static irqreturn_t meson_sar_adc_irq(int irq, void *data)
@@ -1283,7 +1284,9 @@ static int meson_sar_adc_remove(struct platform_device *pdev)
 
 	iio_device_unregister(indio_dev);
 
-	return meson_sar_adc_hw_disable(indio_dev);
+	meson_sar_adc_hw_disable(indio_dev);
+
+	return 0;
 }
 
 static int meson_sar_adc_suspend(struct device *dev)

base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
-- 
2.39.1


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

* Re: [PATCH] iio: adc: meson_saradc: Better handle BL30 not releaseing the hardware
  2023-02-16 14:07 ` Uwe Kleine-König
  (?)
@ 2023-02-18 15:50   ` Martin Blumenstingl
  -1 siblings, 0 replies; 6+ messages in thread
From: Martin Blumenstingl @ 2023-02-18 15:50 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Jonathan Cameron, Neil Armstrong, Kevin Hilman, Jerome Brunet,
	Andy Shevchenko, Nuno Sá,
	linux-iio, linux-arm-kernel, linux-amlogic, kernel,
	Lars-Peter Clausen

Hi Uwe,

On Thu, Feb 16, 2023 at 3:07 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> meson_sar_adc_lock() might return an error if BL30 doesn't release its
> lock on the hardware. Just returning early from .remove() is wrong
> however as this keeps the clocks and regulators on which is never
> cleaned up later.
>
> So only skip hardware accesses with an error message if
> meson_sar_adc_lock() fails, but disable clocks and regulator and return
> zero to suppress another error message by the driver core.
The clocks and regulators are shared with the BL30 firmware.
In practice I have not seen meson_sar_adc_lock() fail yet.

I think it's enough to print an error message if locking fails, then
continue as if nothing happened. Unlocking obviously has to be skipped
as well in this case.
There's not much we can do to recover from this and I consider the
BL30 firmware to be hanging (or broken) if it doesn't release the
lock.


Best regards,
Martin

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

* Re: [PATCH] iio: adc: meson_saradc: Better handle BL30 not releaseing the hardware
@ 2023-02-18 15:50   ` Martin Blumenstingl
  0 siblings, 0 replies; 6+ messages in thread
From: Martin Blumenstingl @ 2023-02-18 15:50 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Jonathan Cameron, Neil Armstrong, Kevin Hilman, Jerome Brunet,
	Andy Shevchenko, Nuno Sá,
	linux-iio, linux-arm-kernel, linux-amlogic, kernel,
	Lars-Peter Clausen

Hi Uwe,

On Thu, Feb 16, 2023 at 3:07 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> meson_sar_adc_lock() might return an error if BL30 doesn't release its
> lock on the hardware. Just returning early from .remove() is wrong
> however as this keeps the clocks and regulators on which is never
> cleaned up later.
>
> So only skip hardware accesses with an error message if
> meson_sar_adc_lock() fails, but disable clocks and regulator and return
> zero to suppress another error message by the driver core.
The clocks and regulators are shared with the BL30 firmware.
In practice I have not seen meson_sar_adc_lock() fail yet.

I think it's enough to print an error message if locking fails, then
continue as if nothing happened. Unlocking obviously has to be skipped
as well in this case.
There's not much we can do to recover from this and I consider the
BL30 firmware to be hanging (or broken) if it doesn't release the
lock.


Best regards,
Martin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH] iio: adc: meson_saradc: Better handle BL30 not releaseing the hardware
@ 2023-02-18 15:50   ` Martin Blumenstingl
  0 siblings, 0 replies; 6+ messages in thread
From: Martin Blumenstingl @ 2023-02-18 15:50 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Jonathan Cameron, Neil Armstrong, Kevin Hilman, Jerome Brunet,
	Andy Shevchenko, Nuno Sá,
	linux-iio, linux-arm-kernel, linux-amlogic, kernel,
	Lars-Peter Clausen

Hi Uwe,

On Thu, Feb 16, 2023 at 3:07 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> meson_sar_adc_lock() might return an error if BL30 doesn't release its
> lock on the hardware. Just returning early from .remove() is wrong
> however as this keeps the clocks and regulators on which is never
> cleaned up later.
>
> So only skip hardware accesses with an error message if
> meson_sar_adc_lock() fails, but disable clocks and regulator and return
> zero to suppress another error message by the driver core.
The clocks and regulators are shared with the BL30 firmware.
In practice I have not seen meson_sar_adc_lock() fail yet.

I think it's enough to print an error message if locking fails, then
continue as if nothing happened. Unlocking obviously has to be skipped
as well in this case.
There's not much we can do to recover from this and I consider the
BL30 firmware to be hanging (or broken) if it doesn't release the
lock.


Best regards,
Martin

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

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

end of thread, other threads:[~2023-02-18 15:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-16 14:07 [PATCH] iio: adc: meson_saradc: Better handle BL30 not releaseing the hardware Uwe Kleine-König
2023-02-16 14:07 ` Uwe Kleine-König
2023-02-16 14:07 ` Uwe Kleine-König
2023-02-18 15:50 ` Martin Blumenstingl
2023-02-18 15:50   ` Martin Blumenstingl
2023-02-18 15:50   ` Martin Blumenstingl

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.