linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Logan Gunthorpe <logang@deltatee.com>
To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-ntb@googlegroups.com, linux-crypto@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
	"Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	"Logan Gunthorpe" <logang@deltatee.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Philippe Ombredanne" <pombredanne@nexb.com>,
	"Kate Stewart" <kstewart@linuxfoundation.org>,
	"Luc Van Oostenryck" <luc.vanoostenryck@gmail.com>
Subject: [PATCH v13 02/10] iomap: Fix sparse endian check warnings
Date: Wed, 21 Mar 2018 10:37:37 -0600	[thread overview]
Message-ID: <20180321163745.12286-3-logang@deltatee.com> (raw)
In-Reply-To: <20180321163745.12286-1-logang@deltatee.com>

Newer version of sparse produce a few warnings of the form:

lib/iomap.c:84:9: warning: cast to restricted __be16

when run with:

make C=2 CF=-D__CHECK_ENDIAN__

(The kbuild robot has recently started running such checks)

The warning is not valid because the __raw_readX() and __raw_writeX()
functions have an endianess determined by the semantics of whichever
register they are operating on (which is intern dependant on the address
passed to the function).

In the iomap case, the register being operated on is known,
semantically, to be Big Endian when an ioXXbe() function is used
by the caller. These functions wrap a raw read or write function
in an endianness conversion function.

Sparse enforces that all values that aren't in CPU endianness
be marked with types like __be16 and similar and said types cannot
be mixed with other types. However, per above, the raw functions
cannot be marked as such seeing the endianness is indeterminate.
Thus, the output of __raw_readX() and the input of __raw_writeX()
must be cast with the __force keyword to supress the invalid warning.

Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
 lib/iomap.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/iomap.c b/lib/iomap.c
index be120c13d6cc..44645c4b516c 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -65,8 +65,8 @@ static void bad_io_access(unsigned long port, const char *access)
 #endif
 
 #ifndef mmio_read16be
-#define mmio_read16be(addr) be16_to_cpu(__raw_readw(addr))
-#define mmio_read32be(addr) be32_to_cpu(__raw_readl(addr))
+#define mmio_read16be(addr) be16_to_cpu((__be16 __force)__raw_readw(addr))
+#define mmio_read32be(addr) be32_to_cpu((__be32 __force)__raw_readl(addr))
 #endif
 
 unsigned int ioread8(void __iomem *addr)
@@ -106,8 +106,8 @@ EXPORT_SYMBOL(ioread32be);
 #endif
 
 #ifndef mmio_write16be
-#define mmio_write16be(val,port) __raw_writew(cpu_to_be16(val),port)
-#define mmio_write32be(val,port) __raw_writel(cpu_to_be32(val),port)
+#define mmio_write16be(val,port) __raw_writew((u16 __force)cpu_to_be16(val),port)
+#define mmio_write32be(val,port) __raw_writel((u32 __force)cpu_to_be32(val),port)
 #endif
 
 void iowrite8(u8 val, void __iomem *addr)
-- 
2.11.0

  parent reply	other threads:[~2018-03-21 16:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 16:37 [PATCH v13 00/10] Add io{read|write}64 to io-64-atomic headers Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 01/10] iomap: Use correct endian conversion function in mmio_writeXXbe Logan Gunthorpe
2018-03-21 17:28   ` Luc Van Oostenryck
2018-03-26 10:53   ` Arnd Bergmann
2018-03-26 16:21     ` Logan Gunthorpe
2018-03-26 19:50       ` Arnd Bergmann
2018-03-26 20:33         ` Logan Gunthorpe
2018-03-21 16:37 ` Logan Gunthorpe [this message]
2018-03-21 16:37 ` [PATCH v13 03/10] parisc: iomap: introduce io{read|write}64 Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 04/10] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 05/10] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo} Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 06/10] iomap: " Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 07/10] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 08/10] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 09/10] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64 Logan Gunthorpe
2018-03-21 16:37 ` [PATCH v13 10/10] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header Logan Gunthorpe
2018-03-21 17:40 ` [PATCH v13 00/10] Add io{read|write}64 to io-64-atomic headers Andy Shevchenko
2018-03-21 19:47   ` Logan Gunthorpe

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=20180321163745.12286-3-logang@deltatee.com \
    --to=logang@deltatee.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=horia.geanta@nxp.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntb@googlegroups.com \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=pombredanne@nexb.com \
    --cc=tglx@linutronix.de \
    /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).