* Re: [PATCH 2/8] arm64: memory: Ensure address tag is masked in conversion macros
From: Steve Capper @ 2019-08-13 18:54 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Catalin Marinas, Geert Uytterhoeven,
Andrey Konovalov, Qian Cai, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190813170149.26037-3-will@kernel.org>
On Tue, Aug 13, 2019 at 06:01:43PM +0100, Will Deacon wrote:
> When converting a linear virtual address to a physical address, pfn or
> struct page *, we must make sure that the tag bits are masked before the
> calculation otherwise we end up with corrupt pointers when running with
> CONFIG_KASAN_SW_TAGS=y:
>
> | Unable to handle kernel paging request at virtual address 0037fe0007580d08
> | [0037fe0007580d08] address between user and kernel address ranges
>
> Mask out the tag in __virt_to_phys_nodebug() and virt_to_page().
>
> Reported-by: Qian Cai <cai@lca.pw>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Fixes: 9cb1c5ddd2c4 ("arm64: mm: Remove bit-masking optimisations for PAGE_OFFSET and VMEMMAP_START")
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Steve Capper <steve.capper@arm.com>
> ---
> arch/arm64/include/asm/memory.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 442ab861cab8..47b4dc73b8bf 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -252,7 +252,7 @@ static inline const void *__tag_set(const void *addr, u8 tag)
> #define __kimg_to_phys(addr) ((addr) - kimage_voffset)
>
> #define __virt_to_phys_nodebug(x) ({ \
> - phys_addr_t __x = (phys_addr_t)(x); \
> + phys_addr_t __x = (phys_addr_t)(__tag_reset(x)); \
> __is_lm_address(__x) ? __lm_to_phys(__x) : \
> __kimg_to_phys(__x); \
> })
> @@ -324,7 +324,8 @@ static inline void *phys_to_virt(phys_addr_t x)
> ((void *)__addr_tag); \
> })
>
> -#define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) + VMEMMAP_START))
> +#define virt_to_page(vaddr) \
> + ((struct page *)((__virt_to_pgoff(__tag_reset(vaddr))) + VMEMMAP_START))
> #endif
>
> #define virt_addr_valid(addr) ({ \
> --
> 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 1/8] arm64: memory: Fix virt_addr_valid() using __is_lm_address()
From: Steve Capper @ 2019-08-13 18:53 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Catalin Marinas, Geert Uytterhoeven,
Andrey Konovalov, Qian Cai, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190813170149.26037-2-will@kernel.org>
On Tue, Aug 13, 2019 at 06:01:42PM +0100, Will Deacon 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>
Reviewed-by: Steve Capper <steve.capper@arm.com>
> ---
> 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. 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)))
>
> #define __lm_to_phys(addr) (((addr) + physvirt_offset))
> #define __kimg_to_phys(addr) ((addr) - kimage_voffset)
> @@ -326,13 +326,13 @@ static inline void *phys_to_virt(phys_addr_t x)
>
> #define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) + VMEMMAP_START))
> #endif
> -#endif
>
> -#define _virt_addr_is_linear(kaddr) \
> - (__tag_reset((u64)(kaddr)) >= PAGE_OFFSET)
> +#define virt_addr_valid(addr) ({ \
> + __typeof__(addr) __addr = addr; \
> + __is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr)); \
> +})
>
> -#define virt_addr_valid(kaddr) \
> - (_virt_addr_is_linear(kaddr) && pfn_valid(virt_to_pfn(kaddr)))
> +#endif
>
> /*
> * Given that the GIC architecture permits ITS implementations that can only be
> --
> 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 0/8] Fix issues with 52-bit kernel virtual addressing
From: Steve Capper @ 2019-08-13 18:53 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Catalin Marinas, Geert Uytterhoeven,
Andrey Konovalov, Qian Cai, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190813170149.26037-1-will@kernel.org>
On Tue, Aug 13, 2019 at 06:01:41PM +0100, Will Deacon wrote:
> Hi all,
>
> This patch series addresses some issues with 52-bit kernel VAs reported
> by Qian Cai and Geert. It's all confined to asm/memory.h and I got a bit
> carried away cleaning that thing up so the patches get more worthless
> as you go through the series. Still, I'd like to queue this on top of
> the 52-bit VA stuff currently sitting in -next.
>
> Although Geert and Steve tested my initial hacks, I dropped the tags
> because I've split things up and could've easily broken things again.
>
> Cheers,
>
> Will
>
A really big thank you for this Will! and apologies again for missing
these things in testing.
I've applied this series to for-next/52-bit-kva and tested using 52-bit
VAs with SW TAGS with DEBUG_VIRTUAL and DEBUG_VM, so please feel free to
add:
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] coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute
From: Greg KH @ 2019-08-13 18:37 UTC (permalink / raw)
To: Suzuki K Poulose; +Cc: linux-arm-kernel, mathieu.poirier, stable
In-Reply-To: <20190812135328.30952-1-suzuki.poulose@arm.com>
On Mon, Aug 12, 2019 at 02:53:28PM +0100, Suzuki K Poulose wrote:
> commit 5511c0c309db4c526a6e9f8b2b8a1483771574bc upstream
>
> While running the linux-next with CONFIG_DEBUG_LOCKS_ALLOC enabled,
> I get the following splat.
>
Thanks for the backport, now queued up.
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] net: qca: update MODULE_AUTHOR() email address
From: Stefan Wahren @ 2019-08-13 18:17 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, David S. Miller, Srinivas Kandagatla,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
Cc: linux-hwmon, netdev, linux-kernel, linux-arm-kernel,
Stefan Wahren
In-Reply-To: <1565720249-6549-1-git-send-email-wahrenst@gmx.net>
I2SE has been acquired by in-tech. So the email address listed in
MODULE_AUTHOR() will be disabled in the near future. I only have access
to QCA7000 boards at in-tech, so use my new company address.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
drivers/net/ethernet/qualcomm/qca_7k_common.c | 2 +-
drivers/net/ethernet/qualcomm/qca_spi.c | 2 +-
drivers/net/ethernet/qualcomm/qca_uart.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/qca_7k_common.c b/drivers/net/ethernet/qualcomm/qca_7k_common.c
index 6b511f0..87d023d 100644
--- a/drivers/net/ethernet/qualcomm/qca_7k_common.c
+++ b/drivers/net/ethernet/qualcomm/qca_7k_common.c
@@ -162,5 +162,5 @@ EXPORT_SYMBOL_GPL(qcafrm_fsm_decode);
MODULE_DESCRIPTION("Qualcomm Atheros QCA7000 common");
MODULE_AUTHOR("Qualcomm Atheros Communications");
-MODULE_AUTHOR("Stefan Wahren <stefan.wahren@i2se.com>");
+MODULE_AUTHOR("Stefan Wahren <stefan.wahren@in-tech.com>");
MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/net/ethernet/qualcomm/qca_spi.c b/drivers/net/ethernet/qualcomm/qca_spi.c
index b28360b..d9d3554 100644
--- a/drivers/net/ethernet/qualcomm/qca_spi.c
+++ b/drivers/net/ethernet/qualcomm/qca_spi.c
@@ -1034,6 +1034,6 @@ module_spi_driver(qca_spi_driver);
MODULE_DESCRIPTION("Qualcomm Atheros QCA7000 SPI Driver");
MODULE_AUTHOR("Qualcomm Atheros Communications");
-MODULE_AUTHOR("Stefan Wahren <stefan.wahren@i2se.com>");
+MODULE_AUTHOR("Stefan Wahren <stefan.wahren@in-tech.com>");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_VERSION(QCASPI_DRV_VERSION);
diff --git a/drivers/net/ethernet/qualcomm/qca_uart.c b/drivers/net/ethernet/qualcomm/qca_uart.c
index 5906168..ab4da8e 100644
--- a/drivers/net/ethernet/qualcomm/qca_uart.c
+++ b/drivers/net/ethernet/qualcomm/qca_uart.c
@@ -418,6 +418,6 @@ module_serdev_device_driver(qca_uart_driver);
MODULE_DESCRIPTION("Qualcomm Atheros QCA7000 UART Driver");
MODULE_AUTHOR("Qualcomm Atheros Communications");
-MODULE_AUTHOR("Stefan Wahren <stefan.wahren@i2se.com>");
+MODULE_AUTHOR("Stefan Wahren <stefan.wahren@in-tech.com>");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_VERSION(QCAUART_DRV_VERSION);
--
2.7.4
_______________________________________________
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 2/3] hwmon: raspberrypi: update MODULE_AUTHOR() email address
From: Stefan Wahren @ 2019-08-13 18:17 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, David S. Miller, Srinivas Kandagatla,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
Cc: linux-hwmon, netdev, linux-kernel, linux-arm-kernel,
Stefan Wahren
In-Reply-To: <1565720249-6549-1-git-send-email-wahrenst@gmx.net>
The email address listed in MODULE_AUTHOR() will be disabled in the
near future. Replace it with my private one.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
drivers/hwmon/raspberrypi-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/raspberrypi-hwmon.c b/drivers/hwmon/raspberrypi-hwmon.c
index efe4bb1..d3a64a3 100644
--- a/drivers/hwmon/raspberrypi-hwmon.c
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -146,7 +146,7 @@ static struct platform_driver rpi_hwmon_driver = {
};
module_platform_driver(rpi_hwmon_driver);
-MODULE_AUTHOR("Stefan Wahren <stefan.wahren@i2se.com>");
+MODULE_AUTHOR("Stefan Wahren <wahrenst@gmx.net>");
MODULE_DESCRIPTION("Raspberry Pi voltage sensor driver");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:raspberrypi-hwmon");
--
2.7.4
_______________________________________________
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 1/3] nvmem: mxs-ocotp: update MODULE_AUTHOR() email address
From: Stefan Wahren @ 2019-08-13 18:17 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, David S. Miller, Srinivas Kandagatla,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
Cc: linux-hwmon, netdev, linux-kernel, linux-arm-kernel,
Stefan Wahren
The email address listed in MODULE_AUTHOR() will be disabled in the
near future. Replace it with my private one.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
drivers/nvmem/mxs-ocotp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvmem/mxs-ocotp.c b/drivers/nvmem/mxs-ocotp.c
index c34d9fe..8e4898d 100644
--- a/drivers/nvmem/mxs-ocotp.c
+++ b/drivers/nvmem/mxs-ocotp.c
@@ -200,6 +200,6 @@ static struct platform_driver mxs_ocotp_driver = {
};
module_platform_driver(mxs_ocotp_driver);
-MODULE_AUTHOR("Stefan Wahren <stefan.wahren@i2se.com>");
+MODULE_AUTHOR("Stefan Wahren <wahrenst@gmx.net");
MODULE_DESCRIPTION("driver for OCOTP in i.MX23/i.MX28");
MODULE_LICENSE("GPL v2");
--
2.7.4
_______________________________________________
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 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Aaro Koskinen @ 2019-08-13 18:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bartlomiej Zolnierkiewicz, Tony Lindgren, Greg Kroah-Hartman,
Linus Walleij, Linux Kernel Mailing List, Dominik Brodowski,
Tomi Valkeinen, linux-omap, Linux ARM
In-Reply-To: <CAK8P3a0E+QUn9wcP5Obv-FitWyXCFwcp+oPConeO2p-NV1rqsw@mail.gmail.com>
Hi,
On Tue, Aug 13, 2019 at 01:02:16PM +0200, Arnd Bergmann wrote:
> On Tue, Aug 13, 2019 at 12:36 PM Tony Lindgren <tony@atomide.com> wrote:
> > * Arnd Bergmann <arnd@arndb.de> [190808 21:34]:
> > > The ISA I/O space handling in omap_cf is incompatible with
> > > PCI drivers in a multiplatform kernel, and requires a custom
> > > mach/io.h.
> > >
> > > Change the driver to use pci_ioremap_io() like PCI drivers do,
> > > so the generic ioport access can work across platforms.
> > >
> > > To actually use that code, we have to select CONFIG_PCI
> > > here.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Looks like this series boots for me on 5912osk up to this
> > patch
>
> Ok, that's something. Thanks for testing!
>
> >, but this patch breaks booting somehow.
> >
> > Any ideas for fixes?
>
> I can think of multiple possible issues:
>
> - I force CONFIG_PCI to be enabled here in order to keep the
> asm/io.h logic unchanged. If PCI support in itself is an issue,
> then turning on CONFIG_PCI without the rest of this patch
> should also break.
The board dies early, probably in pci_reserve_io():
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.3.0-rc4-osk-los_80efa+-00028-g09f6f22a63e9 (aaro@amd-fx-6350) (gcc version 8.3.0 (GCC)) #1 Tue Aug 13 20:50:11 EEST 2019
[ 0.000000] CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: TI-OSK
[ 0.000000] Ignoring tag cmdline (using the default kernel command line)
[ 0.000000] printk: bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] Internal error: Oops - undefined instruction: 0 [#1] ARM
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.3.0-rc4-osk-los_80efa+-00028-g09f6f22a63e9 #1
[ 0.000000] Hardware name: TI-OSK
[ 0.000000] PC is at vm_area_add_early+0x1c/0x74
[ 0.000000] LR is at 0x200000
[ 0.000000] pc : [<c0419310>] lr : [<00200000>] psr: 800000d3
[ 0.000000] sp : c05b5f14 ip : ff000000 fp : c05bad68
[ 0.000000] r10: fefb0000 r9 : ffe00000 r8 : 001fffff
[ 0.000000] r7 : c05bad88 r6 : c05db3d4 r5 : c05ca678 r4 : c1ffcf60
[ 0.000000] r3 : c1ffcfd8 r2 : c1ffcfb0 r1 : fefb0000 r0 : c1ffcf60
[ 0.000000] Flags: Nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
[ 0.000000] Control: 0005317f Table: 10004000 DAC: 00000053
[ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc05b5f14 to 0xc05b6000)
[ 0.000000] 5f00: c0411724 ff000000 c041260c
[ 0.000000] 5f20: 00010000 00010600 c0428794 c05b7008 c042b000 00600000 00000000 ffff1000
[ 0.000000] 5f40: 00011fff 00001000 00000007 00000000 00000000 c0428794 c0008000 c060ba7c
[ 0.000000] 5f60: c0429a38 c05b5fc4 c05ca818 00053177 00000001 c04101fc 0000006c 0005317f
[ 0.000000] 5f80: 00000000 00000000 00000053 00003135 c05b7008 c05b7000 41069263 00053177
[ 0.000000] 5fa0: 00000001 c040da10 00000000 00000000 00000000 00000000 00000000 00000000
[ 0.000000] 5fc0: 00000000 c0429a38 00000000 00000000 00000000 c040d330 00000053 00003135
[ 0.000000] 5fe0: 00000203 10000100 41069263 00053177 00000000 00000000 00000000 00000000
[ 0.000000] [<c0419310>] (vm_area_add_early) from [<c0411724>] (add_static_vm_early+0xc/0x5c)
[ 0.000000] [<c0411724>] (add_static_vm_early) from [<c041260c>] (paging_init+0x2e0/0x5b4)
[ 0.000000] [<c041260c>] (paging_init) from [<c04101fc>] (setup_arch+0x4c8/0x7cc)
[ 0.000000] [<c04101fc>] (setup_arch) from [<c040da10>] (start_kernel+0x58/0x478)
[ 0.000000] [<c040da10>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] Code: e3530000 059f2058 05923000 0a000006 (e7f001f2)
[ 0.000000] random: get_random_bytes called from init_oops_id+0x20/0x3c with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
A.
_______________________________________________
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/8] arm64: memory: Fix virt_addr_valid() using __is_lm_address()
From: Ard Biesheuvel @ 2019-08-13 18:09 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Steve Capper, Catalin Marinas, Qian Cai,
Andrey Konovalov, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <20190813170149.26037-2-will@kernel.org>
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.
> 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
> #define __lm_to_phys(addr) (((addr) + physvirt_offset))
> #define __kimg_to_phys(addr) ((addr) - kimage_voffset)
> @@ -326,13 +326,13 @@ static inline void *phys_to_virt(phys_addr_t x)
>
> #define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) + VMEMMAP_START))
> #endif
> -#endif
>
> -#define _virt_addr_is_linear(kaddr) \
> - (__tag_reset((u64)(kaddr)) >= PAGE_OFFSET)
> +#define virt_addr_valid(addr) ({ \
> + __typeof__(addr) __addr = addr; \
> + __is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr)); \
> +})
>
> -#define virt_addr_valid(kaddr) \
> - (_virt_addr_is_linear(kaddr) && pfn_valid(virt_to_pfn(kaddr)))
> +#endif
>
> /*
> * Given that the GIC architecture permits ITS implementations that can only be
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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 v2 4/6] irqchip/irq-pruss-intc: Add helper functions to configure internal mapping
From: Suman Anna @ 2019-08-13 17:49 UTC (permalink / raw)
To: David Lechner, Marc Zyngier, Thomas Gleixner, Jason Cooper
Cc: devicetree, Grygorii Strashko, Tony Lindgren, Sekhar Nori,
linux-kernel, Andrew F. Davis, Lokesh Vutla, Rob Herring,
Murali Karicheri, linux-omap, linux-arm-kernel, Roger Quadros
In-Reply-To: <de94d398-4768-17b0-b9ef-a66d43d34ae3@lechnology.com>
Hi David,
On 8/13/19 9:26 AM, David Lechner wrote:
> On 8/12/19 2:39 PM, Suman Anna wrote:
>> Hi David,
>>
>> On 8/8/19 12:09 PM, David Lechner wrote:
>>> On 8/2/19 4:26 PM, Suman Anna wrote:
>>>> Point is different applications might use mapping differently as per
>>>> their firmware and driver/application design and their split across one
>>>> or more PRUs (design by contract). And we need to set this up at
>>>> runtime
>>>> when the application driver is getting run. We will have either the
>>>> Soft
>>>> UART or the Ethernet running at a time depending on the end goal
>>>> desired
>>>>
>>>>> I have an idea that we can use multiple struct irq_domains to make
>>>>> this work in the existing IRQ framework, but it would be helpful to
>>>>> know more about the bigger picture first.
>>>>
>>>> Yeah, would be great if there is a way this can be solved without
>>>> having
>>>> to introduce additional API.
>>>>
>>>
>>>
>>> Here is what I came up with to use existing IRQ APIs to implement event
>>> mapping.
>>> Basically it is the same as my previous suggestion [1], with the
>>> addition of
>>> multiple IRQ domains.
>>
>> First of all, many thanks for looking into the problem and providing
>> patches for the alternate solutions. If we were to not use any exported
>> functions, this approach does seem to be a viable solution. I am going
>> to play around with both [1] and this patch with all our existing
>> usecases and see if I run into any issues.
>>
>> So, w.r.t this patch compared to [1], is the multiple IRQ domain solving
>> anything specifically? Our main issue is the re-purposing of a event
>> (and its mapping depending on the application), and the same issue will
>> remain whether we have multiple domains or not. Also, now we would
>> expect an event to migrate between different domains based on its usage.
>
> The only thing using multiple IRQ domains gets us is that it allows us to
> have multiple IRQ descriptors (virq) for a single PRU event. In other
> words, if we needed to map a single system event to both a PRU core and
> the MCU interrupt controller at the same time, then we would need separate
> IRQ domains to do this. I we would never need to do something like this,
> then we don't the IRQ domains.
Yeah, this is not a realistic usecase. A event can only be mapped to a
single channel which in turn can be mapped to only a single output
interrupt and we expect this to be processed by only a single entity
even if it may be connected to multiple processors. That is going to be
a system integration partitioning design choice. This is where the
irqs-shared and irqs-reserved logic comes in, so that MPU doesn't deal
with that interrupt line if it is expected to be handled by a different
processor.
>
> Previously, you said "We can have two different applications use the same
> event with different mappings." So I took this to mean that the events
> would actually be mapped in hardware at the same time, but now I
> understand it to just mean that a single firmware blob could contain
> multiple mappings that contain the same events, but won't actually be used
> at the same time. So if this is the case, then we probably don't need to
> mess with IRQ domains.
The different applications (like PRU Dual-EMAC or PRU Soft UART I
mentioned earlier) will indeed be running at separate times, PRU cores
are a very limited resource, so it is treated as an exclusive resource.
The INTC is expected to be programmed as per the application running at
a given time. We also expect the firmware blob to change as per the
application.
>
>
>>
>>>
>>> The idea is that each external interrupt controller (or DMA controller,
>>> etc.)
>>> that is connected to the PRUSS interrupt controller is considered an
>>> interrupt
>>> domain. One of the objections to my previous patch was that we could
>>> only have
>>> one IRQ descriptor per event. Now we can have one descriptor per
>>> event per
>>> domain.
>>>
>>> I am still proposing that we use the interrupt-cells and identical
>>> vendor
>>> resource data structures in the PRU firmware be used to provide the
>>> mapping
>>> information. (As a side note, I still think it is important to include
>>> EVTSEL
>>> on AM18xx in order to fully describe the event.)
>>
>> W.r.t EVTSEL, it is a global value and applies to a range of events. I
>> have another equivalent register/functionality on most of the other SoCs
>> as well (a register in PRUSS_CFG space) that muxes standard events vs
>> MII_RT events. Again, that is limited to only a subset of all the system
>> events. So, should this continue to be a per event specifier, it will be
>> yet another mapping configuration data item (my idea was to manage this
>> once per application within the PRU remoteproc driver along with the
>> fwspec mapping).
>
> I guess it just seems a bit fragile to me to specify EVTSEL elsewhere. My
> thinking is that the first event registered that requires a specific EVTSEL
> value "wins" and if any other events are registered with a different EVTSEL
> value, then we will get an error. Likewise, if all users of a specific
> EVTSEL value are unmapped, then it is up for grabs for any value again.
We usually expect an application to have possibly multiple events, and
so all of them are expected to match if it is using multiple events
within the range controlled by EVTSEL or the CFG register. It only needs
to be programmed once if the application needs it. The first one to win
introduces ordering issues in general. Anyway, for this solution to work
in general, I am expecting the irq_create_fwspec_mapping()s to be per
application, and they should be overwriting any previous configured values.
>
> On the other hand, with a global value as you have proposed, we can just
> leave comments in the device tree and the firmware about which EVTSEL value
> is required for a specific event number. We won't be able to catch mistakes
> at runtime, but at least there will be something to remind us what we did
> wrong. So, I suppose that is good enough.
With the global value, I expect it to be a property of the client node
alongside interrupts. The management and selection of this will be left
to the PRU remoteproc driver. Encoding this on the firmware-side per
event also seems a waste of memory. End of the day, it is going to be
design contract with the application and firmware.
regards
Suman
_______________________________________________
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 v2] tracing/arm64: Have max stack tracer handle the case of return address after data
From: Steven Rostedt @ 2019-08-13 17:47 UTC (permalink / raw)
To: Will Deacon
Cc: Jiping Ma, catalin.marinas, will.deacon, linux-kernel, mingo,
Joel Fernandes, linux-arm-kernel
In-Reply-To: <20190813173114.himeal2ublebx7ea@willie-the-truck>
On Tue, 13 Aug 2019 18:31:14 +0100
Will Deacon <will@kernel.org> wrote:
> Hi Steve,
>
> On Thu, Aug 08, 2019 at 10:24:40PM -0400, Steven Rostedt wrote:
> > On Fri, 9 Aug 2019 10:17:19 +0800
> > Jiping Ma <Jiping.Ma2@windriver.com> wrote:
> > > On 2019年08月09日 01:24, Steven Rostedt wrote:
> > > > On Thu, 8 Aug 2019 18:11:53 +0100
> > > > Will Deacon <will@kernel.org> wrote:
> > > >
> > > >>> We could make it more descriptive of what it will do and not the reason
> > > >>> for why it is done...
> > > >>>
> > > >>>
> > > >>> ARCH_FTRACE_SHIFT_STACK_TRACER
> > > >> Acked-by: Will Deacon <will@kernel.org>
> > > > Thanks Will!
> > > >
> > > > Here's the official patch.
> > > >
> > > > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> > > >
> > > > Most archs (well at least x86) store the function call return address on the
> > > > stack before storing the local variables for the function. The max stack
> > > > tracer depends on this in its algorithm to display the stack size of each
> > > > function it finds in the back trace.
> > > >
> > > > Some archs (arm64), may store the return address (from its link register)
> > > > just before calling a nested function. There's no reason to save the link
> > > > register on leaf functions, as it wont be updated. This breaks the algorithm
> > > > of the max stack tracer.
> > > >
> > > > Add a new define ARCH_RET_ADDR_AFTER_LOCAL_VARS that an architecture may set
> > >
> > > ARCH_FTRACE_SHIFT_STACK_TRACER is used in the code.
> >
> > Ah, I did a s/x/y/ to the diff of the patch, but not the change log.
> > Thanks for pointing that out. I also need to update the comment in 2/2.
>
> Are you going to post another version of this or have you queued it already?
> Just want to make sure it doesn't slip through the cracks.
>
Ah, it's in my queue. I should post a new version :-/
Thanks for the reminder.
-- 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 v2] tracing/arm64: Have max stack tracer handle the case of return address after data
From: Will Deacon @ 2019-08-13 17:31 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jiping Ma, catalin.marinas, will.deacon, linux-kernel, mingo,
Joel Fernandes, linux-arm-kernel
In-Reply-To: <20190808222440.2f99c50e@oasis.local.home>
Hi Steve,
On Thu, Aug 08, 2019 at 10:24:40PM -0400, Steven Rostedt wrote:
> On Fri, 9 Aug 2019 10:17:19 +0800
> Jiping Ma <Jiping.Ma2@windriver.com> wrote:
> > On 2019年08月09日 01:24, Steven Rostedt wrote:
> > > On Thu, 8 Aug 2019 18:11:53 +0100
> > > Will Deacon <will@kernel.org> wrote:
> > >
> > >>> We could make it more descriptive of what it will do and not the reason
> > >>> for why it is done...
> > >>>
> > >>>
> > >>> ARCH_FTRACE_SHIFT_STACK_TRACER
> > >> Acked-by: Will Deacon <will@kernel.org>
> > > Thanks Will!
> > >
> > > Here's the official patch.
> > >
> > > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> > >
> > > Most archs (well at least x86) store the function call return address on the
> > > stack before storing the local variables for the function. The max stack
> > > tracer depends on this in its algorithm to display the stack size of each
> > > function it finds in the back trace.
> > >
> > > Some archs (arm64), may store the return address (from its link register)
> > > just before calling a nested function. There's no reason to save the link
> > > register on leaf functions, as it wont be updated. This breaks the algorithm
> > > of the max stack tracer.
> > >
> > > Add a new define ARCH_RET_ADDR_AFTER_LOCAL_VARS that an architecture may set
> >
> > ARCH_FTRACE_SHIFT_STACK_TRACER is used in the code.
>
> Ah, I did a s/x/y/ to the diff of the patch, but not the change log.
> Thanks for pointing that out. I also need to update the comment in 2/2.
Are you going to post another version of this or have you queued it already?
Just want to make sure it doesn't slip through the cracks.
Cheers,
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 2/2] arm64: Don't use KPTI where we have E0PD
From: Will Deacon @ 2019-08-13 17:28 UTC (permalink / raw)
To: Mark Brown; +Cc: Catalin Marinas, linux-arm-kernel
In-Reply-To: <20190812125738.17388-3-broonie@kernel.org>
On Mon, Aug 12, 2019 at 01:57:38PM +0100, Mark Brown wrote:
> Since E0PD is intended to fulfil the same role as KPTI we don't need to
> use KPTI on CPUs where E0PD is available, we can rely on E0PD instead.
> Change the check that forces KPTI on when KASLR is enabled to check for
> E0PD before doing so, CPUs with E0PD are not expected to be affected by
> meltdown so should not need to enable KPTI for other reasons.
>
> Since we repeat the KPTI check for all CPUs we will still enable KPTI if
> any of the CPUs in the system lacks E0PD. Since KPTI itself is not changed
> by this patch once we enable KPTI we will do so for all CPUs. This is safe
> but not optimally performant for such systems.
>
> KPTI can still be forced on from the command line if required.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/kernel/cpufeature.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 4aa1d2026bef..322004409211 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -995,7 +995,7 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
>
> /* Useful for KASLR robustness */
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && kaslr_offset() > 0) {
> - if (!__kpti_forced) {
> + if (!__kpti_forced && !this_cpu_has_cap(ARM64_HAS_E0PD)) {
> str = "KASLR";
> __kpti_forced = 1;
> }
Hmm. I'm surprised you haven't had to hack arm64_kernel_use_ng_mappings().
If you boot with RANDOMIZE_BASE=y on a machine with E0PDx support, can
you dump the kernel page tables in /sys/kernel/debug/kernel_page_tables
and check that they're using global mappings? I think some of the early
mappings might still be nG with your patch.
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: next/master boot: 285 boots: 16 failed, 264 passed with 3 offline, 1 untried/unknown, 1 conflict (next-20190718)
From: Kevin Hilman @ 2019-08-13 17:26 UTC (permalink / raw)
To: Mark Brown, Heiko Stuebner
Cc: linux-rockchip, linux-next, linux-arm-kernel,
kernel-build-reports
In-Reply-To: <20190718162005.GF5761@sirena.org.uk>
Mark Brown <broonie@kernel.org> writes:
> On Thu, Jul 18, 2019 at 04:28:08AM -0700, kernelci.org bot wrote:
>
> Today's -next started failing to boot defconfig on rk3399-firefly:
>
>> arm64:
>
>> defconfig:
>> gcc-8:
>> rk3399-firefly: 1 failed lab
>
> It hits a BUG() trying to set up cpufreq:
>
> [ 87.381606] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 200000 KHz
> [ 87.393244] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 408000 KHz
> [ 87.469777] cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 12000 KHz
> [ 87.488595] cpu cpu4: _generic_set_opp_clk_only: failed to set clock rate: -22
> [ 87.491881] cpufreq: __target_index: Failed to change cpu frequency: -22
> [ 87.495335] ------------[ cut here ]------------
> [ 87.496821] kernel BUG at drivers/cpufreq/cpufreq.c:1438!
> [ 87.498462] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
>
> I'm struggling to see anything relevant in the diff from yesterday, the
> unlisted frequency warnings were there in the logs yesterday but no oops
> and I'm not seeing any changes in cpufreq, clk or anything relevant
> looking.
>
> Full bootlog and other info can be found here:
>
> https://kernelci.org/boot/id/5d302d8359b51498d049e983/
I confirm that disabling CPUfreq in the defconfig (CONFIG_CPU_FREQ=n)
makes the firefly board start working again.
Note that the default defconfig enables the "performance" CPUfreq
governor as the default governor, so during kernel boot, it will always
switch to the max frequency.
For fun, I set the default governor to "userspace" so the kernel
wouldn't make any OPP changes, and that leads to a slightly more
informative splat[1]
There is still an OPP change happening because the detected OPP is not
one that's listed in the table, so it tries to change to a listed OPP
and fails in the bowels of clk_set_rate()
Kevin
[1] https://termbin.com/3oum
_______________________________________________
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: Add initial support for E0PD
From: Will Deacon @ 2019-08-13 17:25 UTC (permalink / raw)
To: Mark Brown; +Cc: Catalin Marinas, linux-arm-kernel
In-Reply-To: <20190812125738.17388-2-broonie@kernel.org>
On Mon, Aug 12, 2019 at 01:57:37PM +0100, Mark Brown wrote:
> Kernel Page Table Isolation (KPTI) is used to mitigate some speculation
> based security issues by ensuring that the kernel is not mapped when
> userspace is running but this approach is expensive and is incompatible
> with SPE. E0PD, introduced in the ARMv8.5 extensions, provides an
> alternative to this which ensures that accesses from userspace to the
> kernel's half of the memory map to always fault with constant time,
> preventing timing attacks without requiring constant unmapping and
> remapping or preventing legitimate accesses.
>
> This initial patch does not yet integrate with KPTI, this will be dealt
> with in followup patches. Ideally we could ensure that by default we
> don't use KPTI on CPUs where E0PD is present.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/Kconfig | 14 +++++++++++++
> arch/arm64/include/asm/cpucaps.h | 3 ++-
> arch/arm64/include/asm/pgtable-hwdef.h | 2 ++
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/kernel/cpufeature.c | 27 ++++++++++++++++++++++++++
> 5 files changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c6a978b0fb7c..3a6875a5bb99 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1409,6 +1409,20 @@ config ARM64_PTR_AUTH
>
> endmenu
>
> +menu "ARMv8.5 architectural features"
> +
> +config ARM64_E0PD
> + bool "Enable support for E0PD"
> + default y
> + help
> + E0PD (part of the ARMv8.5 extensions) ensures that EL0
> + accesses made via TTBR1 always fault in constant time,
> + providing the same guarantees as KPTI with lower overhead.
This could do with a slight tweak, since there are two E0PD bits in the
TCR, which apply to TTBR0 and TTBR1 separately. I'd also be reluctant
to state that it provides the /same/ guarantees as kpti, since I don't
think it will cause a translation fault.
It's probably also worth mentioning that, unlike kpti, E0PDx doesn't
break profiling with SPE.
> + This option enables E0PD where available.
For TTBR1.
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 V2 09/13] dt-bindings: arm: Convert BCM2835 board/soc bindings to json-schema
From: Rob Herring @ 2019-08-13 17:22 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland, devicetree, Florian Fainelli, Scott Branden,
Wolfram Sang, Stephen Boyd, Ray Jui, Michael Turquette,
Eric Anholt, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Linux I2C, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:BROADCOM BCM2835 ARM ARCHITECTURE
In-Reply-To: <1565713248-4906-10-git-send-email-wahrenst@gmx.net>
On Tue, Aug 13, 2019 at 10:21 AM Stefan Wahren <wahrenst@gmx.net> wrote:
>
> Convert the BCM2835/6/7 SoC bindings to DT schema format using json-schema.
> All the other Broadcom boards are maintained by Florian Fainelli.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> Acked-by: Eric Anholt <eric@anholt.net>
> ---
> .../devicetree/bindings/arm/bcm/bcm2835.yaml | 46 +++++++++++++++
> .../devicetree/bindings/arm/bcm/brcm,bcm2835.txt | 67 ----------------------
> 2 files changed, 46 insertions(+), 67 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml
> delete mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml
> new file mode 100644
> index 0000000..1a4be26
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/bcm/bcm2835.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom BCM2711/BCM2835 Platforms Device Tree Bindings
> +
> +maintainers:
> + - Eric Anholt <eric@anholt.net>
> + - Stefan Wahren <wahrenst@gmx.net>
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + oneOf:
> + - description: BCM2835 based Boards
> + items:
> + - enum:
> + - raspberrypi,model-a
> + - raspberrypi,model-a-plus
> + - raspberrypi,model-b
> + - raspberrypi,model-b-i2c0 # Raspberry Pi Model B (no P5)
> + - raspberrypi,model-b-rev2
> + - raspberrypi,model-b-plus
> + - raspberrypi,compute-module
> + - raspberrypi,model-zero
> + - raspberrypi,model-zero-w
> + - const: brcm,bcm2835
> +
> + - description: BCM2836 based Boards
> + items:
> + - enum:
> + - raspberrypi,2-model-b
Don't you need brcm,bcm2836 here?
> +
> + - description: BCM2837 based Boards
> + items:
> + - enum:
> + - raspberrypi,3-model-a-plus
> + - raspberrypi,3-model-b
> + - raspberrypi,3-model-b-plus
> + - raspberrypi,3-compute-module
> + - raspberrypi,3-compute-module-lite
Don't you need brcm,bcm2837 here?
Please run 'dtbs_check' and make sure there aren't warnings (in the root node).
Rob
_______________________________________________
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] iommu/arm-smmu-v3: add nr_ats_masters to avoid unnecessary operations
From: Will Deacon @ 2019-08-13 17:10 UTC (permalink / raw)
To: John Garry
Cc: jean-philippe, Jean-Philippe Brucker, Joerg Roedel, linux-kernel,
iommu, Zhen Lei, Robin Murphy, linux-arm-kernel
In-Reply-To: <b5866f7a-013a-5900-6fce-268052f2ba0a@huawei.com>
On Mon, Aug 12, 2019 at 11:42:17AM +0100, John Garry wrote:
> On 01/08/2019 13:20, Zhen Lei wrote:
> > When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a
> > smmu domain does not contain any ats master, the operations of
> > arm_smmu_atc_inv_to_cmd() and lock protection in arm_smmu_atc_inv_domain()
> > are always executed. This will impact performance, especially in
> > multi-core and stress scenarios. For my FIO test scenario, about 8%
> > performance reduced.
> >
> > In fact, we can use a atomic member to record how many ats masters the
> > smmu contains. And check that without traverse the list and check all
> > masters one by one in the lock protection.
> >
>
> Hi Will, Robin, Jean-Philippe,
>
> Can you kindly check this issue? We have seen a signifigant performance
> regression here.
Sorry, John: Robin and Jean-Philippe are off at the moment and I've been
swamped dealing with the arm64 queue. I'll try to get to this tomorrow.
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 v4 3/3] interconnect: qcom: Add tagging and wake/sleep support for sdm845
From: Evan Green @ 2019-08-13 17:08 UTC (permalink / raw)
To: Georgi Djakov
Cc: linux-pm, Sean Sweeney, LKML, David Dai, Doug Anderson,
amit.kucheria, Bjorn Andersson, linux-arm-msm,
linux-arm Mailing List
In-Reply-To: <20190813145341.28530-4-georgi.djakov@linaro.org>
On Tue, Aug 13, 2019 at 7:53 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>
> From: David Dai <daidavid1@codeaurora.org>
>
> Add support for wake and sleep commands by using a tag to indicate
> whether or not the aggregate and set requests fall into execution
> state specific bucket.
>
> Signed-off-by: David Dai <daidavid1@codeaurora.org>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Reviewed-by: Evan Green <evgreen@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: [PATCH 12/16] arm64: prefer __section from compiler_attributes.h
From: Will Deacon @ 2019-08-13 17:08 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Song Liu, Catalin Marinas, Alexei Starovoitov, Daniel Borkmann,
clang-built-linux, Allison Randal, yhs, Masayoshi Mizuma,
Suzuki K Poulose, Andrey Konovalov, Shaokun Zhang, Alexios Zavras,
Josh Poimboeuf, Sedat Dilek, Thomas Gleixner, bpf, Linux ARM,
Greg Kroah-Hartman, Nick Desaulniers, linux-kernel,
Network Development, Andrew Morton, Enrico Weigelt,
Martin KaFai Lau
In-Reply-To: <CANiq72mAfJ23PyWzZAELgbKQDCX2nvY0z+dmOMe14qz=wa6eFg@mail.gmail.com>
On Tue, Aug 13, 2019 at 02:36:06PM +0200, Miguel Ojeda wrote:
> On Tue, Aug 13, 2019 at 10:27 AM Will Deacon <will@kernel.org> wrote:
> > On Mon, Aug 12, 2019 at 02:50:45PM -0700, Nick Desaulniers wrote:
> > > GCC unescapes escaped string section names while Clang does not. Because
> > > __section uses the `#` stringification operator for the section name, it
> > > doesn't need to be escaped.
> > >
> > > This antipattern was found with:
> > > $ grep -e __section\(\" -e __section__\(\" -r
> > >
> > > Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
> > > Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > > ---
> > > arch/arm64/include/asm/cache.h | 2 +-
> > > arch/arm64/kernel/smp_spin_table.c | 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > Does this fix a build issue, or is it just cosmetic or do we end up with
> > duplicate sections or something else?
>
> This should be cosmetic -- basically we are trying to move all users
> of current available __attribute__s in compiler_attributes.h to the
> __attr forms. I am also adding (slowly) new attributes that are
> already used but we don't have them yet in __attr form.
>
> > Happy to route it via arm64, just having trouble working out whether it's
> > 5.3 material!
>
> As you prefer! Those that are not taken by a maintainer I will pick up
> and send via compiler-attributes.
>
> I would go for 5.4, since there is no particular rush anyway.
Okey doke, I'll pick this one up for 5.4 then. Thanks for the explanation!
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/4] clk: imx8mn: Add GIC clock
From: Leonard Crestez @ 2019-08-13 17:05 UTC (permalink / raw)
To: Jacky Bai, Abel Vesa, Stephen Boyd, Shawn Guo
Cc: Dong Aisheng, Anson Huang, Michael Turquette, linux-imx, kernel,
Fabio Estevam, linux-clk, linux-arm-kernel
In-Reply-To: <cover.1565715590.git.leonard.crestez@nxp.com>
This is enabled by default but if it's not explicitly defined and marked
as critical then its parent might get turned off.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/clk/imx/clk-imx8mn.c | 5 +++++
include/dt-bindings/clock/imx8mn-clock.h | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index 106cc417c19b..3a71bb37c656 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -269,10 +269,14 @@ static const char * const imx8mn_usb_core_sels[] = {"osc_24m", "sys_pll1_100m",
static const char * const imx8mn_usb_phy_sels[] = {"osc_24m", "sys_pll1_100m", "sys_pll1_40m",
"sys_pll2_100m", "sys_pll2_200m", "clk_ext2",
"clk_ext3", "audio_pll2_out", };
+static const char * const imx8mn_gic_sels[] = {"osc_24m", "sys_pll2_200m", "sys_pll1_40m",
+ "sys_pll2_100m", "sys_pll1_800m", "clk_ext2",
+ "clk_ext4", "audio_pll2_out" };
+
static const char * const imx8mn_ecspi1_sels[] = {"osc_24m", "sys_pll2_200m", "sys_pll1_40m",
"sys_pll1_160m", "sys_pll1_800m", "sys_pll3_out",
"sys_pll2_250m", "audio_pll2_out", };
static const char * const imx8mn_ecspi2_sels[] = {"osc_24m", "sys_pll2_200m", "sys_pll1_40m",
@@ -522,10 +526,11 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
clks[IMX8MN_CLK_UART2] = imx8m_clk_composite("uart2", imx8mn_uart2_sels, base + 0xaf80);
clks[IMX8MN_CLK_UART3] = imx8m_clk_composite("uart3", imx8mn_uart3_sels, base + 0xb000);
clks[IMX8MN_CLK_UART4] = imx8m_clk_composite("uart4", imx8mn_uart4_sels, base + 0xb080);
clks[IMX8MN_CLK_USB_CORE_REF] = imx8m_clk_composite("usb_core_ref", imx8mn_usb_core_sels, base + 0xb100);
clks[IMX8MN_CLK_USB_PHY_REF] = imx8m_clk_composite("usb_phy_ref", imx8mn_usb_phy_sels, base + 0xb180);
+ clks[IMX8MN_CLK_GIC] = imx8m_clk_composite_critical("gic", imx8mn_gic_sels, base + 0xb200);
clks[IMX8MN_CLK_ECSPI1] = imx8m_clk_composite("ecspi1", imx8mn_ecspi1_sels, base + 0xb280);
clks[IMX8MN_CLK_ECSPI2] = imx8m_clk_composite("ecspi2", imx8mn_ecspi2_sels, base + 0xb300);
clks[IMX8MN_CLK_PWM1] = imx8m_clk_composite("pwm1", imx8mn_pwm1_sels, base + 0xb380);
clks[IMX8MN_CLK_PWM2] = imx8m_clk_composite("pwm2", imx8mn_pwm2_sels, base + 0xb400);
clks[IMX8MN_CLK_PWM3] = imx8m_clk_composite("pwm3", imx8mn_pwm3_sels, base + 0xb480);
diff --git a/include/dt-bindings/clock/imx8mn-clock.h b/include/dt-bindings/clock/imx8mn-clock.h
index 5255b1c2420e..d7b201652f4c 100644
--- a/include/dt-bindings/clock/imx8mn-clock.h
+++ b/include/dt-bindings/clock/imx8mn-clock.h
@@ -207,9 +207,10 @@
#define IMX8MN_CLK_SDMA3_ROOT 189
#define IMX8MN_CLK_TMU_ROOT 190
#define IMX8MN_CLK_ARM 191
#define IMX8MN_CLK_NAND_USDHC_BUS_RAWNAND_CLK 192
#define IMX8MN_CLK_GPU_CORE_ROOT 193
+#define IMX8MN_CLK_GIC 194
-#define IMX8MN_CLK_END 194
+#define IMX8MN_CLK_END 195
#endif
--
2.17.1
_______________________________________________
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 1/4] clk: imx8mq: Fix sys3 pll references
From: Leonard Crestez @ 2019-08-13 17:05 UTC (permalink / raw)
To: Jacky Bai, Abel Vesa, Stephen Boyd, Shawn Guo
Cc: Dong Aisheng, Anson Huang, Michael Turquette, linux-imx, kernel,
Fabio Estevam, linux-clk, linux-arm-kernel
In-Reply-To: <cover.1565715590.git.leonard.crestez@nxp.com>
The "sys3_pll2_out" CLK was removed in refactoring so all references
need to be updated to "sys3_pll_out"
Fixes: e9dda4af685f ("clk: imx: Refactor entire sccg pll clk")
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/clk/imx/clk-imx8mq.c | 112 +++++++++++++++++------------------
1 file changed, 56 insertions(+), 56 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index 81a024928408..41fc9c63356e 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -39,93 +39,93 @@ static const char * const sys2_pll_out_sels[] = {"sys1_pll1_ref_sel", "sys2_pll1
static const char * const sys3_pll_out_sels[] = {"sys3_pll1_ref_sel", "sys2_pll1_ref_sel", };
static const char * const dram_pll_out_sels[] = {"dram_pll1_ref_sel", };
/* CCM ROOT */
static const char * const imx8mq_a53_sels[] = {"osc_25m", "arm_pll_out", "sys2_pll_500m", "sys2_pll_1000m",
- "sys1_pll_800m", "sys1_pll_400m", "audio_pll1_out", "sys3_pll2_out", };
+ "sys1_pll_800m", "sys1_pll_400m", "audio_pll1_out", "sys3_pll_out", };
static const char * const imx8mq_arm_m4_sels[] = {"osc_25m", "sys2_pll_200m", "sys2_pll_250m", "sys1_pll_266m",
- "sys1_pll_800m", "audio_pll1_out", "video_pll1_out", "sys3_pll2_out", };
+ "sys1_pll_800m", "audio_pll1_out", "video_pll1_out", "sys3_pll_out", };
static const char * const imx8mq_vpu_sels[] = {"osc_25m", "arm_pll_out", "sys2_pll_500m", "sys2_pll_1000m",
"sys1_pll_800m", "sys1_pll_400m", "audio_pll1_out", "vpu_pll_out", };
-static const char * const imx8mq_gpu_core_sels[] = {"osc_25m", "gpu_pll_out", "sys1_pll_800m", "sys3_pll2_out",
+static const char * const imx8mq_gpu_core_sels[] = {"osc_25m", "gpu_pll_out", "sys1_pll_800m", "sys3_pll_out",
"sys2_pll_1000m", "audio_pll1_out", "video_pll1_out", "audio_pll2_out", };
-static const char * const imx8mq_gpu_shader_sels[] = {"osc_25m", "gpu_pll_out", "sys1_pll_800m", "sys3_pll2_out",
+static const char * const imx8mq_gpu_shader_sels[] = {"osc_25m", "gpu_pll_out", "sys1_pll_800m", "sys3_pll_out",
"sys2_pll_1000m", "audio_pll1_out", "video_pll1_out", "audio_pll2_out", };
static const char * const imx8mq_main_axi_sels[] = {"osc_25m", "sys2_pll_333m", "sys1_pll_800m", "sys2_pll_250m",
"sys2_pll_1000m", "audio_pll1_out", "video_pll1_out", "sys1_pll_100m",};
static const char * const imx8mq_enet_axi_sels[] = {"osc_25m", "sys1_pll_266m", "sys1_pll_800m", "sys2_pll_250m",
- "sys2_pll_200m", "audio_pll1_out", "video_pll1_out", "sys3_pll2_out", };
+ "sys2_pll_200m", "audio_pll1_out", "video_pll1_out", "sys3_pll_out", };
static const char * const imx8mq_nand_usdhc_sels[] = {"osc_25m", "sys1_pll_266m", "sys1_pll_800m", "sys2_pll_200m",
- "sys1_pll_133m", "sys3_pll2_out", "sys2_pll_250m", "audio_pll1_out", };
+ "sys1_pll_133m", "sys3_pll_out", "sys2_pll_250m", "audio_pll1_out", };
-static const char * const imx8mq_vpu_bus_sels[] = {"osc_25m", "sys1_pll_800m", "vpu_pll_out", "audio_pll2_out", "sys3_pll2_out", "sys2_pll_1000m", "sys2_pll_200m", "sys1_pll_100m", };
+static const char * const imx8mq_vpu_bus_sels[] = {"osc_25m", "sys1_pll_800m", "vpu_pll_out", "audio_pll2_out", "sys3_pll_out", "sys2_pll_1000m", "sys2_pll_200m", "sys1_pll_100m", };
-static const char * const imx8mq_disp_axi_sels[] = {"osc_25m", "sys2_pll_125m", "sys1_pll_800m", "sys3_pll2_out", "sys1_pll_400m", "audio_pll2_out", "clk_ext1", "clk_ext4", };
+static const char * const imx8mq_disp_axi_sels[] = {"osc_25m", "sys2_pll_125m", "sys1_pll_800m", "sys3_pll_out", "sys1_pll_400m", "audio_pll2_out", "clk_ext1", "clk_ext4", };
-static const char * const imx8mq_disp_apb_sels[] = {"osc_25m", "sys2_pll_125m", "sys1_pll_800m", "sys3_pll2_out",
+static const char * const imx8mq_disp_apb_sels[] = {"osc_25m", "sys2_pll_125m", "sys1_pll_800m", "sys3_pll_out",
"sys1_pll_40m", "audio_pll2_out", "clk_ext1", "clk_ext3", };
static const char * const imx8mq_disp_rtrm_sels[] = {"osc_25m", "sys1_pll_800m", "sys2_pll_200m", "sys1_pll_400m",
"audio_pll1_out", "video_pll1_out", "clk_ext2", "clk_ext3", };
static const char * const imx8mq_usb_bus_sels[] = {"osc_25m", "sys2_pll_500m", "sys1_pll_800m", "sys2_pll_100m",
"sys2_pll_200m", "clk_ext2", "clk_ext4", "audio_pll2_out", };
-static const char * const imx8mq_gpu_axi_sels[] = {"osc_25m", "sys1_pll_800m", "gpu_pll_out", "sys3_pll2_out", "sys2_pll_1000m",
+static const char * const imx8mq_gpu_axi_sels[] = {"osc_25m", "sys1_pll_800m", "gpu_pll_out", "sys3_pll_out", "sys2_pll_1000m",
"audio_pll1_out", "video_pll1_out", "audio_pll2_out", };
-static const char * const imx8mq_gpu_ahb_sels[] = {"osc_25m", "sys1_pll_800m", "gpu_pll_out", "sys3_pll2_out", "sys2_pll_1000m",
+static const char * const imx8mq_gpu_ahb_sels[] = {"osc_25m", "sys1_pll_800m", "gpu_pll_out", "sys3_pll_out", "sys2_pll_1000m",
"audio_pll1_out", "video_pll1_out", "audio_pll2_out", };
-static const char * const imx8mq_noc_sels[] = {"osc_25m", "sys1_pll_800m", "sys3_pll2_out", "sys2_pll_1000m", "sys2_pll_500m",
+static const char * const imx8mq_noc_sels[] = {"osc_25m", "sys1_pll_800m", "sys3_pll_out", "sys2_pll_1000m", "sys2_pll_500m",
"audio_pll1_out", "video_pll1_out", "audio_pll2_out", };
-static const char * const imx8mq_noc_apb_sels[] = {"osc_25m", "sys1_pll_400m", "sys3_pll2_out", "sys2_pll_333m", "sys2_pll_200m",
+static const char * const imx8mq_noc_apb_sels[] = {"osc_25m", "sys1_pll_400m", "sys3_pll_out", "sys2_pll_333m", "sys2_pll_200m",
"sys1_pll_800m", "audio_pll1_out", "video_pll1_out", };
static const char * const imx8mq_ahb_sels[] = {"osc_25m", "sys1_pll_133m", "sys1_pll_800m", "sys1_pll_400m",
- "sys2_pll_125m", "sys3_pll2_out", "audio_pll1_out", "video_pll1_out", };
+ "sys2_pll_125m", "sys3_pll_out", "audio_pll1_out", "video_pll1_out", };
static const char * const imx8mq_audio_ahb_sels[] = {"osc_25m", "sys2_pll_500m", "sys1_pll_800m", "sys2_pll_1000m",
- "sys2_pll_166m", "sys3_pll2_out", "audio_pll1_out", "video_pll1_out", };
+ "sys2_pll_166m", "sys3_pll_out", "audio_pll1_out", "video_pll1_out", };
static const char * const imx8mq_dsi_ahb_sels[] = {"osc_25m", "sys2_pll_100m", "sys1_pll_80m", "sys1_pll_800m",
- "sys2_pll_1000m", "sys3_pll2_out", "clk_ext3", "audio_pll2_out"};
+ "sys2_pll_1000m", "sys3_pll_out", "clk_ext3", "audio_pll2_out"};
static const char * const imx8mq_dram_alt_sels[] = {"osc_25m", "sys1_pll_800m", "sys1_pll_100m", "sys2_pll_500m",
"sys2_pll_250m", "sys1_pll_400m", "audio_pll1_out", "sys1_pll_266m", };
static const char * const imx8mq_dram_apb_sels[] = {"osc_25m", "sys2_pll_200m", "sys1_pll_40m", "sys1_pll_160m",
- "sys1_pll_800m", "sys3_pll2_out", "sys2_pll_250m", "audio_pll2_out", };
+ "sys1_pll_800m", "sys3_pll_out", "sys2_pll_250m", "audio_pll2_out", };
-static const char * const imx8mq_vpu_g1_sels[] = {"osc_25m", "vpu_pll_out", "sys1_pll_800m", "sys2_pll_1000m", "sys1_pll_100m", "sys2_pll_125m", "sys3_pll2_out", "audio_pll1_out", };
+static const char * const imx8mq_vpu_g1_sels[] = {"osc_25m", "vpu_pll_out", "sys1_pll_800m", "sys2_pll_1000m", "sys1_pll_100m", "sys2_pll_125m", "sys3_pll_out", "audio_pll1_out", };
-static const char * const imx8mq_vpu_g2_sels[] = {"osc_25m", "vpu_pll_out", "sys1_pll_800m", "sys2_pll_1000m", "sys1_pll_100m", "sys2_pll_125m", "sys3_pll2_out", "audio_pll1_out", };
+static const char * const imx8mq_vpu_g2_sels[] = {"osc_25m", "vpu_pll_out", "sys1_pll_800m", "sys2_pll_1000m", "sys1_pll_100m", "sys2_pll_125m", "sys3_pll_out", "audio_pll1_out", };
-static const char * const imx8mq_disp_dtrc_sels[] = {"osc_25m", "vpu_pll_out", "sys1_pll_800m", "sys2_pll_1000m", "sys1_pll_160m", "sys2_pll_100m", "sys3_pll2_out", "audio_pll2_out", };
+static const char * const imx8mq_disp_dtrc_sels[] = {"osc_25m", "vpu_pll_out", "sys1_pll_800m", "sys2_pll_1000m", "sys1_pll_160m", "sys2_pll_100m", "sys3_pll_out", "audio_pll2_out", };
-static const char * const imx8mq_disp_dc8000_sels[] = {"osc_25m", "vpu_pll_out", "sys1_pll_800m", "sys2_pll_1000m", "sys1_pll_160m", "sys2_pll_100m", "sys3_pll2_out", "audio_pll2_out", };
+static const char * const imx8mq_disp_dc8000_sels[] = {"osc_25m", "vpu_pll_out", "sys1_pll_800m", "sys2_pll_1000m", "sys1_pll_160m", "sys2_pll_100m", "sys3_pll_out", "audio_pll2_out", };
static const char * const imx8mq_pcie1_ctrl_sels[] = {"osc_25m", "sys2_pll_250m", "sys2_pll_200m", "sys1_pll_266m",
- "sys1_pll_800m", "sys2_pll_500m", "sys2_pll_250m", "sys3_pll2_out", };
+ "sys1_pll_800m", "sys2_pll_500m", "sys2_pll_250m", "sys3_pll_out", };
static const char * const imx8mq_pcie1_phy_sels[] = {"osc_25m", "sys2_pll_100m", "sys2_pll_500m", "clk_ext1", "clk_ext2",
"clk_ext3", "clk_ext4", };
-static const char * const imx8mq_pcie1_aux_sels[] = {"osc_25m", "sys2_pll_200m", "sys2_pll_500m", "sys3_pll2_out",
+static const char * const imx8mq_pcie1_aux_sels[] = {"osc_25m", "sys2_pll_200m", "sys2_pll_500m", "sys3_pll_out",
"sys2_pll_100m", "sys1_pll_80m", "sys1_pll_160m", "sys1_pll_200m", };
-static const char * const imx8mq_dc_pixel_sels[] = {"osc_25m", "video_pll1_out", "audio_pll2_out", "audio_pll1_out", "sys1_pll_800m", "sys2_pll_1000m", "sys3_pll2_out", "clk_ext4", };
+static const char * const imx8mq_dc_pixel_sels[] = {"osc_25m", "video_pll1_out", "audio_pll2_out", "audio_pll1_out", "sys1_pll_800m", "sys2_pll_1000m", "sys3_pll_out", "clk_ext4", };
-static const char * const imx8mq_lcdif_pixel_sels[] = {"osc_25m", "video_pll1_out", "audio_pll2_out", "audio_pll1_out", "sys1_pll_800m", "sys2_pll_1000m", "sys3_pll2_out", "clk_ext4", };
+static const char * const imx8mq_lcdif_pixel_sels[] = {"osc_25m", "video_pll1_out", "audio_pll2_out", "audio_pll1_out", "sys1_pll_800m", "sys2_pll_1000m", "sys3_pll_out", "clk_ext4", };
static const char * const imx8mq_sai1_sels[] = {"osc_25m", "audio_pll1_out", "audio_pll2_out", "video_pll1_out", "sys1_pll_133m", "osc_27m", "clk_ext1", "clk_ext2", };
static const char * const imx8mq_sai2_sels[] = {"osc_25m", "audio_pll1_out", "audio_pll2_out", "video_pll1_out", "sys1_pll_133m", "osc_27m", "clk_ext2", "clk_ext3", };
@@ -149,44 +149,44 @@ static const char * const imx8mq_enet_timer_sels[] = {"osc_25m", "sys2_pll_100m"
static const char * const imx8mq_enet_phy_sels[] = {"osc_25m", "sys2_pll_50m", "sys2_pll_125m", "sys2_pll_500m",
"audio_pll1_out", "video_pll1_out", "audio_pll2_out", };
static const char * const imx8mq_nand_sels[] = {"osc_25m", "sys2_pll_500m", "audio_pll1_out", "sys1_pll_400m",
- "audio_pll2_out", "sys3_pll2_out", "sys2_pll_250m", "video_pll1_out", };
+ "audio_pll2_out", "sys3_pll_out", "sys2_pll_250m", "video_pll1_out", };
static const char * const imx8mq_qspi_sels[] = {"osc_25m", "sys1_pll_400m", "sys1_pll_800m", "sys2_pll_500m",
- "audio_pll2_out", "sys1_pll_266m", "sys3_pll2_out", "sys1_pll_100m", };
+ "audio_pll2_out", "sys1_pll_266m", "sys3_pll_out", "sys1_pll_100m", };
static const char * const imx8mq_usdhc1_sels[] = {"osc_25m", "sys1_pll_400m", "sys1_pll_800m", "sys2_pll_500m",
- "audio_pll2_out", "sys1_pll_266m", "sys3_pll2_out", "sys1_pll_100m", };
+ "audio_pll2_out", "sys1_pll_266m", "sys3_pll_out", "sys1_pll_100m", };
static const char * const imx8mq_usdhc2_sels[] = {"osc_25m", "sys1_pll_400m", "sys1_pll_800m", "sys2_pll_500m",
- "audio_pll2_out", "sys1_pll_266m", "sys3_pll2_out", "sys1_pll_100m", };
+ "audio_pll2_out", "sys1_pll_266m", "sys3_pll_out", "sys1_pll_100m", };
-static const char * const imx8mq_i2c1_sels[] = {"osc_25m", "sys1_pll_160m", "sys2_pll_50m", "sys3_pll2_out", "audio_pll1_out",
+static const char * const imx8mq_i2c1_sels[] = {"osc_25m", "sys1_pll_160m", "sys2_pll_50m", "sys3_pll_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out", "sys1_pll_133m", };
-static const char * const imx8mq_i2c2_sels[] = {"osc_25m", "sys1_pll_160m", "sys2_pll_50m", "sys3_pll2_out", "audio_pll1_out",
+static const char * const imx8mq_i2c2_sels[] = {"osc_25m", "sys1_pll_160m", "sys2_pll_50m", "sys3_pll_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out", "sys1_pll_133m", };
-static const char * const imx8mq_i2c3_sels[] = {"osc_25m", "sys1_pll_160m", "sys2_pll_50m", "sys3_pll2_out", "audio_pll1_out",
+static const char * const imx8mq_i2c3_sels[] = {"osc_25m", "sys1_pll_160m", "sys2_pll_50m", "sys3_pll_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out", "sys1_pll_133m", };
-static const char * const imx8mq_i2c4_sels[] = {"osc_25m", "sys1_pll_160m", "sys2_pll_50m", "sys3_pll2_out", "audio_pll1_out",
+static const char * const imx8mq_i2c4_sels[] = {"osc_25m", "sys1_pll_160m", "sys2_pll_50m", "sys3_pll_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out", "sys1_pll_133m", };
static const char * const imx8mq_uart1_sels[] = {"osc_25m", "sys1_pll_80m", "sys2_pll_200m", "sys2_pll_100m",
- "sys3_pll2_out", "clk_ext2", "clk_ext4", "audio_pll2_out", };
+ "sys3_pll_out", "clk_ext2", "clk_ext4", "audio_pll2_out", };
static const char * const imx8mq_uart2_sels[] = {"osc_25m", "sys1_pll_80m", "sys2_pll_200m", "sys2_pll_100m",
- "sys3_pll2_out", "clk_ext2", "clk_ext3", "audio_pll2_out", };
+ "sys3_pll_out", "clk_ext2", "clk_ext3", "audio_pll2_out", };
static const char * const imx8mq_uart3_sels[] = {"osc_25m", "sys1_pll_80m", "sys2_pll_200m", "sys2_pll_100m",
- "sys3_pll2_out", "clk_ext2", "clk_ext4", "audio_pll2_out", };
+ "sys3_pll_out", "clk_ext2", "clk_ext4", "audio_pll2_out", };
static const char * const imx8mq_uart4_sels[] = {"osc_25m", "sys1_pll_80m", "sys2_pll_200m", "sys2_pll_100m",
- "sys3_pll2_out", "clk_ext2", "clk_ext3", "audio_pll2_out", };
+ "sys3_pll_out", "clk_ext2", "clk_ext3", "audio_pll2_out", };
static const char * const imx8mq_usb_core_sels[] = {"osc_25m", "sys1_pll_100m", "sys1_pll_40m", "sys2_pll_100m",
"sys2_pll_200m", "clk_ext2", "clk_ext3", "audio_pll2_out", };
static const char * const imx8mq_usb_phy_sels[] = {"osc_25m", "sys1_pll_100m", "sys1_pll_40m", "sys2_pll_100m",
@@ -194,83 +194,83 @@ static const char * const imx8mq_usb_phy_sels[] = {"osc_25m", "sys1_pll_100m", "
static const char * const imx8mq_gic_sels[] = {"osc_25m", "sys2_pll_200m", "sys1_pll_40m", "sys2_pll_100m",
"sys2_pll_200m", "clk_ext2", "clk_ext3", "audio_pll2_out" };
static const char * const imx8mq_ecspi1_sels[] = {"osc_25m", "sys2_pll_200m", "sys1_pll_40m", "sys1_pll_160m",
- "sys1_pll_800m", "sys3_pll2_out", "sys2_pll_250m", "audio_pll2_out", };
+ "sys1_pll_800m", "sys3_pll_out", "sys2_pll_250m", "audio_pll2_out", };
static const char * const imx8mq_ecspi2_sels[] = {"osc_25m", "sys2_pll_200m", "sys1_pll_40m", "sys1_pll_160m",
- "sys1_pll_800m", "sys3_pll2_out", "sys2_pll_250m", "audio_pll2_out", };
+ "sys1_pll_800m", "sys3_pll_out", "sys2_pll_250m", "audio_pll2_out", };
static const char * const imx8mq_pwm1_sels[] = {"osc_25m", "sys2_pll_100m", "sys1_pll_160m", "sys1_pll_40m",
- "sys3_pll2_out", "clk_ext1", "sys1_pll_80m", "video_pll1_out", };
+ "sys3_pll_out", "clk_ext1", "sys1_pll_80m", "video_pll1_out", };
static const char * const imx8mq_pwm2_sels[] = {"osc_25m", "sys2_pll_100m", "sys1_pll_160m", "sys1_pll_40m",
- "sys3_pll2_out", "clk_ext1", "sys1_pll_80m", "video_pll1_out", };
+ "sys3_pll_out", "clk_ext1", "sys1_pll_80m", "video_pll1_out", };
static const char * const imx8mq_pwm3_sels[] = {"osc_25m", "sys2_pll_100m", "sys1_pll_160m", "sys1_pll_40m",
- "sys3_pll2_out", "clk_ext2", "sys1_pll_80m", "video_pll1_out", };
+ "sys3_pll_out", "clk_ext2", "sys1_pll_80m", "video_pll1_out", };
static const char * const imx8mq_pwm4_sels[] = {"osc_25m", "sys2_pll_100m", "sys1_pll_160m", "sys1_pll_40m",
- "sys3_pll2_out", "clk_ext2", "sys1_pll_80m", "video_pll1_out", };
+ "sys3_pll_out", "clk_ext2", "sys1_pll_80m", "video_pll1_out", };
static const char * const imx8mq_gpt1_sels[] = {"osc_25m", "sys2_pll_100m", "sys1_pll_400m", "sys1_pll_40m",
"sys1_pll_80m", "audio_pll1_out", "clk_ext1", };
static const char * const imx8mq_wdog_sels[] = {"osc_25m", "sys1_pll_133m", "sys1_pll_160m", "vpu_pll_out",
- "sys2_pll_125m", "sys3_pll2_out", "sys1_pll_80m", "sys2_pll_166m", };
+ "sys2_pll_125m", "sys3_pll_out", "sys1_pll_80m", "sys2_pll_166m", };
-static const char * const imx8mq_wrclk_sels[] = {"osc_25m", "sys1_pll_40m", "vpu_pll_out", "sys3_pll2_out", "sys2_pll_200m",
+static const char * const imx8mq_wrclk_sels[] = {"osc_25m", "sys1_pll_40m", "vpu_pll_out", "sys3_pll_out", "sys2_pll_200m",
"sys1_pll_266m", "sys2_pll_500m", "sys1_pll_100m", };
static const char * const imx8mq_dsi_core_sels[] = {"osc_25m", "sys1_pll_266m", "sys2_pll_250m", "sys1_pll_800m",
- "sys2_pll_1000m", "sys3_pll2_out", "audio_pll2_out", "video_pll1_out", };
+ "sys2_pll_1000m", "sys3_pll_out", "audio_pll2_out", "video_pll1_out", };
static const char * const imx8mq_dsi_phy_sels[] = {"osc_25m", "sys2_pll_125m", "sys2_pll_100m", "sys1_pll_800m",
"sys2_pll_1000m", "clk_ext2", "audio_pll2_out", "video_pll1_out", };
static const char * const imx8mq_dsi_dbi_sels[] = {"osc_25m", "sys1_pll_266m", "sys2_pll_100m", "sys1_pll_800m",
- "sys2_pll_1000m", "sys3_pll2_out", "audio_pll2_out", "video_pll1_out", };
+ "sys2_pll_1000m", "sys3_pll_out", "audio_pll2_out", "video_pll1_out", };
static const char * const imx8mq_dsi_esc_sels[] = {"osc_25m", "sys2_pll_100m", "sys1_pll_80m", "sys1_pll_800m",
- "sys2_pll_1000m", "sys3_pll2_out", "clk_ext3", "audio_pll2_out", };
+ "sys2_pll_1000m", "sys3_pll_out", "clk_ext3", "audio_pll2_out", };
static const char * const imx8mq_csi1_core_sels[] = {"osc_25m", "sys1_pll_266m", "sys2_pll_250m", "sys1_pll_800m",
- "sys2_pll_1000m", "sys3_pll2_out", "audio_pll2_out", "video_pll1_out", };
+ "sys2_pll_1000m", "sys3_pll_out", "audio_pll2_out", "video_pll1_out", };
static const char * const imx8mq_csi1_phy_sels[] = {"osc_25m", "sys2_pll_125m", "sys2_pll_100m", "sys1_pll_800m",
"sys2_pll_1000m", "clk_ext2", "audio_pll2_out", "video_pll1_out", };
static const char * const imx8mq_csi1_esc_sels[] = {"osc_25m", "sys2_pll_100m", "sys1_pll_80m", "sys1_pll_800m",
- "sys2_pll_1000m", "sys3_pll2_out", "clk_ext3", "audio_pll2_out", };
+ "sys2_pll_1000m", "sys3_pll_out", "clk_ext3", "audio_pll2_out", };
static const char * const imx8mq_csi2_core_sels[] = {"osc_25m", "sys1_pll_266m", "sys2_pll_250m", "sys1_pll_800m",
- "sys2_pll_1000m", "sys3_pll2_out", "audio_pll2_out", "video_pll1_out", };
+ "sys2_pll_1000m", "sys3_pll_out", "audio_pll2_out", "video_pll1_out", };
static const char * const imx8mq_csi2_phy_sels[] = {"osc_25m", "sys2_pll_125m", "sys2_pll_100m", "sys1_pll_800m",
"sys2_pll_1000m", "clk_ext2", "audio_pll2_out", "video_pll1_out", };
static const char * const imx8mq_csi2_esc_sels[] = {"osc_25m", "sys2_pll_100m", "sys1_pll_80m", "sys1_pll_800m",
- "sys2_pll_1000m", "sys3_pll2_out", "clk_ext3", "audio_pll2_out", };
+ "sys2_pll_1000m", "sys3_pll_out", "clk_ext3", "audio_pll2_out", };
static const char * const imx8mq_pcie2_ctrl_sels[] = {"osc_25m", "sys2_pll_250m", "sys2_pll_200m", "sys1_pll_266m",
- "sys1_pll_800m", "sys2_pll_500m", "sys2_pll_333m", "sys3_pll2_out", };
+ "sys1_pll_800m", "sys2_pll_500m", "sys2_pll_333m", "sys3_pll_out", };
static const char * const imx8mq_pcie2_phy_sels[] = {"osc_25m", "sys2_pll_100m", "sys2_pll_500m", "clk_ext1",
"clk_ext2", "clk_ext3", "clk_ext4", "sys1_pll_400m", };
-static const char * const imx8mq_pcie2_aux_sels[] = {"osc_25m", "sys2_pll_200m", "sys2_pll_50m", "sys3_pll2_out",
+static const char * const imx8mq_pcie2_aux_sels[] = {"osc_25m", "sys2_pll_200m", "sys2_pll_50m", "sys3_pll_out",
"sys2_pll_100m", "sys1_pll_80m", "sys1_pll_160m", "sys1_pll_200m", };
static const char * const imx8mq_ecspi3_sels[] = {"osc_25m", "sys2_pll_200m", "sys1_pll_40m", "sys1_pll_160m",
- "sys1_pll_800m", "sys3_pll2_out", "sys2_pll_250m", "audio_pll2_out", };
+ "sys1_pll_800m", "sys3_pll_out", "sys2_pll_250m", "audio_pll2_out", };
static const char * const imx8mq_dram_core_sels[] = {"dram_pll_out", "dram_alt_root", };
static const char * const imx8mq_clko1_sels[] = {"osc_25m", "sys1_pll_800m", "osc_27m", "sys1_pll_200m",
"audio_pll2_out", "sys2_pll_500m", "vpu_pll_out", "sys1_pll_80m", };
static const char * const imx8mq_clko2_sels[] = {"osc_25m", "sys2_pll_200m", "sys1_pll_400m", "sys2_pll_166m",
- "sys3_pll2_out", "audio_pll1_out", "video_pll1_out", "ckil", };
+ "sys3_pll_out", "audio_pll1_out", "video_pll1_out", "ckil", };
static struct clk_onecell_data clk_data;
static struct clk ** const uart_clks[] = {
&clks[IMX8MQ_CLK_UART1_ROOT],
--
2.17.1
_______________________________________________
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 3/4] clk: imx8mn: Fix incorrect parents
From: Leonard Crestez @ 2019-08-13 17:05 UTC (permalink / raw)
To: Jacky Bai, Abel Vesa, Stephen Boyd, Shawn Guo
Cc: Dong Aisheng, Anson Huang, Michael Turquette, linux-imx, kernel,
Fabio Estevam, linux-clk, linux-arm-kernel
In-Reply-To: <cover.1565715590.git.leonard.crestez@nxp.com>
* Replace to audio_pll2_clk with audio_pll2_out
* Replace sys3_pll2_out with sys_pll3_out
* Replace sys1_pll_40m with sys_pll1_40m
* qspi parent[2] is sys_pll2_333m not sys_pll1_800m
Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/clk/imx/clk-imx8mn.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index ecd1062f6847..106cc417c19b 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -138,11 +138,11 @@ static const char * const imx8mn_nand_usdhc_sels[] = {"osc_24m", "sys_pll1_266m"
static const char * const imx8mn_disp_axi_sels[] = {"osc_24m", "sys_pll2_1000m", "sys_pll1_800m",
"sys_pll3_out", "sys_pll1_40m", "audio_pll2_out",
"clk_ext1", "clk_ext4", };
static const char * const imx8mn_disp_apb_sels[] = {"osc_24m", "sys_pll2_125m", "sys_pll1_800m",
- "sys_pll3_out", "sys1_pll_40m", "audio_pll2_out",
+ "sys_pll3_out", "sys_pll1_40m", "audio_pll2_out",
"clk_ext1", "clk_ext3", };
static const char * const imx8mn_usb_bus_sels[] = {"osc_24m", "sys_pll2_500m", "sys_pll1_800m",
"sys_pll2_100m", "sys_pll2_200m", "clk_ext2",
"clk_ext4", "audio_pll2_out", };
@@ -217,13 +217,13 @@ static const char * const imx8mn_enet_phy_sels[] = {"osc_24m", "sys_pll2_50m", "
static const char * const imx8mn_nand_sels[] = {"osc_24m", "sys_pll2_500m", "audio_pll1_out",
"sys_pll1_400m", "audio_pll2_out", "sys_pll3_out",
"sys_pll2_250m", "video_pll1_out", };
-static const char * const imx8mn_qspi_sels[] = {"osc_24m", "sys1_pll_400m", "sys_pll1_800m",
- "sys2_pll_500m", "audio_pll2_out", "sys1_pll_266m",
- "sys3_pll2_out", "sys1_pll_100m", };
+static const char * const imx8mn_qspi_sels[] = {"osc_24m", "sys_pll1_400m", "sys_pll2_333m",
+ "sys_pll2_500m", "audio_pll2_out", "sys_pll1_266m",
+ "sys_pll3_out", "sys_pll1_100m", };
static const char * const imx8mn_usdhc1_sels[] = {"osc_24m", "sys_pll1_400m", "sys_pll1_800m",
"sys_pll2_500m", "sys_pll3_out", "sys_pll1_266m",
"audio_pll2_out", "sys_pll1_100m", };
@@ -286,11 +286,11 @@ static const char * const imx8mn_pwm1_sels[] = {"osc_24m", "sys_pll2_100m", "sys
static const char * const imx8mn_pwm2_sels[] = {"osc_24m", "sys_pll2_100m", "sys_pll1_160m",
"sys_pll1_40m", "sys_pll3_out", "clk_ext1",
"sys_pll1_80m", "video_pll1_out", };
static const char * const imx8mn_pwm3_sels[] = {"osc_24m", "sys_pll2_100m", "sys_pll1_160m",
- "sys_pll1_40m", "sys3_pll2_out", "clk_ext2",
+ "sys_pll1_40m", "sys_pll3_out", "clk_ext2",
"sys_pll1_80m", "video_pll1_out", };
static const char * const imx8mn_pwm4_sels[] = {"osc_24m", "sys_pll2_100m", "sys_pll1_160m",
"sys_pll1_40m", "sys_pll3_out", "clk_ext2",
"sys_pll1_80m", "video_pll1_out", };
@@ -315,11 +315,11 @@ static const char * const imx8mn_dsi_dbi_sels[] = {"osc_24m", "sys_pll1_266m", "
"sys_pll1_800m", "sys_pll2_1000m", "sys_pll3_out",
"audio_pll2_out", "video_pll1_out", };
static const char * const imx8mn_usdhc3_sels[] = {"osc_24m", "sys_pll1_400m", "sys_pll1_800m",
"sys_pll2_500m", "sys_pll3_out", "sys_pll1_266m",
- "audio_pll2_clk", "sys_pll1_100m", };
+ "audio_pll2_out", "sys_pll1_100m", };
static const char * const imx8mn_camera_pixel_sels[] = {"osc_24m", "sys_pll1_266m", "sys_pll2_250m",
"sys_pll1_800m", "sys_pll2_1000m", "sys_pll3_out",
"audio_pll2_out", "video_pll1_out", };
@@ -344,11 +344,11 @@ static const char * const imx8mn_pdm_sels[] = {"osc_24m", "sys_pll2_100m", "audi
"clk_ext3", "audio_pll2_out", };
static const char * const imx8mn_dram_core_sels[] = {"dram_pll_out", "dram_alt_root", };
static const char * const imx8mn_clko1_sels[] = {"osc_24m", "sys_pll1_800m", "osc_27m",
- "sys_pll1_200m", "audio_pll2_clk", "vpu_pll",
+ "sys_pll1_200m", "audio_pll2_out", "vpu_pll",
"sys_pll1_80m", };
static const char * const imx8mn_clko2_sels[] = {"osc_24m", "sys_pll2_200m", "sys_pll1_400m",
"sys_pll2_166m", "sys_pll3_out", "audio_pll1_out",
"video_pll1_out", "osc_32k", };
--
2.17.1
_______________________________________________
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 0/4] clk: imx8m: Fix incorrect parents
From: Leonard Crestez @ 2019-08-13 17:05 UTC (permalink / raw)
To: Jacky Bai, Abel Vesa, Stephen Boyd, Shawn Guo
Cc: Dong Aisheng, Anson Huang, Michael Turquette, linux-imx, kernel,
Fabio Estevam, linux-clk, linux-arm-kernel
No checks are made to ensure the parents in the _sels arrays actually
exist and it turns out that several are incorrect.
I found the errors using a hack to clk core, is there a better way?
Link: https://github.com/cdleonard/linux/commit/da32c2e76eb373e8a03aec905af2eef28a7997a7
Also add imx8mn GIC clock while we're at it because otherwise parent
could get disabled and lock the system.
Leonard Crestez (4):
clk: imx8mq: Fix sys3 pll references
clk: imx8mm: Fix incorrect parents
clk: imx8mn: Fix incorrect parents
clk: imx8mn: Add GIC clock
drivers/clk/imx/clk-imx8mm.c | 8 +-
drivers/clk/imx/clk-imx8mn.c | 19 ++--
drivers/clk/imx/clk-imx8mq.c | 112 +++++++++++------------
include/dt-bindings/clock/imx8mn-clock.h | 3 +-
4 files changed, 74 insertions(+), 68 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/4] clk: imx8mm: Fix incorrect parents
From: Leonard Crestez @ 2019-08-13 17:05 UTC (permalink / raw)
To: Jacky Bai, Abel Vesa, Stephen Boyd, Shawn Guo
Cc: Dong Aisheng, Anson Huang, Michael Turquette, linux-imx, kernel,
Fabio Estevam, linux-clk, linux-arm-kernel
In-Reply-To: <cover.1565715590.git.leonard.crestez@nxp.com>
* There is no video_pll2 on imx8mm, replace with dummy
* Replace reference to sys_pll3_clk with sys_pll3_out
* qspi parent[2] is sys_pll2_333m not sys_pll1_800m
Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm")
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/clk/imx/clk-imx8mm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 69ec274d4974..2758e3f0d15d 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -173,14 +173,14 @@ static const char *imx8mm_vpu_g1_sels[] = {"osc_24m", "vpu_pll_out", "sys_pll1_8
"sys_pll1_100m", "sys_pll2_125m", "sys_pll3_out", "audio_pll1_out", };
static const char *imx8mm_vpu_g2_sels[] = {"osc_24m", "vpu_pll_out", "sys_pll1_800m", "sys_pll2_1000m",
"sys_pll1_100m", "sys_pll2_125m", "sys_pll3_out", "audio_pll1_out", };
-static const char *imx8mm_disp_dtrc_sels[] = {"osc_24m", "video_pll2_out", "sys_pll1_800m", "sys_pll2_1000m",
+static const char *imx8mm_disp_dtrc_sels[] = {"osc_24m", "dummy", "sys_pll1_800m", "sys_pll2_1000m",
"sys_pll1_160m", "video_pll1_out", "sys_pll3_out", "audio_pll2_out", };
-static const char *imx8mm_disp_dc8000_sels[] = {"osc_24m", "video_pll2_out", "sys_pll1_800m", "sys_pll2_1000m",
+static const char *imx8mm_disp_dc8000_sels[] = {"osc_24m", "dummy", "sys_pll1_800m", "sys_pll2_1000m",
"sys_pll1_160m", "video_pll1_out", "sys_pll3_out", "audio_pll2_out", };
static const char *imx8mm_pcie1_ctrl_sels[] = {"osc_24m", "sys_pll2_250m", "sys_pll2_200m", "sys_pll1_266m",
"sys_pll1_800m", "sys_pll2_500m", "sys_pll2_333m", "sys_pll3_out", };
@@ -230,11 +230,11 @@ static const char *imx8mm_enet_phy_sels[] = {"osc_24m", "sys_pll2_50m", "sys_pll
"sys_pll2_500m", "video_pll1_out", "audio_pll2_out", };
static const char *imx8mm_nand_sels[] = {"osc_24m", "sys_pll2_500m", "audio_pll1_out", "sys_pll1_400m",
"audio_pll2_out", "sys_pll3_out", "sys_pll2_250m", "video_pll1_out", };
-static const char *imx8mm_qspi_sels[] = {"osc_24m", "sys_pll1_400m", "sys_pll1_800m", "sys_pll2_500m",
+static const char *imx8mm_qspi_sels[] = {"osc_24m", "sys_pll1_400m", "sys_pll2_333m", "sys_pll2_500m",
"audio_pll2_out", "sys_pll1_266m", "sys_pll3_out", "sys_pll1_100m", };
static const char *imx8mm_usdhc1_sels[] = {"osc_24m", "sys_pll1_400m", "sys_pll1_800m", "sys_pll2_500m",
"sys_pll3_out", "sys_pll1_266m", "audio_pll2_out", "sys_pll1_100m", };
@@ -345,11 +345,11 @@ static const char *imx8mm_ecspi3_sels[] = {"osc_24m", "sys_pll2_200m", "sys_pll1
static const char *imx8mm_pdm_sels[] = {"osc_24m", "sys_pll2_100m", "audio_pll1_out", "sys_pll1_800m",
"sys_pll2_1000m", "sys_pll3_out", "clk_ext3", "audio_pll2_out", };
static const char *imx8mm_vpu_h1_sels[] = {"osc_24m", "vpu_pll_out", "sys_pll1_800m", "sys_pll2_1000m",
- "audio_pll2_out", "sys_pll2_125m", "sys_pll3_clk", "audio_pll1_out", };
+ "audio_pll2_out", "sys_pll2_125m", "sys_pll3_out", "audio_pll1_out", };
static const char *imx8mm_dram_core_sels[] = {"dram_pll_out", "dram_alt_root", };
static const char *imx8mm_clko1_sels[] = {"osc_24m", "sys_pll1_800m", "osc_27m", "sys_pll1_200m", "audio_pll2_out",
"vpu_pll", "sys_pll1_80m", };
--
2.17.1
_______________________________________________
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 8/8] arm64: memory: Cosmetic cleanups
From: Will Deacon @ 2019-08-13 17:01 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Steve Capper, Catalin Marinas, Qian Cai,
Andrey Konovalov, Geert Uytterhoeven, Will Deacon
In-Reply-To: <20190813170149.26037-1-will@kernel.org>
Cleanup memory.h so that the indentation is consistent, remove pointless
line-wrapping and use consistent parameter names for different versions
of the same macro.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/memory.h | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index d31e4b6e349f..69f4cecb7241 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -12,10 +12,10 @@
#include <linux/compiler.h>
#include <linux/const.h>
+#include <linux/sizes.h>
#include <linux/types.h>
#include <asm/bug.h>
#include <asm/page-def.h>
-#include <linux/sizes.h>
/*
* Size of the PCI I/O space. This must remain a power of two so that
@@ -66,8 +66,8 @@
#define _VA_START(va) (-(UL(1) << ((va) - 1)))
-#define KERNEL_START _text
-#define KERNEL_END _end
+#define KERNEL_START _text
+#define KERNEL_END _end
#ifdef CONFIG_ARM64_VA_BITS_52
#define MAX_USER_VA_BITS 52
@@ -132,14 +132,14 @@
* 16 KB granule: 128 level 3 entries, with contiguous bit
* 64 KB granule: 32 level 3 entries, with contiguous bit
*/
-#define SEGMENT_ALIGN SZ_2M
+#define SEGMENT_ALIGN SZ_2M
#else
/*
* 4 KB granule: 16 level 3 entries, with contiguous bit
* 16 KB granule: 4 level 3 entries, without contiguous bit
* 64 KB granule: 1 level 3 entry
*/
-#define SEGMENT_ALIGN SZ_64K
+#define SEGMENT_ALIGN SZ_64K
#endif
/*
@@ -253,8 +253,7 @@ static inline const void *__tag_set(const void *addr, u8 tag)
#define __virt_to_phys_nodebug(x) ({ \
phys_addr_t __x = (phys_addr_t)(__tag_reset(x)); \
- __is_lm_address(__x) ? __lm_to_phys(__x) : \
- __kimg_to_phys(__x); \
+ __is_lm_address(__x) ? __lm_to_phys(__x) : __kimg_to_phys(__x); \
})
#define __pa_symbol_nodebug(x) __kimg_to_phys((phys_addr_t)(x))
@@ -301,17 +300,17 @@ static inline void *phys_to_virt(phys_addr_t x)
#define __pa_nodebug(x) __virt_to_phys_nodebug((unsigned long)(x))
#define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
-#define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
-#define sym_to_pfn(x) __phys_to_pfn(__pa_symbol(x))
+#define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
+#define sym_to_pfn(x) __phys_to_pfn(__pa_symbol(x))
/*
- * virt_to_page(k) convert a _valid_ virtual address to struct page *
- * virt_addr_valid(k) indicates whether a virtual address is valid
+ * virt_to_page(x) convert a _valid_ virtual address to struct page *
+ * virt_addr_valid(x) indicates whether a virtual address is valid
*/
#define ARCH_PFN_OFFSET ((unsigned long)PHYS_PFN_OFFSET)
#if !defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_DEBUG_VIRTUAL)
-#define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr))
+#define virt_to_page(x) pfn_to_page(virt_to_pfn(x))
#else
#define page_to_virt(x) ({ \
__typeof__(x) __page = x; \
--
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
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