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: Fri, 2 Jul 2021 00:15:43 +0800 [thread overview] Message-ID: <202107020053.Z9mjYXjf-lkp@intel.com> (raw) In-Reply-To: <20210628070657.7669-1-peng.fan@oss.nxp.com> [-- Attachment #1: Type: text/plain, Size: 6798 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-20210701] [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: arm-randconfig-s031-20210630 (attached as .config) compiler: arm-linux-gnueabi-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=arm 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:33: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem *to @@ got void *[assigned] ptr @@ drivers/remoteproc/remoteproc_elf_loader.c:219:33: sparse: expected void volatile [noderef] __iomem *to drivers/remoteproc/remoteproc_elf_loader.c:219:33: sparse: got void *[assigned] ptr >> drivers/remoteproc/remoteproc_elf_loader.c:219:33: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const *from @@ got void [noderef] __iomem * @@ drivers/remoteproc/remoteproc_elf_loader.c:219:33: sparse: expected void const *from drivers/remoteproc/remoteproc_elf_loader.c:219:33: 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: 34855 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: Fri, 02 Jul 2021 00:15:43 +0800 [thread overview] Message-ID: <202107020053.Z9mjYXjf-lkp@intel.com> (raw) In-Reply-To: <20210628070657.7669-1-peng.fan@oss.nxp.com> [-- Attachment #1: Type: text/plain, Size: 6957 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-20210701] [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: arm-randconfig-s031-20210630 (attached as .config) compiler: arm-linux-gnueabi-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=arm 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:33: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem *to @@ got void *[assigned] ptr @@ drivers/remoteproc/remoteproc_elf_loader.c:219:33: sparse: expected void volatile [noderef] __iomem *to drivers/remoteproc/remoteproc_elf_loader.c:219:33: sparse: got void *[assigned] ptr >> drivers/remoteproc/remoteproc_elf_loader.c:219:33: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const *from @@ got void [noderef] __iomem * @@ drivers/remoteproc/remoteproc_elf_loader.c:219:33: sparse: expected void const *from drivers/remoteproc/remoteproc_elf_loader.c:219:33: 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: 34855 bytes --]
next prev parent reply other threads:[~2021-07-01 16:15 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 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 [this message] 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=202107020053.Z9mjYXjf-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: linkBe 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.