Re: 3945 driver using d80211

[Mohamed Abbas <mabbas@linux.intel.com>]

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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>