[PATCH v1 2/3] riscv: errata: picoheart: Add workaround for cbo.clean errata

Vivian Wang wangruikang at iscas.ac.cn
Fri Jul 17 06:25:38 PDT 2026


On 7/17/26 18:42, Yicong Yang wrote:
> On 7/17/26 4:06 PM, Vivian Wang wrote:
>> [...]
>>
>> So you only need to have the wback function, and inv and wback can be
>> left as zero initialized. In that case arch_dma_cache_*() in
> benefit?
>
> I don't have strong feelings for either way but I feel this implicit
> assignment will make the code a bit less readable and not that
> self-explained. Considering only ~10 more LOCs if implement all
> these three callbacks...

To me the benefit is showing more clearly that wback_inv and inv are
standard, and only wback is non-standard.

>> arch/riscv/mm/dma-noncoherent.c will just do the standard operation. See
>> e.g.:
>>
>>     static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
>>     {
>>     	void *vaddr = phys_to_virt(paddr);
>>
>>     #ifdef CONFIG_RISCV_NONSTANDARD_CACHE_OPS
>>     	if (unlikely(noncoherent_cache_ops.inv)) {         // <-- HERE
>>     		noncoherent_cache_ops.inv(paddr, size);
>>     		return;
>>     	}
>>     #endif
>>
>>     	ALT_CMO_OP(INVAL, vaddr, size, riscv_cbom_block_size);
>>     }
>>
>> And after you've done that, consider this somewhat out of left field
>> suggestion: Move the static inline void arch_dma_cache_*() functions to
>> dma-noncoherent.h and here just define the nonstandard cache ops here as:
>>
>>     struct riscv_nonstd_cache_ops picoheart_errata_cmo_ops = {
>>     	.wback = arch_dma_cache_wback_inv
>>     };
>>
>> It's somewhat weirdly recursive but in a way that I think makes sense:
>> It's saying "Instead of wback, do a wback_inv" (Inform 7, anyone? :P).
>> Perf-wise this has one extra cache-hot load for the NULL wback_inv (hot
>> since it's *right* next to the wback function pointer just loaded), and
>> one predictably non-taken branch, and in exchange you get to just
>> completely drop all of your own implementations.
>>
> But I'll just implement the custom callback directly for the readability
> here (as you also find it weirdly, and probably more person will have
> doubts here).
>
Sure. I'm more of a fan of arranging the existing stuff, but, well,
that's just a personal preference.

Vivian "dramforever" Wang.




More information about the linux-riscv mailing list