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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
