[RFC 06/10] nl80211_driver: add support for P2P device in adding and removing interface

[Arend van Spriel]

On 02/17/2013 08:52 AM, Spinadel, David wrote:
>> -----Original Message-----
>> From: Arend van Spriel [mailto:arend at broadcom.com]
>> Sent: Sunday, February 17, 2013 09:47
>> To: Spinadel, David
>> Cc: Johannes Berg; hostap at lists.shmoo.com; Jouni Malinen
>> Subject: Re: [RFC 06/10] nl80211_driver: add support for P2P device in adding
>> and removing interface
>>
>> On 02/17/2013 07:42 AM, Spinadel, David wrote:
>>>>>>>> That's not really necessary, unless you want to have a single P2P
>>>>>>>> Device interface shared between multiple devices, no?
>>>>>>>
>>>>>>> Correct, but it seems to make sense to accommodate for it instead
>>>>>>> of doing another patch later on (although the patch went in for
>>>>>>> v3.9, right?). Just a comment, I leave it to David what to do with it.
>>>>>>>
>>>>>> I don't think it required, since wpa_supplicant has only one P2P
>>>>>> state machine, I don't see a reason to deal with more than one P2P
>>>> device.
>>>>>
>>>>> I think the idea behind it was that you could have a 2.4/5 GHz
>>>>> device and a 60 GHz device and have them both use the same P2P
>>>>> Device Address so you can use them interchangeably.
>>>>
>>>> That is indeed how I understood the explanation from Jouni (see
>>>> attached email). I think it is actually about the mac address that
>>>> ends up in the action frame header.
>>>>
>>> Actually it's not going to work now, since the p2p state machine will always
>> call the callbacks on the same interface. And there is a problem when you try
>> to do something on one interface and it's running on other one - the events
>> are raising on a wrong interface and I don't know how it should work.
>>> I think it's better to prevent enabling p2p on more than one interface (set
>> p2p_disabled on by default and enable it explicitly if needed in the config
>> file)?
>>
>> I see. As the use-case seems valid the p2p state machine will need quite
>> some rework or a more abstract interface that takes care of selecting the
>> appropriate interface. I agree it is better to stick to one interface for now and
>> make that work (maybe it already does, but I still need to test your patches ;-
>> ) ).
>>
> Actually there some bugs, I'll resend it later. And there is another patch that disables p2p by default to be sure that we are not enabling more than one p2p interface concurrently. 
> I guess you are not going to work on it today...

I am if my 4 year old does not interrupt me :-p No rush though as I have
no equipment at home to test with.

Thanks,
Arend