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 s
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 i
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
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
>>>
>>> For some c
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 wh
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 circu
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 (which as p
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 c
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
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
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,
>>>
>
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
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.
>
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:
>>> STM32f769-disc
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 b
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 goin
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 de
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 w
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
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) enabled
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 th
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 builds.
>
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 VD
>
> 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:
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
> ---
> include/linux/sw
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
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/ri
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/include/asm/Kb
| 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:
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
flat.h | 48 ++--
> 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 10064
| 1 +
> 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
>
&g
| 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
&
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
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
>
>
| 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
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/
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:
/*
*
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 if
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
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:
>>>>
>
art.c
> @@ -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
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 in
_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
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: Mer
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)
> KBUILD_CFL
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
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
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 no
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
ges(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
Cheers
Vladimir
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)
>
ze_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
Thanks
Vladimir
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 change
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
tion 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
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 d
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
>
d
make: *** [vmlinux] 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/p
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 give
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
>
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
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':
> arch/arm/mm/pmsa
+ 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 dma_noop_op
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.
^
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
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 not
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
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
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
, 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
Gupta
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/m
0
Cc: Vineet Gupta
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Ralf Baechle
Thanks!
Vladimir Murzin (2):
drivers: dma-coherent: Introduce interface for default DMA pool
ARM: NOMMU: Wire-up default DMA interface
arch/arc/mm/dma.c | 2 +-
arch/arm/mm/dma-mapping-
: Andras Szemzo
Signed-off-by: Vladimir Murzin
---
arch/arm/mm/dma-mapping-nommu.c | 45 -
1 file changed, 36 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index 90ee354..6db5fc2 100644
--- a/arch
idea and provide interface to
allocate/release/mmap the default/global DMA pool.
[1] https://lkml.org/lkml/2017/7/7/370
[2] https://lkml.org/lkml/2017/7/7/431
Suggested-by: Robin Murphy
Signed-off-by: Vladimir Murzin
---
drivers/base/dma-coherent.c
y and/or George of their use of global pool, I'm
leaving ARM MMU part to them.
[1] https://lkml.org/lkml/2017/7/7/370
Vladimir Murzin (2):
drivers: dma-coherent: Introduce interface for default DMA pool
ARM: NOMMU: Wire-up default DMA interface
arch/arm/mm/dma-mapping-nom
: Vladimir Murzin
---
arch/arm/mm/dma-mapping-nommu.c | 45 -
1 file changed, 36 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index 90ee354..6db5fc2 100644
--- a/arch/arm/mm/dma-mapping-nommu.c
On 07/07/17 18:55, Robin Murphy wrote:
> On 07/07/17 17:44, Vladimir Murzin wrote:
>> On 07/07/17 17:06, Robin Murphy wrote:
>>> On 07/07/17 16:40, Vladimir Murzin wrote:
>>>> Christoph,
>>>>
>>>> On 07/07/17 15:27, Christoph Hellwig wrote:
&
On 07/07/17 17:06, Robin Murphy wrote:
> On 07/07/17 16:40, Vladimir Murzin wrote:
>> Christoph,
>>
>> On 07/07/17 15:27, Christoph Hellwig wrote:
>>> Vladimir,
>>>
>>> this is why I really didn't like overloading the current
>>> dma
Christoph,
On 07/07/17 15:27, Christoph Hellwig wrote:
> Vladimir,
>
> this is why I really didn't like overloading the current
> dma coherent infrastructure with the global pool.
>
> And this new patch seems like piling hacks over hacks. I think we
> should go back and make sure allocations fr
On 03/07/17 09:49, Vladimir Murzin wrote:
> On 28/06/17 14:52, Christoph Hellwig wrote:
>> Thanks Vlad,
>>
>> these look fine to me. I'll wait another day or two for comments
>> (especially if other nommu archs actually want this code), and
>> if nothing sh
On 28/06/17 14:52, Christoph Hellwig wrote:
> Thanks Vlad,
>
> these look fine to me. I'll wait another day or two for comments
> (especially if other nommu archs actually want this code), and
> if nothing shows up will apply them.
>
Gentle remainder to make sure this follow-up is not lost ;)
On 30/06/17 12:36, Benjamin Gaignard wrote:
> 2017-06-28 11:16 GMT+02:00 Vladimir Murzin :
>> These two patches are folloups on "[PATCH v6 0/7] ARM: Fix
>> dma_alloc_coherent() and friends for NOMMU" which has been partly
>> merged in [1]. PATCH 1/2 is done pe
build.
c6x and frv stay untouched since they already have ARCH_NO_COHERENT_DMA_MMAP.
Cc: Steven Miao
Cc: Geert Uytterhoeven
Cc: Michal Simek
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Chris Zankel
Cc: Max Filippov
Suggested-by: Christoph Hellwig
Signed-off-by: Vladimir Murzin
---
arch
dma_common_mmap() is already available for NOMMU, so there is no point
to carry own version. Moreover, existent implementation relies on
dma-noop provides mmap, but it is not true anymore.
Signed-off-by: Vladimir Murzin
---
arch/arm/mm/dma-mapping-nommu.c | 18 --
1 file changed
x27;t break bisectability.
[1] git://git.infradead.org/users/hch/dma-mapping.git for-next
[2] https://www.spinics.net/lists/arm-kernel/msg590587.html
Cc: Steven Miao
Cc: Geert Uytterhoeven
Cc: Michal Simek
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Chris Zankel
Cc: Max Filippov
Thanks!
Vladimir Murzin
On 26/06/17 10:42, Christoph Hellwig wrote:
> On Tue, Jun 20, 2017 at 03:24:21PM +0100, Robin Murphy wrote:
>> True, but the case here is where we need a special piece of coherent
>> memory for *all* devices, and it was more complicated *not* to reuse the
>> existing infrastructure. This would alre
DMA operations for NOMMU case have been just factored out into
separate compilation unit, so don't keep dead code.
Tested-by: Benjamin Gaignard
Tested-by: Andras Szemzo
Tested-by: Alexandre TORGUE
Signed-off-by: Vladimir Murzin
Acked-by: Arnd Bergmann
---
arch/arm/mm/dma-mapping.c
, we offer this as an option.
Tested-by: Benjamin Gaignard
Tested-by: Andras Szemzo
Tested-by: Alexandre TORGUE
Reviewed-by: Robin Murphy
Signed-off-by: Vladimir Murzin
---
arch/arm/mm/Kconfig | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/Kconfig b/arch
system memory map
which defines part of address space as Normal memory.
Reported-by: Alexandre Torgue
Reported-by: Andras Szemzo
Tested-by: Benjamin Gaignard
Tested-by: Andras Szemzo
Tested-by: Alexandre TORGUE
Reviewed-by: Robin Murphy
Signed-off-by: Vladimir Murzin
Acked-by: Arnd Bergmann
-by: Alexandre TORGUE
Signed-off-by: Vladimir Murzin
---
drivers/base/dma-coherent.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 640a7e6..99c9695 100644
--- a/drivers/base/dma-coherent.c
+
by: Alexandre TORGUE
Reviewed-by: Robin Murphy
Signed-off-by: Vladimir Murzin
---
lib/dma-noop.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/dma-noop.c b/lib/dma-noop.c
index de26c8b..1f60c8a 100644
--- a/lib/dma-noop.c
+++ b/lib/dma-noop.c
@@ -7,6 +7,7
This patch adds a simple implementation of mmap to dma_noop_ops.
Cc: Joerg Roedel
Cc: Christian Borntraeger
Reported-by: Benjamin Gaignard
Tested-by: Benjamin Gaignard
Tested-by: Andras Szemzo
Tested-by: Alexandre TORGUE
Signed-off-by: Vladimir Murzin
---
lib/dma-noop.c | 24
configured via device tree (so Tested-by discarded there)
RFC v6 -> v1
- dropped RFC tag
- added Alexandre's Tested-by
Vladimir Murzin (7):
dma: Take into account dma_pfn_offset
dma: Add simple dma_noop_mmap
drivers: dma-coherent:
Gaignard
Tested-by: Andras Szemzo
Tested-by: Alexandre TORGUE
Signed-off-by: Vladimir Murzin
---
.../bindings/reserved-memory/reserved-memory.txt | 3 ++
drivers/base/dma-coherent.c| 59 +++---
2 files changed, 55 insertions(+), 7 deletions(-)
diff --git
a
On 20/06/17 14:49, Christoph Hellwig wrote:
> On Wed, May 24, 2017 at 11:24:29AM +0100, Vladimir Murzin wrote:
>> This patch introduces default coherent DMA pool similar to default CMA
>> area concept. To keep other users safe code kept under CONFIG_ARM.
>
> I don't se
On 20/06/17 14:42, Christoph Hellwig wrote:
> Wouldn't the smal patch below solve the same issue in a simple way?
>
> diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
> index 640a7e63c453..e8f8447d705b 100644
> --- a/drivers/base/dma-coherent.c
> +++ b/drivers/base/dma-cohere
On 20/06/17 14:24, Christoph Hellwig wrote:
>> -sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va);
>> +sg_dma_address(sg) = (dma_addr_t)(virt_to_phys(va) -
>> PFN_PHYS(dev->dma_pfn_offset));
>
> Needs a line break instead of the overly long line.
Will do.
>
> Otherwise
On 20/06/17 14:23, Christoph Hellwig wrote:
> On Wed, May 24, 2017 at 11:24:27AM +0100, Vladimir Murzin wrote:
>> This patch adds a simple implementation of mmap to dma_noop_ops.
>
> Currently we use dma_common_mmap as the generic fallback if a dma_ops
> instance doesn't
+Christoph since he is trying to consolidate work in this area [1].
Christoph, any chance you can look into patches touching
dma-{coherent,noop}.c?
[1] https://patchwork.ozlabs.org/patch/778254/
Thanks!
Vladimir
On 15/06/17 08:25, Vladimir Murzin wrote:
> Greg?
>
> On 08/06/17 17:25
1 - 100 of 363 matches
Mail list logo
