* Re: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Mark Rutland @ 2019-08-14 16:03 UTC (permalink / raw)
To: Will Deacon, Andrey Ryabinin
Cc: crecklin, ard.biesheuvel, catalin.marinas, bhsharma, Steve Capper,
maz, linux-arm-kernel
In-Reply-To: <20190814155711.ldwot7ezrrqjlswc@willie-the-truck>
On Wed, Aug 14, 2019 at 04:57:11PM +0100, Will Deacon wrote:
> On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> > On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > > index b2400f9c1213..2b7db0d41498 100644
> > > --- a/arch/arm64/Makefile
> > > +++ b/arch/arm64/Makefile
> > > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > >
> > > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > > -# in 32-bit arithmetic
> > > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > > -
> > > export TEXT_OFFSET GZFLAGS
> > >
> > > core-y += arch/arm64/kernel/ arch/arm64/mm/
> >
> > I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> > CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> > CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> > CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> > regardless.
> >
> > I think that's by accident rather than by design, but to
> > minimize/localize the fixup, how about the below? I can send a cleanup
> > patch for scripts/Makefile.kasan later.
>
> How much work is that? I've dropped this stuff from -next for now, so we
> have time to fix it properly as long as it's not going to take weeks.
I wrote it first, so no effort; patch below.
Andrey, would you be happy with this?
Thanks,
Mark.
---->8----
From ecdf60051a850f817d98f84ae9011afa2311b8f1 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Wed, 14 Aug 2019 15:31:57 +0100
Subject: [PATCH] kasan/arm64: fix CONFIG_KASAN_SW_TAGS && KASAN_INLINE
The generic Makefile.kasan propagates CONFIG_KASAN_SHADOW_OFFSET into
KASAN_SHADOW_OFFSET, but only does so for CONFIG_KASAN_GENERIC.
Since commit:
6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
... arm64 defines CONFIG_KASAN_SHADOW_OFFSET in Kconfig rather than
defining KASAN_SHADOW_OFFSET in a Makefile. Thus, if
CONFIG_KASAN_SW_TAGS && KASAN_INLINE are selected, we get build time
splats due to KASAN_SHADOW_OFFSET not being set:
| [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang
| scripts/kconfig/conf --syncconfig Kconfig
| CC scripts/mod/empty.o
| clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument!
| scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed
| make[1]: *** [scripts/mod/empty.o] Error 1
| Makefile:1123: recipe for target 'prepare0' failed
| make: *** [prepare0] Error 2
Let's fix this by always propagating CONFIG_KASAN_SHADOW_OFFSET into
KASAN_SHADOW_OFFSET if CONFIG_KASAN is selected, moving the existing
common definition of +CFLAGS_KASAN_NOSANITIZE to the top of
Makefile.kasan.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
---
scripts/Makefile.kasan | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 6410bd22fe38..03757cc60e06 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -1,4 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
+ifdef CONFIG_KASAN
+CFLAGS_KASAN_NOSANITIZE := -fno-builtin
+KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
+endif
+
ifdef CONFIG_KASAN_GENERIC
ifdef CONFIG_KASAN_INLINE
@@ -7,8 +12,6 @@ else
call_threshold := 0
endif
-KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
-
CFLAGS_KASAN_MINIMAL := -fsanitize=kernel-address
cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
@@ -45,7 +48,3 @@ CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
$(instrumentation_flags)
endif # CONFIG_KASAN_SW_TAGS
-
-ifdef CONFIG_KASAN
-CFLAGS_KASAN_NOSANITIZE := -fno-builtin
-endif
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: Best representation for TDM devices
From: Mark Brown @ 2019-08-14 16:02 UTC (permalink / raw)
To: Ali Burak Parım; +Cc: maxime.ripard, linux-arm-kernel
In-Reply-To: <CAMTEBE2L6KXH6JW2Z_6RSKdtFJc9ncFvfakwW_Vm88BCGC6aeQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1458 bytes --]
On Wed, Aug 14, 2019 at 12:53:24PM +0200, Ali Burak Parım wrote:
> On Thu, 1 Aug 2019 at 13:48, Mark Brown <broonie@kernel.org> wrote:
> > On Thu, Aug 01, 2019 at 01:43:06PM +0200, Ali Burak Parım wrote:
> > > On Thu, Jul 25, 2019 at 03:01:12PM +0200, Maxime Ripard wrote:
> > > Hardware is a custom board I designed with 4 PDM output microphones
> > > and 2 adau7002 devices as the codec for PDM-to-PCM. We want to do
> > > signal processing with this board. Therefore having separate streams for
> > > each microphone is crucial to the application though I am not sure where
> > > we should implement this exactly.
> > What is this processing - are the streams from these microphones
> > logically related in any way (eg, is this a microphone array)? There's
> Yes, it is a microphone array application for speech enhancement. Thus,
> signal levels and physical time delays are important.
> > probably going to be some overlap in the input signals at least. If you
> > need to for example correlate different microphones then that's
> > relevant.
> Yes, we correlate different microphone signals in some of our algorithms.
OK, in that case I'd recommend providing them to userspace as a single
four channel stream - keeping everything bundled together as long as
possible to make it easier to keep the processing synced up.
> P.S.: I am so sorry for late reply, the thread went to my junk box somehow.
No problem.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Will Deacon @ 2019-08-14 15:57 UTC (permalink / raw)
To: Mark Rutland
Cc: crecklin, ard.biesheuvel, catalin.marinas, bhsharma, Steve Capper,
maz, linux-arm-kernel
In-Reply-To: <20190814152017.GD51963@lakrids.cambridge.arm.com>
On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index b2400f9c1213..2b7db0d41498 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> >
> > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > -# in 32-bit arithmetic
> > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > -
> > export TEXT_OFFSET GZFLAGS
> >
> > core-y += arch/arm64/kernel/ arch/arm64/mm/
>
> I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> regardless.
>
> I think that's by accident rather than by design, but to
> minimize/localize the fixup, how about the below? I can send a cleanup
> patch for scripts/Makefile.kasan later.
How much work is that? I've dropped this stuff from -next for now, so we
have time to fix it properly as long as it's not going to take weeks.
> ---->8----
> From b1a6f2dd5aa30d874c4bd97a20ea1330607da624 Mon Sep 17 00:00:00 2001
> From: Mark Rutland <mark.rutland@arm.com>
> Date: Wed, 14 Aug 2019 15:51:14 +0100
> Subject: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE
>
> Since commit:
>
> 6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
>
> ... attempting to build with CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE
> results ins splat:
>
> | [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang
> | scripts/kconfig/conf --syncconfig Kconfig
> | CC scripts/mod/empty.o
> | clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument!
> | scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed
> | make[1]: *** [scripts/mod/empty.o] Error 1
> | Makefile:1123: recipe for target 'prepare0' failed
> | make: *** [prepare0] Error 2
>
> ... since Makefile.kasan only consumes CONFIG_KASAN_SHADOW_OFFSET when
> CONFIG_KASAN_GENERIC is selected, and for CONFIG_KASAN_SW_TAGS it consumes
> KASAN_SHADOW_OFFSET (without a CONFIG_ prefix).
>
> For the moment, let's always propagate CONFIG_KASAN_SHADOW_OFFSET into
> KASAN_SHADOW_OFFSET via the arm64 Makefile. We can clean up the generic kasan
> Makefile later down the line.
>
> Fixes: 6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
> arch/arm64/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index a8d2a241ac58..a0c733f93b5b 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -126,6 +126,8 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
>
> +KASAN_SHADOW_OFFSET := $(CONFIG_KASAN_SHADOW_OFFSET)
This needs a comment explaining what it's doing and that it's a dirty,
temporary hack.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device
From: Robin Murphy @ 2019-08-14 15:49 UTC (permalink / raw)
To: Christoph Hellwig, Greg Kroah-Hartman, Maxime Chevallier
Cc: linux-arch, Gavin Li, Pengutronix Kernel Team, Mathias Nyman,
Geoff Levand, Olav Kongas, Sascha Hauer, linux-usb, Michal Simek,
linux-kernel, Tony Prisk, iommu, Alan Stern, NXP Linux Team,
Fabio Estevam, Minas Harutyunyan, Shawn Guo, linuxppc-dev,
Bin Liu, linux-arm-kernel
In-Reply-To: <20190811080520.21712-7-hch@lst.de>
On 11/08/2019 09:05, Christoph Hellwig wrote:
> We still treat devices without a DMA mask as defaulting to 32-bits for
> both mask, but a few releases ago we've started warning about such
> cases, as they require special cases to work around this sloppyness.
> Add a dma_mask field to struct platform_object so that we can initialize
s/object/device/
> the dma_mask pointer in struct device and initialize both masks to
> 32-bits by default. Architectures can still override this in
> arch_setup_pdev_archdata if needed.
>
> Note that the code looks a little odd with the various conditionals
> because we have to support platform_device structures that are
> statically allocated.
This would be a good point to also get rid of the long-standing bodge in
platform_device_register_full().
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/base/platform.c | 15 +++++++++++++--
> include/linux/platform_device.h | 1 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index ec974ba9c0c4..b216fcb0a8af 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -264,6 +264,17 @@ struct platform_object {
> char name[];
> };
>
> +static void setup_pdev_archdata(struct platform_device *pdev)
Bikeshed: painting the generic DMA API properties as "archdata" feels a
bit off-target :/
> +{
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dma_mask)
> + pdev->dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = &pdev->dma_mask;
> + arch_setup_pdev_archdata(pdev);
AFAICS m68k's implementation of that arch hook becomes entirely
redundant after this change, so may as well go. That would just leave
powerpc's actual archdata, which at a glance looks like it could
probably be cleaned up with not *too* much trouble.
Robin.
> +};
> +
> /**
> * platform_device_put - destroy a platform device
> * @pdev: platform device to free
> @@ -310,7 +321,7 @@ struct platform_device *platform_device_alloc(const char *name, int id)
> pa->pdev.id = id;
> device_initialize(&pa->pdev.dev);
> pa->pdev.dev.release = platform_device_release;
> - arch_setup_pdev_archdata(&pa->pdev);
> + setup_pdev_archdata(&pa->pdev);
> }
>
> return pa ? &pa->pdev : NULL;
> @@ -512,7 +523,7 @@ EXPORT_SYMBOL_GPL(platform_device_del);
> int platform_device_register(struct platform_device *pdev)
> {
> device_initialize(&pdev->dev);
> - arch_setup_pdev_archdata(pdev);
> + setup_pdev_archdata(pdev);
> return platform_device_add(pdev);
> }
> EXPORT_SYMBOL_GPL(platform_device_register);
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 9bc36b589827..a2abde2aef25 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -24,6 +24,7 @@ struct platform_device {
> int id;
> bool id_auto;
> struct device dev;
> + u64 dma_mask;
> u32 num_resources;
> struct resource *resource;
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/7] dma: iop-adma: include prefetch.h
From: Arnd Bergmann @ 2019-08-14 15:29 UTC (permalink / raw)
To: Vinod Koul
Cc: kbuild test robot, open list:GPIO SUBSYSTEM, Linus Walleij,
Russell King, Linux Kernel Mailing List, Bartosz Golaszewski, soc,
Linux I2C, dmaengine, Dan Williams, Linux ARM
In-Reply-To: <20190813043324.GN12733@vkoul-mobl.Dlink>
On Tue, Aug 13, 2019 at 6:34 AM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 09-08-19, 18:33, Arnd Bergmann wrote:
> > Compile-testing this driver fails on m68k without the
> > extra header inclusion.
>
> Please change title to "dmaengine: iop-adma: include prefetch.h"
>
> After that:
>
> Acked-by: Vinod Koul <vkoul@kernel.org>
Ok, thanks!
One day I will remember all the subsystem prefixes. ;-)
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Mark Rutland @ 2019-08-14 15:20 UTC (permalink / raw)
To: Steve Capper, will
Cc: crecklin, ard.biesheuvel, catalin.marinas, bhsharma, maz,
linux-arm-kernel
In-Reply-To: <20190807155524.5112-4-steve.capper@arm.com>
Hi Steve,
On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> +config KASAN_SHADOW_OFFSET
> + hex
> + depends on KASAN
> + default 0xdfffa00000000000 if (ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52) && !KASAN_SW_TAGS
> + default 0xdfffd00000000000 if ARM64_VA_BITS_47 && !KASAN_SW_TAGS
> + default 0xdffffe8000000000 if ARM64_VA_BITS_42 && !KASAN_SW_TAGS
> + default 0xdfffffd000000000 if ARM64_VA_BITS_39 && !KASAN_SW_TAGS
> + default 0xdffffffa00000000 if ARM64_VA_BITS_36 && !KASAN_SW_TAGS
> + default 0xefff900000000000 if (ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52) && KASAN_SW_TAGS
> + default 0xefffc80000000000 if ARM64_VA_BITS_47 && KASAN_SW_TAGS
> + default 0xeffffe4000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS
> + default 0xefffffc800000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS
> + default 0xeffffff900000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS
> + default 0xffffffffffffffff
> +
> source "arch/arm64/Kconfig.platforms"
>
> menu "Kernel Features"
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index b2400f9c1213..2b7db0d41498 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
>
> -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> -# in 32-bit arithmetic
> -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> -
> export TEXT_OFFSET GZFLAGS
>
> core-y += arch/arm64/kernel/ arch/arm64/mm/
I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
regardless.
I think that's by accident rather than by design, but to
minimize/localize the fixup, how about the below? I can send a cleanup
patch for scripts/Makefile.kasan later.
Build and boot tested with CONFIG_KASAN_{SW_TAGS,GENERIC} and
VA_BITS_52 (on a 48-bit VA system).
Thanks,
Mark.
---->8----
From b1a6f2dd5aa30d874c4bd97a20ea1330607da624 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Wed, 14 Aug 2019 15:51:14 +0100
Subject: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE
Since commit:
6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
... attempting to build with CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE
results ins splat:
| [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang
| scripts/kconfig/conf --syncconfig Kconfig
| CC scripts/mod/empty.o
| clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument!
| scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed
| make[1]: *** [scripts/mod/empty.o] Error 1
| Makefile:1123: recipe for target 'prepare0' failed
| make: *** [prepare0] Error 2
... since Makefile.kasan only consumes CONFIG_KASAN_SHADOW_OFFSET when
CONFIG_KASAN_GENERIC is selected, and for CONFIG_KASAN_SW_TAGS it consumes
KASAN_SHADOW_OFFSET (without a CONFIG_ prefix).
For the moment, let's always propagate CONFIG_KASAN_SHADOW_OFFSET into
KASAN_SHADOW_OFFSET via the arm64 Makefile. We can clean up the generic kasan
Makefile later down the line.
Fixes: 6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index a8d2a241ac58..a0c733f93b5b 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -126,6 +126,8 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
+KASAN_SHADOW_OFFSET := $(CONFIG_KASAN_SHADOW_OFFSET)
+
export TEXT_OFFSET GZFLAGS
core-y += arch/arm64/kernel/ arch/arm64/mm/
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/8] arm64: memory: Fix virt_addr_valid() using __is_lm_address()
From: Ard Biesheuvel @ 2019-08-14 15:17 UTC (permalink / raw)
To: Steve Capper
Cc: Mark Rutland, Catalin Marinas, Qian Cai, Andrey Konovalov,
Geert Uytterhoeven, nd, Will Deacon, linux-arm-kernel
In-Reply-To: <20190813203412.GA22563@capper-ampere.manchester.arm.com>
On Tue, 13 Aug 2019 at 23:34, Steve Capper <Steve.Capper@arm.com> wrote:
>
> On Tue, Aug 13, 2019 at 10:25:14PM +0300, Ard Biesheuvel wrote:
> > On Tue, 13 Aug 2019 at 22:11, Steve Capper <Steve.Capper@arm.com> wrote:
> > >
> > > Hi Ard,
> > >
> > > On Tue, Aug 13, 2019 at 09:09:16PM +0300, Ard Biesheuvel wrote:
> > > > On Tue, 13 Aug 2019 at 20:02, Will Deacon <will@kernel.org> wrote:
> > > > >
> > > > > virt_addr_valid() is intended to test whether or not the passed address
> > > > > is a valid linear map address. Unfortunately, it relies on
> > > > > _virt_addr_is_linear() which is broken because it assumes the linear
> > > > > map is at the top of the address space, which it no longer is.
> > > > >
> > > > > Reimplement virt_addr_valid() using __is_lm_address() and remove
> > > > > _virt_addr_is_linear() entirely. At the same time, ensure we evaluate
> > > > > the macro parameter only once and move it within the __ASSEMBLY__ block.
> > > > >
> > > > > Reported-by: Qian Cai <cai@lca.pw>
> > > > > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > Fixes: 14c127c957c1 ("arm64: mm: Flip kernel VA space")
> > > > > Signed-off-by: Will Deacon <will@kernel.org>
> > > > > ---
> > > > > arch/arm64/include/asm/memory.h | 14 +++++++-------
> > > > > 1 file changed, 7 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > > > index afaf512c0e1b..442ab861cab8 100644
> > > > > --- a/arch/arm64/include/asm/memory.h
> > > > > +++ b/arch/arm64/include/asm/memory.h
> > > > > @@ -244,9 +244,9 @@ static inline const void *__tag_set(const void *addr, u8 tag)
> > > > > /*
> > > > > * The linear kernel range starts in the middle of the virtual adddress
> > > > > * space.
> > > >
> > > > This is no longer true either.
> > > >
> > >
> > > Whoops agreed.
> > >
> > > > > Testing the top bit for the start of the region is a
> > > > > - * sufficient check.
> > > > > + * sufficient check and avoids having to worry about the tag.
> > > > > */
> > > > > -#define __is_lm_address(addr) (!((addr) & BIT(vabits_actual - 1)))
> > > > > +#define __is_lm_address(addr) (!(((u64)addr) & BIT(vabits_actual - 1)))
> > > > >
> > > >
> > > > ... and this assumes that the VA space is split evenly between linear
> > > > and vmalloc/vmemmap/etc, which is no longer true when running with
> > > > 52-bit VAs
> > > >
> > >
> > > For 52-bit VAs we have two possibilities:
> > > Start End Size Use
> > > -----------------------------------------------------------------------
> > > 0000000000000000 000fffffffffffff 4PB user
> > > fff0000000000000 fff7ffffffffffff 2PB kernel logical memory map
> > > fff8000000000000 fffd9fffffffffff 1440TB [gap]
> >
> > Right. I missed the part where we throw away 1/3 of the VA space:
> > IIRC, the idea was that keeping the size of the upper half of the
> > 48-bit VA space fixed for 52-bit not only allowed compile time
> > constant addresses to be used for many of the things that populate it,
> > it also makes a lot more VA space available to the linear region,
> > which is where we need it the most.
> >
> > > fffda00000000000 ffff9fffffffffff 512TB kasan shadow region
> > >
> > > and
> > > Start End Size Use
> > > -----------------------------------------------------------------------
> > > 0000000000000000 0000ffffffffffff 256TB user
> > > ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
> > > ffff800000000000 ffff9fffffffffff 32TB kasan shadow region
> > > ffffa00000000000 ffffa00007ffffff 128MB bpf jit region
> > >
> > > IIUC the definition for __is_lm_address is correct for these cases?
> > > (it's based off vabits_actual).
> > >
> >
> > With the gap taken into account, it is correct. But throwing away 1440
> > TB of address space seems suboptimal to me.
>
> When getting the 52-bit kernel VA support ready, I was trying to achieve
> functional and performant support in as few steps as possible to avoid risk of
> breaking things (unfortunately I missed a couple of things between
> rebases with the SW KASAN). The big gain from that series is support for
> a much larger linear mapping.
>
Sure.
> The best way I can think of to get rid of the gap is to use it for
> vmalloc space which means changes to VMALLOC_START and VMALLOC_END. I
> think it would be better to make this change incrementally and I'm more
> than happy to get hacking on a patch. Or maybe there's a better use for
> the gap in other areas...
>
Given that it is only the MMU hardware that is preventing us from
running a 52-bit VA kernel on 48-bit VA hardware, I still don't follow
100% why we have all these moving parts. If we start the address space
at 0xfff0_... and start the vmalloc/vmemmap/etc space at 0xffff_8....
(and make sure the vmemmap space is sized so it can cover the entire
span), all we should need to do is make sure we don't map any memory
below 0xffff_0... if the hardware does not support that. I don't think
there is any need to make the start of physical memory coincide with
the lowest kernel VA supported by the hardware, or have other variable
quantities that assume different values based on the actual h/w
config.
[Apologies for not bringing this up earlier. I am not actually working atm :-)]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] coresight: Serialize enabling/disabling a link device.
From: Mathieu Poirier @ 2019-08-14 15:04 UTC (permalink / raw)
To: Yabin Cui
Cc: Alexander Shishkin, Linux Kernel Mailing List, linux-arm-kernel,
Suzuki K Poulose
In-Reply-To: <20190814003557.97004-1-yabinc@google.com>
On Tue, 13 Aug 2019 at 18:36, Yabin Cui <yabinc@google.com> wrote:
>
> > The patch isn't difficult to do but does go deeper in each link
> > drivers (ETF, funnel, replicator). Let me know if you are not
> > comfortable with the idea and I will see what I can do on my side.
>
> I am comfortable with the idea. I chose to add lock in coresight_enable_link() just because it
> is the smallest change. But a refactor probably is better for maintainance.
Yes, that is my prime concern.
>
> Feel free to upload a new patch fixing the problem. I can help to test it.
I have a few things on my plate at this time so you might beat me to
the punch. I'll see how the next few days go.
Mathieu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] Re: [PATCH v2 06/15] drm/mxsfb: Update mxsfb with additional pixel formats
From: Robert Chiras @ 2019-08-14 14:58 UTC (permalink / raw)
To: daniel@fooishbar.org
Cc: marex@denx.de, devicetree@vger.kernel.org, s.hauer@pengutronix.de,
dri-devel@lists.freedesktop.org, airlied@linux.ie,
shawnguo@kernel.org, agx@sigxcpu.org,
linux-kernel@vger.kernel.org, stefan@agner.ch, robh+dt@kernel.org,
dl-linux-imx, daniel@ffwll.ch, mark.rutland@arm.com,
festevam@gmail.com, kernel@pengutronix.de,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAPj87rMFG=RGmfVnawbE7qX4zU7vdYxLJB__K4E3B8jcJ764KQ@mail.gmail.com>
Hi Daniel,
On Mi, 2019-08-14 at 12:44 +0100, Daniel Stone wrote:
> Hi Robert,
>
> On Wed, 14 Aug 2019 at 11:49, Robert Chiras <robert.chiras@nxp.com>
> wrote:
> >
> > + case DRM_FORMAT_BGR565: /* BG16 */
> > + if (mxsfb->devdata->ipversion < 4)
> > + goto err;
> > + writel(CTRL2_ODD_LINE_PATTERN(CTRL2_LINE_PATTERN_BG
> > R) |
> > + CTRL2_EVEN_LINE_PATTERN(CTRL2_LINE_PATTERN_
> > BGR),
> > + mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
> > + /* Fall through */
> > + case DRM_FORMAT_RGB565: /* RG16 */
> > + ctrl |= CTRL_SET_WORD_LENGTH(0);
> > + ctrl &= ~CTRL_DF16;
> > + ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
> > + break;
> For non-BGR formats, do you need to write RGB line-pattern back to
> the
> CTRL2 register? Otherwise, if you start with BGR565 then switch back
> to RGB565, presumably CTRL2 would still be programmed for BGR so you
> would display inverted channels.
The LINE_PATTERN from LCDC_V4_CTRL2 register is cleared above, with
this code:
+ if (mxsfb->devdata->ipversion >= 4)
+ writel(CTRL2_ODD_LINE_PATTERN(CTRL2_LINE_PATTERN_CLR) |
+ CTRL2_EVEN_LINE_PATTERN(CTRL2_LINE_PATTERN_CLR),
+ mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
>
> Same goes for all the other BGR/RGB format pairs below.
>
> Cheers,
> Daniel
Thanks,
Robert
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Regression in Linux next with show wakeup sources stats in sysfs
From: Stephen Boyd @ 2019-08-14 14:56 UTC (permalink / raw)
To: Tony Lindgren
Cc: Tri Vo, linux-pm, Greg Kroah-Hartman, Rafael J. Wysocki,
linux-kernel, Sebastian Reichel, Kalesh Singh, linux-omap,
linux-arm-kernel
In-Reply-To: <20190814073234.GZ52127@atomide.com>
Quoting Tony Lindgren (2019-08-14 00:32:34)
> * Stephen Boyd <swboyd@chromium.org> [190814 07:09]:
> > Quoting Tony Lindgren (2019-08-13 23:38:03)
> > > Hi all,
> > >
> > > Looks like commit 986845e747af ("PM / wakeup: Show wakeup sources stats
> > > in sysfs") has caused a regression in Linux next where I can now get
> > > some errors like this during the boot:
> > >
> > > kobject_add_internal failed for wakeup10 (error: -2 parent: usb)
> > >
> > > Any ideas why this might be happening? Maybe some deferred probe
> > > related issue?
> > >
> >
> > Yeah! Take a look at this thread[1] and please test out patches I'm
> > throwing out there like a total cowboy(d).
> >
> > [1] https://lkml.kernel.org/r/1565731976.8572.16.camel@lca.pw
>
> Oh OK thanks, looks like I'm a bit behind then. My test case turned
> out to be caused by device_init_wakeup() called before device_add() for
> power_supply in case that helps. In that case create_dir() will fail
> for kobject_add_internal(). Doing something like below fixes the
> issue, but seems like we probably have other similar issues as well.
> Adding Sebastian to Cc in case this might be a real problem despite
> the other issues.
>
Ah yeah. I sent a patch for power supply earlier[2], but now I'm
thinking that it would be better to take the approach in the thread I
mentioned where we just don't add sysfs stuff until when device_add() is
called.
[2] https://lkml.kernel.org/r/20190801213330.81079-1-swboyd@chromium.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [UNVERIFIED SENDER] Re: [PATCH 0/9] arm64: Stolen time support
From: Alexander Graf @ 2019-08-14 14:52 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, linux-doc, Catalin Marinas, linux-kernel, Russell King,
Paolo Bonzini, Steven Price, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <8636i3omnd.wl-maz@kernel.org>
On 14.08.19 16:19, Marc Zyngier wrote:
> On Wed, 14 Aug 2019 14:02:25 +0100,
> Alexander Graf <graf@amazon.com> wrote:
>>
>>
>>
>> On 05.08.19 15:06, Steven Price wrote:
>>> On 03/08/2019 19:05, Marc Zyngier wrote:
>>>> On Fri, 2 Aug 2019 15:50:08 +0100
>>>> Steven Price <steven.price@arm.com> wrote:
>>>>
>>>> Hi Steven,
>>>>
>>>>> This series add support for paravirtualized time for arm64 guests and
>>>>> KVM hosts following the specification in Arm's document DEN 0057A:
>>>>>
>>>>> https://developer.arm.com/docs/den0057/a
>>>>>
>>>>> It implements support for stolen time, allowing the guest to
>>>>> identify time when it is forcibly not executing.
>>>>>
>>>>> It doesn't implement support for Live Physical Time (LPT) as there are
>>>>> some concerns about the overheads and approach in the above
>>>>> specification, and I expect an updated version of the specification to
>>>>> be released soon with just the stolen time parts.
>>>>
>>>> Thanks for posting this.
>>>>
>>>> My current concern with this series is around the fact that we allocate
>>>> memory from the kernel on behalf of the guest. It is the first example
>>>> of such thing in the ARM port, and I can't really say I'm fond of it.
>>>>
>>>> x86 seems to get away with it by having the memory allocated from
>>>> userspace, why I tend to like more. Yes, put_user is more
>>>> expensive than a straight store, but this isn't done too often either.
>>>>
>>>> What is the rational for your current approach?
>>>
>>> As I see it there are 3 approaches that can be taken here:
>>>
>>> 1. Hypervisor allocates memory and adds it to the virtual machine. This
>>> means that everything to do with the 'device' is encapsulated behind the
>>> KVM_CREATE_DEVICE / KVM_[GS]ET_DEVICE_ATTR ioctls. But since we want the
>>> stolen time structure to be fast it cannot be a trapping region and has
>>> to be backed by real memory - in this case allocated by the host kernel.
>>>
>>> 2. Host user space allocates memory. Similar to above, but this time
>>> user space needs to manage the memory region as well as the usual
>>> KVM_CREATE_DEVICE dance. I've no objection to this, but it means
>>> kvmtool/QEMU needs to be much more aware of what is going on (e.g. how
>>> to size the memory region).
>>
>> You ideally want to get the host overhead for a VM to as little as you
>> can. I'm not terribly fond of the idea of reserving a full page just
>> because we're too afraid of having the guest donate memory.
>
> Well, reduce the amount of memory you give to the guest by one page,
> and allocate that page to the stolen time device. Problem solved!
>
> Seriously, if you're worried about the allocation of a single page,
> you should first look at how many holes we have in the vcpu structure,
> for example (even better, with the 8.4 NV patches applied). Just
> fixing that would give you that page back *per vcpu*.
I'm worried about additional memory slots, about fragmenting the
cachable guest memory regions, about avoidable HV taxes.
I think we need to distinguish here between the KVM implementation and
the hypervisor/guest interface. Just because in KVM we can save overhead
today doesn't mean that the HV interface should be built around the
assumption that "memory is free".
>
>>> 3. Guest kernel "donates" the memory to the hypervisor for the
>>> structure. As far as I'm aware this is what x86 does. The problems I see
>>> this approach are:
>>>
>>> a) kexec becomes much more tricky - there needs to be a disabling
>>> mechanism for the guest to stop the hypervisor scribbling on memory
>>> before starting the new kernel.
>>
>> I wouldn't call "quiesce a device" much more tricky. We have to do
>> that for other devices as well today.
>
> And since there is no standard way of doing it, we keep inventing
> weird and wonderful ways of doing so -- cue the terrible GICv3 LPI
> situation, and all the various hacks to keep existing IOMMU mappings
> around across firmware/kernel handovers as well as kexec.
Well, the good news here is that we don't have to keep it around ;).
>
>>
>>> b) If there is more than one entity that is interested in the
>>> information (e.g. firmware and kernel) then this requires some form of
>>> arbitration in the guest because the hypervisor doesn't want to have to
>>> track an arbitrary number of regions to update.
>>
>> Why would FW care?
>
> Exactly. It doesn't care. Not caring means it doesn't know about the
> page the guest has allocated for stolen time, and starts using it for
> its own purposes. Hello, memory corruption. Same thing goes if you
> reboot into a non stolen time aware kernel.
If you reboot, you go via the vcpu reset path which clears the map, no?
Same goes for FW entry. If you enter firmware that does not set up the
map, you never see it.
>
>>
>>> c) Performance can suffer if the host kernel doesn't have a suitably
>>> aligned/sized area to use. As you say - put_user() is more expensive.
>>
>> Just define the interface to always require natural alignment when
>> donating a memory location?
>>
>>> The structure is updated on every return to the VM.
>>
>> If you really do suffer from put_user(), there are alternatives. You
>> could just map the page on the registration hcall and then leave it
>> pinned until the vcpu gets destroyed again.
>
> put_user() should be cheap enough. It is one of the things we tend to
> optimise anyway. And yes, worse case, we pin the page.
>
>>
>>> Of course x86 does prove the third approach can work, but I'm not sure
>>> which is actually better. Avoid the kexec cancellation requirements was
>>> the main driver of the current approach. Although many of the
>>
>> I really don't understand the problem with kexec cancellation. Worst
>> case, let guest FW set it up for you and propagate only the address
>> down via ACPI/DT. That way you can mark the respective memory as
>> reserved too.
>
> We already went down that road with the LPI hack. I'm not going there
> again if we can avoid it. And it turn out that we can. Just allocate
> the stolen time page as a separate memblock, give it to KVM for that
> purpose.
>
> Your suggestion of letting the guest firmware set something up only
> works if whatever you're booting after that understands it. If it
> doesn't, you're screwed.
Why? For UEFI, mark the region as reserved in the memory map. For DT,
just mark it straight on reserved.
That said, I'm not advocating for doing it in the FW. I think this can
be solved really easily with a simple guest driver to enable and a vcpu
reset hook to disable the map.
>
>> But even with a Linux only mechanism, just take a look at
>> arch/x86/kernel/kvmclock.c. All they do to remove the map is to hook
>> into machine_crash_shutdown() and machine_shutdown().
>
> I'm not going to take something that is Linux specific. It has to work
> for all guests, at all times, whether they know about the hypervisor
> service or not.
If they don't know about the HV service, they don't register the writer,
so they don't see corruption.
If they know about the HV service and they don't support kexec, they
don't have to worry because a vcpu reset should also clear the map.
If they do support kexec, they already have a mechanism to quiesce devices.
So I don't understand how this is Linux specific? The question was Linux
specific, so I answered with precedence to show that disabling on kexec
is not all that hard :).
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] arm64: memory: VA_START fixups
From: Steve Capper @ 2019-08-14 14:51 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190814132848.24295-1-mark.rutland@arm.com>
On Wed, Aug 14, 2019 at 02:28:46PM +0100, Mark Rutland wrote:
> Hi all,
Hi Mark,
>
> These patches address my concerns with the new VA_START semantic as I
> spotted while reviewing Will's 52-bit VA cleanup. The first patch
> corrects the newly broken usage of VA_START, and the second renames
> VA_START to PAGE_END to make the new semantic clearer.
>
> Both patches are based on the arm64 for-next/52-bit-kva branch, and I've
> given a 52-bit VA configuration a build+boot test (on HW without 52-bit
> VA support).
>
A big thank you for this!
I have applied this series and tested it with CONFIG_DEBUG_VIRTUAL,
CONFIG_DEBUG_VM and KASAN SW TAGS.
I've tested this with 52-bit and have given the kernel page table dumper
a go too.
FWIW:
Tested-by: Steve Capper <steve.capper@arm.com>
Cheers,
--
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] arm64: memory: fix flipped VA space fallout
From: Steve Capper @ 2019-08-14 14:51 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190814132848.24295-2-mark.rutland@arm.com>
On Wed, Aug 14, 2019 at 02:28:47PM +0100, Mark Rutland wrote:
> VA_START used to be the start of the TTBR1 address space, but now it's a
> point midway though. In a couple of places we still use VA_START to get
> the start of the TTBR1 address space, so let's fix these up to use
> PAGE_OFFSET instead.
>
> Fixes: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: Will Deacon <will@kernel.org>
Reviewed-by: Steve Capper <steve.capper@arm.com>
> ---
> arch/arm64/mm/dump.c | 2 +-
> arch/arm64/mm/fault.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 6ec75305828e..8e10b4ba215a 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -400,7 +400,7 @@ void ptdump_check_wx(void)
> .check_wx = true,
> };
>
> - walk_pgd(&st, &init_mm, VA_START);
> + walk_pgd(&st, &init_mm, PAGE_OFFSET);
> note_page(&st, 0, 0, 0);
> if (st.wx_pages || st.uxn_pages)
> pr_warn("Checked W+X mappings: FAILED, %lu W+X pages found, %lu non-UXN pages found\n",
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 75eff57bd9ef..bb4e4f3fffd8 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -109,7 +109,7 @@ static inline bool is_ttbr0_addr(unsigned long addr)
> static inline bool is_ttbr1_addr(unsigned long addr)
> {
> /* TTBR1 addresses may have a tag if KASAN_SW_TAGS is in use */
> - return arch_kasan_reset_tag(addr) >= VA_START;
> + return arch_kasan_reset_tag(addr) >= PAGE_OFFSET;
> }
>
> /*
> --
> 2.11.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: memory: rename VA_START to PAGE_END
From: Steve Capper @ 2019-08-14 14:51 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190814132848.24295-3-mark.rutland@arm.com>
On Wed, Aug 14, 2019 at 02:28:48PM +0100, Mark Rutland wrote:
> Prior to commit:
>
> 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
>
> ... VA_START described the start of the TTBR1 address space for a given
> VA size described by VA_BITS, where all kernel mappings began.
>
> Since that commit, VA_START described a portion midway through the
> address space, where the linear map ends and other kernel mappings
> begin.
>
> To avoid confusion, let's rename VA_START to PAGE_END, making it clear
> that it's not the start of the TTBR1 address space and implying that
> it's related to PAGE_OFFSET. Comments and other mnemonics are updated
> accordingly, along with a typo fix in the decription of VMEMMAP_SIZE.
>
> There should be no functional change as a result of this patch.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: Will Deacon <will@kernel.org>
This looks a lot better, and avoids future use of "VA_START", thanks Mark!
Reviewed-by: Steve Capper <steve.capper@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 08/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
From: Will Deacon @ 2019-08-14 14:41 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, chao.hao, Joerg Roedel, linux-kernel, Evan Green,
Tomasz Figa, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
ming-fan.chen, anan.sun, Robin Murphy, Matthias Kaehlcke,
linux-arm-kernel
In-Reply-To: <1565423901-17008-9-git-send-email-yong.wu@mediatek.com>
Hi Yong Wu,
Sorry, but I'm still deeply confused by this patch.
On Sat, Aug 10, 2019 at 03:58:08PM +0800, Yong Wu wrote:
> MediaTek extend the arm v7s descriptor to support the dram over 4GB.
>
> In the mt2712 and mt8173, it's called "4GB mode", the physical address
> is from 0x4000_0000 to 0x1_3fff_ffff, but from EMI point of view, it
> is remapped to high address from 0x1_0000_0000 to 0x1_ffff_ffff, the
> bit32 is always enabled. thus, in the M4U, we always enable the bit9
> for all PTEs which means to enable bit32 of physical address. Here is
> the detailed remap relationship in the "4GB mode":
> CPU PA -> HW PA
> 0x4000_0000 0x1_4000_0000 (Add bit32)
> 0x8000_0000 0x1_8000_0000 ...
> 0xc000_0000 0x1_c000_0000 ...
> 0x1_0000_0000 0x1_0000_0000 (No change)
So in this example, there are no PAs below 0x4000_0000 yet you later
add code to deal with that:
> + /* Workaround for MTK 4GB Mode: Add BIT32 only when PA < 0x4000_0000.*/
> + if (cfg->oas == ARM_V7S_MTK_4GB_OAS && paddr < 0x40000000UL)
> + paddr |= BIT_ULL(32);
Why? Mainline currently doesn't do anything like this for the "4gb mode"
support as far as I can tell. In fact, we currently unconditionally set
bit 32 in the physical address returned by iova_to_phys() which wouldn't
match your CPU PAs listed above, so I'm confused about how this is supposed
to work.
The way I would like this quirk to work is that the io-pgtable code
basically sets bit 9 in the pte when bit 32 is set in the physical address,
and sets bit 4 in the pte when bit 33 is set in the physical address. It
would then do the opposite when converting a pte to a physical address.
That way, your driver can call the page table code directly with the high
addresses and we don't have to do any manual offsetting or range checking
in the page table code.
Please can you explain to me why the diff below doesn't work on top of
this series? I'm happy to chat on IRC if you think it would be easier,
because I have a horrible feeling that we've been talking past each other
and I'd like to see this support merged for 5.4.
Will
--->8
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index ab12ef5f8b03..d8d84617c822 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -184,7 +184,7 @@ static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT) {
- if ((paddr & BIT_ULL(32)) || cfg->oas == ARM_V7S_MTK_4GB_OAS)
+ if (paddr & BIT_ULL(32))
pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
if (paddr & BIT_ULL(33))
pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
@@ -206,17 +206,14 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
mask = ARM_V7S_LVL_MASK(lvl);
paddr = pte & mask;
- if (cfg->oas == 32 || !(cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT))
- return paddr;
- if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
- paddr |= BIT_ULL(33);
+ if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT) {
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
+ paddr |= BIT_ULL(32);
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
+ paddr |= BIT_ULL(33);
+ }
- /* Workaround for MTK 4GB Mode: Add BIT32 only when PA < 0x4000_0000.*/
- if (cfg->oas == ARM_V7S_MTK_4GB_OAS && paddr < 0x40000000UL)
- paddr |= BIT_ULL(32);
- else if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
- paddr |= BIT_ULL(32);
return paddr;
}
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d5b9454352fd..3ae54dedede0 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -286,7 +286,7 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom)
if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
dom->cfg.oas = 32;
else if (data->enable_4GB)
- dom->cfg.oas = ARM_V7S_MTK_4GB_OAS;
+ dom->cfg.oas = 33;
else
dom->cfg.oas = 34;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 27337395bd42..a2a52c349fe4 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -113,8 +113,6 @@ struct io_pgtable_cfg {
};
};
-#define ARM_V7S_MTK_4GB_OAS 33
-
/**
* struct io_pgtable_ops - Page table manipulation API for IOMMU drivers.
*
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 14/14] arm64: dts: meson: fix boards regulators states format
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxbb-odroidc2.dt.yaml: gpio-regulator-tf_io: states:0: Additional items are not allowed (1800000, 1 were unexpected)
meson-gxbb-odroidc2.dt.yaml: gpio-regulator-tf_io: states:0: [3300000, 0, 1800000, 1] is too long
meson-gxbb-nexbox-a95x.dt.yaml: gpio-regulator: states:0: Additional items are not allowed (3300000, 1 were unexpected)
meson-gxbb-nexbox-a95x.dt.yaml: gpio-regulator: states:0: [1800000, 0, 3300000, 1] is too long
meson-gxbb-p200.dt.yaml: gpio-regulator: states:0: Additional items are not allowed (3300000, 1 were unexpected)
meson-gxbb-p200.dt.yaml: gpio-regulator: states:0: [1800000, 0, 3300000, 1] is too long
meson-gxl-s905x-hwacom-amazetv.dt.yaml: gpio-regulator: states:0: Additional items are not allowed (3300000, 1 were unexpected)
meson-gxl-s905x-hwacom-amazetv.dt.yaml: gpio-regulator: states:0: [1800000, 0, 3300000, 1] is too long
meson-gxbb-p201.dt.yaml: gpio-regulator: states:0: Additional items are not allowed (3300000, 1 were unexpected)
meson-gxbb-p201.dt.yaml: gpio-regulator: states:0: [1800000, 0, 3300000, 1] is too long
meson-g12b-odroid-n2.dt.yaml: gpio-regulator-tf_io: states:0: Additional items are not allowed (1800000, 1 were unexpected)
meson-g12b-odroid-n2.dt.yaml: gpio-regulator-tf_io: states:0: [3300000, 0, 1800000, 1] is too long
meson-gxl-s905x-nexbox-a95x.dt.yaml: gpio-regulator: states:0: Additional items are not allowed (3300000, 1 were unexpected)
meson-gxl-s905x-nexbox-a95x.dt.yaml: gpio-regulator: states:0: [1800000, 0, 3300000, 1] is too long
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 4 ++--
.../arm64/boot/dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts | 4 ++--
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
index 81780ffcc7f0..dc35e2982c71 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
@@ -65,8 +65,8 @@
gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_HIGH>;
gpios-states = <0>;
- states = <3300000 0
- 1800000 1>;
+ states = <3300000 0>,
+ <1800000 1>;
};
flash_1v8: regulator-flash_1v8 {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index b636912a2715..afcf8a9f667b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -75,8 +75,8 @@
gpios-states = <1>;
/* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
- states = <1800000 0
- 3300000 1>;
+ states = <1800000 0>,
+ <3300000 1>;
};
vddio_boot: regulator-vddio_boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 9972b1515da6..6039adda12ee 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -77,8 +77,8 @@
gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
gpios-states = <0>;
- states = <3300000 0
- 1800000 1>;
+ states = <3300000 0>,
+ <1800000 1>;
};
vcc1v8: regulator-vcc1v8 {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index e8f925871edf..89f7b41b0e9e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -46,8 +46,8 @@
gpios-states = <1>;
/* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
- states = <1800000 0
- 3300000 1>;
+ states = <1800000 0>,
+ <3300000 1>;
regulator-settling-time-up-us = <10000>;
regulator-settling-time-down-us = <150000>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts
index 796baea7a0bf..c8d74e61dec1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts
@@ -38,8 +38,8 @@
gpios-states = <1>;
/* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
- states = <1800000 0
- 3300000 1>;
+ states = <1800000 0>,
+ <3300000 1>;
};
vddio_boot: regulator-vddio_boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
index 26907ac82930..c433a031841f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
@@ -38,8 +38,8 @@
gpios-states = <1>;
/* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
- states = <1800000 0
- 3300000 1>;
+ states = <1800000 0>,
+ <3300000 1>;
};
vddio_boot: regulator-vddio_boot {
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 13/14] arm64: dts: meson-gxbb-p201: fix snps, reset-delays-us format
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxbb-p201.dt.yaml: ethernet@c9410000: snps,reset-delays-us: [[0, 10000, 1000000]] is too short
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
index 56e0dd1ff55c..150a82f3b2d7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
@@ -21,6 +21,6 @@
phy-mode = "rmii";
snps,reset-gpio = <&gpio GPIOZ_14 0>;
- snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-delays-us = <0>, <10000>, <1000000>;
snps,reset-active-low;
};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 12/14] arm64: dts: meson-gxbb-nanopi-k2: add missing model
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: /: 'model' is a required property
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
index c34c1c90ccb6..1a36d2bd2d21 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
@@ -10,6 +10,7 @@
/ {
compatible = "friendlyarm,nanopi-k2", "amlogic,meson-gxbb";
+ model = "Nanopi K2";
aliases {
serial0 = &uart_AO;
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 11/14] arm64: dts: meson-g12a-x96-max: fix compatible
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-g12a-x96-max.dt.yaml: /: compatible: ['amediatech,x96-max', 'amlogic,u200', 'amlogic,g12a'] is not valid under any of the given schemas
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
index fe4013cca876..acb931cf3e7c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
@@ -11,7 +11,7 @@
#include <dt-bindings/sound/meson-g12a-tohdmitx.h>
/ {
- compatible = "amediatech,x96-max", "amlogic,u200", "amlogic,g12a";
+ compatible = "amediatech,x96-max", "amlogic,g12a";
model = "Shenzhen Amediatech Technology Co., Ltd X96 Max";
aliases {
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 10/14] arm64: dts: meson-g12a: fix reset controller compatible
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-g12a-u200.dt.yaml: reset-controller@1004: compatible:0: 'amlogic,meson-g12a-reset' is not one of ['amlogic,meson8b-reset', 'amlogic,meson-gxbb-reset', 'amlogic,meson-axg-reset']
meson-g12a-sei510.dt.yaml: reset-controller@1004: compatible:0: 'amlogic,meson-g12a-reset' is not one of ['amlogic,meson8b-reset', 'amlogic,meson-gxbb-reset', 'amlogic,meson-axg-reset']
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
index 465106d37289..74c587411306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
@@ -2215,8 +2215,7 @@
ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x100000>;
reset: reset-controller@1004 {
- compatible = "amlogic,meson-g12a-reset",
- "amlogic,meson-axg-reset";
+ compatible = "amlogic,meson-axg-reset";
reg = <0x0 0x1004 0x0 0x9c>;
#reset-cells = <1>;
};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 04/14] arm64: dts: meson-gx: fix spifc compatible
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxl-s805x-libretech-ac.dt.yaml: spi@8c80: compatible:0: 'amlogic,meson-gx-spifc' is not one of ['amlogic,meson6-spifc', 'amlogic,meson-gxbb-spifc']
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 5b3dfd03c3d3..e2cdc9fce21c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -317,7 +317,7 @@
};
spifc: spi@8c80 {
- compatible = "amlogic,meson-gx-spifc", "amlogic,meson-gxbb-spifc";
+ compatible = "amlogic,meson-gxbb-spifc";
reg = <0x0 0x08c80 0x0 0x80>;
#address-cells = <1>;
#size-cells = <0>;
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 09/14] arm64: dts: meson-axg: fix MHU compatible
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-axg-s400.dt.yaml: mailbox@ff63c404: compatible:0: 'amlogic,meson-gx-mhu' is not one of ['amlogic,meson-gxbb-mhu']
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 4a134d29491d..ed59a9e8ebb8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1116,7 +1116,7 @@
};
mailbox: mailbox@ff63c404 {
- compatible = "amlogic,meson-gx-mhu", "amlogic,meson-gxbb-mhu";
+ compatible = "amlogic,meson-gxbb-mhu";
reg = <0 0xff63c404 0 0x4c>;
interrupts = <GIC_SPI 208 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 209 IRQ_TYPE_EDGE_RISING>,
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 07/14] arm64: dts: meson-gx: fix periphs bus node name
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: periphs@c8834000: $nodename:0: 'periphs@c8834000' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
meson-gxl-s805x-libretech-ac.dt.yaml: periphs@c8834000: $nodename:0: 'periphs@c8834000' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index d8127f863b55..a7735d2f0037 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -437,7 +437,7 @@
};
};
- periphs: periphs@c8834000 {
+ periphs: bus@c8834000 {
compatible = "simple-bus";
reg = <0x0 0xc8834000 0x0 0x2000>;
#address-cells = <2>;
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 08/14] arm64: dts: meson-gxl: fix internal phy compatible
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxl-s805x-libretech-ac.dt.yaml: ethernet-phy@8: compatible: ['ethernet-phy-id0181.4400', 'ethernet-phy-ieee802.3-c22'] is not valid under any of the given schemas
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index ee1ecdbcc958..43eb158bee24 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -709,7 +709,7 @@
#size-cells = <0>;
internal_phy: ethernet-phy@8 {
- compatible = "ethernet-phy-id0181.4400", "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0181.4400";
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
reg = <8>;
max-speed = <100>;
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 06/14] arm64: dts: meson-gx: fix mhu compatible
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: mailbox@404: compatible:0: 'amlogic,meson-gx-mhu' is not one of ['amlogic,meson-gxbb-mhu']
meson-gxl-s805x-libretech-ac.dt.yaml: mailbox@404: compatible:0: 'amlogic,meson-gx-mhu' is not one of ['amlogic,meson-gxbb-mhu']
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 00215ece17c8..d8127f863b55 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -476,7 +476,7 @@
};
mailbox: mailbox@404 {
- compatible = "amlogic,meson-gx-mhu", "amlogic,meson-gxbb-mhu";
+ compatible = "amlogic,meson-gxbb-mhu";
reg = <0 0x404 0 0x4c>;
interrupts = <GIC_SPI 208 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 209 IRQ_TYPE_EDGE_RISING>,
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox