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:54:35 +0100 [thread overview]
Message-ID: <5153082B.6080000@broadcom.com> (raw)
In-Reply-To: <1364395136.8388.9.camel@jlt4.sipsolutions.net>
On 03/27/2013 03:38 PM, Johannes Berg wrote:
> On Wed, 2013-03-27 at 15:29 +0100, Arend van Spriel wrote:
>
>>> 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.
>
> Oh, funky, I had no idea.
>
>> However, this
>> interface is only created when the driver is loaded with a module
>> parameter p2pon set to 1.
>
> You could just remove the module parameter then?
>
It kind of depends what mix of kernel and wpa_supplicant an OEM or
distro would select. There may be use-cases where they would need p2pon
parameter to have P2P functionality.
>> 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.
>
> Right, but this wouldn't work because you don't support the interface
> creation, so it would really just be an attempt to create it?
>
Sure. Just thought it would be better to avoid the attempt.
>> 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.
>
> Or you could just remove the module parameter *and* advertisting the
> P2P_DEVICE interface type, that would be a very small patch to "fix" the
> API by disabling it for that kernel version. OTOH, I'm not sure if
> that's a concern for you. For me, it wouldn't be a concern because we
> mostly use compat-wireless anyway, but your situation might be
> different.
That is indeed what I guessed the patch should look like, which would
make P2P unavailable for 3.9 regardless the wpa_supplicant version used.
But indeed there is always compat-drivers aka. compat-wireless so I am
not that concerned.
Gr. AvS
next prev parent reply other threads:[~2013-03-27 14:54 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
2013-03-27 14:38 ` Johannes Berg
2013-03-27 14:54 ` Arend van Spriel [this message]
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=5153082B.6080000@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.