linux-kernel - Re: [PATCH v7] MIPS: Loongson: Add DMA support for LS7A

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 8 May 2020 15:02:23 +0200
From:   Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To:     Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Huacai Chen <chenhc@...ote.com>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        Xuefeng Li <lixuefeng@...ngson.cn>
Subject: Re: [PATCH v7] MIPS: Loongson: Add DMA support for LS7A

On Fri, May 08, 2020 at 04:36:05PM +0800, Tiezhu Yang wrote:
> In the current market, the most used bridge chip on the Loongson platform
> are RS780E and LS7A, the RS780E bridge chip is already supported by the
> mainline kernel.
> 
> If use the default implementation of __phys_to_dma() and __dma_to_phys()
> in dma-direct.h when CONFIG_ARCH_HAS_PHYS_TO_DMA is not set, it works
> well used with LS7A on the Loongson single-way and multi-way platform,
> and also works well used with RS780E on the Loongson single-way platform,
> but the DMA address will be wrong on the non-node0 used with RS780E on
> the Loongson multi-way platform.
> 
> Just as the description in the code comment, the devices get node id from
> 40 bit of HyperTransport bus, so we extract 2 bit node id (bit 44~45) from
> 48 bit address space of Loongson CPU and embed it into HyperTransport bus
> (bit 37-38), this operation can be done only at the software level used
> with RS780E on the Loongson multi-way platform, because it has no hardware
> function to translate address of node id, this is a hardware compatibility
> problem.
> 
> Device
>     |
>     | DMA address
>     |
> Host Bridge
>     |
>     | HT bus address (40 bit)
>     |
>    CPU
>     |
>     | physical address (48 bit)
>     |
>    RAM
> 
> The LS7A has dma_node_id_offset field in the DMA route config register,
> the hardware can use the dma_node_id_offset to translate address of
> node id automatically, so we can get correct address when just use the
> dma_pfn_offset field in struct device.
> 
> For the above reasons, in order to maintain downward compatibility
> to support the RS780E bridge chip, it is better to use the platform
> dependent implementation of __phys_to_dma() and __dma_to_phys().
> 
> Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.cn>
> ---
> 
> v7:
>   - According to the discussion of the v6 patch [1],
>     use the platform dependent implementation of
>     __phys_to_dma() and __dma_to_phys()
>   - Make a slight modification based on the v4 patch [2]
>     to put ls7a things before rs780e things
> 
> [1] https://lore.kernel.org/patchwork/patch/1233541/
> [2] https://lore.kernel.org/patchwork/patch/1220010/
> 
> v6:
>   - Make loongson_dma_config() static
>   - Put ls7a things before rs780 things
> 
> v5:
>   - Use the default implementation of __phys_to_dma()
>     and __dma_to_phys() in dma-direct.h
> 
> v4:
>   - Use LS7A instead of Loongson 7A1000 in the description
>   - Use LS7A or ls7a instead of LS7A1000 or ls7a1000 in the code
> 
> v3:
>   - Modify the macro definition NODE_ID_OFFSET_ADDR to
>     make it easy to read
>   - update the commit message
> 
>  arch/mips/include/asm/mach-loongson64/boot_param.h |  5 +++++
>  arch/mips/loongson64/dma.c                         |  9 ++++++---
>  arch/mips/loongson64/env.c                         |  2 ++
>  arch/mips/loongson64/init.c                        | 17 +++++++++++++++++
>  4 files changed, 30 insertions(+), 3 deletions(-)

applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]