Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Date:   Sun, 3 Dec 2023 18:56:56 +0800
From:   Philip Li <philip.li@intel.com>
To:     kernel test robot <lkp@intel.com>
CC:     Kees Cook <keescook@chromium.org>, <oe-kbuild-all@lists.linux.dev>,
        <linux-kernel@vger.kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: drivers/remoteproc/ti_k3_r5_remoteproc.c:437:9: sparse: sparse:
 incorrect type in argument 1 (different address spaces)
Message-ID: <ZWxe+M2RkN+UQ3SN@rli9-mobl>
References: <202312031555.EyyW2riN-lkp@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <202312031555.EyyW2riN-lkp@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?y/vqsJDIS/mEqsK0me+d05W8w+3MpHuXqi4pBfcejD91M9rPcOB6zJ//NDoj?=
 =?us-ascii?Q?w/jM9EKErfV6j3JM2ndYv3xULyjxDjIOgwK7JvC1T1LmayFgSuyvnyddP7sX?=
 =?us-ascii?Q?GGnIwcPrjLcTlEfSxcPmP8phL7bi9YiQFmdkgwRf4kkhy6ZCS2oFV4bhoX+o?=
 =?us-ascii?Q?KmtxudaMos7TX1Ea08IiV0F81Tv0q3EvrGMFs8Qa34M8XlGhdI9ws0j5son5?=
 =?us-ascii?Q?sw49a3H4/aUhwvOhWuU5qAZvGSO1PjrZV636Ixqt9Zz0c9/l70RE5NW0zi4z?=
 =?us-ascii?Q?GaDMvfXE4tsoxvPCubgsg2/gtig0fXTxLa/S5Ik1adQJPZ38s9qmzZfD5aTk?=
 =?us-ascii?Q?tUR0G4VEHrvPw6SlQgG+QVv6DLwoSo7XMv6UlfIB7F5dCDWIn1EG4cU0NUNd?=
 =?us-ascii?Q?iPZxF4Z8BKfx3QYmC1cB67g+3Mgk5dD8+O+5WLOuIRtpKHk7kzsny8eNHAdy?=
 =?us-ascii?Q?fKkTKMio/UKiGRmJlKFZSIfSGIpcsr+Ql6AJ5Jd8SAmw9blT2fTgD8NTvLnB?=
 =?us-ascii?Q?NVvkTSf5sPAHxN4sPB0k7GzNzQ6NPvJBxRMLrmvasTN4TSEBYXDiq89rM/12?=
 =?us-ascii?Q?66BNcMAvOoNQhZCZW3hFdP9oQpuHmY7vWY1deD4xIWinJX7Hn5jRYzkZv7fg?=
 =?us-ascii?Q?p0Xe+EJDMcuC6O8y0rJyQK6QW5XFFYW5Hl/lMBIpwlIEm5FhxCH1snpzicku?=
 =?us-ascii?Q?Q8/eS4ic8IvCne+5G9dRgmwQjlxvwUdw75JjcNJUhtc+VbtAcq+Ye2CGEmlI?=
 =?us-ascii?Q?i0mE8ykdpOURyGqRAS0nc0cYNuqGHFWIUz1pK4DmnLw6T3vHqd9gvYQW3ftI?=
 =?us-ascii?Q?RzZf8BRO+eWs6BXvo/IhOODoN5WWp7pnuu9tgbECVoBRKHEw5OTiAftgPJ4U?=
 =?us-ascii?Q?wuXKoXkLvQBly/PbVlumvQbEPPWF16RxdleSg0FNsq8JYhPRrvcyLJhofEsn?=
 =?us-ascii?Q?QcHXrDXVCfZ51deUxZh/TYPgQDVCbu9crZ+/B/znbxZxj5eYTPjwGvDGLSzP?=
 =?us-ascii?Q?MWds1DFOm1HXtlNNQ+uG0KIMjI4wInLkXjkForZW1ZxnZeDUqiuEFaiTU/e8?=
 =?us-ascii?Q?m5vm3iThegg2PjuV/cGeW+/2NkgkbD8Best9lbRk+wzzDXsoN/fqcULdjN6V?=
 =?us-ascii?Q?pyKnNyEo8i3prH8S8yyoYDsOp8UDmcOeu8qF9RcsRL7RuJ5wGiEyMmbzb6YA?=
 =?us-ascii?Q?vG5h2lFx59Xuw5HSocm35+3Yvj3+bbZOpU1Wr9uL4tw5PH0+T+OEY8vYBCgJ?=
 =?us-ascii?Q?inKrcTRt7sTfvqU4rsnyZjxbXy8Jy73T3SdGIygocbZ2gACk2pP1Bci7fzER?=
 =?us-ascii?Q?KOquIk/oBYLkY2k+Zot/5z+tyHjlQcy1h15VcadU/TMUeBMlPCmiVrOm882G?=
 =?us-ascii?Q?VwDd2YMPFE11QfTeXcobjv0HUi246QrR2y1yAwfH+IGkR/qucvvFKNXZ+QGz?=
 =?us-ascii?Q?wwJuJBLJJ9+LPYUV3qzLsnFIUwDbhPrRa7xT8aHpLB11+bd3yJdrRkZ74md/?=
 =?us-ascii?Q?rRlyzUAPX5fGMlBOhtPFTufIlkBLQUjpu6i+Q7rdzFcREeurATfMoGQhWoRj?=
 =?us-ascii?Q?ViYG7eQK98fhQNfpwDUTGdqn61sG9FGV2tjKKhT5?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 840eabb7-1876-4e44-c0c7-08dbf3ee95e5
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB2995.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2023 10:57:04.8866
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Vu4vJjY3xdozGHBHsYXAKiwBtumnCvB0mCg7A/8I9xNrnP40jz4c+wrdP+HO0+FyFKviEXsrCKgktaR/LwS+vg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5222
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Sun, 03 Dec 2023 03:03:14 -0800 (PST)

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/202312031555.EyyW2riN-lkp@intel.com/config)
> compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
> reproduce: (https://download.01.org/0day-ci/archive/20231203/202312031555.EyyW2riN-lkp@intel.com/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 <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202312031555.EyyW2riN-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://github.com/intel/lkp-tests/wiki