From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: linux-arch@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Stephen Bates <sbates@raithlin.com>,
linux-crypto@vger.kernel.org, linux-alpha@vger.kernel.org,
linux-ntb@googlegroups.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available
Date: Thu, 22 Jun 2017 21:14:31 +0100 [thread overview]
Message-ID: <20170622211431.14270378@alans-desktop> (raw)
In-Reply-To: <20170622164817.25515-4-logang@deltatee.com>
On Thu, 22 Jun 2017 10:48:13 -0600
Logan Gunthorpe <logang@deltatee.com> wrote:
> Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y
> and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not
> universally available, it makes them unusable for driver developers.
> This leads to ugly hacks such as those at the top of
>
> drivers/ntb/hw/intel/ntb_hw_intel.c
>
> This patch adds fallback implementations for when CONFIG_64BIT and
> CONFIG_GENERIC_IOMAP are not set. These functions use two io32 based
> calls to complete the operation.
>
> Note, we do not use the volatile keyword in these functions like the
> others in the same file. It is necessary to avoid a compiler warning
> on arm.
This is a really really bad idea as per the Alpha comment.
ioread64 and iowrite64 generate a single 64bit bus transaction. There is
hardware where mmio operations have side effects so simply using a pair
of 32bit operations blindly does not work (consider something as trivial
as reading a 64bit performance counter or incrementing pointer).
If a platform doesn't support 64bit I/O operations from the CPU then you
either need to use some kind of platform/architecture specific interface
if present or accept you don't have one.
It's not safe to split it. Possibly for some use cases you could add an
ioread64_maysplit()
but you cannot blindly break ioread64/write64() and expect it to
magically allow you to use drivers that depend upon it.
What btw is the actual ARM compiler warning ? Is the compiler also trying
to tell you it's a bad idea ?
Alan
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-ntb@googlegroups.com, linux-alpha@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-crypto@vger.kernel.org,
dri-devel@lists.freedesktop.org, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Stephen Bates <sbates@raithlin.com>
Subject: Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available
Date: Thu, 22 Jun 2017 21:14:31 +0100 [thread overview]
Message-ID: <20170622211431.14270378@alans-desktop> (raw)
Message-ID: <20170622201431._xulPp8bBIU5V75TLFgiDJtWkQNdlhpkZcGBgEHjEfg@z> (raw)
In-Reply-To: <20170622164817.25515-4-logang@deltatee.com>
On Thu, 22 Jun 2017 10:48:13 -0600
Logan Gunthorpe <logang@deltatee.com> wrote:
> Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y
> and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not
> universally available, it makes them unusable for driver developers.
> This leads to ugly hacks such as those at the top of
>
> drivers/ntb/hw/intel/ntb_hw_intel.c
>
> This patch adds fallback implementations for when CONFIG_64BIT and
> CONFIG_GENERIC_IOMAP are not set. These functions use two io32 based
> calls to complete the operation.
>
> Note, we do not use the volatile keyword in these functions like the
> others in the same file. It is necessary to avoid a compiler warning
> on arm.
This is a really really bad idea as per the Alpha comment.
ioread64 and iowrite64 generate a single 64bit bus transaction. There is
hardware where mmio operations have side effects so simply using a pair
of 32bit operations blindly does not work (consider something as trivial
as reading a 64bit performance counter or incrementing pointer).
If a platform doesn't support 64bit I/O operations from the CPU then you
either need to use some kind of platform/architecture specific interface
if present or accept you don't have one.
It's not safe to split it. Possibly for some use cases you could add an
ioread64_maysplit()
but you cannot blindly break ioread64/write64() and expect it to
magically allow you to use drivers that depend upon it.
What btw is the actual ARM compiler warning ? Is the compiler also trying
to tell you it's a bad idea ?
Alan
next prev parent reply other threads:[~2017-06-22 20:14 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 16:48 [PATCH 0/7] cleanup issues with io{read|write}64 Logan Gunthorpe
2017-06-22 16:48 ` [PATCH 1/7] drm/tilcdc: don't use volatile with iowrite64 Logan Gunthorpe
2017-06-26 8:54 ` Jyri Sarha
2017-06-26 8:54 ` Jyri Sarha
2017-06-26 8:54 ` Jyri Sarha
2017-06-26 8:54 ` Jyri Sarha
2017-06-22 16:48 ` [PATCH 2/7] iomap: implement ioread64 and iowrite64 Logan Gunthorpe
2017-06-26 20:43 ` Arnd Bergmann
2017-06-26 21:25 ` Logan Gunthorpe
2017-06-22 16:48 ` [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available Logan Gunthorpe
2017-06-22 20:14 ` Alan Cox [this message]
2017-06-22 20:14 ` Alan Cox
2017-06-22 20:24 ` Logan Gunthorpe
2017-06-22 20:36 ` Alan Cox
2017-06-22 20:36 ` Alan Cox
2017-06-22 20:38 ` Logan Gunthorpe
2017-06-22 16:48 ` [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations Logan Gunthorpe
2017-06-22 17:29 ` Stephen Bates
2017-06-22 17:29 ` Stephen Bates
2017-06-22 17:30 ` Logan Gunthorpe
2017-06-22 20:08 ` Alan Cox
2017-06-22 20:09 ` Logan Gunthorpe
2017-06-22 21:03 ` Arnd Bergmann
2017-06-22 21:03 ` Arnd Bergmann
2017-06-22 21:10 ` Logan Gunthorpe
2017-06-22 21:20 ` Richard Henderson
2017-06-22 16:48 ` [PATCH 5/7] ntb: ntb_hw_intel: remove ioread64 and iowrite64 hacks Logan Gunthorpe
2017-06-22 17:17 ` Jiang, Dave
2017-06-22 17:17 ` Jiang, Dave
2017-06-22 17:17 ` Jiang, Dave
2017-06-22 16:48 ` [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64 Logan Gunthorpe
2017-06-26 8:55 ` Jyri Sarha
2017-06-26 8:55 ` Jyri Sarha
2017-06-26 8:55 ` Jyri Sarha
2017-06-26 8:55 ` Jyri Sarha
2017-06-26 16:26 ` Logan Gunthorpe
2017-06-27 20:40 ` Arnd Bergmann
2017-06-22 16:48 ` [PATCH 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64 Logan Gunthorpe
2017-06-22 16:48 ` Logan Gunthorpe
2017-06-23 6:51 ` Horia Geantă
2017-06-23 6:51 ` Horia Geantă
2017-06-23 6:51 ` Horia Geantă
2017-06-23 17:59 ` Logan Gunthorpe
2017-06-23 17:59 ` Logan Gunthorpe
2017-06-23 17:59 ` Logan Gunthorpe
2017-06-24 11:57 ` [PATCH v2 " Horia Geantă
2017-06-24 11:57 ` Horia Geantă
2017-06-24 15:13 ` [PATCH] alpha: provide ioread64 and iowrite64 implementations Richard Henderson
2017-06-24 15:19 ` Logan Gunthorpe
2017-06-24 15:25 ` Richard Henderson
2017-06-24 15:32 ` Logan Gunthorpe
2017-06-24 16:14 ` Richard Henderson
2017-06-24 17:17 ` 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=20170622211431.14270378@alans-desktop \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-alpha@vger.kernel.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=linuxppc-dev@lists.ozlabs.org \
--cc=logang@deltatee.com \
--cc=sbates@raithlin.com \
/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.