From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-hexagon@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
Boqun Feng <boqun.feng@gmail.com>,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
intel-gfx@lists.freedesktop.org, linux-m68k@lists.linux-m68k.org,
openrisc@lists.librecores.org, loongarch@lists.linux.dev,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
linux-arm-kernel@lists.infradead.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-alpha@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC DO NOT MERGE] treewide: use __xchg in most obvious places
Date: Tue, 10 Jan 2023 13:07:02 +0200 [thread overview]
Message-ID: <Y71G1tkmUzM4BLxn@smile.fi.intel.com> (raw)
In-Reply-To: <20230110105306.3973122-1-andrzej.hajda@intel.com>
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 spectacular cases IMHO:
> - previous value is returned from function,
> - temporary variables are in use.
>
> As a result readability is much better and diffstat is quite
> nice, less local vars to look at.
> In many cases whole body of functions is replaced
> with __xchg(ptr, val), so as further refactoring the whole
> function can be removed and __xchg can be called directly.
...
> arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr,
> struct pt_regs *regs)
> {
> - unsigned long orig_ret_vaddr;
> -
> - orig_ret_vaddr = regs->ARM_lr;
> - /* Replace the return addr with trampoline addr */
> - regs->ARM_lr = trampoline_vaddr;
> - return orig_ret_vaddr;
> + return __xchg(®s->ARM_lr, trampoline_vaddr);
> }
If it's not a callback, the entire function can be killed.
And this is a good example of the function usage.
OTOH, these places might have a side effect (if it's in deep CPU
handlers), means we need to do this carefully.
...
> static inline void *qed_chain_produce(struct qed_chain *p_chain)
> {
> - void *p_ret = NULL, *p_prod_idx, *p_prod_page_idx;
> + void *p_prod_idx, *p_prod_page_idx;
>
> if (is_chain_u16(p_chain)) {
> if ((p_chain->u.chain16.prod_idx &
> @@ -390,11 +391,8 @@ static inline void *qed_chain_produce(struct qed_chain *p_chain)
> p_chain->u.chain32.prod_idx++;
> }
>
> - p_ret = p_chain->p_prod_elem;
> - p_chain->p_prod_elem = (void *)(((u8 *)p_chain->p_prod_elem) +
> - p_chain->elem_size);
> -
> - return p_ret;
> + return __xchg(&p_chain->p_prod_elem,
> + (void *)(((u8 *)p_chain->p_prod_elem) + p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
> }
...
Btw, is it done by coccinelle? If no, why not providing the script?
--
With Best Regards,
Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-hexagon@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
Boqun Feng <boqun.feng@gmail.com>,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
intel-gfx@lists.freedesktop.org, linux-m68k@lists.linux-m68k.org,
openrisc@lists.librecores.org, loongarch@lists.linux.dev,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
linux-arm-kernel@lists.infradead.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
Daniel Vetter <daniel@ffwll.ch>,
linux-alpha@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [Intel-gfx] [RFC DO NOT MERGE] treewide: use __xchg in most obvious places
Date: Tue, 10 Jan 2023 13:07:02 +0200 [thread overview]
Message-ID: <Y71G1tkmUzM4BLxn@smile.fi.intel.com> (raw)
In-Reply-To: <20230110105306.3973122-1-andrzej.hajda@intel.com>
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 spectacular cases IMHO:
> - previous value is returned from function,
> - temporary variables are in use.
>
> As a result readability is much better and diffstat is quite
> nice, less local vars to look at.
> In many cases whole body of functions is replaced
> with __xchg(ptr, val), so as further refactoring the whole
> function can be removed and __xchg can be called directly.
...
> arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr,
> struct pt_regs *regs)
> {
> - unsigned long orig_ret_vaddr;
> -
> - orig_ret_vaddr = regs->ARM_lr;
> - /* Replace the return addr with trampoline addr */
> - regs->ARM_lr = trampoline_vaddr;
> - return orig_ret_vaddr;
> + return __xchg(®s->ARM_lr, trampoline_vaddr);
> }
If it's not a callback, the entire function can be killed.
And this is a good example of the function usage.
OTOH, these places might have a side effect (if it's in deep CPU
handlers), means we need to do this carefully.
...
> static inline void *qed_chain_produce(struct qed_chain *p_chain)
> {
> - void *p_ret = NULL, *p_prod_idx, *p_prod_page_idx;
> + void *p_prod_idx, *p_prod_page_idx;
>
> if (is_chain_u16(p_chain)) {
> if ((p_chain->u.chain16.prod_idx &
> @@ -390,11 +391,8 @@ static inline void *qed_chain_produce(struct qed_chain *p_chain)
> p_chain->u.chain32.prod_idx++;
> }
>
> - p_ret = p_chain->p_prod_elem;
> - p_chain->p_prod_elem = (void *)(((u8 *)p_chain->p_prod_elem) +
> - p_chain->elem_size);
> -
> - return p_ret;
> + return __xchg(&p_chain->p_prod_elem,
> + (void *)(((u8 *)p_chain->p_prod_elem) + p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
> }
...
Btw, is it done by coccinelle? If no, why not providing the script?
--
With Best Regards,
Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-hexagon@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
Boqun Feng <boqun.feng@gmail.com>,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
intel-gfx@lists.freedesktop.org, linux-m68k@lists.linux-m68k.org,
openrisc@lists.librecores.org, loongarch@lists.linux.dev,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
linux-arm-kernel@lists.infradead.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
Daniel Vetter <daniel@ffwll.ch>,
linux-alpha@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC DO NOT MERGE] treewide: use __xchg in most obvious places
Date: Tue, 10 Jan 2023 13:07:02 +0200 [thread overview]
Message-ID: <Y71G1tkmUzM4BLxn@smile.fi.intel.com> (raw)
In-Reply-To: <20230110105306.3973122-1-andrzej.hajda@intel.com>
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 spectacular cases IMHO:
> - previous value is returned from function,
> - temporary variables are in use.
>
> As a result readability is much better and diffstat is quite
> nice, less local vars to look at.
> In many cases whole body of functions is replaced
> with __xchg(ptr, val), so as further refactoring the whole
> function can be removed and __xchg can be called directly.
...
> arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr,
> struct pt_regs *regs)
> {
> - unsigned long orig_ret_vaddr;
> -
> - orig_ret_vaddr = regs->ARM_lr;
> - /* Replace the return addr with trampoline addr */
> - regs->ARM_lr = trampoline_vaddr;
> - return orig_ret_vaddr;
> + return __xchg(®s->ARM_lr, trampoline_vaddr);
> }
If it's not a callback, the entire function can be killed.
And this is a good example of the function usage.
OTOH, these places might have a side effect (if it's in deep CPU
handlers), means we need to do this carefully.
...
> static inline void *qed_chain_produce(struct qed_chain *p_chain)
> {
> - void *p_ret = NULL, *p_prod_idx, *p_prod_page_idx;
> + void *p_prod_idx, *p_prod_page_idx;
>
> if (is_chain_u16(p_chain)) {
> if ((p_chain->u.chain16.prod_idx &
> @@ -390,11 +391,8 @@ static inline void *qed_chain_produce(struct qed_chain *p_chain)
> p_chain->u.chain32.prod_idx++;
> }
>
> - p_ret = p_chain->p_prod_elem;
> - p_chain->p_prod_elem = (void *)(((u8 *)p_chain->p_prod_elem) +
> - p_chain->elem_size);
> -
> - return p_ret;
> + return __xchg(&p_chain->p_prod_elem,
> + (void *)(((u8 *)p_chain->p_prod_elem) + p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
> }
...
Btw, is it done by coccinelle? If no, why not providing the script?
--
With Best Regards,
Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-xtensa@linux-xtensa.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Arnd Bergmann <arnd@arndb.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [RFC DO NOT MERGE] treewide: use __xchg in most obvious places
Date: Tue, 10 Jan 2023 13:07:02 +0200 [thread overview]
Message-ID: <Y71G1tkmUzM4BLxn@smile.fi.intel.com> (raw)
In-Reply-To: <20230110105306.3973122-1-andrzej.hajda@intel.com>
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 spectacular cases IMHO:
> - previous value is returned from function,
> - temporary variables are in use.
>
> As a result readability is much better and diffstat is quite
> nice, less local vars to look at.
> In many cases whole body of functions is replaced
> with __xchg(ptr, val), so as further refactoring the whole
> function can be removed and __xchg can be called directly.
...
> arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr,
> struct pt_regs *regs)
> {
> - unsigned long orig_ret_vaddr;
> -
> - orig_ret_vaddr = regs->ARM_lr;
> - /* Replace the return addr with trampoline addr */
> - regs->ARM_lr = trampoline_vaddr;
> - return orig_ret_vaddr;
> + return __xchg(®s->ARM_lr, trampoline_vaddr);
> }
If it's not a callback, the entire function can be killed.
And this is a good example of the function usage.
OTOH, these places might have a side effect (if it's in deep CPU
handlers), means we need to do this carefully.
...
> static inline void *qed_chain_produce(struct qed_chain *p_chain)
> {
> - void *p_ret = NULL, *p_prod_idx, *p_prod_page_idx;
> + void *p_prod_idx, *p_prod_page_idx;
>
> if (is_chain_u16(p_chain)) {
> if ((p_chain->u.chain16.prod_idx &
> @@ -390,11 +391,8 @@ static inline void *qed_chain_produce(struct qed_chain *p_chain)
> p_chain->u.chain32.prod_idx++;
> }
>
> - p_ret = p_chain->p_prod_elem;
> - p_chain->p_prod_elem = (void *)(((u8 *)p_chain->p_prod_elem) +
> - p_chain->elem_size);
> -
> - return p_ret;
> + return __xchg(&p_chain->p_prod_elem,
> + (void *)(((u8 *)p_chain->p_prod_elem) + p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
> }
...
Btw, is it done by coccinelle? If no, why not providing the script?
--
With Best Regards,
Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-xtensa@linux-xtensa.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Arnd Bergmann <arnd@arndb.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [RFC DO NOT MERGE] treewide: use __xchg in most obvious places
Date: Tue, 10 Jan 2023 13:07:02 +0200 [thread overview]
Message-ID: <Y71G1tkmUzM4BLxn@smile.fi.intel.com> (raw)
In-Reply-To: <20230110105306.3973122-1-andrzej.hajda@intel.com>
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 spectacular cases IMHO:
> - previous value is returned from function,
> - temporary variables are in use.
>
> As a result readability is much better and diffstat is quite
> nice, less local vars to look at.
> In many cases whole body of functions is replaced
> with __xchg(ptr, val), so as further refactoring the whole
> function can be removed and __xchg can be called directly.
...
> arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr,
> struct pt_regs *regs)
> {
> - unsigned long orig_ret_vaddr;
> -
> - orig_ret_vaddr = regs->ARM_lr;
> - /* Replace the return addr with trampoline addr */
> - regs->ARM_lr = trampoline_vaddr;
> - return orig_ret_vaddr;
> + return __xchg(®s->ARM_lr, trampoline_vaddr);
> }
If it's not a callback, the entire function can be killed.
And this is a good example of the function usage.
OTOH, these places might have a side effect (if it's in deep CPU
handlers), means we need to do this carefully.
...
> static inline void *qed_chain_produce(struct qed_chain *p_chain)
> {
> - void *p_ret = NULL, *p_prod_idx, *p_prod_page_idx;
> + void *p_prod_idx, *p_prod_page_idx;
>
> if (is_chain_u16(p_chain)) {
> if ((p_chain->u.chain16.prod_idx &
> @@ -390,11 +391,8 @@ static inline void *qed_chain_produce(struct qed_chain *p_chain)
> p_chain->u.chain32.prod_idx++;
> }
>
> - p_ret = p_chain->p_prod_elem;
> - p_chain->p_prod_elem = (void *)(((u8 *)p_chain->p_prod_elem) +
> - p_chain->elem_size);
> -
> - return p_ret;
> + return __xchg(&p_chain->p_prod_elem,
> + (void *)(((u8 *)p_chain->p_prod_elem) + p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
> }
...
Btw, is it done by coccinelle? If no, why not providing the script?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-xtensa@linux-xtensa.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Arnd Bergmann <arnd@arndb.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [RFC DO NOT MERGE] treewide: use __xchg in most obvious places
Date: Tue, 10 Jan 2023 13:07:02 +0200 [thread overview]
Message-ID: <Y71G1tkmUzM4BLxn@smile.fi.intel.com> (raw)
In-Reply-To: <20230110105306.3973122-1-andrzej.hajda@intel.com>
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 spectacular cases IMHO:
> - previous value is returned from function,
> - temporary variables are in use.
>
> As a result readability is much better and diffstat is quite
> nice, less local vars to look at.
> In many cases whole body of functions is replaced
> with __xchg(ptr, val), so as further refactoring the whole
> function can be removed and __xchg can be called directly.
...
> arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr,
> struct pt_regs *regs)
> {
> - unsigned long orig_ret_vaddr;
> -
> - orig_ret_vaddr = regs->ARM_lr;
> - /* Replace the return addr with trampoline addr */
> - regs->ARM_lr = trampoline_vaddr;
> - return orig_ret_vaddr;
> + return __xchg(®s->ARM_lr, trampoline_vaddr);
> }
If it's not a callback, the entire function can be killed.
And this is a good example of the function usage.
OTOH, these places might have a side effect (if it's in deep CPU
handlers), means we need to do this carefully.
...
> static inline void *qed_chain_produce(struct qed_chain *p_chain)
> {
> - void *p_ret = NULL, *p_prod_idx, *p_prod_page_idx;
> + void *p_prod_idx, *p_prod_page_idx;
>
> if (is_chain_u16(p_chain)) {
> if ((p_chain->u.chain16.prod_idx &
> @@ -390,11 +391,8 @@ static inline void *qed_chain_produce(struct qed_chain *p_chain)
> p_chain->u.chain32.prod_idx++;
> }
>
> - p_ret = p_chain->p_prod_elem;
> - p_chain->p_prod_elem = (void *)(((u8 *)p_chain->p_prod_elem) +
> - p_chain->elem_size);
> -
> - return p_ret;
> + return __xchg(&p_chain->p_prod_elem,
> + (void *)(((u8 *)p_chain->p_prod_elem) + p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
> }
...
Btw, is it done by coccinelle? If no, why not providing the script?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-xtensa@linux-xtensa.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Arnd Bergmann <arnd@arndb.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [RFC DO NOT MERGE] treewide: use __xchg in most obvious places
Date: Tue, 10 Jan 2023 13:07:02 +0200 [thread overview]
Message-ID: <Y71G1tkmUzM4BLxn@smile.fi.intel.com> (raw)
In-Reply-To: <20230110105306.3973122-1-andrzej.hajda@intel.com>
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 spectacular cases IMHO:
> - previous value is returned from function,
> - temporary variables are in use.
>
> As a result readability is much better and diffstat is quite
> nice, less local vars to look at.
> In many cases whole body of functions is replaced
> with __xchg(ptr, val), so as further refactoring the whole
> function can be removed and __xchg can be called directly.
...
> arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr,
> struct pt_regs *regs)
> {
> - unsigned long orig_ret_vaddr;
> -
> - orig_ret_vaddr = regs->ARM_lr;
> - /* Replace the return addr with trampoline addr */
> - regs->ARM_lr = trampoline_vaddr;
> - return orig_ret_vaddr;
> + return __xchg(®s->ARM_lr, trampoline_vaddr);
> }
If it's not a callback, the entire function can be killed.
And this is a good example of the function usage.
OTOH, these places might have a side effect (if it's in deep CPU
handlers), means we need to do this carefully.
...
> static inline void *qed_chain_produce(struct qed_chain *p_chain)
> {
> - void *p_ret = NULL, *p_prod_idx, *p_prod_page_idx;
> + void *p_prod_idx, *p_prod_page_idx;
>
> if (is_chain_u16(p_chain)) {
> if ((p_chain->u.chain16.prod_idx &
> @@ -390,11 +391,8 @@ static inline void *qed_chain_produce(struct qed_chain *p_chain)
> p_chain->u.chain32.prod_idx++;
> }
>
> - p_ret = p_chain->p_prod_elem;
> - p_chain->p_prod_elem = (void *)(((u8 *)p_chain->p_prod_elem) +
> - p_chain->elem_size);
> -
> - return p_ret;
> + return __xchg(&p_chain->p_prod_elem,
> + (void *)(((u8 *)p_chain->p_prod_elem) + p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
> }
...
Btw, is it done by coccinelle? If no, why not providing the script?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-hexagon@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
Boqun Feng <boqun.feng@gmail.com>,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
intel-gfx@lists.freedesktop.org, linux-m68k@lists.linux-m68k.org,
openrisc@lists.librecores.org, loongarch@lists.linux.dev,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
linux-arm-kernel@lists.infradead.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-alpha@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC DO NOT MERGE] treewide: use __xchg in most obvious places
Date: Tue, 10 Jan 2023 11:07:02 +0000 [thread overview]
Message-ID: <Y71G1tkmUzM4BLxn@smile.fi.intel.com> (raw)
In-Reply-To: <20230110105306.3973122-1-andrzej.hajda@intel.com>
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 spectacular cases IMHO:
> - previous value is returned from function,
> - temporary variables are in use.
>
> As a result readability is much better and diffstat is quite
> nice, less local vars to look at.
> In many cases whole body of functions is replaced
> with __xchg(ptr, val), so as further refactoring the whole
> function can be removed and __xchg can be called directly.
...
> arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr,
> struct pt_regs *regs)
> {
> - unsigned long orig_ret_vaddr;
> -
> - orig_ret_vaddr = regs->ARM_lr;
> - /* Replace the return addr with trampoline addr */
> - regs->ARM_lr = trampoline_vaddr;
> - return orig_ret_vaddr;
> + return __xchg(®s->ARM_lr, trampoline_vaddr);
> }
If it's not a callback, the entire function can be killed.
And this is a good example of the function usage.
OTOH, these places might have a side effect (if it's in deep CPU
handlers), means we need to do this carefully.
...
> static inline void *qed_chain_produce(struct qed_chain *p_chain)
> {
> - void *p_ret = NULL, *p_prod_idx, *p_prod_page_idx;
> + void *p_prod_idx, *p_prod_page_idx;
>
> if (is_chain_u16(p_chain)) {
> if ((p_chain->u.chain16.prod_idx &
> @@ -390,11 +391,8 @@ static inline void *qed_chain_produce(struct qed_chain *p_chain)
> p_chain->u.chain32.prod_idx++;
> }
>
> - p_ret = p_chain->p_prod_elem;
> - p_chain->p_prod_elem = (void *)(((u8 *)p_chain->p_prod_elem) +
> - p_chain->elem_size);
> -
> - return p_ret;
> + return __xchg(&p_chain->p_prod_elem,
> + (void *)(((u8 *)p_chain->p_prod_elem) + p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
> }
...
Btw, is it done by coccinelle? If no, why not providing the script?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-01-10 11:07 UTC|newest]
Thread overview: 306+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 11:46 [PATCH 00/19] Introduce __xchg, non-atomic xchg Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [PATCH 01/19] arch/alpha: rename internal name __xchg to __arch_xchg Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [PATCH 02/19] arch/arc: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 9:32 ` [Intel-gfx] " Arnd Bergmann
2022-12-29 9:32 ` Arnd Bergmann
2022-12-29 11:33 ` [PATCH v2] arch: rename all internal names " Andrzej Hajda
2022-12-29 11:33 ` Andrzej Hajda
2022-12-29 11:33 ` Andrzej Hajda
2022-12-29 11:33 ` [Intel-gfx] " Andrzej Hajda
2022-12-29 11:33 ` Andrzej Hajda
2022-12-29 11:33 ` Andrzej Hajda
2022-12-29 11:33 ` Andrzej Hajda
2022-12-29 23:00 ` kernel test robot
2022-12-29 23:00 ` kernel test robot
2022-12-29 23:00 ` kernel test robot
2022-12-29 23:00 ` kernel test robot
2022-12-29 23:00 ` [Intel-gfx] " kernel test robot
2022-12-30 14:15 ` [PATCH v3] " Andrzej Hajda
2022-12-30 14:15 ` Andrzej Hajda
2022-12-30 14:15 ` Andrzej Hajda
2022-12-30 14:15 ` Andrzej Hajda
2022-12-30 14:15 ` Andrzej Hajda
2022-12-30 14:15 ` [Intel-gfx] " Andrzej Hajda
2022-12-30 14:15 ` Andrzej Hajda
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` [Intel-gfx] " Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-03 10:02 ` Heiko Carstens
2023-01-05 9:54 ` [PATCH v4] " Andrzej Hajda
2023-01-05 9:54 ` Andrzej Hajda
2023-01-05 9:54 ` Andrzej Hajda
2023-01-05 9:54 ` Andrzej Hajda
2023-01-05 9:54 ` Andrzej Hajda
2023-01-05 9:54 ` [Intel-gfx] " Andrzej Hajda
2023-01-05 9:54 ` Andrzej Hajda
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` [Intel-gfx] " Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-16 10:00 ` Geert Uytterhoeven
2023-01-02 8:30 ` [PATCH v2] " Geert Uytterhoeven
2023-01-02 8:30 ` Geert Uytterhoeven
2023-01-02 8:30 ` Geert Uytterhoeven
2023-01-02 8:30 ` Geert Uytterhoeven
2023-01-02 8:30 ` Geert Uytterhoeven
2023-01-02 8:30 ` [Intel-gfx] " Geert Uytterhoeven
2023-01-02 8:30 ` Geert Uytterhoeven
2022-12-22 11:46 ` [PATCH 03/19] arch/arm: rename internal name " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [PATCH 04/19] arch/arm64: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 05/19] arch/hexagon: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 06/19] arch/ia64: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 07/19] arch/loongarch: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 08/19] arch/m68k: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 09/19] arch/mips: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 10/19] arch/openrisc: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 11/19] arch/parisc: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [PATCH 12/19] arch/powerpc: correct logged function names in xchg helpers Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [PATCH 13/19] arch/riscv: rename internal name __xchg to __arch_xchg Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` [Intel-gfx] " Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2022-12-29 16:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` [Intel-gfx] " Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2023-02-15 5:22 ` Palmer Dabbelt
2022-12-22 11:46 ` [PATCH 14/19] arch/s390: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 15/19] arch/sh: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 16/19] arch/sparc: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 17/19] arch/xtensa: " Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 11:46 ` [PATCH 18/19] linux/include: add non-atomic version of xchg Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 12:47 ` [Intel-gfx] " Andy Shevchenko
2022-12-22 12:47 ` Andy Shevchenko
2022-12-22 11:46 ` [PATCH 19/19] drm/i915/gt: use __xchg instead of internal helper Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` Andrzej Hajda
2022-12-22 11:46 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 14:12 ` [PATCH 00/19] Introduce __xchg, non-atomic xchg Geert Uytterhoeven
2022-12-22 14:12 ` Geert Uytterhoeven
2022-12-22 14:12 ` Geert Uytterhoeven
2022-12-22 14:12 ` Geert Uytterhoeven
2022-12-22 14:12 ` Geert Uytterhoeven
2022-12-22 14:12 ` [Intel-gfx] " Geert Uytterhoeven
2022-12-22 14:12 ` Geert Uytterhoeven
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 14:17 ` [Intel-gfx] " Andrzej Hajda
2022-12-22 14:17 ` Andrzej Hajda
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` [Intel-gfx] " Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-22 17:21 ` Andrew Morton
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` [Intel-gfx] " Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-23 14:23 ` Alexander Lobakin
2022-12-29 9:54 ` Andrzej Hajda
2022-12-29 9:54 ` Andrzej Hajda
2022-12-29 9:54 ` Andrzej Hajda
2022-12-29 9:54 ` Andrzej Hajda
2022-12-29 9:54 ` Andrzej Hajda
2022-12-29 9:54 ` [Intel-gfx] " Andrzej Hajda
2022-12-29 9:54 ` Andrzej Hajda
2023-01-05 16:29 ` Daniel Vetter
2023-01-05 16:29 ` Daniel Vetter
2023-01-05 16:29 ` Daniel Vetter
2023-01-05 16:29 ` Daniel Vetter
2023-01-05 16:29 ` Daniel Vetter
2023-01-05 16:29 ` [Intel-gfx] " Daniel Vetter
2023-01-05 16:29 ` Daniel Vetter
2023-01-10 10:53 ` [RFC DO NOT MERGE] treewide: use __xchg in most obvious places Andrzej Hajda
2023-01-10 10:53 ` Andrzej Hajda
2023-01-10 10:53 ` Andrzej Hajda
2023-01-10 10:53 ` Andrzej Hajda
2023-01-10 10:53 ` Andrzej Hajda
2023-01-10 10:53 ` [Intel-gfx] " Andrzej Hajda
2023-01-10 10:53 ` Andrzej Hajda
2023-01-10 11:07 ` Andy Shevchenko [this message]
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` Andy Shevchenko
2023-01-10 11:07 ` [Intel-gfx] " Andy Shevchenko
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 12:46 ` Andrzej Hajda
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` [Intel-gfx] " Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 13:52 ` Andy Shevchenko
2023-01-10 11:15 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for " Patchwork
2022-12-22 18:25 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce __xchg, non-atomic xchg Patchwork
2022-12-22 18:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-12-23 0:40 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-12-29 12:03 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce __xchg, non-atomic xchg (rev2) Patchwork
2022-12-29 12:23 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-12-30 14:32 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce __xchg, non-atomic xchg (rev3) Patchwork
2022-12-30 14:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-12-30 17:13 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y71G1tkmUzM4BLxn@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=andrzej.hajda@intel.com \
--cc=arnd@arndb.de \
--cc=boqun.feng@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=openrisc@lists.librecores.org \
--cc=peterz@infradead.org \
--cc=rodrigo.vivi@intel.com \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.