For 3945 a lot of functionalities were moved to the driver level, what
kept in the firmware is basically some timely related functions like
beacon in IBSS mode but the beacon frame is provided by the driver and
the firmware is responsible to send it according to the timing
constrains. Also scanning was left in the firmware. We don’t do and
authentication or association frame in the firmware and we use d80211 to
do this. We just needed to know once we associated to inform the
firmware we are associated now. I just want to say d80211 was very
flexible and easy to work with, the porting process was smooth and we
only faces these problems with a working workaround and I thought we can
even make d80211 more flexible to cater more varieties of cards. For
ipw2[2/1]00 we did a gap analysis and we found it is hard to port it to
use d80211 because of what mentioned below. I hope to post 3945 with
d80211 code sometime next week so we can have the code available for our
discussion.
Thanks
Mohamed
Dan Williams wrote:
On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote:
On Wednesday 09 August 2006 00:57, Johannes Berg wrote:
Please not, for now. We need someone pushing for fullmac features in
d80211, we need those anyway for embedded systems that can't afford
running all of it on the main CPU. While obviously Intel would benefit
from doing this since a lot more d80211 features would come available,
the greater good would be having a main-stream card that someone cares
about and helps making d80211 full-mac capable.
It's not that hard to generate probe, authentication, and association frames,
and it isn't done frequently enough to stress any embedded system that can
run linux. Doing this would let 3945 take advantage of all the d80211
features, so why not?
What level of fullmac support are we talking about? True fullmac cards (as I
define them) do not need to use d80211. WE19 is all they need, to add
WPA/WPA2 support. The IPW cards have a particularly unique split between
firmware and host 802.11 duties which I haven't seen in any other cards. They
aren't quite fullmac enough to interface with WE directly, yet they only need
probe response handling to complete the picture. What other half-fullmac,
half-softmac card besides the other IPW cards splits card/host 802.11 duties
along those lines? What other splits between card and host are out there? I
would be very reluctant to make changes to the 802.11 stack to support
"fullmac" without evidence that other drivers need the change.
The atmel driver is somewhat of a hybrid. For fullmac cards like airo,
you just set the connection info up, let the card go, and you get back a
link event. But the atmel driver controls authentication and
association stuff; that's not done in firmware. Look at:
send_authentication_request()
send_association_request()
atmel_transmit_management_frame()
atmel_management_frame()
authenticate()
associate()
The driver has an auth/assoc state machine, receives management frames,
and sends out the next appropriate management frame based on the current
state. I think this is the reverse of ipw2100, where the firmware
handles assoc/auth but not much else, but it's still less fullmac than
airo, and more fullmac than softmac.
Dan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
