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
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
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
Benjamin Herrenschmidt wrote:
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
On Mon, 6 Nov 2006, Jeff Garzik wrote:
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
Heartily agreed. MUCH better than adding unrelated #if defined() stuff,
whether arch-related or otherwise.
Linus
-
To unsubscribe from this
On Mon, 2006-11-06 at 01:37 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Jeff Garzik wrote:
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
Heartily agreed. MUCH better than adding unrelated #if defined() stuff,
whether arch-related
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My arch guy side screams at the idea, but if,
indeed, drivers generally cope fine with it, I suppose that's ok.
Last I saw, that's how normal PCI
On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My arch guy side screams at the idea, but if,
indeed, drivers generally cope fine with
Benjamin Herrenschmidt wrote:
On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My arch guy side screams at the idea, but if,
indeed, drivers
On Mon, 2006-11-06 at 04:55 -0500, Jeff Garzik wrote:
Benjamin Herrenschmidt wrote:
On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My
atomic.
Ram
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Benjamin Herrenschmidt
Sent: Monday, November 06, 2006 1:57 AM
To: Jeff Garzik
Cc: Linus Torvalds; netdev@vger.kernel.org
Subject: Re: [PATCH] s2io ppc64 fix for readq/writeq
On Mon
On Mon, Nov 06, 2006 at 03:33:19PM -0500, Ramkrishna Vepa wrote:
The 64 bit io operation on the IA64 platform is a 64 bit transaction on
the pci bus and is optimal to leave it as such. I prefer Jeff's
suggestion -
guaranteeing that a good enough for drivers readq() and writeq() exist
on
For consistencies sake we really want to have readq() and writeq() available
on all platforms. I remember that some IB cards require it to actually
be a 64bit transactions, otherwise they have to do funny workarounds.
I think the best solution is to define ARCH_HAS_ATOMIC_READQ_WRITEQ
Generally the kernel code should write the two 32-bit chunks to the
memory-mapped region in order (low dword first), and let things take
care of themselves from there.
That's pretty much the implementation that -every- driver copies, when
they need readq/writeq to work on a 32-bit
-Original Message-
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Monday, November 06, 2006 12:55 PM
To: Christoph Hellwig
Cc: Ramkrishna Vepa; Benjamin Herrenschmidt; Jeff Garzik; Linus
Torvalds;
netdev@vger.kernel.org; [EMAIL PROTECTED]
Subject: Re: [PATCH] s2io ppc64 fix
The s2io driver is redefining it's own readq/writeq based on
readl/writel when the platform doesn't provide native ones. However, it
currently does so by testing #ifndef readq. While that works for now, we
are about to change ppc64 to use inline functions rather that macros for
all those IO
Benjamin Herrenschmidt wrote:
The s2io driver is redefining it's own readq/writeq based on
readl/writel when the platform doesn't provide native ones. However, it
currently does so by testing #ifndef readq. While that works for now, we
are about to change ppc64 to use inline functions rather
17 matches
Mail list logo
