On Fri, 29 May 2015, Dan Carpenter wrote: > On Fri, May 29, 2015 at 07:21:26PM +0200, Nicholas Mc Guire wrote: > > On Fri, 29 May 2015, Dan Carpenter wrote: > > > > > On Fri, May 29, 2015 at 06:41:28PM +0200, Nicholas Mc Guire wrote: > > > > The schedule_timeout*() helpers take the timeout as signed long, as > > > > ch_close_delay in struct channel_t was not used for other purposes its > > > > type was switched to signed long and the declarations fixed up. > > > > > > Uh, we never pass it to schedule_timeout etc and even if we did how > > > would that matter? It's either 250 or 0. > > > > > > What is the bug you are trying to fix and we can help you? > > > > > static code checkers being unhappy with type mismatch > > automatic type conversion is ok if necessary but in this > > case it simply is not as the ch_close_delay is only being > > used in this one place so why not do it type clean ? > > This seems like a pointless warning. What does the warning look like? > We pass ms to msecs_to_jiffies() and not to schedule_timeout() so it > seems like somewhere something is confused. Not really - just my carelessness - the msecs_to_jiffies was not in there and I fixed up the types first - then put the msecs_to_jiffies in there to fix up the time conversion ...oh well took the type conversion out just to put it back in my self...sorry thats a bit braindead. thanks for catching that. > > > I'll turn the question around - what reason would there be to > > go through type conversion if it is not needed ? > > You can go crazy if you do ever pointless change which a static analysis > tool suggests... > > Btw, Smatch says that "ms" is always 250 here, actually. I was guessing > earlier when I said it could be zero. Get a smarter static checker > which can read code. wont blame it on coccinelle - its my scripts that are to blame - but in this case it was the cleanup after the fix for the warning that broke it. so 2/2 is pointless - sorry for that - pleas just toss it. thx! hofrat _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
