From: "Arend van Spriel" <arend@broadcom.com>
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH V6] cfg80211: introduce critical protocol indication from user-space
Date: Tue, 16 Apr 2013 23:19:09 +0200 [thread overview]
Message-ID: <516DC04D.9090204@broadcom.com> (raw)
In-Reply-To: <1366121523.8244.23.camel@jlt4.sipsolutions.net>
On 04/16/2013 04:12 PM, Johannes Berg wrote:
>
>
>> I reworked the patch based on your comment in this V6. It
>> applies to the master branch on top of commit:
>>
>> 5253ffb mac80211: always pick a basic rate to tx RTS/CTS for pre-HT rates
>
> Yep, applies, thanks. I think you missed something, I can fix it but
> wanted to ask:
>
>
>> + * @crit_proto_started: true if crit_proto_start() has been done.
>> */
>> struct wireless_dev {
>
>> + bool crit_proto_started;
>
> This is no longer needed, right?
>
oops. That should go indeed.
>> + NL80211_CMD_CRIT_PROTOCOL_START,
>> + NL80211_CMD_CRIT_PROTOCOL_STOP,
>> + NL80211_CMD_CRIT_PROTOCOL_STOPPED_EVENT,
>
> Why use a separate command ID? Usually we use the same _STOP for the
> event as well, I think? Except maybe scan which you can't stop? Not
> sure ... Anyway I don't mind, just wondering if there was a special
> reason to do this.
>
This is my first nl80211 event :-) I looked at the ft_event thingy. I am
fine using the _STOP instead.
>> + nla_put_failure:
>> + if (hdr)
>> + genlmsg_cancel(msg, hdr);
>
> There's not really a reason to cancel, but we still do most of the time.
> I guess we can keep it, but it doesn't matter :)
If it not really needed it may call for separate patch removing all
occurrences?
>> --- a/net/wireless/rdev-ops.h
>> +++ b/net/wireless/rdev-ops.h
>> @@ -875,7 +875,7 @@ static inline void rdev_stop_p2p_device(struct cfg80211_registered_device *rdev,
>> trace_rdev_stop_p2p_device(&rdev->wiphy, wdev);
>> rdev->ops->stop_p2p_device(&rdev->wiphy, wdev);
>> trace_rdev_return_void(&rdev->wiphy);
>> -}
>> +}
>
> Heh, thanks.
Have to thank my editor, I guess. Trailing whitespace?
Gr. AvS
next prev parent reply other threads:[~2013-04-16 21:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-08 9:09 [PATCH] cfg80211: introduce critical protocol indication from user-space Arend van Spriel
2013-04-09 10:06 ` Johannes Berg
2013-04-09 19:54 ` Arend van Spriel
2013-04-09 20:42 ` Johannes Berg
2013-04-10 11:49 ` Arend van Spriel
2013-04-10 13:21 ` Johannes Berg
2013-04-11 10:47 ` Arend van Spriel
2013-04-11 12:34 ` Johannes Berg
2013-04-11 10:39 ` [PATCH V6] " Arend van Spriel
2013-04-16 14:12 ` Johannes Berg
2013-04-16 21:19 ` Arend van Spriel [this message]
2013-04-16 21:43 ` 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=516DC04D.9090204@broadcom.com \
--to=arend@broadcom.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/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.