All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Arend van Spriel" <arend@broadcom.com>
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: "John W. Linville" <linville@tuxdriver.com>,
	"John W. Linville" <linville@redhat.com>,
	"David Spinadel" <david.spinadel@intel.com>,
	linux-wireless@vger.kernel.org
Subject: Re: P2P support in brcmfmac
Date: Wed, 27 Mar 2013 15:29:59 +0100	[thread overview]
Message-ID: <51530267.5020705@broadcom.com> (raw)
In-Reply-To: <1364388675.8388.5.camel@jlt4.sipsolutions.net>

On 03/27/2013 01:51 PM, Johannes Berg wrote:
> On Wed, 2013-03-27 at 08:44 -0400, John W. Linville wrote:
>> On Wed, Mar 27, 2013 at 01:34:58PM +0100, Johannes Berg wrote:
>>> On Wed, 2013-03-27 at 08:22 -0400, John W. Linville wrote:
>>>> On Wed, Mar 27, 2013 at 12:51:35PM +0100, Arend van Spriel wrote:
>>>>
>>>>> In 3.9 we introduced P2P support in brcmfmac which was functional using
>>>>> current wpa_supplicant P2P support, but we did not yet support the
>>>>> P2P_DEVICE user-space API.
>>>>>
>>>>> Last week I enabled that in brcmfmac testing it with wpa_supplicant
>>>>> patches for P2P_DEVICE support from David Spinadel. So I do have a
>>>>> couple of brcmfmac patches to make that work and would like to submit
>>>>> those for 3.9 although it is not strictly a bug fix. Would you consider
>>>>> taking these?
>>>>
>>>> That doesn't sound to me like something that would be worthy of such
>>>> an exception.
>>>
>>> Maybe just make a small patch to disable the other API, so we don't end
>>> up having to support both?
>>
>> Maybe I misunderstood.  So brcmfmac currently supports a P2P API
>> that is not otherwise available and which we don't want to support
>> in the future?
> 
> As I understand it, brcmfmac currently supports having a P2P device
> *netdev*, which is of (wireless) type STATION (presumably), which isn't
> something we want to support (well, I don't anyway, it's difficult to
> discover for applications).

It is a bit more subtle. After the merge window since 3.9-rc1 brcmfmac
supports to have a P2P device *wireless dev* WITH a netdev associated as
the old wpa_supplicant needed a network interface. However, this
interface is only created when the driver is loaded with a module
parameter p2pon set to 1.

So brcmfmac announces P2P_DEVICE support in wiphy information. This will
cause wpa_supplicant (with P2P device patches) to create a
*wireless_dev* interface of P2P_DEVICE type.

> The "correct" way (the way I decided to implement this P2P device
> concept in the upstreamtree ) is to have a P2P device *wireless dev*
> which has no netdev associated -- this makes more sense since no data
> frames are ever transmitted or received on a P2P device.

True and I made additional patches on top of 3.9-rc1 that add support
for creating the "correct" P2P device *wireless_dev* through user-space.

> As I understand Arend, he was suggesting to put patches into 3.9 that
> would move brcmfmac from the interim API with a netdev he had used for
> testing to the final API that is actually implemented in 3.9 but before
> the wpa_supplicant patches had no way to get used. Now those patches are
> there in wpa_supplicant though (or well, on their way in)

The interim patches went in 3.9-rc1 so they end up in 3.9 without
nl80211 user-space support. I am now suggesting to add that nl80211
user-space support for 3.9 as well. As you indicated you do not consider
this as an exception to the bugfix rule, I will have to look what
happens when the new wpa_supplicant (with P2P device patches) tries to
use the 3.9-rc1 brcmfmac.

Regards,
Arend


  parent reply	other threads:[~2013-03-27 14:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-27 11:51 P2P support in brcmfmac Arend van Spriel
2013-03-27 12:22 ` John W. Linville
2013-03-27 12:34   ` Johannes Berg
2013-03-27 12:44     ` John W. Linville
2013-03-27 12:51       ` Johannes Berg
2013-03-27 13:04         ` John W. Linville
2013-03-27 14:29         ` Arend van Spriel [this message]
2013-03-27 14:38           ` Johannes Berg
2013-03-27 14:54             ` Arend van Spriel
2013-03-27 15:10               ` John W. Linville

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51530267.5020705@broadcom.com \
    --to=arend@broadcom.com \
    --cc=david.spinadel@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@redhat.com \
    --cc=linville@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.