On 20 April 2017 at 12:31, Kalle Valo wrote:
> + linux-wireless
>
> James Hughes writes:
>
>> The driver was adding header information to incoming skb
>> without ensuring the head was uncloned and hence writable.
>>
>> skb_cow_head has been used to ensure
buffer.
Signed-off-by: James Hughes
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
On 20 April 2017 at 20:48, Arend van Spriel
wrote:
> + linux-wireless
>
> On 4/20/2017 1:16 PM, James Hughes wrote:
>>
>> The driver was adding header information to incoming skb
>> without ensuring the head was uncloned and hence writable.
>>
>> skb_co
On 23 April 2017 at 20:34, Arend Van Spriel
wrote:
> On 21-4-2017 11:22, James Hughes wrote:
>> On 20 April 2017 at 20:48, Arend van Spriel
>> wrote:
>>> + linux-wireless
>>>
>>> On 4/20/2017 1:16 PM, James Hughes wrote:
>>>>
>>
The incoming skb header may be resized if header space is
insufficient, which might change the data adddress in the skb.
Ensure that a cached pointer to that data is correctly set by
moving assignment to after any possible changes.
Signed-off-by: James Hughes
---
drivers/net/wireless/broadcom
The incoming skb header may be resized if header space is
insufficient, which might change the data adddress in the skb.
Ensure that a cached pointer to that data is correctly set by
moving assignment to after any possible changes.
Signed-off-by: James Hughes
Acked-by: Arend van Spriel
: Ensure pointer correctly set if skb data location changes
Signed-off-by: James Hughes
---
Changes in v2
Makes the _cow_ call at the entry point of the skb in to the
stack, means only needs to be done once, and error handling
is easier.
Split a separate minor bug fix off to a separate patch
On 20 April 2017 at 20:22, Arend van Spriel
wrote:
> On 4/20/2017 5:47 PM, James Hughes wrote:
>>
>> Driver was writing to skb header area without ensuring it was
>> writable i.e. uncloned.
>>
>> Used skb_cow_header to ensure that header buffer is large enough
&
.
This patch depends on
brcmfmac: Ensure pointer correctly set if skb data location changes
Signed-off-by: James Hughes
Acked-by: Arend van Spriel
---
Changes in v2
Makes the _cow_ call at the entry point of the skb in to the
stack, means only needs to be done once, and error handling
On 25 April 2017 at 10:10, Arend van Spriel
wrote:
> An issue was found brcmfmac driver in which a skbuff in .start_xmit()
> callback was actually cloned. So instead of checking for sufficient
> headroom it should also be writable. Hence use skb_cow_head() to
> check and expand the headroom approp
On 25 April 2017 at 12:10, Arend Van Spriel
wrote:
> On 25-4-2017 11:36, James Hughes wrote:
>> On 25 April 2017 at 10:10, Arend van Spriel
>> wrote:
>>> An issue was found brcmfmac driver in which a skbuff in .start_xmit()
>>> callback was actually cloned. So i
On 26 April 2017 at 19:03, Arend Van Spriel
wrote:
>
>
> On 26-4-2017 17:44, Steve deRosier wrote:
>> On Wed, Apr 26, 2017 at 1:53 AM, Kalle Valo wrote:
>>> Arend Van Spriel wrote:
An issue was found brcmfmac driver in which a skbuff in .start_xmit()
callback was actually cloned. So in
On 27 April 2017 at 05:55, Steve deRosier wrote:
> On Wed, Apr 26, 2017 at 12:54 PM, James Hughes
> wrote:
>> On 26 April 2017 at 19:03, Arend Van Spriel
>> wrote:
>>>
>>>
>>> On 26-4-2017 17:44, Steve deRosier wrote:
>>>> On Wed, Ap
I going to
have to stick with the driver we are currently using which clearly has
a lockup issue that I, in all likelihood, not going to be able to
track down since its takes days for it to occur.
Or if anyone has any suggestions for getting this working, I'm all ears.
TIA
James Hughes, Raspberry Pi.
On 14 May 2018 at 10:52, Stefan Wahren wrote:
> Hi Arend,
>
> Am 14.05.2018 um 10:15 schrieb Arend van Spriel:
>>
>> On 5/2/2018 8:05 PM, Stefan Wahren wrote:
>>>
>>> Hi,
>>> i wanted to know, if there are any plans to update the Broadcom/Cypress
>>> firmware under:
>>>
>>>
>>> https://git.kernel.
On Wed, 28 Nov 2018 at 20:14, Stefan Wahren wrote:
>
> Hi,
>
> > Stefan Wahren hat am 26. November 2018 um 19:14
> > geschrieben:
> >
> >
> > Hi Arend,
> >
> > > Arend van Spriel hat am 26. November 2018
> > > um 11:11 geschrieben:
> > >
> > > So no AP listed here. I suspect Rafał was focusing
On Thu, 3 Jan 2019 at 07:46, Chi-Hsien Lin wrote:
>
> From: Lo-Hsiang Lo
>
> There is a system warning message, warn_slowpath-fmt, during suspend
> while using supplicant join AP and enable wowl feature by IW command.
> It's cuased by brcmf_pno_remove_request path can't find the reqid.
> This fix
; This is on wireless-drivers-next so maybe it is already fixed, but I
> think this should be fixed.
>
> Regards,
> Arend
--
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd
On 25 September 2017 at 09:18, Kalle Valo wrote:
> Arend Van Spriel wrote:
>
>> The firmware uses a mailbox to communicate to the host what is going
>> on. In the driver we validate the bit received. Various people seen
>> the following message:
>>
>> brcmfmac: brcmf_sdio_hostmail: Unknown mailb
On 25 September 2017 at 10:26, James Hughes
wrote:
> On 25 September 2017 at 09:18, Kalle Valo wrote:
>> Arend Van Spriel wrote:
>>
>>> The firmware uses a mailbox to communicate to the host what is going
>>> on. In the driver we validate the bit received. Vari
On 26 September 2017 at 12:11, Arend van Spriel
wrote:
> On 25-09-17 11:30, James Hughes wrote:
>>
>> On 25 September 2017 at 10:26, James Hughes
>> wrote:
>>>
>>> On 25 September 2017 at 09:18, Kalle Valo wrote:
>>>>
>>>> Are
do appear
to be using the latest firmware file.
I'm not sure how to proceed on this one. It would be interesting to
know under what circumstances that value can be returned from the
mailbox.
More details can be found at the end of this github issue.
https://github.com/raspberrypi/linux/issues/1342
James Hughes
Raspberry Pi
On 24 May 2017 at 14:13, Arend van Spriel wrote:
> On 24-05-17 14:50, James Hughes wrote:
>> We are seeing an issue on Raspberry Pi which uses the bcm43430 chip. It's
>> been tested up to 4.9 which still shows the issue (it's been there for some
>> time, > 1yr).
On 24 May 2017 at 14:16, James Hughes wrote:
> On 24 May 2017 at 14:13, Arend van Spriel
> wrote:
>> On 24-05-17 14:50, James Hughes wrote:
>>> We are seeing an issue on Raspberry Pi which uses the bcm43430 chip. It's
>>> been tested up to 4.9 which still s
On 24 May 2017 at 16:14, James Hughes wrote:
> On 24 May 2017 at 14:16, James Hughes wrote:
>> On 24 May 2017 at 14:13, Arend van Spriel
>> wrote:
>>> On 24-05-17 14:50, James Hughes wrote:
>>>> We are seeing an issue on Raspberry Pi which uses the bcm434
On 17 July 2017 at 05:53, Rafał Miłecki wrote:
> On 16 July 2017 at 13:21, Ian Molton wrote:
>> I've been doing some cleanups in the broadcome brcmfmac driver, trying to
>> understand how it works.
>>
>> I think this makes the driver a *lot* more readable.
>>
>> Of note:
>>
>> * Gets rid of the a
>>
>
> Can you please try to comment out the following lines in
> brcmf_feat_attach? That's the only suspicious line that interact with
> firmware in the patch.
>
> + brcmf_feat_iovar_data_set(ifp, BRCMF_FEAT_GSCAN, "pfn_gscan_cfg",
> +&gscan_cfg, sizeof(
On 22 July 2017 at 20:53, Arend van Spriel wrote:
> On 22-07-17 21:19, Ian Molton wrote:
>> On 22/07/17 20:18, Ian Molton wrote:
>>> On 22/07/17 19:43, Hans de Goede wrote:
Hi,
When upgrading my devel environment to 4.13-rc1+ I noticed that
the brcm43430 sdio wifi on a Chuwi Hi
On 23 July 2017 at 08:08, Hans de Goede wrote:
> Hi,
>
> On 22-07-17 21:53, Arend van Spriel wrote:
>>
>> On 22-07-17 21:19, Ian Molton wrote:
>>>
>>> On 22/07/17 20:18, Ian Molton wrote:
On 22/07/17 19:43, Hans de Goede wrote:
>
> Hi,
>
> When upgrading my devel environm
29 matches
Mail list logo
