Hello all, thank you for your time and replies.
I was user of NetBSD since 3.0 until the the quite current 5.99.XX. I will provide the dmesg and other tomorrow. I do use suspend- it is useful. But on Linux (FreeBSD doesn't wake-up for me at all). @iain I wouldn't be bothered about loosing connection- as John said as well. @John I was afraid that there is not too much work done on modules. I will try the drvctl tomorrow and report. Let me report my findings tomorrow- thanks one more time. Kr, Piotr. On Tue, Dec 7, 2010 at 10:16 PM, John Nemeth <[email protected]> wrote: > On Mar 25, 7:15am, Iain Hibbert wrote: > } On Tue, 7 Dec 2010, John Nemeth wrote: > } > On Apr 28, 10:22am, Piotr Adamus wrote: > } > } > } > } I have one simple question: is it possible to compile these drivers > } > } into modules only: sdhc, ubt, uaudio? At this moment I don't have > } > } NetBSD installed. These drivers don't have suspend support enabled. > } > > } > There is a module for uaudio, but there are no modules for sdhc > } > and ubt. Kernel modules are a work in progress and driver modules even > } > more so. You're best bet if you don't need them, is to remove them > } > from your kernel. > } > } I am not sure but in the old days (when I wrote ubt), there was not really > } any need for specific suspend support in ubt because USB devices were just > } detached upon suspend events. Is the USB stack any different now? I > } confess, I don't use suspend. > > I don't know the USB stack. However, I just looked at ubt.c and I > see that Christos added NULL suspend and resume handlers in rev. 1.30, > which is between NetBSD 4.x and NetBSD 5.x. > > Piotr, what version of NetBSD are you running? Also, can you > execute this command, please: "ident /netbsd | grep ubt". > > } In any case, there is plenty of state about the current Bluetooth > } connections that is held inside the controller and would be lost if the > } device was powered down with no way that I know of to reinstate it, not to > > In that case, you should probably create suspend and resume > routines to save and restore the necessary data. > > } mention that devices would likely be out of range after awakening, so I > } don't really know how much code would be useful there anyway. > > Maybe, maybe not. Equipment doesn't necessarily move while being > suspended (or, if it does move, the Bluetooth device might move with > it, i.e. a mouse or a keyboard). And, with Bluetooth, devices can > move in and out of range at random times, so this needs to be handled > anyways. > > }-- End of excerpt from Iain Hibbert >
