2009-01-12 20:18:47

by Altobelli, David

[permalink] [raw]
Subject: [PATCH] hpilo open/close fix

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 <[email protected]>
---

--- 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.


2009-01-21 18:09:00

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH] hpilo open/close fix

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 <[email protected]>

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

2009-01-21 19:06:06

by Altobelli, David

[permalink] [raw]
Subject: RE: [PATCH] hpilo open/close fix

> -----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.

2009-01-21 19:14:57

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH] hpilo open/close fix

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