Lin; Hante Meuleman; Chi-Hsien Lin;
Wright Feng; Pieter-Paul Giesberts; linux-wireless@vger.kernel.org;
brcm80211-dev-list@broadcom.com; brcm80211-dev-l...@cypress.com
Subject: Re: [PATCH] brcmfmac: detect & reject faked packet generated by a
firmware
On 1/31/2018 2:14 PM, Rafał Miłecki w
Molton [mailto:i...@mnementh.co.uk]
Sent: Wednesday, July 19, 2017 12:45 AM
To: Arend van Spriel; linux-wireless@vger.kernel.org
Cc: Franky Lin; brcm80211-dev-l...@broadcom.com; Hante Meuleman
Subject: Re: brcmfmac bus level addressing issues.
On 18/07/17 21:44, Arend van Spriel wrote:
>
>
>
; Hante Meuleman
Subject: RFC: brcmfmac bus level addressing issues.
Hi folks,
Its come to my attention that there is a substantial disparity between the
PCIe and SDIO variants of the driver when it comes to handlign writes via
the backplane.
The SDIO bus code checks, upon every (32 bit) access
rds,
Hante
-Original Message-
From: Rafał Miłecki [mailto:zaj...@gmail.com]
Sent: Thursday, September 15, 2016 10:12 AM
To: Hante Meuleman; Arend van Spriel; brcm80211-dev-l...@broadcom.com
Cc: linux-wireless@vger.kernel.org; Rafał Miłecki
Subject: brcmf_txfinalize misses 802.1x packet leading to infinit
k it is safe to remove waitqueue_active check since there
is only one place to trigger this signal (sending
BRCMF_H2D_HOST_D3_INFORM). And it is not a problem calling wake_up
event earlier than calling wait_event.
Cc: Brett Rudley <brud...@broadcom.com>
Cc: Hante Meuleman <meule...@bro
, 2016 12:44 PM
To: Arend van Spriel
Cc: Kalle Valo; linux-wireless@vger.kernel.org; Brett Rudley; Arend Van Spriel;
Franky (Zhenhui) Lin; Hante Meuleman; brcm80211-dev-list
Subject: Re: [PATCH FIX?] brcmfmac: fix possible overflows in flowrings code by
bumping u8 to u16
On 31 January 2016 at 10:56
-Original Message-
From: carlo.cai...@gmail.com [mailto:carlo.cai...@gmail.com] On Behalf Of Carlo
Caione
Sent: Friday, December 25, 2015 11:16 AM
To: Arend van Spriel
Cc: Carlo Caione; Hante Meuleman; Arend Van Spriel; kv...@codeaurora.org;
linux-wireless@vger.kernel.org
Subject: Re: [BISECTED
not submit this patch, if anything then remove the comment from the
function brcmf_sdio_txpkt.
Regards,
Hante
-Original Message-
From: Nicholas Krause [mailto:xerofo...@gmail.com]
Sent: Monday, October 05, 2015 1:11 AM
To: Brett Rudley
Cc: Arend Van Spriel; Franky (Zhenhui) Lin; Hante Meuleman
Meuleman wrote:
The problem is with data coming from device, so DMA from device to host. The $
However: this indicates that dma_alloc_coherent on an ARM target may result i$
Regards,
Hante
Thanks.
On Fri, Dec 05, 2014 at 12:56:45PM +, Hante Meuleman wrote:
However: this indicates
Thank you for investigating. Your analysis matches what was intended to be
done. Regarding the cast, you're right, I'll improve it. My idea was that long
long is always 64bit, but when casting directly to long long I get a compiler
(when using C=2) warning: warning: right shift by bigger than
The problem is with data coming from device, so DMA from device to host. The
DMA takes place from device local memory to host memory, where the host memory
is allocated with dma_alloc_coherent, which we thought should not be cached.
The host is an ARM (as is the device). The data being DMA'ed
11 matches
Mail list logo
