In rx path the firmware provide an interface index which is used to
map to a struct brcmf_if instance. However, this involves some trick
that is done in two places. This is changed by having driver core
providing brcmf_get_ifp() function.
Reviewed-by: Hante Meuleman meule...@broadcom.com
Just pass the interface to be removed, ie. the struct brcmf_if instance.
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
In brcmf_bus_start() the function brcmf_cfg80211_attach() is called which
may fail. If this happens we should not call brcmf_cfg80211_detach() in
the failure path as it will result in NULL pointer dereference:
brcmf_fweh_activate_events: Set event_msgs error (-5)
brcmf_bus_start: failed: -5
The p2pdev interface is setup in firmware resulting in a interface
event. This event has role and no-if flag. When role is p2p client
and no-if flag is set it indicates that this is the p2pdev interface.
This info is used in handling the event and adding interface in the
driver.
Reviewed-by:
Most call sites of brcmf_txfinalize already have struct brcmf_if
instance so pass that to brcmf_txfinalize() as the function
needs it anyway.
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts
Both PCIe and SDIO devices have the possibility to log the firmware
console output in kernel log. For PCIe it is logged when PCIE debug
level is enabled. For SDIO it is logged when user specifies a non-zero
console interval through debugfs. This patch tries to make it a
bit more consistent. The
This patch series contains the following:
* rework code dealing with multiple interfaces.
* allow logging firmware console using debug level.
* fix crash in error path when probe fails.
* fix memory leak in free net devices.
* minor code cleanup.
The patch series is intended for v4.3 and applies
The brcmf_fws_txstatus_suppressed() function prototype specifies an
ifidx parameter which is not used within the function implementation.
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts
Because the P2P Device interface in firmware uses the same interface
index as the primary interface we use the bsscfg index as index in the
struct brcmf_pub::iflist. However, in the data path we get the interface
index and not the bsscfg index. So we need a mapping of interface index
to bsscfg
Avoid spreading the ifidx in the driver, but have it return the
struct brcmf_if instance.
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Signed-off-by: Arend van Spriel
Instead of passing ifidx and drvr just pass struct brcmf_if pointer
which holds both parameters.
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Signed-off-by: Arend van Spriel
The knowledge on how to map the interface index to a struct brcmf_if
instance is in brcmf_get_ifp() so use that function when only the
interface index is known instead of accessing brcmf_pub::iflist
directly.
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin
On Mon, Mar 30, 2015 at 5:14 PM, Emmanuel Grumbach
emmanuel.grumb...@intel.com wrote:
This patch series add supports for a new WiFi feature called
Neighbor Awareness Networking a.k.a. NAN.
Quite a few people contacted me on that matter. Several contacted me
privately, others through IRC.
I am
On 26 August 2015 at 22:14, Arend van Spriel ar...@broadcom.com wrote:
This patch series contains the following:
* rework code dealing with multiple interfaces.
* allow logging firmware console using debug level.
* fix crash in error path when probe fails.
* fix memory leak in free net
In case of error during brcmf_bus_start() the network interfaces were
freed using free_netdev(). However, the interfaces may have additional
memory allocated which is not freed. The netdev has destructor set to
brcmf_cfg80211_free_netdev() which frees the additional memory if
allocated and call
Michal Kazior michal.kaz...@tieto.com writes:
This cleans up the naming a little bit. Both
QCA6174 and QCA6164 are in practice the same as
far as driving them is concerned.
Unfortunately firmware paths will need to stay
untouched, i.e. QCA6164 firmware will still be
looked for in QCA6174
Michal Kazior michal.kaz...@tieto.com writes:
The function returns 1 when DMA mapping fails. The
driver would return bogus values and could
possibly confuse itself if DMA failed.
Fixes: 767d34fc67af (ath10k: remove DMA mapping wrappers)
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Arnd Bergmann a...@arndb.de writes:
On Tuesday 25 August 2015 15:47:45 Arnd Bergmann wrote:
On Tuesday 25 August 2015 15:09:45 Michal Kazior wrote:
This is some weird regression with MSI ranges and we still haven't
figured this out.
For the time being add irq_mode=1 parameter when
Raja Mani rm...@qti.qualcomm.com writes:
To enable/configure spectral scan parameters in 10.4 firmware, existing
wmi spectral related functions can be reused. Link those functions in
10.4 wmi ops table.
In addition, adjust bin size (only when size is 68 bytes) before reporting
bin samples
Michal Kazior michal.kaz...@tieto.com writes:
Kernel would complain about leaving a held lock
after going back to userspace and would
subsequently deadlock.
Fixes: e04cafbc38c7 (ath10k: fix peer limit enforcement)
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Michal
Michal Kazior michal.kaz...@tieto.com writes:
This adds additional 0x0041 PCI Device ID
definition to ath10k for QCA6164 which is a 1
spatial stream sibling of the QCA6174 (which is 2
spatial stream chip).
The QCA6164 needs a dedicated board.bin file which
is different than the one used
Raja Mani rm...@qti.qualcomm.com writes:
Below compilation warnings are observed in gcc version 4.8.2.
Even though it's not seen in bit older gcc versions (for ex, 4.7.3),
It's good to fix it by changing format specifier from %d to
%zd in wmi pull phyerr functions.
wmi.c: In function
From: Thierry Reding tred...@nvidia.com
The rate_control_cap_mask() function takes a parameter mcs_mask, which
GCC will take to be u8 * even though it was declared with a fixed size.
This causes the following warning:
net/mac80211/rate.c: In function 'rate_control_cap_mask':
Hi Dave,
here's one more smaller pull request I would like to still get to 4.3.
Nothing really special expect the new firmware API 17 support for
iwlwifi and qca6164 support for ath10k which would be good to have in
4.3.
Please let me know if you have any problems.
Kalle
The following changes
On 08/26/2015 12:22 PM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
The rate_control_cap_mask() function takes a parameter mcs_mask, which
GCC will take to be u8 * even though it was declared with a fixed size.
This causes the following warning:
net/mac80211/rate.c:
On 08/26/2015 10:23 PM, Arend van Spriel wrote:
On 08/26/2015 12:22 PM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
The rate_control_cap_mask() function takes a parameter mcs_mask, which
GCC will take to be u8 * even though it was declared with a fixed size.
This causes the
On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
Luis R. Rodriguez mcg...@suse.com wrote:
But note, we also have kexec_file_load() syscall and an arch specific
signature verification feature, arch_kexec_kernel_verify_sig().
Sad trombone, no LSM hook and only x86 supports
Hi,
Does anybody have patches for CT firmware testing using OpenWRT environment.
I tried to create patch, however OpenWRT patches supporting only for
kernel versions 3.18 and 4.1 at the same time CT Kernels supporting
3.17_dev, 4.0.4 and 4.2.x. Both are miss matching.
Can somebody help me if
On Wed, Aug 26, 2015 at 7:26 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
Now let's review the SELinux stuff before we jump back into firmware / system
data stuff again as there is a joint criteria to consider for all of these.
For
29 matches
Mail list logo
