[PATCH] P2P return a successful response for p2p presence request if driver has return noa_len greater than 0

[Johannes Berg]

On Mon, 2011-11-21 at 10:10 +0100, Johannes Berg wrote:

> If the driver returned noa_len > 0, that means that a NoA schedule is in
> effect. That means that we don't know, without parsing the NoA schedule,
> whether or not the presence request can be fulfilled. Therefore, we must
> return UNABLE_TO_ACCOMODATE.
> 
> With nl80211, unfortunately this logic is broken because the driver
> doesn't return a NoA schedule, so noa_len is always == 0 (I think?) and
> we shouldn't be returning SUCCESS even in that case because the driver
> or device might internally have a NoA schedule in effect.
> 
> I'm not convinced that get_noa/set_noa is the right answer to this.
> get_noa is virtually impossible to implement in a race-free manner at
> least as far as presence requests are confirmed, and set_noa is really
> only a testing hook.
> 
> I think the right answer may be to ask the driver for each presence
> request and return UNABLE_TO_ACCOMODATE if the driver doesn't implement
> the function.

I also just noticed that the P2P core code (src/p2p) appears to attempt
to distinguish between drivers having get_noa support and those that
don't by checking p2p->cfg->get_noa, but obvious that is always set
since it's the p2p_supplicant's function, not the driver's.

So all this seems really really buggy right now. :-(

johannes