Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Cc: linux-wireless@vger.kernel.org,
	"Luis R . Rodriguez" <rodrigue@qca.qualcomm.com>,
	"John W . Linville" <linville@tuxdriver.com>,
	Jouni Malinen <jouni@qca.qualcomm.com>
Subject: Re: [PATCH v6] cfg80211: P2P find phase offload
Date: Tue, 07 May 2013 18:35:28 +0200	[thread overview]
Message-ID: <1367944528.8328.64.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <3561208.okpkftdEFW@lx-vladimir>

On Tue, 2013-05-07 at 19:27 +0300, Vladimir Kondratiev wrote:

> > starting the p2p find? I mean, it seems that should implicitly enable
> > the filter? Or is there a reason you think this command would be useful
> > _without_ enabling the filter??
> 
> Packet filtering already managed by the wpa_sup; and is kind of orthogonal
> to the p2p flows. Yes, wpa_sup need to assemble reasonable combinations to
> make whole system work. I want wpa_sup to take care of packet filtering;
> it deals with filtering within the cfg80211_rx_mgmt().
> 
> wpa_sup may have its own idea for filtering, it may be more restrictive
> then just pass all probe-request and probe-response frames.
> 
> Technically it is possible to call cfg80211_mlme_register_mgmt and
> cfg80211_mlme_unregister_socket, but then I need to save nlportid, and it
> becomes more complicated then it is when wpa_sup takes care of filtering.

Yeah, never mind. That isn't really filtering but the reporting, which
may be tied to filtering internally to the driver (but that makes sense,
if nobody cares about the frame it can drop them.)

> > Please clarify whether or not this should be called when a stop is
> > explicitly requested by userspace. I don't think it's all that useful,
> > and if required maybe cfg80211 should send the event itself instead of
> > having the driver do it?
> 
> There may be delay between request from wpa_sup and actual end of p2p find.
> I want wpa_sup to know when p2p find actually get finished; for timing/race
> reasons.

Yes, but I think you should then document that the driver must call this
even when requested by cfg80211 to stop.

johannes


      reply	other threads:[~2013-05-07 16:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-29 11:40 [PATCH v6] cfg80211: P2P find phase offload Vladimir Kondratiev
2013-04-29 11:40 ` Vladimir Kondratiev
2013-05-07 14:10   ` Johannes Berg
2013-05-07 16:27     ` Vladimir Kondratiev
2013-05-07 16:35       ` Johannes Berg [this message]

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=1367944528.8328.64.camel@jlt4.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=jouni@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=qca_vkondrat@qca.qualcomm.com \
    --cc=rodrigue@qca.qualcomm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox