On 09/04/2018 22:08, David Rientjes wrote:
> On Mon, 9 Apr 2018, Christoph Hellwig wrote:
>
>>> -#ifdef __HAVE_ARCH_PTE_SPECIAL
>>> +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
>>> # define HAVE_PTE_SPECIAL 1
>>> #else
>>> # define HAVE_PTE_SPECIAL 0
>>
>> I'd say kill this odd indirection and just use
Remove the additional define HAVE_PTE_SPECIAL and rely directly on
CONFIG_ARCH_HAS_PTE_SPECIAL.
There is no functional change introduced by this patch
Signed-off-by: Laurent Dufour
---
mm/memory.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/mm/m
Currently the PTE special supports is turned on in per architecture header
files. Most of the time, it is defined in arch/*/include/asm/pgtable.h
depending or not on some other per architecture static definition.
This patch introduce a new configuration variable to manage this directly
in the Kcon
The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the
per architecture header files. This doesn't allow to make other
configuration dependent on it.
The first patch of this series is replacing __HAVE_ARCH_PTE_SPECIAL by
CONFIG_ARCH_HAS_PTE_SPECIAL defined into the Kconfig files
On 10/04/18 16:25, Laurent Dufour wrote:
Remove the additional define HAVE_PTE_SPECIAL and rely directly on
CONFIG_ARCH_HAS_PTE_SPECIAL.
There is no functional change introduced by this patch
Signed-off-by: Laurent Dufour
---
mm/memory.c | 23 ++-
1 file changed, 10 inse
On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote:
> arch/powerpc/include/asm/pte-common.h | 3 ---
> arch/riscv/Kconfig | 1 +
> arch/s390/Kconfig | 1 +
You forgot to delete __HAVE_ARCH_PTE_SPE
On 10/04/2018 18:09, Matthew Wilcox wrote:
> On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote:
>> arch/powerpc/include/asm/pte-common.h | 3 ---
>> arch/riscv/Kconfig | 1 +
>> arch/s390/Kconfig
On 10/04/2018 17:58, Robin Murphy wrote:
> On 10/04/18 16:25, Laurent Dufour wrote:
>> Remove the additional define HAVE_PTE_SPECIAL and rely directly on
>> CONFIG_ARCH_HAS_PTE_SPECIAL.
>>
>> There is no functional change introduced by this patch
>>
>> Signed-off-by: Laurent Dufour
>> ---
>> m
Hello,
May we have
e89f5b370153 ("dma-mapping: Don't clear GFP_ZERO in dma_alloc_attrs")
back-ported to 4.16 kernel as it fixes:
57bf5a8 ("dma-mapping: clear harmful GFP_* flags in common code").
For more info about introduced problem see this thread:
http://lists.infradead.org/pipermail/linux-s
From: yuan linyu
then all arch boot parameter handled in the same way in start_kernel()
Signed-off-by: yuan linyu
---
arch/alpha/kernel/setup.c | 4 +---
arch/arc/kernel/setup.c| 5 +
arch/arm/kernel/setup.c| 7 +--
arch/arm64/kernel/setup.c
On Tue, 10 Apr 2018 09:09:32 PDT (-0700), wi...@infradead.org wrote:
On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote:
arch/powerpc/include/asm/pte-common.h | 3 ---
arch/riscv/Kconfig | 1 +
arch/s390/Kconfig
On Tue, 10 Apr 2018, Laurent Dufour wrote:
> > On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote:
> >> arch/powerpc/include/asm/pte-common.h | 3 ---
> >> arch/riscv/Kconfig | 1 +
> >> arch/s390/Kconfig
Hi Arnd,
On Tue, Dec 19, 2017 at 12:39:33PM +0100, Arnd Bergmann wrote:
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 5d595cfdb2c4..66cfdad68f7e 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -205,6 +205,15 @@
> #endif
>
13 matches
Mail list logo