Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Cc: "Luis R . Rodriguez" <rodrigue@qca.qualcomm.com>,
	Jouni Malinen <jouni@qca.qualcomm.com>,
	"John W . Linville" <linville@tuxdriver.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC] P2P find offload
Date: Thu, 07 Mar 2013 11:08:58 +0100	[thread overview]
Message-ID: <1362650938.8694.21.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <7076584.7eoLUXqF3A@lx-vladimir>

On Thu, 2013-03-07 at 11:31 +0200, Vladimir Kondratiev wrote:

>  /**
> + * struct cfg80211_p2p_find_params - parameters for P2P find
> + * @probe_ie: IE's for probe frames
> + * @probe_ie_len: length, bytes, of @probe_ie
> + * @probe_resp_ie: IE's for probe response frames
> + * @probe_resp_ie_len: length, bytes, of @probe_resp_ie
> + * @n_channels: number of channels to operate on
> + * @channels: channels to operate on
> + */
> +struct cfg80211_p2p_find_params {
> +	const u8 *probe_ie;
> +	size_t probe_ie_len;
> +	const u8 *probe_resp_ie;
> +	size_t probe_resp_ie_len;
> +
> +	int n_channels;
> +	/* Up to 4 social channels: 3 in 2.4GHz band + 1 in 60GHz band */
> +	struct ieee80211_channel *channels[4];

Hmm, is 4 really a good limit? If you wanted to implement progressive
search as part of the find, for example, you'd need more? It seems like
a pretty arbitrary limit -- should it be advertised to userspace?

> + * start_p2p_find: start P2P find phase
> + *	Parameters include IEs for probe/probe resp and channels to operate on

The parameters?

you could spell out "resp" ...

Also needs a period (".") at the end or so, if the sentence runs on in
the next line it doesn't make sense.

> + *	Parameters are not retained after call, driver need to copy data if
> + *	it need it later.
> + * stop_p2p_find: stop P2P find phase
> + *

don't need that blank line

> +	i = 0;
> +	if (attr_freq) {

i can be inside the if()?

> +		/* user specified, bail out if channel not found */
> +		nla_for_each_nested(attr, attr_freq, tmp) {
> +			struct ieee80211_channel *chan;
> +
> +			chan = ieee80211_get_channel(wiphy, nla_get_u32(attr));
> +
> +			if (!chan)
> +				return -EINVAL;
> +
> +			/* ignore disabled channels */
> +			if (chan->flags & IEEE80211_CHAN_DISABLED)
> +				continue;

I think you should reject them, also if they have passive scan or
various other flags set, I think?

> +			params.channels[i] = chan;
> +			i++;
> +		}
> +		if (!i)
> +			return -EINVAL;
> +	}
> +
> +	params.n_channels = i;

if you also move that assignment

> +	i = 0;

Not needed.

> +	attr = info->attrs[NL80211_ATTR_IE];
> +	if (attr) {

This is not typically done in nl80211, I'd prefer not having the
variable I think.

> +	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> +	if (!msg)
> +		return -ENOMEM;
> +
> +	hdr = nl80211hdr_put(msg, info->snd_portid, info->snd_seq, 0,
> +			     NL80211_CMD_START_P2P_FIND);

Err? What's the value of sending a reply back here? It would seem maybe
appropriate to send one when it *actually* started, but you haven't
implemented that.

> +	hdr = nl80211hdr_put(msg, info->snd_portid, info->snd_seq, 0,
> +			     NL80211_CMD_STOP_P2P_FIND);

same here ...

You're also entirely missing feature advertising, so userspace can only
guess whether it's supported or not ...

johannes


  reply	other threads:[~2013-03-07 10:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-27 12:24 [RFC] P2P find offload Vladimir Kondratiev
2013-03-04 15:47 ` Johannes Berg
2013-03-07  7:10   ` Vladimir Kondratiev
2013-03-07  9:31     ` Vladimir Kondratiev
2013-03-07 10:08       ` Johannes Berg [this message]
2013-03-07 10:11         ` Johannes Berg
2013-03-07 14:10         ` Vladimir Kondratiev
2013-03-10 15:43           ` Vladimir Kondratiev
2013-03-15 18:40             ` Johannes Berg
2013-03-17  8:56               ` Vladimir Kondratiev
2013-03-18 20:31                 ` Johannes Berg
     [not found]                   ` <3959922.dEpYdEMVAq@lx-vladimir>
2013-03-19 20:27                     ` Johannes Berg
2013-03-15 15:51           ` Johannes Berg
2013-03-07 10:01     ` Johannes Berg

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=1362650938.8694.21.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