[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hhbejb1yr.wl%tiwai@suse.de>
Date: Sun, 12 Dec 2010 13:38:36 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Tejun Heo <tj@...nel.org>
Cc: linux-kernel@...r.kernel.org, Jaroslav Kysela <perex@...ex.cz>,
Liam Girdwood <lrg@...mlogic.co.uk>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: [PATCH 09/30] sound: don't use flush_scheduled_work()
At Sun, 12 Dec 2010 10:15:55 +0100,
Tejun Heo wrote:
>
> Hello, Takashi.
>
> On 12/12/2010 09:56 AM, Takashi Iwai wrote:
> >> diff --git a/sound/soc/codecs/wm8350.c b/sound/soc/codecs/wm8350.c
> >> index 7611add..b3e9fac 100644
> >> --- a/sound/soc/codecs/wm8350.c
> >> +++ b/sound/soc/codecs/wm8350.c
> >> @@ -1626,7 +1626,6 @@ static int wm8350_codec_remove(struct snd_soc_codec *codec)
> >> {
> >> struct wm8350_data *priv = snd_soc_codec_get_drvdata(codec);
> >> struct wm8350 *wm8350 = dev_get_platdata(codec->dev);
> >> - int ret;
> >>
> >> wm8350_clear_bits(wm8350, WM8350_JACK_DETECT,
> >> WM8350_JDL_ENA | WM8350_JDR_ENA);
> >> @@ -1641,15 +1640,9 @@ static int wm8350_codec_remove(struct snd_soc_codec *codec)
> >> priv->hpr.jack = NULL;
> >> priv->mic.jack = NULL;
> >>
> >> - /* cancel any work waiting to be queued. */
> >> - ret = cancel_delayed_work(&codec->delayed_work);
> >> -
> >> /* if there was any work waiting then we run it now and
> >> * wait for its completion */
> >> - if (ret) {
> >> - schedule_delayed_work(&codec->delayed_work, 0);
> >> - flush_scheduled_work();
> >> - }
> >> + flush_delayed_work_sync(&codec->delayed_work);
> >
> > I vaguely remember Liam introduced this kind of code by some reason.
> >
> > Liam, isn't it better for cancel_delayed_work_sync(), or should it be
> > like the above?
>
> flush_delayed_work_sync() semantics has been recently changed such
> that if a delayed work is pending it's queued immediately and then
> completion is waited. IOW, the behavior remains unchanged with the
> above change.
Yes, I noticed it while I was reviewing your patch. So it's pretty
correct.
Meanwhile, I wondered whether it's the really wanted behavior for
that particular code path, thus the previous question to Liam.
thanks,
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists