- 28 10月, 2009 1 次提交
-
-
由 Samuel Ortiz 提交于
We set the initial CT (Temperature control) value to 110 degrees. If the chip goes over that threshold, we hard block the device which will turn it down. At the same time we schedule a 30 seconds delayed work that unblock the device (and userspace is supposed to bring it back up), hoping that the chip will have cooled down by then... Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com> Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 02 9月, 2009 1 次提交
-
-
由 Zhu Yi 提交于
The device sends connection terminated and [re]association success (or failure) events when roaming occours. The patch uses cfg80211_roamed instead of cfg80211_connect_result to notify SME for roaming. Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 8月, 2009 2 次提交
-
-
由 Zhu Yi 提交于
UMAC only allows us to set default key for WEP and auth type is not 802.1X or RSNA. This patch fixes iwmc3200wifi for 802.1X with WEP104. Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Zhu Yi 提交于
We should only set the static_key flag for open and legacy authentication types. It should not be set for 802.1X and TKIP. Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 04 8月, 2009 1 次提交
-
-
由 Julia Lawall 提交于
Error handling code following a kzalloc should free the allocated data. The semantic match that finds the problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r exists@ local idexpression x; statement S; expression E; identifier f,f1,l; position p1,p2; expression *ptr != NULL; @@ x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...); ... if (x == NULL) S <... when != x when != if (...) { <+...x...+> } ( x->f1 = E | (x->f1 == NULL || ...) | f(...,x->f1,...) ) ...> ( return \(0\|<+...x...+>\|ptr\); | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 25 7月, 2009 2 次提交
-
-
由 Zhu Yi 提交于
cfg80211 now guarantees keys are set after connecting. We can remove the key cache code from the driver now. Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Zhu Yi 提交于
We used to return the result of wait_event_interruptible_timeout() which is the remaining timeout on success. But this information is not used by any of its callers. So we just return 0 on success. This fixed a erroneous return value bug for iwm_set_key(). Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 11 7月, 2009 3 次提交
-
-
由 Zhu Yi 提交于
The patch changes coexist periodic calibration priority flag. It also set wireless mode to UMAC and set PM control flag to 0x1. Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NSamuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Samuel Ortiz 提交于
This patch implements the new cfg80211 privacy related hooks: add/get/set_key and the set_default_key one. With this implementation we can now call the wext-compat *encode* routines and reduce our own wext code. Signed-off-by: NSamuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Samuel Ortiz 提交于
When we're calling iwm_send_wifi_if_cmd() with the resp flag set, we're currently waiting on the mlme queue, waiting for some flags here and there to show up. This patch adds a wifi_ntfy bitmap, and when we're sending a wifi_if command expecting an answers, we wait synchronously for it to show up, on a dedicated queue. The wifi_ntfy bit is set when we receive the corresponding answer. Signed-off-by: NSamuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 5月, 2009 1 次提交
-
-
由 Zhu Yi 提交于
This driver supports Intel's full MAC wireless multicomm 802.11 hardware. Although the hardware is a 802.11agn device, we currently only support 802.11ag, in managed and ad-hoc mode (no AP mode for now). Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NSamuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-