Re: Possible regression due to 269a535ca931 "modpost: generate vmlinux.symvers and reuse it for the second modpost"

On 3/4/21 5:24 PM, Masahiro Yamada wrote: > On Fri, Mar 5, 2021 at 1:21 AM Vladimir Murzin > wrote: > [ snip long description ] > >> >> Does that make sense? What I'm missing? >> >> P.S. >> I've also checked v5.12-rc1 and see the same sym

Possible regression due to 269a535ca931 "modpost: generate vmlinux.symvers and reuse it for the second modpost"

Hi, Recently, I had to dig awkward build issue for external module (originally with ARCH=arm) like MODPOST module/path/Module.symvers ERROR: modpost: "__put_user_1" [module/path/name.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [/module/path/name.ko] undefined! and it looks like it

Re: [PATCH 1/8] ARM: ARMv7-M: Fix register restore corrupt after svc call

On 3/4/21 5:42 AM, dillon min wrote: > Okay， got it. after adding msp/psp switch code in RTOS, now the kernel > can be loaded normally > without any modification. Yay! > > So, just drop the changes in proc-v7m.S. Glad to see they are not strictly necessary :) Thanks Vladimir

Re: [PATCH 1/8] ARM: ARMv7-M: Fix register restore corrupt after svc call

On 3/3/21 1:35 PM, dillon min wrote: > Hi Vladimir, > > Thanks for the review. > > On Wed, Mar 3, 2021 at 5:52 PM Vladimir Murzin > wrote: >> >> On 3/3/21 8:05 AM, dillon.min...@gmail.com wrote: >>> From: dillon min >>> >>&g

Re: [PATCH 1/8] ARM: ARMv7-M: Fix register restore corrupt after svc call

On 3/3/21 8:05 AM, dillon.min...@gmail.com wrote: > From: dillon min > > For some case, kernel not boot by u-boot(single thread), > but by rtos , as most rtos use pendsv to do context switch. Hmm, does it mean that it starts kernel from process context? I'd assume that it is not only kernel

Re: [PATCH] mm/memtest: Add ARCH_USE_MEMTEST

Hi Anshuman, On 2/5/21 4:10 AM, Anshuman Khandual wrote: > early_memtest() does not get called from all architectures. Hence enabling > CONFIG_MEMTEST and providing a valid memtest=[1..N] kernel command line > option might not trigger the memory pattern tests as would be expected in > normal

Re: AMU extension v1 support for cortex A76, A77, A78 CPUs

On 11/20/20 9:54 AM, Marc Zyngier wrote: > On 2020-11-20 09:09, Vladimir Murzin wrote: >> On 11/20/20 8:56 AM, Marc Zyngier wrote: >>> On 2020-11-20 04:30, Neeraj Upadhyay wrote: >>>> Hi, >>>> >>>> For ARM cortex A76, A77, A78 cores (whi

Re: AMU extension v1 support for cortex A76, A77, A78 CPUs

On 11/20/20 8:56 AM, Marc Zyngier wrote: > On 2020-11-20 04:30, Neeraj Upadhyay wrote: >> Hi, >> >> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU) >> AA64PFR0[47:44] field is not set, and AMU does not get enabled for >> them. >> Can you please provide support for these CPUs in

