* problem in b43_nrssi_hw_update()?
@ 2011-10-08 19:29 Dan Carpenter
0 siblings, 0 replies; only message in thread
From: Dan Carpenter @ 2011-10-08 19:29 UTC (permalink / raw)
To: mb; +Cc: linux-wireless
My latest testing version of Smatch complains about the wrapping in
b43_nrssi_hw_update() when val is 0xffff. The function is defined
like this:
/* http://bcm-specs.sipsolutions.net/NRSSILookupTable */
static void b43_nrssi_hw_update(struct b43_wldev *dev, u16 val)
{
u16 i;
s16 tmp;
for (i = 0; i < 64; i++) {
tmp = b43_nrssi_hw_read(dev, i);
tmp -= val;
tmp = clamp_val(tmp, -32, 31);
b43_nrssi_hw_write(dev, i, tmp);
}
}
It's only called from one place like this:
/* The specs state to update the NRSSI LT with
* the value 0x7FFFFFFF here. I think that is some weird
* compiler optimization in the original driver.
* Essentially, what we do here is resetting all NRSSI LT
* entries to -32 (see the clamp_val() in nrssi_hw_update())
*/
b43_nrssi_hw_update(dev, 0xFFFF); //FIXME?
Since tmp in b43_nrssi_hw_update() is s16 and val is always
(u16)0xFFFF, that means that:
tmp -= val;
is always the same just tmp += 1;
This code has a fixme, and it seems like an overly complicated way
of adding 1 to a variable, plus it doesn't seem to match the
documentation very well. :P
I know you've looked at this before and that's why it has the FIXME
comment... I'm not sure what to do...
regards,
dan carpenter
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2011-10-08 19:29 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-08 19:29 problem in b43_nrssi_hw_update()? Dan Carpenter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox