* [PATCH v2 0/7] ath9k: EEPROM swapping improvements
From: Martin Blumenstingl @ 2016-10-02 22:29 UTC (permalink / raw)
To: kvalo, ath9k-devel, linux-wireless, ath9k-devel, devicetree, arnd
Cc: chunkeey, nbd, Martin Blumenstingl
In-Reply-To: <20160821144906.30984-1-martin.blumenstingl@googlemail.com>
There are two types of swapping the EEPROM data in the ath9k driver.
Before this series one type of swapping could not be used without the
other.
The first type of swapping looks at the "magic bytes" at the start of
the EEPROM data and performs swab16 on the EEPROM contents if needed.
The second type of swapping is EEPROM format specific and swaps
specific fields within the EEPROM itself (swab16, swab32 - depends on
the EEPROM format).
With this series the second part now looks at the EEPMISC register
inside the EEPROM, which uses a bit to indicate if the EEPROM data
is Big Endian (this is also done by the FreeBSD kernel).
This has a nice advantage: currently there are some out-of-tree hacks
(in OpenWrt and LEDE) where the EEPROM has a Big Endian header on a
Big Endian system (= no swab16 is performed) but the EEPROM itself
indicates that it's data is Little Endian. Until now the out-of-tree
code simply did a swab16 before passing the data to ath9k, so ath9k
first did the swab16 - this also enabled the format specific swapping.
These out-of-tree hacks are still working with the new logic, but it
is recommended to remove them. This implementation is based on a
discussion with Arnd Bergmann who raised concerns about the
robustness and portability of the swapping logic in the original OF
support patch review, see [0].
After a second round of patches (= v1 of this series) neither Arnd
Bergmann nor I were really happy with the complexity of the EEPROM
swapping logic. Based on a discussion (see [1] and [2]) we decided
that ath9k should use a defined format (specifying the endianness
of the data - I went with __le16 and __le32) when accessing the
EEPROM fields. A benefit of this is that we enable the EEPMISC based
swapping logic by default, just like the FreeBSD driver, see [3]. On
the devices which I have tested (see below) ath9k now works without
having to specify the "endian_check" field in ath9k_platform_data (or
a similar logic which could provide this via devicetree) as ath9k now
detects the endianness automatically. Only EEPROMs which are mangled
by some out-of-tree code still need the endian_check flag (or one can
simply remove that mangling from the out-of-tree code).
Testing:
- tested by myself on AR9287 with Big Endian EEPROM
- tested by myself on AR9227 with Little Endian EEPROM
- tested by myself on AR9381 (using the ar9003_eeprom implementation,
which did not suffer from this whole problem)
- how do we proceed with testing? maybe we could keep this in a
feature-branch and add these patches to LEDE once we have an ACK to
get more people to test this
This series depends on my other series (v7):
"add devicetree support to ath9k" - see [4]
Changes since v1:
- reworked description in the cover-letter to describe the reasons
behind the new patch 7
- reworked patch "Set the "big endian" bit of the AR9003 EEPROM
templates" as ar9003_eeprom.c sets all values as Little Endian, thus
the Big Endian bit should never be set (the new patch makes this
clear)
- dropped "ath9k: Make EEPROM endianness swapping configurable via
devicetree" as it is not needed anymore with the new logic from
patch 7
- added patches 4 and 5 as small cleanup (this made it easier to
implement the le{16,32}_to_cpu() changes where needed)
[0] http://www.spinics.net/lists/linux-wireless/msg152634.html
[1] https://marc.info/?l=linux-wireless&m=147250597503174&w=2
[2] https://marc.info/?l=linux-wireless&m=147254388611344&w=2
[3] https://github.com/freebsd/freebsd/blob/50719b56d9ce8d7d4beb53b16e9edb2e9a4a7a18/sys/dev/ath/ath_hal/ah_eeprom_9287.c#L351
[4] https://marc.info/?l=linux-wireless&m=147544488619822&w=2
Martin Blumenstingl (7):
ath9k: Add a #define for the EEPROM "eepmisc" endianness bit
ath9k: indicate that the AR9003 EEPROM template values are little
endian
ath9k: Add an eeprom_ops callback for retrieving the eepmisc value
ath9k: replace eeprom_param EEP_MINOR_REV with get_eeprom_rev
ath9k: consistently use get_eeprom_rev(ah)
ath9k: Make the EEPROM swapping check use the eepmisc register
ath9k: define all EEPROM fields in Little Endian format
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 6 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 21 ++--
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 4 +-
drivers/net/wireless/ath/ath9k/eeprom.c | 42 ++++---
drivers/net/wireless/ath/ath9k/eeprom.h | 85 +++++++------
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 137 +++++++++------------
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 129 +++++++++----------
drivers/net/wireless/ath/ath9k/eeprom_def.c | 163 ++++++++++++-------------
drivers/net/wireless/ath/ath9k/xmit.c | 3 +-
10 files changed, 289 insertions(+), 303 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v7 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Martin Blumenstingl @ 2016-10-02 21:47 UTC (permalink / raw)
To: ath9k-devel, devicetree, linux-wireless, ath9k-devel
Cc: mcgrof, mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, linux, nbd, Martin Blumenstingl
In-Reply-To: <20161002214743.2263-1-martin.blumenstingl@googlemail.com>
Add documentation how devicetree can be used to configure ath9k based
devices.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
new file mode 100644
index 0000000..9b58ede
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
@@ -0,0 +1,30 @@
+* Qualcomm Atheros ath9k wireless devices
+
+This node provides properties for configuring the ath9k wireless device. The
+node is expected to be specified as a child node of the PCI controller to
+which the wireless chip is connected.
+
+Required properties:
+- compatible: For PCI and PCIe devices this should be an identifier following
+ the format as defined in "PCI Bus Binding to Open Firmware"
+ Revision 2.1. One of the possible formats is "pciVVVV,DDDD"
+ where VVVV is the PCI vendor ID and DDDD is PCI device ID.
+- reg: Address and length of the register set for the device.
+
+Optional properties:
+- qca,no-eeprom: Indicates that there is no physical EEPROM connected to the
+ ath9k wireless chip (in this case the calibration /
+ EEPROM data will be loaded from userspace using the
+ kernel firmware loader).
+- mac-address: See ethernet.txt in the parent directory
+- local-mac-address: See ethernet.txt in the parent directory
+
+
+In this example, the node is defined as child node of the PCI controller:
+&pci0 {
+ ath9k@168c,002d {
+ compatible = "pci168c,002d";
+ reg = <0x7000 0 0 0 0x1000>;
+ qca,no-eeprom;
+ };
+};
--
2.10.0
^ permalink raw reply related
* [PATCH v7 0/3] add devicetree support to ath9k
From: Martin Blumenstingl @ 2016-10-02 21:47 UTC (permalink / raw)
To: ath9k-devel, devicetree, linux-wireless, ath9k-devel
Cc: mcgrof, mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, linux, nbd, Martin Blumenstingl
In-Reply-To: <20160906214623.20424-1-martin.blumenstingl@googlemail.com>
This series adds support for configuring ath9k based devices via
devicetree. This was tested on PCI(e) based devices. This should work
for AHB based devices as well (adding more AHB specific properties may
still be needed) as soon as the ath79 platform is ready to populate the
ath9k wmac via devicetree.
Changes since v6:
- updated documentation to reflect that "reg" is a mandatory attribute
- dropped "qca,clk-25mhz" as it is only useful for AHB devices. OF
support for AHB devices needs more work, so we can still introduce it
later
- removed qca,disable-2ghz and qca,disable-5ghz as these will be
introduced as generic bindings in a separate series
Changes since v5:
- updated the example in the documentation (keeping it at a bare
minimum: removed the PCI bridge, use a better real-world example with
less-confusing device/fn numbers, added the actual size of the config
space to the reg property)
Martin Blumenstingl (3):
Documentation: dt: net: add ath9k wireless device binding
ath9k: add a helper to get the string representation of ath_bus_type
ath9k: parse the device configuration from an OF node
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 30 ++++++++++++++++
drivers/net/wireless/ath/ath.h | 6 ++++
drivers/net/wireless/ath/ath9k/init.c | 42 ++++++++++++++++++++++
drivers/net/wireless/ath/main.c | 7 ++++
4 files changed, 85 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
--
2.10.0
^ permalink raw reply
* [PATCH v7 3/3] ath9k: parse the device configuration from an OF node
From: Martin Blumenstingl @ 2016-10-02 21:47 UTC (permalink / raw)
To: ath9k-devel, devicetree, linux-wireless, ath9k-devel
Cc: mcgrof, mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, linux, nbd, Martin Blumenstingl
In-Reply-To: <20161002214743.2263-1-martin.blumenstingl@googlemail.com>
This allows setting the MAC address and specifying that the firmware
will be requested from userspace (because there might not be a hardware
EEPROM connected to the chip) for ath9k based PCI devices using
the device tree.
There is some out-of-tree code to "convert devicetree to
ath9k_platform_data" (for example in OpenWrt and LEDE) which becomes
obsolete with this patch.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/net/wireless/ath/ath9k/init.c | 42 +++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index cfa3fe8..b7c8ff9 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -20,6 +20,8 @@
#include <linux/slab.h>
#include <linux/ath9k_platform.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_net.h>
#include <linux/relay.h>
#include <net/ieee80211_radiotap.h>
@@ -555,6 +557,42 @@ static int ath9k_init_platform(struct ath_softc *sc)
return 0;
}
+static int ath9k_of_init(struct ath_softc *sc)
+{
+ struct device_node *np = sc->dev->of_node;
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath_common *common = ath9k_hw_common(ah);
+ enum ath_bus_type bus_type = common->bus_ops->ath_bus_type;
+ const char *mac;
+ char eeprom_name[100];
+ int ret;
+
+ if (!of_device_is_available(np))
+ return 0;
+
+ ath_dbg(common, CONFIG, "parsing configuration from OF node\n");
+
+ if (of_property_read_bool(np, "qca,no-eeprom")) {
+ /* ath9k-eeprom-<bus>-<id>.bin */
+ scnprintf(eeprom_name, sizeof(eeprom_name),
+ "ath9k-eeprom-%s-%s.bin",
+ ath_bus_type_to_string(bus_type), dev_name(ah->dev));
+
+ ret = ath9k_eeprom_request(sc, eeprom_name);
+ if (ret)
+ return ret;
+ }
+
+ mac = of_get_mac_address(np);
+ if (mac)
+ ether_addr_copy(common->macaddr, mac);
+
+ ah->ah_flags &= ~AH_USE_EEPROM;
+ ah->ah_flags |= AH_NO_EEP_SWAP;
+
+ return 0;
+}
+
static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
const struct ath_bus_ops *bus_ops)
{
@@ -611,6 +649,10 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
if (ret)
return ret;
+ ret = ath9k_of_init(sc);
+ if (ret)
+ return ret;
+
if (ath9k_led_active_high != -1)
ah->config.led_active_high = ath9k_led_active_high == 1;
--
2.10.0
^ permalink raw reply related
* [PATCH v7 2/3] ath9k: add a helper to get the string representation of ath_bus_type
From: Martin Blumenstingl @ 2016-10-02 21:47 UTC (permalink / raw)
To: ath9k-devel, devicetree, linux-wireless, ath9k-devel
Cc: mcgrof, mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, linux, nbd, Martin Blumenstingl
In-Reply-To: <20161002214743.2263-1-martin.blumenstingl@googlemail.com>
This can be used when the ath_bus_type has to be presented in a log
message or firmware filename.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/net/wireless/ath/ath.h | 6 ++++++
drivers/net/wireless/ath/main.c | 7 +++++++
2 files changed, 13 insertions(+)
diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index da7a7c8..f3f2784 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -327,4 +327,10 @@ static inline const char *ath_opmode_to_string(enum nl80211_iftype opmode)
}
#endif
+extern const char *ath_bus_type_strings[];
+static inline const char *ath_bus_type_to_string(enum ath_bus_type bustype)
+{
+ return ath_bus_type_strings[bustype];
+}
+
#endif /* ATH_H */
diff --git a/drivers/net/wireless/ath/main.c b/drivers/net/wireless/ath/main.c
index 338d723..89f4b05 100644
--- a/drivers/net/wireless/ath/main.c
+++ b/drivers/net/wireless/ath/main.c
@@ -90,3 +90,10 @@ void ath_printk(const char *level, const struct ath_common* common,
va_end(args);
}
EXPORT_SYMBOL(ath_printk);
+
+const char *ath_bus_type_strings[] = {
+ [ATH_PCI] = "pci",
+ [ATH_AHB] = "ahb",
+ [ATH_USB] = "usb",
+};
+EXPORT_SYMBOL(ath_bus_type_strings);
--
2.10.0
^ permalink raw reply related
* Re: [PATCH] ath10k: enable peer stats by default
From: Yeoh Chun-Yeow @ 2016-10-02 16:03 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: ath10k, linux-wireless
In-Reply-To: <1473188728-14995-1-git-send-email-twp@qca.qualcomm.com>
Hi, Thomas
On Wed, Sep 7, 2016 at 3:05 AM, Thomas Pedersen <twp@qca.qualcomm.com> wrote:
> IFTYPE_MESH_POINT need to rely on these for accurate path
> selection metrics. Other modes will probably also find
Both get expected throughput or get txrate are not available to
mac80211. So, is this useful by enabling it?
----
Chun-Yeow
^ permalink raw reply
* Re: RTL8192EU on rtl8xxxu driver breaks every few minutes
From: Franc[e]sco @ 2016-10-02 16:03 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless
In-Reply-To: <wrfjr3816jpr.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
Thanks for the patch, just tested the rtl8xxxu-devel branch and it seems
to have the same exact issue with the same dmesg output with the
addition of "rtl8192eu_active_to_emu: Disabling MAC timed out" when I
disconnect the dongle.
I checked out and compiled the whole kernel from the branch because the
4.7.4 sources seemed to be missing the rtl8192eu_active_to_emu function.
These are the main networking scripts provided by Linux From Scratch, by
the way:
http://www.linuxfromscratch.org/lfs/view/7.10/scripts/apds24.html
http://www.linuxfromscratch.org/lfs/view/7.10/scripts/apds26.html
On 10/01/2016 01:39 AM, Jes Sorensen wrote:
> I just pushed a patch into rtl8xxxu-devel which may resolve this issue.
> There were problems with the 8192eu not handling driver reload very
> well. It is possible the network scripts you run would trigger the shut
> down and restart that caused this problem.
>
> I would be interested in knowing if this patch resolves the problem for
> you.
>
> Jes
>
> PS: Please fix your mail client - adding unlisted-recipients to the Cc
> line and cutting out the person you are responding to is really
> annoying.
>
[-- Attachment #2: rtl8192eu-iw-link-devel.txt --]
[-- Type: text/plain, Size: 328 bytes --]
# uname -a
Linux lfs 4.8.0-rc6 #1 SMP Wed Feb 10 17:55:47 CET 2016 x86_64
GNU/Linux
# iw wlan0 link
Connected to e0:3f:49:97:0c:68 (on wlan0)
SSID: memes
freq: 2472
RX: 4853613 bytes (23417 packets)
TX: 2256453 bytes (9807 packets)
signal: -57 dBm
tx bitrate: 1.0 MBit/s
bss flags:short-slot-time
dtim period:1
beacon int:100
[-- Attachment #3: rtl8192eu-dmesg-devel.txt --]
[-- Type: text/plain, Size: 10217 bytes --]
[ 49.588764] usb 2-1.4: New USB device found, idVendor=0bda, idProduct=818b
[ 49.589418] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=
3
[ 49.590060] usb 2-1.4: Product: 802.11n NIC
[ 49.590681] usb 2-1.4: Manufacturer: Realtek
[ 49.591307] usb 2-1.4: SerialNumber: 00e04c000001
[ 49.592149] usb 2-1.4: This Realtek USB WiFi dongle (0x0bda:0x818b) is unteste
d!
[ 49.592791] usb 2-1.4: Please report results to Jes.Sorensen@gmail.com
[ 49.756655] usb 2-1.4: Vendor: Realtek
[ 49.757295] usb 2-1.4: Product: 802.11n NIC
[ 49.757932] usb 2-1.4: Serial: \xffffffff\xffffffff\xffffffff\xffffffff\xfffff
fff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
[ 49.758560] usb 2-1.4: rtl8192eu_parse_efuse: dumping efuse (0x200 bytes):
[ 49.759196] usb 2-1.4: 00: 29 81 00 7c 01 40 03 00
[ 49.759819] usb 2-1.4: 08: 40 74 04 50 14 00 00 00
[ 49.760442] usb 2-1.4: 10: 21 20 1f 23 23 23 2d 2c
[ 49.761072] usb 2-1.4: 18: 2b 2d 2d ff ef ef ff ff
[ 49.761701] usb 2-1.4: 20: ff ff ff ff ff ff ff ff
[ 49.762318] usb 2-1.4: 28: ff ff ff ff ff ff ff ff
[ 49.762930] usb 2-1.4: 30: ff ff ff ff ff ff ff ff
[ 49.763532] usb 2-1.4: 38: ff ff 1f 1d 1c 1e 1e 1e
[ 49.764133] usb 2-1.4: 40: 2a 29 28 29 29 ff ef ef
[ 49.764730] usb 2-1.4: 48: ff ff ff ff ff ff ff ff
[ 49.765319] usb 2-1.4: 50: ff ff ff ff ff ff ff ff
[ 49.765893] usb 2-1.4: 58: ff ff ff ff ff ff ff ff
[ 49.766447] usb 2-1.4: 60: ff ff ff ff ff ff ff ff
[ 49.766998] usb 2-1.4: 68: ff ff ff ff ff ff ff ff
[ 49.767540] usb 2-1.4: 70: ff ff ff ff ff ff ff ff
[ 49.768083] usb 2-1.4: 78: ff ff ff ff ff ff ff ff
[ 49.768619] usb 2-1.4: 80: ff ff ff ff ff ff ff ff
[ 49.769152] usb 2-1.4: 88: ff ff ff ff ff ff ff ff
[ 49.769686] usb 2-1.4: 90: ff ff ff ff ff ff ff ff
[ 49.770220] usb 2-1.4: 98: ff ff ff ff ff ff ff ff
[ 49.770748] usb 2-1.4: a0: ff ff ff ff ff ff ff ff
[ 49.771271] usb 2-1.4: a8: ff ff ff ff ff ff ff ff
[ 49.771794] usb 2-1.4: b0: ff ff ff ff ff ff ff ff
[ 49.772312] usb 2-1.4: b8: 20 0d ff 00 33 88 ff ff
[ 49.772830] usb 2-1.4: c0: ff 01 20 13 00 00 00 ff
[ 49.773347] usb 2-1.4: c8: 00 00 ff ff ff ff ff ff
[ 49.773863] usb 2-1.4: d0: da 0b 8b 81 e7 47 02 00
[ 49.774373] usb 2-1.4: d8: 19 88 00 1e 33 09 03 52
[ 49.774871] usb 2-1.4: e0: 65 61 6c 74 65 6b 0d 03
[ 49.775373] usb 2-1.4: e8: 38 30 32 2e 31 31 6e 20
[ 49.775867] usb 2-1.4: f0: 4e 49 43 00 ff ff ff ff
[ 49.776351] usb 2-1.4: f8: ff ff ff ff ff ff ff ff
[ 49.776836] usb 2-1.4: 100: ff ff ff ff ff ff ff ff
[ 49.777321] usb 2-1.4: 108: ff ff ff ff ff ff ff ff
[ 49.777804] usb 2-1.4: 110: ff ff ff ff ff ff ff 0d
[ 49.778275] usb 2-1.4: 118: 03 00 05 00 30 00 00 00
[ 49.778747] usb 2-1.4: 120: 00 93 ff ff ff ff ff ff
[ 49.779212] usb 2-1.4: 128: ff ff ff ff ff ff ff ff
[ 49.779679] usb 2-1.4: 130: f6 a8 98 2d 03 92 98 00
[ 49.780142] usb 2-1.4: 138: fc 8c 00 11 9b 44 02 0a
[ 49.780608] usb 2-1.4: 140: ff ff ff ff ff ff ff ff
[ 49.781073] usb 2-1.4: 148: ff ff ff ff ff ff ff ff
[ 49.781536] usb 2-1.4: 150: ff ff ff ff ff ff ff ff
[ 49.781996] usb 2-1.4: 158: ff ff ff ff ff ff ff ff
[ 49.782447] usb 2-1.4: 160: ff ff ff ff ff ff ff ff
[ 49.782898] usb 2-1.4: 168: ff ff ff ff ff ff ff ff
[ 49.783336] usb 2-1.4: 170: ff ff ff ff ff ff ff ff
[ 49.783774] usb 2-1.4: 178: ff ff ff ff ff ff ff ff
[ 49.784207] usb 2-1.4: 180: ff ff ff ff ff ff ff ff
[ 49.784628] usb 2-1.4: 188: ff ff ff ff ff ff ff ff
[ 49.785035] usb 2-1.4: 190: ff ff ff ff ff ff ff ff
[ 49.785429] usb 2-1.4: 198: ff ff ff ff ff ff ff ff
[ 49.785816] usb 2-1.4: 1a0: ff ff ff ff ff ff ff ff
[ 49.786187] usb 2-1.4: 1a8: ff ff ff ff ff ff ff ff
[ 49.786551] usb 2-1.4: 1b0: ff ff ff ff ff ff ff ff
[ 49.786907] usb 2-1.4: 1b8: ff ff ff ff ff ff ff ff
[ 49.787261] usb 2-1.4: 1c0: ff ff ff ff ff ff ff ff
[ 49.787610] usb 2-1.4: 1c8: ff ff ff ff ff ff ff ff
[ 49.787944] usb 2-1.4: 1d0: ff ff ff ff ff ff ff ff
[ 49.788267] usb 2-1.4: 1d8: ff ff ff ff ff ff ff ff
[ 49.788579] usb 2-1.4: 1e0: ff ff ff ff ff ff ff ff
[ 49.788891] usb 2-1.4: 1e8: ff ff ff ff ff ff ff ff
[ 49.789195] usb 2-1.4: 1f0: ff ff ff ff ff ff ff ff
[ 49.789492] usb 2-1.4: 1f8: ff ff ff ff ff ff ff ff
[ 49.789780] usb 2-1.4: RTL8192EU rev B (SMIC) 2T2R, TX queues 3, WiFi=1, BT=0,
GPS=0, HI PA=0
[ 49.790086] usb 2-1.4: RTL8192EU MAC: 00:19:88:00:1e:33
[ 49.790393] usb 2-1.4: rtl8xxxu: Loading firmware rtlwifi/rtl8192eu_nic.bin
[ 49.816242] usb 2-1.4: Firmware revision 19.0 (signature 0x92e1)
[ 66.100685] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 67.325452] wlan0: authenticate with e0:3f:49:97:0c:68
[ 67.348290] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 67.352300] wlan0: authenticated
[ 67.354252] wlan0: associate with e0:3f:49:97:0c:68 (try 1/3)
[ 67.365086] wlan0: RX AssocResp from e0:3f:49:97:0c:68 (capab=0xc11 status=0 a
id=1)
[ 67.367429] usb 2-1.4: rtl8xxxu_bss_info_changed: HT supported
[ 67.369542] wlan0: associated
[ 67.370083] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 380.420651] wlan0: deauthenticated from e0:3f:49:97:0c:68 (Reason: 3=DEAUTH_LE
AVING)
[ 381.674392] wlan0: authenticate with e0:3f:49:97:0c:68
[ 381.697604] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 381.906162] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 382.114170] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 382.322189] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 383.954439] wlan0: authenticate with e0:3f:49:97:0c:68
[ 383.976941] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 384.178355] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 384.386363] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 384.594383] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 386.730693] wlan0: authenticate with e0:3f:49:97:0c:68
[ 386.753198] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 386.954610] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 387.162618] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 387.370637] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 397.516819] wlan0: authenticate with e0:3f:49:97:0c:68
[ 397.529074] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 397.731597] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 397.939614] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 398.147631] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 426.414414] wlan0: authenticate with e0:3f:49:97:0c:68
[ 426.437384] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 426.638255] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 426.846263] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 427.054281] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 463.313819] wlan0: authenticate with e0:3f:49:97:0c:68
[ 463.336685] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 463.537642] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 463.745651] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 463.953670] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 553.226072] wlan0: authenticate with e0:3f:49:97:0c:68
[ 553.249034] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 553.449901] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 553.657909] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 553.865928] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 622.136403] wlan0: authenticate with e0:3f:49:97:0c:68
[ 622.159308] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 622.360239] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 622.568248] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 622.776267] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 759.053074] wlan0: authenticate with e0:3f:49:97:0c:68
[ 759.075897] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 759.276802] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 759.484810] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 759.692829] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 913.971203] wlan0: authenticate with e0:3f:49:97:0c:68
[ 913.994407] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 914.203030] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 914.411037] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 914.619056] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 1063.896978] wlan0: authenticate with e0:3f:49:97:0c:68
[ 1063.919829] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 1064.120800] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 1064.328809] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 1064.536826] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 1230.816360] wlan0: authenticate with e0:3f:49:97:0c:68
[ 1230.838703] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 1231.040109] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 1231.243792] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 1231.448163] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 1250.385904] kworker/dying (27) used greatest stack depth: 11848 bytes left
[ 1386.726605] wlan0: authenticate with e0:3f:49:97:0c:68
[ 1386.749555] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 1386.950442] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 1387.158451] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 1387.366469] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 1518.642733] wlan0: authenticate with e0:3f:49:97:0c:68
[ 1518.665180] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 1518.866556] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 1519.074564] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 1519.282583] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 1653.551219] wlan0: authenticate with e0:3f:49:97:0c:68
[ 1653.574209] wlan0: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 1653.782935] wlan0: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 1653.990955] wlan0: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 1654.198974] wlan0: authentication with e0:3f:49:97:0c:68 timed out
[ 1718.100734] usb 2-1.4: USB disconnect, device number 7
[ 1718.131956] usb 2-1.4: rtl8192eu_active_to_emu: Disabling MAC timed out
[ 1718.132866] usb 2-1.4: disconnecting
^ permalink raw reply
* Re: [PATCH] realtek: rtl8xxxu: Use const init arrays
From: Jes Sorensen @ 2016-10-01 23:20 UTC (permalink / raw)
To: Joe Perches; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1475356122.1996.6.camel@perches.com>
Joe Perches <joe@perches.com> writes:
> On Sat, 2016-10-01 at 16:32 -0400, Jes Sorensen wrote:
>> Your output shows it moving to the text segment - if it's in a different
>> segment, eg. rodata, you should use output demonstrating that to justify
>> the change.
>
> For size, rodata _is_ text
Well then maybe use something which provides accurate data.
Jes
^ permalink raw reply
* Re: [PATCH] realtek: rtl8xxxu: Use const init arrays
From: Joe Perches @ 2016-10-01 21:08 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <wrfjponj4xpq.fsf@redhat.com>
On Sat, 2016-10-01 at 16:32 -0400, Jes Sorensen wrote:
> Your output shows it moving to the text segment - if it's in a different
> segment, eg. rodata, you should use output demonstrating that to justify
> the change.
For size, rodata _is_ text
^ permalink raw reply
* Re: [PATCH] realtek: rtl8xxxu: Use const init arrays
From: Jes Sorensen @ 2016-10-01 20:32 UTC (permalink / raw)
To: Joe Perches; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1475352058.1996.1.camel@perches.com>
Joe Perches <joe@perches.com> writes:
> On Sat, 2016-10-01 at 14:53 -0400, Jes Sorensen wrote:
>> Joe Perches <joe@perches.com> writes:
>> > Make the init arrays const to reduce data.
>> > $ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o*
>> > (allyesconfig: x86-32)
>> > text data bss dec hex filename
>> > 80107 13651 58 93816 16e78
>> > drivers/net/wireless/realtek/rtl8xxxu/built-in.o.new
>> > 65303 28435 58 93796 16e64
>> > drivers/net/wireless/realtek/rtl8xxxu/built-in.o.old
>> In total you grow the kernel by 20 bytes. You reduce the data segment
>> substantially while growing the text segment instead.
>
> No, not really. The alignment boundaries move a bit for
> this particular compilation. It could go the other way for
> a different compiler version or set of CONFIG options.
>
> What's important is multiple pages of .data move to .rodata.
Your output shows it moving to the text segment - if it's in a different
segment, eg. rodata, you should use output demonstrating that to justify
the change.
Jes
^ permalink raw reply
* Re: [PATCH] realtek: rtl8xxxu: Use const init arrays
From: Joe Perches @ 2016-10-01 20:00 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <wrfj37kf6gvd.fsf@redhat.com>
On Sat, 2016-10-01 at 14:53 -0400, Jes Sorensen wrote:
> Joe Perches <joe@perches.com> writes:
> > Make the init arrays const to reduce data.
> > $ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o* (allyesconfig: x86-32)
> > text data bss dec hex filename
> > 80107 13651 58 93816 16e78 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.new
> > 65303 28435 58 93796 16e64 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.old
> In total you grow the kernel by 20 bytes. You reduce the data segment
> substantially while growing the text segment instead.
No, not really. The alignment boundaries move a bit for
this particular compilation. It could go the other way for
a different compiler version or set of CONFIG options.
What's important is multiple pages of .data move to .rodata.
^ permalink raw reply
* Re: [PATCH] realtek: rtl8xxxu: Use const init arrays
From: Jes Sorensen @ 2016-10-01 18:53 UTC (permalink / raw)
To: Joe Perches; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <459bf15427d92cd052fb2fe080438fd97a8a6cd8.1475343483.git.joe@perches.com>
Joe Perches <joe@perches.com> writes:
> Make the init arrays const to reduce data.
>
> $ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o* (allyesconfig: x86-32)
> text data bss dec hex filename
> 80107 13651 58 93816 16e78 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.new
> 65303 28435 58 93796 16e64 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.old
>
> Signed-off-by: Joe Perches <joe@perches.com>
In total you grow the kernel by 20 bytes. You reduce the data segment
substantially while growing the text segment instead.
If any architecture replicates the text segment onto individual numa
nodes, this would actually be a real loss rather than a win. Some archs
used to do this, not sure if they are doing it anymore.
I am not against this patch, but I am not sure it's really a win either.
Jes
^ permalink raw reply
* [PATCH] realtek: rtl8xxxu: Use const init arrays
From: Joe Perches @ 2016-10-01 17:39 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
Make the init arrays const to reduce data.
$ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o* (allyesconfig: x86-32)
text data bss dec hex filename
80107 13651 58 93816 16e78 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.new
65303 28435 58 93796 16e64 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.old
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 6 +++---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 8 ++++----
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 6 +++---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 16 ++++++++--------
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 1016628926d2..bd4449704dfa 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1355,7 +1355,7 @@ struct rtl8xxxu_fileops {
u16 trxff_boundary;
u8 pbp_rx;
u8 pbp_tx;
- struct rtl8xxxu_reg8val *mactable;
+ const struct rtl8xxxu_reg8val *mactable;
u8 total_page_num;
u8 page_num_hi;
u8 page_num_lo;
@@ -1364,7 +1364,7 @@ struct rtl8xxxu_fileops {
extern int rtl8xxxu_debug;
-extern struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[];
+extern const struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[];
extern const u32 rtl8xxxu_iqk_phy_iq_bb_reg[];
u8 rtl8xxxu_read8(struct rtl8xxxu_priv *priv, u16 addr);
u16 rtl8xxxu_read16(struct rtl8xxxu_priv *priv, u16 addr);
@@ -1396,7 +1396,7 @@ int rtl8xxxu_init_phy_rf(struct rtl8xxxu_priv *priv,
struct rtl8xxxu_rfregval *table,
enum rtl8xxxu_rfpath path);
int rtl8xxxu_init_phy_regs(struct rtl8xxxu_priv *priv,
- struct rtl8xxxu_reg32val *array);
+ const struct rtl8xxxu_reg32val *array);
int rtl8xxxu_load_firmware(struct rtl8xxxu_priv *priv, char *fw_name);
void rtl8xxxu_firmware_self_reset(struct rtl8xxxu_priv *priv);
void rtl8xxxu_power_off(struct rtl8xxxu_priv *priv);
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index df54d27e7851..934a380f09b1 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -40,7 +40,7 @@
#include "rtl8xxxu.h"
#include "rtl8xxxu_regs.h"
-static struct rtl8xxxu_reg8val rtl8192e_mac_init_table[] = {
+static const struct rtl8xxxu_reg8val rtl8192e_mac_init_table[] = {
{0x011, 0xeb}, {0x012, 0x07}, {0x014, 0x75}, {0x303, 0xa7},
{0x428, 0x0a}, {0x429, 0x10}, {0x430, 0x00}, {0x431, 0x00},
{0x432, 0x00}, {0x433, 0x01}, {0x434, 0x04}, {0x435, 0x05},
@@ -70,7 +70,7 @@ static struct rtl8xxxu_reg8val rtl8192e_mac_init_table[] = {
{0xffff, 0xff},
};
-static struct rtl8xxxu_reg32val rtl8192eu_phy_init_table[] = {
+static const struct rtl8xxxu_reg32val rtl8192eu_phy_init_table[] = {
{0x800, 0x80040000}, {0x804, 0x00000003},
{0x808, 0x0000fc00}, {0x80c, 0x0000000a},
{0x810, 0x10001331}, {0x814, 0x020c3d10},
@@ -202,7 +202,7 @@ static struct rtl8xxxu_reg32val rtl8192eu_phy_init_table[] = {
{0xffff, 0xffffffff},
};
-static struct rtl8xxxu_reg32val rtl8xxx_agc_8192eu_std_table[] = {
+static const struct rtl8xxxu_reg32val rtl8xxx_agc_8192eu_std_table[] = {
{0xc78, 0xfb000001}, {0xc78, 0xfb010001},
{0xc78, 0xfb020001}, {0xc78, 0xfb030001},
{0xc78, 0xfb040001}, {0xc78, 0xfb050001},
@@ -271,7 +271,7 @@ static struct rtl8xxxu_reg32val rtl8xxx_agc_8192eu_std_table[] = {
{0xffff, 0xffffffff}
};
-static struct rtl8xxxu_reg32val rtl8xxx_agc_8192eu_highpa_table[] = {
+static const struct rtl8xxxu_reg32val rtl8xxx_agc_8192eu_highpa_table[] = {
{0xc78, 0xfa000001}, {0xc78, 0xf9010001},
{0xc78, 0xf8020001}, {0xc78, 0xf7030001},
{0xc78, 0xf6040001}, {0xc78, 0xf5050001},
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 6c086b5657e9..3f173b67fc0d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -40,7 +40,7 @@
#include "rtl8xxxu.h"
#include "rtl8xxxu_regs.h"
-static struct rtl8xxxu_reg8val rtl8723b_mac_init_table[] = {
+static const struct rtl8xxxu_reg8val rtl8723b_mac_init_table[] = {
{0x02f, 0x30}, {0x035, 0x00}, {0x039, 0x08}, {0x04e, 0xe0},
{0x064, 0x00}, {0x067, 0x20}, {0x428, 0x0a}, {0x429, 0x10},
{0x430, 0x00}, {0x431, 0x00},
@@ -71,7 +71,7 @@ static struct rtl8xxxu_reg8val rtl8723b_mac_init_table[] = {
{0xffff, 0xff},
};
-static struct rtl8xxxu_reg32val rtl8723b_phy_1t_init_table[] = {
+static const struct rtl8xxxu_reg32val rtl8723b_phy_1t_init_table[] = {
{0x800, 0x80040000}, {0x804, 0x00000003},
{0x808, 0x0000fc00}, {0x80c, 0x0000000a},
{0x810, 0x10001331}, {0x814, 0x020c3d10},
@@ -172,7 +172,7 @@ static struct rtl8xxxu_reg32val rtl8723b_phy_1t_init_table[] = {
{0xffff, 0xffffffff},
};
-static struct rtl8xxxu_reg32val rtl8xxx_agc_8723bu_table[] = {
+static const struct rtl8xxxu_reg32val rtl8xxx_agc_8723bu_table[] = {
{0xc78, 0xfd000001}, {0xc78, 0xfc010001},
{0xc78, 0xfb020001}, {0xc78, 0xfa030001},
{0xc78, 0xf9040001}, {0xc78, 0xf8050001},
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index b2d7f6e69667..7c62293948cb 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -135,7 +135,7 @@ static struct ieee80211_supported_band rtl8xxxu_supported_band = {
.n_bitrates = ARRAY_SIZE(rtl8xxxu_rates),
};
-struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[] = {
+const struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[] = {
{0x420, 0x80}, {0x423, 0x00}, {0x430, 0x00}, {0x431, 0x00},
{0x432, 0x00}, {0x433, 0x01}, {0x434, 0x04}, {0x435, 0x05},
{0x436, 0x06}, {0x437, 0x07}, {0x438, 0x00}, {0x439, 0x00},
@@ -160,7 +160,7 @@ struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[] = {
{0x70a, 0x65}, {0x70b, 0x87}, {0xffff, 0xff},
};
-static struct rtl8xxxu_reg32val rtl8723a_phy_1t_init_table[] = {
+static const struct rtl8xxxu_reg32val rtl8723a_phy_1t_init_table[] = {
{0x800, 0x80040000}, {0x804, 0x00000003},
{0x808, 0x0000fc00}, {0x80c, 0x0000000a},
{0x810, 0x10001331}, {0x814, 0x020c3d10},
@@ -258,7 +258,7 @@ static struct rtl8xxxu_reg32val rtl8723a_phy_1t_init_table[] = {
{0xffff, 0xffffffff},
};
-static struct rtl8xxxu_reg32val rtl8192cu_phy_2t_init_table[] = {
+static const struct rtl8xxxu_reg32val rtl8192cu_phy_2t_init_table[] = {
{0x024, 0x0011800f}, {0x028, 0x00ffdb83},
{0x800, 0x80040002}, {0x804, 0x00000003},
{0x808, 0x0000fc00}, {0x80c, 0x0000000a},
@@ -356,7 +356,7 @@ static struct rtl8xxxu_reg32val rtl8192cu_phy_2t_init_table[] = {
{0xffff, 0xffffffff},
};
-static struct rtl8xxxu_reg32val rtl8188ru_phy_1t_highpa_table[] = {
+static const struct rtl8xxxu_reg32val rtl8188ru_phy_1t_highpa_table[] = {
{0x024, 0x0011800f}, {0x028, 0x00ffdb83},
{0x040, 0x000c0004}, {0x800, 0x80040000},
{0x804, 0x00000001}, {0x808, 0x0000fc00},
@@ -455,7 +455,7 @@ static struct rtl8xxxu_reg32val rtl8188ru_phy_1t_highpa_table[] = {
{0xffff, 0xffffffff},
};
-static struct rtl8xxxu_reg32val rtl8xxx_agc_standard_table[] = {
+static const struct rtl8xxxu_reg32val rtl8xxx_agc_standard_table[] = {
{0xc78, 0x7b000001}, {0xc78, 0x7b010001},
{0xc78, 0x7b020001}, {0xc78, 0x7b030001},
{0xc78, 0x7b040001}, {0xc78, 0x7b050001},
@@ -539,7 +539,7 @@ static struct rtl8xxxu_reg32val rtl8xxx_agc_standard_table[] = {
{0xffff, 0xffffffff}
};
-static struct rtl8xxxu_reg32val rtl8xxx_agc_highpa_table[] = {
+static const struct rtl8xxxu_reg32val rtl8xxx_agc_highpa_table[] = {
{0xc78, 0x7b000001}, {0xc78, 0x7b010001},
{0xc78, 0x7b020001}, {0xc78, 0x7b030001},
{0xc78, 0x7b040001}, {0xc78, 0x7b050001},
@@ -2146,7 +2146,7 @@ void rtl8xxxu_firmware_self_reset(struct rtl8xxxu_priv *priv)
static int
rtl8xxxu_init_mac(struct rtl8xxxu_priv *priv)
{
- struct rtl8xxxu_reg8val *array = priv->fops->mactable;
+ const struct rtl8xxxu_reg8val *array = priv->fops->mactable;
int i, ret;
u16 reg;
u8 val;
@@ -2174,7 +2174,7 @@ rtl8xxxu_init_mac(struct rtl8xxxu_priv *priv)
}
int rtl8xxxu_init_phy_regs(struct rtl8xxxu_priv *priv,
- struct rtl8xxxu_reg32val *array)
+ const struct rtl8xxxu_reg32val *array)
{
int i, ret;
u16 reg;
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* Re: [PATCH 1/2] rtl8xxxu: Fix rtl8723bu driver reload issue
From: Jes Sorensen @ 2016-10-01 12:29 UTC (permalink / raw)
To: Greg KH; +Cc: linux-wireless, kvalo, Larry.Finger, stable
In-Reply-To: <20161001115622.GB15156@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Fri, Sep 30, 2016 at 07:35:17PM -0400, Jes.Sorensen@redhat.com wrote:
>> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>>
>> The generic disable_rf() function clears bits 22 and 23 in
>> REG_RX_WAIT_CCA, however we did not re-enable them again in
>> rtl8723b_enable_rf()
>>
>> This resolves the problem for me with 8723bu devices not working again
>> after reloading the driver.
>>
>> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
>> ---
>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
>
> </formletter>
DOH Kalle told me to CC stable I took it for granted that you meant CC
in the email sense. Guess I get to blame my self for looking like a
fool in public.
I'll send you an email directly with the SHA once it hits Linus' tree
instead.
Jes
^ permalink raw reply
* Re: [PATCH 1/2] rtl8xxxu: Fix rtl8723bu driver reload issue
From: Greg KH @ 2016-10-01 11:56 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-wireless, kvalo, Larry.Finger, stable
In-Reply-To: <1475278518-18527-2-git-send-email-Jes.Sorensen@redhat.com>
On Fri, Sep 30, 2016 at 07:35:17PM -0400, Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> The generic disable_rf() function clears bits 22 and 23 in
> REG_RX_WAIT_CCA, however we did not re-enable them again in
> rtl8723b_enable_rf()
>
> This resolves the problem for me with 8723bu devices not working again
> after reloading the driver.
>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++++
> 1 file changed, 4 insertions(+)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Krishna Chaitanya @ 2016-10-01 12:02 UTC (permalink / raw)
To: Arend van Spriel
Cc: Gucea Doru, Arend van Spriel, Andra Paraschiv, linux-wireless
In-Reply-To: <ed4a7366-3f67-79da-0868-876a69b1da54@broadcom.com>
On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
>
>
> On 29-09-16 13:32, Gucea Doru wrote:
>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>> What is the decision triggering the exit from the PS mode immediately
>>> after the ping request? I am asking this because 802.11 PS legacy
>>> specifies that the client should wait for a beacon with TIM set in
>>> order to wake up: in my case, there is no beacon between the ping
>>> request message and the Null frame that announces the exit from the PS
>>> mode.
>>
>>
>> Any help would be highly appreciated :)
>
> Actually though I already sent you are reply, but alas here it is.
>
> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
> drivers. Regardless your question is more for firmware running on the
> device. So like the same behavior would be observed when using brcmfmac
> with same firmware.
>
>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>> shall issue a PS Poll". In my capture there are cases when the STA
>> exits the PS mode without waiting for a beacon.
>
> It is a bit tricky, but the standard does not explicitly say the STA
> should be in power-save at any other time. So it is difficult to say
> what event occurred on the STA side to exit PS mode. Also STA means
> P2P-Client as you say. That means that you have multiple interfaces:
> regular STA and P2P-Client. So is the STA connected to some other AP or
> just not connected. wpa_supplicant will do intermittent scan or initiate
> scheduled scan by which firmware will scan at a certain interval. That
> is just some things I can come up with and I am sure there are more.
Keeping the STA aside, as far as AP is concerned the STA is still in PS,
so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
Because the STA might be in power-off mode things seem to work.
^ permalink raw reply
* Re: nl80211 fine timing measurement support
From: Arend van Spriel @ 2016-10-01 9:56 UTC (permalink / raw)
To: Lior David, Luca Coelho, Johannes Berg
Cc: Maya Erez, Jouni Malinen, linux-wireless
In-Reply-To: <b7022d3c-51ff-96eb-f6f0-319eb5ea66b0@codeaurora.org>
On 20-09-16 22:57, Lior David wrote:
> On 9/20/2016 9:39 AM, Luca Coelho wrote:
>> On Mon, 2016-09-19 at 20:42 +0200, Arend Van Spriel wrote:
>>>
>>> On 19-9-2016 19:31, Lior David wrote:
>>>>
>>>> Hi Johannes,
>>>>
>>>> We are working on adding indoor location support to the wil6210
>>>> 11ad driver. This includes fine timing measurement (FTM) as well as
>>>> something we call angle of arrival (AOA) which measures azimuth and
>>>> elevation.
>>>> Initially we implemented it internally using vendor commands but we
>>>> would like to upstream it using standard nl80211 API.
>>>> I noticed a patch you sent some time ago (https://patchwork.kernel.
>>>> org/patch/7790701/) for adding fine timing measurement support to
>>>> nl80211, it looks like a good baseline though we do have few issues
>>>> with it... However I did not see any comments or response on this
>>>> patch. Can you please update if you plan on eventually submitting
>>>> this patch?
>>>
>>> You can find several FTM related patches in backport-iwlwifi repo on
>>> kernel.org. See link to git log of nl80211.h there [1].
>>
>> We have a full FTM implementation in our internal tree (which is
>> published in the URL Arend provided) and we are currently working on
>> cleaning it up for upstream submission. You should see patches from us
>> this week.
>>
> That's great to hear, thanks :-)
> I reviewed your FTM nl80211 API and have some comments. I can send these
> comments once you send the cleaned up patch (most are small issues), but there
> is one issue I would like to raise in advance:
> In the measurement response you report the final calculated RTT (is this
> for each burst or calculated from all bursts?). Our implementation
> reports the raw measurement results (t1, t2, t3, t4 for each measurement
> as well as TOD and TOA errors at responder and initiator as defined in IEEE
> P802.11-REVmc/D7.0, 9.6.8.33). Reporting the final RTT does have benefits, so I
> checked with our location framework developers. The general consensus is they
> prefer to get the raw results, mainly because there are some useful analysis
> algorithms they can run, and in addition the firmware may not be strong enough
> to perform the calculations for deriving the final RTT (it could be done in the
> driver but I don't think this is a proper place for it). Maybe we should
> provide option for reporting both raw and RTT results where drivers can
> support either or both?
If raw results are mainly used for analysis algorithms how about
providing raw measurement data through debugfs. May even consider adding
rtt calculation in cfg80211/mac80211 for drivers that choose to provide
raw measurement data and still only report final RTT in nl80211 api.
Regards,
Arend
> For reference, we have also implemented FTM internally using vendor
> commands. The vendor commands API that we defined can be seen at [1],
> the actual implementation is still under internal review so not yet
> published.
>
> Thanks,
> Lior
>
> [1] http://w1.fi/cgit/hostap/commit/?id=fcd85d9a3f2d9d63d0fa57e93446ad467db75b23
>
>
>> --
>> Cheers,
>> Luca.
>>
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Arend van Spriel @ 2016-10-01 9:22 UTC (permalink / raw)
To: Gucea Doru, Arend van Spriel; +Cc: Andra Paraschiv, linux-wireless
In-Reply-To: <CANfLQrZxEUX0UMwrVNZHps9ztqxmOaeovy34fey2NkErCDDarQ@mail.gmail.com>
On 29-09-16 13:32, Gucea Doru wrote:
> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>> What is the decision triggering the exit from the PS mode immediately
>> after the ping request? I am asking this because 802.11 PS legacy
>> specifies that the client should wait for a beacon with TIM set in
>> order to wake up: in my case, there is no beacon between the ping
>> request message and the Null frame that announces the exit from the PS
>> mode.
>
>
> Any help would be highly appreciated :)
Actually though I already sent you are reply, but alas here it is.
bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
drivers. Regardless your question is more for firmware running on the
device. So like the same behavior would be observed when using brcmfmac
with same firmware.
> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
> detects that the bit corresponding to its AID is 1 i the TIM, the STA
> shall issue a PS Poll". In my capture there are cases when the STA
> exits the PS mode without waiting for a beacon.
It is a bit tricky, but the standard does not explicitly say the STA
should be in power-save at any other time. So it is difficult to say
what event occurred on the STA side to exit PS mode. Also STA means
P2P-Client as you say. That means that you have multiple interfaces:
regular STA and P2P-Client. So is the STA connected to some other AP or
just not connected. wpa_supplicant will do intermittent scan or initiate
scheduled scan by which firmware will scan at a certain interval. That
is just some things I can come up with and I am sure there are more.
Regards,
Arend
^ permalink raw reply
* Re: RTL8192EU on rtl8xxxu driver breaks every few minutes
From: Jes Sorensen @ 2016-09-30 23:39 UTC (permalink / raw)
To: Franc[e]sco; +Cc: linux-wireless
In-Reply-To: <80b8ae50-ca27-674f-0e7e-79b931bae199@waifu.club>
[-- Attachment #1: Type: text/plain, Size: 954 bytes --]
"Franc[e]sco" <lolisamurai@waifu.club> writes:
> Oops, forgot to forward the previous reply to the mailing list.
>
> I have attached the output of iw link
>
> the AP is an asus dsl-n55u router in 2.4 GHz mode, using WPA2-Personal
> with AES encryption. It's also running a second 5GHz wireless network
> which has a different SSID.
>
> Also, this seems to be some kind of power saving kicking in, as the
> dongle keeps working as long as I keep doing things over ssh.
I just pushed a patch into rtl8xxxu-devel which may resolve this issue.
There were problems with the 8192eu not handling driver reload very
well. It is possible the network scripts you run would trigger the shut
down and restart that caused this problem.
I would be interested in knowing if this patch resolves the problem for
you.
Jes
PS: Please fix your mail client - adding unlisted-recipients to the Cc
line and cutting out the person you are responding to is really
annoying.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-rtl8xxxu-Fix-rtl8192eu-driver-reload-issue.patch --]
[-- Type: text/x-patch, Size: 1873 bytes --]
>From 93064d0ae3e9d97c03a3aabd71e6048e1ac82f46 Mon Sep 17 00:00:00 2001
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Date: Fri, 30 Sep 2016 19:18:34 -0400
Subject: [PATCH 2/2] rtl8xxxu: Fix rtl8192eu driver reload issue
The 8192eu suffered from two issues when reloading the driver.
The same problems as with the 8723bu where REG_RX_WAIT_CCA bits 22 and
23 didn't get set in rtl8192e_enable_rf().
In addition it also seems prone to issues when setting REG_RF_CTRL to
0 intead of just disabling the RF_ENABLE bit. Similar to what was
causing issues with the 8188eu.
With this patch I can successfully reload the driver and reassociate
to an APi with an 8192eu dongle.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index df54d27..a793fed 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -1461,7 +1461,9 @@ static int rtl8192eu_active_to_emu(struct rtl8xxxu_priv *priv)
int count, ret = 0;
/* Turn off RF */
- rtl8xxxu_write8(priv, REG_RF_CTRL, 0);
+ val8 = rtl8xxxu_read8(priv, REG_RF_CTRL);
+ val8 &= ~RF_ENABLE;
+ rtl8xxxu_write8(priv, REG_RF_CTRL, val8);
/* Switch DPDT_SEL_P output from register 0x65[2] */
val8 = rtl8xxxu_read8(priv, REG_LEDCFG2);
@@ -1593,6 +1595,10 @@ static void rtl8192e_enable_rf(struct rtl8xxxu_priv *priv)
u32 val32;
u8 val8;
+ val32 = rtl8xxxu_read32(priv, REG_RX_WAIT_CCA);
+ val32 |= (BIT(22) | BIT(23));
+ rtl8xxxu_write32(priv, REG_RX_WAIT_CCA, val32);
+
val8 = rtl8xxxu_read8(priv, REG_GPIO_MUXCFG);
val8 |= BIT(5);
rtl8xxxu_write8(priv, REG_GPIO_MUXCFG, val8);
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] rtl8xxxu: Fix driver reload issues with 8723bu and 8192eu
From: Jes.Sorensen @ 2016-09-30 23:35 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Hi,
These two patches fix issues where rtl8723bu and rtl8192eu dongles
would stop receving data if one reloaded the driver module, requiring
it to be physically removed and reinserted.
Both issues are applicable to 4.9. The first patch for 8723bu is
applicable to stable 4.7 and 4.8. The second patch will only be
applicable to stable 4.8, once patches currently in flight are merged
by the network maintainers.
Cheers,
Jes
Jes Sorensen (2):
rtl8xxxu: Fix rtl8723bu driver reload issue
rtl8xxxu: Fix rtl8192eu driver reload issue
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 8 +++++++-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++++
2 files changed, 11 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [PATCH 2/2] rtl8xxxu: Fix rtl8192eu driver reload issue
From: Jes.Sorensen @ 2016-09-30 23:35 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
In-Reply-To: <1475278518-18527-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
The 8192eu suffered from two issues when reloading the driver.
The same problems as with the 8723bu where REG_RX_WAIT_CCA bits 22 and
23 didn't get set in rtl8192e_enable_rf().
In addition it also seems prone to issues when setting REG_RF_CTRL to
0 intead of just disabling the RF_ENABLE bit. Similar to what was
causing issues with the 8188eu.
With this patch I can successfully reload the driver and reassociate
to an APi with an 8192eu dongle.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index df54d27..a793fed 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -1461,7 +1461,9 @@ static int rtl8192eu_active_to_emu(struct rtl8xxxu_priv *priv)
int count, ret = 0;
/* Turn off RF */
- rtl8xxxu_write8(priv, REG_RF_CTRL, 0);
+ val8 = rtl8xxxu_read8(priv, REG_RF_CTRL);
+ val8 &= ~RF_ENABLE;
+ rtl8xxxu_write8(priv, REG_RF_CTRL, val8);
/* Switch DPDT_SEL_P output from register 0x65[2] */
val8 = rtl8xxxu_read8(priv, REG_LEDCFG2);
@@ -1593,6 +1595,10 @@ static void rtl8192e_enable_rf(struct rtl8xxxu_priv *priv)
u32 val32;
u8 val8;
+ val32 = rtl8xxxu_read32(priv, REG_RX_WAIT_CCA);
+ val32 |= (BIT(22) | BIT(23));
+ rtl8xxxu_write32(priv, REG_RX_WAIT_CCA, val32);
+
val8 = rtl8xxxu_read8(priv, REG_GPIO_MUXCFG);
val8 |= BIT(5);
rtl8xxxu_write8(priv, REG_GPIO_MUXCFG, val8);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] rtl8xxxu: Fix rtl8723bu driver reload issue
From: Jes.Sorensen @ 2016-09-30 23:35 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
In-Reply-To: <1475278518-18527-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
The generic disable_rf() function clears bits 22 and 23 in
REG_RX_WAIT_CCA, however we did not re-enable them again in
rtl8723b_enable_rf()
This resolves the problem for me with 8723bu devices not working again
after reloading the driver.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 6c086b5..02b8ddd 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1498,6 +1498,10 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
u32 val32;
u8 val8;
+ val32 = rtl8xxxu_read32(priv, REG_RX_WAIT_CCA);
+ val32 |= (BIT(22) | BIT(23));
+ rtl8xxxu_write32(priv, REG_RX_WAIT_CCA, val32);
+
/*
* No indication anywhere as to what 0x0790 does. The 2 antenna
* vendor code preserves bits 6-7 here.
--
2.7.4
^ permalink raw reply related
* pull-request: mac80211-next 2016-09-30
From: Johannes Berg @ 2016-09-30 16:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Last pull request before the merge window, since it's about to open :)
It seems that everyone finally agreed on the NAN (neighbor awareness
networking) APIs, so we have that, along with some other things.
Let me know if there's any problem.
Thanks,
johannes
The following changes since commit c13ed534b8db543e4d8ead3885f4b06585a5771c:
Merge tag 'mac80211-next-for-davem-2016-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next (2016-09-18 22:29:08 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-09-30
for you to fetch changes up to bb42f2d13ffcd0baed7547b37d05add51fcd50e1:
mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue (2016-09-30 14:46:57 +0200)
----------------------------------------------------------------
This time around, we have
* Neighbor Awareness Networking (NAN) APIs
* a fix for a previous patch that caused memory corruption
in wireless extensions key settings
* beacon rate configuration for AP and mesh
* memory limits for mac80211's internal TXQs
* a (fairly involved) fix for the TXQ vs. crypto problems
* direct cfg80211 driver API for WEP keys
----------------------------------------------------------------
Ayala Beker (9):
cfg80211: add start / stop NAN commands
mac80211: add boilerplate code for start / stop NAN
cfg80211: add add_nan_func / del_nan_func
cfg80211: allow the user space to change current NAN configuration
cfg80211: provide a function to report a match for NAN
cfg80211: Provide an API to report NAN function termination
mac80211: implement nan_change_conf
mac80211: Implement add_nan_func and rm_nan_func
mac80211: Add API to report NAN function match
David Spinadel (1):
cfg80211: Add support for static WEP in the driver
Johannes Berg (2):
cfg80211: add checks for beacon rate, extend to mesh
cfg80211: wext: really don't store non-WEP keys
Pedersen, Thomas (2):
mac80211: add offset_tsf driver op and use it for mesh
mac80211: mesh: decrease max drift
Purushottam Kushwaha (1):
cfg80211: Add support to configure a beacon data rate
Toke Høiland-Jørgensen (5):
mac80211: Move ieee802111_tx_dequeue() to later in tx.c
fq.h: Port memory limit mechanism from fq_codel
mac80211: Export fq memory limit information in debugfs
mac80211: Set lower memory limit for non-VHT devices
mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue
include/net/cfg80211.h | 223 +++++++-
include/net/fq.h | 3 +
include/net/fq_impl.h | 7 +-
include/net/mac80211.h | 75 +++
include/uapi/linux/nl80211.h | 270 ++++++++-
net/mac80211/cfg.c | 208 +++++++
net/mac80211/chan.c | 6 +
net/mac80211/debugfs.c | 8 +
net/mac80211/debugfs_netdev.c | 12 +-
net/mac80211/driver-ops.c | 15 +
net/mac80211/driver-ops.h | 83 +++
net/mac80211/ieee80211_i.h | 26 +
net/mac80211/iface.c | 28 +-
net/mac80211/main.c | 8 +
net/mac80211/mesh_sync.c | 12 +-
net/mac80211/offchannel.c | 4 +-
net/mac80211/rx.c | 7 +-
net/mac80211/sta_info.c | 10 +-
net/mac80211/trace.h | 159 ++++++
net/mac80211/tx.c | 351 ++++++++----
net/mac80211/util.c | 61 ++-
net/wireless/chan.c | 2 +
net/wireless/core.c | 35 ++
net/wireless/core.h | 7 +-
net/wireless/ibss.c | 5 +-
net/wireless/mlme.c | 1 +
net/wireless/nl80211.c | 1220 ++++++++++++++++++++++++++++++++---------
net/wireless/rdev-ops.h | 58 ++
net/wireless/sme.c | 6 +-
net/wireless/trace.h | 90 +++
net/wireless/util.c | 30 +-
net/wireless/wext-compat.c | 14 +-
net/wireless/wext-sme.c | 2 +-
33 files changed, 2648 insertions(+), 398 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Arnd Bergmann @ 2016-09-30 14:58 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Kalle Valo, linux-wireless, devicetree
In-Reply-To: <557be2b8-5ff1-83ea-f6d1-6421c2465969@nbd.name>
On Friday 30 September 2016, Felix Fietkau wrote:
> >> >> >> + device_type = "pci";
> >> >> >> + mediatek,mtd-eeprom = <&factory 0x8000>;
> >> >> >> + mediatek,2ghz = <0>;
> >> >
> >> > It's not clear what the possible values for the 2ghz property are,
> >> > can you be more verbose in the description? How is <0> different
> >> > from no property?
> >> 0 means disabled, no property means unchanged (compared to EEPROM).
> >
> > Maybe have a boolean property instead then to say "mediatek,2ghz-disabled" ?
> >
> > If zero is the only possible value, there is no need to put a number in there.
> 1 is also possible, which will force-enable the capability.
Ok, then both those values should be documented in the binding.
Arnd
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Felix Fietkau @ 2016-09-30 14:44 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Kalle Valo, linux-wireless, devicetree
In-Reply-To: <201609301636.43363.arnd@arndb.de>
On 2016-09-30 16:36, Arnd Bergmann wrote:
> On Friday 30 September 2016, Felix Fietkau wrote:
>> >> >> + pcie0 {
>> >> >> + mt76@0,0 {
>> >> >> + reg = <0x0000 0 0 0 0>;
>> >
>> > Maybe have an examplep of a real register address other than zero?
>> This is a real example referring to the first device on a PCI bus.
>> I copy&pasted this from a .dts file that we use in LEDE.
>
> Ok, I see.
>
>> >> >> + device_type = "pci";
>> >> >> + mediatek,mtd-eeprom = <&factory 0x8000>;
>> >> >> + mediatek,2ghz = <0>;
>> >
>> > It's not clear what the possible values for the 2ghz property are,
>> > can you be more verbose in the description? How is <0> different
>> > from no property?
>> 0 means disabled, no property means unchanged (compared to EEPROM).
>
> Maybe have a boolean property instead then to say "mediatek,2ghz-disabled" ?
>
> If zero is the only possible value, there is no need to put a number in there.
1 is also possible, which will force-enable the capability.
- Felix
^ permalink raw reply
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