Sorry, just thought of something. On Wed, 2010-05-05 at 20:34 -0700, wey-yi.w.guy@xxxxxxxxx wrote: > + * @timestamp: value in microseconds of the 64-bit Time Synchronization > + * Function (TSF) timer when the channel switch ie received. This is not accurate now but see below. > + if (beacon) > + timestamp = le64_to_cpu(mgmt->u.beacon.timestamp); > + else > + timestamp = le64_to_cpu(mgmt->u.probe_resp.timestamp); > + ieee80211_sta_process_chanswitch(sdata, sw_elem, > + bss, timestamp); > } > } > > @@ -1647,7 +1691,8 @@ static void ieee80211_sta_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata, > > ieee80211_sta_process_chanswitch(sdata, > &mgmt->u.action.u.chan_switch.sw_elem, > - (void *)ifmgd->associated->priv); > + (void *)ifmgd->associated->priv, > + rx_status->mactime); For some reason I didn't notice the action frame handling before. Maybe it would be more consistent to keep using rx_status->mactime even for beacons? I apologise, this is totally my fault since I suggested using the beacon time before, but that has a slightly different value relative to the frame... Hmm. Maybe it would be better after all to require drivers to provide mactime at least for mgmt frames (beacons + actions) when they want to implement this callback. Anyone else have ideas? johannes -- 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
