linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Zhu Yi <yi.zhu@intel.com>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
	Samuel Ortiz <samuel.ortiz@intel.com>
Subject: Re: [PATCH 1/2] wireless: move some utility functions from mac80211 to cfg80211
Date: Thu, 21 May 2009 11:32:22 +0200	[thread overview]
Message-ID: <1242898342.5471.12.camel@johannes.local> (raw)
In-Reply-To: <1242872340-27417-2-git-send-email-yi.zhu@intel.com>

[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]

On Thu, 2009-05-21 at 10:18 +0800, Zhu Yi wrote:

> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -752,6 +752,32 @@ enum wiphy_params_flags {
>  };
>  
>  /**
> + * enum ieee80211_key_alg - key algorithm
> + * @ALG_WEP: WEP40 or WEP104
> + * @ALG_TKIP: TKIP
> + * @ALG_CCMP: CCMP (AES)
> + * @ALG_AES_CMAC: AES-128-CMAC
> + */
> +enum ieee80211_key_alg {
> +	ALG_WEP,
> +	ALG_TKIP,
> +	ALG_CCMP,
> +	ALG_AES_CMAC,
> +};
> +
> +/**
> + * enum ieee80211_key_len - key length
> + * @LEN_WEP40: WEP 5-byte long key
> + * @LEN_WEP104: WEP 13-byte long key
> + */
> +enum ieee80211_key_len {
> +	LEN_WEP40 = 5,
> +	LEN_WEP104 = 13,
> +	LEN_CCMP = 16,
> +	LEN_TKIP = 32,
> +};

This doesn't seem appropriate. ALG_* is purely mac80211 internals, and
shouldn't be in cfg80211's API since cfg80211 uses u32 values as cipher
suite specifiers. Why do you need these?

And if you want to move the key lengths they probably should be in
ieee80211.h, have a proper prefix and also be used within cfg80211
itself...

> +/* Default mapping in classifier to work with default queue setup. */
> +const int ieee802_1d_to_ac[8] = { 2, 3, 3, 2, 1, 1, 0, 0 };
> +EXPORT_SYMBOL(ieee802_1d_to_ac);

That seems a little odd, unless we want to specify how the default queue
setup should be ... which seems to make no sense. It probably will be
like this most of the time, but still, should this really be mandated by
cfg80211? There seems to be no reason to do that. I'd rather keep this
in every driver since the drivers may differ, and changing this for
mac80211 is unlikely.

> +int ieee80211_data_to_8023(struct sk_buff *skb, struct net_device *dev,
> +                          enum nl80211_iftype iftype)

Should probably pass in dev->dev_addr instead of dev for this and the
other direction? OTOH, I suppose it only makes sense to be used for a
netdev.


> 
> +u16 cfg80211_classify80211(struct sk_buff *skb)
> +{
> +       struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
> +
> +       if (!ieee80211_is_data(hdr->frame_control)) {
> +               /* management frames go on AC_VO queue, but are sent
> +                * without QoS control fields */
> +               return 0;
> +       }
> +
> +       if (ieee80211_is_data_qos(hdr->frame_control))
> +               skb->priority = cfg80211_classify8021d(skb);
> +       else
> +               skb->priority = 0;
> +
> +       return ieee802_1d_to_ac[skb->priority];
> +}
> +EXPORT_SYMBOL(cfg80211_classify80211);

If you pass in suitable information for the ACM downgrade, it seems you
can move over that code too and remove one export. If your device
supports ACM you can always pass in 0 for the ACM bitfield, I think? It
seems a little weird to have this function and then write it in a way
mac80211 can't use it.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  parent reply	other threads:[~2009-05-21  9:32 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-21  2:18 [Announce] Intel Wireless Multicomm 3200 WiFi driver Zhu Yi
2009-05-21  2:18 ` [PATCH 1/2] wireless: move some utility functions from mac80211 to cfg80211 Zhu Yi
2009-05-21  2:19   ` [PATCH 2/2] iwmc3200wifi: Add new Intel Wireless Multicomm 802.11 driver Zhu Yi
2009-05-21  2:54     ` Luis R. Rodriguez
2009-05-21  3:13       ` Zhu Yi
2009-05-21  7:12   ` [PATCH 1/2] wireless: move some utility functions from mac80211 to cfg80211 drago01
2009-05-21  7:09     ` Zhu Yi
2009-05-21  9:21       ` Johannes Berg
2009-05-21 13:38         ` John W. Linville
2009-05-21 13:56           ` Johannes Berg
2009-05-21 14:10             ` Gábor Stefanik
2009-05-21 14:41             ` John W. Linville
2009-05-21 14:54               ` Johannes Berg
2009-05-21  9:32   ` Johannes Berg [this message]
2009-05-21 11:53     ` Zhu, Yi
2009-05-21 16:10 ` [Announce] Intel Wireless Multicomm 3200 WiFi driver Johannes Berg
2009-05-21 17:54   ` Gábor Stefanik
2009-05-21 17:57     ` Johannes Berg
2009-05-21 18:23       ` Gábor Stefanik
2009-05-26 22:24 ` Luis R. Rodriguez
2009-05-31  2:17   ` Zhu Yi
2009-05-31  6:27     ` Luis R. Rodriguez
2009-05-31  6:42       ` Zhu Yi
2009-05-31 12:10         ` Maxim Levitsky
2009-05-31 12:20           ` Gábor Stefanik
2009-06-01  1:29           ` Zhu Yi
2009-06-01 22:52             ` Luis R. Rodriguez
2009-06-02  7:36               ` Zhu Yi
2009-06-01 23:00         ` Luis R. Rodriguez
2009-06-02  7:42           ` Zhu Yi
2009-06-02 16:53             ` Luis R. Rodriguez

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=1242898342.5471.12.camel@johannes.local \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=samuel.ortiz@intel.com \
    --cc=yi.zhu@intel.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;
as well as URLs for NNTP newsgroup(s).