From: Andi Kleen <[EMAIL PROTECTED]>
Date: 08 Aug 2007 14:38:10 +0200
> Jeff Garzik <[EMAIL PROTECTED]> writes:
> > > + val, reg_index, addr, addr+4); */
> > > + writel(cpu_to_le32(reg_index), addr);
> > > + writel(cpu_to_le32(val),(u8 *)addr + 4);
> >
> > wrong -- endian conversi
Michael Buesch wrote:
On Wednesday 08 August 2007 18:59:08 Jeff Garzik wrote:
Michael Buesch wrote:
writel doesn't guarantee flushing either.
readl does.
Not quite -- there are multiple kinds of flushing. You're thinking
about flushing across PCI bridges, which is correct, but you also have
On Wednesday 08 August 2007 18:59:08 Jeff Garzik wrote:
> Michael Buesch wrote:
> > writel doesn't guarantee flushing either.
> > readl does.
>
>
> Not quite -- there are multiple kinds of flushing. You're thinking
> about flushing across PCI bridges, which is correct, but you also have
> CPU
Michael Buesch wrote:
writel doesn't guarantee flushing either.
readl does.
Not quite -- there are multiple kinds of flushing. You're thinking
about flushing across PCI bridges, which is correct, but you also have
CPU write posting and CPU write ordering and such.
Without taking all that
On Wed, Aug 08, 2007 at 09:46:16AM -0700, Roland Dreier wrote:
>
> Not mmiowb() -- that is for ordering between CPUs, eg on systems like
> Altix where PCI transactions might get reordered in the system fabric
> before reaching the PCI bus.
>
Yes, that's right. This is a continual source of
> The barrier/ordering issue however might be a critical thing,
> when using __raw_XXX. So one must always mmiowb() after such a write.
Not mmiowb() -- that is for ordering between CPUs, eg on systems like
Altix where PCI transactions might get reordered in the system fabric
before reaching the
On Wednesday 08 August 2007 18:33:24 Jeff Garzik wrote:
> Michael Buesch wrote:
> > On Wednesday 08 August 2007 18:18:31 Roland Dreier wrote:
> >> > But there are indeed a few cases that look wrong.
> >>
> >> yes...
> >>
> >> > arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val),
> >
> Most likely the __raw_writel variant is portable, but I am not
> sure. Anybody sure?
Yes, it should be fine. I use that construct in a few IB drivers.
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
Michael Buesch wrote:
On Wednesday 08 August 2007 18:18:31 Roland Dreier wrote:
> But there are indeed a few cases that look wrong.
yes...
> arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
eg this almost certainly wants to be
writel(swab32(val), target);
On Wednesday 08 August 2007 18:18:31 Roland Dreier wrote:
> > But there are indeed a few cases that look wrong.
>
> yes...
>
> > arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
>
> eg this almost certainly wants to be
>
> writel(swab32(val), target);
>
> or so
Roland Dreier wrote:
> But there are indeed a few cases that look wrong.
yes...
> arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
eg this almost certainly wants to be
writel(swab32(val), target);
or something equivalent like
__raw_writel(cpu_to_be
Andi Kleen wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
+ val, reg_index, addr, addr+4); */
+ writel(cpu_to_le32(reg_index), addr);
+ writel(cpu_to_le32(val),(u8 *)addr + 4);
wrong -- endian conversion macros not needed with writel()
Are you sure?
Yes.
r
> But there are indeed a few cases that look wrong.
yes...
> arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
eg this almost certainly wants to be
writel(swab32(val), target);
or something equivalent like
__raw_writel(cpu_to_be32(val), target);
On Wednesday 08 August 2007 15:48:25 Michael Buesch wrote:
> > However if that's true then there are quite some drivers wrong:
> >
> > % grep -r write[bwl]\(cpu_to * | wc -l
> > 57
>
> Yeah, seems so.
Most of them seem to be
__raw_writew(cpu_toXX(...
which I think might be valid.
But there a
On Wednesday 08 August 2007 15:38:50 Andi Kleen wrote:
> On Wed, Aug 08, 2007 at 03:28:33PM +0200, Michael Buesch wrote:
> > On Wednesday 08 August 2007 15:08:28 Andi Kleen wrote:
> > > On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
> > > > On Wednesday 08 August 2007 14:55:11 Andi
On Wed, Aug 08, 2007 at 03:28:33PM +0200, Michael Buesch wrote:
> On Wednesday 08 August 2007 15:08:28 Andi Kleen wrote:
> > On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
> > > On Wednesday 08 August 2007 14:55:11 Andi Kleen wrote:
> > > > On Wed, Aug 08, 2007 at 01:50:35PM +0200,
On Wednesday 08 August 2007 15:08:28 Andi Kleen wrote:
> On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
> > On Wednesday 08 August 2007 14:55:11 Andi Kleen wrote:
> > > On Wed, Aug 08, 2007 at 01:50:35PM +0200, Michael Buesch wrote:
> > > > On Wednesday 08 August 2007 14:38:10 Andi
On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
> On Wednesday 08 August 2007 14:55:11 Andi Kleen wrote:
> > On Wed, Aug 08, 2007 at 01:50:35PM +0200, Michael Buesch wrote:
> > > On Wednesday 08 August 2007 14:38:10 Andi Kleen wrote:
> > > > Jeff Garzik <[EMAIL PROTECTED]> writes:
>
On Wednesday 08 August 2007 14:55:11 Andi Kleen wrote:
> On Wed, Aug 08, 2007 at 01:50:35PM +0200, Michael Buesch wrote:
> > On Wednesday 08 August 2007 14:38:10 Andi Kleen wrote:
> > > Jeff Garzik <[EMAIL PROTECTED]> writes:
> > > > > + val, reg_index, addr, addr+4); */
> > > >
On Wed, Aug 08, 2007 at 01:50:35PM +0200, Michael Buesch wrote:
> On Wednesday 08 August 2007 14:38:10 Andi Kleen wrote:
> > Jeff Garzik <[EMAIL PROTECTED]> writes:
> > > > + val, reg_index, addr, addr+4); */
> > > > + writel(cpu_to_le32(reg_index), addr);
> > > > +
On Wednesday 08 August 2007 14:38:10 Andi Kleen wrote:
> Jeff Garzik <[EMAIL PROTECTED]> writes:
> > > + val, reg_index, addr, addr+4); */
> > > + writel(cpu_to_le32(reg_index), addr);
> > > + writel(cpu_to_le32(val),(u8 *)addr + 4);
> >
> > wrong -- endian conversion macros not ne
Jeff Garzik <[EMAIL PROTECTED]> writes:
> > + val, reg_index, addr, addr+4); */
> > + writel(cpu_to_le32(reg_index), addr);
> > + writel(cpu_to_le32(val),(u8 *)addr + 4);
>
> wrong -- endian conversion macros not needed with writel()
Are you sure? I don't think that's true.
[EMAIL PROTECTED] wrote:
+#ifndef PCI_VENDOR_ID_NETEFFECT/* not in pci.ids yet */
+#define PCI_VENDOR_ID_NETEFFECT 0x1678
this should be part of your patch
+#define PCI_DEVICE_ID_NETEFFECT_NE020 0x0100
no need for a #define at all, just use the hex number if the ONLY place
its use
Main include file for device structures and defines
Signed-off-by: Glenn Grundstrom <[EMAIL PROTECTED]>
---
diff -Nurp NULL ofa_kernel-1.2/drivers/infiniband/hw/nes/nes.h
--- NULL1969-12-31 18:00:00.0 -0600
+++ ofa_kernel-1.2/drivers/infiniband/hw/nes/nes.h 2007-08-06
20:09:0
24 matches
Mail list logo
