linux-kernel - Re: [PATCH] Add support for the Philips SA56004 temperature sensor.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 4 Jun 2011 09:57:57 -0700
From:	Guenter Roeck <guenter.roeck@...csson.com>
To:	"Stijn Devriendt (sdevrien)" <sdevrien@...co.com>
CC:	anish singh <anish198519851985@...il.com>,
	"khali@...ux-fr.org" <khali@...ux-fr.org>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Add support for the Philips SA56004 temperature sensor.

On Sat, Jun 04, 2011 at 12:32:01PM -0400, Stijn Devriendt (sdevrien) wrote:
> > From: anish singh [mailto:anish198519851985@...il.com] 
> >
> > I am no expert on HWMON but just want to 
> > add some points.
> > @@ -454,7 +477,7 @@ static struct lm90_data *lm90_update_device(struct device *dev)
> >
> >               if (data->flags & LM90_HAVE_LOCAL_EXT) {
> >                       lm90_read16(client, LM90_REG_R_LOCAL_TEMP,
> > -                                   MAX6657_REG_R_LOCAL_TEMPL,
> > +                                   data->reg_local_ext,
> >                                   &data->temp11[4]);
> > I don't think this variable reg_local_ext should exist as 
> > register address should be "# defined" and should not be
> > part of lm90_data but i do see a case here where we are
> > assuming MAX6657 is only having this LM90_HAVE_LOCAL_EXT
> > flag set.So i think we should have some more branching here
> > to detect the device and pass the corresponding register but as
> > i said i am no expert.
> > 
> 
> Only MAX6657 and SA56004 have the local temperature extension
> register and unfortunately they reside at different offsets.
> Therefore the probing will detect the right chip and, if supported,
> use the correct register.
> 
> >               } else {
> >                       if (lm90_read_reg(client, LM90_REG_R_LOCAL_TEMP,
> > @@ -1372,6 +1400,11 @@ 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) {
> > +               data->reg_local_ext = lm90_params[data->kind].reg_local_ext;
> > +               BUG_ON(data->reg_local_ext == 0);
> > +       }
> > +
> > I think this BUG_ON is too harsh in probe.We generally use pr_err
> > to print if something which is supposed to be set is not set.As BUG_ON
> > will call kernel panic,right?
> 
> The reason for adding the BUG_ON rather than the error was that it is
> in fact a coding error when the flag is set without specifying the offset.
> Such a condition should never make it into a running system and should be
> caught during coding or review.
> BUG_ON only does an oops, panic is optional depending on panic_on_oops being
> set.
> 
Maybe use WARN_ON instead ?

Thanks,
Guenter
--
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/