* [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type
From: Larry Finger @ 2013-10-28 23:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Mark Cave-Ayland, netdev, Larry Finger, Stable
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
All of the rtlwifi drivers have an error in the routine that tests if
the received data is "special". The 16-bit quantity is big-endian, but
was being extracted in native CPU mode. One of the effects of this bug
is to inhibit association under some conditions.
A statement that would have made the code correct had been changed to
a comment. Rather than just reinstating that code, the fix here passes
sparse tests.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Stable <stable@vger.kernel.org> [2.6.38+]
---
drivers/net/wireless/rtlwifi/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
index 9a78e3d..1efde7f 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1077,8 +1077,8 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
ip = (struct iphdr *)((u8 *) skb->data + mac_hdr_len +
SNAP_SIZE + PROTOC_TYPE_SIZE);
- ether_type = *(u16 *) ((u8 *) skb->data + mac_hdr_len + SNAP_SIZE);
- /* ether_type = ntohs(ether_type); */
+ ether_type = be16_to_cpu(*(__be16 *)((u8 *)skb->data + mac_hdr_len +
+ SNAP_SIZE));
if (ETH_P_IP == ether_type) {
if (IPPROTO_UDP == ip->protocol) {
--
1.8.4
^ permalink raw reply related
* Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Sebastian Reichel @ 2013-10-28 23:26 UTC (permalink / raw)
To: Mark Brown
Cc: Grazvydas Ignotas, Alexander Shiyan, Luciano Coelho, Mark Rutland,
devicetree, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren,
Greg Kroah-Hartman, Stephen Warren, linux-doc, John W. Linville,
Rob Herring, linux-kernel@vger.kernel.org, Sachin Kamat,
Bill Pemberton, Felipe Balbi, Rob Landley, netdev,
linux-wireless@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20131028192354.GA18208@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]
Hi,
On Mon, Oct 28, 2013 at 12:23:54PM -0700, Mark Brown wrote:
> On Mon, Oct 28, 2013 at 07:29:52PM +0200, Grazvydas Ignotas wrote:
>
> > When wl12xx family of chips is connected through SDIO, we already have
> > that pin set up as a regulator controlled with the help of mmc
> > subsystem. When time comes to communicate with the chip, mmc subsystem
> > sees this as yet another SD card and looks for associated regulator
> > for it, and the board file has that set up as a fixed regulator
> > controlling that pin (see pandora_vmmc3 in
> > arch/arm/mach-omap2/board-omap3pandora.c). To prevent poweroff after
> > first SDIO communications are over, pm_runtime calls are used in
> > drivers/net/wireless/ti/wl1251/sdio.c .
>
> Is this actually controlling VMMC though, or is it some other control?
> If it's not controlling VMMC then it shouldn't say that it is.
>
> > I don't know if something similar can be done done in SPI case, but
> > I'm sure this is not the first your-so-called regulator misuse.
>
> It's not the first but that doesn't make controlling something other
> than a regulator through the regulator API any less broken.
I gave it a second try to find out details for this pin:
1. The pin is named PMEN in the Nokia N900 schematics
2. PMEN is described as "Power management enable - system shutdown"
in a crippled datasheet of the wl1253, which I found in the internet.
I don't think this is supposed to be handled by the regulator API.
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Linksys AE3000 iw tool issues
From: Dan Williams @ 2013-10-28 23:19 UTC (permalink / raw)
To: Richard Wang; +Cc: linux-wireless
In-Reply-To: <526ED703.6020901@andrew.cmu.edu>
On Mon, 2013-10-28 at 17:28 -0400, Richard Wang wrote:
> Hi,
>
> I currently have a Linksys AE3000 Wifi USB dongle, which has the
> RalinkRT3573 chipset.
>
> I am able currently able to connect to surrounding APs by installing
> Ralink proprietary drivers as outlined here
> (http://geekniggle.blogspot.com/2012/07/cisco-linksys-ae3000-wifi-usb-dongle.html).
> Ifconfig and iwconfig both recognize the device using the interface ra0.
> Unfortunately, the "iw" tool is having some issues. One machine running
> Lucid Ubuntu 10.04 with the following command "iw dev ra0 info" returns
> "command failed: No such device (-19)". Another machine machine with
> xubuntu on command "iw list" returns "nl80211 not found."
The proprietary ralink drivers do not appear to support the kernel's
nl80211 API. In the first case (no such device) that's what is
happening. IN the second case (nl80211 not found) the nl80211 module is
either not compiled into the kernel, or is not loaded. And since the
wifi driver doesn't use nl80211, that's probably why it's not loaded.
> From what I have read so far, it appears that the current driver may
> not support iw operations. As a result, I looked into installing
Correct, that proprietary driver does not use nl80211.
> rt2800usb driver that a few other threads appear to have working
> successfully. As stated on wikidevi
> (http://wikidevi.com/wiki/Linksys_AE3000), one of the more recent
> patches appears to support the RT3573 chipset. I tried to install the
> latest developmental release. After rebooting and loading the rt2800usb
> driver, "modprobe rt2800usb", I get dmesg errors like "rt2x00lib:
> disagrees about version of... ieee80211....".
>
> Any suggestions to get the "iw" tool working would be much appreciated.
Getting "iw" working would basically involve adding RT3573 support to
rt2800usb, so you're really asking "how can we get RT3573 chips properly
supported in Linux?". If that's done, "iw" comes for free.
Dan
^ permalink raw reply
* Re: [PATCH 4/4] wl1251: spi: add device tree support
From: Tomasz Figa @ 2013-10-28 22:38 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Kumar Gala, Sebastian Reichel, Mark Rutland, linux-doc,
Tony Lindgren, Russell King, Sachin Kamat, Ian Campbell,
Sebastian Reichel, Luciano Coelho, devicetree, Pawel Moll,
Stephen Warren, John W. Linville, Rob Herring, Bill Pemberton,
linux-omap, Greg Kroah-Hartman, linux-wireless, linux-kernel,
Felipe Balbi, Rob Landley, netdev
In-Reply-To: <FF34C626-4A49-43B1-B0AD-DC6146ABBB11@codeaurora.org>
On Monday 28 of October 2013 01:37:34 Kumar Gala wrote:
> On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
> > Add device tree support for the spi variant of wl1251
> > and document the binding.
> >
> > Signed-off-by: Sebastian Reichel <sre@debian.org>
> > ---
> > .../devicetree/bindings/net/wireless/ti,wl1251.txt | 36
> > ++++++++++++++++++++++ drivers/net/wireless/ti/wl1251/spi.c
> > | 23 ++++++++++---- 2 files changed, 53 insertions(+), 6
> > deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> > b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt new
> > file mode 100644
> > index 0000000..5f8a154
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> > @@ -0,0 +1,36 @@
> > +* Texas Instruments wl1251 controller
> > +
> > +The wl1251 chip can be connected via SPI or via SDIO. The linux
> > +kernel currently only supports device tree for the SPI variant.
> > +
>
> From the binding I have no idea what this chip actually does, also we
> don't normally reference linux kernel support in bindings specs (so
> please remove it).
>
> However, what would expect the SDIO binding to look like? Or more
> specifically, how would you distinguish the SPI vs SDIO
> binding/connection? I'm wondering if the compatible should be
> something like "ti,wl1251-spi" and than the sdio can be
> "ti,wl1251-sdio"
Well, you can easily distinguish an SDIO device from an SPI device by its
parent node, but...
The binding for SDIO might require different set of properties (other than
ones inherited from generic SDIO or SPI bindings) than one for SPI. So
probably different compatible values might be justified.
Did we already have such case before? (maybe some I2C + SPI devices?)
> > +Required properties:
> > +- compatible : Should be "ti,wl1251"
>
> reg is not listed as a required prop.
It is implied by SPI bindings, but it might be a good idea to have this
stated here as well.
>
> > +- interrupts : Should contain interrupt line
> > +- interrupt-parent : Should be the phandle for the interrupt
> > + controller that services interrupts for this device
> > +- vio-supply : phandle to regulator providing VIO
> > +- power-gpio : GPIO connected to chip's PMEN pin
>
> should be vendor prefixed: ti,power-gpio
Hmm, out of curiosity, is it a rule for this kind of properties? I can see
both cases with and without prefixes when grepping for "-gpios" in
Documentation/devicetree/bindings. We should really have such things
written down somewhere.
>
> > +- For additional required properties on SPI, please consult
> > + Documentation/devicetree/bindings/spi/spi-bus.txt
> > +
> > +Optional properties:
> > +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
>
> can you be a bit more specific on what cfg will be loaded. Also, is
> this property a boolean, if so how do I know which eeprom the cfg is
> loaded from (is it one that is directly connected to the wl1251?
Maybe one from ti,has-eeprom or ti,config-eeprom would be better name for
this property?
Best regards,
Tomasz
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Felipe Contreras @ 2013-10-28 21:32 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CABPxzYL-Gzbzoc_ui+qUQ6uzoKp=Yq7yLWZvc7PoEjiH3dFczg@mail.gmail.com>
On Mon, Oct 28, 2013 at 2:44 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> On Tue, Oct 29, 2013 at 1:36 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Mon, Oct 28, 2013 at 1:27 PM, Krishna Chaitanya
>> <chaitanya.mgit@gmail.com> wrote:
>
>>> From the logs we can see that we have received authentication response,
>>> so the association request is getting dropped somewhere? We might
>>> need the mac80211 and iwlwifi trace-cmd logs to check for the drop.
>>>
>>> http://wireless.kernel.org/en/developers/Documentation/mac80211/tracing
>>
>> There you go:
>> http://people.freedesktop.org/~felipec/wpa/trace.dat.xz
>>
> Hmm.."trace-cmd report -i trace.dat" returned lots of errors, i have even
> tried with the trace-cmd from git (ubuntu). Did it worked fro you?
Yes, but maybe I overrode the file. I've pushed a new one again. The
sha-1 is 36c260d8d8c171a24eb1aa7b2ea736b06c9b55b7.
--
Felipe Contreras
^ permalink raw reply
* Re: [OPW kernel] [Patch v3 1/3] net: wireless: replace printk with pr_warn in adm8211.c
From: Greg KH @ 2013-10-28 21:30 UTC (permalink / raw)
To: Georgiana Rodica Chelu; +Cc: opw-kernel, linux-wireless
In-Reply-To: <20131026192053.GA10494@fireworks>
On Sat, Oct 26, 2013 at 10:20:53PM +0300, Georgiana Rodica Chelu wrote:
> WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then pr_warn(...
> to printk(KERN_WARNING ...
>
> Signed-off-by: Georgiana Rodica Chelu <georgiana.chelu93@gmail.com>
> ---
> drivers/net/wireless/adm8211.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Like Sarah said, we can't take these as they are not against the staging
tree.
And even if they were:
> diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
> index f9a24e5..e36d54d 100644
> --- a/drivers/net/wireless/adm8211.c
> +++ b/drivers/net/wireless/adm8211.c
> @@ -151,7 +151,7 @@ static int adm8211_read_eeprom(struct ieee80211_hw *dev)
> else
> priv->rf_type = ADM8211_TYPE_AIROHA;
>
> - printk(KERN_WARNING "%s (adm8211): Unknown RFtype %d\n",
> + pr_warn("%s (adm8211): Unknown RFtype %d\n",
You didn't read the message that sparse was telling you, why didn't you
convert this to netdev_warn() instead?
thanks,
greg k-h
^ permalink raw reply
* Linksys AE3000 iw tool issues
From: Richard Wang @ 2013-10-28 21:28 UTC (permalink / raw)
To: linux-wireless
Hi,
I currently have a Linksys AE3000 Wifi USB dongle, which has the
RalinkRT3573 chipset.
I am able currently able to connect to surrounding APs by installing
Ralink proprietary drivers as outlined here
(http://geekniggle.blogspot.com/2012/07/cisco-linksys-ae3000-wifi-usb-dongle.html).
Ifconfig and iwconfig both recognize the device using the interface ra0.
Unfortunately, the "iw" tool is having some issues. One machine running
Lucid Ubuntu 10.04 with the following command "iw dev ra0 info" returns
"command failed: No such device (-19)". Another machine machine with
xubuntu on command "iw list" returns "nl80211 not found."
From what I have read so far, it appears that the current driver may
not support iw operations. As a result, I looked into installing
rt2800usb driver that a few other threads appear to have working
successfully. As stated on wikidevi
(http://wikidevi.com/wiki/Linksys_AE3000), one of the more recent
patches appears to support the RT3573 chipset. I tried to install the
latest developmental release. After rebooting and loading the rt2800usb
driver, "modprobe rt2800usb", I get dmesg errors like "rt2x00lib:
disagrees about version of... ieee80211....".
Any suggestions to get the "iw" tool working would be much appreciated.
Thanks!
^ permalink raw reply
* Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Jeffrey Johnson @ 2013-10-28 21:11 UTC (permalink / raw)
To: Dan Williams
Cc: Chauhan, Rajesh, Rodriguez, Luis, Johannes Berg,
linux-wireless@vger.kernel.org, Malinen, Jouni, Bahini, Henri,
Chang, Leo, Luo, Xun
In-Reply-To: <1382986906.7298.10.camel@dcbw.foobar.com>
On 10/28/2013 12:01 PM, Dan Williams wrote:
> On Mon, 2013-10-28 at 18:08 +0000, Chauhan, Rajesh wrote:
>> Hi Luis,
>>
>> For "enough information for proper usage" - how about if I add an attribute for the source of interference (say, for example, "cellular") for each of those frequency range?
> When you say "cellular" here, do mean a WWAN card in the same machine,
> sharing the antenna (or using a very very nearby antenna) with the WiFi
> card? Or do you mean a close-by phone, or a tower itself? How is this
> different from BT coexistence or WiMAX coexistence?
>
One use case would be a colocated WWAN card sharing an antenna or using
a very very nearby antenna. There could be other use cases. I would say
this is complimentary to coexistence. The idea is to tell userspace
which frequencies have know sources of interference so that they can be
avoided, and hence coexistence would not be required. If userspace
chooses to use an "unsafe" frequency, the the driver's coexistence logic
would then be utilized, but the user experience could suffer compared to
if a "safe" frequency had been selected.
The issue that has been debated internally is whether or not userspace
needs to know the source of the interference. In other words, if we
have an enumerated set of interference sources, would userspace behave
differently based upon the source?
This is, after all, just meant to be a hint to userspace to give it more
information to use when selected a channel to be used in a master mode
of operation.
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Krishna Chaitanya @ 2013-10-28 20:44 UTC (permalink / raw)
To: Felipe Contreras
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CAMP44s0svc2MRKCrZXS5ZYRZNPoomQkcKHdC2m2BGy7di+TCyA@mail.gmail.com>
On Tue, Oct 29, 2013 at 1:36 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Oct 28, 2013 at 1:27 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
>> From the logs we can see that we have received authentication response,
>> so the association request is getting dropped somewhere? We might
>> need the mac80211 and iwlwifi trace-cmd logs to check for the drop.
>>
>> http://wireless.kernel.org/en/developers/Documentation/mac80211/tracing
>
> There you go:
> http://people.freedesktop.org/~felipec/wpa/trace.dat.xz
>
Hmm.."trace-cmd report -i trace.dat" returned lots of errors, i have even
tried with the trace-cmd from git (ubuntu). Did it worked fro you?
===
# trace-cmd report -i trace.dat
version = 6
trace-cmd: No such file or directory ??????????????
function scsi_trace_parse_cdb not defined
function scsi_trace_parse_cdb not defined
function scsi_trace_parse_cdb not defined
function scsi_trace_parse_cdb not defined
function is_writable_pte not defined
function __le16_to_cpup not defined
function __le16_to_cpup not defined
function __le16_to_cpup not defined
CPU 0 is empty
CPU 1 is empty
CPU 2 is empty
CPU 3 is empty
cpus=4
--
Thanks,
Regards,
Chaitanya T K.
Mobile:+91-9963910010.
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Felipe Contreras @ 2013-10-28 20:37 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CABPxzYLwwyFCFw1pEt0v9Xw4kcue1C_RZx0RbTbMrUw=+MWvgQ@mail.gmail.com>
On Mon, Oct 28, 2013 at 1:27 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> Another side porint? Also all the beacons from that AP are malformed
> but probe responses are fine, weird??
Also, here's a message I get some times. I don't think it's related to
the issue at hands, but who knows:
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: fail to flush all
tx fifo queues Q 11
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Current SW read_ptr
137 write_ptr 154
Oct 28 14:28:47 nysa kernel: iwl data: 00000000: 00 fe ff 01 00 00 00
00 00 00 00 00 00 00 00 00 ................
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(0) = 0x00000000
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(1) = 0xc010b098
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(2) = 0x00000000
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(3) = 0x803000e3
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(4) = 0x00000000
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(5) = 0x00000000
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(6) = 0x00000000
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(7) = 0x00709041
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 0 is active and
mapped to fifo 3 ra_tid 0x0000 [228,228]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 1 is active and
mapped to fifo 2 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 2 is active and
mapped to fifo 1 ra_tid 0x0000 [105,105]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 3 is active and
mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 4 is active and
mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 5 is active and
mapped to fifo 4 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 6 is active and
mapped to fifo 2 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 7 is active and
mapped to fifo 5 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 8 is active and
mapped to fifo 4 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 9 is active and
mapped to fifo 7 ra_tid 0x0000 [66,66]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 10 is active and
mapped to fifo 5 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 11 is active and
mapped to fifo 1 ra_tid 0x0000 [137,154]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 12 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 13 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 14 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 15 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 16 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 17 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 18 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 19 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
--
Felipe Contreras
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Felipe Contreras @ 2013-10-28 20:06 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CABPxzYLwwyFCFw1pEt0v9Xw4kcue1C_RZx0RbTbMrUw=+MWvgQ@mail.gmail.com>
On Mon, Oct 28, 2013 at 1:27 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> On Tue, Oct 29, 2013 at 12:13 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Mon, Oct 28, 2013 at 12:28 PM, Krishna Chaitanya
>> <chaitanya.mgit@gmail.com> wrote:
>>> On Mon, Oct 28, 2013 at 11:30 PM, Felipe Contreras
>>> <felipe.contreras@gmail.com> wrote:
>>>
>>>> The authentication response does come back in both cases though, it's
>>>> just the acknowledgement that is missing. Unfortunately I cannot
>>>> figure out for which message it's the ack.
>>>>
>>>> Also, I notice the sequence number received from the router doesn't
>>>> seem to change. All the authentication requests received have the same
>>>> number (256). Another peculiar thing is that in the failed case the SN
>>>> we send starts with 0.
>>>>
>>>> I suppose since the authentication ack never arrives, the next steps
>>>> are never completed.
>>>>
>>>> Does that help?
>>> From the supplicant logs we have successfully received the
>>> authentication response
>>> and sent out the association request. So are you referring to not receiving ACK
>>> for association request??
>>
>> No, from the capture there's no association request in the bad case,
>> only in the good one.
>>
>>> It would be nice to get the capture without any filters?
>>
>> http://people.freedesktop.org/~felipec/wpa/wpa-bad.pcapng
>> http://people.freedesktop.org/~felipec/wpa/wpa-good.pcapng
>>
>
> From the logs we can see that we have received authentication response,
> so the association request is getting dropped somewhere? We might
> need the mac80211 and iwlwifi trace-cmd logs to check for the drop.
>
> http://wireless.kernel.org/en/developers/Documentation/mac80211/tracing
There you go:
http://people.freedesktop.org/~felipec/wpa/trace.dat.xz
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 4/4] wl1251: spi: add device tree support
From: Kumar Gala @ 2013-10-28 19:30 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: Sebastian Reichel, Mark Rutland, linux-doc, Tony Lindgren,
Russell King, Sachin Kamat, Ian Campbell, Sebastian Reichel,
Luciano Coelho, devicetree, Pawel Moll, Stephen Warren,
John W. Linville, Rob Herring, Bill Pemberton,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Greg Kroah-Hartman, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, Felipe Balbi, Rob Landley, netdev
In-Reply-To: <CANOLnOP=antQDwQLxWhuB8+-kZh9x-JJXrXmOz3FH67fM2Lang@mail.gmail.com>
On Oct 28, 2013, at 12:15 PM, Grazvydas Ignotas wrote:
> On Mon, Oct 28, 2013 at 8:37 AM, Kumar Gala <galak@codeaurora.org> wrote:
>> On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
>>> +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>>> @@ -0,0 +1,36 @@
>>> +* Texas Instruments wl1251 controller
>>> +
>>> +The wl1251 chip can be connected via SPI or via SDIO. The linux
>>> +kernel currently only supports device tree for the SPI variant.
>>> +
>>
>> From the binding I have no idea what this chip actually does, also we don't normally reference linux kernel support in bindings specs (so please remove it).
>>
>> However, what would expect the SDIO binding to look like? Or more specifically, how would you distinguish the SPI vs SDIO binding/connection? I'm wondering if the compatible should be something like "ti,wl1251-spi" and than the sdio can be "ti,wl1251-sdio"
>
> When connected to SDIO, it doesn't act as standard SDIO device and
> can't be probed (standard SDIO registers missing), so information has
> to come some other way. That used to partially come through
> platform_data and partially through a callback from mmc subsystem (see
> pandora_wl1251_init_card() in
> arch/arm/mach-omap2/board-omap3pandora.c). I don't know much about DT,
> but maybe the information that comes from SDIO registers on "normal"
> SDIO devices should come through DT in this case too? I don't really
> know how that should be integrated with mmc subsystem though..
Ok, my point is still valid that we can use a different compatible for the SDIO case even if its no standard SDIO vs the SPI case.
>
>>> +Required properties:
>>> +- compatible : Should be "ti,wl1251"
>>
>> reg is not listed as a required prop.
>>
>>> +- interrupts : Should contain interrupt line
>>> +- interrupt-parent : Should be the phandle for the interrupt
>>> + controller that services interrupts for this device
>>> +- vio-supply : phandle to regulator providing VIO
>>> +- power-gpio : GPIO connected to chip's PMEN pin
>>
>> should be vendor prefixed: ti,power-gpio
>>
>>> +- For additional required properties on SPI, please consult
>>> + Documentation/devicetree/bindings/spi/spi-bus.txt
>>> +
>>> +Optional properties:
>>> +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
>>
>> can you be a bit more specific on what cfg will be loaded. Also, is this property a boolean, if so how do I know which eeprom the cfg is loaded from (is it one that is directly connected to the wl1251?
>
> wl1251 is a wifi chip that can have an optional eeprom connected to it
> to store things like calibration stuff and MAC address, and that
> eeprom is usually inside a single module with some additional radio
> related chips. If the eeprom is connected (like the module on pandora
> board has), the driver can issue command to the firmware running on
> chip to load that data on it's startup, alternatively the driver can
> load calibration from other storage (like it happens on N900).
So sounds like a boolean. I think just adding that its a boolean and maybe something like "configuration (calibration data, MAC addr, etc..)"
- k
>
>
> Gražvydas
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Krishna Chaitanya @ 2013-10-28 19:27 UTC (permalink / raw)
To: Felipe Contreras
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CAMP44s0087jYz5AiEaEzwt7GqH9ed8PWE1CmvMPr4Dqn3yE6rA@mail.gmail.com>
On Tue, Oct 29, 2013 at 12:13 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Oct 28, 2013 at 12:28 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
>> On Mon, Oct 28, 2013 at 11:30 PM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>
>>> The authentication response does come back in both cases though, it's
>>> just the acknowledgement that is missing. Unfortunately I cannot
>>> figure out for which message it's the ack.
>>>
>>> Also, I notice the sequence number received from the router doesn't
>>> seem to change. All the authentication requests received have the same
>>> number (256). Another peculiar thing is that in the failed case the SN
>>> we send starts with 0.
>>>
>>> I suppose since the authentication ack never arrives, the next steps
>>> are never completed.
>>>
>>> Does that help?
>> From the supplicant logs we have successfully received the
>> authentication response
>> and sent out the association request. So are you referring to not receiving ACK
>> for association request??
>
> No, from the capture there's no association request in the bad case,
> only in the good one.
>
>> It would be nice to get the capture without any filters?
>
> http://people.freedesktop.org/~felipec/wpa/wpa-bad.pcapng
> http://people.freedesktop.org/~felipec/wpa/wpa-good.pcapng
>
>From the logs we can see that we have received authentication response,
so the association request is getting dropped somewhere? We might
need the mac80211 and iwlwifi trace-cmd logs to check for the drop.
http://wireless.kernel.org/en/developers/Documentation/mac80211/tracing
Another side porint? Also all the beacons from that AP are malformed
but probe responses are fine, weird??
^ permalink raw reply
* Re: iwlegacy (4965) - what would 0x8000 as the completed TX rate indicate?
From: Adrian Chadd @ 2013-10-28 19:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1382968966.17956.15.camel@jlt4.sipsolutions.net>
Hi!
On 28 October 2013 07:02, Johannes Berg <johannes@sipsolutions.net> wrote:
[snip]
>> The status indicates things are transmitting and completing fine.
>>
>> So, any ideas what that 0x8000 rate in the rate completion means?
>
> I think that just means it used the other antenna and rate 0, since the
> bits 0x1c000 contain the antenna bitmap that was used (up to three can
> be used for each transmission)
Well, what's rate=0 mean?
And 0x8000 is bit 11 set, which is HT40. I definitely don't have HT40 enabled.
-a
^ permalink raw reply
* Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Mark Brown @ 2013-10-28 19:23 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: Alexander Shiyan, Luciano Coelho, Mark Rutland, devicetree,
Russell King, Pawel Moll, Ian Campbell, Tony Lindgren,
Greg Kroah-Hartman, Stephen Warren, linux-doc, John W. Linville,
Rob Herring, linux-kernel@vger.kernel.org, Sachin Kamat,
Bill Pemberton, Felipe Balbi, Rob Landley, netdev,
linux-wireless@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CANOLnONKcC1i19ypb4rh2Rff3WsVhhuUhNvZvYwDV2-ZNtjVxQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
On Mon, Oct 28, 2013 at 07:29:52PM +0200, Grazvydas Ignotas wrote:
> When wl12xx family of chips is connected through SDIO, we already have
> that pin set up as a regulator controlled with the help of mmc
> subsystem. When time comes to communicate with the chip, mmc subsystem
> sees this as yet another SD card and looks for associated regulator
> for it, and the board file has that set up as a fixed regulator
> controlling that pin (see pandora_vmmc3 in
> arch/arm/mach-omap2/board-omap3pandora.c). To prevent poweroff after
> first SDIO communications are over, pm_runtime calls are used in
> drivers/net/wireless/ti/wl1251/sdio.c .
Is this actually controlling VMMC though, or is it some other control?
If it's not controlling VMMC then it shouldn't say that it is.
> I don't know if something similar can be done done in SPI case, but
> I'm sure this is not the first your-so-called regulator misuse.
It's not the first but that doesn't make controlling something other
than a regulator through the regulator API any less broken.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Dan Williams @ 2013-10-28 19:01 UTC (permalink / raw)
To: Chauhan, Rajesh
Cc: Rodriguez, Luis, Johannes Berg, linux-wireless@vger.kernel.org,
Malinen, Jouni, Bahini, Henri, Chang, Leo, Luo, Xun
In-Reply-To: <D19FD2B13A40CD4B8DA64DB9B8F112E9218E461D@nasanexd01a.na.qualcomm.com>
On Mon, 2013-10-28 at 18:08 +0000, Chauhan, Rajesh wrote:
> Hi Luis,
>
> For "enough information for proper usage" - how about if I add an attribute for the source of interference (say, for example, "cellular") for each of those frequency range?
When you say "cellular" here, do mean a WWAN card in the same machine,
sharing the antenna (or using a very very nearby antenna) with the WiFi
card? Or do you mean a close-by phone, or a tower itself? How is this
different from BT coexistence or WiMAX coexistence?
Dan
> Regards,
> Rajesh Chauhan
>
> -----Original Message-----
> From: mcgrof@gmail.com [mailto:mcgrof@gmail.com] On Behalf Of Luis R. Rodriguez
> Sent: Sunday, October 20, 2013 3:39 AM
> To: Chauhan, Rajesh
> Cc: Dan Williams; Johannes Berg; linux-wireless@vger.kernel.org; Malinen, Jouni; Bahini, Henri; Chang, Leo; Luo, Xun
> Subject: Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
>
> On Thu, Oct 17, 2013 at 9:51 PM, Chauhan, Rajesh <rajeshc@qca.qualcomm.com> wrote:
> > Hi Dan,
> >
> > Thanks for your comments.
> >
> > Current patch is to report event asynchronously and that would be needed even if we have your suggested interface of client collecting that information upfront, which seems like you also kind of agree, because RF environment may change later and generating an event at that time with frequency details would help. So your suggested approach of "mechanism for the client to get this information" in itself seems like a candidate for a separate patch.
>
> The infrastructure for this sort of thing that me, Inaky and Marcel had proposed in 2007 is the Frequency Broker:
>
> http://wireless.kernel.org/en/developers/FrequencyBroker
>
> > On the race condition which you described - thanks!, but it is something which implementation of driver would need to take care. Similarly, user space can have implementation to cache information on receipt of the event to use it later.
>
> This patch is vague. Once we set something as API we have to live with it, I am not comfortable with this patch having enough information for proper usage by different drivers for the same purpose or intent. The only real positive argument that could be used here is where something like Android might have already embraced some similar API but are we going to always just enable API on Linux just because Android did it without thinking about proper long term architecture? I don't think so.
>
> Luis
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Felipe Contreras @ 2013-10-28 18:43 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CABPxzY+xJ7kst-sYwP8RJwMO_zkNYWKaYy=_LS7WQfuxquK24w@mail.gmail.com>
On Mon, Oct 28, 2013 at 12:28 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> On Mon, Oct 28, 2013 at 11:30 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>
>> The authentication response does come back in both cases though, it's
>> just the acknowledgement that is missing. Unfortunately I cannot
>> figure out for which message it's the ack.
>>
>> Also, I notice the sequence number received from the router doesn't
>> seem to change. All the authentication requests received have the same
>> number (256). Another peculiar thing is that in the failed case the SN
>> we send starts with 0.
>>
>> I suppose since the authentication ack never arrives, the next steps
>> are never completed.
>>
>> Does that help?
> From the supplicant logs we have successfully received the
> authentication response
> and sent out the association request. So are you referring to not receiving ACK
> for association request??
No, from the capture there's no association request in the bad case,
only in the good one.
> It would be nice to get the capture without any filters?
http://people.freedesktop.org/~felipec/wpa/wpa-bad.pcapng
http://people.freedesktop.org/~felipec/wpa/wpa-good.pcapng
--
Felipe Contreras
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Krishna Chaitanya @ 2013-10-28 18:28 UTC (permalink / raw)
To: Felipe Contreras
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CAMP44s2Cvw9HF3c3Asuq+bTSD36Gw6PXOUVjAcCD+hf6KB_awg@mail.gmail.com>
On Mon, Oct 28, 2013 at 11:30 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> The authentication response does come back in both cases though, it's
> just the acknowledgement that is missing. Unfortunately I cannot
> figure out for which message it's the ack.
>
> Also, I notice the sequence number received from the router doesn't
> seem to change. All the authentication requests received have the same
> number (256). Another peculiar thing is that in the failed case the SN
> we send starts with 0.
>
> I suppose since the authentication ack never arrives, the next steps
> are never completed.
>
> Does that help?
>From the supplicant logs we have successfully received the
authentication response
and sent out the association request. So are you referring to not receiving ACK
for association request??
It would be nice to get the capture without any filters?
--
Thanks,
Regards,
Chaitanya T K.
Mobile:+91-9963910010.
^ permalink raw reply
* [PATCH 5/5] cfg80211: fix dfs channel state after stopping AP
From: Janusz Dziedzic @ 2013-10-28 18:27 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Marek Puzyniak
In-Reply-To: <1382984824-3729-1-git-send-email-janusz.dziedzic@tieto.com>
From: Marek Puzyniak <marek.puzyniak@tieto.com>
This can be called when a mode of operation that can supports
initiating radiation on a DFS channel leaves that channel to
ensure that if the mode of operation is started again on it
that it will require a new channel availability check.
Signed-off-by: Marek Puzyniak <marek.puzyniak@tieto.com>
Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
include/net/cfg80211.h | 10 ++++++++++
net/mac80211/cfg.c | 6 ++++++
net/wireless/mlme.c | 7 +++++++
3 files changed, 23 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8b52fcb..cc1ba48 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4135,6 +4135,16 @@ void cfg80211_cac_event(struct net_device *netdev,
struct cfg80211_chan_def *chandef,
enum nl80211_radar_event event, gfp_t gfp);
+/**
+ * cfg80211_leave_dfs_channel - Leaving dfs channel
+ * @wiphy: the wiphy
+ * @chandef: chandef for the current channel
+ *
+ * This function is called when dfs channel is being not used for diffrent
+ * reasons. Make channel DFS USABLE again.
+ */
+void cfg80211_leave_dfs_channel(struct wiphy *wiphy,
+ struct cfg80211_chan_def *chandef);
/**
* cfg80211_cqm_pktloss_notify - notify userspace about packetloss to peer
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 5690d21..10778ae 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1096,6 +1096,12 @@ static int ieee80211_stop_ap(struct wiphy *wiphy, struct net_device *dev)
cfg80211_cac_event(sdata->dev, &chandef,
NL80211_RADAR_CAC_ABORTED,
GFP_KERNEL);
+ } else if (sdata->radar_required) {
+ /*
+ * AP stopped on DFS channel so change that channel state
+ * to NL80211_DFS_USABLE again.
+ */
+ cfg80211_leave_dfs_channel(wiphy, &sdata->vif.bss_conf.chandef);
}
drv_stop_ap(sdata->local, sdata);
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index a50c27b..c75b1d3 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -797,3 +797,10 @@ void cfg80211_cac_event(struct net_device *netdev,
nl80211_radar_notify(rdev, chandef, event, netdev, gfp);
}
EXPORT_SYMBOL(cfg80211_cac_event);
+
+void cfg80211_leave_dfs_channel(struct wiphy *wiphy,
+ struct cfg80211_chan_def *chandef)
+{
+ cfg80211_set_dfs_state(wiphy, chandef, NL80211_DFS_USABLE);
+}
+EXPORT_SYMBOL(cfg80211_leave_dfs_channel);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/5] cfg80211: add helper functions for start/end freq
From: Janusz Dziedzic @ 2013-10-28 18:27 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Janusz Dziedzic
In-Reply-To: <1382984824-3729-1-git-send-email-janusz.dziedzic@tieto.com>
Add helper fuctions for start/end freq.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
net/wireless/chan.c | 44 ++++++++++++++++++++++++++++++--------------
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 16f3c3a..f74dae3 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -277,6 +277,32 @@ void cfg80211_set_dfs_state(struct wiphy *wiphy,
width, dfs_state);
}
+static u32 cfg80211_get_start_freq(u32 center_freq,
+ u32 bandwidth)
+{
+ u32 start_freq;
+
+ if (bandwidth <= 20)
+ start_freq = center_freq;
+ else
+ start_freq = center_freq - bandwidth/2 + 10;
+
+ return start_freq;
+}
+
+static u32 cfg80211_get_end_freq(u32 center_freq,
+ u32 bandwidth)
+{
+ u32 end_freq;
+
+ if (bandwidth <= 20)
+ end_freq = center_freq;
+ else
+ end_freq = center_freq + bandwidth/2 - 10;
+
+ return end_freq;
+}
+
static int cfg80211_get_chans_dfs_required(struct wiphy *wiphy,
u32 center_freq,
u32 bandwidth)
@@ -284,13 +310,8 @@ static int cfg80211_get_chans_dfs_required(struct wiphy *wiphy,
struct ieee80211_channel *c;
u32 freq, start_freq, end_freq;
- if (bandwidth <= 20) {
- start_freq = center_freq;
- end_freq = center_freq;
- } else {
- start_freq = center_freq - bandwidth/2 + 10;
- end_freq = center_freq + bandwidth/2 - 10;
- }
+ start_freq = cfg80211_get_start_freq(center_freq, bandwidth);
+ end_freq = cfg80211_get_end_freq(center_freq, bandwidth);
for (freq = start_freq; freq <= end_freq; freq += 20) {
c = ieee80211_get_channel(wiphy, freq);
@@ -337,13 +358,8 @@ static bool cfg80211_secondary_chans_ok(struct wiphy *wiphy,
struct ieee80211_channel *c;
u32 freq, start_freq, end_freq;
- if (bandwidth <= 20) {
- start_freq = center_freq;
- end_freq = center_freq;
- } else {
- start_freq = center_freq - bandwidth/2 + 10;
- end_freq = center_freq + bandwidth/2 - 10;
- }
+ start_freq = cfg80211_get_start_freq(center_freq, bandwidth);
+ end_freq = cfg80211_get_end_freq(center_freq, bandwidth);
for (freq = start_freq; freq <= end_freq; freq += 20) {
c = ieee80211_get_channel(wiphy, freq);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/5] cfg80211: DFS check chandef usable before CAC
From: Janusz Dziedzic @ 2013-10-28 18:27 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Janusz Dziedzic
In-Reply-To: <1382984824-3729-1-git-send-email-janusz.dziedzic@tieto.com>
Check chandef we get in CAC request is usable for CAC.
All channels have to be DFS channels. Allow DFS_USABLE
and DFS_AVAILABLE channels mix. At least one channel
has to be DFS_USABLE (require CAC).
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
net/wireless/chan.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++
net/wireless/core.h | 11 +++++++
net/wireless/nl80211.c | 2 +-
3 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index f74dae3..a6f5c4c 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -351,6 +351,81 @@ int cfg80211_chandef_dfs_required(struct wiphy *wiphy,
}
EXPORT_SYMBOL(cfg80211_chandef_dfs_required);
+static int cfg80211_get_chans_dfs_usable(struct wiphy *wiphy,
+ u32 center_freq,
+ u32 bandwidth)
+{
+ struct ieee80211_channel *c;
+ u32 freq, start_freq, end_freq;
+ int count = 0;
+
+ start_freq = cfg80211_get_start_freq(center_freq, bandwidth);
+ end_freq = cfg80211_get_end_freq(center_freq, bandwidth);
+
+ /*
+ * Check entire range of channels for the bandwidth.
+ * Check all channels are DFS channels (DFS_USABLE or
+ * DFS_AVAILABLE). Return number of usable channels
+ * (require CAC).
+ */
+ for (freq = start_freq; freq <= end_freq; freq += 20) {
+ c = ieee80211_get_channel(wiphy, freq);
+ if (!c)
+ return -EINVAL;
+
+ if (c->flags & IEEE80211_CHAN_DISABLED)
+ return -EINVAL;
+
+ if (!(c->flags & IEEE80211_CHAN_RADAR))
+ return -EINVAL;
+
+ if (c->dfs_state == NL80211_DFS_UNAVAILABLE)
+ return -EINVAL;
+
+ if (c->dfs_state == NL80211_DFS_USABLE)
+ count++;
+ }
+
+ return count;
+}
+
+bool cfg80211_chandef_dfs_usable(struct wiphy *wiphy,
+ const struct cfg80211_chan_def *chandef)
+{
+ int width;
+ int r1, r2 = 0;
+
+ if (WARN_ON(!cfg80211_chandef_valid(chandef)))
+ return false;
+
+ width = cfg80211_chandef_get_width(chandef);
+ if (width < 0)
+ return false;
+
+ r1 = cfg80211_get_chans_dfs_usable(wiphy, chandef->center_freq1,
+ width);
+
+ if (r1 < 0)
+ return false;
+
+ switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_80P80:
+ WARN_ON(!chandef->center_freq2);
+ r2 = cfg80211_get_chans_dfs_usable(wiphy,
+ chandef->center_freq2,
+ width);
+ if (r2 < 0)
+ return false;
+ break;
+ default:
+ WARN_ON(chandef->center_freq2);
+ break;
+ }
+
+ return (r1 + r2 > 0);
+}
+
+
static bool cfg80211_secondary_chans_ok(struct wiphy *wiphy,
u32 center_freq, u32 bandwidth,
u32 prohibited_flags)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index eb0f7a3..eb24a53 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -382,6 +382,17 @@ int cfg80211_can_use_iftype_chan(struct cfg80211_registered_device *rdev,
enum cfg80211_chan_mode chanmode,
u8 radar_detect);
+/**
+ * cfg80211_chandef_dfs_usable - checks if chandef is usable and we can
+ * start CAC on such chandef.
+ * @wiphy: the wiphy to validate against
+ * @chandef: the channel definition to check
+ * Return: Return true if all channels available and at least
+ * one channel required CAC (NL80211_DFS_USABLE)
+ */
+bool cfg80211_chandef_dfs_usable(struct wiphy *wiphy,
+ const struct cfg80211_chan_def *chandef);
+
void cfg80211_set_dfs_state(struct wiphy *wiphy,
const struct cfg80211_chan_def *chandef,
enum nl80211_dfs_state dfs_state);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cbbef88..1cb1cd9 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5604,7 +5604,7 @@ static int nl80211_start_radar_detection(struct sk_buff *skb,
if (err == 0)
return -EINVAL;
- if (chandef.chan->dfs_state != NL80211_DFS_USABLE)
+ if (!cfg80211_chandef_dfs_usable(wdev->wiphy, &chandef))
return -EINVAL;
if (!rdev->ops->start_radar_detection)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/5] cfg80211/mac80211: DFS setup chandef for cac event
From: Janusz Dziedzic @ 2013-10-28 18:27 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Janusz Dziedzic
To report channel width correctly we have
to send correct channel parameters from
mac80211 when calling cfg80211_cac_event().
This is required in case of using channel width
higher than 20MHz and we have to set correct
dfs channel state after CAC (NL80211_DFS_AVAILABLE).
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
include/net/cfg80211.h | 2 ++
net/mac80211/cfg.c | 5 ++++-
net/mac80211/iface.c | 5 ++++-
net/mac80211/mlme.c | 6 ++++--
net/mac80211/util.c | 3 +++
net/wireless/mlme.c | 8 +++-----
6 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 45f6bf5..8b52fcb 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4123,6 +4123,7 @@ void cfg80211_radar_event(struct wiphy *wiphy,
/**
* cfg80211_cac_event - Channel availability check (CAC) event
* @netdev: network device
+ * @chandef: chandef for the current channel
* @event: type of event
* @gfp: context flags
*
@@ -4131,6 +4132,7 @@ void cfg80211_radar_event(struct wiphy *wiphy,
* also by full-MAC drivers.
*/
void cfg80211_cac_event(struct net_device *netdev,
+ struct cfg80211_chan_def *chandef,
enum nl80211_radar_event event, gfp_t gfp);
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 7501497..5690d21 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1050,6 +1050,7 @@ static int ieee80211_stop_ap(struct wiphy *wiphy, struct net_device *dev)
struct ieee80211_local *local = sdata->local;
struct beacon_data *old_beacon;
struct probe_resp *old_probe_resp;
+ struct cfg80211_chan_def chandef;
old_beacon = rtnl_dereference(sdata->u.ap.beacon);
if (!old_beacon)
@@ -1090,8 +1091,10 @@ static int ieee80211_stop_ap(struct wiphy *wiphy, struct net_device *dev)
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED);
if (sdata->wdev.cac_started) {
+ chandef = sdata->vif.bss_conf.chandef;
cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);
- cfg80211_cac_event(sdata->dev, NL80211_RADAR_CAC_ABORTED,
+ cfg80211_cac_event(sdata->dev, &chandef,
+ NL80211_RADAR_CAC_ABORTED,
GFP_KERNEL);
}
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index e48f103..cb5e339 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -749,6 +749,7 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
u32 hw_reconf_flags = 0;
int i, flushed;
struct ps_data *ps;
+ struct cfg80211_chan_def chandef;
clear_bit(SDATA_STATE_RUNNING, &sdata->state);
@@ -823,11 +824,13 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);
if (sdata->wdev.cac_started) {
+ chandef = sdata->vif.bss_conf.chandef;
WARN_ON(local->suspended);
mutex_lock(&local->iflist_mtx);
ieee80211_vif_release_channel(sdata);
mutex_unlock(&local->iflist_mtx);
- cfg80211_cac_event(sdata->dev, NL80211_RADAR_CAC_ABORTED,
+ cfg80211_cac_event(sdata->dev, &chandef,
+ NL80211_RADAR_CAC_ABORTED,
GFP_KERNEL);
}
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 91cc828..a2487da 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1400,10 +1400,12 @@ void ieee80211_dfs_cac_timer_work(struct work_struct *work)
struct ieee80211_sub_if_data *sdata =
container_of(delayed_work, struct ieee80211_sub_if_data,
dfs_cac_timer_work);
+ struct cfg80211_chan_def chandef = sdata->vif.bss_conf.chandef;
ieee80211_vif_release_channel(sdata);
-
- cfg80211_cac_event(sdata->dev, NL80211_RADAR_CAC_FINISHED, GFP_KERNEL);
+ cfg80211_cac_event(sdata->dev, &chandef,
+ NL80211_RADAR_CAC_FINISHED,
+ GFP_KERNEL);
}
/* MLME */
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index aefb9d5..f704415 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2253,14 +2253,17 @@ u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
void ieee80211_dfs_cac_cancel(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata;
+ struct cfg80211_chan_def chandef;
mutex_lock(&local->iflist_mtx);
list_for_each_entry(sdata, &local->interfaces, list) {
cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);
if (sdata->wdev.cac_started) {
+ chandef = sdata->vif.bss_conf.chandef;
ieee80211_vif_release_channel(sdata);
cfg80211_cac_event(sdata->dev,
+ &chandef,
NL80211_RADAR_CAC_ABORTED,
GFP_KERNEL);
}
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 6a6b1c8..a50c27b 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -763,12 +763,12 @@ void cfg80211_radar_event(struct wiphy *wiphy,
EXPORT_SYMBOL(cfg80211_radar_event);
void cfg80211_cac_event(struct net_device *netdev,
+ struct cfg80211_chan_def *chandef,
enum nl80211_radar_event event, gfp_t gfp)
{
struct wireless_dev *wdev = netdev->ieee80211_ptr;
struct wiphy *wiphy = wdev->wiphy;
struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
- struct cfg80211_chan_def chandef;
unsigned long timeout;
trace_cfg80211_cac_event(netdev, event);
@@ -779,14 +779,12 @@ void cfg80211_cac_event(struct net_device *netdev,
if (WARN_ON(!wdev->channel))
return;
- cfg80211_chandef_create(&chandef, wdev->channel, NL80211_CHAN_NO_HT);
-
switch (event) {
case NL80211_RADAR_CAC_FINISHED:
timeout = wdev->cac_start_time +
msecs_to_jiffies(IEEE80211_DFS_MIN_CAC_TIME_MS);
WARN_ON(!time_after_eq(jiffies, timeout));
- cfg80211_set_dfs_state(wiphy, &chandef, NL80211_DFS_AVAILABLE);
+ cfg80211_set_dfs_state(wiphy, chandef, NL80211_DFS_AVAILABLE);
break;
case NL80211_RADAR_CAC_ABORTED:
break;
@@ -796,6 +794,6 @@ void cfg80211_cac_event(struct net_device *netdev,
}
wdev->cac_started = false;
- nl80211_radar_notify(rdev, &chandef, event, netdev, gfp);
+ nl80211_radar_notify(rdev, chandef, event, netdev, gfp);
}
EXPORT_SYMBOL(cfg80211_cac_event);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/5] mac80211: DFS setup chandef for radar_event correctly
From: Janusz Dziedzic @ 2013-10-28 18:27 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Janusz Dziedzic
In-Reply-To: <1382984824-3729-1-git-send-email-janusz.dziedzic@tieto.com>
Setup chandef for radar event correctly, before we
will clear this in ieee80211_dfs_cac_cancel() function.
Without this patch mac80211 will report wrong channel
width in case we will get radar event during active CAC.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
net/mac80211/util.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index f704415..c286d9b 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2275,17 +2275,15 @@ void ieee80211_dfs_radar_detected_work(struct work_struct *work)
{
struct ieee80211_local *local =
container_of(work, struct ieee80211_local, radar_detected_work);
- struct cfg80211_chan_def chandef;
+ struct cfg80211_chan_def chandef = local->hw.conf.chandef;
ieee80211_dfs_cac_cancel(local);
if (local->use_chanctx)
/* currently not handled */
WARN_ON(1);
- else {
- chandef = local->hw.conf.chandef;
+ else
cfg80211_radar_event(local->hw.wiphy, &chandef, GFP_KERNEL);
- }
}
void ieee80211_radar_detected(struct ieee80211_hw *hw)
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Chauhan, Rajesh @ 2013-10-28 18:14 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Rodriguez, Luis, Malinen, Jouni,
Bahini, Henri, Chang, Leo, Luo, Xun, Chauhan, Rajesh
In-Reply-To: <1382971479.17956.29.camel@jlt4.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCkluIGFub3RoZXIgZW1haWwsIEkgYW0gcHJvcG9zaW5nIHRvIGFkZCBh
biBhdHRyaWJ1dGUgZm9yIHRoZSBzb3VyY2Ugb2YgaW50ZXJmZXJlbmNlIChmb3IgZXhhbXBsZSwg
ImNlbGx1bGFyIikgZm9yIGVhY2ggZnJlcXVlbmN5IHJhbmdlLiBTbyB0aGF0IHdheSBkcml2ZXIg
d2lsbCBoYXZlIHRvIHNwZWNpZnkgZXhhY3Qgc291cmNlIG9mIGludGVyZmVyZW5jZSBhbmQgdGhh
dCB3b3VsZCBhbHNvIGF2b2lkIHJhbmRvbSBjaGFubmVsIHN0ZWVyaW5nLiBJIHdvdWxkIHNlbmQg
b3V0IHVwZGF0ZWQgcGF0Y2ggc2V0IHdpdGggdGhhdCBjaGFuZ2UuDQoNClJlZ2FyZHMsDQpSYWpl
c2ggQ2hhdWhhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9oYW5uZXMg
QmVyZyBbbWFpbHRvOmpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXRdIA0KU2VudDogTW9uZGF5LCBP
Y3RvYmVyIDI4LCAyMDEzIDc6NDUgQU0NClRvOiBDaGF1aGFuLCBSYWplc2gNCkNjOiBsaW51eC13
aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IFJvZHJpZ3VleiwgTHVpczsgTWFsaW5lbiwgSm91bmk7
IEJhaGluaSwgSGVucmk7IENoYW5nLCBMZW87IEx1bywgWHVuDQpTdWJqZWN0OiBSZTogW1BBVENI
XSBjZmc4MDIxMS9ubDgwMjExOiBBZGQgc3VwcG9ydCB0byByZXBvcnQgdW5zYWZlIGZyZXF1ZW5j
eSByYW5nZXMocykNCg0KT24gVGh1LCAyMDEzLTEwLTE3IGF0IDE3OjE5ICswMDAwLCBDaGF1aGFu
LCBSYWplc2ggd3JvdGU6DQo+IEhpIEpvaGFubmVzLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGNv
bW1lbnQuIFB1cnBvc2Ugb2YgdGhpcyBwYXRjaCBpcyB0byBhZGQgYW4gQVBJIGZvciANCj4gV0xB
TiBkcml2ZXIgdG8gcmVwb3J0IGZyZXF1ZW5jeSByYW5nZXMgd2hpY2ggc2hvdWxkIGJlIGF2b2lk
ZWQgZm9yIA0KPiBTQVAvUDJQLUdPIGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlLg0KPiANCj4gSG93
IGFib3V0IGlmIEkgcmV3b3JkIGNvbW1pdCB0ZXN0IGFzIGJlbG93Pw0KPiANCj4gY2ZnODAyMTEv
bmw4MDIxMTogQWRkIEFQSSB0byByZXBvcnQgZnJlcXVlbmN5IHJhbmdlKHMpIHRvIGJlIGF2b2lk
ZWQNCj4gDQo+IEFkZCBzdXBwb3J0IGZvciBXTEFOIGRyaXZlciB0byByZXBvcnQgZnJlcXVlbmN5
IHJhbmdlKHMpIHRvIGJlIGF2b2lkZWQgDQo+IGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlLg0KDQpX
b3VsZG4ndCBpdCBtYWtlIG1vcmUgc2Vuc2UgdG8gcmFpc2UgYSAiZGV0ZWN0ZWQgaW50ZXJmZXJl
bmNlIiBldmVudD8NClRoZXJlJ3Mgbm8gd2F5IHRvIGtub3cgd2hhdCBjaGFubmVsIHJhbmdlIGlz
IGFmZmVjdGVkIGFueXdheS4gSSBmZWFyIHRoYXQgdGhpcyBpcyB2YWd1ZSBlbm91Z2ggZm9yIHlv
dSB0byAoYWIpdXNlIGl0IGZvciBhbGwga2luZHMgb2YgcmFuZG9tICJjaGFubmVsIHN0ZWVyaW5n
IiBmcm9tIHRoZSBkcml2ZXIuDQoNCmpvaGFubmVzDQoNCg==
^ permalink raw reply
* RE: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Chauhan, Rajesh @ 2013-10-28 18:08 UTC (permalink / raw)
To: Rodriguez, Luis
Cc: Dan Williams, Johannes Berg, linux-wireless@vger.kernel.org,
Malinen, Jouni, Bahini, Henri, Chang, Leo, Luo, Xun,
Chauhan, Rajesh
In-Reply-To: <CAB=NE6UkKuSzH4x2SjkE0pRTVCVa3k7g=_ZeU_JE+t2OovRoEg@mail.gmail.com>
SGkgTHVpcywNCg0KRm9yICJlbm91Z2ggaW5mb3JtYXRpb24gZm9yIHByb3BlciB1c2FnZSIgLSBo
b3cgYWJvdXQgaWYgSSBhZGQgYW4gYXR0cmlidXRlIGZvciB0aGUgc291cmNlIG9mIGludGVyZmVy
ZW5jZSAoc2F5LCBmb3IgZXhhbXBsZSwgImNlbGx1bGFyIikgZm9yIGVhY2ggb2YgdGhvc2UgZnJl
cXVlbmN5IHJhbmdlPw0KDQpSZWdhcmRzLA0KUmFqZXNoIENoYXVoYW4NCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IG1jZ3JvZkBnbWFpbC5jb20gW21haWx0bzptY2dyb2ZAZ21h
aWwuY29tXSBPbiBCZWhhbGYgT2YgTHVpcyBSLiBSb2RyaWd1ZXoNClNlbnQ6IFN1bmRheSwgT2N0
b2JlciAyMCwgMjAxMyAzOjM5IEFNDQpUbzogQ2hhdWhhbiwgUmFqZXNoDQpDYzogRGFuIFdpbGxp
YW1zOyBKb2hhbm5lcyBCZXJnOyBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IE1hbGlu
ZW4sIEpvdW5pOyBCYWhpbmksIEhlbnJpOyBDaGFuZywgTGVvOyBMdW8sIFh1bg0KU3ViamVjdDog
UmU6IFtQQVRDSF0gY2ZnODAyMTEvbmw4MDIxMTogQWRkIHN1cHBvcnQgdG8gcmVwb3J0IHVuc2Fm
ZSBmcmVxdWVuY3kgcmFuZ2VzKHMpDQoNCk9uIFRodSwgT2N0IDE3LCAyMDEzIGF0IDk6NTEgUE0s
IENoYXVoYW4sIFJhamVzaCA8cmFqZXNoY0BxY2EucXVhbGNvbW0uY29tPiB3cm90ZToNCj4gSGkg
RGFuLA0KPg0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQo+DQo+IEN1cnJlbnQgcGF0Y2gg
aXMgdG8gcmVwb3J0IGV2ZW50IGFzeW5jaHJvbm91c2x5IGFuZCB0aGF0IHdvdWxkIGJlIG5lZWRl
ZCBldmVuIGlmIHdlIGhhdmUgeW91ciBzdWdnZXN0ZWQgaW50ZXJmYWNlIG9mIGNsaWVudCBjb2xs
ZWN0aW5nIHRoYXQgaW5mb3JtYXRpb24gdXBmcm9udCwgd2hpY2ggc2VlbXMgbGlrZSB5b3UgYWxz
byBraW5kIG9mIGFncmVlLCBiZWNhdXNlIFJGIGVudmlyb25tZW50IG1heSBjaGFuZ2UgbGF0ZXIg
YW5kIGdlbmVyYXRpbmcgYW4gZXZlbnQgYXQgdGhhdCB0aW1lIHdpdGggZnJlcXVlbmN5IGRldGFp
bHMgd291bGQgaGVscC4gU28geW91ciBzdWdnZXN0ZWQgYXBwcm9hY2ggb2YgIm1lY2hhbmlzbSBm
b3IgdGhlIGNsaWVudCB0byBnZXQgdGhpcyBpbmZvcm1hdGlvbiIgaW4gaXRzZWxmIHNlZW1zIGxp
a2UgYSBjYW5kaWRhdGUgZm9yIGEgc2VwYXJhdGUgcGF0Y2guDQoNClRoZSBpbmZyYXN0cnVjdHVy
ZSBmb3IgdGhpcyBzb3J0IG9mIHRoaW5nIHRoYXQgbWUsIEluYWt5IGFuZCBNYXJjZWwgaGFkIHBy
b3Bvc2VkIGluIDIwMDcgaXMgdGhlIEZyZXF1ZW5jeSBCcm9rZXI6DQoNCmh0dHA6Ly93aXJlbGVz
cy5rZXJuZWwub3JnL2VuL2RldmVsb3BlcnMvRnJlcXVlbmN5QnJva2VyDQoNCj4gT24gdGhlIHJh
Y2UgY29uZGl0aW9uIHdoaWNoIHlvdSBkZXNjcmliZWQgLSB0aGFua3MhLCBidXQgaXQgaXMgc29t
ZXRoaW5nIHdoaWNoIGltcGxlbWVudGF0aW9uIG9mIGRyaXZlciB3b3VsZCBuZWVkIHRvIHRha2Ug
Y2FyZS4gU2ltaWxhcmx5LCB1c2VyIHNwYWNlIGNhbiBoYXZlIGltcGxlbWVudGF0aW9uIHRvIGNh
Y2hlIGluZm9ybWF0aW9uIG9uIHJlY2VpcHQgb2YgdGhlIGV2ZW50IHRvIHVzZSBpdCBsYXRlci4N
Cg0KVGhpcyBwYXRjaCBpcyB2YWd1ZS4gT25jZSB3ZSBzZXQgc29tZXRoaW5nIGFzIEFQSSB3ZSBo
YXZlIHRvIGxpdmUgd2l0aCBpdCwgSSBhbSBub3QgY29tZm9ydGFibGUgd2l0aCB0aGlzIHBhdGNo
IGhhdmluZyBlbm91Z2ggaW5mb3JtYXRpb24gZm9yIHByb3BlciB1c2FnZSBieSBkaWZmZXJlbnQg
ZHJpdmVycyBmb3IgdGhlIHNhbWUgcHVycG9zZSBvciBpbnRlbnQuIFRoZSBvbmx5IHJlYWwgcG9z
aXRpdmUgYXJndW1lbnQgdGhhdCBjb3VsZCBiZSB1c2VkIGhlcmUgaXMgd2hlcmUgc29tZXRoaW5n
IGxpa2UgQW5kcm9pZCBtaWdodCBoYXZlIGFscmVhZHkgZW1icmFjZWQgc29tZSBzaW1pbGFyIEFQ
SSBidXQgYXJlIHdlIGdvaW5nIHRvIGFsd2F5cyBqdXN0IGVuYWJsZSBBUEkgb24gTGludXgganVz
dCBiZWNhdXNlIEFuZHJvaWQgZGlkIGl0IHdpdGhvdXQgdGhpbmtpbmcgYWJvdXQgcHJvcGVyIGxv
bmcgdGVybSBhcmNoaXRlY3R1cmU/IEkgZG9uJ3QgdGhpbmsgc28uDQoNCiBMdWlzDQo=
^ 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