linux.git/drivers/net/wireless/ti, branch v4.18

wlcore: sdio: check for valid platform device data before suspend

2018-05-29T07:20:56+00:00

the wl pointer can be null In case only wlcore_sdio is probed while
no WiLink module is successfully probed, as in the case of mounting a
wl12xx module while using a device tree file configured with wl18xx
related settings.
In this case the system was crashing in wl1271_suspend() as platform
device data is not set.
Make sure wl the pointer is valid before using it.

Signed-off-by: Eyal Reizer 
Signed-off-by: Kalle Valo

wlcore: sdio: Fix flakey SDIO runtime PM handling

2018-05-29T07:14:45+00:00

We can have pm_runtime_get_sync() return 1, and we can have
pm_runtime_put_sync() return -EBUSY. See rpm_suspend() and
rpm_resume() for more information.

Fix the issue by returning 0 from wl12xx_sdio_power_on() on success.
And use pm_runtime_put() instead of pm_runtime_put_sync() for
wl12xx_sdio_power_off(), then the MMC subsystem will idle the bus
when suitable.

Otherwise wlcore can sometimes get confused and may report bogus
errors and WLAN connection can fail.

Note that while wlcore checks the return value for wl1271_power_on(),
the return value is ignored for wl1271_power_off(). Let's fix them
both though to avoid further confusion in the future.

Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Signed-off-by: Tony Lindgren 
Signed-off-by: Kalle Valo

wlcore: sdio: allow pm to handle sdio power

2018-04-30T10:30:42+00:00

pm_runtime handles sdio power on and power off transitions.
An old workaround for trying to control the power explicitly from the
driver was in fact causing failures on suspend/resume as the mmc layer
already power the module on resume.

In case of resume pm_runtime_get sync returns a positive device's usage
count causing the driver to try an re-initialize an already initialized
device. This was causing sdio bus failure on resume.

Remove this manual power on/off sequence as it is in-fact not needed.

Signed-off-by: Eyal Reizer 
Acked-by: Tony Lindgren 
Signed-off-by: Kalle Valo

wireless: Use octal not symbolic permissions

2018-03-27T08:01:13+00:00

Prefer the direct use of octal for permissions.

Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace
and some typing.

Miscellanea:

o Whitespace neatening around these conversions.

Signed-off-by: Joe Perches 
Signed-off-by: Kalle Valo

Merge tag 'wireless-drivers-next-for-davem-2018-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next

2018-03-26T01:27:38+00:00

Kalle Valo says:

====================
wireless-drivers-next patches for 4.17

The biggest changes are the bluetooth related patches to the rsi
driver. It adds a new bluetooth driver which communicates directly
with the wireless driver and the interface is defined in
include/net/rsi_91x.h.

Major changes:

wl1251

* read the MAC address from the NVS file

rtlwifi

* enable mac80211 fast-tx support

mt76

* add capability to select tx/rx antennas

mt7601

* let mac80211 validate rx CCMP Packet Number (PN)

rsi

* bluetooth: add new btrsi driver

* btcoex support with the new btrsi driver
====================

Signed-off-by: David S. Miller

net: drivers/net: Remove unnecessary skb_copy_expand OOM messages

2018-03-15T18:28:03+00:00

skb_copy_expand without __GFP_NOWARN already does a dump_stack
on OOM so these messages are redundant.

Signed-off-by: Joe Perches 
Signed-off-by: David S. Miller

net/wireless: fix spaces and grammar copy/paste in vendor Kconfig help text

2018-03-13T16:52:25+00:00

Lots of the wireless driver vendor Kconfig symol help text says
"questions about  cards." (2 spaces between "about" and "cards")

Besides dropping one of those spaces, it also needs some other word
inserted there. Instead of putting each vendor's name there, I chose
to say "these" cards in all of the Kconfig help text.

Cc: Kalle Valo 
Signed-off-by: Randy Dunlap 
Signed-off-by: Kalle Valo

wl1251: Set generated MAC address back to NVS data

2018-02-27T13:50:44+00:00

In case there is no valid MAC address kernel generates random one. This
patch propagate this generated MAC address back to NVS data which will be
uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
uses.

This should not change any functionality, but it is better to tell wl1251
correct mac address since beginning of chip usage.

Signed-off-by: Pali Rohár 
Signed-off-by: Kalle Valo

wl1251: Parse and use MAC address from supplied NVS data

2018-02-27T13:50:43+00:00

This patch implements parsing MAC address from NVS data which are sent to
wl1251 chip. Calibration NVS data could contain valid MAC address and it
will be used instead of randomly generated one.

This patch also moves code for requesting NVS data from userspace to driver
initialization code to make sure that NVS data will be there at time when
permanent MAC address is needed.

Calibration NVS data for wl1251 are device specific. Every device with
wl1251 chip should have been calibrated in factory and needs to provide own
calibration data.

Default example file wl1251-nvs.bin, found in linux-firmware repository,
contains MAC address 00:00:20:07:03:09. So this MAC address is marked as
invalid as it is not real device specific address, just example one.

Format of calibration NVS data can be found at:
http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt

Signed-off-by: Pali Rohár 
Signed-off-by: Kalle Valo

wl1251: Generate random MAC address only if driver does not have valid

2018-02-27T13:50:43+00:00

Before this patch, driver generated random MAC address every time it was
initialized. After that random MAC address could be overwritten with fixed
one, if provided.

This patch changes order. First it tries to read fixed MAC address and if
it fails then driver generates random MAC address.

Signed-off-by: Pali Rohár 
Acked-by: Pavel Machek 
Signed-off-by: Kalle Valo