Ivo van Doorn <ivdoorn@...> writes: > > Hi, > > > > > > Then there is a problem for rt2x00. Since the mactime isn't known. > > > > > rt2400pci is the _only_ device which has a RX_END_TIME field in the > > > > > RX descriptor. > > > > > > > > one workaround could be to simply use the current TSF at the time in > > > > the tasklet or interrupt handler (to be more close to the actual rx > > > > time). this should be sufficient to catch most cases where an IBSS > > > > merge is necessary - usually the beacon's TSF will be much higher > > > > than the local TSF. > > > > > > Should the driver to this, or should mac80211 handle that? > > > > The driver should if it has access to some the mactime of the received > > packet otherwise yes -- I think mac80211 can handle this using the > > supplied get_tsf(). > > > > > Personally I think it is something for the mac80211 layer since the > > > driver will give what it can, and can be sure that it is what mac80211 > > > expects instead of drivers interpreting what mac80211 might want as > > > replacement. If mac80211 needs the TSF value when no mac time is > > > given, it could just use the get_tsf() callback function to the driver > > > to get the substitute. When the get_tsf() callback is not provided, > > > then mac80211 can complain about missing information. > > > I see one problem with this. At the moment rt2x00 doesn't implement get_tsf for USB devices. In the case of RT73 this is because mac80211 requires get_tsf to be atomic which precludes waiting for a USB device to reply to a request. Ivo has got an implementation in the code but it is disabled as the fact it sleeps was causing bugs. Presumably other USB devices would have the same problem. I'm not sure if the code path for IBSS merging would require an atomic version, I'm guessing it wouldn't. If so do we need to consider whether to either have both get_tsf and get_tsf_atomic or have a flag to get_tsf indicating if it can sleep if it needs to? Adam Baker - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
