* [PATCH] libertas: sort and categorize entries in decl.h
From: Holger Schurig @ 2009-10-19 13:27 UTC (permalink / raw)
To: linux-wireless, John Linville, Dan Williams
Also make lbs_find_cfp_by_band_and_channel() as static, as it's only used
inside wext.c.
This now makes decl.h only contain declarations for functions that don't
have their own *.h file.
No function change.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
--- linux-wl.orig/drivers/net/wireless/libertas/decl.h
+++ linux-wl/drivers/net/wireless/libertas/decl.h
@@ -8,46 +8,30 @@
#include <linux/netdevice.h>
-#include "defs.h"
-
-extern const struct ethtool_ops lbs_ethtool_ops;
-
-/** Function Prototype Declaration */
struct lbs_private;
struct sk_buff;
struct net_device;
-struct cmd_ctrl_node;
-struct cmd_ds_command;
-int lbs_suspend(struct lbs_private *priv);
-void lbs_resume(struct lbs_private *priv);
-
-void lbs_send_tx_feedback(struct lbs_private *priv, u32 try_count);
-void lbs_queue_event(struct lbs_private *priv, u32 event);
-void lbs_notify_command_response(struct lbs_private *priv, u8 resp_idx);
-int lbs_enter_auto_deep_sleep(struct lbs_private *priv);
-int lbs_exit_auto_deep_sleep(struct lbs_private *priv);
+/* ethtool.c */
+extern const struct ethtool_ops lbs_ethtool_ops;
-u32 lbs_fw_index_to_data_rate(u8 index);
-u8 lbs_data_rate_to_fw_index(u32 rate);
-/** The proc fs interface */
+/* tx.c */
+void lbs_send_tx_feedback(struct lbs_private *priv, u32 try_count);
netdev_tx_t lbs_hard_start_xmit(struct sk_buff *skb,
struct net_device *dev);
+/* rx.c */
int lbs_process_rxed_packet(struct lbs_private *priv, struct sk_buff *);
-struct chan_freq_power *lbs_find_cfp_by_band_and_channel(
- struct lbs_private *priv,
- u8 band,
- u16 channel);
/* persistcfg.c */
void lbs_persist_config_init(struct net_device *net);
void lbs_persist_config_remove(struct net_device *net);
+
/* main.c */
struct lbs_private *lbs_add_card(void *card, struct device *dmdev);
void lbs_remove_card(struct lbs_private *priv);
@@ -55,5 +39,17 @@
void lbs_stop_card(struct lbs_private *priv);
void lbs_host_to_card_done(struct lbs_private *priv);
+int lbs_suspend(struct lbs_private *priv);
+void lbs_resume(struct lbs_private *priv);
+
+void lbs_queue_event(struct lbs_private *priv, u32 event);
+void lbs_notify_command_response(struct lbs_private *priv, u8 resp_idx);
+
+int lbs_enter_auto_deep_sleep(struct lbs_private *priv);
+int lbs_exit_auto_deep_sleep(struct lbs_private *priv);
+
+u32 lbs_fw_index_to_data_rate(u8 index);
+u8 lbs_data_rate_to_fw_index(u32 rate);
+
#endif
--- linux-wl.orig/drivers/net/wireless/libertas/scan.c
+++ linux-wl/drivers/net/wireless/libertas/scan.c
@@ -12,10 +12,10 @@
#include <net/lib80211.h>
#include "host.h"
-#include "decl.h"
#include "dev.h"
#include "scan.h"
#include "assoc.h"
+#include "wext.h"
#include "cmd.h"
//! Approximate amount of data needed to pass a scan result back to iwlist
--- linux-wl.orig/drivers/net/wireless/libertas/wext.c
+++ linux-wl/drivers/net/wireless/libertas/wext.c
@@ -86,7 +86,7 @@
* @param channel the channel for looking
* @return A pointer to struct chan_freq_power structure or NULL if not find.
*/
-struct chan_freq_power *lbs_find_cfp_by_band_and_channel(
+static struct chan_freq_power *lbs_find_cfp_by_band_and_channel(
struct lbs_private *priv,
u8 band,
u16 channel)
--
http://www.holgerschurig.de
^ permalink raw reply
* IBSS mode and scanning
From: Holger Schurig @ 2009-10-19 14:05 UTC (permalink / raw)
To: linux-wireless
Hi list !
I now try for the first time ever to do some IBSS/ADHOC
networking (so that I can implement this for libertas+cfg80211).
I noticed several things:
Documentation
-------------
http://linuxwireless.org/en/users/Documentation/iw doesn't have
any example. Via google, I found
http://linuxwireless.org/en/users/Documentation/iw/replace-iwconfig,
but this example is wrong, e.g. the frequency isn't specified.
As I'm not yet an authoritative instance for IBSS questions, I
won't fix those wiki pages --- yet.
Scanning while in IBSS mode?
----------------------------
I finally settled to use these commands:
dmesg -c >/dev/null
iw dev wlan0 set type ibss
ifconfig wlan0 192.168.1.2 up
iw --debug dev wlan0 ibss join ADHOC 2412
This seemed to work, but then I tried to look at the beacon. This
was just not possible using "iw":
iw dev wlan0 scan freq
iw dev wlan0 scan freq 2412
didn't work. But, oh wonder, it worked via "iwlist eth1 scan".
For me it looks like a but that I have to use a WEXT tool to
check for ADHOC beacons while in IBSS mode.
DMESG spamming
--------------
At first, my dmesg looked quite reasonable:
[22313.286690] phy0: device now idle
[22313.292241] phy0: device no longer idle - in use
[22313.292647] wlan0: Trigger new scan to find an IBSS to join
[22316.000249] wlan0: Trigger new scan to find an IBSS to join
[22320.000336] wlan0: Trigger new scan to find an IBSS to join
[22322.000444] wlan0: Creating new IBSS network, BSSID 4e:9d:b6:88:b7:9b
but then something started to spam it (Note that I did *NOT* yet operate another IBSS mode):
[22352.000210] wlan0: No active IBSS STAs - trying to scan for other IBSS networks with same SSID (merge)
[22352.032050] wlan0: No active IBSS STAs - trying to scan for other IBSS networks with same SSID (merge)
[22352.068034] wlan0: No active IBSS STAs - trying to scan for other IBSS networks with same SSID (merge)
[22352.108035] wlan0: No active IBSS STAs - trying to scan for other IBSS networks with same SSID (merge)
[22352.140057] wlan0: No active IBSS STAs - trying to scan for other IBSS networks with same SSID (merge)
[22352.176038] wlan0: No active IBSS STAs - trying to scan for other IBSS networks with same SSID (merg
...
ad-infinitum
--
http://www.holgerschurig.de
^ permalink raw reply
* How do you set the rate algorithm from the command line
From: Charles Gordon @ 2009-10-19 15:50 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm using mac80211 in an embedded system. I can build the driver so
that more than one wifi rate algorithm is included, and one is set as
the default. It is not clear to me how to set the rate algorithm at
run time. Is there a command line utility that does this?
Suppose I build the driver so that both the PID and Mistrel algorithms
are included, and the Minstrel algorithm is the default. How can I
switch to the PID algorithm at run time?
Thanks for your help.
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: Implement support for rt2800pci
From: Bartlomiej Zolnierkiewicz @ 2009-10-19 15:56 UTC (permalink / raw)
To: Ivo van Doorn
Cc: John Linville, linux-wireless, users, Alban Browaeys,
Benoit PAPILLAULT, Felix Fietkau, Luis Correia, Mattias Nissler,
Mark Asselstine, Xose Vazquez Perez, linux-kernel
In-Reply-To: <200910181859.22413.IvDoorn@gmail.com>
On Sunday 18 October 2009 18:59:21 Ivo van Doorn wrote:
> > I also used the opportunity to take a closer look at this driver and
> > it seems that it needlessly adds around 2 KLOC to kernel by duplicating
> > the common content of rt2800usb.h to rt2800pci.h instead of moving it
> > to the shared header (like it is done in the staging crap drivers):
> >
> > $ wc -l drivers/net/wireless/rt2x00/rt2800usb.h drivers/net/wireless/rt2x00/rt2800pci.h
> > 1951 drivers/net/wireless/rt2x00/rt2800usb.h
> > 1960 drivers/net/wireless/rt2x00/rt2800pci.h
> > 3911 total
> >
> > $ diff -u drivers/net/wireless/rt2x00/rt2800usb.h drivers/net/wireless/rt2x00/rt2800pci.h|diffstat
> > rt2800pci.h | 213 +++++++++++++++++++++++++++++++-----------------------------
> > 1 file changed, 111 insertions(+), 102 deletions(-)
>
> Creating rt2800.h with common register defines has been on the todo list for some time already,
> it will likely happen in the future, but until I get around to update my debugfs scripts the seperate
> rt2800pci.h and rt2800usb.h files make debugging and register analysis a bit easier.
Knowing that this driver has been in more-or-less unchanged state in your
tree for at least past half year I would say that there was a plenty of time
to fix this trivial issue..
Also are the said scripts available anywhere?
> > Similarly it looks like most of the code between rt2800usb.c and rt2800pci.c
> > could also be shared (up to another 2 KLOC saved) by adding abstraction layer
> > for accessing chipset registers over different buses (again like it is done
> > in staging crap drivers):
> >
> > $ wc -l drivers/net/wireless/rt2x00/rt2800usb.c drivers/net/wireless/rt2x00/rt2800pci.c
> > 3077 drivers/net/wireless/rt2x00/rt2800usb.c
> > 3323 drivers/net/wireless/rt2x00/rt2800pci.c
> > 6400 total
> >
> > $ diff -u drivers/net/wireless/rt2x00/rt2800usb.c drivers/net/wireless/rt2x00/rt2800pci.c|diffstat
> > rt2800pci.c | 2190 +++++++++++++++++++++++++++++++++---------------------------
> > 1 file changed, 1218 insertions(+), 972 deletions(-)
>
> I don't agree on this, for starters the whole "abstraction layer as done in the staging driver, really
> obfuscated the code in multiple areas, so whatever abstraction layer will be needed for rt2x00 it
> should be done much cleaner without the ugly defines and crap like that. So unless there is a _clean_
> and very _readable_ solution for such abstraction layer I might consider it.
Nobody was talking about duplicating any obfuscations present in the staging
driver -- adding struct rt2800_ops would be the preferred way to go.
> Secondly, you can't merge them until both drivers would correctly for all users/chipsets, because only
> then you can see what registers are initialized equaly, and where potential pitfalls are between the
> 2 busses.
Merge should be done sooner than later, or the drivers will diverge even
more, i.e. eFUSE support is needed for rt2800usb and is currently present
only in rt2800pci driver.
You can always split them later, OTOH joining diverged code bases is much
more difficult task (i.e. unifying rt2860, rt2870, rt3070 and rt3090 was)
Moreover rt2800pci doesn't work at all currently (why it is not labeled as
EXPERIMENTAL BTW, ditto for rt2800usb?) so there is no rush in merging it
and you have a plenty of time to improve your code for the usual kernel
standards (alternatively you may want consider submitting it for staging).
Could you please start looking into addressing valid review comments?
[ If you do not have a time for it, my offer to take over maintenance of
rt2800 drivers is still actual.. ]
^ permalink raw reply
* Re: [PATCH 10/10] iwlwifi: rework for static power save
From: Guy, Wey-Yi @ 2009-10-19 16:32 UTC (permalink / raw)
To: Tomas Winkler
Cc: Chatre, Reinette, linville@tuxdriver.com,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1ba2fa240910161615h75a74e13u8a31c3e49eae234a@mail.gmail.com>
Tom,
Thanks for the feedback, I will submit a cleanup patch to address this
mistake.
On Fri, 2009-10-16 at 16:15 -0700, Tomas Winkler wrote:
> > #include "iwl-commands.h"
> >
> > +#define IWL_CONN_LISTEN_INTERVAL 10
>
> There is already IWL_CONN_MAX_LISTEN_INTERVAL; defined
>
> Thanks
> Tomas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] mac80211: fix SME warning by removing stale BSS upon assoc failure
From: ASIC Felix @ 2009-10-19 16:37 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, Luis R. Rodriguez, Luis Rodriguez,
linux-wireless@vger.kernel.org
In-Reply-To: <20091016182039.GC6438@tuxdriver.com>
On Fri, 2009-10-16 at 14:20 -0400, John W. Linville wrote:
> On Fri, Oct 16, 2009 at 06:31:32PM +0900, Johannes Berg wrote:
> > On Wed, 2009-10-14 at 16:35 -0700, Luis R. Rodriguez wrote:
> >
> > > Well sure, but why do we want to keep the authentication present if
> > > association failed? And as a matter of fact it lingers there forever.
> > > Is that desired behaviour?
> >
> > Yes, well, the SME is supposed to clean it up or try the association
> > again (possibly with different parameters in the IEs, e.g. different WPA
> > settings). The cfg80211 SME certainly does so (it deauthenticates).
> >
> > > > > +++ b/net/mac80211/mlme.c
> > > > > @@ -1463,11 +1463,11 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
> > > > > if (status_code != WLAN_STATUS_SUCCESS) {
> > > > > printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
> > > > > sdata->dev->name, status_code);
> > > > > list_del(&wk->list);
> > > > > kfree(wk);
> > > > > - return RX_MGMT_CFG80211_ASSOC;
> > > > > + return RX_MGMT_CFG80211_DEAUTH;
> > > >
> > > > I'm sure this is correct. Maybe cfg80211 doesn't react properly to
> > > > getting an assoc frame with non-zero status?
> > >
> > > I see, will have to take a look when I get a chance then, not now though.
> >
> > > Actually can you elaborate a little on the logic here as to why
> > > we want to issue an association command with non-zero status to
> > > cfg80211 instead of just knocking off the current authentication
> > > and killing the BSS?
> >
> > Is the above sufficient? Btw, please don't talk about "killing the BSS",
> > you're not talking about a BSS struct but rather one of the mlme work
> > structs.
>
> So, should this patch be dropped? It is currently in w-t...
I'm still running the first w-t kernel with this fix
(master-2009-10-14), and haven't seen the sme warning I had been
complaining about for the past months, also: no connection drops.
Note I have _not_ run performance tests.
So this patch affects the sme issue. You guys will know where the
correct place is for fixing it.
By the way, (master-2009-10-14) is the best kernel for me since about
March/April this year. It looks like we're out of the rough again on
ath9k&mac80211.
Felix
^ permalink raw reply
* Re: Support for Broadcom's BCM4328 chip
From: Gábor Stefanik @ 2009-10-19 17:29 UTC (permalink / raw)
To: Russell Knighton; +Cc: Chriss Kalogeropoulos, linux-wireless
In-Reply-To: <279b980f0910191011p50064547r6d77a5ac32e22f93@mail.gmail.com>
2009/10/19 Russell Knighton <russell@knighton.me.uk>
>
> Great news that this is now truly under-way - but, at the risk of sounding cheeky, is there an estimated merge date on this (or any progress information you can share)? I have a broadcom BCM4322 and would like to get involved in any possible testing, or at the very least be able to check the progress on this.
>
> Thanks for all your hard work - your skill and efforts are highly appreciated by us end users!
>
> Russell
>
Only reverse-engineering is happening at this point - actual
development can only start once reverse-engineering is done. (And even
then, we will need to find someone to actually write the code for
N-PHY, as I'm not sure that I will have enough free time to do it
myself, and Michael seems to have practically abandoned the project.)
> 2009/10/18 Gábor Stefanik <netrolller.3d@gmail.com>
>>
>> On Sun, Oct 18, 2009 at 12:32 PM, Chriss Kalogeropoulos
>> <iz.iznogood@gmail.com> wrote:
>> > Hello,
>> >
>> > i have an i-mac using Broadcom's BCM4328 chip.
>> >
>> > lspci gives:
>> >
>> > 03:00.0 Network controller [0280]: Broadcom Corporation BCM4328
>> > 802.11a/b/g/n [14e4:4328] (rev 01)
>> >
>> > This must have been answered before but i thought to ask in case
>> > something has changed. Any hope on getting support on that chip with an
>> > open source driver ?
>> >
>> > Please cc me since i am not a subscriber on the list.
>> >
>> > Thanks in advance
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >
>>
>> This is an N-PHY card. Reverse-engineering of N-PHY cards is still in
>> progress (though it is finally really "in progress", and not stalled
>> anymore), and it needs to be finished (at least the G part) before we
>> can work on implementing it.
>>
>> --
>> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] rt2800pci.c : more ids
From: Ivo van Doorn @ 2009-10-19 17:31 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: linux-wireless, users
In-Reply-To: <4ADC3664.8050900@gmail.com>
Hi,
I have merged your previous rt2800pci patch before sending it
upstream. Please recheck and if required rebase your patch
to the new version.
Thanks,
Ivo
On Monday 19 October 2009, Xose Vazquez Perez wrote:
> On 10/13/2009 10:05 AM, Xose Vazquez Perez wrote:
>
> > stolen from windows inf file(09/05/2009, 1.04.07.0000)
> >
> > 0x1814, 0x3060
>
> apply this one instead,
> got 0x1462,0x89a from linux driver(2009_0903_RT3090_Linux_STA_v2.2.0.1)
>
> -thanks-
>
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
>
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: Implement support for rt2800pci
From: Ivo van Doorn @ 2009-10-19 17:42 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: John Linville, linux-wireless, users, Alban Browaeys,
Benoit PAPILLAULT, Felix Fietkau, Luis Correia, Mattias Nissler,
Mark Asselstine, Xose Vazquez Perez, linux-kernel
In-Reply-To: <200910191756.16579.bzolnier@gmail.com>
> > > I also used the opportunity to take a closer look at this driver and
> > > it seems that it needlessly adds around 2 KLOC to kernel by duplicating
> > > the common content of rt2800usb.h to rt2800pci.h instead of moving it
> > > to the shared header (like it is done in the staging crap drivers):
> > >
> > > $ wc -l drivers/net/wireless/rt2x00/rt2800usb.h drivers/net/wireless/rt2x00/rt2800pci.h
> > > 1951 drivers/net/wireless/rt2x00/rt2800usb.h
> > > 1960 drivers/net/wireless/rt2x00/rt2800pci.h
> > > 3911 total
> > >
> > > $ diff -u drivers/net/wireless/rt2x00/rt2800usb.h drivers/net/wireless/rt2x00/rt2800pci.h|diffstat
> > > rt2800pci.h | 213 +++++++++++++++++++++++++++++++-----------------------------
> > > 1 file changed, 111 insertions(+), 102 deletions(-)
> >
> > Creating rt2800.h with common register defines has been on the todo list for some time already,
> > it will likely happen in the future, but until I get around to update my debugfs scripts the seperate
> > rt2800pci.h and rt2800usb.h files make debugging and register analysis a bit easier.
>
> Knowing that this driver has been in more-or-less unchanged state in your
> tree for at least past half year I would say that there was a plenty of time
> to fix this trivial issue..
Well good to see you actually read the mails I send in this, and the previous, discussion regarding
the rt2800 development. Because that would have answered your question regarding the "plenty of time" part.
> Also are the said scripts available anywhere?
http://kernel.org/pub/linux/kernel/people/ivd/tools/
There is no howto for the scripts...
I have an updated script somewhere, but that is mostly performance fixes.
> > Secondly, you can't merge them until both drivers would correctly for all users/chipsets, because only
> > then you can see what registers are initialized equaly, and where potential pitfalls are between the
> > 2 busses.
>
> Merge should be done sooner than later, or the drivers will diverge even
> more, i.e. eFUSE support is needed for rt2800usb and is currently present
> only in rt2800pci driver.
Well nobody mentioned which USB chipsets require the eFuse EEPROM,
and I am not adding it until that is figured out.
> You can always split them later, OTOH joining diverged code bases is much
> more difficult task (i.e. unifying rt2860, rt2870, rt3070 and rt3090 was)
There have been way to many problems with the rt2800pci/usb drivers where
the ordering of the register initialization really matters. And those parts seem
to be different between rt2800pci/usb or at least they depend on different registers
to make it work.
So until that has been figured out we can try to unify the drivers then,
> Moreover rt2800pci doesn't work at all currently (why it is not labeled as
> EXPERIMENTAL BTW, ditto for rt2800usb?)
+config RT2800PCI
+ tristate "Ralink rt2800 (PCI/PCMCIA) support"
+ depends on (RT2800PCI_PCI || RT2800PCI_SOC) && EXPERIMENTAL
^^^^^^^^^
The same exists for RT2800USB....
> so there is no rush in merging it
> and you have a plenty of time to improve your code for the usual kernel
> standards (alternatively you may want consider submitting it for staging).
>
> Could you please start looking into addressing valid review comments?
Haven't I been answering all your points already?
> [ If you do not have a time for it, my offer to take over maintenance of
> rt2800 drivers is still actual.. ]
If I am going to hand over the maintainership to somebody else
(and don't worry I will in the near future), I will hand it over to somebody
who has experience with the rt2x00 driver (i.e. actually wrote code for
the drivers).
The second requirement is that the new maintainer needs to be interested
in _all_ rt2x00 drivers, and is willing to give the priority of the development
to those drivers rather then then staging drivers.
Ivo
^ permalink raw reply
* [PATCH] mac80211: fix ibss joining
From: Reinette Chatre @ 2009-10-19 21:55 UTC (permalink / raw)
To: johannes, linville; +Cc: linux-wireless, Reinette Chatre
From: Reinette Chatre <reinette.chatre@intel.com>
Recent commit "mac80211: fix logic error ibss merge bssid check" fixed
joining of ibss cell when static bssid is provided. In this case
ifibss->bssid is set before the cell is joined and comparing that address
to a bss should thus always succeed. Unfortunately this change broke the
other case of joining a ibss cell without providing a static bssid where
the value of ifibss->bssid is not set before the cell is joined.
Since ifibss->bssid may be set before or after joining the cell we do not
learn anything by comparing it to a known bss. Remove this check.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
I tested this change with static bssid and without.
The symptom without this patch is that it is not possible to join an ad-hoc
cell unless you provide a bssid. When you want to join an existing cell a
new cell will be created.
net/mac80211/ibss.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 6eaf698..ca8ecce 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -538,13 +538,12 @@ static void ieee80211_sta_find_ibss(struct ieee80211_sub_if_data *sdata)
WLAN_CAPABILITY_PRIVACY,
capability);
+ if (bss) {
#ifdef CONFIG_MAC80211_IBSS_DEBUG
- if (bss)
printk(KERN_DEBUG " sta_find_ibss: selected %pM current "
"%pM\n", bss->cbss.bssid, ifibss->bssid);
#endif /* CONFIG_MAC80211_IBSS_DEBUG */
- if (bss && !memcmp(ifibss->bssid, bss->cbss.bssid, ETH_ALEN)) {
printk(KERN_DEBUG "%s: Selected IBSS BSSID %pM"
" based on configured SSID\n",
sdata->dev->name, bss->cbss.bssid);
@@ -552,8 +551,7 @@ static void ieee80211_sta_find_ibss(struct ieee80211_sub_if_data *sdata)
ieee80211_sta_join_ibss(sdata, bss);
ieee80211_rx_bss_put(local, bss);
return;
- } else if (bss)
- ieee80211_rx_bss_put(local, bss);
+ }
#ifdef CONFIG_MAC80211_IBSS_DEBUG
printk(KERN_DEBUG " did not try to join ibss\n");
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH] libertas: remove unused 11d code
From: Luis R. Rodriguez @ 2009-10-19 23:49 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, John Linville, Dan Williams
In-Reply-To: <200910191118.39975.hs4233@mail.mn-solutions.de>
On Mon, Oct 19, 2009 at 6:18 PM, Holger Schurig
<hs4233@mail.mn-solutions.de> wrote:
>> Is the countryinfo->countrycode not usable for
>> regulatory_hint_11d() ?
>
> I guess so, but the libertas+cfg80211 patch hasn't yet landed.
>
> And if it lands, it will have a WAY simpler 11d coding than
> before:
>
> 1. get the region code out of the EEPROM, convert it, call call
> regulatory_hint_11d().
>
> 2. no need to parse the scan result IE for a WLAN_EID_COUNTRY,
> because cfg80211 does this for us
>
> 3. no need to parse the association response either, because
> cfg80211 does this for us
>
> 4. no need to store special channel settings, because cfg80211
> does this for us
>
>
> At least this is how I understand it based on my current
> region-handling knowledge of cfg80211, which isn't too deep.
Sounds right.
Luis
^ permalink raw reply
* Re: How do you set the rate algorithm from the command line
From: Johannes Berg @ 2009-10-20 0:31 UTC (permalink / raw)
To: Charles Gordon; +Cc: linux-wireless
In-Reply-To: <86201b3f0910190850g3f014abbi9e2fa3f89463e7c6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 574 bytes --]
On Mon, 2009-10-19 at 11:50 -0400, Charles Gordon wrote:
> Hi,
>
> I'm using mac80211 in an embedded system. I can build the driver so
> that more than one wifi rate algorithm is included, and one is set as
> the default. It is not clear to me how to set the rate algorithm at
> run time. Is there a command line utility that does this?
>
> Suppose I build the driver so that both the PID and Mistrel algorithms
> are included, and the Minstrel algorithm is the default. How can I
> switch to the PID algorithm at run time?
You cannot (yet).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC] libertas: monster-patch to make CFG/WEXT configurable
From: Johannes Berg @ 2009-10-20 0:33 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, Dan Williams
In-Reply-To: <200910191449.18915.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
On Mon, 2009-10-19 at 14:49 +0200, Holger Schurig wrote:
> This is a monster patch that makes CFG80211/WEXT operation
> configurable. My cfg80211-RFC/WIP-Patch would come on top of it,
> but would then be quite small, e.g. almost only changed to
> cfg.c/cfg.h.
>
> As there's no mesh/adhoc/monitor mode implemented in cfg80211-
> mode, I added many, many #ifdef/#endif pairs. Maybe too many.
> Is this too ugly? Or would this patch be applyable as-is ?
>
> If the patch is perceived to be too ugly, I could create an
> monitor.h/monitor.c file and singleout everything related to
> monitoring in it, where monitor.h would resolv to dummy static
> functions in the cfg80211-case ... at least as long as we don't
> have monitor suppport in libertas+cfg80211. The same for mesh
> support, e.g. here I could create a mesh.h/mesh.c and do the
> same.
I really don't understand the point. Can't you just use the cfg80211
hooks and keep both functional at the same time? Just like orinoco does
-- it uses cfg80211 only partially.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: wlan oops
From: Johannes Berg @ 2009-10-20 1:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-wireless, nbd
In-Reply-To: <1255916929.2139.1.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]
On Mon, 2009-10-19 at 10:48 +0900, Benjamin Herrenschmidt wrote:
> [ 3698.908913] wlan0: Selected IBSS BSSID 22:48:99:ac:65:40 based on configured SSID
> [ 3698.932660] ------------[ cut here ]------------
> [ 3698.932701] WARNING: at net/wireless/scan.c:483 cfg80211_inform_bss_frame+0x151/0x190 [cfg80211]()
> [ 3698.932707] Hardware name: 7659AB8
> [ 3698.932711] Modules linked in: tun snd_hda_codec_analog snd_hda_intel snd_hda_codec binfmt_misc snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi arc4 snd_seq_midi_event ecb snd_seq snd_timer snd_seq_device pcmcia bridge iwlagn stp iptable_filter sdhci_pci ppdev snd iwlcore bnep ip_tables yenta_socket psmouse thinkpad_acpi sdhci soundcore mac80211 x_tables lp ricoh_mmc btusb rsrc_nonstatic pcmcia_core serio_raw led_class nvram snd_page_alloc cfg80211 parport fbcon tileblit font bitblit softcursor ohci1394 ieee1394 i915 e1000e drm i2c_algo_bit cfbcopyarea video output cfbimgblt cfbfillrect intel_agp
> [ 3698.932822] Pid: 1345, comm: iwlagn Not tainted 2.6.31.4-14-benh #1
> [ 3698.932827] Call Trace:
> [ 3698.932875] [<ffffffffa012a4b1>] cfg80211_inform_bss_frame+0x151/0x190 [cfg80211]
> [ 3698.932916] [<ffffffffa01a3cc4>] __ieee80211_sta_join_ibss+0x384/0x460 [mac80211]
> [ 3698.932944] [<ffffffffa01a427e>] ieee80211_sta_find_ibss+0x4de/0x4f0 [mac80211]
> [ 3698.932971] [<ffffffffa01a4303>] ieee80211_ibss_notify_scan_completed+0x73/0xa0 [mac80211]
> [ 3698.932997] [<ffffffffa01a0bc9>] ieee80211_scan_completed+0xc9/0x470 [mac80211]
This actually seems to be a bug in mac80211, not just random weird
frames being received.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH net-next V2 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: David Miller @ 2009-10-20 4:54 UTC (permalink / raw)
To: tomas.winkler
Cc: linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1255806576-26869-1-git-send-email-tomas.winkler@intel.com>
From: Tomas Winkler <tomas.winkler@intel.com>
Date: Sat, 17 Oct 2009 21:09:34 +0200
> This patch adds Intel Wireless MultiCom 3200 top driver.
> IWMC3200 is 4Wireless Com CHIP (GPS/BT/WiFi/WiMAX).
> Top driver is responsible for device initialization and firmware download.
> Firmware handled by top is responsible for top itself and
> as well as bluetooth and GPS coms. (Wifi and WiMax provide their own firmware)
> In addition top driver is used to retrieve firmware logs
> and supports other debugging features
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH net-next V2 2/3] iwmc3200wifi: select IWMC3200TOP in Kconfig
From: David Miller @ 2009-10-20 4:55 UTC (permalink / raw)
To: tomas.winkler
Cc: linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1255806576-26869-2-git-send-email-tomas.winkler@intel.com>
From: Tomas Winkler <tomas.winkler@intel.com>
Date: Sat, 17 Oct 2009 21:09:35 +0200
> iwmc3200wifi requires iwmc3200top for its operation
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Acked-by: Zhu Yi <yi.zhu@intel.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH net-next V2 3/3] i2400m-sdio: select IWMC3200TOP in Kconfig
From: David Miller @ 2009-10-20 4:55 UTC (permalink / raw)
To: tomas.winkler
Cc: linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1255806576-26869-3-git-send-email-tomas.winkler@intel.com>
From: Tomas Winkler <tomas.winkler@intel.com>
Date: Sat, 17 Oct 2009 21:09:36 +0200
> i2400m-sdio requires iwmc3200top for its operation
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Acked-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Applied to net-next-2.6, thanks!
^ permalink raw reply
* [PATCH] mac80211: keep auth state when assoc fails
From: Johannes Berg @ 2009-10-20 6:08 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Luis R. Rodriguez
When association fails, we should stay authenticated,
which in mac80211 is represented by the existence of
the mlme work struct, so we cannot free that, instead
we need to just set it to idle.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/mlme.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- wireless-testing.orig/net/mac80211/mlme.c 2009-10-20 15:01:40.000000000 +0900
+++ wireless-testing/net/mac80211/mlme.c 2009-10-20 15:01:46.000000000 +0900
@@ -1457,8 +1457,7 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee
if (status_code != WLAN_STATUS_SUCCESS) {
printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
sdata->dev->name, status_code);
- list_del(&wk->list);
- kfree(wk);
+ wk->state = IEEE80211_MGD_STATE_IDLE;
return RX_MGMT_CFG80211_ASSOC;
}
^ permalink raw reply
* [PATCH] cfg80211: sme: deauthenticate on assoc failure
From: Johannes Berg @ 2009-10-20 6:08 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Luis R. Rodriguez
When the in-kernel SME gets an association failure from
the AP we don't deauthenticate, and thus get into a very
confused state which will lead to warnings later on. Fix
this by actually deauthenticating when the AP indicates
an association failure.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/core.h | 1 +
net/wireless/mlme.c | 9 +++++++++
net/wireless/sme.c | 21 +++++++++++++++++++--
3 files changed, 29 insertions(+), 2 deletions(-)
--- wireless-testing.orig/net/wireless/core.h 2009-10-20 15:02:15.000000000 +0900
+++ wireless-testing/net/wireless/core.h 2009-10-20 15:03:20.000000000 +0900
@@ -358,6 +358,7 @@ int cfg80211_mgd_wext_connect(struct cfg
struct wireless_dev *wdev);
void cfg80211_conn_work(struct work_struct *work);
+void cfg80211_sme_failed_assoc(struct wireless_dev *wdev);
bool cfg80211_sme_failed_reassoc(struct wireless_dev *wdev);
/* internal helpers */
--- wireless-testing.orig/net/wireless/mlme.c 2009-10-20 15:02:15.000000000 +0900
+++ wireless-testing/net/wireless/mlme.c 2009-10-20 15:03:20.000000000 +0900
@@ -62,6 +62,7 @@ void cfg80211_send_rx_assoc(struct net_d
u8 *ie = mgmt->u.assoc_resp.variable;
int i, ieoffs = offsetof(struct ieee80211_mgmt, u.assoc_resp.variable);
struct cfg80211_internal_bss *bss = NULL;
+ bool need_connect_result = true;
wdev_lock(wdev);
@@ -94,6 +95,14 @@ void cfg80211_send_rx_assoc(struct net_d
}
WARN_ON(!bss);
+ } else if (wdev->conn) {
+ cfg80211_sme_failed_assoc(wdev);
+ need_connect_result = false;
+ /*
+ * do not call connect_result() now because the
+ * sme will schedule work that does it later.
+ */
+ goto out;
}
if (!wdev->conn && wdev->sme_state == CFG80211_SME_IDLE) {
--- wireless-testing.orig/net/wireless/sme.c 2009-10-20 15:02:15.000000000 +0900
+++ wireless-testing/net/wireless/sme.c 2009-10-20 15:03:20.000000000 +0900
@@ -26,6 +26,7 @@ struct cfg80211_conn {
CFG80211_CONN_AUTHENTICATING,
CFG80211_CONN_ASSOCIATE_NEXT,
CFG80211_CONN_ASSOCIATING,
+ CFG80211_CONN_DEAUTH_ASSOC_FAIL,
} state;
u8 bssid[ETH_ALEN], prev_bssid[ETH_ALEN];
u8 *ie;
@@ -148,6 +149,12 @@ static int cfg80211_conn_do_work(struct
NULL, 0,
WLAN_REASON_DEAUTH_LEAVING);
return err;
+ case CFG80211_CONN_DEAUTH_ASSOC_FAIL:
+ __cfg80211_mlme_deauth(rdev, wdev->netdev, params->bssid,
+ NULL, 0,
+ WLAN_REASON_DEAUTH_LEAVING);
+ /* return an error so that we call __cfg80211_connect_result() */
+ return -EINVAL;
default:
return 0;
}
@@ -158,6 +165,7 @@ void cfg80211_conn_work(struct work_stru
struct cfg80211_registered_device *rdev =
container_of(work, struct cfg80211_registered_device, conn_work);
struct wireless_dev *wdev;
+ u8 bssid[ETH_ALEN];
rtnl_lock();
cfg80211_lock_rdev(rdev);
@@ -173,10 +181,10 @@ void cfg80211_conn_work(struct work_stru
wdev_unlock(wdev);
continue;
}
+ memcpy(bssid, wdev->conn->params.bssid, ETH_ALEN);
if (cfg80211_conn_do_work(wdev))
__cfg80211_connect_result(
- wdev->netdev,
- wdev->conn->params.bssid,
+ wdev->netdev, bssid,
NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
false, NULL);
@@ -337,6 +345,15 @@ bool cfg80211_sme_failed_reassoc(struct
return true;
}
+void cfg80211_sme_failed_assoc(struct wireless_dev *wdev)
+{
+ struct wiphy *wiphy = wdev->wiphy;
+ struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
+
+ wdev->conn->state = CFG80211_CONN_DEAUTH_ASSOC_FAIL;
+ schedule_work(&rdev->conn_work);
+}
+
void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
const u8 *req_ie, size_t req_ie_len,
const u8 *resp_ie, size_t resp_ie_len,
^ permalink raw reply
* Re: [PATCH] cfg80211: sme: deauthenticate on assoc failure
From: Luis R. Rodriguez @ 2009-10-20 6:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1256018933.4475.6.camel@johannes.local>
On Tue, Oct 20, 2009 at 3:08 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> When the in-kernel SME gets an association failure from
> the AP we don't deauthenticate, and thus get into a very
> confused state which will lead to warnings later on. Fix
> this by actually deauthenticating when the AP indicates
> an association failure.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Thanks Johannes.
Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
John -- this patch and the previous patch titled "mac80211: keep auth
state when assoc fails" fix the SME warning as well. These are also
2.6.32-rc fixes.
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: sme: deauthenticate on assoc failure
From: Johannes Berg @ 2009-10-20 6:26 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John Linville, linux-wireless
In-Reply-To: <43e72e890910192324t3deab484nad855a5ecd109dd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
On Tue, 2009-10-20 at 15:24 +0900, Luis R. Rodriguez wrote:
> On Tue, Oct 20, 2009 at 3:08 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > When the in-kernel SME gets an association failure from
> > the AP we don't deauthenticate, and thus get into a very
> > confused state which will lead to warnings later on. Fix
> > this by actually deauthenticating when the AP indicates
> > an association failure.
> >
> > Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> Thanks Johannes.
>
> Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>
> John -- this patch and the previous patch titled "mac80211: keep auth
> state when assoc fails" fix the SME warning as well. These are also
> 2.6.32-rc fixes.
And also done during the hacking session at KS.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC] libertas: monster-patch to make CFG/WEXT configurable
From: Holger Schurig @ 2009-10-20 6:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Dan Williams
In-Reply-To: <1255998802.4475.2.camel@johannes.local>
> I really don't understand the point. Can't you just use the
> cfg80211 hooks and keep both functional at the same time? Just
> like orinoco does it uses cfg80211 only partially.
I think I can't do this in a sane way.
Oh, and please don't compare libertas all the time with orinoco.
Orinoco is FULLMAC, libertas is HALFMAC.
Because libertas firmware doesn't roam, it has to be done in
software. Libertas does this in assoc.c, partly in scan.c, cmd.c
and wext.c and even main.c. For example, libertas keeps its own
list of BSS entries, has code to select the best matching BSS
when it comes to associating ... things like this.
cfg80211 has this code too.
Having two competing implementations running in one driver is a
way to havoc.
I could keep "old" stuff of the libertas in, e.g. monitor
mode --- but then it's not too difficult to use .change_intf()
to add monitor mode to cfg80211.
I can't and won't do the MESH stuff: I don't have a firmware that
does MESH, no knowledge and usage case for MESH. It would,
however, be possible to keep the current mesh code with WEXT and
use cfg80211 for monitor/station mode. However, I dislike this
more than cfg80211/wext configurability.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH v2] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
From: Holger Schurig @ 2009-10-20 6:43 UTC (permalink / raw)
To: Bing Zhao
Cc: libertas-dev@lists.infradead.org, linux-wireless@vger.kernel.org,
Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F704306DDD5C26C@SC-VEXCH1.marvell.com>
> > Side question: which firmware are you using on CS cards?
>
> firmware version for Marvell CF8385 card: 5.101.13p1
Can you provide this firmware to me? Or can you say me where I
can download it?
I still have 5.0.16p0, which seems to not understand
CMD_802_11_MONITOR_MODE and CMD_802_11_TX_RATE_QUERY.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: Implement support for rt2800pci
From: Holger Schurig @ 2009-10-20 6:58 UTC (permalink / raw)
To: Ivo van Doorn
Cc: Bartlomiej Zolnierkiewicz, John Linville, linux-wireless, users,
Alban Browaeys, Benoit PAPILLAULT, Felix Fietkau, Luis Correia,
Mattias Nissler, Mark Asselstine, Xose Vazquez Perez,
linux-kernel
In-Reply-To: <200910181859.22413.IvDoorn@gmail.com>
> I don't agree on this, for starters the whole "abstraction
> layer as done in the staging driver, really obfuscated the code
> in multiple areas
Ivo, you could look at Orinoco or Libertas. Both WLAN drivers
support a multitude of different hardware (Libertas: CF/PCMCIA,
SDIO, SD, USB and Orinoco: CF/PCMCIA, PCI, PPC_PMAC). And both
have hardware abstraction layers that don't suck, obfuscate or
create lots of duplicate code.
So AFAIK it's not the question *IF* to do hardware abstraction
but only a question *HOW* to do it in an intelligent way. Don't
luck at one bad implementation and disregard the whole
concept :-)
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] cfg80211: sme: deauthenticate on assoc failure
From: Sedat Dilek @ 2009-10-20 7:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1256018933.4475.6.camel@johannes.local>
SXMgdGhpcyBwYXRjaCBvbiB0b3Agb2Ygd2lyZWxlc3MtdGVzdGluZyAobWFzdGVyLTIwMDktMTAt
MTYpPwoKSXQgZmFpbHMgaGVyZToKLi4uCkFwcGx5aW5nIHBhdGNoIGxpbnV4LXdpcmVsZXNzL21h
YzgwMjExLWtlZXAtYXV0aC1zdGF0ZS13aGVuLWFzc29jLWZhaWxzLnBhdGNoCnBhdGNoaW5nIGZp
bGUgbmV0L21hYzgwMjExL21sbWUuYwpIdW5rICMxIEZBSUxFRCBhdCAxNDU3LgoxIG91dCBvZiAx
IGh1bmsgRkFJTEVEIC0tIHJlamVjdHMgaW4gZmlsZSBuZXQvbWFjODAyMTEvbWxtZS5jClBhdGNo
IGxpbnV4LXdpcmVsZXNzL21hYzgwMjExLWtlZXAtYXV0aC1zdGF0ZS13aGVuLWFzc29jLWZhaWxz
LnBhdGNoCmRvZXMgbm90IGFwcGx5IChlbmZvcmNlIHdpdGggLWYpCkVSUk9SOiBmYWlsZWQgdG8g
YXBwbHkgcGF0Y2ggc2VyaWVzIQoKRG9lcyBpdCBuZWVkIHRvIHJldmVydCAibWFjODAyMTE6IGZp
eCBTTUUgd2FybmluZyBieSByZW1vdmluZyBzdGFsZQpCU1MgdXBvbiBhc3NvYyBmYWlsdXJlIj8K
Ci0gU2VkYXQgLQoKT24gVHVlLCBPY3QgMjAsIDIwMDkgYXQgODowOCBBTSwgSm9oYW5uZXMgQmVy
Zwo8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3JvdGU6Cj4gV2hlbiB0aGUgaW4ta2VybmVs
IFNNRSBnZXRzIGFuIGFzc29jaWF0aW9uIGZhaWx1cmUgZnJvbQo+IHRoZSBBUCB3ZSBkb24ndCBk
ZWF1dGhlbnRpY2F0ZSwgYW5kIHRodXMgZ2V0IGludG8gYSB2ZXJ5Cj4gY29uZnVzZWQgc3RhdGUg
d2hpY2ggd2lsbCBsZWFkIHRvIHdhcm5pbmdzIGxhdGVyIG9uLiBGaXgKPiB0aGlzIGJ5IGFjdHVh
bGx5IGRlYXV0aGVudGljYXRpbmcgd2hlbiB0aGUgQVAgaW5kaWNhdGVzCj4gYW4gYXNzb2NpYXRp
b24gZmFpbHVyZS4KPgo+IFNpZ25lZC1vZmYtYnk6IEpvaGFubmVzIEJlcmcgPGpvaGFubmVzQHNp
cHNvbHV0aW9ucy5uZXQ+Cj4gLS0tCj4gwqBuZXQvd2lyZWxlc3MvY29yZS5oIHwgwqAgwqAxICsK
PiDCoG5ldC93aXJlbGVzcy9tbG1lLmMgfCDCoCDCoDkgKysrKysrKysrCj4gwqBuZXQvd2lyZWxl
c3Mvc21lLmMgwqB8IMKgIDIxICsrKysrKysrKysrKysrKysrKystLQo+IMKgMyBmaWxlcyBjaGFu
Z2VkLCAyOSBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQo+Cj4gLS0tIHdpcmVsZXNzLXRl
c3Rpbmcub3JpZy9uZXQvd2lyZWxlc3MvY29yZS5oIMKgIDIwMDktMTAtMjAgMTU6MDI6MTUuMDAw
MDAwMDAwICswOTAwCj4gKysrIHdpcmVsZXNzLXRlc3RpbmcvbmV0L3dpcmVsZXNzL2NvcmUuaCDC
oCDCoCDCoCDCoDIwMDktMTAtMjAgMTU6MDM6MjAuMDAwMDAwMDAwICswOTAwCj4gQEAgLTM1OCw2
ICszNTgsNyBAQCBpbnQgY2ZnODAyMTFfbWdkX3dleHRfY29ubmVjdChzdHJ1Y3QgY2ZnCj4gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzdHJ1Y3Qgd2lyZWxlc3Nf
ZGV2ICp3ZGV2KTsKPgo+IMKgdm9pZCBjZmc4MDIxMV9jb25uX3dvcmsoc3RydWN0IHdvcmtfc3Ry
dWN0ICp3b3JrKTsKPiArdm9pZCBjZmc4MDIxMV9zbWVfZmFpbGVkX2Fzc29jKHN0cnVjdCB3aXJl
bGVzc19kZXYgKndkZXYpOwo+IMKgYm9vbCBjZmc4MDIxMV9zbWVfZmFpbGVkX3JlYXNzb2Moc3Ry
dWN0IHdpcmVsZXNzX2RldiAqd2Rldik7Cj4KPiDCoC8qIGludGVybmFsIGhlbHBlcnMgKi8KPiAt
LS0gd2lyZWxlc3MtdGVzdGluZy5vcmlnL25ldC93aXJlbGVzcy9tbG1lLmMgwqAgMjAwOS0xMC0y
MCAxNTowMjoxNS4wMDAwMDAwMDAgKzA5MDAKPiArKysgd2lyZWxlc3MtdGVzdGluZy9uZXQvd2ly
ZWxlc3MvbWxtZS5jIMKgIMKgIMKgIMKgMjAwOS0xMC0yMCAxNTowMzoyMC4wMDAwMDAwMDAgKzA5
MDAKPiBAQCAtNjIsNiArNjIsNyBAQCB2b2lkIGNmZzgwMjExX3NlbmRfcnhfYXNzb2Moc3RydWN0
IG5ldF9kCj4gwqAgwqAgwqAgwqB1OCAqaWUgPSBtZ210LT51LmFzc29jX3Jlc3AudmFyaWFibGU7
Cj4gwqAgwqAgwqAgwqBpbnQgaSwgaWVvZmZzID0gb2Zmc2V0b2Yoc3RydWN0IGllZWU4MDIxMV9t
Z210LCB1LmFzc29jX3Jlc3AudmFyaWFibGUpOwo+IMKgIMKgIMKgIMKgc3RydWN0IGNmZzgwMjEx
X2ludGVybmFsX2JzcyAqYnNzID0gTlVMTDsKPiArIMKgIMKgIMKgIGJvb2wgbmVlZF9jb25uZWN0
X3Jlc3VsdCA9IHRydWU7Cj4KPiDCoCDCoCDCoCDCoHdkZXZfbG9jayh3ZGV2KTsKPgo+IEBAIC05
NCw2ICs5NSwxNCBAQCB2b2lkIGNmZzgwMjExX3NlbmRfcnhfYXNzb2Moc3RydWN0IG5ldF9kCj4g
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB9Cj4KPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFdBUk5f
T04oIWJzcyk7Cj4gKyDCoCDCoCDCoCB9IGVsc2UgaWYgKHdkZXYtPmNvbm4pIHsKPiArIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIGNmZzgwMjExX3NtZV9mYWlsZWRfYXNzb2Mod2Rldik7Cj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCBuZWVkX2Nvbm5lY3RfcmVzdWx0ID0gZmFsc2U7Cj4gKyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCAvKgo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGRvIG5vdCBjYWxs
IGNvbm5lY3RfcmVzdWx0KCkgbm93IGJlY2F1c2UgdGhlCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCogc21lIHdpbGwgc2NoZWR1bGUgd29yayB0aGF0IGRvZXMgaXQgbGF0ZXIuCj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCovCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBnb3RvIG91dDsK
PiDCoCDCoCDCoCDCoH0KPgo+IMKgIMKgIMKgIMKgaWYgKCF3ZGV2LT5jb25uICYmIHdkZXYtPnNt
ZV9zdGF0ZSA9PSBDRkc4MDIxMV9TTUVfSURMRSkgewo+IC0tLSB3aXJlbGVzcy10ZXN0aW5nLm9y
aWcvbmV0L3dpcmVsZXNzL3NtZS5jIMKgIMKgMjAwOS0xMC0yMCAxNTowMjoxNS4wMDAwMDAwMDAg
KzA5MDAKPiArKysgd2lyZWxlc3MtdGVzdGluZy9uZXQvd2lyZWxlc3Mvc21lLmMgMjAwOS0xMC0y
MCAxNTowMzoyMC4wMDAwMDAwMDAgKzA5MDAKPiBAQCAtMjYsNiArMjYsNyBAQCBzdHJ1Y3QgY2Zn
ODAyMTFfY29ubiB7Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBDRkc4MDIxMV9DT05OX0FVVEhF
TlRJQ0FUSU5HLAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQ0ZHODAyMTFfQ09OTl9BU1NPQ0lB
VEVfTkVYVCwKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoENGRzgwMjExX0NPTk5fQVNTT0NJQVRJ
TkcsCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDRkc4MDIxMV9DT05OX0RFQVVUSF9BU1NPQ19G
QUlMLAo+IMKgIMKgIMKgIMKgfSBzdGF0ZTsKPiDCoCDCoCDCoCDCoHU4IGJzc2lkW0VUSF9BTEVO
XSwgcHJldl9ic3NpZFtFVEhfQUxFTl07Cj4gwqAgwqAgwqAgwqB1OCAqaWU7Cj4gQEAgLTE0OCw2
ICsxNDksMTIgQEAgc3RhdGljIGludCBjZmc4MDIxMV9jb25uX2RvX3dvcmsoc3RydWN0Cj4gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgTlVMTCwgMCwKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBXTEFOX1JFQVNPTl9ERUFVVEhfTEVBVklO
Ryk7Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZXR1cm4gZXJyOwo+ICsgwqAgwqAgwqAgY2Fz
ZSBDRkc4MDIxMV9DT05OX0RFQVVUSF9BU1NPQ19GQUlMOgo+ICsgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgX19jZmc4MDIxMV9tbG1lX2RlYXV0aChyZGV2LCB3ZGV2LT5uZXRkZXYsIHBhcmFtcy0+YnNz
aWQsCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoE5VTEwsIDAsCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoFdMQU5fUkVBU09OX0RFQVVUSF9MRUFWSU5HKTsKPiArIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIC8qIHJldHVybiBhbiBlcnJvciBzbyB0aGF0IHdlIGNhbGwgX19jZmc4
MDIxMV9jb25uZWN0X3Jlc3VsdCgpICovCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXR1cm4g
LUVJTlZBTDsKPiDCoCDCoCDCoCDCoGRlZmF1bHQ6Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBy
ZXR1cm4gMDsKPiDCoCDCoCDCoCDCoH0KPiBAQCAtMTU4LDYgKzE2NSw3IEBAIHZvaWQgY2ZnODAy
MTFfY29ubl93b3JrKHN0cnVjdCB3b3JrX3N0cnUKPiDCoCDCoCDCoCDCoHN0cnVjdCBjZmc4MDIx
MV9yZWdpc3RlcmVkX2RldmljZSAqcmRldiA9Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjb250
YWluZXJfb2Yod29yaywgc3RydWN0IGNmZzgwMjExX3JlZ2lzdGVyZWRfZGV2aWNlLCBjb25uX3dv
cmspOwo+IMKgIMKgIMKgIMKgc3RydWN0IHdpcmVsZXNzX2RldiAqd2RldjsKPiArIMKgIMKgIMKg
IHU4IGJzc2lkW0VUSF9BTEVOXTsKPgo+IMKgIMKgIMKgIMKgcnRubF9sb2NrKCk7Cj4gwqAgwqAg
wqAgwqBjZmc4MDIxMV9sb2NrX3JkZXYocmRldik7Cj4gQEAgLTE3MywxMCArMTgxLDEwIEBAIHZv
aWQgY2ZnODAyMTFfY29ubl93b3JrKHN0cnVjdCB3b3JrX3N0cnUKPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoHdkZXZfdW5sb2NrKHdkZXYpOwo+IMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgY29udGludWU7Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB9Cj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtZW1jcHkoYnNzaWQsIHdkZXYtPmNvbm4tPnBhcmFtcy5i
c3NpZCwgRVRIX0FMRU4pOwo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaWYgKGNmZzgwMjExX2Nv
bm5fZG9fd29yayh3ZGV2KSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoF9f
Y2ZnODAyMTFfY29ubmVjdF9yZXN1bHQoCj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3ZGV2LT5uZXRkZXYsCj4gLSDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3ZGV2LT5jb25u
LT5wYXJhbXMuYnNzaWQsCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCB3ZGV2LT5uZXRkZXYsIGJzc2lkLAo+IMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgTlVMTCwgMCwgTlVM
TCwgMCwKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoFdMQU5fU1RBVFVTX1VOU1BFQ0lGSUVEX0ZBSUxVUkUsCj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBmYWxzZSwgTlVM
TCk7Cj4gQEAgLTMzNyw2ICszNDUsMTUgQEAgYm9vbCBjZmc4MDIxMV9zbWVfZmFpbGVkX3JlYXNz
b2Moc3RydWN0Cj4gwqAgwqAgwqAgwqByZXR1cm4gdHJ1ZTsKPiDCoH0KPgo+ICt2b2lkIGNmZzgw
MjExX3NtZV9mYWlsZWRfYXNzb2Moc3RydWN0IHdpcmVsZXNzX2RldiAqd2RldikKPiArewo+ICsg
wqAgwqAgwqAgc3RydWN0IHdpcGh5ICp3aXBoeSA9IHdkZXYtPndpcGh5Owo+ICsgwqAgwqAgwqAg
c3RydWN0IGNmZzgwMjExX3JlZ2lzdGVyZWRfZGV2aWNlICpyZGV2ID0gd2lwaHlfdG9fZGV2KHdp
cGh5KTsKPiArCj4gKyDCoCDCoCDCoCB3ZGV2LT5jb25uLT5zdGF0ZSA9IENGRzgwMjExX0NPTk5f
REVBVVRIX0FTU09DX0ZBSUw7Cj4gKyDCoCDCoCDCoCBzY2hlZHVsZV93b3JrKCZyZGV2LT5jb25u
X3dvcmspOwo+ICt9Cj4gKwo+IMKgdm9pZCBfX2NmZzgwMjExX2Nvbm5lY3RfcmVzdWx0KHN0cnVj
dCBuZXRfZGV2aWNlICpkZXYsIGNvbnN0IHU4ICpic3NpZCwKPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb25zdCB1OCAqcmVxX2llLCBzaXplX3QgcmVxX2ll
X2xlbiwKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb25z
dCB1OCAqcmVzcF9pZSwgc2l6ZV90IHJlc3BfaWVfbGVuLAo+Cj4KPiAtLQo+IFRvIHVuc3Vic2Ny
aWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC13aXJl
bGVzcyIgaW4KPiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVs
Lm9yZwo+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgwqBodHRwOi8vdmdlci5rZXJuZWwub3JnL21h
am9yZG9tby1pbmZvLmh0bWwKPgo=
^ 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