* Re: [PATCH v2 1/2] mm/page_ext: support to record the last stack of page
From: Walter Wu @ 2019-09-10 1:07 UTC (permalink / raw)
To: David Hildenbrand
Cc: Qian Cai, wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, Michal Hocko,
Martin Schwidefsky, Alexander Potapenko, linux-arm-kernel,
Matthias Brugger, Andrey Ryabinin, Andrew Morton, Will Deacon,
Thomas Gleixner, Dmitry Vyukov
In-Reply-To: <36b5a8e0-2783-4c0e-4fc7-78ea652ba475@redhat.com>
On Mon, 2019-09-09 at 12:57 +0200, David Hildenbrand wrote:
> On 09.09.19 10:53, Walter Wu wrote:
> > KASAN will record last stack of page in order to help programmer
> > to see memory corruption caused by page.
> >
> > What is difference between page_owner and our patch?
> > page_owner records alloc stack of page, but our patch is to record
> > last stack(it may be alloc or free stack of page).
> >
> > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > ---
> > mm/page_ext.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/mm/page_ext.c b/mm/page_ext.c
> > index 5f5769c7db3b..7ca33dcd9ffa 100644
> > --- a/mm/page_ext.c
> > +++ b/mm/page_ext.c
> > @@ -65,6 +65,9 @@ static struct page_ext_operations *page_ext_ops[] = {
> > #if defined(CONFIG_IDLE_PAGE_TRACKING) && !defined(CONFIG_64BIT)
> > &page_idle_ops,
> > #endif
> > +#ifdef CONFIG_KASAN
> > + &page_stack_ops,
> > +#endif
> > };
> >
> > static unsigned long total_usage;
> >
>
> Are you sure this patch compiles?
>
This is patchsets, it need another patch2.
We have verified it by running KASAN UT on Qemu.
_______________________________________________
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 02/11] xen/arm: consolidate page-coherent.h
From: Stefano Stabellini @ 2019-09-10 0:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Stefano Stabellini, Konrad Rzeszutek Wilk, gross, x86,
linux-kernel, iommu, xen-devel, boris.ostrovsky, linux-arm-kernel
In-Reply-To: <20190905113408.3104-3-hch@lst.de>
On Thu, 5 Sep 2019, Christoph Hellwig wrote:
> Shared the duplicate arm/arm64 code in include/xen/arm/page-coherent.h.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> arch/arm/include/asm/xen/page-coherent.h | 75 --------------------
> arch/arm64/include/asm/xen/page-coherent.h | 75 --------------------
> include/xen/arm/page-coherent.h | 80 ++++++++++++++++++++++
> 3 files changed, 80 insertions(+), 150 deletions(-)
>
> diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
> index 602ac02f154c..27e984977402 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -1,77 +1,2 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _ASM_ARM_XEN_PAGE_COHERENT_H
> -#define _ASM_ARM_XEN_PAGE_COHERENT_H
> -
> -#include <linux/dma-mapping.h>
> -#include <asm/page.h>
> #include <xen/arm/page-coherent.h>
> -
> -static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
> - dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
> -{
> - return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
> -}
> -
> -static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
> - void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
> -{
> - dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
> -}
> -
> -static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
> - dma_addr_t handle, size_t size, enum dma_data_direction dir)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> -
> - if (pfn_valid(pfn))
> - dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
> - else
> - __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
> -}
> -
> -static inline void xen_dma_sync_single_for_device(struct device *hwdev,
> - dma_addr_t handle, size_t size, enum dma_data_direction dir)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> - if (pfn_valid(pfn))
> - dma_direct_sync_single_for_device(hwdev, handle, size, dir);
> - else
> - __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
> -}
> -
> -static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> - dma_addr_t dev_addr, unsigned long offset, size_t size,
> - enum dma_data_direction dir, unsigned long attrs)
> -{
> - unsigned long page_pfn = page_to_xen_pfn(page);
> - unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
> - unsigned long compound_pages =
> - (1<<compound_order(page)) * XEN_PFN_PER_PAGE;
> - bool local = (page_pfn <= dev_pfn) &&
> - (dev_pfn - page_pfn < compound_pages);
> -
> - if (local)
> - dma_direct_map_page(hwdev, page, offset, size, dir, attrs);
> - else
> - __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
> -}
> -
> -static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
> - size_t size, enum dma_data_direction dir, unsigned long attrs)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> - /*
> - * Dom0 is mapped 1:1, while the Linux page can be spanned accross
> - * multiple Xen page, it's not possible to have a mix of local and
> - * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a
> - * foreign mfn will always return false. If the page is local we can
> - * safely call the native dma_ops function, otherwise we call the xen
> - * specific function.
> - */
> - if (pfn_valid(pfn))
> - dma_direct_unmap_page(hwdev, handle, size, dir, attrs);
> - else
> - __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
> -}
> -
> -#endif /* _ASM_ARM_XEN_PAGE_COHERENT_H */
> diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
> index d88e56b90b93..27e984977402 100644
> --- a/arch/arm64/include/asm/xen/page-coherent.h
> +++ b/arch/arm64/include/asm/xen/page-coherent.h
> @@ -1,77 +1,2 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _ASM_ARM64_XEN_PAGE_COHERENT_H
> -#define _ASM_ARM64_XEN_PAGE_COHERENT_H
> -
> -#include <linux/dma-mapping.h>
> -#include <asm/page.h>
> #include <xen/arm/page-coherent.h>
> -
> -static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
> - dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
> -{
> - return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
> -}
> -
> -static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
> - void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
> -{
> - dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
> -}
> -
> -static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
> - dma_addr_t handle, size_t size, enum dma_data_direction dir)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> -
> - if (pfn_valid(pfn))
> - dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
> - else
> - __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
> -}
> -
> -static inline void xen_dma_sync_single_for_device(struct device *hwdev,
> - dma_addr_t handle, size_t size, enum dma_data_direction dir)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> - if (pfn_valid(pfn))
> - dma_direct_sync_single_for_device(hwdev, handle, size, dir);
> - else
> - __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
> -}
> -
> -static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> - dma_addr_t dev_addr, unsigned long offset, size_t size,
> - enum dma_data_direction dir, unsigned long attrs)
> -{
> - unsigned long page_pfn = page_to_xen_pfn(page);
> - unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
> - unsigned long compound_pages =
> - (1<<compound_order(page)) * XEN_PFN_PER_PAGE;
> - bool local = (page_pfn <= dev_pfn) &&
> - (dev_pfn - page_pfn < compound_pages);
> -
> - if (local)
> - dma_direct_map_page(hwdev, page, offset, size, dir, attrs);
> - else
> - __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
> -}
> -
> -static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
> - size_t size, enum dma_data_direction dir, unsigned long attrs)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> - /*
> - * Dom0 is mapped 1:1, while the Linux page can be spanned accross
> - * multiple Xen page, it's not possible to have a mix of local and
> - * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a
> - * foreign mfn will always return false. If the page is local we can
> - * safely call the native dma_ops function, otherwise we call the xen
> - * specific function.
> - */
> - if (pfn_valid(pfn))
> - dma_direct_unmap_page(hwdev, handle, size, dir, attrs);
> - else
> - __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
> -}
> -
> -#endif /* _ASM_ARM64_XEN_PAGE_COHERENT_H */
> diff --git a/include/xen/arm/page-coherent.h b/include/xen/arm/page-coherent.h
> index 2ca9164a79bf..a840d6949a87 100644
> --- a/include/xen/arm/page-coherent.h
> +++ b/include/xen/arm/page-coherent.h
> @@ -2,6 +2,9 @@
> #ifndef _XEN_ARM_PAGE_COHERENT_H
> #define _XEN_ARM_PAGE_COHERENT_H
>
> +#include <linux/dma-mapping.h>
> +#include <asm/page.h>
> +
> void __xen_dma_map_page(struct device *hwdev, struct page *page,
> dma_addr_t dev_addr, unsigned long offset, size_t size,
> enum dma_data_direction dir, unsigned long attrs);
> @@ -13,4 +16,81 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
> void __xen_dma_sync_single_for_device(struct device *hwdev,
> dma_addr_t handle, size_t size, enum dma_data_direction dir);
>
> +static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
> + dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
> +{
> + return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
> +}
> +
> +static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
> + void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
> +{
> + dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
> +}
> +
> +static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
> + dma_addr_t handle, size_t size, enum dma_data_direction dir)
> +{
> + unsigned long pfn = PFN_DOWN(handle);
> +
> + if (pfn_valid(pfn))
> + dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
> + else
> + __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
> +}
> +
> +static inline void xen_dma_sync_single_for_device(struct device *hwdev,
> + dma_addr_t handle, size_t size, enum dma_data_direction dir)
> +{
> + unsigned long pfn = PFN_DOWN(handle);
> + if (pfn_valid(pfn))
> + dma_direct_sync_single_for_device(hwdev, handle, size, dir);
> + else
> + __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
> +}
> +
> +static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> + dma_addr_t dev_addr, unsigned long offset, size_t size,
> + enum dma_data_direction dir, unsigned long attrs)
> +{
> + unsigned long page_pfn = page_to_xen_pfn(page);
> + unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
> + unsigned long compound_pages =
> + (1<<compound_order(page)) * XEN_PFN_PER_PAGE;
> + bool local = (page_pfn <= dev_pfn) &&
> + (dev_pfn - page_pfn < compound_pages);
> +
> + /*
> + * Dom0 is mapped 1:1, while the Linux page can span across
> + * multiple Xen pages, it's not possible for it to contain a
> + * mix of local and foreign Xen pages. So if the first xen_pfn
> + * == mfn the page is local otherwise it's a foreign page
> + * grant-mapped in dom0. If the page is local we can safely
> + * call the native dma_ops function, otherwise we call the xen
> + * specific function.
> + */
> + if (local)
> + dma_direct_map_page(hwdev, page, offset, size, dir, attrs);
> + else
> + __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
> +}
> +
> +static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir, unsigned long attrs)
> +{
> + unsigned long pfn = PFN_DOWN(handle);
> + /*
> + * Dom0 is mapped 1:1, while the Linux page can be spanned accross
> + * multiple Xen page, it's not possible to have a mix of local and
> + * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a
> + * foreign mfn will always return false. If the page is local we can
> + * safely call the native dma_ops function, otherwise we call the xen
> + * specific function.
> + */
> + if (pfn_valid(pfn))
> + dma_direct_unmap_page(hwdev, handle, size, dir, attrs);
> + else
> + __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
> +}
> +
> #endif /* _XEN_ARM_PAGE_COHERENT_H */
> --
> 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
* Re: [PATCH 01/11] xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance
From: Stefano Stabellini @ 2019-09-10 0:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Stefano Stabellini, Konrad Rzeszutek Wilk, gross, x86,
linux-kernel, iommu, xen-devel, boris.ostrovsky, linux-arm-kernel
In-Reply-To: <20190905113408.3104-2-hch@lst.de>
On Thu, 5 Sep 2019, Christoph Hellwig wrote:
> Copy the arm64 code that uses the dma-direct/swiotlb helpers for DMA
> on-coherent devices.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
This is much better and much more readable.
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> arch/arm/include/asm/device.h | 3 -
> arch/arm/include/asm/xen/page-coherent.h | 72 +++++++++---------------
> arch/arm/mm/dma-mapping.c | 8 +--
> drivers/xen/swiotlb-xen.c | 20 -------
> 4 files changed, 28 insertions(+), 75 deletions(-)
>
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index f6955b55c544..c675bc0d5aa8 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -14,9 +14,6 @@ struct dev_archdata {
> #endif
> #ifdef CONFIG_ARM_DMA_USE_IOMMU
> struct dma_iommu_mapping *mapping;
> -#endif
> -#ifdef CONFIG_XEN
> - const struct dma_map_ops *dev_dma_ops;
> #endif
> unsigned int dma_coherent:1;
> unsigned int dma_ops_setup:1;
> diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
> index 2c403e7c782d..602ac02f154c 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -6,23 +6,37 @@
> #include <asm/page.h>
> #include <xen/arm/page-coherent.h>
>
> -static inline const struct dma_map_ops *xen_get_dma_ops(struct device *dev)
> -{
> - if (dev && dev->archdata.dev_dma_ops)
> - return dev->archdata.dev_dma_ops;
> - return get_arch_dma_ops(NULL);
> -}
> -
> static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
> dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
> {
> - return xen_get_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, attrs);
> + return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
> }
>
> static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
> void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
> {
> - xen_get_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
> + dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
> +}
> +
> +static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
> + dma_addr_t handle, size_t size, enum dma_data_direction dir)
> +{
> + unsigned long pfn = PFN_DOWN(handle);
> +
> + if (pfn_valid(pfn))
> + dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
> + else
> + __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
> +}
> +
> +static inline void xen_dma_sync_single_for_device(struct device *hwdev,
> + dma_addr_t handle, size_t size, enum dma_data_direction dir)
> +{
> + unsigned long pfn = PFN_DOWN(handle);
> + if (pfn_valid(pfn))
> + dma_direct_sync_single_for_device(hwdev, handle, size, dir);
> + else
> + __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
> }
>
> static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> @@ -36,17 +50,8 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> bool local = (page_pfn <= dev_pfn) &&
> (dev_pfn - page_pfn < compound_pages);
>
> - /*
> - * Dom0 is mapped 1:1, while the Linux page can span across
> - * multiple Xen pages, it's not possible for it to contain a
> - * mix of local and foreign Xen pages. So if the first xen_pfn
> - * == mfn the page is local otherwise it's a foreign page
> - * grant-mapped in dom0. If the page is local we can safely
> - * call the native dma_ops function, otherwise we call the xen
> - * specific function.
> - */
> if (local)
> - xen_get_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
> + dma_direct_map_page(hwdev, page, offset, size, dir, attrs);
> else
> __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
> }
> @@ -63,33 +68,10 @@ static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
> * safely call the native dma_ops function, otherwise we call the xen
> * specific function.
> */
> - if (pfn_valid(pfn)) {
> - if (xen_get_dma_ops(hwdev)->unmap_page)
> - xen_get_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
> - } else
> + if (pfn_valid(pfn))
> + dma_direct_unmap_page(hwdev, handle, size, dir, attrs);
> + else
> __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
> }
>
> -static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
> - dma_addr_t handle, size_t size, enum dma_data_direction dir)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> - if (pfn_valid(pfn)) {
> - if (xen_get_dma_ops(hwdev)->sync_single_for_cpu)
> - xen_get_dma_ops(hwdev)->sync_single_for_cpu(hwdev, handle, size, dir);
> - } else
> - __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
> -}
> -
> -static inline void xen_dma_sync_single_for_device(struct device *hwdev,
> - dma_addr_t handle, size_t size, enum dma_data_direction dir)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> - if (pfn_valid(pfn)) {
> - if (xen_get_dma_ops(hwdev)->sync_single_for_device)
> - xen_get_dma_ops(hwdev)->sync_single_for_device(hwdev, handle, size, dir);
> - } else
> - __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
> -}
> -
> #endif /* _ASM_ARM_XEN_PAGE_COHERENT_H */
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index d42557ee69c2..738097396445 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1132,10 +1132,6 @@ static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
> * 32-bit DMA.
> * Use the generic dma-direct / swiotlb ops code in that case, as that
> * handles bounce buffering for us.
> - *
> - * Note: this checks CONFIG_ARM_LPAE instead of CONFIG_SWIOTLB as the
> - * latter is also selected by the Xen code, but that code for now relies
> - * on non-NULL dev_dma_ops. To be cleaned up later.
> */
> if (IS_ENABLED(CONFIG_ARM_LPAE))
> return NULL;
> @@ -2363,10 +2359,8 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> set_dma_ops(dev, dma_ops);
>
> #ifdef CONFIG_XEN
> - if (xen_initial_domain()) {
> - dev->archdata.dev_dma_ops = dev->dma_ops;
> + if (xen_initial_domain())
> dev->dma_ops = xen_dma_ops;
> - }
> #endif
> dev->archdata.dma_ops_setup = true;
> }
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ae1df496bf38..eee86cc7046b 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -557,11 +557,6 @@ xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> void *cpu_addr, dma_addr_t dma_addr, size_t size,
> unsigned long attrs)
> {
> -#ifdef CONFIG_ARM
> - if (xen_get_dma_ops(dev)->mmap)
> - return xen_get_dma_ops(dev)->mmap(dev, vma, cpu_addr,
> - dma_addr, size, attrs);
> -#endif
> return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
> }
>
> @@ -574,21 +569,6 @@ xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
> void *cpu_addr, dma_addr_t handle, size_t size,
> unsigned long attrs)
> {
> -#ifdef CONFIG_ARM
> - if (xen_get_dma_ops(dev)->get_sgtable) {
> -#if 0
> - /*
> - * This check verifies that the page belongs to the current domain and
> - * is not one mapped from another domain.
> - * This check is for debug only, and should not go to production build
> - */
> - unsigned long bfn = PHYS_PFN(dma_to_phys(dev, handle));
> - BUG_ON (!page_is_ram(bfn));
> -#endif
> - return xen_get_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr,
> - handle, size, attrs);
> - }
> -#endif
> return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size, attrs);
> }
>
> --
> 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
* [RFC PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: Prakhar Srivastava @ 2019-09-09 23:14 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: mark.rutland, jean-philippe, arnd, takahiro.akashi, sboyd,
catalin.marinas, zohar, yamada.masahiro, kristina.martsenko, duwe,
bauerman, james.morse, tglx, allison
In-Reply-To: <20190909231409.20461-1-prsriva@linux.microsoft.com>
During kexec_file_load, carrying forward the ima measurement log allows
a verifying party to get the entire runtime event log since the last
full reboot since that is when PCRs were last reset.
Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
---
arch/arm64/Kconfig | 7 +
arch/arm64/include/asm/ima.h | 29 ++++
arch/arm64/include/asm/kexec.h | 5 +
arch/arm64/kernel/Makefile | 3 +-
arch/arm64/kernel/ima_kexec.c | 213 +++++++++++++++++++++++++
arch/arm64/kernel/machine_kexec_file.c | 6 +
6 files changed, 262 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/include/asm/ima.h
create mode 100644 arch/arm64/kernel/ima_kexec.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3adcec05b1f6..f39b12dbf9e8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -976,6 +976,13 @@ config KEXEC_VERIFY_SIG
verification for the corresponding kernel image type being
loaded in order for this to work.
+config HAVE_IMA_KEXEC
+ bool "Carry over IMA measurement log during kexec_file_load() syscall"
+ depends on KEXEC_FILE
+ help
+ Select this option to carry over IMA measurement log during
+ kexec_file_load.
+
config KEXEC_IMAGE_VERIFY_SIG
bool "Enable Image signature verification support"
default y
diff --git a/arch/arm64/include/asm/ima.h b/arch/arm64/include/asm/ima.h
new file mode 100644
index 000000000000..e23cee84729f
--- /dev/null
+++ b/arch/arm64/include/asm/ima.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM64_IMA_H
+#define _ASM_ARM64_IMA_H
+
+struct kimage;
+
+int ima_get_kexec_buffer(void **addr, size_t *size);
+int ima_free_kexec_buffer(void);
+
+#ifdef CONFIG_IMA
+void remove_ima_buffer(void *fdt, int chosen_node);
+#else
+static inline void remove_ima_buffer(void *fdt, int chosen_node) {}
+#endif
+
+#ifdef CONFIG_IMA_KEXEC
+int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
+ size_t size);
+
+int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node);
+#else
+static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
+ int chosen_node)
+{
+ remove_ima_buffer(fdt, chosen_node);
+ return 0;
+}
+#endif /* CONFIG_IMA_KEXEC */
+#endif /* _ASM_ARM64_IMA_H */
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 12a561a54128..e8d2412066e7 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -96,6 +96,11 @@ static inline void crash_post_resume(void) {}
struct kimage_arch {
void *dtb;
unsigned long dtb_mem;
+
+#ifdef CONFIG_IMA_KEXEC
+ phys_addr_t ima_buffer_addr;
+ size_t ima_buffer_size;
+#endif
};
extern const struct kexec_file_ops kexec_image_ops;
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 478491f07b4f..580238f2e9a7 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -55,7 +55,8 @@ obj-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
obj-$(CONFIG_HIBERNATION) += hibernate.o hibernate-asm.o
obj-$(CONFIG_KEXEC_CORE) += machine_kexec.o relocate_kernel.o \
cpu-reset.o
-obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o kexec_image.o
+obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o kexec_image.o \
+ ima_kexec.o
obj-$(CONFIG_ARM64_RELOC_TEST) += arm64-reloc-test.o
arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
diff --git a/arch/arm64/kernel/ima_kexec.c b/arch/arm64/kernel/ima_kexec.c
new file mode 100644
index 000000000000..b14326d541f3
--- /dev/null
+++ b/arch/arm64/kernel/ima_kexec.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Microsoft Corporation.
+ *
+ * Authors:
+ * Prakhar Srivastava <prsriva@linux.microsoft.com>
+ */
+
+#include <linux/slab.h>
+#include <linux/kexec.h>
+#include <linux/of.h>
+#include <linux/memblock.h>
+#include <linux/libfdt.h>
+
+
+/**
+ * delete_fdt_mem_rsv - delete memory reservation with given address and size
+ * @fdt - pointer to the fdt.
+ * @start - start address of the memory.
+ * @size - number of cells to be deletd.
+ *
+ * Return: 0 on success, or negative errno on error.
+ */
+int delete_fdt_mem_rsv(void *fdt, unsigned long start, unsigned long size)
+{
+ int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
+
+ for (i = 0; i < num_rsvs; i++) {
+ uint64_t rsv_start, rsv_size;
+
+ ret = fdt_get_mem_rsv(fdt, i, &rsv_start, &rsv_size);
+ if (ret) {
+ pr_err("Malformed device tree\n");
+ return -EINVAL;
+ }
+
+ if (rsv_start == start && rsv_size == size) {
+ ret = fdt_del_mem_rsv(fdt, i);
+ if (ret) {
+ pr_err("Error deleting device tree reservation\n");
+ return -EINVAL;
+ }
+
+ return 0;
+ }
+ }
+
+ return -ENOENT;
+}
+
+/**
+ * remove_ima_buffer - remove the IMA buffer property and reservation
+ * @fdt - pointer the fdt.
+ * @chosen_node - node under which property can be found.
+ *
+ * The IMA measurement buffer is either read by now and freeed or a kexec call
+ * needs to replace the ima measurement buffer, clear the property and memory
+ * reservation.
+ */
+void remove_ima_buffer(void *fdt, int chosen_node)
+{
+ int ret, len;
+ const void *prop;
+ uint64_t tmp_start, tmp_end;
+
+ prop = fdt_getprop(fdt, chosen_node, "linux,ima-kexec-buffer", &len);
+ if (prop) {
+ tmp_start = fdt64_to_cpu(*((const fdt64_t *) prop));
+
+ prop = fdt_getprop(fdt, chosen_node,
+ "linux,ima-kexec-buffer-end", &len);
+ if (!prop)
+ return;
+
+ tmp_end = fdt64_to_cpu(*((const fdt64_t *) prop));
+
+ ret = delete_fdt_mem_rsv(fdt, tmp_start, tmp_end - tmp_start);
+
+ if (ret == 0)
+ pr_debug("Removed old IMA buffer reservation.\n");
+ else if (ret != -ENOENT)
+ return;
+
+ fdt_delprop(fdt, chosen_node, "linux,ima-kexec-buffer");
+ fdt_delprop(fdt, chosen_node, "linux,ima-kexec-buffer-end");
+ }
+}
+
+/**
+ * ima_get_kexec_buffer - get IMA buffer from the previous kernel
+ * @addr: On successful return, set to point to the buffer contents.
+ * @size: On successful return, set to the buffer size.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int ima_get_kexec_buffer(void **addr, size_t *size)
+{
+ int len;
+ const void *prop;
+ uint64_t tmp_start, tmp_end;
+
+ prop = of_get_property(of_chosen, "linux,ima-kexec-buffer", &len);
+ if (!prop)
+ return -ENOENT;
+
+ tmp_start = fdt64_to_cpu(*((const fdt64_t *) prop));
+
+ prop = of_get_property(of_chosen, "linux,ima-kexec-buffer-end", &len);
+ if (!prop)
+ return -ENOENT;
+
+ tmp_end = fdt64_to_cpu(*((const fdt64_t *) prop));
+
+ *addr = __va(tmp_start);
+ *size = tmp_end - tmp_start;
+
+ return 0;
+}
+
+/**
+ * ima_free_kexec_buffer - free memory used by the IMA buffer
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int ima_free_kexec_buffer(void)
+{
+ int ret;
+ void *propStart, *propEnd;
+ uint64_t tmp_start, tmp_end;
+
+ propStart = of_find_property(of_chosen, "linux,ima-kexec-buffer",
+ NULL);
+ if (propStart) {
+ tmp_start = fdt64_to_cpu(*((const fdt64_t *) propStart));
+ ret = of_remove_property(of_chosen, propStart);
+ if (!ret) {
+ return ret;
+ }
+
+ propEnd = of_find_property(of_chosen,
+ "linux,ima-kexec-buffer-end", NULL);
+ if (!propEnd) {
+ return -EINVAL;
+ }
+
+ tmp_end = fdt64_to_cpu(*((const fdt64_t *) propEnd));
+
+ ret = of_remove_property(of_chosen, propEnd);
+ if (!ret) {
+ return ret;
+ }
+
+ return memblock_free(tmp_start, tmp_end - tmp_start);
+ }
+ return 0;
+}
+
+#ifdef CONFIG_IMA_KEXEC
+/**
+ * arch_ima_add_kexec_buffer - do arch-specific steps to add the IMA
+ * measurement log.
+ * @image: - pointer to the kimage, to store the address and size of the
+ * IMA measurement log.
+ * @load_addr: - the address where the IMA measurement log is stored.
+ * @size - size of the IMA measurement log.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
+ size_t size)
+{
+ image->arch.ima_buffer_addr = load_addr;
+ image->arch.ima_buffer_size = size;
+ return 0;
+}
+
+/**
+ * setup_ima_buffer - update the fdt to contain the ima mesasurement log
+ * @image: - pointer to the kimage, containing the address and size of
+ * the IMA measurement log.
+ * @fdt: - pointer to the fdt.
+ * @chosen_node: - node under which property is to be defined.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node)
+{
+ int ret;
+
+ remove_ima_buffer(fdt, chosen_node);
+
+ if (!image->arch.ima_buffer_size)
+ return 0;
+
+ ret = fdt_setprop_u64(fdt, chosen_node, "linux,ima-kexec-buffer",
+ image->arch.ima_buffer_addr);
+ if (ret < 0)
+ return ret;
+
+ ret = fdt_setprop_u64(fdt, chosen_node, "linux,ima-kexec-buffer-end",
+ image->arch.ima_buffer_addr +
+ image->arch.ima_buffer_size);
+ if (ret < 0)
+ return ret;
+
+ ret = fdt_add_mem_rsv(fdt, image->arch.ima_buffer_addr,
+ image->arch.ima_buffer_size);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+#endif /* CONFIG_IMA_KEXEC */
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index 58871333737a..de5452539c67 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -21,6 +21,7 @@
#include <linux/types.h>
#include <linux/vmalloc.h>
#include <asm/byteorder.h>
+#include <asm/ima.h>
/* relevant device tree properties */
#define FDT_PROP_INITRD_START "linux,initrd-start"
@@ -85,6 +86,11 @@ static int setup_dtb(struct kimage *image,
goto out;
}
+ /* add ima measuremnet log buffer */
+ ret = setup_ima_buffer(image, dtb, off);
+ if (ret)
+ goto out;
+
/* add kaslr-seed */
ret = fdt_delprop(dtb, off, FDT_PROP_KASLR_SEED);
if (ret == -FDT_ERR_NOTFOUND)
--
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
* [RFC PATCH v1 0/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: Prakhar Srivastava @ 2019-09-09 23:14 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: mark.rutland, jean-philippe, arnd, takahiro.akashi, sboyd,
catalin.marinas, zohar, yamada.masahiro, kristina.martsenko, duwe,
bauerman, james.morse, tglx, allison
Add support for arm64 to carry ima measurement log
to the next kexec'ed session triggered via kexec_file_load.
- Top of Linux 5.3-rc6
Currently during kexec the kernel file signatures are/can be validated
prior to actual load, the information(PE/ima signature) is not carried
to the next session. This lead to loss of information.
Carrying forward the ima measurement log to the next kexec'ed session
allows a verifying party to get the entire runtime event log since the
last full reboot, since that is when PCRs were last reset.
Changelog:
v1:
- add new fdt porperties to mark start and end for ima measurement
log.
- use fdt_* functions to add/remove fdt properties and memory
allocations.
- remove additional check for endian-ness as they are checked
in fdt_* functions.
v0:
- Add support to carry ima measurement log in arm64,
uses same code as powerpc.
Prakhar Srivastava (1):
Add support for arm64 to carry ima measurement log in kexec_file_load
arch/arm64/Kconfig | 7 +
arch/arm64/include/asm/ima.h | 29 ++++
arch/arm64/include/asm/kexec.h | 5 +
arch/arm64/kernel/Makefile | 3 +-
arch/arm64/kernel/ima_kexec.c | 213 +++++++++++++++++++++++++
arch/arm64/kernel/machine_kexec_file.c | 6 +
6 files changed, 262 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/include/asm/ima.h
create mode 100644 arch/arm64/kernel/ima_kexec.c
--
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
* Re: kexec broken on later 4 series arm kernels ?
From: Russell King - ARM Linux admin @ 2019-09-09 22:31 UTC (permalink / raw)
To: Aggelis Aggelis; +Cc: linux-arm-kernel
In-Reply-To: <CAKUkA50BOqpW7ZCQc9nGGE8ceYZuZMsPk-2rfq1txu3R9114TA@mail.gmail.com>
On Mon, Sep 09, 2019 at 09:15:58PM +0300, Aggelis Aggelis wrote:
> I use MitySOM-5CSX dev kit (cyclone v)and i would like to boot to a
> different kernel using kexec.
>
> In my configuration:
>
> KERNEL : https://github.com/altera-opensource/linux-socfpga/archive/socfpga-4.9.76-ltsi-rt.zip
> COMPILER : https://releases.linaro.org/archive/14.04/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux.tar.bz2
>
> In the kernel configuration kexec is enabled
>
> zcat /proc/config.gz |grep KEXEC
> CONFIG_KEXEC_CORE=y
> CONFIG_KEXEC=y
>
> and the default kernel cmdline is
>
> # cat /proc/cmdline
> root=/dev/mmcblk0p3 rootwait rw earlycon
>
> First we load kernel with
>
> #./kexec --version
> kexec-tools 2.0.19
>
> # kexec -d -l zImagebkx --dtb=socfpga_cyclone5_mitysom5csx_devkit.dtb
> --command-line="root=/dev/mmcblk0p3 rootwait rw earlycon"
> syscall kexec_file_load not available.
> kernel: 0xb6a9d008 kernel_size: 0x4a55c8
> MEMORY RANGES
> 0000000000000000-000000003fffffff (0)
> zImage header: 0x016f2818 0x00000000 0x004a55c8
> zImage size 0x4a55c8, file size 0x4a55c8
> zImage requires 0x004b65c8 bytes
> Kernel: address=0x00008000 size=0x0178fce8
> DT : address=0x01799000 size=0x00007cf4
Same comments as per your previous email on this same subject.
> kexec_load: entry = 0x8000 flags = 0x280000
> nr_segments = 2
> segment[0].buf = 0xb6a9d008kernel
> segment[0].bufsz = 0x4a55cc
> segment[0].mem = 0x8000
> segment[0].memsz = 0x4a6000
> segment[1].buf = 0x8e610
> segment[1].bufsz = 0x7cf4
> segment[1].mem = 0x1799000
> segment[1].memsz = 0x8000
>
> and kexec kernel with
>
> # kexec -e
> [ 134.110855] kexec_core: Starting new kernel
> [ 134.115064] Disabling non-boot CPUs ...
> [ 134.176961] CPU1: shutdown
> [ 134.180624] Bye!
> Uncompressing Linux... done, booting the kernel.
>
> and then nothing no messages on console.
>
> The same kernel boots successfully with U-Boot
>
> Using kernel 4.1.22 from https://github.com/dlaut/linux-socfpga and
> applying the patch described in https://patchwork.kernel.org/patch/6504321/
> i successfully kexeced 4.9.76 kernel from 4.1.22 using the same
> kexec-tools 2.0.19.
>
> root@node1:/mnt/test#uname -a Linux node1 4.1.22-ltsi-altera #2 SMP
> PREEMPT Mon Jul 29 12:38:06 EEST 2019 armv7l GNU/L
> root@node1:/mnt/test# kexec -d -e
> [ 46.306102] kexec: Starting new kernel
> [ 46.309928] Disabling non-boot CPUs ...
> [ 46.306102] kexec: Starting new kernel
> [ 46.378053] CPU1: shutdown
> [ 46.381875] Bye!
> Uncompressing Linux... done, booting the kernel.
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 4.9.76-rt61-ltsi-altera (aggelis@corei5)
> (gcc version 4.8.3 20140401 (prerelease) (crosstool-NG l9
> [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [ 0.000000] OF: fdt:Machine model: MitySOM-5CSX Altera SOCFPGA Cyclone V
> [ 0.000000] cma: Reserved 16 MiB at 0x3f000000
> [ 0.000000] Memory policy: Data cache writealloc
> [ 0.000000] percpu: Embedded 15 pages/cpu @ef6bf000 s29184 r8192
> d24064 u61440
> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 260416
> [ 0.000000] Kernel command line: root=/dev/mmcblk0p3 rootwait
> [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [ 0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [ 0.000000] allocated 1048576 bytes of page_ext
> ...
> ...
> Angstrom v2017.12 - Kernel 4.9.76-rt61-ltsi-altera
> node1 login:
>
> The kexec patch applied on the 4.1.22 kernel (enabling kexec on
> socfpga) is already present in 4.9.76 kernel.
>
> Since the same kexec 2.0.19 userland tool runs successfully in the
> older 4.1.22
> but not in 4.9.76 kernel did something break in kexec implementation
> in later 4 series kernels?
>
> Aggelis Aggelis
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix unreachable code issue with cmpxchg
From: Nick Desaulniers @ 2019-09-09 21:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Catalin Marinas, LKML, clang-built-linux,
Andrew Murray, Nathan Chancellor, Will Deacon, Linux ARM
In-Reply-To: <CAKwvOdn90naN2qLx6qBCii67HNOYeJmVqTKEKuUpXcTXLEEaLA@mail.gmail.com>
On Mon, Sep 9, 2019 at 2:06 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Mon, Sep 9, 2019 at 1:21 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined
> > when CONFIG_OPTIMIZE_INLINING is set.
> > Clang then fails a compile-time assertion, because it cannot tell at
> > compile time what the size of the argument is:
> >
> > mm/memcontrol.o: In function `__cmpxchg_mb':
> > memcontrol.c:(.text+0x1a4c): undefined reference to `__compiletime_assert_175'
> > memcontrol.c:(.text+0x1a4c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__compiletime_assert_175'
> >
> > Mark all of the cmpxchg() style functions as __always_inline to
> > ensure that the compiler can see the result.
>
> Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Also, I think a Link tag may be appropriate as I believe it fixes this report:
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/648
>
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm64/include/asm/cmpxchg.h | 15 ++++++++-------
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> > index a1398f2f9994..fd64dc8a235f 100644
> > --- a/arch/arm64/include/asm/cmpxchg.h
> > +++ b/arch/arm64/include/asm/cmpxchg.h
> > @@ -19,7 +19,7 @@
> > * acquire+release for the latter.
> > */
> > #define __XCHG_CASE(w, sfx, name, sz, mb, nop_lse, acq, acq_lse, rel, cl) \
> > -static inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr) \
> > +static __always_inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr)\
> > { \
> > u##sz ret; \
> > unsigned long tmp; \
> > @@ -62,7 +62,7 @@ __XCHG_CASE( , , mb_, 64, dmb ish, nop, , a, l, "memory")
> > #undef __XCHG_CASE
> >
> > #define __XCHG_GEN(sfx) \
> > -static inline unsigned long __xchg##sfx(unsigned long x, \
> > +static __always_inline unsigned long __xchg##sfx(unsigned long x, \
> > volatile void *ptr, \
> > int size) \
> > { \
> > @@ -103,8 +103,9 @@ __XCHG_GEN(_mb)
> > #define arch_xchg_release(...) __xchg_wrapper(_rel, __VA_ARGS__)
> > #define arch_xchg(...) __xchg_wrapper( _mb, __VA_ARGS__)
> >
> > -#define __CMPXCHG_CASE(name, sz) \
> > -static inline u##sz __cmpxchg_case_##name##sz(volatile void *ptr, \
> > +#define __CMPXCHG_CASE(name, sz) \
> > +static __always_inline u##sz \
> > +__cmpxchg_case_##name##sz(volatile void *ptr, \
> > u##sz old, \
> > u##sz new) \
> > { \
> > @@ -148,7 +149,7 @@ __CMPXCHG_DBL(_mb)
> > #undef __CMPXCHG_DBL
> >
> > #define __CMPXCHG_GEN(sfx) \
> > -static inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
> > +static __always_inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
> > unsigned long old, \
> > unsigned long new, \
> > int size) \
> > @@ -230,7 +231,7 @@ __CMPXCHG_GEN(_mb)
> > })
> >
> > #define __CMPWAIT_CASE(w, sfx, sz) \
> > -static inline void __cmpwait_case_##sz(volatile void *ptr, \
> > +static __always_inline void __cmpwait_case_##sz(volatile void *ptr, \
> > unsigned long val) \
> > { \
> > unsigned long tmp; \
> > @@ -255,7 +256,7 @@ __CMPWAIT_CASE( , , 64);
> > #undef __CMPWAIT_CASE
> >
> > #define __CMPWAIT_GEN(sfx) \
> > -static inline void __cmpwait##sfx(volatile void *ptr, \
> > +static __always_inline void __cmpwait##sfx(volatile void *ptr, \
> > unsigned long val, \
> > int size) \
> > { \
> > --
> > 2.20.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20190909202153.144970-1-arnd%40arndb.de.
>
>
>
> --
> Thanks,
> ~Nick Desaulniers
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix unreachable code issue with cmpxchg
From: Nick Desaulniers @ 2019-09-09 21:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Catalin Marinas, LKML, clang-built-linux,
Andrew Murray, Will Deacon, Linux ARM
In-Reply-To: <20190909202153.144970-1-arnd@arndb.de>
On Mon, Sep 9, 2019 at 1:21 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined
> when CONFIG_OPTIMIZE_INLINING is set.
> Clang then fails a compile-time assertion, because it cannot tell at
> compile time what the size of the argument is:
>
> mm/memcontrol.o: In function `__cmpxchg_mb':
> memcontrol.c:(.text+0x1a4c): undefined reference to `__compiletime_assert_175'
> memcontrol.c:(.text+0x1a4c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__compiletime_assert_175'
>
> Mark all of the cmpxchg() style functions as __always_inline to
> ensure that the compiler can see the result.
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm64/include/asm/cmpxchg.h | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> index a1398f2f9994..fd64dc8a235f 100644
> --- a/arch/arm64/include/asm/cmpxchg.h
> +++ b/arch/arm64/include/asm/cmpxchg.h
> @@ -19,7 +19,7 @@
> * acquire+release for the latter.
> */
> #define __XCHG_CASE(w, sfx, name, sz, mb, nop_lse, acq, acq_lse, rel, cl) \
> -static inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr) \
> +static __always_inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr)\
> { \
> u##sz ret; \
> unsigned long tmp; \
> @@ -62,7 +62,7 @@ __XCHG_CASE( , , mb_, 64, dmb ish, nop, , a, l, "memory")
> #undef __XCHG_CASE
>
> #define __XCHG_GEN(sfx) \
> -static inline unsigned long __xchg##sfx(unsigned long x, \
> +static __always_inline unsigned long __xchg##sfx(unsigned long x, \
> volatile void *ptr, \
> int size) \
> { \
> @@ -103,8 +103,9 @@ __XCHG_GEN(_mb)
> #define arch_xchg_release(...) __xchg_wrapper(_rel, __VA_ARGS__)
> #define arch_xchg(...) __xchg_wrapper( _mb, __VA_ARGS__)
>
> -#define __CMPXCHG_CASE(name, sz) \
> -static inline u##sz __cmpxchg_case_##name##sz(volatile void *ptr, \
> +#define __CMPXCHG_CASE(name, sz) \
> +static __always_inline u##sz \
> +__cmpxchg_case_##name##sz(volatile void *ptr, \
> u##sz old, \
> u##sz new) \
> { \
> @@ -148,7 +149,7 @@ __CMPXCHG_DBL(_mb)
> #undef __CMPXCHG_DBL
>
> #define __CMPXCHG_GEN(sfx) \
> -static inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
> +static __always_inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
> unsigned long old, \
> unsigned long new, \
> int size) \
> @@ -230,7 +231,7 @@ __CMPXCHG_GEN(_mb)
> })
>
> #define __CMPWAIT_CASE(w, sfx, sz) \
> -static inline void __cmpwait_case_##sz(volatile void *ptr, \
> +static __always_inline void __cmpwait_case_##sz(volatile void *ptr, \
> unsigned long val) \
> { \
> unsigned long tmp; \
> @@ -255,7 +256,7 @@ __CMPWAIT_CASE( , , 64);
> #undef __CMPWAIT_CASE
>
> #define __CMPWAIT_GEN(sfx) \
> -static inline void __cmpwait##sfx(volatile void *ptr, \
> +static __always_inline void __cmpwait##sfx(volatile void *ptr, \
> unsigned long val, \
> int size) \
> { \
> --
> 2.20.0
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20190909202153.144970-1-arnd%40arndb.de.
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: fix unreachable code issue with cmpxchg
From: Arnd Bergmann @ 2019-09-09 20:21 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, Arnd Bergmann, linux-kernel, clang-built-linux,
Andrew Murray, linux-arm-kernel
On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined
when CONFIG_OPTIMIZE_INLINING is set.
Clang then fails a compile-time assertion, because it cannot tell at
compile time what the size of the argument is:
mm/memcontrol.o: In function `__cmpxchg_mb':
memcontrol.c:(.text+0x1a4c): undefined reference to `__compiletime_assert_175'
memcontrol.c:(.text+0x1a4c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__compiletime_assert_175'
Mark all of the cmpxchg() style functions as __always_inline to
ensure that the compiler can see the result.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm64/include/asm/cmpxchg.h | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
index a1398f2f9994..fd64dc8a235f 100644
--- a/arch/arm64/include/asm/cmpxchg.h
+++ b/arch/arm64/include/asm/cmpxchg.h
@@ -19,7 +19,7 @@
* acquire+release for the latter.
*/
#define __XCHG_CASE(w, sfx, name, sz, mb, nop_lse, acq, acq_lse, rel, cl) \
-static inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr) \
+static __always_inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr)\
{ \
u##sz ret; \
unsigned long tmp; \
@@ -62,7 +62,7 @@ __XCHG_CASE( , , mb_, 64, dmb ish, nop, , a, l, "memory")
#undef __XCHG_CASE
#define __XCHG_GEN(sfx) \
-static inline unsigned long __xchg##sfx(unsigned long x, \
+static __always_inline unsigned long __xchg##sfx(unsigned long x, \
volatile void *ptr, \
int size) \
{ \
@@ -103,8 +103,9 @@ __XCHG_GEN(_mb)
#define arch_xchg_release(...) __xchg_wrapper(_rel, __VA_ARGS__)
#define arch_xchg(...) __xchg_wrapper( _mb, __VA_ARGS__)
-#define __CMPXCHG_CASE(name, sz) \
-static inline u##sz __cmpxchg_case_##name##sz(volatile void *ptr, \
+#define __CMPXCHG_CASE(name, sz) \
+static __always_inline u##sz \
+__cmpxchg_case_##name##sz(volatile void *ptr, \
u##sz old, \
u##sz new) \
{ \
@@ -148,7 +149,7 @@ __CMPXCHG_DBL(_mb)
#undef __CMPXCHG_DBL
#define __CMPXCHG_GEN(sfx) \
-static inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
+static __always_inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
unsigned long old, \
unsigned long new, \
int size) \
@@ -230,7 +231,7 @@ __CMPXCHG_GEN(_mb)
})
#define __CMPWAIT_CASE(w, sfx, sz) \
-static inline void __cmpwait_case_##sz(volatile void *ptr, \
+static __always_inline void __cmpwait_case_##sz(volatile void *ptr, \
unsigned long val) \
{ \
unsigned long tmp; \
@@ -255,7 +256,7 @@ __CMPWAIT_CASE( , , 64);
#undef __CMPWAIT_CASE
#define __CMPWAIT_GEN(sfx) \
-static inline void __cmpwait##sfx(volatile void *ptr, \
+static __always_inline void __cmpwait##sfx(volatile void *ptr, \
unsigned long val, \
int size) \
{ \
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] iommu/io-pgtable: Move some initialization data to .init.rodata
From: Christophe JAILLET @ 2019-09-09 20:19 UTC (permalink / raw)
To: will, robin.murphy, joro
Cc: Christophe JAILLET, iommu, kernel-janitors, linux-kernel,
linux-arm-kernel
The memory used by '__init' functions can be freed once the initialization
phase has been performed.
Mark some 'static const' array defined and used within some '__init'
functions as '__initconst', so that the corresponding data can also be
discarded.
Without '__initconst', the data are put in the .rodata section.
With the qualifier, they are put in the .init.rodata section.
With gcc 8.3.0, the following changes have been measured:
Without '__initconst':
section size
.rodata 00000720
.init.rodata 00000018
With '__initconst':
section size
.rodata 00000660
.init.rodata 00000058
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Adding __initconst "within" a function is not in line with kernel/include/init.h
which states that:
* Don't forget to initialize data not at file scope, i.e. within a function,
* as gcc otherwise puts the data into the bss section and not into the init
* section.
However, having the array within the function or out-side the function
seems to have no impact in the generated code and in the section used.
According to my test, both put the data in .init.rodata.
Maybe the comment is outdated or related to some older vesion of gcc.
---
drivers/iommu/io-pgtable-arm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 161a7d56264d..24076f0560c6 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -1109,7 +1109,7 @@ static void __init arm_lpae_dump_ops(struct io_pgtable_ops *ops)
static int __init arm_lpae_run_tests(struct io_pgtable_cfg *cfg)
{
- static const enum io_pgtable_fmt fmts[] = {
+ static const enum io_pgtable_fmt fmts[] __initconst = {
ARM_64_LPAE_S1,
ARM_64_LPAE_S2,
};
@@ -1208,13 +1208,13 @@ static int __init arm_lpae_run_tests(struct io_pgtable_cfg *cfg)
static int __init arm_lpae_do_selftests(void)
{
- static const unsigned long pgsize[] = {
+ static const unsigned long pgsize[] __initconst = {
SZ_4K | SZ_2M | SZ_1G,
SZ_16K | SZ_32M,
SZ_64K | SZ_512M,
};
- static const unsigned int ias[] = {
+ static const unsigned int ias[] __initconst = {
32, 36, 40, 42, 44, 48,
};
--
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 v5 0/4] Raspberry Pi 4 DMA addressing support
From: Nicolas Saenz Julienne @ 2019-09-09 19:50 UTC (permalink / raw)
To: Stefan Wahren, catalin.marinas, hch, marc.zyngier, robh+dt,
linux-arm-kernel, linux-mm, linux-riscv
Cc: f.fainelli, robin.murphy, linux-kernel, mbrugger,
linux-rpi-kernel, phill, will, m.szyprowski
In-Reply-To: <5a8af6e9-6b90-ce26-ebd7-9ee626c9fa0e@gmx.net>
[-- Attachment #1.1: Type: text/plain, Size: 3074 bytes --]
On Mon, 2019-09-09 at 21:33 +0200, Stefan Wahren wrote:
> Hi Nicolas,
>
> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne:
> > Hi all,
> > this series attempts to address some issues we found while bringing up
> > the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
> > up of these discussions:
> > v4: https://lkml.org/lkml/2019/9/6/352
> > v3: https://lkml.org/lkml/2019/9/2/589
> > v2: https://lkml.org/lkml/2019/8/20/767
> > v1: https://lkml.org/lkml/2019/7/31/922
> > RFC: https://lkml.org/lkml/2019/7/17/476
> >
> > The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can
> > only address the first GB: their DMA address range is
> > 0xc0000000-0xfc000000 which is aliased to the first GB of physical
> > memory 0x00000000-0x3c000000. Note that only some peripherals have these
> > limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider
> > view of the address space by virtue of being hooked up trough a second
> > interconnect.
> >
> > Part of this is solved on arm32 by setting up the machine specific
> > '.dma_zone_size = SZ_1G', which takes care of reserving the coherent
> > memory area at the right spot. That said no buffer bouncing (needed for
> > dma streaming) is available at the moment, but that's a story for
> > another series.
> >
> > Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only
> > ZONE_DMA32 is created which is interpreted by dma-direct and the arm64
> > arch code as if all peripherals where be able to address the first 4GB
> > of memory.
> >
> > In the light of this, the series implements the following changes:
> >
> > - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G
> > area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far
> > the RPi4 is the only arm64 device with such DMA addressing limitations
> > so this hardcoded solution was deemed preferable.
> >
> > - Properly set ARCH_ZONE_DMA_BITS.
> >
> > - Reserve the CMA area in a place suitable for all peripherals.
> >
> > This series has been tested on multiple devices both by checking the
> > zones setup matches the expectations and by double-checking physical
> > addresses on pages allocated on the three relevant areas GFP_DMA,
> > GFP_DMA32, GFP_KERNEL:
> >
> > - On an RPi4 with variations on the ram memory size. But also forcing
> > the situation where all three memory zones are nonempty by setting a 3G
> > ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support.
> >
> i like to test this series on Raspberry Pi 4 and i have some questions
> to get arm64 running:
>
> Do you use U-Boot? Which tree?
No, I boot directly.
> Are there any config.txt tweaks necessary?
I'm using the foundation's arm64 stub. Though I'm not 100% it's needed anymore
with the latest firmware.
config.txt:
arm_64bit=1
armstub=armstub8-gic.bin
enable_gic=1
enable_uart=1
Apart from that the series is based on today's linux-next plus your RPi4
bringup patches.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- 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 v2 4/5] ARM: davinci: support multiplatform build for ARM v5
From: Arnd Bergmann @ 2019-09-09 19:38 UTC (permalink / raw)
To: Sekhar Nori
Cc: David Lechner, Kevin Hilman, Bartosz Golaszewski,
linux-kernel@vger.kernel.org, Bartosz Golaszewski, Linux ARM
In-Reply-To: <5fd79cda-59d4-b69b-9902-5d01e1087c62@ti.com>
On Mon, Sep 9, 2019 at 9:38 AM Sekhar Nori <nsekhar@ti.com> wrote:
>
> On 25/07/19 6:42 PM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > Add modifications necessary to make davinci part of the ARM v5
> > multiplatform build.
> >
> > Move the arch-specific configuration out of arch/arm/Kconfig and
> > into mach-davinci/Kconfig. Remove the sub-menu for DaVinci
> > implementations (they'll be visible directly under the system type.
> > Select all necessary options not already selected by ARCH_MULTI_V5.
> > Update davinci_all_defconfig. Explicitly include the mach-specific
> > headers in mach-davinci/Makefile.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Acked-by: Sekhar Nori <nsekhar@ti.com>
Ok, pulled both into arm/soc.
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 0/4] Raspberry Pi 4 DMA addressing support
From: Stefan Wahren @ 2019-09-09 19:33 UTC (permalink / raw)
To: Nicolas Saenz Julienne, catalin.marinas, hch, marc.zyngier,
robh+dt, linux-arm-kernel, linux-mm, linux-riscv
Cc: f.fainelli, robin.murphy, linux-kernel, mbrugger,
linux-rpi-kernel, phill, will, m.szyprowski
In-Reply-To: <20190909095807.18709-1-nsaenzjulienne@suse.de>
Hi Nicolas,
Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne:
> Hi all,
> this series attempts to address some issues we found while bringing up
> the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
> up of these discussions:
> v4: https://lkml.org/lkml/2019/9/6/352
> v3: https://lkml.org/lkml/2019/9/2/589
> v2: https://lkml.org/lkml/2019/8/20/767
> v1: https://lkml.org/lkml/2019/7/31/922
> RFC: https://lkml.org/lkml/2019/7/17/476
>
> The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can
> only address the first GB: their DMA address range is
> 0xc0000000-0xfc000000 which is aliased to the first GB of physical
> memory 0x00000000-0x3c000000. Note that only some peripherals have these
> limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider
> view of the address space by virtue of being hooked up trough a second
> interconnect.
>
> Part of this is solved on arm32 by setting up the machine specific
> '.dma_zone_size = SZ_1G', which takes care of reserving the coherent
> memory area at the right spot. That said no buffer bouncing (needed for
> dma streaming) is available at the moment, but that's a story for
> another series.
>
> Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only
> ZONE_DMA32 is created which is interpreted by dma-direct and the arm64
> arch code as if all peripherals where be able to address the first 4GB
> of memory.
>
> In the light of this, the series implements the following changes:
>
> - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G
> area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far
> the RPi4 is the only arm64 device with such DMA addressing limitations
> so this hardcoded solution was deemed preferable.
>
> - Properly set ARCH_ZONE_DMA_BITS.
>
> - Reserve the CMA area in a place suitable for all peripherals.
>
> This series has been tested on multiple devices both by checking the
> zones setup matches the expectations and by double-checking physical
> addresses on pages allocated on the three relevant areas GFP_DMA,
> GFP_DMA32, GFP_KERNEL:
>
> - On an RPi4 with variations on the ram memory size. But also forcing
> the situation where all three memory zones are nonempty by setting a 3G
> ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support.
>
i like to test this series on Raspberry Pi 4 and i have some questions
to get arm64 running:
Do you use U-Boot? Which tree?
Are there any config.txt tweaks necessary?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH V3 5/5] media: platform: mtk-mdp3: Add struct tuning_addr and img_sw_buffer
From: frederic.chen @ 2019-09-09 19:22 UTC (permalink / raw)
To: hans.verkuil, laurent.pinchart+renesas, tfiga, matthias.bgg,
mchehab
Cc: shik, devicetree, Sean.Cheng, Rynn.Wu, Allan.Yang, srv_heupstream,
holmes.chiou, suleiman, Jerry-ch.Chen, jungo.lin, sj.huang,
yuzhao, linux-mediatek, zwisler, christie.yu, frederic.chen,
linux-arm-kernel, linux-media
In-Reply-To: <20190909192244.9367-1-frederic.chen@mediatek.com>
From: Frederic Chen <frederic.chen@mediatek.com>
We added a struct tuning_addr which contains a field "present"
so that the driver can tell the firmware if we have user tuning
dataor not.
The strcut img_sw_buffer is also added. This struct has no cpu address
field and uses a handle instead so that we don't pass a cpu address
to co-processor.
Signed-off-by: Frederic Chen <frederic.chen@mediatek.com>
---
drivers/media/platform/mtk-mdp3/mtk-img-ipi.h | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp3/mtk-img-ipi.h b/drivers/media/platform/mtk-mdp3/mtk-img-ipi.h
index 9fabe7e8b71d..f61e61faf636 100644
--- a/drivers/media/platform/mtk-mdp3/mtk-img-ipi.h
+++ b/drivers/media/platform/mtk-mdp3/mtk-img-ipi.h
@@ -38,6 +38,12 @@ struct img_addr {
u32 iova; /* Used by IOMMU HW access */
} __attribute__ ((__packed__));
+struct tuning_addr {
+ u32 present;
+ u32 pa; /* Used by CM4 access */
+ u32 iova; /* Used by IOMMU HW access */
+} __attribute__ ((__packed__));
+
struct img_sw_addr {
u64 va; /* Used by APMCU access */
u32 pa; /* Used by CM4 access */
@@ -105,16 +111,21 @@ struct img_ipi_frameparam {
u64 drv_data;
struct img_input inputs[IMG_MAX_HW_INPUTS];
struct img_output outputs[IMG_MAX_HW_OUTPUTS];
- struct img_addr tuning_data;
+ struct tuning_addr tuning_data;
struct img_addr subfrm_data;
struct img_sw_addr config_data;
struct img_sw_addr self_data;
/* u8 pq_data[]; */
} __attribute__ ((__packed__));
+struct img_sw_buffer {
+ u64 handle; /* Used by APMCU access */
+ u32 scp_addr; /* Used by CM4 access */
+} __attribute__ ((__packed__));
+
struct img_ipi_param {
u8 usage;
- struct img_sw_addr frm_param;
+ struct img_sw_buffer frm_param;
} __attribute__ ((__packed__));
struct img_frameparam {
--
2.18.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
* [RFC PATCH V3 1/5] dt-bindings: mt8183: Added DIP dt-bindings
From: frederic.chen @ 2019-09-09 19:22 UTC (permalink / raw)
To: hans.verkuil, laurent.pinchart+renesas, tfiga, matthias.bgg,
mchehab
Cc: shik, devicetree, Sean.Cheng, Rynn.Wu, Allan.Yang, srv_heupstream,
holmes.chiou, suleiman, Jerry-ch.Chen, jungo.lin, sj.huang,
yuzhao, linux-mediatek, zwisler, christie.yu, frederic.chen,
linux-arm-kernel, linux-media
In-Reply-To: <20190909192244.9367-1-frederic.chen@mediatek.com>
From: Frederic Chen <frederic.chen@mediatek.com>
This patch adds DT binding documentation for the Digital Image
Processing (DIP) unit of camera ISP system on Mediatek's SoCs.
It depends on the SCP and MDP 3 patch as following:
1. dt-bindings: Add a binding for Mediatek SCP
https://patchwork.kernel.org/patch/11027247/
2. dt-binding: mt8183: Add Mediatek MDP3 dt-bindings
https://patchwork.kernel.org/patch/10945603/
Signed-off-by: Frederic Chen <frederic.chen@mediatek.com>
---
.../bindings/media/mediatek,mt8183-dip.txt | 40 +++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8183-dip.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8183-dip.txt b/Documentation/devicetree/bindings/media/mediatek,mt8183-dip.txt
new file mode 100644
index 000000000000..3a0435513089
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mt8183-dip.txt
@@ -0,0 +1,40 @@
+* Mediatek Digital Image Processor (DIP)
+
+Digital Image Processor (DIP) unit in Mediatek ISP system is responsible for
+image content adjustment according to the tuning parameters. DIP can process
+the image form memory buffer and output the processed image to multiple output
+buffers. Furthermore, it can support demosaicing and noise reduction on the
+images.
+
+Required properties:
+- compatible: "mediatek,mt8183-dip"
+- reg: Physical base address and length of the function block register space
+- interrupts: interrupt number to the cpu
+- iommus: should point to the respective IOMMU block with master port as
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ for details.
+- mediatek,mdp3: should point to the respective mdp block. DIP hardware
+ connects to MDP and we can get the processed image with both effect of the
+ two blocks.
+- mediatek,larb: must contain the local arbiters in the current SoCs, see
+ Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+ for details.
+- mediatek,scp: should point to the scp node since the we use SCP
+ coprocessor to control DIP hardware
+- clocks: must contain the local arbiters 5 (LARB5) and DIP clock
+- clock-names: must contain "larb5" and "dip"
+
+Example:
+ dip: dip@15022000 {
+ compatible = "mediatek,mt8183-dip";
+ mediatek,larb = <&larb5>;
+ mediatek,mdp3 = <&mdp_rdma0>;
+ mediatek,scp = <&scp>;
+ iommus = <&iommu M4U_PORT_CAM_IMGI>;
+ reg = <0 0x15022000 0 0x6000>;
+ interrupts = <GIC_SPI 268 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&imgsys CLK_IMG_LARB5>,
+ <&imgsys CLK_IMG_DIP>;
+ clock-names = "larb5",
+ "dip";
+ };
--
2.18.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
* [RFC PATCH V3 2/5] dts: arm64: mt8183: Add DIP nodes
From: frederic.chen @ 2019-09-09 19:22 UTC (permalink / raw)
To: hans.verkuil, laurent.pinchart+renesas, tfiga, matthias.bgg,
mchehab
Cc: shik, devicetree, Sean.Cheng, Rynn.Wu, Allan.Yang, srv_heupstream,
holmes.chiou, suleiman, Jerry-ch.Chen, jungo.lin, sj.huang,
yuzhao, linux-mediatek, zwisler, christie.yu, frederic.chen,
linux-arm-kernel, linux-media
In-Reply-To: <20190909192244.9367-1-frederic.chen@mediatek.com>
From: Frederic Chen <frederic.chen@mediatek.com>
This patch adds nodes for Digital Image Processing (DIP). DIP is
embedded in Mediatek SoCs and works with the co-processor to
adjust image content according to tuning input data. It also
provides image format conversion, resizing, and rotation
features.
Signed-off-by: Frederic Chen <frederic.chen@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 0f2646c9eb65..d7b0fb8230f0 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -513,6 +513,22 @@
#clock-cells = <1>;
};
+ dip: dip@15022000 {
+ compatible = "mediatek,mt8183-dip";
+ mediatek,larb = <&larb5>;
+ mediatek,mdp3 = <&mdp_rdma0>;
+ mediatek,scp = <&scp>;
+ iommus = <&iommu M4U_PORT_CAM_IMGI>;
+ reg = <0 0x15022000 0 0x6000>;
+ interrupts = <GIC_SPI 268 IRQ_TYPE_LEVEL_LOW>;
+ clocks =
+ <&imgsys CLK_IMG_LARB5>,
+ <&imgsys CLK_IMG_DIP>;
+ clock-names =
+ "larb5",
+ "dip";
+ };
+
vdecsys: syscon@16000000 {
compatible = "mediatek,mt8183-vdecsys", "syscon";
reg = <0 0x16000000 0 0x1000>;
--
2.18.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
* [RFC PATCH V3 3/5] media: platform: Add Mediatek DIP driver KConfig
From: frederic.chen @ 2019-09-09 19:22 UTC (permalink / raw)
To: hans.verkuil, laurent.pinchart+renesas, tfiga, matthias.bgg,
mchehab
Cc: shik, devicetree, Sean.Cheng, Rynn.Wu, Allan.Yang, srv_heupstream,
holmes.chiou, suleiman, Jerry-ch.Chen, jungo.lin, sj.huang,
yuzhao, linux-mediatek, zwisler, christie.yu, frederic.chen,
linux-arm-kernel, linux-media
In-Reply-To: <20190909192244.9367-1-frederic.chen@mediatek.com>
From: Frederic Chen <frederic.chen@mediatek.com>
This patch adds KConfig for Mediatek Digital Image Processing
driver(DIP). DIP is embedded in Mediatek SoCs. It provides
image format conversion, resizing, and rotation function.
Signed-off-by: Frederic Chen <frederic.chen@mediatek.com>
---
drivers/media/platform/Kconfig | 2 ++
drivers/media/platform/mtk-isp/Kconfig | 19 +++++++++++++++++++
2 files changed, 21 insertions(+)
create mode 100644 drivers/media/platform/mtk-isp/Kconfig
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0c725d4dcf80..b8501e1b134f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -32,6 +32,8 @@ source "drivers/media/platform/davinci/Kconfig"
source "drivers/media/platform/omap/Kconfig"
+source "drivers/media/platform/mtk-isp/Kconfig"
+
config VIDEO_ASPEED
tristate "Aspeed AST2400 and AST2500 Video Engine driver"
depends on VIDEO_V4L2
diff --git a/drivers/media/platform/mtk-isp/Kconfig b/drivers/media/platform/mtk-isp/Kconfig
new file mode 100644
index 000000000000..a4267db70c24
--- /dev/null
+++ b/drivers/media/platform/mtk-isp/Kconfig
@@ -0,0 +1,19 @@
+config VIDEO_MEDIATEK_ISP_DIP
+ bool "Mediatek Digital Image Processing function"
+ select VIDEO_V4L2_SUBDEV_API
+ select VIDEOBUF2_DMA_CONTIG
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_V4L2
+ select VIDEOBUF2_MEMOPS
+ select MEDIA_CONTROLLER
+
+ default n
+ help
+ Support the basic Digital Image Processing (DIP) driver.
+
+ DIP driver provides image format conversion, resizing,
+ and rotation function through the low power hardware.
+ DIP also supports multiple output feature. It can
+ generate two or more output image with different effect
+ based on a single input image at the same time.
+
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC] ARM: omap3: Enable HWMODS for HW Random Number Generator
From: Adam Ford @ 2019-09-09 19:19 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Rutland, devicetree, Paul Walmsley, Aaro Koskinen,
Russell King, Linux Kernel Mailing List, Tero Kristo, Rob Herring,
Benoît Cousson, Pali Rohár, Linux-OMAP, Adam Ford,
arm-soc
In-Reply-To: <20190909163543.GQ52127@atomide.com>
On Mon, Sep 9, 2019 at 11:35 AM Tony Lindgren <tony@atomide.com> wrote:
>
> * Pali Rohár <pali.rohar@gmail.com> [190909 13:41]:
> > On Monday 09 September 2019 08:37:09 Adam Ford wrote:
> > > I applied this on 5.3 and it is working. I assume the same is true in for-next.
>
> Hmm I noticed I stopped getting RNG data after several rmmod modprobe
> cycles, or several hd /dev/random reads. Anybody else seeing that?
On the Logic PD Torpedo, I was able to read from /dev/hwrng and
/dev/random 10x without issue
I have installed rng-tools and I have sshd running and some other
stuff that might get in the way if I do an rmmod too much, but I
removed and modprobed the omap-rng 3x and never saw an issue reading
either /dev/hwrng or /dev/random.
I have been meaning to test this on the AM3517 and haven't gotten to
it yet, but I assume you've only tested omap3630, is that true?
adam
>
> > > Do you want to submit a formal patch? I can mark it as 'tested-by'
> > > This really helps speed up the startup sequence on boards with sshd
> > > because it delays for nearly 80 seconds waiting for entropy without
> > > the hwrng.
> >
> > Hi! When applying a patch, could you please disable this rng for n900?
> >
> > In omap3-n900.dts for rng should be status = "disabled" (as Tony already
> > wrote), similarly like for aes.
>
> Yeah I'll post a proper patch after -rc1.
>
> Regards,
>
> Tony
_______________________________________________
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 2/2] ARM: exynos: Enable support for ARM architected timers
From: Krzysztof Kozlowski @ 2019-09-09 18:58 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Chanwoo Choi, linux-samsung-soc, Marc Zyngier, linux-arm-kernel,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20190828121005.29368-3-m.szyprowski@samsung.com>
On Wed, Aug 28, 2019 at 02:10:05PM +0200, Marek Szyprowski wrote:
> ARM architected timer can be used together with Exynos MultiCore Timer
> driver, so enable support for it. Support for ARM architected timers is
> essential for enabling proper KVM support.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mach-exynos/Kconfig | 1 +
Thanks, applied this one only from the set (I will have send another soc
pull request before merge window).
Best regards,
Krzysztof
_______________________________________________
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 v1 1/1] arm64: dts: Fix gpio to pinmux mapping
From: Ray Jui @ 2019-09-09 18:56 UTC (permalink / raw)
To: Rayagonda Kokatanur, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Rob Herring, Mark Rutland,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1568018127-26730-1-git-send-email-rayagonda.kokatanur@broadcom.com>
On 9/9/19 1:35 AM, Rayagonda Kokatanur wrote:
> There are total of 151 non-secure gpio (0-150) and four
> pins of pinmux (91, 92, 93 and 94) are not mapped to any
> gpio pin, hence update same in DT.
>
> Fixes: 8aa428cc1e2e ("arm64: dts: Add pinctrl DT nodes for Stingray SOC")
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
> arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi | 5 +++--
> arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 3 +--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
> index 8a3a770..56789cc 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
> @@ -42,13 +42,14 @@
>
> pinmux: pinmux@14029c {
> compatible = "pinctrl-single";
> - reg = <0x0014029c 0x250>;
> + reg = <0x0014029c 0x26c>;
> #address-cells = <1>;
> #size-cells = <1>;
> pinctrl-single,register-width = <32>;
> pinctrl-single,function-mask = <0xf>;
> pinctrl-single,gpio-range = <
> - &range 0 154 MODE_GPIO
> + &range 0 91 MODE_GPIO
> + &range 95 60 MODE_GPIO
> >;
> range: gpio-range {
> #pinctrl-single,gpio-range-cells = <3>;
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
> index 71e2e34..0098dfd 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
> @@ -464,8 +464,7 @@
> <&pinmux 108 16 27>,
> <&pinmux 135 77 6>,
> <&pinmux 141 67 4>,
> - <&pinmux 145 149 6>,
> - <&pinmux 151 91 4>;
> + <&pinmux 145 149 6>;
> };
>
> i2c1: i2c@e0000 {
>
Thanks for the fix. Looks good to me!
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: SAMSUNG: Fix system restart support on s3c6410
From: krzk @ 2019-09-09 18:55 UTC (permalink / raw)
To: Yao Lihua
Cc: linux-samsung-soc@vger.kernel.org, kgene@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <BY5PR12MB3699F7EF4920F878F3096DE7C4B50@BY5PR12MB3699.namprd12.prod.outlook.com>
On Sat, Sep 07, 2019 at 03:30:01AM +0000, Yao Lihua wrote:
> From: Lihua Yao <ylhuajnu@outlook.com>
>
> S3C6410 system restart is triggered by watchdog reset.
>
> Fixes: 9f55342cc2de ("ARM: dts: s3c64xx: Fix infinite interrupt in soft mode")
> Signed-off-by: Lihua Yao <ylhuajnu@outlook.com>
> ---
> arch/arm/plat-samsung/watchdog-reset.c | 1 +
Thanks, applied.
Best regards,
Krzysztof
_______________________________________________
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] ARM: dts: s3c64xx: specify dependency of clock providers
From: krzk @ 2019-09-09 18:53 UTC (permalink / raw)
To: Yao Lihua
Cc: linux-samsung-soc@vger.kernel.org, kgene@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <BY5PR12MB36991E62DD57AA6962C05420C4B50@BY5PR12MB3699.namprd12.prod.outlook.com>
On Sat, Sep 07, 2019 at 02:48:12AM +0000, Yao Lihua wrote:
> From: Lihua Yao <ylhuajnu@outlook.com>
>
> fin_pll is the parent of clock-controller@7e00f000, specify
> the dependency to ensure proper initialization order of clock
> providers.
>
> Fixes: 3f6d439f2022 ("clk: reverse default clk provider initialization order in of_clk_init()")
> Signed-off-by: Lihua Yao <ylhuajnu@outlook.com>
> ---
> arch/arm/boot/dts/s3c6400.dtsi | 1 +
> arch/arm/boot/dts/s3c6410.dtsi | 1 +
> 2 files changed, 2 insertions(+)
Idea looks good but should go to each of DTS files.
Best regards,
Krzysztof
>
> diff --git a/arch/arm/boot/dts/s3c6400.dtsi b/arch/arm/boot/dts/s3c6400.dtsi
> index 8c28e8a0c824..ef5a8fa3555c 100644
> --- a/arch/arm/boot/dts/s3c6400.dtsi
> +++ b/arch/arm/boot/dts/s3c6400.dtsi
> @@ -34,5 +34,6 @@
> compatible = "samsung,s3c6400-clock";
> reg = <0x7e00f000 0x1000>;
> #clock-cells = <1>;
> + clocks = <&fin_pll>;
> };
> };
> diff --git a/arch/arm/boot/dts/s3c6410.dtsi b/arch/arm/boot/dts/s3c6410.dtsi
> index a766d6de696c..b201b71d45b5 100644
> --- a/arch/arm/boot/dts/s3c6410.dtsi
> +++ b/arch/arm/boot/dts/s3c6410.dtsi
> @@ -38,6 +38,7 @@
> compatible = "samsung,s3c6410-clock";
> reg = <0x7e00f000 0x1000>;
> #clock-cells = <1>;
> + clocks = <&fin_pll>;
> };
>
> i2c1: i2c@7f00f000 {
> --
> 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
* Re: [PATCH 1/2] ARM: dts: s3c64xx: factor out external fixed clocks
From: krzk @ 2019-09-09 18:51 UTC (permalink / raw)
To: Yao Lihua
Cc: linux-samsung-soc@vger.kernel.org, kgene@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <BY5PR12MB36996A79D9B1EEC5162B00F4C4B50@BY5PR12MB3699.namprd12.prod.outlook.com>
On Sat, Sep 07, 2019 at 02:48:08AM +0000, Yao Lihua wrote:
> From: Lihua Yao <ylhuajnu@outlook.com>
>
> As per arch/arm/mach-s3c64xx/common.c, the external oscillators
> of S3C6400 and S3C6410 are identical. Move them to s3c64xx.dtsi
> and place under root node directly.
Hi,
Thanks for patches!
These are external oscillators so they are not a SoC property. They
should be external.
They could be moved to their own shared DTSI but I am not sure how much
benefit it will bring - it is rather small code duplication.
You need to fix the error in different way. However I do not quite
understand why moving them to the end of DTS fixed the error - they
should be now registered at the end...
Best regards,
Krzysztof
> This introduces side effect of changing the initialization order of
> fin_pll and clock-controller@7e00f000. As of commit 3f6d439f2022
> ("clk: reverse default clk provider initialization order in of_clk_init()"),
> clock providers are initialized in the orders they are present in the
> device tree unless the clocks' dependencies are specified explicitly.
>
> without this patch:
> [ 0.000000] S3C6410 clocks: apll = 0, mpll = 0
> [ 0.000000] epll = 0, arm_clk = 0
>
> with this patch:
> [ 0.000000] S3C6410 clocks: apll = 532000000, mpll = 532000000
> [ 0.000000] epll = 24000000, arm_clk = 532000000
>
> Fixes: 3f6d439f2022 ("clk: reverse default clk provider initialization order in of_clk_init()")
> Signed-off-by: Lihua Yao <ylhuajnu@outlook.com>
> ---
> arch/arm/boot/dts/s3c6410-mini6410.dts | 22 ----------------------
> arch/arm/boot/dts/s3c6410-smdk6410.dts | 22 ----------------------
> arch/arm/boot/dts/s3c64xx.dtsi | 14 ++++++++++++++
> 3 files changed, 14 insertions(+), 44 deletions(-)
>
> diff --git a/arch/arm/boot/dts/s3c6410-mini6410.dts b/arch/arm/boot/dts/s3c6410-mini6410.dts
> index 5201512054c4..7028507b7076 100644
> --- a/arch/arm/boot/dts/s3c6410-mini6410.dts
> +++ b/arch/arm/boot/dts/s3c6410-mini6410.dts
> @@ -28,28 +28,6 @@
> bootargs = "console=ttySAC0,115200n8 earlyprintk root=/dev/nfs rw nfsroot=192.168.31.2:/srv/nfs/tiny6410,nfsvers=3 ip=dhcp";
> };
>
> - clocks {
> - compatible = "simple-bus";
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - fin_pll: oscillator@0 {
> - compatible = "fixed-clock";
> - reg = <0>;
> - clock-frequency = <12000000>;
> - clock-output-names = "fin_pll";
> - #clock-cells = <0>;
> - };
> -
> - xusbxti: oscillator@1 {
> - compatible = "fixed-clock";
> - reg = <1>;
> - clock-output-names = "xusbxti";
> - clock-frequency = <48000000>;
> - #clock-cells = <0>;
> - };
> - };
> -
> srom-cs1@18000000 {
> compatible = "simple-bus";
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/s3c6410-smdk6410.dts b/arch/arm/boot/dts/s3c6410-smdk6410.dts
> index a9a5689dc462..10a854b488a8 100644
> --- a/arch/arm/boot/dts/s3c6410-smdk6410.dts
> +++ b/arch/arm/boot/dts/s3c6410-smdk6410.dts
> @@ -28,28 +28,6 @@
> bootargs = "console=ttySAC0,115200n8 earlyprintk rootwait root=/dev/mmcblk0p1";
> };
>
> - clocks {
> - compatible = "simple-bus";
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - fin_pll: oscillator@0 {
> - compatible = "fixed-clock";
> - reg = <0>;
> - clock-frequency = <12000000>;
> - clock-output-names = "fin_pll";
> - #clock-cells = <0>;
> - };
> -
> - xusbxti: oscillator@1 {
> - compatible = "fixed-clock";
> - reg = <1>;
> - clock-output-names = "xusbxti";
> - clock-frequency = <48000000>;
> - #clock-cells = <0>;
> - };
> - };
> -
> srom-cs1@18000000 {
> compatible = "simple-bus";
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
> index 2e611df37911..672764133cea 100644
> --- a/arch/arm/boot/dts/s3c64xx.dtsi
> +++ b/arch/arm/boot/dts/s3c64xx.dtsi
> @@ -39,6 +39,20 @@
> };
> };
>
> + fin_pll: oscillator-0 {
> + compatible = "fixed-clock";
> + clock-frequency = <12000000>;
> + clock-output-names = "fin_pll";
> + #clock-cells = <0>;
> + };
> +
> + xusbxti: oscillator-1 {
> + compatible = "fixed-clock";
> + clock-frequency = <48000000>;
> + clock-output-names = "xusbxti";
> + #clock-cells = <0>;
> + };
> +
> soc: soc {
> compatible = "simple-bus";
> #address-cells = <1>;
> --
> 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
* Re: [PATCH 0/2] Fix init order of S3C64xx's clock providers
From: krzk @ 2019-09-09 18:45 UTC (permalink / raw)
To: Yao Lihua
Cc: linux-samsung-soc@vger.kernel.org, kgene@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <BY5PR12MB3699A8D741EF6226B8DB65E4C4B50@BY5PR12MB3699.namprd12.prod.outlook.com>
On Sat, Sep 07, 2019 at 02:47:48AM +0000, Yao Lihua wrote:
> From: Lihua Yao <ylhuajnu@outlook.com>
>
> Ensure fin_pll is initialized before clock-controller@7e00f000 so
> we have correct clock frequency like below:
>
> [ 0.000000] S3C6410 clocks: apll = 532000000, mpll = 532000000
> [ 0.000000] epll = 24000000, arm_clk = 532000000
Hi,
Unfortunately your patches missed the samsung-soc mailing list:
https://www.spinics.net/lists/linux-samsung-soc/
Maybe you need to be subscribed?
In general, if the patches are not there, I do not see them under
Patchwork. You miss also review from Samsung folks.
Best regards,
Krzysztof
>
> Lihua Yao (2):
> ARM: dts: s3c64xx: factor out external fixed clocks
> ARM: dts: s3c64xx: specify dependency of clock providers
>
> arch/arm/boot/dts/s3c6400.dtsi | 1 +
> arch/arm/boot/dts/s3c6410-mini6410.dts | 22 ----------------------
> arch/arm/boot/dts/s3c6410-smdk6410.dts | 22 ----------------------
> arch/arm/boot/dts/s3c6410.dtsi | 1 +
> arch/arm/boot/dts/s3c64xx.dtsi | 14 ++++++++++++++
> 5 files changed, 16 insertions(+), 44 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 v2] arm64: dts: allwinner: a64: pine64-plus: Add PHY regulator delay
From: Jernej Skrabec @ 2019-09-09 18:42 UTC (permalink / raw)
To: mripard, wens
Cc: mark.rutland, devicetree, Ondrej Jirman, linux-kernel,
linux-sunxi, robh+dt, linux-arm-kernel
Depending on kernel and bootloader configuration, it's possible that
Realtek ethernet PHY isn't powered on properly. According to the
datasheet, it needs 30ms to power up and then some more time before it
can be used.
Fix that by adding 100ms ramp delay to regulator responsible for
powering PHY.
Fixes: 94dcfdc77fc5 ("arm64: allwinner: pine64-plus: Enable dwmac-sun8i")
Suggested-by: Ondrej Jirman <megous@megous.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
Changes from v1:
- Added comment with explanation why delay is needed
- Updated commit message
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
index 24f1aac366d6..d5b6e8159a33 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -63,3 +63,12 @@
reg = <1>;
};
};
+
+®_dc1sw {
+ /*
+ * Ethernet PHY needs 30ms to properly power up and some more
+ * to initialize. 100ms should be plenty of time to finish
+ * whole process.
+ */
+ regulator-enable-ramp-delay = <100000>;
+};
--
2.23.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