From: kbuild test robot <lkp@intel.com>
To: Brett Grandbois <brett.grandbois@opengear.com>
Cc: kbuild-all@01.org, Marek Vasut <marek.vasut@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Boris Brezillon <boris.brezillon@bootlin.com>,
Richard Weinberger <richard@nod.at>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: Add support for SPI boot flash access for AMD Family 16h
Date: Fri, 12 Oct 2018 10:46:56 +0800 [thread overview]
Message-ID: <201810121014.FUgu6nuT%fengguang.wu@intel.com> (raw)
In-Reply-To: <20181011035220.22343-1-brett.grandbois@opengear.com>
[-- Attachment #1: Type: text/plain, Size: 3910 bytes --]
Hi Brett,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on mtd/spi-nor/next]
[also build test WARNING on v4.19-rc7 next-20181011]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Brett-Grandbois/mtd-spi-nor-Add-support-for-SPI-boot-flash-access-for-AMD-Family-16h/20181012-085348
base: git://git.infradead.org/linux-mtd.git spi-nor/next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
>> drivers/mtd/spi-nor/amd-spirom.c:355:22: warning: incorrect type in assignment (different base types)
drivers/mtd/spi-nor/amd-spirom.c:355:22: expected unsigned int [unsigned] [usertype] addr
drivers/mtd/spi-nor/amd-spirom.c:355:22: got restricted __be32 [usertype] <noident>
drivers/mtd/spi-nor/amd-spirom.c:396:14: warning: incorrect type in assignment (different base types)
drivers/mtd/spi-nor/amd-spirom.c:396:14: expected unsigned int [unsigned] [usertype] addr
drivers/mtd/spi-nor/amd-spirom.c:396:14: got restricted __be32 [usertype] <noident>
vim +355 drivers/mtd/spi-nor/amd-spirom.c
296
297 /*
298 * fallback read op based on explicit read command
299 * ideally the HW io will be used but this needs to be available if it's not
300 * strapped, can't get the resources, etc.
301 * spi_nor_read() will loop on the actual bytes read so we can just limit
302 * ourselves to the 64-byte FIFO size.
303 */
304 static ssize_t amd_spirom_read(struct spi_nor *nor, loff_t from,
305 size_t len, u_char *read_buf)
306 {
307 struct amd_spirom *spirom = nor->priv;
308 u32 *pbuf32;
309 size_t head;
310 size_t tail;
311 size_t left;
312 ssize_t rc;
313 size_t cur;
314 u8 *p_addr;
315 u8 rd_len;
316 size_t i;
317 u32 addr;
318
319 dev_dbg(nor->dev, "read: from: %lld len: %zu\n", from, len);
320
321 /*
322 * We only allow READ in the HWCAPS so most read operations should come
323 * with that opcode. However, the SPI-NOR layer can swap out the read
324 * opcode with something else (i.e. Read SFDP) which must be handled via
325 * alt command and not the ROM IO
326 */
327 if (spirom->rom && (nor->read_opcode == SPINOR_OP_READ)) {
328 /*
329 * no need for status/busy as the HW controller will deal with
330 * that, but memcpy_fromio can make out-of-order fetches so need
331 * to do this explicitly
332 */
333 left = len;
334 head = from & 3;
335 left -= head;
336 tail = left & 3;
337 left -= tail;
338 cur = 0;
339
340 for (i = 0; i < head; i++, cur++)
341 read_buf[cur] = ioread8(spirom->rom + from + cur);
342
343 pbuf32 = (u32 *)(read_buf + cur);
344 left /= 4;
345
346 for (i = 0; i < left; i++, cur += 4, pbuf32++)
347 *pbuf32 = ioread32(spirom->rom + from + cur);
348
349 for (i = 0; i < tail; i++, cur++)
350 read_buf[cur] = ioread8(spirom->rom + from + cur);
351
352 rc = (ssize_t)len;
353 } else {
354
> 355 addr = cpu_to_be32((u32)(from));
356 p_addr = (u8 *)(&addr);
357
358 rd_len = len > 64 ? 64 : (u8)len;
359
360 if (nor->addr_width == 3)
361 p_addr++;
362
363 rc = amd_spirom_reg_xfer(spirom, nor->read_opcode, rd_len,
364 nor->addr_width, read_buf, p_addr);
365
366 if (!rc)
367 rc = (ssize_t)rd_len;
368 }
369
370 return rc;
371 }
372
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 65709 bytes --]
prev parent reply other threads:[~2018-10-12 2:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 3:52 [PATCH] mtd: spi-nor: Add support for SPI boot flash access for AMD Family 16h Brett Grandbois
2018-10-12 2:46 ` kbuild test robot [this message]
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=201810121014.FUgu6nuT%fengguang.wu@intel.com \
--to=lkp@intel.com \
--cc=boris.brezillon@bootlin.com \
--cc=brett.grandbois@opengear.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=kbuild-all@01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).