Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

On Tue, Jul 28, 2015 at 5:47 AM, Adrian Chadd adr...@freebsd.org wrote: Those are some high values (eg from noise/spur somewhere) and the driver is deciding to program in -110. So the radio thinks its deaf. That made me think... I have a second ath9k device, this time with an AR9300 (note, this

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

On Wed, Jul 29, 2015 at 12:22 AM, Adrian Chadd adr...@freebsd.org wrote: Hm, doesn't someone have a graphical frontend for this on linux? Yep, I just found FFT_eval (screenshot: [0] and ath_spectral (screenshot [1]) in the ath9k spectral scan wiki page. [0] http://abload.de/img/athscanfjsvv.png

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

On Wed, Jul 29, 2015 at 1:37 AM, Adrian Chadd adr...@freebsd.org wrote: Cool! Does it let you capture lots of samples over time and plot them? At least FFT_eval would allow capturing samples, but the device with the AR9227 is a small router - no screen there, so I have to dump it on that device,

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

On Wed, Jul 29, 2015 at 9:49 AM, Adrian Chadd adr...@freebsd.org wrote: ok, can you re-run this again before the NF patch, so I can compare? Sure, here they are: [0] And here are the NF values reported by ath9k right before that: # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal Channel

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

On Tue, Jul 28, 2015 at 7:25 PM, Adrian Chadd adr...@freebsd.org wrote: So the values aren't bad on the 1043nd - they're in 1/2 or 1/4dB, but there's no scalar quantity (ie, it's not in dBm.) The 1043nd calibrates down to around -95 or so, which sounds like it's in dBm but it isn't, and any

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

Hi Adrian, On Wed, Jul 29, 2015 at 10:49 AM, Martin Blumenstingl martin.blumensti...@googlemail.com wrote: Sure, here they are: [0] Was this data useful for you? Let me know if you need more information. Regards, Martin -- To unsubscribe from this list: send the line unsubscribe linux-wireless

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

