From: kernel test robot <lkp@intel.com>
To: Kees Cook <keescook@chromium.org>
Cc: kbuild-all@lists.01.org, linux-kernel@vger.kernel.org
Subject: drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse: incorrect type in argument 1 (different address spaces)
Date: Thu, 7 Apr 2022 08:13:16 +0800 [thread overview]
Message-ID: <202204070809.ucmsn4mT-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 3e732ebf7316ac83e8562db7e64cc68aec390a18
commit: 28e77cc1c0686621a4d416f599cee5ab369daa0a fortify: Detect struct member overflows in memset() at compile-time
date: 7 weeks ago
config: arm64-randconfig-s032-20220406 (https://download.01.org/0day-ci/archive/20220407/202204070809.ucmsn4mT-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 11.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-dirty
# https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28e77cc1c0686621a4d416f599cee5ab369daa0a
git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 28e77cc1c0686621a4d416f599cee5ab369daa0a
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/remoteproc/ lib/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
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 <s-anna@ti.com>
:::::: CC: Bjorn Andersson <bjorn.andersson@linaro.org>
--
0-DAY CI Kernel Test Service
https://01.org/lkp
next reply other threads:[~2022-04-07 0:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-07 0:13 kernel test robot [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-12-03 7:32 drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse: incorrect type in argument 1 (different address spaces) kernel test robot
2023-12-03 10:56 ` Philip Li
2022-10-22 20:46 kernel test robot
2022-09-16 15:35 kernel test robot
2022-08-19 20:49 kernel test robot
2022-08-04 6:48 kernel test robot
2022-06-04 19:04 kernel test robot
2022-04-19 11:09 kernel test robot
2022-04-04 2:41 kernel test robot
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=202204070809.ucmsn4mT-lkp@intel.com \
--to=lkp@intel.com \
--cc=kbuild-all@lists.01.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.