From: Thierry Reding <thierry.reding@gmail.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: linux-pwm@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH v8 1/2] pwm: add support for atmel-hlcdc-pwm device
Date: Tue, 7 Oct 2014 11:55:56 +0200 [thread overview]
Message-ID: <20141007095556.GB12631@ulmo> (raw)
In-Reply-To: <20141007111411.57448c57@bbrezillon>
[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]
On Tue, Oct 07, 2014 at 11:14:11AM +0200, Boris Brezillon wrote:
> On Tue, 7 Oct 2014 10:45:16 +0200 Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Oct 06, 2014 at 04:07:02PM +0200, Boris Brezillon wrote:
[...]
> > > +static int atmel_hlcdc_pwm_remove(struct platform_device *pdev)
> > > +{
> > > + struct atmel_hlcdc_pwm *chip = platform_get_drvdata(pdev);
> > > + int ret;
> > > +
> > > + ret = pwmchip_remove(&chip->chip);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + clk_disable_unprepare(chip->hlcdc->periph_clk);
> >
> > You might want to call clk_disable_unprepare() regardless of whether or
> > not pwmchip_remove() failed. You could simply leave out the above check
> > for ret and instead...
>
> Are you sure of this one, if pwmchip_remove fails, then the PWM chip
> might still be used. And if we disable the clock the PWM chip won't work
> anymore.
The return value of .remove() isn't really used, so if built as a module
the PWM chip will disappear anyway. Even if not built as a module the
managed resources are going to go away anyway, so for all intents and
purposes the PWM chip will be defunct.
A long time ago there were some discussions about adding reference
counting to the PWM chip and PWM devices to better handle this situation
but it has never really proven to be an issue thus far.
Perhaps a better way to solve this would be to make pwmchip_remove() not
return an error and instead WARN in the single case where it can fail
(if one of the PWM devices it exposes is still in use). That way users
will still get an appropriate warning that something's awry and it would
play more nicely with an advanced mechanism to keep PWM devices alive
beyond the lifetime of a driver to cope with removal.
Irrespective of the above it's probably fine either way, since if
pwmchip_remove() fails you're in a pretty bad place anyway.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-10-07 9:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-06 14:07 [PATCH v8 0/2] pwm: add support for atmel-hlcdc-pwm device Boris Brezillon
2014-10-06 14:07 ` [PATCH v8 1/2] " Boris Brezillon
2014-10-07 8:45 ` Thierry Reding
2014-10-07 9:14 ` Boris Brezillon
2014-10-07 9:55 ` Thierry Reding [this message]
2014-10-06 14:07 ` [PATCH v8 2/2] pwm: add DT bindings documentation for atmel-hlcdc-pwm driver Boris Brezillon
2014-10-07 8:47 ` Thierry Reding
2014-10-07 9:05 ` Boris Brezillon
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=20141007095556.GB12631@ulmo \
--to=thierry.reding@gmail.com \
--cc=boris.brezillon@free-electrons.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-pwm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).