All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: peng.fan@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 V5 2/8] remoteproc: add is_iomem to da_to_va
Date: Wed, 30 Dec 2020 23:14:29 +0800	[thread overview]
Message-ID: <202012302346.WgBmOSjv-lkp@intel.com> (raw)
In-Reply-To: <20201229033019.25899-3-peng.fan@nxp.com>

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

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.11-rc1 next-20201223]
[cannot apply to soc/for-next 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-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dea8dcf2a9fa8cc540136a6cd885c3beece16ec3
config: powerpc64-randconfig-s032-20201230 (attached as .config)
compiler: powerpc64-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-184-g1b896707-dirty
        # https://github.com/0day-ci/linux/commit/f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review peng-fan-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
        git checkout f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
        # 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=powerpc64 

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:61: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const volatile [noderef] __iomem *s @@     got unsigned char const [usertype] * @@
   drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse:     expected void const volatile [noderef] __iomem *s
   drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse:     got unsigned char const [usertype] *
>> drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void volatile [noderef] __iomem *a @@     got void * @@
   drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse:     expected void volatile [noderef] __iomem *a
   drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse:     got void *
--
>> drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const volatile [noderef] __iomem *s @@     got void *[assigned] ptr @@
   drivers/remoteproc/remoteproc_coredump.c:169:53: sparse:     expected void const volatile [noderef] __iomem *s
   drivers/remoteproc/remoteproc_coredump.c:169:53: sparse:     got void *[assigned] ptr

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_fromio(ptr, 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(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: 36269 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 V5 2/8] remoteproc: add is_iomem to da_to_va
Date: Wed, 30 Dec 2020 23:14:29 +0800	[thread overview]
Message-ID: <202012302346.WgBmOSjv-lkp@intel.com> (raw)
In-Reply-To: <20201229033019.25899-3-peng.fan@nxp.com>

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

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.11-rc1 next-20201223]
[cannot apply to soc/for-next 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-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dea8dcf2a9fa8cc540136a6cd885c3beece16ec3
config: powerpc64-randconfig-s032-20201230 (attached as .config)
compiler: powerpc64-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-184-g1b896707-dirty
        # https://github.com/0day-ci/linux/commit/f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review peng-fan-nxp-com/remoteproc-imx_rproc-support-iMX8MQ-M/20201229-110725
        git checkout f2054bc05d3b183ef0b0ff0b4c802ba53680a5af
        # 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=powerpc64 

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:61: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const volatile [noderef] __iomem *s @@     got unsigned char const [usertype] * @@
   drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse:     expected void const volatile [noderef] __iomem *s
   drivers/remoteproc/remoteproc_elf_loader.c:219:61: sparse:     got unsigned char const [usertype] *
>> drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void volatile [noderef] __iomem *a @@     got void * @@
   drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse:     expected void volatile [noderef] __iomem *a
   drivers/remoteproc/remoteproc_elf_loader.c:233:47: sparse:     got void *
--
>> drivers/remoteproc/remoteproc_coredump.c:169:53: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const volatile [noderef] __iomem *s @@     got void *[assigned] ptr @@
   drivers/remoteproc/remoteproc_coredump.c:169:53: sparse:     expected void const volatile [noderef] __iomem *s
   drivers/remoteproc/remoteproc_coredump.c:169:53: sparse:     got void *[assigned] ptr

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_fromio(ptr, 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(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: 36269 bytes --]

  reply	other threads:[~2020-12-30 15:15 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-29  3:30 [PATCH V5 0/8] remoteproc: imx_rproc: support iMX8MQ/M peng.fan
2020-12-29  3:30 ` peng.fan
2020-12-29  3:30 ` [PATCH V5 1/8] remoteproc: introduce is_iomem to rproc_mem_entry peng.fan
2020-12-29  3:30   ` peng.fan
2021-01-11 18:53   ` Mathieu Poirier
2021-01-11 18:53     ` Mathieu Poirier
2020-12-29  3:30 ` [PATCH V5 2/8] remoteproc: add is_iomem to da_to_va peng.fan
2020-12-29  3:30   ` peng.fan
2020-12-30 15:14   ` kernel test robot [this message]
2020-12-30 15:14     ` kernel test robot
2020-12-30 15:20   ` kernel test robot
2020-12-30 15:20     ` kernel test robot
2021-01-11 20:25   ` Mathieu Poirier
2021-01-11 20:25     ` Mathieu Poirier
2020-12-29  3:30 ` [PATCH V5 3/8] remoteproc: imx_rproc: correct err message peng.fan
2020-12-29  3:30   ` peng.fan
2021-01-11 20:35   ` Mathieu Poirier
2021-01-11 20:35     ` Mathieu Poirier
2021-01-11 20:44   ` Mathieu Poirier
2021-01-11 20:44     ` Mathieu Poirier
2020-12-29  3:30 ` [PATCH V5 4/8] remoteproc: imx_rproc: use devm_ioremap peng.fan
2020-12-29  3:30   ` peng.fan
2021-01-11 20:46   ` Mathieu Poirier
2021-01-11 20:46     ` Mathieu Poirier
2020-12-29  3:30 ` [PATCH V5 5/8] remoteproc: imx_rproc: add i.MX specific parse fw hook peng.fan
2020-12-29  3:30   ` peng.fan
2020-12-29  3:30 ` [PATCH V5 6/8] remoteproc: imx_rproc: support i.MX8MQ/M peng.fan
2020-12-29  3:30   ` peng.fan
2021-01-11 21:40   ` Mathieu Poirier
2021-01-11 21:40     ` Mathieu Poirier
2020-12-29  3:30 ` [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev regions peng.fan
2020-12-29  3:30   ` peng.fan
2021-01-11 21:50   ` Mathieu Poirier
2021-01-11 21:50     ` Mathieu Poirier
2021-01-12  9:41     ` Peng Fan
2021-01-12  9:41       ` Peng Fan
2021-01-12 18:46       ` Mathieu Poirier
2021-01-12 18:46         ` Mathieu Poirier
2021-01-13  2:19         ` Peng Fan
2021-01-13  2:19           ` Peng Fan
2021-01-13 16:17           ` Mathieu Poirier
2021-01-13 16:17             ` Mathieu Poirier
2021-01-14  9:52             ` Peng Fan
2021-01-14  9:52               ` Peng Fan
2021-01-14 17:10               ` Mathieu Poirier
2021-01-14 17:10                 ` Mathieu Poirier
2021-01-15  3:29                 ` Peng Fan
2021-01-15  3:29                   ` Peng Fan
2020-12-29  3:30 ` [PATCH V5 8/8] remoteproc: imx_proc: enable virtio/mailbox peng.fan
2020-12-29  3:30   ` peng.fan

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=202012302346.WgBmOSjv-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@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.