* Re: [PATCH 1/7] ath10k: simplify HTC credits calculation
From: Michal Kazior @ 2013-09-11 5:06 UTC (permalink / raw)
To: Bob Copeland; +Cc: ath10k, linux-wireless
In-Reply-To: <20130910141413.GE29385@localhost>
On 10 September 2013 16:14, Bob Copeland <me@bobcopeland.com> wrote:
> On Tue, Sep 10, 2013 at 03:49:57PM +0200, Michal Kazior wrote:
>> + skb = __skb_dequeue(&ep->tx_queue);
>> +
>> + if (ep->tx_credit_flow_enabled) {
>> + /* integer division w/ round-up */
>> + credits = (skb->len + htc->target_credit_size - 1) /
>> + htc->target_credit_size;
>
> There's a macro for that...
>
> credits = DIV_ROUND_UP(skb->len, htc->target_credit_size);
I didn't know that. Thanks!
Michał.
^ permalink raw reply
* Re: [PATCH 06/12] wireless: ath10k: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-09-11 0:32 UTC (permalink / raw)
To: 'Kalle Valo'
Cc: 'John W. Linville', linux-wireless, ath10k,
'Jingoo Han'
In-Reply-To: <87zjrkibn0.fsf@kamboji.qca.qualcomm.com>
On Wednesday, September 11, 2013 6:57 AM, Kalle Valo wrote:
> Jingoo Han <jg1.han@samsung.com> writes:
>
> > The driver core clears the driver data to NULL after device_release
> > or on probe failure. Thus, it is not needed to manually clear the
> > device driver data to NULL.
> >
> > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
>
> Thanks, look good. Do you want me to apply this to my ath.git tree or
> are you planning to send this via some other route?
>
Hi Kalle Valo,
It would be good that you apply this to your ath.git tree.
Thank you. :-)
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH 06/12] wireless: ath10k: remove unnecessary pci_set_drvdata()
From: Kalle Valo @ 2013-09-10 21:56 UTC (permalink / raw)
To: Jingoo Han; +Cc: 'John W. Linville', linux-wireless, ath10k
In-Reply-To: <00b701ceae18$69cd1860$3d674920$%han@samsung.com>
Jingoo Han <jg1.han@samsung.com> writes:
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Thanks, look good. Do you want me to apply this to my ath.git tree or
are you planning to send this via some other route?
--
Kalle Valo
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Mark Cave-Ayland @ 2013-09-10 20:04 UTC (permalink / raw)
To: Larry Finger; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522F3757.8030600@lwfinger.net>
On 10/09/13 16:14, Larry Finger wrote:
> Those disconnects do happen for reasons that I do not understand. They
> will be worse on your system without a network manager as it appears
> that you need to manually reconnect at that point, or at least it took a
> long time for the system to react. With NetworkManager, that reconnect
> is automatic, and relatively quick.
Okay - understood.
>> Whilst checking various parts of my kernel, I noticed for the first
>> time during
>> testing that my current kernel configuration doesn't have SMP enabled.
>> This got
>> me thinking that perhaps there are other build options which could
>> have an
>> effect on the driver. Hence I also uploaded a copy of my .config file to
>> http://www.ilande.co.uk/tmp/rtl8192cu-config in the hope that maybe
>> this can
>> help you recreate the issue locally?
>
> As I have a dual-core CPU, thus I always have SMP set. That should not
> be a problem. In fact, the concurrent operation of 2 CPUs usually causes
> more problems. I will review that configuration.
I'd definitely be interested to know if by duplicating that same
configuration, you see the same issues that I do.
> You can now disable the logging. When the watchdog reports that contact
> with the AP has been lost, that is certainly true, and the watchdog is
> doing its job. In addition, nothing was received from any AP, which
> leads me to conclude that the receiver has locked up for some reason. I
> need to check to see what the code does to recover. Perhaps that will
> help me understand the problem. In my current run that has run for 20
> hours, I have had two disconnects for Reason 3, but more importantly, I
> have had two watchdog restarts. It does happen on my system, just a lot
> less frequently. BTW, my ping loss rate is about 3%. That is too high,
> but not as bad as yours.
Interesting. Perhaps there is something different in the initial
programming of the radio that causes it to crash on my particular
hardware revision? As before, please let me know if there is anything
else you require.
ATB,
Mark.
^ permalink raw reply
* pull request: wireless 2013-09-10
From: John W. Linville @ 2013-09-10 19:38 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 12858 bytes --]
Dave,
This is a pull request for a few early fixes for the 3.12 stream.
Alexey Khoroshilov corrects a use-after-free issue on rtl8187 found
by the Linux Driver Verification project.
Arend van Spriel provides a brcmfmac patch to fix a build issue
reported by Randy Dunlap.
Hauke Mehrtens offers a bcma fix to properly account for the storage
width of error code values before checking them.
Solomon Peachy brings a pair of cw1200 fixes to avoid hangs in that
driver with SPI devices. One avoids transfers in interrupt context,
the other fixes a locking issue.
Stanislaw Gruszka changes the initialization of the rt2800 driver to
avoid a freeze, addressing a bug in the Red Hat bugzilla.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit e7d33bb5ea82922e6ddcfc6b28a630b1a4ced071:
lockref: add ability to mark lockrefs "dead" (2013-09-07 15:49:18 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git tags/master-2013-09-09
for you to fetch changes up to f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20:
rt2800: change initialization sequence to fix system freeze (2013-09-09 14:44:34 -0400)
----------------------------------------------------------------
Alexey Khoroshilov (1):
rtl8187: fix use after free on failure path in rtl8187_init_urbs()
Arend van Spriel (1):
brcmfmac: fix bus interface selection in Kconfig
Hauke Mehrtens (1):
bcma: fix error code handling on 64 Bit systems
Solomon Peachy (2):
cw1200: Don't perform SPI transfers in interrupt context
cw1200: Prevent a lock-related hang in the cw1200_spi driver
Stanislaw Gruszka (1):
rt2800: change initialization sequence to fix system freeze
drivers/bcma/scan.c | 12 +++++++-----
drivers/net/wireless/brcm80211/Kconfig | 4 ++--
drivers/net/wireless/cw1200/cw1200_spi.c | 28 +++++++++++++++++++++++++---
drivers/net/wireless/cw1200/fwio.c | 2 +-
drivers/net/wireless/cw1200/hwbus.h | 1 +
drivers/net/wireless/cw1200/hwio.c | 15 +++++++++++++++
drivers/net/wireless/rt2x00/rt2800lib.c | 11 ++++++-----
drivers/net/wireless/rtl818x/rtl8187/dev.c | 15 ++++++++++-----
8 files changed, 67 insertions(+), 21 deletions(-)
diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
index cd6b20f..3776840 100644
--- a/drivers/bcma/scan.c
+++ b/drivers/bcma/scan.c
@@ -269,6 +269,8 @@ static struct bcma_device *bcma_find_core_reverse(struct bcma_bus *bus, u16 core
return NULL;
}
+#define IS_ERR_VALUE_U32(x) ((x) >= (u32)-MAX_ERRNO)
+
static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
struct bcma_device_id *match, int core_num,
struct bcma_device *core)
@@ -351,11 +353,11 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
* the main register space for the core
*/
tmp = bcma_erom_get_addr_desc(bus, eromptr, SCAN_ADDR_TYPE_SLAVE, 0);
- if (tmp == 0 || IS_ERR_VALUE(tmp)) {
+ if (tmp == 0 || IS_ERR_VALUE_U32(tmp)) {
/* Try again to see if it is a bridge */
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_BRIDGE, 0);
- if (tmp == 0 || IS_ERR_VALUE(tmp)) {
+ if (tmp == 0 || IS_ERR_VALUE_U32(tmp)) {
return -EILSEQ;
} else {
bcma_info(bus, "Bridge found\n");
@@ -369,7 +371,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_SLAVE, i);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: slave port %d "
* "has %d descriptors\n", i, j); */
@@ -386,7 +388,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_MWRAP, i);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: master wrapper %d "
* "has %d descriptors\n", i, j); */
@@ -404,7 +406,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_SWRAP, i + hack);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: master wrapper %d "
* has %d descriptors\n", i, j); */
diff --git a/drivers/net/wireless/brcm80211/Kconfig b/drivers/net/wireless/brcm80211/Kconfig
index fc8a0fa..b00a7e9 100644
--- a/drivers/net/wireless/brcm80211/Kconfig
+++ b/drivers/net/wireless/brcm80211/Kconfig
@@ -28,7 +28,7 @@ config BRCMFMAC
config BRCMFMAC_SDIO
bool "SDIO bus interface support for FullMAC driver"
- depends on MMC
+ depends on (MMC = y || MMC = BRCMFMAC)
depends on BRCMFMAC
select FW_LOADER
default y
@@ -39,7 +39,7 @@ config BRCMFMAC_SDIO
config BRCMFMAC_USB
bool "USB bus interface support for FullMAC driver"
- depends on USB
+ depends on (USB = y || USB = BRCMFMAC)
depends on BRCMFMAC
select FW_LOADER
---help---
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index d063760..f5e6b48 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -40,7 +40,9 @@ struct hwbus_priv {
struct cw1200_common *core;
const struct cw1200_platform_data_spi *pdata;
spinlock_t lock; /* Serialize all bus operations */
+ wait_queue_head_t wq;
int claimed;
+ int irq_disabled;
};
#define SDIO_TO_SPI_ADDR(addr) ((addr & 0x1f)>>2)
@@ -197,8 +199,11 @@ static void cw1200_spi_lock(struct hwbus_priv *self)
{
unsigned long flags;
+ DECLARE_WAITQUEUE(wait, current);
+
might_sleep();
+ add_wait_queue(&self->wq, &wait);
spin_lock_irqsave(&self->lock, flags);
while (1) {
set_current_state(TASK_UNINTERRUPTIBLE);
@@ -211,6 +216,7 @@ static void cw1200_spi_lock(struct hwbus_priv *self)
set_current_state(TASK_RUNNING);
self->claimed = 1;
spin_unlock_irqrestore(&self->lock, flags);
+ remove_wait_queue(&self->wq, &wait);
return;
}
@@ -222,6 +228,8 @@ static void cw1200_spi_unlock(struct hwbus_priv *self)
spin_lock_irqsave(&self->lock, flags);
self->claimed = 0;
spin_unlock_irqrestore(&self->lock, flags);
+ wake_up(&self->wq);
+
return;
}
@@ -230,6 +238,8 @@ static irqreturn_t cw1200_spi_irq_handler(int irq, void *dev_id)
struct hwbus_priv *self = dev_id;
if (self->core) {
+ disable_irq_nosync(self->func->irq);
+ self->irq_disabled = 1;
cw1200_irq_handler(self->core);
return IRQ_HANDLED;
} else {
@@ -263,13 +273,22 @@ exit:
static int cw1200_spi_irq_unsubscribe(struct hwbus_priv *self)
{
- int ret = 0;
-
pr_debug("SW IRQ unsubscribe\n");
disable_irq_wake(self->func->irq);
free_irq(self->func->irq, self);
- return ret;
+ return 0;
+}
+
+static int cw1200_spi_irq_enable(struct hwbus_priv *self, int enable)
+{
+ /* Disables are handled by the interrupt handler */
+ if (enable && self->irq_disabled) {
+ enable_irq(self->func->irq);
+ self->irq_disabled = 0;
+ }
+
+ return 0;
}
static int cw1200_spi_off(const struct cw1200_platform_data_spi *pdata)
@@ -349,6 +368,7 @@ static struct hwbus_ops cw1200_spi_hwbus_ops = {
.unlock = cw1200_spi_unlock,
.align_size = cw1200_spi_align_size,
.power_mgmt = cw1200_spi_pm,
+ .irq_enable = cw1200_spi_irq_enable,
};
/* Probe Function to be called by SPI stack when device is discovered */
@@ -400,6 +420,8 @@ static int cw1200_spi_probe(struct spi_device *func)
spi_set_drvdata(func, self);
+ init_waitqueue_head(&self->wq);
+
status = cw1200_spi_irq_subscribe(self);
status = cw1200_core_probe(&cw1200_spi_hwbus_ops,
diff --git a/drivers/net/wireless/cw1200/fwio.c b/drivers/net/wireless/cw1200/fwio.c
index acdff0f..0b2061b 100644
--- a/drivers/net/wireless/cw1200/fwio.c
+++ b/drivers/net/wireless/cw1200/fwio.c
@@ -485,7 +485,7 @@ int cw1200_load_firmware(struct cw1200_common *priv)
/* Enable interrupt signalling */
priv->hwbus_ops->lock(priv->hwbus_priv);
- ret = __cw1200_irq_enable(priv, 1);
+ ret = __cw1200_irq_enable(priv, 2);
priv->hwbus_ops->unlock(priv->hwbus_priv);
if (ret < 0)
goto unsubscribe;
diff --git a/drivers/net/wireless/cw1200/hwbus.h b/drivers/net/wireless/cw1200/hwbus.h
index 8b2fc83..51dfb3a 100644
--- a/drivers/net/wireless/cw1200/hwbus.h
+++ b/drivers/net/wireless/cw1200/hwbus.h
@@ -28,6 +28,7 @@ struct hwbus_ops {
void (*unlock)(struct hwbus_priv *self);
size_t (*align_size)(struct hwbus_priv *self, size_t size);
int (*power_mgmt)(struct hwbus_priv *self, bool suspend);
+ int (*irq_enable)(struct hwbus_priv *self, int enable);
};
#endif /* CW1200_HWBUS_H */
diff --git a/drivers/net/wireless/cw1200/hwio.c b/drivers/net/wireless/cw1200/hwio.c
index ff230b7..41bd761 100644
--- a/drivers/net/wireless/cw1200/hwio.c
+++ b/drivers/net/wireless/cw1200/hwio.c
@@ -273,6 +273,21 @@ int __cw1200_irq_enable(struct cw1200_common *priv, int enable)
u16 val16;
int ret;
+ /* We need to do this hack because the SPI layer can sleep on I/O
+ and the general path involves I/O to the device in interrupt
+ context.
+
+ However, the initial enable call needs to go to the hardware.
+
+ We don't worry about shutdown because we do a full reset which
+ clears the interrupt enabled bits.
+ */
+ if (priv->hwbus_ops->irq_enable) {
+ ret = priv->hwbus_ops->irq_enable(priv->hwbus_priv, enable);
+ if (ret || enable < 2)
+ return ret;
+ }
+
if (HIF_8601_SILICON == priv->hw_type) {
ret = __cw1200_reg_read_32(priv, ST90TDS_CONFIG_REG_ID, &val32);
if (ret < 0) {
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 95e6e61..88ce656 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6659,19 +6659,20 @@ int rt2800_enable_radio(struct rt2x00_dev *rt2x00dev)
rt2800_init_registers(rt2x00dev)))
return -EIO;
+ if (unlikely(rt2800_wait_bbp_rf_ready(rt2x00dev)))
+ return -EIO;
+
/*
* Send signal to firmware during boot time.
*/
rt2800_register_write(rt2x00dev, H2M_BBP_AGENT, 0);
rt2800_register_write(rt2x00dev, H2M_MAILBOX_CSR, 0);
- if (rt2x00_is_usb(rt2x00dev)) {
+ if (rt2x00_is_usb(rt2x00dev))
rt2800_register_write(rt2x00dev, H2M_INT_SRC, 0);
- rt2800_mcu_request(rt2x00dev, MCU_BOOT_SIGNAL, 0, 0, 0);
- }
+ rt2800_mcu_request(rt2x00dev, MCU_BOOT_SIGNAL, 0, 0, 0);
msleep(1);
- if (unlikely(rt2800_wait_bbp_rf_ready(rt2x00dev) ||
- rt2800_wait_bbp_ready(rt2x00dev)))
+ if (unlikely(rt2800_wait_bbp_ready(rt2x00dev)))
return -EIO;
rt2800_init_bbp(rt2x00dev);
diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c b/drivers/net/wireless/rtl818x/rtl8187/dev.c
index 841fb9d..9a6edb0 100644
--- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
@@ -438,17 +438,16 @@ static int rtl8187_init_urbs(struct ieee80211_hw *dev)
skb_queue_tail(&priv->rx_queue, skb);
usb_anchor_urb(entry, &priv->anchored);
ret = usb_submit_urb(entry, GFP_KERNEL);
+ usb_put_urb(entry);
if (ret) {
skb_unlink(skb, &priv->rx_queue);
usb_unanchor_urb(entry);
goto err;
}
- usb_free_urb(entry);
}
return ret;
err:
- usb_free_urb(entry);
kfree_skb(skb);
usb_kill_anchored_urbs(&priv->anchored);
return ret;
@@ -956,8 +955,12 @@ static int rtl8187_start(struct ieee80211_hw *dev)
(RETRY_COUNT << 8 /* short retry limit */) |
(RETRY_COUNT << 0 /* long retry limit */) |
(7 << 21 /* MAX TX DMA */));
- rtl8187_init_urbs(dev);
- rtl8187b_init_status_urb(dev);
+ ret = rtl8187_init_urbs(dev);
+ if (ret)
+ goto rtl8187_start_exit;
+ ret = rtl8187b_init_status_urb(dev);
+ if (ret)
+ usb_kill_anchored_urbs(&priv->anchored);
goto rtl8187_start_exit;
}
@@ -966,7 +969,9 @@ static int rtl8187_start(struct ieee80211_hw *dev)
rtl818x_iowrite32(priv, &priv->map->MAR[0], ~0);
rtl818x_iowrite32(priv, &priv->map->MAR[1], ~0);
- rtl8187_init_urbs(dev);
+ ret = rtl8187_init_urbs(dev);
+ if (ret)
+ goto rtl8187_start_exit;
reg = RTL818X_RX_CONF_ONLYERLPKT |
RTL818X_RX_CONF_RX_AUTORESETPHY |
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH 09/12] wlcore: fix regulatory domain bit translation
From: Luca Coelho @ 2013-09-10 19:41 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEdmkxNyK2i1DZXwKqnxZtXGhT3VVizc9iBQ+zTK-YJFPA@mail.gmail.com>
On Tue, 2013-09-10 at 16:51 +0200, Eliad Peller wrote:
> On Tue, Sep 10, 2013 at 10:39 AM, Luca Coelho <luca@coelho.fi> wrote:
> > On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> >> From: Ido Reis <idor@ti.com>
> >>
> >> This is a fix for channels 52,56,60,64 bit translation.
> >>
> >> Reported-by: Yaniv Machani <yanivma@ti.com>
> >> Signed-off-by: Ido Reis <idor@ti.com>
> >> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> >> Signed-off-by: Eliad Peller <eliad@wizery.com>
> >> ---
> >> drivers/net/wireless/ti/wlcore/cmd.c | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/wireless/ti/wlcore/cmd.c b/drivers/net/wireless/ti/wlcore/cmd.c
> >> index e3ae425..1cb3296 100644
> >> --- a/drivers/net/wireless/ti/wlcore/cmd.c
> >> +++ b/drivers/net/wireless/ti/wlcore/cmd.c
> >> @@ -1613,8 +1613,10 @@ static int wlcore_get_reg_conf_ch_idx(enum ieee80211_band band, u16 ch)
> >> case IEEE80211_BAND_5GHZ:
> >> if (ch >= 8 && ch <= 16)
> >> idx = ((ch-8)/4 + 18);
> >> - else if (ch >= 34 && ch <= 64)
> >> + else if (ch >= 34 && ch <= 48)
> >> idx = ((ch-34)/2 + 3 + 18);
> >> + else if (ch >= 52 && ch <= 64)
> >> + idx = ((ch-52)/4 + 11 + 18);
> >> else if (ch >= 100 && ch <= 140)
> >> idx = ((ch-100)/4 + 15 + 18);
> >> else if (ch >= 149 && ch <= 165)
> >
> > Hmmm... I don't have a clue what is going on here. I don't know how I
> > let this function pass as is originally, shame on me. :)
> >
> :)
>
> > The change probably makes things work better, since someone apparently
> > saw a bug in real life and reported it, but can anyone explain what is
> > going on during this translation? Aren't we losing data here? Eg.
> > channels 8, 9, 10 and 11 all use the same bit in the firmware command
> > bitmask?
> >
> the 8-16 indeed looks weird, as the driver indeed declares supports
> for channels 7,8,9,11...
Yes, weird, because channel 7 would return an error even. And 9 and 11
would use 8...
> the other conditions are a simple attempt to reduce the gap between
> the channels (e.g. no channels between 64 and 100) in order to get a
> minimized bitmap.
Right, I should have looked into the channel list we advertise.
> since the gap between the defined channels in the 5ghz band is usually
> 2/4 (36->38 vs. 60->64) the other calculations seems fine (i didn't
> dig into them as well, though).
Yes, now that you mentioned it looks clearer, but still, this function
sucks big time. If it takes more than a couple of minutes to understand
what is going on (in such a simple thing as this is), it should be
rewritten. Or at _least_ better documented.
> i'll try getting some more information from the fw guys regarding the
> 8-16 range.
Great! Thanks.
--
Luca.
^ permalink raw reply
* Re: [PATCH 06/12] wlcore: send EAPOL frames with voice priority
From: Luca Coelho @ 2013-09-10 19:26 UTC (permalink / raw)
To: Eliad Peller; +Cc: Arik Nemtsov, linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEfPQb1FWT3wukBZvSkP9eB1kO=wPpWFxKXBmX5YULAVqw@mail.gmail.com>
On Tue, 2013-09-10 at 16:15 +0200, Eliad Peller wrote:
> On Tue, Sep 10, 2013 at 12:15 PM, Luca Coelho <luca@coelho.fi> wrote:
> > On Tue, 2013-09-10 at 11:11 +0200, Arik Nemtsov wrote:
> >> On Tue, Sep 10, 2013 at 9:47 AM, Luca Coelho <luca@coelho.fi> wrote:
> >> > On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> >> >> From: Igal Chernobelsky <igalc@ti.com>
> >> >>
> >> >> Send EAPOL frames with voice priority by setting TX_HW_ATTR_EAPOL_FRAME
> >> >> new bit in tx attribute. Sending EAPOL with voice priority fixes
> >> >> re-key timeout during heavy traffic issue.
> >> >>
> >> >> Signed-off-by: Igal Chernobelsky <igalc@ti.com>
> >> >> Signed-off-by: Eliad Peller <eliad@wizery.com>
> >> >> ---
> >> >
> >> > This seems to be the same problem that Ben had and debugged by himself
> >> > [1]. Fixing this in hostapd/wpa_supplicant seems more appropriate?
> >> >
> >> > This patch seems to take an advantage of some sort of hack in the
> >> > firmware that will change the priority by itself when the
> >> > TX_HW_ATTR_EAPOL_GRAME bit is set. If we have a good reason to use this
> >> > patch, we need to take care of the firmware version as well. This
> >> > probably doesn't work with the latest published firmware.
> >> >
> >> > [1] http://mid.gmane.org/522E18E5.1020503@candelatech.com
> >>
> >> I believe he only fixed one mode (AP - hostapd) but not the other (GO
> >> - wpa_supplicant). Anyway that's what we tested at the time.
> >
> > Okay, I didn't dig much into it.
> >
> >
> >> Anyway marking it as this level doesn't do any harm. You're right
> >> about the FW version though - it should be upstreamed first.
> >
> > Fair enough. If the firmware implements this, no reason why not use it.
> > But I'll wait for the new firmware before applying this.
> >
> this change is backward compatible, so there's no issue applying it as is.
> however, if you prefer waiting for a newer fw that's fine too.
> i'll add it to the waiting list :)
Okay, indeed it's probably backwards compatible because that bit was not
used before. But I still prefer if you put this in the waiting list,
because otherwise it seems the issue is solved (if you look at the git
log) when it is not really fixed until a new firmware version is
available.
--
Luca.
^ permalink raw reply
* Re: [PATCH 03/12] wlcore: disable elp sleep while in plt mode
From: Luca Coelho @ 2013-09-10 19:24 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEdNkEAsC8mz_jpz8UmjnK_pBwfGSChZQLGiuhtd0Q9Wnw@mail.gmail.com>
On Tue, 2013-09-10 at 16:04 +0200, Eliad Peller wrote:
> On Tue, Sep 10, 2013 at 9:34 AM, Luca Coelho <luca@coelho.fi> wrote:
> > On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
> >> From: Yair Shapira <yair.shapira@ti.com>
> >>
> >> We now disable elp sleep during plt mode to allow normal operation of
> >> plt tools such as calibrator.
> >>
> >> Having elp_sleep enabled during plt mode is actually not required and
> >> in fact it disrupt plt operations such as rx statistics etc.
> >>
> >> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
> >> Signed-off-by: Eliad Peller <eliad@wizery.com>
> >> ---
> >
> > I also had a comment internally about this one. Why do we need this?
> > AFAICT this would never happen in real life, since the firmware is not
> > even loaded at this point. Is there any real life situation where we
> > try to go into ELP while in PLT mode?
> >
> i'm not familiar with the whole plt process, but i guess some flows
> might indeed end up in elp (e.g. via wl1271_cmd_interrogate(), in
> order to read statistics)
Well, I don't think this would ever happen. The PLT stuff is a
completely different firmware and, really, if it tries to go into ELP
mode it is a bug.
In any case, there probably is a bug somewhere if this was implemented
at all. And applying it won't really hurt. I'm just nagging because it
would be nice to know what caused this to become necessary.
--
Luca.
^ permalink raw reply
* Re: [PATCH 02/12] wlcore: add new plt power-mode: CHIP_AWAKE
From: Luca Coelho @ 2013-09-10 19:16 UTC (permalink / raw)
To: Eliad Peller; +Cc: Arik Nemtsov, linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEd=n5=pG9=Rvj6P6RHygqYyoqh3rGa3ntQf9f=obK03Sg@mail.gmail.com>
On Tue, 2013-09-10 at 15:46 +0200, Eliad Peller wrote:
> On Tue, Sep 10, 2013 at 9:56 AM, Luca Coelho <luca@coelho.fi> wrote:
> > On Tue, 2013-09-10 at 08:47 +0200, Arik Nemtsov wrote:
> >> On Tue, Sep 10, 2013 at 9:33 AM, Luca Coelho <luca@coelho.fi> wrote:
> >> > On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
> >> >> From: Yair Shapira <yair.shapira@ti.com>
> >> >>
> >> >> Under this mode the chip is powered on including sdio
> >> >> but no FW is downloaded and run, interrupts are not enabled, etc...
> >> >>
> >> >> This mode is intended to allow RTTT to bridge sdio as a transport
> >> >> to the chip.
> >> >>
> >> >> Driver only provides sdio access using the dev_mem debugfs file.
> >> >>
> >> >> Some fixes done to the code that ensures that PLT mode and normal
> >> >> driver power mode (ifconfig/add_interface) are mutually excluded.
> >> >>
> >> >> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
> >> >> Signed-off-by: Eliad Peller <eliad@wizery.com>
> >> >> ---
> >> >
> >> > I had some comments to this patch internally while I was still at TI.
> >> > Namely, I asked why do we need a new way of doing this if this is
> >> > already possible via debugsfs (using the gpio_power file)?
> >>
> >> Are you commenting on the correct patch? Seems this is just a patch to
> >> prevent "ifconfig up" during PLT mode..
> >
> > Yes, I'm commenting on the right patch. It allows the chip power
> > (namely the WLAN_EN GPIO pin) to be set directly, without loading the
> > firmware and doing other initialization stuff. This can already be
> > controlled via the gpio_power debugfs file. I've used that a bunch of
> > times, including with the RTTT tool.
> >
> > Okay, this patch has a few more protections (eg. not allowing an
> > interface to be added while the chip is powered in this way), but this
> > could also be added on top of the existing implementation.
> >
> i guess this just a bit "cleaner" (similar to the way PLT is used).
> the gpio_power debugfs only toggles the gpio power, without changing
> the driver mode, so adding similar protections will be more
> complicated.
Maybe, but the truth is that you don't need to add these protections,
unless you really want to shoot your own foot and start mangling with
the interfaces. These tools are usually used in very controlled
environments (like RF R&D and production testing).
Still, this is okay, but it's just bad to see things being done in two
different ways. I guess whoever requested this "new feature" didn't
know about the gpio toggling debugfs file.
--
Luca.
^ permalink raw reply
* Re: regulatory will stuck when cfg80211 is built-in
From: Kalle Valo @ 2013-09-10 17:59 UTC (permalink / raw)
To: Eugene Krasnikov; +Cc: linux-wireless
In-Reply-To: <CAFSJ42b_jOJA7ABK7GqDi0KO-Nnv-8CvhMC6ysTicPhe00kS=w@mail.gmail.com>
Eugene Krasnikov <k.eugene.e@gmail.com> writes:
> No, the flag CONFIG_CFG80211_INTERNAL_REGDB does not help and it should not.
>
> The problem is that cfg80211 will stuck in situation when cfg80211 is
> initialized before user space. One way to get cfg80211 out of this
> state is to run crda once right after user space is up and running.
> But again is this intentional? Or it is more like a workaround?
With the internal regdb you do not need crda anymore, so why does it still
get stuck? Where does it exactly get stuck?
--
Kalle Valo
^ permalink raw reply
* Re: RTL8187SE staging Linux driver
From: Larry Finger @ 2013-09-10 17:35 UTC (permalink / raw)
To: andrea.merello
Cc: wlanfae, shwei, John Linville, linux-kernel, Greg Kroah-Hartman,
linux-wireless, Michael Wu, Bernhard Schiffner
In-Reply-To: <CAN8YU5NTKUtS8+YzmcOSM3=YUX-FSwLTD86F_hXsNdVkw5NEGA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]
On 09/10/2013 10:59 AM, Andrea Merello wrote:
> Hello,
>
> As you probably know, in the current Linux kernel there is a staging
> driver for the RTL8187SE device (based on my older RTL8180/RTL8185
> Linux driver), while there also a regular (not staging) driver
> supporting older RTL8185 and RTL8180 devices
> (net/wireless/rtl818x/rtl8180) .
>
> As far as I can see, the RTL8187SE device seems not so much different
> from an RTL8185 device.
> I would like to try (in my spare time) to add support for RTL8187SE
> device in the current RTL818x driver, in order to avoid code
> duplication, remove a driver from staging, and make RTL8187SE using
> mac80211.
>
> Do any one of you have any comment/objection/suggestions about this ?
>
> Is it possible to get the RTL8187SE documentation to make things easier?
>
> For now I will probably keep different RF code for the two cards even
> if the RTL8225 (zebra 2) radio is used by both RTL8187SE and some
> RTL8185 devices, however if I could get enough documentation about it,
> it would be great to try to merge also RF code..
I too would be very happy for you to do this. At one point, I was trying to do
this and I had a version that very nearly worked. The driver was receiving data
and transmitting short packets but failing on longer ones. Length 42 was OK, but
68 failed. At that point, the chip locked up and needed to be power cycled. It
seems that I got the DMA wrong, but I could never find it, and eventually, I had
to move on.
At the moment, I am working at getting it to build on the current kernel. When I
finish that, I will send the code to you. Even if you decide to scrap it, it may
help you a little.
Attached is the datasheet, which is the only documentation I have.
Larry
[-- Attachment #2: RTL8187SE_DataSheet_1.0.pdf --]
[-- Type: application/pdf, Size: 718269 bytes --]
^ permalink raw reply
* Re: RTL8187SE staging Linux driver
From: John W. Linville @ 2013-09-10 16:56 UTC (permalink / raw)
To: Andrea Merello
Cc: wlanfae, shwei, linux-kernel, Greg Kroah-Hartman, linux-wireless,
Michael Wu
In-Reply-To: <CAN8YU5NTKUtS8+YzmcOSM3=YUX-FSwLTD86F_hXsNdVkw5NEGA@mail.gmail.com>
On Tue, Sep 10, 2013 at 05:59:54PM +0200, Andrea Merello wrote:
> Hello,
>
> As you probably know, in the current Linux kernel there is a staging
> driver for the RTL8187SE device (based on my older RTL8180/RTL8185
> Linux driver), while there also a regular (not staging) driver
> supporting older RTL8185 and RTL8180 devices
> (net/wireless/rtl818x/rtl8180) .
>
> As far as I can see, the RTL8187SE device seems not so much different
> from an RTL8185 device.
> I would like to try (in my spare time) to add support for RTL8187SE
> device in the current RTL818x driver, in order to avoid code
> duplication, remove a driver from staging, and make RTL8187SE using
> mac80211.
>
> Do any one of you have any comment/objection/suggestions about this ?
I would be extremely happy for you to tackle this.
> Is it possible to get the RTL8187SE documentation to make things easier?
This info used to be readily available. If you can't find a source, I
probably still have a (mildly useful) datasheet somewhere in my heap...
> For now I will probably keep different RF code for the two cards even
> if the RTL8225 (zebra 2) radio is used by both RTL8187SE and some
> RTL8185 devices, however if I could get enough documentation about it,
> it would be great to try to merge also RF code..
>
> Thank you,
> Andrea
Seems reasonable...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: regulatory will stuck when cfg80211 is built-in
From: Eugene Krasnikov @ 2013-09-10 16:23 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87ppshu5mr.fsf@purkki.adurom.net>
No, the flag CONFIG_CFG80211_INTERNAL_REGDB does not help and it should not.
The problem is that cfg80211 will stuck in situation when cfg80211 is
initialized before user space. One way to get cfg80211 out of this
state is to run crda once right after user space is up and running.
But again is this intentional? Or it is more like a workaround?
2013/9/9 Kalle Valo <kvalo@adurom.com>:
> Eugene Krasnikov <k.eugene.e@gmail.com> writes:
>
>> There is a problem with regulatory part of cfg80211 when cfg80211 is
>> built-in the kernel. On regulatory init cfg80211 will try to notify
>> user space about changing current domain to world regulatory but at
>> that time user space is not up and running yet and uevent message will
>> be lost. So what will happen is that cfg80211 will wait for the
>> response from user space and all requests to set current regulatory
>> will be dropped with the following error: “Pending regulatory request,
>> waiting for it to be processed...”.
>
> Does CONFIG_CFG80211_INTERNAL_REGDB help?
>
> --
> Kalle Valo
--
Best regards,
Eugene
^ permalink raw reply
* RTL8187SE staging Linux driver
From: Andrea Merello @ 2013-09-10 15:59 UTC (permalink / raw)
To: wlanfae, shwei
Cc: John Linville, linux-kernel, Greg Kroah-Hartman, linux-wireless,
Michael Wu
Hello,
As you probably know, in the current Linux kernel there is a staging
driver for the RTL8187SE device (based on my older RTL8180/RTL8185
Linux driver), while there also a regular (not staging) driver
supporting older RTL8185 and RTL8180 devices
(net/wireless/rtl818x/rtl8180) .
As far as I can see, the RTL8187SE device seems not so much different
from an RTL8185 device.
I would like to try (in my spare time) to add support for RTL8187SE
device in the current RTL818x driver, in order to avoid code
duplication, remove a driver from staging, and make RTL8187SE using
mac80211.
Do any one of you have any comment/objection/suggestions about this ?
Is it possible to get the RTL8187SE documentation to make things easier?
For now I will probably keep different RF code for the two cards even
if the RTL8225 (zebra 2) radio is used by both RTL8187SE and some
RTL8185 devices, however if I could get enough documentation about it,
it would be great to try to merge also RF code..
Thank you,
Andrea
^ permalink raw reply
* Re: Always send management frames at MCS-0??
From: Ben Greear @ 2013-09-10 15:48 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: linux-wireless@vger.kernel.org, hostap@lists.shmoo.com
In-Reply-To: <21038.54250.912310.332354@gargle.gargle.HOWL>
On 09/10/2013 01:10 AM, Sujith Manoharan wrote:
> Ben Greear wrote:
>> I had a user request that we support always sending management frames
>> (such as EAPOL) at the lowest rate. Evidently, other equipment does this,
>> where as normal-ish supplicant/linux tends to send them at much higher
>> rates.
>>
>> Any suggestions on how to go about doing this properly?
>
> If this is with ath9k_rate_control, then it is a known bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=927191
I'm not using ath9k rate control in this case, and at least most messages
get through fine. We didn't actually see any obvious improvement when forcing
everything to 6Mbps, but since my user was asking, I wanted to run the
idea past the list.
Rate control is not perfect, and on initial bringup it doesn't have
many packets to work with so I thought it might still be useful to allow
users to specify a particular rate for EAPOL packets. Maybe using
a socket ioctl so user-space (ie, supplicant/hostapd) can control it,
for example.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 06/12] wlcore: send EAPOL frames with voice priority
From: Ben Greear @ 2013-09-10 15:31 UTC (permalink / raw)
To: Eliad Peller; +Cc: Luca Coelho, Arik Nemtsov, linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEfPQb1FWT3wukBZvSkP9eB1kO=wPpWFxKXBmX5YULAVqw@mail.gmail.com>
On 09/10/2013 07:15 AM, Eliad Peller wrote:
> On Tue, Sep 10, 2013 at 12:15 PM, Luca Coelho <luca@coelho.fi> wrote:
>> On Tue, 2013-09-10 at 11:11 +0200, Arik Nemtsov wrote:
>>> On Tue, Sep 10, 2013 at 9:47 AM, Luca Coelho <luca@coelho.fi> wrote:
>>>> On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
>>>>> From: Igal Chernobelsky <igalc@ti.com>
>>>>>
>>>>> Send EAPOL frames with voice priority by setting TX_HW_ATTR_EAPOL_FRAME
>>>>> new bit in tx attribute. Sending EAPOL with voice priority fixes
>>>>> re-key timeout during heavy traffic issue.
>>>>>
>>>>> Signed-off-by: Igal Chernobelsky <igalc@ti.com>
>>>>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>>>>> ---
>>>>
>>>> This seems to be the same problem that Ben had and debugged by himself
>>>> [1]. Fixing this in hostapd/wpa_supplicant seems more appropriate?
I just posted hostapd/supplicant patches yesterday that fix it for both
AP mode and for station mode (at least in my configuration using ath9k
and 3.11 kernel).
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Larry Finger @ 2013-09-10 15:14 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522EB51A.2080004@ilande.co.uk>
On 09/10/2013 12:58 AM, Mark Cave-Ayland wrote:
>
> No worries - disk space is reasonably cheap these days ;)
>
> dmesg output:
> http://www.ilande.co.uk/tmp/rtl8192cu_patch-4-dmesg.txt
>
> wpa_supplicant output:
> http://www.ilande.co.uk/tmp/rtl8192cu_patch-4-wpa_supplicant.txt
>
> I noticed that I got several re-authentication attempts in the dmesg output
> without the corresponding rtl_watchdog_wq_callback() line being emitted - this
> is again something I don't see with zd1211rw and iwlwifi. Once these drivers are
> associated, they seem to stay in that state for hours.
Those disconnects do happen for reasons that I do not understand. They will be
worse on your system without a network manager as it appears that you need to
manually reconnect at that point, or at least it took a long time for the system
to react. With NetworkManager, that reconnect is automatic, and relatively quick.
> Whilst checking various parts of my kernel, I noticed for the first time during
> testing that my current kernel configuration doesn't have SMP enabled. This got
> me thinking that perhaps there are other build options which could have an
> effect on the driver. Hence I also uploaded a copy of my .config file to
> http://www.ilande.co.uk/tmp/rtl8192cu-config in the hope that maybe this can
> help you recreate the issue locally?
As I have a dual-core CPU, thus I always have SMP set. That should not be a
problem. In fact, the concurrent operation of 2 CPUs usually causes more
problems. I will review that configuration.
You can now disable the logging. When the watchdog reports that contact with the
AP has been lost, that is certainly true, and the watchdog is doing its job. In
addition, nothing was received from any AP, which leads me to conclude that the
receiver has locked up for some reason. I need to check to see what the code
does to recover. Perhaps that will help me understand the problem. In my current
run that has run for 20 hours, I have had two disconnects for Reason 3, but more
importantly, I have had two watchdog restarts. It does happen on my system, just
a lot less frequently. BTW, my ping loss rate is about 3%. That is too high, but
not as bad as yours.
Larry
^ permalink raw reply
* [PATCH] mac80211: add explicit IBSS driver operations
From: Johannes Berg @ 2013-09-10 14:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
This can be useful for drivers if they have any failure cases
when joining an IBSS. Also move setting the queue parameters
to before this new call, in case the new driver op needs them
already.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/mac80211.h | 7 +++++++
net/mac80211/driver-ops.h | 27 +++++++++++++++++++++++++++
net/mac80211/ibss.c | 22 ++++++++++++++++++++--
net/mac80211/trace.h | 35 +++++++++++++++++++++++++++++++++++
4 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 9bf07ef..2e8e817 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2671,6 +2671,10 @@ enum ieee80211_roc_type {
* zero using ieee80211_csa_is_complete() after the beacon has been
* transmitted and then call ieee80211_csa_finish().
*
+ * @join_ibss: Join an IBSS (on an IBSS interface); this is called after all
+ * information in bss_conf is set up and the beacon can be retrieved. A
+ * channel context is bound before this is called.
+ * @leave_ibss: Leave the IBSS again.
*/
struct ieee80211_ops {
void (*tx)(struct ieee80211_hw *hw,
@@ -2862,6 +2866,9 @@ struct ieee80211_ops {
void (*channel_switch_beacon)(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct cfg80211_chan_def *chandef);
+
+ int (*join_ibss)(struct ieee80211_hw *hw, struct ieee80211_vif *vif);
+ void (*leave_ibss)(struct ieee80211_hw *hw, struct ieee80211_vif *vif);
};
/**
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index b3ea11f..5d03c47 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -1085,4 +1085,31 @@ drv_channel_switch_beacon(struct ieee80211_sub_if_data *sdata,
}
}
+static inline int drv_join_ibss(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata)
+{
+ int ret = 0;
+
+ might_sleep();
+ check_sdata_in_driver(sdata);
+
+ trace_drv_join_ibss(local, sdata, &sdata->vif.bss_conf);
+ if (local->ops->join_ibss)
+ ret = local->ops->join_ibss(&local->hw, &sdata->vif);
+ trace_drv_return_int(local, ret);
+ return ret;
+}
+
+static inline void drv_leave_ibss(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata)
+{
+ might_sleep();
+ check_sdata_in_driver(sdata);
+
+ trace_drv_leave_ibss(local, sdata);
+ if (local->ops->leave_ibss)
+ local->ops->leave_ibss(&local->hw, &sdata->vif);
+ trace_drv_return_void(local);
+}
+
#endif /* __MAC80211_DRIVER_OPS */
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 5ea9b3a..21a0b88 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -229,6 +229,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
struct beacon_data *presp;
enum nl80211_bss_scan_width scan_width;
bool have_higher_than_11mbit;
+ int err;
sdata_assert_lock(sdata);
@@ -247,6 +248,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
ieee80211_bss_info_change_notify(sdata,
BSS_CHANGED_IBSS |
BSS_CHANGED_BEACON_ENABLED);
+ drv_leave_ibss(local, sdata);
}
presp = rcu_dereference_protected(ifibss->presp,
@@ -329,11 +331,26 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
else
sdata->flags &= ~IEEE80211_SDATA_OPERATING_GMODE;
+ ieee80211_set_wmm_default(sdata, true);
+
sdata->vif.bss_conf.ibss_joined = true;
sdata->vif.bss_conf.ibss_creator = creator;
- ieee80211_bss_info_change_notify(sdata, bss_change);
- ieee80211_set_wmm_default(sdata, true);
+ err = drv_join_ibss(local, sdata);
+ if (err) {
+ sdata->vif.bss_conf.ibss_joined = false;
+ sdata->vif.bss_conf.ibss_creator = false;
+ sdata->vif.bss_conf.enable_beacon = false;
+ sdata->vif.bss_conf.ssid_len = 0;
+ RCU_INIT_POINTER(ifibss->presp, NULL);
+ kfree_rcu(presp, rcu_head);
+ ieee80211_vif_release_channel(sdata);
+ sdata_info(sdata, "Failed to join IBSS, driver failure: %d\n",
+ err);
+ return;
+ }
+
+ ieee80211_bss_info_change_notify(sdata, bss_change);
ifibss->state = IEEE80211_IBSS_MLME_JOINED;
mod_timer(&ifibss->timer,
@@ -761,6 +778,7 @@ static void ieee80211_ibss_disconnect(struct ieee80211_sub_if_data *sdata)
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED |
BSS_CHANGED_IBSS);
+ drv_leave_ibss(local, sdata);
ieee80211_vif_release_channel(sdata);
}
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index 1aba645..5d62c58 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -1475,6 +1475,41 @@ DEFINE_EVENT(local_sdata_evt, drv_ipv6_addr_change,
);
#endif
+TRACE_EVENT(drv_join_ibss,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_bss_conf *info),
+
+ TP_ARGS(local, sdata, info),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ __field(u8, dtimper)
+ __field(u16, bcnint)
+ __dynamic_array(u8, ssid, info->ssid_len);
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ __entry->dtimper = info->dtim_period;
+ __entry->bcnint = info->beacon_int;
+ memcpy(__get_dynamic_array(ssid), info->ssid, info->ssid_len);
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT VIF_PR_FMT,
+ LOCAL_PR_ARG, VIF_PR_ARG
+ )
+);
+
+DEFINE_EVENT(local_sdata_evt, drv_leave_ibss,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata),
+ TP_ARGS(local, sdata)
+);
+
/*
* Tracing for API calls that drivers call.
*/
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH 09/12] wlcore: fix regulatory domain bit translation
From: Eliad Peller @ 2013-09-10 14:51 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1378798759.4799.57.camel@porter.coelho.fi>
On Tue, Sep 10, 2013 at 10:39 AM, Luca Coelho <luca@coelho.fi> wrote:
> On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
>> From: Ido Reis <idor@ti.com>
>>
>> This is a fix for channels 52,56,60,64 bit translation.
>>
>> Reported-by: Yaniv Machani <yanivma@ti.com>
>> Signed-off-by: Ido Reis <idor@ti.com>
>> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>> ---
>> drivers/net/wireless/ti/wlcore/cmd.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ti/wlcore/cmd.c b/drivers/net/wireless/ti/wlcore/cmd.c
>> index e3ae425..1cb3296 100644
>> --- a/drivers/net/wireless/ti/wlcore/cmd.c
>> +++ b/drivers/net/wireless/ti/wlcore/cmd.c
>> @@ -1613,8 +1613,10 @@ static int wlcore_get_reg_conf_ch_idx(enum ieee80211_band band, u16 ch)
>> case IEEE80211_BAND_5GHZ:
>> if (ch >= 8 && ch <= 16)
>> idx = ((ch-8)/4 + 18);
>> - else if (ch >= 34 && ch <= 64)
>> + else if (ch >= 34 && ch <= 48)
>> idx = ((ch-34)/2 + 3 + 18);
>> + else if (ch >= 52 && ch <= 64)
>> + idx = ((ch-52)/4 + 11 + 18);
>> else if (ch >= 100 && ch <= 140)
>> idx = ((ch-100)/4 + 15 + 18);
>> else if (ch >= 149 && ch <= 165)
>
> Hmmm... I don't have a clue what is going on here. I don't know how I
> let this function pass as is originally, shame on me. :)
>
:)
> The change probably makes things work better, since someone apparently
> saw a bug in real life and reported it, but can anyone explain what is
> going on during this translation? Aren't we losing data here? Eg.
> channels 8, 9, 10 and 11 all use the same bit in the firmware command
> bitmask?
>
the 8-16 indeed looks weird, as the driver indeed declares supports
for channels 7,8,9,11...
the other conditions are a simple attempt to reduce the gap between
the channels (e.g. no channels between 64 and 100) in order to get a
minimized bitmap.
since the gap between the defined channels in the 5ghz band is usually
2/4 (36->38 vs. 60->64) the other calculations seems fine (i didn't
dig into them as well, though).
i'll try getting some more information from the fw guys regarding the
8-16 range.
Eliad.
^ permalink raw reply
* Re: Always send management frames at MCS-0??
From: Dan Williams @ 2013-09-10 14:49 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Ben Greear, hostap@lists.shmoo.com,
linux-wireless@vger.kernel.org
In-Reply-To: <CABPxzYKcVyomdXaDxT3mLXQb0sYfM=UdoZwpbsb4qohTkPU3Cw@mail.gmail.com>
On Tue, 2013-09-10 at 14:47 +0530, Krishna Chaitanya wrote:
> On Tue, Sep 10, 2013 at 4:40 AM, Ben Greear <greearb@candelatech.com> wrote:
>
> > Would forcing them to a lower rate at least theoretically improve
> > the chance that the packets are properly delivered?
> Yes. But we already have a RC algorithm taking care of that.
> Right?
Except if there's periodic interference, like a microwave. In this
case, where the microwave cycles on and off, the longer it takes to
transmit the frame (ie, a lower rate) the *more* likely it is to get
partially squelched by the microwave turning on in its next cycle. Here
a faster rate can be more robust since it can transmit the entire frame
in between microwave cycles.
Dan
^ permalink raw reply
* Re: [PATCH 02/12] wireless: rtlwifi: remove unnecessary pci_set_drvdata()
From: Larry Finger @ 2013-09-10 14:34 UTC (permalink / raw)
To: Jingoo Han
Cc: 'John W. Linville', linux-wireless, 'Chaoming Li'
In-Reply-To: <00b301ceae17$7f417480$7dc45d80$%han@samsung.com>
On 09/10/2013 06:18 AM, Jingoo Han wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/net/wireless/rtlwifi/pci.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
> index 703f839..2b6d3e0 100644
> --- a/drivers/net/wireless/rtlwifi/pci.c
> +++ b/drivers/net/wireless/rtlwifi/pci.c
> @@ -2009,7 +2009,6 @@ fail2:
> fail1:
> if (hw)
> ieee80211_free_hw(hw);
> - pci_set_drvdata(pdev, NULL);
> pci_disable_device(pdev);
>
> return err;
> @@ -2064,8 +2063,6 @@ void rtl_pci_disconnect(struct pci_dev *pdev)
>
> rtl_pci_disable_aspm(hw);
>
> - pci_set_drvdata(pdev, NULL);
> -
> ieee80211_free_hw(hw);
> }
> EXPORT_SYMBOL(rtl_pci_disconnect);
>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH 1/7] ath10k: simplify HTC credits calculation
From: Bob Copeland @ 2013-09-10 14:14 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1378821003-22925-2-git-send-email-michal.kazior@tieto.com>
On Tue, Sep 10, 2013 at 03:49:57PM +0200, Michal Kazior wrote:
> + skb = __skb_dequeue(&ep->tx_queue);
> +
> + if (ep->tx_credit_flow_enabled) {
> + /* integer division w/ round-up */
> + credits = (skb->len + htc->target_credit_size - 1) /
> + htc->target_credit_size;
There's a macro for that...
credits = DIV_ROUND_UP(skb->len, htc->target_credit_size);
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH 06/12] wlcore: send EAPOL frames with voice priority
From: Eliad Peller @ 2013-09-10 14:15 UTC (permalink / raw)
To: Luca Coelho; +Cc: Arik Nemtsov, linux-wireless@vger.kernel.org
In-Reply-To: <1378804510.4799.69.camel@porter.coelho.fi>
On Tue, Sep 10, 2013 at 12:15 PM, Luca Coelho <luca@coelho.fi> wrote:
> On Tue, 2013-09-10 at 11:11 +0200, Arik Nemtsov wrote:
>> On Tue, Sep 10, 2013 at 9:47 AM, Luca Coelho <luca@coelho.fi> wrote:
>> > On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
>> >> From: Igal Chernobelsky <igalc@ti.com>
>> >>
>> >> Send EAPOL frames with voice priority by setting TX_HW_ATTR_EAPOL_FRAME
>> >> new bit in tx attribute. Sending EAPOL with voice priority fixes
>> >> re-key timeout during heavy traffic issue.
>> >>
>> >> Signed-off-by: Igal Chernobelsky <igalc@ti.com>
>> >> Signed-off-by: Eliad Peller <eliad@wizery.com>
>> >> ---
>> >
>> > This seems to be the same problem that Ben had and debugged by himself
>> > [1]. Fixing this in hostapd/wpa_supplicant seems more appropriate?
>> >
>> > This patch seems to take an advantage of some sort of hack in the
>> > firmware that will change the priority by itself when the
>> > TX_HW_ATTR_EAPOL_GRAME bit is set. If we have a good reason to use this
>> > patch, we need to take care of the firmware version as well. This
>> > probably doesn't work with the latest published firmware.
>> >
>> > [1] http://mid.gmane.org/522E18E5.1020503@candelatech.com
>>
>> I believe he only fixed one mode (AP - hostapd) but not the other (GO
>> - wpa_supplicant). Anyway that's what we tested at the time.
>
> Okay, I didn't dig much into it.
>
>
>> Anyway marking it as this level doesn't do any harm. You're right
>> about the FW version though - it should be upstreamed first.
>
> Fair enough. If the firmware implements this, no reason why not use it.
> But I'll wait for the new firmware before applying this.
>
this change is backward compatible, so there's no issue applying it as is.
however, if you prefer waiting for a newer fw that's fine too.
i'll add it to the waiting list :)
Eliad.
^ permalink raw reply
* Re: [PATCH 05/12] wl18xx: increase the number of allowed BA sessions
From: Eliad Peller @ 2013-09-10 14:11 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1378795155.4799.40.camel@porter.coelho.fi>
On Tue, Sep 10, 2013 at 9:39 AM, Luca Coelho <luca@coelho.fi> wrote:
> On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
>> From: Victor Goldenshtein <victorg@ti.com>
>>
>> The current fw (actually starting from fw 8.5.0.0.58)
>> supports 8 rx BA sessions.
>>
>> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>> ---
>
> The latest firmware version published at linux-firmware.git is
> 8.5.0.0.55 (wl18xx-fw-2.bin), so this patch cannot be taken into the
> official tree yet.
>
> Please publish a newer version of the firmware (with appropriate
> increase in the filename version), since I cannot do that myself
> anymore.
>
you're right.
i'll check with fw guys what fw should be upstreamed.
please drop this patch for now, and let's continue only with the other
patches (that don't require a new fw, afaict).
thanks,
Eliad.
^ permalink raw reply
* Re: [PATCH 03/12] wlcore: disable elp sleep while in plt mode
From: Eliad Peller @ 2013-09-10 14:04 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1378794898.4799.37.camel@porter.coelho.fi>
On Tue, Sep 10, 2013 at 9:34 AM, Luca Coelho <luca@coelho.fi> wrote:
> On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
>> From: Yair Shapira <yair.shapira@ti.com>
>>
>> We now disable elp sleep during plt mode to allow normal operation of
>> plt tools such as calibrator.
>>
>> Having elp_sleep enabled during plt mode is actually not required and
>> in fact it disrupt plt operations such as rx statistics etc.
>>
>> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>> ---
>
> I also had a comment internally about this one. Why do we need this?
> AFAICT this would never happen in real life, since the firmware is not
> even loaded at this point. Is there any real life situation where we
> try to go into ELP while in PLT mode?
>
i'm not familiar with the whole plt process, but i guess some flows
might indeed end up in elp (e.g. via wl1271_cmd_interrogate(), in
order to read statistics)
Eliad.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox