On Wednesday, 14 February 2007 22:43, Michael Buesch wrote:
> On Wednesday 14 February 2007 17:29, Larry Finger wrote:
> > > And no, it is not correct to just call attach_board from resume. ;)
> > > Instead you must copy (or probably move) the HW init stuff that
> > > is in the attach step to the init step.
> > > 
> > > I have done that in my tree in bcm43xx-d80211.
> > > 
> > > Not easy to refactor without introducing bugs. Definately _not_
> > > a patch for next -stable kernel. ;)
> > 
> > After looking through your code, I agree that it is not -stable material.
> > 
> > It would be drastic, but we could call remove_one on suspend and init_one 
> > on resume. Userland might
> > get excited about the interface disappearing and reappearing, but it should 
> > work. Any thoughts?
> 
> Yes, exactly. The problem would be that we redo all the data structures, too.
> If you want, create a patch to test if it works. But I really don't want
> to have something like that in the kernel tree, because it's worse behaviour
> in the common suspend-to-ram case. Userspace is confused by it. The supplicant
> for instance might, too, and might be unable to reassociate. But I don't know
> for sure.

I think the current behavior is acceptable if the driver generally works with
the STR.  The STR is more important to us than the STD these days. :-)

It may be possible to make it work after the resume from disk too if it's
loaded before reading the image, for example.

I have to carry out some more tests and debug it a bit more, but that will
take some time (obviously).

Greetings,
Rafael
_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Reply via email to