On Thu, 2017-09-21 at 23:56 +0100, Colin King wrote:
> From: Colin Ian King
>
> Don't populate const array ac_to_fifo on the stack in an inlined
> function, instead make it static. Makes the object code smaller
> by over 800 bytes:
>
> text data bss dec hex
> filename
>
On Thu, Sep 21, 2017 at 09:40:14AM -0500, Larry Finger wrote:
> On 09/21/2017 03:07 AM, James Cameron wrote:
> >My test kernel "-qb" was write_readback = false in sw.c, with 8-bit
> >read of REG_DBI_RDATA, and has been stable for four hours. I'll
> >focus on some more testing of this one. It is a
From: Colin Ian King
Don't populate const array ac_to_fifo on the stack in an inlined
function, instead make it static. Makes the object code smaller
by over 800 bytes:
textdata bss dec hex filename
159029 331541216 193399 2f377 4965-mac.o
textdata bss
From: Igor Mitsyanko
No reason to verify channel switch request in driver, it can simply be
forwarded to wireless device. Device can perform required checks and
return appropriate error code, and driver may not even have information
on current operational channel.
Signed-off-by: Igor Mitsyanko
From: Igor Mitsyanko
There are no users of this field and it can safely be removed.
Signed-off-by: Igor Mitsyanko
---
drivers/net/wireless/quantenna/qtnfmac/commands.c | 1 -
drivers/net/wireless/quantenna/qtnfmac/core.h | 5 -
drivers/net/wireless/quantenna/qtnfmac/event.c| 2 --
From: Igor Mitsyanko
Specifically, it has to report center frequency, secondary center
frequency (for 80+80) and BW.
Introduce channel definition structure to qlink and modify channel
change event processing function accordingly.
Signed-off-by: Igor Mitsyanko
---
drivers/net/wireless/quantenna
From: Igor Mitsyanko
It is never used for anything useful, and all logic is handled by
either WiFi card or higher layers.
Signed-off-by: Igor Mitsyanko
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 12
drivers/net/wireless/quantenna/qtnfmac/commands.c | 2 --
drivers/ne
From: Igor Mitsyanko
This makes no sense because real operational channel is choosen based
on AP operation, not on what STA is configured to.
Signed-off-by: Igor Mitsyanko
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 15 +--
drivers/net/wireless/quantenna/qtnfmac/command
From: Igor Mitsyanko
Wireless device may send "channel changed" event before driver
registered this device with wireless core, which will result in
warnings.
Once device is registered, higher layer will query channel info
manually using .get_channel callback.
Signed-off-by: Igor Mitsyanko
---
From: Igor Mitsyanko
Do not assume whether wireless device can or can not handle switching
several interfaces on a single radio to different channels. Device will
handle it itself and will return appropriate error code.
Signed-off-by: Igor Mitsyanko
---
drivers/net/wireless/quantenna/qtnfmac/c
From: Igor Mitsyanko
Do not try to cache current operational channel info in driver, this
is a potential source of synchronization issues + driver does not
really need that info.
Introduce GET_CHANNEL command and process it appropriately.
Signed-off-by: Igor Mitsyanko
---
drivers/net/wireless
From: Igor Mitsyanko
This will allow to use qlink channel width values to specify BW setting
corresponding to enum nl80211_chan_width.
Current user is converted to apply BIT() macro manually to each individual
qlink_channel_width enumeration value.
Signed-off-by: Igor Mitsyanko
---
drivers/net
From: Igor Mitsyanko
This patchset has a goal to start using full current channel information
as reported by wireless device (specifically, center freq 1 and 2 and
operational BW).
It was part of bigger changeset when it was V1.
Changelist V2->V3:
Do not leave commit messages empty
Changelist
Including some people I've seen mentioned in ToF-related e-mails...
This is what I've tried:
-- Responder --
* hostapd running, hostapd.conf:
driver=nl80211
interface=wlan1
hw_mode=g
channel=1
wmm_enabled=1
ssid=tof_test
ftm_responder=1
On Wed, Sep 20, 2017 at 9:55 PM, Johannes Berg
wrote:
> On Wed, 2017-09-20 at 21:27 +0200, Christian Lamparter wrote:
>
>> It seems this is caused as a result of:
>> -> lock_map_acquire(&work->lockdep_map);
>> lock_map_release(&work->lockdep_map);
>>
>> in flush_work() [0]
>
> Ag
Hi All
I am trying to apply the path mentioned below to set txq params using
iw command.
http://www.spinics.net/lists/linux-wireless/msg42585.html
But I am getting below error.
root@teste-VirtualBox:~/old_iw/iw-0.9.17# ./iw list | grep Wiphy
Wiphy mn00s05
Wiphy mn00s04
Wiphy mn00s03
Wiphy mn00s
On Fri, Aug 18, 2017 at 08:20:02PM +0300, Luca Coelho wrote:
Hello Luca,
Thank you and Johannes for looking into this.
> > I'll try to dig the thread I had about this and take it again with our
> > system engineers to hear what they have to say about it.
Any news about that thread by any chance?
Hi Arend,
On Thu, Sep 21, 2017 at 4:26 AM, Arend van Spriel
wrote:
> On 20-09-17 21:33, Vanessa Ayumi Maegima wrote:
>>
>> Hi,
>>
>> I am trying to enable Wifi on imx7d-pico using mainline kernel. imx7d-pico
>> has an AP6335 chip.
>>
>> I am facing some issues related to the nvram file. I am usin
Arnd Bergmann writes:
> When CONFIG_PM_SLEEP is disabled, we get a compile-time
> warning:
>
> drivers/net/wireless/ath/ath10k/pci.c:3417:12: error: 'ath10k_pci_pm_resume'
> defined but not used [-Werror=unused-function]
> static int ath10k_pci_pm_resume(struct device *dev)
> ^~
Allen Pais writes:
> Use setup_timer function instead of initializing timer with the
> function and data fields.
>
> Signed-off-by: Allen Pais
The commit log is weirdly indented and no need to have "wireless:
broadcom:" in the title. I can fix both of those.
--
Kalle Valo
Larry Finger writes:
> On 09/21/2017 06:37 AM, Zwindl wrote:
>> Hi, I've reported to archlinux's bugzilla, and finally found out the
>> flag which caused that issue, it's the
>> `CONFIG_INTEL_IOMMU_DEFAULT_ON=y` flag, I think may this is a kernel
>> bug, more details at https://bugs.archlinux.org
On 09/21/2017 03:07 AM, James Cameron wrote:
My test kernel "-qb" was write_readback = false in sw.c, with 8-bit
read of REG_DBI_RDATA, and has been stable for four hours. I'll focus
on some more testing of this one. It is a surprise.
http://dev.laptop.org/~quozl/z/1dutXk.txt (dmesg)
Observe
On Tue, Sep 19, 2017 at 8:19 PM, Kalle Valo wrote:
> Amitkumar Karwar writes:
>
>> From: Karun Eagalapati
>>
>> SDIO suspend and resume handlers are implemented and verified
>> that device works after suspend/resume cycle.
>>
>> Signed-off-by: Karun Eagalapati
>> Signed-off-by: Amitkumar Karwar
On Tue, Sep 19, 2017 at 8:09 PM, Kalle Valo wrote:
> Amitkumar Karwar writes:
>
>> From: Pavani Muthyala
>>
>> We will dump information about driver and firmware versions,
>> firmware file name and operating mode during initialization.
>>
>> Signed-off-by: Pavani Muthyala
>> Signed-off-by: Amit
On Thu, Sep 21, 2017 at 7:08 PM, Souptick Joarder wrote:
> On Thu, Sep 21, 2017 at 6:21 PM, Amitkumar Karwar
> wrote:
>> From: Karun Eagalapati
>>
>> SDIO suspend and resume handlers are implemented and verified
>> that device works after suspend/resume cycle.
>>
>> Signed-off-by: Karun Eagalap
On 09/21/2017 06:37 AM, Zwindl wrote:
Hi, I've reported to archlinux's bugzilla, and finally found out the flag which
caused that issue, it's the `CONFIG_INTEL_IOMMU_DEFAULT_ON=y` flag, I think may
this is a kernel bug, more details at https://bugs.archlinux.org/task/55665
My standard kernel h
On Fri, 2017-09-08 at 18:07 +0200, Richard Schütz wrote:
> Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B
> to get
> all mandatory rates in 2.4 GHz band. It is safe to do so because ERP
> mandatory rates are a superset of HR/DSSS mandatory rates. Also limit
> to
> OFDM rates f
On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote:
> According to IEEE Std 802.11-2016 (16.2.3.4 Long PHY SIGNAL field)
> all of
> the following rates are mandatory for a HR/DSSS PHY: 1 Mb/s, 2 Mb/s,
> 5.5 Mb/s and 11 Mb/s. Set IEEE80211_RATE_MANDATORY_B flag for all of
> these
> instead of j
On Thu, Sep 21, 2017 at 6:21 PM, Amitkumar Karwar wrote:
> From: Karun Eagalapati
>
> SDIO suspend and resume handlers are implemented and verified
> that device works after suspend/resume cycle.
>
> Signed-off-by: Karun Eagalapati
> Signed-off-by: Amitkumar Karwar
> ---
> v2: Replaced never en
From: Karun Eagalapati
SDIO suspend and resume handlers are implemented and verified
that device works after suspend/resume cycle.
Signed-off-by: Karun Eagalapati
Signed-off-by: Amitkumar Karwar
---
v2: Replaced never ending while loop with 20msecs loop(Kalle Valo)
---
drivers/net/wireless/rs
From: Pavani Muthyala
We will dump information about firmware version, firmware file
name and operating mode during initialization.
Signed-off-by: Pavani Muthyala
Signed-off-by: Amitkumar Karwar
---
v2: Removed driver version information.(Kalle Valo)
---
drivers/net/wireless/rsi/rsi_91x_debug
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm8021
> > - these two fixes will show up in wireless-drivers-next at some point
> > in the future after you move wireless-drivers-next forward, rebasing
> > it on top of one of the upcoming "-rc"
>
> I would not use the term "rebase" here, as that means rewriting the
> history which should be avoided on
Sergey Matyukevich writes:
> Hello Kalle,
>
>> > Fix tx path regression. Lock should be held when queuing packets
>> > to h/w fifos in order to properly handle configurations with
>> > multiple enabled interfaces.
>> >
>> > Signed-off-by: Sergey Matyukevich
>>
>> 2 patches applied to wireless-d
On Thu, Sep 21, 2017 at 09:22:28AM +1000, James Cameron wrote:
> On Wed, Sep 20, 2017 at 04:48:23PM -0500, Larry Finger wrote:
> > On 09/20/2017 04:36 AM, James Cameron wrote:
> > >When the problem occurs, register 0x350 bit 25 is set, for which a
> > >comment in _rtl8821ae_check_pcie_dma_hang says
Hello Kalle,
> > Fix tx path regression. Lock should be held when queuing packets
> > to h/w fifos in order to properly handle configurations with
> > multiple enabled interfaces.
> >
> > Signed-off-by: Sergey Matyukevich
>
> 2 patches applied to wireless-drivers.git, thanks.
>
> 20da2ec06bfa
On 20-09-17 21:33, Vanessa Ayumi Maegima wrote:
Hi,
I am trying to enable Wifi on imx7d-pico using mainline kernel. imx7d-pico
has an AP6335 chip.
I am facing some issues related to the nvram file. I am using the firmware
provided by Buildroot (brcmfmac4339-sdio.bin). I get the following error:
37 matches
Mail list logo
