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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).