Hi Dan, > Last I knew there were cases where mesh forwarding was _not_ > supposed to be on due to the high power drain of the 8388 when the > radio was enabled, plus the airplane case. As long as the > networking core doesn't close the devices on suspend, this patch > shouldn't have side-effects on mesh forwarding.
The current setup is: suspend: caused by idleness, radio stays on, unicast wakeups stay on sleep: caused by lid close or power button, radio stays on, wakeups off I think it's still undecided whether sleep should leave the radio on or not -- we need to take power measurements now that mesh beacons can be disabled and see whether the power consumption is significantly reduced. > [1] when doing long suspends, when the resume occurs userspace will > need to redo the networking setup anyway, scanning and searching > for the school server or default mesh channel, because a long > suspend most likely means you changed location and increases the > likelihood that the networking situation around you changed as > well. Is there a dbus message OHM can pass to NM for this? (If not, maybe you could mention which NM functions perform the full scan/search so that we can wrap them?) Thanks! - Chris. -- Chris Ball <[EMAIL PROTECTED]> _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
