On Tue, 2005-01-25 at 07:08 +0100, Heiko Carstens wrote:
Originally this generic device was part of your adapter structure. Now
you're trying to separate it and causing these problems. What it's
Could you please elaborate where this patch does cause a problem?
You're look to be breaking
]
|
| Subject: Re: [PATCH] zfcp: updates for -bk
On Tue, 2005-01-25 at 19:10 +0100, Martin Peschke3 wrote:
Actually, you will find the adapter structure be an anchor for several
other objects, or lists of them respectively. We tried to organize
all the driver private data in a sane way. That means there is a tree
of objects representing the
Hi James,
could you please apply the patch below?
Thanks,
Heiko
From: Heiko Carstens [EMAIL PROTECTED]
From: Andreas Herrmann [EMAIL PROTECTED]
From: Maxim Shchetynin [EMAIL PROTECTED]
zfcp changes:
- revert kfree patch leftovers
- don't call del_timer_sync() in interrupt context
- correct
On Mon, Jan 24, 2005 at 10:46:29AM +0100, Heiko Carstens wrote:
@@ -1099,9 +1099,9 @@
}
void
-zfcp_dummy_release(struct device *dev)
+zfcp_generic_services_release(struct device *dev)
{
- return;
+ kfree(dev);
}
/*
I thought that having release methods that just
On Mon, 2005-01-24 at 15:48 +0100, Heiko Carstens wrote:
I thought that having release methods that just called kfree() were
also verboten?
We do a kmalloc(sizeof(struce device),...) somewhere and this
is how we get rid of it again.
How are we supposed to free this object otherwise? The
I thought that having release methods that just called kfree() were
also verboten?
We do a kmalloc(sizeof(struce device),...) somewhere and this
is how we get rid of it again.
How are we supposed to free this object otherwise? The release
function gets called when there is no more
7 matches
Mail list logo
