[PATCH v2] RISC-V: Clean up the Zicbom block size probing
Conor.Dooley at microchip.com
Conor.Dooley at microchip.com
Mon Aug 22 15:02:33 PDT 2022
On 13/08/2022 00:07, Palmer Dabbelt wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Fri, 12 Aug 2022 10:43:02 PDT (-0700), atishp at atishpatra.org wrote:
>> On Fri, Aug 12, 2022 at 9:06 AM Palmer Dabbelt <palmer at 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 at intel.com>
>>> Signed-off-by: Palmer Dabbelt <palmer at 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.
>
> That seems reasonable to me, even if having a 0 block size is allowed by
> the spec it seems way more likely to have been a mistake. I'll send a
> v3, after puttting together a toolchain that actually builds this
> (assuming that's why I'm not getting the failures/warnings).
What's the plan here with v3?
I folded the following into this version locally to clear both the original
warning & the build error with this patch on clang-15:
diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c
index 3aa3572715d6..8a49ea5ba01d 100644
--- a/arch/riscv/mm/dma-noncoherent.c
+++ b/arch/riscv/mm/dma-noncoherent.c
@@ -79,12 +79,13 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
void riscv_init_cbom_blocksize(void)
{
struct device_node *node;
- int ret;
+ unsigned long cbom_hartid;
u32 val, probed_block_size;
+ int ret;
probed_block_size = 0;
for_each_of_cpu_node(node) {
- unsigned long hartid, cbom_hartid;
+ unsigned long hartid;
ret = riscv_of_processor_hartid(node, &hartid);
if (ret)
@@ -100,7 +101,7 @@ void riscv_init_cbom_blocksize(void)
cbom_hartid = hartid;
} else {
if (probed_block_size != val)
- pr_warn("cbom-block-size mismatched between harts %d and %lu\n",
+ pr_warn("cbom-block-size mismatched between harts %lu and %lu\n",
cbom_hartid, hartid);
}
}
@@ -112,7 +113,7 @@ void riscv_init_cbom_blocksize(void)
void riscv_noncoherent_supported(void)
{
- WARN_ON(!riscv_cbom_block_size,
- "Non-coherent DMA support enabled without a block size\n");
+ WARN(!riscv_cbom_block_size,
+ "Non-coherent DMA support enabled without a block size\n");
noncoherent_supported = true;
}
>
>>
>>> 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
>>>
>>>
More information about the linux-riscv
mailing list