On Tuesday 22 May 2007 12:16, James Ketrenos wrote: > > - Read and set the MAC address before calling ieee80211_register_hw. > > We're calling SET_IEEE80211_PERM_ADDR before we call ieee80211_register_hw. > Is there something else we should be doing? > Well, after jumping through a few hoops to find ieee80211_register_hw, it appears you're right. However, I don't like it. Bringing the hardware up should be deferred as much as possible to when the user actually brings the interface up. ipw2200 can defer firmware loading to interface open time while still reading the mac address from the eeprom.. why not ipw3945? (the ipw2200 driver doesn't actually do this, but it should. I know it can.) Also, the code doesn't appear to support changing the mac address at all. The mac address given by conf->mac_addr should be the address that your driver uses. > That said -- if the driver can execute in parallel to the stack for some > operations, shouldn't they remain on their own workqueues so the work can > be divided up vs. having *everything* routed through one singlethread > workqueue? > Your choice. mac80211 needs a workqueue regardless so it's made available to drivers. Many callbacks are called on this workqueue so drivers don't need to defer work to their own workqueue (and can actually return error values). > > - Why are probe requests being dropped in adhoc mode? (assuming hardware > > handles it.. but the message output for that doesn't sound like it) > > It only drops them if the adapter is not in the associated state (the card > is configured with the RXON_FLAG_ASSOC_MSK bit clear) > I think this decision making belongs in mac80211. -Michael Wu
Attachment:
pgpLaiE6hcbkP.pgp
Description: PGP signature
