* Re: [PATCHv6 00/18] Add support for 5 and 10 MHz channels
From: Simon Wunderlich @ 2013-07-09 15:29 UTC (permalink / raw)
To: Johannes Berg
Cc: Simon Wunderlich, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1373382510.8241.2.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
On Tue, Jul 09, 2013 at 05:08:30PM +0200, Johannes Berg wrote:
> On Mon, 2013-07-08 at 16:55 +0200, Simon Wunderlich wrote:
> > This patchset adds support for 5 and 10 MHz in nl80211/cfg80211/mac80211
> > and enables support in ath5k and ath9k, which already support this feature
> > on the driver side. 5 and 10 MHz wide channels might be useful for:
> >
> > * long shot links, as the transmissions are more robust
> > * future support for 802.11y which allows some 5 and 10 MHz channels in
> > 3.6 GHz range
> > * future support for 802.11p which uses 10 MHz in 5.9 GHz range
> > * ... and more "special" applications.
> >
> > This patchset enables 5 and 10 MHz channels only for OFDM, and without
> > HT/MIMO/aggregation (for now). Support may be added later.
>
> I've applied patches 1-10, not going to take the ath patches.
Thanks! I'll ask John to merge them when pulls mac80211-next, you might want
to mention that in your pull request too.
Thanks again,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v13 2/2] cfg80211: P2P find phase offload
From: Johannes Berg @ 2013-07-09 15:22 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: linux-wireless, Luis R . Rodriguez, John W . Linville,
Jouni Malinen, Arend van Spriel, Ilan Peer
In-Reply-To: <9095491.AkZl2nGOCe@lx-vladimir>
A few nits, since you're going to have to resend anyway (this patch is
also line-wrapped)
> NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD
Is that actually needed at all? Now that we have the "replied" flag in
the first patch, it seems like this wouldn't be used at all?
> CMD(crit_proto_stop, CRIT_PROTOCOL_STOP);
> + CMD(start_p2p_find, START_P2P_FIND);
> + CMD(stop_p2p_find, STOP_P2P_FIND);
That'll probably have to be changed when mac80211 supports this, but we
don't have to worry about it right now.
> +}
> +static int nl80211_start_p2p_find(struct sk_buff *skb, struct genl_info
> *info)
There should be a blank line between the two functions
> + params.channels = kzalloc(n_channels * sizeof(*params.channels),
> + GFP_KERNEL);
kcalloc? Probably doesn't matter much though.
> + attr = info->attrs[NL80211_ATTR_MIN_DISCOVERABLE_INTERVAL];
> + if (attr)
> + params.min_discoverable_interval = nla_get_u32(attr);
> +
> + attr = info->attrs[NL80211_ATTR_MAX_DISCOVERABLE_INTERVAL];
> + if (attr)
> + params.max_discoverable_interval = nla_get_u32(attr);
No validation at all? What if I pass 7/3 for min/max (yes, in that
order)?
johannes
^ permalink raw reply
* Re: [PATCH v13 1/2] cfg80211: add 'flags' to cfg80211_rx_mgmt()
From: Johannes Berg @ 2013-07-09 15:15 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: linux-wireless, Luis R . Rodriguez, John W . Linville,
Jouni Malinen, Arend van Spriel, Ilan Peer
In-Reply-To: <2816930.mUJMdCmsNg@lx-vladimir>
On Wed, 2013-07-03 at 17:37 +0300, Vladimir Kondratiev wrote:
> Flags intended to report various auxiliary information.
> Introduced flag NL80211_RXMGMT_FLAG_REPLIED to report
> whether frame was replied by the device/driver.
This looks fine to me, but the patch is line-wrapped and won't apply:
> @@ -608,8 +608,7 @@ static int ath6kl_wmi_rx_action_event_rx(struct wmi *wmi,
> u8 *datap, int len,
You also sent me at least three versions of it and I don't really want
to figure out what that meant.
johannes
^ permalink raw reply
* Re: [PATCHv6 00/18] Add support for 5 and 10 MHz channels
From: Johannes Berg @ 2013-07-09 15:08 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1373295366-12823-1-git-send-email-siwu@hrz.tu-chemnitz.de>
On Mon, 2013-07-08 at 16:55 +0200, Simon Wunderlich wrote:
> This patchset adds support for 5 and 10 MHz in nl80211/cfg80211/mac80211
> and enables support in ath5k and ath9k, which already support this feature
> on the driver side. 5 and 10 MHz wide channels might be useful for:
>
> * long shot links, as the transmissions are more robust
> * future support for 802.11y which allows some 5 and 10 MHz channels in
> 3.6 GHz range
> * future support for 802.11p which uses 10 MHz in 5.9 GHz range
> * ... and more "special" applications.
>
> This patchset enables 5 and 10 MHz channels only for OFDM, and without
> HT/MIMO/aggregation (for now). Support may be added later.
I've applied patches 1-10, not going to take the ath patches.
johannes
^ permalink raw reply
* Re: ralink 3290: still lots of misc errors reported by Iwconfig with 3.10 + HD streaming on WiFi fails
From: Eric Valette @ 2013-07-09 15:00 UTC (permalink / raw)
To: Eric.Valette, Stanislaw Gruszka; +Cc: linux-wireless
In-Reply-To: <51DC1F9D.7000705@Free.fr>
On 07/09/2013 04:35 PM, Eric Valette wrote:
>> Do you mean that 3.10 perform better than 3.9.9 ? I do not see any
>> rt2x00 fixes between 3.9 and 3.10 that are not yet applied on 3.9.9.
>> I can see only some cleanups and new hardware support patches.
>
> From memory I think I had a lot of reported TX error with 3.9.9 and
> they are now gone with 3.10 but the number of misc error reported by
> iwconfig is still high with 3.10. But you are right the fix for TX is
> still in wireless git and does not seem to be in 3.10. As I checked
> several git trees I mist have been confused...
Unless I'm really tired, this patch is in 3.10 and not in 3.9.9 :
http://git.kernel.org/cgit/linux/kernel/git/linville/wireless-testing.git/patch/drivers/net/wireless/rt2x00?id=8857d6dc77e4e3afeee2f33c49597010130ed858
--eric
^ permalink raw reply
* Re: Replacement for local->hw.conf.channel
From: Johannes Berg @ 2013-07-09 14:35 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <51DB0937.2020609@candelatech.com>
> > No, don't use that in any new code. It's purely for compatibility with
> > drivers that aren't converted to channel contexts (yet).
> >
> >> In 3.9, ath9k_htc was giving me a null channel in the code below:
> >>
> >> chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> >> if (chanctx_conf)
> >> channel = chanctx_conf->def.chan;
> >> else
> >> channel = NULL;
> >
> > Well that of course happens if the vif isn't bound to a channel context.
>
> Any opinions on what to return in ethtool stats for frequency if
> there is no channel context?
Why even bother doing so? "iw dev" shows the frequency and channel width
just fine, no?
> If there is a quick way to just return whatever the hardware is
> currently using, I think that is best, but if there is not
> a reliable way to do this then, some hard coded default
> like 0 is probably best.
Well there's no such concept as "what the hardware is currently using"
in this case, the channel is completely pointless when there's no
channel context at all. There might be something like the current scan
channel, but what value would there be in returning that?
johannes
^ permalink raw reply
* Re: ralink 3290: still lots of misc errors reported by Iwconfig with 3.10 + HD streaming on WiFi fails
From: Eric Valette @ 2013-07-09 14:35 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless
In-Reply-To: <20130709142202.GB3681@redhat.com>
On 07/09/2013 04:22 PM, Stanislaw Gruszka wrote:
> On Tue, Jul 09, 2013 at 12:50:52PM +0200, Eric Valette wrote:
>> I just bought a HP netbook for my son equipped with this chipset. I
>> first tried linux 3.9.7, got WiFi working badly but working. Saw fix
>> for TX power in 3.9.9. WiFi became more reliable but still had a lot
>> of TX, and MISC errors reported by iwconfig. While laptop is now
>> usable for internet browsing, trying to play HD tv via XBMC +
>> tvheadend fails miserably due to WiFi data rate and WiFi errors
>> while other PC at home do play without problems.
>>
>> Saw the fix in 3.10 for TX errors and indeed the TX errors dropped
>> to 0. However, the MISC error count in turn rose (Downloading
>> linux-3.10.tar.xz on 3.10 reports 550 misc errors). So there is
>> still some problem with this chipset. I know support is experimental
>> but I would be glad to test any patchif possible on 3.9.x as on 3.10
>> I have no ATI driver available at the moment and thus HD decoding is
>> out of reach anyway.
>
> Do you mean that 3.10 perform better than 3.9.9 ? I do not see any
> rt2x00 fixes between 3.9 and 3.10 that are not yet applied on 3.9.9.
> I can see only some cleanups and new hardware support patches.
From memory I think I had a lot of reported TX error with 3.9.9 and
they are now gone with 3.10 but the number of misc error reported by
iwconfig is still high with 3.10. But you are right the fix for TX is
still in wireless git and does not seem to be in 3.10. As I checked
several git trees I mist have been confused...
> Try to subscribe to rt2x00 mailing list,
> http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
> we post new patches there, but currently we do not have any pending
> RT3290 fixes.
OK. Next radical solution is to open the laptop and change for another
half mini pcie card... Quite difficult to find one reliably even if
there are some available on ebay.
Thanks for taking the time to respond...
--eric
^ permalink raw reply
* Re: ralink 3290: still lots of misc errors reported by Iwconfig with 3.10 + HD streaming on WiFi fails
From: Stanislaw Gruszka @ 2013-07-09 14:22 UTC (permalink / raw)
To: Eric Valette; +Cc: linux-wireless
In-Reply-To: <51DBEB0C.6040704@Free.fr>
On Tue, Jul 09, 2013 at 12:50:52PM +0200, Eric Valette wrote:
> I just bought a HP netbook for my son equipped with this chipset. I
> first tried linux 3.9.7, got WiFi working badly but working. Saw fix
> for TX power in 3.9.9. WiFi became more reliable but still had a lot
> of TX, and MISC errors reported by iwconfig. While laptop is now
> usable for internet browsing, trying to play HD tv via XBMC +
> tvheadend fails miserably due to WiFi data rate and WiFi errors
> while other PC at home do play without problems.
>
> Saw the fix in 3.10 for TX errors and indeed the TX errors dropped
> to 0. However, the MISC error count in turn rose (Downloading
> linux-3.10.tar.xz on 3.10 reports 550 misc errors). So there is
> still some problem with this chipset. I know support is experimental
> but I would be glad to test any patchif possible on 3.9.x as on 3.10
> I have no ATI driver available at the moment and thus HD decoding is
> out of reach anyway.
Do you mean that 3.10 perform better than 3.9.9 ? I do not see any
rt2x00 fixes between 3.9 and 3.10 that are not yet applied on 3.9.9.
I can see only some cleanups and new hardware support patches.
Try to subscribe to rt2x00 mailing list,
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
we post new patches there, but currently we do not have any pending
RT3290 fixes.
Stanislaw
^ permalink raw reply
* Re: wl1271 NVS file loading
From: Ben Gamari @ 2013-07-09 14:16 UTC (permalink / raw)
To: ravichandra bangalore; +Cc: Luciano Coelho, linux-wireless
In-Reply-To: <1333356840.16990.29.camel@cumari>
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
ravichandra bangalore <ravichandra.bangalore@gmail.com> writes:
> Hi
>
Moving to linux-wireless@ and including Luciano Coelho who replied to my
original request. It's often best to reply to the original thread (or at
least include the original list) in these cases so others might benefit
From the resulting discussion.
> This is related to your posting on "wl1271 NVS file loading" in forum
> linux-wireless@vger.kernel.org
>
> We are facing same issue while loading wl12xx.ko
> wl12xx: ERROR could not get nvs file ti-connectivity/wl1271-nvs.bin: -2
> Can you please let us know how do you fix this issue.
>
> How to compile "wl1271 as a module"
>
I suspect the bug that brought about the need for wl1271 to be a module
is probably fixed by now (assuming your kernel is newer than
3.5). Luciano might be able to confirm this.
If this is the case, you may want to verify that
/lib/firmware/ti-connectivity/wl1271-nvs.bin exists. If it does not, you
simply need to install the firmware by whatever means your distribution
provides (e.g. Debian/Ubuntu's `linux-firmware` package).
Otherwise, you can try compiling as a module. You can do this by either
editing `.config` or using the `make menuconfig` command. There are
numerous guides describing this to be found online. The relevant
confirmation symbol is `CONFIG_WL12XX`, if I recall correctly.
Cheers,
- Ben
[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply
* Re: [PATCHv3 4/5] mac80211: add channel switch command and beacon callbacks
From: Michal Kazior @ 2013-07-09 14:11 UTC (permalink / raw)
To: Simon Wunderlich
Cc: Johannes Berg, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <20130709102751.GA21674@pandem0nium>
On 9 July 2013 12:27, Simon Wunderlich
<simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> On Tue, Jul 09, 2013 at 09:17:41AM +0200, Michal Kazior wrote:
>> I'm wondering if it's a huge hassle to support drivers that depend on
>> channel context API? Perhaps local->open_count could be used instead
>> of local->use_chantx and chanctx->refcount?
>
> Actually I'm not using any chanctx drivers, and as long as I can't test
> I prefer to keep things disabled. :)
Understandable :) I'm not able to test it now either.
Hmm.. Just as an idea: mac80211_hwsim uses chanctx so it could be
modified to support CSA to test this case.
> local->open_count seems doable though,
> it should be the same if there is only one channel context. I can change
> that ... If you think it is safe I can enable support, nothing will happen
> anyway as long as the driver don't set the "CSA supported" wiphy flag ...
I looked at the code and I think local->open_count won't cut it. It
will fail with AP_VLAN interfaces present (and this isn't a problem
with your current approach). Monitor interfaces are counted in
local->monitors, but AP_VLAN aren't counted at all. mac80211 doesn't
really keep track of the number of interfaces it has reported to a
driver nor the number of software interfaces (that aren't reported to
the driver) unless I missed something.
Another idea is to verify there's exactly 1 chanctx present and it's
refcount is also 1.
CSA + chanctx is just a nice to have. If you're short on resources
it's fine the way it is I think.
>> It seems there's nothing preventing from multiple calls to channel
>> switch callback. Is this expected? Can this work if CSA is invoked
>> while other CSA is still in progress?
>
> This should not happen as long as there is only one interface
> doing a channel switch. If this is properly checked (need to fix
> the point you mentioned above) that should be safe, I think?
Yes it's okay as long as userspace doesn't do something stupid (i.e.
call channel switch more than once quickly). Whether this is a concern
is not for me to decide though.
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: intel 4965 fails to set channel 12 or 13
From: Stanislaw Gruszka @ 2013-07-09 14:13 UTC (permalink / raw)
To: Hendrik-Jan Heins; +Cc: linux-wireless
In-Reply-To: <CAAU0D9dyrsHKw6cvbfNnhodQOC9_Bhxm0xiDqmKXTuN8Lby3DQ@mail.gmail.com>
On Tue, Jul 09, 2013 at 10:47:37AM +0200, Hendrik-Jan Heins wrote:
> Dear list,
>
> On Debian Wheezy, kernel 3.2, I am trying to get my iwl4965 to
> scan/find/connect on channels 13 and 13. As I am in Europe, this
> should be no issue.
> However: I can not get these channels activated on my card at all!
> I tried the following:
> - Using the regdom option, setting to EU, DE, or PL (I see the correct
> setting in /sys/modules/cfg80211/parameters/ieee_regdom...
> - Completely disabling CRDA, and manually loading regdom through iw
> reg set EU/DE/PL/US
>
> In all cases, I see some changes in the channels listed, but I never
> get 12 and 13 enabled.
>
> Does anyone has an idea on this?
Please provide output of "iw phy" and "iw dev wlan0 scan".
Stanislaw
^ permalink raw reply
* Re: New device for ar5523
From: Larry Finger @ 2013-07-09 13:36 UTC (permalink / raw)
To: Dmitry Zganyaiko; +Cc: Pontus Fuchs, linux-wireless
In-Reply-To: <CC807E45-D614-4540-AD3F-160B56795851@gmail.com>
On 07/09/2013 03:59 AM, Dmitry Zganyaiko wrote:
> Hi! I'm using usb wireless adaptor named
> 07d1:3a0d D-Link System DWA-120 802.11g Wireless 108G (taken from lsusb)
>
> System is Debian wheezy with 3.8 kernel taken from ubuntu reps. But after launch this adaptor doesn't work: no any new network interfaces is shown in ifconfig.
>
> As far as I understood, such vendor:product (07d1:3a0d) isn't specified in drivers/net/wireless/ath/ar5523/ar5523.c, and therefore the driver doesn't recognise my device. Firmware 'ar5523.bin' is located in /usr/local/lib/firmware.
>
> What can I do to make this adaptor work? Only add that v:p pair to ar5523.c and recompile it? Just if that can be done without compiling - it will be great.
You can test to see if it works with that kernel with the following commands (as
root):
modprobe -v ar5523
echo 07d1 3a0d > /sys/bus/usb/drivers/ar5523/new_id
If the device would work by adding that USB ID to the device table, then the
above commands should accomplish the same result. Note - these commands will
need to be re-entered after every reload of ar5523.
Larry
^ permalink raw reply
* Re:
From: Arend van Spriel @ 2013-07-09 13:22 UTC (permalink / raw)
To: Jeffrey (Sheng-Hui) Chu; +Cc: linux-wireless@vger.kernel.org, Samuel Ortiz
In-Reply-To: <90AC93A0CCA054488FFC508D6F62B6F40FED489B@IRVEXCHMB07.corp.ad.broadcom.com>
+ Samuel
On 07/08/2013 11:52 PM, Jeffrey (Sheng-Hui) Chu wrote:
> From b4555081b1d27a31c22abede8e0397f1d61fbb04 Mon Sep 17 00:00:00 2001
> From: Jeffrey Chu <jeffchu@broadcom.com>
> Date: Mon, 8 Jul 2013 17:50:21 -0400
> Subject: [PATCH] Add bcm2079x-i2c driver for Bcm2079x NFC Controller.
The subject did not show in my mailbox. Not sure if necessary, but I
tend to send patches to a maintainer and CC the appropriate list(s). So
the nfc list as well (linux-nfc@lists.01.org).
Regards,
Arend
> Signed-off-by: Jeffrey Chu <jeffchu@broadcom.com>
> ---
> drivers/nfc/Kconfig | 1 +
> drivers/nfc/Makefile | 1 +
> drivers/nfc/bcm2079x/Kconfig | 10 +
> drivers/nfc/bcm2079x/Makefile | 4 +
> drivers/nfc/bcm2079x/bcm2079x-i2c.c | 416 +++++++++++++++++++++++++++++++++++
> drivers/nfc/bcm2079x/bcm2079x.h | 34 +++
> 6 files changed, 466 insertions(+)
> create mode 100644 drivers/nfc/bcm2079x/Kconfig
> create mode 100644 drivers/nfc/bcm2079x/Makefile
> create mode 100644 drivers/nfc/bcm2079x/bcm2079x-i2c.c
> create mode 100644 drivers/nfc/bcm2079x/bcm2079x.h
>
> diff --git a/drivers/nfc/Kconfig b/drivers/nfc/Kconfig
> index 74a852e..fa540f4 100644
> --- a/drivers/nfc/Kconfig
> +++ b/drivers/nfc/Kconfig
> @@ -38,5 +38,6 @@ config NFC_MEI_PHY
>
> source "drivers/nfc/pn544/Kconfig"
> source "drivers/nfc/microread/Kconfig"
> +source "drivers/nfc/bcm2079x/Kconfig"
>
> endmenu
> diff --git a/drivers/nfc/Makefile b/drivers/nfc/Makefile
> index aa6bd65..a56adf6 100644
> --- a/drivers/nfc/Makefile
> +++ b/drivers/nfc/Makefile
> @@ -7,5 +7,6 @@ obj-$(CONFIG_NFC_MICROREAD) += microread/
> obj-$(CONFIG_NFC_PN533) += pn533.o
> obj-$(CONFIG_NFC_WILINK) += nfcwilink.o
> obj-$(CONFIG_NFC_MEI_PHY) += mei_phy.o
> +obj-$(CONFIG_NFC_PN544) += bcm2079x/
I suspect this is a copy-paste error right? Should be
obj-$(CONFIG_NFC_BCM2079X_I2C).
>
> ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG
> diff --git a/drivers/nfc/bcm2079x/Kconfig b/drivers/nfc/bcm2079x/Kconfig
> new file mode 100644
> index 0000000..889e181
> --- /dev/null
> +++ b/drivers/nfc/bcm2079x/Kconfig
> @@ -0,0 +1,10 @@
> +config NFC_BCM2079X_I2C
> + tristate "NFC BCM2079x i2c support"
> + depends on I2C
> + default n
> + ---help---
> + Broadcom BCM2079x i2c driver.
> + This is a driver that allows transporting NCI/HCI command and response
> + to/from Broadcom bcm2079x NFC Controller. Select this if your
> + platform is using i2c bus to controll this chip.
> +
> diff --git a/drivers/nfc/bcm2079x/Makefile b/drivers/nfc/bcm2079x/Makefile
> new file mode 100644
> index 0000000..be64d35
> --- /dev/null
> +++ b/drivers/nfc/bcm2079x/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# Makefile for bcm2079x NFC driver
> +#
> +obj-$(CONFIG_NFC_BCM2079X_I2C) += bcm2079x-i2c.o
> diff --git a/drivers/nfc/bcm2079x/bcm2079x-i2c.c b/drivers/nfc/bcm2079x/bcm2079x-i2c.c
> new file mode 100644
> index 0000000..988a65e
> --- /dev/null
> +++ b/drivers/nfc/bcm2079x/bcm2079x-i2c.c
> @@ -0,0 +1,416 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/fs.h>
> +#include <linux/slab.h>
> +#include <linux/i2c.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/gpio.h>
> +#include <linux/miscdevice.h>
> +#include <linux/spinlock.h>
> +#include <linux/poll.h>
> +
> +#include "bcm2079x.h"
> +
> +/* do not change below */
> +#define MAX_BUFFER_SIZE 780
> +
> +/* Read data */
> +#define PACKET_HEADER_SIZE_NCI (4)
> +#define PACKET_HEADER_SIZE_HCI (3)
> +#define PACKET_TYPE_NCI (16)
> +#define PACKET_TYPE_HCIEV (4)
> +#define MAX_PACKET_SIZE (PACKET_HEADER_SIZE_NCI + 255)
> +
> +struct bcm2079x_dev {
> + wait_queue_head_t read_wq;
> + struct mutex read_mutex;
> + struct i2c_client *client;
> + struct miscdevice bcm2079x_device;
> + unsigned int wake_gpio;
> + unsigned int en_gpio;
> + unsigned int irq_gpio;
> + bool irq_enabled;
> + spinlock_t irq_enabled_lock;
> + unsigned int count_irq;
> +};
> +
> +static void bcm2079x_init_stat(struct bcm2079x_dev *bcm2079x_dev)
> +{
> + bcm2079x_dev->count_irq = 0;
> +}
> +
> +static void bcm2079x_disable_irq(struct bcm2079x_dev *bcm2079x_dev)
> +{
> + unsigned long flags;
> + spin_lock_irqsave(&bcm2079x_dev->irq_enabled_lock, flags);
> + if (bcm2079x_dev->irq_enabled) {
> + disable_irq_nosync(bcm2079x_dev->client->irq);
> + bcm2079x_dev->irq_enabled = false;
> + }
> + spin_unlock_irqrestore(&bcm2079x_dev->irq_enabled_lock, flags);
> +}
> +
> +static void bcm2079x_enable_irq(struct bcm2079x_dev *bcm2079x_dev)
> +{
> + unsigned long flags;
> + spin_lock_irqsave(&bcm2079x_dev->irq_enabled_lock, flags);
> + if (!bcm2079x_dev->irq_enabled) {
> + bcm2079x_dev->irq_enabled = true;
> + enable_irq(bcm2079x_dev->client->irq);
> + }
> + spin_unlock_irqrestore(&bcm2079x_dev->irq_enabled_lock, flags);
> +}
> +
> +static void set_client_addr(struct bcm2079x_dev *bcm2079x_dev, int addr)
> +{
> + struct i2c_client *client = bcm2079x_dev->client;
> + dev_info(&client->dev,
> + "Set client device address from 0x%04X flag = "
> + "%02x, to 0x%04X\n",
> + client->addr, client->flags, addr);
> + client->addr = addr;
> + if (addr < 0x80)
> + client->flags &= ~I2C_CLIENT_TEN;
> + else
> + client->flags |= I2C_CLIENT_TEN;
> +}
> +
> +static irqreturn_t bcm2079x_dev_irq_handler(int irq, void *dev_id)
> +{
> + struct bcm2079x_dev *bcm2079x_dev = dev_id;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&bcm2079x_dev->irq_enabled_lock, flags);
> + bcm2079x_dev->count_irq++;
> + spin_unlock_irqrestore(&bcm2079x_dev->irq_enabled_lock, flags);
> + wake_up(&bcm2079x_dev->read_wq);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static unsigned int bcm2079x_dev_poll(struct file *filp, poll_table *wait)
> +{
> + struct bcm2079x_dev *bcm2079x_dev = filp->private_data;
> + unsigned int mask = 0;
> + unsigned long flags;
> +
> + poll_wait(filp, &bcm2079x_dev->read_wq, wait);
> +
> + spin_lock_irqsave(&bcm2079x_dev->irq_enabled_lock, flags);
> + if (bcm2079x_dev->count_irq > 0) {
> + bcm2079x_dev->count_irq--;
> + mask |= POLLIN | POLLRDNORM;
> + }
> + spin_unlock_irqrestore(&bcm2079x_dev->irq_enabled_lock, flags);
> +
> + return mask;
> +}
> +
> +static ssize_t bcm2079x_dev_read(struct file *filp, char __user *buf,
> + size_t count, loff_t *offset)
> +{
> + struct bcm2079x_dev *bcm2079x_dev = filp->private_data;
> + unsigned char tmp[MAX_BUFFER_SIZE];
> + int total, len, ret;
> +
> + total = 0;
> + len = 0;
> +
> + if (count > MAX_BUFFER_SIZE)
> + count = MAX_BUFFER_SIZE;
> +
> + mutex_lock(&bcm2079x_dev->read_mutex);
> +
> + /* Read the first 4 bytes to include the length of the NCI or
> + HCI packet.*/
> + ret = i2c_master_recv(bcm2079x_dev->client, tmp, 4);
> + if (ret == 4) {
> + total = ret;
> + /* First byte is the packet type*/
> + switch (tmp[0]) {
> + case PACKET_TYPE_NCI:
> + len = tmp[PACKET_HEADER_SIZE_NCI-1];
> + break;
> +
> + case PACKET_TYPE_HCIEV:
> + len = tmp[PACKET_HEADER_SIZE_HCI-1];
> + if (len == 0)
> + total--;
> + else
> + len--;
> + break;
> +
> + default:
> + len = 0;/*Unknown packet byte */
> + break;
> + } /* switch*/
> +
> + /* make sure full packet fits in the buffer*/
> + if (len > 0 && (len + total) <= count) {
> + /** read the remainder of the packet.
> + **/
> + ret = i2c_master_recv(bcm2079x_dev->client, tmp+total,
> + len);
> + if (ret == len)
> + total += len;
> + } /* if */
> + } /* if */
> +
> + mutex_unlock(&bcm2079x_dev->read_mutex);
> +
> + if (total > count || copy_to_user(buf, tmp, total)) {
> + dev_err(&bcm2079x_dev->client->dev,
> + "failed to copy to user space, total = %d\n", total);
> + total = -EFAULT;
> + }
> +
> + return total;
> +}
> +
> +static ssize_t bcm2079x_dev_write(struct file *filp, const char __user *buf,
> + size_t count, loff_t *offset)
> +{
> + struct bcm2079x_dev *bcm2079x_dev = filp->private_data;
> + char tmp[MAX_BUFFER_SIZE];
> + int ret;
> +
> + if (count > MAX_BUFFER_SIZE) {
> + dev_err(&bcm2079x_dev->client->dev, "out of memory\n");
> + return -ENOMEM;
> + }
> +
> + if (copy_from_user(tmp, buf, count)) {
> + dev_err(&bcm2079x_dev->client->dev,
> + "failed to copy from user space\n");
> + return -EFAULT;
> + }
> +
> + mutex_lock(&bcm2079x_dev->read_mutex);
> + /* Write data */
> +
> + ret = i2c_master_send(bcm2079x_dev->client, tmp, count);
> + if (ret != count) {
> + dev_err(&bcm2079x_dev->client->dev,
> + "failed to write %d\n", ret);
> + ret = -EIO;
> + }
> + mutex_unlock(&bcm2079x_dev->read_mutex);
> +
> + return ret;
> +}
> +
> +static int bcm2079x_dev_open(struct inode *inode, struct file *filp)
> +{
> + int ret = 0;
> +
> + struct bcm2079x_dev *bcm2079x_dev = container_of(filp->private_data,
> + struct bcm2079x_dev,
> + bcm2079x_device);
> + filp->private_data = bcm2079x_dev;
> + bcm2079x_init_stat(bcm2079x_dev);
> + bcm2079x_enable_irq(bcm2079x_dev);
> + dev_info(&bcm2079x_dev->client->dev,
> + "%d,%d\n", imajor(inode), iminor(inode));
> +
> + return ret;
> +}
> +
> +static long bcm2079x_dev_unlocked_ioctl(struct file *filp,
> + unsigned int cmd, unsigned long arg)
> +{
> + struct bcm2079x_dev *bcm2079x_dev = filp->private_data;
> +
> + switch (cmd) {
> + case BCMNFC_POWER_CTL:
> + gpio_set_value(bcm2079x_dev->en_gpio, arg);
> + break;
> + case BCMNFC_WAKE_CTL:
> + gpio_set_value(bcm2079x_dev->wake_gpio, arg);
> + break;
> + case BCMNFC_SET_ADDR:
> + set_client_addr(bcm2079x_dev, arg);
> + break;
> + default:
> + dev_err(&bcm2079x_dev->client->dev,
> + "%s, unknown cmd (%x, %lx)\n", __func__, cmd, arg);
> + return -ENOSYS;
> + }
> +
> + return 0;
> +}
> +
> +static const struct file_operations bcm2079x_dev_fops = {
> + .owner = THIS_MODULE,
> + .llseek = no_llseek,
> + .poll = bcm2079x_dev_poll,
> + .read = bcm2079x_dev_read,
> + .write = bcm2079x_dev_write,
> + .open = bcm2079x_dev_open,
> + .unlocked_ioctl = bcm2079x_dev_unlocked_ioctl
> +};
> +
> +static int bcm2079x_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + int ret;
> + struct bcm2079x_platform_data *platform_data;
> + struct bcm2079x_dev *bcm2079x_dev;
> +
> + platform_data = client->dev.platform_data;
> +
> + dev_info(&client->dev, "%s, probing bcm2079x driver flags = %x\n",
> + __func__, client->flags);
> + if (platform_data == NULL) {
> + dev_err(&client->dev, "nfc probe fail\n");
> + return -ENODEV;
> + }
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> + dev_err(&client->dev, "need I2C_FUNC_I2C\n");
> + return -ENODEV;
> + }
> +
> + ret = gpio_request_one(platform_data->irq_gpio, GPIOF_IN, "nfc_irq");
> + if (ret)
> + return -ENODEV;
> + ret = gpio_request_one(platform_data->en_gpio, GPIOF_OUT_INIT_LOW,
> + "nfc_en");
> + if (ret)
> + goto err_en;
> + ret = gpio_request_one(platform_data->wake_gpio, GPIOF_OUT_INIT_LOW,
> + "nfc_wake");
> + if (ret)
> + goto err_wake;
> +
> + gpio_set_value(platform_data->en_gpio, 0);
> + gpio_set_value(platform_data->wake_gpio, 0);
> +
> + bcm2079x_dev = kzalloc(sizeof(*bcm2079x_dev), GFP_KERNEL);
> + if (bcm2079x_dev == NULL) {
> + dev_err(&client->dev,
> + "failed to allocate memory for module data\n");
> + ret = -ENOMEM;
> + goto err_exit;
> + }
> +
> + bcm2079x_dev->wake_gpio = platform_data->wake_gpio;
> + bcm2079x_dev->irq_gpio = platform_data->irq_gpio;
> + bcm2079x_dev->en_gpio = platform_data->en_gpio;
> + bcm2079x_dev->client = client;
> +
> + /* init mutex and queues */
> + init_waitqueue_head(&bcm2079x_dev->read_wq);
> + mutex_init(&bcm2079x_dev->read_mutex);
> + spin_lock_init(&bcm2079x_dev->irq_enabled_lock);
> +
> + bcm2079x_dev->bcm2079x_device.minor = MISC_DYNAMIC_MINOR;
> + bcm2079x_dev->bcm2079x_device.name = "bcm2079x-i2c";
> + bcm2079x_dev->bcm2079x_device.fops = &bcm2079x_dev_fops;
> +
> + ret = misc_register(&bcm2079x_dev->bcm2079x_device);
> + if (ret) {
> + dev_err(&client->dev, "misc_register failed\n");
> + goto err_misc_register;
> + }
> +
> + /* request irq. the irq is set whenever the chip has data available
> + * for reading. it is cleared when all data has been read.
> + */
> + dev_info(&client->dev, "requesting IRQ %d\n", client->irq);
> + bcm2079x_dev->irq_enabled = true;
> + ret = request_irq(client->irq, bcm2079x_dev_irq_handler,
> + IRQF_TRIGGER_RISING, client->name, bcm2079x_dev);
> + if (ret) {
> + dev_err(&client->dev, "request_irq failed\n");
> + goto err_request_irq_failed;
> + }
> + bcm2079x_disable_irq(bcm2079x_dev);
> + i2c_set_clientdata(client, bcm2079x_dev);
> + dev_info(&client->dev,
> + "%s, probing bcm2079x driver exited successfully\n",
> + __func__);
> + return 0;
> +
> +err_request_irq_failed:
> + misc_deregister(&bcm2079x_dev->bcm2079x_device);
> +err_misc_register:
> + mutex_destroy(&bcm2079x_dev->read_mutex);
> + kfree(bcm2079x_dev);
> +err_exit:
> + gpio_free(platform_data->wake_gpio);
> +err_wake:
> + gpio_free(platform_data->en_gpio);
> +err_en:
> + gpio_free(platform_data->irq_gpio);
> + return ret;
> +}
> +
> +static int bcm2079x_remove(struct i2c_client *client)
> +{
> + struct bcm2079x_dev *bcm2079x_dev;
> +
> + bcm2079x_dev = i2c_get_clientdata(client);
> + free_irq(client->irq, bcm2079x_dev);
> + misc_deregister(&bcm2079x_dev->bcm2079x_device);
> + mutex_destroy(&bcm2079x_dev->read_mutex);
> + gpio_free(bcm2079x_dev->irq_gpio);
> + gpio_free(bcm2079x_dev->en_gpio);
> + gpio_free(bcm2079x_dev->wake_gpio);
> + kfree(bcm2079x_dev);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id bcm2079x_id[] = {
> + {"bcm2079x-i2c", 0},
> + {}
> +};
> +
> +static struct i2c_driver bcm2079x_driver = {
> + .id_table = bcm2079x_id,
> + .probe = bcm2079x_probe,
> + .remove = bcm2079x_remove,
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = "bcm2079x-i2c",
> + },
> +};
> +
> +/*
> + * module load/unload record keeping
> + */
> +
> +static int __init bcm2079x_dev_init(void)
> +{
> + return i2c_add_driver(&bcm2079x_driver);
> +}
> +module_init(bcm2079x_dev_init);
> +
> +static void __exit bcm2079x_dev_exit(void)
> +{
> + i2c_del_driver(&bcm2079x_driver);
> +}
> +module_exit(bcm2079x_dev_exit);
> +
> +MODULE_AUTHOR("Broadcom");
> +MODULE_DESCRIPTION("NFC bcm2079x driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/nfc/bcm2079x/bcm2079x.h b/drivers/nfc/bcm2079x/bcm2079x.h
> new file mode 100644
> index 0000000..b8b243f
> --- /dev/null
> +++ b/drivers/nfc/bcm2079x/bcm2079x.h
> @@ -0,0 +1,34 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#ifndef _BCM2079X_H
> +#define _BCM2079X_H
> +
> +#define BCMNFC_MAGIC 0xFA
> +
> +#define BCMNFC_POWER_CTL _IO(BCMNFC_MAGIC, 0x01)
> +#define BCMNFC_WAKE_CTL _IO(BCMNFC_MAGIC, 0x05)
> +#define BCMNFC_SET_ADDR _IO(BCMNFC_MAGIC, 0x07)
> +
> +struct bcm2079x_platform_data {
> + unsigned int irq_gpio;
> + unsigned int en_gpio;
> + unsigned int wake_gpio;
> +};
> +
> +#endif
>
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-09 13:22 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: Luciano Coelho, linux-wireless
In-Reply-To: <CA+XVXfeB3jpXaaV4vgbHUVRdPeH9tPVRWvRhZsYHmg33HNzmmw@mail.gmail.com>
On 09-07-2013 13:42, Arik Nemtsov wrote:
> On Tue, Jul 9, 2013 at 2:27 PM, José Miguel Gonçalves
> <jose.goncalves@inov.pt> wrote:
>
>> Any more ideas on how to debug this? Is there any specific debug_level mask
>> that can apply to the driver to help it?
> You can try the mask 0x63c20 (it's pretty verbose, so I would put it
> in pastebin).
>
> Perhaps this is a genuine problem with the antenna of the card?
Nope. The AP is 1 meter away form my board (even without antenna in the
card it should associate).
> Can
> you verify the RSSI of the AP is ok using iw?
The iw output:
http://pastebin.com/XmEzqjHs
The dmesg output with debug mask set to 0x63c20:
http://pastebin.com/zGE0Gfp8
Note that with debug activated I did not see the driver's "Beacon loss
detected" messages.
José Gonçalves
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Arik Nemtsov @ 2013-07-09 12:42 UTC (permalink / raw)
To: José Miguel Gonçalves; +Cc: Luciano Coelho, linux-wireless
In-Reply-To: <51DBF389.5060209@inov.pt>
On Tue, Jul 9, 2013 at 2:27 PM, José Miguel Gonçalves
<jose.goncalves@inov.pt> wrote:
> Any more ideas on how to debug this? Is there any specific debug_level mask
> that can apply to the driver to help it?
You can try the mask 0x63c20 (it's pretty verbose, so I would put it
in pastebin).
Perhaps this is a genuine problem with the antenna of the card? Can
you verify the RSSI of the AP is ok using iw?
Arik
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-09 11:27 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <1373362817.21065.191.camel@cumari.coelho.fi>
Hi,
I've upgraded the firmware and also backported all patches in Luca's
tree which do not break API compatibility in kernel 3.9 and still have
no success. Here goes the log:
[root ~]$ wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
Successfully initialized wpa_supplicant
[ 38.295000] wlcore: firmware booted (Rev 6.3.10.0.136)
[ 38.655000] cfg80211: Calling CRDA for country: PT
[ 38.655000] cfg80211: Regulatory domain changed to country: PT
[ 38.665000] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 38.665000] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 38.675000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 38.675000] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 38.685000] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz),
(N/A, 2700 mBm)
[ 38.685000] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz),
(N/A, 4000 mBm)
wlan0: SME: Trying to authenticate with 88:43:e1:57:79:c0 (SSID='[
38.945000] wlan0: authenticate with 88:43:e1:57:79:c0
A. Guidance' freq=2452 MHz)
[ 38.985000] wlan0: send auth to 88:43:e1:57:79:c0 (try 1/3)
[ 38.990000] wlan0: authenticated
wlan0: Trying to associate with 88:43:e1:57:79:c0 (SSID='A. Guidance'
freq=2452 MHz)
[ 39.065000] wlan0: associate with 88:43:e1:57:79:c0 (try 1/3)
[ 39.070000] wlan0: RX AssocResp from 88:43:e1:57:79:c0 (capab=0x431
status=0 aid=1)
[ 39.095000] wlan0: associated
[ 39.095000] cfg80211: Calling CRDA for country: PT
[ 39.105000] cfg80211: Regulatory domain changed to country: PT
[ 39.105000] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 39.110000] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 39.125000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 39.125000] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 39.140000] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz),
(N/A, 2700 mBm)
[ 39.140000] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz),
(N/A, 4000 mBm)
wlan0: Associated with 88:43:e1:57:79:c0
[ 40.925000] wlcore: Beacon loss detected. roles:0xff
[ 42.610000] wlcore: Beacon loss detected. roles:0xff
[ 44.275000] wlcore: Beacon loss detected. roles:0xff
[ 45.740000] wlcore: Connection loss work (role_id: 0).
[ 45.740000] wlan0: Connection to AP 88:43:e1:57:79:c0 lost
And I still have the issue of not being able to scan all APs in the
vicinity. I can only (briefly) associate with my AP because I restrict
the scanning frequencies in wpa_supplicant.conf file;
country=PT
ap_scan=1
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="A. Guidance"
scan_freq=2452
key_mgmt=WPA-PSK
proto=WPA2
pairwise=CCMP TKIP
group=TKIP
psk="<some_password_in_ascii>"
}
Any more ideas on how to debug this? Is there any specific debug_level
mask that can apply to the driver to help it?
José Gonçalves
^ permalink raw reply
* ralink 3290: still lots of misc errors reported by Iwconfig with 3.10 + HD streaming on WiFi fails
From: Eric Valette @ 2013-07-09 10:50 UTC (permalink / raw)
To: linux-wireless
I just bought a HP netbook for my son equipped with this chipset. I
first tried linux 3.9.7, got WiFi working badly but working. Saw fix for
TX power in 3.9.9. WiFi became more reliable but still had a lot of TX,
and MISC errors reported by iwconfig. While laptop is now usable for
internet browsing, trying to play HD tv via XBMC + tvheadend fails
miserably due to WiFi data rate and WiFi errors while other PC at home
do play without problems.
Saw the fix in 3.10 for TX errors and indeed the TX errors dropped to 0.
However, the MISC error count in turn rose (Downloading
linux-3.10.tar.xz on 3.10 reports 550 misc errors). So there is still
some problem with this chipset. I know support is experimental but I
would be glad to test any patchif possible on 3.9.x as on 3.10 I have no
ATI driver available at the moment and thus HD decoding is out of reach
anyway.
Using ralink proprietary driver on linux recent kernel and amd64 is a no
go(does not compile due to API change + lots of INT32/pointers
conversion)but may be the driver code could shed some light for people
with adequate knowledge...
Please CC me I'm not subscribed
-- eric
^ permalink raw reply
* Re: [PATCHv3 4/5] mac80211: add channel switch command and beacon callbacks
From: Simon Wunderlich @ 2013-07-09 10:27 UTC (permalink / raw)
To: Michal Kazior
Cc: Simon Wunderlich, Johannes Berg, linux-wireless,
Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <CA+BoTQnsDGtAp4n9hYQTjhNZFzsEsaT4qnX_W7hBcutTAZvjYw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3279 bytes --]
Hi Michal,
thank you for your feedback!
On Tue, Jul 09, 2013 at 09:17:41AM +0200, Michal Kazior wrote:
> Hi Simon,
>
> On 8 July 2013 15:14, Simon Wunderlich
> <simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> > +static int ieee80211_channel_switch(struct wiphy *wiphy, struct net_device *dev,
> > + struct cfg80211_csa_settings *params)
> > +{
> > + struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> > + struct ieee80211_local *local = sdata->local;
> > + struct ieee80211_chanctx_conf *chanctx_conf;
> > + struct ieee80211_chanctx *chanctx;
> > + int err;
> > +
> > + if (!list_empty(&local->roc_list) || local->scanning)
> > + return -EBUSY;
> > +
> > + if (sdata->wdev.cac_started)
> > + return -EBUSY;
> > +
> > + /* don't handle if chanctx is used */
> > + if (local->use_chanctx)
> > + return -EBUSY;
> > +
> > + rcu_read_lock();
> > + chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> > + if (!chanctx_conf) {
> > + rcu_read_unlock();
> > + return -EBUSY;
> > + }
> > +
> > + /* don't handle for multi-VIF cases */
> > + chanctx = container_of(chanctx_conf, struct ieee80211_chanctx, conf);
> > + if (chanctx->refcount > 1) {
> > + rcu_read_unlock();
> > + return -EBUSY;
> > + }
> > + rcu_read_unlock();
>
> I'm wondering if it's a huge hassle to support drivers that depend on
> channel context API? Perhaps local->open_count could be used instead
> of local->use_chantx and chanctx->refcount?
Actually I'm not using any chanctx drivers, and as long as I can't test
I prefer to keep things disabled. :) local->open_count seems doable though,
it should be the same if there is only one channel context. I can change
that ... If you think it is safe I can enable support, nothing will happen
anyway as long as the driver don't set the "CSA supported" wiphy flag ...
>
> I'm also worried this can possibly do silly things if someone starts
> an interface while CSA is under way. Consider the following:
>
> * start AP
> * initiate channel switch
> [ while channel switch is in progress and driver is yet to call
> ieee80211_csa_finish() ]
> * start another STA interface and associate
> [ CSA completes ]
>
> Upon CSA completion the STA will be moved to a different channel
> silently and most likely end up with a beacon loss quickly. I think
> mac80211 should forbid bringing up any new interfaces during CSA.
I'm afraid you are right about that - there should be some check to
prevent other devices coming up during CSA. I'll add something to
prevent that.
>
> It seems there's nothing preventing from multiple calls to channel
> switch callback. Is this expected? Can this work if CSA is invoked
> while other CSA is still in progress?
This should not happen as long as there is only one interface
doing a channel switch. If this is properly checked (need to fix
the point you mentioned above) that should be safe, I think?
Cheers,
Simon
>
>
> Pozdrawiam / Best regards,
> Michał Kazior.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Luciano Coelho @ 2013-07-09 9:40 UTC (permalink / raw)
To: José Miguel Gonçalves; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <51DBD904.6020007@inov.pt>
On Tue, 2013-07-09 at 10:33 +0100, José Miguel Gonçalves wrote:
> On 09-07-2013 10:09, Luciano Coelho wrote:
> >>> wlcore: Beacon loss detected. roles:0xff
> >> This one is possibly a FW version issue. I'd give it a go with the
> >> latest FW in TI's git:
> >> https://github.com/TI-OpenLink/ti-utils/tree/master/hw/firmware
> > More specifically, try the hw/firmware/wl127x-fw-4-sr.bin and the
> > hw/firmware/wl127x-fw-4-mr.bin (if you're using multirole). Note that
> > you need to rename them to wl127x-fw-5-sr.bin and wl127x-fw-5-mr.bin,
> > respectively.
> >
> > What we have in the linux-firmware git at the moment are versions
> > 6.3.10.0.133 (singlerole) and 6.5.7.0.42 (multirole). The new ones in
> > TI's github repo are 6.3.10.0.136 and 6.5.7.0.46.
> >
> > If the new firmwares solve your problem, please let me know and I'll
> > push them to the linux-firmware git repo.
>
> Just to clarify. I was using the latest firmware files from
> linux-firmware and the driver picks the file wl127x-fw-5-sr.bin which is
> Rev 6.3.10.0.133. So are you saying that I should install the
> wl127x-fw-4-sr.bin from TI's github repo named as wl127x-fw-5-sr.bin and
> give it a try?
Exactly. The name used with TI's forked kernel hasn't update the
version number to 5, so you need to rename it manually. When the
firmware boots, you should see Rev. 6.3.10.0.136 printed out.
You may also want to update the mr version, if you'll use P2P, or other
multirole scenarios.
--
Cheers,
Luca.
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-09 9:33 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <1373360959.21065.183.camel@cumari.coelho.fi>
Hi,
First of all, thanks Arik and Luca for your help.
On 09-07-2013 10:09, Luciano Coelho wrote:
>>> wlcore: Beacon loss detected. roles:0xff
>> This one is possibly a FW version issue. I'd give it a go with the
>> latest FW in TI's git:
>> https://github.com/TI-OpenLink/ti-utils/tree/master/hw/firmware
> More specifically, try the hw/firmware/wl127x-fw-4-sr.bin and the
> hw/firmware/wl127x-fw-4-mr.bin (if you're using multirole). Note that
> you need to rename them to wl127x-fw-5-sr.bin and wl127x-fw-5-mr.bin,
> respectively.
>
> What we have in the linux-firmware git at the moment are versions
> 6.3.10.0.133 (singlerole) and 6.5.7.0.42 (multirole). The new ones in
> TI's github repo are 6.3.10.0.136 and 6.5.7.0.46.
>
> If the new firmwares solve your problem, please let me know and I'll
> push them to the linux-firmware git repo.
Just to clarify. I was using the latest firmware files from
linux-firmware and the driver picks the file wl127x-fw-5-sr.bin which is
Rev 6.3.10.0.133. So are you saying that I should install the
wl127x-fw-4-sr.bin from TI's github repo named as wl127x-fw-5-sr.bin and
give it a try?
>
>>> To use the driver in the Luca's tree I need to do some work to adapt my
>>> platform to the latest kernel version, what I would like to avoid for now.
>>> Is there any set of patches to put the driver in vanilla kernel 3.9 in a
>>> more stable condition?
>> Well 3.9 is pretty new, so the difference is not that big. A simple
>> cherry pick of all patches done on <root>/drivers/wireless/ti/ would
>> do the trick.
>>
>> Or you could always used compat-wireless, or in it's new name "driver
>> backports":
>> https://backports.wiki.kernel.org/index.php/Main_Page
> I'd really recommend cherry-picking just what is needed. It should be
> very few patches.
I was doing that in this precise moment...
> And every time you find a new patch that fixes some
> real issue you're seeing, let me know and I'll send to stable.
OK.
José Gonçalves
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Luciano Coelho @ 2013-07-09 9:09 UTC (permalink / raw)
To: Arik Nemtsov, José Miguel Gonçalves; +Cc: linux-wireless
In-Reply-To: <CA+XVXffKKVMeD5GXkzDsnvR7=Ocb8QP0Y7eeD-ZZTzsxJL7PqA@mail.gmail.com>
Thanks Arik, for helping with this.
On Tue, 2013-07-09 at 10:21 +0300, Arik Nemtsov wrote:
> On Tue, Jul 9, 2013 at 1:47 AM, José Miguel Gonçalves
> <jose.goncalves@inov.pt> wrote:
> > Hi Arik,
> >
> > Yep, that patch solved the kernel warning, but the association with the AP
> > is still lost after 3 warnings;
Cool, I have just sent this patch to the stable mailing list, for
inclusion on v.3.9.y.
> > wlcore: Beacon loss detected. roles:0xff
>
> This one is possibly a FW version issue. I'd give it a go with the
> latest FW in TI's git:
> https://github.com/TI-OpenLink/ti-utils/tree/master/hw/firmware
More specifically, try the hw/firmware/wl127x-fw-4-sr.bin and the
hw/firmware/wl127x-fw-4-mr.bin (if you're using multirole). Note that
you need to rename them to wl127x-fw-5-sr.bin and wl127x-fw-5-mr.bin,
respectively.
What we have in the linux-firmware git at the moment are versions
6.3.10.0.133 (singlerole) and 6.5.7.0.42 (multirole). The new ones in
TI's github repo are 6.3.10.0.136 and 6.5.7.0.46.
If the new firmwares solve your problem, please let me know and I'll
push them to the linux-firmware git repo.
> > To use the driver in the Luca's tree I need to do some work to adapt my
> > platform to the latest kernel version, what I would like to avoid for now.
> > Is there any set of patches to put the driver in vanilla kernel 3.9 in a
> > more stable condition?
>
> Well 3.9 is pretty new, so the difference is not that big. A simple
> cherry pick of all patches done on <root>/drivers/wireless/ti/ would
> do the trick.
>
> Or you could always used compat-wireless, or in it's new name "driver
> backports":
> https://backports.wiki.kernel.org/index.php/Main_Page
I'd really recommend cherry-picking just what is needed. It should be
very few patches. And every time you find a new patch that fixes some
real issue you're seeing, let me know and I'll send to stable.
You're so close to the mainline that it would be silly to use compat
just for a few patches. ;)
--
Cheers,
Luca.
^ permalink raw reply
* New device for ar5523
From: Dmitry Zganyaiko @ 2013-07-09 8:59 UTC (permalink / raw)
To: Pontus Fuchs; +Cc: linux-wireless
Hi! I'm using usb wireless adaptor named
07d1:3a0d D-Link System DWA-120 802.11g Wireless 108G (taken from lsusb)
System is Debian wheezy with 3.8 kernel taken from ubuntu reps. But after launch this adaptor doesn't work: no any new network interfaces is shown in ifconfig.
As far as I understood, such vendor:product (07d1:3a0d) isn't specified in drivers/net/wireless/ath/ar5523/ar5523.c, and therefore the driver doesn't recognise my device. Firmware 'ar5523.bin' is located in /usr/local/lib/firmware.
What can I do to make this adaptor work? Only add that v:p pair to ar5523.c and recompile it? Just if that can be done without compiling - it will be great.
Regards,
Dmitry.
^ permalink raw reply
* intel 4965 fails to set channel 12 or 13
From: Hendrik-Jan Heins @ 2013-07-09 8:47 UTC (permalink / raw)
To: linux-wireless
Dear list,
On Debian Wheezy, kernel 3.2, I am trying to get my iwl4965 to
scan/find/connect on channels 13 and 13. As I am in Europe, this
should be no issue.
However: I can not get these channels activated on my card at all!
I tried the following:
- Using the regdom option, setting to EU, DE, or PL (I see the correct
setting in /sys/modules/cfg80211/parameters/ieee_regdom...
- Completely disabling CRDA, and manually loading regdom through iw
reg set EU/DE/PL/US
In all cases, I see some changes in the channels listed, but I never
get 12 and 13 enabled.
Does anyone has an idea on this?
thanks,
Hendrik-Jan
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Arik Nemtsov @ 2013-07-09 7:21 UTC (permalink / raw)
To: José Miguel Gonçalves; +Cc: linux-wireless, Luciano Coelho
In-Reply-To: <51DB4195.8090103@inov.pt>
On Tue, Jul 9, 2013 at 1:47 AM, José Miguel Gonçalves
<jose.goncalves@inov.pt> wrote:
> Hi Arik,
>
> Yep, that patch solved the kernel warning, but the association with the AP
> is still lost after 3 warnings;
>
>
> wlcore: Beacon loss detected. roles:0xff
This one is possibly a FW version issue. I'd give it a go with the
latest FW in TI's git:
https://github.com/TI-OpenLink/ti-utils/tree/master/hw/firmware
>
> To use the driver in the Luca's tree I need to do some work to adapt my
> platform to the latest kernel version, what I would like to avoid for now.
> Is there any set of patches to put the driver in vanilla kernel 3.9 in a
> more stable condition?
Well 3.9 is pretty new, so the difference is not that big. A simple
cherry pick of all patches done on <root>/drivers/wireless/ti/ would
do the trick.
Or you could always used compat-wireless, or in it's new name "driver
backports":
https://backports.wiki.kernel.org/index.php/Main_Page
Arik
^ permalink raw reply
* Re: [PATCHv3 4/5] mac80211: add channel switch command and beacon callbacks
From: Michal Kazior @ 2013-07-09 7:17 UTC (permalink / raw)
To: Simon Wunderlich
Cc: Johannes Berg, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1373289250-12259-5-git-send-email-siwu@hrz.tu-chemnitz.de>
Hi Simon,
On 8 July 2013 15:14, Simon Wunderlich
<simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> +static int ieee80211_channel_switch(struct wiphy *wiphy, struct net_device *dev,
> + struct cfg80211_csa_settings *params)
> +{
> + struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> + struct ieee80211_local *local = sdata->local;
> + struct ieee80211_chanctx_conf *chanctx_conf;
> + struct ieee80211_chanctx *chanctx;
> + int err;
> +
> + if (!list_empty(&local->roc_list) || local->scanning)
> + return -EBUSY;
> +
> + if (sdata->wdev.cac_started)
> + return -EBUSY;
> +
> + /* don't handle if chanctx is used */
> + if (local->use_chanctx)
> + return -EBUSY;
> +
> + rcu_read_lock();
> + chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> + if (!chanctx_conf) {
> + rcu_read_unlock();
> + return -EBUSY;
> + }
> +
> + /* don't handle for multi-VIF cases */
> + chanctx = container_of(chanctx_conf, struct ieee80211_chanctx, conf);
> + if (chanctx->refcount > 1) {
> + rcu_read_unlock();
> + return -EBUSY;
> + }
> + rcu_read_unlock();
I'm wondering if it's a huge hassle to support drivers that depend on
channel context API? Perhaps local->open_count could be used instead
of local->use_chantx and chanctx->refcount?
I'm also worried this can possibly do silly things if someone starts
an interface while CSA is under way. Consider the following:
* start AP
* initiate channel switch
[ while channel switch is in progress and driver is yet to call
ieee80211_csa_finish() ]
* start another STA interface and associate
[ CSA completes ]
Upon CSA completion the STA will be moved to a different channel
silently and most likely end up with a beacon loss quickly. I think
mac80211 should forbid bringing up any new interfaces during CSA.
It seems there's nothing preventing from multiple calls to channel
switch callback. Is this expected? Can this work if CSA is invoked
while other CSA is still in progress?
Pozdrawiam / Best regards,
Michał Kazior.
^ 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;
as well as URLs for NNTP newsgroup(s).