Re: [PATCH v2] RISC-V: Clean up the Zicbom block size probing

Atish Patra
2022-08-12T17:43:45Z

On Fri, Aug 12, 2022 at 9:06 AM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>
> This fixes two issues: I truncated the warning's hart ID when porting to
> the 64-bit hart ID code, and the original code's warning handling could
> fire on an uninitialized hart ID.
>
> The biggest change here is that riscv_cbom_block_size is no longer
> initialized, as IMO the default isn't sane: there's nothing in the ISA
> that mandates any specific cache block size, so falling back to one will
> just silently produce the wrong answer on some systems. This also
> changes the probing order so the cache block size is known before
> enabling Zicbom support.
>
> Fixes: 3aefb2ee5bdd ("riscv: implement Zicbom-based CMO instructions + the t-head variant")
> Fixes: 1631ba1259d6 ("riscv: Add support for non-coherent devices using zicbom extension")
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>
> ---
>
> Changes since v1 <https://lore.kernel.org/all/20220812142400.7186-1-palmer@rivosinc.com/>:
>
> * Everything but the unsigned long cbom_hartid.
> ---
> arch/riscv/kernel/setup.c | 2 +-
> arch/riscv/mm/dma-noncoherent.c | 22 ++++++++++++----------
> 2 files changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 95ef6e2bf45c..2dfc463b86bb 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -296,8 +296,8 @@ void __init setup_arch(char **cmdline_p)
> setup_smp();
> #endif
>
> - riscv_fill_hwcap();
> riscv_init_cbom_blocksize();
> + riscv_fill_hwcap();
> apply_boot_alternatives();
> }
>
> diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c
> index cd2225304c82..3aa3572715d6 100644
> --- a/arch/riscv/mm/dma-noncoherent.c
> +++ b/arch/riscv/mm/dma-noncoherent.c
> @@ -12,7 +12,7 @@
> #include <linux/of_device.h>
> #include <asm/cacheflush.h>
>
> -static unsigned int riscv_cbom_block_size = L1_CACHE_BYTES;
> +static unsigned int riscv_cbom_block_size;

What is the expected behavior if the block size is zero in CMO
operations ? As per my understanding, it will be equivalent to a nop.
Let me know if I am wrong.

If that is the case, this is misleading as well. Maybe we should just
disable CMO extension altogether if it can't find the DT property.

> static bool noncoherent_supported;
>
> void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
> @@ -80,37 +80,39 @@ void riscv_init_cbom_blocksize(void)
> {
> struct device_node *node;
> int ret;
> - u32 val;
> + u32 val, probed_block_size;
>
> + probed_block_size = 0;
> for_each_of_cpu_node(node) {
> - unsigned long hartid;
> - int cbom_hartid;
> + unsigned long hartid, cbom_hartid;
>
> ret = riscv_of_processor_hartid(node, &hartid);
> if (ret)
> continue;
>
> - if (hartid < 0)
> - continue;
> -
> /* set block-size for cbom extension if available */
> ret = of_property_read_u32(node, "riscv,cbom-block-size", &val);
> if (ret)
> continue;
>
> - if (!riscv_cbom_block_size) {
> - riscv_cbom_block_size = val;
> + if (!probed_block_size) {
> + probed_block_size = val;
> cbom_hartid = hartid;
> } else {
> - if (riscv_cbom_block_size != val)
> + if (probed_block_size != val)
> pr_warn("cbom-block-size mismatched between harts %d and %lu\n",
> cbom_hartid, hartid);
> }
> }
> +
> + if (probed_block_size)
> + riscv_cbom_block_size = probed_block_size;
> }
> #endif
>
> void riscv_noncoherent_supported(void)
> {
> + WARN_ON(!riscv_cbom_block_size,
> + "Non-coherent DMA support enabled without a block size\n");
> noncoherent_supported = true;
> }
> --
> 2.34.1
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

--
Regards,
Atish