2023-12-03 07:33:26

by kernel test robot

[permalink] [raw]
Subject: drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse: incorrect type in argument 1 (different address spaces)

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 968f35f4ab1c0966ceb39af3c89f2e24afedf878
commit: 281d0c962752fb40866dd8d4cade68656f34bd1f fortify: Add Clang support
date: 1 year, 10 months ago
config: arm64-randconfig-r131-20231130 (https://download.01.org/0day-ci/archive/20231203/[email protected]/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce: (https://download.01.org/0day-ci/archive/20231203/[email protected]/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

sparse warnings: (new ones prefixed by >>)
>> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const * @@ got void [noderef] __iomem *cpu_addr @@
drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: expected void const *
drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: got void [noderef] __iomem *cpu_addr
>> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const * @@ got void [noderef] __iomem *cpu_addr @@
drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: expected void const *
drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: got void [noderef] __iomem *cpu_addr
drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void * @@ got void [noderef] __iomem *cpu_addr @@
drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: expected void *
drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: got void [noderef] __iomem *cpu_addr
drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const * @@ got void [noderef] __iomem *cpu_addr @@
drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: expected void const *
drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: got void [noderef] __iomem *cpu_addr
drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const * @@ got void [noderef] __iomem *cpu_addr @@
drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: expected void const *
drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: got void [noderef] __iomem *cpu_addr
drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void * @@ got void [noderef] __iomem *cpu_addr @@
drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: expected void *
drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: got void [noderef] __iomem *cpu_addr

vim +437 drivers/remoteproc/ti_k3_r5_remoteproc.c

6dedbd1d544389 Suman Anna 2020-10-02 378
6dedbd1d544389 Suman Anna 2020-10-02 379 /*
6dedbd1d544389 Suman Anna 2020-10-02 380 * The R5F cores have controls for both a reset and a halt/run. The code
6dedbd1d544389 Suman Anna 2020-10-02 381 * execution from DDR requires the initial boot-strapping code to be run
6dedbd1d544389 Suman Anna 2020-10-02 382 * from the internal TCMs. This function is used to release the resets on
6dedbd1d544389 Suman Anna 2020-10-02 383 * applicable cores to allow loading into the TCMs. The .prepare() ops is
6dedbd1d544389 Suman Anna 2020-10-02 384 * invoked by remoteproc core before any firmware loading, and is followed
6dedbd1d544389 Suman Anna 2020-10-02 385 * by the .start() ops after loading to actually let the R5 cores run.
ee99ee7c929c3e Suman Anna 2021-03-27 386 *
ee99ee7c929c3e Suman Anna 2021-03-27 387 * The Single-CPU mode on applicable SoCs (eg: AM64x) only uses Core0 to
ee99ee7c929c3e Suman Anna 2021-03-27 388 * execute code, but combines the TCMs from both cores. The resets for both
ee99ee7c929c3e Suman Anna 2021-03-27 389 * cores need to be released to make this possible, as the TCMs are in general
ee99ee7c929c3e Suman Anna 2021-03-27 390 * private to each core. Only Core0 needs to be unhalted for running the
ee99ee7c929c3e Suman Anna 2021-03-27 391 * cluster in this mode. The function uses the same reset logic as LockStep
ee99ee7c929c3e Suman Anna 2021-03-27 392 * mode for this (though the behavior is agnostic of the reset release order).
6dedbd1d544389 Suman Anna 2020-10-02 393 */
6dedbd1d544389 Suman Anna 2020-10-02 394 static int k3_r5_rproc_prepare(struct rproc *rproc)
6dedbd1d544389 Suman Anna 2020-10-02 395 {
6dedbd1d544389 Suman Anna 2020-10-02 396 struct k3_r5_rproc *kproc = rproc->priv;
6dedbd1d544389 Suman Anna 2020-10-02 397 struct k3_r5_cluster *cluster = kproc->cluster;
6dedbd1d544389 Suman Anna 2020-10-02 398 struct k3_r5_core *core = kproc->core;
6dedbd1d544389 Suman Anna 2020-10-02 399 struct device *dev = kproc->dev;
7508ea19b20da8 Suman Anna 2020-11-18 400 u32 ctrl = 0, cfg = 0, stat = 0;
7508ea19b20da8 Suman Anna 2020-11-18 401 u64 boot_vec = 0;
7508ea19b20da8 Suman Anna 2020-11-18 402 bool mem_init_dis;
6dedbd1d544389 Suman Anna 2020-10-02 403 int ret;
6dedbd1d544389 Suman Anna 2020-10-02 404
7508ea19b20da8 Suman Anna 2020-11-18 405 ret = ti_sci_proc_get_status(core->tsp, &boot_vec, &cfg, &ctrl, &stat);
7508ea19b20da8 Suman Anna 2020-11-18 406 if (ret < 0)
7508ea19b20da8 Suman Anna 2020-11-18 407 return ret;
7508ea19b20da8 Suman Anna 2020-11-18 408 mem_init_dis = !!(cfg & PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS);
7508ea19b20da8 Suman Anna 2020-11-18 409
ee99ee7c929c3e Suman Anna 2021-03-27 410 /* Re-use LockStep-mode reset logic for Single-CPU mode */
ee99ee7c929c3e Suman Anna 2021-03-27 411 ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP ||
ee99ee7c929c3e Suman Anna 2021-03-27 412 cluster->mode == CLUSTER_MODE_SINGLECPU) ?
6dedbd1d544389 Suman Anna 2020-10-02 413 k3_r5_lockstep_release(cluster) : k3_r5_split_release(core);
34f2653686fecc Suman Anna 2020-10-02 414 if (ret) {
6dedbd1d544389 Suman Anna 2020-10-02 415 dev_err(dev, "unable to enable cores for TCM loading, ret = %d\n",
6dedbd1d544389 Suman Anna 2020-10-02 416 ret);
6dedbd1d544389 Suman Anna 2020-10-02 417 return ret;
6dedbd1d544389 Suman Anna 2020-10-02 418 }
6dedbd1d544389 Suman Anna 2020-10-02 419
7508ea19b20da8 Suman Anna 2020-11-18 420 /*
7508ea19b20da8 Suman Anna 2020-11-18 421 * Newer IP revisions like on J7200 SoCs support h/w auto-initialization
7508ea19b20da8 Suman Anna 2020-11-18 422 * of TCMs, so there is no need to perform the s/w memzero. This bit is
7508ea19b20da8 Suman Anna 2020-11-18 423 * configurable through System Firmware, the default value does perform
7508ea19b20da8 Suman Anna 2020-11-18 424 * auto-init, but account for it in case it is disabled
7508ea19b20da8 Suman Anna 2020-11-18 425 */
7508ea19b20da8 Suman Anna 2020-11-18 426 if (cluster->soc_data->tcm_ecc_autoinit && !mem_init_dis) {
7508ea19b20da8 Suman Anna 2020-11-18 427 dev_dbg(dev, "leveraging h/w init for TCM memories\n");
7508ea19b20da8 Suman Anna 2020-11-18 428 return 0;
7508ea19b20da8 Suman Anna 2020-11-18 429 }
7508ea19b20da8 Suman Anna 2020-11-18 430
34f2653686fecc Suman Anna 2020-10-02 431 /*
34f2653686fecc Suman Anna 2020-10-02 432 * Zero out both TCMs unconditionally (access from v8 Arm core is not
34f2653686fecc Suman Anna 2020-10-02 433 * affected by ATCM & BTCM enable configuration values) so that ECC
34f2653686fecc Suman Anna 2020-10-02 434 * can be effective on all TCM addresses.
34f2653686fecc Suman Anna 2020-10-02 435 */
34f2653686fecc Suman Anna 2020-10-02 436 dev_dbg(dev, "zeroing out ATCM memory\n");
34f2653686fecc Suman Anna 2020-10-02 @437 memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size);
34f2653686fecc Suman Anna 2020-10-02 438
34f2653686fecc Suman Anna 2020-10-02 439 dev_dbg(dev, "zeroing out BTCM memory\n");
34f2653686fecc Suman Anna 2020-10-02 440 memset(core->mem[1].cpu_addr, 0x00, core->mem[1].size);
34f2653686fecc Suman Anna 2020-10-02 441
34f2653686fecc Suman Anna 2020-10-02 442 return 0;
34f2653686fecc Suman Anna 2020-10-02 443 }
34f2653686fecc Suman Anna 2020-10-02 444

