- 07 Mar, 2012 32 commits
-
-
Johannes Berg authored
All variables related to uCode loading (the waitqueue and done indication) should be in the PCI-E transport's private data as this is transport specific. Move them there. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The transport doesn't really need to know as we can enforce it in the command wrapper. Move the ucode_owner variable into priv and do all enforcing there. Signed-off-by:
-
Johannes Berg authored
This will be sharable, but needs to live in the op_mode as it is dependent on command processing. Make a library out of the notification wait code. Since I wrote all of the code originally and only Intel employees changed it, we can also relicense it to dual BSD/GPL. Signed-off-by:
-
Johannes Berg authored
In "iwlwifi: consolidate the start_device flow" Emmanuel added the return if the fw isn't there but forgot to take into account that the struct for notification wait needs to be added only after the check -- fix that. Signed-off-by:
-
Johannes Berg authored
The HW configuration settings base_params, ht_params and bt_params all should be const, make it so. Signed-off-by:
-
Johannes Berg authored
The hardware config ht_params shouldn't be modified, so copy the use_rts_for_aggregation parameter into hw_params and use/modify it there. Signed-off-by:
-
Johannes Berg authored
This is the version that can be modified, the config params should be read-only. Signed-off-by:
-
Johannes Berg authored
The base_params shouldn't be writable, so keep a copy of this in priv that can be modified. Signed-off-by:
-
Johannes Berg authored
This can be used directly from the config now. Signed-off-by:
-
Johannes Berg authored
This is a hardware parameter, so it shouldn't be configurable by the user. Users can disable aggregation (which is the only thing affected) with 11n_disable. Signed-off-by:
-
Johannes Berg authored
The transport doesn't need to include iwl-core.h any more. Signed-off-by:
-
Johannes Berg authored
When the command queue is full, the transport will return -ENOSPC, but the reaction to that depends on the op_mode. Virtualize that, the DVM op_mode checks for CT-kill and restarts the hardware otherwise. We may be able to get rid of this callback by putting the behaviour check into the wrapper but that needs more careful evaluation. Signed-off-by:
-
Johannes Berg authored
Tracing used the priv pointer as an identifier, which has the problem that we don't have it in all code, and also some people say no pointers should be "leaked" to userspace. Use the device name instead, it is more useful anyway. Signed-off-by:
-
Johannes Berg authored
They are only used in the DVM op_mode. Also move the rfkill debug macros that depend on them. Signed-off-by:
-
Johannes Berg authored
There's no need to copy shadow_reg_enable into hw_params since it is a pure hardware parameter that will never change, we can access it from the config directly. Signed-off-by:
-
Johannes Berg authored
As iwl_prepare_card_hw() is idempotent (and many cards support AMT anyway) there's no point in calling iwl_prepare_card_hw() only for AMT capable devices -- call it always and simplify the code that way. Signed-off-by:
-
Johannes Berg authored
That name better reflects the contents of the file and the fact that it isn't related to iwl-ucode.c. Signed-off-by:
-
Johannes Berg authored
The transport layer should only check the hardware RF kill status, not impose any policy or reaction based on it, so move that out of it into the op_mode. For now keep the restriction on loading firmware, that will have to be removed later. Signed-off-by:
-
Johannes Berg authored
Now the mutex no longer needs to be shared, so move it into iwl_priv. Signed-off-by:
-
Johannes Berg authored
The fact that the mutex must be held is an implementation detail of DVM, but something has to ensure that no two synchronous cmds are submitted concurrently. Move the lockdep assertion into the DVM-specific code, but also make the transport abort if there are two concurrently commands. The assertion is much more useful though as the transport check can only catch it when it actually happens, while the assertion makes sure it can't possibly happen. Signed-off-by:
-
Johannes Berg authored
Currently, we cannot send any commands when the uCode is in RF or CT kill, but that will not be true for all new uCode versions, so we need to move the check into the uCode specific code. Also remove the duplicate rfkill check. Signed-off-by:
-
Johannes Berg authored
Add wrappers to send commands from the DVM op-mode (which essentially consists of the current driver). This will allow us to move specific sanity checks there. Also, this removes iwl_trans_send_cmd_pdu() since that can now be taken care of in the DVM-specific wrapper. Signed-off-by:
-
Johannes Berg authored
This file was recently introduced, but then directly abused -- it contained private data that shouldn't have been used by anything but the implementation of firmware requests and some very core code. Now that it is no longer accessed by any code but the code in iwl-drv.c, we can dissolve it. Also rename the iwl_nic struct to iwl_drv to better reflect where and how it is used. Signed-off-by:
-
Johannes Berg authored
Through the driver, struct iwl_fw will store the firmware. Split this out into a separate file, iwl-fw.h, and make all other code use it. To do this, also move the log pointers into it, and remove the knowledge of "nic" from everything. Now the op_mode has a fw pointer, and (unfortunately) for now the shared data also needs to keep one for the transport to access dump the error log -- I think that will move later. Since I wanted to constify the firmware pointers, some more changes were needed. Signed-off-by:
-
Johannes Berg authored
uCode loading belongs to the op_mode, as it is dependent on various things there and the commands sent during it are specific to it. Move the prototypes to iwl-agn.h to indicate this. To make this possible, also move all the calibration handling (which is op_mode dependent after all). Signed-off-by:
-
Ashok Nagarajan authored
The patch "{nl,cfg,mac}80211: Implement RSSI threshold for mesh peering" has a potential null pointer dereferencing problem. Thanks to Dan Carpenter for pointing out. This patch will fix the issue. Signed-off-by:Ashok Nagarajan <ashok@cozybit.com> Signed-off-by:
-
Felix Fietkau authored
On A-MPDU frames, the hardware only reports valid signal strength data for the last subframe. The driver also mangled rx_stats->rs_rssi using the ATH_EP_RND macro in a way that may make sense for ANI, but definitely not for reporting to mac80211. This patch changes the code to calculate the signal strength from the rssi directly instead of taking the average value, and flag everything but the last subframe in an A-MPDU to tell mac80211 to ignore the signal strength entirely, fixing signal strength fluctuation issues reported by various users. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
Process rx status directly instead of separating the completion test from the actual rx status processing. Signed-off-by:
-
Felix Fietkau authored
The way this is implemented (simply storing the last value) is absolutely worthless for debugging anything, and the same information is also available through the MAC sample feature, so there's no point in keeping this around. Signed-off-by:
-
Felix Fietkau authored
They're more expensive than some of the other debug options and only used in very rare situations, so it sometimes makes sense to disable them while leaving in debugfs support. Signed-off-by:
-
Felix Fietkau authored
Cold reset is more reliable for getting the hardware out of some specific stuck states. Signed-off-by:
-
Paul Stewart authored
mac80211 is lenient with respect to reception of corrupted beacons. Even if the frame is corrupted as a whole, the available IE elements are still passed back and accepted, sometimes replacing legitimate data. It is unknown to what extent this "feature" is made use of, but it is clear that in some cases, this is detrimental. One such case is reported in http://crosbug.com/26832 where an AP corrupts its beacons but not its probe responses. One approach would be to completely reject frames with invaid data (for example, if the last tag extends beyond the end of the enclosing PDU). The enclosed approach is much more conservative: we simply prevent later IEs from overwriting the state from previous ones. This approach hopes that there might be some salient data in the IE stream before the corruption, and seeks to at least prevent that data from being overwritten. This approach will fix the case above. Further, we flag element structures that contain data we think might be corrupted, so that as we fill the mac80211 BSS structure, we try not to replace data from an un-corrupted probe response with that of a corrupted beacon, for example. Short of any statistics gathering in the various forms of AP breakage, it's not possible to ascertain the side effects of more stringent discarding of data. Signed-off-by:
Paul Stewart <pstew@chromium.org> Cc: Sam Leffler <sleffler@chromium.org> Cc: Eliad Peller <eliad@wizery.com> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
- 06 Mar, 2012 8 commits
-
-
Samuel Ortiz authored
Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Samuel Ortiz authored
Signed-off-by:
-
Samuel Ortiz authored
Signed-off-by:
-
Samuel Ortiz authored
The socket local pointer needs to be set to NULL when the adapter is removed or the MAC goes down. If the socket release code is called after such an event, the socket reference count still needs to be decreased in order for the socket to eventually be freed. Signed-off-by:
-
Samuel Ortiz authored
When calling nfc_dep_link_up, we implicitely are in initiator mode. Which means we also can provide the general bytes as a function argument, as all drivers will eventually request them. Signed-off-by:
-
Samuel Ortiz authored
We just don't do anything with it when parsing the general bytes. We handle it from the CONNECT reception code. Signed-off-by:
-
Samuel Ortiz authored
The parent socket (the bound one) could be freed before its children, so we should unlink the children without trying to reach it through the parent. Signed-off-by:
-
Samuel Ortiz authored
Signed-off-by:
-
