> Quoting Bryan O'Sullivan <[EMAIL PROTECTED]>:
> Subject: Backport and fix patches for ipath driver
>
> Hi, Vlad and Tziporet -
>
> Here's a round of fix and backport patches for the ipath driver, for
> dropping into the OFED 1.2 tree. The way in which they're organised
> should, I hope, be clear.
Looks good, fixes look much cleaner than what we had for OFED 1.1.
I think fixes can be applied already.
However, I'm not sure the backports are ready to be applied as is yet.
Just taking a look at random:
./backport/2.6.18/ipath-50-mad-kmem_cache-2.6.19.patch
BACKPORT - kmem_cache_t disappeared after 2.6.19
diff -r a290ff6e9ae7 drivers/infiniband/core/mad.c
--- a/drivers/infiniband/core/mad.c Wed Jan 31 14:47:02 2007 -0800
+++ b/drivers/infiniband/core/mad.c Wed Jan 31 14:48:00 2007 -0800
@@ -46,7 +46,7 @@ MODULE_AUTHOR("Hal Rosenstock");
MODULE_AUTHOR("Hal Rosenstock");
MODULE_AUTHOR("Sean Hefty");
-static struct kmem_cache *ib_mad_cache;
+static kmem_cache_t *ib_mad_cache;
static struct list_head ib_mad_port_list;
static u32 ib_mad_client_id = 0;
This changes a core file, and does not seem to be related to ipath at all.
What problem does this solve? I note that mad.c already seems to build fine on
2.6.18
for us - this is part of daily build.
Another example that looks strange:
BACKPORT - workqueues changed in 2.6.20
diff -r 8b94fcef1edd drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.c Thu Feb 01 08:54:29
2007 -0800
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c Thu Feb 01 08:57:19
2007 -0800
@@ -241,7 +241,7 @@ static struct ipath_devdata *ipath_alloc
dd->pcidev = pdev;
pci_set_drvdata(pdev, dd);
- INIT_DELAYED_WORK(&dd->link_work, check_link_status);
+ INIT_WORK(&dd->link_work, check_link_status);
list_add(&dd->ipath_list, &ipath_dev_list);
INIT_DELAYED_WORK is implemented in kernel_addons, so this should
not be necessary.
@@ -725,6 +725,7 @@ static void __devexit ipath_remove_one(s
*/
ipath_shutdown_device(dd);
+#undef cancel_delayed_work
cancel_delayed_work(&dd->link_work);
flush_scheduled_work();
This undef looks quite ugly. What does it do?
Please go over the backport patches and check whether they are really necessary.
I think you will mostly discover that the kernel_addons mechanism makes
the backport patches unnecessary. If not, you should try adding
things under kernel_addons as first choice so that everyone benefits.
--
MST
_______________________________________________
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
