From: marc@cpdesign.com.au (Marc Reilly)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] mfd: mc13xxx-core: ADC conv: wait_for_completion returns a long
Date: Tue, 31 Jan 2012 08:40:55 +1100 [thread overview]
Message-ID: <201201310840.55707.marc@cpdesign.com.au> (raw)
In-Reply-To: <20120130072453.GG6305@pengutronix.de>
Hi Uwe,
Thanks for reviewing.
On Monday, January 30, 2012 06:24:53 PM Uwe Kleine-K?nig wrote:
> On Mon, Jan 30, 2012 at 09:33:24AM +1100, Marc Reilly wrote:
> > Use the correct return type for wait_for_completion, as long may be
> > larger than int.
>
> That's a theoretical problem only because the return value should be in
> the range -ESOMETHING ... HZ which fits into an int.
It _should_ be ok, but I propose that it is generally better practice to match
up the types.
> > @@ -566,20 +567,23 @@ int mc13xxx_adc_do_conversion(struct mc13xxx
> > *mc13xxx, unsigned int mode,
> >
> > mc13xxx_handler_adcdone, __func__, &adcdone_data);
> >
> > mc13xxx_reg_write(mc13xxx, MC13XXX_ADC0, adc0);
> >
> > - mc13xxx_reg_write(mc13xxx, MC13XXX_ADC1, adc1);
> > + ret = mc13xxx_reg_write(mc13xxx, MC13XXX_ADC1, adc1);
>
> Is this change intended? I guess without it you get a warning that ret
> is used uninitialized,
This was intended, ret is then either 0 after a successful write to start the
conversion off, or negative from a write error (or non-completion below).
> but if mc13xxx_reg_write fails you should IMHO
> return at once.
I guess there should be a lot more checking for failure in other places too.
You are right about returning at once.
>
> > mc13xxx_unlock(mc13xxx);
> >
> > - ret = wait_for_completion_interruptible_timeout(&adcdone_data.done,
> > HZ); + timeout =
> > wait_for_completion_interruptible_timeout(&adcdone_data.done, HZ);
> >
> > - if (!ret)
> > + if (timeout <= 0) {
> > + dev_warn(mc13xxx->dev,
> > + "timed out waiting for ADC completion\n");
> >
> > ret = -ETIMEDOUT;
> >
> > + }
>
> I think this is wrong. wait_for_completion_interruptible_timeout returns
> -ERESTARTSYS if it was interrupted. That's not a timeout and
> -ERESTARTSYS should be propagated then. !ret is the correct test for
> timeout.
It took me a little while to get your point here, and I guess I missed that in
my original understanding of the code, (which may be more of a reflection on
me :) )
I still think the way it was before is subtle, and would prefer something more
explicit, perhaps:
if (timeout == 0)
ret = -ETIMEDOUT;
else if (timeout < 0)
ret = timeout;
>
> > mc13xxx_lock(mc13xxx);
> >
> > mc13xxx_irq_free(mc13xxx, MC13XXX_IRQ_ADCDONE, &adcdone_data);
> >
> > - if (ret > 0)
> > + if (!ret)
>
> This is wrong, too, isn't it?
This is right I think. ret is return code from the mc13xxx_* call, so 0 is
success.
Cheers,
Marc
next prev parent reply other threads:[~2012-01-30 21:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-29 22:33 mfd: mc13xxx adc fixes and enhancements Marc Reilly
2012-01-29 22:33 ` [PATCH 1/6] mfd: mc13xxx-core: ADC conv: ack existing pending irqs before requesting Marc Reilly
2012-01-30 7:15 ` Uwe Kleine-König
2012-01-30 23:08 ` Marc Reilly
2012-01-29 22:33 ` [PATCH 2/6] mfd: mc13xxx-core: ADC conv: wait_for_completion returns a long Marc Reilly
2012-01-30 7:24 ` Uwe Kleine-König
2012-01-30 21:40 ` Marc Reilly [this message]
2012-01-31 8:07 ` Uwe Kleine-König
2012-02-09 10:40 ` Uwe Kleine-König
2012-01-29 22:33 ` [PATCH 3/6] mfd: mc13xxx-core: ADC conv: setup readout for single channel Marc Reilly
2012-01-29 22:33 ` [PATCH 4/6] mfd: mc13xxx-core: ADC conv: clear ADC_WORKING flag for invalid mode Marc Reilly
2012-01-30 7:27 ` Uwe Kleine-König
2012-01-29 22:33 ` [PATCH 5/6] mfd: mc13xxx-core: ADC conv: only preserve TSMOD if TS in interrupt mode Marc Reilly
2012-01-29 22:33 ` [PATCH 6/6] mfd: mc13xxx-core: ADC conversion with extra capabilities Marc Reilly
2012-01-30 8:07 ` mfd: mc13xxx adc fixes and enhancements Uwe Kleine-König
2012-02-10 7:58 ` Robin van der Gracht
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=201201310840.55707.marc@cpdesign.com.au \
--to=marc@cpdesign.com.au \
--cc=linux-arm-kernel@lists.infradead.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 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.