Re: [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory

On 6/10/20 9:19 AM, Vladimir Murzin wrote: > On 6/10/20 8:24 AM, Christoph Hellwig wrote: >> Ok, I finally found the original patch from Vladimir. Comments below: >> >>> +++ b/kernel/dma/direct.c >>> @@ -456,14 +456,14 @@ int dma_direct_mmap(struct device *dev

Re: [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory

struct device *dev) > -{ > - return false; > -} > - > -int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma, > - void *cpu_addr, dma_addr_t dma_addr, size_t size, > - unsigned long attrs) > -{ > - return -ENXIO; > -} > -#endif /* CONFIG_MMU */ > > int dma_direct_supported(struct device *dev, u64 mask) > { > LGTM. FWIW: Reviewed-by: Vladimir Murzin

Re: [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory

On 6/9/20 4:43 PM, Vladimir Murzin wrote: > On 6/9/20 4:36 PM, Christoph Hellwig wrote: >> On Tue, Jun 09, 2020 at 11:22:24PM +0800, dillon min wrote: >>> Hi Vladimir, >>> >>> Thanks for reviewing. >>> >>> Hi Christoph Hellwig, >>>

Re: [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory

On 6/9/20 4:36 PM, Christoph Hellwig wrote: > On Tue, Jun 09, 2020 at 11:22:24PM +0800, dillon min wrote: >> Hi Vladimir, >> >> Thanks for reviewing. >> >> Hi Christoph Hellwig, >> >> I just want to know if kernel dma mapping/direct is focused on >> platforms with MMU. >> leave arch code to handle

Re: [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory

On 6/8/20 9:30 AM, dillon.min...@gmail.com wrote: > From: dillon min > > Currently, we use dma direct to request coherent memory for driver on armv7m > platform if 'cacheid' is zero, but dma_direct_can_mmap() is return false, > dma_direct_mmap() return -ENXIO for CONFIG_MMU undefined platform. >

Re: [PATCH 2/2] arm: dts: stm32f769-disco: Enable MIPI DSI display support

Hi Adrian, On 4/27/20 9:05 PM, Adrian Pop wrote: > Added lee.jo...@linaro.org. > > First, thank you all for taking a look at my changes! > > Hello Alex, > > On Mon, Apr 27, 2020 at 11:28 AM Alexandre Torgue > wrote: >> >> Hi Adrian >> >> On 4/24/20 8:21 PM, Adrian Pop wrote: >>>

Re: [PATCH] arm64: defconfig: add JFFS FS support in defconfig

On 10/16/19 10:35 AM, Ooi, Joyce wrote: > This patch adds JFFS2 FS support and remove QSPI Sector 4K size force in > the default defconfig > > Signed-off-by: Ooi, Joyce > --- > arch/arm64/configs/defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/configs/defconfig

Re: [PATCH v2 10/12] irqchip/gic-v3: Warn about inconsistent implementations of extended ranges

Hi Marc, On 8/6/19 11:01 AM, Marc Zyngier wrote: > As is it usual for the GIC, it isn't disallowed to put together a system > that is majorly inconsistent, with a distributor supporting the > extended ranges while some of the CPUs don't. > > Kindly tell the user that things are sailing isn't

Re: [PATCH 17/17] riscv: add nommu support

Hi Christoph, On 6/24/19 6:43 AM, Christoph Hellwig wrote: > The kernel runs in M-mode without using page tables, and thus can't run > bare metal without help from additional firmware. > > Most of the patch is just stubbing out code not needed without page > tables, but there is an interesting

Re: [PATCH v2] arm64: mm: Fix dead assignment of old_pte

On 7/3/19 12:41 AM, Nathan Huckleberry wrote: > When analyzed with the clang static analyzer the > following warning occurs > > line 251, column 2 > Value stored to 'old_pte' is never read > > This warning is repeated every time pgtable.h is > included by another file and produces ~3500 > extra

Re: RISC-V nommu support v2

On 6/25/19 8:31 AM, Palmer Dabbelt wrote: > On Mon, 24 Jun 2019 06:08:50 PDT (-0700), vladimir.mur...@arm.com wrote: >> On 6/24/19 12:54 PM, Christoph Hellwig wrote: >>> On Mon, Jun 24, 2019 at 12:47:07PM +0100, Vladimir Murzin wrote: >>>> Since you are using binfm

Re: RISC-V nommu support v2

On 6/24/19 12:54 PM, Christoph Hellwig wrote: > On Mon, Jun 24, 2019 at 12:47:07PM +0100, Vladimir Murzin wrote: >> Since you are using binfmt_flat which is kind of 32-bit only I was expecting >> to see >> CONFIG_COMPAT (or something similar to that, like ILP32) ena

Re: RISC-V nommu support v2

Hi, On 6/24/19 6:42 AM, Christoph Hellwig wrote: > Hi all, > > below is a series to support nommu mode on RISC-V. For now this series > just works under qemu with the qemu-virt platform, but Damien has also > been able to get kernel based on this tree with additional driver hacks > to work on

Re: [PATCH 02/17] mm: stub out all of swapops.h for !CONFIG_MMU

On 6/11/19 3:18 PM, Christoph Hellwig wrote: > On Tue, Jun 11, 2019 at 11:15:44AM +0100, Vladimir Murzin wrote: >> On 6/10/19 11:16 PM, Christoph Hellwig wrote: >>> The whole header file deals with swap entries and PTEs, none of which >>> can exist for nommu bui

Re: [PATCH 17/17] riscv: add nommu support

On 6/10/19 11:16 PM, Christoph Hellwig wrote: > Most of the patch is just stubbing out code not needed without page > tables, but there is an interesting detail in the signals implementation: > > - The normal RISC-V syscall ABI only implements rt_sigreturn as VDSO >entry point, but the ELF

Re: [PATCH 03/17] mm/nommu: fix the MAP_UNINITIALIZED flag

> Signed-off-by: Christoph Hellwig > --- > arch/xtensa/include/uapi/asm/mman.h| 6 +- > include/uapi/asm-generic/mman-common.h | 8 +++- > mm/nommu.c | 4 +++- > 3 files changed, 7 insertions(+), 11 deletions(-) FWIW: Reviewed-by: Vladimir M

Re: [PATCH 02/17] mm: stub out all of swapops.h for !CONFIG_MMU

On 6/10/19 11:16 PM, Christoph Hellwig wrote: > The whole header file deals with swap entries and PTEs, none of which > can exist for nommu builds. Although I agree with the patch, I'm wondering how you get into it? Cheers Vladimir > > Signed-off-by: Christoph Hellwig > --- >

Re: [PATCH 01/17] mm: provide a print_vma_addr stub for !CONFIG_MMU

On 6/10/19 11:16 PM, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > include/linux/mm.h | 6 ++ > 1 file changed, 6 insertions(+) FWIW: Reviewed-by: Vladimir Murzin > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index dd0b5f4e1e45

Re: binfmt_flat cleanups and RISC-V support

On 6/11/19 9:11 AM, Christoph Hellwig wrote: > On Tue, Jun 11, 2019 at 09:05:45AM +0100, Vladimir Murzin wrote: >> I'm wondering if you have a branch with these changes so I can give >> it a try on ARM NOMMU platforms? > > > git://git.infradead.org/users/hch/riscv.g

Re: [PATCH 11/15] binfmt_flat: provide an asm-generic/flat.h

include/asm-generic}/flat.h| 12 --- > 3 files changed, 6 insertions(+), 28 deletions(-) > rename {arch/arm/include/asm => include/asm-generic}/flat.h (73%) FWIW: Reviewed-by: Vladimir Murzin > > diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/includ

Re: [PATCH 09/15] binfmt_flat: add a ARCH_HAS_BINFMT_FLAT option

| 1 + > arch/h8300/Kconfig | 1 + > arch/m68k/Kconfig | 1 + > arch/microblaze/Kconfig | 1 + > arch/sh/Kconfig | 1 + > arch/xtensa/Kconfig | 1 + > fs/Kconfig.binfmt | 5 - > 8 files changed, 11 insertions(+), 1 deletion(-) For ARM bits:

Re: [PATCH 08/15] binfmt_flat: add endianess annotations

ions(+), 10 deletions(-) Tested-by: Vladimir Murzin Reviewed-by: Vladimir Murzin > > diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c > index 6ae0f9af3fc9..6c1848dee724 100644 > --- a/fs/binfmt_flat.c > +++ b/fs/binfmt_flat.c > @@ -421,7 +421,8 @@ static int load_flat_file(struct li

Re: [PATCH 07/15] binfmt_flat: use __be32 for the on-disk format

+++-- > 1 file changed, 24 insertions(+), 24 deletions(-) With comment message fixed: Reviewed-by: Vladimir Murzin > > diff --git a/include/linux/flat.h b/include/linux/flat.h > index 21d901ba191b..59e892d5fadb 100644 > --- a/in

Re: [PATCH 06/15] binfmt_flat: remove the uapi header

+ > include/linux/flat.h | 45 ++--- > include/uapi/linux/flat.h | 59 --- > 3 files changed, 42 insertions(+), 63 deletions(-) > delete mode 100644 include/uapi/linux/flat.h FWIW: Reviewed-by: Vladimir Murzin > > di

Re: [PATCH 05/15] binfmt_flat: replace flat_argvp_envp_on_stack with a Kconfig variable

| 1 - > arch/xtensa/include/asm/flat.h | 1 - > fs/Kconfig.binfmt | 3 +++ > fs/binfmt_flat.c | 5 +++-- > 12 files changed, 9 insertions(+), 12 deletions(-) > For ARM bits: Tested-by: Vladimir Murzin Reviewed-by: Vladimir Murzin &

Re: [PATCH 04/15] binfmt_flat: remove flat_old_ram_flag

fmt_flat.c | 3 ++- > 10 files changed, 6 insertions(+), 8 deletions(-) > For ARM bits: Tested-by: Vladimir Murzin Reviewed-by: Vladimir Murzin > diff --git a/arch/arm/include/asm/flat.h b/arch/arm/include/asm/flat.h > index a185fe023b60..acf162111ee2 10064

Re: [PATCH 03/15] binfmt_flat: provide a default version of flat_get_relocate_addr

include/asm/flat.h | 1 - > arch/sh/include/asm/flat.h | 1 - > arch/xtensa/include/asm/flat.h | 1 - > fs/binfmt_flat.c | 4 > 6 files changed, 4 insertions(+), 6 deletions(-) For ARM bits: Tested-by: Vladimir Murzin Reviewed-by: Vladimir Murzin > >

Re: [PATCH 02/15] binfmt_flat: remove flat_set_persistent

| 1 - > arch/m68k/include/asm/flat.h | 5 - > arch/microblaze/include/asm/flat.h | 1 - > arch/sh/include/asm/flat.h | 1 - > arch/xtensa/include/asm/flat.h | 1 - > fs/binfmt_flat.c | 2 -- > 8 files changed, 13 deletions(-) > For ARM b

Re: [PATCH 01/15] binfmt_flat: remove flat_reloc_valid

insertion(+), 8 deletions(-) For ARM bits: Tested-by: Vladimir Murzin Reviewed-by: Vladimir Murzin > > diff --git a/arch/arm/include/asm/flat.h b/arch/arm/include/asm/flat.h > index f0c75ddeea23..10cce9ecf151 100644 > --- a/arch/arm/include/asm/flat.h > +++ b/arch/

Re: [PATCH 15/15] riscv: add binfmt_flat support

On 6/10/19 10:20 PM, Christoph Hellwig wrote: > Use the generic support with arguments are on the stack. Same as arm > and m68k. Out of curiosity, what is reason for keeping arguments on the stack? ARM port of uClibc has following comment around manipulating of argv/argc: /* *

Re: binfmt_flat cleanups and RISC-V support

Hi Christoph, On 6/10/19 10:20 PM, Christoph Hellwig wrote: > Hi Greg, > > below is a larger stash of cleanups for the binfmt_misc code, > preparing for the last patch that now trivially adds RISC-V > support, which will be used for the RISC-V nommu series I am > about to post. I'm wondering

Re:

On 2/1/19 12:41 PM, Souptick Joarder wrote: > On Fri, Feb 1, 2019 at 6:06 PM Vladimir Murzin > wrote: >> >> On 2/1/19 12:32 PM, Souptick Joarder wrote: >>> On Thu, Jan 31, 2019 at 6:28 PM Vladimir Murzin >>> wrote: >>>> >>>> Hi So

Re:

On 2/1/19 12:32 PM, Souptick Joarder wrote: > On Thu, Jan 31, 2019 at 6:28 PM Vladimir Murzin > wrote: >> >> Hi Souptick, >> >> On 1/31/19 5:54 AM, Souptick Joarder wrote: >>> On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport wrote: >>>> >

Re: [PATCH] serial: mps2-uart: Add parentheses around conditional in mps2_uart_shutdown

@@ -348,7 +348,7 @@ static void mps2_uart_shutdown(struct uart_port *port) > > mps2_uart_write8(port, control, UARTn_CTRL); > > - if (!mps_port->flags & UART_PORT_COMBINED_IRQ) { > + if (!(mps_port->flags & UART_PORT_COMBINED_IRQ)) { > free_irq(mps_port->rx_irq, mps_port); > free_irq(mps_port->tx_irq, mps_port); > } > Acked-by: Vladimir Murzin

Re:

Hi Souptick, On 1/31/19 5:54 AM, Souptick Joarder wrote: > On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport wrote: >> >> On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: >>> On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder >>> wrote: Remove duplicate headers which are

Re: [PATCH] arm/mm/pmsa-v8 : remove unneeded semicolon

_addr_t start,phys_ad > return -EINVAL; > > bar = start; > - lar = (end - 1) & ~(PMSAv8_MINALIGN - 1);; > + lar = (end - 1) & ~(PMSAv8_MINALIGN - 1); > > bar |= PMSAv8_AP_PL1RW_PL0RW | PMSAv8_RGN_SHARED | PMSAv8_BAR_XN; > lar

Re: [PATCH 0/7] arm64: capabilities: Optimize checking and enabling

atory step, we remove the > duplicate entries for the same capabilities (Patch 1-3). > Thanks a lot for getting it sorted out! In case it'd help: Reviewed-by: Vladimir Murzin Tested-by: Vladimir Murzin Cheers Vladimir > > Suzuki K Poulose (7): > arm64: capabilities: Merge en

Re: [PATCH 0/7] arm64: capabilities: Optimize checking and enabling

atory step, we remove the > duplicate entries for the same capabilities (Patch 1-3). > Thanks a lot for getting it sorted out! In case it'd help: Reviewed-by: Vladimir Murzin Tested-by: Vladimir Murzin Cheers Vladimir > > Suzuki K Poulose (7): > arm64: capabilities: Merge en

Re: [RFC 17/17] arm64: compile the kernel with ptrauth -msign-return-address

Hi Kristina, On 05/10/18 09:47, Kristina Martsenko wrote: > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 106039d25e2f..dbcd43ea99d8 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -56,6 +56,10 @@ KBUILD_AFLAGS += $(lseinstr) $(brokengasinst) >

Re: [RFC 17/17] arm64: compile the kernel with ptrauth -msign-return-address

Hi Kristina, On 05/10/18 09:47, Kristina Martsenko wrote: > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 106039d25e2f..dbcd43ea99d8 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -56,6 +56,10 @@ KBUILD_AFLAGS += $(lseinstr) $(brokengasinst) >

Re: [PATCH AUTOSEL 4.14 49/89] ARM: 8783/1: NOMMU: Extend check for VBAR support

On 02/09/18 14:07, Sasha Levin wrote: > From: Vladimir Murzin > > [ Upstream commit c803ce3f18bd93b3b4a15d1da0c5b5ebc60e0b85 ] > > ARMv8R adds support for VBAR and updates ID_PFR1 with the new filed > Sec_frac (bits [23:20]): > > Security fractional field. When th

Re: [PATCH AUTOSEL 4.14 49/89] ARM: 8783/1: NOMMU: Extend check for VBAR support

On 02/09/18 14:07, Sasha Levin wrote: > From: Vladimir Murzin > > [ Upstream commit c803ce3f18bd93b3b4a15d1da0c5b5ebc60e0b85 ] > > ARMv8R adds support for VBAR and updates ID_PFR1 with the new filed > Sec_frac (bits [23:20]): > > Security fractional field. When th

Re: [PATCH AUTOSEL 4.18 074/131] ARM: 8783/1: NOMMU: Extend check for VBAR support

On 02/09/18 14:04, Sasha Levin wrote: > From: Vladimir Murzin > > [ Upstream commit c803ce3f18bd93b3b4a15d1da0c5b5ebc60e0b85 ] > > ARMv8R adds support for VBAR and updates ID_PFR1 with the new filed > Sec_frac (bits [23:20]): > > Security fractional field. When th

Re: [PATCH AUTOSEL 4.18 074/131] ARM: 8783/1: NOMMU: Extend check for VBAR support

On 02/09/18 14:04, Sasha Levin wrote: > From: Vladimir Murzin > > [ Upstream commit c803ce3f18bd93b3b4a15d1da0c5b5ebc60e0b85 ] > > ARMv8R adds support for VBAR and updates ID_PFR1 with the new filed > Sec_frac (bits [23:20]): > > Security fractional field. When th

Re: [PATCH] serial: mps2-uart: Initialize early console

Hi Guenter, On 19/06/18 05:54, Guenter Roeck wrote: > The early console code for mps2-uart assumes that the serial hardware is > enabled for transmit when the system boots. However, this is not the case > after reset. This results in a hang in mps2_early_putchar() if the serial > transmitter is

Re: [PATCH] serial: mps2-uart: Initialize early console

Hi Guenter, On 19/06/18 05:54, Guenter Roeck wrote: > The early console code for mps2-uart assumes that the serial hardware is > enabled for transmit when the system boots. However, this is not the case > after reset. This results in a hang in mps2_early_putchar() if the serial > transmitter is

Re: [PATCH v3 4/5] ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM

On 18/05/18 15:39, Marc Zyngier wrote: > +static inline int read_pmuver(void) > +{ > + /* PMUVers is not a signed field */ > + u32 dfr0 = read_cpuid_ext(CPUID_EXT_DFR0); > + return (dfr0 >> 24) & 0xf; > +} Should we rule out versions prior v3 here or in __armv8pmu_probe_pmu()? Thanks

Re: [PATCH v3 4/5] ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM

On 18/05/18 15:39, Marc Zyngier wrote: > +static inline int read_pmuver(void) > +{ > + /* PMUVers is not a signed field */ > + u32 dfr0 = read_cpuid_ext(CPUID_EXT_DFR0); > + return (dfr0 >> 24) & 0xf; > +} Should we rule out versions prior v3 here or in __armv8pmu_probe_pmu()? Thanks

Re: [PATCH 29/33] dma-direct: retry allocations using GFP_DMA for small masks

), size)) { > + __free_pages(page, page_order); > + page = NULL; > + > + if (dev->coherent_dma_mask < DMA_BIT_MASK(32) && > + !(gfp & GFP_DMA)) { > + gfp = (gfp & ~GFP_DMA32) | GFP_DMA; > + goto again; > + } > + } > + > if (!page) > return NULL; > > Reviewed-by: Vladimir Murzin <vladimir.mur...@arm.com> Cheers Vladimir

