Re: [PATCH] x86: Remove readq()/writeq() on 32-bit

[Roland Dreier <rdreier@cisco.com>]

 > What caused 2c5643b1 was that right now we have ugly per driver
 > #defines and inlines for readq/writeq. See:

but 2c5643b1 doesn't fix that situation -- a portable driver still needs
the #defines for other 32-bit architectures.  And 2c5643b1 isn't really
a particularly good step towards rectifying the situation, since if
every 32-bit architecture follows suit and adds its own compatibility
versions, then we'll want someone to go through and unify them into a
generic implementation.  In other words removing the x86 private version
will be part of the work in getting to a final solution.

 > Atomicity of a 64-bit IO space access on 32-bit platforms, on an 
 > unknown-bitness transport (it might even be a 64-bit PCI device 
 > bridged over a 32-bit bridge) is obviously not guaranteed.

Yes, some platforms may not be able to give true atomicity.  eg 32-bit
PowerPC has no instructions that generate 64-bit cycles, even on the CPU
bus.  I do think the 32-bit PCI thing is a bit of a red herring, since
eg PCIe devices can rely on a 64-bit bus.

 > So trying to suggest that 64-bit readq/writeq when running on a 
 > 64-bit kernel is somehow atomic (or can be made atomic) is really 
 > wrong IMO. The 32-bit wrapper is simply the expression of how the 
 > CPU would do a 64-bit access even in 64-bit mode anyway [if the 
 > transport is 32-bit].

As far as I know, all 64-bit CPUs doing 64-bit accesses to a PCIe device
(eg the NIC driven by the niu driver) will generate 64-bit bus cycles.

The issue for me is that the benefit of having this compatibility define
is rather minimal, while the cost is potentially high: spending a long
time debugging platform-specific bugs -- the symptoms will not point
immediately to the IO define, of course.

 - R.