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