On Fri, 2007-08-03 at 18:56 -0400, Daniel Drake wrote: > As for the other problems mentioned in followup mails, how about > something like the following: > > A new configure_device callback with these parameters: > - ieee80211_hw *hw > - int state: possible values NOCHANGE, ON, OFF > - int filter_flags: FIF_ flags from above > - u8 *mac_addr > > This would combine the ideas of add_interface, remove_interface and > open/stop into one. That isn't going to work as soon as you have multiple MAC addresses which I'm told zd1211 supports. Didn't you or Uli just complain that struct wiphy has only one address? > state: this would become ON when the first interface is brought up, and > would become OFF when the last interface is brought down. For all other > calls into this function, state is NOCHANGE Why NOCHANGE? The driver surely knows whether it's on or off so just on/off should be enough. > Also I was wanting to add communication from mac80211 to the driver > about supported rates in the ESS (softmac does this, zd1211rw uses this > info). This would also fall in the same category. And maybe we should > add the multicast list above too. Overload IMHO. Let's have a few calls. add/remove_interface are still required because you still need the if_id to ask the stack for beacons (IIRC); open/close (can we rename those to start/stop?) can be well-defined with this instead of having ON/OFF/NOCHANGE flags (NOCHANGE would just mean no start/stop callback). Then we can have one call for filtering setup which includes multicast and filter flags. > I feel the above would make life fairly easy for drivers, or am I > over-designing this? Perhaps I am also missing some considerations for > IBSS/AP mode... Yeah, for beacons you need to know about the interfaces that were added to get the beacons. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
