Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
Arend van Spriel wrote: > On 12/31/14 16:14, Andreas Hartmann wrote: [...] >> All in all: >> If you want to get rid of wext, you still have to go a *very* long way >> to get the same *stable* and high throughput quality with *all* chips >> depending on mac80211 and not just a few flagship drivers like Atheros. > > Hi Andreas, > > That's a nice list of unrelated stuff. This has all nothing to do with > WEXT. Actually, you can build rt5572sta with cfg80211 support > (RT_CFG80211_SUPPORT). You seem to know sources I don't know off. Could you please tell me, where to find them? I have DPO_RT5572_LinuxSTA_2.6.0.1_20120629 which doesn't compile with HAS_CFG80211_SUPPORT=y because -DCONFIG_AP_SUPPORT, on which RT_CFG80211_SUPPORT relies, is broken. DPO_RT5572_LinuxSTA_2.6.1.3_20121022 removed the necessary broken AP code completely. > This thread is about the configuration API and > not about driver performance. I know. I tried to show, why WEXT as a whole is still necessary even if there is a mac80211 based driver, because of the weakness of rt2800usb: Nip it in the bud. Kind regards, Andreas -- 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
Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On Thu, Jan 1, 2015 at 1:22 AM, David Lang wrote: > there are things that you can do with "ip" that you can't do with > "ifconfig", but they tend to be rather esoteric things (hundreds of IP > addresses on "eth0" without using eth0:1, eth0:2, etc as one example) > > The trouble is that doing simple things is harder with "ip" than "ifconfig" Jan did a nice overview: http://inai.de/2008/02/19 -- Thanks, //richard -- 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
[PATCH 1/2] cfg80211: introduce sync regdom set API for self-managed
A self-managed device will sometimes need to set its regdomain synchronously.
Notably it should be set before usermode has a chance to query it. Expose
a new API to accomplish this which requires the RTNL.
Signed-off-by: Arik Nemtsov
Reviewed-by: Ilan Peer
Reviewed-by: Emmanuel Grumbach
---
include/net/cfg80211.h | 14 ++
net/wireless/reg.c | 17 +
2 files changed, 31 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index bd672ea..cb0bba2 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3827,6 +3827,20 @@ int regulatory_set_wiphy_regd(struct wiphy *wiphy,
struct ieee80211_regdomain *rd);
/**
+ * regulatory_set_wiphy_regd_sync_rtnl - set regdom for self-managed drivers
+ * @wiphy: the wireless device we want to process the regulatory domain on
+ * @rd: the regulatory domain information to use for this wiphy
+ *
+ * This functions requires the RTNL to be held and applies the new regdomain
+ * synchronously to this wiphy. For more details see
+ * regulatory_set_wiphy_regd().
+ *
+ * Return: 0 on success. -EINVAL, -EPERM
+ */
+int regulatory_set_wiphy_regd_sync_rtnl(struct wiphy *wiphy,
+ struct ieee80211_regdomain *rd);
+
+/**
* wiphy_apply_custom_regulatory - apply a custom driver regulatory domain
* @wiphy: the wireless device we want to process the regulatory domain on
* @regd: the custom regulatory domain to use for this wiphy
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 9a5411c..9b5662f 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2928,6 +2928,23 @@ int regulatory_set_wiphy_regd(struct wiphy *wiphy,
}
EXPORT_SYMBOL(regulatory_set_wiphy_regd);
+int regulatory_set_wiphy_regd_sync_rtnl(struct wiphy *wiphy,
+ struct ieee80211_regdomain *rd)
+{
+ int ret;
+
+ ASSERT_RTNL();
+
+ ret = regulatory_set_wiphy_regd(wiphy, rd);
+ if (ret)
+ return ret;
+
+ /* process the request immediately */
+ reg_process_self_managed_hints();
+ return 0;
+}
+EXPORT_SYMBOL(regulatory_set_wiphy_regd_sync_rtnl);
+
void wiphy_regulatory_register(struct wiphy *wiphy)
{
struct regulatory_request *lr;
--
2.1.0
--
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
[PATCH 2/2] cfg80211: avoid reg-hints in self-managed only systems
When a system contains only self-managed regulatory devices all hints
from the regulatory core are ignored. Stop hint processing early in this
case. These systems usually don't have CRDA deployed, which results in
endless (irrelevent) logs of the form:
cfg80211: Calling CRDA to update world regulatory domain
Signed-off-by: Arik Nemtsov
---
net/wireless/reg.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 9b5662f..21b2095 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2102,6 +2102,22 @@ out_free:
reg_free_request(reg_request);
}
+static bool reg_only_self_managed_wiphys(void)
+{
+ struct cfg80211_registered_device *rdev;
+ struct wiphy *wiphy;
+
+ ASSERT_RTNL();
+
+ list_for_each_entry(rdev, &cfg80211_rdev_list, list) {
+ wiphy = &rdev->wiphy;
+ if (!(wiphy->regulatory_flags & REGULATORY_WIPHY_SELF_MANAGED))
+ return false;
+ }
+
+ return true;
+}
+
/*
* Processes regulatory hints, this is all the NL80211_REGDOM_SET_BY_*
* Regulatory hints come on a first come first serve basis and we
@@ -2133,6 +2149,11 @@ static void reg_process_pending_hints(void)
spin_unlock(®_requests_lock);
+ if (reg_only_self_managed_wiphys()) {
+ reg_free_request(reg_request);
+ return;
+ }
+
reg_process_hint(reg_request);
}
--
2.1.0
--
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
[PATCH] mac80211: skip disabled channels in VHT check
The patch "40a11ca mac80211: check if channels allow 80 MHz for VHT
probe requests" considered disabled channels as VHT enabled, and
mistakenly sent out probe-requests with the VHT IE.
Signed-off-by: Arik Nemtsov
---
net/mac80211/util.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 0f9bf47..ad8cb4f 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1470,10 +1470,12 @@ static int ieee80211_build_preq_ies_band(struct
ieee80211_local *local,
/* Check if any channel in this sband supports at least 80 MHz */
for (i = 0; i < sband->n_channels; i++) {
- if (!(sband->channels[i].flags & IEEE80211_CHAN_NO_80MHZ)) {
- have_80mhz = true;
- break;
- }
+ if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED |
+ IEEE80211_CHAN_NO_80MHZ))
+ continue;
+
+ have_80mhz = true;
+ break;
}
if (sband->vht_cap.vht_supported && have_80mhz) {
--
2.1.0
--
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
Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On 01/01/15 11:56, Andreas Hartmann wrote: Arend van Spriel wrote: On 12/31/14 16:14, Andreas Hartmann wrote: [...] All in all: If you want to get rid of wext, you still have to go a *very* long way to get the same *stable* and high throughput quality with *all* chips depending on mac80211 and not just a few flagship drivers like Atheros. Hi Andreas, That's a nice list of unrelated stuff. This has all nothing to do with WEXT. Actually, you can build rt5572sta with cfg80211 support (RT_CFG80211_SUPPORT). You seem to know sources I don't know off. Could you please tell me, where to find them? I have DPO_RT5572_LinuxSTA_2.6.0.1_20120629 which doesn't compile with HAS_CFG80211_SUPPORT=y because -DCONFIG_AP_SUPPORT, on which RT_CFG80211_SUPPORT relies, is broken. DPO_RT5572_LinuxSTA_2.6.1.3_20121022 removed the necessary broken AP code completely. Nice. This thread is about the configuration API and not about driver performance. I know. I tried to show, why WEXT as a whole is still necessary even if there is a mac80211 based driver, because of the weakness of rt2800usb: Nip it in the bud. Yes. WEXT needs to stay for a while. Not arguing that. Just saying this is really about cfg80211 providing "WEXT compatibility" so WEXT user-space apps can interact with cfg80211-based drivers and how to come up with a plan to phase out "WEXT compatibility", not WEXT. Regards, Arend Kind regards, Andreas -- 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
[PATCH] net: wireless: b43legacy: radio.c: Remove unused function
Remove the function b43legacy_radio_set_tx_iq() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/net/wireless/b43legacy/radio.c | 19 ---
drivers/net/wireless/b43legacy/radio.h |1 -
2 files changed, 20 deletions(-)
diff --git a/drivers/net/wireless/b43legacy/radio.c
b/drivers/net/wireless/b43legacy/radio.c
index 8961776..9501420 100644
--- a/drivers/net/wireless/b43legacy/radio.c
+++ b/drivers/net/wireless/b43legacy/radio.c
@@ -1743,25 +1743,6 @@ u16 freq_r3A_value(u16 frequency)
return value;
}
-void b43legacy_radio_set_tx_iq(struct b43legacy_wldev *dev)
-{
- static const u8 data_high[5] = { 0x00, 0x40, 0x80, 0x90, 0xD0 };
- static const u8 data_low[5] = { 0x00, 0x01, 0x05, 0x06, 0x0A };
- u16 tmp = b43legacy_radio_read16(dev, 0x001E);
- int i;
- int j;
-
- for (i = 0; i < 5; i++) {
- for (j = 0; j < 5; j++) {
- if (tmp == (data_high[i] | data_low[j])) {
- b43legacy_phy_write(dev, 0x0069, (i - j) << 8 |
- 0x00C0);
- return;
- }
- }
- }
-}
-
int b43legacy_radio_selectchannel(struct b43legacy_wldev *dev,
u8 channel,
int synthetic_pu_workaround)
diff --git a/drivers/net/wireless/b43legacy/radio.h
b/drivers/net/wireless/b43legacy/radio.h
index bccb3d7..dd2976d 100644
--- a/drivers/net/wireless/b43legacy/radio.h
+++ b/drivers/net/wireless/b43legacy/radio.h
@@ -92,7 +92,6 @@ void b43legacy_nrssi_hw_write(struct b43legacy_wldev *dev,
u16 offset, s16 val);
void b43legacy_nrssi_hw_update(struct b43legacy_wldev *dev, u16 val);
void b43legacy_nrssi_mem_update(struct b43legacy_wldev *dev);
-void b43legacy_radio_set_tx_iq(struct b43legacy_wldev *dev);
u16 b43legacy_radio_calibrationvalue(struct b43legacy_wldev *dev);
#endif /* B43legacy_RADIO_H_ */
--
1.7.10.4
--
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
[PATCH] net: wireless: ipw2x00: ipw2100.c: Remove some unused functions
Removes some functions that are not used anywhere:
write_nic_dword_auto_inc() write_nic_auto_inc_address()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/net/wireless/ipw2x00/ipw2100.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c
b/drivers/net/wireless/ipw2x00/ipw2100.c
index 6fabea0..fa88839 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -433,17 +433,6 @@ static inline void write_nic_byte(struct net_device *dev,
u32 addr, u8 val)
write_register_byte(dev, IPW_REG_INDIRECT_ACCESS_DATA, val);
}
-static inline void write_nic_auto_inc_address(struct net_device *dev, u32 addr)
-{
- write_register(dev, IPW_REG_AUTOINCREMENT_ADDRESS,
- addr & IPW_REG_INDIRECT_ADDR_MASK);
-}
-
-static inline void write_nic_dword_auto_inc(struct net_device *dev, u32 val)
-{
- write_register(dev, IPW_REG_AUTOINCREMENT_DATA, val);
-}
-
static void write_nic_memory(struct net_device *dev, u32 addr, u32 len,
const u8 * buf)
{
--
1.7.10.4
--
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
Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On Wed, Dec 31, 2014 at 01:57:59PM -0800, Linus Torvalds wrote: > Side note: does anybody think that was really a good idea to begin > with? I mean, Cisco iOS is just _s_ universally loved, right? > > And yeah, I refuse to use "ip link" or other insane commands. Let's > face it, "ifconfig" and "route" are perfectly fine commands, and a > whole lot less confusing than "ip" with random crap after it. I'm > really not seeing why that "ip" command was seen as an improvement. > > (Ok, "ip route" isn't any more complex than "route", but "ip link" > sure as hell isn't simpler than "ifconfig" for most things I can think > of) Well at least in the past (not sure these days), ifconfig was reading rather inefficiently from /proc rather than using netlink, and it had annoying bugs like only showing the first 9 characters of the interface name, not handling IPv6 (I think that has been fixed by now), and many other awfulnesses. I just did a quick check to see how ifconfig does longer interface names and got this: tun0-12345678:2: error fetching interface information: Device not found for an interface I had renamed to tun0-123456789 ip had no issue with it. Renaming it to tun0-12345678 made ifconfig not die on it. I wonder if someone failed to understand that 15 character interface names meant that 15 characters before the NULL should be allowed. If did show all of the 14 characters though, so the old cut at 9 character limit is at least gone these days. ifconfig seems to just be broken for many cases of perfectly nice features in the kernel. So yes some parts of ip are pretty painful, while others are rather nice (I certainly like ip route, where the output actually matches the syntax of the input, unlike the route command). Would be nice if all features of the ip command were actually documented, but they clearly are not. -- Len Sorensen -- 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
Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On Thu, Jan 1, 2015 at 11:44 AM, Lennart Sorensen wrote: > > ifconfig seems to just be broken for many cases of perfectly nice features > in the kernel. So I'm not saying "ifconfig is wonderful". It's not. But I *am* saying that "changing user interfaces and then expecting people to change is f*cking stupid". The fact is, ifconfig is simple for the simple cases, but more importantly, a lot of people learnt how to use it. Saying "you should all change, because we made up a new syntax" is not good policy. The people who did "ip" could have fairly easily have done a wrapper around the same code that also left the old "ifconfig" syntax. Then, distros could have trivially just dropped the old "ifconfig" package, and entirely replaced it with the new "ip" package. As it is, we have two different models, and they'll basically stay around forever. For something like ifconfig, very few people care. But *all* the same arguments are true wrt "iw" and "iwconfig". The people who are trying to deprecate the WEXT interfaces should put the blame firmly where it belongs - on the people who thought that "we'll just ignore all old history". Because people who think that "we'll just redesign everything" are actually f*cking morons. Really. There's a real reason the kernel has the "no regression" policy. And that reason is that I'm not a moron. History matter. Legacy uses matter. Linus -- 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
Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On Thu, Jan 01, 2015 at 12:14:15PM -0800, Linus Torvalds wrote: > So I'm not saying "ifconfig is wonderful". It's not. > > But I *am* saying that "changing user interfaces and then expecting > people to change is f*cking stupid". > > The fact is, ifconfig is simple for the simple cases, but more > importantly, a lot of people learnt how to use it. Saying "you should > all change, because we made up a new syntax" is not good policy. Perhaps it would be good to at least fix the buggy bits of ifconfig and perhaps make it work with netlink instead of parsing /proc. Maybe not add features, but at least fix the broken bits and make it use modern interfaces. The interface to the user can stay. And of course if it happens to encounter a really old kernel, it should still remember how to speak to it with the old interface. > The people who did "ip" could have fairly easily have done a wrapper > around the same code that also left the old "ifconfig" syntax. Then, > distros could have trivially just dropped the old "ifconfig" package, > and entirely replaced it with the new "ip" package. Hmm, that might be a better idea. > As it is, we have two different models, and they'll basically stay > around forever. > > For something like ifconfig, very few people care. But *all* the same > arguments are true wrt "iw" and "iwconfig". > > The people who are trying to deprecate the WEXT interfaces should put > the blame firmly where it belongs - on the people who thought that > "we'll just ignore all old history". > > Because people who think that "we'll just redesign everything" are > actually f*cking morons. Really. > > There's a real reason the kernel has the "no regression" policy. And > that reason is that I'm not a moron. > > History matter. Legacy uses matter. Sounds good to me. -- Len Sorensen -- 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
Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On Wed 2014-12-31 08:49:00, Peter Hurley wrote:
> On 12/31/2014 08:26 AM, Grumbach, Emmanuel wrote:
> >>
> >> On Wed, 31 Dec 2014, Arend van Spriel wrote:
> >>
> >>> You mentioned in the discussion and I quote: "*If* wireless
> >>> maintainers think otherwise, I'll send a revert request to Linus for
> >>> consideration.". However, you did not wait for any response from the
> >>> wireless maintainers nor from the author of the patch you are reverting.
> >>> Seems like an overreaction to me though personally I do not disgree
> >>> with the revert itself.
> >>
> >> My understanding from the whole thread was that Emmanuel disagrees with
> >> the revert, and I consider Emmanuel to definitely belong to the "wireless
> >> maintainers" group. If my understanding was wrong on this, sorry for that.
> >
> > You understanding is wrong. This patch has an author and you could I didn't
> > sign-off the patch which is an obvious indication I am not a "wireless
> > maintainer".
> > You didn't even make the minimal effort to check how this patch should be
> > properly
> > routed.
> >
> > Regardless of all this, I didn't say I disagree, I said that we need to
> > find a way to signal
> > the userland developers that an API will be deprecated at some point. I
> > haven't seen
> > any response / suggestion from you on that.
>
> pr_notice_once("WEXT compatibility has been deprecated since _" \
>" Upgrade your userspace tools to nl80211!\n");
Kernel interfaces are not being removed, not now, not ever. No need to
spam logs.
(And to the person who suggested WARN(): No.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: [PATCH] ath10k: Fix DMA burst size
Sujith Manoharan writes: > From: Sujith Manoharan > > A value of zero indicates that 128B is the maximum > DMA request size for read/writes. But PCI cards based > on AR9880 can support 256B, so enable this for > the 10.2 firmware. > > Signed-off-by: Sujith Manoharan Did you see any throughput improvements with this? -- Kalle Valo -- 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
Re: [PATCH] ath10k: Enable RX batching
Sujith Manoharan writes:
> From: Sujith Manoharan
>
> This feature allows the FW to batch RX indications,
> reducing the rate of host interrupt generation, which
> in turn reduces CPU load. Currently, this is enabled
> only for the 10.2 firmware.
>
> Signed-off-by: Sujith Manoharan
Any throughput improvements?
Also I simplified the patch a bit in ath-next-test:
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3710,7 +3710,7 @@ static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct
ath10k *ar)
struct wmi_init_cmd_10_2 *cmd;
struct sk_buff *buf;
struct wmi_resource_config_10x config = {};
- u32 len, val, features = 0;
+ u32 len, val, features;
config.num_vdevs = __cpu_to_le32(TARGET_10X_NUM_VDEVS);
config.num_peers = __cpu_to_le32(TARGET_10X_NUM_PEERS);
@@ -3764,7 +3764,7 @@ static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct
ath10k *ar)
cmd = (struct wmi_init_cmd_10_2 *)buf->data;
- features |= WMI_10_2_RX_BATCH_MODE;
+ features = WMI_10_2_RX_BATCH_MODE;
cmd->resource_config.feature_mask = __cpu_to_le32(features);
memcpy(&cmd->resource_config.common, &config, sizeof(config));
--
Kalle Valo
--
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
