From: Andrew Morton <akpm@linux-foundation.org>
To: Peter Meerwald <pmeerw@pmeerw.net>
Cc: linux-kernel@vger.kernel.org, lars@metafoo.de, rpurdie@rpsys.net
Subject: Re: [PATCH v2] add LED driver for PCA9663 I2C chip
Date: Thu, 2 Feb 2012 11:54:56 -0800 [thread overview]
Message-ID: <20120202115456.7fe11c18.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.2.01.1202021130070.10172@pmeerw.net>
On Thu, 2 Feb 2012 11:42:09 +0100 (CET)
Peter Meerwald <pmeerw@pmeerw.net> wrote:
>
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > +exit:
> > > > + while (i--) {
> > > > + led_classdev_unregister(&pca9633[i].led_cdev);
> > > > + cancel_work_sync(&pca9633[i].work);
> > > > + }
> > > This (untested!) loop has an off-by-one error.
>
> > Well, it's partly wrong. It's wrong for the cancel_work_sync() but not
> > for the led_classdev_unregister(). The cancel_work_sync() can just be
> > removed: we haven't scheduled any works yet.
>
> there are 4 leds with get led_classdev_register()ed
>
> wouldn't it be possible that someone is starting to use led1 while led3 has
> not been registered yet? if registration for led3 fails, the exit code
> (above) is called and there might be work scheduled
>
> so (hypothetically):
> register led1 -> ok
> register led2 -> ok
> use led1 (schedule work)
> register led3 -> fail -> exit code
>
> the code has been copied from other led drivers
> I think there is no harm to keep cancel_work_sync()
Spose so - it won't hurt. And I was wrong about there being an
off-by-one.
prev parent reply other threads:[~2012-02-02 19:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-18 19:51 [PATCH v2] add LED driver for PCA9663 I2C chip Peter Meerwald
2012-01-31 0:28 ` Andrew Morton
2012-01-31 0:34 ` Andrew Morton
2012-02-02 10:42 ` Peter Meerwald
2012-02-02 19:54 ` Andrew Morton [this message]
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=20120202115456.7fe11c18.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=lars@metafoo.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=rpurdie@rpsys.net \
/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).