Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

On Thu, Jan 31, 2019 at 08:07:29AM +0100, Christophe Leroy wrote: > > > Le 31/01/2019 à 07:44, Christophe Leroy a écrit : > > > > > >Le 31/01/2019 à 07:41, Mike Rapoport a écrit : > >>On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote: > >>> > >>> > >>>Le 21/01/2019 à 09:04, Mike

Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

Le 31/01/2019 à 07:44, Christophe Leroy a écrit : Le 31/01/2019 à 07:41, Mike Rapoport a écrit : On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote: Le 21/01/2019 à 09:04, Mike Rapoport a écrit : Add check for the return value of memblock_alloc*() functions and call

Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

Le 31/01/2019 à 07:41, Mike Rapoport a écrit : On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote: Le 21/01/2019 à 09:04, Mike Rapoport a écrit : Add check for the return value of memblock_alloc*() functions and call panic() in case of error. The panic message repeats the one

Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote: > > > Le 21/01/2019 à 09:04, Mike Rapoport a écrit : > >Add check for the return value of memblock_alloc*() functions and call > >panic() in case of error. > >The panic message repeats the one used by panicing memblock allocators

Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

Le 21/01/2019 à 09:04, Mike Rapoport a écrit : Add check for the return value of memblock_alloc*() functions and call panic() in case of error. The panic message repeats the one used by panicing memblock allocators with adjustment of parameters to include only relevant ones. The replacement

Re: [PATCH v2 05/15] ARC: Atomics and Locking primitives

On Wed, 30 Jan 2019, Vineet Gupta wrote: > On 1/30/19 1:50 PM, Joseph Myers wrote: > >>> This seems like something that could be a common issue for new ports, so > >>> worth a mention at alongside > >>> such things as using init_array and

Re: [PATCH v2 05/15] ARC: Atomics and Locking primitives

On 1/30/19 1:50 PM, Joseph Myers wrote: >>> This seems like something that could be a common issue for new ports, so >>> worth a mention at alongside >>> such things as using init_array and USE_ATOMIC_COMPILER_BUILTINS. >> Updated wiki page ! > Now

Re: [PATCH v2 05/15] ARC: Atomics and Locking primitives

On Wed, 30 Jan 2019, Vineet Gupta wrote: > On 1/30/19 1:04 PM, Joseph Myers wrote: > >>> +#define __PTHREAD_MUTEX_NUSERS_AFTER_KIND 1 > >>> +#define __PTHREAD_MUTEX_USE_UNION 1 > >> New ports should use the preferred values for these macros. > > This seems like something that could be a

Re: [PATCH v2 05/15] ARC: Atomics and Locking primitives

On 1/30/19 1:04 PM, Joseph Myers wrote: >>> +#define __PTHREAD_MUTEX_NUSERS_AFTER_KIND 1 >>> +#define __PTHREAD_MUTEX_USE_UNION 1 >> New ports should use the preferred values for these macros. > This seems like something that could be a common issue for new ports, so > worth a mention

Re: [PATCH v2 00/15] glibc port to ARC processors

On Wed, 30 Jan 2019, Vineet Gupta wrote: > Having said that, wheels were already set in motion after your initial > request in > December. The ARCv2 ABI spec was opened up quickly (and mea culpa for not > referencing it v2 submission). It is now publicly accessibly at [1] Thanks. To be clear,

Re: [PATCH v2 05/15] ARC: Atomics and Locking primitives

On Wed, 30 Jan 2019, Andreas Schwab wrote: > On Jan 29 2019, Vineet Gupta wrote: > > > +#define __PTHREAD_MUTEX_NUSERS_AFTER_KIND 1 > > +#define __PTHREAD_MUTEX_USE_UNION 1 > > New ports should use the preferred values for these macros. This seems like something that could be a

Re: [PATCH v2 00/15] glibc port to ARC processors

On 1/29/19 6:29 PM, Joseph Myers wrote: > In the absence of clear consensus regarding consideration of new ports to > undocumented architectures (which would need to result in consensus on > suitable rules on the subject to go in > ), and in the

Re: [PATCH v2 05/15] ARC: Atomics and Locking primitives

