[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 12 Dec 2010 14:47:50 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Will Newton <will.newton@...il.com>
Cc: Chris Ball <cjb@...top.org>, Matt Fleming <matt@...sole-pimps.org>,
linux-mmc@...r.kernel.org,
Linux Kernel list <linux-kernel@...r.kernel.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] dw_mmc: Add Synopsys DesignWare mmc host driver.
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@....linux.org.uk> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists