On 2018-04-06 06:19, Arnd Bergmann wrote:
On Thu, Apr 5, 2018 at 3:09 PM, Sinan Kaya <okaya@xxxxxxxxxxxxxx>
wrote:
Getting ready to harden readX()/writeX() and inX()/outX() semantics
for the
generic implementation.
Defining two set of macros as __io_br() and __io_ar() to indicate
actions
to be taken before and after MMIO read.
Defining two set of macros as __io_bw() and __io_aw() to indicate
actions
to be taken before and after MMIO write.
Defining two set of macros as __io_pbw() and __io_paw() to indicate
actions
to be taken before and after Port IO write.
Defining two set of macros as __io_pbr() and __io_par() to indicate
actions
to be taken before and after Port IO read.
If rmb() is available for the architecture, prefer rmb() as the
default
implementation of __io_ar()/__io_par().
If wmb() is available for the architecture, prefer wmb() as the
default
implementation of __io_bw()/__io_pbw().
Signed-off-by: Sinan Kaya <okaya@xxxxxxxxxxxxxx>
I've applied the series to my asm-generic tree now, I will give it a
few days
in linux-next to see if any obvious regressions happen, and then send
a pull request.
Checking the list of architectures that are affected by this, I see
h8300, microblaze, nios2, openrisc, s390, sparc, um, unicore32,
and xtensa, all of which use asm-generic/io.h without overriding
the default readl/writel.
I would guess that at least s390 doesn't need the barriers
(maintainers on Cc now), but there may be others that want to
override the new barriers with weaker ones where an MMIO
access is guaranteed to serialize against DMA, or where
a specialized barrier for this case exists.
Looking over the asm-generic implementation once more now,
I wonder if we should change the relaxed accessors to not have
any barriers (back to the version before your series) rather than
defaulting them to having the same barriers as the regular
readl/writel.
I can do a follow up patch. You want to map them to raw api without any
barriers as before. Right?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
