* 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: [-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: 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: 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
* [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
* [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
* 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
* 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
* [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
* (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
* [ANNOUNCE] Netdev 1.2 updates (27th September, 2016)
From: Hajime Tazaki @ 2016-09-27 16:18 UTC (permalink / raw)
To: netdev, netfilter-devel, linux-wireless, netdev-conference, lwn
Hello folks,
The Linux netdev 1.2 conference will start on next week and
I hope everyone is ready to join us.
== program ==
The full list of accepted sessions (keynotes, workshops,
talks, bofs) are available at the following page.
http://netdevconf.org/1.2/accepted-sessions.html
We will have a great series of the talks; thank you for
your contributions for the great conference.
We're heavily working on finalizing the program; we will
announce it very soon on the web page. Stay tuned.
== travel information ==
You might be the first time to visit Tokyo/Japan (or even
Asian countries). Several trip tips (transportation, venue
access, etc) are listed in our web page; please check it
out before your trip.
http://netdevconf.org/1.2/travel.html
== mailing list ==
We have received a couple of requests to prepare one-time
mailing list only for the netdev 1.2 attendees. We will
prepare the list asap; please freely use the list to
chat/discuss/communicate among the conference attendees.
== sponsors ==
We have finally a great list of our sponsors. Without such
a huge support, the conference never makes it happen. Many
many thanks !
- Platinum
Verizon, Facebook, Cumulus Networks
- Gold
Mojatatu Networks, VMWare, Google, NTT, LinkedIn, Cisco
- Silver
NetApp, IIJ, Netronome, SolarFlare, Mellanox, Sophos,
RedHat, Intel (new)
- Bronze
Zen Load Balancer
- Media sponsor
LWN.net
We're really looking forward to seeing you in Tokyo. We
hope you will have a safe and great trip.
-- Hajime
^ permalink raw reply
* [PATCH] hostap: Mark the Host AP driver obsolete
From: Jouni Malinen @ 2016-09-27 15:42 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
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>
---
MAINTAINERS | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index efd69c76..20de5f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5593,10 +5593,9 @@ F: Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
HOST AP DRIVER
M: Jouni Malinen <j@w1.fi>
-L: hostap@shmoo.com (subscribers-only)
L: linux-wireless@vger.kernel.org
-W: http://hostap.epitest.fi/
-S: Maintained
+W: http://w1.fi/hostap-driver.html
+S: Obsolete
F: drivers/net/wireless/intersil/hostap/
HP COMPAQ TC1100 TABLET WMI EXTRAS DRIVER
--
1.9.1
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply related
* Re: [V2, 4.9] brcmfmac: use correct skb freeing helper when deleting flowring
From: Kalle Valo @ 2016-09-27 15:48 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel,
Rafał Miłecki
In-Reply-To: <20160927121104.5771-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Flowrings contain skbs waiting for transmission that were passed to us
> by netif. It means we checked every one of them looking for 802.1x
> Ethernet type. When deleting flowring we have to use freeing function
> that will check for 802.1x type as well.
>
> Freeing skbs without a proper check was leading to counter not being
> properly decreased. This was triggering a WARNING every time
> brcmf_netdev_wait_pend8021x was called.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-by: Arend van Spriel <arend@broadcom.com>
> Cc: stable@vger.kernel.org # 4.5+
Patch applied to wireless-drivers-next.git, thanks.
7f00ee2bbc63 brcmfmac: use correct skb freeing helper when deleting flowring
--
https://patchwork.kernel.org/patch/9351797/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmfmac: replace WARNING on timeout with a simple error message
From: Kalle Valo @ 2016-09-27 15:47 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel,
Rafał Miłecki
In-Reply-To: <20160927101224.3534-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Even with timeout increased to 950 ms we get WARNINGs from time to time.
> It mostly happens on A-MPDU stalls (e.g. when station goes out of
> range). It may take up to 5-10 secods for the firmware to recover and
> for that time it doesn't process packets.
>
> It's still useful to have a message on time out as it may indicate some
> firmware problem and incorrect key update. Raising a WARNING however
> wasn't really that necessary, it doesn't point to any driver bug anymore
> and backtrace wasn't much useful.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
2f0e56fa37cc brcmfmac: replace WARNING on timeout with a simple error message
--
https://patchwork.kernel.org/patch/9351657/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] rtlwifi: Add HAL_DEF_WOWLAN case to *_get_hw() routines
From: Kalle Valo @ 2016-09-27 15:46 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Larry Finger
In-Reply-To: <1474736239-9826-2-git-send-email-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Only rtl8821ae implements WOWLAN; however, the other drivers may receive
> a call requesting information about this mode. The other drivers need to
> ignore the request rather than logging that the default branch of the
> switch statement has been reached.
>
> Reported by: Jean Delvare <jdelvare@suse.de>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
2 patches applied to wireless-drivers-next.git, thanks.
1cc49a5b5466 rtlwifi: Add HAL_DEF_WOWLAN case to *_get_hw() routines
8334ffdc8290 rtlwifi: Add explicit values to hw_variables enum
--
https://patchwork.kernel.org/patch/9349217/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: Add switch variable to 'switch case not processed' messages
From: Kalle Valo @ 2016-09-27 15:45 UTC (permalink / raw)
To: Joe Perches
Cc: Larry Finger, Jean Delvare, Chaoming Li, linux-wireless, netdev,
linux-kernel
In-Reply-To: <d091f73a6adf3bdaa09ab0399c22a9fdfe9b188c.1474654979.git.joe@perches.com>
Joe Perches <joe@perches.com> wrote:
> Help along debugging by showing what switch/case variable is not
> being processed in these messages.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Patch applied to wireless-drivers-next.git, thanks.
ad5748893b27 rtlwifi: Add switch variable to 'switch case not processed' messages
--
https://patchwork.kernel.org/patch/9348573/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2016-09-26
From: Kalle Valo @ 2016-09-27 15:36 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1474921450.8149.57.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Hi Kalle,
>
> One more small pull-request intended for 4.9. =C2=A0It seems that I'm
> actually catching up with our internal tree! :) Nothing major here,
> mostly clean-ups and small bug fixes and improvements.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit 0979a913f879ea39504200d83fb9f275a555a5=
8d:
>
> iwlwifi: pcie: use LIST_HEAD() macro (2016-09-19 11:29:35 +0300)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git =
tags/iwlwifi-next-for-kalle-2016-09-26
Pulled, thanks.
--=20
Kalle Valo
^ permalink raw reply
* RE: [PATCH v8] cfg80211: Provision to allow the support for different beacon intervals
From: Undekari, Sunil Dutt @ 2016-09-27 15:36 UTC (permalink / raw)
To: Johannes Berg, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Hullur Subramanyam, Amarnath
In-Reply-To: <1474981379.5141.37.camel@sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCj4+IDIuIFNpbmNlICJkaWZmX2JlYWNvbl9pbnRfZ2NkX21pbiLCoMKg
aXMgb25seSBzcGVjaWZpZWQgLyBhZHZlcnRpc2VkIGluIA0KPj4gdGhlIGludGVyZmFjZSBjb21i
aW5hdGlvbnMgLCBvdXIgbG9naWMgd2FzIHRvIGdldCB0aGUgbWluaW1hbCANCj4+ICJkaWZmX2Jl
YWNvbl9pbnRfZ2NkX21pbiIgb2YgYWxsIHRoZSBtYXRjaGluZyBjb21iaW5hdGlvbnMgYW5kIGxh
dGVyDQo+PiDCoMKgwqDCoGNvbXBhcmUgd2l0aCB0aGUgbmV3IGJlYWNvbiBpbnRlcnZhbC4gKEFQ
SSANCj4+ICJjZmc4MDIxMV9pdGVyX2NvbWJpbmF0aW9ucyIgaGFzIHRvIGJlIGludm9rZWQgdG8g
Z2V0IHRoZSANCj4+IGNvcnJlc3BvbmRpbmcgImRpZmZfYmVhY29uX2ludF9nY2RfbWluIikNCg0K
PlllYWgsIGJ1dCB5b3UgZ2V0IHRoZSBkaWZmX2JlYWNvbl9pbnRfZ2NkX21pbiBmb3IgYWxsIGNv
bWJpbmF0aW9ucyB0aGF0IGFsbG93IHRoZSAqY3VycmVudCogY29tYmluYXRpb24gb2YgaW50ZXJm
YWNlcywgbm90IHRoZSBjb21iaW5hdGlvbnMgdGhhdCBhbGxvdyB0aGUgbmV3ICpuZXcqIGNvbWJp
bmF0aW9uIG9mIGludGVyZmFjZXMsIG5vPw0KDQo+SSBtZWFuLCBjb25zaWRlciB0aGUgY2FzZSB0
aGF0IHlvdSBoYXZlIGEgc2luZ2xlIEFQIGludGVyZmFjZSwgd2l0aCBiZWFjb24gaW50ZXJ2YWwg
MzAwLCBhbmQgeW91J3JlIGFkZGluZyBhbm90aGVyIEFQLCB3aXRoIGJlYWNvbiBpbnRlcnZhbCAx
NTAsIGFuZCB0aGUgZm9sbG93aW5nIGFsbG93ZWQgY29tYmluYXRpb25zOg0KDQrCoD4qIGFwID0g
MQ0KwqA+wqBtZXNoID0gMQ0KwqA+IMKgZGlmZl9iZWFjb25faW50X2djZF9taW4gPSAxMDANCsKg
PiAqIGFwID0gMg0KPiDCoGRpZmZfYmVhY29uX2ludF9nY2RfbWluID0gNTANCg0KPiBXb3VsZG4n
dCB5b3UgcHJldmVudCB0aGF0LCBvciBzb21ldGhpbmc/DQoNCj4gT3Igc2F5IHlvdSBoYXZlDQoN
Cj7CoCogYXAgPSAxDQo+wqAgwqBtZXNoID0gMQ0KPsKgIMKgZGlmZl9iZWFjb25faW50X2djZF9t
aW4gPSAxMDANCj4gwqAqIGFwID3CoDINCj7CoCDCoGRpZmZfYmVhY29uX2ludF9nY2RfbWluID0g
MjAwDQoNCj4gUHJvYmFibHkgZG9lc24ndCByZWFsbHkgbWFrZSBzZW5zZSwgYnV0IG5vdyBpZiB5
b3UgaGF2ZSBhbiBleGlzdGluZyBBUCBpbnRlcmZhY2UsIHlvdSB3b3VsZCB0aGluayB0aGUgbWlu
IGlzIDEwMCwgd2hlbiByZWFsbHkgd2hpbGUgYWRkaW5nIGFub3RoZXIgQVAgaXQgc2hvdWxkIGJl
IDIwMC4NCg0KSW4gUEFUQ0ggdjggLCBjZmc4MDIxMV92YWxpZGF0ZV9iZWFjb25faW50IC0+IGNm
ZzgwMjExX2l0ZXJfY29tYmluYXRpb25zIGNhcnJpZXMgdGhlIGFyZ3VtZW50IGlmdHlwZV9udW0g
LCB3aGljaCBhbHNvIGNvbnNpZGVycyB0aGUgIm5ldyBpbnRlcmZhY2UiIHRoYXQgaXMgZ2V0dGlu
ZyBhZGRlZC4gDQpUaHVzICwgaW4gdGhlIGV4YW1wbGUgeW91IGhhdmUgcXVvdGVkIGFib3ZlICwg
dGhlIGlmdHlwZV9udW0gc2hhbGwgcmVwcmVzZW50IDIgKCBBUCArIEFQICkgLCBhbmQgdGh1cyB0
aGUgbWluX2djZCBvYnRhaW5lZCBvdXQgb2YgY2ZnODAyMTFfaXRlcl9jb21iaW5hdGlvbnMgKGNm
ZzgwMjExX2dldF9iZWFjb25faW50X21pbl9nY2QpIHNoYWxsIGJlIDUwIGZvciB0aGUgZXhhbXBs
ZSAxIGFuZCAyMDAgZm9yIHRoZSBleGFtcGxlIDIgLiANClRodXMgLCBjb25zaWRlcmluZyB0aGUg
dHdvIGV4YW1wbGVzIG1lbnRpb25lZCBhYm92ZSAsIHRoZSBzZWNvbmQgQVAgc2hvdWxkIHN1Y2Nl
ZWQgZm9yICJleGFtcGxlIDEiIHZzIGZhaWx1cmUgZm9yICJleGFtcGxlIDIiIHdpdGggcGF0Y2gg
VjggLCBpc24ndCA/ICANCg0KPj4gSWYgSSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5ICwgYXJl
IHlvdSBzYXlpbmcgdGhhdCB0aGlzIG5ldyBhcmd1bWVudCANCj4+IHRvIGNmZzgwMjExX2l0ZXJf
Y29tYmluYXRpb25zIHNoYWxsIGJlIHRoZSBHQ0Qgb2YgYWxsIHRoZSBleGlzdGluZyANCj4+IGJl
YWNvbiBpbnRlcnZhbHMgYW5kIHdvdWxkIGJlIHVzZWQgdG8gbWF0Y2ggd2l0aCB0aGUgY29ycmVz
cG9uZGluZyANCj4+ICJkaWZmX2JlYWNvbl9pbnRfZ2NkX21pbiIgb2YgdGhlIGludGVyZmFjZSBj
b21iaW5hdGlvbnMgaW4gDQo+PiAiY2ZnODAyMTFfaXRlcl9jb21iaW5hdGlvbnMiLg0KDQo+WWVz
LCB0aGF0J3Mgd2hhdCBJIHdhcyB0aGlua2luZy4NCg0KPj4gSWYgeWVzICwgdGhpcyBHQ0QgYXJn
dW1lbnQgZG9lcyBub3QgcmVwcmVzZW50ICwgaWYgdGhlIGJlYWNvbiANCj4+IGludGVydmFscyBv
ZiBhbGwgdGhlIGV4aXN0aW5nIGludGVyZmFjZXMgZGlmZmVyIG9yIG5vdCAsIGlzbuKAmXQgPyBJ
ZiANCj4+IHRoZSAiZGlmZl9iZWFjb25faW50X2djZF9taW4iwqDCoG9mIHRoZSBhbGwgdGhlIG1h
dGNoaW5nIGludGVyZmFjZSANCj4+IGNvbWJpbmF0aW9ucyBpcyAwICwgc3VjaCBkaWZmZXJlZCBi
ZWFjb24gaW50ZXJ2YWxzIHdvdWxkIHBhc3MgdGhlIA0KPj4gY2hlY2sgLCBjb250cmFkaWN0aW5n
IHRoZSBleGlzdGluZyBsb2dpYyAoIG5vdCBhbGxvd2luZyB0aGUgZGlmZmVyZWQgDQo+PiBiZWFj
b24gaW50ZXJ2YWxzKSwgaXNuJ3QgPw0KDQo+T2gsIHdlbGwsIG9rIC0gaWYgYWxsIGV4aXN0aW5n
IGFuZCBuZXcgYmVhY29uIGludGVydmFscyBhcmUgdGhlIHNhbWUgd2UnZCBoYXZlIHRvIGRvIHRo
ZSBsb29rdXAgd2l0aG91dCB0aGUgZXhpc3RpbmcgYmVhY29uIGludGVydmFsIEdDRCBhbmQgc3Rp
bGwgY29tcGFyZSB0byB0aGUgbWluIHNlcGFyYXRlbHkuDQoNCkxldCBtZSByZWl0ZXJhdGUgb3Vy
IHByb2JsZW0gaGVyZSB3aXRoIHRoaXMgYXBwcm9hY2guDQoNClRoZSBjdXJyZW50IGJlaGF2aW9y
IG9mIHRoZSBrZXJuZWwgaXMgdG8gbm90IGFsbG93IHRoZSBjb25maWd1cmF0aW9uIG9mIGRpZmZl
cmVudCBiZWFjb24gaW50ZXJ2YWxzIGFuZCBvdXIgZXhwZWN0YXRpb24gaXMgdGhhdCB0aGlzIG5l
dyBwYXRjaCBzaG91bGQgYmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIHRoZSBleGlzdGluZyBi
ZWhhdmlvci4NCk5vdyAsIGlmIHdlIGdvIHdpdGggdGhpcyBhcHByb2FjaCBvZiAiaW50cm9kdWNp
bmcgYSBuZXcgYXJndW1lbnQgdG8gY2ZnODAyMTFfaXRlcl9jb21iaW5hdGlvbnMgd2hpY2ggc2hh
bGwgYmUgdGhlIEdDRCBvZiBhbGwgdGhlIGV4aXN0aW5nIGNvbWJpbmF0aW9ucyB0byBjaGVjayBh
Z2FpbnN0IHRoZSByZXNwZWN0aXZlICJkaWZmX2JlYWNvbl9pbnRfZ2NkX21pbiIiICwgIGNvbnNp
ZGVyIHRoZSBjYXNlICggc2FtZSBvbmUgd2hpY2ggaXMgbWVudGlvbmVkIGFib3ZlICkgdGhhdCB3
ZSBoYXZlIGEgc2luZ2xlIEFQIGludGVyZmFjZSAoIGJlYWNvbiBpbnRlcnZhbCA9IDMwMCApICwg
YW5kIGEgbmV3IEFQIGlzIGdldHRpbmcgYWRkZWQgKCBiZWFjb24gaW50ZXJ2YWwgPSAxNTAgKSwg
IHdpdGggdGhlIGZvbGxvd2luZyBhbGxvd2VkIGNvbWJpbmF0aW9uczoNCg0KMSkgKiBhcCA9IDIN
CiAgICAgICAgZGlmZl9iZWFjb25faW50X2djZF9taW4gPSAwICggcmF0aGVyIG5vdCBzcGVjaWZp
ZWQgKSANCjIpICAqIGFwID0gMg0KICAgICAgZGlmZl9iZWFjb25faW50X2djZF9taW4gPSAxMDAN
Cg0KVGhlIEdDRCBjYWxjdWxhdGVkIGlzIDE1MCAuIGNmZzgwMjExX2l0ZXJfY29tYmluYXRpb25z
IHNoYWxsIHJldHVybiBzdWNjZXNzIGZvciBib3RoIHRoZSBzY2VuYXJpb3MgKCAxIGFuZCAyICkg
KFRoZSBpbnRlbnRpb24gaGVyZSBpcyB0byBjb21wYXJlIHdpdGggb25seSB0aGUgbm9uemVybyAi
IGRpZmZfYmVhY29uX2ludF9nY2RfbWluIiApDQoNClRoaXMgc3VjY2VzcyBmcm9tICJjZmc4MDIx
MV9pdGVyX2NvbWJpbmF0aW9ucyIgZG9lcyBub3QgcmVwcmVzZW50IGlmIHRoZSBHQ0QgcGFzc2Vk
IGlzIGNvbXBhcmVkIGFnYWluc3QgYSAwIC8gbm9uIHplcm8gImRpZmZfYmVhY29uX2ludF9nY2Rf
bWluIiAsIGlzbid0ID8NCg0KVGh1cyAsIHdlIGFyZSB0cnlpbmcgdG8gc29sdmUgdGhpcyBwcm9i
bGVtICwgYnkgZ2V0dGluZyB0aGUgImRpZmZfYmVhY29uX2ludF9nY2RfbWluIiBmb3IgdGhlIHJl
c3BlY3RpdmUgaW50ZXJmYWNlIGNvbWJpbmF0aW9uICwgYmVmb3JlIGNvbXBhcmluZyBpdCB3aXRo
IHRoZSBjYWxjdWxhdGVkIEdDRC4gDQoNClBsZWFzZSBjb3JyZWN0IHVzLg0KDQpSZWdhcmRzLA0K
U3VuaWwNCg0KIA0KDQo=
^ permalink raw reply
* Re: staging: wilc1000: kernel Oops while opening the device
From: Greg KH @ 2016-09-27 15:21 UTC (permalink / raw)
To: Aditya.Shankar; +Cc: Ganesh.Krishna, nicolas.ferre, linux-wireless, luisbg
In-Reply-To: <1FA4CE79C3B5BA4CB1930722261ABC02CAF99066@CHN-SV-EXMX03.mchp-main.com>
On Mon, Sep 26, 2016 at 05:17:37AM +0000, Aditya.Shankar@microchip.com wrote:
> On Friday 23 September 2016 08:37 PM, Greg KH wrote:
> > On Fri, Sep 23, 2016 at 01:17:08PM +0000, Aditya.Shankar@microchip.com wrote:
> >> On Thursday 22 September 2016 06:04 PM, Ganesh Krishna - I00112 wrote:
> >>>> -----Original Message-----
> >>>> From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org]
> >>>> Sent: Monday, September 19, 2016 7:12 PM
> >>>> To: Nicolas Ferre
> >>>> Cc: linux-wireless@vger.kernel.org; Aditya Shankar - I16078; Ganesh Krishna - I00112; luisbg@osg.samsung.com
> >>>> Subject: Re: staging: wilc1000: kernel Oops while opening the device
> >>>>
> >>>> On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> While using the wilc1000 driver with latest 4.8-rc7, I have
> >>>>> difficulties to open the device and actually use it as I have this
> >>>>> kernel Oops right after the loading of the firmware (wilc1003_firmware.bin).
> >>>>>
> >>>>> If I revert back the driver to its
> >>>>> b9811891a9f60ca9c314dcab3244c65930c4cf37 state, it works okay. I did
> >>>>> this because I tend to think that it might be related to the latest move on this driver to "completion" or "work queues".
> >>>>> It seems to be a regression from 4.7.
> >>>>
> >>>> Ick, not good at all.
> >>>>
> >>>> Any chance you can run 'git bisect' to see if you can find the offending patch?
> >>>>
> >>>> I thought the maintainers were testing this driver over time :(
> >>>
> >>>> thanks,
> >>>>
> >>>> greg k-h
> >>>
> >>> Ick indeed. Maintainers are on it full time. Thank you very much for the flag. While I am only reporting activity, hope to have results soon.
> >>> Regards,
> >>> ganesh k
> >>>
> >> Hi All,
> >>
> >> bisecting changes on the wilc1000 host driver, I find that this problem seems to occur after the below change.
> >> As of now, I only know the where and not the why. So I will continue to figure out why this happens.
> >>
> >> commit 2518ac59eb27ed003c5a97e8f9588adafdfe4a8a
> >> Author: Binoy Jayan <binoy.jayan@linaro.org>
> >> Date: Thu Jun 23 11:11:51 2016 +0530
> >>
> >> staging: wilc1000: Replace kthread with workqueue for host interface
> >>
> >> Deconstruct the kthread / message_queue logic, replacing it with
> >> create_singlethread_workqueue() / queue_work() setup, by adding a
> >> 'struct work_struct' to 'struct host_if_msg'. The current kthread
> >> hostIFthread() is converted to a work queue helper with the name
> >> 'host_if_work'.
> >
> > So if you revert this, it works?
> >
> > If so, let us know and I will gladly revert it, as breaking things is
> > not ok.
> >
> > thanks,
> >
> > greg k-h
> >
> Unfortunately no. We will have to revert this commit and the one submitted after this.
> The commit a5c84b2 after 2518ac5 is heavily reliant on its parent 2518ac5.
>
> Note that reverting 2518ac5 throws up a couple of minor merge conflicts which can be
> resolved by dropping changes in HEAD and retaining the parent commit of 2518ac5.
> With this, the crash is not seen anymore.
Can you send me a patch, or series of patches, that does all of this so
I know I get it correct?
thanks,
greg k-h
^ permalink raw reply
* Re: [v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Stephan Mueller @ 2016-09-27 15:17 UTC (permalink / raw)
To: Kalle Valo
Cc: Ted Tso, herbert, linux-kernel, linux-crypto, ath9k-devel,
linux-wireless, ath9k-devel, Kalle Valo, Jason Cooper
In-Reply-To: <2ba03f89daee4f09a88a1238943eb49d@euamsexm01a.eu.qualcomm.com>
Am Dienstag, 27. September 2016, 16:44:16 CEST schrieb Kalle Valo:
Hi Kalle,
> Stephan Mueller <smueller@chronox.de> wrote:
> > The ATH9K driver implements an RNG which is completely bypassing the
> > standard Linux HW generator logic.
> >
> > The RNG may or may not deliver entropy. Considering the conservative
> > approach in treating entropy with respect to non-auditable sources, this
> > patch changes the delivered entropy value to zero. The RNG still feeds
> > data into the input_pool but it is assumed to have no entropy.
> >
> > When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
> > the entropy estimation considering that a user can change that value at
> > boot and runtime.
> >
> > Reviewed-by: Jason Cooper <jason@lakedaemon.net>
> > Signed-off-by: Stephan Mueller <smueller@chronox.de>
>
> Based on the discussion I'm dropping this patch. But the discussion was
> hard to follow so please let me know if I misunderstood.
I guess the rejection is appropriate, but something needs to be done:
add_hwgenerator_randomness should not be used in this scenario.
>
> Patch set to Rejected.
Ciao
Stephan
^ permalink raw reply
* Re: wil6200
From: Lior David @ 2016-09-27 15:04 UTC (permalink / raw)
To: Vikram; +Cc: linux-wireless
In-Reply-To: <CALZLQ=anWS6ThxEOnifRcxgYyk3BvWwMUFqTtZdOMcqZYA+igA@mail.gmail.com>
On 9/26/2016 9:05 PM, Vikram wrote:
> Hi Lior,
>
> On 26 September 2016 at 18:19, Lior David <liord@codeaurora.org> wrote:
>> On 9/25/2016 6:15 PM, Vikram wrote:
>>> Hi,
>>>
>>> Could you please let me know as to how to change the mode of wil6200
>>> chip from WBE to WiFi?
>>>
>>> Regards,
>>> Vikram
>>>
>> What is the exact device you are using? Older devices have firmware that only
>> supports WBE mode.
>>
>> Thanks,
>> Lior
>
> I'm using Dell Wireless DW1601 7Gbps WiGig 802.11ad 802.11n 2*2 WiFi
> Half Mini Card abgn+ad 2*2:2
Unfortunately it looks like this is an old chip which does not support WIFI
mode. There are 2 main problems:
1. The chip has its firmware burned into flash and cannot be upgraded, unlike
newer chips where firmware can be loaded into memory (so wil6210 driver can use
the firmware file from /lib/firmware).
2. Based on the product description this card was specifically used to connect
to the Dell wireless dock which used WBE, so it has a firmware with only WBE
support.
Thanks,
Lior
>
> Regards,
> Vikram
>
^ permalink raw reply
* Re: [1/2] ath9k: change entropy formula for easier understanding
From: Kalle Valo @ 2016-09-27 14:53 UTC (permalink / raw)
To: miaoqing pan
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
In-Reply-To: <1470726147-30095-1-git-send-email-miaoqing@codeaurora.org>
miaoqing pan <miaoqing@codeaurora.org> wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> The quality of ADC entropy is 10 bits of min-entropy for
> a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
> '(((x) * 8 * 10) >> 5)' for easier understanding.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
I need some help here, it this patch ok to take or should I drop it? The
discussion is available from the patchwork link below if someone needs to
refresh the memory.
--
https://patchwork.kernel.org/patch/9270463/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Kalle Valo @ 2016-09-27 14:44 UTC (permalink / raw)
To: Stephan Mueller
Cc: Ted Tso, herbert, linux-kernel, linux-crypto, ath9k-devel,
linux-wireless, ath9k-devel, Kalle Valo, Jason Cooper
In-Reply-To: <1654172.XfclnXhRmn@positron.chronox.de>
Stephan Mueller <smueller@chronox.de> wrote:
> The ATH9K driver implements an RNG which is completely bypassing the
> standard Linux HW generator logic.
>
> The RNG may or may not deliver entropy. Considering the conservative
> approach in treating entropy with respect to non-auditable sources, this
> patch changes the delivered entropy value to zero. The RNG still feeds
> data into the input_pool but it is assumed to have no entropy.
>
> When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
> the entropy estimation considering that a user can change that value at
> boot and runtime.
>
> Reviewed-by: Jason Cooper <jason@lakedaemon.net>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
Based on the discussion I'm dropping this patch. But the discussion was
hard to follow so please let me know if I misunderstood.
Patch set to Rejected.
--
https://patchwork.kernel.org/patch/9266265/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v4] ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Shajakhan, Mohammed Shafi (Mohammed Shafi) @ 2016-09-27 13:04 UTC (permalink / raw)
To: ath10k@lists.infradead.org
Cc: mohammed@codeaurora.org, linux-wireless@vger.kernel.org
In-Reply-To: <1474981300-15945-1-git-send-email-mohammed@qca.qualcomm.com>
apologies please ignore this , wrong patch due to confusing v4 tag=0A=
=0A=
please review,=0A=
=0A=
[PATCH] ath10k: Cleanup calling ath10k_htt_rx_h_unchain=0A=
=0A=
________________________________________=0A=
From: Shajakhan, Mohammed Shafi (Mohammed Shafi)=0A=
Sent: 27 September 2016 18:31=0A=
To: ath10k@lists.infradead.org=0A=
Cc: mohammed@codeaurora.org; linux-wireless@vger.kernel.org; Shajakhan, Moh=
ammed Shafi (Mohammed Shafi)=0A=
Subject: [PATCH v4] ath10k: Cleanup calling ath10k_htt_rx_h_unchain=0A=
=0A=
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>=0A=
=0A=
'ath10k_htt_rx_h_unchain' is need to be called only if the return=0A=
value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this=0A=
change makes it more explicit and avoids doing a skb_peek, fetching=0A=
rx descriptor pointer, checking rx msdu decap format for the case of=0A=
ret =3D 0 (unchained msdus). Found this change during code walk through,=0A=
not sure if this addresses any issue.=0A=
=0A=
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>=0A=
---=0A=
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++------=0A=
1 file changed, 6 insertions(+), 6 deletions(-)=0A=
=0A=
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireles=
s/ath/ath10k/htt_rx.c=0A=
index 7ae9349..e51dace 100644=0A=
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c=0A=
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c=0A=
@@ -1459,8 +1459,7 @@ static int ath10k_unchain_msdu(struct sk_buff_head *a=
msdu)=0A=
}=0A=
=0A=
static void ath10k_htt_rx_h_unchain(struct ath10k *ar,=0A=
- struct sk_buff_head *amsdu,=0A=
- bool chained)=0A=
+ struct sk_buff_head *amsdu)=0A=
{=0A=
struct sk_buff *first;=0A=
struct htt_rx_desc *rxd;=0A=
@@ -1471,9 +1470,6 @@ static void ath10k_htt_rx_h_unchain(struct ath10k *ar=
,=0A=
decap =3D MS(__le32_to_cpu(rxd->msdu_start.common.info1),=0A=
RX_MSDU_START_INFO1_DECAP_FORMAT);=0A=
=0A=
- if (!chained)=0A=
- return;=0A=
-=0A=
/* FIXME: Current unchaining logic can only handle simple case of r=
aw=0A=
* msdu chaining. If decapping is other than raw the chaining may b=
e=0A=
* more complex and this isn't handled by the current code. Don't e=
ven=0A=
@@ -1550,7 +1546,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_=
htt *htt)=0A=
}=0A=
=0A=
ath10k_htt_rx_h_ppdu(ar, &amsdu, rx_status, 0xffff);=0A=
- ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);=0A=
+=0A=
+ /* only for ret =3D 1 indicates chained msdus */=0A=
+ if (ret > 0)=0A=
+ ath10k_htt_rx_h_unchain(ar, &amsdu);=0A=
+=0A=
ath10k_htt_rx_h_filter(ar, &amsdu, rx_status);=0A=
ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status);=0A=
ath10k_htt_rx_h_deliver(ar, &amsdu, rx_status);=0A=
--=0A=
1.9.1=0A=
=0A=
^ permalink raw reply related
* [PATCH] ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Mohammed Shafi Shajakhan @ 2016-09-27 13:01 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
'ath10k_htt_rx_h_unchain' is need to be called only if the return
value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
change makes it more explicit and avoids doing a skb_peek, fetching
rx descriptor pointer, checking rx msdu decap format for the case of
ret = 0 (unchained msdus). Found this change during code walk through,
not sure if this addresses any issue.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 7ae9349..e51dace 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1459,8 +1459,7 @@ static int ath10k_unchain_msdu(struct sk_buff_head *amsdu)
}
static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
- struct sk_buff_head *amsdu,
- bool chained)
+ struct sk_buff_head *amsdu)
{
struct sk_buff *first;
struct htt_rx_desc *rxd;
@@ -1471,9 +1470,6 @@ static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
decap = MS(__le32_to_cpu(rxd->msdu_start.common.info1),
RX_MSDU_START_INFO1_DECAP_FORMAT);
- if (!chained)
- return;
-
/* FIXME: Current unchaining logic can only handle simple case of raw
* msdu chaining. If decapping is other than raw the chaining may be
* more complex and this isn't handled by the current code. Don't even
@@ -1550,7 +1546,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
}
ath10k_htt_rx_h_ppdu(ar, &amsdu, rx_status, 0xffff);
- ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
+
+ /* only for ret = 1 indicates chained msdus */
+ if (ret > 0)
+ ath10k_htt_rx_h_unchain(ar, &amsdu);
+
ath10k_htt_rx_h_filter(ar, &amsdu, rx_status);
ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status);
ath10k_htt_rx_h_deliver(ar, &amsdu, rx_status);
--
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