* (no subject)
From: Rajat Jain @ 2016-09-27 16:50 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless,
netdev
Cc: Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain, Rajat Jain
From: Wei-Ning Huang <wnhuang@google.com>
Date: Thu, 17 Mar 2016 11:43:16 +0800
Subject: [PATCH] mwifiex: report wakeup for wowlan
Enable notifying wakeup source to the PM core. This allow darkresume to
correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup
source.
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Signed-off-by: Rajat Jain <rajatja@google.com>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++
drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..a5f63e4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
disable_irq_nosync(irq);
}
+ /* Notify PM core we are wakeup source */
+ pm_wakeup_event(cfg->dev, 0);
+
return IRQ_HANDLED;
}
@@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
GFP_KERNEL);
cfg = card->plt_wake_cfg;
if (cfg && card->plt_of_node) {
+ cfg->dev = dev;
cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_wifi) {
dev_dbg(dev,
@@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
}
}
+ ret = device_init_wakeup(dev, true);
+ if (ret)
+ dev_err(dev, "fail to init wakeup for mwifiex");
+
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index db837f1..07cdd23 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -155,6 +155,7 @@
} while (0)
struct mwifiex_plt_wake_cfg {
+ struct device *dev;
int irq_wifi;
bool wake_by_wifi;
};
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH] mwifiex: report wakeup for wowlan
From: Rajat Jain @ 2016-09-27 16:56 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless,
netdev
Cc: Rajat Jain, Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain
Enable notifying wakeup source to the PM core. This allow darkresume to
correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup
source.
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Signed-off-by: Rajat Jain <rajatja@google.com>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++
drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..a5f63e4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
disable_irq_nosync(irq);
}
+ /* Notify PM core we are wakeup source */
+ pm_wakeup_event(cfg->dev, 0);
+
return IRQ_HANDLED;
}
@@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
GFP_KERNEL);
cfg = card->plt_wake_cfg;
if (cfg && card->plt_of_node) {
+ cfg->dev = dev;
cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_wifi) {
dev_dbg(dev,
@@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
}
}
+ ret = device_init_wakeup(dev, true);
+ if (ret)
+ dev_err(dev, "fail to init wakeup for mwifiex");
+
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index db837f1..07cdd23 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -155,6 +155,7 @@
} while (0)
struct mwifiex_plt_wake_cfg {
+ struct device *dev;
int irq_wifi;
bool wake_by_wifi;
};
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re:
From: Rajat Jain @ 2016-09-27 16:57 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless,
netdev
Cc: Wei-Ning Huang, Brian Norris, Eric Caruso, Rajat Jain, Rajat Jain
In-Reply-To: <1474995052-122337-1-git-send-email-rajatja@google.com>
Please ignore, not sure why this landed without a subject.
On Tue, Sep 27, 2016 at 9:50 AM, Rajat Jain <rajatja@google.com> wrote:
> From: Wei-Ning Huang <wnhuang@google.com>
>
> Date: Thu, 17 Mar 2016 11:43:16 +0800
> Subject: [PATCH] mwifiex: report wakeup for wowlan
>
> Enable notifying wakeup source to the PM core. This allow darkresume to
> correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup
> source.
>
> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
> ---
> drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++
> drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index d3e1561..a5f63e4 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
> disable_irq_nosync(irq);
> }
>
> + /* Notify PM core we are wakeup source */
> + pm_wakeup_event(cfg->dev, 0);
> +
> return IRQ_HANDLED;
> }
>
> @@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
> GFP_KERNEL);
> cfg = card->plt_wake_cfg;
> if (cfg && card->plt_of_node) {
> + cfg->dev = dev;
> cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
> if (!cfg->irq_wifi) {
> dev_dbg(dev,
> @@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
> }
> }
>
> + ret = device_init_wakeup(dev, true);
> + if (ret)
> + dev_err(dev, "fail to init wakeup for mwifiex");
> +
> return 0;
> }
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
> index db837f1..07cdd23 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.h
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
> @@ -155,6 +155,7 @@
> } while (0)
>
> struct mwifiex_plt_wake_cfg {
> + struct device *dev;
> int irq_wifi;
> bool wake_by_wifi;
> };
> --
> 2.8.0.rc3.226.g39d4020
>
^ permalink raw reply
* Re: rfkill guidance
From: Jonathan Richardson @ 2016-09-27 22:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1474961105.5141.5.camel@sipsolutions.net>
+linux-wireless
On 16-09-27 12:25 AM, Johannes Berg wrote:
> Hi,
>
> You should probably Cc the linux-wireless list, at least :)
>
> But anyway.
>
>> The driver enables/disables one or more regulators controlling a
>> bluetooth radio using the rfkill_ops set_block function. It's
>> different in that there is no bluetooth driver in the kernel - it's
>> controlled with some firmware that gets uploaded to a chip. The only
>> kernel usage is to power on/off the regulator(s).
>
> Interesting, don't you have to talk to the BT somehow? So the BT can't
> ever be used from the kernel?
Not from the kernel, a user space app interacts with the BT chip and
kernel. More below.
>
> Is rfkill really even the right concept here then? I mean, from the
> kernel's POV it doesn't even really have to know there's BT behind
> that, if there's no relation to BT in the kernel? Then again, the
> *user* might need to know?
> Would you be able to explain the overall system function of this a bit
> more?
Sure, I'll tell you what I can. A user space app handles interaction
between the kernel and BT radio. When the app is started, it enables the
regulator (via the rfkill driver and userspace sysfs interface) to power
up the BT chip. The app sends the firmware via a uart to the chip. The
chip loads the firmware then goes into a lower power mode. When the app
needs to talk to the chip it toggles a gpio (device wake) before sending
messages. If the kernel is in a low power mode and the BT chip receives
a message that requires handling by the app, then a host wake gpio is
driven to wake up the host (kernel).
In addition to the regulator(s) controlled by the rfkill driver I didn't
mention the two gpio's previously. The existing rfkill driver does
nothing with them. It just exports the global gpio # to sysfs which the
app can read to control via the gpio sysfs interface. These could be
hard coded in a startup script or something, they aren't that important
but it does handle the conversion to the global gpio# from 1 of 3 gpio
controllers on a Cygnus SOC. I'm not sure how to handle that, since the
gpio's vary across board variants.
I'm not sure rfkill is the right concept either but the app does use the
rfkill sysfs interface to control the regulators which in turn powers a
BT radio. The driver could not use the rfkill interface and provide its
own but would essentially be doing the same thing as rfkill-regulator.c.
>
>> The driver is basically a wrapper around controlling regulators.
>> There's already rfkill-regulator.c but it has no DT support and only
>> controls 1 regulator. I was considering modifying it until I saw this
>> thread where Mark objected and it looks like the submitter abandoned
>> the patchset (http://www.serverphorums.com/read.php?12,870025).
>
> I don't think that's a "killer" thread for this feature really. Yes,
> people have (quite possibly legitimate) concerns about that, but we
> should discuss that.
>
>> I couldn't see any way to enable/disable regulators from sysfs so it
>> looks like the regulator kernel API needs to be used from some
>> driver.
>
> Indeed, looks like Documentation/ABI/testing/sysfs-class-regulator is
> all read-only.
There's a regulator driver named userspace-consumer.c that allows
enable/disable from userspace, but it doesn't support DT either.
>
>> Do you think adding DT support and multiple regulators to the
>> existing driver is the best way to add support for this? Our driver
>> basically duplicates this and I don't think can be upstreamed the way
>> it is.
>
> Hard to say, really. Like I said, I'm not really _quite_ sure rfkill is
> even the right concept, since you're essentially toggling some
> hardware, but then again it *does* end up being a BT device.
Looking forward to more feedback. I see the options as either rfkill or
some regulator controller that allows enabling/disabling via sysfs.
>
> It also looks like nobody is actually using rfkill-regulator anywhere
> (in the upstream kernel), so we could just port that entirely to DT,
> which would be nice.
>
> johannes
>
Thanks,
Jon
^ permalink raw reply
* [PATCH] mwifiex: report wakeup for wowlan
From: Rajat Jain @ 2016-09-28 1:41 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless,
netdev
Cc: Rajat Jain, Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain
In-Reply-To: <1474995364-123069-1-git-send-email-rajatja@google.com>
Enable notifying wakeup source to the PM core. This allow darkresume to
correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup
source.
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Signed-off-by: Rajat Jain <rajatja@google.com>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++
drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..a5f63e4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
disable_irq_nosync(irq);
}
+ /* Notify PM core we are wakeup source */
+ pm_wakeup_event(cfg->dev, 0);
+
return IRQ_HANDLED;
}
@@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
GFP_KERNEL);
cfg = card->plt_wake_cfg;
if (cfg && card->plt_of_node) {
+ cfg->dev = dev;
cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_wifi) {
dev_dbg(dev,
@@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
}
}
+ ret = device_init_wakeup(dev, true);
+ if (ret)
+ dev_err(dev, "fail to init wakeup for mwifiex");
+
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index db837f1..07cdd23 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -155,6 +155,7 @@
} while (0)
struct mwifiex_plt_wake_cfg {
+ struct device *dev;
int irq_wifi;
bool wake_by_wifi;
};
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2] mwifiex: report wakeup for wowlan
From: Rajat Jain @ 2016-09-28 1:45 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless,
netdev
Cc: Rajat Jain, Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain
In-Reply-To: <1474995364-123069-1-git-send-email-rajatja@google.com>
Enable notifying wakeup source to the PM core in case of
a wake on wireless LAN event.
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Signed-off-by: Rajat Jain <rajatja@google.com>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
---
v2: Fix the commit log
drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++
drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..a5f63e4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
disable_irq_nosync(irq);
}
+ /* Notify PM core we are wakeup source */
+ pm_wakeup_event(cfg->dev, 0);
+
return IRQ_HANDLED;
}
@@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
GFP_KERNEL);
cfg = card->plt_wake_cfg;
if (cfg && card->plt_of_node) {
+ cfg->dev = dev;
cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_wifi) {
dev_dbg(dev,
@@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
}
}
+ ret = device_init_wakeup(dev, true);
+ if (ret)
+ dev_err(dev, "fail to init wakeup for mwifiex");
+
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index db837f1..07cdd23 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -155,6 +155,7 @@
} while (0)
struct mwifiex_plt_wake_cfg {
+ struct device *dev;
int irq_wifi;
bool wake_by_wifi;
};
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: rfkill guidance
From: Johannes Berg @ 2016-09-28 6:38 UTC (permalink / raw)
To: Jonathan Richardson
Cc: linux-wireless, devicetree, Marek Belisko, Mark Rutland
In-Reply-To: <0a8cff88-73aa-8311-7afe-98612161421f@broadcom.com>
Hi,
Mark, Marek, DT folks - the root of the discussion here is the old
rfkill-regulator device-tree support. I'm discussing some details of
the system here first, but below we get to the DT discussion.
The old thread is here:
http://thread.gmane.org/gmane.linux.kernel/1643236
> Sure, I'll tell you what I can. A user space app handles interaction
> between the kernel and BT radio. When the app is started, it enables
> the regulator (via the rfkill driver and userspace sysfs interface)
You should probably consider /dev/rfkill over the sysfs interface :)
> to power up the BT chip. The app sends the firmware via a uart to the
> chip. The chip loads the firmware then goes into a lower power mode.
> When the app needs to talk to the chip it toggles a gpio (device
> wake) before sending messages. If the kernel is in a low power mode
> and the BT chip receives a message that requires handling by the app,
> then a host wake gpio is driven to wake up the host (kernel).
So the reason then for having it all done in userspace is that there's
a UART to communicate with it? Or is the reason that you just don't
want the kernel abstraction? There *are* UART BT drivers in the kernel,
as far as I can tell, what's the difference? Or is it that there's just
a completely different protocol, vs. the HCI protocol used normally?
At this point I'm just curious though, doesn't seem all that important
to the discussion :)
Although having a DT binding for a kernel driver for the device that
includes the regulator might change the discussion somewhat?
> In addition to the regulator(s) controlled by the rfkill driver I
> didn't mention the two gpio's previously. The existing rfkill driver
> does nothing with them. It just exports the global gpio # to sysfs
> which the app can read to control via the gpio sysfs interface. These
> could be hard coded in a startup script or something, they aren't
> that important but it does handle the conversion to the global gpio#
> from 1 of 3 gpio controllers on a Cygnus SOC. I'm not sure how to
> handle that, since the gpio's vary across board variants.
Could also just be exposed in the DT, I guess? Userspace can read the
DT, no? Not sure that actually gives you all the dynamic information
though that might be needed if there's any kind of mapping going on.
> > Indeed, looks like Documentation/ABI/testing/sysfs-class-regulator
> > is all read-only.
>
> There's a regulator driver named userspace-consumer.c that allows
> enable/disable from userspace, but it doesn't support DT either.
Adding DT support there might make some sense, perhaps? Although that's
not really a useful DT binding at all since it won't provide any hints
as to how you'd use that, so ... maybe not so much.
As I read it, the main concern about or objection to the rfkill-
regulator DT binding was that it's not tied to a device, when it seems
that rfkill instances really should be living off a device that they
control. That's true for many, but not all devices.
Today we already have all the platform rfkill instances (like the
various ACPI ones) that don't live off a device that they control, but
instead control the platform's radio functionality. And in some cases,
that actually has very similar behaviour to what was proposed in the
previous patch, and what you're looking for, in that it sometimes kills
power to BT or WiFi chips when soft-disabled (or kicks them off the bus
in some other way). Particularly for the ones that call some random
ACPI function to deal with things, that can happen.
rfkill-regulator, with its platform driver today, more or less mirrors
that. You could even use that with a very simple (few lines of code)
platform module that just binds the regulators to rfkill-regulator, I
think.
Making this more flexible and configurable with DT would make sense to
me, less for the usage of rfkill-for-a-device (which could *also* be
done, but isn't what you need or what was discussed before), but more
for the usage of rfkill-for-the-platform.
Mark and DT folks - can you clarify your objections to the old patch?
Am I reading things correctly, and if so, what do you think about the
platform rfkill?
johannes
^ permalink raw reply
* Re: rfkill guidance
From: Johannes Berg @ 2016-09-28 6:49 UTC (permalink / raw)
To: Jonathan Richardson
Cc: linux-wireless, devicetree, Marek Belisko, Mark Rutland
In-Reply-To: <1475044682.4139.18.camel@sipsolutions.net>
> Today we already have all the platform rfkill instances (like the
> various ACPI ones) that don't live off a device that they control,
> but instead control the platform's radio functionality. And in some
> cases, that actually has very similar behaviour to what was proposed
> in the previous patch, and what you're looking for, in that it
> sometimes kills power to BT or WiFi chips when soft-disabled (or
> kicks them off the bus in some other way).
Actually, let me retract that a bit. Obviously they *do* control a
device or radio, but we don't actually know which one. And that can
actually become a problem, since we don't even know how they work etc.
So IOW, even with the ACPI stuff, there's no real "platform rfkill"
concept - it's always killing a specific radio.
There used to be some rfkill that was just reflecting the button state,
but I think we got rid of that in favour of reflecting button state
through hid/input, if it doesn't also control a radio.
So, actually, the more I think about it the more I agree with Mark's
objection. It doesn't really make sense to have a concept of an rfkill
and not know what radio it controls.
In your particular case, Jon, it's complicated by the fact that you
don't want to bind a kernel driver with the rfkill, not sure where
you'd get a device to tie the rfkill to then.
johannes
^ permalink raw reply
* Re: [-next] ath10k: fix error return code in ahb
From: Kalle Valo @ 2016-09-28 9:44 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Raja Mani, linux-wireless, Wei Yongjun, ath10k
In-Reply-To: <1474031135-6963-1-git-send-email-weiyj.lk@gmail.com>
Wei Yongjun <weiyj.lk@gmail.com> wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix to return a negative error code from the error handling case
> instead of 0, as done elsewhere in function ath10k_ahb_probe() or
> ath10k_ahb_resource_init().
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied to ath-next branch of ath.git, thanks.
931eb6b7fee3 ath10k: fix error return code in ahb
--
https://patchwork.kernel.org/patch/9335759/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Ignore SWBA event for a vif if its marked for no beacon
From: Kalle Valo @ 2016-09-28 9:48 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1474359727-6854-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> Ignore processing further in SWBA event scheduled for a vif, if mac80211
> has marked the particular vif for stop beaconing and brought the vdev
> down in 'ath10k_control_beaconing'. This should potentially avoid ath10k
> warning/error messages while running continuous wifi down/up with max
> number of vaps configured. Found this change during code walk through
> and going through other beacon configuration related functions in ath10k
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
b63b33ecafa5 ath10k: Ignore SWBA event for a vif if its marked for no beacon
--
https://patchwork.kernel.org/patch/9341147/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: fix copy engine 5 destination ring stuck
From: Kalle Valo @ 2016-09-28 9:48 UTC (permalink / raw)
To: Rajkumar Manoharan
Cc: ath10k, stable, linux-wireless, Rajkumar Manoharan, rmanohar
In-Reply-To: <20160921105806.23980-1-rmanohar@qti.qualcomm.com>
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
> Firmware is running watchdog timer for tracking copy engine ring index
> and write index. Whenever both indices are stuck at same location for
> given duration, watchdog will be trigger to assert target. While
> updating copy engine destination ring write index, driver ensures that
> write index will not be same as read index by finding delta between these
> two indices (CE_RING_DELTA).
>
> HTT target to host copy engine (CE5) is special case where ring buffers
> will be reused and delta check is not applied while updating write index.
> In rare scenario, whenever CE5 ring is full, both indices will be referring
> same location and this is causing CE ring stuck issue as explained
> above. This issue is originally reported on IPQ4019 during long hour stress
> testing and during veriwave max clients testsuites. The same issue is
> also observed in other chips as well. Fix this by ensuring that write
> index is one less than read index which means that full ring is
> available for receiving data.
>
> Cc: stable@vger.kernel.org
> Tested-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
0628467f97b5 ath10k: fix copy engine 5 destination ring stuck
--
https://patchwork.kernel.org/patch/9343317/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [2/2] ath9k: disable RNG by default
From: Kalle Valo @ 2016-09-28 10:00 UTC (permalink / raw)
To: miaoqing pan
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
In-Reply-To: <1470726147-30095-2-git-send-email-miaoqing@codeaurora.org>
miaoqing pan <miaoqing@codeaurora.org> wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
> Acked-by: Stephan Mueller <smueller@chronox.de>
> Acked-by: Stephan Mueller <smueller@chronox.de>
> Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Patch applied to ath-next branch of ath.git, thanks.
739ccd76b40e ath9k: disable RNG by default
--
https://patchwork.kernel.org/patch/9270467/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath6kl: fix return value in ath6kl_wmi_set_pvb_cmd
From: Kalle Valo @ 2016-09-28 10:01 UTC (permalink / raw)
To: Chaehyun Lim; +Cc: linux-wireless, netdev, Chaehyun Lim
In-Reply-To: <20160918063024.2535-1-chaehyun.lim@gmail.com>
Chaehyun Lim <chaehyun.lim@gmail.com> wrote:
> When building with W=1, we got one warning as belows:
> drivers/net/wireless/ath/ath6kl/wmi.c:3509:6: warning: variable ‘ret’
> set but not used [-Wunused-but-set-variable]
>
> At the end of ath6kl_wmi_set_pvb_cmd, it is returned by 0 regardless of
> return value of ath6kl_wmi_cmd_send.
> This patch fixes return value from 0 to ret that has result of
> ath6kl_wmi_cmd_send execution.
>
> Signed-off-by: Chaehyun Lim <chaehyun.lim@gmail.com>
Patch applied to ath-next branch of ath.git, thanks.
b93015057e31 ath6kl: fix return value in ath6kl_wmi_set_pvb_cmd
--
https://patchwork.kernel.org/patch/9337611/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: advertize hardware packet loss mechanism
From: Kalle Valo @ 2016-09-28 10:11 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: ath10k, linux-wireless, Rajkumar Manoharan, rmanohar
In-Reply-To: <20160906070841.4266-1-rmanohar@qti.qualcomm.com>
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
> Indicate hardware (or firmware) supports that CQM packet-loss report
> will be generated based on station kickout algorithm. As of now mac80211
> tracks connection loss by missing msdu counts (50) whereas ath10k
> firmware tracks them by missing ppdus (+ BAR tries). While firmware is
> trying to adapt its rate table, mac80211 might send out low_ack event to
> hostapd. This is causing frequent connect and disconnect iteration under
> noisy environment or when station is roaming around.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
(Note to myself in patchwork)
Depends on:
e8a24cd4b872 mac80211: allow driver to handle packet-loss mechanism
Is in net-next currently.
--
https://patchwork.kernel.org/patch/9315811/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: add support for controlling tx power to a station
From: Kalle Valo @ 2016-09-28 10:14 UTC (permalink / raw)
To: Ashok Raj Nagarajan; +Cc: ath10k, Ashok Raj Nagarajan, arnagara, linux-wireless
In-Reply-To: <1465925914-6404-1-git-send-email-arnagara@qti.qualcomm.com>
Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> wrote:
> This patch will add the support to control the transmit power for traffic
> to a station associated with the AP. Userspace provide the transmit power
> value in mBm units and the allowed range is from 0 to 70. Underlying FW
> will enforce that the maximum tx power will be based on the regulatory
> requirements. If the user given transmit power is greater than the allowed
> tx power in the given channel, then the FW will use the maximum tx power
> in the same channel.
>
> When 0 is sent to the FW as tx power, it will revert to the automatic tx
> power for the station.
>
> Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
No development on the dependency patches. I'm dropping this for now,
please resend once mac80211 patches are accepted.
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9176353/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: MAINTAINERS: hostap: Mark the Host AP driver obsolete
From: Kalle Valo @ 2016-09-28 10:27 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <20160927154258.GA6443@w1.fi>
Jouni Malinen <j@w1.fi> wrote:
> This is old code for old hardware and it is not really accurate to claim
> this to be maintained anymore. Change the status to "Obsolete" to make
> it clearer that minor cleanup and other unnecessary changes from
> automated tools is not necessarily beneficial and has larger risk of
> breaking something without being quickly noticed due to lack of testing.
>
> In addition, remove the old mailing list that does not work anymore and
> point the web-page to a more accurate URL.
>
> Signed-off-by: Jouni Malinen <j@w1.fi>
Patch applied to wireless-drivers-next.git, thanks.
ffd74aca44b7 MAINTAINERS: hostap: Mark the Host AP driver obsolete
--
https://patchwork.kernel.org/patch/9352117/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] rt2x00: add support for mac addr from device tree
From: Kalle Valo @ 2016-09-28 10:55 UTC (permalink / raw)
To: Mathias Kresin; +Cc: linux-wireless, devicetree
In-Reply-To: <CABwW5nn9gGpzBQq3ag1MhsA-bxGop93=C7mjZG9nmi26G4ar5A@mail.gmail.com>
Mathias Kresin <dev@kresin.me> writes:
> 2016-09-27 17:50 GMT+02:00 Kalle Valo <kvalo@codeaurora.org>:
>> Mathias Kresin <dev@kresin.me> wrote:
>>> On some devices the EEPROMs of Ralink Wi-Fi chips have a default Ralink
>>> MAC address set (RT3062F: 00:0C:43:30:62:00, RT3060F:
>>> 00:0C:43:30:60:00). Using multiple of these devices in the same network
>>> can cause nasty issues.
>>>
>>> Allow to override the MAC in the EEPROM with (a known good) one set in
>>> the device tree to bypass the issue.
>>>
>>> Signed-off-by: Mathias Kresin <dev@kresin.me>
>>> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
>>
>> I think this needs to update the devicetree binding document. Also
>> remember to CC the devicetree mailing list.
>>
>> Patch set to Changes Requested.
>>
>> --
>> https://patchwork.kernel.org/patch/9300893/
>
> Hey Kalle,
>
> was it intentional not to CC the linux-wireless list?
No, that was a bug in my script. Thanks for noticing it! Please always
report back if my script does something strange.
I'm adding now linux-wireless back.
> I thought about _adding_ a devicetree binding document before sending
> the patch. But in the end it would be an empty file, since I neither
> add any bindings nor introduce a compatible string. I'm just add
> support for the generic of_get_mac_address() devicetree property,
> which is meant to be used via a devicetree pci childnode.
>
> I grepped though the 4.7 code and found a few driver using
> of_get_mac_address() without having a devicetree binding document:
>
> - drivers/net/usb/smsc95xx.c
> - drivers/net/usb/smsc75xx.c
> - drivers/net/ethernet/marvell/sky2.c
> - drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> - drivers/net/ethernet/wiznet/w5100-spi.c
> - drivers/net/ethernet/arc/emac_main.c
>
> Just let me know if you are still the opinion that a devicetree
> binding document is required to get this patch accepted.
I'm not familiar enough device tree to really comment. Can someone from
the device tree list (CCed) help?
Full patch here:
https://patchwork.kernel.org/patch/9300893/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v8] cfg80211: Provision to allow the support for different beacon intervals
From: Johannes Berg @ 2016-09-28 11:21 UTC (permalink / raw)
To: Undekari, Sunil Dutt, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Hullur Subramanyam, Amarnath
In-Reply-To: <0b626d7836be4cce8ea4868538fe66d3@aphydexm01f.ap.qualcomm.com>
Hi,
> In PATCH v8 , cfg80211_validate_beacon_int ->
> cfg80211_iter_combinations carries the argument iftype_num , which
> also considers the "new interface" that is getting added.
Ah, right, I remember now, sorry.
> Thus , in the example you have quoted above , the iftype_num shall
> represent 2 ( AP + AP ) , and thus the min_gcd obtained out of
> cfg80211_iter_combinations (cfg80211_get_beacon_int_min_gcd) shall be
> 50 for the example 1 and 200 for the example 2 .
> Thus , considering the two examples mentioned above , the second AP
> should succeed for "example 1" vs failure for "example 2" with patch
> V8 , isn't ?
Yeah, I tried to simplify and did so too much. I believe you are, for
this purpose, ignoring for example radar detection.
Since you're passing 0 for num_different_channels and radar_detect, you
might find a combination isn't actually currently usable, but that
allows the new beacon interval configuration.
So I think overall this will only work right if it's done with all
necessary information, no?
Trying to construct another example ... let's say permitted
combinations are
* go = 3, channels = 1, min_bcn_gcd = 50
* go = 3, channels = 2, min_bcn_gcd = 100
(which isn't actually all that far-fetched, since channel hopping takes
time)
For simplification, say you already have two GOs active on different
channels (with BI 100), and want to add another one - with beacon
interval 50 - this isn't possible, but I don't think your code would
detect it?
Or, perhaps I'm reading this wrong, if your code *does* detect it then
changing the scenario a bit to have just a single channel, your code
would prevent it even though it's allowed?
> The current behavior of the kernel is to not allow the configuration
> of different beacon intervals and our expectation is that this new
> patch should be backward compatible with the existing behavior.
Correct, and I agree, we shouldn't break that.
> Now , if we go with this approach of "introducing a new argument to
> cfg80211_iter_combinations which shall be the GCD of all the existing
> combinations to check against the respective
> "diff_beacon_int_gcd_min"" , consider the case ( same one which is
> mentioned above ) that we have a single AP interface ( beacon
> interval = 300 ) , and a new AP is getting added ( beacon interval =
> 150 ), with the following allowed combinations:
>
> 1) * ap = 2
> diff_beacon_int_gcd_min = 0 ( rather not specified )
> 2) * ap = 2
> diff_beacon_int_gcd_min = 100
>
> The GCD calculated is 150 . cfg80211_iter_combinations shall return
> success for both the scenarios ( 1 and 2 ) (The intention here is to
> compare with only the nonzero " diff_beacon_int_gcd_min" )
>
> This success from "cfg80211_iter_combinations" does not represent if
> the GCD passed is compared against a 0 / non zero
> "diff_beacon_int_gcd_min" , isn't ?
>
> Thus , we are trying to solve this problem , by getting the
> "diff_beacon_int_gcd_min" for the respective interface combination ,
> before comparing it with the calculated GCD.
Oh. I think I finally understand your concern - good point!
Let me see if I understand correctly - you're saying that if I first
calculate
g = GCD(all BIs, including the new one)
and then do
cfg80211_iter_combinations(... existing variables ..., g)
then I cannot accurately determine whether or not I can use a
combination that doesn't specify a min_beacon_interval_gcd, you can't
know if the "all BIs" were the same, or not.
That's actually a very good point.
However, it seems pretty easy to solve by passing another bool that
indicates "all the same"?
johannes
^ permalink raw reply
* [PATCH 1/8] mwifiex: prevent register accesses after host is sleeping
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
Following is mwifiex driver-firmware host sleep handshake.
It involves three threads. suspend handler, interrupt handler, interrupt
processing in main work queue.
1) Enter suspend handler
2) Download HS_CFG command
3) Response from firmware for HS_CFG
4) Suspend thread waits until handshake completes(i.e hs_activate becomes
true)
5) SLEEP from firmware
6) SLEEP confirm downloaded to firmware.
7) SLEEP confirm response from firmware
8) Driver processes SLEEP confirm response and set hs_activate to wake up
suspend thread
9) Exit suspend handler
10) Read sleep cookie in loop and wait until it indicates firmware is
sleep.
11) After processing SLEEP confirm response, we are at the end of interrupt
processing routine. Recheck if there are interrupts received while we were
processing them.
During suspend-resume stress test, it's been observed that we may end up
acessing PCIe hardware(in 10 and 11) when PCIe bus is closed which leads
to a kernel crash.
This patch solves the problem with below changes.
a) action 10 above can be done before 8
b) Skip 11 if hs_activated is true. SLEEP confirm response
is the last interrupt from firmware. No need to recheck for
pending interrupts.
c) Add flush_workqueue() in suspend handler.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 3c3c4f1..2833d47 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -118,6 +118,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
adapter = card->adapter;
hs_actived = mwifiex_enable_hs(adapter);
+ flush_workqueue(adapter->workqueue);
/* Indicate device suspended */
adapter->is_suspended = true;
@@ -1669,9 +1670,6 @@ static int mwifiex_pcie_process_cmd_complete(struct mwifiex_adapter *adapter)
if (!adapter->curr_cmd) {
if (adapter->ps_state == PS_STATE_SLEEP_CFM) {
- mwifiex_process_sleep_confirm_resp(adapter, skb->data,
- skb->len);
- mwifiex_pcie_enable_host_int(adapter);
if (mwifiex_write_reg(adapter,
PCIE_CPU_INT_EVENT,
CPU_INTR_SLEEP_CFM_DONE)) {
@@ -1684,6 +1682,9 @@ static int mwifiex_pcie_process_cmd_complete(struct mwifiex_adapter *adapter)
while (reg->sleep_cookie && (count++ < 10) &&
mwifiex_pcie_ok_to_access_hw(adapter))
usleep_range(50, 60);
+ mwifiex_pcie_enable_host_int(adapter);
+ mwifiex_process_sleep_confirm_resp(adapter, skb->data,
+ skb->len);
} else {
mwifiex_dbg(adapter, ERROR,
"There is no command but got cmdrsp\n");
@@ -2322,6 +2323,8 @@ static int mwifiex_process_pcie_int(struct mwifiex_adapter *adapter)
ret = mwifiex_pcie_process_cmd_complete(adapter);
if (ret)
return ret;
+ if (adapter->hs_activated)
+ return ret;
}
if (card->msi_enable) {
--
1.9.1
^ permalink raw reply related
* [PATCH 2/8] mwifiex: report error to PCIe for suspend failure
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
When host_sleep_config command fails, we should return an error to
PCIe, instead of continuing (and possibly panicking, when we try to keep
processing a timed-out ioctl after we return "successfully" from
suspend).
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 2833d47..063c707 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -101,7 +101,6 @@ static int mwifiex_pcie_suspend(struct device *dev)
{
struct mwifiex_adapter *adapter;
struct pcie_service_card *card;
- int hs_actived;
struct pci_dev *pdev = to_pci_dev(dev);
if (pdev) {
@@ -117,7 +116,14 @@ static int mwifiex_pcie_suspend(struct device *dev)
adapter = card->adapter;
- hs_actived = mwifiex_enable_hs(adapter);
+ /* Enable the Host Sleep */
+ if (!mwifiex_enable_hs(adapter)) {
+ mwifiex_dbg(adapter, ERROR,
+ "cmd: failed to suspend\n");
+ adapter->hs_enabling = false;
+ return -EFAULT;
+ }
+
flush_workqueue(adapter->workqueue);
/* Indicate device suspended */
--
1.9.1
^ permalink raw reply related
* [PATCH 3/8] mwifiex: Fix NULL pointer dereference in skb_dequeue()
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
At couple of places in cleanup path, we are just going through the
skb queue and freeing them without unlinking. This leads to a crash
when other thread tries to do skb_dequeue() and use already freed node.
The problem is freed by unlinking skb before freeing it.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 +++-
drivers/net/wireless/marvell/mwifiex/wmm.c | 12 +++++++++---
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 39ce76a..e83861f 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3070,8 +3070,10 @@ int mwifiex_del_virtual_intf(struct wiphy *wiphy, struct wireless_dev *wdev)
mwifiex_stop_net_dev_queue(priv->netdev, adapter);
- skb_queue_walk_safe(&priv->bypass_txq, skb, tmp)
+ skb_queue_walk_safe(&priv->bypass_txq, skb, tmp) {
+ skb_unlink(skb, &priv->bypass_txq);
mwifiex_write_data_complete(priv->adapter, skb, 0, -1);
+ }
if (netif_carrier_ok(priv->netdev))
netif_carrier_off(priv->netdev);
diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 0eb2465..dea2fe6 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -503,8 +503,10 @@ mwifiex_wmm_del_pkts_in_ralist_node(struct mwifiex_private *priv,
struct mwifiex_adapter *adapter = priv->adapter;
struct sk_buff *skb, *tmp;
- skb_queue_walk_safe(&ra_list->skb_head, skb, tmp)
+ skb_queue_walk_safe(&ra_list->skb_head, skb, tmp) {
+ skb_unlink(skb, &ra_list->skb_head);
mwifiex_write_data_complete(adapter, skb, 0, -1);
+ }
}
/*
@@ -600,11 +602,15 @@ mwifiex_clean_txrx(struct mwifiex_private *priv)
priv->adapter->if_ops.clean_pcie_ring(priv->adapter);
spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock, flags);
- skb_queue_walk_safe(&priv->tdls_txq, skb, tmp)
+ skb_queue_walk_safe(&priv->tdls_txq, skb, tmp) {
+ skb_unlink(skb, &priv->tdls_txq);
mwifiex_write_data_complete(priv->adapter, skb, 0, -1);
+ }
- skb_queue_walk_safe(&priv->bypass_txq, skb, tmp)
+ skb_queue_walk_safe(&priv->bypass_txq, skb, tmp) {
+ skb_unlink(skb, &priv->bypass_txq);
mwifiex_write_data_complete(priv->adapter, skb, 0, -1);
+ }
atomic_set(&priv->adapter->bypass_tx_pending, 0);
idr_for_each(&priv->ack_status_frames, mwifiex_free_ack_frame, NULL);
--
1.9.1
^ permalink raw reply related
* [PATCH 4/8] mwifiex: vendor_ie length check for parse WMM IEs
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Karthik D A, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
From: Karthik D A <karthida@marvell.com>
While copying the vendor_ie obtained from the cfg80211_find_vendor_ie()
to the struct mwifiex_types_wmm_info, length/size was inappropriate.
This patch corrects the required length needed to the
mwifiex_types_wmm_info
Signed-off-by: Karthik D A <karthida@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
index a7e9f54..35d8636 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
@@ -404,7 +404,7 @@ mwifiex_set_wmm_params(struct mwifiex_private *priv,
struct cfg80211_ap_settings *params)
{
const u8 *vendor_ie;
- struct ieee_types_header *wmm_ie;
+ const u8 *wmm_ie;
u8 wmm_oui[] = {0x00, 0x50, 0xf2, 0x02};
vendor_ie = cfg80211_find_vendor_ie(WLAN_OUI_MICROSOFT,
@@ -412,9 +412,9 @@ mwifiex_set_wmm_params(struct mwifiex_private *priv,
params->beacon.tail,
params->beacon.tail_len);
if (vendor_ie) {
- wmm_ie = (struct ieee_types_header *)vendor_ie;
- memcpy(&bss_cfg->wmm_info, wmm_ie + 1,
- sizeof(bss_cfg->wmm_info));
+ wmm_ie = vendor_ie;
+ memcpy(&bss_cfg->wmm_info, wmm_ie +
+ sizeof(struct ieee_types_header), *(wmm_ie + 1));
priv->wmm_enabled = 1;
} else {
memset(&bss_cfg->wmm_info, 0, sizeof(bss_cfg->wmm_info));
--
1.9.1
^ permalink raw reply related
* [PATCH 5/8] mwifiex: add memrw command information in README
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
Support for this debugfs command is available in driver. This patch
adds usage information in README file.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/README | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/README b/drivers/net/wireless/marvell/mwifiex/README
index 24e649b..588fcbe 100644
--- a/drivers/net/wireless/marvell/mwifiex/README
+++ b/drivers/net/wireless/marvell/mwifiex/README
@@ -180,6 +180,29 @@ regrdwr
echo "1 0xa060 0x12" > regrdwr : Write the MAC register
echo "1 0xa794 0x80000000" > regrdwr
: Write 0x80000000 to MAC register
+
+memrw
+ This command is used to read/write the firmware memory.
+
+ Usage:
+ 1) For reading firmware memory location.
+ echo r <address> 0 > /sys/kernel/debug/mwifiex/mlan0/memrw
+ cat /sys/kernel/debug/mwifiex/mlan0/memrw
+ 2) For writing value to firmware memory location.
+ echo w <address> [value] > /sys/kernel/debug/mwifiex/mlan0/memrw
+
+ where the parameters are,
+ <address>: memory address
+ [value]: value to be written
+
+ Examples:
+ echo r 0x4cf70 0 > /sys/kernel/debug/mwifiex/mlan0/memrw
+ cat /sys/kernel/debug/mwifiex/mlan0/memrw
+ : Read memory address 0x4cf70
+ iwpriv mlan0 memrdwr -0x7fff6000 -0x40000000
+ echo w 0x8000a000 0xc0000000 > /sys/kernel/debug/mwifiex/mlan0/memrw
+ : Write 0xc0000000 to memory address 0x8000a000
+
rdeeprom
This command is used to read the EEPROM contents of the card.
--
1.9.1
^ permalink raw reply related
* [PATCH 6/8] mwifiex: update tx_pkts_queued for requeued packets
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
wmm.tx_pkts_queued and ralist's total_pkt_count should be updated in
synchronization. They were not correctly updated in
mwifiex_send_processed_packet().
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/wmm.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index dea2fe6..1ff3a87 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -1334,9 +1334,11 @@ mwifiex_send_processed_packet(struct mwifiex_private *priv,
skb = skb_dequeue(&ptr->skb_head);
if (adapter->data_sent || adapter->tx_lock_flag) {
+ ptr->total_pkt_count--;
spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock,
ra_list_flags);
skb_queue_tail(&adapter->tx_data_q, skb);
+ atomic_dec(&priv->wmm.tx_pkts_queued);
atomic_inc(&adapter->tx_queued);
return;
}
@@ -1394,6 +1396,10 @@ mwifiex_send_processed_packet(struct mwifiex_private *priv,
if (ret != -EBUSY) {
mwifiex_rotate_priolists(priv, ptr, ptr_index);
atomic_dec(&priv->wmm.tx_pkts_queued);
+ spin_lock_irqsave(&priv->wmm.ra_list_spinlock, ra_list_flags);
+ ptr->total_pkt_count--;
+ spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock,
+ ra_list_flags);
}
}
--
1.9.1
^ permalink raw reply related
* [PATCH 7/8] mwifiex: fix command timeout problem seen in stress tests
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
It is observed that if single tid 6 packet comes among with massive tid 0
packets, tid 6 packet may stay in it's queue and will never be
transmited. This is because wmm.highest_queued_prio will be set to 2
during transmission of tid 0 packets As a result, main work thread
keeps on looping without serving that packet. In this case, if command
has downloaded to firmware, driver doesn't process it's response causing
command timeout.
This patch will reset highest_queued_prio if packets exist in data
queue, and try to find a ra_list for current private.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/main.h | 1 +
drivers/net/wireless/marvell/mwifiex/wmm.c | 13 ++++++++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 26df28f..d61fe3a 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -315,6 +315,7 @@ struct mwifiex_tid_tbl {
#define WMM_HIGHEST_PRIORITY 7
#define HIGH_PRIO_TID 7
#define LOW_PRIO_TID 0
+#define NO_PKT_PRIO_TID -1
#define MWIFIEX_WMM_DRV_DELAY_MAX 510
struct mwifiex_wmm_desc {
diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 1ff3a87..28c2f6f 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -1105,6 +1105,7 @@ mwifiex_wmm_get_highest_priolist_ptr(struct mwifiex_adapter *adapter,
&adapter->bss_prio_tbl[j].bss_prio_head,
list) {
+try_again:
priv_tmp = adapter->bss_prio_tbl[j].bss_prio_cur->priv;
if (((priv_tmp->bss_mode != NL80211_IFTYPE_ADHOC) &&
@@ -1140,8 +1141,18 @@ mwifiex_wmm_get_highest_priolist_ptr(struct mwifiex_adapter *adapter,
ra_list_spinlock,
flags_ra);
}
- }
+ if (atomic_read(&priv_tmp->wmm.tx_pkts_queued) != 0) {
+ atomic_set(&priv_tmp->wmm.highest_queued_prio,
+ HIGH_PRIO_TID);
+ /* Iterate current private once more, since
+ * there still exist packets in data queue
+ */
+ goto try_again;
+ } else
+ atomic_set(&priv_tmp->wmm.highest_queued_prio,
+ NO_PKT_PRIO_TID);
+ }
}
return NULL;
--
1.9.1
^ 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