Re: Re: [lwlan-devel] Linux-wlan-ng and xen

Hi Solomon,


On Mon, 2006-06-19 at 17:36 -0400, Solomon Peachy wrote:
> On Sat, Jun 17, 2006 at 10:47:26AM +0100, Richard Kennedy wrote:
> > > there an SVN or CVS repo with all the patches in - I'm already running
> > > the FC5 udev patch, now there's this reference counting one too - it
> 
> Can someone bounce me a copy of the current udev patch?
> 
I see David's already sent it -- thanks David.

> > I don't know what's happening with suspend/resume, it doesn't work for
> > me at all. Without the attached patch my laptop hangs on resume -- with
> > it the wlan card doesn't start up again but everything else is OK.
> 
> Rather than being in the "create/destroy" functions, the refcounting 
> should be in the probe/remove functions.  And it also needs to handle 
> errors on registration. 
> 
hfa384x_create & destroy _are_ called from probe_usb & disconnect_usb --
and have the correct error handling already, so it was a lot easier to
add the ref count in there.

I think it is the correct thing to do -- although it might look a bit
odd -- I ref count the usb device _only_ when it gets stored for later
use ( in hfa384_create ) and release it when we finished with it
(destroy).

 
> This particular API call was there before 2.6.16, and it is also not 
> used by most of the in-kernel USB drivers.  So I'm honestly not sure 
> when it's actually of use.
> 
I don't know either - but without the fix resume hangs.

> > I would like to get the driver to send the disable message to the card
> > on module unload and see if that helps. but I haven't 1) found the right
> > place in the code to put it and 2) found the time to do much with it :)
> 
> The prism_usb's hardware is rather finiky, to stay the least.. but 
> essentially, on a suspend, the hardware goes away but the driver does 
> not.  The driver needs to reset itself by basically going into 
> ifstate_disable state.  That said, in the case of USB I believe the 
> device should be disconnecting itself from the bus, so the driver stack 
> should go down and come back up cleanly.
> 
There seems to be new code in the 2.6.16 kernel supporting usb suspend /
resume -- I'm seeing warning messages about the device not supporting
the usb suspend & resume methods. I'm not sure what's supposed to happen
in these methods -- other drivers stop kernel timers etc in suspend and
then restart them and reset the card, reloading firmware etc ...

But I've not found any doc's describing what needs to happen in these
methods -- but there again I've not looked too hard :)

I know my setup is a bit strange -- with the usb wlan built in to the
laptop so it never gets unplugged-- but on a soft reboot the card gets
wedged and won't reconnect to the usb bus. Only a full power down will
reset it. 
If I manually prims2ctl disable and remove the module before the reboot
-- it come back up correctly -- this is what made me think it might be
worth add a disable if the module is removed when the card is still
plugged in. Anyway, only another theory...   


> That's the theory, anyway..
> 
>  - Solomon

Cheers

Richard