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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

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>

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This makes the code more readable
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The PCIe host driver and the chip common initialisation accesses the
sprom struct, but it is not initialized when these functions are run.
Move the sprom parsing up in to do it earlier.
As we need the chip common core rev and some other attributes from the
chip common core, the early initialization is done before accessing the
sprom.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Some parts of the initialization for chip common and the pcie core are
accessing the sprom struct, but it is not initialized at that stage.
Just do the necessary thing in the early register on SoCs and not the
complete initialization to read out the nvram from the flash chip.
After it is possible to read out the nvram, the sprom should be parsed
from it and the full initialization of the cores should be run.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch prepares mac80211 for a later implementation of mesh or
ad-hoc powersave clients.
The structures related to powersave (buffer, TIM map, counters) are
moved from the AP-specific interface structure to a generic structure
that can be embedded into any interface type.
The functions related to powersave are prepared to allow easy
extension with different interface types. For example with:

+ } else if (sta->sdata->vif.type == NL80211_IFTYPE_MESH_POINT) {
+         ps = &sdata->u.mesh.ps;

Some references to the AP's beacon structure are removed where they
were obviously not used.

The patch compiles without warning and has been briefly tested as AP
interface with one client in PS mode.
Signed-off-by: Marco Porsch <marco.porsch@etit.tu-chemnitz.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If the user wants to scan using a vif configured as AP,
cfg80211 must give him a chance to do it, even if this
will disrupt the stations performance due to off-channel
scanning. To do so, this patch adds a 'force' flag to the
SCAN_TRIGGER command which tells cfg80211 to perform the
scanning operation even if the vif is an AP and the
beaconing has already started.
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When assigning amp_mgr in hci_conn (type AMP_LINK) get also reference.
In hci_conn_del those references would be put for both conn types
AMP_LINK and ACL_LINK associated with amp_mgr.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Also add tracing to the API functions that drivers
(and mac80211) can call in cfg80211.
Signed-off-by: Beni Lev <beni.lev@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Add tracing to make debugging cfg80211/mac80211
(or full-mac driver) interaction easier.
Signed-off-by: Beni Lev <beni.lev@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Hila Gonen <hila.gonen@intel.com>
Tested-by: Hila Gonen <hila.gonen@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
[add a cast to int to sizeof() to avoid warning]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This will allow adding central tracing like in mac80211.
Signed-off-by: Hila Gonen <hila.gonen@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Currently, a user is allowed to choose a HT operating channel
with WEP when creating an IBSS network. WEP is not allowed
in HT configuration - this patch ensures that such requests
are denied.
Signed-off-by: Sujith Manoharan <c_manoha@qti.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Signed-off-by: Marco Porsch <marco.porsch@etit.tu-chemnitz.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The internal function mac80211_format_buffer() has a
printf-style argument list, so add the attribute to
have gcc verify that list.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There are a number of unused variables that gcc
pointed out (when building with W=1) as well as
some conditions that can never be true due to
the datatypes used: unsigned values can't be
less than zero. Remove this code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There's no vendor-specific mesh sync implemented
and there don't need to be dummy handlers that
only print messages, so remove that code. While
at it, also constify the mesh sync ops.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

WLAN_EID_WPA and WLAN_EID_GENERIC mapped to the same value
as WLAN_EID_VENDOR_SPECIFIC. The last one being more in line
with the standard specification. Removing WLAN_EID_WPA and
WLAN_EID_GENERIC as there are no longer drivers using these.

Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The include file linux/ieee80211.h contains three definitions for
the same thing in enum ieee80211_eid due to historic changes:

    /* Information Element IDs */
    enum ieee80211_eid {
        :
        WLAN_EID_WPA = 221,
        WLAN_EID_GENERIC = 221,
        WLAN_EID_VENDOR_SPECIFIC = 221,
        :
    };

The standard refers to this as "vendor specific" element so the
other two definitions are better not used. This patch changes the
wireless drivers to use one definition, ie. WLAN_EID_VENDOR_SPECIFIC.

Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The include file linux/ieee80211.h contains three definitions for
the same thing in enum ieee80211_eid due to historic changes:

/* Information Element IDs */
enum ieee80211_eid {
    :
    WLAN_EID_WPA = 221,
    WLAN_EID_GENERIC = 221,
    WLAN_EID_VENDOR_SPECIFIC = 221,
    :
};

The standard refers to this as "vendor specific" element so the
other two definitions are better not used. This patch changes the
wireless drivers to use one definition, ie. WLAN_EID_VENDOR_SPECIFIC.

Cc: Jouni Malinen <j@w1.fi>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath6kl]
Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex]
Acked-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> [ipw2x00]
Signed-off-by: Arend van Spriel <arend@broadcom.com>
[change libipw as well]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Initialization of beacon transmission in IBSS mode depends
on whether a new BSS is being created or joined. When joining
an existing IBSS network, beaconing has to start only after
a TSF-sync has happened - this is explained in 11.1.4.

Introduce a new parameter in the BSS information structure to
indicate creator/joiner mode.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>