On Tue, 2015-06-02 at 21:39 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.b...@intel.com>
>
> As we're running out of hardware capability flags pretty quickly,
> convert them to use the regular test_bit() style unsigned long
> bitmaps.
I think this is nice, thanks.
> diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
[]
> @@ -1369,9 +1369,9 @@ static void adm8211_configure_filter(struct
> ieee80211_hw *dev,
[]
> - dev->flags |= IEEE80211_HW_RX_INCLUDES_FCS;
> + ieee80211_hw_set(dev, RX_INCLUDES_FCS);
[]
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
[]
> @@ -1889,35 +1889,38 @@ struct ieee80211_txq {
[]
> enum ieee80211_hw_flags {
> - IEEE80211_HW_HAS_RATE_CONTROL = 1<<0,
> - IEEE80211_HW_RX_INCLUDES_FCS = 1<<1,
[]
> + IEEE80211_HW_HAS_RATE_CONTROL,
> + IEEE80211_HW_RX_INCLUDES_FCS,
It may be nicer to use specified bit numbers here.
It may make compatibility easier and maybe it should be
written down that new entries are only to be added at
the bottom of the enum and not inserted in the middle.
[]
> +static inline bool _ieee80211_hw_check(struct ieee80211_hw *hw,
> + enum ieee80211_hw_flags flg)
> +{
> + return test_bit(flg, hw->flags);
> +}
> +#define ieee80211_hw_check(hw, flg) _ieee80211_hw_check(hw,
> IEEE80211_HW_##flg)
> +
> +static inline void _ieee80211_hw_set(struct ieee80211_hw *hw,
> + enum ieee80211_hw_flags flg)
> +{
> + return __set_bit(flg, hw->flags);
> +}
This is similar to the broadcom tg3 driver, but a little different.
The mechanism in tg3 compared to ieee80211_hw is
tg3_flag ieee80211_hw_check
tg3_flag_set ieee80211_hw_set
tg3_flag_clear ?
Would a ieee80211_hw_clear be useful?
Would it be clearer without the _check?
> static ssize_t hwflags_read(struct file *file, char __user *user_buf,
> size_t count, loff_t *ppos)
> {
[]
> + for (i = 0; i < NUM_IEEE80211_HW_FLAGS; i++) {
> + if (test_bit(i, local->hw.flags))
Maybe use the ieee80211_hw_check() function?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
