On Sun, Dec 12, 2010 at 02:31:40PM +0000, Will Newton wrote:
> On Sun, Dec 12, 2010 at 2:11 PM, Russell King - ARM Linux
> <linux@xxxxxxxxxxxxxxxx> wrote:
> > Maybe invent CONFIG_HAVE_MMIO_64BIT which architectures can select as
> > appropriate?
>
> Wouldn't it be simpler to have a fallback readq/writeq implementation
> like the below?
>
> static inline u64 __raw_readq(const volatile void __iomem *addr)
> {
> return *(const volatile u64 __force *) addr;
> }
>
> It won't break any existing hardware (if your SoC bus does not support
> 64bit accesses you are unlikely to have peripherals that require it)
> and would avoid a number of #ifdefs and/or Kconfig dependencies.
Firstly, why, then, are we discussing fixing dw_mmc.c so it builds on ARM?
Just make its configuration option conditional on !ARM and that specific
problem is solved.
Secondly, providing such a fallback implementation is asking people to
use it, and they'll expect it to work. Their driver will build and
apparantly work, but because the compiler will use ldrd/strd for it, a
perfectly timed interrupt could cause data corruption.
It's unsafe to provide 64-bit MMIO operations on hardware which is unable
to perform 64-bit MMIO atomically - it will lead to really subtle driver
bugs.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