Re: [PATCH 29/33] dma-direct: retry allocations using GFP_DMA for small masks

age, page_order); > + page = NULL; > + > + if (dev->coherent_dma_mask < DMA_BIT_MASK(32) && > + !(gfp & GFP_DMA)) { > + gfp = (gfp & ~GFP_DMA32) | GFP_DMA; > + goto again; > + } > + } > + > if (!page) > return NULL; > > Reviewed-by: Vladimir Murzin Cheers Vladimir

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

On 10/01/18 08:00, Christoph Hellwig wrote: > index 9110988b92a1..f00833acb626 100644 > --- a/arch/mips/include/asm/mach-cavium-octeon/dma-coherence.h > +++ b/arch/mips/include/asm/mach-cavium-octeon/dma-coherence.h > @@ -61,6 +61,14 @@ static inline void plat_post_dma_flush(struct device *dev) >

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

On 10/01/18 08:00, Christoph Hellwig wrote: > index 9110988b92a1..f00833acb626 100644 > --- a/arch/mips/include/asm/mach-cavium-octeon/dma-coherence.h > +++ b/arch/mips/include/asm/mach-cavium-octeon/dma-coherence.h > @@ -61,6 +61,14 @@ static inline void plat_post_dma_flush(struct device *dev) >

Re: [PATCH 31/67] dma-direct: make dma_direct_{alloc, free} available to other implementations

