On Wed, Mar 24, 2010 at 02:31:39PM +0000, Mark Brown wrote:
On Wed, Mar 24, 2010 at 05:06:21PM +0300, Dan Carpenter wrote:
On Wed, Mar 24, 2010 at 12:59:46PM +0000, Mark Brown wrote:
This is caused by confusion with the MAX_CACHED_REGISTER definition in the header. Best to use that one consistently, I guess - I've got a sneaking suspicion something has gone AWOL in the driver publication process.
Hm... That sounds more involved than I anticipated. I don't have the hardware and don't feel comfortable making complicated changes if I can't test them.
Not really, it's just a case of picking the value to standardise on for the size of the array instead of the one you picked. However, now I look at it again REG_CACHE_SIZE is the one we want and _MAX_CACHED_REGISTER is bitrot which should be removed.
I didn't look as closely as I might due to the extraneous changes for BUG_ON() I mentioned which meant the patch wouldn't be applied anyway. Those shouldn't be changed because there's no way anything in the kernel should be generating a reference to a register which doesn't physically exist (which is what they check for).
Can someone else take care of this.
Actually, now I look even more closely there's further issues with the patch - you're missing the fact that the register cache is only used for non-volatile registers but all registers beyond the end of the register cache are treated as volatile. This means that I'm not convinced there are any actual problems here, I'm not sure what analysis smatch is doing but it looks to have generated false positives here.
Yup. You are right, this is a false positive. I'm very sorry about that, I misread the code as well.
The problem is that Smatch doesn't do cross function analysis yet. :/
regards, dan carpenter
I'll send a patch for _MAX_CACHED_REGISTER later today.