Hi Adrian, On Mon, Jul 27, 2015 at 9:13 PM, Adrian Chadd adr...@freebsd.org wrote: I wonder if this is a mis-merge on my part (I'm the freebsd maintainer.) can you log the noisefloor calibrated values before and after the patch? I'd like to see how low it calibrrates to. Sure, I hope

Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

On Tue, Jul 28, 2015 at 1:50 AM, Adrian Chadd adr...@freebsd.org wrote: is it never getting any readings before your patch? NF Readings all look empty... Yes, looks like it. Unfortunately I haven't saved a complete kernel log (with ath9k debug level = 0x4449) but only a few parts. Here are

Re: [RFC] ath9k: Simplify and fix eeprom endianness swapping

On Thu, Oct 15, 2015 at 12:33 AM, Martin Blumenstingl <martin.blumensti...@googlemail.com> wrote: > I have tested my patch on a single AR9227 device and there it's > working fine. It would be great if more people would give this a go > before merging this patch. I have just tested

[PATCH V2] ath9k: Simplify and fix eeprom endianness swapping

ifics from the other implementations. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- V2: Use the AH_NO_EEP_SWAP flag to decide if swapping is required. If this flag is set then we assume that the contents of the EEPROM are using the correct endianness even

[RFC] ath9k: Simplify and fix eeprom endianness swapping

ath9k has some code which is supposed to adjust the endianness of the eeprom's contents in case it does not match the CPU endianness. However, it seems that this code was only working properly for chips that used eeprom_def. I personally have a device with an AR9227 chipset which uses an eeprom

[PATCH] ath9k: Simplify and fix eeprom endianness swapping

ifics from the other implementations. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath9k/eeprom.c | 75 +++ drivers/net/wireless/ath/ath9k/eeprom.h | 3 ++ drivers/net/wireless/ath/ath9k/ee

Re: [patch -next] ath9k: fix ath9k_hw_nvram_check_version()

On Sat, Dec 19, 2015 at 11:59 AM, Dan Carpenter <dan.carpen...@oracle.com> wrote: > There is a type bug so it always returns success. > > Fixes: 6fa658fd5ab2 ('ath9k: Simplify and fix eeprom endianness swapping') > Signed-off-by: Dan Carpenter <dan.carpen...@oracle.

[PATCH 1/6] ath9k: Allow configuration of LED polarity in platform data.

Some devices running OpenWrt need this and it makes sense to add this to ath9k_platform_data as the next patches will add a devicetree (boolean) property for it as well. Suggested-by: Vittorio Gambaletta <open...@vittgam.net> Signed-off-by: Martin Blumenstingl <martin.blumensti...@googl

[PATCH 5/6] ath9k: move all ath9k_platform_data initialization into one function

No functional changes, this simply makes the code easier to understand because all initialization based on ath9k_platform_data is now within one function. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath9k/init.

[PATCH 6/6] ath9k: simplify the code-paths when not using the built-in EEPROM

tform_data. With this change all eeprom data handling is now unified in eeprom.c. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- This supersedes the following patch by Eduardo Abinader <eduardo.abina...@riverbed.com>: "ath9k: return false when reading

[PATCH 4/6] ath9k: remove return value from ath9k_hw_init_macaddr

ath9k_hw_init_macaddr unconditionally returns 0 in all cases, making the return value unnecessary. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath9k/hw.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff

[PATCH 3/6] ath9k: ath9k_hw_init_macaddr should not overwrite valid MAC addresses

Currently setting the MAC address via ath9k_platform_data works only due to the order in which init.c sets common->macaddr, which is done after ath9k_hw_init_macaddr was executed. It would be better if the latter was independent of the order in which it's being called. Signed-off-by: Mar

[PATCH 2/6] ath9k: remove variable which is set but never read

No functional changes - this only removes a variable which is set but never read. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath9k/hw.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/d

ath9k: extend and improve handling of ath9k_platform_data

This series improves handling of ath9k_platform_data inside ath9k. A quick summary of the changes is: - led_active_high can now be configured via ath9k_platform_data: This change is based on a patch originally written by Vittorio Gambaletta which is part of OpenWrt's ath9k patches. - small

[PATCH 2/2] Documentation: dt: net: add ath9k wireless device binding

Add documentation how devicetree can be used to configure ath9k based devices. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- .../devicetree/bindings/net/wireless/ath,ath9k.txt | 40 ++ 1 file changed, 40 insertions(+) create mode

[RFC] ath9k: add devicetree support to ath9k

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 as soon as the ath79 platform is ready to populate the ath9k wmac via devicetree. This series depends on my previous series: "ath9k:

[PATCH RFC v2 2/2] ath9k: parse the device configuration from an OF node

This makes it possible to configure ath9k based devices using devicetree. That makes some out-of-tree "convert devicetree to ath9k_platform_data glue"-code obsolete. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- changes in v1 -> v2: - use vendor p

[RFC v2] ath9k: add devicetree support to ath9k

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 as soon as the ath79 platform is ready to populate the ath9k wmac via devicetree. This series depends on my previous series: "ath9k:

[PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

Add documentation how devicetree can be used to configure ath9k based devices. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- changes in v1 -> v2: - use vendor prefix "qca" instead of "ath" - extend the example so it includes the "com

Re: [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

On Thu, Jun 23, 2016 at 7:58 PM, Mark Rutland <mark.rutl...@arm.com> wrote: > On Thu, Jun 23, 2016 at 07:45:35PM +0200, Martin Blumenstingl wrote: >> Add documentation how devicetree can be used to configure ath9k based >> devices. >> >> Signed-off-by: Mart

[PATCH RFC v3 3/3] ath9k: parse the device configuration from an OF node

This makes it possible to configure ath9k based devices using devicetree. That makes some out-of-tree "convert devicetree to ath9k_platform_data glue"-code obsolete. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- changes in v2 -> v3: - repla

[PATCH v3 2/3] ath9k: add a helper to get the string representation of ath_bus_type

Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- this is a new patch which didn't exist in v2 yet, it prepares the new function ath_bus_type_to_string which will be used in patch #3 drivers/net/wireless/ath/ath.h | 2 ++ drivers/net/wireless/ath/main.

[PATCH RFC v3 1/3] Documentation: dt: net: add ath9k wireless device binding

Add documentation how devicetree can be used to configure ath9k based devices. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- changes in v2 -> v3: - improved wording of the qca,disable-2ghz and qca,disable-5ghz properties - replaced qca,eeprom-name with qca,

[RFC v3] ath9k: add devicetree support to ath9k

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 as soon as the ath79 platform is ready to populate the ath9k wmac via devicetree. This series depends on my previous series: "ath9k:

Re: [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

On Thu, Jun 23, 2016 at 9:25 PM, Arend Van Spriel wrote: >> +Optional properties: >> +- reg: Address and length of the register set for the device. > > Is 'reg' property handled. I don't see it in patch 2/2. for AHB we would probably have to handle it separately, but

Re: [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

On Mon, Jun 27, 2016 at 2:57 PM, Mark Rutland wrote: >> > Please find a better way to identify relevant FW. What exactly affects >> > which FW can be used, or would ideally be used? Are different FWs >> > required for the same HW in some contexts? >> > >> > Can we not figure

Re: [PATCH] ath9k_hw: ignore eeprom magic mismatch on flash based devices

uot;) > Signed-off-by: Felix Fietkau <n...@openwrt.org> Acked-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> After I misread the patch in the first place here's an explanation what the main point is: there are (many) devices out there which have the EEPROM dat

Re: [PATCH v4 1/3] Documentation: dt: net: add ath9k wireless device binding

On Mon, Jul 11, 2016 at 12:01 AM, Arnd Bergmann wrote: >> ath9k reads the data from the EEPROM into memory. With that property >> disabled ath9k simply assumes that the endianness of the values in the >> EEPROM are having the correct endianness for the host system (in other >>

[PATCH v4 0/3] add devicetree support to ath9k

nted out typos. - use an array for accessing the string representation of the bus types (as suggested by Felix) 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

[PATCH v4 2/3] ath9k: add a helper to get the string representation of ath_bus_type

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.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath.h | 6 ++ drivers/net/wireless/ath/main.c | 7 +++ 2 files changed, 13 inse

[PATCH v4 1/3] Documentation: dt: net: add ath9k wireless device binding

Add documentation how devicetree can be used to configure ath9k based devices. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- .../devicetree/bindings/net/wireless/qca,ath9k.txt | 59 ++ 1 file changed, 59 insertions(+) create mode

[PATCH v4 3/3] ath9k: parse the device configuration from an OF node

This makes it possible to configure ath9k based devices using devicetree. That makes some out-of-tree "convert devicetree to ath9k_platform_data glue"-code obsolete. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/a

[PATCH v2] ath9k: simplify the code-paths when not using the built-in EEPROM

tform_data. With this change all eeprom data handling is now unified in eeprom.c. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- Changes since v1: - rebased to currrent ath.git/ath-next to resolve a small merge conflict with commit "0f27ac40fb64 ath9k: retu

Re: [PATCH v4 1/3] Documentation: dt: net: add ath9k wireless device binding

On Sun, Jul 10, 2016 at 10:52 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Sunday, July 10, 2016 1:28:32 AM CEST Martin Blumenstingl wrote: >> +- qca,check-eeprom-endianness: When enabled, the driver checks if the >> + endianness of the EEP

Re: [PATCH v4 3/3] ath9k: parse the device configuration from an OF node

On Sun, Jul 10, 2016 at 2:19 AM, Bjørn Mork <bj...@mork.no> wrote: > Martin Blumenstingl <martin.blumensti...@googlemail.com> writes: > >> + if (of_property_read_bool(np, "qca,clk-25mhz")) >> + ah->is_clk_25mhz = true; >> + >>

ath9k: EEPROM format / byte swapping

Hello, I have a question regarding the ath9k EEPROM format. Most EEPROM versions have two magic bytes at the beginning, indicating the endianness of the data in this EEPROM. Let's take the AR9287 EEPROM as an example: during ath9k initialization ath9k/eeprom_9287.c:ath9k_hw_ar9287_check_eeprom

Re: [PATCH v3 2/3] ath9k: add a helper to get the string representation of ath_bus_type

On Mon, Jun 27, 2016 at 12:26 PM, Felix Fietkau <n...@nbd.name> wrote: > On 2016-06-24 14:34, Martin Blumenstingl wrote: >> Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> >> --- >> this is a new patch which didn't exist in v2 yet

[PATCH] brcmfmac: add support for BCM43455 with modalias sdio:c00v02D0dA9BF

support in the driver). Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- This is the proper patch following the (short) discussion from [0] [0] https://marc.info/?l=linux-wireless=148455981002310=2 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 + i

[PATCH v5 1/3] Documentation: dt: net: add ath9k wireless device binding

Add documentation how devicetree can be used to configure ath9k based devices. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- .../devicetree/bindings/net/wireless/qca,ath9k.txt | 47 ++ 1 file changed, 47 insertions(+) create mode

[PATCH v5 2/3] ath9k: add a helper to get the string representation of ath_bus_type

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.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath.h | 6 ++ drivers/net/wireless/ath/main.c | 7 +++ 2 files changed, 13 inse

[PATCH v5 3/3] ath9k: parse the device configuration from an OF node

This allows configuring ath9k based PCI devices using devicetree. 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.blumensti...@g

[PATCH v5 0/3] add devicetree support to ath9k

eprom-endianness" for now - this will be part of a separate patch - update documentation to fix the "compatible" string (as there is a PCI device specific format) Martin Blumenstingl (3): Documentation: dt: net: add ath9k wireless device binding ath9k: add a helper to get the s

[PATCH 4/5] ath9k: Make the EEPROM swapping check use the eepmisc register

There are two ways of swapping the EEPROM data in the ath9k driver: 1) swab16 based on the first two EEPROM "magic" bytes (same for all EEPROM formats) 2) field and EEPROM format specific swab16/swab32 (different for eeprom_def, eeprom_4k and eeprom_9287) The result of the first check was

[PATCH 5/5] ath9k: Make EEPROM endianness swapping configurable via devicetree

The endianness swapping is disabled by default since many devices have EEPROMs with incorrect endianness magic bytes (at the beginning). Devices where the EEPROM is known to indicate the correct endianness can enable the new flag to enable swapping when required. This behavior is consistent with

[PATCH 3/5] ath9k: Add an eeprom_ops callback for retrieving the eepmisc value

This allows deciding if we have to swap the EEPROM data (so it matches the system's native endianness) even if no byte-swapping (swab16, based on the first two bytes in the EEPROM) is needed. --- drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 8 +++- drivers/net/wireless/ath/ath9k/eeprom.h

[PATCH 1/5] ath9k: Add a #define for the EEPROM "eepmisc" endianness bit

This replaces a magic number with a named #define. Additionally it removes two "eeprom format" specific #defines for the "big endianness" bit which are the same on all eeprom formats. --- drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 3 ++- drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 1 -

[PATCH 2/5] ath9k: Set the "big endian" bit of the AR9003 EEPROM templates

We will default to the system's native endianness for the eepmisc value. This may be overwritten by the actual calibration data. If it is not overwritten we interpret the template data in it's native endianness, meaning that no swapping is required. ---

[PATCH 0/5] ath9k: EEPROM swapping improvements

nics.net/lists/linux-wireless/msg152634.html [1] https://marc.info/?l=linux-wireless=147178988827847=2 Martin Blumenstingl (5): ath9k: Add a #define for the EEPROM "eepmisc" endianness bit ath9k: Set the "big endian" bit of the AR9003 EEPROM templates ath9k: Add an eeprom

Re: [PATCH 2/5] ath9k: Set the "big endian" bit of the AR9003 EEPROM templates

On Mon, Aug 22, 2016 at 1:47 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote: >> We will default to the system's native endianness for the eepmisc value. >> This may be overwritten by the ac

Re: [PATCH 2/5] ath9k: Set the "big endian" bit of the AR9003 EEPROM templates

On Mon, Aug 22, 2016 at 5:31 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Monday, August 22, 2016 1:56:46 PM CEST Martin Blumenstingl wrote: >> On Mon, Aug 22, 2016 at 1:47 PM, Arnd Bergmann <a...@arndb.de> wrote: >> > On Sunday, August 21, 2016 4:49:03 PM CEST Marti

[PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding

Add documentation how devicetree can be used to configure ath9k based devices. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- .../devicetree/bindings/net/wireless/qca,ath9k.txt | 39 ++ 1 file changed, 39 insertions(+) create mode

[PATCH v6 0/3] add devicetree support to ath9k

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

[PATCH v6 2/3] ath9k: add a helper to get the string representation of ath_bus_type

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.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath.h | 6 ++ drivers/net/wireless/ath/main.c | 7 +++ 2 files changed, 13 inse

[PATCH v6 3/3] ath9k: parse the device configuration from an OF node

This allows configuring ath9k based PCI devices using devicetree. 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.blumensti...@g

Re: [PATCH 5/5] ath9k: Make EEPROM endianness swapping configurable via devicetree

On Mon, Aug 29, 2016 at 2:10 PM, Arnd Bergmann wrote: >> Without patch 4 from this series the EEPROM data is loaded like this: >> 1. out of tree code extracts the EEPROM data from NOR/SPI/NAND flash >> 2. board specific entry (usually device-tree) tells the code to apply >> swab16

Re: [PATCH 5/5] ath9k: Make EEPROM endianness swapping configurable via devicetree

On Mon, Aug 29, 2016 at 11:25 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Monday 29 August 2016, Martin Blumenstingl wrote: >> > and then do a swab32() on them. I suspect these should just be __le32 >> > (and __le16, respectively where needed), using appropriat

support for QCA9377 SDIO (ath10k or ath6kl)

Hello, is there any support for the SDIO chips QCA9377 (and QCA9378) planned? Would these be supported by ath10k or ath6kl or is a completely new driver needed? Some background: There are some device (Android TV boxes) which are using a QCA9377 wifi chip connected via SDIO. Example: Beelink GT1

Re: ath10k mesh + ap + encryption?

dge if anyone even tests that firmware branch with ath10k. >> I recommend to only use firmware releases from ath10k-firmware.git as we >> use those internally with ath10k. In any case, don't make any >> assumptions about future from that firmware branch as it's so old. Thanks for clarif

Re: support for QCA9377 SDIO (ath10k or ath6kl)

On Fri, Sep 9, 2016 at 2:35 PM, Valo, Kalle wrote: >> is there any support for the SDIO chips QCA9377 (and QCA9378) planned? >> Would these be supported by ath10k or ath6kl or is a completely new >> driver needed? > > I'm not familiar with the details of QCA9377 SDIO

Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding

On Fri, Sep 9, 2016 at 9:48 AM, Oleksij Rempel wrote: >> +Optional properties: >> +- reg: Address and length of the register set for the device. >> +- qca,clk-25mhz: Defines that a 25MHz clock is used > > Some SoCs even Atheros WiSoCs use WiFi clock for System Clock. In

device stops working ("failed to install key for vdev" error in kernel log)

Hello, sometimes my AP simply stops working. Typical situation: - (me coming home from work) - client (Nexus 5, Xperia Z3 Compact or another ath10k device) can see my ath10k AP for a brief moment - AP is gone, errors from below show up in the kernel log - reboot of my AP is required to fix this

Re: [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands

On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring <robh...@kernel.org> wrote: > On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl > <martin.blumensti...@googlemail.com> wrote: >> There are at least two drivers (ath9k and mt76) out there, where >> devicetree authors need

Re: ath10k: device stops working ("failed to install key for vdev" error in kernel log)

On Wed, Oct 5, 2016 at 8:58 PM, Ben Greear <gree...@candelatech.com> wrote: > On 10/05/2016 11:51 AM, Martin Blumenstingl wrote: >>> >>> [54064.293597] ath10k_pci :02:00.0: failed to install key for vdev >>> 0 peer [AP MAC addr]: -145 >>>

Re: [PATCH v7 1/3] Documentation: dt: net: add ath9k wireless device binding

On Sun, Oct 9, 2016 at 3:28 AM, Rob Herring <r...@kernel.org> wrote: > On Sun, Oct 02, 2016 at 11:47:41PM +0200, Martin Blumenstingl wrote: >> Add documentation how devicetree can be used to configure ath9k based >> devices. >> >> Signed-off-by: Mart

Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding

On Fri, Sep 16, 2016 at 2:45 PM, Rob Herring <r...@kernel.org> wrote: > On Fri, Sep 09, 2016 at 10:57:06PM +0200, Martin Blumenstingl wrote: >> On Fri, Sep 9, 2016 at 9:48 AM, Oleksij Rempel <li...@rempel-privat.de> >> wrote: >> >> +Optional prope

Re: [PATCH v5 1/3] Documentation: dt: net: add ath9k wireless device binding

On Mon, Aug 22, 2016 at 11:08 AM, Arnd Bergmann <a...@arndb.de> wrote: > On Sunday, August 21, 2016 4:31:03 PM CEST Martin Blumenstingl wrote: >> +pci { >> + pcie@0 { >> + reg = <0 0 0 0 0>; > > It's not clear what these two nodes re

Re: [PATCH 5/5] ath9k: Make EEPROM endianness swapping configurable via devicetree

On Mon, Aug 22, 2016 at 1:52 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Sunday, August 21, 2016 4:49:06 PM CEST Martin Blumenstingl wrote: >> +- qca,check-eeprom-endianness: When enabled, the driver checks if the >> + endianness of the EEP

[PATCH v7 3/3] ath9k: parse the device configuration from an OF node

etree to ath9k_platform_data" (for example in OpenWrt and LEDE) which becomes obsolete with this patch. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath9k/init.c | 42 +++ 1 file changed, 42 insertions(+) diff --g

[PATCH v7 1/3] Documentation: dt: net: add ath9k wireless device binding

Add documentation how devicetree can be used to configure ath9k based devices. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- .../devicetree/bindings/net/wireless/qca,ath9k.txt | 30 ++ 1 file changed, 30 insertions(+) create mode

[PATCH v7 0/3] add devicetree support to ath9k

f 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/wireles

[PATCH v7 2/3] ath9k: add a helper to get the string representation of ath_bus_type

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.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath.h | 6 ++ drivers/net/wireless/ath/main.c | 7 +++ 2 files changed, 13 inse

[PATCH v2 1/7] ath9k: Add a #define for the EEPROM "eepmisc" endianness bit

This replaces a magic number with a named #define. Additionally it removes two "eeprom format" specific #defines for the "big endianness" bit which are the same on all eeprom formats. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- driv

[PATCH v2 0/7] ath9k: EEPROM swapping improvements

b16e9edb2e9a4a7a18/sys/dev/ath/ath_hal/ah_eeprom_9287.c#L351 [4] https://marc.info/?l=linux-wireless=147544488619822=2 Martin Blumenstingl (7): ath9k: Add a #define for the EEPROM "eepmisc" endianness bit ath9k: indicate that the AR9003 EEPROM template values are little endia

[PATCH v2 7/7] ath9k: define all EEPROM fields in Little Endian format

_to_cpu. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath9k/eeprom.c | 27 ++- drivers/net/wireless/ath/ath9k/eeprom.h | 75 ++ drivers/net/wireless/ath/ath9k/eeprom_4k.c | 94 +-

[PATCH v2 2/7] ath9k: indicate that the AR9003 EEPROM template values are little endian

state that the values are little endian - there are no functional changes with this patch. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 10 +- drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 3 +++ 2

[PATCH v2 4/7] ath9k: replace eeprom_param EEP_MINOR_REV with get_eeprom_rev

get_eeprom(ah, EEP_MINOR_REV) and get_eeprom_rev(ah) are both doing the same thing: returning the EEPROM revision (12 lowest bits). Make the code consistent by using get_eeprom_rev(ah) everywhere. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wi

[PATCH v2 6/7] ath9k: Make the EEPROM swapping check use the eepmisc register

more. [0] https://github.com/freebsd/freebsd/blob/50719b56d9ce8d7d4beb53b16e9edb2e9a4a7a18/sys/dev/ath/ath_hal/ah_eeprom_9287.c#L351 Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath9k/eeprom.c | 57 - 1 fil

[PATCH v2 5/7] ath9k: consistently use get_eeprom_rev(ah)

MINOR_MASK. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath9k/eeprom.h | 4 +-- drivers/net/wireless/ath/ath9k/eeprom_4k.c | 32 ++ drivers/net/wireless/ath/ath9k/eeprom_9287.c | 19 +++-- drivers/

[PATCH v2 3/7] ath9k: Add an eeprom_ops callback for retrieving the eepmisc value

This allows deciding if we have to swap the EEPROM data (so it matches the system's native endianness) even if no byte-swapping (swab16, based on the first two bytes in the EEPROM) is needed. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wirele

[RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands

el.org/index.php/Main_Page Martin Blumenstingl (3): Documentation: dt-bindings: add IEEE 802.11 binding documentation of: add IEEE 802.11 device configuration support code ath9k: add OF configuration to disable the 2.4GHz or 5GHz band .../devicetree/bindings/net/wireless/ieee80211.tx

[RFC 3/3] ath9k: add OF configuration to disable the 2.4GHz or 5GHz band

-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt | 2 ++ drivers/net/wireless/ath/ath9k/init.c| 4 2 files changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindin

[RFC 2/3] of: add IEEE 802.11 device configuration support code

a generic implementation for IEEE 802.11 device configuration OF properties, which can be used by all drivers. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/of/Kconfig | 4 +++ drivers/of/Makefile | 1 + drivers/of/of_ieee80211.c

[RFC 1/3] Documentation: dt-bindings: add IEEE 802.11 binding documentation

This adds the documentation for the generic IEEE 802.111 binding, which currently allows enabling and disabling the 2.4GHz and 5GHz band. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- Documentation/devicetree/bindings/net/wireless/ieee80211.txt | 12 +

Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements

On Fri, Nov 25, 2016 at 4:06 PM, Valo, Kalle <kv...@qca.qualcomm.com> wrote: > Kalle Valo <kv...@codeaurora.org> writes: > >> Martin Blumenstingl <martin.blumensti...@googlemail.com> writes: >> >>> There are two types of swapping the EEPROM data in the

[PATCH v8 2/3] ath9k: add a helper to get the string representation of ath_bus_type

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.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath.h | 6 ++ drivers/net/wireless/ath/main.c | 7 +++ 2 files changed, 13 inse

[PATCH v8 0/3] add devicetree support to ath9k

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

[PATCH v8 1/3] Documentation: dt: net: add ath9k wireless device binding

Add documentation how devicetree can be used to configure ath9k based devices. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- .../devicetree/bindings/net/wireless/qca,ath9k.txt | 48 ++ 1 file changed, 48 insertions(+) create mode

Re: [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands

On Wed, Oct 5, 2016 at 10:31 PM, Rob Herring <robh...@kernel.org> wrote: > On Wed, Oct 5, 2016 at 1:36 PM, Felix Fietkau <n...@nbd.name> wrote: >> On 2016-10-05 20:25, Martin Blumenstingl wrote: >>> On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring <robh...@kernel.org

[PATCH v8 3/3] ath9k: parse the device configuration from an OF node

etree to ath9k_platform_data" (for example in OpenWrt and LEDE) which becomes obsolete with this patch. Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/net/wireless/ath/ath9k/init.c | 42 +++ 1 file changed, 42 insertions(+) diff --g

Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements

Hi Adrian, On Wed, Dec 14, 2016 at 7:45 AM, Adrian Chadd <adr...@freebsd.org> wrote: > hi, > > On 12 December 2016 at 12:05, Martin Blumenstingl > <martin.blumensti...@googlemail.com> wrote: > >> >> It seems that there are a few devices out there where

Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements

Hello Kalle, On Fri, Nov 25, 2016 at 4:06 PM, Valo, Kalle <kv...@qca.qualcomm.com> wrote: > Kalle Valo <kv...@codeaurora.org> writes: > >> Martin Blumenstingl <martin.blumensti...@googlemail.com> writes: >> >>> There are two types of swapping th

Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding

On Wed, Dec 28, 2016 at 11:08 AM, Rafał Miłecki wrote: > On 3 October 2016 at 15:29, Kalle Valo wrote: >> Arnd Bergmann writes: >> >>> On Friday 30 September 2016, Felix Fietkau wrote: >> >> >> + device_type = "pci";

Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties

On Wed, Dec 28, 2016 at 9:32 PM, Rafał Miłecki wrote: > On 28 December 2016 at 21:05, Arend van Spriel > wrote: >> On 28-12-16 16:59, Rafał Miłecki wrote: >>> From: Rafał Miłecki >>> >>> This new file should be used for

support for Ampak AP6255 (bcm43455c0 with SDIO device ID 0xa9bf)

Hello, I recently got a "Khadas VIM Pro" (see [0] for more information) The "Pro" version comes with an AP6255 wifi chipset. Looking at the vendor firmware this seems to be a bcm43455 device: [1] To my surprise brcmfmac from a mainline 4.10-rc3 kernel did not pick this device up. So I started

  1   2   >