Ian Molton writes:
> Here's a v4 of the cleanup patchset - checkpatch clean(er - I have purposely
> left some warnings unaddressed).
>
> I also dropped an accidental adjustment of a debug macro from v3.
Like I said already last time, please split the patchset into reasonable
sizes (and submit on
Daniel Stone writes:
> The commit to rework the headroom check in start_xmit() now calls
> pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
> it does so with the delta between the extant headroom and the header
> length, which may be negative if there is already sufficient
Hi,
On 26-07-17 13:24, Daniel Stone wrote:
The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is alr
Hi,
On 26-07-17 23:08, Arend van Spriel wrote:
+ ref
On 26-07-17 23:08, Arend van Spriel wrote:
On 26-07-17 23:03, Hans de Goede wrote:
Hi,
I've been seeing frequent kernel panics on wifi activity
(scp-ing a lot of files) with 4.13 on 2 different systems
which both use a brcmfmac4356-pcie wi
+ ref
On 26-07-17 23:08, Arend van Spriel wrote:
> On 26-07-17 23:03, Hans de Goede wrote:
>> Hi,
>>
>> I've been seeing frequent kernel panics on wifi activity
>> (scp-ing a lot of files) with 4.13 on 2 different systems
>> which both use a brcmfmac4356-pcie wifi chip.
>>
>> This is with this fix
On 26-07-17 23:03, Hans de Goede wrote:
> Hi,
>
> I've been seeing frequent kernel panics on wifi activity
> (scp-ing a lot of files) with 4.13 on 2 different systems
> which both use a brcmfmac4356-pcie wifi chip.
>
> This is with this fix:
> https://www.spinics.net/lists/linux-wireless/msg16417
Hi,
I've been seeing frequent kernel panics on wifi activity
(scp-ing a lot of files) with 4.13 on 2 different systems
which both use a brcmfmac4356-pcie wifi chip.
This is with this fix:
https://www.spinics.net/lists/linux-wireless/msg164178.html
already applied.
Here is a picture of the panic
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
Linux doesnt pass you func0 as a function when probing - instead
providing specific access functions to read/write it.
This prepares for a patch to remove the actual array entry itself.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 5 +
drivers/n
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|
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
Trivial cleanup of nasty variable name
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/broa
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
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
This function needs to be split up into separate read / write variants
for clarity.
Signed-off-by: Ian Molton
# Conflicts:
# drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
---
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 69 +++---
1 file changed, 47 ins
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
#
Avoid confusion with unrelated _buscore labels.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/br
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
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| 91 +++---
1 file changed, 45 insertions(+), 46 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm8
In preparation for removing the function array, remove all code that
refers to function by index and replace with pointers to the function
itself.
Signed-off-by: Ian Molton
# Conflicts:
# drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
---
.../wireless/broadcom/brcm80211/brcmfma
Rather than workaround the restrictions on func0 addressing in the
driver, set MMC_QUIRK_LENIENT_FN0
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h | 4 ++--
2 files changed, 6 insertions
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
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| 383 +
.../wireless/broadcom/brcm8
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/
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 --
* 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| 132 +
1 file changed, 84 insertions(+), 48 deletions(-)
diff --git a/drivers/net/wireless/
The IO functions operate within the Chipcommon IO window. Explicitly
set this, rather than relying on the last initialisation IO access to
leave it set to the right value by chance.
Signed-off-by: Ian Molton
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8
drivers/net/
This introduces no functional changes, but makes the code drastically more
readable, reducing the amount of dereferencing performed inside functions
throughout the SDIO core.
For example, reduce:
sdio_release_host(bus->sdiodev->func1);
to:
sdio_release_host(func1);
Fixup a few inc
Replace the array of functions with a pair of pointers to the
relevant functions.
Signed-off-by: Ian Molton
# Conflicts:
# drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
# drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
---
.../wireless/broadcom/brcm80211/brcmfma
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
Most of the core IO functions are called via a long train of pointers.
Introduce brcmf_readl(), brcmf_writel(), brcmf_writelp(),
brcmf_clear_bits(), and brcmf_set_bits_post() in an attempt to deal with
this.
These brcmf_writelp() and brcmf_set_bits_post() issue posted writes.
Signed-off-by: Ian
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
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
# Conflicts:
# drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
---
.../wireless/broadcom/brcm80211/brcmf
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
# Conflicts:
# drive
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
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
# Conflicts:
# drivers/net/wireless/broadcom/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
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 | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80
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
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/
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
Hi folks,
Here's a v4 of the cleanup patchset - checkpatch clean(er - I have purposely
left some warnings unaddressed).
I also dropped an accidental adjustment of a debug macro from v3.
-Ian
On Wednesday, July 26, 2017 01:03:03 PM Andy Shevchenko wrote:
> On Wed, 2017-07-26 at 02:27 +0200, Rafael J. Wysocki wrote:
> > On Wednesday, July 26, 2017 03:35:01 AM Andy Shevchenko wrote:
> > > On Wed, Jul 26, 2017 at 3:21 AM, Rafael J. Wysocki > > t> wrote:
>
> > > > Andy, do you want me to
Loan Offer at 3%, Feel Free to REPLY back to us for more info.
Arend van Spriel writes:
> Due to a bugfix in wireless tree and the commit mentioned below a merge
> was needed which went haywire. So the submitted change resulted in the
> function brcmf_sdiod_sgtable_alloc() being called twice during the probe
> thus leaking the memory of the first call.
>
> C
On Wednesday, 26. July 2017, 13:49:51 CEST you wrote:
> So if possible please do:
>
> $ insmod brcmfmac debug=0xd416
You'll find the log attached to the bugzilla report:
https://bugzilla.kernel.org/show_bug.cgi?id=193121#c8
If there's anything else I can provide to get to the ground of this issu
Due to a bugfix in wireless tree and the commit mentioned below a merge
was needed which went haywire. So the submitted change resulted in the
function brcmf_sdiod_sgtable_alloc() being called twice during the probe
thus leaking the memory of the first call.
Cc: sta...@vger.kernel.org # 4.6.x
Fixe
On 7/25/2017 8:07 AM, Daniel Roschka wrote:
Hi,
All Apple MacBook Pro models with Touch Bar contain a BCM43602 Wi-Fi chip.
This chip isn't working properly. While it is properly detected by brcmfmac
and even shows wifi networks nearby, connections only succeed when being very,
very close to the
The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is already sufficient headroom.
pskb_expand_head()
On 7/26/2017 1:03 PM, Daniel Stone wrote:
The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is alrea
The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is already sufficient headroom.
pskb_expand_head()
On 24/07/17 20:47, Arend van Spriel wrote:
> On 19-07-17 21:07, Ian Molton wrote:
>> Hi all,
>>
>> Please find the 3rd revision of my cleanup patchset for brcmfmac.
>>
>> I've done some further cleanup and it now handles SDIO the ay the MMC
>> subsystem
>> was designed to.
>>
>> I've also taken th
On Wed, 2017-07-26 at 02:27 +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 26, 2017 03:35:01 AM Andy Shevchenko wrote:
> > On Wed, Jul 26, 2017 at 3:21 AM, Rafael J. Wysocki > t> wrote:
> > > Andy, do you want me to apply this?
> >
> > If you would like to.
> >
> > The patch is now pretty
On Wed, 2017-07-19 at 21:28 +0300, Andy Shevchenko wrote:
> There are new types and helpers that are supposed to be used in new
> code.
>
> As a preparation to get rid of legacy types and API functions do
> the conversion here.
>
> While here, re-indent couple of lines to increase readability.
T
On 7/26/2017 10:49 AM, Daniel Stone wrote:
The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is alre
On 7/26/2017 8:19 AM, Stefan Wahren wrote:
Hi,
Stefan Wahren hat am 17. Juli 2017 um 22:31
geschrieben:
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:
H
The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is already sufficient headroom.
pskb_expand_head()
The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is already sufficient headroom.
pskb_expand_head()
On 26 July 2017 at 08:52, Christoph Hellwig wrote:
> On Tue, Jul 25, 2017 at 01:40:06PM +0300, Andy Shevchenko wrote:
>> Christoph, can we apply this one at least to move things forward?
>
> Id be happy to pick this up for 4.14. Does everyone involved agree
> that the uuid tree is the right one?
On 7/26/2017 8:12 AM, Stefan Wahren wrote:
Hi Arend,
Stefan Wahren hat am 23. Juli 2017 um 02:24
geschrieben:
Arend van Spriel hat am 22. Juli 2017 um 21:40
geschrieben:
On 22-07-17 15:18, Stefan Wahren wrote:
Hi,
with enabled memleak detector on 4.13-rc1 (Raspberry Pi Zero W) i get
On Tue, Jul 25, 2017 at 01:40:06PM +0300, Andy Shevchenko wrote:
> Christoph, can we apply this one at least to move things forward?
Id be happy to pick this up for 4.14. Does everyone involved agree
that the uuid tree is the right one?
61 matches
Mail list logo