linux-stable.git/drivers/net/wireless/broadcom, branch v5.1.5

brcmfmac: Add DMI nvram filename quirk for ACEPC T8 and T11 mini PCs

2019-05-25T16:16:26+00:00

commit b1a0ba8f772d7a6dcb5aa3e856f5bd8274989ebe upstream.

The ACEPC T8 and T11 mini PCs contain quite generic names in the sys_vendor
and product_name DMI strings, without this patch brcmfmac will try to load:
"brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which
is way too generic.

The DMI strings on which we are matching are somewhat generic too, but
"To be filled by O.E.M." is less common then "Default string" and the
system-sku and bios-version strings are pretty unique. Beside the DMI
strings we also check the wifi-module chip-id and revision. I'm confident
that the combination of all this is unique.

Both the T8 and T11 use the same wifi-module, this commit adds DMI
quirks for both mini PCs pointing to brcmfmac43455-sdio.acepc-t8.txt .

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: print firmware reported general status errors

2019-02-28T08:27:59+00:00

Firmware may report general errors using a special message type. Add
basic support for it by simply decoding & printing an error number.

A sample situation in which firmware reports a buf error:
CONSOLE: 027084.733 no host response IOCTL buffer available..so fail the request
will now produce a "Firmware reported general error: 9" on the host.

Signed-off-by: Rafał Miłecki 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo

brcmfmac: fix size of the struct msgbuf_ring_status

2019-02-28T08:27:58+00:00

This updates host struct to match the in-firmawre definition. It's a
cosmetic change as it only applies to the reserved struct space.

Fixes: c988b78244df ("brcmfmac: print firmware reported ring status errors")
Signed-off-by: Rafał Miłecki 
Signed-off-by: Kalle Valo

brcmfmac: add basic validation of shared RAM address

2019-02-20T17:55:22+00:00

While experimenting with firmware loading I ended up in a state of
firmware reporting shared RAM address 0x04000001. It was causing:
[   94.448015] Unable to handle kernel paging request at virtual address cd680001
due to reading out of the mapped memory.

This patch adds some basic validation to avoid kernel crashes due to the
unexpected firmware behavior.

Signed-off-by: Rafał Miłecki 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo

brcmfmac: use bphy_err() in all wiphy-related code

2019-02-20T17:54:17+00:00

This recently added macro provides more meaningful error messages thanks
to identifying a specific wiphy. It's especially important on systems
with few cards supported by the same (brcmfmac) driver.

Signed-off-by: Rafał Miłecki 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo

brcmfmac: remove set but not used variable 'old_state'

2019-02-19T15:07:40+00:00

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 'brcmf_usb_state_change':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:578:6: warning:
 variable 'old_state' set but not used [-Wunused-but-set-variable]

It's never used and can be removed.

Signed-off-by: YueHaibing 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo

brcmfmac: rework bphy_err() to take struct brcmf_pub argument

2019-02-19T15:07:13+00:00

This macro will be used in more places not just the cfg80211.c. It makes
sense to pass some common struct to it as "struct wiphy" is mostly
referenced in cfg80211 code only.

A very common one (used above the bus abstraction layer) is struct
brcmf_pub. Many functions already keep reference to it which will make
using bphy_err() simpler. It should also allow extending that macro's
logic if it's ever needed.

This improves code recently added in the commit 3ef005b82e2a ("brcmfmac:
add bphy_err() and use it in the cfg80211.c").

Signed-off-by: Rafał Miłecki 
Signed-off-by: Kalle Valo

brcmfmac: support firmware reporting 160 MHz channels

2019-02-19T15:06:36+00:00

So far 160 MHz channels were treated as 20 MHz ones which was breaking
support for 40/80 MHz due to the brcmf_construct_chaninfo() logic and
its assumptions.

Signed-off-by: Rafał Miłecki 
Signed-off-by: Kalle Valo

brcmfmac: improve code handling bandwidth of firmware reported channels

2019-02-19T15:06:36+00:00

1) Use switch to simplify/improve the code & avoid some duplication
2) Add warning for unsupported values

Signed-off-by: Rafał Miłecki 
Signed-off-by: Kalle Valo

brcmfmac: print firmware reported ring status errors

2019-02-19T15:06:04+00:00

Firmware is capable of reporting ring status. It's used e.g. to signal
some problem with a specific ring setup. This patch adds support for
printing ring & error number which may be useful for debugging setup
issues.

Signed-off-by: Rafał Miłecki 
Signed-off-by: Kalle Valo