On Sat, Aug 2, 2008 at 10:27 PM, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote: > Hi Johannes! > > On Sat, 02 Aug 2008, Johannes Berg wrote: > >> On Sat, 2008-08-02 at 15:11 -0300, Henrique de Moraes Holschuh wrote: >> > Currently, rfkill would stand in the way of properly supporting wireless >> > devices that are capable of waking the system up from sleep or hibernation >> > when they receive a special wireless message. >> > >> > Since rfkill attempts to soft-block any transmitters during class suspend, >> >> why does it interfere with suspend anyway? > > The class makes sure that all transmitters are blocked on suspend. You'd > have to ask Ivo for the reason, but AFAIK, it is for both safety and to help > conserve power. This one is also on my list to remove. Suspend/Hibernate Resume definitelly doesn't mean to rfkill radio on and off.. Driver should bring down the NIC up and down. anyway nless it supports some D3 working condition as iwlwiifi HW )not enabled under Linux). This only creates conflicts as both driver and rfkill system are trying to bring radio down RFKILL IMHO shell track rfkill switches states and not to invent them. If the radio was SW switched off before NIC was suspend it shell be switched off also in resume. That's should be role of rfkill system, probably with some help from user space. Tomas Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