e_t > size, > return page_address(page); > } > > -static void dma_direct_free(struct device *dev, size_t size, void *cpu_addr, > +void dma_direct_free(struct device *dev, size_t size, void *cpu_addr, > dma_addr_t dma_addr, unsigned long attrs) > { > unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT; > Reviewed-by: Vladimir Murzin <vladimir.mur...@arm.com> Thanks Vladimir

Re: [PATCH 31/67] dma-direct: make dma_direct_{alloc, free} available to other implementations

ze, > return page_address(page); > } > > -static void dma_direct_free(struct device *dev, size_t size, void *cpu_addr, > +void dma_direct_free(struct device *dev, size_t size, void *cpu_addr, > dma_addr_t dma_addr, unsigned long attrs) > { > unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT; > Reviewed-by: Vladimir Murzin Thanks Vladimir

Re: [PATCH 30/67] dma-direct: retry allocations using GFP_DMA for small masks

On 29/12/17 08:18, Christoph Hellwig wrote: > If we got back an allocation that wasn't inside the support coherent mask, > retry the allocation using GFP_DMA. > > Based on the x86 code. > > Signed-off-by: Christoph Hellwig > --- > lib/dma-direct.c | 25 - >

Re: [PATCH 30/67] dma-direct: retry allocations using GFP_DMA for small masks

On 29/12/17 08:18, Christoph Hellwig wrote: > If we got back an allocation that wasn't inside the support coherent mask, > retry the allocation using GFP_DMA. > > Based on the x86 code. > > Signed-off-by: Christoph Hellwig > --- > lib/dma-direct.c | 25 - > 1 file

Re: [PATCH 26/67] dma-direct: use phys_to_dma

BUG_ON(!sg_page(sg)); > - va = sg_virt(sg); > - sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va) - offset; > + > + sg_dma_address(sg) = phys_to_dma(dev, sg_phys(sg)); > sg_dma_len(sg) = sg->length; > } > > >From ARM NOMMU perspective Reviewed-by: Vladimir Murzin <vladimir.mur...@arm.com> Thanks Vladimir

Re: [PATCH 26/67] dma-direct: use phys_to_dma

g)); > - va = sg_virt(sg); > - sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va) - offset; > + > + sg_dma_address(sg) = phys_to_dma(dev, sg_phys(sg)); > sg_dma_len(sg) = sg->length; > } > > >From ARM NOMMU perspective Reviewed-by: Vladimir Murzin Thanks Vladimir

