* 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 3/8] arm64: memory: Rewrite default page_to_virt()/virt_to_page()
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-4-will@kernel.org>
On Tue, Aug 13, 2019 at 06:01:44PM +0100, Will Deacon wrote:
> The default implementations of page_to_virt() and virt_to_page() are
> fairly confusing to read and the former evaluates its 'page' parameter
> twice in the macro
>
> Rewrite them so that the computation is expressed as 'base + index' in
> both cases and the parameter is always evaluated exactly once.
>
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Steve Capper <steve.capper@arm.com>
> ---
> arch/arm64/include/asm/memory.h | 21 ++++++++++-----------
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 47b4dc73b8bf..77074b3a1025 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -313,19 +313,18 @@ static inline void *phys_to_virt(phys_addr_t x)
> #if !defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_DEBUG_VIRTUAL)
> #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
> #else
> -#define __virt_to_pgoff(kaddr) (((u64)(kaddr) - PAGE_OFFSET) / PAGE_SIZE * sizeof(struct page))
> -#define __page_to_voff(kaddr) (((u64)(kaddr) - VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
> -
> -#define page_to_virt(page) ({ \
> - unsigned long __addr = \
> - ((__page_to_voff(page)) + PAGE_OFFSET); \
> - const void *__addr_tag = \
> - __tag_set((void *)__addr, page_kasan_tag(page)); \
> - ((void *)__addr_tag); \
> +#define page_to_virt(x) ({ \
> + __typeof__(x) __page = x; \
> + u64 __idx = ((u64)__page - VMEMMAP_START) / sizeof(struct page);\
> + u64 __addr = PAGE_OFFSET + (__idx * PAGE_SIZE); \
> + (void *)__tag_set((const void *)__addr, page_kasan_tag(__page));\
> })
>
> -#define virt_to_page(vaddr) \
> - ((struct page *)((__virt_to_pgoff(__tag_reset(vaddr))) + VMEMMAP_START))
> +#define virt_to_page(x) ({ \
> + u64 __idx = (__tag_reset((u64)x) - PAGE_OFFSET) / PAGE_SIZE; \
> + u64 __addr = VMEMMAP_START + (__idx * sizeof(struct page)); \
> + (struct page *)__addr; \
> +})
> #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 4/8] arm64: memory: Simplify virt_to_page() implementation
From: Steve Capper @ 2019-08-13 18:55 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-5-will@kernel.org>
On Tue, Aug 13, 2019 at 06:01:45PM +0100, Will Deacon wrote:
> Build virt_to_page() on top of virt_to_pfn() so we can avoid the need
> for explicit shifting.
>
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Steve Capper <steve.capper@arm.com>
> ---
> arch/arm64/include/asm/memory.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 77074b3a1025..56be462c69ce 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -311,7 +311,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> #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(__pa(kaddr) >> PAGE_SHIFT)
> +#define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr))
> #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
* Re: [PATCH 5/8] arm64: memory: Simplify _VA_START and _PAGE_OFFSET definitions
From: Steve Capper @ 2019-08-13 18:55 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-6-will@kernel.org>
On Tue, Aug 13, 2019 at 06:01:46PM +0100, Will Deacon wrote:
> Rather than subtracting from -1 and then adding 1, we can simply
> subtract from 0.
>
> Cc: Steve Capper <steve.capper@arm.com>
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Steve Capper <steve.capper@arm.com>
> ---
> arch/arm64/include/asm/memory.h | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 56be462c69ce..5552c8cba1e2 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -44,8 +44,7 @@
> * VA_START - the first kernel virtual address.
> */
> #define VA_BITS (CONFIG_ARM64_VA_BITS)
> -#define _PAGE_OFFSET(va) (UL(0xffffffffffffffff) - \
> - (UL(1) << (va)) + 1)
> +#define _PAGE_OFFSET(va) (-(UL(1) << (va)))
> #define PAGE_OFFSET (_PAGE_OFFSET(VA_BITS))
> #define KIMAGE_VADDR (MODULES_END)
> #define BPF_JIT_REGION_START (KASAN_SHADOW_END)
> @@ -63,8 +62,7 @@
> #else
> #define VA_BITS_MIN (VA_BITS)
> #endif
> -#define _VA_START(va) (UL(0xffffffffffffffff) - \
> - (UL(1) << ((va) - 1)) + 1)
> +#define _VA_START(va) (-(UL(1) << ((va) - 1)))
>
> #define KERNEL_START _text
> #define KERNEL_END _end
> --
> 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 6/8] arm64: memory: Implement __tag_set() as common function
From: Steve Capper @ 2019-08-13 18:56 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-7-will@kernel.org>
On Tue, Aug 13, 2019 at 06:01:47PM +0100, Will Deacon wrote:
> There's no need for __tag_set() to be a complicated macro when
> CONFIG_KASAN_SW_TAGS=y and a simple static inline otherwise. Rewrite
> the thing as a common static inline function.
>
> 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 5552c8cba1e2..e902132b808c 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -218,20 +218,20 @@ static inline unsigned long kaslr_offset(void)
>
> #ifdef CONFIG_KASAN_SW_TAGS
> #define __tag_shifted(tag) ((u64)(tag) << 56)
> -#define __tag_set(addr, tag) (__typeof__(addr))( \
> - ((u64)(addr) & ~__tag_shifted(0xff)) | __tag_shifted(tag))
> #define __tag_reset(addr) untagged_addr(addr)
> #define __tag_get(addr) (__u8)((u64)(addr) >> 56)
> #else
> -static inline const void *__tag_set(const void *addr, u8 tag)
> -{
> - return addr;
> -}
> -
> +#define __tag_shifted(tag) 0UL
> #define __tag_reset(addr) (addr)
> #define __tag_get(addr) 0
> #endif
>
> +static inline const void *__tag_set(const void *addr, u8 tag)
> +{
> + u64 __addr = (u64)addr & ~__tag_shifted(0xff);
> + return (const void *)(__addr | __tag_shifted(tag));
> +}
> +
> /*
> * Physical vs virtual RAM address space conversion. These are
> * private definitions which should NOT be used outside memory.h
> --
> 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 7/8] arm64: memory: Add comments to end of non-trivial #ifdef blocks
From: Steve Capper @ 2019-08-13 18:57 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-8-will@kernel.org>
On Tue, Aug 13, 2019 at 06:01:48PM +0100, Will Deacon wrote:
> Commenting the #endif of a multi-statement #ifdef block with the
> condition which guards it is useful and can save having to scroll back
> through the file to figure out which set of Kconfig options apply to
> a particular piece of code.
>
> 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, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index e902132b808c..d31e4b6e349f 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -57,11 +57,13 @@
> #define PCI_IO_END (VMEMMAP_START - SZ_2M)
> #define PCI_IO_START (PCI_IO_END - PCI_IO_SIZE)
> #define FIXADDR_TOP (PCI_IO_START - SZ_2M)
> +
> #if VA_BITS > 48
> #define VA_BITS_MIN (48)
> #else
> #define VA_BITS_MIN (VA_BITS)
> #endif
> +
> #define _VA_START(va) (-(UL(1) << ((va) - 1)))
>
> #define KERNEL_START _text
> @@ -86,7 +88,7 @@
> #else
> #define KASAN_THREAD_SHIFT 0
> #define KASAN_SHADOW_END (_VA_START(VA_BITS_MIN))
> -#endif
> +#endif /* CONFIG_KASAN */
>
> #define MIN_THREAD_SHIFT (14 + KASAN_THREAD_SHIFT)
>
> @@ -224,7 +226,7 @@ static inline unsigned long kaslr_offset(void)
> #define __tag_shifted(tag) 0UL
> #define __tag_reset(addr) (addr)
> #define __tag_get(addr) 0
> -#endif
> +#endif /* CONFIG_KASAN_SW_TAGS */
>
> static inline const void *__tag_set(const void *addr, u8 tag)
> {
> @@ -263,7 +265,7 @@ extern phys_addr_t __phys_addr_symbol(unsigned long x);
> #else
> #define __virt_to_phys(x) __virt_to_phys_nodebug(x)
> #define __phys_addr_symbol(x) __pa_symbol_nodebug(x)
> -#endif
> +#endif /* CONFIG_DEBUG_VIRTUAL */
>
> #define __phys_to_virt(x) ((unsigned long)((x) - physvirt_offset))
> #define __phys_to_kimg(x) ((unsigned long)((x) + kimage_voffset))
> @@ -323,14 +325,14 @@ static inline void *phys_to_virt(phys_addr_t x)
> u64 __addr = VMEMMAP_START + (__idx * sizeof(struct page)); \
> (struct page *)__addr; \
> })
> -#endif
> +#endif /* !CONFIG_SPARSEMEM_VMEMMAP || CONFIG_DEBUG_VIRTUAL */
>
> #define virt_addr_valid(addr) ({ \
> __typeof__(addr) __addr = addr; \
> __is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr)); \
> })
>
> -#endif
> +#endif /* !ASSEMBLY */
>
> /*
> * Given that the GIC architecture permits ITS implementations that can only be
> @@ -345,4 +347,4 @@ static inline void *phys_to_virt(phys_addr_t x)
>
> #include <asm-generic/memory_model.h>
>
> -#endif
> +#endif /* __ASM_MEMORY_H */
> --
> 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 8/8] arm64: memory: Cosmetic cleanups
From: Steve Capper @ 2019-08-13 18:57 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-9-will@kernel.org>
On Tue, Aug 13, 2019 at 06:01:49PM +0100, Will Deacon wrote:
> 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>
Reviewed-by: Steve Capper <steve.capper@arm.com>
> ---
> 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
* Re: [PATCH 2/2] arm64: Don't use KPTI where we have E0PD
From: Mark Brown @ 2019-08-13 19:05 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, linux-arm-kernel
In-Reply-To: <20190813172836.vbotnv35w3w62b2y@willie-the-truck>
[-- Attachment #1.1: Type: text/plain, Size: 1225 bytes --]
On Tue, Aug 13, 2019 at 06:28:36PM +0100, Will Deacon wrote:
> On Mon, Aug 12, 2019 at 01:57:38PM +0100, Mark Brown wrote:
> > 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.
Hrm, yeah - they are if I not only turn on RANDOMIZE_BASE but also
ensure KASLR gets a seed it'll pay attention to passed. I had been
testing with it on but changes I'd made in the test environment to pass
a seed in had been broken so it silently wasn't actually doing anything.
The simplest thing would just be to add an IS_ENABLED() check in
_use_ng_mappings() which I've verifed does the right thing at the
expense of requiring the remapping later, but obviously that's a useful
optimization so we should really check the FTR.
[-- 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 15/15] iommu/arm-smmu: Add context init implementation hook
From: Krishna Reddy @ 2019-08-13 19:11 UTC (permalink / raw)
To: Robin Murphy, will@kernel.org
Cc: gregory.clement@bootlin.com, robdclark@gmail.com,
bjorn.andersson@linaro.org, iommu@lists.linux-foundation.org,
vivek.gautam@codeaurora.org, joro@8bytes.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <6adbec8e4757f3b6c9f47135544a0302f8e7c55c.1565369764.git.robin.murphy@arm.com>
Tested-by: Krishna Reddy<vdumpa@nvidia.com>
Validated the entire patch set on Tegra194 SOC based platform and confirmed that arm-smmu driver is functional as it has been.
-KR
-----Original Message-----
From: Robin Murphy <robin.murphy@arm.com>
Sent: Friday, August 9, 2019 10:08 AM
To: will@kernel.org
Cc: iommu@lists.linux-foundation.org; linux-arm-kernel@lists.infradead.org; joro@8bytes.org; vivek.gautam@codeaurora.org; bjorn.andersson@linaro.org; Krishna Reddy <vdumpa@nvidia.com>; gregory.clement@bootlin.com; robdclark@gmail.com
Subject: [PATCH 15/15] iommu/arm-smmu: Add context init implementation hook
Allocating and initialising a context for a domain is another point where certain implementations are known to want special behaviour.
Currently the other half of the Cavium workaround comes into play here, so let's finish the job to get the whole thing right out of the way.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu-impl.c | 39 +++++++++++++++++++++++++--
drivers/iommu/arm-smmu.c | 51 +++++++----------------------------
drivers/iommu/arm-smmu.h | 42 +++++++++++++++++++++++++++--
3 files changed, 86 insertions(+), 46 deletions(-)
diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c index c8904da08354..7a657d47b6ec 100644
--- a/drivers/iommu/arm-smmu-impl.c
+++ b/drivers/iommu/arm-smmu-impl.c
@@ -48,6 +48,12 @@ const struct arm_smmu_impl calxeda_impl = { };
+struct cavium_smmu {
+ struct arm_smmu_device smmu;
+ u32 id_base;
+};
+#define to_csmmu(s) container_of(s, struct cavium_smmu, smmu)
+
static int cavium_cfg_probe(struct arm_smmu_device *smmu) {
static atomic_t context_count = ATOMIC_INIT(0); @@ -56,17 +62,46 @@ static int cavium_cfg_probe(struct arm_smmu_device *smmu)
* Ensure ASID and VMID allocation is unique across all SMMUs in
* the system.
*/
- smmu->cavium_id_base = atomic_fetch_add(smmu->num_context_banks,
+ to_csmmu(smmu)->id_base = atomic_fetch_add(smmu->num_context_banks,
&context_count);
dev_notice(smmu->dev, "\tenabling workaround for Cavium erratum 27704\n");
return 0;
}
+int cavium_init_context(struct arm_smmu_domain *smmu_domain) {
+ u32 id_base = to_csmmu(smmu_domain->smmu)->id_base;
+
+ if (smmu_domain->stage == ARM_SMMU_DOMAIN_S2)
+ smmu_domain->cfg.vmid += id_base;
+ else
+ smmu_domain->cfg.asid += id_base;
+
+ return 0;
+}
+
const struct arm_smmu_impl cavium_impl = {
.cfg_probe = cavium_cfg_probe,
+ .init_context = cavium_init_context,
};
+struct arm_smmu_device *cavium_smmu_impl_init(struct arm_smmu_device
+*smmu) {
+ struct cavium_smmu *csmmu;
+
+ csmmu = devm_kzalloc(smmu->dev, sizeof(*csmmu), GFP_KERNEL);
+ if (!csmmu)
+ return ERR_PTR(-ENOMEM);
+
+ csmmu->smmu = *smmu;
+ csmmu->smmu.impl = &cavium_impl;
+
+ devm_kfree(smmu->dev, smmu);
+
+ return &csmmu->smmu;
+}
+
#define ARM_MMU500_ACTLR_CPRE (1 << 1)
@@ -121,7 +156,7 @@ struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
smmu->impl = &calxeda_impl;
if (smmu->model == CAVIUM_SMMUV2)
- smmu->impl = &cavium_impl;
+ return cavium_smmu_impl_init(smmu);
if (smmu->model == ARM_MMU500)
smmu->impl = &arm_mmu500_impl;
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 298ab9e6a6cd..1c1c9ef91d7b 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -27,7 +27,6 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/io-64-nonatomic-hi-lo.h> -#include <linux/io-pgtable.h> #include <linux/iopoll.h> #include <linux/init.h> #include <linux/moduleparam.h> @@ -111,44 +110,6 @@ struct arm_smmu_master_cfg { #define for_each_cfg_sme(fw, i, idx) \
for (i = 0; idx = fwspec_smendx(fw, i), i < fw->num_ids; ++i)
-enum arm_smmu_context_fmt {
- ARM_SMMU_CTX_FMT_NONE,
- ARM_SMMU_CTX_FMT_AARCH64,
- ARM_SMMU_CTX_FMT_AARCH32_L,
- ARM_SMMU_CTX_FMT_AARCH32_S,
-};
-
-struct arm_smmu_cfg {
- u8 cbndx;
- u8 irptndx;
- union {
- u16 asid;
- u16 vmid;
- };
- enum arm_smmu_cbar_type cbar;
- enum arm_smmu_context_fmt fmt;
-};
-#define INVALID_IRPTNDX 0xff
-
-enum arm_smmu_domain_stage {
- ARM_SMMU_DOMAIN_S1 = 0,
- ARM_SMMU_DOMAIN_S2,
- ARM_SMMU_DOMAIN_NESTED,
- ARM_SMMU_DOMAIN_BYPASS,
-};
-
-struct arm_smmu_domain {
- struct arm_smmu_device *smmu;
- struct io_pgtable_ops *pgtbl_ops;
- const struct iommu_gather_ops *tlb_ops;
- struct arm_smmu_cfg cfg;
- enum arm_smmu_domain_stage stage;
- bool non_strict;
- struct mutex init_mutex; /* Protects smmu pointer */
- spinlock_t cb_lock; /* Serialises ATS1* ops and TLB syncs */
- struct iommu_domain domain;
-};
-
static bool using_legacy_binding, using_generic_binding;
static inline int arm_smmu_rpm_get(struct arm_smmu_device *smmu) @@ -749,9 +710,16 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
}
if (smmu_domain->stage == ARM_SMMU_DOMAIN_S2)
- cfg->vmid = cfg->cbndx + 1 + smmu->cavium_id_base;
+ cfg->vmid = cfg->cbndx + 1;
else
- cfg->asid = cfg->cbndx + smmu->cavium_id_base;
+ cfg->asid = cfg->cbndx;
+
+ smmu_domain->smmu = smmu;
+ if (smmu->impl && smmu->impl->init_context) {
+ ret = smmu->impl->init_context(smmu_domain);
+ if (ret)
+ goto out_unlock;
+ }
pgtbl_cfg = (struct io_pgtable_cfg) {
.pgsize_bitmap = smmu->pgsize_bitmap,
@@ -765,7 +733,6 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
if (smmu_domain->non_strict)
pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
- smmu_domain->smmu = smmu;
pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
if (!pgtbl_ops) {
ret = -ENOMEM;
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h index 616cc87a05e3..a18b5925b43c 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -14,6 +14,7 @@
#include <linux/bits.h>
#include <linux/clk.h>
#include <linux/device.h>
+#include <linux/io-pgtable.h>
#include <linux/iommu.h>
#include <linux/mutex.h>
#include <linux/spinlock.h>
@@ -270,14 +271,50 @@ struct arm_smmu_device {
struct clk_bulk_data *clks;
int num_clks;
- u32 cavium_id_base; /* Specific to Cavium */
-
spinlock_t global_sync_lock;
/* IOMMU core code handle */
struct iommu_device iommu;
};
+enum arm_smmu_context_fmt {
+ ARM_SMMU_CTX_FMT_NONE,
+ ARM_SMMU_CTX_FMT_AARCH64,
+ ARM_SMMU_CTX_FMT_AARCH32_L,
+ ARM_SMMU_CTX_FMT_AARCH32_S,
+};
+
+struct arm_smmu_cfg {
+ u8 cbndx;
+ u8 irptndx;
+ union {
+ u16 asid;
+ u16 vmid;
+ };
+ enum arm_smmu_cbar_type cbar;
+ enum arm_smmu_context_fmt fmt;
+};
+#define INVALID_IRPTNDX 0xff
+
+enum arm_smmu_domain_stage {
+ ARM_SMMU_DOMAIN_S1 = 0,
+ ARM_SMMU_DOMAIN_S2,
+ ARM_SMMU_DOMAIN_NESTED,
+ ARM_SMMU_DOMAIN_BYPASS,
+};
+
+struct arm_smmu_domain {
+ struct arm_smmu_device *smmu;
+ struct io_pgtable_ops *pgtbl_ops;
+ const struct iommu_gather_ops *tlb_ops;
+ struct arm_smmu_cfg cfg;
+ enum arm_smmu_domain_stage stage;
+ bool non_strict;
+ struct mutex init_mutex; /* Protects smmu pointer */
+ spinlock_t cb_lock; /* Serialises ATS1* ops and TLB syncs */
+ struct iommu_domain domain;
+};
+
/* Implementation details, yay! */
struct arm_smmu_impl {
@@ -289,6 +326,7 @@ struct arm_smmu_impl {
u64 val);
int (*cfg_probe)(struct arm_smmu_device *smmu);
int (*reset)(struct arm_smmu_device *smmu);
+ int (*init_context)(struct arm_smmu_domain *smmu_domain);
};
static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
--
2.21.0.dirty
_______________________________________________
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 19:11 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mark Rutland, Catalin Marinas, Qian Cai, Andrey Konovalov,
Geert Uytterhoeven, nd, Will Deacon, linux-arm-kernel
In-Reply-To: <CAKv+Gu8Gws2MVE5ck1-rjm06X2nOUzRRQL_rCuoXd2Fyp-cOyw@mail.gmail.com>
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]
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).
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/8] arm64: memory: Fix virt_addr_valid() using __is_lm_address()
From: Ard Biesheuvel @ 2019-08-13 19:25 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: <20190813191124.GA21406@capper-ampere.manchester.arm.com>
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.
_______________________________________________
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 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Arnd Bergmann @ 2019-08-13 19:33 UTC (permalink / raw)
To: Aaro Koskinen
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: <20190813181158.GA26798@darkstar.musicnaut.iki.fi>
On Tue, Aug 13, 2019 at 8:12 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> 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:
>
> > - 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
That sounds like an address conflict in the virtual addres space.
In multiplatform kernels, PCI I/O space is hardwired to addresses
0xfee00000-0xfeffffff,
which happened to be available on all the other machines that needed it so far.
OMAP1_IO_VIRT is 0xfefb0000-0xfefeffff, which clearly overlaps with the end of
the PCI I/O area.
We only really need 4KB of I/O space rather than the full 2MB, but it
would also be
good not to make this too machine specific.
Could we change OMAP1_IO_OFFSET to stay out of that area? Something like
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 97c114c1ef80..3b66d203dc98 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1794,9 +1794,9 @@ config DEBUG_UART_VIRT
default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
- default 0xfefb0000 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
- default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
- default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
+ default 0xff000000 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+ default 0xff000800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+ default 0xff009800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xff003000 if DEBUG_U300_UART
default 0xffd01000 if DEBUG_HIP01_UART
default DEBUG_UART_PHYS if !MMU
diff --git a/arch/arm/mach-omap1/hardware.h b/arch/arm/mach-omap1/hardware.h
index 232b8deef907..9fc76a3c9e57 100644
--- a/arch/arm/mach-omap1/hardware.h
+++ b/arch/arm/mach-omap1/hardware.h
@@ -61,7 +61,7 @@ static inline u32 omap_cs3_phys(void)
#endif /* ifndef __ASSEMBLER__ */
-#define OMAP1_IO_OFFSET 0x01000000 /* Virtual IO
= 0xfefb0000 */
+#define OMAP1_IO_OFFSET 0x00fb0000 /* Virtual IO
= 0xff000000 */
#define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET)
#include "serial.h"
There may be additional locations that hardcode the virtual address.
Arnd
_______________________________________________
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: linux-next: Fixes tags need some work in the arm-soc tree
From: Arnd Bergmann @ 2019-08-13 19:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Alexandre Torgue, Linux Kernel Mailing List,
Linux Next Mailing List, Olof Johansson, Fabrice Gasnier, ARM
In-Reply-To: <20190814002836.4b6aa14b@canb.auug.org.au>
On Tue, Aug 13, 2019 at 4:28 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Please do not split Fixes tags over more than one line. Also, please
> keep them with the rest of the other tags.
Thanks for the report. How bad is this? Should I undo the merge and
wait for an updated pull request?
Arnd
_______________________________________________
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 v5 08/18] thermal: sun8i: support mod clocks
From: Ondřej Jirman @ 2019-08-13 20:06 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Linux PM, Frank Lee, Greg Kroah-Hartman,
Daniel Lezcano, linux-kernel, Eduardo Valentin, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Jonathan.Cameron,
Mauro Carvalho Chehab, rui.zhang, David S. Miller, arm-linux
In-Reply-To: <CA+E=qVf9V9iTvCfXXyjqKeviCJOvYpKUO8qw6cQsKqoaRmdKYQ@mail.gmail.com>
On Mon, Aug 12, 2019 at 04:54:15PM -0700, Vasily Khoruzhick wrote:
> On Mon, Aug 12, 2019 at 4:46 PM Frank Lee <tiny.windzz@gmail.com> wrote:
> >
> > HI Vasily,
> >
> > On Sat, Aug 10, 2019 at 2:17 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > >
> > > On Fri, Aug 9, 2019 at 10:31 PM Yangtao Li <tiny.windzz@gmail.com> wrote:
> > > >
> > > > H3 has extra clock, so introduce something in ths_thermal_chip/ths_device
> > > > and adds the process of the clock.
> > > >
> > > > This is pre-work for supprt it.
> > > >
> > > > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > > > ---
> > > > drivers/thermal/sun8i_thermal.c | 17 ++++++++++++++++-
> > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> > > > index b934bc81eba7..6f4294c2aba7 100644
> > > > --- a/drivers/thermal/sun8i_thermal.c
> > > > +++ b/drivers/thermal/sun8i_thermal.c
> > > > @@ -54,6 +54,7 @@ struct tsensor {
> > > > };
> > > >
> > > > struct ths_thermal_chip {
> > > > + bool has_mod_clk;
> > > > int sensor_num;
> > > > int offset;
> > > > int scale;
> > > > @@ -69,6 +70,7 @@ struct ths_device {
> > > > struct regmap *regmap;
> > > > struct reset_control *reset;
> > > > struct clk *bus_clk;
> > > > + struct clk *mod_clk;
> > > > struct tsensor sensor[MAX_SENSOR_NUM];
> > > > };
> > > >
> > > > @@ -274,6 +276,12 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev)
> > > > if (IS_ERR(tmdev->bus_clk))
> > > > return PTR_ERR(tmdev->bus_clk);
> > > >
> > > > + if (tmdev->chip->has_mod_clk) {
> > > > + tmdev->mod_clk = devm_clk_get(&pdev->dev, "mod");
> > > > + if (IS_ERR(tmdev->mod_clk))
> > > > + return PTR_ERR(tmdev->mod_clk);
> > > > + }
> > > > +
> > > > ret = reset_control_deassert(tmdev->reset);
> > > > if (ret)
> > > > return ret;
> > > > @@ -282,12 +290,18 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev)
> > > > if (ret)
> > > > goto assert_reset;
> > > >
> > > > - ret = sun50i_ths_calibrate(tmdev);
> > > > + ret = clk_prepare_enable(tmdev->mod_clk);
> > >
> > > You have to set rate of modclk before enabling it since you can't rely
> > > on whatever bootloader left for you.
> > >
> > > Also I found that parameters you're using for PC_TEMP_PERIOD, ACQ0 and
> > > ACQ1 are too aggressive and may result in high interrupt rate to the
> > > point when it may stall RCU. I changed driver a bit to use params from
> > > Philipp Rossak's work (modclk set to 4MHz, PC_TEMP_PERIOD is 7, ACQ0
> > > is 255, ACQ1 is 63) and it fixed RCU stalls for me, see [1] for
> > > details.
> >
> > Why is the RCU stall happening, is it caused by a deadlock?
> > Can you provide log information and your configuration?
> > I am a bit curious.
>
> It's not deadlock, I believe it just can't handle that many interrupts
> when running at lowest CPU frequency. Even with Philipp's settings
> there's ~20 interrupts a second from ths. I don't remember how many
> interrupts were there with your settings.
>
> Unfortunately there's nothing interesting in backtraces, I'm using
> Pine64-LTS board.
Recently there was a similar issue, with buggy CCU driver that caused
CIR interrupts being fired constantly, and it also resulted in RCU
stalls. Looks like a comon cause of RCU stalls.
THS timing settings probably need to be made specific to the SoC, because
I noticed that the same settings lead to wildly different timings on
different SoCs.
It would be good to measure how often ths interrupt fires with this driver
on various SoCs.
20 times a second and more sounds like overkill. I'd expect a useful
range to be at most 5-10 times a second. That should be enough to stop
overheating the SoC due to suddenly increased load, even without a
heatsink.
regards,
o.
> > Thx,
> > Yangtao
> >
> > >
> > > [1] https://github.com/anarsoul/linux-2.6/commit/46b8bb0fe2ccd1cd88fa9181a2ecbf79e8d513b2
> > >
> > >
> > > > if (ret)
> > > > goto bus_disable;
> > > >
> > > > + ret = sun50i_ths_calibrate(tmdev);
> > > > + if (ret)
> > > > + goto mod_disable;
> > > > +
> > > > return 0;
> > > >
> > > > +mod_disable:
> > > > + clk_disable_unprepare(tmdev->mod_clk);
> > > > bus_disable:
> > > > clk_disable_unprepare(tmdev->bus_clk);
> > > > assert_reset:
> > > > @@ -395,6 +409,7 @@ static int sun8i_ths_remove(struct platform_device *pdev)
> > > > {
> > > > struct ths_device *tmdev = platform_get_drvdata(pdev);
> > > >
> > > > + clk_disable_unprepare(tmdev->mod_clk);
> > > > clk_disable_unprepare(tmdev->bus_clk);
> > > > reset_control_assert(tmdev->reset);
> > > >
> > > > --
> > > > 2.17.1
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
_______________________________________________
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 20:34 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mark Rutland, Catalin Marinas, Qian Cai, Andrey Konovalov,
Geert Uytterhoeven, nd, Will Deacon, linux-arm-kernel
In-Reply-To: <CAKv+Gu-VBwXH+n7A0vr9xXm43HmFqsHOazQA-BuJKSqNhngR2A@mail.gmail.com>
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.
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...
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 V2 00/13] ARM: Add minimal Raspberry Pi 4 support
From: Eric Anholt @ 2019-08-13 20:42 UTC (permalink / raw)
To: Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden,
Wolfram Sang, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd
Cc: devicetree, Stefan Wahren, bcm-kernel-feedback-list,
linux-rpi-kernel, linux-clk, linux-arm-kernel, linux-i2c
In-Reply-To: <1565713248-4906-1-git-send-email-wahrenst@gmx.net>
[-- Attachment #1.1: Type: text/plain, Size: 440 bytes --]
Stefan Wahren <wahrenst@gmx.net> writes:
> This series adds minimal support for the new Raspberry Pi 4, so we are able
> to login via debug UART.
>
> Patch 1-2: Prepare platform and DTS for the new SoC BMC2711
> Patch 3-6: Enable clock support for BCM2711
> Patch 7-8: Add I2C support for BCM2711
> Patch 9-12: Add Raspberry Pi 4 DTS support
> Patch 13: Update MAINTAINERS
Series is:
Reviewed-by: Eric Anholt <eric@anholt.net>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 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
* [PATCH] dt-bindings: pinctrl: stm32: Fix 'st,syscfg' schema
From: Rob Herring @ 2019-08-13 20:55 UTC (permalink / raw)
To: devicetree
Cc: Mark Rutland, Alexandre Torgue, Linus Walleij, linux-gpio,
Maxime Coquelin, linux-stm32, linux-arm-kernel
The proper way to add additional contraints to an existing json-schema
is using 'allOf' to reference the base schema. Using just '$ref' doesn't
work. Fix this for the 'st,syscfg' property.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
I've got some other fixes queued up and can take this via the DT tree.
Rob
.../devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
index 91d3e78b3395..400df2da018a 100644
--- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
@@ -37,7 +37,8 @@ properties:
hwlocks: true
st,syscfg:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/phandle-array"
description: Should be phandle/offset/mask
items:
- description: Phandle to the syscon node which includes IRQ mux selection.
--
2.20.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
* Re: [PATCH net-next v2 01/12] net: stmmac: Get correct timestamp values from XGMAC
From: Jakub Kicinski @ 2019-08-13 20:57 UTC (permalink / raw)
To: Jose Abreu
Cc: Joao Pinto, Alexandre Torgue, netdev, linux-kernel, linux-stm32,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <195f374a0b46e5e65a691742fc2dbeffacfaf148.1565602974.git.joabreu@synopsys.com>
On Mon, 12 Aug 2019 11:44:00 +0200, Jose Abreu wrote:
> TX Timestamp in XGMAC comes from MAC instead of descriptors. Implement
> this in a new callback.
>
> Also, RX Timestamp in XGMAC must be cheked against corruption and we need
> a barrier to make sure that descriptor fields are read correctly.
>
> Changes from v1:
> - Rework the get timestamp function (David)
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
The barrier sounds like it might be a bug fix, does it occur in he wild?
> @@ -113,13 +119,11 @@ static int dwxgmac2_get_rx_timestamp_status(void *desc, void *next_desc,
> unsigned int rdes3 = le32_to_cpu(p->des3);
> int ret = -EBUSY;
>
> - if (likely(rdes3 & XGMAC_RDES3_CDA)) {
> + if (likely(rdes3 & XGMAC_RDES3_CDA))
> ret = dwxgmac2_rx_check_timestamp(next_desc);
> - if (ret)
> - return ret;
> - }
> -
> - return ret;
> + if (!ret)
> + return 1;
> + return 0;
nit:
return !ret;
> }
>
> static void dwxgmac2_init_rx_desc(struct dma_desc *p, int disable_rx_ic,
_______________________________________________
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 net-next v2 02/12] net: stmmac: Prepare to add Split Header support
From: Jakub Kicinski @ 2019-08-13 21:11 UTC (permalink / raw)
To: Jose Abreu
Cc: Joao Pinto, Alexandre Torgue, netdev, linux-kernel, linux-stm32,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <342007d6ac2b44db03d113e7e8bf0310caa77ea0.1565602974.git.joabreu@synopsys.com>
On Mon, 12 Aug 2019 11:44:01 +0200, Jose Abreu wrote:
> In order to add Split Header support, stmmac_rx() needs to take into
> account that packet may be split accross multiple descriptors.
>
> Refactor the logic of this function in order to support this scenario.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
>
> ---
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Jose Abreu <joabreu@synopsys.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 6 +
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 149 +++++++++++++---------
> 2 files changed, 95 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index 80276587048a..56158e1448ac 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -74,6 +74,12 @@ struct stmmac_rx_queue {
> u32 rx_zeroc_thresh;
> dma_addr_t dma_rx_phy;
> u32 rx_tail_addr;
> + unsigned int state_saved;
> + struct {
> + struct sk_buff *skb;
> + unsigned int len;
> + unsigned int error;
> + } state;
> };
>
> struct stmmac_channel {
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index b2e5f4ecd551..a093eb4ec275 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3353,9 +3353,10 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
> {
> struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
> struct stmmac_channel *ch = &priv->channel[queue];
> + unsigned int count = 0, error = 0, len = 0;
> + int status = 0, coe = priv->hw->rx_csum;
> unsigned int next_entry = rx_q->cur_rx;
> - int coe = priv->hw->rx_csum;
> - unsigned int count = 0;
> + struct sk_buff *skb = NULL;
>
> if (netif_msg_rx_status(priv)) {
> void *rx_head;
> @@ -3369,9 +3370,27 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
> stmmac_display_ring(priv, rx_head, DMA_RX_SIZE, true);
> }
> while (count < limit) {
> + enum pkt_hash_types hash_type;
> struct stmmac_rx_buffer *buf;
> + unsigned int prev_len = 0;
> struct dma_desc *np, *p;
> - int entry, status;
> + int entry;
> + u32 hash;
> +
> + if (!count && rx_q->state_saved) {
> + skb = rx_q->state.skb;
> + error = rx_q->state.error;
> + len = rx_q->state.len;
> + } else {
> + rx_q->state_saved = false;
> + skb = NULL;
> + error = 0;
> + len = 0;
> + }
> +
> +read_again:
> + if (count >= limit)
> + break;
Is this stopping the NAPI poll once @limit descriptors were seen?
It should probably be okay to ignore the limit until you get a full
frame? I'd think it'd be best to finish up the frame while the state
is hot in the CPU cache.. WDYT?
> entry = next_entry;
> buf = &rx_q->buf_pool[entry];
> @@ -3407,28 +3426,24 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
> page_pool_recycle_direct(rx_q->page_pool, buf->page);
> priv->dev->stats.rx_errors++;
> buf->page = NULL;
> + error = 1;
> + }
> +
> + if (unlikely(error & (status & rx_not_ls)))
Looks suspicious - sure this is supposed to be error & (status & bla)
and not error && ... ?
> + goto read_again;
> + if (unlikely(error)) {
> + if (skb)
> + dev_kfree_skb(skb);
> + continue;
> + }
> +
> + /* Buffer is good. Go on. */
> +
> + if (likely(status & rx_not_ls)) {
> + len += priv->dma_buf_sz;
> } else {
> - enum pkt_hash_types hash_type;
> - struct sk_buff *skb;
> - unsigned int des;
> - int frame_len;
> - u32 hash;
> -
> - stmmac_get_desc_addr(priv, p, &des);
> - frame_len = stmmac_get_rx_frame_len(priv, p, coe);
> -
> - /* If frame length is greater than skb buffer size
> - * (preallocated during init) then the packet is
> - * ignored
> - */
> - if (frame_len > priv->dma_buf_sz) {
> - if (net_ratelimit())
> - netdev_err(priv->dev,
> - "len %d larger than size (%d)\n",
> - frame_len, priv->dma_buf_sz);
> - priv->dev->stats.rx_length_errors++;
> - continue;
> - }
> + prev_len = len;
> + len = stmmac_get_rx_frame_len(priv, p, coe);
>
> /* ACS is set; GMAC core strips PAD/FCS for IEEE 802.3
> * Type frames (LLC/LLC-SNAP)
> @@ -3439,57 +3454,71 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
> */
> if (unlikely(priv->synopsys_id >= DWMAC_CORE_4_00) ||
> unlikely(status != llc_snap))
> - frame_len -= ETH_FCS_LEN;
> -
> - if (netif_msg_rx_status(priv)) {
> - netdev_dbg(priv->dev, "\tdesc: %p [entry %d] buff=0x%x\n",
> - p, entry, des);
> - netdev_dbg(priv->dev, "frame size %d, COE: %d\n",
> - frame_len, status);
> - }
> + len -= ETH_FCS_LEN;
> + }
>
> - skb = netdev_alloc_skb_ip_align(priv->dev, frame_len);
> - if (unlikely(!skb)) {
> + if (!skb) {
> + skb = netdev_alloc_skb_ip_align(priv->dev, len);
Since you're in NAPI call perhaps something like napi_alloc_skb() could
speed things up a little? But please also see below..
> + if (!skb) {
> priv->dev->stats.rx_dropped++;
> continue;
> }
>
> - dma_sync_single_for_cpu(priv->device, buf->addr,
> - frame_len, DMA_FROM_DEVICE);
> + dma_sync_single_for_cpu(priv->device, buf->addr, len,
> + DMA_FROM_DEVICE);
> skb_copy_to_linear_data(skb, page_address(buf->page),
> - frame_len);
> - skb_put(skb, frame_len);
> + len);
> + skb_put(skb, len);
>
> - if (netif_msg_pktdata(priv)) {
> - netdev_dbg(priv->dev, "frame received (%dbytes)",
> - frame_len);
> - print_pkt(skb->data, frame_len);
> - }
> + /* Data payload copied into SKB, page ready for recycle */
> + page_pool_recycle_direct(rx_q->page_pool, buf->page);
> + buf->page = NULL;
> + } else {
> + unsigned int buf_len = len - prev_len;
>
> - stmmac_get_rx_hwtstamp(priv, p, np, skb);
> + if (likely(status & rx_not_ls))
> + buf_len = priv->dma_buf_sz;
>
> - stmmac_rx_vlan(priv->dev, skb);
> + dma_sync_single_for_cpu(priv->device, buf->addr,
> + buf_len, DMA_FROM_DEVICE);
> + skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
> + buf->page, 0, buf_len,
> + priv->dma_buf_sz);
>
> - skb->protocol = eth_type_trans(skb, priv->dev);
> + /* Data payload appended into SKB */
> + page_pool_release_page(rx_q->page_pool, buf->page);
> + buf->page = NULL;
> + }
>
> - if (unlikely(!coe))
> - skb_checksum_none_assert(skb);
> - else
> - skb->ip_summed = CHECKSUM_UNNECESSARY;
> + if (likely(status & rx_not_ls))
> + goto read_again;
>
> - if (!stmmac_get_rx_hash(priv, p, &hash, &hash_type))
> - skb_set_hash(skb, hash, hash_type);
> + /* Got entire packet into SKB. Finish it. */
>
> - skb_record_rx_queue(skb, queue);
> - napi_gro_receive(&ch->rx_napi, skb);
> + stmmac_get_rx_hwtstamp(priv, p, np, skb);
> + stmmac_rx_vlan(priv->dev, skb);
> + skb->protocol = eth_type_trans(skb, priv->dev);
>
> - /* Data payload copied into SKB, page ready for recycle */
> - page_pool_recycle_direct(rx_q->page_pool, buf->page);
> - buf->page = NULL;
> + if (unlikely(!coe))
> + skb_checksum_none_assert(skb);
> + else
> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>
> - priv->dev->stats.rx_packets++;
> - priv->dev->stats.rx_bytes += frame_len;
> - }
> + if (!stmmac_get_rx_hash(priv, p, &hash, &hash_type))
> + skb_set_hash(skb, hash, hash_type);
> +
> + skb_record_rx_queue(skb, queue);
> + napi_gro_receive(&ch->rx_napi, skb);
Did you look into using napi_gro_frags() family of APIs?
I think Eric said those are more efficient from GRO perspective..
> + priv->dev->stats.rx_packets++;
> + priv->dev->stats.rx_bytes += len;
> + }
> +
> + if (status & rx_not_ls) {
> + rx_q->state_saved = true;
> + rx_q->state.skb = skb;
> + rx_q->state.error = error;
> + rx_q->state.len = len;
> }
>
> stmmac_rx_refill(priv, queue);
_______________________________________________
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/9] dt-bindings: first tentative of conversion to yaml format
From: Rob Herring @ 2019-08-13 21:19 UTC (permalink / raw)
To: Neil Armstrong
Cc: Philipp Zabel, devicetree, LINUX-WATCHDOG, Jassi Brar, linux-spi,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
open list:SERIAL DRIVERS, linux-amlogic, Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190808085139.21438-1-narmstrong@baylibre.com>
On Thu, Aug 8, 2019 at 2:51 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> This is a first tentative to convert some of the simplest Amlogic
> dt-bindings to the yaml format.
>
> All have been tested using :
> $ make ARCH=arm64 dtbs_check
>
> Issues with the amlogic arm64 DTs has already been identified thanks
> to the validation scripts. The DT fixes will be pushed once these yaml
> bindings are acked.
>
> Changes since rfc v2:
> - Collected Rob's, Martin's, Philipp's and Guenter's tags
> - Removed mhu maxItems: 3 to leave only minItems
> - Fixed flash@0 in spifc example
>
> Changes since rfc v1:
> - Fixed bindings according to Rob's comments
> - Added commit log
> - renamed yaml files using amlogic prefix
>
> Neil Armstrong (9):
> dt-bindings: mailbox: meson-mhu: convert to yaml
> dt-bindings: rng: amlogic,meson-rng: convert to yaml
> dt-bindings: spi: meson: convert to yaml
> dt-bindings: reset: amlogic,meson-reset: convert to yaml
> dt-bindings: arm: amlogic: amlogic,meson-gx-ao-secure: convert to yaml
> dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml
> dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml
> dt-bindings: serial: meson-uart: convert to yaml
> dt-bindings: watchdog: meson-gxbb-wdt: convert to yaml
Series applied.
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 net-next v2 07/12] net: stmmac: Add ethtool register dump for XGMAC cores
From: Jakub Kicinski @ 2019-08-13 21:19 UTC (permalink / raw)
To: Jose Abreu
Cc: Joao Pinto, Alexandre Torgue, netdev, linux-kernel, linux-stm32,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <3d860a78ce4e98941f7e292d251d7360755fdf2e.1565602974.git.joabreu@synopsys.com>
On Mon, 12 Aug 2019 11:44:06 +0200, Jose Abreu wrote:
> static void stmmac_ethtool_gregs(struct net_device *dev,
> struct ethtool_regs *regs, void *space)
> {
> - u32 *reg_space = (u32 *) space;
> -
> struct stmmac_priv *priv = netdev_priv(dev);
> + int size = stmmac_ethtool_get_regs_len(dev);
> + u32 *reg_space = (u32 *) space;
>
> - memset(reg_space, 0x0, REG_SPACE_SIZE);
> + memset(reg_space, 0x0, size);
no need to zero regs, ethtool core zallocs them
_______________________________________________
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 4/6] dma: pxa_dma: no need to check return value of debugfs_create functions
From: Robert Jarzmik @ 2019-08-13 21:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, Haojian Zhuang, vkoul, linux-arm-kernel, dmaengine,
dan.j.williams, Daniel Mack
In-Reply-To: <20190811070350.GA28202@kroah.com>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Sat, Aug 10, 2019 at 09:27:26PM +0200, Robert Jarzmik wrote:
>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>>
>> This is not strictly equivalent.
>> Imagine that the debugfs_create_dir() fails and returns NULL :
> How can that happen?
Well in v5.0-rc1 that could happen ... unfortunately that's also the code I
checked ...
>> - in the former case, neither "state", "descriptors" nor "requesters" would be
>> created
>> - in the new code, "state", "descriptors" nor "requesters" will be created in
>> the debugfs root directory
>
> I agree, but debugfs_create_dir() does not return a NULL on an error
> since many kernel releases. Neither can debugfs_create_file() so really
> this test is not working at all as-is :)
Ah yes, you're right, I wasn't aware of the debugfs changes ...
But checking a bit further, your original mail is 2 monthes old, and this patch
was already merged in v5.2. I probably fell in a time-space anomaly, as I
received this mail only a couple of days ago.
Have a nice day.
--
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: [PATCH v3 1/2] dt-bindings: arm: imx: add imx8mq nitrogen support
From: Rob Herring @ 2019-08-13 21:22 UTC (permalink / raw)
To: Dafna Hirschfeld
Cc: Mark Rutland, devicetree, Ezequiel Garcia, Sascha Hauer,
linux-kernel@vger.kernel.org, Troy Kisky, Gary Bisson,
Sascha Hauer, kernel, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190813125147.29605-2-dafna.hirschfeld@collabora.com>
On Tue, Aug 13, 2019 at 6:51 AM Dafna Hirschfeld
<dafna.hirschfeld@collabora.com> wrote:
>
> From: Gary Bisson <gary.bisson@boundarydevices.com>
>
> The Nitrogen8M is an ARM based single board computer (SBC)
> designed to leverage the full capabilities of NXP’s i.MX8M
> Quad processor.
>
> Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> [Dafna: porting vendor's code to mainline]
> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Rob Herring <robh@kernel.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 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
From: Rob Herring @ 2019-08-13 21:23 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Young, Maxime Ripard,
linux-kernel@vger.kernel.org, Chen-Yu Tsai, Mauro Carvalho Chehab,
Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <20190813124513.31413-1-mripard@kernel.org>
On Tue, Aug 13, 2019 at 6:45 AM Maxime Ripard <mripard@kernel.org> wrote:
>
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The RC controllers have a bunch of generic properties that are needed in a
> device tree. Add a YAML schemas for those.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../devicetree/bindings/media/rc.txt | 118 +--------------
> .../devicetree/bindings/media/rc.yaml | 135 ++++++++++++++++++
> 2 files changed, 136 insertions(+), 117 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/rc.yaml
Reviewed-by: Rob Herring <robh@kernel.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 2/2] dt-bindings: media: Convert Allwinner A10 IR to a schema
From: Rob Herring @ 2019-08-13 21:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Young, Maxime Ripard,
linux-kernel@vger.kernel.org, Chen-Yu Tsai, Mauro Carvalho Chehab,
Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <20190813124513.31413-2-mripard@kernel.org>
On Tue, Aug 13, 2019 at 6:45 AM Maxime Ripard <mripard@kernel.org> wrote:
>
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The older Allwinner SoCs have a IR receiver supported in Linux, with a
> matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../media/allwinner,sun4i-a10-ir.yaml | 80 +++++++++++++++++++
> .../devicetree/bindings/media/sunxi-ir.txt | 35 --------
> 2 files changed, 80 insertions(+), 35 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
> delete mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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