1. 28 3月, 2013 16 次提交
  2. 19 3月, 2013 1 次提交
  3. 07 3月, 2013 2 次提交
  4. 15 2月, 2013 3 次提交
  5. 09 2月, 2013 2 次提交
    • T
      brcmsmac: avoid 512 byte stack variable · 0d61c917
      Tim Gardner 提交于
      Dynamically allocate the probe response template which
      avoids potential stack corruption. Observed with smatch:
      
      drivers/net/wireless/brcm80211/brcmsmac/main.c:7412 brcms_c_bss_update_probe_resp()
       warn: 'prb_resp' puts 512 bytes on stack
      
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
      Cc: Hante Meuleman <meuleman@broadcom.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Pieter-Paul Giesberts <pieterpg@broadcom.com>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Cc: linux-wireless@vger.kernel.org
      Cc: brcm80211-dev-list@broadcom.com
      Cc: netdev@vger.kernel.org
      Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
      Acked-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0d61c917
    • T
      brcmsmac: fix u16 overflow warning · 708eb54f
      Tim Gardner 提交于
      DOT11_MIN_BEACON_PERIOD and DOT11_MAX_BEACON_PERIOD are
      superfluous. The only invalid beacon period is 0. Comparing
      a 16 bit quantity to 0xffff also causes a compile warning:
      
      drivers/net/wireless/brcm80211/brcmsmac/main.c:5560 brcms_c_set_beacon_period()
       warn: impossible condition '(period > 65535) => (0-65535 > 65535)'
      
      Observed from smatch analysis.
      
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
      Cc: Hante Meuleman <meuleman@broadcom.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Pieter-Paul Giesberts <pieterpg@broadcom.com>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Cc: linux-wireless@vger.kernel.org
      Cc: brcm80211-dev-list@broadcom.com
      Cc: netdev@vger.kernel.org
      Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
      Acked-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      708eb54f
  6. 05 2月, 2013 1 次提交
  7. 29 1月, 2013 1 次提交
  8. 19 1月, 2013 1 次提交
  9. 14 1月, 2013 1 次提交
  10. 12 1月, 2013 1 次提交
  11. 08 1月, 2013 5 次提交
  12. 03 1月, 2013 5 次提交
    • J
      mac80211: split TX aggregation stop action · 18b559d5
      Johannes Berg 提交于
      When TX aggregation is stopped, there are a few
      different cases:
       - connection with the peer was dropped
       - session stop was requested locally
       - session stop was requested by the peer
       - connection was dropped while a session is stopping
      
      The behaviour in these cases should be different, if
      the connection is dropped then the driver should drop
      all frames, otherwise the frames may continue to be
      transmitted, aggregated in the case of a locally
      requested session stop or unaggregated in the case of
      the peer requesting session stop.
      
      Split these different cases so that the driver can
      act accordingly; however, treat local and remote stop
      the same way and ask the driver to not send frames as
      aggregated packets any more.
      
      In the case of connection drop, the stop callback the
      driver is otherwise supposed to call is no longer
      required.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      18b559d5
    • J
      regulatory: use IS_ERR macro family for freq_reg_info · 361c9c8b
      Johannes Berg 提交于
      Instead of returning an error and filling a pointer
      return the pointer and an ERR_PTR value in error cases.
      Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      361c9c8b
    • J
      regulatory: remove handling of channel bandwidth · fe7ef5e9
      Johannes Berg 提交于
      The channel bandwidth handling isn't really quite right,
      it assumes that a 40 MHz channel is really two 20 MHz
      channels, which isn't strictly true. This is the way the
      regulatory database handling is defined right now though
      so remove the logic to handle other channel widths.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fe7ef5e9
    • A
      brcmsmac: add copyright information for Canonical · 1b2c2e73
      Arend van Spriel 提交于
      Patches from Canonical involved the introduction of new source
      files debug.[ch]. That coincided with other patches from Broadcom
      introducing the same files.
      
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
      Reviewed-by: NPiotr Haber <phaber@broadcom.com>
      Signed-off-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1b2c2e73
    • N
      brcmsmac: Use udelay instead of usleep_range · 7ffa5928
      Niels Ole Salscheider 提交于
      wlc_lcnphy_rx_iq_cal_gain is called during initialization, i. e. when
      executing brcms_up.
      But brcms_up is called from brcms_ops_start while the latter holds a spin lock.
      Thus, we cannot use usleep_range but have to use udelay.
      
      This fixes:
      BUG: scheduling while atomic: NetworkManager/1652/0x00000200
      [...]
      Call Trace:
       [<ffffffff81582522>] __schedule_bug+0x48/0x54
       [<ffffffff815892b6>] __schedule+0x596/0x6d0
       [<ffffffff81589719>] schedule+0x29/0x70
       [<ffffffff8158893c>] schedule_hrtimeout_range_clock+0xfc/0x140
       [<ffffffff81060f10>] ? update_rmtp+0x70/0x70
       [<ffffffff81588993>] schedule_hrtimeout_range+0x13/0x20
       [<ffffffff810495e0>] usleep_range+0x40/0x50
       [<ffffffffa05dedcb>] wlc_lcnphy_rx_iq_cal.constprop.10+0x59b/0xa90 [brcmsmac]
       [<ffffffffa05df4ce>] wlc_lcnphy_periodic_cal+0x20e/0x220 [brcmsmac]
       [<ffffffffa05dce8d>] ? wlc_lcnphy_set_tx_pwr_ctrl+0x21d/0x3c0 [brcmsmac]
       [<ffffffffa05e0cfc>] wlc_phy_init_lcnphy+0xacc/0x1100 [brcmsmac]
       [<ffffffffa05e0230>] ? wlc_phy_txpower_recalc_target_lcnphy+0x90/0x90 [brcmsmac]
       [<ffffffffa05d7c7d>] wlc_phy_init+0xcd/0x170 [brcmsmac]
       [<ffffffffa05c9dfe>] brcms_b_bsinit.isra.65+0x12e/0x310 [brcmsmac]
       [<ffffffffa05d061b>] brcms_c_init+0x8fb/0x1170 [brcmsmac]
       [<ffffffffa05c3a0a>] brcms_init+0x5a/0x70 [brcmsmac]
       [<ffffffffa05ce76c>] brcms_c_up+0x1ac/0x4a0 [brcmsmac]
       [<ffffffffa05c3c65>] brcms_up+0x25/0x30 [brcmsmac]
       [<ffffffffa05c44c0>] brcms_ops_start+0xd0/0x100 [brcmsmac]
      [...]
      Signed-off-by: NNiels Ole Salscheider <niels_ole@salscheider-online.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7ffa5928
  13. 11 12月, 2012 1 次提交