From: Thierry Reding <thierry.reding@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Fabrice Gasnier <fabrice.gasnier@st.com>,
jic23@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com,
alexandre.torgue@st.com, mcoquelin.stm32@gmail.com,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
vilhelm.gray@gmail.com, linux-stm32@st-md-mailman.stormreply.com,
Tomasz Duszynski <tduszyns@gmail.com>
Subject: Re: [PATCH 2/4] pwm: stm32-lp: Add power management support
Date: Wed, 6 Feb 2019 13:55:45 +0100 [thread overview]
Message-ID: <20190206125545.GI21676@ulmo> (raw)
In-Reply-To: <20190206085405.pdiwd3c6wjog5hl7@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]
On Wed, Feb 06, 2019 at 09:54:05AM +0100, Uwe Kleine-König wrote:
> On Wed, Feb 06, 2019 at 09:42:48AM +0100, Fabrice Gasnier wrote:
> > If you agree with the current approach, I can send a V2 with Tomasz's
> > suggestion to remove the ifdefs and use __maybe_unused instead.
>
> I think the suspend callback should have something like:
>
> if (is_still_enabled) {
> /*
> * The consumer didn't stop us, so refuse to suspend.
> */
> dev_err(dev, "The consumer didn't stop us, so refuse to suspend.\n");
> return -EBUSY;
> }
>
> This way there are no bad surprises if the pwm is suspended before its
> consumer and it's obvious what is missing.
Something that just occurred to me: perhaps as part of pwm_get() we
should track where we were being requested from so that we could give
hints in situations like this as to where the consumer is that forgot
to suspend the PWM.
I suppose we already have pwm_device.label to help with this, but
perhaps we could improve things if we stored __builtin_return_address
during pwm_get() to help users pinpoint where they need to look.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
alexandre.torgue@st.com, linux-pwm@vger.kernel.org,
linux-iio@vger.kernel.org, Tomasz Duszynski <tduszyns@gmail.com>,
linux-kernel@vger.kernel.org, vilhelm.gray@gmail.com,
robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
mcoquelin.stm32@gmail.com,
Fabrice Gasnier <fabrice.gasnier@st.com>,
linux-stm32@st-md-mailman.stormreply.com, jic23@kernel.org
Subject: Re: [PATCH 2/4] pwm: stm32-lp: Add power management support
Date: Wed, 6 Feb 2019 13:55:45 +0100 [thread overview]
Message-ID: <20190206125545.GI21676@ulmo> (raw)
In-Reply-To: <20190206085405.pdiwd3c6wjog5hl7@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 1128 bytes --]
On Wed, Feb 06, 2019 at 09:54:05AM +0100, Uwe Kleine-König wrote:
> On Wed, Feb 06, 2019 at 09:42:48AM +0100, Fabrice Gasnier wrote:
> > If you agree with the current approach, I can send a V2 with Tomasz's
> > suggestion to remove the ifdefs and use __maybe_unused instead.
>
> I think the suspend callback should have something like:
>
> if (is_still_enabled) {
> /*
> * The consumer didn't stop us, so refuse to suspend.
> */
> dev_err(dev, "The consumer didn't stop us, so refuse to suspend.\n");
> return -EBUSY;
> }
>
> This way there are no bad surprises if the pwm is suspended before its
> consumer and it's obvious what is missing.
Something that just occurred to me: perhaps as part of pwm_get() we
should track where we were being requested from so that we could give
hints in situations like this as to where the consumer is that forgot
to suspend the PWM.
I suppose we already have pwm_device.label to help with this, but
perhaps we could improve things if we stored __builtin_return_address
during pwm_get() to help users pinpoint where they need to look.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-02-06 12:55 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-05 12:40 [PATCH 0/4] Add PM support to STM32 LP Timer drivers Fabrice Gasnier
2019-02-05 12:40 ` Fabrice Gasnier
2019-02-05 12:40 ` Fabrice Gasnier
2019-02-05 12:40 ` [PATCH 1/4] dt-bindings: pwm-stm32-lp: document pinctrl sleep state Fabrice Gasnier
2019-02-05 12:40 ` Fabrice Gasnier
2019-02-05 12:40 ` Fabrice Gasnier
2019-02-05 12:40 ` [PATCH 2/4] pwm: stm32-lp: Add power management support Fabrice Gasnier
2019-02-05 12:40 ` Fabrice Gasnier
2019-02-05 12:40 ` Fabrice Gasnier
2019-02-05 18:30 ` Tomasz Duszynski
2019-02-05 18:30 ` Tomasz Duszynski
2019-02-05 18:30 ` Tomasz Duszynski
2019-02-06 8:42 ` Fabrice Gasnier
2019-02-06 8:42 ` Fabrice Gasnier
2019-02-06 8:42 ` Fabrice Gasnier
2019-02-05 20:47 ` Uwe Kleine-König
2019-02-05 20:47 ` Uwe Kleine-König
2019-02-05 22:25 ` Thierry Reding
2019-02-05 22:25 ` Thierry Reding
2019-02-06 8:42 ` Fabrice Gasnier
2019-02-06 8:42 ` Fabrice Gasnier
2019-02-06 8:54 ` Uwe Kleine-König
2019-02-06 8:54 ` Uwe Kleine-König
2019-02-06 12:55 ` Thierry Reding [this message]
2019-02-06 12:55 ` Thierry Reding
2019-02-06 14:54 ` Fabrice Gasnier
2019-02-06 14:54 ` Fabrice Gasnier
2019-02-06 14:54 ` Fabrice Gasnier
2019-02-05 12:40 ` [PATCH 3/4] dt-bindings: iio: stm32-lptimer-counter: document pinctrl sleep state Fabrice Gasnier
2019-02-05 12:40 ` Fabrice Gasnier
2019-02-05 12:40 ` Fabrice Gasnier
2019-02-05 12:40 ` [PATCH 4/4] iio: counter: stm32-lptimer: Add power management support Fabrice Gasnier
2019-02-05 12:40 ` Fabrice Gasnier
2019-02-05 12:40 ` Fabrice Gasnier
2019-02-09 16:21 ` Jonathan Cameron
2019-02-09 16:21 ` Jonathan Cameron
2019-02-09 16:21 ` Jonathan Cameron
2019-02-10 21:33 ` Uwe Kleine-König
2019-02-10 21:33 ` Uwe Kleine-König
2019-02-10 21:33 ` Uwe Kleine-König
2019-02-11 13:21 ` Fabrice Gasnier
2019-02-11 13:21 ` Fabrice Gasnier
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=20190206125545.GI21676@ulmo \
--to=thierry.reding@gmail.com \
--cc=alexandre.torgue@st.com \
--cc=devicetree@vger.kernel.org \
--cc=fabrice.gasnier@st.com \
--cc=jic23@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mark.rutland@arm.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=robh+dt@kernel.org \
--cc=tduszyns@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vilhelm.gray@gmail.com \
/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.