All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	ohad@wizery.com, bjorn.andersson@linaro.org,
	mathieu.poirier@linaro.org, o.rempel@pengutronix.de
Cc: kbuild-all@lists.01.org, shawnguo@kernel.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de,
	festevam@gmail.com, linux-imx@nxp.com,
	linux-remoteproc@vger.kernel.org
Subject: Re: [PATCH] remoteproc: elf_loader: fix loading segment when is_iomem true
Date: Mon, 28 Jun 2021 16:52:23 +0800	[thread overview]
Message-ID: <202106281601.7vHE0Go0-lkp@intel.com> (raw)
In-Reply-To: <20210628070657.7669-1-peng.fan@oss.nxp.com>

[-- Attachment #1: Type: text/plain, Size: 6806 bytes --]

Hi "Peng,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on soc/for-next]
[also build test WARNING on linus/master v5.13 next-20210625]
[cannot apply to xlnx/master remoteproc/for-next rpmsg/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Peng-Fan-OSS/remoteproc-elf_loader-fix-loading-segment-when-is_iomem-true/20210628-143358
base:   https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
config: riscv-randconfig-s031-20210628 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.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.3-341-g8af24329-dirty
        # https://github.com/0day-ci/linux/commit/2c90d7d15776bf485ad028de63002efbc2facc66
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Peng-Fan-OSS/remoteproc-elf_loader-fix-loading-segment-when-is_iomem-true/20210628-143358
        git checkout 2c90d7d15776bf485ad028de63002efbc2facc66
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv 

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/remoteproc_elf_loader.c:219:45: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void volatile [noderef] __iomem *addr @@     got void *[assigned] ptr @@
   drivers/remoteproc/remoteproc_elf_loader.c:219:45: sparse:     expected void volatile [noderef] __iomem *addr
   drivers/remoteproc/remoteproc_elf_loader.c:219:45: sparse:     got void *[assigned] ptr
>> drivers/remoteproc/remoteproc_elf_loader.c:219:51: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const *buffer @@     got void [noderef] __iomem * @@
   drivers/remoteproc/remoteproc_elf_loader.c:219:51: sparse:     expected void const *buffer
   drivers/remoteproc/remoteproc_elf_loader.c:219:51: sparse:     got void [noderef] __iomem *

vim +219 drivers/remoteproc/remoteproc_elf_loader.c

   131	
   132	/**
   133	 * rproc_elf_load_segments() - load firmware segments to memory
   134	 * @rproc: remote processor which will be booted using these fw segments
   135	 * @fw: the ELF firmware image
   136	 *
   137	 * This function loads the firmware segments to memory, where the remote
   138	 * processor expects them.
   139	 *
   140	 * Some remote processors will expect their code and data to be placed
   141	 * in specific device addresses, and can't have them dynamically assigned.
   142	 *
   143	 * We currently support only those kind of remote processors, and expect
   144	 * the program header's paddr member to contain those addresses. We then go
   145	 * through the physically contiguous "carveout" memory regions which we
   146	 * allocated (and mapped) earlier on behalf of the remote processor,
   147	 * and "translate" device address to kernel addresses, so we can copy the
   148	 * segments where they are expected.
   149	 *
   150	 * Currently we only support remote processors that required carveout
   151	 * allocations and got them mapped onto their iommus. Some processors
   152	 * might be different: they might not have iommus, and would prefer to
   153	 * directly allocate memory for every segment/resource. This is not yet
   154	 * supported, though.
   155	 */
   156	int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
   157	{
   158		struct device *dev = &rproc->dev;
   159		const void *ehdr, *phdr;
   160		int i, ret = 0;
   161		u16 phnum;
   162		const u8 *elf_data = fw->data;
   163		u8 class = fw_elf_get_class(fw);
   164		u32 elf_phdr_get_size = elf_size_of_phdr(class);
   165	
   166		ehdr = elf_data;
   167		phnum = elf_hdr_get_e_phnum(class, ehdr);
   168		phdr = elf_data + elf_hdr_get_e_phoff(class, ehdr);
   169	
   170		/* go through the available ELF segments */
   171		for (i = 0; i < phnum; i++, phdr += elf_phdr_get_size) {
   172			u64 da = elf_phdr_get_p_paddr(class, phdr);
   173			u64 memsz = elf_phdr_get_p_memsz(class, phdr);
   174			u64 filesz = elf_phdr_get_p_filesz(class, phdr);
   175			u64 offset = elf_phdr_get_p_offset(class, phdr);
   176			u32 type = elf_phdr_get_p_type(class, phdr);
   177			void *ptr;
   178			bool is_iomem;
   179	
   180			if (type != PT_LOAD)
   181				continue;
   182	
   183			dev_dbg(dev, "phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
   184				type, da, memsz, filesz);
   185	
   186			if (filesz > memsz) {
   187				dev_err(dev, "bad phdr filesz 0x%llx memsz 0x%llx\n",
   188					filesz, memsz);
   189				ret = -EINVAL;
   190				break;
   191			}
   192	
   193			if (offset + filesz > fw->size) {
   194				dev_err(dev, "truncated fw: need 0x%llx avail 0x%zx\n",
   195					offset + filesz, fw->size);
   196				ret = -EINVAL;
   197				break;
   198			}
   199	
   200			if (!rproc_u64_fit_in_size_t(memsz)) {
   201				dev_err(dev, "size (%llx) does not fit in size_t type\n",
   202					memsz);
   203				ret = -EOVERFLOW;
   204				break;
   205			}
   206	
   207			/* grab the kernel address for this device address */
   208			ptr = rproc_da_to_va(rproc, da, memsz, &is_iomem);
   209			if (!ptr) {
   210				dev_err(dev, "bad phdr da 0x%llx mem 0x%llx\n", da,
   211					memsz);
   212				ret = -EINVAL;
   213				break;
   214			}
   215	
   216			/* put the segment where the remote processor expects it */
   217			if (filesz) {
   218				if (is_iomem)
 > 219					memcpy_toio(ptr, (void __iomem *)(elf_data + offset), filesz);
   220				else
   221					memcpy(ptr, elf_data + offset, filesz);
   222			}
   223	
   224			/*
   225			 * Zero out remaining memory for this segment.
   226			 *
   227			 * This isn't strictly required since dma_alloc_coherent already
   228			 * did this for us. albeit harmless, we may consider removing
   229			 * this.
   230			 */
   231			if (memsz > filesz) {
   232				if (is_iomem)
   233					memset_io((void __iomem *)(ptr + filesz), 0, memsz - filesz);
   234				else
   235					memset(ptr + filesz, 0, memsz - filesz);
   236			}
   237		}
   238	
   239		return ret;
   240	}
   241	EXPORT_SYMBOL(rproc_elf_load_segments);
   242	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33286 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH] remoteproc: elf_loader: fix loading segment when is_iomem true
Date: Mon, 28 Jun 2021 16:52:23 +0800	[thread overview]
Message-ID: <202106281601.7vHE0Go0-lkp@intel.com> (raw)
In-Reply-To: <20210628070657.7669-1-peng.fan@oss.nxp.com>

[-- Attachment #1: Type: text/plain, Size: 6965 bytes --]

Hi "Peng,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on soc/for-next]
[also build test WARNING on linus/master v5.13 next-20210625]
[cannot apply to xlnx/master remoteproc/for-next rpmsg/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Peng-Fan-OSS/remoteproc-elf_loader-fix-loading-segment-when-is_iomem-true/20210628-143358
base:   https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
config: riscv-randconfig-s031-20210628 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.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.3-341-g8af24329-dirty
        # https://github.com/0day-ci/linux/commit/2c90d7d15776bf485ad028de63002efbc2facc66
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Peng-Fan-OSS/remoteproc-elf_loader-fix-loading-segment-when-is_iomem-true/20210628-143358
        git checkout 2c90d7d15776bf485ad028de63002efbc2facc66
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv 

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/remoteproc_elf_loader.c:219:45: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void volatile [noderef] __iomem *addr @@     got void *[assigned] ptr @@
   drivers/remoteproc/remoteproc_elf_loader.c:219:45: sparse:     expected void volatile [noderef] __iomem *addr
   drivers/remoteproc/remoteproc_elf_loader.c:219:45: sparse:     got void *[assigned] ptr
>> drivers/remoteproc/remoteproc_elf_loader.c:219:51: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const *buffer @@     got void [noderef] __iomem * @@
   drivers/remoteproc/remoteproc_elf_loader.c:219:51: sparse:     expected void const *buffer
   drivers/remoteproc/remoteproc_elf_loader.c:219:51: sparse:     got void [noderef] __iomem *

vim +219 drivers/remoteproc/remoteproc_elf_loader.c

   131	
   132	/**
   133	 * rproc_elf_load_segments() - load firmware segments to memory
   134	 * @rproc: remote processor which will be booted using these fw segments
   135	 * @fw: the ELF firmware image
   136	 *
   137	 * This function loads the firmware segments to memory, where the remote
   138	 * processor expects them.
   139	 *
   140	 * Some remote processors will expect their code and data to be placed
   141	 * in specific device addresses, and can't have them dynamically assigned.
   142	 *
   143	 * We currently support only those kind of remote processors, and expect
   144	 * the program header's paddr member to contain those addresses. We then go
   145	 * through the physically contiguous "carveout" memory regions which we
   146	 * allocated (and mapped) earlier on behalf of the remote processor,
   147	 * and "translate" device address to kernel addresses, so we can copy the
   148	 * segments where they are expected.
   149	 *
   150	 * Currently we only support remote processors that required carveout
   151	 * allocations and got them mapped onto their iommus. Some processors
   152	 * might be different: they might not have iommus, and would prefer to
   153	 * directly allocate memory for every segment/resource. This is not yet
   154	 * supported, though.
   155	 */
   156	int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
   157	{
   158		struct device *dev = &rproc->dev;
   159		const void *ehdr, *phdr;
   160		int i, ret = 0;
   161		u16 phnum;
   162		const u8 *elf_data = fw->data;
   163		u8 class = fw_elf_get_class(fw);
   164		u32 elf_phdr_get_size = elf_size_of_phdr(class);
   165	
   166		ehdr = elf_data;
   167		phnum = elf_hdr_get_e_phnum(class, ehdr);
   168		phdr = elf_data + elf_hdr_get_e_phoff(class, ehdr);
   169	
   170		/* go through the available ELF segments */
   171		for (i = 0; i < phnum; i++, phdr += elf_phdr_get_size) {
   172			u64 da = elf_phdr_get_p_paddr(class, phdr);
   173			u64 memsz = elf_phdr_get_p_memsz(class, phdr);
   174			u64 filesz = elf_phdr_get_p_filesz(class, phdr);
   175			u64 offset = elf_phdr_get_p_offset(class, phdr);
   176			u32 type = elf_phdr_get_p_type(class, phdr);
   177			void *ptr;
   178			bool is_iomem;
   179	
   180			if (type != PT_LOAD)
   181				continue;
   182	
   183			dev_dbg(dev, "phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
   184				type, da, memsz, filesz);
   185	
   186			if (filesz > memsz) {
   187				dev_err(dev, "bad phdr filesz 0x%llx memsz 0x%llx\n",
   188					filesz, memsz);
   189				ret = -EINVAL;
   190				break;
   191			}
   192	
   193			if (offset + filesz > fw->size) {
   194				dev_err(dev, "truncated fw: need 0x%llx avail 0x%zx\n",
   195					offset + filesz, fw->size);
   196				ret = -EINVAL;
   197				break;
   198			}
   199	
   200			if (!rproc_u64_fit_in_size_t(memsz)) {
   201				dev_err(dev, "size (%llx) does not fit in size_t type\n",
   202					memsz);
   203				ret = -EOVERFLOW;
   204				break;
   205			}
   206	
   207			/* grab the kernel address for this device address */
   208			ptr = rproc_da_to_va(rproc, da, memsz, &is_iomem);
   209			if (!ptr) {
   210				dev_err(dev, "bad phdr da 0x%llx mem 0x%llx\n", da,
   211					memsz);
   212				ret = -EINVAL;
   213				break;
   214			}
   215	
   216			/* put the segment where the remote processor expects it */
   217			if (filesz) {
   218				if (is_iomem)
 > 219					memcpy_toio(ptr, (void __iomem *)(elf_data + offset), filesz);
   220				else
   221					memcpy(ptr, elf_data + offset, filesz);
   222			}
   223	
   224			/*
   225			 * Zero out remaining memory for this segment.
   226			 *
   227			 * This isn't strictly required since dma_alloc_coherent already
   228			 * did this for us. albeit harmless, we may consider removing
   229			 * this.
   230			 */
   231			if (memsz > filesz) {
   232				if (is_iomem)
   233					memset_io((void __iomem *)(ptr + filesz), 0, memsz - filesz);
   234				else
   235					memset(ptr + filesz, 0, memsz - filesz);
   236			}
   237		}
   238	
   239		return ret;
   240	}
   241	EXPORT_SYMBOL(rproc_elf_load_segments);
   242	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 33286 bytes --]

  reply	other threads:[~2021-06-28  8:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28  7:06 [PATCH] remoteproc: elf_loader: fix loading segment when is_iomem true Peng Fan (OSS)
2021-06-28  7:06 ` Peng Fan (OSS)
2021-06-28  8:52 ` kernel test robot [this message]
2021-06-28  8:52   ` kernel test robot
2021-06-28 13:45 ` kernel test robot
2021-06-28 13:45   ` kernel test robot
2021-06-28 14:23 ` kernel test robot
2021-06-28 14:23   ` kernel test robot
2021-06-28 16:16 ` Bjorn Andersson
2021-06-28 16:16   ` Bjorn Andersson
2021-07-01 16:15 ` kernel test robot
2021-07-01 16:15   ` kernel test robot
2021-07-05  7:22 ` kernel test robot
2021-07-05  7:22   ` kernel test robot
2021-07-05 21:07 ` kernel test robot
2021-07-05 21:07   ` kernel test robot
2021-07-06 12:55 ` kernel test robot
2021-07-06 12:55   ` 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=202106281601.7vHE0Go0-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=festevam@gmail.com \
    --cc=kbuild-all@lists.01.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-imx@nxp.com \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=o.rempel@pengutronix.de \
    --cc=ohad@wizery.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@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.