RE: ATH9 driver issues on ARM64

Hi All, After further debugging we know the place it hangs. In function: static int ath_reset_internal (struct ath_softc *sc, struct ath9k_channel *hchan) { disable_irq(sc->irq); tasklet_disable(>intr_tq); tasklet_disable(>bcon_tasklet);

Re: [PATCH 2/2] net: wireless: fix to uses struct

Hi Ozgur, [auto build test ERROR on mac80211-next/master] [also build test ERROR on v4.9 next-20161221] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ozgur-Karatas/net-wireless-fixed

Re: [PATCH 2/2] net: wireless: fix to uses struct

Hi Ozgur, [auto build test ERROR on mac80211-next/master] [also build test ERROR on v4.9 next-20161221] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ozgur-Karatas/net-wireless-fixed

[PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

From: Jaret Cantu Repeated polling attempts cause a NULL dereference error to occur. This is because the state of the trf7970a is currently reading but another request has been made to send a command before it has finished. The solution is to properly kill the waiting

[PATCH v3 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage

The TRF7970A has configuration options for supporting hardware designs with 1.8 Volt or 3.3 Volt IO. This commit adds a device tree option, using a fixed regulator binding, for setting the io voltage to match the hardware configuration. If no option is supplied it defaults to 3.3 volt

[PATCH v3 1/3] NFC: trf7970a: add device tree option for 27MHz clock

The TRF7970A has configuration options to support hardware designs which use a 27.12MHz clock. This commit adds a device tree option 'clock-frequency' to support configuring the this chip for default 13.56MHz clock or the optional 27.12MHz clock. Signed-off-by: Geoff Lansberry

Re: [PATCH 2/2] net: wireless: fix to uses struct

My previous patch is invalid, I'm sorry. The last patc will be fellow because "regulatory_request" is defined as a "static struct". Signed-off-by: Ozgur Karatas --- net/wireless/reg.c | 10 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 2/2] net: wireless: fix to uses struct

22.12.2016, 01:06, "Paul Bolle" : > On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote: >>  I don't have a problem with C programming > > I'm sorry, but you do need to learn C, at a basic level, first. Hmm, I don't like to discussion but I'm an assertive on C/C++. So, I'm

Re: [PATCH 2/2] net: wireless: fix to uses struct

On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote: > I don't have a problem with C programming I'm sorry, but you do need to learn C, at a basic level, first. Paul Bolle

Re: [PATCH 2/2] net: wireless: fix to uses struct

22.12.2016, 00:34, "Paul Bolle" : > On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote: >>  I compiled and didn't to errors. > > Really? I'm very sorry. The "regulatory_request" is defined a static struct. I missed. line: static struct regulatory_request

Re: [PATCH 2/2] net: wireless: fix to uses struct

On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote: > I compiled and didn't to errors. Really? $ make net/wireless/reg.o CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h

[PATCH 2/2] net: wireless: fix to uses struct

The patch fixed to struct uses in reg.c, I think doesn't need to be use to "struct". There is dataype not have to logical link and each is different definitons. I'm undecided on this patch. I compiled and didn't to errors. Signed-off-by: Ozgur Karatas ---

[PATCH 1/2] net: wireless: fixed to checkpatch errors

Fixed to checkpatch errors, Normally, comment's */ had to be finish on the next line. The patch fix to readability and Coding Style. Sİgned-off-by: Ozgur Karatas --- net/wireless/chan.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git

[PATCH] rtlwifi: rtl_usb: Fix missing entry in USB driver's private data

These drivers need to be able to reference "struct ieee80211_hw" from the driver's private data, and vice versa. The USB driver failed to store the address of ieee80211_hw in the private data. Although this bug has been present for a long time, it was not exposed until commit ba9f93f82aba

Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage

On Wed, Dec 21, 2016 at 06:47:36AM -0500, Geoff Lansberry wrote: > Thanks Mark. Should I resubmit patches with the requested edits today, or > wait a bit for more comments? What is the desired etiquette? Its up to you. I don't think there are any hard & fast rules on this. If it were me, I

Re: ath10k mesh error 80MHz channel

Hi all again, just an update to the previous message: looking at iw list I found this situation: Frequencies: * 5180 MHz [36] (20.0 dBm) * 5200 MHz [40] (20.0 dBm) * 5220 MHz [44] (20.0 dBm) * 5240 MHz [48] (20.0 dBm) * 5260 MHz

Re: rtlwifi: Fix kernel oops introduced with commit e49656147359

Larry Finger wrote: > With commit e49656147359 {"rtlwifi: Use dev_kfree_skb_irq instead of > kfree_skb"), the method used to free an skb was changed because the > kfree_skb() was inside a spinlock. What was forgotten is that kfree_skb() > guards against a NULL value for

Re: [v2] ath9k: do not return early to fix rcu unlocking

Tobias Klausmann wrote: > Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb > where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on > returning early in ath_tx_edma_tasklet() the unlock is missing leading to >

ath10k mesh error 80MHz channel

Dear all, I'm configuring a simple mesh network using four miniPCIe adapters (Compex WLE900VX) on two Gateworks Ventana 5410 boards. Actually, based on the guide https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh I don't have any problem setting up the mesh network on channels 36, 149,

[PATCH] ath10k: support dev_coredump for crash dump

From: Arun Khandavalli Whenever firmware crashes, and both CONFIG_ATH10K_DEBUGFS and CONFIG_ALLOW_DEV_COREDUMP are enabled, dump information about the crash via a devcoredump device. Dump can be read from userspace for further analysis from:

skb truesize bug related to ath10k

This warning is from the code below. Anyone seen this recently? And, what sorts of code problems can generate this type of error? We seem to have a way to reproduce this by bringing down and up many station vdevs over and over again, so I can probably fix/test it if I can understand the

Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage

Thanks Mark. Should I resubmit patches with the requested edits today, or wait a bit for more comments? What is the desired etiquette? > On Dec 20, 2016, at 9:23 PM, Mark Greer wrote: > >> On Tue, Dec 20, 2016 at 11:16:31AM -0500, Geoff Lansberry wrote: >> From:

[RFC] nl80211: allow multiple active scheduled scan requests

This patch implements the idea to have multiple scheduled scan requests running concurrently. It mainly illustrates how to deal with the incoming request from user-space in terms of backward compatibility. In order to use multiple scheduled scans user-space needs to provide a flag attribute

Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs

On 20-12-2016 21:52, Malinen, Jouni wrote: > On Fri, Dec 16, 2016 at 10:56:51AM +0100, Johannes Berg wrote: >> On Thu, 2016-12-15 at 11:06 +, Malinen, Jouni wrote: >>> Maybe the nl80211.h description was not clear enough, but the >>> comments in cfg80211.h should be quite clear on how this was

[PATCH v3] rfkill: Add rfkill-any LED trigger

Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any, which may be useful on laptops with a single "radio LED" and multiple radio transmitters. The trigger is meant to turn a LED on whenever there is at least one radio transmitter active and turn it off otherwise. This