aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Bluetooth: trivial: Remove newline before EOFSyam Sidhardhan2012-10-23
| | | | | | | | Trivial fix. Signed-off-by: Syam Sidhardhan <s.syam@samsung.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Start channel move when socket option is changedMat Martineau2012-10-23
| | | | | | | | | | | Channel moves are triggered by changes to the BT_CHANNEL_POLICY sockopt when an ERTM or streaming-mode channel is connected. Moves are only started if enable_hs is true. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Do not retransmit data during a channel moveMat Martineau2012-10-23
| | | | | | | | | | | | | | Do not retransmit previously-sent data when a "receiver ready" s-frame with the "final" flag is received during a move. The ERTM state machines will resynchronize at the end of a channel move, and the state machine needs to avoid state changes during a move. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Ignore BR/EDR packet size constraints when fragmenting for AMPMat Martineau2012-10-23
| | | | | | | | | | | | When operating over BR/EDR, ERTM accounts for the maximum over-the-air packet size when setting the PDU size. AMP controllers do not use the same over-the-air packets, so the PDU size should only be based on the HCI MTU of the AMP controller. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Configure appropriate timeouts for AMP controllersMat Martineau2012-10-23
| | | | | | | | | | | | The L2CAP spec recommends specific retransmit and monitor timeouts for ERTM channels that are on AMP controllers. These timeouts are calculated from the AMP controller's best effort flush timeout. BR/EDR controllers use the default retransmit and monitor timeouts. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Do not send data during channel moveMat Martineau2012-10-23
| | | | | | | | | | | | | | | Outgoing ERTM data is queued during a channel move. The ERTM state machine is partially reset at the start of a move, and must be resynchronized with the remote state machine at the end of the move. Data is not sent so that there are no state transitions between the partial reset and the resync. Streaming mode frames are dropped during a move. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Flag ACL frames as complete for AMP controllersMat Martineau2012-10-23
| | | | | | | | | | | AMP controllers expect to transmit only "complete" ACL frames. These frames have both the "start" and "cont" bits set. AMP does not allow fragmented ACLs. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Handle physical link completionMat Martineau2012-10-23
| | | | | | | | | | | | | Several different actions may be taken when an AMP physical link becomes available. A channel being created on an AMP controller must continue the connection process. A channel being moved needs to either send a move request or a move response. A failed physical link will revert to using a BR/EDR controller if possible. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Add move confirm response handlingMat Martineau2012-10-23
| | | | | | | | | | The move confirm response concludes the channel move command sequence. Receipt of this command indicates that data may begin to flow again. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Add logical link confirmMat Martineau2012-10-23
| | | | | | | | | | | | | | | | The logical link confirm callback is executed when the AMP controller completes its logical link setup. During a channel move, a newly formed logical link allows a move responder to send a move channel response. A move initiator will send a move channel confirm. A failed logical link will end the channel move and send an appropriate response or confirm command indicating a failure. If the channel is being created on an AMP controller, L2CAP configuration is completed after the logical link is set up. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Move channel responseMat Martineau2012-10-23
| | | | | | | | | | | | | | The move response command includes a result code indicating "pending", "success", or "failure" status. A pending result is received when the remote address is still setting up a physical link, and will be followed by success or failure. On success, logical link setup will proceed. On failure, the move is stopped. The receiver of a move channel response must always follow up by sending a move channel confirm command. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Add state to hci_chanMat Martineau2012-10-23
| | | | | | | | | | | | On an AMP controller, hci_chan maps to a logical link. When a channel is being moved, the logical link may or may not be connected already. The hci_chan->state is used to determine the existance of a useable logical link so the link can be either used or requested. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Add move channel confirm handlingMat Martineau2012-10-23
| | | | | | | | | | | | After sending a move channel response, a move responder waits for a move channel confirm command. If the received command has a "confirmed" result the move is proceeding, and "unconfirmed" means the move has failed and the channel will not change controllers. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Add new ERTM receive states for channel moveMat Martineau2012-10-23
| | | | | | | | | | | | | | | | | Two new states are required to implement channel moves with the ERTM receive state machine. The "WAIT_P" state is used by a move responder to wait for a "poll" flag after a move is completed (success or failure). "WAIT_F" is similarly used by a move initiator to wait for a "final" flag when the move is completing. In either state, the reqseq value in the poll/final frame tells the state machine exactly which frame should be expected next. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Channel move request handlingMat Martineau2012-10-23
| | | | | | | | | | | | | | | | On receipt of a channel move request, the request must be validated based on the L2CAP mode, connection state, and controller capabilities. ERTM channels must have their state machines cleared and transmission paused while the channel move takes place. If the channel is being moved to an AMP controller then an AMP physical link must be prepared. Moving the channel back to BR/EDR proceeds immediately. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Lookup channel structure based on DCIDMat Martineau2012-10-23
| | | | | | | | | | | Processing a move channel request involves getting the channel structure using the destination channel ID. Previous code could only look up using the source channel ID. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Remove unnecessary intermediate functionMat Martineau2012-10-23
| | | | | | | | | | | Resolves a conflict resolution issue in "Bluetooth: Fix L2CAP coding style". The remaining connect and create channel response handler is renamed to better reflect its use for both response types. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Add L2CAP create channel request handlingMat Martineau2012-10-23
| | | | | | | | | | | | | | | | | | | | The L2CAP create channel request is very similar to an L2CAP connect request, but it has an additional parameter for the controller ID. If the controller id is 0, the channel is set up on the BR/EDR controller (just like a connect request). Using a valid high speed controller ID will cause the channel to be initially created on that high speed controller. While the L2CAP data will be initially routed over the AMP controller, the L2CAP fixed signaling channel only uses BR/EDR. When a create channel request is received for a high speed controller, a pending response is always sent first. After the high speed physical and logical links are complete a success response will be sent. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* Bluetooth: Add new l2cap_chan struct members for high speed channelsMat Martineau2012-10-23
| | | | | | | | | | | | | | | | | | | | | | An L2CAP channel using high speed continues to be associated with a BR/EDR l2cap_conn, while also tracking an additional hci_conn (representing a physical link on a high speed controller) and hci_chan (representing a logical link). There may only be one physical link between two high speed controllers. Each physical link may contain several logical links, with each logical link representing a channel with specific quality of service. During a channel move, the destination channel id, current move state, and role (initiator vs. responder) are tracked and used by the channel move state machine. The ident value associated with a move request must also be stored in order to use it in later move responses. The active channel is stored in local_amp_id. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
* brcm80211: remove some truely barftastic codeAlan Cox2012-10-19
| | | | | | | | | It's not used or called but please make it go away before someone copies or uses it Signed-off-by: Alan "minus lunch" Cox <alan@linux.intel.com> Acked-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: remove 'always false' condition from brcmf_c_mkiovar_bsscfgArend van Spriel2012-10-19
| | | | | | | | | | | | | The parameter buflen is unsigned so the condition buflen < 0 is always false. The patch fixes the if statement checking the buffer length. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: fix sparse warningsFranky Lin2012-10-19
| | | | | | | | | Following sparse warning is fixed: drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:2518:21: warning: symbol 'brcmf_find_wpaie' was not declared. Should it be static? drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:3768:1: warning: symbol 'brcmf_set_management_ie' was not declared. Should it be static? Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: Using zero instead of NULLDan Carpenter2012-10-19
| | | | | | | | | | | | | Sparse complains that we use zero instead of NULL here. In fact, the initialization is wrong and should be removed. Doing these kinds of bogus initializations means that GCC can't detect unitialized variables and leads to bugs. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: perform ANI cycle in idle stateRajkumar Manoharan2012-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | As of now the ANI cycle is executed only when the chip is awake. On idle state case, the station wakes up from network sleep for beacon reception. Since most of the time, ANI cycle is not syncing with beacon wakeup, ANI cycle is ignored. Approx 5 mins once, the calibration is performed. This could affect the connection stability when the station is idle for long. Even though the OFDM and CCK phy error rates are too high, ANI is unable to tune its immunity level as quick enough due to rare execution. Here the experiment shows that OFDM and CCK levels are at default even on higher phy error rate. listenTime=44 OFDM:3 errs=121977/s CCK:2 errs=440818/s ofdm_turn=1 This change ensures that ANI calibration will be exectued atleast once for every 10 seconds. The below result shows improvements and immunity levels are adopted quick enough. listenTime=557 OFDM:4 errs=752/s CCK:4 errs=125/s ofdm_turn=0 Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* carl9170: handle traps from firmware loaderChristian Lamparter2012-10-19
| | | | | | | | | | | | | | | | | | | | | | This patch changes the way the driver deals with command responses and traps which are sent through the special interrupt input endpoint 3. While the carl9170 firmware does not use this endpoint for command responses or traps, the firmware loader on the device does. It uses it to notify the host about 'watchdog triggered' in case the firmware/hardware has crashed. Note: Even without this patch, the driver is still able to detect the mishap and reset the device. But previously it did that because the trap event caused an out-of-order message sequence number error, which also triggered a reset. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mwifiex: Using %*phD instead of print_hex_dump_bytesAndrei Emeltchenko2012-10-19
| | | | | | | | | | | | | | | | | | | | Make output more readable and remove unneeded function call. ... mwifiex_sdio mmc0:0001:1: last_cmd_index = 3 last_cmd_id: 00000000: 16 00 cd 00 83 00 df 00 28 00 ........(. ... would be changed to: ... mwifiex_sdio mmc0:0001:1: last_cmd_index = 3 mwifiex_sdio mmc1:0001:1: last_cmd_id: 16 00 cd 00 83 00 df 00 28 00 ... Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mwifiex: use sizeof(array) to print_hex_dump_bytesBing Zhao2012-10-19
| | | | | | | | | | | DBG_CMD_NUM is the number of commands, not the actual bytes of data for printing. Also remove the duplicated DBG_CMD_NUM definition. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2800: comment tx power settingsStanislaw Gruszka2012-10-19
| | | | | | | | Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2800: allow to reduce tx power on devices not exporting power limitStanislaw Gruszka2012-10-19
| | | | | | | | | | | | | | Some rt2800 devices don't have their calibrated max eirp tx power in their calibration data. For those devices reduce tx power according to difference between regulatory max channel power and requested tx power. This patch is based on Helmut Schaa work. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2800: pass channel pointer to rt2800_config_txpowerStanislaw Gruszka2012-10-19
| | | | | | | | | | Preparation for use regulatory max channel power in TX power delta calculations. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2800: use eeprom OFDM 6M TX power as criterionStanislaw Gruszka2012-10-19
| | | | | | | | | | | | Don use TX_PWR_CFG_0 register value of OFDM 6M tx power as criterion since it can be changed. The same do vendor driver (see AsicAdjustSingleSkuTxPower and AsicGetTxPowerOffset functions from 2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO). Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2800: compensate tx power also for non 11b rates on 2GHzStanislaw Gruszka2012-10-19
| | | | | | | | | | | | We skip compensate calculation for non 11b rates on 2.4GHz band. I do not see that on vendor driver (2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO). Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2800: limit TX_PWR_CFG_ values to 0xcStanislaw Gruszka2012-10-19
| | | | | | | | | | | | | | | Based on AsicAdjustTxPower function from vendor driver (2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO) limit per rate TX power values we program into TX_PWR_CFG_ registers. Note that on some configurations (devices/rates) is allowed to use bigger values than 0xc, but we use safe maximum value for now. Further work need to be done to allow use bigger values than 0xc. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2800: use BBP_R1 for setting tx powerStanislaw Gruszka2012-10-19
| | | | | | | | | | | | | | | | TX power delta can be negative. TX_PWR_CFG_ registers allow to set delta only in range between 0 dBm and 15 dBm (4 bits for each rate). Se we need to use BBP_R1 to configure negative deltas. Not utilize +6 dBm increasing BBP_R1 option for safety reason. For now, this can be used for devices, which export maximum allowed TX power value. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath_hw: Use common REG_WRITE parameter orderSven Eckelmann2012-10-19
| | | | | | | | | | | | | | | | | All defines for REG_WRITE in Atheros wireless drivers use the order "ah", "register" and "value". hw.c is the only file using the order "ah", "value" and "register". drivers/net/wireless/ath/ath9k/hw.h:#define REG_WRITE(_ah, _reg, _val) \ drivers/net/wireless/ath/key.c:#define REG_WRITE(_ah, _reg, _val) (common->ops->write)(_ah, _val, _reg) This inconsistent definition can easily lead to implementation errors. The modification doesn't change the behavior of the driver or the generated code. Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rtlwifi: rtl8192ce: rtl8192cu: use %*phC to dump small buffersAndy Shevchenko2012-10-19
| | | | | | | | | | The patch changes a bit trace output format in the rtl_cam_program_entry() to print prefix and the actual data on the same line. Moreover the %*phC outputs each byte as 2 hex digits, which is slightly different to the original %x. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> ACKed-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* orinoco_usb: clean up some signedness issuesDan Carpenter2012-10-19
| | | | | | | | | | | | | | | | | | In ezusb_read_ltv() we had a comparison "(bufsize < 0)" which was never true because bufsize was unsigned. I looked at the implications of that. If we passed a negative number to ezusb_access_ltv() then it would be used as the size parameter of the memcpy() because that function uses min_t(int, exp_len, ans_size). But fortunately when I looked at the callers, bufsize is not controlled by the user and it's never negative. So these signedness mistakes have no impact. I removed the always false check from ezusb_read_ltv() and I changed the types in ezusb_access_ltv() and made the variables unsigned. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* bcma: do not initialize deactivated PCIe coresHauke Mehrtens2012-10-19
| | | | | | | | | | Before it was tried to initialize the deactivated PCIe core in client mode, but this causes the SoC to hang. Just do not initialize it at all and ignore the core it is not working and nothing is connected to it when the specific bit is set in the boardflags. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath/ath9k/ar9003_eeprom.c: Remove semicolon after ifPeter Senna Tschudin2012-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch remove a semicolon after if(...) that is preventing the error check to work correctly. Removing this semicolon will change the code behavior, but this is intended. The semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r1@ position p; @@ if (...);@p @script:python@ p0 << r1.p; @@ // Emacs org-mode output cocci.print_main("", p0) cocci.print_secs("", p0) // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: Fix BT_OP_SCAN usageSujith Manoharan2012-10-19
| | | | | | | | | BT_OP_SCAN is applicable only for pre-MCI WLAN/BT combo chips and using it for MCI-based cards is incorrect. Fix this by cleaning up its usage. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: Use a helper routine for MCI/FTP tuningSujith Manoharan2012-10-19
| | | | | Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* bcma: add an extra pcie core structHauke Mehrtens2012-10-19
| | | | | | | | | | The BCM4706 has two PCIe host controller on the bcma bus. For PCIe client mode it is assumed that there is only one PCIe controller so the PCIe driver, like b43 and brcmsmac are accessing the first PCIe controller when they want to issue a operation on the host controller. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* bcma: use fallback sprom if sprom on card was not validHauke Mehrtens2012-10-19
| | | | | | | | | | | | | Sometimes the PCIe card indicates that it has a sprom somewhere and we are able to read the memory region, but it is empty and not valid. In these cases we should try to use the fallback sprom as a last chance. This is the case for the PCIe cards in my ASUS RT-N66U (BCM4706 + 2 times BCM4331) and I have heard of someone having the same problem with an other PCIe card connected to an other Broadcom SoC. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ssb: add attribute to indicate a parallel flash is availableHauke Mehrtens2012-10-19
| | | | | Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ssb: move parallel flash config into an own structHauke Mehrtens2012-10-19
| | | | | | | This is a preparing step for adding serial flash support. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* bcma: add some more flash chips for serial flashHauke Mehrtens2012-10-19
| | | | | Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* bcma: extract drv_cc in bcma_core_mips_flash_detect()Hauke Mehrtens2012-10-19
| | | | | | | This makes the code more readable Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* bcma: mark nflash if it is the boot flashHauke Mehrtens2012-10-19
| | | | | | | | | | | There are some devices which are able to boot from nand flash and other are using a serial flash for booting. Add a bool to indicate that the device is booted from that flash chip and not from some other chip also connected to the SoC. This is needed to find the nvram, as it is stored on the flash the devices booted from. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* bcma: add and use constants for the flash windowsHauke Mehrtens2012-10-19
| | | | | Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* bcma: mark pflash as present when availableHauke Mehrtens2012-10-19
| | | | | Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>