From: Miaoqing Pan
rename the variable as preparation for using the array with 2.4 GHz
band, etc.
Signed-off-by: Miaoqing Pan
---
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 4 ++--
drivers/net/wireless/ath/ath9k/hw.h | 2
From: Miaoqing Pan
A small bugfix for commit ede6a5e7b859 ("ath9k: Add QCA956x HW support").
I guess I would have skipped renaming (that initial QCA956x commit has
been there already for almost a year with the "5g" in the name) and move
the call outside AR_SREV_9462_20_OR_LATER() to make it reach
On Mon, Sep 28, 2015 at 11:43:55PM +0530, Chandra S Gorentla wrote:
> - The message queue is replaced with standard Linux linked list
> - kmem_cache is used for list members
> - A check for return value of receive method is added
> - GFP_ATOMIC is changed to GFP_KERNEL
> - A few other related
From: Miaoqing Pan
This patch is derived from
commit 6301566e0b2d ("ath9k: export HW random number generator"),
We evaluated the entropy of the ADC data on QCA9531, QCA9561, QCA955x,
and AR9340, and it has sufficient quality random data (at least 10 bits
and up to 22 bits of min-entropy for a 32
On Mon, Sep 28, 2015 at 11:43:55PM +0530, Chandra S Gorentla wrote:
> - The message queue is replaced with standard Linux linked list
> - kmem_cache is used for list members
Why?
> - A check for return value of receive method is added
> - GFP_ATOMIC is changed to GFP_KERNEL
Why? Are you sur
On Tue, Sep 29, 2015 at 12:07:43AM +0530, Chandra Gorentla wrote:
> Please do not review this. This is duplicate to -
> [PATCH 2/2] drivers: staging: wilc1000: wilc_msgqueue.c: Remove ineffective
> code
I don't understand, you sent 2 2/2 patches, which one do I look at?
Please just resend the w
On Wed, Sep 23, 2015 at 06:03:49PM +0900, Chaehyun Lim wrote:
> This patch removes wilc_platform.h include file in wilc_oswrapper.h
> Because wilc_platform.h have several standard header files so that some
> header file should be included .c file to avoid compilation errors.
>
> Signed-off-by: Cha
On Wed, Sep 23, 2015 at 04:10:54PM +0900, Glen Lee wrote:
> The define WILC_PARSE_SCAN_IN_HOST is always used in the driver, so just
> delete ifdef WILC_PARSE_SCAN_IN_HOST line, ifndef WILC_PARSE_SCAN_IN_HOST
> line and it's related codes. Finally, remove define in Makefile.
>
> Signed-off-by: Gle
Here is the changelog note. This requires some corresponding driver patches to
enable the A-MSDU with IBSS because the ath10k hardware (or maybe firmware bug)
causes the BSSID in A-MSDU packets to be all zeros.
So, in CT 4.0 and 4.2 kernels there is a patch that allows all-zero BSSIDs
on IBSS in
Here is an older draft document, dated end 2014 directly from the regulator
(ICASA):
http://www.icasa.org.za/Portals/0/Regulations/Working%20Docmuents/Radio%20Frequency%20Spectrum%20Regulations/DraftRevRadioFreq.pdf
Notice on page end 80 / top 81 that it lists:
"DFS & Transmitter Power Control
Christian Lamparter schrieb:
>This patch fixes a crash which is triggered
>by __ieee80211_beacon_get returning NULL.
Ouch, thanks for catching this!
Helmut
>This causes sky_copy to crash later unless
>the hardware supports BEACON_TX_STATUS
>feature.
>
>Signed-off-by: Christian Lamparter
>--
This patch fixes a crash which is triggered
by __ieee80211_beacon_get returning NULL.
This causes sky_copy to crash later unless
the hardware supports BEACON_TX_STATUS
feature.
Signed-off-by: Christian Lamparter
---
"mac80211: Copy tx'ed beacons to monitor mode" added the skb_copy.
There are few
Please do not review this. This is duplicate to -
[PATCH 2/2] drivers: staging: wilc1000: wilc_msgqueue.c: Remove ineffective code
On Mon, Sep 28, 2015 at 11:43:56PM +0530, Chandra S Gorentla wrote:
> Signed-off-by: Chandra S Gorentla
> ---
> drivers/staging/wilc1000/wilc_msgqueue.c | 5 -
>
Mateusz Kulikowski writes:
> Firmware was not released properly if kmemdup fails.
>
> Addresses-Coverity-Id: 1269118
> Signed-off-by: Mateusz Kulikowski
> ---
> drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Jes Sorensen
- The message queue is replaced with standard Linux linked list
- kmem_cache is used for list members
- A check for return value of receive method is added
- GFP_ATOMIC is changed to GFP_KERNEL
- A few other related minor changes
Signed-off-by: Chandra S Gorentla
---
- Comments of Dan Carpe
Arend van Spriel writes:
> If my administration is correct there are 29 patches pending. Any
> chance these will get applied. Or did I miss some remarks requiring a
> resend.
Yeah, I have been lagging behind patches due to other stuff and I have
64 patches pending right now. Sorry about that, I
Signed-off-by: Chandra S Gorentla
---
drivers/staging/wilc1000/wilc_msgqueue.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c
b/drivers/staging/wilc1000/wilc_msgqueue.c
index a01ada4..1a411d3 100644
--- a/drivers/staging/wilc1000/wilc_msgqueue.c
Signed-off-by: Chandra S Gorentla
---
drivers/staging/wilc1000/wilc_msgqueue.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c
b/drivers/staging/wilc1000/wilc_msgqueue.c
index a01ada4..1a411d3 100644
--- a/drivers/staging/wilc1000/wilc_msgqueue.c
On 09/18/2015 10:08 PM, Arend van Spriel wrote:
This series is intended for v4.4 containing the following highlights:
* support for BCM4350, BCM4365, and BCM4366 PCIE devices.
* fixed for legacy P2P and P2P device handling.
* correct set and get tx-power.
The series should be applied to master
On Mon, 2015-09-28 at 11:07 -0500, Seth Forshee wrote:
> On Mon, Sep 28, 2015 at 09:44:20AM +0200, Johannes Berg wrote:
> >
> > > The bands don’t quite match up and DFS/TPC is (apparently) not
> > > required for 5470 - 5725. More importantly, the max transmitted
> > > power
> > > seems to be 1W/
Hi,
On 09/28/2015 05:59 AM, Bob Copeland wrote:
Rather than always advertising mesh support and then generating
an error when the user attempts to bring up the device without
rawmode, only advertise it when available: that is, if the module
is loaded with rawmode=1, the firmware supports it, and
On Mon, Sep 28, 2015 at 09:44:20AM +0200, Johannes Berg wrote:
>
> > The bands don’t quite match up and DFS/TPC is (apparently) not
> > required for 5470 - 5725. More importantly, the max transmitted power
> > seems to be 1W/30dBm e.i.r.p and not 27dBm.
>
> Without checking now, just a note: we
From: James Bottomley
> Sent: 28 September 2015 16:12
> > > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit'
> > > > operations.
> > >
> > > That's different: it's an atomic RMW operation. The problem with the
> > > alpha was that the operation wasn't atomic (meaning that it can't
On Mon, 2015-09-28 at 14:50 +, David Laight wrote:
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> > Sent: 28 September 2015 15:27
> > On Mon, 2015-09-28 at 08:58 +, David Laight wrote:
> > > From: Rafael J. Wysocki
> > > > Sent: 27 September 2015 15:09
> > > ...
>
From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: 28 September 2015 15:27
> On Mon, 2015-09-28 at 08:58 +, David Laight wrote:
> > From: Rafael J. Wysocki
> > > Sent: 27 September 2015 15:09
> > ...
> > > > > Say you have three adjacent fields in a structure, x, y, z,
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
master
head: 75281915cd10d5ae6fe7a78bfd9fd3cce988c77b
commit: 290da6ceeb8f58d63f0810593c95753825b52f57 [10/15] Merge branch 'master'
of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
config: mip
On Mon, 2015-09-28 at 08:58 +, David Laight wrote:
> From: Rafael J. Wysocki
> > Sent: 27 September 2015 15:09
> ...
> > > > Say you have three adjacent fields in a structure, x, y, z, each one
> > > > byte long.
> > > > Initially, all of them are equal to 0.
> > > >
> > > > CPU A writes 1 to
Hi,
I moved my ath.git tree to kernel.org:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
cgit:
https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/
I'll try to manually update the old location for a while but sooner than
later I remove the old tree. I strongly recommend to
From: Anilkumar Kolli
This patch disables PCI PS for QCA988X and QCA99X0, Since PCI PS is
validated for QCA6174, let it be enabled only for QCA6174. It would be
better to execute PCI PS related functions only for the supported devices.
PCI time out issue is observed with QCA99X0 on x86 platform,
Rather than always advertising mesh support and then generating
an error when the user attempts to bring up the device without
rawmode, only advertise it when available: that is, if the module
is loaded with rawmode=1, the firmware supports it, and the
device/firmware supports an AP virtual interfa
* Johannes Berg [28.09.2015 14:38]:
> Depends what you're measuring, but ping should apply the same DSCP tag
> on the response I believe.
your are right, I did not know this till yet 8-)
(i applied 0xb8 with 'ping -c1 -Q' just for testing)
14:49:52.491925 IP (tos 0xb8, ttl 64, id 51117, offset 0
On Monday, September 28, 2015 10:24:58 AM Arnd Bergmann wrote:
> On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> > On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > > On 25 September 2015 at 15:19,
On Mon, 2015-09-28 at 14:15 +0200, Bastian Bittorf wrote:
> * Johannes Berg [28.09.2015 14:00]:
> > > > # you have to add some magic for matching your data
> > > > e.g. $IPT -t mangle -I OUTPUT -j DSCP --set-dscp-class CS7
> > >
> > > Again, this is ping -Q equivalent, right? I was doing
> >
> >
* Johannes Berg [28.09.2015 14:00]:
> > > # you have to add some magic for matching your data
> > > e.g. $IPT -t mangle -I OUTPUT -j DSCP --set-dscp-class CS7
> >
> > Again, this is ping -Q equivalent, right? I was doing
>
> Yes.
IMHO this is not the same: you have to do it on both ends.
(also
On Sun, Sep 27, 2015 at 09:48:19PM +0200, Mateusz Kulikowski wrote:
> Firmware was not released properly if kmemdup fails.
>
> Addresses-Coverity-Id: 1269118
> Signed-off-by: Mateusz Kulikowski
> ---
Not seen your v2 while replying to your v1. Sorry for the noise.
regards
sudip
--
To unsubscribe
On Sun, Sep 27, 2015 at 09:30:54PM +0200, Mateusz Kulikowski wrote:
> Firmware was not released properly if kmemdup fails.
>
> Addresses-Coverity-Id: 1269118
> Signed-off-by: Mateusz Kulikowski
> ---
> drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Sun, Sep 27, 2015 at 07:43:18PM +0530, Chandra S Gorentla wrote:
> The message queue is replaced with standard Linux linked list. A check for
> return value of receive method is added.
>
> Signed-off-by: Chandra S Gorentla
> ---
> drivers/staging/wilc1000/host_interface.c | 7 +++-
> driver
Hi,
I'm using recent brcmfmac and brcmfmac43602-pcie.ap.bin that currently
sits in linux-firmware.git.
In OpenWrt we have hostapd with a feature of banning STAs. It works in
a quite simple way. Whenever hostapd gets NL80211_CMD_NEW_STATION for
STA that is banned it sends NL80211_CMD_DEL_STATION.
From: Rafael J. Wysocki
> Sent: 27 September 2015 15:09
...
> > > Say you have three adjacent fields in a structure, x, y, z, each one byte
> > > long.
> > > Initially, all of them are equal to 0.
> > >
> > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > >
> > > What's the resu
On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > On 25 September 2015 at 15:19, Rafael J. Wysocki
> > > wrote:
> > > > So if you allow something lik
> The bands don’t quite match up and DFS/TPC is (apparently) not
> required for 5470 - 5725. More importantly, the max transmitted power
> seems to be 1W/30dBm e.i.r.p and not 27dBm.
Without checking now, just a note: we sometimes have lower limits here
due to spectral power density, indoor/outd
On Sat, 2015-09-26 at 12:24 +0200, Pavel Machek wrote:
>
> That would be equivalent to ping -Q, right? It does not seem to have
> any effect :-(. I'd expect at least local machine to use shorter waits
> for medium, and thus drop packets instead of waiting.
Correct. But it won't *drop* packets, it
42 matches
Mail list logo