Re: [PATCH 25/67] dma-direct: rename dma_noop to dma_direct

enum dma_data_direction dir, > - unsigned long attrs) > +static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, > + int nents, enum dma_data_direction dir, unsigned long attrs) > { > int i; > struct scatterlist *sg; >

Re: [PATCH 25/67] dma-direct: rename dma_noop to dma_direct

, > - unsigned long attrs) > +static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, > + int nents, enum dma_data_direction dir, unsigned long attrs) > { > int i; > struct scatterlist *sg; > @@ -58,12 +54,11 @@ static int dma_noop_map_sg(struct device *dev, struct > scatterlist *sgl, int nent > return nents; > } > > -const struct dma_map_ops dma_noop_ops = { > - .alloc = dma_noop_alloc, > - .free = dma_noop_free, > - .map_page = dma_noop_map_page, > - .map_sg = dma_noop_map_sg, > +const struct dma_map_ops dma_direct_ops = { > + .alloc = dma_direct_alloc, > + .free = dma_direct_free, > + .map_page = dma_direct_map_page, > + .map_sg = dma_direct_map_sg, > .is_phys= true, > }; > - > -EXPORT_SYMBOL(dma_noop_ops); > +EXPORT_SYMBOL(dma_direct_ops); > >From ARM NOMMU perspective Reviewed-by: Vladimir Murzin Thanks Vladimir

Re: consolidate direct dma mapping and swiotlb support

On 29/12/17 08:18, Christoph Hellwig wrote: > Almost every architecture supports a direct dma mapping implementation, > where no iommu is used and the device dma address is a 1:1 mapping to > the physical address or has a simple linear offset. Currently the > code for this implementation is most

Re: consolidate direct dma mapping and swiotlb support

On 29/12/17 08:18, Christoph Hellwig wrote: > Almost every architecture supports a direct dma mapping implementation, > where no iommu is used and the device dma address is a 1:1 mapping to > the physical address or has a simple linear offset. Currently the > code for this implementation is most

Re: [PATCH] phy: rcar-gen3-usb2: add dependency on USB

Hi, On 15/12/17 10:27, Yoshihiro Shimoda wrote: > Hi, > >> -Original Message----- >> From: Vladimir Murzin, Sent: Friday, December 15, 2017 7:20 PM >> >> Following error showed up: >> >> drivers/phy/renesas/phy-rcar-gen3-usb2.o: In function >

Re: [PATCH] phy: rcar-gen3-usb2: add dependency on USB

Hi, On 15/12/17 10:27, Yoshihiro Shimoda wrote: > Hi, > >> -Original Message----- >> From: Vladimir Murzin, Sent: Friday, December 15, 2017 7:20 PM >> >> Following error showed up: >> >> drivers/phy/renesas/phy-rcar-gen3-usb2.o: In function >

[PATCH] phy: rcar-gen3-usb2: add dependency on USB

] Error 1 with CONFIG_USB_SUPPORT=n Add dependency on USB_SUPPORT and select USB_COMMON to make sure that of_usb_get_dr_mode_by_phy() is available. Signed-off-by: Vladimir Murzin <vladimir.mur...@arm.com> --- drivers/phy/renesas/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/d

[PATCH] phy: rcar-gen3-usb2: add dependency on USB

] Error 1 with CONFIG_USB_SUPPORT=n Add dependency on USB_SUPPORT and select USB_COMMON to make sure that of_usb_get_dr_mode_by_phy() is available. Signed-off-by: Vladimir Murzin --- drivers/phy/renesas/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/phy/renesas/Kconfig b

