All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, kernel@pengutronix.de,
	"Lars-Peter Clausen" <lars@metafoo.de>
Subject: Re: [PATCH] iio: adc: meson_saradc: Better handle BL30 not releaseing the hardware
Date: Sat, 18 Feb 2023 16:50:33 +0100	[thread overview]
Message-ID: <CAFBinCC4zdu+rLk3oGOOyT5mcgoU2qmeF=vjHoarJ9vq1GO59w@mail.gmail.com> (raw)
In-Reply-To: <20230216140725.1181867-1-u.kleine-koenig@pengutronix.de>

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

WARNING: multiple messages have this Message-ID (diff)
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, kernel@pengutronix.de,
	"Lars-Peter Clausen" <lars@metafoo.de>
Subject: Re: [PATCH] iio: adc: meson_saradc: Better handle BL30 not releaseing the hardware
Date: Sat, 18 Feb 2023 16:50:33 +0100	[thread overview]
Message-ID: <CAFBinCC4zdu+rLk3oGOOyT5mcgoU2qmeF=vjHoarJ9vq1GO59w@mail.gmail.com> (raw)
In-Reply-To: <20230216140725.1181867-1-u.kleine-koenig@pengutronix.de>

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

WARNING: multiple messages have this Message-ID (diff)
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, kernel@pengutronix.de,
	"Lars-Peter Clausen" <lars@metafoo.de>
Subject: Re: [PATCH] iio: adc: meson_saradc: Better handle BL30 not releaseing the hardware
Date: Sat, 18 Feb 2023 16:50:33 +0100	[thread overview]
Message-ID: <CAFBinCC4zdu+rLk3oGOOyT5mcgoU2qmeF=vjHoarJ9vq1GO59w@mail.gmail.com> (raw)
In-Reply-To: <20230216140725.1181867-1-u.kleine-koenig@pengutronix.de>

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

  reply	other threads:[~2023-02-18 15:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2023-02-18 15:50   ` Martin Blumenstingl
2023-02-18 15:50   ` Martin Blumenstingl

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='CAFBinCC4zdu+rLk3oGOOyT5mcgoU2qmeF=vjHoarJ9vq1GO59w@mail.gmail.com' \
    --to=martin.blumenstingl@googlemail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jbrunet@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=khilman@baylibre.com \
    --cc=lars@metafoo.de \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=nuno.sa@analog.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.