On Sat, Jun 29, 2019 at 10:44 AM Christian Lamparter wrote:
[...]
> That said: I have no problem relicensing my code under the ISC, if it
> helps with the upstreaming process. I've added Chris, Martin and
> Mathias as they both were consultants, as well as the previous
> authors of three targets t
]https://github.com/openwrt/openwrt/pull/1645#issuecomment-448027058
> [2]https://github.com/openwrt/openwrt/pull/1613
> [3]https://patchwork.kernel.org/patch/10241731/
+Cc Bas Vermeulen: can you please try Daniel's patch on your PowerMac
G5? I hope that this replaces your "endian
Hi Arend,
On Mon, Jun 18, 2018 at 9:23 PM Arend van Spriel
wrote:
>
> + Martin
thank you for CC'ing me!
> On 6/18/2018 3:53 PM, mgre...@cinci.rr.com wrote:
> >
> > Tom Psyborg wrote:
> >> Hi
> >>
> >> Your log only show attemps on ch 2447, Can you try connecting to 5GHz
> >> AP? Connect to
Hello Bas,
On Tue, Apr 10, 2018 at 11:05 AM, Bas Vermeulen wrote:
> On 14-03-18 15:34, Kalle Valo wrote:
>>
>> Bas Vermeulen writes:
>>
>>> --- a/drivers/net/wireless/ath/ath9k/init.c
>>> +++ b/drivers/net/wireless/ath/ath9k/init.c
>>> @@ -67,6 +67,9 @@ static int ath9k_ps_enable;
>>
Hi Rafal,
On Tue, Mar 20, 2018 at 10:07 PM, Rafał Miłecki wrote:
> On 19 March 2018 at 09:11, Martin Blumenstingl
> wrote:
>> - some ship with a broken EEPROM that enables the 5GHz band on a
>> 2.4GHz-only card, which is why we need "qca,disable-5ghz"
>
> No. Y
fault if
>>> you prefer, as that would fix my problem as well. I am just not sure
>>> that doesn't break things for some platform/device I don't have.
>>
>>
>> I'm not really sure what to do. Basically this is a choise between bad
>> for user ex
Hello Jeremy, Hello Hans,
On Tue, Feb 20, 2018 at 5:15 PM, Hans de Goede wrote:
> Hi,
>
> On 02/20/2018 03:36 PM, Carlo Caione wrote:
>>
>> On Tue, Feb 20, 2018 at 2:01 PM, Hans de Goede
>> wrote:
>>>
>>> Hi Carlo,
>>
>>
>> Hi Hans,
>>
>>> Is this for devices with a RTL8723BS chip? If so then th
Hi Arend,
On Tue, May 16, 2017 at 12:05 AM, Arend Van Spriel
wrote:
> On 15-5-2017 22:13, Martin Blumenstingl wrote:
>> The example in the BCM43xx documentation uses "brcmf" as node name.
>> However, wireless devices should be named "wifi" instead. Fix this
case a .dts author copied from another .dts which still uses
the "wrong" node name).
Martin Blumenstingl (1):
dt-binding: net: wireless: fix node name in the BCM43xx example
Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.13.0
djust only the board specific bits).
Signed-off-by: Martin Blumenstingl
---
Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
b/Documentation/dev
support in the driver).
Signed-off-by: Martin Blumenstingl
---
This is the proper patch following the (short) discussion from [0]
[0] https://marc.info/?l=linux-wireless&m=148455981002310&w=2
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
include/linux/mmc/sd
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 inv
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 properties handled at higher level and
>>> so usable with all drivers.
>>>
>
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";
>> >> >> + mediatek,mtd-eeprom = <&fa
Hi Adrian,
On Wed, Dec 14, 2016 at 7:45 AM, Adrian Chadd wrote:
> hi,
>
> On 12 December 2016 at 12:05, Martin Blumenstingl
> wrote:
>
>>
>> It seems that there are a few devices out there where the whole EEPROM
>> is swab16'ed which switches the position
Hello Kalle,
On Fri, Nov 25, 2016 at 4:06 PM, Valo, Kalle wrote:
> Kalle Valo writes:
>
>> Martin Blumenstingl writes:
>>
>>> There are two types of swapping the EEPROM data in the ath9k driver.
>>> Before this series one type of swapping could not be use
On Fri, Nov 25, 2016 at 4:06 PM, Valo, Kalle wrote:
> Kalle Valo writes:
>
>> Martin Blumenstingl writes:
>>
>>> 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
On Wed, Oct 5, 2016 at 10:31 PM, Rob Herring wrote:
> On Wed, Oct 5, 2016 at 1:36 PM, Felix Fietkau wrote:
>> On 2016-10-05 20:25, Martin Blumenstingl wrote:
>>> On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring wrote:
>>>> On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumens
ee to
ath9k_platform_data" (for example in OpenWrt and LEDE) which becomes
obsolete with this patch.
Signed-off-by: Martin Blumenstingl
---
drivers/net/wireless/ath/ath9k/init.c | 42 +++
1 file changed, 42 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/d
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
---
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
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 bi
Add documentation how devicetree can be used to configure ath9k based
devices.
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net
On Sun, Oct 9, 2016 at 3:28 AM, Rob Herring 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: Martin Blumenstingl
>> ---
>>
On Wed, Oct 5, 2016 at 8:58 PM, Ben Greear 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
>>> [54064.301234] wlan0: failed to
> [54064.293597] ath10k_pci :02:00.0: failed to install key for vdev
> 0 peer [AP MAC addr]: -145
> [54064.301234] wlan0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from
> hardware (-145)
> [54067.305703] ath10k_pci :02:00.0: failed to install key for vdev
> 0 peer [AP MAC addr]: -145
> [5
On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring wrote:
> On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl
> wrote:
>> There are at least two drivers (ath9k and mt76) out there, where
>> devicetree authors need to override the enabled bands.
>>
>> For ath9k there is
generic implementation for IEEE 802.11 device
configuration OF properties, which can be used by all drivers.
Signed-off-by: Martin Blumenstingl
---
drivers/of/Kconfig | 4 +++
drivers/of/Makefile | 1 +
drivers/of/of_ieee80211.c| 83
173804817&w=2
[2] https://backports.wiki.kernel.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
igned-off-by: Martin Blumenstingl
---
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/bindings/net/wireless/qca,ath9k.txt
b/Document
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
---
Documentation/devicetree/bindings/net/wireless/ieee80211.txt | 12
1 file changed, 12 insertions
6,32}_to_cpu.
Signed-off-by: Martin Blumenstingl
---
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 +-
drivers/net/wireless/ath/
/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 t
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
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
state that the values
are little endian - there are no functional changes with this patch.
Signed-off-by: Martin Blumenstingl
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 3 +++
2 files changed, 8 insertions(+), 5 deletions
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
---
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2
more.
[0]
https://github.com/freebsd/freebsd/blob/50719b56d9ce8d7d4beb53b16e9edb2e9a4a7a18/sys/dev/ath/ath_hal/ah_eeprom_9287.c#L351
Signed-off-by: Martin Blumenstingl
---
drivers/net/wireless/ath/ath9k/eeprom.c | 57 -
1 file changed, 41 insertions(+), 16 deletions(-)
di
MINOR_MASK.
Signed-off-by: Martin Blumenstingl
---
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/net/wireless/ath/ath9k/eeprom_d
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
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.
Add documentation how devicetree can be used to configure ath9k based
devices.
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 30 ++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net
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
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
---
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
ee to
ath9k_platform_data" (for example in OpenWrt and LEDE) which becomes
obsolete with this patch.
Signed-off-by: Martin Blumenstingl
---
drivers/net/wireless/ath/ath9k/init.c | 42 +++
1 file changed, 42 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/d
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
[
On Fri, Sep 16, 2016 at 2:45 PM, Rob Herring 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
>> wrote:
>> >> +Optional properties:
>> >> +- reg: Address and length of the re
ch 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 clarifying this.
> Thi
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 this
> case we need to use
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 firmware but I assume
> ath10k
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 (
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
---
drivers/net/wireless/ath/at
Add documentation how devicetree can be used to configure ath9k based
devices.
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net
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
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
---
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
On Mon, Aug 29, 2016 at 11:25 PM, Arnd Bergmann 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 appropriate accessors
>> > ev
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 to the data
>> 3
On Mon, Aug 22, 2016 at 1:52 PM, Arnd Bergmann 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 EEPROM (u
On Mon, Aug 22, 2016 at 11:08 AM, Arnd Bergmann 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 refer to in the example
On Mon, Aug 22, 2016 at 5:31 PM, Arnd Bergmann 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 wrote:
>> > On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote:
>> >> W
On Mon, Aug 22, 2016 at 1:47 PM, Arnd Bergmann 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 actual calibration data. If it is n
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 -
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 us
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 at
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
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.
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom
w.spinics.net/lists/linux-wireless/msg152634.html
[1] https://marc.info/?l=linux-wireless&m=147178988827847&w=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:
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
---
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
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
---
drivers/net/wireless/ath/at
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
Add documentation how devicetree can be used to configure ath9k based
devices.
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net
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
>> words: no swap is be
On Sun, Jul 10, 2016 at 2:19 AM, Bjørn Mork wrote:
> Martin Blumenstingl writes:
>
>> + if (of_property_read_bool(np, "qca,clk-25mhz"))
>> + ah->is_clk_25mhz = true;
>> +
>> + if (of_property_read_bool(np, "qca,disable-
On Sun, Jul 10, 2016 at 10:52 PM, Arnd Bergmann 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 EEPROM (b
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
---
drivers/net/wireless/ath/ath9k/init.c | 55 +
r pointed
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: p
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
---
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
Add documentation how devicetree can be used to configure ath9k based
devices.
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 59 ++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net
tform_data.
With this change all eeprom data handling is now unified in eeprom.c.
Signed-off-by: Martin Blumenstingl
---
Changes since v1:
- rebased to currrent ath.git/ath-next to resolve a small merge
conflict with commit
"0f27ac40fb64 ath9k: return false when reading wrong eeprom of
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 is
On Mon, Jun 27, 2016 at 12:26 PM, Felix Fietkau wrote:
> On 2016-06-24 14:34, Martin Blumenstingl wrote:
>> Signed-off-by: Martin Blumenstingl
>> ---
>> this is a new patch which didn't exist in v2 yet, it prepares the new
>> function ath_bus_type_to_strin
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 out the relevant FW na
On Sat, Jun 25, 2016 at 9:26 PM, Christian Lamparter
wrote:
> The problem with the owl-loader is/was that it sticks around
> when it has initialized all the cards. Unloading a module by
> itself is tough. One way out would be to add it to ath9k's pci.c.
> The question is: will such a feature have
On Sat, Jun 25, 2016 at 2:01 PM, Christian Lamparter
wrote:
> On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote:
>> This makes it possible to configure ath9k based devices using
>> devicetree. That makes some out-of-tree "convert devicetree to
>> ath9
Signed-off-by: Martin Blumenstingl
---
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.c | 15 +++
2 files change
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
---
changes in v2 -> v3:
- replaced qca,eeprom-name with a boolean "qca,no-ee
Add documentation how devicetree can be used to configure ath9k based
devices.
Signed-off-by: Martin Blumenstingl
---
changes in v2 -> v3:
- improved wording of the qca,disable-2ghz and qca,disable-5ghz properties
- replaced qca,eeprom-name with qca,no-eeprom (the eeprom name is now
bu
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:
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 AHB
support is not scope of my
On Thu, Jun 23, 2016 at 7:58 PM, Mark Rutland 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: Martin Blumenstingl
>> ---
>&g
Add documentation how devicetree can be used to configure ath9k based
devices.
Signed-off-by: Martin Blumenstingl
---
changes in v1 -> v2:
- use vendor prefix "qca" instead of "ath"
- extend the example so it includes the "compatible" property
.../devicetree/bi
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
---
changes in v1 -> v2:
- use vendor prefix "qca"
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:
Add documentation how devicetree can be used to configure ath9k based
devices.
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/net/wireless/ath,ath9k.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net
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
---
drivers/net/wireless/ath/ath9k/init.c | 70 +
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:
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
Signed-off-by: Martin Blumenstingl
---
drivers/net/wireless/ath/ath9k/init.c | 3
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 code
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
---
drivers/net/wireless/ath/ath9k/init.c | 49 ++-
1 file changed, 25
tform_data.
With this change all eeprom data handling is now unified in eeprom.c.
Signed-off-by: Martin Blumenstingl
---
This supersedes the following patch by Eduardo Abinader
:
"ath9k: return false when reading wrong eeprom offset"
https://patchwork.kernel.org/patch/9181371/
drivers/ne
ath9k_hw_init_macaddr unconditionally returns 0 in all cases, making the
return value unnecessary.
Signed-off-by: Martin Blumenstingl
---
drivers/net/wireless/ath/ath9k/hw.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
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
No functional changes - this only removes a variable which is set but
never read.
Signed-off-by: Martin Blumenstingl
---
drivers/net/wireless/ath/ath9k/hw.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index
1 - 100 of 115 matches
Mail list logo