:::::: The code at line 437 was first introduced by commit
:::::: 34f2653686fecc9bd5a4ee16724768c72953fb57 remoteproc: k3-r5: Initialize TCM memories for ECC

:::::: TO: Suman Anna <[email protected]>
:::::: CC: Bjorn Andersson <[email protected]>

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


2023-12-03 11:03:18

by Li, Philip

[permalink] [raw]
Subject: Re: drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse: incorrect type in argument 1 (different address spaces)

On Sun, Dec 03, 2023 at 03:32:46PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 968f35f4ab1c0966ceb39af3c89f2e24afedf878
> commit: 281d0c962752fb40866dd8d4cade68656f34bd1f fortify: Add Clang support
> date: 1 year, 10 months ago
> config: arm64-randconfig-r131-20231130 (https://download.01.org/0day-ci/archive/20231203/[email protected]/config)
> compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
> reproduce: (https://download.01.org/0day-ci/archive/20231203/[email protected]/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of

Kindly ignore the report that the found commit is not the cause of
this sparse warning. Sorry for the wrong info.

> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <[email protected]>
> | Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>
> sparse warnings: (new ones prefixed by >>)
> >> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const * @@ got void [noderef] __iomem *cpu_addr @@
> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: expected void const *
> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: got void [noderef] __iomem *cpu_addr
> >> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const * @@ got void [noderef] __iomem *cpu_addr @@
> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: expected void const *
> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: got void [noderef] __iomem *cpu_addr
> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void * @@ got void [noderef] __iomem *cpu_addr @@
> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: expected void *
> drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: got void [noderef] __iomem *cpu_addr
> drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const * @@ got void [noderef] __iomem *cpu_addr @@
> drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: expected void const *
> drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: got void [noderef] __iomem *cpu_addr
> drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const * @@ got void [noderef] __iomem *cpu_addr @@
> drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: expected void const *
> drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: got void [noderef] __iomem *cpu_addr
> drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void * @@ got void [noderef] __iomem *cpu_addr @@
> drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: expected void *
> drivers/remoteproc/ti_k3_r5_remoteproc.c:440:9: sparse: got void [noderef] __iomem *cpu_addr
>
> vim +437 drivers/remoteproc/ti_k3_r5_remoteproc.c
>
> 6dedbd1d544389 Suman Anna 2020-10-02 378
> 6dedbd1d544389 Suman Anna 2020-10-02 379 /*
> 6dedbd1d544389 Suman Anna 2020-10-02 380 * The R5F cores have controls for both a reset and a halt/run. The code
> 6dedbd1d544389 Suman Anna 2020-10-02 381 * execution from DDR requires the initial boot-strapping code to be run
> 6dedbd1d544389 Suman Anna 2020-10-02 382 * from the internal TCMs. This function is used to release the resets on
> 6dedbd1d544389 Suman Anna 2020-10-02 383 * applicable cores to allow loading into the TCMs. The .prepare() ops is
> 6dedbd1d544389 Suman Anna 2020-10-02 384 * invoked by remoteproc core before any firmware loading, and is followed
> 6dedbd1d544389 Suman Anna 2020-10-02 385 * by the .start() ops after loading to actually let the R5 cores run.
> ee99ee7c929c3e Suman Anna 2021-03-27 386 *
> ee99ee7c929c3e Suman Anna 2021-03-27 387 * The Single-CPU mode on applicable SoCs (eg: AM64x) only uses Core0 to
> ee99ee7c929c3e Suman Anna 2021-03-27 388 * execute code, but combines the TCMs from both cores. The resets for both
> ee99ee7c929c3e Suman Anna 2021-03-27 389 * cores need to be released to make this possible, as the TCMs are in general
> ee99ee7c929c3e Suman Anna 2021-03-27 390 * private to each core. Only Core0 needs to be unhalted for running the
> ee99ee7c929c3e Suman Anna 2021-03-27 391 * cluster in this mode. The function uses the same reset logic as LockStep
> ee99ee7c929c3e Suman Anna 2021-03-27 392 * mode for this (though the behavior is agnostic of the reset release order).
> 6dedbd1d544389 Suman Anna 2020-10-02 393 */
> 6dedbd1d544389 Suman Anna 2020-10-02 394 static int k3_r5_rproc_prepare(struct rproc *rproc)
> 6dedbd1d544389 Suman Anna 2020-10-02 395 {
> 6dedbd1d544389 Suman Anna 2020-10-02 396 struct k3_r5_rproc *kproc = rproc->priv;
> 6dedbd1d544389 Suman Anna 2020-10-02 397 struct k3_r5_cluster *cluster = kproc->cluster;
> 6dedbd1d544389 Suman Anna 2020-10-02 398 struct k3_r5_core *core = kproc->core;
> 6dedbd1d544389 Suman Anna 2020-10-02 399 struct device *dev = kproc->dev;
> 7508ea19b20da8 Suman Anna 2020-11-18 400 u32 ctrl = 0, cfg = 0, stat = 0;
> 7508ea19b20da8 Suman Anna 2020-11-18 401 u64 boot_vec = 0;
> 7508ea19b20da8 Suman Anna 2020-11-18 402 bool mem_init_dis;
> 6dedbd1d544389 Suman Anna 2020-10-02 403 int ret;
> 6dedbd1d544389 Suman Anna 2020-10-02 404
> 7508ea19b20da8 Suman Anna 2020-11-18 405 ret = ti_sci_proc_get_status(core->tsp, &boot_vec, &cfg, &ctrl, &stat);
> 7508ea19b20da8 Suman Anna 2020-11-18 406 if (ret < 0)
> 7508ea19b20da8 Suman Anna 2020-11-18 407 return ret;
> 7508ea19b20da8 Suman Anna 2020-11-18 408 mem_init_dis = !!(cfg & PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS);
> 7508ea19b20da8 Suman Anna 2020-11-18 409
> ee99ee7c929c3e Suman Anna 2021-03-27 410 /* Re-use LockStep-mode reset logic for Single-CPU mode */
> ee99ee7c929c3e Suman Anna 2021-03-27 411 ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP ||
> ee99ee7c929c3e Suman Anna 2021-03-27 412 cluster->mode == CLUSTER_MODE_SINGLECPU) ?
> 6dedbd1d544389 Suman Anna 2020-10-02 413 k3_r5_lockstep_release(cluster) : k3_r5_split_release(core);
> 34f2653686fecc Suman Anna 2020-10-02 414 if (ret) {
> 6dedbd1d544389 Suman Anna 2020-10-02 415 dev_err(dev, "unable to enable cores for TCM loading, ret = %d\n",
> 6dedbd1d544389 Suman Anna 2020-10-02 416 ret);
> 6dedbd1d544389 Suman Anna 2020-10-02 417 return ret;
> 6dedbd1d544389 Suman Anna 2020-10-02 418 }
> 6dedbd1d544389 Suman Anna 2020-10-02 419
> 7508ea19b20da8 Suman Anna 2020-11-18 420 /*
> 7508ea19b20da8 Suman Anna 2020-11-18 421 * Newer IP revisions like on J7200 SoCs support h/w auto-initialization
> 7508ea19b20da8 Suman Anna 2020-11-18 422 * of TCMs, so there is no need to perform the s/w memzero. This bit is
> 7508ea19b20da8 Suman Anna 2020-11-18 423 * configurable through System Firmware, the default value does perform
> 7508ea19b20da8 Suman Anna 2020-11-18 424 * auto-init, but account for it in case it is disabled
> 7508ea19b20da8 Suman Anna 2020-11-18 425 */
> 7508ea19b20da8 Suman Anna 2020-11-18 426 if (cluster->soc_data->tcm_ecc_autoinit && !mem_init_dis) {
> 7508ea19b20da8 Suman Anna 2020-11-18 427 dev_dbg(dev, "leveraging h/w init for TCM memories\n");
> 7508ea19b20da8 Suman Anna 2020-11-18 428 return 0;
> 7508ea19b20da8 Suman Anna 2020-11-18 429 }
> 7508ea19b20da8 Suman Anna 2020-11-18 430
> 34f2653686fecc Suman Anna 2020-10-02 431 /*
> 34f2653686fecc Suman Anna 2020-10-02 432 * Zero out both TCMs unconditionally (access from v8 Arm core is not
> 34f2653686fecc Suman Anna 2020-10-02 433 * affected by ATCM & BTCM enable configuration values) so that ECC
> 34f2653686fecc Suman Anna 2020-10-02 434 * can be effective on all TCM addresses.
> 34f2653686fecc Suman Anna 2020-10-02 435 */
> 34f2653686fecc Suman Anna 2020-10-02 436 dev_dbg(dev, "zeroing out ATCM memory\n");
> 34f2653686fecc Suman Anna 2020-10-02 @437 memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size);
> 34f2653686fecc Suman Anna 2020-10-02 438
> 34f2653686fecc Suman Anna 2020-10-02 439 dev_dbg(dev, "zeroing out BTCM memory\n");
> 34f2653686fecc Suman Anna 2020-10-02 440 memset(core->mem[1].cpu_addr, 0x00, core->mem[1].size);
> 34f2653686fecc Suman Anna 2020-10-02 441
> 34f2653686fecc Suman Anna 2020-10-02 442 return 0;
> 34f2653686fecc Suman Anna 2020-10-02 443 }
> 34f2653686fecc Suman Anna 2020-10-02 444
>
> :::::: The code at line 437 was first introduced by commit
> :::::: 34f2653686fecc9bd5a4ee16724768c72953fb57 remoteproc: k3-r5: Initialize TCM memories for ECC
>
> :::::: TO: Suman Anna <[email protected]>
> :::::: CC: Bjorn Andersson <[email protected]>
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki