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
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