[ath9k-devel] ath9k ARMv7 OOPS in v4.8.6, v4.2.8

All, I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox board (Marvell Armada 370 SoC). Every day or so I get a consistent crash that brings down the whole board. I've attached three oops I captured on the serial port. I looked at the commits from v4.8.6 to v4.9-rc6, and

Re: [ath9k-devel] [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

The entropy was evaluated by crypto expert, the analysis report show the ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits value, we conservatively assume the min-entropy is 10 bits out of 32 bits, so that's why set entropy quality to 320/1024 = 10/32. Also we have

[ath9k-devel] [Bug][AR9285] WiFi LED stops working after suspend/hibernate cycle with 4.7.0 kernel

Hello. After kernel upgrade from 4.6.4 to 4.7.0 WiFi LED stops working after suspend/hibernate cycle. LED works properly right after (re)boot. LED worked properly after suspend/hibernate cycle with 4.6.4, thus it's a regression. My hardware is "Qualcomm Atheros AR9285 Wireless Network Adapter

Re: [ath9k-devel] ath9k ARMv7 OOPS in v4.8.6, v4.2.8

On Thu, Nov 24, 2016 at 02:06:57PM +0800, miaoq...@codeaurora.org wrote: > > >>Okay, so i was 0, so running UP probably isn't going to help. r7 is > >>also spec_priv->rfs_chan_spec_scan. > >> > >>So, I think the question is... how is this NULL - and has it always > >>been NULL... > > > >The

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

On Mon, Jun 27, 2016 at 01:38:43AM +0200, Martin Blumenstingl wrote: > On Sat, Jun 25, 2016 at 9:26 PM, Christian Lamparter > wrote: > > I've added lede-dev and Luis since this is relevant for them. > > Maybe between the sysloadfw.sh and owl-loader, there's another > >

Re: [ath9k-devel] ath9k ARMv7 OOPS in v4.8.6, v4.2.8

All, On Wed, Nov 23, 2016 at 09:40:53PM +, Jason Cooper wrote: > I'm running with ATH9K_DEBUGFS=y now. If it goes a couple of days > without crashing, I'll gin up a patch. Well, it survived overnight, which it's never done before. :-) I'm testing the relay_open() NULL patch now. thx,

Re: [ath9k-devel] [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Jason, Stephan, Agree with Jason's point, also understand Stephan's concern. The date rate can be roughly estimated by 'cat /dev/random |rngtest -c 1000', the average speed is .294Kibits/s. I will sent the patch to disable ath9k RNG by default. Thanks, Miaoqing -Original

[ath9k-devel] [PATCH 3.19.y-ckt 19/99] ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.

3.19.8-ckt23 -stable review patch. If anyone has any objections, please let me know. ---8< From: "Vittorio Gambaletta (VittGam)" commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream. The Wistron

Re: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption

all patches have a unclear license since most patches are not comming with any licence declaration ;-) Am 27.10.2016 um 08:02 schrieb Kalle Valo: > Antonio Quartulli writes: > >> On Wed, Oct 26, 2016 at 05:05:14PM +0300, Kalle Valo wrote: >>> Antonio Quartulli

[ath9k-devel] regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

Hello, while testing kernel 4.9 I run into a weird issue with the ath9k driver. I can boot the box in console mode and it stay up sometime but is not usable. from dmesg : === [ INFO: suspicious RCU usage. ] 4.9-fw1 #1 Tainted: G I

Re: [ath9k-devel] regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

On 18.12.2016 21:14, Paul E. McKenney wrote: > On Sun, Dec 18, 2016 at 07:57:42PM +, Valo, Kalle wrote: >> Tobias Klausmann writes: >> >>> A patch for this is already floating on the ML for a while now latest: >>> (ath9k: do not return early to fix rcu

Re: [ath9k-devel] [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.

Kalle Valo writes: > Toke Høiland-Jørgensen writes: > >> Kalle Valo writes: >> >>> Toke Høiland-Jørgensen writes: >>> >>> I understand your point, but I don't want to rush this to 4.9 and then >>> start getting lots of

Re: [ath9k-devel] [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.

Kalle Valo writes: > Toke Høiland-Jørgensen writes: > > This is great work but due to the regressions I'm not sure if this > will be ready for 4.9. To get more testing time I wonder if we should > wait for 4.10? IMHO applying this in the end of

Re: [ath9k-devel] [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.

Kalle Valo writes: > Toke Høiland-Jørgensen writes: > >> This switches ath9k over to using the mac80211 intermediate software >> queueing mechanism for data packets. It removes the queueing inside the >> driver, except for the retry queue, and instead pulls

[ath9k-devel] 802.11s Power Save

Dear Experts, I hope all of you are doing good. My name is Umar Ali Malik and I am a PhD student in Germany. I am doing my research on 802.11s and would like to have your input regarding some queries. Please help me to find the solution. 1) I am trying to build a small setup which

Re: [ath9k-devel] [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.

Kalle Valo writes: > Toke Høiland-Jørgensen writes: > >> Kalle Valo writes: >> >>> Toke Høiland-Jørgensen writes: >>> This switches ath9k over to using the mac80211 intermediate software queueing mechanism for

Re: [ath9k-devel] [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.

Kalle Valo writes: > Toke Høiland-Jørgensen writes: > >> Kalle Valo writes: >> >>> Toke Høiland-Jørgensen writes: >>> Kalle Valo writes: > Toke Høiland-Jørgensen writes:

[ath9k-devel] ath9k_htc: continuously output spectral samples

Hi, We are trying to continuously output spectral samples with no gaps. People are talking about configuring ani levels to make the chip(ar9271) deaf to wireless frames and report all frames as spectral samples to make them continuous. Can you please give us some suggestions on what to do?

Re: [ath9k-devel] ath9k ARMv7 OOPS in v4.8.6, v4.2.8

On Wed, Nov 23, 2016 at 07:51:20PM +, Russell King - ARM Linux wrote: > On Wed, Nov 23, 2016 at 07:15:39PM +, Jason Cooper wrote: > > --- oops from v4.8.6 #2 -- > > [42059.303625] Unable to handle kernel NULL pointer dereference at virtual > >

Re: [ath9k-devel] ath9k ARMv7 OOPS in v4.8.6, v4.2.8

Hi Russell, On Wed, Nov 23, 2016 at 07:51:20PM +, Russell King - ARM Linux wrote: > On Wed, Nov 23, 2016 at 07:15:39PM +, Jason Cooper wrote: > > --- oops from v4.8.6 #2 -- > > [42059.303625] Unable to handle kernel NULL pointer dereference at

Re: [ath9k-devel] ATH9K warnings from commit b2d70d494

It's an AR9462 Here's the wifi adapter: 03:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01) Subsystem: Lite-On Communications Inc Device 6621 Flags: bus master, fast devsel, latency 0, IRQ 19 Memory at f7c0 (64-bit, non-prefetchable) [size=512K] Expansion

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

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 > --- > changes in v1 -> v2: > - use vendor prefix "qca" instead of

Re: [ath9k-devel] ath9k ARMv7 OOPS in v4.8.6, v4.2.8

On Wed, Nov 23, 2016 at 09:17:45PM +, Russell King - ARM Linux wrote: > On Wed, Nov 23, 2016 at 08:59:17PM +, Jason Cooper wrote: > > As requested on irc: > > Thanks. > > > 7f0: ea02b 800 > > 7f4: e7970102ldr r0, [r7,

Re: [ath9k-devel] ath9k ARMv7 OOPS in v4.8.6, v4.2.8

Hi Kalle, On Wed, Nov 23, 2016 at 09:26:42PM +0200, Kalle Valo wrote: > Jason Cooper writes: > > I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox > > board (Marvell Armada 370 SoC). Every day or so I get a consistent > > crash that brings down the

[ath9k-devel] ATH9K warnings from commit b2d70d494

I'm getting many warning stack traces fom the above--at least two every 5 seconds whether or not connected via wireless. Samples are below. On further investigation I see that for each of the pair gpio = 11, for the first ah->caps.num_gpio_pins = 10 and for the second BIT(gpio) = 0x800 and

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

On Thu, Jun 23, 2016 at 08:14:29PM +0200, Martin Blumenstingl wrote: > 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: > >> +- qca,eeprom-name: The name of the file which contains the EEPROM data

[ath9k-devel] [3.19.y-ckt stable] Patch "ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards." has been added to the 3.19.y-ckt tree

This is a note to let you know that I have just added a patch titled ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards. to the linux-3.19.y-queue branch of the 3.19.y-ckt extended stable tree which can be found at:

[ath9k-devel] [3.19.y-ckt stable] Patch "ath9k: Add a module parameter to invert LED polarity." has been added to the 3.19.y-ckt tree

This is a note to let you know that I have just added a patch titled ath9k: Add a module parameter to invert LED polarity. to the linux-3.19.y-queue branch of the 3.19.y-ckt extended stable tree which can be found at:

Re: [ath9k-devel] [PATCH v3] ath9k: Switch to using mac80211 intermediate software queues.

> The old code path in ath_tx_start that would queue packets has been > removed completely, It seems to me that this breaks the ath9k driver when non-data packets which mac80211 will not queue on the new intermediate queues, see ieee80211_drv_tx( ) in mac80211/tx.c where it says if

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

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 register set for the device. > >> +- qca,clk-25mhz: Defines that a 25MHz clock is

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

Oh cool.. I will try to understand this patch thoroughly in the next couple of days. My patch (both v1 and v2) have one or two bugs (depending on exactly how you count bugs and/or my confusion) (that I know of). At first glance my first bug appears to remain in your reworked patch: > >

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

> I think we should finish intermediate queues support first and then look > into the rename later. Hmm... if the renaming is going to go in mainline, I feel pretty strongly it should go in *before* a patch to switch over to use the intermediate queues. The whole point of the renaming was to

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

> > You're right that it doesn't check the max. However, this is less of a > problem now that there is no intermediate queueing in the driver; and > indeed the utility of haven the qlen_* tunables is somewhat questionable > with the patch applied: The only thing this is going to control is the

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

Toke, I've been tesing your ath9k patch (using it instead of my earlier ath9k patch) and plan to continue testing it. Thanks for unconfusing me a couple weeks ago, and cluing me into how the limit on ->pending_frames is not really relevant for the data packets that go through the new

[ath9k-devel] linux-4.8-rcX: ath9k traceback

Hi, There weren't any problems on linux-4.7 kernels. I'm getting the following traceback on linux-4.8-rc1/-rc4 kernels. Let me know if you need any additional information. [ 64.006529] WARNING: CPU: 3 PID: 94 at drivers/net/wireless/ath/ath9k/beacon.c:642 ath9k_beacon_config+0x12c/0x140

Re: [ath9k-devel] linux-4.8-rcX: ath9k traceback

On Thu, 2016-09-01 at 19:15 +0300, Kalle Valo wrote: > Mimi Zohar writes: > > > There weren't any problems on linux-4.7 kernels. I'm getting the > > following traceback on linux-4.8-rc1/-rc4 kernels. Let me know if you > > need any additional information. > > > > [

[ath9k-devel] [PATCH] tree-wide: replace config_enabled() with IS_ENABLED()

The use of config_enabled() against config options is ambiguous. In practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the author might have used it for the meaning of IS_ENABLED(). Using IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc. makes the intention clearer. This commit

Re: [ath9k-devel] [Make-wifi-fast] Diagram of the ath9k TX path

On Fri, May 13, 2016 at 11:57 AM, Dave Taht wrote: > On Fri, May 13, 2016 at 11:05 AM, Bob McMahon > wrote: > >> don't have the data available for multiple flows at the moment. >> > > The world is full of folk trying to make single tcp flows go at

[ath9k-devel] Might the the macVersion be wrongly assigned sometimes ?

Thank you for ath9k. Sorry if this is silly, but I had some problems with 9271 and looked at the code, but then I saw a suspicious line. I don't really understand the code or whether this is a big problem or just dead code or maybe it is ok after all, just thought I'd better tell in case someone

Re: [ath9k-devel] [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

Hey Ted, On Wed, Aug 10, 2016 at 07:44:25PM -0400, Theodore Ts'o wrote: > On Tue, Aug 09, 2016 at 02:04:44PM +, Jason Cooper wrote: > > iiuc, Ted, you're saying using the hw_random framework would be > > disasterous because despite most drivers having a default quality of 0, > > rngd assumes

Re: [ath9k-devel] [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Stephan, Miaoqing Pan, On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote: > Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing: > > The entropy was evaluated by crypto expert, the analysis report show the > > ADC with at least 10bits and up to 22 bits of min-entropy

Re: [ath9k-devel] [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Stephan, On Sat, Aug 06, 2016 at 10:03:58PM +0200, Stephan Mueller wrote: > Am Samstag, 6. August 2016, 19:45:51 CEST schrieb Jason Cooper: > > On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote: ... > > > diff --git a/drivers/net/wireless/ath/ath9k/rng.c > > >

Re: [ath9k-devel] [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Ted, On Tue, Aug 09, 2016 at 07:56:22AM -0400, Theodore Ts'o wrote: > On Tue, Aug 09, 2016 at 06:30:03AM +, Pan, Miaoqing wrote: > > Agree with Jason's point, also understand Stephan's concern. The > > date rate can be roughly estimated by 'cat /dev/random |rngtest -c > > 1000', the

Re: [ath9k-devel] [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Stephan, On Mon, Aug 08, 2016 at 05:29:30PM +, Jason Cooper wrote: > On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote: ... > > If you think that this patch is a challenge because your driver starts to > > spin, please help and offer another solution. > > Well, I don't buy

Re: [ath9k-devel] [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Stephan, On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote: > Hi Ted, Herbert, > > I sent a question to the ATH9K RNG some time ago to the developers. > See https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg19115.html > > I have not yet received a word and I think

Re: [ath9k-devel] ath9k gpio request

On Wednesday 01 June 2016 12:24 PM, Pan, Miaoqing wrote: > which chip ? And what's the GPIO number ? lspci -v reports: 09:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01) Subsystem: Foxconn International, Inc. Device e052 Flags: bus master, fast

Re: [ath9k-devel] [v2] RANDOM: ATH9K RNG delivers zero bits of entropy

Am Dienstag, 27. September 2016, 16:44:16 CEST schrieb Kalle Valo: Hi Kalle, > Stephan Mueller wrote: > > The ATH9K driver implements an RNG which is completely bypassing the > > standard Linux HW generator logic. > > > > The RNG may or may not deliver entropy. Considering

[ath9k-devel] [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

The ATH9K driver implements an RNG which is completely bypassing the standard Linux HW generator logic. The RNG may or may not deliver entropy. Considering the conservative approach in treating entropy with respect to non-auditable sources, this patch changes the delivered entropy value to zero.

[ath9k-devel] [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Ted, Herbert, I sent a question to the ATH9K RNG some time ago to the developers. See https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg19115.html I have not yet received a word and I think this issue should be resolved. Thanks Stephan ---8<--- The ATH9K driver implements an RNG

Re: [ath9k-devel] linux-next: Tree for May 30

On Monday 30 May 2016 08:52 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20160527: Hi All, I have just built and booted with next-20160530 and my dmesg is full of warnings from ath9k. Last kernel tested was v4.6 and there was no problem with that. The traces are like: Call Trace:

Re: [ath9k-devel] ath9k gpio request

On Thursday 02 June 2016 01:32 PM, Pan, Miaoqing wrote: > Seems there are something wrong in the datasheet, try > > --- a/drivers/net/wireless/ath/ath9k/reg.h > +++ b/drivers/net/wireless/ath/ath9k/reg.h > @@ -1122,8 +1122,8 @@ enum { > #define AR9300_NUM_GPIO 16 >

[ath9k-devel] [RFC/RFT 4/5] ath9k: Add a per-station airtime deficit scheduler

This modifies the logic in ath_txq_schedule to account airtime consumed by each station and uses a deficit-based scheduler derived from FQ-CoDel to try to enforce airtime fairness. The deficit is decreased on TX completion and the scheduler simply makes scheduling decisions based on this.

[ath9k-devel] [RFC/RFT 1/5] mac80211: skip netdev queue control with software queuing

From: Michal Kazior Qdiscs are designed with no regard to 802.11 aggregation requirements and hand out packet-by-packet with no guarantee they are destined to the same tid. This does more bad than good no matter how fairly a given qdisc may behave on an ethernet

[ath9k-devel] [RFC/RFT 2/5] ath9k: use mac80211 intermediate software queues

This patch leaves the code for ath9k's internal per-node per-tid queues in place and just modifies the driver to also pull from the new mac80211 intermediate software queues, and implements the .wake_tx_queue method, which will cause mac80211 to deliver packets to be sent via the new intermediate

Re: [ath9k-devel] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

Adrian Chadd writes: > I've been working on something similar in freebsd, so cool to see this > happening here! Cool. Do you have code available somewhere? > The only thing missing atm is STBC and LDPC. My RX airtime code looks > basically like this one too; but I have TODO

Re: [ath9k-devel] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

Toke Høiland-Jørgensen writes: >> [snip] >> >> I also found one of my notes in my version of this - how can we >> estimate the duration of an A-MPDU, when we only get hardware >> de-encapsulated frames? > > Well in my case I'm sidestepping this by getting the TX duration from > a

Re: [ath9k-devel] [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

Michal Kazior writes: > On 10 June 2016 at 11:08, Toke Høiland-Jørgensen wrote: >> Michal Kazior writes: >> >>> For A-MPDU all MPDU rx status (except last one) should share the same >>> timestamp. Last one has a different one so

Re: [ath9k-devel] [RFC/RFT 1/5] mac80211: skip netdev queue control with software queuing

Julian Calaby writes: > As this patch is passing through your hands, you need to add your > Signed-off-by too. Ah, right, sorry; didn't know that. Will add it the next time around. Thanks for the pointer! :) -Toke ___

Re: [ath9k-devel] [Make-wifi-fast] [RFC/RFT 0/5] Adding an airtime fairness scheduler to ath9k

Luca Muscariello writes: > I don't fully understand your plots but it would be useful to report > the physical rate of the stations. Yes, well, there's not really one rate to report for each station, since Minstrel jumps about a bit and tries different ones. > As a

Re: [ath9k-devel] [RFC/RFT 2/5] ath9k: use mac80211 intermediate software queues

Tim Shepard writes: > OK, makes sense. But you left it called txq in mac80211. So someone > reading the mac80211 code and ath9k at the same time (to understand > the whole stack) winds up with txq meaning different things, including > in places in ath9k where it has to

Re: [ath9k-devel] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

Adrian Chadd writes: > [snip] > > I also found one of my notes in my version of this - how can we > estimate the duration of an A-MPDU, when we only get hardware > de-encapsulated frames? Well in my case I'm sidestepping this by getting the TX duration from a register in the

Re: [ath9k-devel] [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

>> I initially thought that using the timestamp put into the frame by the >> hardware could be a way to get timing. But there's only a timestamp of >> the first symbol in rs_tstamp, and getting a time to compare it with is >> difficult; by the time the frame is handled in the rx tasklet, way too

[ath9k-devel] [PATCH] ath9k: allow tx99 for ar9002 based cards

As there is current support for ar9002 tx99 mode, just allow to init debugfs and enable tx99. Signed-off-by: Eduardo Abinader --- drivers/net/wireless/ath/ath9k/tx99.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[ath9k-devel] [PATCH] ath9k: Remove empty test condition

Just some code cleanup to remove an empty if clause. Signed-off-by: Eduardo Abinader --- drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c

Re: [ath9k-devel] ath9k-htc on OHCI -> bogus usb xfer

On 06.07.2016 10:32, Alexey Brodkin wrote: > Hi Oleksij, > > On Wed, 2016-07-06 at 10:24 +0200, fixed-term.Oleksij.Rempel wrote: >> >> Hm... this Endpoint should be Interrupt, not Bulk. If you search for >> lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt. >> >> what

[ath9k-devel] [PATCH] ath9k: Remove empty test condition

Just some code cleanup to remove an empty if clause. Signed-off-by: Eduardo Abinader --- drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c

Re: [ath9k-devel] ath9k-htc on OHCI -> bogus usb xfer

On 06.07.2016 09:44, Alexey Brodkin wrote: > Hi Oleksij, > > On Tue, 2016-07-05 at 21:01 +0200, Oleksij Rempel wrote: >> Am 05.07.2016 um 19:31 schrieb Alexey Brodkin: >>> >>> Hi Oleksij, >>> >>> On Tue, 2016-07-05 at 19:23 +0200, Oleksij Rempel wrote: Hi, Am 05.07.2016 um

Re: [ath9k-devel] ath9k-htc on OHCI -> bogus usb xfer

On 06.07.2016 11:30, Alexey Brodkin wrote: > Hi Oleksij, > > On Wed, 2016-07-06 at 11:09 +0200, fixed-term.Oleksij.Rempel wrote: >> >> On 06.07.2016 10:45, Alexey Brodkin wrote: >>> >>> Hi Oleksij, >>> >>> On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote: On

[ath9k-devel] [PATCH] ath9k: allow tx99 for ar9002 based cards

As there is current support for ar9002 tx99 mode, just allow to init debugfs and enable tx99. Signed-off-by: Eduardo Abinader --- drivers/net/wireless/ath/ath9k/tx99.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[ath9k-devel] [PATCH] ath9k: bring back direction setting in ath9k_{start_stop}

A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup led_pin initial") that broken the WLAN status led on my laptop with AR9287 after suspending and resuming. Steps to reproduce: * Suspend (laptop) * Resume (laptop) * Observe that the WLAN led no longer turns ON/OFF depending on

Re: [ath9k-devel] [PATCH] ath9k: bring back direction setting in ath9k_{start_stop}

Some more users complaining about this: https://bbs.archlinux.org/viewtopic.php?id=215978 On Thu, Sep 01, 2016 at 08:47:02PM +0300, Giedrius Statkevičius wrote: > A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup > led_pin initial") that broken the WLAN status led on my laptop

Re: [ath9k-devel] Fwd: Re: EOMA68-A20 (allwinner sunxi a20) 4.7.0-rc2 ath9k_htc "ath9k_htc: Unable to allocate URBs" issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 hm... take my words back i reviewed the code, "ath9k_htc: Unable to allocate URBs" may come if there is not enough RAM or it is too fragmented. Some other reasons can be too, but current code is not verbose enough to provide mode information. On

[ath9k-devel] ath9k excessive delay in handling EAPOL frames

Hi, As this is remote problem debugging I haven't gathered quite as much info as I would like, and won't be investigating further immediately, but I would like to share what I have found so far, maybe it is useful knowledge and we can revisit later. With the following hardware on Linux 4.4, we

[ath9k-devel] [PATCH] ath9k: Proper TX99 interrupt ref count

On TX99 mode, instead of assuming interrupt mask non ATH9K_INT_GLOBAL, let ath9k_hw_disable_interrupts proper set interrupt ref count. This prevents some PCI PERR occurring specialy when setting 11b and n rates. Signed-off-by: Eduardo Abinader ---

Re: [ath9k-devel] ath9k-htc on OHCI -> bogus usb xfer

On 06.07.2016 10:45, Alexey Brodkin wrote: > Hi Oleksij, > > On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote: >> >> On 06.07.2016 10:32, Alexey Brodkin wrote: >>> >>> Hi Oleksij, >>> >>> On Wed, 2016-07-06 at 10:24 +0200, fixed-term.Oleksij.Rempel wrote:

[ath9k-devel] [PATCH] ath9k: Proper TX99 interrupt ref count

On TX99 mode, instead of assuming interrupt mask non ATH9K_INT_GLOBAL, let ath9k_hw_disable_interrupts proper set interrupt ref count. This prevents some PCI PERR occurring specialy when setting 11b and n rates. Signed-off-by: Eduardo Abinader ---

[ath9k-devel] [PATCH 2/2] ath9k: ar9003_mac: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some new features (e.g.

Re: [ath9k-devel] ath9k ARMv7 OOPS in v4.8.6, v4.2.8

On Wed, Nov 23, 2016 at 07:15:39PM +, Jason Cooper wrote: > --- oops from v4.8.6 #2 -- > [42059.303625] Unable to handle kernel NULL pointer dereference at virtual > address 0020 > [42059.311799] pgd = c0004000 > [42059.314522] [0020]

[ath9k-devel] [PATCH 1/2] ath9k: ar9002_mac: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some new features (e.g.

[ath9k-devel] Is it possible to configure multiple virtual AP and STA interfaces on DFS channel ?

I set up a virtual interface in AP mode on a DFS channel (52). Now I would like to have a couple of virtual interfaces in STA mode next to the AP interface. However, I cannot bring UP any STA interface due to the following error: "SIOCSIFFLAGS: Device or resource busy”. How can I configure

Re: [ath9k-devel] [PATCH 4.9.0-rc5] AR9300 calibration problems with antenna selected

I would prefer that you didn't submit this. > > I recently tried to select a single antenna on AR9300 and it works for > 30 seconds only. The subsequent calibration makes the RX signal level > to drop from the usual -30/-40 dBm to -70/-80 dBm, and the > transmission practically stops. > > With

Re: [ath9k-devel] [PATCH 4.9.0-rc5] AR9300 calibration problems with antenna selected

miaoq...@codeaurora.org writes: >> rmmod ath9k >> modprobe ath9k >> iw dev wlan0 set type ibss >> iw phy phyX set antenna 2 > > 2 is a bad mask. We use bitmap, the valid masks are 1, 3, 7. Thanks for your response. I have two antenna connections (and a single antenna). Is it possible to select

Re: [ath9k-devel] ath9k ARMv7 OOPS in v4.8.6, v4.2.8

On Wed, Nov 23, 2016 at 08:59:17PM +, Jason Cooper wrote: > As requested on irc: Thanks. > 7f0: ea02b 800 > 7f4: e7970102ldr r0, [r7, r2, lsl #2] > 7f8: ebfebl 0 > 7fc: e0844000

[ath9k-devel] [PATCH 0/2] ath9k: kill of ACCESS_ONCE() in MAC drivers

For several reasons, it would be beneficial to kill off ACCESS_ONCE() tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, more obviously document their intended behaviour, and are necessary for tools like KTSAN to work correctly (as otherwise reads and writes cannot be

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

On Sun, Oct 16, 2016 at 10:59:05PM +0200, Martin Blumenstingl wrote: > 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 >

Re: [ath9k-devel] regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

On Sun, Dec 18, 2016 at 07:57:42PM +, Valo, Kalle wrote: > Tobias Klausmann writes: > > > A patch for this is already floating on the ML for a while now latest: > > (ath9k: do not return early to fix rcu unlocking) > > It's here: > >

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

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 Blumenstingl >>> wrote:

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

On Tue, Sep 06, 2016 at 11:46:21PM +0200, Martin Blumenstingl wrote: > 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 >

Re: [ath9k-devel] [v3] ath9k: Switch to using mac80211 intermediate software queues.

Felix Fietkau writes: > On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote: >> Kalle Valo writes: >> >>> Toke Høiland-Jørgensen wrote: This switches ath9k over to using the mac80211 intermediate software queueing mechanism for data packets. It

[ath9k-devel] [PATCH v3] ath9k: Switch to using mac80211 intermediate software queues.

This switches ath9k over to using the mac80211 intermediate software queueing mechanism for data packets. It removes the queueing inside the driver, except for the retry queue, and instead pulls from mac80211 when a packet is needed. The retry queue is used to store a packet that was pulled but

Re: [ath9k-devel] [v3] ath9k: Switch to using mac80211 intermediate software queues.

Felix Fietkau writes: > On 2016-07-08 18:28, Toke Høiland-Jørgensen wrote: >> Felix Fietkau writes: >> >>> On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote: Kalle Valo writes: > Toke Høiland-Jørgensen wrote: >> This

Re: [ath9k-devel] [v3] ath9k: Switch to using mac80211 intermediate software queues.

Sebastian Gottschall writes: > for me it crashes on wds sta on 3.18 kernels. Bugger :/ > need to solder a serial to get more logs That would be helpful :) -Toke ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org

Re: [ath9k-devel] [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

On Tue, Aug 09, 2016 at 02:04:44PM +, Jason Cooper wrote: > > iiuc, Ted, you're saying using the hw_random framework would be > disasterous because despite most drivers having a default quality of 0, > rngd assumes 1 bit of entropy for every bit read? Sorry, what I was trying to say (but

[ath9k-devel] [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.

This switches ath9k over to using the mac80211 intermediate software queueing mechanism for data packets. It removes the queueing inside the driver, except for the retry queue, and instead pulls from mac80211 when a packet is needed. The retry queue is used to store a packet that was pulled but

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

Tim Shepard writes: > Thanks for unconfusing me a couple weeks ago, and cluing me into how > the limit on ->pending_frames is not really relevant for the data > packets that go through the new intermediate queues. > > But I'm not sure if this would allow us to remove the limit

[ath9k-devel] [PATCH v2] ath9k: Switch to using mac80211 intermediate software queues.

This switches ath9k over to using the mac80211 intermediate software queueing mechanism for data packets. It removes the queueing inside the driver, except for the retry queue, and instead pulls from mac80211 when a packet is needed. The retry queue is used to store a packet that was pulled but

Re: [ath9k-devel] [PATCH v2] ath9k: Switch to using mac80211 intermediate software queues.

Felix Fietkau writes: > On 2016-07-06 20:52, Toke Høiland-Jørgensen wrote: >> Felix Fietkau writes: >> >>> On 2016-07-06 18:16, Toke Høiland-Jørgensen wrote: This switches ath9k over to using the mac80211 intermediate software queueing mechanism for data

Re: [ath9k-devel] [v3] ath9k: Switch to using mac80211 intermediate software queues.

Kalle Valo writes: > Toke Høiland-Jørgensen wrote: >> This switches ath9k over to using the mac80211 intermediate software >> queueing mechanism for data packets. It removes the queueing inside the >> driver, except for the retry queue, and instead pulls from mac80211

Re: [ath9k-devel] [PATCH v3] ath9k: Switch to using mac80211 intermediate software queues.

Tim Shepard writes: >> The old code path in ath_tx_start that would queue packets has been >> removed completely, > > It seems to me that this breaks the ath9k driver when non-data packets > which mac80211 will not queue on the new intermediate queues, see > ieee80211_drv_tx(

Re: [ath9k-devel] [PATCH v2] ath9k: Switch to using mac80211 intermediate software queues.

Felix Fietkau writes: > On 2016-07-06 18:16, Toke Høiland-Jørgensen wrote: >> This switches ath9k over to using the mac80211 intermediate software >> queueing mechanism for data packets. It removes the queueing inside the >> driver, except for the retry queue, and instead pulls

  1   2   >