Re: [PATCH] ARM: supplementing IO accessors with 64 bit capability

[Will Deacon]

On Mon, Oct 27, 2014 at 10:14:41PM +0000, Mathieu Poirier wrote:
> On 27 October 2014 09:54, Will Deacon <will.deacon@xxxxxxx> wrote:
> > On Fri, Oct 24, 2014 at 05:16:34PM +0100, Catalin Marinas wrote:
> >> As I said, it's confusing. Anyway, you can go ahead and add the
> >> readq/writeq for ARMv6 and later, though it won't be guaranteed to have
> >> a 64-bit access, it depends on the bus.
> >
> > I'm really not comfortable with this... we don't make any guarantees for
> > 32-bit CPUs that a double-word access will be single-copy atomic for MMIO.
> > That means it could be subjected to things like reordering and merging,
> > which I think means that it depends on both the bus *and* the endpoint as to
> > whether or not this will work. Worse still, the endpoint could decide to
> > return a SLVERR, which would appear as an external abort.
> 
> I agree on all of the point you bring up.  The person using these
> should know their architecture and the target endpoint support this
> kind of access.  If they don't then a problem will show up pretty
> quickly.

That goes against the I/O abstractions provided by the kernel to allow for
portable device drivers. readq/writeq *must* have some portable semantics
and I don't think that we should implement them on a best-effort basis
in io.h.

> >
> > Is it not possible to use 32-bit MMIO accesses for this driver?
> 
> Sure it is but we wouldn't be using the HW to it's full capability.
> Another solution is to move the accessors to the driver itself where
> nobody else in the 32 bit world will have access to them.  Russell,
> what you're opinion on that?

FWIW, I'd much prefer that, but I'd be interested to know how much of a
a couple of {read,write}l_relaxed operations really cost you by
comparison.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/