Re: Linux kernel configuration for MPS2 AN385

On 09/12/17 18:33, Guenter Roeck wrote: > Hi folks, > > I am playing with qemu's mps2-an385 emulation and try to get Linux to boot > with it, > so far with little (ie no) success. > > Is a working kernel configuration for this board available somewhere ? make ARCH=arm mps2_defconfig would

Re: Linux kernel configuration for MPS2 AN385

On 09/12/17 18:33, Guenter Roeck wrote: > Hi folks, > > I am playing with qemu's mps2-an385 emulation and try to get Linux to boot > with it, > so far with little (ie no) success. > > Is a working kernel configuration for this board available somewhere ? make ARCH=arm mps2_defconfig would

Re: [PATCH] ARM: dma-mapping: Use vma_pages helper

On 22/11/17 15:20, Vasyl Gomonovych wrote: > Use vma_pages function on vma object instead of explicit computation. > arch/arm/mm/dma-mapping.c:849:36-42: WARNING: Consider using vma_pages helper > on vma > Generated by: scripts/coccinelle/api/vma_pages.cocci > > Signed-off-by: Vasyl Gomonovych

Re: [PATCH] ARM: dma-mapping: Use vma_pages helper

On 22/11/17 15:20, Vasyl Gomonovych wrote: > Use vma_pages function on vma object instead of explicit computation. > arch/arm/mm/dma-mapping.c:849:36-42: WARNING: Consider using vma_pages helper > on vma > Generated by: scripts/coccinelle/api/vma_pages.cocci > > Signed-off-by: Vasyl Gomonovych

