Hello all, I tried drvctl- it works with ubt0, uaudio0 but not with sdhc0- it returns (from memory) "Operations not supported" or similar. Anyway shdc0 doesn't work with drvctl.
Thanks ! Piotr. On Tue, Dec 7, 2010 at 10:28 PM, Piotr Adamus <[email protected]> wrote: > 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 >> >