On 1/30/19 12:28 AM, Andreas Schwab wrote: > On Jan 29 2019, Vineet Gupta wrote: > >> +#define __PTHREAD_MUTEX_NUSERS_AFTER_KIND 1 >> +#define __PTHREAD_MUTEX_USE_UNION 1 > New ports should use the preferred values for these macros. OK, changed to 0 and 0 per commit 06be6368da16104

Re: [PATCH 2/5] ARCv2: introduce unaligned access under a Kconfig option

On 1/30/19 8:44 AM, Eugeniy Paltsev wrote: >> I'd prefer to change the define of STATUS_AD_MASK itself and keep all of this >> unchanged ! >> > Actually I'd prefer to leave STATUS_AD_MASK untouched. Otherwise we will > implicitly assign > wrong value to STATUS_AD_MASK which is quite misleading. >

Re: [PATCH 2/5] ARCv2: introduce unaligned access under a Kconfig option

On Tue, 2019-01-29 at 21:44 +, Vineet Gupta wrote: > On 1/29/19 2:49 AM, Eugeniy Paltsev wrote: > > As of today we enable unaligned access unconditionally on ARCv2. > > Lets move it under Kconfig option so we can disable it in case of > > using HW configuration which lacks of it. > > > >

[PATCH v2 5/5] ARC: boot log: print unaligned memory access details

This now prints both HW feature status (exists, enabled / disabled) and SW status (used / not used). Signed-off-by: Eugeniy Paltsev --- arch/arc/kernel/setup.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c

[PATCH v2 4/5] ARCv2: LIB: MEMCPY: fixed and optimised routine

Optimise code to use efficient unaligned memory access which is available on ARCv2. This allows us to really simplify memcpy code and speed up the code one and a half times (in case of unaligned source or destination). Signed-off-by: Eugeniy Paltsev --- arch/arc/lib/Makefile |

[PATCH v2 2/5] ARCv2: introduce unaligned access under a Kconfig option

As of today we enable unaligned access unconditionally on ARCv2. Lets move it under Kconfig option so we can disable it in case of using HW configuration which lacks of it. Signed-off-by: Eugeniy Paltsev --- arch/arc/Kconfig | 8

[PATCH v2 1/5] ARCv2: lib: memcpy: fix doing prefetchw outside of buffer

ARCv2 optimized memcpy uses PREFETCHW instruction for prefetching the next cache line but doesn't ensure that the line is not past the end of the buffer. PRETECHW changes the line ownership and marks it dirty, which can cause data corruption if this area is used for DMA IO. Fix the issue by

[PATCH v2 0/5] introduce unaligned access under a Kconfig option

As of today we enable unaligned access unconditionally on ARCv2. Lets move it under Kconfig option and use it actively in SW if it is enabled. While I'm at it fix and optimise ARCv2 memcpy implementaion. Changes v1->v2: * Rebase onto last ARC changes. * Don't add dummy symbol to ARC Kconfig *

[PATCH v2 3/5] ARCv2: use unaligned access in SW

Select HAVE_EFFICIENT_UNALIGNED_ACCESS and allow GCC to generate unaligned data if we enable enable unaligned access in HW. Signed-off-by: Eugeniy Paltsev --- arch/arc/Kconfig | 1 + arch/arc/Makefile | 6 ++ 2 files changed, 7 insertions(+) diff --git a/arch/arc/Kconfig

Re: [PATCH v2 21/21] memblock: drop memblock_alloc_*_nopanic() variants

On Mon 2019-01-21 10:04:08, Mike Rapoport wrote: > As all the memblock allocation functions return NULL in case of error > rather than panic(), the duplicates with _nopanic suffix can be removed. > > Signed-off-by: Mike Rapoport > Acked-by: Greg Kroah-Hartman > --- > arch/arc/kernel/unwind.c

Re: [PATCH v2 05/15] ARC: Atomics and Locking primitives

On Jan 29 2019, Vineet Gupta wrote: > +#define __PTHREAD_MUTEX_NUSERS_AFTER_KIND 1 > +#define __PTHREAD_MUTEX_USE_UNION 1 New ports should use the preferred values for these macros. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE