linux-kernel - Re: [RFC PATCH 1/2] riscv: vendors: andes: Add support to configure the PMA regions

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <02df5db7-99bc-5476-2530-4237c3904933@microchip.com>
Date:   Thu, 8 Sep 2022 14:04:51 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <biju.das.jz@...renesas.com>, <atishp@...shpatra.org>,
        <palmer@...belt.com>, <guoheyi@...ux.alibaba.com>,
        <guoren@...ux.alibaba.com>
CC:     <prabhakar.mahadev-lad.rj@...renesas.com>,
        <paul.walmsley@...ive.com>, <aou@...s.berkeley.edu>,
        <atishp@...osinc.com>, <apatel@...tanamicro.com>,
        <geert+renesas@...der.be>, <linux-riscv@...ts.infradead.org>,
        <linux-renesas-soc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <prabhakar.csengg@...il.com>
Subject: Re: [RFC PATCH 1/2] riscv: vendors: andes: Add support to configure
 the PMA regions

On 08/09/2022 14:01, Biju Das wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Conor,
> 
> Thanks for the feedback.
> 
>> Subject: Re: [RFC PATCH 1/2] riscv: vendors: andes: Add support to
>> configure the PMA regions
>>
>> On 08/09/2022 09:39, Biju Das wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> Hi Conor, Atish,
>>>
>>> What RISC-V devices you have?
>>
>> A bunch ;)
>>
>> A __couple__ PolarFire SoC boards, HiFive Unleashed, D1 Nezha, Canaan
>> k210 MAIX something & the VisionFive.
> 
> If standard DMA api works without any issue means, on these platforms
> IO Coherence port is enabled in the hardware. So all peripherals
> involving DMA work as expected.
> 
>>> Ours is RISC-V uniprocessor without IO Coherence Port.
>>
>> What does "IO Coherence Port" mean? Zicbo*?
> 
> The HW will provide coherency between CPU and peripheral.
> 
> If Zibco* is uniprocessor, then highly it may not have IO coherence
> Port enabled in their design.

Zicbo* are cache management extensions as Geert pointed out.

> 
> Guo, Please confirm.
> 
>>
>>> Currently USB, ethernet, SDHI/eMMC doesn't work with standard DMA
>>> api's.
>>
>> Sounds pretty similar to the D1 so.
>>
>>> On RISC-V world, how do we handle DMA api for uniprocessor without IO
>>> Coherence Port?
>>
>> If you do mean Zicbo* you're into errata territory there & I don't know
>> if that'll be acceptable upstream - not for me to make that call...
> 
> It is not errata for sure. It is a HW design where we don't have
> IO cache coherency port enabled in the HW. So looks like it is not
> an extension or errata but it is core stuff.

If you do non-coherent stuff that is not Zicbo*, the precedence set by
the D1 is errata. As I said to Prabhakar earlier, do a
`git grep "ERRATA_THEAD*`. I am not a maintainer so I don't know the
"rules" about doing cache management without the dedicated extensions
are.

Hope that at least helps,
Conor.