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(&sc->intr_tq);
tasklet_disable(&sc->bcon_tasklet);
spin_lock_bh(&sc->
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-to
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-to
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 reading (workqueue)
before
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 configurati
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
---
.../devicetree
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 a/net/wireless/reg.c b/net/wire
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 not into the Linux k
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
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 core_request_world = {
I send to wro
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
CHK
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
---
net/wireless/reg.c | 10 +-
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 a/net/wireless/chan.c b/net/wireless/
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 ("rtlwifi
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 w
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
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 the argument. Routine dev_k
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
> stalls
> and suspicious RCU usage:
>
>
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,
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:
/sys/class/devcoredump/devcd*/data
As until now we ha
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 problem
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: Geoff Lansberry
>>
>> The T
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
NL80211
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
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 requires
25 matches
Mail list logo