On Thu, Nov 10, 2016 at 06:12:52PM +0200, Andy Shevchenko wrote: > On Thu, 2016-11-10 at 17:06 +0100, Greg Kroah-Hartman wrote: > > On Thu, Nov 10, 2016 at 05:52:47PM +0200, Andy Shevchenko wrote: > > > On Thu, 2016-11-10 at 16:25 +0100, Greg Kroah-Hartman wrote: > > > > On Thu, Nov 10, 2016 at 04:59:54PM +0200, Andy Shevchenko wrote: > > > > > On Thu, 2016-11-10 at 14:59 +0100, Greg Kroah-Hartman wrote: > > > > > > On Thu, Nov 03, 2016 at 06:26:57PM +0200, Andy Shevchenko > > > > > > wrote: > > > > > > That doesn't make much logical sense. Yes, I know __acquire > > > > > > is > > > > > > just a > > > > > > crazy macro, but really, look at what you just wrote and tell > > > > > > me > > > > > > that > > > > > > someone who doesn't know what __acquire does, would instantly > > > > > > think > > > > > > this > > > > > > is a null pointer dereference. > > > > > > > > > > > > Please fix. > > > > > > > > > > Do you mean add comments here in the code? > > > > > > > > Huh? > > > > > > > > No, fix the macro to make sense!!! > > > > > > Most cleaner way for now I see is to get rid of macros completely > > > and > > > open code them in caller's places. > > > > No, just write valid C in the macro. > > > > You are going to make me do this myself, aren't you... > > No, though I don't clearly see the way of valid C in those macros to get > rid of sparse warning. Really? Ick... Writing invalid C in a macro just to make a tool happy should never be the solution. How about just making those inline static functions? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
