linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Wetzel <alexander@wetzel-home.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v3 03/12] mac80211: IEEE 802.11 Extended Key ID support
Date: Fri, 1 Mar 2019 21:43:43 +0100	[thread overview]
Message-ID: <95ba87e8-d7d2-53ae-f2c8-d4656dc1d29a@wetzel-home.de> (raw)
In-Reply-To: <767ada740d984e180d0ac799487722293a50367c.camel@sipsolutions.net>

>>> So here the reasoning for why I named them as they are and why I  prefer
>>> the names used in the patch.
>>> First, many drivers will handle SET_KEY and SET_KEY_RX_ONLY with the
>>> same code and not differentiate between those at all. Using EXT_as a
>>> prefix for the "normal" command is therefore a nice way to imply the
>>> command can only be used with Extended Key ID and still link it to the
>>> original command.
>>> But more important for me was the clash between what the command spells
>>> and what it does in the COMPAT mode: SET_KEY_RX_ONLY would then be used
>>> to install a TX only key which never can be used by the card for Rx.
>>> So I decided to rename it to EXT_SET_KEY, just indicating that this
>>> command adds a new key to the card for Extended Key ID and drop the
>>> confusing reference to Rx.
> Wait, what? In compat mode SET_KEY_RX_ONLY installs a TX-only key? Ah,
> you mean before you changed this.
> 
> Why don't we split out compat mode then?
> 
> But I see where you're coming from with the EXT_ now. I need to think of
> it less as an "extension" now, but as "extended key ID". I'm not really
> entirely sure that makes sense - even what we think of as "extended key
> ID" now might be the new normal soon? But then again the spec does the
> same thing.
> 
>>> Long story short: Using SET_KEY_RXONLY and SET_KEY_TX is not wrong, but
>>> I would rate them more confusing.
> Fair enough.

I've had second (or more like tenths..) thoughts about this API.
If you like any of the solutions below more than the others I'll use 
that in the next patch, of course...

In a nutshell, the point of EXT_SET_KEY is to install a key, prepare it 
for Tx but NOT use it for Tx. The driver can use it for Rx (NATIVE) or 
just do nothing with the (in COMPAT mode) Tx only key till mac80211 
starts using it for Tx later.

1) Assuming we keep the RX_ONLY key flag we could just drop EXT_SET_KEY 
and  use the "normal" SET_KEY with the flag moved to ieee80211_key_conf.
We really just want to install the key to the driver here, only drivers 
like ath10k need a way to figure out it must not be used for Tx.

2) We also can drop the Rx only flag/extra command and simply use 
SET_KEY. ath10k will then have to honor the keyID mac80211 prepared when 
it want to support Extended Key ID. (ath10k seems to need a firmware 
update either way, so that could be acceptable.)

That said I've now decided to simply name the calls in the next patch:
SET_KEY	
	-> no RX only flag!
SET_KEY_RX
	-> SET_KEY, only key must not be used for Tx
DISABLE_KEY,
	-> unchanged
ACTIVATE_KEY
	-> so far named EXT_KEY_RX_TX
DISABLE_KEY_RX
	-> so far named EXT_DISABLE_KEY_RX

We can then continue the discussion with a new patch and the other fixes 
in it when needed.
To really clean that up we would have to change the existing names to 
something like ADD_KEY, REMOVE_KEY. We could then name the new calls 
ADD_KEY_RX, ACTIVATE_KEY and DISABLE_KEY_RX. But that seems to be overkill.

Alexander

Alexander

  parent reply	other threads:[~2019-03-01 20:43 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-10 21:06 [RFC PATCH v3 00/12] Draft for Extended Key ID support Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 01/12] mac80211: Optimize tailroom_needed update checks Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 02/12] nl80211/cfg80211: Extended Key ID support Alexander Wetzel
2019-02-15 10:52   ` Johannes Berg
2019-02-17 19:19     ` Alexander Wetzel
2019-02-22  8:30       ` Johannes Berg
2019-02-22 23:04         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 03/12] mac80211: IEEE 802.11 " Alexander Wetzel
2019-02-15 11:06   ` Johannes Berg
2019-02-19 20:58     ` Alexander Wetzel
2019-02-21 19:47       ` Alexander Wetzel
2019-02-22  8:41         ` Johannes Berg
2019-02-23 21:02           ` Alexander Wetzel
2019-03-01 20:43           ` Alexander Wetzel [this message]
2019-02-23 17:26         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 04/12] mac80211: Compatibility " Alexander Wetzel
2019-02-15 11:09   ` Johannes Berg
2019-02-21 20:07     ` Alexander Wetzel
2019-02-22  8:53       ` Johannes Berg
2019-02-23 22:50         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 05/12] mac80211: Mark A-MPDU keyid borders for drivers Alexander Wetzel
2019-02-15 11:50   ` Johannes Berg
2019-02-21 21:20     ` Alexander Wetzel
2019-02-22  8:51       ` Johannes Berg
2019-02-23 21:47         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 06/12] mac80211_hwsim: Ext Key ID support (NATIVE) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 07/12] iwlwifi: Extended " Alexander Wetzel
2019-02-15 11:52   ` Johannes Berg
2019-02-22 20:50     ` Alexander Wetzel
2019-02-22 21:06       ` Johannes Berg
2019-02-24 13:04         ` Alexander Wetzel
2019-04-08 20:10           ` Johannes Berg
2019-04-10 20:46             ` Alexander Wetzel
2019-04-12  9:51               ` Johannes Berg
2019-04-14 16:12                 ` Alexander Wetzel
2019-04-15  8:44                   ` Johannes Berg
2019-04-15 20:09                     ` Alexander Wetzel
2019-04-16  9:31                       ` Johannes Berg
2019-04-16 18:28                         ` Alexander Wetzel
2019-04-16 19:11                           ` Johannes Berg
2019-04-16 21:32                             ` Alexander Wetzel
2019-04-12 11:19               ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 08/12] iwlwifi: dvm - EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:54   ` Johannes Berg
2019-02-22 21:15     ` Alexander Wetzel
2019-02-22 21:20       ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 09/12] ath: Basic Extended Key ID support (COMPAT+NATIVE) Alexander Wetzel
2019-02-13 11:05   ` Kalle Valo
2019-02-13 23:15     ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 10/12] ath5k: ath_key_config() API compatibility update Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 11/12] ath9k: Extended Key ID support (COMPAT) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 12/12] ath9k: EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:10 ` [RFC PATCH v3 00/12] Draft for Extended Key ID support Johannes Berg
2019-02-21 20:44   ` Alexander Wetzel

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=95ba87e8-d7d2-53ae-f2c8-d4656dc1d29a@wetzel-home.de \
    --to=alexander@wetzel-home.de \
    --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).