* Re: Stability connection problems in ath9k kernel 4.7
From: Joerg Roedel @ 2016-09-09 8:38 UTC (permalink / raw)
To: Valerio Passini
Cc: Kalle Valo, Adam Morrison, linux-wireless, Omer Peleg,
linux-kernel, iommu, David Woodhouse
In-Reply-To: <CAC6K2=_Hdkgc_6igoC59J_Cn9=bdye827zbEK7PWtZY6ebh-6Q@mail.gmail.com>
Hi Valerio,
On Thu, Sep 08, 2016 at 09:07:56PM +0200, Valerio Passini wrote:
> I'm hoping having done it right and I can try your first suggestion, but I
> really cannot solve this problem by myself: sorry, I have no capabilities in
> programming in any known and unknown computer language. Surely, I can test all
> the patches you want and report the results but this is the best I can do. Best
> regards
Can you please send me the full dmesg after boot? The Intel-IOMMU is not
enabled by default, so I want to check if it is either enabled by
kernel-config or kernel command-line.
Thanks,
Joerg
^ permalink raw reply
* Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Oleksij Rempel @ 2016-09-09 7:48 UTC (permalink / raw)
To: Martin Blumenstingl, ath9k-devel, devicetree, linux-wireless,
ath9k-devel
Cc: mcgrof, mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, nbd
In-Reply-To: <20160906214623.20424-2-martin.blumenstingl@googlemail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3989 bytes --]
Hallo all,
if it is not too late i would add my two cents :)
Am 06.09.2016 um 23:46 schrieb Martin Blumenstingl:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> .../devicetree/bindings/net/wireless/qca,ath9k.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> new file mode 100644
> index 0000000..77b9202
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,39 @@
> +* Qualcomm Atheros ath9k wireless devices
> +
> +This node provides properties for configuring the ath9k wireless device. The
> +node is expected to be specified as a child node of the PCI controller to
> +which the wireless chip is connected.
> +
> +Required properties:
> +- compatible: For PCI and PCIe devices this should be an identifier following
> + the format as defined in "PCI Bus Binding to Open Firmware"
> + Revision 2.1. One of the possible formats is "pciVVVV,DDDD"
> + where VVVV is the PCI vendor ID and DDDD is PCI device ID.
> +
> +Optional properties:
> +- reg: Address and length of the register set for the device.
> +- qca,clk-25mhz: Defines that a 25MHz clock is used
Some SoCs even Atheros WiSoCs use WiFi clock for System Clock. In this
case we need to use clock framework any way, so why not in this case too?
Provide dummy static clock in DT and connect it with this node?
osc25m: oscillator {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <25000000>;
clock-accuracy = <30000>;
};
acc: clock-controller@80040000 {
compatible = "some-clock-controller";
#clock-cells = <1>;
clocks = <&osc25m>;
reg = <0x80040000 0x204>;
};
&pci0 {
ath9k@168c,002d {
compatible = "pci168c,002d";
reg = <0x7000 0 0 0 0x1000>;
clocks = <&osc25m>;
qca,disable-5ghz;
};
};
driver will need to use clk_get and compare frequency instead of
of_property_read_bool(np, "qca,clk-25mhz"). In this case you will need
to define source clock only one time and reuse it by all affected DT
nodes. If we have 40MHz clock you will only need to change it in
fixed-clock.
> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to the
> + ath9k wireless chip (in this case the calibration /
> + EEPROM data will be loaded from userspace using the
> + kernel firmware loader).
> +- qca,disable-2ghz: Overrides the settings from the EEPROM and disables the
> + 2.4GHz band. Setting this property is only needed
> + when the RF circuit does not support the 2.4GHz band
> + while it is enabled nevertheless in the EEPROM.
> +- qca,disable-5ghz: Overrides the settings from the EEPROM and disables the
> + 5GHz band. Setting this property is only needed when
> + the RF circuit does not support the 5GHz band while
> + it is enabled nevertheless in the EEPROM.
This option can be reused for every WiFi controller. Not only for qca.
So may be instead of adding vendor specific name, make it reusable for
all vendors. Instead of qca,disable-5ghz and qca,disable-2ghz make
disable-5ghz and disable-2ghz?
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +
> +
> +In this example, the node is defined as child node of the PCI controller:
> +&pci0 {
> + ath9k@168c,002d {
> + compatible = "pci168c,002d";
> + reg = <0x7000 0 0 0 0x1000>;
> + qca,disable-5ghz;
> + };
> +};
>
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Kalle Valo @ 2016-09-09 5:17 UTC (permalink / raw)
To: Andy Gross
Cc: Bjorn Andersson, Eugene Krasnikov, wcn36xx, linux-wireless,
netdev, lkml, linux-arm-msm
In-Reply-To: <20160909042754.GA32071@hector.attlocal.net>
Andy Gross <andy.gross@linaro.org> writes:
>> > >> This doesn't compile for me:
>> > >>
>> > >
>> > > I thought I mentioned this in the mail, sorry for missing that.
>> >
>> > Maybe you did and I just forgot, I have a tendency to do that :)
>> >
>> > > There is a patch for this issue in linux-next already [1] which is
>> > > part of [2], which was part of the pull request to arm-soc for
>> > > inclusion in v4.9.
>> > >
>> > > [1] https://patchwork.kernel.org/patch/9272457/
>> > > [2] https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
>> >
>> > So the commit in question is:
>> >
>> > soc: qcom: smd: Correct compile stub prototypes
>> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9&id=3a1281848830fcb3202cfd7ffe62d19641471d05
>> >
>>
>> Correct
>>
>> > But that's not obviously in my tree yet, but I should have it after
>> > 4.9-rc1 is released. I think it's easiest that I wait for that before
>> > applying these. Do you agree?
>> >
>>
>> Would be nice to have it land sooner rather than later, but I'm okay
>> with this.
>
> We could just treat the tag as immutable. You can merge the tag in and arm-soc
> can as well. it'll just get nop'd the second time it is taken. The only
> downside is if arm-soc doesn't take my merge request.
I take it that you are talking about this tag:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git qcom-drivers-for-4.9
I did a test pull and there are only 8 commits so in theory that could
work. But my trees go via Dave Miller's net-next so I can't control when
they hit Linus' tree. It might be that Linus pulls the net-next tree
before arm-soc and arm-soc commits coming from net-next might confuse
people. I'm just afraid that the hassle would outweight the benefit.
> Or we can wait till -rc1
To keep things simple I prefer this option. Of course it means waiting
few more extra weeks, but when working with new subsystems that can
happen. The crystall ball[1] says that 4.9-rc1 would be released on
2016-10-16 so it's not that far away.
[1] http://phb-crystal-ball.org/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Andy Gross @ 2016-09-09 4:27 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Kalle Valo, Eugene Krasnikov, wcn36xx, linux-wireless, netdev,
lkml, linux-arm-msm
In-Reply-To: <20160909042159.GD405@tuxbot>
On Thu, Sep 08, 2016 at 09:21:59PM -0700, Bjorn Andersson wrote:
> On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:
>
> > Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> >
> > > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> > >> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> > >>
> > >>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> > >>> channel, as such it should be a SMD client. This patch makes this
> > >>> transition, now that we have the necessary frameworks available.
> > >>>
> > >>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > >>> ---
> > >>>
> > >>> Changes since v3:
> > >>> - Made msg_header const in wcn36xx_smd_rsp_process()
> > >>>
> > >>> Changes since v2:
> > >>> - Correct the call to the new ieee80211_scan_completed()
> > >>>
> > >>> drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
> > >>> drivers/net/wireless/ath/wcn36xx/main.c | 79 ++++++++++++++++++++----------
> > >>> drivers/net/wireless/ath/wcn36xx/smd.c | 31 +++++-------
> > >>> drivers/net/wireless/ath/wcn36xx/smd.h | 5 ++
> > >>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-----
> > >>> 5 files changed, 86 insertions(+), 66 deletions(-)
> > >>
> > >> This doesn't compile for me:
> > >>
> > >
> > > I thought I mentioned this in the mail, sorry for missing that.
> >
> > Maybe you did and I just forgot, I have a tendency to do that :)
> >
> > > There is a patch for this issue in linux-next already [1] which is
> > > part of [2], which was part of the pull request to arm-soc for
> > > inclusion in v4.9.
> > >
> > > [1] https://patchwork.kernel.org/patch/9272457/
> > > [2] https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
> >
> > So the commit in question is:
> >
> > soc: qcom: smd: Correct compile stub prototypes
> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9&id=3a1281848830fcb3202cfd7ffe62d19641471d05
> >
>
> Correct
>
> > But that's not obviously in my tree yet, but I should have it after
> > 4.9-rc1 is released. I think it's easiest that I wait for that before
> > applying these. Do you agree?
> >
>
> Would be nice to have it land sooner rather than later, but I'm okay
> with this.
We could just treat the tag as immutable. You can merge the tag in and arm-soc
can as well. it'll just get nop'd the second time it is taken. The only
downside is if arm-soc doesn't take my merge request.
Or we can wait till -rc1
Regards,
Andy
^ permalink raw reply
* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Bjorn Andersson @ 2016-09-09 4:21 UTC (permalink / raw)
To: Kalle Valo
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev, lkml,
Andy Gross, linux-arm-msm
In-Reply-To: <878tv2s3ao.fsf@kamboji.qca.qualcomm.com>
On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:
> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>
> > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> >> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> >>
> >>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> >>> channel, as such it should be a SMD client. This patch makes this
> >>> transition, now that we have the necessary frameworks available.
> >>>
> >>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> >>> ---
> >>>
> >>> Changes since v3:
> >>> - Made msg_header const in wcn36xx_smd_rsp_process()
> >>>
> >>> Changes since v2:
> >>> - Correct the call to the new ieee80211_scan_completed()
> >>>
> >>> drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
> >>> drivers/net/wireless/ath/wcn36xx/main.c | 79 ++++++++++++++++++++----------
> >>> drivers/net/wireless/ath/wcn36xx/smd.c | 31 +++++-------
> >>> drivers/net/wireless/ath/wcn36xx/smd.h | 5 ++
> >>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-----
> >>> 5 files changed, 86 insertions(+), 66 deletions(-)
> >>
> >> This doesn't compile for me:
> >>
> >
> > I thought I mentioned this in the mail, sorry for missing that.
>
> Maybe you did and I just forgot, I have a tendency to do that :)
>
> > There is a patch for this issue in linux-next already [1] which is
> > part of [2], which was part of the pull request to arm-soc for
> > inclusion in v4.9.
> >
> > [1] https://patchwork.kernel.org/patch/9272457/
> > [2] https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
>
> So the commit in question is:
>
> soc: qcom: smd: Correct compile stub prototypes
> https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9&id=3a1281848830fcb3202cfd7ffe62d19641471d05
>
Correct
> But that's not obviously in my tree yet, but I should have it after
> 4.9-rc1 is released. I think it's easiest that I wait for that before
> applying these. Do you agree?
>
Would be nice to have it land sooner rather than later, but I'm okay
with this.
Regards,
Bjorn
^ permalink raw reply
* Re: [RFC] mac80211: Dynamically set CoDel parameters per station.
From: Felix Fietkau @ 2016-09-08 20:18 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
Cc: Michal Kazior, Dave Taht
In-Reply-To: <20160908195915.31478-1-toke@toke.dk>
On 2016-09-08 21:59, Toke Høiland-Jørgensen wrote:
> CoDel can be too aggressive if a station sends at a very low rate. This
> gets worse the more stations are present, as each station gets more
> bursty the longer the round-robin scheduling between stations takes.
>
> This is an attempt to dynamically adjust CoDel parameters per station.
> It takes a rather simple approach and uses a simple binary designation
> of a station as 'slow' if it has expected throughput less than eight
> Mbps (i.e. the lowest couple of rates). In this case, CoDel is set to be
> more lenient by adjusting its target to 50 ms and interval to 300 ms.
> There's a built-in hysteresis so a station cannot flip between slow and
> fast more than once every two seconds.
>
> In this version the check is performed every time a packet is enqueued
> to the intermediate queues; and the overhead of doing this is alleviated
> a bit by caching the result and by the above-mentioned hysteresis. It
> can probably be smarter about both when and how to do the scaling, but
> this seems to alleviate some of the starvation I've seen with very slow
> stations.
Since this is not dealing properly with firmware rate control anyway,
I'd suggest calling the update from rate_control_set_rates in order to
avoid putting more stuff into the tx hot path.
You could add a separate code path to allow firmware rate control
devices to provide a hint at a convenient point in time.
- Felix
^ permalink raw reply
* [RFC] mac80211: Dynamically set CoDel parameters per station.
From: Toke Høiland-Jørgensen @ 2016-09-08 19:59 UTC (permalink / raw)
To: make-wifi-fast, linux-wireless
Cc: Toke Høiland-Jørgensen, Michal Kazior, Felix Fietkau,
Dave Taht
CoDel can be too aggressive if a station sends at a very low rate. This
gets worse the more stations are present, as each station gets more
bursty the longer the round-robin scheduling between stations takes.
This is an attempt to dynamically adjust CoDel parameters per station.
It takes a rather simple approach and uses a simple binary designation
of a station as 'slow' if it has expected throughput less than eight
Mbps (i.e. the lowest couple of rates). In this case, CoDel is set to be
more lenient by adjusting its target to 50 ms and interval to 300 ms.
There's a built-in hysteresis so a station cannot flip between slow and
fast more than once every two seconds.
In this version the check is performed every time a packet is enqueued
to the intermediate queues; and the overhead of doing this is alleviated
a bit by caching the result and by the above-mentioned hysteresis. It
can probably be smarter about both when and how to do the scaling, but
this seems to alleviate some of the starvation I've seen with very slow
stations.
I'm not sure how this interacts with drivers that do rate-control in
firmware (such as ath10k). I assume they will just not be able to return
an expected rate (and so will be considered 'fast').
Cc: Michal Kazior <michal.kazior@tieto.com>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Dave Taht <dave@taht.net>
Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
---
net/mac80211/sta_info.c | 37 +++++++++++++++++++++++++++++++++++++
net/mac80211/sta_info.h | 13 +++++++++++++
net/mac80211/tx.c | 14 +++++++++++++-
3 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 19f14c9..8bc9eba 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -20,6 +20,8 @@
#include <linux/timer.h>
#include <linux/rtnetlink.h>
=20
+#include <net/codel.h>
+#include <net/codel_impl.h>
#include <net/mac80211.h>
#include "ieee80211_i.h"
#include "driver-ops.h"
@@ -325,6 +327,10 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub=
_if_data *sdata,
INIT_WORK(&sta->drv_deliver_wk, sta_deliver_ps_frames);
INIT_WORK(&sta->ampdu_mlme.work, ieee80211_ba_session_work);
mutex_init(&sta->ampdu_mlme.mtx);
+
+ codel_params_init(&sta->cparams.cparams);
+ sta->cparams.cparams.ecn =3D true;
+
#ifdef CONFIG_MAC80211_MESH
if (ieee80211_vif_is_mesh(&sdata->vif)) {
sta->mesh =3D kzalloc(sizeof(*sta->mesh), gfp);
@@ -2314,3 +2320,34 @@ unsigned long ieee80211_sta_last_active(struct sta=
_info *sta)
return stats->last_rx;
return sta->status_stats.last_ack;
}
+
+void sta_update_codel_params(struct sta_info *sta)
+{
+ u64 now =3D ktime_get_ns();
+ u32 thr;
+ bool slow;
+
+ if (likely(now - sta->cparams.update_time < STA_CPARAMS_HYSTERESIS))
+ return;
+
+ thr =3D sta_get_expected_throughput(sta);
+ slow =3D !!(thr && thr < STA_SLOW_THRESHOLD);
+
+ if (likely(slow =3D=3D sta->cparams.slow))
+ return;
+
+ net_info_ratelimited("%pM: updating CoDel params - throughput %d slow %=
s\n",
+ sta->addr, thr, slow ? "true" : "false");
+
+ if (slow) {
+ sta->cparams.cparams.target =3D MS2TIME(50);
+ sta->cparams.cparams.interval =3D MS2TIME(300);
+ sta->cparams.cparams.ecn =3D false;
+ } else {
+ sta->cparams.cparams.target =3D MS2TIME(5);
+ sta->cparams.cparams.interval =3D MS2TIME(100);
+ sta->cparams.cparams.ecn =3D true;
+ }
+ sta->cparams.update_time =3D now;
+ sta->cparams.slow =3D slow;
+}
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 0556be3..928c52d 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -384,6 +384,16 @@ struct ieee80211_sta_rx_stats {
u64 msdu[IEEE80211_NUM_TIDS + 1];
};
=20
+#define STA_CPARAMS_HYSTERESIS 5 * NSEC_PER_SEC
+#define STA_SLOW_THRESHOLD 8000 /* 8 mbps */
+
+struct sta_codel_params {
+ struct codel_params cparams;
+ u64 update_time;
+ bool slow;
+};
+void sta_update_codel_params(struct sta_info *sta);
+
/**
* struct sta_info - STA information
*
@@ -437,6 +447,7 @@ struct ieee80211_sta_rx_stats {
* @known_smps_mode: the smps_mode the client thinks we are in. Relevant=
for
* AP only.
* @cipher_scheme: optional cipher scheme for this station
+ * @cparams: CoDel parameters for this station.
* @reserved_tid: reserved TID (if any, otherwise IEEE80211_TID_UNRESERV=
ED)
* @fast_tx: TX fastpath information
* @fast_rx: RX fastpath information
@@ -540,6 +551,8 @@ struct sta_info {
enum ieee80211_smps_mode known_smps_mode;
const struct ieee80211_cipher_scheme *cipher_scheme;
=20
+ struct sta_codel_params cparams;
+
u8 reserved_tid;
=20
struct cfg80211_chan_def tdls_chandef;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index efc38e7..3973ab0 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1339,12 +1339,19 @@ static struct sk_buff *fq_tin_dequeue_func(struct=
fq *fq,
struct codel_vars *cvars;
struct codel_params *cparams;
struct codel_stats *cstats;
+ struct sta_info *sta;
=20
local =3D container_of(fq, struct ieee80211_local, fq);
txqi =3D container_of(tin, struct txq_info, tin);
- cparams =3D &local->cparams;
cstats =3D &local->cstats;
=20
+ if (txqi->txq.sta) {
+ sta =3D container_of(txqi->txq.sta, struct sta_info, sta);
+ cparams =3D &sta->cparams.cparams;
+ } else
+ cparams =3D &local->cparams;
+
+
if (flow =3D=3D &txqi->def_flow)
cvars =3D &txqi->def_cvars;
else
@@ -1547,6 +1554,11 @@ static bool ieee80211_tx_frags(struct ieee80211_lo=
cal *local,
=20
txqi =3D ieee80211_get_txq(local, vif, sta, skb);
if (txqi) {
+ if (sta) {
+ struct sta_info *sti =3D container_of(sta, struct sta_info, sta);
+ sta_update_codel_params(sti);
+ }
+
info->control.vif =3D vif;
=20
__skb_unlink(skb, skbs);
--=20
2.9.3
^ permalink raw reply related
* support for QCA9377 SDIO (ath10k or ath6kl)
From: Martin Blumenstingl @ 2016-09-08 19:31 UTC (permalink / raw)
To: ath10k, ath6kl; +Cc: linux-wireless
Hello,
is there any support for the SDIO chips QCA9377 (and QCA9378) planned?
Would these be supported by ath10k or ath6kl or is a completely new
driver needed?
Some background:
There are some device (Android TV boxes) which are using a QCA9377
wifi chip connected via SDIO. Example: Beelink GT1 (using an Amlogic
S912 SoC) - [0]
The part in question is labeled with AW-CM273SM (could be an AzureWave
module based on the name - but that is pure speculation).
According to some google hits it uses a QCA9377 chip (which would
match with the wifi-fw tarball from Amlogic which recently gained a
"qcom9377" folder).
Regards,
Martin
[0] http://forum.xda-developers.com/android-stick--console-computers/amlogic/beelink-gt1-amlogic-912-2-16gb-t3451068
^ permalink raw reply
* Re: [PATCH 2/2] mwifiex: fix unaligned read in mwifiex_config_scan()
From: Kalle Valo @ 2016-09-08 18:01 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Petri Gynther, linux-wireless@vger.kernel.org, David Miller,
Joe Perches
In-Reply-To: <63fa0bf1951945bebc1d620c39a7c6e8@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
>> > --- a/drivers/net/wireless/marvell/mwifiex/scan.c
>> > +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
>> > @@ -883,7 +883,8 @@ mwifiex_config_scan(struct mwifiex_private *priv,
>> > sizeof(scan_cfg_out->specific_bssid));
>> >
>> > if (adapter->ext_scan &&
>> > - !is_zero_ether_addr(scan_cfg_out->specific_bssid))
>> {
>> > + !is_zero_ether_addr_unaligned(
>> > + scan_cfg_out->specific_bssid)) {
>>
>> Any comments? Is this approach of adding
>> is_zero_ether_addr_unaligned() fine? We already have similar routine
>> ether_addr_equal_unaligned().
>>
>> I don't see much benefit making a local, aligned copy here. It would
>> have to use memcpy w/ byte operations anyways and then still run
>> is_zero_ether_addr().
>>
>> Amitkumar -- Is it possible to modify struct mwifiex_scan_cmd_config {}
>> and align specific_bssid field to u16 boundary?
>>
>
> We can’t change the structure. The reason is firmware at receiving end
> expects the variables in the same order.
> is_zero_ether_addr_unaligned() should be fine.
If I understood correctly Dave doesn't like
is_zero_ether_addr_unaligned() so we can't use that either.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Kalle Valo @ 2016-09-08 17:35 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev, lkml,
Andy Gross, linux-arm-msm
In-Reply-To: <CAOCOHw5Wvy5g0HuDaYUZ2WTCws5uXtw6DO7S3Dvp+0mgW-Mg=Q@mail.gmail.com>
Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>>
>>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
>>> channel, as such it should be a SMD client. This patch makes this
>>> transition, now that we have the necessary frameworks available.
>>>
>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>> ---
>>>
>>> Changes since v3:
>>> - Made msg_header const in wcn36xx_smd_rsp_process()
>>>
>>> Changes since v2:
>>> - Correct the call to the new ieee80211_scan_completed()
>>>
>>> drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
>>> drivers/net/wireless/ath/wcn36xx/main.c | 79 ++++++++++++++++++++----------
>>> drivers/net/wireless/ath/wcn36xx/smd.c | 31 +++++-------
>>> drivers/net/wireless/ath/wcn36xx/smd.h | 5 ++
>>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-----
>>> 5 files changed, 86 insertions(+), 66 deletions(-)
>>
>> This doesn't compile for me:
>>
>
> I thought I mentioned this in the mail, sorry for missing that.
Maybe you did and I just forgot, I have a tendency to do that :)
> There is a patch for this issue in linux-next already [1] which is
> part of [2], which was part of the pull request to arm-soc for
> inclusion in v4.9.
>
> [1] https://patchwork.kernel.org/patch/9272457/
> [2] https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
So the commit in question is:
soc: qcom: smd: Correct compile stub prototypes
https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9&id=3a1281848830fcb3202cfd7ffe62d19641471d05
But that's not obviously in my tree yet, but I should have it after
4.9-rc1 is released. I think it's easiest that I wait for that before
applying these. Do you agree?
--
Kalle Valo
^ permalink raw reply
* Re: Stability connection problems in ath9k kernel 4.7
From: Kalle Valo @ 2016-09-08 17:25 UTC (permalink / raw)
To: Valerio Passini
Cc: linux-wireless, Omer Peleg, Adam Morrison, David Woodhouse,
linux-kernel, Joerg Roedel, iommu
In-Reply-To: <2596121.7secQ7hYiJ@automatix>
Valerio Passini <valerio.passini@unicam.it> writes:
> On mercoledì 7 settembre 2016 11:32:24 CEST Kalle Valo wrote:
>> Valerio Passini <valerio.passini@unicam.it> writes:
>> > I have found some connection problems since 4.7 release using ath9k that
>> > turn the wifi pretty useless, I think it might be something in the power
>> > management because the signal seems really low. Previously, up to kernel
>> > 4.6.7 everything worked very well.
>> >
>> > This is a sample of dmesg in kernel 4.7.2:
>> > 239.898935] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
>> >
>> > [ 239.919995] wlp4s0: send auth to XX:XX:XX:XX:XX:XX (try 1/3)
>> > [ 239.931877] wlp4s0: authenticated
>> > [ 239.932357] wlp4s0: associate with XX:XX:XX:XX:XX:XX (try 1/3)
>> > [ 239.942171] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=0x431
>> > status=0 aid=2)
>> > [ 239.942301] wlp4s0: associated
>> > [ 244.802853] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024
>> > AR_DIAG_SW=0x02000020 DMADBG_7=0x0000
>> > 6100
>> > [ 245.931832] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
>> > [ 245.953028] wlp4s0: send auth to XX:XX:XX:XX:XX:XX (try 1/3)
>> > [ 245.958702] wlp4s0: authenticated
>> > [ 245.960386] wlp4s0: associate withXX:XX:XX:XX:XX:XX (try 1/3)
>> > [ 245.980543] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=0x431
>> > status=0 aid=2)
>> >
>> > lspci on 4.6.7 kernel:
>> > 04:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network
>> > Adapter (rev 01)
>> >
>> > Subsystem: AzureWave AR9485 Wireless Network Adapter
>> > Flags: bus master, fast devsel, latency 0, IRQ 18
>> > Memory at f7900000 (64-bit, non-prefetchable) [size=512K]
>> > Expansion ROM at f7980000 [disabled] [size=64K]
>> > Capabilities: [40] Power Management version 2
>> > Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>> > Capabilities: [70] Express Endpoint, MSI 00
>> > Capabilities: [100] Advanced Error Reporting
>> > Capabilities: [140] Virtual Channel
>> > Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
>> > Kernel driver in use: ath9k
>> > Kernel modules: ath9k
>> >
>> > Probably you need some debugging output, but before recompiling the kernel
>> > I would like to know if you are interested in any kind of help from me
>> > and what steps I should take (I'm able to help in testing patches but I'm
>> > not familiar with git). Thank you
>>
>> Usually it's really helpful if you can find the commit id which broke
>> it. 'git bisect' is a great tool to do that and this seems to be a nice
>> tutorial how to use it:
>>
>> http://webchick.net/node/99
>>
>> Instead of commit ids you can use release tags like v4.6 and v4.7 to
>> make it easier to start the bisect. Just make sure that v4.7 is really
>> broken and v4.6 works before you start the bisection.
>
> Hi Kalle,
>
> I tried to understand the whole procedure related to git and git bisect, and
> this is the first time I try it, so I can have done some mistake. In the git
> log you'll find the commit that could be guilty for the behaviour I reported
> yesterday. Anyhow, the resulting commit doesn't make any sense to me.
So your bisect found this as the bad commit:
commit 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270
Author: Omer Peleg <omer@cs.technion.ac.il>
Date: Wed Apr 20 11:34:11 2016 +0300
iommu/iova: introduce per-cpu caching to iova allocation
The ath9k log you provided has a DMA warning and iommu problems can
cause DMA problems but I cannot make any conclusions yet. To confirm
that this commit really is the problem you could try to revert it with
'git revert -n 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270'. For some
reason I got conflicts but if you are good enough with C you could try
to fix those yourself. Another option is that you disable iommu and see
if that helps.
I'm adding more people and mailing lists related to this commit,
hopefully they have better ideas.
This is Valerio's bisect log:
git bisect start
# good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
# bad: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect bad 523d939ef98fd712632d93a5a2b588e477a7565e
# good: [0694f0c9e20c47063e4237e5f6649ae5ce5a369a] radix tree test suite:
remove dependencies on height
git bisect good 0694f0c9e20c47063e4237e5f6649ae5ce5a369a
# good: [e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697] Merge branch 'for-4.7-zac'
of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
git bisect good e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697
# bad: [049ec1b5a76d34a6980cccdb7c0baeb4eed7a993] Merge tag 'drm-fixes-for-
v4.7-rc2' of git://people.freedesktop.org/~airlied/linux
git bisect bad 049ec1b5a76d34a6980cccdb7c0baeb4eed7a993
# good: [a10c38a4f385f5d7c173a263ff6bb2d36021b3bb] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
git bisect good a10c38a4f385f5d7c173a263ff6bb2d36021b3bb
# bad: [9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d] Merge branch 'for-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
git bisect bad 9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d
# bad: [c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd] Merge tag 'drm-fixes-v4.7-
rc1' of git://people.freedesktop.org/~airlied/linux
git bisect bad c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd
# good: [dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6] Merge branch 'misc' of
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
git bisect good dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6
# good: [e28e909c36bb5d6319953822d84df00fce7cbd18] Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good e28e909c36bb5d6319953822d84df00fce7cbd18
# good: [79b3c7164c18e2fe9e69b0dcc0d45bab7ae3c968] Merge branch 'drm-next-4.7'
of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect good 79b3c7164c18e2fe9e69b0dcc0d45bab7ae3c968
# bad: [1e8143db755f745a9842984de5e8b423f583aea2] Merge tag 'platform-drivers-
x86-v4.7-1' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
git bisect bad 1e8143db755f745a9842984de5e8b423f583aea2
# good: [afcedebc6a094224973534f43b396bbbf33fe44e] thinkpad_acpi: save
kbdlight state on suspend and restore it on resume
git bisect good afcedebc6a094224973534f43b396bbbf33fe44e
# good: [2aac630429d986a43ac59525a4cff47a624dc58e] iommu/vt-d: change intel-
iommu to use IOVA frame numbers
git bisect good 2aac630429d986a43ac59525a4cff47a624dc58e
# bad: [2566278551d3db875bc3bbfc41b42f2e80392108] Merge git://
git.infradead.org/intel-iommu
git bisect bad 2566278551d3db875bc3bbfc41b42f2e80392108
# bad: [22e2f9fa63b092923873fc8a52955151f4d83274] iommu/vt-d: Use per-cpu IOVA
caching
git bisect bad 22e2f9fa63b092923873fc8a52955151f4d83274
# bad: [9257b4a206fc0229dd5f84b78e4d1ebf3f91d270] iommu/iova: introduce per-
cpu caching to iova allocation
git bisect bad 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270
# first bad commit: [9257b4a206fc0229dd5f84b78e4d1ebf3f91d270] iommu/iova:
introduce per-cpu caching to iova allocation
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 2/2] mwifiex: fix unaligned read in mwifiex_config_scan()
From: Amitkumar Karwar @ 2016-09-08 16:10 UTC (permalink / raw)
To: Petri Gynther, linux-wireless@vger.kernel.org
Cc: kvalo@codeaurora.org, David Miller, Joe Perches
In-Reply-To: <CAGXr9JFSUFr+mhyRnPk0pCeVsde4PUudZW+AZ44mKdT1iEpV6A@mail.gmail.com>
SGkgUGV0cmksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0cmkg
R3ludGhlciBbbWFpbHRvOnBneW50aGVyQGdvb2dsZS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEF1
Z3VzdCAxNiwgMjAxNiAxMToxNyBQTQ0KPiBUbzogbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwu
b3JnDQo+IENjOiBrdmFsb0Bjb2RlYXVyb3JhLm9yZzsgRGF2aWQgTWlsbGVyOyBKb2UgUGVyY2hl
czsgQW1pdGt1bWFyIEthcndhcjsNCj4gUGV0cmkgR3ludGhlcg0KPiBTdWJqZWN0OiBSZTogW1BB
VENIIDIvMl0gbXdpZmlleDogZml4IHVuYWxpZ25lZCByZWFkIGluDQo+IG13aWZpZXhfY29uZmln
X3NjYW4oKQ0KPiANCj4gT24gRnJpLCBBdWcgMTIsIDIwMTYgYXQgODowMCBQTSwgUGV0cmkgR3lu
dGhlciA8cGd5bnRoZXJAZ29vZ2xlLmNvbT4NCj4gd3JvdGU6DQo+ID4gJCBpd2NvbmZpZyBtbGFu
MCBlc3NpZCBNeVNTSUQNCj4gPiBbICAgMzYuOTMwMDAwXSBQYXRoOiAvc2Jpbi9pd2NvbmZpZw0K
PiA+IFsgICAzNi45MzAwMDBdIENQVTogMCBQSUQ6IDIwMyBDb21tOiBpd2NvbmZpZyBOb3QgdGFp
bnRlZCA0LjcuMCAjMg0KPiA+IFsgICAzNi45NDAwMDBdIHRhc2s6IDg2NmY4M2EwIHRpOiA4NjZh
NjAwMCB0YXNrLnRpOiA4NjZhNjAwMA0KPiA+IFsgICAzNi45NDAwMDBdDQo+ID4gW0VDUiAgIF06
IDB4MDAyMzA0MDAgPT4gTWlzYWxpZ25lZCByL3cgZnJvbSAweDg2NzdmNDAzDQo+ID4gWyAgIDM2
Ljk2MDAwMF0gW0VGQSAgIF06IDB4ODY3N2Y0MDMNCj4gPiBbICAgMzYuOTYwMDAwXSBbQkxJTksg
XTogbXdpZmlleF9zY2FuX25ldHdvcmtzKzB4MTdhLzB4MTk4YyBbbXdpZmlleF0NCj4gPiBbICAg
MzYuOTYwMDAwXSBbRVJFVCAgXTogbXdpZmlleF9zY2FuX25ldHdvcmtzKzB4MThhLzB4MTk4YyBb
bXdpZmlleF0NCj4gPiBbICAgMzYuOTgwMDAwXSBbU1RBVDMyXTogMHgwMDAwMDIwNiA6IEsgICAg
ICAgICBFMiBFMQ0KPiA+IFsgICAzNi45ODAwMDBdIEJUQTogMHg3MDA3MzZlMiAgIFNQOiAweDg2
NmE3ZDBjICBGUDogMHg1ZmFkZGM4NA0KPiA+IFsgICAzNy4wMDAwMDBdIExQUzogMHg4MDZhMzdl
YyAgTFBFOiAweDgwNmEzN2ZhIExQQzogMHgwMDAwMDAwMA0KPiA+IFsgICAzNy4wMDAwMDBdIHIw
MDogMHg4Njc3ZjQwMSAgcjAxOiAweDg2NjhhYTA4IHIwMjogMHgwMDAwMDAwMQ0KPiA+IHIwMzog
MHgwMDAwMDAwMCByMDQ6IDB4ODY2OGI2MDAgcjA1OiAweDg2NzdmNDA2DQo+ID4gcjA2OiAweDg3
MDJiNjAwIHIwNzogMHgwMDAwMDAwMCByMDg6IDB4ODcwMmI2MDANCj4gPiByMDk6IDB4MDAwMDAw
MDAgcjEwOiAweDg3MGIzYjAwIHIxMTogMHgwMDAwMDAwMA0KPiA+IHIxMjogMHgwMDAwMDAwMA0K
PiA+IFsgICAzNy4wNDAwMDBdDQo+ID4gWyAgIDM3LjA0MDAwMF0gU3RhY2sgVHJhY2U6DQo+ID4g
WyAgIDM3LjA0MDAwMF0gICBtd2lmaWV4X3NjYW5fbmV0d29ya3MrMHgxOGEvMHgxOThjIFttd2lm
aWV4XQ0KPiA+DQo+ID4gUm9vdCBjYXVzZToNCj4gPiBtd2lmaWV4IGRyaXZlciBjYWxscyBpc196
ZXJvX2V0aGVyX2FkZHIoKSBhZ2FpbnN0IGJ5dGUtYWxpZ25lZA0KPiBhZGRyZXNzOg0KPiA+DQo+
ID4gZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L2Z3Lmg6DQo+ID4gc3RydWN0
IG13aWZpZXhfc2Nhbl9jbWRfY29uZmlnIHsNCj4gPiAgICAgICAgIC8qDQo+ID4gICAgICAgICAg
KiAgQlNTIG1vZGUgdG8gYmUgc2VudCBpbiB0aGUgZmlybXdhcmUgY29tbWFuZA0KPiA+ICAgICAg
ICAgICovDQo+ID4gICAgICAgICB1OCBic3NfbW9kZTsNCj4gPg0KPiA+ICAgICAgICAgLyogU3Bl
Y2lmaWMgQlNTSUQgdXNlZCB0byBmaWx0ZXIgc2NhbiByZXN1bHRzIGluIHRoZSBmaXJtd2FyZQ0K
PiAqLw0KPiA+ICAgICAgICAgdTggc3BlY2lmaWNfYnNzaWRbRVRIX0FMRU5dOw0KPiA+DQo+ID4g
ICAgICAgICAuLi4NCj4gPiB9IF9fcGFja2VkOw0KPiA+DQo+ID4gZHJpdmVycy9uZXQvd2lyZWxl
c3MvbWFydmVsbC9td2lmaWV4L3NjYW4uYzoNCj4gPiBtd2lmaWV4X2NvbmZpZ19zY2FuKC4uLiwg
c3RydWN0IG13aWZpZXhfc2Nhbl9jbWRfY29uZmlnICpzY2FuX2NmZ19vdXQsDQo+IC4uLikNCj4g
PiAgICAgICAgIC4uLg0KPiA+ICAgICAgICAgaWYgKGFkYXB0ZXItPmV4dF9zY2FuICYmDQo+ID4g
ICAgICAgICAgICAgIWlzX3plcm9fZXRoZXJfYWRkcihzY2FuX2NmZ19vdXQtPnNwZWNpZmljX2Jz
c2lkKSkgew0KPiA+ICAgICAgICAgICAgIC4uLg0KPiA+ICAgICAgICAgfQ0KPiA+DQo+ID4gU2lu
Y2UgZmlybXdhcmUtcmVsYXRlZCBzdHJ1Y3QgbXdpZmlleF9zY2FuX2NtZF9jb25maWcgY2Fubm90
IGJlDQo+ID4gY2hhbmdlZCwgd2UgbmVlZCB0byB1c2UgdGhlIG5ldyBmdW5jdGlvbg0KPiBpc196
ZXJvX2V0aGVyX2FkZHJfdW5hbGlnbmVkKCkgaGVyZS4NCj4gPg0KPiA+IFRoaXMgaXMgdjIgb2Yg
dGhlIG9yaWdpbmFsIHBhdGNoOg0KPiA+IFtQQVRDSF0gTW9kaWZ5IGlzX3plcm9fZXRoZXJfYWRk
cigpIHRvIGhhbmRsZSBieXRlLWFsaWduZWQgYWRkcmVzc2VzDQo+ID4NCj4gPiBQZXIgSm9lJ3Mg
c3VnZ2VzdGlvbiAtLSBpbnN0ZWFkIG9mIG1vZGlmeWluZyBpc196ZXJvX2V0aGVyX2FkZHIoKSAt
LQ0KPiA+IGFkZCBpc196ZXJvX2V0aGVyX2FkZHJfdW5hbGlnbmVkKCkgYW5kIHVzZSBpdCB3aGVy
ZSBuZWVkZWQuDQo+ID4NCj4gPiBDYzogS2FsbGUgVmFsbyA8a3ZhbG9AY29kZWF1cm9yYS5vcmc+
DQo+ID4gQ2M6IERhdmlkIFMuIE1pbGxlciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldD4NCj4gPiBDYzog
Sm9lIFBlcmNoZXMgPGpvZUBwZXJjaGVzLmNvbT4NCj4gPiBDYzogQW1pdGt1bWFyIEthcndhciA8
YWthcndhckBtYXJ2ZWxsLmNvbT4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBQZXRyaSBHeW50aGVyIDxw
Z3ludGhlckBnb29nbGUuY29tPg0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL25ldC93aXJlbGVzcy9t
YXJ2ZWxsL213aWZpZXgvc2Nhbi5jIHwgMyArKy0NCj4gPiAgMSBmaWxlIGNoYW5nZWQsIDIgaW5z
ZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMv
bmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9zY2FuLmMNCj4gPiBiL2RyaXZlcnMvbmV0L3dp
cmVsZXNzL21hcnZlbGwvbXdpZmlleC9zY2FuLmMNCj4gPiBpbmRleCBiYzVlNTJjLi5kNjQ4Yzg4
IDEwMDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9z
Y2FuLmMNCj4gPiArKysgYi9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvc2Nh
bi5jDQo+ID4gQEAgLTg4Myw3ICs4ODMsOCBAQCBtd2lmaWV4X2NvbmZpZ19zY2FuKHN0cnVjdCBt
d2lmaWV4X3ByaXZhdGUgKnByaXYsDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICBzaXplb2Yo
c2Nhbl9jZmdfb3V0LT5zcGVjaWZpY19ic3NpZCkpOw0KPiA+DQo+ID4gICAgICAgICAgICAgICAg
IGlmIChhZGFwdGVyLT5leHRfc2NhbiAmJg0KPiA+IC0gICAgICAgICAgICAgICAgICAgIWlzX3pl
cm9fZXRoZXJfYWRkcihzY2FuX2NmZ19vdXQtPnNwZWNpZmljX2Jzc2lkKSkNCj4gew0KPiA+ICsg
ICAgICAgICAgICAgICAgICAgIWlzX3plcm9fZXRoZXJfYWRkcl91bmFsaWduZWQoDQo+ID4gKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzY2FuX2NmZ19vdXQtPnNwZWNpZmljX2Jzc2lk
KSkgew0KPiANCj4gQW55IGNvbW1lbnRzPyBJcyB0aGlzIGFwcHJvYWNoIG9mIGFkZGluZw0KPiBp
c196ZXJvX2V0aGVyX2FkZHJfdW5hbGlnbmVkKCkgZmluZT8gV2UgYWxyZWFkeSBoYXZlIHNpbWls
YXIgcm91dGluZQ0KPiBldGhlcl9hZGRyX2VxdWFsX3VuYWxpZ25lZCgpLg0KPiANCj4gSSBkb24n
dCBzZWUgbXVjaCBiZW5lZml0IG1ha2luZyBhIGxvY2FsLCBhbGlnbmVkIGNvcHkgaGVyZS4gSXQg
d291bGQNCj4gaGF2ZSB0byB1c2UgbWVtY3B5IHcvIGJ5dGUgb3BlcmF0aW9ucyBhbnl3YXlzIGFu
ZCB0aGVuIHN0aWxsIHJ1bg0KPiBpc196ZXJvX2V0aGVyX2FkZHIoKS4NCj4gDQo+IEFtaXRrdW1h
ciAtLSBJcyBpdCBwb3NzaWJsZSB0byBtb2RpZnkgc3RydWN0IG13aWZpZXhfc2Nhbl9jbWRfY29u
ZmlnIHt9DQo+IGFuZCBhbGlnbiBzcGVjaWZpY19ic3NpZCBmaWVsZCB0byB1MTYgYm91bmRhcnk/
DQo+IA0KDQpXZSBjYW7igJl0IGNoYW5nZSB0aGUgc3RydWN0dXJlLiBUaGUgcmVhc29uIGlzIGZp
cm13YXJlIGF0IHJlY2VpdmluZyBlbmQgZXhwZWN0cyB0aGUgdmFyaWFibGVzIGluIHRoZSBzYW1l
IG9yZGVyLg0KaXNfemVyb19ldGhlcl9hZGRyX3VuYWxpZ25lZCgpIHNob3VsZCBiZSBmaW5lLg0K
DQpSZWdhcmRzLA0KQW1pdGt1bWFyDQo=
^ permalink raw reply
* Re: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()
From: Javier Martinez Canillas @ 2016-09-08 15:57 UTC (permalink / raw)
To: Amitkumar Karwar, Kalle Valo
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, Nishant Sarmukadam,
Arend van Spriel
In-Reply-To: <0f15fe320fa34ae287f8a6b91ec78a34@SC-EXCH04.marvell.com>
Hello Amitkumar,
On 09/08/2016 11:55 AM, Amitkumar Karwar wrote:
> Hi Javier,
>
>> From: Javier Martinez Canillas [mailto:javier@osg.samsung.com]
>> Sent: Tuesday, September 06, 2016 5:43 PM
>> To: Kalle Valo
>> Cc: linux-kernel@vger.kernel.org; Amitkumar Karwar;
>> netdev@vger.kernel.org; linux-wireless@vger.kernel.org; Nishant
>> Sarmukadam; Arend van Spriel
>> Subject: Re: mwifiex: propagate error if IRQ request fails in
>> mwifiex_sdio_of()
>>
>> Hello Kalle,
>>
>> On 09/03/2016 12:35 PM, Kalle Valo wrote:
>>> Javier Martinez Canillas <javier@osg.samsung.com> wrote:
>>>> If request_irq() fails in mwifiex_sdio_probe_of(), only an error
>>>> message is printed but the actual error is not propagated to the
>> caller function.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>>
>>> What's the conclusion with this patch? Should I drop it or take it?
>>>
>>> (The discussion is available from the patchwork link in the
>>> signature.)
>>>
>>
>> My understanding is that Arend agrees with the patch and that the
>> question raised was caused by looking at an older kernel version. IOW,
>> the patch is OK and should be picked.
>>
>> I'm adding Arend to cc, so can comment in case I misunderstood him
>> though.
>>
>
> This error doesn't affect actual wifi functionality. Only thing is wakeup on interrupt when system is in suspended state won't work.
> I think, we can make below change.
>
> ------------------
> @@ -122,9 +122,11 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
> IRQF_TRIGGER_LOW,
> "wifi_wake", cfg);
> if (ret) {
> - dev_err(dev,
> + dev_dbg(dev,
> "Failed to request irq_wifi %d (%d)\n",
> cfg->irq_wifi, ret);
> + card->plt_wake_cfg = NULL;
> + return 0;
> }
I'm OK with that change. Feel free too add my Reviewed-by if you post it.
> disable_irq(cfg->irq_wifi);
> }
> -----------------
>
> Regards,
> Amitkumar
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* RE: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()
From: Amitkumar Karwar @ 2016-09-08 15:55 UTC (permalink / raw)
To: Javier Martinez Canillas, Kalle Valo
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, Nishant Sarmukadam,
Arend van Spriel
In-Reply-To: <66735eb5-c831-8e06-337b-80ccfc392061@osg.samsung.com>
SGkgSmF2aWVyLA0KDQo+IEZyb206IEphdmllciBNYXJ0aW5leiBDYW5pbGxhcyBbbWFpbHRvOmph
dmllckBvc2cuc2Ftc3VuZy5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNiwgMjAx
NiA1OjQzIFBNDQo+IFRvOiBLYWxsZSBWYWxvDQo+IENjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJu
ZWwub3JnOyBBbWl0a3VtYXIgS2Fyd2FyOw0KPiBuZXRkZXZAdmdlci5rZXJuZWwub3JnOyBsaW51
eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IE5pc2hhbnQNCj4gU2FybXVrYWRhbTsgQXJlbmQg
dmFuIFNwcmllbA0KPiBTdWJqZWN0OiBSZTogbXdpZmlleDogcHJvcGFnYXRlIGVycm9yIGlmIElS
USByZXF1ZXN0IGZhaWxzIGluDQo+IG13aWZpZXhfc2Rpb19vZigpDQo+IA0KPiBIZWxsbyBLYWxs
ZSwNCj4gDQo+IE9uIDA5LzAzLzIwMTYgMTI6MzUgUE0sIEthbGxlIFZhbG8gd3JvdGU6DQo+ID4g
SmF2aWVyIE1hcnRpbmV6IENhbmlsbGFzIDxqYXZpZXJAb3NnLnNhbXN1bmcuY29tPiB3cm90ZToN
Cj4gPj4gSWYgcmVxdWVzdF9pcnEoKSBmYWlscyBpbiBtd2lmaWV4X3NkaW9fcHJvYmVfb2YoKSwg
b25seSBhbiBlcnJvcg0KPiA+PiBtZXNzYWdlIGlzIHByaW50ZWQgYnV0IHRoZSBhY3R1YWwgZXJy
b3IgaXMgbm90IHByb3BhZ2F0ZWQgdG8gdGhlDQo+IGNhbGxlciBmdW5jdGlvbi4NCj4gPj4NCj4g
Pj4gU2lnbmVkLW9mZi1ieTogSmF2aWVyIE1hcnRpbmV6IENhbmlsbGFzIDxqYXZpZXJAb3NnLnNh
bXN1bmcuY29tPg0KPiA+DQo+ID4gV2hhdCdzIHRoZSBjb25jbHVzaW9uIHdpdGggdGhpcyBwYXRj
aD8gU2hvdWxkIEkgZHJvcCBpdCBvciB0YWtlIGl0Pw0KPiA+DQo+ID4gKFRoZSBkaXNjdXNzaW9u
IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBwYXRjaHdvcmsgbGluayBpbiB0aGUNCj4gPiBzaWduYXR1
cmUuKQ0KPiA+DQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgQXJlbmQgYWdyZWVzIHdp
dGggdGhlIHBhdGNoIGFuZCB0aGF0IHRoZQ0KPiBxdWVzdGlvbiByYWlzZWQgd2FzIGNhdXNlZCBi
eSBsb29raW5nIGF0IGFuIG9sZGVyIGtlcm5lbCB2ZXJzaW9uLiBJT1csDQo+IHRoZSBwYXRjaCBp
cyBPSyBhbmQgc2hvdWxkIGJlIHBpY2tlZC4NCj4gDQo+IEknbSBhZGRpbmcgQXJlbmQgdG8gY2Ms
IHNvIGNhbiBjb21tZW50IGluIGNhc2UgSSBtaXN1bmRlcnN0b29kIGhpbQ0KPiB0aG91Z2guDQo+
IA0KDQpUaGlzIGVycm9yIGRvZXNuJ3QgYWZmZWN0IGFjdHVhbCB3aWZpIGZ1bmN0aW9uYWxpdHku
IE9ubHkgdGhpbmcgaXMgd2FrZXVwIG9uIGludGVycnVwdCB3aGVuIHN5c3RlbSBpcyBpbiBzdXNw
ZW5kZWQgc3RhdGUgd29uJ3Qgd29yay4NCkkgdGhpbmssIHdlIGNhbiBtYWtlIGJlbG93IGNoYW5n
ZS4gDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KQEAgLTEyMiw5ICsxMjIsMTEgQEAgc3RhdGljIGlu
dCBtd2lmaWV4X3NkaW9fcHJvYmVfb2Yoc3RydWN0IGRldmljZSAqZGV2LCBzdHJ1Y3Qgc2Rpb19t
bWNfY2FyZCAqY2FyZCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgSVJRRl9UUklHR0VSX0xPVywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIndpZmlfd2FrZSIsIGNmZyk7DQogICAgICAgICAgIGlmIChyZXQpIHsN
Ci0gICAgICAgICAgICAgICAgICAgIGRldl9lcnIoZGV2LA0KKyAgICAgICAgICAgICAgICAgICAg
ZGV2X2RiZyhkZXYsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICJGYWlsZWQgdG8gcmVx
dWVzdCBpcnFfd2lmaSAlZCAoJWQpXG4iLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
ZmctPmlycV93aWZpLCByZXQpOw0KKyAgICAgICAgICAgICAgICAgICAgY2FyZC0+cGx0X3dha2Vf
Y2ZnID0gTlVMTDsNCisgICAgICAgICAgICAgICAgICAgIHJldHVybiAwOw0KICAgICAgICAgICAg
IH0NCiAgICAgICAgICAgICAgICBkaXNhYmxlX2lycShjZmctPmlycV93aWZpKTsNCiAgICAgICAg
ICAgIH0NCi0tLS0tLS0tLS0tLS0tLS0tDQoNClJlZ2FyZHMsDQpBbWl0a3VtYXINCg==
^ permalink raw reply
* Re: rtl8xxxu: fix spelling mistake "firmare" -> "firmware"
From: Jes Sorensen @ 2016-09-08 15:41 UTC (permalink / raw)
To: Kalle Valo; +Cc: Colin Ian King, linux-wireless, netdev, linux-kernel
In-Reply-To: <20160908122813.E50B561BB7@smtp.codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Colin Ian King <colin.king@canonical.com> wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> Trivial fix to spelling mistakes in dev_dbg message.
>>
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>> Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
>
> I assume Jes will take this.
It's on my list, sorry been swamped in LPC stuff and other work the last
couple of days.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Bjorn Andersson @ 2016-09-08 15:31 UTC (permalink / raw)
To: Kalle Valo
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev, lkml,
Andy Gross, linux-arm-msm
In-Reply-To: <87k2emsi22.fsf@kamboji.qca.qualcomm.com>
On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>
>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
>> channel, as such it should be a SMD client. This patch makes this
>> transition, now that we have the necessary frameworks available.
>>
>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> ---
>>
>> Changes since v3:
>> - Made msg_header const in wcn36xx_smd_rsp_process()
>>
>> Changes since v2:
>> - Correct the call to the new ieee80211_scan_completed()
>>
>> drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
>> drivers/net/wireless/ath/wcn36xx/main.c | 79 ++++++++++++++++++++----------
>> drivers/net/wireless/ath/wcn36xx/smd.c | 31 +++++-------
>> drivers/net/wireless/ath/wcn36xx/smd.h | 5 ++
>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-----
>> 5 files changed, 86 insertions(+), 66 deletions(-)
>
> This doesn't compile for me:
>
I thought I mentioned this in the mail, sorry for missing that.
There is a patch for this issue in linux-next already [1] which is
part of [2], which was part of the pull request to arm-soc for
inclusion in v4.9.
[1] https://patchwork.kernel.org/patch/9272457/
[2] https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
Regards,
Bjorn
^ permalink raw reply
* RE: mwifiex: add PCIe function level reset support
From: Amitkumar Karwar @ 2016-09-08 15:05 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20160903154016.4BCE56217C@smtp.codeaurora.org>
SGkgS2FsbGUsDQoNCj4gRnJvbTogbGludXgtd2lyZWxlc3Mtb3duZXJAdmdlci5rZXJuZWwub3Jn
IFttYWlsdG86bGludXgtd2lyZWxlc3MtDQo+IG93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVo
YWxmIE9mIEthbGxlIFZhbG8NCj4gU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAwMywgMjAxNiA5
OjEwIFBNDQo+IFRvOiBBbWl0a3VtYXIgS2Fyd2FyDQo+IENjOiBsaW51eC13aXJlbGVzc0B2Z2Vy
Lmtlcm5lbC5vcmc7IEFtaXRrdW1hciBLYXJ3YXINCj4gU3ViamVjdDogUmU6IG13aWZpZXg6IGFk
ZCBQQ0llIGZ1bmN0aW9uIGxldmVsIHJlc2V0IHN1cHBvcnQNCj4gDQo+IEFtaXRrdW1hciBLYXJ3
YXIgPGFrYXJ3YXJAbWFydmVsbC5jb20+IHdyb3RlOg0KPiA+IFRoaXMgcGF0Y2ggaW1wbGVtZW50
cyBwcmUgYW5kIHBvc3QgRkxSIGhhbmRsZXJzIHRvIHN1cHBvcnQgUENJZSBGTFINCj4gPiBmdW5j
dGlvbmFsaXR5LiBTb2Z0d2FyZSBjbGVhbnVwIGlzIHBlcmZvcm1lZCBpbiBwcmUtRkxSIHdoZXJl
YXMNCj4gPiBmaXJtd2FyZSBpcyBkb3dubG9hZGVkIGFuZCBzb2Z0d2FyZSBpcyByZS1pbml0aWFs
aXNlZCBpbiBwb3N0LUZMUg0KPiA+IGhhbmRsZXIuDQo+ID4NCj4gPiBGb2xsb3dpbmcgY29tbWFu
ZCB0cmlnZ2VycyBGTFIuDQo+ID4gZWNobyAiMSIgPiAvc3lzL2J1cy9wY2kvZGV2aWNlcy8kTlVN
QkVSL3Jlc2V0DQo+ID4NCj4gPiBUaGlzIGZlYXR1cmUgY2FuIGJlIHVzZWQgYXMgYSByZWNvdmVy
eSBtZWNoYW5pc20gd2hlbiBmaXJtd2FyZSBnZXRzDQo+ID4gaGFuZy4NCj4gPg0KPiA+IFNpZ25l
ZC1vZmYtYnk6IEFtaXRrdW1hciBLYXJ3YXIgPGFrYXJ3YXJAbWFydmVsbC5jb20+DQo+IA0KPiBE
b2Vzbid0IGFwcGx5IGFueW1vcmUsIHBsZWFzZSByZWJhc2UuDQo+IA0KPiBBcHBseWluZzogbXdp
ZmlleDogYWRkIFBDSWUgZnVuY3Rpb24gbGV2ZWwgcmVzZXQgc3VwcG9ydA0KPiBmYXRhbDogc2hh
MSBpbmZvcm1hdGlvbiBpcyBsYWNraW5nIG9yIHVzZWxlc3MNCj4gKGRyaXZlcnMvbmV0L3dpcmVs
ZXNzL21hcnZlbGwvbXdpZmlleC9tYWluLmMpLg0KPiBSZXBvc2l0b3J5IGxhY2tzIG5lY2Vzc2Fy
eSBibG9icyB0byBmYWxsIGJhY2sgb24gMy13YXkgbWVyZ2UuDQo+IENhbm5vdCBmYWxsIGJhY2sg
dG8gdGhyZWUtd2F5IG1lcmdlLg0KPiBQYXRjaCBmYWlsZWQgYXQgMDAwMSBtd2lmaWV4OiBhZGQg
UENJZSBmdW5jdGlvbiBsZXZlbCByZXNldCBzdXBwb3J0DQo+IA0KDQpJdCBnZXRzIGFwcGxpZWQg
c21vb3RobHkgaWYgYmVsb3cgcGF0Y2hlcyBhcmUgYXBwbGllZCBmaXJzdC4NCmh0dHBzOi8vcGF0
Y2h3b3JrLmtlcm5lbC5vcmcvcGF0Y2gvOTMxMDQ5OS8gKFt2NSwxLzJdIG13aWZpZXg6IGFkZCBt
YW51ZmFjdHVyaW5nIG1vZGUgc3VwcG9ydCkNCmh0dHBzOi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcv
cGF0Y2gvOTMxMDUwMS8gKFt2NSwyLzJdIG13aWZpZXg6IGFkZCBjZmc4MDIxMSB0ZXN0bW9kZSBz
dXBwb3J0KQ0KDQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IHdhbnQgbWUgdG8gcmViYXNlICJQ
Q0llIGZ1bmN0aW9uIGxldmVsIHJlc2V0IHN1cHBvcnQiLiBJbiB0aGF0IGNhc2UgSSBuZWVkIHRv
IHJlYmFzZSBhbmQgc2VuZCBhYm92ZSAyIHBhdGNoZXMgYXMgd2VsbC4NCg0KUmVnYXJkcywNCkFt
aXRrdW1hcg0K
^ permalink raw reply
* Re: Stability connection problems in ath9k kernel 4.7
From: Valerio Passini @ 2016-09-08 14:20 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <2596121.7secQ7hYiJ@automatix>
On gioved=EC 8 settembre 2016 16:11:49 CEST Valerio Passini wrote:
I missed a line in copy-paste, sorry.
Valerio
git bisect start
# good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
# bad: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect bad 523d939ef98fd712632d93a5a2b588e477a7565e
# good: [0694f0c9e20c47063e4237e5f6649ae5ce5a369a] radix tree test suite:=20
remove dependencies on height
git bisect good 0694f0c9e20c47063e4237e5f6649ae5ce5a369a
# good: [e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697] Merge branch 'for-4.7-za=
c'=20
of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
git bisect good e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697
# bad: [049ec1b5a76d34a6980cccdb7c0baeb4eed7a993] Merge tag 'drm-fixes-for-
v4.7-rc2' of git://people.freedesktop.org/~airlied/linux
git bisect bad 049ec1b5a76d34a6980cccdb7c0baeb4eed7a993
# good: [a10c38a4f385f5d7c173a263ff6bb2d36021b3bb] Merge branch 'for-linus'=
of=20
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
git bisect good a10c38a4f385f5d7c173a263ff6bb2d36021b3bb
# bad: [9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d] Merge branch 'for-next' o=
f=20
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
git bisect bad 9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d
# bad: [c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd] Merge tag 'drm-fixes-v4.7-
rc1' of git://people.freedesktop.org/~airlied/linux
git bisect bad c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd
# good: [dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6] Merge branch 'misc' of=20
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
git bisect good dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6
# good: [e28e909c36bb5d6319953822d84df00fce7cbd18] Merge tag 'for-linus' of=
=20
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good e28e909c36bb5d6319953822d84df00fce7cbd18
# good: [79b3c7164c18e2fe9e69b0dcc0d45bab7ae3c968] Merge branch 'drm-next-4=
=2E7'=20
of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect good 79b3c7164c18e2fe9e69b0dcc0d45bab7ae3c968
# bad: [1e8143db755f745a9842984de5e8b423f583aea2] Merge tag 'platform-drive=
rs-
x86-v4.7-1' of git://git.infradead.org/users/dvhart/linux-platform-drivers-=
x86
git bisect bad 1e8143db755f745a9842984de5e8b423f583aea2
# good: [afcedebc6a094224973534f43b396bbbf33fe44e] thinkpad_acpi: save=20
kbdlight state on suspend and restore it on resume
git bisect good afcedebc6a094224973534f43b396bbbf33fe44e
# good: [2aac630429d986a43ac59525a4cff47a624dc58e] iommu/vt-d: change intel-
iommu to use IOVA frame numbers
git bisect good 2aac630429d986a43ac59525a4cff47a624dc58e
# bad: [2566278551d3db875bc3bbfc41b42f2e80392108] Merge git://
git.infradead.org/intel-iommu
git bisect bad 2566278551d3db875bc3bbfc41b42f2e80392108
# bad: [22e2f9fa63b092923873fc8a52955151f4d83274] iommu/vt-d: Use per-cpu I=
OVA=20
caching
git bisect bad 22e2f9fa63b092923873fc8a52955151f4d83274
# bad: [9257b4a206fc0229dd5f84b78e4d1ebf3f91d270] iommu/iova: introduce per-
cpu caching to iova allocation
git bisect bad 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270
# first bad commit: [9257b4a206fc0229dd5f84b78e4d1ebf3f91d270] iommu/iova:=
=20
introduce per-cpu caching to iova allocation
^ permalink raw reply
* Re: Stability connection problems in ath9k kernel 4.7
From: Valerio Passini @ 2016-09-08 14:11 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87wpio155z.fsf@purkki.adurom.net>
On mercoled=EC 7 settembre 2016 11:32:24 CEST Kalle Valo wrote:
> Valerio Passini <valerio.passini@unicam.it> writes:
> > I have found some connection problems since 4.7 release using ath9k that
> > turn the wifi pretty useless, I think it might be something in the power
> > management because the signal seems really low. Previously, up to kernel
> > 4.6.7 everything worked very well.
> >=20
> > This is a sample of dmesg in kernel 4.7.2:
> > 239.898935] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
> >=20
> > [ 239.919995] wlp4s0: send auth to XX:XX:XX:XX:XX:XX (try 1/3)
> > [ 239.931877] wlp4s0: authenticated
> > [ 239.932357] wlp4s0: associate with XX:XX:XX:XX:XX:XX (try 1/3)
> > [ 239.942171] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=3D0x=
431
> > status=3D0 aid=3D2)
> > [ 239.942301] wlp4s0: associated
> > [ 244.802853] ath: phy0: DMA failed to stop in 10 ms AR_CR=3D0x00000024
> > AR_DIAG_SW=3D0x02000020 DMADBG_7=3D0x0000
> > 6100
> > [ 245.931832] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
> > [ 245.953028] wlp4s0: send auth to XX:XX:XX:XX:XX:XX (try 1/3)
> > [ 245.958702] wlp4s0: authenticated
> > [ 245.960386] wlp4s0: associate withXX:XX:XX:XX:XX:XX (try 1/3)
> > [ 245.980543] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=3D0x=
431
> > status=3D0 aid=3D2)
> >=20
> > lspci on 4.6.7 kernel:
> > 04:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network
> > Adapter (rev 01)
> >=20
> > Subsystem: AzureWave AR9485 Wireless Network Adapter
> > Flags: bus master, fast devsel, latency 0, IRQ 18
> > Memory at f7900000 (64-bit, non-prefetchable) [size=3D512K]
> > Expansion ROM at f7980000 [disabled] [size=3D64K]
> > Capabilities: [40] Power Management version 2
> > Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
> > Capabilities: [70] Express Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [140] Virtual Channel
> > Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
> > Kernel driver in use: ath9k
> > Kernel modules: ath9k
> >=20
> > Probably you need some debugging output, but before recompiling the ker=
nel
> > I would like to know if you are interested in any kind of help from me
> > and what steps I should take (I'm able to help in testing patches but I=
'm
> > not familiar with git). Thank you
>=20
> Usually it's really helpful if you can find the commit id which broke
> it. 'git bisect' is a great tool to do that and this seems to be a nice
> tutorial how to use it:
>=20
> http://webchick.net/node/99
>=20
> Instead of commit ids you can use release tags like v4.6 and v4.7 to
> make it easier to start the bisect. Just make sure that v4.7 is really
> broken and v4.6 works before you start the bisection.
Hi Kalle,
I tried to understand the whole procedure related to git and git bisect, an=
d=20
this is the first time I try it, so I can have done some mistake. In the gi=
t=20
log you'll find the commit that could be guilty for the behaviour I reporte=
d=20
yesterday. Anyhow, the resulting commit doesn't make any sense to me. If yo=
u=20
have any request, please send an email in cc to me, because I want to=20
unsuscribe this mailing list since it's too high volume for me. Best regards
Valerio
git bisect log
git bisect start
# good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
# bad: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect bad 523d939ef98fd712632d93a5a2b588e477a7565e
# good: [0694f0c9e20c47063e4237e5f6649ae5ce5a369a] radix tree test suite:=20
remove dependencies on height
git bisect good 0694f0c9e20c47063e4237e5f6649ae5ce5a369a
# good: [e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697] Merge branch 'for-4.7-za=
c'=20
of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
git bisect good e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697
# bad: [049ec1b5a76d34a6980cccdb7c0baeb4eed7a993] Merge tag 'drm-fixes-for-
v4.7-rc2' of git://people.freedesktop.org/~airlied/linux
git bisect bad 049ec1b5a76d34a6980cccdb7c0baeb4eed7a993
# good: [a10c38a4f385f5d7c173a263ff6bb2d36021b3bb] Merge branch 'for-linus'=
of=20
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
git bisect good a10c38a4f385f5d7c173a263ff6bb2d36021b3bb
# bad: [9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d] Merge branch 'for-next' o=
f=20
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
git bisect bad 9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d
# bad: [c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd] Merge tag 'drm-fixes-v4.7-
rc1' of git://people.freedesktop.org/~airlied/linux
git bisect bad c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd
# good: [dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6] Merge branch 'misc' of=20
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
git bisect good dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6
# good: [e28e909c36bb5d6319953822d84df00fce7cbd18] Merge tag 'for-linus' of=
=20
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good e28e909c36bb5d6319953822d84df00fce7cbd18
# good: [79b3c7164c18e2fe9e69b0dcc0d45bab7ae3c968] Merge branch 'drm-next-4=
=2E7'=20
of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect good 79b3c7164c18e2fe9e69b0dcc0d45bab7ae3c968
# bad: [1e8143db755f745a9842984de5e8b423f583aea2] Merge tag 'platform-drive=
rs-
x86-v4.7-1' of git://git.infradead.org/users/dvhart/linux-platform-drivers-=
x86
git bisect bad 1e8143db755f745a9842984de5e8b423f583aea2
# good: [afcedebc6a094224973534f43b396bbbf33fe44e] thinkpad_acpi: save=20
kbdlight state on suspend and restore it on resume
git bisect good afcedebc6a094224973534f43b396bbbf33fe44e
# good: [2aac630429d986a43ac59525a4cff47a624dc58e] iommu/vt-d: change intel-
iommu to use IOVA frame numbers
git bisect good 2aac630429d986a43ac59525a4cff47a624dc58e
# bad: [2566278551d3db875bc3bbfc41b42f2e80392108] Merge git://
git.infradead.org/intel-iommu
git bisect bad 2566278551d3db875bc3bbfc41b42f2e80392108
^ permalink raw reply
* Re: rtl8xxxu: fix spelling mistake "firmare" -> "firmware"
From: Kalle Valo @ 2016-09-08 12:28 UTC (permalink / raw)
To: Colin Ian King; +Cc: Jes Sorensen, linux-wireless, netdev, linux-kernel
In-Reply-To: <20160903164354.13331-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistakes in dev_dbg message.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
I assume Jes will take this.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9312169/
^ permalink raw reply
* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Kalle Valo @ 2016-09-08 12:16 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev, linux-kernel,
linux-arm-msm, Andy Gross
In-Reply-To: <1473200312-22438-2-git-send-email-bjorn.andersson@linaro.org>
Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> channel, as such it should be a SMD client. This patch makes this
> transition, now that we have the necessary frameworks available.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v3:
> - Made msg_header const in wcn36xx_smd_rsp_process()
>
> Changes since v2:
> - Correct the call to the new ieee80211_scan_completed()
>
> drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
> drivers/net/wireless/ath/wcn36xx/main.c | 79 ++++++++++++++++++++----------
> drivers/net/wireless/ath/wcn36xx/smd.c | 31 +++++-------
> drivers/net/wireless/ath/wcn36xx/smd.h | 5 ++
> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-----
> 5 files changed, 86 insertions(+), 66 deletions(-)
This doesn't compile for me:
CC [M] drivers/net/wireless/ath/wcn36xx/main.o
CC [M] drivers/net/wireless/ath/wcn36xx/dxe.o
CC [M] drivers/net/wireless/ath/wcn36xx/txrx.o
CC [M] drivers/net/wireless/ath/wcn36xx/smd.o
CC [M] drivers/net/wireless/ath/wcn36xx/pmc.o
CC [M] drivers/net/wireless/ath/wcn36xx/debug.o
LD [M] drivers/net/wireless/ath/wcn36xx/wcn36xx.o
drivers/net/wireless/ath/wcn36xx/smd.o: In function `qcom_smd_get_drvdata':
/home/kvalo/ath10k/src/ath/./include/linux/soc/qcom/smd.h:87: multiple definition of `qcom_smd_get_drvdata'
drivers/net/wireless/ath/wcn36xx/main.o:/home/kvalo/ath10k/src/ath/./include/linux/soc/qcom/smd.h:87: first defined here
drivers/net/wireless/ath/wcn36xx/smd.o: In function `qcom_smd_set_drvdata':
/home/kvalo/ath10k/src/ath/./include/linux/soc/qcom/smd.h:94: multiple definition of `qcom_smd_set_drvdata'
drivers/net/wireless/ath/wcn36xx/main.o:/home/kvalo/ath10k/src/ath/./include/linux/soc/qcom/smd.h:94: first defined here
make[5]: *** [drivers/net/wireless/ath/wcn36xx/wcn36xx.o] Error 1
I fixed it with the diff below. Please let me know if it looks ok to
you, the patch is not applied yet so it's easy to make changes. The full
commit in my pending branch:
https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=dba68ea7a404a9959d0ab44bc13c844187db6d6a
--- a/include/linux/soc/qcom/smd.h
+++ b/include/linux/soc/qcom/smd.h
@@ -83,14 +83,14 @@ qcom_smd_open_channel(struct qcom_smd_channel *channel,
return NULL;
}
-void *qcom_smd_get_drvdata(struct qcom_smd_channel *channel)
+static inline void *qcom_smd_get_drvdata(struct qcom_smd_channel *channel)
{
/* This shouldn't be possible */
WARN_ON(1);
return NULL;
}
-void qcom_smd_set_drvdata(struct qcom_smd_channel *channel, void *data)
+static inline void qcom_smd_set_drvdata(struct qcom_smd_channel *channel, void *data)
{
/* This shouldn't be possible */
WARN_ON(1);
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] ath9k: use ieee80211_tx_status_noskb where possible
From: Felix Fietkau @ 2016-09-08 11:43 UTC (permalink / raw)
To: Kalle Valo, Zefir Kurtisi; +Cc: linux-wireless
In-Reply-To: <87y432sjoj.fsf@kamboji.qca.qualcomm.com>
On 2016-09-08 13:41, Kalle Valo wrote:
> Zefir Kurtisi <zefir.kurtisi@neratec.com> writes:
>
>> On 08/11/2016 09:27 PM, Felix Fietkau wrote:
>>> On 2016-08-11 18:05, Zefir Kurtisi wrote:
>>>> On 08/04/2016 11:49 PM, Felix Fietkau wrote:
>>>>> It removes the need for undoing the padding changes to skb->data and it
>>>>> improves performance by eliminating one tx status lookup per MPDU in the
>>>>> status path. It is also useful for preparing a follow-up fix to better
>>>>> handle powersave filtering.
>>>>>
>>>>
>>>> For me, this one introduces a regression to the statistics, e.g.
>>>> 'dot11TransmittedFragmentCount' is now accounted differently since it is not
>>>> updated from within ieee80211_tx_status_noskb().
>>> Is this important? I guess it would be possible to make this more
>>> accurate by extending the API, but I wonder if that's worth doing just
>>> for these debugfs counters.
>>>
>> If you want to support the IEEE802dot11.MIB (dot11mac.dot11CountersTable), they
>> are important. Not sure though if it is used by others besides us.
>>
>> I think the real issue here is that those counters are regarded as internal debug
>> values (as the comments or e.g. commit c206ca6709 state) instead of general
>> purpose statistics that is exposed to SNMP. As such, they should be configurable
>> as a feature independent of debug settings in mac80211.
>>
>>
>> Aside from that consideration, this patch (with the follow up ones) increased peak
>> performance noticeably (we measure some 5%+ higher peak throughput), which for
>> sure is worth dropping the counters for most.
>>
>> I am fine handling this internally. A note in the commit message would be helpful
>> that states that counters dot11TransmittedFragmentCount, dot11FrameDuplicateCount,
>> dot11ReceivedFragmentCount, and dot11MulticastReceivedFrameCount become invalid.
>
> A good idea, I updated the commit log to mention that. Does that look
> ok?
>
> Author: Felix Fietkau <nbd@nbd.name>
> Date: Fri Sep 2 19:46:12 2016 +0300
>
> ath9k: use ieee80211_tx_status_noskb where possible
>
> It removes the need for undoing the padding changes to skb->data and it
> improves performance by eliminating one tx status lookup per MPDU in the
> status path. It is also useful for preparing a follow-up fix to better
> handle powersave filtering.
>
> A side effect is that these counters, available via debugfs, become now invalid:
>
> * dot11TransmittedFragmentCount
> * dot11FrameDuplicateCount,
> * dot11ReceivedFragmentCount
> * dot11MulticastReceivedFrameCount
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Looks good to me.
- Felix
^ permalink raw reply
* Re: [PATCH 1/2] ath9k: use ieee80211_tx_status_noskb where possible
From: Kalle Valo @ 2016-09-08 11:41 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <236fc08a-9474-0917-47f0-756e9136e3b5@neratec.com>
Zefir Kurtisi <zefir.kurtisi@neratec.com> writes:
> On 08/11/2016 09:27 PM, Felix Fietkau wrote:
>> On 2016-08-11 18:05, Zefir Kurtisi wrote:
>>> On 08/04/2016 11:49 PM, Felix Fietkau wrote:
>>>> It removes the need for undoing the padding changes to skb->data and it
>>>> improves performance by eliminating one tx status lookup per MPDU in the
>>>> status path. It is also useful for preparing a follow-up fix to better
>>>> handle powersave filtering.
>>>>
>>>
>>> For me, this one introduces a regression to the statistics, e.g.
>>> 'dot11TransmittedFragmentCount' is now accounted differently since it is not
>>> updated from within ieee80211_tx_status_noskb().
>> Is this important? I guess it would be possible to make this more
>> accurate by extending the API, but I wonder if that's worth doing just
>> for these debugfs counters.
>>
> If you want to support the IEEE802dot11.MIB (dot11mac.dot11CountersTable), they
> are important. Not sure though if it is used by others besides us.
>
> I think the real issue here is that those counters are regarded as internal debug
> values (as the comments or e.g. commit c206ca6709 state) instead of general
> purpose statistics that is exposed to SNMP. As such, they should be configurable
> as a feature independent of debug settings in mac80211.
>
>
> Aside from that consideration, this patch (with the follow up ones) increased peak
> performance noticeably (we measure some 5%+ higher peak throughput), which for
> sure is worth dropping the counters for most.
>
> I am fine handling this internally. A note in the commit message would be helpful
> that states that counters dot11TransmittedFragmentCount, dot11FrameDuplicateCount,
> dot11ReceivedFragmentCount, and dot11MulticastReceivedFrameCount become invalid.
A good idea, I updated the commit log to mention that. Does that look
ok?
Author: Felix Fietkau <nbd@nbd.name>
Date: Fri Sep 2 19:46:12 2016 +0300
ath9k: use ieee80211_tx_status_noskb where possible
It removes the need for undoing the padding changes to skb->data and it
improves performance by eliminating one tx status lookup per MPDU in the
status path. It is also useful for preparing a follow-up fix to better
handle powersave filtering.
A side effect is that these counters, available via debugfs, become now invalid:
* dot11TransmittedFragmentCount
* dot11FrameDuplicateCount,
* dot11ReceivedFragmentCount
* dot11MulticastReceivedFrameCount
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Patchwork-Id: 9264385
[kvalo@qca.qualcomm.com: add a note about counters, thanks to Zefir Kurtisi]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
--
Kalle Valo
^ permalink raw reply
* pull-request: wireless-drivers 2016-09-08
From: Kalle Valo @ 2016-09-08 11:31 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
few important, but as can be seen from the diffstat, really small fixes
for 4.8. Please let me know if you have any problems.
Kalle
The following changes since commit bb87f02b7e4ccdb614a83cbf840524de81e9b321:
Merge ath-current from ath.git (2016-08-29 21:39:04 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2016-09-08
for you to fetch changes up to a0714125d11bcf21599b08b25fdaf384c0db6712:
Merge ath-current from ath.git (2016-09-07 20:16:37 +0300)
----------------------------------------------------------------
wireless-drivers fixes for 4.8
iwlwifi
* fix P2P dump trigger
* prevent a potential null dereference in iwlmvm
* prevent an uninitialized value from being returned in iwlmvm
* advertise support for channel width change in AP mode
ath10k
* fix racy rx status retrieval from htt context
* QCA9887 support is not experimental anymore, remove the warning message
ath9k
* fix regression with led GPIOs
* fix AR5416 GPIO access warning
brcmfmac
* avoid potential stack overflow in brcmf_cfg80211_start_ap()
----------------------------------------------------------------
Arend Van Spriel (1):
brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()
Ashok Raj Nagarajan (1):
ath10k: fix get rx_status from htt context
Emmanuel Grumbach (2):
iwlwifi: mvm: consider P2p device type for firmware dump triggers
iwlwifi: mvm: don't use ret when not initialised
Giedrius Statkevičius (1):
ath9k: bring back direction setting in ath9k_{start_stop}
Kalle Valo (2):
Merge tag 'iwlwifi-for-kalle-2016-08-29' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge ath-current from ath.git
Miaoqing Pan (1):
ath9k: fix AR5416 access GPIO warning
Mohammed Shafi Shajakhan (1):
ath10k: Remove driver log suggesting QCA9887 support is experimental
Peer, Ilan (1):
iwlwifi: mvm: Advertise support for AP channel width change
Sharon Dvir (1):
iwlwifi: mvm: check if vif is NULL before using it
drivers/net/wireless/ath/ath10k/htt_rx.c | 10 +++++-----
drivers/net/wireless/ath/ath10k/pci.c | 1 -
drivers/net/wireless/ath/ath9k/hw.c | 4 ++--
drivers/net/wireless/ath/ath9k/main.c | 9 +++++++--
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 3 ++-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.h | 3 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 2 ++
9 files changed, 22 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Kalle Valo @ 2016-09-08 10:54 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, devicetree
In-Reply-To: <20160905095128.80560-2-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
> .../bindings/net/wireless/mediatek,mt76.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> new file mode 100644
> index 0000000..d51c35f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> @@ -0,0 +1,26 @@
> +* MediaTek mt76xx devices
> +
> +This node provides properties for configuring the MediaTek mt76xx wireless
> +device. The node is expected to be specified as a child node of the PCI
> +controller to which the wireless chip is connected.
> +
> +Optional properties:
> +
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +- mediatek,2ghz: Override the 2.4 GHz band capability from EEPROM
> +- mediatek,5ghz: Override the 5 GHz band capability from EEPROM
> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
> +
> +&pcie {
> + status = "okay";
> +
> + pcie0 {
> + mt76@0,0 {
> + reg = <0x0000 0 0 0 0>;
> + device_type = "pci";
> + mediatek,mtd-eeprom = <&factory 0x8000>;
> + mediatek,2ghz = <0>;
> + };
> + };
> +};
I need an ack from device tree maintainers, CCing the devicetree list.
Do we need to resend or this ok?
Patchwork link:
https://patchwork.kernel.org/patch/9313309/
--
Kalle Valo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox