public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: "Stijn Devriendt (sdevrien)" <sdevrien@cisco.com>
Cc: "khali@linux-fr.org" <khali@linux-fr.org>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] [PATCH] Add support for the Philips SA56004 temperature sensor.
Date: Mon, 23 May 2011 06:52:44 -0700	[thread overview]
Message-ID: <20110523135244.GA6897@ericsson.com> (raw)
In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F047F51E5@XMB-AMS-103.cisco.com>

On Mon, May 23, 2011 at 03:08:42AM -0400, Stijn Devriendt (sdevrien) wrote:
> > -----Original Message-----
> > From: Guenter Roeck [mailto:guenter.roeck@ericsson.com]
> > 
> > >  	if (!name) { /* identification failed */
> > > @@ -1372,6 +1401,18 @@ static int lm90_probe(struct i2c_client
> > *new_client,
> > >  	/* Set maximum conversion rate */
> > >  	data->max_convrate = lm90_params[data->kind].max_convrate;
> > >
> > > +	if (data->flags & LM90_HAVE_LOCAL_EXT) {
> > > +		if (lm90_params[data->kind].local_ext_offset > 0)
> > > +			data->local_ext_offset =
> > > +
> lm90_params[data->kind].local_ext_offset;
> > > +		else {
> > > +			dev_err(&new_client->dev,
> > > +			  "Invalid temperature extension register. "
> > > +			  "Accuracy may be limited.\n");
> > > +			data->flags &= (~LM90_HAVE_LOCAL_EXT);
> > > +		}
> > 
> > Either { } in both branches of the if statement, or none.
> > ( ) around ~LM90_HAVE_LOCAL_EXT is unnecessary.
> > 
> > I see it as BUG if LM90_HAVE_LOCAL_EXT is set but local_ext_offset
> isn't.
> > That should be found during coding (or code review), and not be
> exported
> > to the user. So, from my perspective, the check is unnecessary. I'll
> leave
> > that up to Jean to decide, though.
> > 
> Do you think a BUG_ON() would be better suited here?
> 
I would just use

	data->local_ext_offset = lm90_params[data->kind].local_ext_offset;

without any conditionals (the if statements just add code without real value),
followed by

	BUG_ON((data->flags & LM90_HAVE_LOCAL_EXT) && data->local_ext_offset == 0);

if you want to be sure.

> > In addition to the above, your patch generates several checkpatch
> errors
> > (trailing whitespace). Please fix.
> I recall letting checkpatch yell at me... I'll have another round of it
> to
> be sure.
> 
Try to apply your own patch, and you'll see git complain about whitespace errors.

Thanks,
Guenter

      reply	other threads:[~2011-05-23 13:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-19 14:10 [PATCH] Add support for the Philips SA56004 temperature sensor sdevrien
2011-05-23  4:37 ` [lm-sensors] " Guenter Roeck
2011-05-23  7:08   ` Stijn Devriendt (sdevrien)
2011-05-23 13:52     ` Guenter Roeck [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=20110523135244.GA6897@ericsson.com \
    --to=guenter.roeck@ericsson.com \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=sdevrien@cisco.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox