* 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
* RE: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels
From: Peer, Ilan @ 2013-07-09 5:40 UTC (permalink / raw)
To: Jouni Malinen
Cc: linux-wireless@vger.kernel.org, mcgrof@do-not-panic.com,
Spinadel, David
In-Reply-To: <20130708100418.GA10670@w1.fi>
> -----Original Message-----
> From: Jouni Malinen [mailto:j@w1.fi]
> Sent: Monday, July 08, 2013 13:04
> To: Peer, Ilan
> Cc: linux-wireless@vger.kernel.org; mcgrof@do-not-panic.com; Spinadel, David
> Subject: Re: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional
> channels
>
> On Tue, Jul 02, 2013 at 03:28:15PM +0300, Ilan Peer wrote:
> > Allow GO operation on a channel marked with
> IEEE80211_CHAN_INDOOR_ONLY
> > or IEEE80211_CHAN_GO_CONCURRENT iff there is an active station
> > interface that is associated to an AP operating on this channel.
> >
> > Note that this is a permissive approach to the FCC definitions, that
> > require a clear assessment that either the platform device is an
> > indoor device, or the device operating the AP is an indoor device,
> > i.e., AC powered.
> > It is assumed that these restrictions are enforced by user space.
>
> The introduction in 0/3 mentioned DFS, but I did not see it being addressed in
> any of the actual changes. Is this only for indoors vs.
> outdoors?
>
The DFS was mentioned in 0/3 in the context of an example for a case where a device can support WFD on bands where an authorized master is operating. The example assumes that the master has radar detection capabilities and is able to evacuate its operating channel if needed (which must be followed by the device also evicting the WFD operation from this channel).
The purpose of this patch was to allow the instantiation of a GO on channels marked as indoor/Concurrent GO assuming some conditions are met, ignoring the NO_IBSS and PASSIVE channels. I intend to implement to full restriction logic in the wpa_supplicant (based on the device type etc.), and also handle the actual indication that this channel can no longer be used, eviction and new channel selection in the wpa_supplicant.
> > Furthermore, it is assumed, that if the conditions that allowed for
> > the operation of the GO on such a channel change, it is the
> > responsibility of user space to evacuate the GO from the channel.
>
> Do you have plans or changes to address this? I'd assume wpa_supplicant could
> stop the group on channel list changes, but I don't think it does that currently.
Yes. This is currently WIP :)
^ permalink raw reply
* Re: [PATCH] rtlwifi: Fix Kconfig for some corner cases
From: Larry Finger @ 2013-07-09 2:34 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, Fengguang Wu
In-Reply-To: <1373165244-9536-1-git-send-email-Larry.Finger@lwfinger.net>
On 07/06/2013 09:47 PM, Larry Finger wrote:
> Fengguang Wu reported the following errors in the build of rtlwifi with
> a random configuration:
John,
Please drop this patch. A better one will be submitted later.
Larry
^ permalink raw reply
* Re: [PATCH] rtlwifi: Fix Kconfig for some corner cases
From: Larry Finger @ 2013-07-09 2:33 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linville, linux-wireless, netdev, Fengguang Wu
In-Reply-To: <1373330415.1860.14.camel@bwh-desktop.uk.level5networks.com>
On 07/08/2013 07:40 PM, Ben Hutchings wrote:
> On Sun, 2013-07-07 at 13:13 -0500, Larry Finger wrote:
>> On 07/07/2013 04:42 AM, Ben Hutchings wrote:
>>> On Sat, 2013-07-06 at 21:47 -0500, Larry Finger wrote:
>>>>
>>>> Although I could not duplicate this result on my machine, it seemed likely
>>>> that it was due to the unusual configuration where rtlwifi was being built,
>>>> but none of its dependent drivers were selected.
>>>
>>> I think it just requires:
>>>
>>> CONFIG_USB=m
>>> CONFIG_RTLWIFI=y
>>>
>>>> The fix is to select rtlwifi only when it is needed.
>>>
>>> I don't think so. Consider this configuration:
>>>
>>> CONFIG_PCI=y
>>> CONFIG_USB=m
>>> CONFIG_RTL_CARDS=y
>>> CONFIG_RTL8192CE=y
>>> CONFIG_RTL8192CU=m
>>> CONFIG_RTLWIFI=y # maximum of RTL8192CE=y and RTL8192CU=m
>>>
>>> The same breakage occurs.
>>
>> Ben,
>>
>> Thanks for your comments. I certainly do not claim to understand very much about
>> the whole Kbuild process.
>>
>> After setting up the above configuration manually, I ran 'make oldconfig' and
>> got back
>>
>> CONFIG_RTL_CARDS=m
>> CONFIG_RTL8192CE=m
>> CONFIG_RTL8192SE=m
>> CONFIG_RTL8192DE=m
>> CONFIG_RTL8723AE=m
>> CONFIG_RTL8188EE=m
>> CONFIG_RTL8192CU=m
>> CONFIG_RTLWIFI=m
>> CONFIG_RTLWIFI_DEBUG=y
>> CONFIG_RTL8192C_COMMON=m
>>
>> That set of configuration parameters built normally.
>
> But you can still manually set:
>
> CONFIG_PCI=y
> CONFIG_USB=m
> CONFIG_MAC80211=y # maybe you had =m here?
> CONFIG_RTL_CARDS=y
> CONFIG_RTL8192CE=y
>
> and that will select:
>
> CONFIG_RTLWIFI=y
>
>>>> While making this
>>>> change, I simplified the configuration so that variable RTLWIFI is never seen
>>>> by the user.
>>> [...]
>>>
>>> This will break existing configurations as RTL_CARDS defaults to n.
>>
>> I added a 'default y' to the RTL_CARDS stanza. I now get the following:
>>
>> finger@larrylap:~/staging> make
>> scripts/kconfig/conf --silentoldconfig Kconfig
>> *
>> * Restart config...
>> *
>> *
>> * Realtek rtlwifi family of devices
>> *
>> Realtek rtlwifi family of devices (RTL_CARDS) [M/n/?] (NEW)
>>
>> That should prevent breakage of existing configurations. It defaults to "m"
>> because mac80211 is built as a module in my configuration.
>>
>>> Perhaps you should introduce separate modules for the common PCI and USB
>>> support code, similarly to how the rt2x00 modules are organised.
>>
>> That would not be very difficult, but it would involve converting the single
>> module rtlwifi into 3 separate entities. Does that make sense to you? I'm not sure.
>
> Yes it does make sense.
I will be submitting a new patch as an RFC.
Larry
^ permalink raw reply
* Re: [PATCH] rtlwifi: Fix Kconfig for some corner cases
From: Ben Hutchings @ 2013-07-09 0:40 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev, Fengguang Wu
In-Reply-To: <51D9AFB2.2030707@lwfinger.net>
On Sun, 2013-07-07 at 13:13 -0500, Larry Finger wrote:
> On 07/07/2013 04:42 AM, Ben Hutchings wrote:
> > On Sat, 2013-07-06 at 21:47 -0500, Larry Finger wrote:
> >>
> >> Although I could not duplicate this result on my machine, it seemed likely
> >> that it was due to the unusual configuration where rtlwifi was being built,
> >> but none of its dependent drivers were selected.
> >
> > I think it just requires:
> >
> > CONFIG_USB=m
> > CONFIG_RTLWIFI=y
> >
> >> The fix is to select rtlwifi only when it is needed.
> >
> > I don't think so. Consider this configuration:
> >
> > CONFIG_PCI=y
> > CONFIG_USB=m
> > CONFIG_RTL_CARDS=y
> > CONFIG_RTL8192CE=y
> > CONFIG_RTL8192CU=m
> > CONFIG_RTLWIFI=y # maximum of RTL8192CE=y and RTL8192CU=m
> >
> > The same breakage occurs.
>
> Ben,
>
> Thanks for your comments. I certainly do not claim to understand very much about
> the whole Kbuild process.
>
> After setting up the above configuration manually, I ran 'make oldconfig' and
> got back
>
> CONFIG_RTL_CARDS=m
> CONFIG_RTL8192CE=m
> CONFIG_RTL8192SE=m
> CONFIG_RTL8192DE=m
> CONFIG_RTL8723AE=m
> CONFIG_RTL8188EE=m
> CONFIG_RTL8192CU=m
> CONFIG_RTLWIFI=m
> CONFIG_RTLWIFI_DEBUG=y
> CONFIG_RTL8192C_COMMON=m
>
> That set of configuration parameters built normally.
But you can still manually set:
CONFIG_PCI=y
CONFIG_USB=m
CONFIG_MAC80211=y # maybe you had =m here?
CONFIG_RTL_CARDS=y
CONFIG_RTL8192CE=y
and that will select:
CONFIG_RTLWIFI=y
> >> While making this
> >> change, I simplified the configuration so that variable RTLWIFI is never seen
> >> by the user.
> > [...]
> >
> > This will break existing configurations as RTL_CARDS defaults to n.
>
> I added a 'default y' to the RTL_CARDS stanza. I now get the following:
>
> finger@larrylap:~/staging> make
> scripts/kconfig/conf --silentoldconfig Kconfig
> *
> * Restart config...
> *
> *
> * Realtek rtlwifi family of devices
> *
> Realtek rtlwifi family of devices (RTL_CARDS) [M/n/?] (NEW)
>
> That should prevent breakage of existing configurations. It defaults to "m"
> because mac80211 is built as a module in my configuration.
>
> > Perhaps you should introduce separate modules for the common PCI and USB
> > support code, similarly to how the rt2x00 modules are organised.
>
> That would not be very difficult, but it would involve converting the single
> module rtlwifi into 3 separate entities. Does that make sense to you? I'm not sure.
Yes it does make sense.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-08 22:47 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho
In-Reply-To: <CA+XVXfcakDiN1pPqGDQAN=VR8p_C1LUWGt_nX-rGXDLsBkk+Dw@mail.gmail.com>
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
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?
Best regards,
Jose Gonçalves
On 08-07-2013 20:08, Arik Nemtsov wrote:
> Hey,
>
> About the second issue - seems the following patch is missing from your tree:
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/105449
>
> So the warning is bogus. It will happen if you're working on a single
> processor (UP) system.
>
> To get the latest driver, you can use Luca's tree, which already
> contains this patch:
> git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
>
> Arik
>
>
> On Mon, Jul 8, 2013 at 9:54 PM, José Miguel Gonçalves
> <jose.goncalves@inov.pt> wrote:
>> Hi,
>>
>> After solving some initial platform issues, I'm now blocked in two more
>> issues using the wl127x driver with kernel 3.9.9 in a S3C2416 hardware based
>> platform.
>>
>> The first one is that the command "iw wlan0 scan" does not scan all
>> frequencies. I've seen a patch submitted to fix an issue in the driver for
>> the 5 GHz band
>> (http://permalink.gmane.org/gmane.linux.kernel.wireless.general/107771) but
>> this is not my issue, because I can not see also several APs in the 2.4GHz
>> band after a scan.
>>
>> The second issue is when I try to associate with an AP using WPA2-PSK with
>> wpa_supplicant (only able to reach this point by setting "scan_freq" in
>> wpa_supplicat.conf file to the frequency used by the AP, because of the
>> inability to perform of a complete scan) I get an error in the driver, as
>> shown in the log bellow:
>>
>>
>> [root ~]$ wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
>> Successfully initialized wpa_supplicant
>> [ 33.915000] wlcore: firmware booted (Rev 6.3.10.0.133)
>> [ 34.280000] cfg80211: Calling CRDA for country: PT
>> [ 34.290000] cfg80211: Regulatory domain changed to country: PT
>> [ 34.290000] cfg80211: (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [ 34.305000] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A,
>> 2000 mBm)
>> [ 34.320000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A,
>> 2000 mBm)
>> [ 34.320000] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A,
>> 2000 mBm)
>> [ 34.330000] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A,
>> 2700 mBm)
>> [ 34.340000] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz),
>> (N/A, 4000 mBm)
>> wlan0: SME: Trying to authenticate with 88:43:e1:57:79:c0 (SSID='[
>> 34.585000] wlan0: authenticate with 88:43:e1:57:79:c0
>> A. Guidance' freq=2452 MHz)
>> [ 34.595000] ------------[ cut here ]------------
>> [ 34.595000] WARNING: at drivers/net/wireless/ti/wlcore/tx.c:1307
>> wlcore_is_queue_stopped_by_reason_locked+0x98/0xb4 [wlcore]()
>> [ 34.595000] Modules linked in: arc4 wl12xx wlcore mac80211 wlcore_sdio
>> lm70
>> [ 34.595000] Backtrace:
>> [ 34.595000] [<c000b92c>] (dump_backtrace+0x0/0x10c) from [<c02ed4a4>]
>> (dump_stack+0x18/0x1c)
>> [ 34.595000] r6:bf05ddd8 r5:00000009 r4:00000000 r3:00000000
>> [ 34.595000] [<c02ed48c>] (dump_stack+0x0/0x1c) from [<c0019ecc>]
>> (warn_slowpath_common+0x54/0x70)
>> [ 34.595000] [<c0019e78>] (warn_slowpath_common+0x0/0x70) from
>> [<c0019f0c>] (warn_slowpath_null+0x24/0x2c)
>> [ 34.595000] r8:c39e2acc r7:00000000 r6:c305b160 r5:bf06ca36 r4:00000002
>> r3:00000009
>> [ 34.595000] [<c0019ee8>] (warn_slowpath_null+0x0/0x2c) from [<bf05ddd8>]
>> (wlcore_is_queue_stopped_by_reason_locked+0x98/0xb4 [wlcore])
>> [ 34.595000] [<bf05dd40>]
>> (wlcore_is_queue_stopped_by_reason_locked+0x0/0xb4 [wlcore]) from
>> [<bf05de38>] (wlcore_is_queue_stopped_by_reason+0x44/0x7c [wlcore])
>> [ 34.595000] r6:00000000 r5:c305b160 r4:80000013
>> [ 34.595000] [<bf05ddf4>] (wlcore_is_queue_stopped_by_reason+0x0/0x7c
>> [wlcore]) from [<bf05deb4>] (wl1271_handle_tx_low_watermark+0x44/0x94
>> [wlcore])
>> [ 34.595000] r8:c305b160 r7:c39e2acc r6:00000000 r5:c39e2acc r4:00000000
>> r3:00000000
>> [ 34.595000] [<bf05de70>] (wl1271_handle_tx_low_watermark+0x0/0x94
>> [wlcore]) from [<bf05e050>] (wl1271_tx_reset_link_queues+0x14c/0x174
>> [wlcore])
>> [ 34.595000] [<bf05df04>] (wl1271_tx_reset_link_queues+0x0/0x174 [wlcore])
>> from [<bf05970c>] (wl12xx_free_link+0xec/0x150 [wlcore])
>> [ 34.595000] [<bf059620>] (wl12xx_free_link+0x0/0x150 [wlcore]) from
>> [<bf059b50>] (wl12xx_cmd_role_stop_sta+0x98/0x100 [wlcore])
>> [ 34.595000] r7:c305b160 r6:00000000 r5:c39e2acc r4:c3a89ac0
>> [ 34.595000] [<bf059ab8>] (wl12xx_cmd_role_stop_sta+0x0/0x100 [wlcore])
>> from [<bf0546d8>] (wl1271_bss_info_changed_sta+0x840/0x9a4 [wlcore])
>> [ 34.595000] r7:c39e2acc r6:c305b160 r5:c39e2a10 r4:000000e0
>> [ 34.595000] [<bf053e98>] (wl1271_bss_info_changed_sta+0x0/0x9a4 [wlcore])
>> from [<bf054a0c>] (wl1271_op_bss_info_changed+0x1d0/0x46c [wlcore])
>> [ 34.595000] [<bf05483c>] (wl1271_op_bss_info_changed+0x0/0x46c [wlcore])
>> from [<bf009538>] (ieee80211_bss_info_change_notify+0x6c/0x10c [mac80211])
>> [ 34.595000] [<bf0094cc>] (ieee80211_bss_info_change_notify+0x0/0x10c
>> [mac80211]) from [<bf02bf1c>] (ieee80211_prep_connection+0x2dc/0x76c
>> [mac80211])
>> [ 34.595000] r7:00000fff r6:c39cfe48 r5:c305b8e4 r4:c39e2440
>> [ 34.595000] [<bf02bc40>] (ieee80211_prep_connection+0x0/0x76c [mac80211])
>> from [<bf030d70>] (ieee80211_mgd_auth+0x228/0x29c [mac80211])
>> [ 34.595000] [<bf030b48>] (ieee80211_mgd_auth+0x0/0x29c [mac80211]) from
>> [<bf01afd4>] (ieee80211_auth+0x18/0x1c [mac80211])
>> [ 34.595000] [<bf01afbc>] (ieee80211_auth+0x0/0x1c [mac80211]) from
>> [<c02e40a8>] (__cfg80211_mlme_auth+0x170/0x188)
>> [ 34.595000] [<c02e3f38>] (__cfg80211_mlme_auth+0x0/0x188) from
>> [<c02e4154>] (cfg80211_mlme_auth+0x94/0xb8)
>> [ 34.595000] [<c02e40c0>] (cfg80211_mlme_auth+0x0/0xb8) from [<c02dffbc>]
>> (nl80211_authenticate+0x258/0x27c)
>> [ 34.595000] [<c02dfd64>] (nl80211_authenticate+0x0/0x27c) from
>> [<c0260044>] (genl_rcv_msg+0x23c/0x274)
>> [ 34.595000] [<c025fe08>] (genl_rcv_msg+0x0/0x274) from [<c025f458>]
>> (netlink_rcv_skb+0xb4/0xc8)
>> [ 34.595000] [<c025f3a4>] (netlink_rcv_skb+0x0/0xc8) from [<c025fdfc>]
>> (genl_rcv+0x20/0x2c)
>> [ 34.595000] r6:00000048 r5:c3a5b400 r4:c38c4bc0 r3:c025fddc
>> [ 34.595000] [<c025fddc>] (genl_rcv+0x0/0x2c) from [<c025ee40>]
>> (netlink_unicast+0x1b0/0x214)
>> [ 34.595000] r4:c38c5e00 r3:c025fddc
>> [ 34.595000] [<c025ec90>] (netlink_unicast+0x0/0x214) from [<c025f230>]
>> (netlink_sendmsg+0x2e0/0x358)
>> [ 34.595000] [<c025ef50>] (netlink_sendmsg+0x0/0x358) from [<c0230944>]
>> (sock_sendmsg+0x88/0xa8)
>> [ 34.595000] [<c02308bc>] (sock_sendmsg+0x0/0xa8) from [<c0230d64>]
>> (___sys_sendmsg+0x2c8/0x2e0)
>> [ 34.595000] [<c0230a9c>] (___sys_sendmsg+0x0/0x2e0) from [<c0232920>]
>> (__sys_sendmsg+0x44/0x70)
>> [ 34.595000] [<c02328dc>] (__sys_sendmsg+0x0/0x70) from [<c023295c>]
>> (sys_sendmsg+0x10/0x14)
>> [ 34.595000] r6:be94fa8c r5:017940a0 r4:00000000
>> [ 34.595000] [<c023294c>] (sys_sendmsg+0x0/0x14) from [<c0009400>]
>> (ret_fast_syscall+0x0/0x2c)
>> [ 34.595000] ---[ end trace a2c5f3d5ef286154 ]---
>> [ 34.605000] wlan0: send auth to 88:43:e1:57:79:c0 (try 1/3)
>> [ 34.605000] ------------[ cut here ]------------
>> [ 34.605000] WARNING: at drivers/net/wireless/ti/wlcore/tx.c:1316
>> wlcore_is_queue_stopped_locked+0x74/0x8c [wlcore]()
>> [ 34.605000] Modules linked in: arc4 wl12xx wlcore mac80211 wlcore_sdio
>> lm70
>> [ 34.605000] Backtrace:
>> [ 34.605000] [<c000b92c>] (dump_backtrace+0x0/0x10c) from [<c02ed4a4>]
>> (dump_stack+0x18/0x1c)
>> [ 34.605000] r6:bf05f240 r5:00000009 r4:00000000 r3:00000000
>> [ 34.605000] [<c02ed48c>] (dump_stack+0x0/0x1c) from [<c0019ecc>]
>> (warn_slowpath_common+0x54/0x70)
>> [ 34.605000] [<c0019e78>] (warn_slowpath_common+0x0/0x70) from
>> [<c0019f0c>] (warn_slowpath_null+0x24/0x2c)
>> [ 34.605000] r8:40000013 r7:c305b160 r6:c305b160 r5:bf06ca36 r4:00000000
>> r3:00000009
>> [ 34.605000] [<c0019ee8>] (warn_slowpath_null+0x0/0x2c) from [<bf05f240>]
>> (wlcore_is_queue_stopped_locked+0x74/0x8c [wlcore])
>> [ 34.605000] [<bf05f1cc>] (wlcore_is_queue_stopped_locked+0x0/0x8c
>> [wlcore]) from [<bf05225c>] (wl1271_op_tx+0x104/0x290 [wlcore])
>> [ 34.605000] r6:c39e2a10 r5:00000001 r4:c38c4a40 r3:00000003
>> [ 34.605000] [<bf052158>] (wl1271_op_tx+0x0/0x290 [wlcore]) from
>> [<bf023e64>] (__ieee80211_tx+0x134/0x384 [mac80211])
>> [ 34.605000] [<bf023d30>] (__ieee80211_tx+0x0/0x384 [mac80211]) from
>> [<bf024174>] (ieee80211_tx+0xc0/0xe8 [mac80211])
>> [ 34.605000] [<bf0240b4>] (ieee80211_tx+0x0/0xe8 [mac80211]) from
>> [<bf02474c>] (ieee80211_xmit+0x80/0x94 [mac80211])
>> [ 34.605000] [<bf0246cc>] (ieee80211_xmit+0x0/0x94 [mac80211]) from
>> [<bf025698>] (__ieee80211_tx_skb_tid_band+0x58/0x64 [mac80211])
>> [ 34.605000] r8:00000000 r7:00000001 r6:00000000 r5:c39e2440 r4:c38c4a40
>> r3:c3ae8000
>> [ 34.605000] [<bf025640>] (__ieee80211_tx_skb_tid_band+0x0/0x64
>> [mac80211]) from [<bf0286c4>] (ieee80211_send_auth+0x158/0x1e0 [mac80211])
>> [ 34.605000] r6:c39e2440 r5:c38c4a40 r4:c3ac8b94 r3:00000000
>> [ 34.605000] [<bf02856c>] (ieee80211_send_auth+0x0/0x1e0 [mac80211]) from
>> [<bf02c550>] (ieee80211_probe_auth+0x174/0x2c8 [mac80211])
>> [ 34.605000] [<bf02c3dc>] (ieee80211_probe_auth+0x0/0x2c8 [mac80211]) from
>> [<bf030d80>] (ieee80211_mgd_auth+0x238/0x29c [mac80211])
>> [ 34.605000] r8:c39e2798 r7:00000000 r6:c39e2440 r5:c3a72c20 r4:c3ae9af8
>> [ 34.605000] [<bf030b48>] (ieee80211_mgd_auth+0x0/0x29c [mac80211]) from
>> [<bf01afd4>] (ieee80211_auth+0x18/0x1c [mac80211])
>> [ 34.605000] [<bf01afbc>] (ieee80211_auth+0x0/0x1c [mac80211]) from
>> [<c02e40a8>] (__cfg80211_mlme_auth+0x170/0x188)
>> [ 34.605000] [<c02e3f38>] (__cfg80211_mlme_auth+0x0/0x188) from
>> [<c02e4154>] (cfg80211_mlme_auth+0x94/0xb8)
>> [ 34.605000] [<c02e40c0>] (cfg80211_mlme_auth+0x0/0xb8) from [<c02dffbc>]
>> (nl80211_authenticate+0x258/0x27c)
>> [ 34.605000] [<c02dfd64>] (nl80211_authenticate+0x0/0x27c) from
>> [<c0260044>] (genl_rcv_msg+0x23c/0x274)
>> [ 34.605000] [<c025fe08>] (genl_rcv_msg+0x0/0x274) from [<c025f458>]
>> (netlink_rcv_skb+0xb4/0xc8)
>> [ 34.605000] [<c025f3a4>] (netlink_rcv_skb+0x0/0xc8) from [<c025fdfc>]
>> (genl_rcv+0x20/0x2c)
>> [ 34.605000] r6:00000048 r5:c3a5b400 r4:c38c4bc0 r3:c025fddc
>> [ 34.605000] [<c025fddc>] (genl_rcv+0x0/0x2c) from [<c025ee40>]
>> (netlink_unicast+0x1b0/0x214)
>> [ 34.605000] r4:c38c5e00 r3:c025fddc
>> [ 34.605000] [<c025ec90>] (netlink_unicast+0x0/0x214) from [<c025f230>]
>> (netlink_sendmsg+0x2e0/0x358)
>> [ 34.605000] [<c025ef50>] (netlink_sendmsg+0x0/0x358) from [<c0230944>]
>> (sock_sendmsg+0x88/0xa8)
>> [ 34.605000] [<c02308bc>] (sock_sendmsg+0x0/0xa8) from [<c0230d64>]
>> (___sys_sendmsg+0x2c8/0x2e0)
>> [ 34.605000] [<c0230a9c>] (___sys_sendmsg+0x0/0x2e0) from [<c0232920>]
>> (__sys_sendmsg+0x44/0x70)
>> [ 34.605000] [<c02328dc>] (__sys_sendmsg+0x0/0x70) from [<c023295c>]
>> (sys_sendmsg+0x10/0x14)
>> [ 34.605000] r6:be94fa8c r5:017940a0 r4:00000000
>> [ 34.605000] [<c023294c>] (sys_sendmsg+0x0/0x14) from [<c0009400>]
>> (ret_fast_syscall+0x0/0x2c)
>> [ 34.605000] ---[ end trace a2c5f3d5ef286155 ]---
>> [ 34.625000] wlan0: send auth to 88:43:e1:57:79:c0 (try 2/3)
>> [ 34.640000] wlan0: send auth to 88:43:e1:57:79:c0 (try 3/3)
>> [ 34.650000] wlan0: authentication with 88:43:e1:57:79:c0 timed out
>> wlan0: SME: Trying to authenticate with 88:43:e1:57:79:c0 (SSID='[
>> 34.875000] wlan0: authenticate with 88:43:e1:57:79:c0
>> A. Guidance' freq=2452 MHz)
>> [ 34.915000] wlan0: send auth to 88:43:e1:57:79:c0 (try 1/3)
>> [ 34.920000] wlan0: authenticated
>> wlan0: Trying to associate with 88:43:e1:57:79:c0 (SSID='A. Guidance'
>> freq=2452 MHz)
>> [ 34.995000] wlan0: associate with 88:43:e1:57:79:c0 (try 1/3)
>> [ 35.015000] wlan0: associate with 88:43:e1:57:79:c0 (try 2/3)
>> [ 35.035000] wlan0: associate with 88:43:e1:57:79:c0 (try 3/3)
>> [ 35.060000] wlan0: association with 88:43:e1:57:79:c0 timed out
>> wlan0: SME: Trying to authenticate with 88:43:e1:57:79:c0 (SSID='[
>> 35.620000] wlan0: authenticate with 88:43:e1:57:79:c0
>> A. Guidance' freq=2452 MHz)
>> [ 35.660000] wlan0: send auth to 88:43:e1:57:79:c0 (try 1/3)
>> [ 35.665000] wlan0: authenticated
>> wlan0: Trying to associate with 88:43:e1:57:79:c0 (SSID='A. Guidance'
>> freq=2452 MHz)
>> [ 35.740000] wlan0: associate with 88:43:e1:57:79:c0 (try 1/3)
>> [ 35.745000] wlan0: RX AssocResp from 88:43:e1:57:79:c0 (capab=0x431
>> status=0 aid=2)
>> [ 35.765000] wlan0: associated
>> [ 35.770000] cfg80211: Calling CRDA for country: PT
>> [ 35.780000] cfg80211: Regulatory domain changed to country: PT
>> [ 35.780000] cfg80211: (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [ 35.790000] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A,
>> 2000 mBm)
>> [ 35.790000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A,
>> 2000 mBm)
>> [ 35.800000] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A,
>> 2000 mBm)
>> [ 35.800000] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A,
>> 2700 mBm)
>> [ 35.810000] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz),
>> (N/A, 4000 mBm)
>> wlan0: Associated with 88:43:e1:57:79:c0
>> [ 37.585000] wlcore: Beacon loss detected. roles:0xff
>> [ 39.250000] wlcore: Beacon loss detected. roles:0xff
>> [ 40.935000] wlcore: Beacon loss detected. roles:0xff
>> [ 42.400000] wlcore: Connection loss work (role_id: 0).
>> [ 42.400000] wlan0: Connection to AP 88:43:e1:57:79:c0 lost
>> [ 42.475000] cfg80211: Calling CRDA to update world regulatory domain
>> [ 42.485000] cfg80211: World regulatory domain updated:
>> [ 42.485000] cfg80211: (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [ 42.500000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300
>> mBi, 2000 mBm)
>> [ 42.500000] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300
>> mBi, 2000 mBm)
>> [ 42.515000] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300
>> mBi, 2000 mBm)
>> [ 42.515000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300
>> mBi, 2000 mBm)
>> [ 42.525000] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300
>> mBi, 2000 mBm)
>> [ 42.525000] cfg80211: Calling CRDA for country: PT
>> [ 42.540000] cfg80211: Regulatory domain changed to country: PT
>> [ 42.540000] cfg80211: (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [ 42.550000] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A,
>> 2000 mBm)
>> [ 42.550000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A,
>> 2000 mBm)
>> [ 42.560000] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A,
>> 2000 mBm)
>> [ 42.560000] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A,
>> 2700 mBm)
>> wlan0: CTRL-EVENT-DISCONNECTED bssid=88:43:e1:57:79:c0 reason=4 l[
>> 42.575000] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A,
>> 4000 mBm)
>> ocally_generated=1
>> wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
>> wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="A. Guidance" auth_failures=1
>> duration=10
>>
>>
>> Any ideas in what could be wrong?
>>
>> Best regards,
>> José Gonçalves
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
____________________________________________________________
José Miguel P. Gonçalves * email: jose.goncalves@inov.pt
*
INOV * Tel.(Phone): +351 213 100 474
Av. Duque de Ávila, 23 *
1000-138 Lisboa *
PORTUGAL * WWW: http://www.inov.pt
____________________________________________________________
^ permalink raw reply
* Re: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels
From: Luis R. Rodriguez @ 2013-07-08 22:04 UTC (permalink / raw)
To: Ilan Peer
Cc: David Spinadel, linux-wireless,
wireless-regdb@lists.infradead.org, Jouni Malinen
In-Reply-To: <1372768095-26053-4-git-send-email-ilan.peer@intel.com>
On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@intel.com> wrote:
> From: David Spinadel <david.spinadel@intel.com>
>
> Allow GO operation on a channel marked with
> IEEE80211_CHAN_INDOOR_ONLY or IEEE80211_CHAN_GO_CONCURRENT
> iff there is an active station interface that is associated to
> an AP operating on this channel.
>
> Note that this is a permissive approach to the FCC definitions,
> that require a clear assessment that either the platform device
> is an indoor device, or the device operating the AP is an indoor
> device, i.e., AC powered.
> It is assumed that these restrictions are enforced by user space.
> Furthermore, it is assumed, that if the conditions that allowed for
> the operation of the GO on such a channel change, it is the
> responsibility of user space to evacuate the GO from the channel.
In the context of strict regulatory data we currently do not
differentiate specifically between a device that can initiate
radiation between AP and Group Owner (GO) but in your earlier patches
you proposed a way to do that. I reviewed feedback on that patch
there. It may make sense however to define clearly what you mean by
why the flag is being introduced by documenting the use case, ie what
you describe here. Other regulatory bodies may follow and it helps to
provide context here.
My review below.
> Signed-off-by: David Spinadel <david.spinadel@intel.com>
> Signed-off-by: Ilan Peer <ilan.peer@intel.com>
> ---
> include/net/cfg80211.h | 4 +-
> net/mac80211/ibss.c | 2 +-
> net/wireless/Kconfig | 10 +++++
> net/wireless/chan.c | 98 ++++++++++++++++++++++++++++++++++++++++++++----
> net/wireless/mesh.c | 2 +-
> net/wireless/nl80211.c | 8 ++--
> net/wireless/trace.h | 11 ++++--
> 7 files changed, 118 insertions(+), 17 deletions(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index f0badeb..17d693d 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -4070,12 +4070,14 @@ void cfg80211_report_obss_beacon(struct wiphy *wiphy,
> * cfg80211_reg_can_beacon - check if beaconing is allowed
> * @wiphy: the wiphy
> * @chandef: the channel definition
> + * @p2p_go: if the interface type is a P2P GO
> *
> * Return: %true if there is no secondary channel or the secondary channel(s)
> * can be used for beaconing (i.e. is not a radar channel etc.)
> */
> bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
> - struct cfg80211_chan_def *chandef);
> + struct cfg80211_chan_def *chandef,
> + bool p2p_go);
>
> /*
> * cfg80211_ch_switch_notify - update wdev channel and notify userspace
> diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
> index ea7b9c2..1e0fac1 100644
> --- a/net/mac80211/ibss.c
> +++ b/net/mac80211/ibss.c
> @@ -82,7 +82,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
> sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
>
> chandef = ifibss->chandef;
> - if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef)) {
> + if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef, false)) {
> chandef.width = NL80211_CHAN_WIDTH_20;
> chandef.center_freq1 = chan->center_freq;
> }
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index de76078..d9e2be7 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -102,6 +102,16 @@ config CFG80211_REG_CELLULAR_HINTS
> This option adds support for drivers that can receive regulatory
> hints from cellular base stations
>
> +config CFG80211_REG_SOFT_CONFIGURATIONS
> + bool "cfg80211 support for GO operation on additional channels"
> + depends on CFG80211 && CFG80211_CERTIFICATION_ONUS
> + ---help---
> + This option enables the operation of a P2P Group Owner on
> + additional channels, if there is a clear assessment that
> + the platform device operates in an indoor environment or
> + in case that there is an additional BSS interface which is
> + connected to an AP which is an indoor device.
> +
I like this approach, indeed this is great work and reflects usage of
the onus kconfig option appropriately in this case due dilligence
required more in part on userspace / other components for full
regulatory compliance.
> config CFG80211_DEFAULT_PS
> bool "enable powersave by default"
> depends on CFG80211
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index 50f6195..92d9e3c 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -457,18 +457,102 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
> }
> EXPORT_SYMBOL(cfg80211_chandef_usable);
>
> +#ifdef CPTCFG_CFG80211_REG_SOFT_CONFIGURATIONS
> +static int cfg80211_get_unii_band(int freq)
> +{
> + /* UNII-1 */
> + if (freq >= 5150 && freq <= 5250)
> + return 0;
> +
> + /* UNII-2 */
> + if (freq > 5250 && freq <= 5350)
> + return 1;
> +
> + /* UNII-2E */
> + if (freq >= 5470 && freq <= 5725)
> + return 2;
> +
> + /* UNII-3 */
> + if (freq > 5725 && freq <= 5825)
> + return 3;
> +
> + WARN_ON(1);
> + return -EINVAL;
> +}
> +#endif
#else?
Are you aware of UNII-1, UNII-2, UNII-2E, UNII-3 are specific world
regulatory language bands? When I last tried to look for a clear
definition I could not find a clear definition of them and its why on
the ath module on for QCA modules I state "we call these" in reference
to the UNII nomenclature. If we can get a clear resource for its
definition that would help here.
> +
> +/* For GO only, check if the channel can be used under permissive conditions
> + * mandated by the FCC, i.e., the channel is marked as:
Ah -- note - FCC, you are making an FCC specific rule global, that
doesn't seems right. The implementation should reflect that *some*
regulatory bodies are implicating software requirements for GO
operation and in that case this tries to implement such known current
interpretations.
Hope is that regulatory bodies will stick to this singular
interpretation / preference when required.
So my point: your code treats this appropriately as agnostic to the
regulatory body but your comments do not, just modify the comments
more to make it more agnostic.
> + * 1. Indoor only: a GO can be operational on such a channel, iff there is
> + * clear assessment that the platform device is indoor.
> + * 2. Concurrent GO: a GO can be operational on such a channel, iff there is an
> + * additional station interface connected to an AP on this channel.
> + *
> + * TODO: The function is too permissive, as it does not verify the platform
> + * device type is indeed indoor, or that the AP is indoor/AC powered.
So to do this properly we need an eventual userspace API to throw to
kernelspace if we are AC powered? We'll need this to enhance this
routine here?
> + */
> +static bool cfg80211_can_go_use_chan(struct cfg80211_registered_device *rdev,
> + struct ieee80211_channel *chan)
> +{
> +#ifdef CPTCFG_CFG80211_REG_SOFT_CONFIGURATIONS
> + struct wireless_dev *wdev_iter;
> +
> + ASSERT_RTNL();
> +
> + if (!(chan->flags & (IEEE80211_CHAN_INDOOR_ONLY |
> + IEEE80211_CHAN_GO_CONCURRENT)))
> + return false;
> +
> + if (chan->band == IEEE80211_BAND_60GHZ)
> + return false;
> +
> + list_for_each_entry(wdev_iter, &rdev->wdev_list, list) {
> + struct ieee80211_channel *other_chan = NULL;
> +
> + if (wdev_iter->iftype != NL80211_IFTYPE_STATION ||
> + (!netif_running(wdev_iter->netdev)))
> + continue;
> +
> +
> + wdev_lock(wdev_iter);
> + if (wdev_iter->current_bss)
> + other_chan = wdev_iter->current_bss->pub.channel;
> + wdev_unlock(wdev_iter);
> +
> + if (!other_chan)
> + continue;
> +
> + if (chan == other_chan)
> + return true;
> + else if ((chan->band == IEEE80211_BAND_5GHZ) &&
> + (cfg80211_get_unii_band(chan->center_freq) ==
> + cfg80211_get_unii_band(other_chan->center_freq)))
> + return true;
> + }
> +#endif
> + return false;
> +}
Please wrap code as follows:
#ifdef FOO
static int foo(void)
{
return true;
}
#else
static int foo(void)
return false;
}
#endif
In the meantime, while you get all your patch sets properly developed
I'd recommend to define the code returning false there strictly or
perhaps for any flag on the channel requiring DFS / no-ibss, or
passive scan. The stricter case, defining false always, seems to be
what you are suggesting here.
Do you have a white list that can exclude some channels for now
globally or somehow as all this lines up?
Luis
^ permalink raw reply
* Re:
From: Joe Perches @ 2013-07-08 22:04 UTC (permalink / raw)
To: Jeffrey (Sheng-Hui) Chu; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <90AC93A0CCA054488FFC508D6F62B6F40FED489B@IRVEXCHMB07.corp.ad.broadcom.com>
On Mon, 2013-07-08 at 21:52 +0000, Jeffrey (Sheng-Hui) Chu wrote:
[]
> diff --git a/drivers/nfc/bcm2079x/bcm2079x-i2c.c b/drivers/nfc/bcm2079x/bcm2079x-i2c.c
[]
> +/* do not change below */
> +#define MAX_BUFFER_SIZE 780
[]
> +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];
780 bytes on stack isn't a great idea.
> +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];
etc.
> + int ret;
> +
> + if (count > MAX_BUFFER_SIZE) {
> + dev_err(&bcm2079x_dev->client->dev, "out of memory\n");
Out of memory isn't really true.
The packet size is just too big for your
little buffer.
> +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));
Looks to me like this should be dev_dbg not dev_info
^ permalink raw reply
* (no subject)
From: Jeffrey (Sheng-Hui) Chu @ 2013-07-08 21:52 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
>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.
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/
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
--
1.7.9.5
^ permalink raw reply related
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