Re: [PATCH] ARM: NOMMU: work around maybe-uninitialized warning

On 02/11/17 13:07, Russell King - ARM Linux wrote: > On Thu, Nov 02, 2017 at 12:25:47PM +0000, Vladimir Murzin wrote: >> On 02/11/17 09:21, Arnd Bergmann wrote: >>> The reworked MPU code produces a new warning in some configurations, >>> presumably starting with the c

Re: [PATCH] ARM: NOMMU: work around maybe-uninitialized warning

On 02/11/17 13:07, Russell King - ARM Linux wrote: > On Thu, Nov 02, 2017 at 12:25:47PM +0000, Vladimir Murzin wrote: >> On 02/11/17 09:21, Arnd Bergmann wrote: >>> The reworked MPU code produces a new warning in some configurations, >>> presumably starting with the c

Re: [PATCH] ARM: NOMMU: work around maybe-uninitialized warning

On 02/11/17 09:21, Arnd Bergmann wrote: > The reworked MPU code produces a new warning in some configurations, > presumably starting with the code move after the compiler now makes > different inlining decisions: > > arch/arm/mm/pmsa-v7.c: In function 'adjust_lowmem_bounds_mpu': >

Re: [PATCH] ARM: NOMMU: work around maybe-uninitialized warning

On 02/11/17 09:21, Arnd Bergmann wrote: > The reworked MPU code produces a new warning in some configurations, > presumably starting with the code move after the compiler now makes > different inlining decisions: > > arch/arm/mm/pmsa-v7.c: In function 'adjust_lowmem_bounds_mpu': >

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

+ Robin and Christoph On 16/10/17 06:27, Marian Mihailescu wrote: > I am using 4.14-rc4 with a patch on top that includes > arch/arm/include/asm/dma-mapping.h in a module. > > I have MMU enabled, so > select DMA_NOOP_OPS if !MMU > does nothing for me, and I get a compile error because

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

+ Robin and Christoph On 16/10/17 06:27, Marian Mihailescu wrote: > I am using 4.14-rc4 with a patch on top that includes > arch/arm/include/asm/dma-mapping.h in a module. > > I have MMU enabled, so > select DMA_NOOP_OPS if !MMU > does nothing for me, and I get a compile error because

Re: [PATCH] arm64: KVM: Skip PSTATE.PAN reest at EL2 in non-VHE

On 11/09/17 12:16, Dongjiu Geng wrote: > PSTATE.PAN disables reading and/or writing to a userspace virtual > address from EL1 in non-VHE or from EL2 in VHE. In non-VHE, there is > no any userspace mapping at EL2, so no need to reest the PSTATE.PAN.

