-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On Monday 12 January 2009 10:09:56 Andy Green wrote: |> | - in the discussion on linux-wireless, Michael Buesch also mentioned |> | that rfkill is expected to act "immediately". |> |> Yeah I take it to mean when you return from the rfkill action, the |> stopping of RF TX is done already. That sounds doable? | | Well, that would be ideal. | I think it wouldn't be that much of a problem if it takes another 10ms however. | My main idea just was that rfkill should _not_ trigger _sending_ of the pending | packets in the queue. Instead it should just drop the queue.
Yes only SDIO packets would be triggered by rfkill in this scheme to be sent to set state in the controlling firmware, not network packets on the RF. AIUI if we tell it to go into sleep like mode it won't play ball as a network device until told to wake up. | Btw, as we're talking about firmware, I'm wondering if there's some binary firmware | (update?) blob available for download somewhere. Or if it's possible to read the | firmware code from the PROM. No, it's a less than happy-making situation there are no updates and no redistributable Linux firmware update tool. | It seems possible to read the device RAM in the boot stage and that also seems to work | fine. But I didn't see a way to read the PROM. I didn't even find a way to write the PROM | actually. Except this runtime patching thing. So I was wondering if that runtime patching | stuff can be used to read the ROM step by step (into RAM). | Does somebody have some information on the CPU and/or instruction set used in the wireless device? I don't have anything. |> Well killing TX kills association, kills any connectivity lying around, |> etc. It inherently affects everything on top of the network interface. |> ~ I think maybe we can just do it and the sky won't fall? | | rfkill is expected to kill the radio without terminating any MAC functions. | The AP/Authenticator/Supplicant will take care of cleaning up dead connections. Right, but I mean the direct implication of (only) killing TX is that association state and the other network layer states change too. So I don't think we need to sweat possibility of rfkill changing state like essid when it has definitely trashed the association and all that will need to be set up again from scratch. If it does turn out to be objectionable, we can reload old essid from just before we rfkilled it when we un-rfkill it. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklraQ0ACgkQOjLpvpq7dMpktgCeLa2s94OsaGMp8S8geS9y5WEu cIIAnRitY9NZy7xaTPR7DTVJzXvpstB0 =m6/w -----END PGP SIGNATURE----- _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
