* Re: [PATCH 2/9] rt2800: increase TX timeout
From: Stanislaw Gruszka @ 2017-01-06 15:34 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Helmut Schaa, Mathias Kresin
In-Reply-To: <ce1a213e-19fe-83fa-e037-a5fefa88284e@nbd.name>
On Fri, Jan 06, 2017 at 04:15:40PM +0100, Felix Fietkau wrote:
> On 2017-01-06 14:05, Stanislaw Gruszka wrote:
> > When medium is busy or frames have to be resend, it takes time to send
> > the frames and get TX status from hardware. For some really bad medium
> > conditions it can take seconds. Patch change TX status timeout to give
> > HW more time to provide it, however 500ms is not enough for bad
> > conditions. In the future this timeout should be removed and replaced
> > with proper watchdog mechanism.
> >
> > Increase flush timeout accordingly as well.
> >
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> By the way, to make tx status reporting more robust, I would suggest
> mapping tx fifo status to skb only for frames where
> IEEE80211_TX_CTL_REQ_TX_STATUS is set. For all other frames, set PID=0
> and return the status using ieee80211_tx_status_noskb.
> I did the same in mt76 and it works quite well.
Good idea, thanks!
Stanislaw
^ permalink raw reply
* [RFC] ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS
From: Christian Lamparter @ 2017-01-06 15:48 UTC (permalink / raw)
To: QCA ath9k Development, linux-wireless, ath9k-devel; +Cc: Kalle Valo
Currently, the common ath9k_common module needs to have a
dependency on RELAY and DEBUG_FS in order to built. This
is usually not a problem. But for RAM and FLASH starved
AR71XX devices, every little bit counts.
This patch adds a new symbol CONFIG_ATH9K_COMMON_DEBUG
which makes it possible to drop the RELAY and DEBUG_FS
dependency there and move it to ATH_(HTC)_DEBUGFS.
Note: The shared FFT/spectral code (which is the only user
of the relayfs in ath9k*) needs DEBUG_FS to export the relayfs
interface to dump the data to userspace. So it makes no sense
to have the functions compiled in, if DEBUG_FS is not there.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
Here are some numbers for my WD Range Extender (AR7370 with a AR9300):
For both configurations MAC80211_DEBUGFS and ATH_DEBUG is disabled.
(if they are enabled, there should be no change). All sizes are in
bytes. And I only test with or without the patch applied.
module | file size | .text size |
ath9k_common.ko (w/o) | 32208 | 12832 |
ath9k_common.ko (with) | 12204 | 3456 |
Note: The kernel with the patch, doesn't need RELAY support anymore.
Therefore it shrinks a bit as well.
| lzma uimage size | .text size |
kernel (w/o) | 1181777 | 3004592 |
kernel (with) | 1179666 | 2999448 |
If anyone wants to play with it, I made a test-patch For LEDE [0].
Just remember to disable CONFIG_PACKAGE_MAC80211_DEBUGFS and
CONFIG_PACKAGE_ATH_DEBUG.
There are more ways to do this. Let's hear if there's support for
it or not. The main motivation was that relayfs can be very costly
on the RAM as well (on ath10k in can eat like 4MiB with VM
debugging etc...).
[0] <https://github.com/chunkeey/apm82181-lede/commit/5ef8d4e6497b0b41f0c562650347251e96d73ec8>
---
---
drivers/net/wireless/ath/ath9k/Kconfig | 9 ++++++--
drivers/net/wireless/ath/ath9k/Makefile | 5 +++--
drivers/net/wireless/ath/ath9k/common-debug.h | 27 ++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/common-spectral.c | 2 +-
drivers/net/wireless/ath/ath9k/common-spectral.h | 23 ++++++++++++++++++++
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 2 +-
8 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index 8f231c67dd51..783a38f1a626 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -3,8 +3,8 @@ config ATH9K_HW
config ATH9K_COMMON
tristate
select ATH_COMMON
- select DEBUG_FS
- select RELAY
+config ATH9K_COMMON_DEBUG
+ bool
config ATH9K_DFS_DEBUGFS
def_bool y
depends on ATH9K_DEBUGFS && ATH9K_DFS_CERTIFIED
@@ -60,12 +60,14 @@ config ATH9K_DEBUGFS
bool "Atheros ath9k debugging"
depends on ATH9K && DEBUG_FS
select MAC80211_DEBUGFS
+ select ATH9K_COMMON_DEBUG
select RELAY
---help---
Say Y, if you need access to ath9k's statistics for
interrupts, rate control, etc.
Also required for changing debug message flags at run time.
+ As well as access to the FFT/spectral data and TX99.
config ATH9K_STATION_STATISTICS
bool "Detailed station statistics"
@@ -174,8 +176,11 @@ config ATH9K_HTC
config ATH9K_HTC_DEBUGFS
bool "Atheros ath9k_htc debugging"
depends on ATH9K_HTC && DEBUG_FS
+ select ATH9K_COMMON_DEBUG
+ select RELAY
---help---
Say Y, if you need access to ath9k_htc's statistics.
+ As well as access to the FFT/spectral data.
config ATH9K_HWRNG
bool "Random number generator support"
diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile
index 76f9dc37500b..36a40ffdce15 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -60,8 +60,9 @@ obj-$(CONFIG_ATH9K_COMMON) += ath9k_common.o
ath9k_common-y:= common.o \
common-init.o \
common-beacon.o \
- common-debug.o \
- common-spectral.o
+
+ath9k_common-$(CONFIG_ATH9K_COMMON_DEBUG) += common-debug.o \
+ common-spectral.o
ath9k_htc-y += htc_hst.o \
hif_usb.o \
diff --git a/drivers/net/wireless/ath/ath9k/common-debug.h b/drivers/net/wireless/ath/ath9k/common-debug.h
index 7c9788490f7f..3376990d3a24 100644
--- a/drivers/net/wireless/ath/ath9k/common-debug.h
+++ b/drivers/net/wireless/ath/ath9k/common-debug.h
@@ -60,6 +60,7 @@ struct ath_rx_stats {
u32 rx_spectral;
};
+#ifdef CONFIG_ATH9K_COMMON_DEBUG
void ath9k_cmn_debug_modal_eeprom(struct dentry *debugfs_phy,
struct ath_hw *ah);
void ath9k_cmn_debug_base_eeprom(struct dentry *debugfs_phy,
@@ -70,3 +71,29 @@ void ath9k_cmn_debug_recv(struct dentry *debugfs_phy,
struct ath_rx_stats *rxstats);
void ath9k_cmn_debug_phy_err(struct dentry *debugfs_phy,
struct ath_rx_stats *rxstats);
+#else
+static inline void ath9k_cmn_debug_modal_eeprom(struct dentry *debugfs_phy,
+ struct ath_hw *ah)
+{
+}
+
+static inline void ath9k_cmn_debug_base_eeprom(struct dentry *debugfs_phy,
+ struct ath_hw *ah)
+{
+}
+
+static inline void ath9k_cmn_debug_stat_rx(struct ath_rx_stats *rxstats,
+ struct ath_rx_status *rs)
+{
+}
+
+static inline void ath9k_cmn_debug_recv(struct dentry *debugfs_phy,
+ struct ath_rx_stats *rxstats)
+{
+}
+
+static inline void ath9k_cmn_debug_phy_err(struct dentry *debugfs_phy,
+ struct ath_rx_stats *rxstats)
+{
+}
+#endif /* CONFIG_ATH9K_COMMON_DEBUG */
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c b/drivers/net/wireless/ath/ath9k/common-spectral.c
index eedf86b67cf5..789a3dbe8341 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -1075,7 +1075,7 @@ static struct rchan_callbacks rfs_spec_scan_cb = {
void ath9k_cmn_spectral_deinit_debug(struct ath_spec_scan_priv *spec_priv)
{
- if (IS_ENABLED(CONFIG_ATH9K_DEBUGFS) && spec_priv->rfs_chan_spec_scan) {
+ if (spec_priv->rfs_chan_spec_scan) {
relay_close(spec_priv->rfs_chan_spec_scan);
spec_priv->rfs_chan_spec_scan = NULL;
}
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.h b/drivers/net/wireless/ath/ath9k/common-spectral.h
index 998743be9c67..5d1a51d83aa6 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.h
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.h
@@ -151,6 +151,7 @@ static inline u8 spectral_bitmap_weight(u8 *bins)
return bins[0] & 0x3f;
}
+#ifdef CONFIG_ATH9K_COMMON_DEBUG
void ath9k_cmn_spectral_init_debug(struct ath_spec_scan_priv *spec_priv, struct dentry *debugfs_phy);
void ath9k_cmn_spectral_deinit_debug(struct ath_spec_scan_priv *spec_priv);
@@ -161,5 +162,27 @@ int ath9k_cmn_spectral_scan_config(struct ath_common *common,
enum spectral_mode spectral_mode);
int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv, struct ieee80211_hdr *hdr,
struct ath_rx_status *rs, u64 tsf);
+#else
+static inline void ath9k_cmn_spectral_init_debug(struct ath_spec_scan_priv *spec_priv,
+ struct dentry *debugfs_phy)
+{
+}
+
+static inline void ath9k_cmn_spectral_deinit_debug(struct ath_spec_scan_priv *spec_priv)
+{
+}
+
+static inline void ath9k_cmn_spectral_scan_trigger(struct ath_common *common,
+ struct ath_spec_scan_priv *spec_priv)
+{
+}
+
+static inline int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv,
+ struct ieee80211_hdr *hdr,
+ struct ath_rx_status *rs, u64 tsf)
+{
+ return 0;
+}
+#endif /* CONFIG_ATH9K_COMMON_DEBUG */
#endif /* SPECTRAL_H */
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 4a01ebe53053..b8c0a08066a0 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -72,7 +72,7 @@ static bool ath9k_hw_4k_fill_eeprom(struct ath_hw *ah)
return __ath9k_hw_4k_fill_eeprom(ah);
}
-#if defined(CONFIG_ATH9K_DEBUGFS) || defined(CONFIG_ATH9K_HTC_DEBUGFS)
+#ifdef CONFIG_ATH9K_COMMON_DEBUG
static u32 ath9k_dump_4k_modal_eeprom(char *buf, u32 len, u32 size,
struct modal_eep_4k_header *modal_hdr)
{
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_9287.c b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
index 9611f020f7c0..3caa149b1013 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_9287.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
@@ -75,7 +75,7 @@ static bool ath9k_hw_ar9287_fill_eeprom(struct ath_hw *ah)
return __ath9k_hw_ar9287_fill_eeprom(ah);
}
-#if defined(CONFIG_ATH9K_DEBUGFS) || defined(CONFIG_ATH9K_HTC_DEBUGFS)
+#ifdef CONFIG_ATH9K_COMMON_DEBUG
static u32 ar9287_dump_modal_eeprom(char *buf, u32 len, u32 size,
struct modal_eep_ar9287_header *modal_hdr)
{
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index 7d5223451ce9..56b44fc7a8e6 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -131,7 +131,7 @@ static bool ath9k_hw_def_fill_eeprom(struct ath_hw *ah)
return __ath9k_hw_def_fill_eeprom(ah);
}
-#if defined(CONFIG_ATH9K_DEBUGFS) || defined(CONFIG_ATH9K_HTC_DEBUGFS)
+#ifdef CONFIG_ATH9K_COMMON_DEBUG
static u32 ath9k_def_dump_modal_eeprom(char *buf, u32 len, u32 size,
struct modal_eep_header *modal_hdr)
{
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v4] rfkill: Add rfkill-any LED trigger
From: Michał Kępień @ 2017-01-06 19:20 UTC (permalink / raw)
To: Johannes Berg
Cc: David S . Miller,
Михаил Кринкин,
linux-wireless, netdev, linux-kernel
In-Reply-To: <1483705333.4089.6.camel@sipsolutions.net>
> On Fri, 2017-01-06 at 07:07 +0100, Michał Kępień wrote:
> > Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-
> > any,
> > which may be useful on laptops with a single "radio LED" and multiple
> > radio transmitters. The trigger is meant to turn a LED on whenever
> > there is at least one radio transmitter active and turn it off
> > otherwise.
> >
> > Signed-off-by: Michał Kępień <kernel@kempniu.pl>
> > ---
> > Changes from v3:
> >
> > - Revert introducing a new bitfield and instead defer LED event
> > firing
> > to a work queue to prevent conditional locking and ensure the
> > trigger can really be used from any context. This also voids the
> > need to take rfkill_global_mutex before calling
> > rfkill_set_block()
> > in rfkill_resume().
>
> Looks better, but
>
> > +static struct work_struct rfkill_any_work;
>
> At least on module exit you need to cancel this work.
It is cancelled in rfkill_any_led_trigger_unregister(). It seemed
fitting to do it this way as rfkill_any_work is initialized in
rfkill_any_led_trigger_register(). And if CONFIG_RFKILL_LEDS=n,
rfkill_any_work is neither initialized nor scheduled, so we should be
good as well. Am I missing something?
--
Best regards,
Michał Kępień
^ permalink raw reply
* Re: [PATCH v4] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Andrew Zaborowski @ 2017-01-06 19:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1483610213.4394.4.camel@sipsolutions.net>
Hi,
On 5 January 2017 at 04:56, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2017-01-04 at 15:35 -0500, Andrew Zaborowski wrote:
>> On 4 January 2017 at 10:40, Johannes Berg <johannes@sipsolutions.net>
>> wrote:
>> > This also doesn't seem right - the same socket could possibly own
>> > both
>> > an interface and a connection? If the connection is on the same
>> > interface you might not really want to do both - though it
>> > shouldn't
>> > hurt if all the cancel_work is in the right place - but it could be
>> > a
>> > different interface?
>>
>> This is only a syntactic change though. The "continue" is now in the
>> "if (schedule_destroy_work)" block so the other actions will not be
>> scheduled is the interface is being destroyed.
>
> Yes, this part is only syntactic, but you added something new
> afterwards, and that new thing should happen even if another interface
> is going to be scheduled for destruction.
>
> I actually think that the code right now is already wrong though, since
> schedule_destroy_work and schedule_scan_stop shouldn't be mutually
> exclusive, a single socket could own both a sched scan and a different
> interface.
>
> I'll fix that bug, and we'll have to deal with the conflicts when
> merging this.
Yes, good point. I'll just rebase this patch on top of the fix.
Best regards
^ permalink raw reply
* Re: pull-request: mac80211 2017-01-06
From: David Miller @ 2017-01-06 21:27 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20170106123721.10970-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 6 Jan 2017 13:37:20 +0100
> Here's another fix for something I noticed while reviewing the code in
> a new suggested patch that added another netlink socket destroy path.
>
> Since the new patch would otherwise cause conflicts, it might be good
> to pull net or Linus's next RC containing it into net-next, if you can.
>
> Please pull and let me know if there's any problem.
Pulled, I'll try to get this moving into net-next over the weekend.
Remind me about this early next week if that ends up slipping through
the cracks.
Thanks.
^ permalink raw reply
* [PATCH v5] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Andrew Zaborowski @ 2017-01-06 21:33 UTC (permalink / raw)
To: linux-wireless
Disconnect or deauthenticate when the owning socket is closed if this
flag is supplied to CMD_CONNECT or CMD_ASSOCIATE. This may be used
to ensure userspace daemon doesn't leave an unmanaged connection behind.
In some situations it would be possible to account for that, to some
degree, in the deamon restart code or in the up/down scripts without
the use of this attribute. But there will be systems where the daemon
can go away for varying periods without a warning due to local resource
management.
Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com>
---
changes in v2:
- add wdev.disconnect_bssid so we can deauthenticate from a BSS before
association finishes
- dropped CMD_AUTHENTICATE changes
changes in v3:
- commit message fix
changes in v4:
- move cfg80211_autodisconnect_wk to sme.c
- drop two "wdev->conn_owner_nlportid = 0" lines in nl80211.c found redundant
- use wdev_lock when setting wdev->conn_owner_nlportid
- drop wdev->netdev check in cfg80211_autodisconnect_wk
changes in v5:
- in nl80211_netlink_notify schedule disconnect_wk even if another wdev
is wdev is owned by the nlportid and is being destroyed
- in cfg80211_mlme_deauth check the bssid is of the current bss or
disconnect_bssid
- set disconnect_bssid in nl80211_connect if bssid supplied
---
include/net/cfg80211.h | 7 +++++++
include/uapi/linux/nl80211.h | 2 ++
net/wireless/core.c | 3 +++
net/wireless/core.h | 1 +
net/wireless/mlme.c | 5 +++++
net/wireless/nl80211.c | 26 +++++++++++++++++++++++++-
net/wireless/sme.c | 33 +++++++++++++++++++++++++++++++++
7 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 814be4b..57383a1 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3837,6 +3837,9 @@ struct cfg80211_cached_keys;
* @conn: (private) cfg80211 software SME connection state machine data
* @connect_keys: (private) keys to set after connection is established
* @conn_bss_type: connecting/connected BSS type
+ * @conn_owner_nlportid: (private) connection owner socket port ID
+ * @disconnect_wk: (private) auto-disconnect work
+ * @disconnect_bssid: (private) the BSSID to use for auto-disconnect
* @ibss_fixed: (private) IBSS is using fixed BSSID
* @ibss_dfs_possible: (private) IBSS may change to a DFS channel
* @event_list: (private) list for internal event processing
@@ -3868,6 +3871,10 @@ struct wireless_dev {
struct cfg80211_conn *conn;
struct cfg80211_cached_keys *connect_keys;
enum ieee80211_bss_type conn_bss_type;
+ u32 conn_owner_nlportid;
+
+ struct work_struct disconnect_wk;
+ u8 disconnect_bssid[ETH_ALEN];
struct list_head event_list;
spinlock_t event_lock;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6b76e3b..455ed9b 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1820,6 +1820,8 @@ enum nl80211_commands {
* and remove functions. NAN notifications will be sent in unicast to that
* socket. Without this attribute, any socket can add functions and the
* notifications will be sent to the %NL80211_MCGRP_NAN multicast group.
+ * If set during %NL80211_CMD_ASSOCIATE or %NL80211_CMD_CONNECT the
+ * station will deauthenticate when the socket is closed.
*
* @NL80211_ATTR_TDLS_INITIATOR: flag attribute indicating the current end is
* the TDLS link initiator.
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 158c59e..903fc41 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1142,6 +1142,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
wdev->iftype == NL80211_IFTYPE_ADHOC) && !wdev->use_4addr)
dev->priv_flags |= IFF_DONT_BRIDGE;
+ INIT_WORK(&wdev->disconnect_wk, cfg80211_autodisconnect_wk);
+
nl80211_notify_iface(rdev, wdev, NL80211_CMD_NEW_INTERFACE);
break;
case NETDEV_GOING_DOWN:
@@ -1230,6 +1232,7 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
#ifdef CONFIG_CFG80211_WEXT
kzfree(wdev->wext.keys);
#endif
+ flush_work(&wdev->disconnect_wk);
}
/*
* synchronise (so that we won't find this netdev
diff --git a/net/wireless/core.h b/net/wireless/core.h
index af6e023..9d1a030 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -400,6 +400,7 @@ void __cfg80211_roamed(struct wireless_dev *wdev,
const u8 *resp_ie, size_t resp_ie_len);
int cfg80211_mgd_wext_connect(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev);
+void cfg80211_autodisconnect_wk(struct work_struct *work);
/* SME implementation */
void cfg80211_conn_work(struct work_struct *work);
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 4646cf5..1c63a77 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -345,6 +345,11 @@ int cfg80211_mlme_deauth(struct cfg80211_registered_device *rdev,
!ether_addr_equal(wdev->current_bss->pub.bssid, bssid)))
return 0;
+ if (ether_addr_equal(wdev->disconnect_bssid, bssid) ||
+ (wdev->current_bss &&
+ ether_addr_equal(wdev->current_bss->pub.bssid, bssid)))
+ wdev->conn_owner_nlportid = 0;
+
return rdev_deauth(rdev, dev, &req);
}
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ef5eff93..cc05d36 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -8053,8 +8053,17 @@ static int nl80211_associate(struct sk_buff *skb, struct genl_info *info)
err = nl80211_crypto_settings(rdev, info, &req.crypto, 1);
if (!err) {
wdev_lock(dev->ieee80211_ptr);
+
err = cfg80211_mlme_assoc(rdev, dev, chan, bssid,
ssid, ssid_len, &req);
+
+ if (!err && info->attrs[NL80211_ATTR_SOCKET_OWNER]) {
+ dev->ieee80211_ptr->conn_owner_nlportid =
+ info->snd_portid;
+ memcpy(dev->ieee80211_ptr->disconnect_bssid,
+ bssid, ETH_ALEN);
+ }
+
wdev_unlock(dev->ieee80211_ptr);
}
@@ -8773,11 +8782,24 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
}
wdev_lock(dev->ieee80211_ptr);
+
err = cfg80211_connect(rdev, dev, &connect, connkeys,
connect.prev_bssid);
- wdev_unlock(dev->ieee80211_ptr);
if (err)
kzfree(connkeys);
+
+ if (!err && info->attrs[NL80211_ATTR_SOCKET_OWNER]) {
+ dev->ieee80211_ptr->conn_owner_nlportid = info->snd_portid;
+ if (connect.bssid)
+ memcpy(dev->ieee80211_ptr->disconnect_bssid,
+ connect.bssid, ETH_ALEN);
+ else
+ memset(dev->ieee80211_ptr->disconnect_bssid,
+ 0, ETH_ALEN);
+ }
+
+ wdev_unlock(dev->ieee80211_ptr);
+
return err;
}
@@ -14519,6 +14541,8 @@ static int nl80211_netlink_notify(struct notifier_block * nb,
if (wdev->owner_nlportid == notify->portid)
schedule_destroy_work = true;
+ else if (wdev->conn_owner_nlportid == notify->portid)
+ schedule_work(&wdev->disconnect_wk);
}
spin_lock_bh(&rdev->beacon_registrations_lock);
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 5e0d193..4669391 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -727,6 +727,7 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
kzfree(wdev->connect_keys);
wdev->connect_keys = NULL;
wdev->ssid_len = 0;
+ wdev->conn_owner_nlportid = 0;
if (bss) {
cfg80211_unhold_bss(bss_from_pub(bss));
cfg80211_put_bss(wdev->wiphy, bss);
@@ -955,6 +956,7 @@ void __cfg80211_disconnected(struct net_device *dev, const u8 *ie,
wdev->current_bss = NULL;
wdev->ssid_len = 0;
+ wdev->conn_owner_nlportid = 0;
nl80211_send_disconnected(rdev, dev, reason, ie, ie_len, from_ap);
@@ -1098,6 +1100,8 @@ int cfg80211_disconnect(struct cfg80211_registered_device *rdev,
kzfree(wdev->connect_keys);
wdev->connect_keys = NULL;
+ wdev->conn_owner_nlportid = 0;
+
if (wdev->conn)
err = cfg80211_sme_disconnect(wdev, reason);
else if (!rdev->ops->disconnect)
@@ -1107,3 +1111,32 @@ int cfg80211_disconnect(struct cfg80211_registered_device *rdev,
return err;
}
+
+/*
+ * Used to clean up after the connection / connection attempt owner socket
+ * disconnects
+ */
+void cfg80211_autodisconnect_wk(struct work_struct *work)
+{
+ struct wireless_dev *wdev =
+ container_of(work, struct wireless_dev, disconnect_wk);
+ struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy);
+
+ wdev_lock(wdev);
+
+ if (wdev->conn_owner_nlportid) {
+ /*
+ * Use disconnect_bssid if still connecting and ops->disconnect
+ * not implemented. Otherwise we can use cfg80211_disconnect.
+ */
+ if (rdev->ops->disconnect || wdev->current_bss)
+ cfg80211_disconnect(rdev, wdev->netdev,
+ WLAN_REASON_DEAUTH_LEAVING, true);
+ else
+ cfg80211_mlme_deauth(rdev, wdev->netdev,
+ wdev->disconnect_bssid, NULL, 0,
+ WLAN_REASON_DEAUTH_LEAVING, false);
+ }
+
+ wdev_unlock(wdev);
+}
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: Rafał Miłecki @ 2017-01-06 22:39 UTC (permalink / raw)
To: Rahul Krishnan
Cc: Michael Büsch, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <20170106152043.GA6383@rahul>
Hi Rahul,
On 6 January 2017 at 16:20, Rahul Krishnan <mrahul.krishnan@gmail.com> wrot=
e:
> This patch removes unnecessary return statement using spatch.
> Signed-off-by: Rahul Krishnan <mrahul.krishnan@gmail.com>
Please work on simplifying & making topic more accurate.
You can drop "main.c:" and "This patch".
I don't think this patch really "removes unnecessary return". It looks
like you just dropped assignment/calculation done just before
returning value. That "using spatch tool" part is also misleading. You
don't really use that tool for removing it. More likely it was
noticed/suggested that that tool you use.
Please use commit message for describing your change and don't just
copy & paste topic. You can e.g. put into about "spatch" there
(instead of the topic).
> @@ -1,4 +1,4 @@
> -/*
> + patch /home/rahul/git/kernels/staging/drivers//*
> * Sonics Silicon Backplane
> * Subsystem core
> *
Huh? Looks definitely wrong and I don't think it even compiles
anymore! Make sure to compile code after your change, to make sure it
does & there isn't any new warning.
> @@ -1272,9 +1272,7 @@ u32 ssb_admatch_size(u32 adm)
> default:
> SSB_WARN_ON(1);
> }
> - size =3D (1 << (size + 1));
> -
> - return size;
> + return (1 << (size + 1));
> }
> EXPORT_SYMBOL(ssb_admatch_size);
Please rework your patch, *test it* and resend V2.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: Rafał Miłecki @ 2017-01-06 22:40 UTC (permalink / raw)
To: Rahul Krishnan
Cc: Michael Büsch, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <CACna6ryhvkSaHgU9igshnMjNg=wgeXd3p57VXxbr0ykoEtLH_g@mail.gmail.com>
On 6 January 2017 at 23:39, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> wrot=
e:
> On 6 January 2017 at 16:20, Rahul Krishnan <mrahul.krishnan@gmail.com> wr=
ote:
>> This patch removes unnecessary return statement using spatch.
>> Signed-off-by: Rahul Krishnan <mrahul.krishnan@gmail.com>
Also an extra line break above Signed-off-by is preferred. Look at
"git log" to get am overview.
^ permalink raw reply
* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: Michael Büsch @ 2017-01-06 22:46 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Rahul Krishnan, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <CACna6ryhvkSaHgU9igshnMjNg=wgeXd3p57VXxbr0ykoEtLH_g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
> > @@ -1272,9 +1272,7 @@ u32 ssb_admatch_size(u32 adm)
> > default:
> > SSB_WARN_ON(1);
> > }
> > - size = (1 << (size + 1));
> > -
> > - return size;
> > + return (1 << (size + 1));
> > }
> > EXPORT_SYMBOL(ssb_admatch_size);
I'm all for cleaning up code, but I don't really see how this
change improves the code.
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: Julian Calaby @ 2017-01-07 0:52 UTC (permalink / raw)
To: Rahul Krishnan
Cc: Michael Büsch, linux-wireless, linux-kernel@vger.kernel.org
In-Reply-To: <20170106152043.GA6383@rahul>
Hi Rahul,
On Sat, Jan 7, 2017 at 2:20 AM, Rahul Krishnan
<mrahul.krishnan@gmail.com> wrote:
> This patch removes unnecessary return statement using spatch.
This doesn't describe the patch.
> Signed-off-by: Rahul Krishnan <mrahul.krishnan@gmail.com>
> ---
> drivers/ssb/main.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
> index d1a7507..ae3b7fe 100644
> --- a/drivers/ssb/main.c
> +++ b/drivers/ssb/main.c
> @@ -1,4 +1,4 @@
> -/*
> + patch /home/rahul/git/kernels/staging/drivers//*
What is the purpose of this change, won't this cause the file to fail
to compile?
> * Sonics Silicon Backplane
> * Subsystem core
> *
> @@ -1272,9 +1272,7 @@ u32 ssb_admatch_size(u32 adm)
> default:
> SSB_WARN_ON(1);
> }
> - size = (1 << (size + 1));
> -
> - return size;
> + return (1 << (size + 1));
Is the size variable used elsewhere? If not, it's declaration should
probably be removed.
Also, there should be a blank line before the return statement.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Stephen Hemminger @ 2017-01-07 3:13 UTC (permalink / raw)
To: Linus Lüssing
Cc: netdev, David S . Miller, bridge, linux-kernel, linux-wireless,
Felix Fietkau
In-Reply-To: <20170102193214.31723-1-linus.luessing@c0d3.blue>
On Mon, 2 Jan 2017 20:32:14 +0100
Linus L=C3=BCssing <linus.luessing@c0d3.blue> wrote:
> This feature is intended for interface types which have a more reliable
> and/or efficient way to deliver unicast packets than broadcast ones
> (e.g. wifi).
Why is this not done in MAC80211 rather than bridge?
^ permalink raw reply
* Re: [PATCH v2 3/4] cfg80211: Accept multiple RSSI thresholds for CQM
From: Andrew Zaborowski @ 2017-01-07 9:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1483616947.4394.10.camel@sipsolutions.net>
Hi,
On 5 January 2017 at 06:49, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2017-01-04 at 15:19 -0500, Andrew Zaborowski wrote:
>> On 4 January 2017 at 10:53, Johannes Berg <johannes@sipsolutions.net>
>> wrote:
>> > Thus, you either need an nl80211 protocol feature bit (enum
>> > nl80211_protocol_features) or a new attribute, or so, I think.
>>
>> True, I'd assumed that netlink would check for exact attribute length
>> with NLA_S32.
>>
>> I'll add the feature bit but I wonder if it's better as a
>> driver/device feature (enum nl80211_ext_feature_index) so that it can
>> take into account whether rdev->set_cqm_rssi_range_config is set.
>
> Well, it's even more complicated than that because mac80211 may have
> the callback but still not be able to support it, with filtering,
> perhaps? Not quite sure now.
With the basic mac80211 implementation in my patch 4/4 this feature
should be set when IEEE80211_VIF_BEACON_FILTER is not set. The
problem with a nl80211_ext_feature is that it's per wiphy instead of
per interface. So in the case mac80211, it would need to be set if
all interfaces can accept lists of thresholds and that can change
dynamically as interfaces are added. And nl80211 has no per-interface
features.
I wonder if it's better to add a ieee80211_hw_flags flag to advertise
this feature per wiphy, or, as an approximation, set the flag based on
the default interface that is created in ieee80211_register_hw.
Best regards
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: M. Braun @ 2017-01-07 10:32 UTC (permalink / raw)
To: Johannes Berg, Felix Fietkau, Linus Lüssing, netdev
Cc: David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless
In-Reply-To: <1483710841.12677.1.camel@sipsolutions.net>
Am 06.01.2017 um 14:54 schrieb Johannes Berg:
>
>> The bridge layer can use IGMP snooping to ensure that the multicast
>> stream is only transmitted to clients that are actually a member of
>> the group. Can the mac80211 feature do the same?
>
> No, it'll convert the packet for all clients that are behind that
> netdev. But that's an argument for dropping the mac80211 feature, which
> hasn't been merged upstream yet, no?
But there is multicast/broadcast traffic like e.g. ARP and some IP
multicast groups that are not covered by IGMP snooping. The mac80211
patch converts this to unicast as well, which the bridge cannot do.
That way, these features both complement and overlap each other.
Regards,
Michael
^ permalink raw reply
* Re: [PATCH] brcmfmac: check if we can support used firmware API version
From: Arend Van Spriel @ 2017-01-07 11:44 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <CACna6rwJAjK1_Wpyj_NaOwdkegGONhTsS+-ckafkmyFRXAdphw@mail.gmail.com>
On 5-1-2017 11:06, Rafał Miłecki wrote:
> On 5 January 2017 at 10:50, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 3-1-2017 17:11, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> Every new firmware API will most likely require changes in our code to
>>> support it. Right now we support 2 versions only. Refuse to init if we
>>> detect newer version.
>>>
>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>> ---
>>> Hi Arend,
>>>
>>> I think you were concerned about possible firmware API changes. Please
>>> review this patch, I hope it's a proper check for running unsupported
>>> firmware version which could result in broken communication between host
>>> driver and a device.
>>> ---
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> index 0babfc7..c69ae84 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> @@ -6816,6 +6816,11 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
>>> brcmf_err("Failed to get D11 version (%d)\n", err);
>>> goto priv_out;
>>> }
>>> + if (io_type > BRCMU_D11AC_IOTYPE) {
>>> + brcmf_err("Unsupported IO version %d\n", io_type);
>>> + goto priv_out;
>>> + }
>>
>> I prefer to have this in brcmu_d11_attach() and have it return an error.
>
> My too, but since you made brcmu_d11_attach part of *utils* and new IO
> version support may require driver changes, I didn't want to mess
> these two.
>
> If it was up to me, I would keep brcmu_d11_attach in brcmfmac code and
> then add a proper check in this function indeed.
>
> Is there any reason you made brcmu_d11_attach part of utils?
The plan was/is to add 11ac support in brcmsmac so it would need the
brcmu_d11_*() functions.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Arend Van Spriel @ 2017-01-07 12:52 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Johannes Berg, linux-wireless@vger.kernel.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree@vger.kernel.org, Rob Herring,
Rafał Miłecki
In-Reply-To: <CACna6rw22benfuw_7BSFw1wedavmMJWTo_hfPLCVa1t0kV+Aqg@mail.gmail.com>
On 5-1-2017 11:02, Rafał Miłecki wrote:
> On 5 January 2017 at 10:31, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 4-1-2017 22:19, Rafał Miłecki wrote:
>>> On 4 January 2017 at 21:07, Arend Van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>> On 4-1-2017 18:58, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>
>>>>> There are some devices (e.g. Netgear R8000 home router) with one chipset
>>>>> model used for different radios, some of them limited to subbands. NVRAM
>>>>> entries don't contain any extra info on such limitations and firmware
>>>>> reports full list of channels to us. We need to store extra limitation
>>>>> info in DT to support such devices properly.
>>>>>
>>>>> Now there is a cfg80211 helper for reading such info use it in brcmfmac.
>>>>> This patch adds check for channel being disabled with orig_flags which
>>>>> is how this wiphy helper and wiphy_register work.
>>>>>
>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>>> ---
>>>>> This patch should probably go through wireless-driver-next which is why
>>>>> it got weird number 4/3. I'm sending it just as a proof of concept.
>>>>> It was succesfully tested on SmartRG SR400ac with BCM43602.
>>>>>
>>>>> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
>>>>> V5: Update commit message
>>>>> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make it work
>>>>> with helper setting "flags" instead of "orig_flags".
>>>>> ---
>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 ++++++++-
>>>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> index ccae3bb..a008ba5 100644
>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
>>>>> band->band);
>>>>> channel[index].hw_value = ch.control_ch_num;
>>>>>
>>>>> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
>>>>> + continue;
>>>>> +
>>>>
>>>> So to be clear this is still needed for subsequent calls to
>>>> brcmf_setup_wiphybands(). The subsequent calls are done from the
>>>> regulatory notifier. So I think we have an issue with this approach. Say
>>>> the device comes up with US. That would set DISABLED flags for channels
>>>> 12 to 14. With a country update to PL we would want to enable channels
>>>> 12 and 13, right? The orig_flags are copied from the initial flags
>>>> during wiphy_register() so it seems we will skip enabling 12 and 13. I
>>>> think we should remove the check above and call
>>>> wiphy_read_of_freq_limits() as a last step within
>>>> brcmf_setup_wiphybands(). It means it is called every time, but it
>>>> safeguards that the limits in DT are always applied.
>>>
>>> I'm not exactly happy with channels management in brcmfmac. Before
>>> calling wiphy_register it already disables channels unavailable for
>>> current country. This results in setting IEEE80211_CHAN_DISABLED in
>>
>> What do you mean by current country. There is none that we are aware off
>> in the driver. So we obtain the channels for the current
>> country/revision in the firmware and enable those before
>> wiphy_register(). This all is within the probe/init sequence so I do not
>> really see an issue. As the wiphy object is not yet registered there is
>> no user-space awareness
>
> It seems I'm terrible as describing my patches/problems/ideas :( Here
> I used 1 inaccurate word and you couldn't understand my point.
Well. Because of our track record of miscommunication and other
annoyances I want to be sure this time :-p
> By "current country" I meant current region (and so a set of
> regulatory rules) used by the firmware. I believe firmware describes
> it using "ccode" and "regrev".
>
> Now, about the issue I see:
>
> AFAIU if you set IEEE80211_CHAN_DISABLED in "orig_flags" it's meant to
> be there for good. Some reference code that makes me believe so
Indeed. Admittedly, it is the first time I became aware of it when
Johannes brought it up.
> (reg.c):
> pr_debug("Disabling freq %d MHz for good\n", chan->center_freq);
> chan->orig_flags |= IEEE80211_CHAN_DISABLED;
>
> This is what happens with brcmfmac right now. If firmware doesn't
> report some channels, you set "flags" to IEEE80211_CHAN_DISABLED for
> them. Then you call wiphy_register which copies that "flags" to the
> "orig_flags". I read it as: we are never going to use these channels.
>
> Now, consider you support regdom change (I do with my local patches).
> You translate alpha2 to a proper firmware request (board specific!),
> you execute it and then firmware may allow you to use channels that
> you marked as disabled for good. You would need to mess with
> orig_flags to recover from this issue.
>
> Does my explanation make more sense of this issue now?
Sure. It seems we should leave all channels enabled and disable them
after wiphy_register() based on firmware information. Or did you have
something else in mind. DFS channels may need to pass a feature check in
firmware and always be disabled otherwise.
>>> orig_flags of channels that may become available later, after country
>>> change. Please note it happens even right now, without this patch.
>>
>> Nope. As stated earlier the country setting in firmware is not updated
>> unless you provide a *proper* mapping of user-space country code to
>> firmware country code/revision. That is the reason, ie. firmware simply
>> returns the same list of channels as nothing changed from its
>> perspective. We may actually drop 11d support.
>
> I implemented mapping support locally, this is the feature I'm talking about.
Ok. So this is not an upstream feature. Or are you getting the mapping
from DT?
>>> Maybe you can workaround this by ignoring orig_flags in custom
>>> regulatory code, but I'd just prefer to have it nicely handled in the
>>> first place.
>>
>> Please care to explain your ideas before putting any effort in this
>> "feature". As the author of the code that makes you unhappy and as
>> driver maintainer I would like to get a clearer picture of your point of
>> view. What exactly is the issue that makes you unhappy.
>
> I meant that problem with "orig_flags" I described in the first
> paragraph. I wasn't trying to hide whatever issue I'm seeing, I swear
> ;)
>
>
>>> This is the next feature I'm going to work on. AFAIU this patch won't
>>> be applied for now (it's for wireless-drivers-next and we first need
>>> to get wiphy_read_of_freq_limits in that tree). By the time that
>>> happens I may have another patchset cleaning brcmfmac ready. And FWIW
>>> this patch wouldn't make things worse *at this point* as we don't
>>> really support country switching for any device yet.
>>
>> Now who is *we*? We as Broadcom can, because we know how to map the ISO
>> 3166-1 country code to firmware country code/revision for a specific
>> firmware release. Firmware uses its own regulatory rules which may
>> differ from what regdb has. Now I know Intel submitted a mechanism to
>> export firmware rules to regdb so maybe we should consider switching to
>> that api if that has been upstreamed. Need to check.
>
> We as a driver developers. Please read
> "we don't really support country switching for any device yet"
> as
> "brcmfmac doesn't really support country switching for any device yet"
>
> Does it help to get the context?
I indeed prefer to talk about the driver instead of we. Indeed it is
true due to the orig_flags behavior although that only seems to involve
regulatory code. Could it be that brcmfmac undo that through the notifier?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rafał Miłecki @ 2017-01-07 12:53 UTC (permalink / raw)
To: Johannes Berg
Cc: Rob Herring, linux-wireless, Martin Blumenstingl, Felix Fietkau,
Arend van Spriel, Arnd Bergmann, devicetree@vger.kernel.org,
Rafał Miłecki
In-Reply-To: <1483707597.12677.0.camel@sipsolutions.net>
On 6 January 2017 at 13:59, Johannes Berg <johannes@sipsolutions.net> wrote=
:
> On Thu, 2017-01-05 at 10:34 -0600, Rob Herring wrote:
>> On Thu, Jan 5, 2017 at 5:51 AM, Johannes Berg <johannes@sipsolutions.
>> net> wrote:
>> >
>> > > Acked-by: Rob Herring <robh@kernel.org>
>> >
>> > Do I take that to mean that we'll merge it through the subsystem
>> > tree,
>> > and not go through some common DT tree?
>>
>> Yes, that's generally the case when bindings are in a series with
>> driver changes.
>
> Alright, thanks.
>
> I've applied patches 1-3, patch 4 obviously still needs work (and
> probably won't go through my tree anyway.)
>
> Note that I made some documentation fixes in patch 3, Rafa=C5=82, please
> check.
Looks great, thanks everyone for your help on getting this patchset in shap=
e!
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Rafał Miłecki @ 2017-01-07 12:58 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Johannes Berg, linux-wireless@vger.kernel.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree@vger.kernel.org, Rob Herring,
Rafał Miłecki
In-Reply-To: <36d2dbd1-bcbe-021b-dd7f-068a5b9739ef@broadcom.com>
On 7 January 2017 at 13:52, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 5-1-2017 11:02, Rafa=C5=82 Mi=C5=82ecki wrote:
>> On 5 January 2017 at 10:31, Arend Van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>> On 4-1-2017 22:19, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>> On 4 January 2017 at 21:07, Arend Van Spriel
>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>> On 4-1-2017 18:58, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>>
>>>>>> There are some devices (e.g. Netgear R8000 home router) with one chi=
pset
>>>>>> model used for different radios, some of them limited to subbands. N=
VRAM
>>>>>> entries don't contain any extra info on such limitations and firmwar=
e
>>>>>> reports full list of channels to us. We need to store extra limitati=
on
>>>>>> info in DT to support such devices properly.
>>>>>>
>>>>>> Now there is a cfg80211 helper for reading such info use it in brcmf=
mac.
>>>>>> This patch adds check for channel being disabled with orig_flags whi=
ch
>>>>>> is how this wiphy helper and wiphy_register work.
>>>>>>
>>>>>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>> ---
>>>>>> This patch should probably go through wireless-driver-next which is =
why
>>>>>> it got weird number 4/3. I'm sending it just as a proof of concept.
>>>>>> It was succesfully tested on SmartRG SR400ac with BCM43602.
>>>>>>
>>>>>> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
>>>>>> V5: Update commit message
>>>>>> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to m=
ake it work
>>>>>> with helper setting "flags" instead of "orig_flags".
>>>>>> ---
>>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 +++=
+++++-
>>>>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg802=
11.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>>> index ccae3bb..a008ba5 100644
>>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>>> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brc=
mf_cfg80211_info *cfg,
>>>>>> band->band);
>>>>>> channel[index].hw_value =3D ch.control_ch_num;
>>>>>>
>>>>>> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
>>>>>> + continue;
>>>>>> +
>>>>>
>>>>> So to be clear this is still needed for subsequent calls to
>>>>> brcmf_setup_wiphybands(). The subsequent calls are done from the
>>>>> regulatory notifier. So I think we have an issue with this approach. =
Say
>>>>> the device comes up with US. That would set DISABLED flags for channe=
ls
>>>>> 12 to 14. With a country update to PL we would want to enable channel=
s
>>>>> 12 and 13, right? The orig_flags are copied from the initial flags
>>>>> during wiphy_register() so it seems we will skip enabling 12 and 13. =
I
>>>>> think we should remove the check above and call
>>>>> wiphy_read_of_freq_limits() as a last step within
>>>>> brcmf_setup_wiphybands(). It means it is called every time, but it
>>>>> safeguards that the limits in DT are always applied.
>>>>
>>>> I'm not exactly happy with channels management in brcmfmac. Before
>>>> calling wiphy_register it already disables channels unavailable for
>>>> current country. This results in setting IEEE80211_CHAN_DISABLED in
>>>
>>> What do you mean by current country. There is none that we are aware of=
f
>>> in the driver. So we obtain the channels for the current
>>> country/revision in the firmware and enable those before
>>> wiphy_register(). This all is within the probe/init sequence so I do no=
t
>>> really see an issue. As the wiphy object is not yet registered there is
>>> no user-space awareness
>>
>> It seems I'm terrible as describing my patches/problems/ideas :( Here
>> I used 1 inaccurate word and you couldn't understand my point.
>
> Well. Because of our track record of miscommunication and other
> annoyances I want to be sure this time :-p
>
>> By "current country" I meant current region (and so a set of
>> regulatory rules) used by the firmware. I believe firmware describes
>> it using "ccode" and "regrev".
>>
>> Now, about the issue I see:
>>
>> AFAIU if you set IEEE80211_CHAN_DISABLED in "orig_flags" it's meant to
>> be there for good. Some reference code that makes me believe so
>
> Indeed. Admittedly, it is the first time I became aware of it when
> Johannes brought it up.
>
>> (reg.c):
>> pr_debug("Disabling freq %d MHz for good\n", chan->center_freq);
>> chan->orig_flags |=3D IEEE80211_CHAN_DISABLED;
>>
>> This is what happens with brcmfmac right now. If firmware doesn't
>> report some channels, you set "flags" to IEEE80211_CHAN_DISABLED for
>> them. Then you call wiphy_register which copies that "flags" to the
>> "orig_flags". I read it as: we are never going to use these channels.
>>
>> Now, consider you support regdom change (I do with my local patches).
>> You translate alpha2 to a proper firmware request (board specific!),
>> you execute it and then firmware may allow you to use channels that
>> you marked as disabled for good. You would need to mess with
>> orig_flags to recover from this issue.
>>
>> Does my explanation make more sense of this issue now?
>
> Sure. It seems we should leave all channels enabled and disable them
> after wiphy_register() based on firmware information. Or did you have
> something else in mind. DFS channels may need to pass a feature check in
> firmware and always be disabled otherwise.
I got in mind exactly what you described. I didn't look at DFS channels yet=
.
>>>> orig_flags of channels that may become available later, after country
>>>> change. Please note it happens even right now, without this patch.
>>>
>>> Nope. As stated earlier the country setting in firmware is not updated
>>> unless you provide a *proper* mapping of user-space country code to
>>> firmware country code/revision. That is the reason, ie. firmware simply
>>> returns the same list of channels as nothing changed from its
>>> perspective. We may actually drop 11d support.
>>
>> I implemented mapping support locally, this is the feature I'm talking a=
bout.
>
> Ok. So this is not an upstream feature. Or are you getting the mapping
> from DT?
I'll send patch next week. So far I put mapping table directly in a
driver, but I think it's better to have this in DT.
>>>> Maybe you can workaround this by ignoring orig_flags in custom
>>>> regulatory code, but I'd just prefer to have it nicely handled in the
>>>> first place.
>>>
>>> Please care to explain your ideas before putting any effort in this
>>> "feature". As the author of the code that makes you unhappy and as
>>> driver maintainer I would like to get a clearer picture of your point o=
f
>>> view. What exactly is the issue that makes you unhappy.
>>
>> I meant that problem with "orig_flags" I described in the first
>> paragraph. I wasn't trying to hide whatever issue I'm seeing, I swear
>> ;)
>>
>>
>>>> This is the next feature I'm going to work on. AFAIU this patch won't
>>>> be applied for now (it's for wireless-drivers-next and we first need
>>>> to get wiphy_read_of_freq_limits in that tree). By the time that
>>>> happens I may have another patchset cleaning brcmfmac ready. And FWIW
>>>> this patch wouldn't make things worse *at this point* as we don't
>>>> really support country switching for any device yet.
>>>
>>> Now who is *we*? We as Broadcom can, because we know how to map the ISO
>>> 3166-1 country code to firmware country code/revision for a specific
>>> firmware release. Firmware uses its own regulatory rules which may
>>> differ from what regdb has. Now I know Intel submitted a mechanism to
>>> export firmware rules to regdb so maybe we should consider switching to
>>> that api if that has been upstreamed. Need to check.
>>
>> We as a driver developers. Please read
>> "we don't really support country switching for any device yet"
>> as
>> "brcmfmac doesn't really support country switching for any device yet"
>>
>> Does it help to get the context?
>
> I indeed prefer to talk about the driver instead of we. Indeed it is
> true due to the orig_flags behavior although that only seems to involve
> regulatory code. Could it be that brcmfmac undo that through the notifier=
?
I guess you could touch orig_flags, but I don't know if it's preferred
way. This is probably question to Johannes & cfg80211 guys.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: kbuild test robot @ 2017-01-07 13:39 UTC (permalink / raw)
To: Rahul Krishnan; +Cc: kbuild-all, m, linux-wireless, linux-kernel
In-Reply-To: <20170106152043.GA6383@rahul>
[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]
Hi Rahul,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rahul-Krishnan/ssb-main-c-This-patch-removes-unnecessary-return-statement-using-spatch-tool/20170107-205451
config: x86_64-randconfig-x008-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/ssb/main.c:1:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before '/' token
patch /home/rahul/git/kernels/staging/drivers//*
^
>> drivers/ssb/main.c:6:43: error: stray '@' in program
* Copyright 2006, 2007, Michael Buesch <m@bues.ch>
^
vim +1 drivers/ssb/main.c
> 1 patch /home/rahul/git/kernels/staging/drivers//*
2 * Sonics Silicon Backplane
3 * Subsystem core
4 *
5 * Copyright 2005, Broadcom Corporation
> 6 * Copyright 2006, 2007, Michael Buesch <m@bues.ch>
7 *
8 * Licensed under the GNU/GPL. See COPYING for details.
9 */
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27927 bytes --]
^ permalink raw reply
* Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: kbuild test robot @ 2017-01-07 13:57 UTC (permalink / raw)
To: Rahul Krishnan; +Cc: kbuild-all, m, linux-wireless, linux-kernel
In-Reply-To: <20170106152043.GA6383@rahul>
[-- Attachment #1: Type: text/plain, Size: 26233 bytes --]
Hi Rahul,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rahul-Krishnan/ssb-main-c-This-patch-removes-unnecessary-return-statement-using-spatch-tool/20170107-205451
config: i386-randconfig-r0-201701 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/ssb/main.c:1:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before '/' token
patch /home/rahul/git/kernels/staging/drivers//*
^
drivers/ssb/main.c:6:43: error: stray '@' in program
* Copyright 2006, 2007, Michael Buesch <m@bues.ch>
^
In file included from include/linux/ioport.h:12:0,
from include/linux/device.h:16,
from include/linux/ssb/ssb.h:4,
from drivers/ssb/ssb_private.h:4,
from drivers/ssb/main.c:11:
>> include/linux/compiler.h:110:34: warning: 'struct ftrace_branch_data' declared inside parameter list
void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
^
>> include/linux/compiler.h:110:34: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/err.h: In function 'IS_ERR':
include/linux/compiler.h:117:18: error: variable '______f' has initializer but incomplete type
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/compiler.h:117:18: error: unknown field 'func' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/compiler.h:121:13: warning: excess elements in struct initializer
.func = __func__, \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/compiler.h:121:13: note: (near initialization for '______f')
.func = __func__, \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/compiler.h:117:18: error: unknown field 'file' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/err.h:35:40: warning: excess elements in struct initializer
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/err.h:35:40: note: (near initialization for '______f')
include/linux/compiler.h:117:18: error: unknown field 'line' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/err.h:35:40: warning: excess elements in struct initializer
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/err.h:35:40: note: (near initialization for '______f')
include/linux/compiler.h:120:5: error: storage size of '______f' isn't known
______f = { \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
^
include/linux/err.h:35:9: note: in expansion of macro 'IS_ERR_VALUE'
return IS_ERR_VALUE((unsigned long)ptr);
^
include/linux/compiler.h:120:5: warning: unused variable '______f' [-Wunused-variable]
______f = { \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
include/linux/err.h:21:25: note: in expansion of macro 'unlikely'
--
^
include/linux/compiler.h:121:13: note: (near initialization for '______f')
.func = __func__, \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
arch/x86/include/asm/preempt.h:98:9: note: in expansion of macro 'unlikely'
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
include/linux/compiler.h:117:18: error: unknown field 'file' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
arch/x86/include/asm/preempt.h:98:9: note: in expansion of macro 'unlikely'
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
arch/x86/include/asm/preempt.h:98:67: warning: excess elements in struct initializer
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
arch/x86/include/asm/preempt.h:98:67: note: (near initialization for '______f')
include/linux/compiler.h:117:18: error: unknown field 'line' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
arch/x86/include/asm/preempt.h:98:9: note: in expansion of macro 'unlikely'
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
arch/x86/include/asm/preempt.h:98:67: warning: excess elements in struct initializer
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
arch/x86/include/asm/preempt.h:98:67: note: (near initialization for '______f')
include/linux/compiler.h:120:5: error: storage size of '______f' isn't known
______f = { \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
arch/x86/include/asm/preempt.h:98:9: note: in expansion of macro 'unlikely'
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
include/linux/compiler.h:120:5: warning: unused variable '______f' [-Wunused-variable]
______f = { \
^
include/linux/compiler.h:139:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
^
arch/x86/include/asm/preempt.h:98:9: note: in expansion of macro 'unlikely'
return unlikely(raw_cpu_read_4(__preempt_count) == preempt_offset);
^
include/asm-generic/qspinlock.h: In function 'queued_spin_lock':
include/linux/compiler.h:117:18: error: variable '______f' has initializer but incomplete type
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/linux/compiler.h:117:18: error: unknown field 'func' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/linux/compiler.h:121:13: warning: excess elements in struct initializer
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/linux/compiler.h:121:13: note: (near initialization for '______f')
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/linux/compiler.h:117:18: error: unknown field 'file' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
>> include/asm-generic/qspinlock.h:101:21: warning: excess elements in struct initializer
if (likely(val == 0))
^
include/asm-generic/qspinlock.h:101:21: note: (near initialization for '______f')
include/linux/compiler.h:117:18: error: unknown field 'line' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
>> include/asm-generic/qspinlock.h:101:21: warning: excess elements in struct initializer
if (likely(val == 0))
^
include/asm-generic/qspinlock.h:101:21: note: (near initialization for '______f')
include/linux/compiler.h:120:5: error: storage size of '______f' isn't known
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/linux/compiler.h:120:5: warning: unused variable '______f' [-Wunused-variable]
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qspinlock.h:101:6: note: in expansion of macro 'likely'
if (likely(val == 0))
^
include/asm-generic/qrwlock.h: In function 'queued_read_trylock':
include/linux/compiler.h:117:18: error: variable '______f' has initializer but incomplete type
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:117:18: error: unknown field 'func' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:121:13: warning: excess elements in struct initializer
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:121:13: note: (near initialization for '______f')
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:117:18: error: unknown field 'file' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
>> include/asm-generic/qrwlock.h:83:32: warning: excess elements in struct initializer
if (likely(!(cnts & _QW_WMASK))) {
^
include/asm-generic/qrwlock.h:83:32: note: (near initialization for '______f')
include/linux/compiler.h:117:18: error: unknown field 'line' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
>> include/asm-generic/qrwlock.h:83:32: warning: excess elements in struct initializer
if (likely(!(cnts & _QW_WMASK))) {
^
include/asm-generic/qrwlock.h:83:32: note: (near initialization for '______f')
include/linux/compiler.h:120:5: error: storage size of '______f' isn't known
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:120:5: warning: unused variable '______f' [-Wunused-variable]
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:83:6: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK))) {
^
include/linux/compiler.h:117:18: error: variable '______f' has initializer but incomplete type
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/linux/compiler.h:117:18: error: unknown field 'func' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/linux/compiler.h:121:13: warning: excess elements in struct initializer
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/linux/compiler.h:121:13: note: (near initialization for '______f')
.func = __func__, \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/linux/compiler.h:117:18: error: unknown field 'file' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/asm-generic/qrwlock.h:85:33: warning: excess elements in struct initializer
if (likely(!(cnts & _QW_WMASK)))
^
include/asm-generic/qrwlock.h:85:33: note: (near initialization for '______f')
include/linux/compiler.h:117:18: error: unknown field 'line' specified in initializer
static struct ftrace_branch_data \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/asm-generic/qrwlock.h:85:33: warning: excess elements in struct initializer
if (likely(!(cnts & _QW_WMASK)))
^
include/asm-generic/qrwlock.h:85:33: note: (near initialization for '______f')
include/linux/compiler.h:120:5: error: storage size of '______f' isn't known
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
^
include/linux/compiler.h:120:5: warning: unused variable '______f' [-Wunused-variable]
______f = { \
^
include/linux/compiler.h:136:56: note: in expansion of macro '__branch_check__'
# define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
^
include/asm-generic/qrwlock.h:85:7: note: in expansion of macro 'likely'
if (likely(!(cnts & _QW_WMASK)))
..
vim +212 drivers/ssb/main.c
3ba6018a Michael Buesch 2009-11-23 196 *
3ba6018a Michael Buesch 2009-11-23 197 * After freezing no device driver will be handling a device
3ba6018a Michael Buesch 2009-11-23 198 * on this bus anymore. ssb_devices_thaw() must be called after
3ba6018a Michael Buesch 2009-11-23 199 * a successful freeze to reactivate the devices.
3ba6018a Michael Buesch 2009-11-23 200 *
3ba6018a Michael Buesch 2009-11-23 201 * @bus: The bus.
3ba6018a Michael Buesch 2009-11-23 202 * @ctx: Context structure. Pass this to ssb_devices_thaw().
3ba6018a Michael Buesch 2009-11-23 203 */
3ba6018a Michael Buesch 2009-11-23 204 int ssb_devices_freeze(struct ssb_bus *bus, struct ssb_freeze_context *ctx)
61e115a5 Michael Buesch 2007-09-18 205 {
3ba6018a Michael Buesch 2009-11-23 206 struct ssb_device *sdev;
3ba6018a Michael Buesch 2009-11-23 207 struct ssb_driver *sdrv;
3ba6018a Michael Buesch 2009-11-23 208 unsigned int i;
3ba6018a Michael Buesch 2009-11-23 209
3ba6018a Michael Buesch 2009-11-23 210 memset(ctx, 0, sizeof(*ctx));
3ba6018a Michael Buesch 2009-11-23 211 ctx->bus = bus;
3ba6018a Michael Buesch 2009-11-23 @212 SSB_WARN_ON(bus->nr_devices > ARRAY_SIZE(ctx->device_frozen));
61e115a5 Michael Buesch 2007-09-18 213
61e115a5 Michael Buesch 2007-09-18 214 for (i = 0; i < bus->nr_devices; i++) {
3ba6018a Michael Buesch 2009-11-23 215 sdev = ssb_device_get(&bus->devices[i]);
3ba6018a Michael Buesch 2009-11-23 216
3ba6018a Michael Buesch 2009-11-23 217 if (!sdev->dev || !sdev->dev->driver ||
3ba6018a Michael Buesch 2009-11-23 218 !device_is_registered(sdev->dev)) {
3ba6018a Michael Buesch 2009-11-23 219 ssb_device_put(sdev);
61e115a5 Michael Buesch 2007-09-18 220 continue;
:::::: The code at line 212 was first introduced by commit
:::::: 3ba6018aa314559c5867138a8173b068268a70db ssb: Fix SPROM writing
:::::: TO: Michael Buesch <mb@bu3sch.de>
:::::: CC: John W. Linville <linville@tuxdriver.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 21800 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Linus Lüssing @ 2017-01-07 14:55 UTC (permalink / raw)
To: M. Braun
Cc: Johannes Berg, Felix Fietkau, netdev, David S . Miller,
Stephen Hemminger, bridge, linux-kernel, linux-wireless
In-Reply-To: <22fad045-57c6-7789-d19f-f47bd0faf441@fami-braun.de>
On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote:
> Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> >
> >> The bridge layer can use IGMP snooping to ensure that the multicast
> >> stream is only transmitted to clients that are actually a member of
> >> the group. Can the mac80211 feature do the same?
> >
> > No, it'll convert the packet for all clients that are behind that
> > netdev. But that's an argument for dropping the mac80211 feature, which
> > hasn't been merged upstream yet, no?
>
> But there is multicast/broadcast traffic like e.g. ARP and some IP
> multicast groups that are not covered by IGMP snooping. The mac80211
> patch converts this to unicast as well, which the bridge cannot do.
>
> That way, these features both complement and overlap each other.
Right, I'd agree with that.
I didn't write it explicitly in the commit message, but yes, the
like anything concerning bridge multicast snooping, bridge
multicast-to-unicast can only affect packets as noted in
RFC4541 ("Considerations for Internet Group Management Protocol (IGMP)
and Multicast Listener Discovery (MLD) Snooping Switches"), too.
So it is only working for IPv4 multicast, excluding link-local
(224.0.0.0/24), and IPv6 multicast, excluding all-host-multicast
(ff02::1).
And does not concern ARP in any way.
The nice complementary effect is, that the bridge can first sieve
out those IP packets thanks to IGMP/MLD snooping knowledge and for
anything else, like ARP, 224.0.0.x or ff02::1, the mac80211
multicast-to-unicast could do its job.
For APs with a small number of STAs (like your private home AP),
you might want to enable both bridge multicast-to-unicast and
mac80211 multicast-to-unicast for this complementary effect. While
on public APs with 30 to 50 STAs with varying distances and bitrates,
you might only one to enable the bridge one, because sending an ARP
packet 50x might actually reduce performance and airtime
significantly.
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Linus Lüssing @ 2017-01-07 15:06 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, David S . Miller, bridge, linux-kernel, linux-wireless,
Felix Fietkau
In-Reply-To: <20170106191356.43740a26@xeon-e3>
On Fri, Jan 06, 2017 at 07:13:56PM -0800, Stephen Hemminger wrote:
> On Mon, 2 Jan 2017 20:32:14 +0100
> Linus Lüssing <linus.luessing@c0d3.blue> wrote:
>
> > This feature is intended for interface types which have a more reliable
> > and/or efficient way to deliver unicast packets than broadcast ones
> > (e.g. wifi).
>
>
> Why is this not done in MAC80211 rather than bridge?
Because mac80211 does not have the IGMP/MLD snooping code as
the bridge has?
Reimplementing the snooping in mac80211 does not make sense
because of duplicating code. Moving the snooping code from the
bridge to mac80211 does not make sense either, because we want
multicast snooping, software based, (virtually) wired switches,
too.
The "best way" (TM) would probably be to migrate the IGMP/MLD
snooping from the bridge code to the net device code on the long
run to make such a database usable for any kind of device, without
needing this bridge hack.
But such a migration would also need a way more invasive patchset.
While Felix's idea might look a little "ugly" due it's hacky
nature, I think it is also quite beautiful thanks to it's
simplicity.
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Linus Lüssing @ 2017-01-07 15:15 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev, David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless, Felix Fietkau, Michael Braun
In-Reply-To: <1483706872.4089.8.camel@sipsolutions.net>
On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg wrote:
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
>
> I suppose that the feature there could apply also to locally generated
> traffic when the AP interface isn't in a bridge, but I think I could
> live with requiring the AP to be put into a bridge to achieve a similar
> configuration?
>
> Additionally, on an unrelated note, this seems to apply generically to
> all kinds of frames, losing information by replacing the address.
> Shouldn't it have similar limitations as the wifi stack feature has
> then, like only applying to ARP, IPv4, IPv6 and not general protocols?
(should all three be answered with Michael's and my reply to
Michael's mail, I think)
>
> Also, it should probably come with the same caveat as we documented for
> the wifi feature:
>
> Note that this may break certain expectations of the receiver,
> such as the ability to drop unicast IP packets received within
> multicast L2 frames, or the ability to not send ICMP destination
> unreachable messages for packets received in L2 multicast (which
> is required, but the receiver can't tell the difference if this
> new option is enabled.)
Actually, I do not quite understand that remark in the mac80211
multicast-to-unicast patch. IP should not care about the ethernet
header?
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Rafał Miłecki @ 2017-01-07 17:36 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Johannes Berg, linux-wireless@vger.kernel.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree@vger.kernel.org, Rob Herring,
Rafał Miłecki
In-Reply-To: <CACna6rw22benfuw_7BSFw1wedavmMJWTo_hfPLCVa1t0kV+Aqg@mail.gmail.com>
On 5 January 2017 at 11:02, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> wrot=
e:
> On 5 January 2017 at 10:31, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 4-1-2017 22:19, Rafa=C5=82 Mi=C5=82ecki wrote:
>>> I'm not exactly happy with channels management in brcmfmac. Before
>>> calling wiphy_register it already disables channels unavailable for
>>> current country. This results in setting IEEE80211_CHAN_DISABLED in
>>
>> What do you mean by current country. There is none that we are aware off
>> in the driver. So we obtain the channels for the current
>> country/revision in the firmware and enable those before
>> wiphy_register(). This all is within the probe/init sequence so I do not
>> really see an issue. As the wiphy object is not yet registered there is
>> no user-space awareness
>
> It seems I'm terrible as describing my patches/problems/ideas :( Here
> I used 1 inaccurate word and you couldn't understand my point.
>
> By "current country" I meant current region (and so a set of
> regulatory rules) used by the firmware. I believe firmware describes
> it using "ccode" and "regrev".
>
> Now, about the issue I see:
>
> AFAIU if you set IEEE80211_CHAN_DISABLED in "orig_flags" it's meant to
> be there for good. Some reference code that makes me believe so
> (reg.c):
> pr_debug("Disabling freq %d MHz for good\n", chan->center_freq);
> chan->orig_flags |=3D IEEE80211_CHAN_DISABLED;
>
> This is what happens with brcmfmac right now. If firmware doesn't
> report some channels, you set "flags" to IEEE80211_CHAN_DISABLED for
> them. Then you call wiphy_register which copies that "flags" to the
> "orig_flags". I read it as: we are never going to use these channels.
>
> Now, consider you support regdom change (I do with my local patches).
> You translate alpha2 to a proper firmware request (board specific!),
> you execute it and then firmware may allow you to use channels that
> you marked as disabled for good. You would need to mess with
> orig_flags to recover from this issue.
I was wrong about this. Current notifier implementation in brcmfmac
doesn't care about "orig_flags" and it just sets "flags" as it wants.
This way it can enable even these channels that were believed to be
disabled for good (DISABLED in "orig_flags").
For my test I booted SR400ac with ccode & regrev set to values that
didn't allow me to use channels 149 - 165 (5735 - 5835). It matches my
current country:
country PL: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
Then I used "iw reg set ??" to set country that allows these channels.
My locally modified brcmfmac driver sent proper "country" iovar to the
firmware and queried it for the updated "chanspecs". See my debugging
messages below:
brcmfmac: [brcmf_construct_chaninfo] hw_value:34 orig_flags:0x101 flags:0x0=
01
brcmfmac: [brcmf_construct_chaninfo] hw_value:36 orig_flags:0x1a0 flags:0x0=
a0
brcmfmac: [brcmf_construct_chaninfo] hw_value:38 orig_flags:0x101 flags:0x0=
01
brcmfmac: [brcmf_construct_chaninfo] hw_value:40 orig_flags:0x190 flags:0x0=
90
brcmfmac: [brcmf_construct_chaninfo] hw_value:42 orig_flags:0x101 flags:0x0=
01
brcmfmac: [brcmf_construct_chaninfo] hw_value:44 orig_flags:0x1a0 flags:0x0=
a0
brcmfmac: [brcmf_construct_chaninfo] hw_value:46 orig_flags:0x101 flags:0x0=
01
brcmfmac: [brcmf_construct_chaninfo] hw_value:48 orig_flags:0x190 flags:0x0=
90
brcmfmac: [brcmf_construct_chaninfo] hw_value:52 orig_flags:0x1aa flags:0x0=
aa
brcmfmac: [brcmf_construct_chaninfo] hw_value:56 orig_flags:0x19a flags:0x0=
9a
brcmfmac: [brcmf_construct_chaninfo] hw_value:60 orig_flags:0x1aa flags:0x0=
aa
brcmfmac: [brcmf_construct_chaninfo] hw_value:64 orig_flags:0x19a flags:0x0=
9a
brcmfmac: [brcmf_construct_chaninfo] hw_value:100 orig_flags:0x1aa flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:104 orig_flags:0x19a flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:108 orig_flags:0x1aa flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:112 orig_flags:0x19a flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:116 orig_flags:0x1aa flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:120 orig_flags:0x19a flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:124 orig_flags:0x1aa flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:128 orig_flags:0x19a flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:132 orig_flags:0x1aa flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:136 orig_flags:0x19a flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:140 orig_flags:0x1ba flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:144 orig_flags:0x101 flags:0x=
001
brcmfmac: [brcmf_construct_chaninfo] hw_value:149 orig_flags:0x101 flags:0x=
0a0
brcmfmac: [brcmf_construct_chaninfo] hw_value:153 orig_flags:0x101 flags:0x=
090
brcmfmac: [brcmf_construct_chaninfo] hw_value:157 orig_flags:0x101 flags:0x=
0a0
brcmfmac: [brcmf_construct_chaninfo] hw_value:161 orig_flags:0x101 flags:0x=
090
brcmfmac: [brcmf_construct_chaninfo] hw_value:165 orig_flags:0x101 flags:0x=
0b0
As you can see brcmfmac dropped IEEE80211_CHAN_DISABLED (hint: 0x1)
for channels 149 - 165 even though they were disabled according to the
"orig_flags".
So this patch with its
if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
continue;
could be considered some kind of regression. My change wouldn't allow
enabling such channels anymore.
Of course noone would notice this as noone uses country_codes table
yet I guess (except for me locally). Anyway, this patch should be
reworked to make sure it still allows implementing support for
country_codes tables in the future.
^ permalink raw reply
* [PATCH 1/2] brcmfmac: don't preset all channels as disabled
From: Rafał Miłecki @ 2017-01-07 20:36 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
During init we take care of regulatory stuff by disabling all
unavailable channels (see brcmf_construct_chaninfo) so this predisabling
them is not really required (and this patch won't change any behavior).
It will on the other hand allow more detailed runtime control over
channels which is the main reason for this change.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 895404c..45ee5b6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -138,7 +138,6 @@ static struct ieee80211_rate __wl_rates[] = {
.band = NL80211_BAND_2GHZ, \
.center_freq = (_freq), \
.hw_value = (_channel), \
- .flags = IEEE80211_CHAN_DISABLED, \
.max_antenna_gain = 0, \
.max_power = 30, \
}
@@ -147,7 +146,6 @@ static struct ieee80211_rate __wl_rates[] = {
.band = NL80211_BAND_5GHZ, \
.center_freq = 5000 + (5 * (_channel)), \
.hw_value = (_channel), \
- .flags = IEEE80211_CHAN_DISABLED, \
.max_antenna_gain = 0, \
.max_power = 30, \
}
--
2.10.1
^ permalink raw reply related
* [PATCH 2/2] brcmfmac: setup wiphy bands after registering it first
From: Rafał Miłecki @ 2017-01-07 20:36 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170107203605.24866-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
During bands setup we disable all channels that firmware doesn't support
in the current regulatory setup. If we do this before wiphy_register
it will result in copying set flags (including IEEE80211_CHAN_DISABLED)
to the orig_flags which is supposed to be persistent. We don't want this
as regulatory change may result in enabling some channels. We shouldn't
mess with orig_flags then (by changing them or ignoring them) so it's
better to just take care of their proper values.
This patch cleanups code a bit (by taking orig_flags more seriously) and
allows further improvements like disabling really unavailable channels.
We will need that e.g. if some frequencies should be disabled for good
due to hardware setup (design).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 45ee5b6..729bf33 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6477,8 +6477,7 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp)
wiphy->bands[NL80211_BAND_5GHZ] = band;
}
}
- err = brcmf_setup_wiphybands(wiphy);
- return err;
+ return 0;
}
static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg)
@@ -6843,6 +6842,12 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
goto priv_out;
}
+ err = brcmf_setup_wiphybands(wiphy);
+ if (err) {
+ brcmf_err("Setting wiphy bands failed (%d)\n", err);
+ goto wiphy_unreg_out;
+ }
+
/* If cfg80211 didn't disable 40MHz HT CAP in wiphy_register(),
* setup 40MHz in 2GHz band and enable OBSS scanning.
*/
--
2.10.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox