This clarifies this is only required for external radios.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is calling an allocation and checking for it, simplify
this process in a macro.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw_rfattach() was just calling a helper and this helper was
doing nothing for single-chip devices, and for non single-chip devices
it is just allocating memory for banks to program the RF registers
at a later time. Simplify this by having the hw initialization call
the rf bank allocation directly for external radios.
Also, propagate an -ENOMEM properly now upon failure.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We a huge branch for old hardware and nothing for newer
hardware. Instead of doing this just bail out early for
newer hardware.
This patch has no functional changes.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Document what we can about the RF analog front ends (radios)
of Atheros 802.11n devices. What should be clearer now is the
what we do for old pre AR5416 and AR5418 MAC based devices in
comparison to the modern sigle-chip 802.11n solutions.
All devices after AR9280 are single chip and require less
programming -- the RF registers no longer need to be initialized
as they all have the RF analog front end embedded together with
the MAC/BB; this includes the AR9271. Older devices such as the
ones with the AR5416 MACs (PCI) or AR5418 MACs (PCI-E) have an
external 2.4 GHz AR2133 radio or a dual band 2.4 GHz / 5 GHz
AR5133 radio. These external radios require additional programming
of the RF registers.
Clarify which parts are for what devices and which code is
shared. This patch has no functional changes.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We adjust the core clock for ar9271 to 117 MHz; this also
requires us to adjust the baud divider based on the targetted
baud rate.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This update the register initialization/reset values (aka initvals)
for ar9271 based on the last recommended values on 2009-06-04 by our
systems engineering team.
The changes account for:
* Supporting ar9271 1.0 and ar9271 1.1 together, the difference
is bb_spectral_scan_ena, for 1.0 we'll set this to 0x1.
* Ensuring we get the correct noise floor values -115 ~ -118
when we enable bb_enable_ant_div_lnadiv=0 and
mc_tx_def_ant_sel=1. Previous to this we would get noise
floor values in the range -50 ~ -80. To fix settings for
the registers:
- bb_ch1_xatten1_db
- bb_ch1_xatten2_db
- bb_ch1_xatten1_margin
- bb_ch1_xatten2_margin
- bb_ch1_gain_force
- bb_ch1_xatten2_hyst_margin
- bb_ch1_xatten1_hyst_margin
- bb_ch1_max_oc_gain
* 0x8120[2] mc_mic_new_location_enable is changed to 0x1. The MAC team
suggest to set this value.
* 0x9910[0] bb_spectral_scan_ena is changed to 0x0.
For ar9271 1.1 we don't need to enable this bit.
Cc: Stephen Chen <Stephen.Chen@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With the WLAN_PRE80211 drivers moved to drivers/staging, this
distinction becomes unnecessary.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move the netwave driver to drivers/staging. This is another pre-802.11
driver that has seen virtually no non-API-fixup activity in years, and
for which no active hardware is likely to still exist. This driver
represents unnecessary ongoing maintenance for no clear benefit.
This patch brought to you by the "hacking" session at the 2009 Kernel
Summit in Tokyo, Japan...
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move the wavelan driver to drivers/staging. This is another pre-802.11
driver that has seen virtually no non-API-fixup activity in years, and
for which no active hardware is likely to still exist. This driver
represents unnecessary ongoing maintenance for no clear benefit.
This patch brought to you by the "hacking" session at the 2009 Kernel
Summit in Tokyo, Japan...
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move the arlan driver to drivers/staging. This is another pre-802.11
driver that has seen virtually no non-API-fixup activity in years, and
for which no active hardware is likely to still exist. This driver
represents unnecessary ongoing maintenance for no clear benefit.
This patch brought to you by the "hacking" session at the 2009 Kernel
Summit in Tokyo, Japan...
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move the strip ("Starmode Radio IP") driver to drivers/staging. For
several years this driver has only seen API "bombing-run" changes, and
few people ever had the hardware. This driver represents unnecessary
ongoing maintenance for no clear benefit.
This patch brought to you by the "hacking" session at the 2009 Kernel
Summit in Tokyo, Japan...
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While there may be a case for a driver adding its
own bits of radiotap information, none currently
does. Also, drivers would have to copy the code
to generate the radiotap bits that now mac80211
generates. If some driver in the future needs to
add some driver-specific information I'd expect
that to be in a radiotap vendor namespace and we
can add a different way of passing such data up
and having mac80211 include it.
Additionally, rename IEEE80211_CONF_RADIOTAP to
IEEE80211_CONF_MONITOR since it's still used by
b43(legacy) to obtain per-frame timestamps.
The purpose of this patch is to simplify the RX
code in mac80211 to make it easier to add paged
skb support.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In
commit 601ae7f25a
Author: Bruno Randolf <br1@einfach.org>
Date: Thu May 8 19:22:43 2008 +0200
mac80211: make rx radiotap header more flexible
code was added that tried to align the radiotap header
position in memory based on the radiotap header length.
Quite obviously, that is completely useless.
Instead of trying to do that, use unaligned accesses
to generate the radiotap header. To properly do that,
we also need to mark struct ieee80211_radiotap_header
packed, but that is fine since it's already packed
(and it should be marked packed anyway since its a
wire format).
Cc: Bruno Randolf <br1@einfach.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's currently a very odd bug in mac80211 -- a
hardware scan that is done while the hardware is
really operating on 2.4 GHz will include CCK rates
in the probe request frame, even on 5 GHz (if the
driver uses the mac80211 IEs). Vice versa, if the
hardware is operating on 5 GHz the 2.4 GHz probe
requests will not include CCK rates even though
they should.
Fix this by splitting up cfg80211 scan requests by
band -- recalculating the IEs every time -- and
requesting only per-band scans from the driver.
Apparently this bug hasn't been a problem yet, but
it is imaginable that some older access points get
confused if confronted with such behaviour.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This comment hasn't been a real TODO item for a long
time now since we fixed that quite a while ago.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This buglet confused me a lot just now ...
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
An extra register was being written to for PA calibration
making the hardware unresponsive, remove it. Hardware
reset should now complete fine on ar9271.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We had 0x9912 but AR_PHY_SPECTRAL_SCAN is 0x9910. By using the
0x9912 we were making the hardware unresponsive. This allows us
to move forward with hardware reset on ar9271 on the ath9k_htc
driver.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Devices with external radios have revisions which we can count on.
On single chip solutions these EEPROM values for these radio revision
also exist but are not meaningful as the radios are embedded onto the
same chip. Each single-chip device evolves together as one device.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These are shared between ath9k and the future ath9k_htc driver.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
wl1251 supports power save and it can be enabled now.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In TX path it was assumed that dynamic power save works only if
IEEE80211_HW_PS_NULLFUNC_STACK is set. But is not the case, there are
devices which have nullfunc support in hardware but need mac80211
to handle dynamic power save timers, TI's wl1251 is one of them.
The fix is to not check for IEEE80211_HW_PS_NULLFUNC_STACK in
is_dynamic_ps_enabled(), instead check IEEE80211_HW_SUPPORTS_PS and
IEEE80211_HW_SUPPORTS_DYNAMIC_PS flags and act accordingly.
Tested with wl1251.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Refactor dynamic power save checks to a function of it's own for better
readibility. No functional changes.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We can save a lot of code and pointers in the structs
by using debugfs_remove_recursive().
First, change cfg80211 to use debugfs_remove_recursive()
so that drivers do not need to clean up any files they
added to the per-wiphy debugfs (if and only if they are
ok to be accessed until after wiphy_unregister!).
Then also make mac80211 use debugfs_remove_recursive()
where necessary -- it need not remove per-wiphy files
as cfg80211 now removes those, but netdev etc. files
still need to be handled but can now be removed without
needing struct dentry pointers to all of them.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This implements the following calibration functions:
-Set TX IQCC
-Set TX Power by Index
-PR41573 workaround (incomplete, needs PHY reset)
-Calc RX IQ Comp
-PHY Cordic
-Run Samples
-Start/Stop TX Tone
-part of PAPD Cal TX Power
-RX I/Q Calibration
-The basic structure of the periodic calibration wrapper
Software RFKILL (required by calibration) is also implemented in
this round.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The temporary copy of the VLAN group is not neccessary since the lower device
is already in the process of being unregistered, if it was neccessary the
memset of the global group would introduce a race condition.
With this removed, the changes to the original code are only a few lines, so
remove the new function and move the code back into vlan_device_event().
Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For USB 3.0 it is necessary that all drivers use the standard
API to reset a configuration. This removes a home-grown
implementation.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Hi David,
please take this for the next merge window.
Regards
Oliver
Signed-off-by: David S. Miller <davem@davemloft.net>
struct ax25_ctl_struct member `arg' is unsigned and cannot be less
than 0.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tentative support for newer Marvell hardware including
the Yukon-2 Optima chip. Do not have hatdware to test this yet,
code is based on vendor driver.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Changes related to support of Yukon supreme chip.
Don't have this chip version to test on,
these are reverse engineered from the vendor (GPL) driver.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Program the receive pause thresholds differently depending on
chip version. This cloned from from the vendor (GPL) driver.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds infrastructure for the newer chip versions and workarounds.
Extracted from the vendor (GPL) driver.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a new ID that just showed up in latest vendor driver.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now that we can tell whether GRO is being applied, this heuristic is
effective once more.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When GRO is successfully merging received packets, we should allocate
raw page buffers rather than skbs that will be discarded by GRO.
Otherwise, we should allocate skbs.
GRO also benefits from higher interrupt moderation, so increase the
score for mergeable RX packets.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This will allow drivers to adjust their receive path dynamically
based on whether GRO is being applied successfully.
Currently all in-tree callers ignore the return values of these
functions and do not need to be changed.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
This clarifies which return and parameter types are GRO result codes
and not RX result codes.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently PACKET_TX_RING forces certain amount of every frame to remain
unused. This probably originates from an early version of the
PACKET_TX_RING patch that in fact used the extra space when the (since
removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
code does not make any use of this extra space.
This patch removes the extra space reservation and lets userspace make
use of the full frame size.
Signed-off-by: Gabor Gombas <gombasg@sztaki.hu>
Signed-off-by: David S. Miller <davem@davemloft.net>
proto_ops->getname implies copying protocol specific data
into storage unit (particulary to __kernel_sockaddr_storage).
So when we implement new protocol support we should keep such
a detail in mind (which is easy to forget about).
Lets introduce DECLARE_SOCKADDR helper which check if
storage unit is not overfowed at build time.
Eventually inet_getname is switched to use DECLARE_SOCKADDR
(to show example of usage).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some workloads hit dev_base_lock rwlock pretty hard.
We can use RCU lookups to avoid touching this rwlock.
netdevices are already freed after a RCU grace period, so this patch
adds no penalty at device dismantle time.
dev_ifname() converted to dev_get_by_index_rcu()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
