Benjamin Herrenschmidt wrote:
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
That's ugly too imho but I suppose I can do it :-)
I generally think it's a bug in the kernel-wide API, if use of said API
requires arch-specific ifdefs.
Yes. I agree. In that specific case, I suppose what you propose is the
least ugly of the solutions. HAVE_ARCH_* is pretty much out of fascion
(and I tend to agree with Linus that it's not pretty anyway).
Actually, I tend to think in that specific case that the driver defining
something called readq and writeq based on a pair of readl's and
writel's is fairly bogus though.
Or maybe the problem could be solved another way, by guaranteeing that a
"good enough for drivers" readq() and writeq() exist on all platforms,
even 32-bit platforms where the operation isn't inherently atomic.
I'd rather not provide readq/writeq if they aren't atomic.
This is why I said "good enough for drivers". This is _key_.
I have run into several [PCI] devices with 64-bit registers, and
__none__ of them had requirements such that the Linux platform code
-must- provide an atomic readq/writeq. Probably because everybody wants
to support 32-bit platforms with their devices.
What you call "fairly bogus" is precisely what drivers need. These
devices with 64-bit registers just don't need the atomicity that arch
developers harp about :)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
