[PATCH v3 2/2] RISC-V: Clean up the Zicbom block size probing

Conor.Dooley at microchip.com Conor.Dooley at microchip.com
Thu Sep 8 00:50:47 PDT 2022


On 08/09/2022 08:11, Andrew Jones wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Wed, Sep 07, 2022 at 03:47:09PM -0700, Atish Patra wrote:
>> On Tue, Sep 6, 2022 at 12:45 AM Andrew Jones <ajones at ventanamicro.com>
>> wrote:
>>
>>> From: Palmer Dabbelt <palmer at rivosinc.com>
>>> -               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)
>>> -                               pr_warn("cbom-block-size mismatched
>>> between harts %d and %lu\n",
>>> +                       if (probed_block_size != val)
>>> +                               pr_warn("cbom-block-size mismatched
>>> between harts %lu and %lu\n",
>>>                                          cbom_hartid, hartid);
>>>
>>
>> Maybe add more info saying the first one will be selected in that case as
>> it is just a warning.
> 
> If we detect a mismatch then should we disable the CMO extension? The
> current spec says "size of a cache block shall be uniform throughout the
> system", even though that may be relaxed in later extensions. I also now
> recall you suggested that when DT parsing ends up with a zero block size
> we should disable the CMO extension. riscv_init_cbom_blocksize() still
> doesn't handle zeros in the DT correctly, even with this patch, though.
> For example, if the first harts parsed are zero, but the latter harts
> all match, we won't even get the mismatch warning.
> 
> But, for now, my preference would be to merge this patch, as it's an
> improvement on its own. I can try to write another patch which handles
> zeros and mismatches by disabling the feature. What do you think?

Given that the clang allmodconfig build is currently broken by this
issue, my preference would be to fix the issue first & follow up work
can sort out extra checks etc.

Conor.



More information about the linux-riscv mailing list