- 16 Jun, 2016 12 commits
-
-
Rafał Miłecki authored
There are two firmware events we handle similarly in brcmfmac: BRCMF_E_LINK and BRCMF_E_IF. The difference from firmware point of view is that the first one means BSS remains present in the firmware. Trying to (re)create it (e.g. when adding new virtual interface) will result in an error. Current code treats both events in a similar way. It removes Linux interface for each of them. It works OK with e.g. BCM43602. Its firmware generates both events for each interface. It means we get BRCMF_E_LINK and remove interface. That is soon followed by BRCMF_E_IF which means BSS was also removed in a firmware. The only downside of this is a harmless error like: [ 208.643180] brcmfmac: brcmf_fweh_call_event_handler: no interface object Unfortunately BCM4366 firmware doesn't automatically remove BSS and so it doesn't generate BRCMF_E_IF. In such case we incorrectly remove Linux interface on BRCMF_E_LINK as BSS is still present in the firmware. It results in an error when trying to re-create virtual interface, e.g.: > iw phy phy1 interface add wlan1-1 type __ap [ 3602.929199] brcmfmac: brcmf_ap_add_vif: timeout occurred command failed: I/O error (-5) With this patch we don't remove Linux interface while firmware keeps BSS. Thanks to this we keep a consistent states of host driver and device firmware. Further improvement should be to mark BSS as disabled and remove interface on BRCMF_E_LINK. Then we should add support for reusing BSS-es. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Rafał Miłecki authored
Firmware for new chipsets is based on a new major version of code internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was based on 7.35.177.56. Currently setting AP 5 GHz channel doesn't work reliably with BCM4366B1. When setting e.g. 36 control channel with VHT80 (center channel 42) firmware may randomly pick one of: 1) 52 control channel with 58 as center one 2) 100 control channel with 106 as center one 3) 116 control channel with 122 as center one 4) 149 control channel with 155 as center one It seems new firmwares require setting AP mode (BRCMF_C_SET_AP) before specifying a channel. Changing an order of firmware calls fixes the problem. This requirement resulted in two separated "chanspec" calls, one in AP code path and one in P2P path. This fix was verified with BCM4366B1 and tested for regressions on BCM43602. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Arnd Bergmann authored
gcc-6 on x86 started warning about wl3501_get_encode when building with -O2: drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_get_encode’: drivers/net/wireless/wl3501_cs.c:1769:5: warning: ‘implemented’ may be used uninitialized in this function drivers/net/wireless/wl3501_cs.c:1686:19: warning: ‘threshold’ may be used uninitialized in this function drivers/net/wireless/wl3501_cs.c:1702:20: warning: ‘threshold’ may be used uninitialized in this function drivers/net/wireless/wl3501_cs.c:1719:23: warning: ‘txpow’ may be used uninitialized in this function drivers/net/wireless/wl3501_cs.c:1752:20: warning: ‘retry’ may be used uninitialized in this function drivers/net/wireless/wl3501_cs.c:1806:25: warning: ‘pwr_state’ may be used uninitialized in this function drivers/net/wireless/wl3501_cs.c:1383:24: warning: ‘value’ may be used uninitialized in this function I could not figure out what exactly confuses gcc here, but splitting the wl3501_get_mib_value function into two helps the compiler to figure out that the variables are not actually used uninitialized, and makes it slightly clearer to a human reader what the function actually does and which parts of it are under the spinlock. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Javier Martinez Canillas authored
The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT binding document lists the possible compatible strings that a SDIO child node can have, so the driver checks if the defined in the node matches. But the error message when that's not the case is misleading, so change for one that makes clear what the error really is. Also, returning a -1 as errno code is not correct since that's -EPERM. A -EINVAL seems to be a more appropriate one. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Javier Martinez Canillas authored
The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT binding document say that the "interrupts" property in the child node is optional. So the property being missed shouldn't be treated as an error. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Javier Martinez Canillas authored
The function can fail so the returned value should be checked and the error propagated to the caller in case of a failure. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Javier Martinez Canillas authored
It's better to have the device name prefixed in the error message. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Javier Martinez Canillas authored
Instead of duplicating part of the cleanups needed in case of an error in .probe callback, have a single error path and use goto labels as is common practice in the kernel. This also has the nice side effect that the cleanup operations are made in the inverse order of their counterparts, which was not the case for the mwifiex_add_card() error path. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Javier Martinez Canillas authored
There's only a check if mwifiex_add_card() returned a nonzero value, but the actual error code is neither stored nor propagated to the caller. So instead of always returning -1 (which is -EPERM and not a suitable errno code in this case), propagate the value returned by mwifiex_add_card(). Patch also removes the assignment of sdio_disable_func() returned value since it was overwritten anyways and what matters is to know the error value returned by the first function that failed. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Javier Martinez Canillas authored
If the sdio_enable_func() function fails on .probe, the -EIO errno code is always returned but that could make more difficult to debug and find the cause of why the function actually failed. Since the driver/device core prints the value returned by .probe in its error message propagate what was returned by sdio_enable_func() at fail. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Javier Martinez Canillas authored
SDIO is an auto enumerable bus so the SDIO devices are matched using the sdio_device_id table and not using compatible strings from a OF id table. However, commit ce4f6f0c ("mwifiex: add platform specific wakeup interrupt support") allowed to match nodes defined as child of the SDIO host controller in the probe function using a compatible string to setup platform specific parameters in the DT. The problem is that the OF parse function is always called regardless if the SDIO dev has an OF node associated or not, and prints an error if it is not found. So, on a platform that doesn't have a node for a SDIO dev, the following misleading error message will be printed: [ 12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Rafał Miłecki authored
This is helpful for debugging. Without this all I was getting from "iw" command on failed creating of P2P interface was: > command failed: Too many open files in system (-23) Signed-off-by: Rafal Milecki <zajec5@gmail.com> [arend@broadcom.com: reduce error prints upon iface creation] Signed-off-by: Arend van Spriel <arend@broadcom.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 14 Jun, 2016 13 commits
-
-
Amitkumar Karwar authored
This patch ensures that 'locally_generated' parameter is correctly passed to cfg80211_disconnected() API. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Mathias Krause authored
The GFP_DMA flag is obviously misunderstood in the mwifiex driver. It's meant for legacy ISA DMA memory mappings only -- the lower 16MB on x86. That doesn't apply to PCIe or SDIO devices, I guess. Remove the GFP_DMA flag to reduce the need to place the socket buffer allocation into the low mem DMA area, which might already be in use by other drivers. This misuse was flagged by the PaX USERCOPY feature by chance, as it detected the user copy operation from a DMA buffer in the recvfrom() syscall path. Signed-off-by: Mathias Krause <minipli@googlemail.com> Tested-by: Dennis Wassenberg <dennis.wassenberg@secunet.com> Cc: Amitkumar Karwar <akarwar@marvell.com> Cc: Nishant Sarmukadam <nishants@marvell.com> Cc: Xinming Hu <huxm@marvell.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Brad Spengler <spender@grsecurity.net> Cc: PaX Team <pageexec@freemail.hu> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Rafał Miłecki authored
This is important for brcmfmac as some of released firmwares (e.g. brcmfmac4366b-pcie.bin) may pick different channel than requested. This has been tested with BCM4366B1 in D-Link DIR-885L. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Rafał Miłecki authored
Our d11 code supports encoding/decoding channel info into/from chanspec format used by firmware. Current implementation is quite misleading because of the way "chnum" field is used. When encoding channel info, "chnum" has to be filled by a caller with *center* channel number. However when decoding chanspec the same field is filled with a *control* channel number. 1) This can be confusing. It's expected for information to be the same after encoding and decoding. 2) It doesn't allow accessing all info when decoding. Some functions may need to know both channel numbers, e.g. cfg80211 callback getting current channel. Solve this by adding a separated field for control channel. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Muhammad Falak R Wani authored
Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Arnd Bergmann authored
gcc-6 warns about code in il3945_hw_txq_ctx_free() being somewhat ambiguous: drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses] This adds a set of curly braces to avoid the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Wei-Ning Huang authored
The action 'check for winner' and 'download firmware' should be an atomic action. This is true for btmrvl driver but not mwmfiex, which cause firmware download to fail when the following senerio happens: 1) mwifiex check winner status: true 2) btmrvl check winner status: true, and start downloading firmware 3) mwfieix tries to download firmware, but failed because btmrvl is already downloading. This won't happen if 1) and 3) is an atomic action. This patch adds sdio_claim/release_host call around those two actions to make sure it's atomic. Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Heinrich Schuchardt authored
Simplify assignment in wlc_phy_rxcal_gainctrl_nphy_rev5. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Heinrich Schuchardt authored
Simplify _rtl92ee_phy_path_adda_on. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Heinrich Schuchardt authored
Do not dereference card before checking against NULL value. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Heinrich Schuchardt authored
Do not return undefined value for transmission power if the rate is invalid. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Heinrich Schuchardt authored
Variable adapter is incorrectly initialized. Fixes: bf00dc22 ("mwifiex: AMSDU Rx frame handling in AP mode") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Heinrich Schuchardt authored
msg is dereferenced before checking against NULL, e.g. when assigning pad_bytes. Remove the superfluous check in function rsi_mgmt_pkt_to_core. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 09 Jun, 2016 1 commit
-
-
Rafał Miłecki authored
The old implementation was overcomplicated and slightly bugged in some corner cases. Consider following state of BSS-es (limited to 6 for simplification): drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, } drvr->iflist[1]: (null) drvr->iflist[2]: { bsscfgidx:2, ndev->name:wlan1-1, } drvr->iflist[3]: { bsscfgidx:3, ndev->name:wlan1-2, } drvr->iflist[4]: (null) drvr->iflist[5]: (null) In such case the next AP interface should bsscfgidx 4 (we don't use 1 as it's reserved for P2P). With old code the loop iterations were following: [ifidx = 0] [bsscfgidx = 2] [highest = 2] [ifidx = 1] [bsscfgidx = 2] [highest = 2] available = true [ifidx = 2] [bsscfgidx = 2] [highest = 2] bsscfgidx = highest + 1 [ifidx = 3] [bsscfgidx = 3] [highest = 2] bsscfgidx = highest + 1 [ifidx = 4] [bsscfgidx = 3] [highest = 2] available = true [ifidx = 5] [bsscfgidx = 3] [highest = 2] available = true There were 2 obvious problems: 1) Having empty BSS at index 1 was resulting in available being always set to true, even if we would run out of BSS-es. 2) Calculated bsscfgidx was invalid (3 instead of 4) resulting in driver not being able to create the 4th AP interface. New code is simpler, placed in file where it's really used, handles running out of free BSS-es and allows using 4 interfaces at the same time. It also looks for the first free BSS instead of one after the last in use. It works well with current driver (which doesn't allow deleting interfaces) and should be future proof (if we ever allow deleting). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 04 Jun, 2016 13 commits
-
-
Julia Lawall authored
firmare -> firmware Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Adrian Chadd authored
Check the current PHY operating mode (gmode) to see if we should fall back from 6MB OFDM to 11MB CCK. For 5GHz operation this isn't allowed. Note, the fallback lookup is only done for RTS rates; normal fallback rates are done via mac80211 and aren't affected by this change. Signed-off-by: Adrian Chadd <adrian@freebsd.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Christian Daudt authored
brcmf_sdiod_intr_unregister call that removes both func1 and func2 interrupt handlers only called when brcmf_ops_sdio_remove is called for func 1 (which is the 2nd call) but sdio is expecting it to be removed at the end of each sdio_remove call. This is causing 'rmmod bcmrfmac' on a 4356-sdio chip to complain with: WARNING: driver brcmfmac did not remove its interrupt handler! The modification makes calling brcmf_sdiod_intr_unregister multiple times harmless by clearing the variables that track if interrupt handlers have been installed, and then calls it on every brcmf_ops_sdio_remove call instead of just remove for func 1. Signed-off-by: Christian Daudt <csd@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Christian Daudt authored
When chip attach fails, brcmf_sdiod_intr_unregister is being called but that is too early as sdiodev->settings has not been set yet nor has brcmf_sdiod_intr_register been called. Change to use oob_irq_requested + newly created sd_irq_requested to decide on what to unregister at intr_unregister time. Steps to reproduce problem: - modprobe brcmfmac using buggy FW - rmmod brcmfmac - modprobe brcmfmac again. If done with a buggy firmware, brcm_chip_attach will fail on the 2nd modprobe triggering the call to intr_unregister and the kernel oops when attempting to de-reference sdiodev->settings->bus.sdio which has not yet been set. Signed-off-by: Christian Daudt <csd@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Lauri Kasanen authored
The previous text was confusing, leading readers to think this driver was a duplicate, and so didn't need to be enabled. After the removal of the older staging driver, this is the only driver in mainline for these devices. Signed-off-by: Lauri Kasanen <cand@gmx.com> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
size_t objects should be printed with %Z printf format. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
Commit a91eb52a ("qed: Revisit chain implementation") contains an incorrect implementation for BE platforms, as device's regpairs containing addresses are LE and they're not converted correctly when read back. In addition, it raises a compilation warning for 32-bit platforms where dma_addr_t is a 32-bit variable. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Yuval Mintz says: ==================== qed: RocE & iSCSI infrastructure We plan on sending 2 new protocol drivers in the imminent future - both our RoCE [qedr] and iSCSI [qedi] drivers. As both submissions would be rather massive and in order to avoid collisions between them, the common infrastructure on the qed side was prepared as an independent patch-series to be sent ahead of those 2 submissions. This patch series introduces in QED 2 new 'ids' - one for iscsi and one for roce. It then goes and adds logic required for configuring said protocols in HW. Notice it *doesn't* actually add any client using said ids, but rather only the infrastructure to allow their later usage. What this patch doesn't contain is the slowpath protocol-configuration toward the firmware. I.e., it contains register-setting logic, memory allocations, etc., but not actual flow-related configuration specific to the protocl. Those would be sent as part of the protocol driver submissions. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
RoCE and iSCSI would require some added/changed hw configuration in order to properly run; The biggest single change being the requirement of allocating and mapping host memory for several HW blocks that aren't being used by qede [SRC, QM, TM, etc.]. In addition, whereas qede is only using context memory for HW blocks, the new protocol would also require task memories to be added. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
This patch adds in the ecore 2 new personalities in addition to QED_PCI_ETH - QED_PCI_ISCSI and QED_PCI_ETH_ROCE. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
This adds the qed portion of the RoCE & iSCSI firmware HSI, as well as adding several new common HSI files which would be required by both qed and qed* protocols. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
RoCE driver is going to need a 32-bit chain [current chain implementation for qed* currently supports only 16-bit producer/consumer chains]. This patch adds said support, as well as doing other slight tweaks and modifications to qed's chain API. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 03 Jun, 2016 1 commit
-
-
Ivan Khoronzhuk authored
There is no reason in this lock. At least for now. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-