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
On 17/07/17 10:13, James Hughes wrote:
> As someone who is interested in any bug fixes to this driver (Device
> is used on Raspberry Pi3/0W and we have a number of issues reported
> which we are actively investigating), it would be very useful to more
> clearly split out any actual fixes vs simply
Gmail seems to mark your replies as spam :(
On 17 July 2017 at 11:34, Ian Molton wrote:
> On 17/07/17 05:53, Rafał Miłecki wrote:
>> I looked at 4 random patches and none got any description. Not to
>> mention their chaotic subjects. In this state I can't even review it.
>> If you want to have so
I have a laptop which reports the wifi adapter to be an 8265/8275 rev 78
and the driver complains that it can not find:-
iwlwifi-8265-23.ucode
iwlwifi-8265-24.ucode
iwlwifi-8265-25.ucode
iwlwifi-8265-26.ucode
and they not appear to be in the kernel.org github. Where do I find
them and could the
On 16-07-17 13:21, Ian Molton wrote:
> Hi folks,
>
> 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.
Everyone is entitled to his own opinion. While skimming the patches
terms like horrid
Hi,
> Stefan Wahren hat am 28. Juni 2017 um 21:33
> geschrieben:
>
>
> Hi,
>
> i'm currently working on Raspberry Pi Zero W for Mainline. Here is my first
> patch series [1].
>
> Unfortunately i didn't get brcmfmac (connected via SDIO) probed with this
> patch series against 4.12.0-rc5-nex
This reverts commit f95d95a7cd5514549dcf6ba754f0ee834cce3e1f.
With commit f95d95a7cd55 ("rtlwifi: btcoex: rtl8723be: fix ant_sel not
work"), the kernel has a NULL pointer dereference oops. This content and
the proper fix will be included in a later patch.
Fixes: f95d95a7cd55 ("rtlwifi: btcoex: rt
From: Ping-Ke Shih
We must choose only one of VHT_CAP among
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895,
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991 and
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hsuan Chuang
Cc: Birming Chiu
Cc: Shaofu
Cc
From: Ping-Ke Shih
Originally, we get legacy rate only, so we extend to get HT and VHT rate.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hsuan Chuang
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
---
v2 - no changes
---
drivers/net/wireless/realtek/rtlwifi/base.c | 42 ++
From: Ping-Ke Shih
New btcoex uses it to setup antenna before wifi on.
This patch also restores the content of commit f95d95a7cd55 ("rtlwifi:
btcoex: rtl8723be: fix ant_sel not work"), which caused a kernel oops
without this material.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc
To get maximum benefit of the recent changes in btcoexist, changes need
to be made in the drivers for the NIC. This is set 4 of those changes.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hsuan Chuang
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
v2 - Add the material in co
From: Ping-Ke Shih
These definition will be used by phydm later.
Signed-off-by: Ping-Ke Shih
---
v2 - no changes
---
drivers/net/wireless/realtek/rtlwifi/wifi.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h
b/drivers/net/wireless/realtek
From: Ping-Ke Shih
The semicolon can cause compiler error, if it exists in if...else
statement.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hsuan Chuang
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
---
v2 - no changes
---
drivers/net/wireless/realtek/rtlwifi/wifi.h | 6
From: Ping-Ke Shih
1. Both 32-bit and 64-bit use the same TX/RX buffer desc layout
2. Extend set_desc() and get_desc() to set and get 64-bit address
3. Remove directive DMA_IS_64BIT
4. Add module parameter to turn on 64-bit dma
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hs
From: Ping-Ke Shih
- Add new parameter "is_bw_update" to control if current bandwidth setting
is updated to FW RA.
- After this commit, we keep the same setting as before.
- Later, bandwidth update in watchdog is changed to false for 8822BE.
Signed-off-by: Tsang-Shian Lin
Signed-off-by: Larry
From: Ping-Ke Shih
On some platforms, enable ASPM will cause AER error to be logged, thus
we use a parameter to selectively turn on ASPM.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hsuan Chuang
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
---
v2 - no changes
---
driver
From: Ping-Ke Shih
The statistic variables use u64 to get higher precision.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hsuan Chuang
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
---
v2 - no changes
---
drivers/net/wireless/realtek/rtlwifi/base.c | 16
d
From: Ping-Ke Shih
These fields are unused, and we will define them in phydm later.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hsuan Chuang
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
---
v2 - no changes
---
drivers/net/wireless/realtek/rtlwifi/wifi.h | 16 ---
From: Ping-Ke Shih
Convert from the value of ieee80211_tx_queue_params to Realtek's
register value.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hsuan Chuang
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
---
v2 - no changes
---
drivers/net/wireless/realtek/rtlwifi/base.c
On 17/07/17 13:41, Arend van Spriel wrote:
>> * Gets rid of the arbitrary and completely 1:1 mapping of
>> struct brcmf_{core,chip}_priv/struct brcmf_{core,chip} structures
>> which add unreadability whilst offering no real seperation.
> It is maybe 1:1 but it assures that whatever is in the priv
From: Michael Gugino
This patch adds support for USB Device TP-Link TL-WN722N v2.
VendorID: 0x2357, ProductID: 0x010c
Signed-off-by: Michael Gugino
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/dr
From: Michael Gugino
This patch adds support for USB Device TP-Link TL-WN722N v2.
VendorID: 0x2357, ProductID: 0x010c
Signed-off-by: Michael Gugino
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/
Hi,
Here is a respin of my patchset from yesterday. I consider this finished and
have signed it off. It's improved since yesterday, with better names chosen for
a few functions.
It's all clean-up with the exception of the patch titled HACK, which I dont
have enough information to address.
If so
This large function is concealing a LOT of obscure logic about
how the hardware functions. Time to split it up.
This first patch splits the function into two pieces - read and write,
doing away with the rw flag in the process.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm8021
The 4 IO functions in this patch are incorrect as they use compiler types
to determine how many bytes to send to the hardware.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --g
All the other IO functions are the other way round in this
driver. Make this one match.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm8021
Register access code is not the place for band-aid fixes like this.
If this is a genuine problem, it should be fixed further up in the driver
stack.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 26 --
1 file changed, 26 deletions(-)
diff
If you need debugging this low level, you're doing something wrong.
Remove these noisy debug statements so the code is more readable.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/
This function is obfuscating how IO works on this chip. Remove it
and push its logic into brcmf_sdiod_reg_{read,write}().
Handling of -ENOMEDIUM is altered, but as that's pretty much broken anyway
we can ignore that.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.
The value passed to brcmf_sdiod_addrprep() is *always* 4
remove this parameter and the unused code to handle it.
Signed-off-by: Ian Molton
---
.../net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/dr
This function sets the address of the IO window used for
SDIO accesses onto the backplane of the chip.
It currently uses 3 separate masks despite the full mask being
defined in the code already. Remove the separate masks and clean up.
Signed-off-by: Ian Molton
---
drivers/net/wireless/b
Unlikely to be a problem, but brcmf_sdiod_regrb() is
not symmetric with brcmf_sdiod_regrl() in this regard.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/bro
On 17/07/17 13:41, Arend van Spriel wrote:
> For
> instance changing the order of parameters in a function is simply absurd
> although that is my opinion.
If one function has its parameters in a different order to all its
compatriots, I would consider this a highly likely scenario for someone
to m
On 17/07/17 13:41, Arend van Spriel wrote:
> I am sure you have them in mind so don't qualm and just spew them.
Done. See later patchset.
-Ian
On Mon, Jul 17, 2017 at 11:59:35AM -0400, Michael Gugino wrote:
> From: Michael Gugino
>
> This patch adds support for USB Device TP-Link TL-WN722N v2.
> VendorID: 0x2357, ProductID: 0x010c
>
> Signed-off-by: Michael Gugino
> ---
> drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
> 1 file chan
On Mon, Jul 17, 2017 at 12:03:07PM -0400, Michael Gugino wrote:
> From: Michael Gugino
>
> This patch adds support for USB Device TP-Link TL-WN722N v2.
> VendorID: 0x2357, ProductID: 0x010c
>
> Signed-off-by: Michael Gugino
> ---
> drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
> 1 file ch
This function needs to be split up into separate read / write variants
for clarity.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 64 +++---
1 file changed, 45 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm8021
This driver uses the label ctx like its going out of fashion.
Lets rename this usage of it so that its easier to see whats going on.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/chip.c| 24 +++---
.../wireless/broadcom/brcm80211/brcmfmac/chip.h|
Tidy code, fix whitespace, remove useless debug code.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 24 ++
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/ne
Trivial tidy of register definitions.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
b/drivers/net/wireless/broadcom/brc
Create a macro to make the code a bit more readable, whilst we're stuck
with using struct element offsets as register offsets.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 35 +-
1 file changed, 14 insertions(+), 21 deletions(-)
diff --
This #define is poorly named. Correct it.
At the same time, convert the if..elseif...else it is used in to a switch
for clarity.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/
There is no need to repeatdly call brcmf_chip_get_core(), which
traverses a list of cores every time its called (including during
register access code!).
Call it once, and store a pointer to the core structure. The existing
code does nto keep track of users of the cores anyway, and even so, this
w
Primarily this patch removes:
brcmf_sdiod_f0_writeb()
brcmf_sdiod_reg_write()
brcmf_sdiod_reg_read()
Since we no longer use the quirky method of deciding which function to
address via the address being accessed, take the opportunity to rename
some IO functions more in line with common kernel code
These functions are poorly named. for the sake of one character,
correct this.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac
Avoid confusion with unrelated _buscore labels.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/broad
Most of the cor IO functions are called via a spaghetti mess of pointers.
Introduce brcmf_readl(), brcmf_writel(), brcmf_writelp(),
brcmf_clear_bits(), and brcmf_set_bits_post() in an attempt to deal with
this.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/chip.c| 4
Remove yet another IO function from the code and replace with one
that already exists.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 88 +++---
1 file changed, 42 insertions(+), 46 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm8
This function has become trivial enough that it may as well be pushed into
its callers, which has the side-benefit of clarifying what's going on.
Remove it, and rename brcmf_sdiod_set_sbaddr_window() to
brcmf_sdiod_set_backplane_window() as it's easier to understand.
Signed-off-by: Ian Molton
--
We probably need to look up the value in future, but this has to be
better for now.
During my cleanup I uncovered this. The value of ->sbwad is essentially
un-known in several functions, and this will lead to tears should the code
be modified in ways that *should* be OK, but in practice may move t
This macro is used exactly nowhere in the code. Delete it.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/broadcom/brcm80211
All functions that might require the window address changing call
brcmf_sdiod_set_backplane_window() prior to access. Thus resetting
the window is not required.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 5 -
1 file changed, 5 deletions(-)
diff
Trivial cleanup of nasty variable name
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/broadc
There is zero need to keep these structures separate, they are *always*
allocated together. All they do is obfuscate the code, whilst offering
zero real gain.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/chip.c| 384 +
.../wireless/broadcom/brcm8
* Renamed routine in line with kernel convention.
* Improved handling of chips that cannot autoprobe
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/chip.c| 130 +
1 file changed, 84 insertions(+), 46 deletions(-)
diff --git a/drivers/net/wireless/
Improve legibility / conform to kernel coding style.
Signed-off-by: Ian Molton
---
.../wireless/broadcom/brcm80211/brcmfmac/chip.c| 47 ++
1 file changed, 47 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
b/drivers/net/wireless/broadc
Sorry for the spam. I think I have it together now, sent patch to
driverdev-devel list with what appears to be correct subject line. I
appreciate your time and feedback.
Re what changed from v1: Nothing, my first mangled patch added
whitespace. I have submitted new patch to driverdev without vX
On 17/07/17 16:56, Ian Molton wrote:
> The two structures *always* exist together. And yes, preventing access
> to the members that we don't want accessed from the wrong layer would
> be *possibly* worthwhile, however the driver code as it stands
> *constantly* short circuits that with the use of o
Hi Folks,
9fe929aaace6 brcmfmac: add firmware feature detection for gscan feature
Completely breaks 43430a1 support.
This was tested on top of my last patchset - but the same occurs on top
of vanilla 4.13-rc1
[ 15.703014] [1 ] core 0x800:49 base 0x1800 wrap 0x1810
[ 15.703025] [2
Resent due to subject error. Apologies, Hante :)
Hi Folks,
9fe929aaace6 brcmfmac: add firmware feature detection for gscan feature
Completely breaks 43430a1 support.
This was tested on top of my last patchset - but the same occurs on top
of vanilla 4.13-rc1
[ 15.703014] [1 ] core 0x800:49
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
2775 912 03687 e67 realtek/rtlwi
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
1899 928 02827 b0b realtek/rtlwi
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
3032 912 03944 f68 realtek/rtlwi
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
3090 912 04002 fa2 realtek/rtlwi
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
2833 945 123790 ece realtek/rtlwi
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
2491 960 03451 d7b realtek/rtlwi
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
28171040 03857 f11 realtek/rtlwi
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
Arvind Yadav (11):
[PATCH 01/11] rtlwifi: rtl8192de: constify pci_device_id.
[PATCH 02/11] rtlwifi: rtl8192se: const
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 2 +-
1 file changed, 1 insertio
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +-
1 file changed, 1 inse
On 17/07/17 18:50, Ian Molton wrote:
> Resent due to subject error. Apologies, Hante :)
>
> Hi Folks,
>
> 9fe929aaace6 brcmfmac: add firmware feature detection for gscan feature
>
> Completely breaks 43430a1 support.
Digging a bit deeper, this would *appear* to be one of a couple of
possibilit
Hi folks,
I've found that:
270a6c1f65fe brcmfmac: rework headroom check in .start_xmit()
Causes the 43430a1 to become non-responsive. The log starts emitting
these messages:
brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet received,
flags 0x0
brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0:
On 17-07-17 21:03, Ian Molton wrote:
> Hi folks,
>
> I've found that:
>
> 270a6c1f65fe brcmfmac: rework headroom check in .start_xmit()
>
> Causes the 43430a1 to become non-responsive. The log starts emitting
> these messages:
A fix is already pending in patchwork:
https://patchwork.kernel.o
On 17-07-17 20:16, Arvind Yadav wrote:
> pci_device_id are not supposed to change at runtime. All functions
> working with pci_device_id provided by work with
> const pci_device_id. So mark the non-const structs as const.
Acked-by: Arend van Spriel
> Signed-off-by: Arvind Yadav
> ---
> drive
On Mon, Jul 17, 2017 at 6:10 AM, Stefan Wahren wrote:
> Hi,
>
>> Stefan Wahren hat am 28. Juni 2017 um 21:33
>> geschrieben:
>>
>>
>> Hi,
>>
>> i'm currently working on Raspberry Pi Zero W for Mainline. Here is my first
>> patch series [1].
>>
>> Unfortunately i didn't get brcmfmac (connected v
On 17-07-17 20:31, Ian Molton wrote:
> On 17/07/17 18:50, Ian Molton wrote:
>> Resent due to subject error. Apologies, Hante :)
>>
>> Hi Folks,
>>
>> 9fe929aaace6 brcmfmac: add firmware feature detection for gscan feature
>>
>> Completely breaks 43430a1 support.
>
> Digging a bit deeper, this wou
On 17/07/17 20:14, Arend van Spriel wrote:
>
> On 17-07-17 21:03, Ian Molton wrote:
>> Hi folks,
>>
>> I've found that:
>>
>> 270a6c1f65fe brcmfmac: rework headroom check in .start_xmit()
>>
>> Causes the 43430a1 to become non-responsive. The log starts emitting
>> these messages:
>
> A fix is al
On 17-07-17 21:56, Ian Molton wrote:
> On 17/07/17 20:14, Arend van Spriel wrote:
>>
>> On 17-07-17 21:03, Ian Molton wrote:
>>> Hi folks,
>>>
>>> I've found that:
>>>
>>> 270a6c1f65fe brcmfmac: rework headroom check in .start_xmit()
>>>
>>> Causes the 43430a1 to become non-responsive. The log st
On 17/07/17 20:53, Arend van Spriel wrote:
>> 2) The firmware is failing when asked to handle the new requiests, and
>>is going to la-la land.
> taken a wrong turn straight into la-la land.
Doh!
>> I have version wl0: Aug 29 2016 20:48:16 version 7.45.41.26 (r640327)
>> FWID 01-4527cfab
> Not
On 07/17/2017 01:09 PM, Arvind Yadav wrote:
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
Hi,
> Franky Lin hat am 17. Juli 2017 um 21:50
> geschrieben:
>
>
> On Mon, Jul 17, 2017 at 6:10 AM, Stefan Wahren wrote:
> > Hi,
> >
> >> Stefan Wahren hat am 28. Juni 2017 um 21:33
> >> geschrieben:
> >>
> >>
> >> Hi,
> >>
> >> i'm currently working on Raspberry Pi Zero W for Mainline. He
On 17-07-17 22:13, Ian Molton wrote:
> On 17/07/17 20:53, Arend van Spriel wrote:
>>> 2) The firmware is failing when asked to handle the new requiests, and
>>>is going to la-la land.
>> taken a wrong turn straight into la-la land.
>
> Doh!
>
>>> I have version wl0: Aug 29 2016 20:48:16 ver
On 17/07/17 21:36, Arend van Spriel wrote:
> In /brcmfmac/*/forensics, but you have to load the
> driver with modules parameter 'ignore_probe_fail=1' to avoid the driver
> remove tearing down all debugfs stuff.
modinfo shows:
parm: txglomsz:Maximum tx packet chain size [SDIO] (int)
par
On 17-07-17 22:41, Ian Molton wrote:
> On 17/07/17 21:36, Arend van Spriel wrote:
>
>> In /brcmfmac/*/forensics, but you have to load the
>> driver with modules parameter 'ignore_probe_fail=1' to avoid the driver
>> remove tearing down all debugfs stuff.
>
> modinfo shows:
>
> parm:
On 17/07/17 22:31, Arend van Spriel wrote:
>
>
> On 17-07-17 22:41, Ian Molton wrote:
>> On 17/07/17 21:36, Arend van Spriel wrote:
>>
>>> In /brcmfmac/*/forensics, but you have to load the
>>> driver with modules parameter 'ignore_probe_fail=1' to avoid the driver
>>> remove tearing down all deb
Hi Arend,
This is all there is in the forensics file, hope its of some use.
# cat /sys/kernel/debug/brcmfmac/mmc1\:0001\:1/forensics
Enter
hndarm_armr addr: 0x18003000, cr4_idx: 0
00.000
RTE (SDIO-CDC) 7.45.41.26 (r640327) on BCM43430 r1 @ 37.4/81.0/81.0MHz
00.001 sdpcmdcdc0: Broadcom SDP
On 07/11/2017 06:19 PM, Igor Mitsyanko wrote:
> On 07/11/2017 10:28 AM, Andrey Ryabinin wrote:
>>
>> It gave me this:
>>
>> [118648.825347] #1 quota too big 72 64 16
>> [118648.825351] #2 quota too big 72 64 16
>> [118648.825471] [ cut here ]
>> [118648.825484] WARNING: CPU
87 matches
Mail list logo