[PATCH] hpilo open/close fix

[PATCH] hpilo open/close fix

[David Altobelli]

Fix to hpilo module, patch against 2.6.28.
The device can take a while to respond to an open/close request, so increase
the time kernel will wait for response (1 ms to 10ms).  
Also, properly clean up a channel on a failed open, by calling the 
channel close routine.  Just freeing the memory isn't sufficient, the device
needs to be informed that the channel is no longer open, and the device
memory cleared of references to freed dma buffer.

Please CC me on any replies.

Signed-off-by: David Altobelli <david.altobelli@hp.com>
---

--- drivers/misc/hpilo.c.orig	2009-01-12 10:03:33.000000000 -0600
+++ drivers/misc/hpilo.c	2009-01-12 14:03:40.000000000 -0600
@@ -207,7 +207,7 @@ static void ilo_ccb_close(struct pci_dev
 		  &device_ccb->recv_ctrl);
 
 	/* give iLO some time to process stop request */
-	for (retries = 1000; retries > 0; retries--) {
+	for (retries = MAX_WAIT; retries > 0; retries--) {
 		doorbell_set(driver_ccb);
 		udelay(1);
 		if (!(ioread32(&device_ccb->send_ctrl) & (1 << CTRL_BITPOS_A))
@@ -309,7 +309,7 @@ static int ilo_ccb_open(struct ilo_hwinf
 	doorbell_clr(driver_ccb);
 
 	/* make sure iLO is really handling requests */
-	for (i = 1000; i > 0; i--) {
+	for (i = MAX_WAIT; i > 0; i--) {
 		if (ilo_pkt_dequeue(hw, driver_ccb, SENDQ, &pkt_id, NULL, NULL))
 			break;
 		udelay(1);
@@ -326,7 +326,7 @@ static int ilo_ccb_open(struct ilo_hwinf
 
 	return 0;
 free:
-	pci_free_consistent(pdev, data->dma_size, data->dma_va, data->dma_pa);
+	ilo_ccb_close(pdev, data);
 out:
 	return error;
 }
--- drivers/misc/hpilo.h.orig	2009-01-12 13:49:11.000000000 -0600
+++ drivers/misc/hpilo.h	2009-01-12 13:56:33.000000000 -0600
@@ -19,6 +19,8 @@
 #define MAX_ILO_DEV	1
 /* max number of files */
 #define MAX_OPEN	(MAX_CCB * MAX_ILO_DEV)
+/* spin counter for open/close delay */
+#define MAX_WAIT	10000
 
 /*
  * Per device, used to track global memory allocations.

Re: [PATCH] hpilo open/close fix

[Greg KH]

On Mon, Jan 12, 2009 at 01:18:37PM -0700, David Altobelli wrote:
> Fix to hpilo module, patch against 2.6.28.
> The device can take a while to respond to an open/close request, so increase
> the time kernel will wait for response (1 ms to 10ms).  
> Also, properly clean up a channel on a failed open, by calling the 
> channel close routine.  Just freeing the memory isn't sufficient, the device
> needs to be informed that the channel is no longer open, and the device
> memory cleared of references to freed dma buffer.
> 
> Please CC me on any replies.
> 
> Signed-off-by: David Altobelli <david.altobelli@hp.com>

Am I supposed to be shepharding patches to drivers/misc/hpilo into the
kernel tree?  If so, I've been ignoring it, sorry.  Is there any becides
this one that you need to go in?

thanks,

greg k-h

RE: [PATCH] hpilo open/close fix

[Altobelli, David]

> -----Original Message-----
> From: Greg KH 
> Am I supposed to be shepharding patches to drivers/misc/hpilo into the
> kernel tree?  If so, I've been ignoring it, sorry.  Is there any
> becides this one that you need to go in?
> 

I appreciated your help when I first posted this driver, and you 
are a general driver guy, so I copied you, but I didn't expect you 
to take over shepherding patches into the tree for me.  I don't really 
know how this process works, but I'm happy to copy any person/list that 
will help me move code into the tree.  

I got an email that this patch was in -mm, but I don't know where it 
went from there.

I have a simple add device id patch that I was going to submit after 
figuring out the patch submission process.

Re: [PATCH] hpilo open/close fix

[Greg KH]

On Wed, Jan 21, 2009 at 07:05:03PM +0000, Altobelli, David wrote:
> > -----Original Message-----
> > From: Greg KH 
> > Am I supposed to be shepharding patches to drivers/misc/hpilo into the
> > kernel tree?  If so, I've been ignoring it, sorry.  Is there any
> > becides this one that you need to go in?
> > 
> 
> I appreciated your help when I first posted this driver, and you 
> are a general driver guy, so I copied you, but I didn't expect you 
> to take over shepherding patches into the tree for me.  I don't really 
> know how this process works, but I'm happy to copy any person/list that 
> will help me move code into the tree.  
> 
> I got an email that this patch was in -mm, but I don't know where it 
> went from there.

Ah, yeah, it looks like Andrew took this, which is good, it can go in
through there with no need for me to touch it.

Just cc: him on future patches to make sure he picks them up.

thanks,

greg k-h