Re: [Intel-gfx] [RFC DO NOT MERGE] treewide: use __xchg in most obvious places

2023-01-10 Thread Andy Shevchenko
On Tue, Jan 10, 2023 at 01:46:37PM +0100, Andrzej Hajda wrote: > On 10.01.2023 12:07, Andy Shevchenko wrote: > > On Tue, Jan 10, 2023 at 11:53:06AM +0100, Andrzej Hajda wrote: ... > > > + return __xchg(_chain->p_prod_elem, > > > + (void *)(((u8 *)p_chain->p_prod_elem) + > > >

Re: [Intel-gfx] [RFC DO NOT MERGE] treewide: use __xchg in most obvious places

2023-01-10 Thread Andrzej Hajda
On 10.01.2023 12:07, Andy Shevchenko wrote: On Tue, Jan 10, 2023 at 11:53:06AM +0100, Andrzej Hajda wrote: This patch tries to show usability of __xchg helper. It is not intended to be merged, but I can convert it to proper patchset if necessary. There are many more places where __xchg can be

Re: [RFC DO NOT MERGE] treewide: use __xchg in most obvious places

2023-01-10 Thread Andy Shevchenko
On Tue, Jan 10, 2023 at 11:53:06AM +0100, Andrzej Hajda wrote: > This patch tries to show usability of __xchg helper. > It is not intended to be merged, but I can convert > it to proper patchset if necessary. > > There are many more places where __xchg can be used. > This demo shows the most

[RFC DO NOT MERGE] treewide: use __xchg in most obvious places

2023-01-10 Thread Andrzej Hajda
This patch tries to show usability of __xchg helper. It is not intended to be merged, but I can convert it to proper patchset if necessary. There are many more places where __xchg can be used. This demo shows the most spectacular cases IMHO: - previous value is returned from function, - temporary