Use the BIT() macro from 'linux/bitops.h' to define the rx desc
bit flags to have consistency with new definitions.
Signed-off-by: Govind Singh
---
drivers/net/wireless/ath/ath10k/rx_desc.h | 134 +++---
1 file changed, 67 insertions(+), 67 deletions(-)
On 2018-05-08 23:07, Bjorn Andersson wrote:
On Sun 25 Mar 22:37 PDT 2018, Govind Singh wrote:
Add QMI client driver for Q6 integrated WLAN connectivity subsystem.
This module is responsible for communicating WLAN control messages to
FW
over QMI interface.
“QUALCOMM Messaging Interface”(QMI)
On 2018-05-08 02:12, Bjorn Andersson wrote:
On Sun 25 Mar 22:40 PDT 2018, Govind Singh wrote:
Add WLAN related VMID's to support wlan driver to set up
the remote's permissions call via TrustZone.
Signed-off-by: Govind Singh
Please use ./scripts/get_maintainer.pl for
ware loader can use my linux-next
> branch 20180508-firmware_loader_for-v4.18-try2 for now.
>
> 0-day sends its blessings.
>
> The patches from Mimi's series still require a bit more discussion and
> review. The discussion over the EFI firmware fallback mechanism is still
> ongo
On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez wrote:
> If you try to read FW_LOADER today it speaks of old riddles and
> unless you have been following development closely you will loose
Typo: lose
> track of what is what. Even the documentation for
Hi,
On 8 May 2018 at 14:19, Johannes Berg wrote:
> On Tue, 2018-05-08 at 14:18 +0200, Arend van Spriel wrote:
>> On 5/7/2018 9:19 PM, Johannes Berg wrote:
>> > On Sun, 2018-04-29 at 20:30 +0200, Andrew Zaborowski wrote:
>> > > On 28 April 2018 at 15:07, Kalle Valo
On Thu, May 03, 2018 at 06:58:22PM +0300, Haim Dreyfuss wrote:
> The ETSI EN 301 893 v211 (2017-05) standard defines a new channel
> access mechanism that all devices (WLAN and LAA) need to comply with.
> In previous versions the device was allowed by ETSI to implement
> 802.11 channel access
On 2018-05-08 02:12 PM, Luis R. Rodriguez wrote:
Clarify the provenance of the firmware loader firmware_class module name
and why we cannot rename the module in the future.
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/fallback-mechanisms.rst | 9
From: Andres Rodriguez
This should let us associate enum kdoc to these values.
While at it, kdocify the fw_opt.
Signed-off-by: Andres Rodriguez
Acked-by: Luis R. Rodriguez
[mcgrof: coding style fixes, merge kdoc with enum move]
This also sets the expecations for future fallback interfaces, even
if they are not exported.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/fallback.c | 20
1 file changed, 20 insertions(+)
diff --git
From: Andres Rodriguez
The kernel-doc spec dictates a function name ends in ().
Signed-off-by: Andres Rodriguez
Acked-by: Randy Dunlap
Acked-by: Luis R. Rodriguez
[mcgrof: adjust since the wide API rename is
If you try to read FW_LOADER today it speaks of old riddles and
unless you have been following development closely you will loose
track of what is what. Even the documentation for PREVENT_FIRMWARE_BUILD
is a bit fuzzy and how it fits into this big picture.
Give the FW_LOADER kconfig documentation
From: Andres Rodriguez
This is done since this call is now exposed through kernel-doc,
and since this also paves the way for different future types of
fallback mechanims.
Signed-off-by: Andres Rodriguez
Acked-by: Luis R. Rodriguez
This will make it easier to track and easier to understand
what components and features are part of the FW_LOADER. There
are some components related to firmware which have *nothing* to
do with the FW_LOADER, souch as PREVENT_FIRMWARE_BUILD.
Signed-off-by: Luis R. Rodriguez
---
From: Andres Rodriguez
This reduces the unnecessary spew when trying to load optional firmware:
"Direct firmware load for ... failed with error -2"
Signed-off-by: Andres Rodriguez
Acked-by: Kalle Valo
Signed-off-by: Luis R.
If we resort to using the sysfs fallback mechanism we don't print
the filename. This can be deceiving given we could have a series of
callers intertwined and it'd be unclear exactly for what firmware
this was meant for.
Additionally, although we don't currently use FW_OPT_NO_WARN when
dealing
From: Andres Rodriguez
The ath10k testmode uses request_firmware_direct() in order to avoid
producing firmware load warnings. Disabling the fallback mechanism was a
side effect of disabling warnings.
We now have a new API that allows us to avoid warnings while keeping the
From: Andres Rodriguez
Currently the firmware loader only exposes one silent path for querying
optional firmware, and that is firmware_request_direct(). This function
also disables the sysfs fallback mechanism, which might not always be the
desired behaviour [0].
This patch
Fix a few typos, and clarify a few sentences.
Signed-off-by: Luis R. Rodriguez
---
Documentation/driver-api/firmware/fallback-mechanisms.rst | 5 +++--
Documentation/driver-api/firmware/firmware_cache.rst | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff
It refers to a pending patch, but this was merged eons ago.
Signed-off-by: Luis R. Rodriguez
---
Documentation/dell_rbu.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt
index 0fdb6aa2704c..077fdc29a0d0 100644
Clarify the provenance of the firmware loader firmware_class module name
and why we cannot rename the module in the future.
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/fallback-mechanisms.rst | 9 ++---
1 file changed, 6 insertions(+), 3
which have come up recently. These changes are available on my git tree
both based on linux-next [0] and Linus' latest tree [1]. Folks working
on new developments for the firmware loader can use my linux-next
branch 20180508-firmware_loader_for-v4.18-try2 for now.
0-day sends its blessings
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
master
head: 57c6cb81717f957fb741f2e4c79bd0e2f4f55910
commit: 52539ca89f365d3db530535fbffa88a3cca4d2ec [12/14] cfg80211: Expose TXQ
stats and parameters to userspace
config: i386-randconfig-i1-201818 (attached as
On Tue, May 08, 2018 at 10:13:42AM -0600, Jonathan Corbet wrote:
> On Mon, 7 May 2018 06:35:36 -0300
> Mauro Carvalho Chehab wrote:
>
> > I decided to give a try with Sphinx last stable version
> > (1.17.4), and noticed several issues. The worse one was
> > with the
On Sun 25 Mar 22:37 PDT 2018, Govind Singh wrote:
> Add QMI client driver for Q6 integrated WLAN connectivity subsystem.
> This module is responsible for communicating WLAN control messages to FW
> over QMI interface.
>
> “QUALCOMM Messaging Interface”(QMI) provides the control interface between
On Thu, May 03, 2018 at 08:24:26PM -0400, Mimi Zohar wrote:
> On Fri, 2018-05-04 at 00:07 +, Luis R. Rodriguez wrote:
> > On Tue, May 01, 2018 at 09:48:20AM -0400, Mimi Zohar wrote:
> > > Allow LSMs and IMA to differentiate between signed regulatory.db and
> > > other firmware.
> > >
> > >
This patch lets user to specify duration(TUs) and set duration-mandatory
flag in scan command.
Signed-off-by: Pradeep Kumar Chitrapu
---
scan.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/scan.c b/scan.c
index
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
master
head: 57c6cb81717f957fb741f2e4c79bd0e2f4f55910
commit: 52539ca89f365d3db530535fbffa88a3cca4d2ec [12/14] cfg80211: Expose TXQ
stats and parameters to userspace
reproduce: make htmldocs
All warnings (new ones
On Tue, 2018-05-08 at 11:31 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Used buffer wasn't big enough to hold whole strings. Example output of
> this function is:
> [0.180892] bcma: bus0: core 0x0800, irq: 2(S)* 3 4 5 6 D I
> [0.180948] bcma: bus0: core
On Mon, 7 May 2018 06:35:36 -0300
Mauro Carvalho Chehab wrote:
> I decided to give a try with Sphinx last stable version
> (1.17.4), and noticed several issues. The worse one was
> with the networking book: a non-standard footnote there
> with [*] instead of a number
Maya Erez wrote:
> From: Dedy Lansky
>
> wil6210 device needs to use country specific board file while in China
> regulatory domain.
> Register cfg80211 reg_notifier and switch board file if needed
> according to new regulatory domain.
> This
On Fri, May 04, 2018 at 10:43:49AM -0700, Luis R. Rodriguez wrote:
> Greg,
>
> I've reviewed the pending patches for the firmware_laoder and as for
> v4.18, the following 3 patches from Andres have been iterated enough
> that they're ready after I made some final minor changes, mostly just
>
me...@codeaurora.org writes:
> On 2018-04-24 12:47, Kalle Valo wrote:
>> me...@codeaurora.org writes:
>>
>>> On 2018-04-19 19:15, Kalle Valo wrote:
Maya Erez wrote:
> Setting EDMG channel through debugfs for connect and PCP start
> commands.
Why? And
Balaji Pothunoori wrote:
> Average ack rssi value is weighted average of ack rssi for
> no of msdu's has been sent.
> This feature is enabled by the host driver if firmware is capable.
> After receiving event from host, firmware allocates the necessary
> memory to store
Kalle Valo writes:
> Jia-Ju Bai writes:
>
>> The write operation to "sc->next_chan" is protected by
>> the lock on line 1287, but the read operation to
>> this data on line 1262 is not protected by the lock.
>> Thus, there may exist a data race for
On 2018-05-07 02:39, Kenneth Lu wrote:
Variable buf_len and num_vdev_stats are bging assigned but never read.
typo: bging => being
Jia-Ju Bai writes:
> The write operation to "sc->next_chan" is protected by
> the lock on line 1287, but the read operation to
> this data on line 1262 is not protected by the lock.
> Thus, there may exist a data race for "sc->next_chan".
>
> To fix this data race, the
On Tue, 2018-05-08 at 13:57 +0100, Colin King wrote:
> From: Colin Ian King
>
> The multiplication of 10 * cfg80211_calculate_bitrate() is a 32 bit
> operation and can overflow if cfg80211_calculate_bitrate is greater
> than 42949. Although I don't believe this is
From: Colin Ian King
The multiplication of 10 * cfg80211_calculate_bitrate() is a 32 bit
operation and can overflow if cfg80211_calculate_bitrate is greater
than 42949. Although I don't believe this is occurring at present, it
would be safer to avoid the potential
Arend van Spriel writes:
> + Kalle (explicitly)
>
> On 5/8/2018 9:58 AM, Ulf Hansson wrote:
>> On 4 May 2018 at 08:48, Sean Lanigan wrote:
>>> Add support for the BCM43364 chipset via an SDIO interface, as used in
>>> e.g. the Murata 1FX module.
On 5/8/2018 2:19 PM, Johannes Berg wrote:
On Tue, 2018-05-08 at 14:18 +0200, Arend van Spriel wrote:
On 5/7/2018 9:19 PM, Johannes Berg wrote:
On Sun, 2018-04-29 at 20:30 +0200, Andrew Zaborowski wrote:
On 28 April 2018 at 15:07, Kalle Valo wrote:
Andrew Zaborowski
On Tue, 2018-05-08 at 14:18 +0200, Arend van Spriel wrote:
> On 5/7/2018 9:19 PM, Johannes Berg wrote:
> > On Sun, 2018-04-29 at 20:30 +0200, Andrew Zaborowski wrote:
> > > On 28 April 2018 at 15:07, Kalle Valo wrote:
> > > > Andrew Zaborowski
On 5/7/2018 9:19 PM, Johannes Berg wrote:
On Sun, 2018-04-29 at 20:30 +0200, Andrew Zaborowski wrote:
On 28 April 2018 at 15:07, Kalle Valo wrote:
Andrew Zaborowski writes:
Reject NL80211_CMD_DISCONNECT, NL80211_CMD_DISASSOCIATE,
+ Kalle (explicitly)
On 5/8/2018 9:58 AM, Ulf Hansson wrote:
On 4 May 2018 at 08:48, Sean Lanigan wrote:
Add support for the BCM43364 chipset via an SDIO interface, as used in
e.g. the Murata 1FX module.
The BCM43364 uses the same firmware as the BCM43430 (which is already
This patch adds crash dump support for QCA9888 and QCA99X0
Tested On: QCA9888, Firmware Version: 10.4-3.5.3-00053
Tested on QCA99X0, Firmware Version: 10.4.1.00030-1
Signed-off-by: Anilkumar Kolli
---
drivers/net/wireless/ath/ath10k/coredump.c | 98
This adds commands to get and set the per-phy TXQ parameters for drivers
that use the intermediate TXQs. These are the settings and statistics that
are also available through /sys/kernel/debug/ieee80211/phyX/aqm.
Sample output:
$ iw phy phy0 get txq
Packet limit: 8192 pkts
Memory
This adds printing of TXQ statistics for stations and interfaces when
supplied by the kernel. For stations, another section is added when verbose
mode is enabled; for interfaces, the multicast queue information is always
printed when available.
This is the information also available through
This adds support to mac80211 to export TXQ stats via the newly added
cfg80211 API.
Signed-off-by: Toke Høiland-Jørgensen
---
net/mac80211/cfg.c | 99
net/mac80211/ieee80211_i.h |3 +
net/mac80211/main.c|3 +
This adds support for exporting the mac80211 TXQ stats via nl80211 by
way of a nested TXQ stats attribute, as well as for configuring the
quantum and limits that were previously only changeable through debugfs.
This commit adds just the nl80211 API, a subsequent commit adds support to
mac80211
Johannes Berg writes:
> On Tue, 2018-05-08 at 12:18 +0200, Toke Høiland-Jørgensen wrote:
>> Johannes Berg writes:
>>
>> > net/mac80211/cfg.c:3762:12: warning: context imbalance in
>> > 'ieee80211_get_txq_stats' - different lock contexts for
On Mon, 2018-02-19 at 18:02 +0100, Toke Høiland-Jørgensen wrote:
> +static int ieee80211_get_txq_stats(struct wiphy *wiphy,
> + struct wireless_dev *wdev,
> + struct cfg80211_txq_stats *txqstats)
> +{
> + struct
On Tue, 2018-05-08 at 12:18 +0200, Toke Høiland-Jørgensen wrote:
> Johannes Berg writes:
>
> > net/mac80211/cfg.c:3762:12: warning: context imbalance in
> > 'ieee80211_get_txq_stats' - different lock contexts for basic block
>
> Found and fixed all the other warnings,
On Tue, 2018-05-08 at 12:18 +0200, Toke Høiland-Jørgensen wrote:
> Johannes Berg writes:
>
> > net/mac80211/cfg.c:3762:12: warning: context imbalance in
> > 'ieee80211_get_txq_stats' - different lock contexts for basic block
>
> Found and fixed all the other warnings,
Johannes Berg writes:
> net/mac80211/cfg.c:3762:12: warning: context imbalance in
> 'ieee80211_get_txq_stats' - different lock contexts for basic block
Found and fixed all the other warnings, but I'm not seeing this one. And
I don't really see what is wrong with the
Rafał Miłecki writes:
> From: Rafał Miłecki
>
> Used buffer wasn't big enough to hold whole strings. Example output of
> this function is:
> [0.180892] bcma: bus0: core 0x0800, irq: 2(S)* 3 4 5 6 D I
> [0.180948] bcma: bus0: core 0x0812, irq:
From: Rafał Miłecki
Used buffer wasn't big enough to hold whole strings. Example output of
this function is:
[0.180892] bcma: bus0: core 0x0800, irq: 2(S)* 3 4 5 6 D I
[0.180948] bcma: bus0: core 0x0812, irq: 2(S) 3* 4 5 6 D I
[0.180998] bcma: bus0: core
On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 1, 2018 at 10:58 PM, Pkshih wrote:
> > On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
> >>
> >> > -Original Message-
> >> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> >> >
The write operation to "sc->next_chan" is protected by
the lock on line 1287, but the read operation to
this data on line 1262 is not protected by the lock.
Thus, there may exist a data race for "sc->next_chan".
To fix this data race, the read operation to "sc->next_chan"
should be also
On 4 May 2018 at 08:48, Sean Lanigan wrote:
> Add support for the BCM43364 chipset via an SDIO interface, as used in
> e.g. the Murata 1FX module.
>
> The BCM43364 uses the same firmware as the BCM43430 (which is already
> included), the only difference is the omission of
59 matches
Mail list logo