Re: [PATCH] arm64: KVM: Skip PSTATE.PAN reest at EL2 in non-VHE

On 11/09/17 12:16, Dongjiu Geng wrote: > PSTATE.PAN disables reading and/or writing to a userspace virtual > address from EL1 in non-VHE or from EL2 in VHE. In non-VHE, there is > no any userspace mapping at EL2, so no need to reest the PSTATE.PAN.

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

2。so after swich to host，need to check whether set pstate.UAO > <http://pstate.UAO> again。 What negative effect do you see with change UAO to 0 (i.e. do not override)? P. S. Please, avoid HTML and top posting Vladimir > *发件人：*Vladimir Murzin > *收件人：*耿东久,marc.zyngier,christoffer.d

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

2。so after swich to host，need to check whether set pstate.UAO > <http://pstate.UAO> again。 What negative effect do you see with change UAO to 0 (i.e. do not override)? P. S. Please, avoid HTML and top posting Vladimir > *发件人：*Vladimir Murzin > *收件人：*耿东久,marc.zyngier,christoffer.d

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 15:10, gengdongjiu wrote: > Hi, Vladimir > Do you see effect of "PAN is unexpectedly enabled"? >>> In fact I did not encounter this case, but I think it can exist. >>> I think if host OS dynamically disable PAN, it wants the host kernel access >>> the user space address space

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 15:10, gengdongjiu wrote: > Hi, Vladimir > Do you see effect of "PAN is unexpectedly enabled"? >>> In fact I did not encounter this case, but I think it can exist. >>> I think if host OS dynamically disable PAN, it wants the host kernel access >>> the user space address space

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 13:44, gengdongjiu wrote: > > > On 2017/9/6 20:30, Vladimir Murzin wrote: >> On 06/09/17 13:14, gengdongjiu wrote: >>> >>> >>> On 2017/9/6 20:00, Vladimir Murzin wrote: >>>> On 06/09/17 11:35, gengdongjiu wrote: >>>&g

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 13:44, gengdongjiu wrote: > > > On 2017/9/6 20:30, Vladimir Murzin wrote: >> On 06/09/17 13:14, gengdongjiu wrote: >>> >>> >>> On 2017/9/6 20:00, Vladimir Murzin wrote: >>>> On 06/09/17 11:35, gengdongjiu wrote: >>>&g

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 13:14, gengdongjiu wrote: > > > On 2017/9/6 20:00, Vladimir Murzin wrote: >> On 06/09/17 11:35, gengdongjiu wrote: >>> Vladimir, >>> >>> On 2017/9/6 17:41, Vladimir Murzin wrote: >>>> Can you please elaborate on cases where P

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 13:14, gengdongjiu wrote: > > > On 2017/9/6 20:00, Vladimir Murzin wrote: >> On 06/09/17 11:35, gengdongjiu wrote: >>> Vladimir, >>> >>> On 2017/9/6 17:41, Vladimir Murzin wrote: >>>> Can you please elaborate on cases where P

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 11:35, gengdongjiu wrote: > Vladimir, > > On 2017/9/6 17:41, Vladimir Murzin wrote: >> Can you please elaborate on cases where PAN is not enabled? > > I mean the informal private usage, For example, he disabled the PAN > dynamically to let kernel space

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 11:35, gengdongjiu wrote: > Vladimir, > > On 2017/9/6 17:41, Vladimir Murzin wrote: >> Can you please elaborate on cases where PAN is not enabled? > > I mean the informal private usage, For example, he disabled the PAN > dynamically to let kernel space

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

or example below fixing, it will check CPU capability, If CPU > supports PAN, > the kvm will always enable the PAN for the host. But in fact, the host may be > not enable the PAN. Can you please elaborate on cases where PAN is not enabled? Thanks Vladimir > Of course for the U

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

, host_ctxt); > ... > > if (has_vhe()) > asm("msr daifclr, #0xd"); > } > > > If not save/restore them, the KVM will set them according to the CPU > capability. For example below fixing, it will check CPU capability, If C

[PATCH 1/2] drivers: dma-coherent: Introduce interface for default DMA pool

<vgu...@synopsys.com> Cc: Russell King <li...@armlinux.org.uk> Cc: Catalin Marinas <catalin.mari...@arm.com> Cc: Will Deacon <will.dea...@arm.com> Cc: Ralf Baechle <r...@linux-mips.org> Suggested-by: Robin Murphy <robin.mur...@arm.com> Tested-by: Andras Szemzo &

[PATCH 1/2] drivers: dma-coherent: Introduce interface for default DMA pool

Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Ralf Baechle Suggested-by: Robin Murphy Tested-by: Andras Szemzo Signed-off-by: Vladimir Murzin --- arch/arc/mm/dma.c | 2 +- arch/arm/mm/dma-mapping.c | 2 +- arch/arm64/mm/dma-mapping.c | 4 +- arch/mips/mm/dma

  1   2   3   4   5   6   7   >