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

[Johannes Berg]

Hi Neeraj,

Maybe instead of proposals, you should describe what you want first. It
seems that you want a basic form of presence request handling?

> Proposal A):
> 1) Upon getting presence request, supplicant can simply call set_noa()
> with received presence request NOA attribute. Let the driver take care
> of modifying the NOA attribute in NOA frames depending upon the
> received presence request. Driver will also disable oppps upon this
> set_noa call.
> 2) We need to modify current set_noa function prototype to tell the
> driver somehow that the attached NOA attributes are from the presence
> request. Otherwise driver will not have anyway to find out if he has
> to do the modify NOA schedule based on presence request OR they are
> new NOA values from the application itself.
> 3) The disadvantage with this approach is that it doesn't look clean.
> Or we need to comeup with a new driver function (*handle_presence) or
> something like that.

Using set_noa() is definitely not a good plan. Adding handle_presence(),
which can return an error as well, is a better plan. HOWEVER -- for
symmetry you will have to also give the driver which station this was so
it can *remove* the presence request again when the station requests a
new one/none any more, and the supplicant should also tell the driver to
remove it before it removes that station from the driver. So I think
there are a bunch of corner cases to get right wrt. updating the
presence request and removing it.

> Proposal B): 
> 1) Upon getting presence request, supplicant will call get_noa().
> Supplicant will disable the current NOA schedule completely and will
> also disable oppps by simply calling set_noa(). Also multiple presence
> requests from different clients will do the same. 
> 2) Once all clients sends a presence request with 0 values (whoevers
> sent a presence request earlier), we will again enable the previous
> NOA schedule. 
> 3) Advantage here is it is clean approach and doesn't increase the
> supplicant complexity to calculate revised NOA schedule.

This doesn't seem right either -- forget set_noa() completely, it's for
testing. Anything should, in my opinion, be done through specific APIs.

johannes