* Re: [PATCH] cfg80211: update information elements in cached BSS struct
From: Johannes Berg @ 2010-12-09 12:47 UTC (permalink / raw)
To: Sven Neumann; +Cc: linux-wireless
In-Reply-To: <1291891690-26118-1-git-send-email-s.neumann@raumfeld.com>
On Thu, 2010-12-09 at 11:48 +0100, Sven Neumann wrote:
> When a cached BSS struct is updated because a new beacon was received,
> the code replaces the cached information elements by the IEs from the
> new beacon. However it did not update the pub.information_elements
> and pub.len_information_elements fields leaving them either pointing
> to the old beacon IEs or in an inconsistent state where the data is
> replaced by the new beacon IEs but len_information_elements still has
> its value from the first beacon.
>
> Fix this by updating the information elements fields if they are
> pointing to beacon IEs.
Err, no, this is intentional -- we want data from probe responses to
"win" and be displayed preferentially. If you look at the code that
dumps them out, that's what will happen.
If you need the most up-to-date beacon IEs, use (the equivalent of) "iw
wlan0 scan dump -b".
johannes
^ permalink raw reply
* [PATCH] cfg80211: update information elements in cached BSS struct
From: Sven Neumann @ 2010-12-09 10:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Sven Neumann
When a cached BSS struct is updated because a new beacon was received,
the code replaces the cached information elements by the IEs from the
new beacon. However it did not update the pub.information_elements
and pub.len_information_elements fields leaving them either pointing
to the old beacon IEs or in an inconsistent state where the data is
replaced by the new beacon IEs but len_information_elements still has
its value from the first beacon.
Fix this by updating the information elements fields if they are
pointing to beacon IEs.
Signed-off-by: Sven Neumann <s.neumann@raumfeld.com>
---
net/wireless/scan.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 503ebb8..629bfaa 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -465,6 +465,9 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
size_t used = dev->wiphy.bss_priv_size + sizeof(*res);
size_t ielen = res->pub.len_beacon_ies;
+ int information_elements_is_beacon_ies =
+ (found->pub.information_elements == found->pub.beacon_ies);
+
if (found->pub.beacon_ies &&
!found->beacon_ies_allocated &&
ksize(found) >= used + ielen) {
@@ -487,6 +490,11 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
found->pub.len_beacon_ies = ielen;
}
}
+
+ if (information_elements_is_beacon_ies) {
+ found->pub.information_elements = found->pub.beacon_ies;
+ found->pub.len_information_elements = found->pub.len_beacon_ies;
+ }
}
kref_put(&res->ref, bss_release);
--
1.7.1
^ permalink raw reply related
* [PATCH] wl12xx: add auto-arp support
From: Eliad Peller @ 2010-12-09 9:31 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
The auto-arp feature of wl12xx allows the firmware to automatically
response to arp requests asking for its ip.
in order to use it, we configure the arp response template and
enable the corresponding bit in wl1271_acx_arp_filter (along with
passing its ip)
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/wl12xx/acx.c | 4 +-
drivers/net/wireless/wl12xx/acx.h | 9 +++++-
drivers/net/wireless/wl12xx/cmd.c | 41 ++++++++++++++++++++++++++++
drivers/net/wireless/wl12xx/cmd.h | 2 +
drivers/net/wireless/wl12xx/init.c | 7 +++++
drivers/net/wireless/wl12xx/main.c | 24 +++++++++++++---
drivers/net/wireless/wl12xx/wl12xx_80211.h | 14 +++++++++
7 files changed, 93 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/acx.c b/drivers/net/wireless/wl12xx/acx.c
index 7cbaeb6..cc4068d 100644
--- a/drivers/net/wireless/wl12xx/acx.c
+++ b/drivers/net/wireless/wl12xx/acx.c
@@ -1041,7 +1041,7 @@ out:
return ret;
}
-int wl1271_acx_arp_ip_filter(struct wl1271 *wl, bool enable, __be32 address)
+int wl1271_acx_arp_ip_filter(struct wl1271 *wl, u8 enable, __be32 address)
{
struct wl1271_acx_arp_filter *acx;
int ret;
@@ -1057,7 +1057,7 @@ int wl1271_acx_arp_ip_filter(struct wl1271 *wl, bool enable, __be32 address)
acx->version = ACX_IPV4_VERSION;
acx->enable = enable;
- if (enable == true)
+ if (enable)
memcpy(acx->address, &address, ACX_IPV4_ADDR_SIZE);
ret = wl1271_cmd_configure(wl, ACX_ARP_IP_FILTER,
diff --git a/drivers/net/wireless/wl12xx/acx.h b/drivers/net/wireless/wl12xx/acx.h
index 75a6306..9cbc3f4 100644
--- a/drivers/net/wireless/wl12xx/acx.h
+++ b/drivers/net/wireless/wl12xx/acx.h
@@ -868,10 +868,15 @@ struct wl1271_acx_bet_enable {
#define ACX_IPV4_VERSION 4
#define ACX_IPV6_VERSION 6
#define ACX_IPV4_ADDR_SIZE 4
+
+/* bitmap of enabled arp_filter features */
+#define ACX_ARP_FILTER_ARP_FILTERING BIT(0)
+#define ACX_ARP_FILTER_AUTO_ARP BIT(1)
+
struct wl1271_acx_arp_filter {
struct acx_header header;
u8 version; /* ACX_IPV4_VERSION, ACX_IPV6_VERSION */
- u8 enable; /* 1 to enable ARP filtering, 0 to disable */
+ u8 enable; /* bitmap of enabled ARP filtering features */
u8 padding[2];
u8 address[16]; /* The configured device IP address - all ARP
requests directed to this IP address will pass
@@ -1168,7 +1173,7 @@ int wl1271_acx_init_mem_config(struct wl1271 *wl);
int wl1271_acx_init_rx_interrupt(struct wl1271 *wl);
int wl1271_acx_smart_reflex(struct wl1271 *wl);
int wl1271_acx_bet_enable(struct wl1271 *wl, bool enable);
-int wl1271_acx_arp_ip_filter(struct wl1271 *wl, bool enable, __be32 address);
+int wl1271_acx_arp_ip_filter(struct wl1271 *wl, u8 enable, __be32 address);
int wl1271_acx_pm_config(struct wl1271 *wl);
int wl1271_acx_keep_alive_mode(struct wl1271 *wl, bool enable);
int wl1271_acx_keep_alive_config(struct wl1271 *wl, u8 index, u8 tpl_valid);
diff --git a/drivers/net/wireless/wl12xx/cmd.c b/drivers/net/wireless/wl12xx/cmd.c
index 8e438e2..0106628 100644
--- a/drivers/net/wireless/wl12xx/cmd.c
+++ b/drivers/net/wireless/wl12xx/cmd.c
@@ -639,6 +639,47 @@ out:
return skb;
}
+int wl1271_cmd_build_arp_rsp(struct wl1271 *wl, __be32 ip_addr)
+{
+ int ret;
+ struct wl12xx_arp_rsp_template tmpl;
+ struct ieee80211_hdr_3addr *hdr;
+ struct arphdr *arp_hdr;
+
+ memset(&tmpl, 0, sizeof(tmpl));
+
+ /* mac80211 header */
+ hdr = &tmpl.hdr;
+ hdr->frame_control = cpu_to_le16(IEEE80211_FTYPE_DATA |
+ IEEE80211_STYPE_DATA |
+ IEEE80211_FCTL_TODS);
+ memcpy(hdr->addr1, wl->vif->bss_conf.bssid, ETH_ALEN);
+ memcpy(hdr->addr2, wl->vif->addr, ETH_ALEN);
+ memset(hdr->addr3, 0xff, ETH_ALEN);
+
+ /* llc layer */
+ memcpy(tmpl.llc_hdr, rfc1042_header, sizeof(rfc1042_header));
+ tmpl.llc_type = htons(ETH_P_ARP);
+
+ /* arp header */
+ arp_hdr = &tmpl.arp_hdr;
+ arp_hdr->ar_hrd = htons(ARPHRD_ETHER);
+ arp_hdr->ar_pro = htons(ETH_P_IP);
+ arp_hdr->ar_hln = ETH_ALEN;
+ arp_hdr->ar_pln = 4;
+ arp_hdr->ar_op = htons(ARPOP_REPLY);
+
+ /* arp payload */
+ memcpy(tmpl.sender_hw, wl->vif->addr, ETH_ALEN);
+ tmpl.sender_ip = ip_addr;
+
+ ret = wl1271_cmd_template_set(wl, CMD_TEMPL_ARP_RSP,
+ &tmpl, sizeof(tmpl), 0,
+ wl->basic_rate);
+
+ return ret;
+}
+
int wl1271_build_qos_null_data(struct wl1271 *wl)
{
struct ieee80211_qos_hdr template;
diff --git a/drivers/net/wireless/wl12xx/cmd.h b/drivers/net/wireless/wl12xx/cmd.h
index 111d112..2a1d9db 100644
--- a/drivers/net/wireless/wl12xx/cmd.h
+++ b/drivers/net/wireless/wl12xx/cmd.h
@@ -51,6 +51,7 @@ int wl1271_cmd_build_probe_req(struct wl1271 *wl,
const u8 *ie, size_t ie_len, u8 band);
struct sk_buff *wl1271_cmd_build_ap_probe_req(struct wl1271 *wl,
struct sk_buff *skb);
+int wl1271_cmd_build_arp_rsp(struct wl1271 *wl, __be32 ip_addr);
int wl1271_build_qos_null_data(struct wl1271 *wl);
int wl1271_cmd_build_klv_null_data(struct wl1271 *wl);
int wl1271_cmd_set_default_wep_key(struct wl1271 *wl, u8 id);
@@ -124,6 +125,7 @@ enum cmd_templ {
CMD_TEMPL_CTS, /*
* For CTS-to-self (FastCTS) mechanism
* for BT/WLAN coexistence (SoftGemini). */
+ CMD_TEMPL_ARP_RSP,
CMD_TEMPL_MAX = 0xff
};
diff --git a/drivers/net/wireless/wl12xx/init.c b/drivers/net/wireless/wl12xx/init.c
index 7949d34..0392e37 100644
--- a/drivers/net/wireless/wl12xx/init.c
+++ b/drivers/net/wireless/wl12xx/init.c
@@ -102,6 +102,13 @@ int wl1271_init_templates_config(struct wl1271 *wl)
if (ret < 0)
return ret;
+ ret = wl1271_cmd_template_set(wl, CMD_TEMPL_ARP_RSP, NULL,
+ sizeof
+ (struct wl12xx_arp_rsp_template),
+ 0, WL1271_RATE_AUTOMATIC);
+ if (ret < 0)
+ return ret;
+
for (i = 0; i < CMD_TEMPL_KLV_IDX_MAX; i++) {
ret = wl1271_cmd_template_set(wl, CMD_TEMPL_KLV, NULL,
WL1271_CMD_TEMPL_MAX_SIZE, i,
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index dc3a093..98e6b7b 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -2106,10 +2106,26 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,
__be32 addr = bss_conf->arp_addr_list[0];
WARN_ON(wl->bss_type != BSS_TYPE_STA_BSS);
- if (bss_conf->arp_addr_cnt == 1 && bss_conf->arp_filter_enabled)
- ret = wl1271_acx_arp_ip_filter(wl, true, addr);
- else
- ret = wl1271_acx_arp_ip_filter(wl, false, addr);
+ if (bss_conf->arp_addr_cnt == 1 &&
+ bss_conf->arp_filter_enabled) {
+ /*
+ * The template should have been configured only upon
+ * association. however, it seems that the correct ip
+ * isn't being set (when sending), so we have to
+ * reconfigure the template upon every ip change.
+ */
+ ret = wl1271_cmd_build_arp_rsp(wl, addr);
+ if (ret < 0) {
+ wl1271_warning("build arp rsp failed: %d", ret);
+ goto out_sleep;
+ }
+
+ ret = wl1271_acx_arp_ip_filter(wl,
+ (ACX_ARP_FILTER_ARP_FILTERING |
+ ACX_ARP_FILTER_AUTO_ARP),
+ addr);
+ } else
+ ret = wl1271_acx_arp_ip_filter(wl, 0, addr);
if (ret < 0)
goto out_sleep;
diff --git a/drivers/net/wireless/wl12xx/wl12xx_80211.h b/drivers/net/wireless/wl12xx/wl12xx_80211.h
index 1846280..8ee0d3a 100644
--- a/drivers/net/wireless/wl12xx/wl12xx_80211.h
+++ b/drivers/net/wireless/wl12xx/wl12xx_80211.h
@@ -2,6 +2,7 @@
#define __WL12XX_80211_H__
#include <linux/if_ether.h> /* ETH_ALEN */
+#include <linux/if_arp.h>
/* RATES */
#define IEEE80211_CCK_RATE_1MB 0x02
@@ -140,6 +141,19 @@ struct wl12xx_probe_req_template {
struct wl12xx_ie_rates ext_rates;
} __packed;
+struct wl12xx_arp_rsp_template {
+ struct ieee80211_hdr_3addr hdr;
+
+ u8 llc_hdr[sizeof(rfc1042_header)];
+ u16 llc_type;
+
+ struct arphdr arp_hdr;
+ u8 sender_hw[ETH_ALEN];
+ u32 sender_ip;
+ u8 target_hw[ETH_ALEN];
+ u32 target_ip;
+} __packed;
+
struct wl12xx_probe_resp_template {
struct ieee80211_header header;
--
1.7.0.4
^ permalink raw reply related
* Re: ath5k: Weird Retransmission Behaviour
From: Helmut Schaa @ 2010-12-09 9:21 UTC (permalink / raw)
To: Jonathan Guerin
Cc: Bob Copeland, Bruno Randolf, linux-wireless, ath5k-devel, nbd
In-Reply-To: <AANLkTimwprBJpnLM6_Qap1wSVboVJPQecAUgmzAnQhu-@mail.gmail.com>
On Wed, Dec 8, 2010 at 10:53 PM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
> I only seem to have Minstrel as the only available Rate Control
> algorithm in my kernel config?
PID is only selectable on embedded platforms:
config MAC80211_RC_PID
bool "PID controller based rate control algorithm" if EMBEDDED
Just remove the "if EMBEDDED" from net/mac8011/Kconfig and retry.
Helmut
^ permalink raw reply
* [PATCH] libertas: fix potential NULL-pointer dereference
From: Sven Neumann @ 2010-12-09 8:38 UTC (permalink / raw)
To: linux-wireless; +Cc: Dan Williams
The code wants to check if there's a channel and it is not disabled,
but it used to check if channel is not NULL and accessed the channel
struct if this check failed.
Signed-off-by: Sven Neumann <s.neumann@raumfeld.com>
---
drivers/net/wireless/libertas/cfg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index 373930a..113f4f2 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -619,7 +619,7 @@ static int lbs_ret_scan(struct lbs_private *priv, unsigned long dummy,
print_ssid(ssid_buf, ssid, ssid_len),
LBS_SCAN_RSSI_TO_MBM(rssi)/100);
- if (channel ||
+ if (channel &&
!(channel->flags & IEEE80211_CHAN_DISABLED))
cfg80211_inform_bss(wiphy, channel,
bssid, le64_to_cpu(*(__le64 *)tsfdesc),
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH v2] linux-firmware: brcm: Removed codeversion from firmware filenames.
From: Rafał Miłecki @ 2010-12-09 9:01 UTC (permalink / raw)
To: Henry Ptasinski
Cc: Greg KH, David Woodhouse, devel@linuxdriverproject.org,
Brett Rudley, grundler@google.com, linux-wireless@vger.kernel.org,
Roland Vossen, Dowan Kim, Arend Van Spriel, dcbw@redhat.com
In-Reply-To: <20101209013003.GB2243@broadcom.com>
W dniu 9 grudnia 2010 02:30 użytkownik Henry Ptasinski
<henryp@broadcom.com> napisał:
> Yes, I omitted the earlier part since those comments were not directly about
> the existing Broadcom license. But to be complete:
Yes, this part explained why I mentioned distos problems.
> Obviously that's taking some time,
> and I don't have any resolution yet, but I'll keep working on it.
Great, thanks :)
--
Rafał
^ permalink raw reply
* Re: carl9170 connect/disconnect loop
From: Christian Lamparter @ 2010-12-09 6:50 UTC (permalink / raw)
To: Wade Fitzpatrick; +Cc: linux-wireless
In-Reply-To: <4D006D31.4000604@gmail.com>
On Thursday 09 December 2010 06:46:25 Wade Fitzpatrick wrote:
>
> On 07/12/10 10:32, Christian Lamparter wrote:
> > mac80211 comes with some powerful debug tools.
> > Since you get the disconnects fairly quickly, you should
> > setup a wlan monitor.
> >
> > <http://linuxwireless.org/en/users/Documentation/iw#Adding_interfaces_with_iw>
> > iw dev wlan1 interface add mon type monitor flags otherbss control
> > ifconfig mon up
> >
> I'm getting a kernel panic just after bringing up the interface with
> ifconfig. It mentions this info:
>
> skb_under_panic ...
> kernel BUG at net/core/skbuff.c:146!
> Call Trace:
> <IRQ>
> skb_defer_rx_timestamp
> netif_receive_skb
never seen this one before, but maybe I was just lucky.
Because googling the BUG actually gave me this:
http://patchwork.ozlabs.org/patch/73998/ (scroll down to the bottom)
Best regards,
Christian
^ permalink raw reply
* Re: [PATCH 2/3] iwlagn: implement layout-agnostic EEPROM reading
From: Guy, Wey-Yi @ 2010-12-09 6:30 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Berg, Johannes
In-Reply-To: <20101209014850.GA2915@tuxdriver.com>
On Wed, 2010-12-08 at 17:48 -0800, John W. Linville wrote:
> On Wed, Dec 08, 2010 at 03:33:11PM -0800, Guy, Wey-Yi wrote:
> > On Wed, 2010-12-08 at 12:19 -0800, John W. Linville wrote:
> > > On Tue, Dec 07, 2010 at 11:45:18AM -0800, Guy, Wey-Yi wrote:
>
> > > > So it is really judgment call, we plan to release both 6005 and 6030
> > > > uCode in the next few weeks and hardware should be on the market early
> > > > next year. If by the time when hardware become available, distro already
> > > > move to .38, then I am ok with it. What you think?
> > >
> > > What about a patch to disable those devices in 2.6.37, and leave the
> > > existing EEPROM code alone for that release?
> > >
> >
> > I don't think it is an option to disable all the new devices for .37
> > since we commit to support them in .37 kernel,
>
> It certainly is an option. Missing hardware support for one release
> versus potentially destabilizing all existing iwlwifi users seems
> like an obvious trade-off to me. I trust Johannes, of course, but
> we all make subtle mistakes from time to time.
>
> > How about re-work the patch to keep the orig. EEPROM reading method for
> > older devices, but using new EEPROM method for the newer devices
> > (6005/6030/...). it that work for .37 kernel?
>
> I suppose this could work, although it sounds like an even bigger
> patch. I guess we would need to see the patch.
>
as matter as fact, I think the patch will be smaller since the old code
will not be removed. I will ask Johannes to rework the patch and see if
it works for you
Thanks
Wey
^ permalink raw reply
* Re: carl9170 connect/disconnect loop
From: Wade Fitzpatrick @ 2010-12-09 5:46 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <201012070032.23135.chunkeey@googlemail.com>
On 07/12/10 10:32, Christian Lamparter wrote:
> mac80211 comes with some powerful debug tools.
> Since you get the disconnects fairly quickly, you should
> setup a wlan monitor.
>
> <http://linuxwireless.org/en/users/Documentation/iw#Adding_interfaces_with_iw>
> iw dev wlan1 interface add mon type monitor flags otherbss control
> ifconfig mon up
>
I'm getting a kernel panic just after bringing up the interface with
ifconfig. It mentions this info:
skb_under_panic ...
kernel BUG at net/core/skbuff.c:146!
Call Trace:
<IRQ>
skb_defer_rx_timestamp
netif_receive_skb
$ uname -vmpir
2.6.36-ARCH #1 SMP PREEMPT Wed Nov 24 00:39:57 CET 2010 x86_64 AMD
Phenom(tm) II X4 955 Processor AuthenticAMD
^ permalink raw reply
* Re: orinoco_cs module and WPA not working
From: Giacomo Comes @ 2010-12-09 2:58 UTC (permalink / raw)
To: Dave Kilroy; +Cc: Giacomo Comes, linux-wireless
In-Reply-To: <AANLkTi=YawLwmnJeKX+dFe4mW1vbGbQnD2z4qQV0_3q3@mail.gmail.com>
On Wed, Dec 08, 2010 at 07:24:47PM +0000, Dave Kilroy wrote:
> On Mon, Dec 6, 2010 at 9:25 PM, Giacomo Comes <comes@naic.edu> wrote:
> > On Mon, Dec 06, 2010 at 06:43:04PM +0000, Dave Kilroy wrote:
> >> > The only issue still not fixed is the suspend/resume timeout.
> >> > Can you help also with that?
> >>
> >> Absolutely. With the latest patches, please just do a suspend resume,
> >> and post the dmesg output. Also let me know what the value of
> >> CONFIG_HERMES_CACHE_FW_ON_INIT is.
> >
> > CONFIG_HERMES_CACHE_FW_ON_INIT=y
> >
> > Attached is the outpur of dmesg after suspend/resume
> >
> > As you can see, the driver is unable to load the firmware,
> > therefore WPA is not available after resume:
>
> I've had a look at the log. Things aren't working as I'd expect.
> orinoco_init is being called on resume, which I don't think used to
> happen. That is what is causing the request for firmware, and the
> delay on resume.
>
> Instead I only expected orinoco_up to get called. I'll dig around to
> see whether that's a change in the kernel. It might be distro specific
> though. Do you know if suse works differently on suspend/resume? i.e
> explicitly 'modprobe -r'ing drivers
>
> Dave.
After more investigation, I have found that
suspend/resume works if I suspend the system from the console
with the command s2disk even if the orinoco module is loaded.
When I suspend the system from the desktop calling pm-hibernate
then there is the delay. Remember, the delay happens on suspend
AND on resume.
pm-hibernate will run a set of scripts in /usr/lib/pm-utils/sleep.d
One of these scripts (45pcmcia) executes:
"/sbin/pccardctl eject" on suspend and
"/sbin/pccardctl insert" on resume.
If I disable this script, then suspend/resume works properly.
I wonder if there are other pcmcia wireles cards that suffer
the same problem?
What is, in your opinion, the proper way to proceed?
To change something in the orinoco driver? Modify pm-utils?
Something else?
Giacomo
^ permalink raw reply
* ath5k: IBSS Join Fail
From: Jonathan Guerin @ 2010-12-09 2:36 UTC (permalink / raw)
To: linux-wireless, ath5k-devel
Hi,
I'm currently running 2 Linux nodes. One is running kernel version
2.6.37-rc2, the other -rc5. I'm finding that the rc5 node refuses to
join the IBSS, and simply ignores any probe requests from other
stations. The card is working fine (i.e. I can see other frames coming
up on a monitor-mode interface). The rc2 station sends out probe
requests upon joining the IBSS, but the rc5 station does not.
Reverting the rc5 station to rc2 means that it joins the IBSS
correctly. I'm having a look through the commits to see if any changes
occurred which may affect an IBSS join. I realise I could also bisect,
but it takes me 40mins to rebuild a kernel, so I'm just wondering if
anyone can think of something I can start the search on to fix this?
Cheers,
--
Jonathan Guerin
^ permalink raw reply
* Re: [PATCH 2/3] iwlagn: implement layout-agnostic EEPROM reading
From: John W. Linville @ 2010-12-09 1:48 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Berg, Johannes
In-Reply-To: <1291851191.10280.174.camel@wwguy-ubuntu>
On Wed, Dec 08, 2010 at 03:33:11PM -0800, Guy, Wey-Yi wrote:
> On Wed, 2010-12-08 at 12:19 -0800, John W. Linville wrote:
> > On Tue, Dec 07, 2010 at 11:45:18AM -0800, Guy, Wey-Yi wrote:
> > > So it is really judgment call, we plan to release both 6005 and 6030
> > > uCode in the next few weeks and hardware should be on the market early
> > > next year. If by the time when hardware become available, distro already
> > > move to .38, then I am ok with it. What you think?
> >
> > What about a patch to disable those devices in 2.6.37, and leave the
> > existing EEPROM code alone for that release?
> >
>
> I don't think it is an option to disable all the new devices for .37
> since we commit to support them in .37 kernel,
It certainly is an option. Missing hardware support for one release
versus potentially destabilizing all existing iwlwifi users seems
like an obvious trade-off to me. I trust Johannes, of course, but
we all make subtle mistakes from time to time.
> How about re-work the patch to keep the orig. EEPROM reading method for
> older devices, but using new EEPROM method for the newer devices
> (6005/6030/...). it that work for .37 kernel?
I suppose this could work, although it sounds like an even bigger
patch. I guess we would need to see the patch.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH v2] linux-firmware: brcm: Removed codeversion from firmware filenames.
From: Henry Ptasinski @ 2010-12-09 1:30 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Greg KH, David Woodhouse, devel@linuxdriverproject.org,
Brett Rudley, grundler@google.com, linux-wireless@vger.kernel.org,
Roland Vossen, Dowan Kim, Arend Van Spriel, dcbw@redhat.com,
Henry Ptasinski
In-Reply-To: <AANLkTimXjLCLwznMDzT-KdX1qfHvdbpNpJPcNpmuZkOS@mail.gmail.com>
On Wed, Dec 08, 2010 at 04:28:31PM -0800, Rafał Miłecki wrote:
> 2010/12/9 Henry Ptasinski <henryp@broadcom.com>:
> > On Wed, Dec 08, 2010 at 02:23:49PM -0800, Greg KH wrote:
> >> On Wed, Dec 08, 2010 at 11:07:53PM +0100, Rafał Miłecki wrote:
> >> > 2010/12/8 Henry Ptasinski <henryp@broadcom.com>:
> >> > > Second attempt at cleaning up firmware filenames.
> >> > >
> >> > > The basename-apiversion-codeversion construction for firmware filenames is not
> >> > > used by most other firmware files, adds complexity, and is not providing any
> >> > > value. Renamed the firmware files using just basename-apiversion. Also, fixed
> >> > > WHENCE to have correct path to brcmfmac files.
> >> > >
> >> > > Signed-off-by: Henry Ptasinski <henryp@broadcom.com>
> >> >
> >> > Henry, I believe we got report that Red Hat can not include your
> >> > firmware anyway because of licensing. Can you change license to some
> >> > common one which allows providing your firmware with distributions?
> >>
> >> That's news to me, what specific licensing issue have you heard about
> >> here? Last I saw, the issues were resolved and everyone could
> >> redistribute this firmware.
> >
> > On a thread about other firmware, Dan Williams wrote:
> >
> >> There's an existing Broadcom license in linux-firmware.git, and it *may*
> >> be OK, but it's really, really long and given that other major companies
> >> adopted the "shorter is better" approach, it's hard to believe that all
> >> the existing Broadcom license text is actually needed.
> >
> > I'm not sure that translates to "can not include your firmware". Regardless, I
> > am trying to get our license simplified. Obviously that's taking some time,
> > and I don't have any resolution yet, but I'll keep working on it.
>
> You quoted just a selected part of Dan's message. Earlier he mentioned
> about Fedora's problems (sorry, I misremembered distro)
Yes, I omitted the earlier part since those comments were not directly about
the existing Broadcom license. But to be complete:
> That's not enough to allow Fedora to ship it. We'd need a clear license from
> Broadcom (ex the existing Intel or Marvell firmware licenses) before Fedora
> could feel comfortable about shipping it legally in all jurisdictions.
>
> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=LICENCE.mwl8k;h=3224e1bbfba8ccd1d980f57eb88378f20bb2d146;hb=HEAD
> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=LICENCE.libertas;h=1fd8766c26a170b50605455ae6f54b607baa12cf;hb=HEAD
>
> There's an existing Broadcom license in linux-firmware.git, and it *may* be
> OK, but it's really, really long and given that other major companies adopted
> the "shorter is better" approach, it's hard to believe that all the existing
> Broadcom license text is actually needed.
(via http://marc.info/?l=linux-wireless&m=128767431028798&w=2)
- Henry
^ permalink raw reply
* Re: Re-distributable 88w8335 Firmware?
From: Julian Calaby @ 2010-12-09 0:36 UTC (permalink / raw)
To: Dan Williams
Cc: linux-wireless, David.Woodhouse, Greg KH, linux-kernel,
Lennert Buytenhek, Holger Schurig, Markus Becker, andreamrl,
Denis Kirjanov, dwmw2
In-Reply-To: <1291853616.16839.10.camel@dcbw.foobar.com>
On Thu, Dec 9, 2010 at 11:13, Dan Williams <dcbw@redhat.com> wrote:
> I've converted the cb35 duplex firmware to binary and uploaded it to
> linux-firmware after receiving permission from Marvell to do so. Now
> lets get a driver :)
Yeah!
Well Done!
Thanks for all your work on this!
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: [PATCH] compat-wireless: make patches apply again
From: Luis R. Rodriguez @ 2010-12-09 0:28 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1291853727-7919-1-git-send-email-hauke@hauke-m.de>
On Wed, Dec 8, 2010 at 4:15 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> uninit is already set in netdev_attach_ops so it is not needed an extra time.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied and pushed, thanks!
Luis
^ permalink raw reply
* Re: [PATCH v2] linux-firmware: brcm: Removed codeversion from firmware filenames.
From: Rafał Miłecki @ 2010-12-09 0:28 UTC (permalink / raw)
To: Henry Ptasinski
Cc: Greg KH, David Woodhouse, devel@linuxdriverproject.org,
Brett Rudley, grundler@google.com, linux-wireless@vger.kernel.org,
Roland Vossen, Dowan Kim, Arend Van Spriel, dcbw
In-Reply-To: <20101208233527.GA2148@broadcom.com>
2010/12/9 Henry Ptasinski <henryp@broadcom.com>:
> On Wed, Dec 08, 2010 at 02:23:49PM -0800, Greg KH wrote:
>> On Wed, Dec 08, 2010 at 11:07:53PM +0100, Rafał Miłecki wrote:
>> > 2010/12/8 Henry Ptasinski <henryp@broadcom.com>:
>> > > Second attempt at cleaning up firmware filenames.
>> > >
>> > > The basename-apiversion-codeversion construction for firmware filenames is not
>> > > used by most other firmware files, adds complexity, and is not providing any
>> > > value. Renamed the firmware files using just basename-apiversion. Also, fixed
>> > > WHENCE to have correct path to brcmfmac files.
>> > >
>> > > Signed-off-by: Henry Ptasinski <henryp@broadcom.com>
>> >
>> > Henry, I believe we got report that Red Hat can not include your
>> > firmware anyway because of licensing. Can you change license to some
>> > common one which allows providing your firmware with distributions?
>>
>> That's news to me, what specific licensing issue have you heard about
>> here? Last I saw, the issues were resolved and everyone could
>> redistribute this firmware.
>
> On a thread about other firmware, Dan Williams wrote:
>
>> There's an existing Broadcom license in linux-firmware.git, and it *may*
>> be OK, but it's really, really long and given that other major companies
>> adopted the "shorter is better" approach, it's hard to believe that all
>> the existing Broadcom license text is actually needed.
>
> I'm not sure that translates to "can not include your firmware". Regardless, I
> am trying to get our license simplified. Obviously that's taking some time,
> and I don't have any resolution yet, but I'll keep working on it.
You quoted just a selected part of Dan's message. Earlier he mentioned
about Fedora's problems (sorry, I misremembered distro)
---------- Wiadomość przekazana dalej ----------
Od: Dan Williams <dcbw@redhat.com>
Data: 21 października 2010 17:21
Temat: Re: Request for free-distributable Broadcom's (G|LP)-PHY firmware
Do: Rafał Miłecki <zajec5@gmail.com>
DW: Henry Ptasinski <henryp@broadcom.com>, Brett Rudley
<brudley@broadcom.com>, Nohee Ko <noheek@broadcom.com>, Greg
Kroah-Hartman <gregkh@suse.de>, "linux-wireless@vger.kernel.org"
<linux-wireless@vger.kernel.org>, b43-dev
<b43-dev@lists.infradead.org>
That's not enough to allow Fedora to ship it. We'd need a clear license
from Broadcom (ex the existing Intel or Marvell firmware licenses)
before Fedora could feel comfortable about shipping it legally in all
jurisdictions.
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=LICENCE.mwl8k;h=3224e1bbfba8ccd1d980f57eb88378f20bb2d146;hb=HEAD
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=LICENCE.libertas;h=1fd8766c26a170b50605455ae6f54b607baa12cf;hb=HEAD
There's an existing Broadcom license in linux-firmware.git, and it *may*
be OK, but it's really, really long and given that other major companies
adopted the "shorter is better" approach, it's hard to believe that all
the existing Broadcom license text is actually needed.
^ permalink raw reply
* [PATCH] mwifiex: remove struct ieeetypes_sub_band_set from ieee.h
From: Bing Zhao @ 2010-12-09 0:20 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Johannes Berg, Amitkumar Karwar, Kiran Divekar,
Frank Huang, Bing Zhao
From: Amitkumar Karwar <akarwar@marvell.com>
use "struct ieee80211_country_ie_triplet" instead.
Also remove "enum MWIFIEX_802_11_NETWORK_TYPE"
and bss_desc->network_type_use.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/cfg80211.c | 35 ++++++++++++---------------
drivers/net/wireless/mwifiex/fw.h | 2 +-
drivers/net/wireless/mwifiex/ieee.h | 17 +------------
drivers/net/wireless/mwifiex/join.c | 2 -
drivers/net/wireless/mwifiex/main.h | 5 ++-
drivers/net/wireless/mwifiex/scan.c | 2 -
drivers/net/wireless/mwifiex/sta_cmd.c | 17 ++++++-------
drivers/net/wireless/mwifiex/sta_cmdresp.c | 16 ++++++------
8 files changed, 38 insertions(+), 58 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
index 4a42493..7861cb7 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -1658,10 +1658,11 @@ mwifiex_11d_set_domain_info(struct mwifiex_private *priv)
*/
void mwifiex_send_domain_info_cmd_fw(struct wiphy *wiphy)
{
- u8 no_of_sub_band = 0;
- u8 no_of_parsed_chan = 0;
- u8 first_chan = 0, next_chan = 0, max_pwr = 0;
- u8 i, flag = 0;
+ u8 no_of_triplet = 0;
+ struct ieee80211_country_ie_triplet *t;
+ u8 no_of_parsed_chan = 0;
+ u8 first_chan = 0, next_chan = 0, max_pwr = 0;
+ u8 i, flag = 0;
enum ieee80211_band band;
struct ieee80211_supported_band *sband;
struct ieee80211_channel *ch;
@@ -1704,13 +1705,11 @@ void mwifiex_send_domain_info_cmd_fw(struct wiphy *wiphy)
next_chan++;
no_of_parsed_chan++;
} else {
- domain_info->sub_band[no_of_sub_band]
- .first_chan = first_chan;
- domain_info->sub_band[no_of_sub_band]
- .no_of_chan = no_of_parsed_chan;
- domain_info->sub_band[no_of_sub_band]
- .max_tx_pwr = max_pwr;
- no_of_sub_band++;
+ t = &domain_info->triplet[no_of_triplet];
+ t->chans.first_channel = first_chan;
+ t->chans.num_channels = no_of_parsed_chan;
+ t->chans.max_power = max_pwr;
+ no_of_triplet++;
first_chan = (u32) ch->hw_value;
next_chan = first_chan;
max_pwr = ch->max_power;
@@ -1719,16 +1718,14 @@ void mwifiex_send_domain_info_cmd_fw(struct wiphy *wiphy)
}
if (flag) {
- domain_info->sub_band[no_of_sub_band]
- .first_chan = first_chan;
- domain_info->sub_band[no_of_sub_band]
- .no_of_chan = no_of_parsed_chan;
- domain_info->sub_band[no_of_sub_band]
- .max_tx_pwr = max_pwr;
- no_of_sub_band++;
+ t = &domain_info->triplet[no_of_triplet];
+ t->chans.first_channel = first_chan;
+ t->chans.num_channels = no_of_parsed_chan;
+ t->chans.max_power = max_pwr;
+ no_of_triplet++;
}
- domain_info->no_of_sub_band = no_of_sub_band;
+ domain_info->no_of_triplet = no_of_triplet;
/* Set domain info */
ret = mwifiex_11d_set_domain_info(priv);
if (ret)
diff --git a/drivers/net/wireless/mwifiex/fw.h b/drivers/net/wireless/mwifiex/fw.h
index 95b3d2f..d8f4011 100644
--- a/drivers/net/wireless/mwifiex/fw.h
+++ b/drivers/net/wireless/mwifiex/fw.h
@@ -1083,7 +1083,7 @@ struct host_cmd_ds_802_11_bg_scan_query_rsp {
struct mwifiex_ietypes_domain_param_set {
struct mwifiex_ie_types_header header;
u8 country_code[COUNTRY_CODE_LEN];
- struct ieeetypes_sub_band_set sub_band[1];
+ struct ieee80211_country_ie_triplet triplet[1];
} __attribute__ ((packed));
struct host_cmd_ds_802_11d_domain_info {
diff --git a/drivers/net/wireless/mwifiex/ieee.h b/drivers/net/wireless/mwifiex/ieee.h
index ed9e03d..3245f17 100644
--- a/drivers/net/wireless/mwifiex/ieee.h
+++ b/drivers/net/wireless/mwifiex/ieee.h
@@ -24,12 +24,6 @@
#define MWIFIEX_SUPPORTED_RATES_EXT 32
-enum MWIFIEX_802_11_NETWORK_TYPE {
- MWIFIEX_802_11_FH,
- MWIFIEX_802_11_DS,
- MWIFIEX_802_11_NETWORK_TYPE_MAX
-};
-
#define IEEE_MAX_IE_SIZE 256
struct ieee_types_header {
@@ -222,14 +216,8 @@ struct ieee_types_wmm_parameter {
struct ieee_types_wmm_ac_parameters ac_params[IEEE80211_MAX_QUEUES];
} __attribute__ ((packed));
-#define MWIFIEX_MAX_SUBBAND_802_11D 83
-#define COUNTRY_CODE_LEN 3
-
-struct ieeetypes_sub_band_set {
- u8 first_chan;
- u8 no_of_chan;
- u8 max_tx_pwr;
-} __attribute__ ((packed));
+#define MWIFIEX_MAX_TRIPLET_802_11D 83
+#define COUNTRY_CODE_LEN 3
struct ieee_htcap {
__le16 ht_cap_info;
@@ -301,7 +289,6 @@ struct mwifiex_bssdescriptor {
u16 beacon_period;
u32 atim_window;
u8 erp_flags;
- enum MWIFIEX_802_11_NETWORK_TYPE network_type_use;
u32 bss_mode;
u8 supported_rates[MWIFIEX_SUPPORTED_RATES];
u8 data_rates[MWIFIEX_SUPPORTED_RATES];
diff --git a/drivers/net/wireless/mwifiex/join.c b/drivers/net/wireless/mwifiex/join.c
index 917f368..2888f54 100644
--- a/drivers/net/wireless/mwifiex/join.c
+++ b/drivers/net/wireless/mwifiex/join.c
@@ -973,8 +973,6 @@ mwifiex_cmd_802_11_ad_hoc_start(struct mwifiex_private *priv,
&adhoc_start->phy_param_set,
sizeof(union ieee_types_phy_param_set));
- bss_desc->network_type_use = MWIFIEX_802_11_DS;
-
/* Set IBSS param set */
/** IBSS parameter IE Id */
#define IBSS_PARA_IE_ID 6
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index 285cbc0..620616a 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -303,8 +303,9 @@ enum state_11d_t {
struct mwifiex_802_11d_domain_reg {
u8 country_code[COUNTRY_CODE_LEN];
- u8 no_of_sub_band;
- struct ieeetypes_sub_band_set sub_band[MWIFIEX_MAX_SUBBAND_802_11D];
+ u8 no_of_triplet;
+ struct ieee80211_country_ie_triplet
+ triplet[MWIFIEX_MAX_TRIPLET_802_11D];
};
struct mwifiex_vendor_spec_cfg_ie {
diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
index 8ed3677..d69a6cb 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -1497,7 +1497,6 @@ mwifiex_interpret_bss_desc_with_ie(struct mwifiex_adapter *adapter,
case WLAN_EID_FH_PARAMS:
fh_param_set =
(struct ieee_types_fh_param_set *) current_ptr;
- bss_entry->network_type_use = MWIFIEX_802_11_FH;
memcpy(&bss_entry->phy_param_set.fh_param_set,
fh_param_set,
sizeof(struct ieee_types_fh_param_set));
@@ -1507,7 +1506,6 @@ mwifiex_interpret_bss_desc_with_ie(struct mwifiex_adapter *adapter,
ds_param_set =
(struct ieee_types_ds_param_set *) current_ptr;
- bss_entry->network_type_use = MWIFIEX_802_11_DS;
bss_entry->channel = ds_param_set->current_chan;
memcpy(&bss_entry->phy_param_set.ds_param_set,
diff --git a/drivers/net/wireless/mwifiex/sta_cmd.c b/drivers/net/wireless/mwifiex/sta_cmd.c
index 955b960..9a87a2a 100644
--- a/drivers/net/wireless/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/mwifiex/sta_cmd.c
@@ -965,11 +965,11 @@ mwifiex_cmd_802_11d_domain_info(struct mwifiex_private *priv,
&cmd->params.domain_info;
struct mwifiex_ietypes_domain_param_set *domain =
&domain_info->domain;
- u8 no_of_sub_band = adapter->domain_reg.no_of_sub_band;
+ u8 no_of_triplet = adapter->domain_reg.no_of_triplet;
ENTER();
- PRINTM(MINFO, "11D: no_of_sub_band=0x%x\n", no_of_sub_band);
+ PRINTM(MINFO, "11D: no_of_triplet=0x%x\n", no_of_triplet);
cmd->command = cpu_to_le16(HostCmd_CMD_802_11D_DOMAIN_INFO);
domain_info->action = cpu_to_le16(cmd_action);
@@ -989,15 +989,14 @@ mwifiex_cmd_802_11d_domain_info(struct mwifiex_private *priv,
adapter->domain_reg.country_code,
sizeof(domain->country_code));
- domain->header.len = cpu_to_le16((no_of_sub_band *
- sizeof(struct ieeetypes_sub_band_set)) +
+ domain->header.len = cpu_to_le16((no_of_triplet *
+ sizeof(struct ieee80211_country_ie_triplet)) +
sizeof(domain->country_code));
- if (no_of_sub_band) {
- memcpy(domain->sub_band,
- adapter->domain_reg.sub_band,
- no_of_sub_band *
- sizeof(struct ieeetypes_sub_band_set));
+ if (no_of_triplet) {
+ memcpy(domain->triplet, adapter->domain_reg.triplet,
+ no_of_triplet *
+ sizeof(struct ieee80211_country_ie_triplet));
cmd->size = cpu_to_le16(sizeof(domain_info->action) +
le16_to_cpu(domain->header.len) +
diff --git a/drivers/net/wireless/mwifiex/sta_cmdresp.c b/drivers/net/wireless/mwifiex/sta_cmdresp.c
index ed8e1aa..d5b8ef0 100644
--- a/drivers/net/wireless/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/mwifiex/sta_cmdresp.c
@@ -1074,26 +1074,26 @@ mwifiex_ret_802_11d_domain_info(struct mwifiex_private *priv,
&resp->params.domain_info_resp;
struct mwifiex_ietypes_domain_param_set *domain = &domain_info->domain;
u16 action = le16_to_cpu(domain_info->action);
- u8 no_of_sub_band = 0;
+ u8 no_of_triplet = 0;
ENTER();
/* Dump domain info response data */
HEXDUMP("11D: DOMAIN Info Rsp Data", (u8 *) resp, resp->size);
- no_of_sub_band =
+ no_of_triplet =
(u8) ((le16_to_cpu(domain->header.len) -
3) / sizeof(struct
- ieeetypes_sub_band_set));
+ ieee80211_country_ie_triplet));
/* Country code is 3 bytes */
- PRINTM(MINFO, "11D Domain Info Resp: no_of_sub_band=%d\n",
- no_of_sub_band);
+ PRINTM(MINFO, "11D Domain Info Resp: no_of_triplet=%d\n",
+ no_of_triplet);
- if (no_of_sub_band > MWIFIEX_MAX_SUBBAND_802_11D) {
- PRINTM(MWARN, "11D: Invalid number of subbands %d "
+ if (no_of_triplet > MWIFIEX_MAX_TRIPLET_802_11D) {
+ PRINTM(MWARN, "11D: Invalid number of triplets %d "
"returned!!\n",
- no_of_sub_band);
+ no_of_triplet);
LEAVE();
return MWIFIEX_STATUS_FAILURE;
}
--
1.7.0.2
^ permalink raw reply related
* compat-wireless-2.6.37-rc5 released
From: Luis R. Rodriguez @ 2010-12-09 0:15 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-kernel, linux-bluetooth
We're closing in on the 2.6.37 release, now at rc5, so I'll start
making two releases, a vanilla release and one which has more stuff.
For now I'll just suck in all pending stable patches (all patches
marked with Cc: stable@kernel.org on linux-next.git, not only
Atheros', everyone's). This is:
pending-stable/0001-cfg80211-pass-the-reg-hint-initiator-to-helpers.patch
pending-stable/0002-cfg80211-fix-allowing-country-IEs-for-WIPHY_FLAG_STR.patch
pending-stable/0003-cfg80211-fix-disabling-channels-based-on-hints.patch
pending-stable/0004-ath9k_hw-fix-potential-spurious-tx-error-bit-interpr.patch
pending-stable/0005-ath9k-simplify-hw-reset-locking.patch
pending-stable/0006-ath9k-move-the-PCU-lock-to-the-sc-structure.patch
pending-stable/0007-ath9k-content-DMA-start-stop-through-the-PCU-lock.patch
pending-stable/0008-ath9k_hw-Fix-XPABIAS-level-configuration-for-AR9003.patch
pending-stable/0009-ath9k-Fix-bug-in-delimiter-padding-computation.patch
pending-stable/0010-ath9k-Disable-SWBA-interrupt-on-remove_interface.patch
pending-stable/0011-mac80211-Fix-STA-disconnect-due-to-MIC-failure.patch
pending-stable/0012-ath9k-Fix-STA-disconnect-issue-due-to-received-MIC-f.patch
pending-stable/0013-ath9k-Fix-bug-in-reading-input-gpio-state-for-ar9003.patch
pending-stable/0014-ath9k_hw-fix-endian-issues-with-CTLs-on-AR9003.patch
You can find the vanilla [1] and extra pending-stable [2] releass on
the stable download page [3] along with the respective ChangeLog of
all:
* The kernel components
* compat-wireless
* compat
In later releases we will have to consider if we want to cherry pick
anything extra or leave them as is. These few patches seem tempting to
suck in:
01-ath9k-OTP.patch
03-ath9k-no-aggr-VO.patch
04-mac80211-no-aggr-VO.patch
05-ath9k-Reintroduce-modparam-to-enable-btcoex.patch
06-ath9k_hw-fix-A-MPDU-key-search-issues-on-AR9003.patch
Particularly it is now known AR9003 devices will only ship with OTP
so.. it seems to make sense to actually disable AR9003 on 36 and even
37 and only have it available with the OTP patch and above EEPROM
fixes. I'm inclined to just disregard all these and just let us get
AR9003 from 2.6.38.... but we already have users of AR9003 coming up
so this can't wait in practice now. This now goes compile-tested and
fixed for 2.6.31.
[1] http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.37/compat-wireless-2.6.37-rc5-2.tar.bz2
[2] http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.37/compat-wireless-2.6.37-rc5-2-s.tar.bz2
[3] http://wireless.kernel.org/en/users/Download/stable
[4] http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.37/ChangeLog-2.6.37-wireless
Luis
^ permalink raw reply
* [PATCH] compat-wireless: make patches apply again
From: Hauke Mehrtens @ 2010-12-09 0:15 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
uninit is already set in netdev_attach_ops so it is not needed an extra time.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/01-netdev.patch | 23 ++++++-----------------
patches/99-change-makefiles.patch | 5 +++--
2 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/patches/01-netdev.patch b/patches/01-netdev.patch
index c1833e3..fd0139e 100644
--- a/patches/01-netdev.patch
+++ b/patches/01-netdev.patch
@@ -23,7 +23,7 @@ without creating a headache on maintenance of the pathes.
if (unlikely(retval < 0)) {
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
-@@ -1343,7 +1343,7 @@ usbnet_probe (struct usb_interface *udev
+@@ -1360,7 +1360,7 @@ usbnet_probe (struct usb_interface *udev
net->features |= NETIF_F_HIGHDMA;
#endif
@@ -45,7 +45,7 @@ without creating a headache on maintenance of the pathes.
retval = rndis_set_oid(usbdev, OID_GEN_CURRENT_PACKET_FILTER, &tmp,
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
-@@ -711,7 +711,12 @@ static const struct net_device_ops ieee8
+@@ -689,7 +689,12 @@ static const struct net_device_ops ieee8
static void ieee80211_if_setup(struct net_device *dev)
{
ether_setup(dev);
@@ -59,7 +59,7 @@ without creating a headache on maintenance of the pathes.
dev->destructor = free_netdev;
}
-@@ -858,7 +863,7 @@ static void ieee80211_setup_sdata(struct
+@@ -836,7 +841,7 @@ static void ieee80211_setup_sdata(struct
/* and set some type-dependent values */
sdata->vif.type = type;
sdata->vif.p2p = false;
@@ -68,7 +68,7 @@ without creating a headache on maintenance of the pathes.
sdata->wdev.iftype = type;
sdata->control_port_protocol = cpu_to_be16(ETH_P_PAE);
-@@ -897,7 +902,7 @@ static void ieee80211_setup_sdata(struct
+@@ -875,7 +880,7 @@ static void ieee80211_setup_sdata(struct
break;
case NL80211_IFTYPE_MONITOR:
sdata->dev->type = ARPHRD_IEEE80211_RADIOTAP;
@@ -77,7 +77,7 @@ without creating a headache on maintenance of the pathes.
sdata->u.mntr_flags = MONITOR_FLAG_CONTROL |
MONITOR_FLAG_OTHER_BSS;
break;
-@@ -1148,6 +1153,8 @@ int ieee80211_if_add(struct ieee80211_lo
+@@ -1126,6 +1131,8 @@ int ieee80211_if_add(struct ieee80211_lo
return -ENOMEM;
dev_net_set(ndev, wiphy_net(local->hw.wiphy));
@@ -86,7 +86,7 @@ without creating a headache on maintenance of the pathes.
ndev->needed_headroom = local->tx_headroom +
4*6 /* four MAC addresses */
+ 2 + 2 + 2 + 2 /* ctl, dur, seq, qos */
-@@ -1156,6 +1163,7 @@ int ieee80211_if_add(struct ieee80211_lo
+@@ -1134,6 +1141,7 @@ int ieee80211_if_add(struct ieee80211_lo
- ETH_HLEN /* ethernet hard_header_len */
+ IEEE80211_ENCRYPT_HEADROOM;
ndev->needed_tailroom = IEEE80211_ENCRYPT_TAILROOM;
@@ -94,17 +94,6 @@ without creating a headache on maintenance of the pathes.
ret = dev_alloc_name(ndev, ndev->name);
if (ret < 0)
-@@ -1204,6 +1212,10 @@ int ieee80211_if_add(struct ieee80211_lo
- if (ret)
- goto fail;
-
-+#if (LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,28))
-+ ndev->uninit = ieee80211_teardown_sdata;
-+#endif
-+
- if (ieee80211_vif_is_mesh(&sdata->vif) &&
- params && params->mesh_id_len)
- ieee80211_sdata_set_mesh_id(sdata,
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -2163,7 +2163,7 @@ static int __devinit b44_init_one(struct
diff --git a/patches/99-change-makefiles.patch b/patches/99-change-makefiles.patch
index c75f4f2..5114869 100644
--- a/patches/99-change-makefiles.patch
+++ b/patches/99-change-makefiles.patch
@@ -13,7 +13,7 @@ only the wireless stuff.
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
-@@ -2,28 +2,7 @@
+@@ -2,29 +2,7 @@
# Makefile for USB Network drivers
#
@@ -41,6 +41,7 @@ only the wireless stuff.
-obj-$(CONFIG_USB_IPHETH) += ipheth.o
-obj-$(CONFIG_USB_SIERRA_NET) += sierra_net.o
-obj-$(CONFIG_USB_NET_CX82310_ETH) += cx82310_eth.o
+-obj-$(CONFIG_USB_NET_CDC_NCM) += cdc_ncm.o
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -88,5 +89,5 @@ only the wireless stuff.
-obj-$(CONFIG_WEXT_PRIV) += wext-priv.o
-
cfg80211-y += core.o sysfs.o radiotap.o util.o reg.o scan.o nl80211.o
- cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o
+ cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o mesh.o
cfg80211-$(CONFIG_CFG80211_DEBUGFS) += debugfs.o
--
1.7.1
^ permalink raw reply related
* Re: Re-distributable 88w8335 Firmware?
From: Dan Williams @ 2010-12-09 0:13 UTC (permalink / raw)
To: Julian Calaby
Cc: linux-wireless, David.Woodhouse, Greg KH, linux-kernel,
Lennert Buytenhek, Holger Schurig, Markus Becker, andreamrl,
Denis Kirjanov, dwmw2
In-Reply-To: <AANLkTiks65oAvVEu0Df4yeHNJm=cVnSfFeo=enxt-gpn@mail.gmail.com>
On Wed, 2010-11-24 at 16:26 +1100, Julian Calaby wrote:
> On Wed, Nov 24, 2010 at 16:10, Dan Williams <dcbw@redhat.com> wrote:
> > On Wed, 2010-11-24 at 15:48 +1100, Julian Calaby wrote:
> >> On Wed, Nov 24, 2010 at 15:13, Dan Williams <dcbw@redhat.com> wrote:
> >> > Malo supports the PCMCIA/CF variant of the 8385; not a PCI variant
> >> > AFAICT. I know of no PCI variant for the 8385, just CF, SDIO, and GSPI.
> >> > But I find it curious that malo supports 8335+8385, given that the
> >> > firmware interface of the 8385 and the 8335 are so different. Unless
> >> > they have special firmware, the 8385 is a fullmac device, while the 8335
> >> > is a softmac device. Enough differences exist that I'd expect them to
> >> > be driven by separate drivers, otherwise the code would be quite ugly.
> >> > Which is why we didn't try to shoehorn the 8335 or TopDog stuff into
> >> > libertas.
> >>
> >> You clearly know a hell of a lot more about the ins and outs of Marvel
> >> chipsets that I do. =)
> >
> > Eh, *some* of the chipsets :) Others (Lennert) know a lot more about
> > later versions than I do. But I never know everything or even enough of
> > anything :)
>
> I know exactly how you feel. =)
>
> >> I stand corrected.
> >>
> >> So, to amend my previous request: We're after firmware for the softmac
> >> 88w8335 chipset *only*.
> >>
> >> Though it may be nicer if Marvell were to bless Malo's firmware
> >> package (linked above) as this contains firmware for the PCI 88w8335,
> >> USB 88w8338 and a file which claims to be for the PCMCIA/CF 88w8385.
> >
> > Yeah, though honestly I'd rather have the duplex firmware from MSSII for
> > the 8335, since it can do AP mode too. That does leave the 8338 (USB?)
>
> Me too - and it'd mean that we don't have to do AP-mode firmware
> loading tricks like in mw8k. But if we can't get that then some
> firmware is better than none.
>
> > of course but we can probably get clarification on that too. As with
> > the 8335, I only have access to a 8335 Windows driver, but if we had a
> > firmware extractor tool, I believe the Marvell Extranet firmware license
> > covers embedded firmware from Windows .sys files too.
>
> I think I may have a simple firmware extractor at home that I pulled
> from *somewhere* when I was working on this last time. We can see if
> it does anything with those files. I believe I have at least two
> different Windows drivers at home - IIRC, one of them is *just* the
> files needed for this extractor.
I've converted the cb35 duplex firmware to binary and uploaded it to
linux-firmware after receiving permission from Marvell to do so. Now
lets get a driver :)
Dan
^ permalink raw reply
* Re: [PATCH v2] linux-firmware: brcm: Removed codeversion from firmware filenames.
From: Henry Ptasinski @ 2010-12-08 23:35 UTC (permalink / raw)
To: Greg KH
Cc: Rafał Miłecki, David Woodhouse,
devel@linuxdriverproject.org, Brett Rudley, grundler@google.com,
linux-wireless@vger.kernel.org, Roland Vossen, Dowan Kim,
Arend Van Spriel, dcbw
In-Reply-To: <20101208222349.GA31641@kroah.com>
On Wed, Dec 08, 2010 at 02:23:49PM -0800, Greg KH wrote:
> On Wed, Dec 08, 2010 at 11:07:53PM +0100, Rafał Miłecki wrote:
> > 2010/12/8 Henry Ptasinski <henryp@broadcom.com>:
> > > Second attempt at cleaning up firmware filenames.
> > >
> > > The basename-apiversion-codeversion construction for firmware filenames is not
> > > used by most other firmware files, adds complexity, and is not providing any
> > > value. Renamed the firmware files using just basename-apiversion. Also, fixed
> > > WHENCE to have correct path to brcmfmac files.
> > >
> > > Signed-off-by: Henry Ptasinski <henryp@broadcom.com>
> >
> > Henry, I believe we got report that Red Hat can not include your
> > firmware anyway because of licensing. Can you change license to some
> > common one which allows providing your firmware with distributions?
>
> That's news to me, what specific licensing issue have you heard about
> here? Last I saw, the issues were resolved and everyone could
> redistribute this firmware.
On a thread about other firmware, Dan Williams wrote:
> There's an existing Broadcom license in linux-firmware.git, and it *may*
> be OK, but it's really, really long and given that other major companies
> adopted the "shorter is better" approach, it's hard to believe that all
> the existing Broadcom license text is actually needed.
I'm not sure that translates to "can not include your firmware". Regardless, I
am trying to get our license simplified. Obviously that's taking some time,
and I don't have any resolution yet, but I'll keep working on it.
- Henry
^ permalink raw reply
* Re: [PATCH 2/3] iwlagn: implement layout-agnostic EEPROM reading
From: Guy, Wey-Yi @ 2010-12-08 23:33 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Berg, Johannes
In-Reply-To: <20101208201926.GF2423@tuxdriver.com>
Hi John,
On Wed, 2010-12-08 at 12:19 -0800, John W. Linville wrote:
> On Tue, Dec 07, 2010 at 11:45:18AM -0800, Guy, Wey-Yi wrote:
> > Hi John,
> >
> > On Tue, 2010-12-07 at 11:28 -0800, John W. Linville wrote:
> > > On Tue, Dec 07, 2010 at 09:37:07AM -0800, Wey-Yi Guy wrote:
> > > > From: Johannes Berg <johannes.berg@intel.com>
> > > >
> > > > The current EEPROM reading code has some layout
> > > > assumptions that now turned out to be false with
> > > > some newer versions of the EEPROM. Luckily, we
> > > > can avoid all such assumptions by using data in
> > > > the EEPROM itself, so implement using that.
> > > >
> > > > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> > > > Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> > >
> > > Is rewriting the EEPROM code really necessary for 2.6.37? This seems
> > > like a lot of code to potentially get wrong...
> > >
> >
> > I agree it is a lot of changes. It is necessary for 6005 and 6030
> > devices. I understand the Hardware is not out yet; but both devices is
> > already supported by .37; without this changes, the regulatory will have
> > issues.
> >
> > Yes, you are correct, this changes will also impact the older devices
> > (6000, 6050, 1000).
> >
> > So it is really judgment call, we plan to release both 6005 and 6030
> > uCode in the next few weeks and hardware should be on the market early
> > next year. If by the time when hardware become available, distro already
> > move to .38, then I am ok with it. What you think?
>
> What about a patch to disable those devices in 2.6.37, and leave the
> existing EEPROM code alone for that release?
>
I don't think it is an option to disable all the new devices for .37
since we commit to support them in .37 kernel,
How about re-work the patch to keep the orig. EEPROM reading method for
older devices, but using new EEPROM method for the newer devices
(6005/6030/...). it that work for .37 kernel?
Regards
Wey
^ permalink raw reply
* Re: [PATCH v2] linux-firmware: brcm: Removed codeversion from firmware filenames.
From: Greg KH @ 2010-12-08 22:23 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Henry Ptasinski, David Woodhouse, devel@linuxdriverproject.org,
Brett Rudley, grundler@google.com, linux-wireless@vger.kernel.org,
rvossen, dowan, arend
In-Reply-To: <AANLkTin70oBFYq8LMJYw6zc7oVF9-UXv=nn_ophx+L2S@mail.gmail.com>
On Wed, Dec 08, 2010 at 11:07:53PM +0100, Rafał Miłecki wrote:
> 2010/12/8 Henry Ptasinski <henryp@broadcom.com>:
> > Second attempt at cleaning up firmware filenames.
> >
> > The basename-apiversion-codeversion construction for firmware filenames is not
> > used by most other firmware files, adds complexity, and is not providing any
> > value. Renamed the firmware files using just basename-apiversion. Also, fixed
> > WHENCE to have correct path to brcmfmac files.
> >
> > Signed-off-by: Henry Ptasinski <henryp@broadcom.com>
>
> Henry, I believe we got report that Red Hat can not include your
> firmware anyway because of licensing. Can you change license to some
> common one which allows providing your firmware with distributions?
That's news to me, what specific licensing issue have you heard about
here? Last I saw, the issues were resolved and everyone could
redistribute this firmware.
Do you have a bugzilla number?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] linux-firmware: brcm: Removed codeversion from firmware filenames.
From: Rafał Miłecki @ 2010-12-08 22:07 UTC (permalink / raw)
To: Henry Ptasinski
Cc: David Woodhouse, devel@linuxdriverproject.org, Brett Rudley,
grundler@google.com, greg@kroah.com,
linux-wireless@vger.kernel.org, rvossen, dowan, arend
In-Reply-To: <20101208205000.GA30861@broadcom.com>
2010/12/8 Henry Ptasinski <henryp@broadcom.com>:
> Second attempt at cleaning up firmware filenames.
>
> The basename-apiversion-codeversion construction for firmware filenames is not
> used by most other firmware files, adds complexity, and is not providing any
> value. Renamed the firmware files using just basename-apiversion. Also, fixed
> WHENCE to have correct path to brcmfmac files.
>
> Signed-off-by: Henry Ptasinski <henryp@broadcom.com>
Henry, I believe we got report that Red Hat can not include your
firmware anyway because of licensing. Can you change license to some
common one which allows providing your firmware with distributions?
--
Rafał
^ permalink raw reply
* Re: ath5k: Weird Retransmission Behaviour
From: Jonathan Guerin @ 2010-12-08 21:53 UTC (permalink / raw)
To: Bob Copeland; +Cc: Bruno Randolf, linux-wireless, ath5k-devel, nbd
In-Reply-To: <AANLkTi=+bZbsZXR2v1AUKLEEAWGLpq-uNJXQ13t-Bf+D@mail.gmail.com>
On Thu, Dec 9, 2010 at 2:08 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Mon, Dec 6, 2010 at 3:14 AM, Bruno Randolf <br1@einfach.org> wrote:
>> But it seems weird that there are so many retransmissions. The default maximum
>> numbers of retransmissions should be 7 for short frames and 4 for long frames
>> (dot11[Short|Long]RetryLimit), and this is what is set as defaults in mac80211
>> (local->hw.conf.short_frame_max_tx_count). Seems we are getting many
>> retransmissions from minstel, i added some debug prints:
>>
>
> I posted a patch for this about a week ago to linux-wireless.
>
> AFAICT minstrel doesn't use these configuration parrameters
> at all (but PID does).
I only seem to have Minstrel as the only available Rate Control
algorithm in my kernel config?
Cheers,
Jonathan
>
> --
> Bob Copeland %% www.bobcopeland.com
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox