Steve Wise wrote:
It passes sparse with only a few warnings about calling memset() with a
size > 10.
You need to pass in CF=-D__CHECK_ENDIAN__ too, on the kernel build
command line. Otherwise, the endianness annotations aren't turned on in
the kernel headers, and you get this nice false
Steve Wise wrote:
T3 WQE and CQE structures, defines, etc...
I notice that none of the fields in these structs seem to be
endianness-annotated, but that there's a lot of cpu_to_be64 and so on
being used to frob values into them. Please make sure that the driver
passes a sparse check, which
Steve Wise wrote:
+static void release_tid(struct t3cdev *tdev, u32 hwtid, struct sk_buff *skb)
+{
+ struct cpl_tid_release *req;
+
+ skb = get_skb(skb, sizeof *req, GFP_KERNEL);
+ if (!skb) {
+ return;
+ }
Style micronit: no curlies for single-statement b
Steve Wise wrote:
+static inline void *vzmalloc(int size)
+{
+ void *p = vmalloc(size);
+ memset(p, 0, size);
+ return p;
+}
This isn't checking the return value from vmalloc.
Also, we could do with a generic vzalloc and vcalloc, just as we now
have kzalloc and kcalloc. Th
On Fri, 2006-07-07 at 08:37 +1000, Benjamin Herrenschmidt wrote:
> > +int ipath_unordered_wc(void)
> > +{
> > + return 1;
> > +}
>
> How is the above providing any kind of serialisation ?
It's not intended to; it tells the *caller* whether to do it.
http://vger.kernel.org/majordomo-in
On Fri, 2006-06-30 at 19:31 +0300, Michael S. Tsirkin wrote:
> OK, next week I'll put these into my tree, too.
Thanks. The first 37 are in -mm; the last two you can drop until I sort
them out.
http://vger.kernel.org/majordomo-info.html
On Thu, 2006-06-29 at 15:03 -0700, David Miller wrote:
> I'm not good with names :-)
Heh. I'll call it memcpy_nc for now, then, and people can retch all
over the name as they please when I submit a more suitably generic
patch.
> Note that there also might be cases where using such a memcpy
> va
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r e43b4df874a9 -r 125471ee6c68 drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.cThu Jun 29 14:33:25
2006 -0700
+++ b/driv
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 081142011371 -r ac81d2563bba drivers/infiniband/hw/ipath/ipath_mr.c
--- a/drivers/infiniband/hw/ipath/ipath_mr.cThu Jun 29 14:33:25 2006 -0700
+++ b/drivers/in
We must increment uaddr by size we are reading or writing, since it's
passed as a char *, not a pointer to the appropriate size.
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 8fbb5d71823a -r a7c1ad1e090b drive
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 8f08597cacd2 -r 081142011371 drivers/infiniband/hw/ipath/ipath_qp.c
--- a/drivers/infiniband/hw/ipath/ipath_qp.cThu Jun 29 14:33:25 2006 -0700
+++ b/drivers/in
scheduled tail register update, that we'll process the
"extra" packet that lost the interrupt because we cleared it just as it
was about to arrive.
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 1a43
AIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 2a721e1f490b -r c22b6c244d5d drivers/infiniband/hw/ipath/Makefile
--- a/drivers/infiniband/hw/ipath/Makefile Thu Jun 29 14:33:26 2006 -0700
+++ b/drivers/infiniband/hw/ipath/Makefile Thu Jun 29 14:33:26 20
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 28e3d8204fdb -r addf90abc724 drivers/infiniband/hw/ipath/ipath_mad.c
--- a/drivers/infiniband/hw/ipath/ipath_mad.c Fri Jun 23 22:47:27 2006 +0700
+++ b/drivers/in
o the
address registers for the closing port, we point it at a dummy memory.
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r a7c1ad1e090b -r b6ebaf2dd2fd drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/h
These limits are somewhat artificial in that we don't actually have any
device limits. However, the verbs layer expects that such limits exist
and are enforced, so we make up arbitrary (but sensible) limits.
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r a94e9f9c9c23 -r e43b4df874a9 drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.cThu Jun 29 14:33:25
2006 -0700
+++ b/driv
The two arrays only had space for 4 units.
Also changed from ipath_set_sps_lid() to ipath_set_lid(); the sps
was leftover.
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 1bef8244297a -r 3ceb73f8bde0 drivers/in
The receive work queue size should be ignored if the QP is created
to use a shared receive queue according to the IB spec.
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 9b423c45af8b -r 31c382d8210a drivers/in
This is not a DMA target, so no need to use dma_alloc_coherent on it.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 9d943b828776 -r 9c072f8e7e68 drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.cThu Jun 29 14:33:25
2006
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 811021b6c112 -r 8e39364c2402 drivers/infiniband/hw/ipath/ipath_ud.c
--- a/drivers/infiniband/hw/ipath/ipath_ud.cThu Jun 29 14:33:26 2006 -0700
+++ b/drivers/in
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 600ceb6aeb8c -r 8f08597cacd2 drivers/infiniband/hw/ipath/ipath_kernel.h
--- a/drivers/infiniband/hw/ipath/ipath_kernel.hThu Jun 29 14:33:25
2006 -0700
+++ b/driv
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 1e1f3da0e78d -r 21d5d64750ac drivers/infiniband/hw/ipath/ipath_layer.c
--- a/drivers/infiniband/hw/ipath/ipath_layer.c Thu Jun 29 14:33:25 2006 -0700
+++ b/drivers/in
The tail register read became redundant as the result of earlier receive
interrupt bug fixes.
Drop another unneeded register read.
And another line that got duplicated.
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r b6ebaf2dd2fd -r 9b423c45af8b
drivers/infiniband/hw/ipath/ipath_user_pages.c
--- a/drivers/infiniband/hw/ipath/ipath_user_pages.cThu Jun 29 14:33:26
2006 -0700
+++ b/d
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r c93c2b42d279 -r e4f29a4e0c0f drivers/infiniband/hw/ipath/ipath_rc.c
--- a/drivers/infiniband/hw/ipath/ipath_rc.cThu Jun 29 14:33:25 2006 -0700
+++ b/drivers/in
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r ebf646d10db0 -r c93c2b42d279 drivers/infiniband/hw/ipath/ipath_rc.c
--- a/drivers/infiniband/hw/ipath/ipath_rc.cThu Jun 29 14:33:25 2006 -0700
+++ b/drivers/in
The mb() prevents the compiler from reordering on this function, with some
versions
of gcc and -Os optimization. The result is random failures in the EEPROM read
without this change.
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTEC
There is no longer a /dev/ipath_diag file; instead, there's
/dev/ipath_diag0, 1, etc.
It's still not possible to have diags run on more than one unit at a time,
but that's easy to fix at some point.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r e4f29a4e0c
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r ac81d2563bba -r 160e5cf91761
drivers/infiniband/hw/ipath/ipath_init_chip.c
--- a/drivers/infiniband/hw/ipath/ipath_init_chip.c Thu Jun 29 14:33:25
2006 -0700
+++ b/d
keep up better with the sender, resulting
in many fewer dropped packets. We use normal stores to the destination,
because the copied-to data will be used soon after the interrupt handler
completes.
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan &
ckets stuck
and unable to go out.
A few other random debug and comment cleanups.
Always init rcvhdrq head/tail registers to 0, to avoid race conditions
(should have been that way some time ago).
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan &l
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r addf90abc724 -r f7c82500b9c7 drivers/infiniband/hw/ipath/Kconfig
--- a/drivers/infiniband/hw/ipath/Kconfig Thu Jun 29 14:33:25 2006 -0700
+++ b/drivers/infiniband/hw/ipath/Kconfig Thu Jun 29 14:33:25 2006 -0700
@@
.
Signed-off-by: Christian Bell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 31c382d8210a -r 2a721e1f490b drivers/infiniband/hw/ipath/ipath_common.h
--- a/drivers/infiniband/hw/ipath/ipath_common.hThu Jun 29 14:33:26
2006 -0700
+++ b/driv
This patch fixes some problems uncovered during IB compliance
testing to return the right values for error counters returned
by the Performance Get Counters packet.
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -
On Thu, 2006-06-29 at 14:53 -0700, David Miller wrote:
> From: Bryan O'Sullivan <[EMAIL PROTECTED]>
> Date: Thu, 29 Jun 2006 14:41:29 -0700
>
> > ipath_core-$(CONFIG_X86_64) += ipath_wc_x86_64.o
> > +ipath_core-$(CONFIG_PPC64) += ipath_wc_ppc64.o
>
> Again,
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 8e39364c2402 -r e952aedb0e94 drivers/infiniband/hw/ipath/ipath_verbs.c
--- a/drivers/infiniband/hw/ipath/ipath_verbs.c Thu Jun 29 14:33:26 2006 -0700
+++ b/drivers/in
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 4c581c37bb95 -r eef7f8021500 drivers/infiniband/hw/ipath/ipath_sysfs.c
--- a/drivers/infiniband/hw/ipath/ipath_sysfs.c Thu Jun 29 14:33:26 2006 -0700
+++ b/drivers/in
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r f7c82500b9c7 -r ebf646d10db0 drivers/infiniband/hw/ipath/ipath_qp.c
--- a/drivers/infiniband/hw/ipath/ipath_qp.cThu Jun 29 14:33:25 2006 -0700
+++ b/drivers/in
2900+, at 128KB
Signed-off-by: [EMAIL PROTECTED]
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 8bc865893a11 -r 1a4350d895c9 drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.cThu Jun 29 14:33:25
2006 -0700
+++ b/driver
This attribute group made it into the original driver, but should
not have.
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 3ceb73f8bde0 -r 21378f21e091 drivers/infiniband/hw/ipath/ipath_sysfs.c
--- a/drivers/infiniband/hw/ipath/ipath_sysfs.c Thu Jun 29 14:33:26 2006
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 125471ee6c68 -r fd5e733f02ac drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.cThu Jun 29 14:33:25
2006 -0700
+++ b/driv
Signed-off-by: Robert Walsh <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 160e5cf91761 -r 1e1f3da0e78d
drivers/infiniband/hw/ipath/ipath_verbs_mcast.c
--- a/drivers/infiniband/hw/ipath/ipath_verbs_mcast.c Thu Jun 29 14:33:25
2006 -0
used with a new board, while newer software will
correctly handle an older board.
Signed-off-by: Mike Albaugh <[EMAIL PROTECTED]>
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 21378f21e091 -r 8fbb5d71823a driv
On Thu, 2006-06-29 at 14:50 -0700, David Miller wrote:
> A facility like this doesn't belong in some arbitrary driver layer.
> It belongs as a generic facility the whole kernel could make use
> of.
It could, indeed. In fact, we had that discussion here before I sent
this patch in. It presumably
Hi, Andrew -
These patches bring the ipath driver up to date with a number of bug fixes,
performance improvements, and better PowerPC support. There are a few
whitespace and formatting patches in the series, but they're all self-
contained. The patches have been tested internally, and shouldn't
AIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r 5f3c0b2d446d -r 1bef8244297a drivers/infiniband/hw/ipath/ipath_keys.c
--- a/drivers/infiniband/hw/ipath/ipath_keys.c Thu Jun 29 14:33:26 2006 -0700
+++ b/drivers/infiniband/hw/ipath/ipath_keys.c Thu Jun 29 14
so no longer loop in ipath_kreceive(); better to not hold things off
too long (I saw many cases where we would loop 4-8 times, and handle
thousands (up to 3500) in a single call).
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
d
This helps us to survive better when memory is fragmented.
Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]>
diff -r fd5e733f02ac -r 9d943b828776
drivers/infiniband/hw/ipath/ipath_file_ops.c
--- a/drivers/infiniband/hw/ipath
On Wed, 2006-04-05 at 10:13 -0700, Stephen Hemminger wrote:
> Or for a new driver, just make it one big piece and put it at a
> website for download and include linke.
Funny, I'd have thought that was a guaranteed way to get it ignored.
http://vger.kernel.org/majordomo-info.html
On Sat, 2006-04-01 at 05:49 -0800, Linsys Contractor Amit S. Kale wrote:
> +for (ctx = 0; ctx < MAX_RCV_CTX; ++ctx) {
Why did this patch suddenly start in the middle?
> + if (adapter->is_up != ADAPTER_UP_MAGIC) {
> + printk("NetXen adapter %d\n", opencount);
> +
On Sat, 2006-04-01 at 05:14 -0800, Linsys Contractor Amit S. Kale wrote:
> We would like this driver to be inluded in mainline kernel.
> Kindly review it and feel free to get back to me for any
> feedback/queries/comments.
Based on some light reading and my own recent experience, I'd estimate
On Sat, 2006-04-01 at 05:20 -0800, Linsys Contractor Amit S. Kale wrote:
> +static inline void
> +netxen_nic_reg_write (netxen_adapter *adapter, u64 off, __uint32_t val)
> +{//Only for window 1
> +void *addr;
> +
> +read_lock(&adapter->adapter_lock);
> +
> +if (adapter->cur
On Sat, 2006-04-01 at 05:48 -0800, Linsys Contractor Amit S. Kale wrote:
> diff -Naru linux-2.6.16_orig/drivers/net/netxen/netxen_nic_init.c
> linux-2.6.16/drivers/net/netxen/netxen_nic_init.c
Why are you submitting the same file multiple times?
This is really pretty sloppy.
http://vger
On Sat, 2006-04-01 at 05:20 -0800, Linsys Contractor Amit S. Kale wrote:
> +U16 brdnum;
Where does U16 come from?
> +#define MAX_CMD_DESCRIPTORS 1024
Same comment as before WRT generic macro names. You're certain to break
the kernel build at some point with all these names.
On Sat, 2006-04-01 at 05:20 -0800, Linsys Contractor Amit S. Kale wrote:
> +#define NO_EPG_PROXY 1
> +
> +#define HOST_CPU_64_BIT 1
What?
> +#include
> +#ifdef NETIF_F_HW_VLAN_TX
> +#include
> +#endif
> +#ifndef MODULE
> +#include
> +#endif
?
> +#define BAR_00
> +#def
On Sat, 2006-04-01 at 05:19 -0800, Linsys Contractor Amit S. Kale wrote:
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define NetXen_CONF_X863
> +
> +#if defined(CONFIG_MODVERSIONS) && !defined(MODVERSIONS)
> +#define MODVERSIONS
> +#endif
> +
> +#if defi
On Sat, 2006-04-01 at 05:19 -0800, Linsys Contractor Amit S. Kale wrote:
> +/*
> + * netxen_niu_gbe_phy_read - read a register from the GbE PHY via
> + * mii management interface.
> + *
> + * Note: The MII management interface goes through port 0.
> + * Individual phys are addressed as foll
On Sat, 2006-04-01 at 05:18 -0800, Linsys Contractor Amit S. Kale wrote:
> +extern struct netxen_adapter_s *g_adapter;
> +extern spinlock_thal_lock;
In a header.
> diff -Naru linux-2.6.16_orig/drivers/net/netxen/xge_mdio.c
> linux-2.6.16/drivers/net/netxen/xge_mdio.c
This entire
On Sat, 2006-04-01 at 05:17 -0800, Linsys Contractor Amit S. Kale wrote:
> +unsigned long
> +decode_crb_addr (unsigned long addr)
> +{
Missing a nexgen_ prefix.
> +int
> +wait_rom_done (netxen_adapter *adapter)
Ditto.
> +int
> +rom_fast_read (netxen_adapter *adapter, int addr)
And again. I'm
On Sat, 2006-04-01 at 05:16 -0800, Linsys Contractor Amit S. Kale wrote:
> +extern char * netxen_nic_driver_string;
> +extern void netxen_update_stats(struct netxen_port *port);
> +extern void netxen_change_ringparam(struct netxen_adapter_s *adapter);
> +extern int rom_fast_read(struct netxen_adap
On Sat, 2006-04-01 at 05:17 -0800, Linsys Contractor Amit S. Kale wrote:
> +extern struct netxen_adapter_s *g_adapter;
> +extern spinlock_thal_lock;
Should be in a header file.
> +void
> +netxen_nic_pci_change_crbwindow(netxen_adapter *adapter, uint32_t wndw)
Should use u32,
On Mon, 2006-03-06 at 15:40 -0800, Roland Dreier wrote:
> Anyway IB works fine with standard INTx interrupts -- MSI is just icing.
Depends on the driver. Ours needs the interrupt vector rather than the
number, which means we don't work without CONFIG_PCI_MSI. That is,
unless there's some other
On Thu, 2006-01-19 at 02:33 -0800, Chris Wedgwood wrote:
> if/we klibc is merged we could pull this code out surely?
Yes. The code in the klibc tree has been sort of ready for that for oh,
about two years now. What it's lacking is a lot of testing, and it will
continue to lack it until we make
On Wed, 2006-01-18 at 08:08 +0100, Arjan van de Ven wrote:
> the dual license text needs a bit of clarification I suspect to make
> explicit that the "or BSD" part only applies when used entirely outside
> the linux kernel. (that already is the case, just it's not explicit.
> Making that explicit
On Wed, 2005-09-07 at 11:15 -0700, Stephen Hemminger wrote:
> This how I think ifplugd should work, it should not poll it
> should just use libnetlink and read for the next message.
Incidentally, this is what netplugd already does, for people using
Fedora, Red Hat or Mandriva systems.
htt
On Fri, 2005-08-05 at 04:55 +0200, Mateusz Berezecki wrote:
> The driver is not yet fully working because I didn't finish kernel
> integration yet.
How far from working is it? I have a miniPCI Atheros card and would be
interested in helping out with bringing the driver up, but it would be
good
67 matches
Mail list logo
