public inbox for linux-riscv@lists.infradead.org
 help / color / mirror / Atom feed
From: <Conor.Dooley@microchip.com>
To: <palmer@rivosinc.com>, <atishp@atishpatra.org>
Cc: <linux-riscv@lists.infradead.org>, <anup@brainfault.org>,
	<lkp@intel.com>
Subject: Re: [PATCH v2] RISC-V: Clean up the Zicbom block size probing
Date: Mon, 22 Aug 2022 22:02:33 +0000	[thread overview]
Message-ID: <ebc4bbcd-becf-c5b7-7b7b-82dfb4c81bf8@microchip.com> (raw)
In-Reply-To: <mhng-897dd8a7-bc9f-4a5c-a336-3d48633a1e58@palmer-ri-x1c9>

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@atishpatra.org wrote:
>> 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.
> 
> 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
>>>
>>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2022-08-22 22:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12 15:40 [PATCH v2] RISC-V: Clean up the Zicbom block size probing Palmer Dabbelt
2022-08-12 17:26 ` Conor.Dooley
2022-08-12 17:43 ` Atish Patra
2022-08-12 23:07   ` Palmer Dabbelt
2022-08-22 22:02     ` Conor.Dooley [this message]
2022-08-15 15:40 ` Nathan Chancellor
2022-08-15 17:36   ` Jessica Clarke
2022-08-15 18:16     ` Nathan Chancellor
2022-09-01 15:57 ` Heiko Stübner
2022-09-02  9:55   ` Conor.Dooley
2022-09-06  6:08     ` Andrew Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ebc4bbcd-becf-c5b7-7b7b-82dfb4c81bf8@microchip.com \
    --to=conor.dooley@microchip.com \
    --cc=anup@brainfault.org \
    --cc=atishp@atishpatra.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=lkp@intel.com \
    --cc=palmer@rivosinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox