Tim Deegan wrote: > > At 10:55 +0000 on 28 Mar (1396000508), Andrew Cooper wrote: >> >> This is some coverity-inspired tidying. >> >> Coverity has some grief analysing the call sites of atomic_read(). >> This is >> believed to be a bug in Coverity itself when expanding the nested >> macros, but >> there is no legitimate reason for it to be a macro in the first place. >> >> This patch changes {,_}atomic_{read,set}() from being macros to being >> static >> inline functions, thus gaining some type safety. >> >> One issue which is not immediately obvious is that the non-atomic >> variants take >> their atomic_t at a different level of indirection to the atomic >> variants. >> >> This is not suitable for _atomic_set() (when used to initialise an >> atomic_t) >> which is converted to take its parameter as a pointer. One callsite of >> _atomic_set() is updated, while the other two callsites are updated to >> ATOMIC_INIT(). >> >> Signed-off-by: Andrew Cooper > > > Reviewed-by: Tim Deegan > > FWIW, I approve of converting both kinds of accessors to inlines, just > on general principles. Agreed, functions are preferable to macros. Acked-by: Keir Fraser