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. Oops, I really should have checked it, I thought the other tsf handler was disabled and only get_tsf was implemented. Apparently rt73usb only has reset_tsf(). :S For rt2500usb the problem is that it contains no TSF registers at all (at least I never found an offset which contained something looking like a TSF). > 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? The new patch has get_tsf() in normal context, I think the best thing would be moving all remaining atomic get_tsf() calls out of that context. But last time I checked that wouldn't be too easy. :( Ivo - 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
