Re: [PATCH] mac80211: enable IBSS merging

[Ivo van Doorn <ivdoorn@gmail.com>]

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