Michael Buesch wrote: > I was talking about BMIrompatchInstall and friends.
Ah ! I hadn't poked around in the BMI yet. That looks quite interesting indeed. > I think it should be handed to the Supplicant. The Supplicant will try > to re-establish the connection or drop it. Sounds good to me. If we're allowed to do something radical, such as just discarding the whole MAC state, that would be perfect for the AR6k in terms of reliability of the rfkill mechanism and also in terms of implementation complexity. More specifically, SDIO gives us a single-bit on/off switch. But that affects the whole module, not just the transmitter. And since this is a "full MAC", there's quite a lot of state in the module. This still leaves the Atheros-specific extensions, such as --power maxperf, but I think we can worry about these later. > So the real question is, does the firmware implement part of the > Supplicant? I guess so. Hmm, I'm not sure what you mean here. The firmware does scan for networks on its own and connects if it finds matching ESSID and encryption. > Well, wireless extensions semantics are a little bit crappy. Hmm, or at least "vague" :) > But as far as I > understand the semantics, SIWESSID is supposed to associate to the > service (except in a few cornercases). > So IMO it should fail, because without a transmitter, we can't handshake a > connection. My understanding is that SIWESSID is allowed to return successfully without establishing an association. The MAC keeps on trying on its own. > Yeah, as I said. Current mainline drivers don't mess with state at all. Yes, that's what I used as my baseline so far. I.e., that rfkill is not allowed to do damage that goes beyond what happens anyway when you have a complete loss of signal. I also noticed that the - otherwise very detailed - documentation of rfkill leaves this aspect completely open to interpretation. Perhaps we should resume this on linux-wireless, since I guess that's where all the rfkill folks hang out. Thanks, - Werner _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
