* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Stefan Lippers-Hollmann @ 2016-07-22 2:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jes Sorensen, linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel,
Andrea Merello
In-Reply-To: <8046944.AyQGVaNKWH@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
Hi
On 2016-07-20, Arnd Bergmann wrote:
> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> > Arnd Bergmann <arnd@arndb.de> writes:
> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> > >> Arnd Bergmann <arnd@arndb.de> writes:
[...]
> Yes, I was just agreeing here that it's not worth doing that one.
> As far as I can see, the evolution of these devices is
>
> RTL81xxU (2008)
> RTL81xxSU (2009)
> RTL81xxCU (2010)
There is also RTL81xxDU, apparently from 2011, a dualband device
coming in several variants (single MAC + single PHY, double MAC +
double PHY and double PHY); e.g. 0bda:8194 (single PHY + single MAC).
While probably not overly common, it was/ is (hardware-wise) a pretty
interesting device due to its support for 5 GHz[1] - actually I hoped
it to be a (supported-) RTL8192CU variant when I bought it.
Unfortunately no driver[2] made it to staging or the proper kernel.
> RTL81xxEU (2013)
Regards
Stefan Lippers-Hollmann
[1] apparently even concurrent operations for the double MAC +
double PHY variants
[2] https://github.com/lwfinger/rtl8192du
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] hostap: Use memdup_user() to reuse code
From: Julian Calaby @ 2016-07-22 0:29 UTC (permalink / raw)
To: Rajan Vaja; +Cc: Jouni Malinen, Kalle Valo, linux-wireless
In-Reply-To: <1469088884-28469-1-git-send-email-rajan.vaja@gmail.com>
Hi All,
On Thu, Jul 21, 2016 at 6:14 PM, Rajan Vaja <rajan.vaja@gmail.com> wrote:
> Fix coccicheck warning which recommends to
> use memdup_user() instead of reimplementing its
> code.
>
> This patch fixes below coccicheck warnings:
>
> drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3044:9-16: WARNING
> opportunity for memdup_user
> drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3806:9-16: WARNING
> opportunity for memdup_user
>
> Signed-off-by: Rajan Vaja <rajan.vaja@gmail.com>
Looks right to me.
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-21 22:00 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <etPan.579137d1.40bb3278.381a@chrisaw.com>
I’ve created cleaner logs (particularly the dmesg one) and have added
timestamps line-by-line to both so it should be easier to track
between the two log files:
wpa_supplicant:
http://termbin.com/cx0e
dmesg | grep libertas:
http://termbin.com/bvdj
Christopher Williamson
On 21 July 2016 at 22:00:02, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> Sure!
>
> wpa_supplicant logs:
> http://termbin.com/z1hg
>
> dmesg logs (grepped for libertas):
> http://termbin.com/7rt5
>
>
> Christopher Williamson
>
>
>
>
> On 21 July 2016 at 21:38:26, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
>
> > On Thu, 2016-07-21 at 11:55 -0700, Christopher Williamson wrote:
> > > Just to confirm - I can connect to the same network using the same
> > > configurations using a USB wifi adapter I tried.
> >
> > Can you grab simultaneous driver debug logging and supplicant debug
> > logging? Unfortunately the 'status 1' is an unspecified failure, which
> > could be from the AP or the firmware.
> >
> > Dan
> >
> >
> > > Unfortunately it’s not ideal since the point of the Viliv N5 is that
> > > it’s ultra portable so I would really like to get the inbuilt wifi
> > > card working.
> > >
> > > It seems odd that wpa_supplicant reports the connection being
> > > “rejected” as seen below:
> > >
> > > wlan0: CTRL-EVENT-ASSOC-REJECT bssid=a0:63:91:1e:ee:43 status_code=1
> > >
> > > Most of the debug output sadly doesn’t mean a great deal to me - wifi
> > > isn’t really my area of expertise.
> > >
> > > On 21 July 2016 at 19:10:56, Christopher Williamson
> > > (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > >
> > > >
> > > >
> > > > Sure, here are the results:
> > > >
> > > > http://termbin.com/e8e2
> > > >
> > > > Christopher Williamson
> > > >
> > > >
> > > > On 21 July 2016 at 16:37:24, Dan Williams (dcbw@redhat.com(mailto:d
> > > > cbw@redhat.com)) wrote:
> > > >
> > > > >
> > > > > On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
> > > > > >
> > > > > > I used NetworkManager in the previous test.
> > > > > >
> > > > > > This time around I have used wpa_supplicant directly and get
> > > > > > the
> > > > > > following results:
> > > > > >
> > > > > > http://termbin.com/j8ea
> > > > > >
> > > > > > Thought I’d throw them on a pastebin since it’s over 700 lines.
> > > > > Can you try with "-D nl80211" instead of using the WEXT
> > > > > supplicant
> > > > > driver? NM is likely going to use nl80211 since the driver has
> > > > > some
> > > > > support for cfg80211/nl80211 and only does WEXT through the glue
> > > > > layer.
> > > > >
> > > > > Dan
> > > > >
> > > > > >
> > > > > > Christopher Williamson
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 20 July 2016 at 22:50:34, Dan Williams
> > > > > > (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Dan,
> > > > > > > >
> > > > > > > > Ah - yeah I hadn’t thought it may be a kernel build option.
> > > > > > > > I’ve
> > > > > > > > now
> > > > > > > > built that and dmesg is a much more lively place!
> > > > > > > >
> > > > > > > > I’ve provided output logs for both when the device is
> > > > > > > > connected
> > > > > > > > and
> > > > > > > > when a connection attempt is made - hopefully this is
> > > > > > > > useful.
> > > > > > >
> > > > > > > The card is scanning and only finds 'shaunthesheep' 20
> > > > > > > seconds
> > > > > > > after
> > > > > > > you "connect for the first time". The logs stop 3 seconds
> > > > > > > later.
> > > > > > > Are
> > > > > > > you connecting with wicd or something else?
> > > > > > >
> > > > > > > Can you run wpa_supplicant with the "-dddtu" option so we can
> > > > > > > get
> > > > > > > debug
> > > > > > > log output from it?
> > > > > > >
> > > > > > > Dan
> > > > > > --
> > > > > > To unsubscribe from this list: send the line "unsubscribe
> > > > > > linux-
> > > > > > wireless" in
> > > > > > the body of a message to majordomo@vger.kernel.org
> > > > > > More majordomo info at http://vger.kernel.org/majordomo-info.ht
> > > > > > ml
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-
> > > wireless" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-21 21:00 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <1469133499.18298.8.camel@redhat.com>
Sure!
wpa_supplicant logs:
http://termbin.com/z1hg
dmesg logs (grepped for libertas):
http://termbin.com/7rt5
Christopher Williamson
On 21 July 2016 at 21:38:26, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> On Thu, 2016-07-21 at 11:55 -0700, Christopher Williamson wrote:
> > Just to confirm - I can connect to the same network using the same
> > configurations using a USB wifi adapter I tried.
>
> Can you grab simultaneous driver debug logging and supplicant debug
> logging? Unfortunately the 'status 1' is an unspecified failure, which
> could be from the AP or the firmware.
>
> Dan
>
>
> > Unfortunately it’s not ideal since the point of the Viliv N5 is that
> > it’s ultra portable so I would really like to get the inbuilt wifi
> > card working.
> >
> > It seems odd that wpa_supplicant reports the connection being
> > “rejected” as seen below:
> >
> > wlan0: CTRL-EVENT-ASSOC-REJECT bssid=a0:63:91:1e:ee:43 status_code=1
> >
> > Most of the debug output sadly doesn’t mean a great deal to me - wifi
> > isn’t really my area of expertise.
> >
> > On 21 July 2016 at 19:10:56, Christopher Williamson
> > (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> >
> > >
> > >
> > > Sure, here are the results:
> > >
> > > http://termbin.com/e8e2
> > >
> > > Christopher Williamson
> > >
> > >
> > > On 21 July 2016 at 16:37:24, Dan Williams (dcbw@redhat.com(mailto:d
> > > cbw@redhat.com)) wrote:
> > >
> > > >
> > > > On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
> > > > >
> > > > > I used NetworkManager in the previous test.
> > > > >
> > > > > This time around I have used wpa_supplicant directly and get
> > > > > the
> > > > > following results:
> > > > >
> > > > > http://termbin.com/j8ea
> > > > >
> > > > > Thought I’d throw them on a pastebin since it’s over 700 lines.
> > > > Can you try with "-D nl80211" instead of using the WEXT
> > > > supplicant
> > > > driver? NM is likely going to use nl80211 since the driver has
> > > > some
> > > > support for cfg80211/nl80211 and only does WEXT through the glue
> > > > layer.
> > > >
> > > > Dan
> > > >
> > > > >
> > > > > Christopher Williamson
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 20 July 2016 at 22:50:34, Dan Williams
> > > > > (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson
> > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > Hi Dan,
> > > > > > >
> > > > > > > Ah - yeah I hadn’t thought it may be a kernel build option.
> > > > > > > I’ve
> > > > > > > now
> > > > > > > built that and dmesg is a much more lively place!
> > > > > > >
> > > > > > > I’ve provided output logs for both when the device is
> > > > > > > connected
> > > > > > > and
> > > > > > > when a connection attempt is made - hopefully this is
> > > > > > > useful.
> > > > > >
> > > > > > The card is scanning and only finds 'shaunthesheep' 20
> > > > > > seconds
> > > > > > after
> > > > > > you "connect for the first time". The logs stop 3 seconds
> > > > > > later.
> > > > > > Are
> > > > > > you connecting with wicd or something else?
> > > > > >
> > > > > > Can you run wpa_supplicant with the "-dddtu" option so we can
> > > > > > get
> > > > > > debug
> > > > > > log output from it?
> > > > > >
> > > > > > Dan
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe
> > > > > linux-
> > > > > wireless" in
> > > > > the body of a message to majordomo@vger.kernel.org
> > > > > More majordomo info at http://vger.kernel.org/majordomo-info.ht
> > > > > ml
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> > wireless" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Dan Williams @ 2016-07-21 20:38 UTC (permalink / raw)
To: Christopher Williamson, linux-wireless@vger.kernel.org
In-Reply-To: <CANXHH3kwH_A-45D9ZsT3Afz3LxYW6Pgz06qBzfnK+jtcg8FiNg@mail.gmail.com>
On Thu, 2016-07-21 at 11:55 -0700, Christopher Williamson wrote:
> Just to confirm - I can connect to the same network using the same
> configurations using a USB wifi adapter I tried.
Can you grab simultaneous driver debug logging and supplicant debug
logging? Unfortunately the 'status 1' is an unspecified failure, which
could be from the AP or the firmware.
Dan
> Unfortunately it’s not ideal since the point of the Viliv N5 is that
> it’s ultra portable so I would really like to get the inbuilt wifi
> card working.
>
> It seems odd that wpa_supplicant reports the connection being
> “rejected” as seen below:
>
> wlan0: CTRL-EVENT-ASSOC-REJECT bssid=a0:63:91:1e:ee:43 status_code=1
>
> Most of the debug output sadly doesn’t mean a great deal to me - wifi
> isn’t really my area of expertise.
>
> On 21 July 2016 at 19:10:56, Christopher Williamson
> (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> >
> >
> > Sure, here are the results:
> >
> > http://termbin.com/e8e2
> >
> > Christopher Williamson
> >
> >
> > On 21 July 2016 at 16:37:24, Dan Williams (dcbw@redhat.com(mailto:d
> > cbw@redhat.com)) wrote:
> >
> > >
> > > On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
> > > >
> > > > I used NetworkManager in the previous test.
> > > >
> > > > This time around I have used wpa_supplicant directly and get
> > > > the
> > > > following results:
> > > >
> > > > http://termbin.com/j8ea
> > > >
> > > > Thought I’d throw them on a pastebin since it’s over 700 lines.
> > > Can you try with "-D nl80211" instead of using the WEXT
> > > supplicant
> > > driver? NM is likely going to use nl80211 since the driver has
> > > some
> > > support for cfg80211/nl80211 and only does WEXT through the glue
> > > layer.
> > >
> > > Dan
> > >
> > > >
> > > > Christopher Williamson
> > > >
> > > >
> > > >
> > > >
> > > > On 20 July 2016 at 22:50:34, Dan Williams
> > > > (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > > >
> > > > >
> > > > >
> > > > > On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > Hi Dan,
> > > > > >
> > > > > > Ah - yeah I hadn’t thought it may be a kernel build option.
> > > > > > I’ve
> > > > > > now
> > > > > > built that and dmesg is a much more lively place!
> > > > > >
> > > > > > I’ve provided output logs for both when the device is
> > > > > > connected
> > > > > > and
> > > > > > when a connection attempt is made - hopefully this is
> > > > > > useful.
> > > > >
> > > > > The card is scanning and only finds 'shaunthesheep' 20
> > > > > seconds
> > > > > after
> > > > > you "connect for the first time". The logs stop 3 seconds
> > > > > later.
> > > > > Are
> > > > > you connecting with wicd or something else?
> > > > >
> > > > > Can you run wpa_supplicant with the "-dddtu" option so we can
> > > > > get
> > > > > debug
> > > > > log output from it?
> > > > >
> > > > > Dan
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe
> > > > linux-
> > > > wireless" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.ht
> > > > ml
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-21 18:55 UTC (permalink / raw)
To: Dan Williams, linux-wireless@vger.kernel.org
In-Reply-To: <CANXHH3kHFDkRUTMyOheFwpJasqOmtGrQ3dG7LP_L0CBN87Aagw@mail.gmail.com>
Just to confirm - I can connect to the same network using the same
configurations using a USB wifi adapter I tried.
Unfortunately it’s not ideal since the point of the Viliv N5 is that
it’s ultra portable so I would really like to get the inbuilt wifi
card working.
It seems odd that wpa_supplicant reports the connection being
“rejected” as seen below:
wlan0: CTRL-EVENT-ASSOC-REJECT bssid=a0:63:91:1e:ee:43 status_code=1
Most of the debug output sadly doesn’t mean a great deal to me - wifi
isn’t really my area of expertise.
On 21 July 2016 at 19:10:56, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> Sure, here are the results:
>
> http://termbin.com/e8e2
>
> Christopher Williamson
>
>
> On 21 July 2016 at 16:37:24, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
>
> > On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
> > > I used NetworkManager in the previous test.
> > >
> > > This time around I have used wpa_supplicant directly and get the
> > > following results:
> > >
> > > http://termbin.com/j8ea
> > >
> > > Thought I’d throw them on a pastebin since it’s over 700 lines.
> >
> > Can you try with "-D nl80211" instead of using the WEXT supplicant
> > driver? NM is likely going to use nl80211 since the driver has some
> > support for cfg80211/nl80211 and only does WEXT through the glue
> > layer.
> >
> > Dan
> >
> > > Christopher Williamson
> > >
> > >
> > >
> > >
> > > On 20 July 2016 at 22:50:34, Dan Williams
> > > (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > >
> > > >
> > > > On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson wrote:
> > > > >
> > > > > Hi Dan,
> > > > >
> > > > > Ah - yeah I hadn’t thought it may be a kernel build option. I’ve
> > > > > now
> > > > > built that and dmesg is a much more lively place!
> > > > >
> > > > > I’ve provided output logs for both when the device is connected
> > > > > and
> > > > > when a connection attempt is made - hopefully this is useful.
> > > >
> > > >
> > > > The card is scanning and only finds 'shaunthesheep' 20 seconds
> > > > after
> > > > you "connect for the first time". The logs stop 3 seconds later.
> > > > Are
> > > > you connecting with wicd or something else?
> > > >
> > > > Can you run wpa_supplicant with the "-dddtu" option so we can get
> > > > debug
> > > > log output from it?
> > > >
> > > > Dan
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-
> > > wireless" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-21 18:10 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <1469115440.29944.1.camel@redhat.com>
Sure, here are the results:
http://termbin.com/e8e2
Christopher Williamson
On 21 July 2016 at 16:37:24, Dan Williams
(dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
> > I used NetworkManager in the previous test.
> >
> > This time around I have used wpa_supplicant directly and get the
> > following results:
> >
> > http://termbin.com/j8ea
> >
> > Thought I’d throw them on a pastebin since it’s over 700 lines.
>
> Can you try with "-D nl80211" instead of using the WEXT supplicant
> driver? NM is likely going to use nl80211 since the driver has some
> support for cfg80211/nl80211 and only does WEXT through the glue
> layer.
>
> Dan
>
> > Christopher Williamson
> >
> >
> >
> >
> > On 20 July 2016 at 22:50:34, Dan Williams
> > (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> >
> > >
> > > On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson wrote:
> > > >
> > > > Hi Dan,
> > > >
> > > > Ah - yeah I hadn’t thought it may be a kernel build option. I’ve
> > > > now
> > > > built that and dmesg is a much more lively place!
> > > >
> > > > I’ve provided output logs for both when the device is connected
> > > > and
> > > > when a connection attempt is made - hopefully this is useful.
> > >
> > >
> > > The card is scanning and only finds 'shaunthesheep' 20 seconds
> > > after
> > > you "connect for the first time". The logs stop 3 seconds later.
> > > Are
> > > you connecting with wicd or something else?
> > >
> > > Can you run wpa_supplicant with the "-dddtu" option so we can get
> > > debug
> > > log output from it?
> > >
> > > Dan
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> > wireless" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ath9k: fix misleading indent
From: Bob Copeland @ 2016-07-21 16:31 UTC (permalink / raw)
To: linux-wireless; +Cc: Bob Copeland
Fixes smatch warning:
ath9k_vif_iter_set_beacon() warn if statement not indented
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath9k/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 7594650..70ca746 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -919,7 +919,7 @@ static void ath9k_vif_iter_set_beacon(struct ath9k_vif_iter_data *iter_data,
} else {
if (iter_data->primary_beacon_vif->type != NL80211_IFTYPE_AP &&
vif->type == NL80211_IFTYPE_AP)
- iter_data->primary_beacon_vif = vif;
+ iter_data->primary_beacon_vif = vif;
}
iter_data->beacons = true;
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 5/9] mwifiex: cfg80211 set_default_mgmt_key handler
From: Jouni Malinen @ 2016-07-21 15:51 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Kalle Valo, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam
In-Reply-To: <33207c0c98c646548bdedf50449719c2@SC-EXCH04.marvell.com>
On Thu, Jul 21, 2016 at 09:18:11AM +0000, Amitkumar Karwar wrote:
> > From: Kalle Valo [mailto:kvalo@codeaurora.org]
> > Is it correct to ignore the key index? I see that brcmfmac ignores it as
> > well but I want to still confirm this.
> >
> > Does this mean that with this patcfh mwifiex properly supports MFP?
>
> Yes. We do pass MFP tests with this patch.
Did you test IGTK rekeying? This patch looks exactly as broken as it did
the last time it was proposed more than a year ago and after the same
concern not receiving any reaction.. hostapd will configure two
different IGTKs with different Key IDs and change the TX key on the AP
once all associated STAs have the new key. If the driver does not
support updating the TX key index, either the old or the new STAs
associated after rekeying will not have the correct key.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [PATCH] iw: display 5/10 MHz channel widths
From: Bob Copeland @ 2016-07-21 15:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Bob Copeland
iw was showing 'width: unknown' for channels on OCB interfaces; teach
it the values for 5/10 MHz so it will show the configured width.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
interface.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/interface.c b/interface.c
index 209561d..2802235 100644
--- a/interface.c
+++ b/interface.c
@@ -295,6 +295,10 @@ char *channel_width_name(enum nl80211_chan_width width)
return "80+80 MHz";
case NL80211_CHAN_WIDTH_160:
return "160 MHz";
+ case NL80211_CHAN_WIDTH_5:
+ return "5 MHz";
+ case NL80211_CHAN_WIDTH_10:
+ return "10 MHz";
default:
return "unknown";
}
--
2.9.0
^ permalink raw reply related
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Dan Williams @ 2016-07-21 15:37 UTC (permalink / raw)
To: Christopher Williamson, linux-wireless@vger.kernel.org
In-Reply-To: <CANXHH3n0=dmV+2D9FeOoGuqDvKJHdpnOMdYH1Ecr3TACJ5FXYQ@mail.gmail.com>
On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
> I used NetworkManager in the previous test.
>
> This time around I have used wpa_supplicant directly and get the
> following results:
>
> http://termbin.com/j8ea
>
> Thought I’d throw them on a pastebin since it’s over 700 lines.
Can you try with "-D nl80211" instead of using the WEXT supplicant
driver? NM is likely going to use nl80211 since the driver has some
support for cfg80211/nl80211 and only does WEXT through the glue
layer.
Dan
> Christopher Williamson
>
>
>
>
> On 20 July 2016 at 22:50:34, Dan Williams
> (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
>
> >
> > On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson wrote:
> > >
> > > Hi Dan,
> > >
> > > Ah - yeah I hadn’t thought it may be a kernel build option. I’ve
> > > now
> > > built that and dmesg is a much more lively place!
> > >
> > > I’ve provided output logs for both when the device is connected
> > > and
> > > when a connection attempt is made - hopefully this is useful.
> >
> >
> > The card is scanning and only finds 'shaunthesheep' 20 seconds
> > after
> > you "connect for the first time". The logs stop 3 seconds later.
> > Are
> > you connecting with wicd or something else?
> >
> > Can you run wpa_supplicant with the "-dddtu" option so we can get
> > debug
> > log output from it?
> >
> > Dan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC
From: Amitkumar Karwar @ 2016-07-21 15:22 UTC (permalink / raw)
To: Luana Borgia; +Cc: Nestor Machno, linux-wireless@vger.kernel.org
In-Reply-To: <CAD3r-iSu5TSQxQckp30ZE1cyOC7tsJtmZbQ911bd6KQjOP5CaA@mail.gmail.com>
PiBGcm9tOiBMdWFuYSBCb3JnaWEgW21haWx0bzpsdWFuYWJvcmdpYTE5NjlAZ21haWwuY29tXQ0K
PiBTZW50OiBUaHVyc2RheSwgSnVseSAyMSwgMjAxNiA2OjA1IFBNDQo+IFRvOiBBbWl0a3VtYXIg
S2Fyd2FyDQo+IENjOiBOZXN0b3IgTWFjaG5vOyBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5v
cmcNCj4gU3ViamVjdDogUmU6IG13aWZpZXgrd3BhX3N1cHBsaWNhbnQgY2Fubm90IHNldCB1cCBX
UEEvV1BBMiBBREhPQw0KPiANCj4gSGkgQW1pdGt1bWFyLA0KPiBpZiBJIHVuZGVyc3Rvb2QgY29y
cmVjdGx5IHlvdSBhcmUgd29ya2luZyB0byBzb2x2ZSB0aGUgaXNzdWUgcmVsYXRlZCB0bw0KPiBp
YnNzLXJzbiAod3BhMiBpbiBhZGhvYyksIEknbSBJIHJpZ2h0Pw0KPiBXaGF0IGFib3V0IHRoZSBh
bHRlcm5hdGl2ZSBXUEEgbWVjaGFuaXNtIHdpdGggd3BhLW5vbmUgaW5zdGVhZD8gRml4IGl0DQo+
IHNob3VsZG4ndCBiZSBzaW1wbGVyIHRoYW4gUlNOPw0KDQpNYWtlcyBzZW5zZS4gSXQgd291bGQg
YmUgdXNlZnVsIHRvIGhhdmUgc3VjY2Vzc2Z1bCBjYXNlIGxvZyBmb3IgY29tcGFyaXNvbiBhbmQg
ZnVydGhlciBkZWJ1Z2dpbmcuDQpJcyBpdCBwb3NzaWJsZSBmb3IgeW91IChvciBzb21lb25lIGVs
c2UpIGNhcHR1cmUgdGhlIHdwYV9zdXBwbGljYW50J3Mgc3VjY2Vzc2Z1bCBjYXNlIGxvZ3MgdXNp
bmcgb3RoZXIgdmVuZG9yJ3MgY2hpcHNldD8NCldlIHRyaWVkIHdpdGggSW50ZWwgZGV2aWNlcy4g
SXQgd29ya2VkIHVzaW5nIEdVSSBvbiB3aW5kb3dzIG1hY2hpbmUsIGJ1dCBkaWRuJ3Qgd29yayB1
c2luZyB3cGFfc3VwcGxpY2FudC4NCg0KUmVnYXJkcywNCkFtaXRrdW1hcg0K
^ permalink raw reply
* RE: [PATCH] mwifiex: fix large amsdu packets causing firmware hang
From: Amitkumar Karwar @ 2016-07-21 14:55 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <8737n39hdl.fsf@purkki.adurom.net>
> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] On Behalf Of Kalle Valo
> Sent: Thursday, July 21, 2016 8:19 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam
> Subject: Re: [PATCH] mwifiex: fix large amsdu packets causing firmware
> hang
>
> Amitkumar Karwar <akarwar@marvell.com> writes:
>
> > From: Cathy Luo <cluo@marvell.com>
> >
> > Sometimes host prepares and downloads a large amsdu packet to firmware
> > which leads to a memory corruption in firmware.
> > The reason is __dev_alloc_skb() may allocate larger buffer than
> > required size. This patch solves the problem by checking "adapter-
> >tx_buf_size"
> > instead of relying on skb_tailroom().
> >
> > Signed-off-by: Cathy Luo <cluo@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
>
> Should this go to 4.8 as an important fix?
>
Yes. Please.
Regards,
Amitkumar.
^ permalink raw reply
* Re: [PATCH] mwifiex: fix large amsdu packets causing firmware hang
From: Kalle Valo @ 2016-07-21 14:48 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <1469098824-8031-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
> From: Cathy Luo <cluo@marvell.com>
>
> Sometimes host prepares and downloads a large amsdu packet to firmware
> which leads to a memory corruption in firmware.
> The reason is __dev_alloc_skb() may allocate larger buffer than required
> size. This patch solves the problem by checking "adapter->tx_buf_size"
> instead of relying on skb_tailroom().
>
> Signed-off-by: Cathy Luo <cluo@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Should this go to 4.8 as an important fix?
--
Kalle Valo
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-21 13:02 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <CANXHH3n0=dmV+2D9FeOoGuqDvKJHdpnOMdYH1Ecr3TACJ5FXYQ@mail.gmail.com>
Tried a few more things worth mentioning:
- Tried connecting with wpa_supplicant & dhclient only but sadly
wpa_supplicant still cannot seem to hold a connection to the base
station.
It looks like the relevant errors here may be:
ioctl[SIOCSIWENCODEEXT]: Invalid argument
wlan0: Trying to associate with a0:63:91:1e:ee:43
(SSID='shaunthesheep' freq=2457 MHz)
ioctl[SIOCSIWFREQ]: Device or resource busy
wlan0: Association request to the driver failed
- Tried NetworkManager again and also tried wicd - both have similar
problems. I expect since they both use wpa_supplicant the issue was
unlikely to not be there for either of these solutions but I figured
it was worth experimenting with.
- I also tried kernel 4.6.4 and noticed no difference there either so
it looks like the same issue is present in the latest stable kernel as
well as the latest longterm kernel (which Ubuntu uses for 16.04 LTS.)
Christopher Williamson
On 20 July 2016 at 23:16:41, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> I used NetworkManager in the previous test.
>
> This time around I have used wpa_supplicant directly and get the following results:
>
> http://termbin.com/j8ea
>
> Thought I’d throw them on a pastebin since it’s over 700 lines.
>
> Christopher Williamson
>
>
>
>
> On 20 July 2016 at 22:50:34, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
>
> > On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson wrote:
> > > Hi Dan,
> > >
> > > Ah - yeah I hadn’t thought it may be a kernel build option. I’ve now
> > > built that and dmesg is a much more lively place!
> > >
> > > I’ve provided output logs for both when the device is connected and
> > > when a connection attempt is made - hopefully this is useful.
> >
> >
> >
> > The card is scanning and only finds 'shaunthesheep' 20 seconds after
> > you "connect for the first time". The logs stop 3 seconds later. Are
> > you connecting with wicd or something else?
> >
> > Can you run wpa_supplicant with the "-dddtu" option so we can get debug
> > log output from it?
> >
> > Dan
^ permalink raw reply
* Re: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC
From: Luana Borgia @ 2016-07-21 12:34 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: Nestor Machno, linux-wireless@vger.kernel.org
In-Reply-To: <c18d3a077345402d83a4d12f1d75f07d@SC-EXCH04.marvell.com>
Hi Amitkumar,
if I understood correctly you are working to solve the issue related
to ibss-rsn (wpa2 in adhoc), I'm I right?
What about the alternative WPA mechanism with wpa-none instead? Fix it
shouldn't be simpler than RSN?
Thanks for update and
best regards.
Luana
2016-07-21 11:05 GMT+02:00 Amitkumar Karwar <akarwar@marvell.com>:
> Hi Luana,
>
>> From: Luana Borgia [mailto:luanaborgia1969@gmail.com]
>> Sent: Wednesday, July 20, 2016 6:53 PM
>> To: Amitkumar Karwar
>> Cc: Nestor Machno; linux-wireless@vger.kernel.org
>> Subject: Re: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC
>>
>> Hi Amitkumar,
>> any news about this issue? I've the same problem also..
>>
>> Security a part, we can't leave the WIFI open or just with WEP because
>> we get too many not trusted connection that consume a lot of our
>> bandwidth
>>
>
> We are still working on this. With some driver changes, we are able to RSN IE in transmitted frames, but 4 way handshake doesn't occur.
>
> Regards,
> Amitkumar
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Prarit Bhargava @ 2016-07-21 12:01 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Emmanuel Grumbach, Michal Kazior, Kalle Valo, linux-wireless,
ath10k, Arend van Spriel, Greg Kroah-Hartman, Ming Lei
In-Reply-To: <20160721115122.GA31869@redhat.com>
On 07/21/2016 07:51 AM, Stanislaw Gruszka wrote:
> (cc: firmware and brcmfmac maintainers)
<snip>
>>>
>>> I'm not sure if replacing to request_firmware_direct() is a good
>>> fix though. For example I can see this problem also on brcmfmac, which
>>> use request_firmware_nowait(). I think I would rather prefer special
>>> helper for firmware drivers that needs user helper and have
>>> request_firmware() be direct as default.
>>>
>>
>> The difference between request_firmware_direct() and request_firmware() is that
>> the _direct() version does not wait the 60 seconds for udev interaction. The
>> only userspace check performed is to see if the file is there, and if the file
>> does exist it is provided to the driver to be applied to the hardware.
>>
>> So the real question to ask here is whether or not the ath10k, brcmfmac, and
>> iwlwifi require udev to do anything beyond checking for the existence and
>> loading the firmware image. If they don't, then it is better to use
>> request_firmware_direct().
>
> They don't need that, like 99% of the drivers I think, hence changing the
> default seems to be more reasonable. However changing 3 drivers would work
I think I argued for that a while back and changing the default was rejected.
I can't remember why it was rejected :(. It may have had something to do with
the complexity of getting a large number of driver maintainers to ack the change.
> for me as well, and that change do not introduce risk of broking drivers
> that require udev fw download.
In my experience, there are very few drivers that actually require userspace
interaction beyond verifying the image location. (The one that comes to mind is
the dell_rbu driver which attempts to download FW images)
>
> iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
> use request_firmware_nowait(), so it first need to be converted to
> ordinary request_firmware(), but this should be doable and I can do
> that.
>
> However I wonder if changing that will not broke the case when
> driver is build-in in the kernel and f/w is not yet available when
> driver start to initialize.
As you say below ...
Or maybe nowadays this is not the case
> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
> images are build-in in the kernel or copied to initramfs?
This is correct AFAIU. If MODULE_FIRMWARE=y then the firmware should be loaded
into the kernel image temp fs and/or initramfs. This of course assumes that the
person building the image is smart enough to have installed the FW on their system.
P.
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Stanislaw Gruszka @ 2016-07-21 11:51 UTC (permalink / raw)
To: Prarit Bhargava
Cc: Emmanuel Grumbach, Michal Kazior, Kalle Valo, linux-wireless,
ath10k, Arend van Spriel, Greg Kroah-Hartman, Ming Lei
In-Reply-To: <5790A28F.8030102@redhat.com>
(cc: firmware and brcmfmac maintainers)
On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
>
>
> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
> > On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
> >> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
> >>>> Firmware files are versioned to prevent older
> >>>> driver instances to load unsupported firmware
> >>>> blobs. This is reflected with a fallback logic
> >>>> which attempts to load several firmware files.
> >>>>
> >>>> This however produced a lot of unnecessary
> >>>> warnings sometimes confusing users and leading
> >>>> them to rename firmware files making things even
> >>>> more confusing.
> >>>
> >>> This happens on kernels configured with
> >>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
> >>> but also 60 seconds delay before loading next firmware version.
> >>> For some reason RHEL kernel needs above config option, so this
> >>> patch is very welcome from my perspective.
> >>>
> >>
> >> Sorry for my ignorance but how does the firmware loading work if not
> >> with udev's help?
> >
> > I'm not sure exactly, but I think kernel VFS layer is capable to copy
> > file data directly from mounted filesystem without user space helper.
>
> Here's the situation: request_firmware() waits 60 seconds for udev to do its
> loading magic via a "usermode helper". This delay is there to allow, for
> example, userspace to unpack or download a new firmware image or verify the
> firmware image *in userspace* before providing it to the driver to apply to the HW.
>
> Why 60 seconds? It is arbitrary and there is no way for udev & the kernel to
> handshake on completion.
>
> >
> >> As you can imagine, iwlwifi is suffering from the
> >> same problem and I would be interested in applying the same change,
> >> but I'd love to understand a bit more :)
> >
> > Yes, iwlwifi (and some other drivers) suffer from this. However this
> > happen when the newest firmware version is not installed on the system
> > and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
> > it's not common.
>
> request_firmware_direct() was introduced at my request because (as you've
> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
> periods of time when starting. The bug that this introduced was a 60 second
> delay per logical cpu when starting a system. On a 64 cpu system that meant the
> boot would complete in a little over one hour.
>
> >
> > I started to see this currently, because that option was enabled on
> > RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
> > happened because of that, i.e. thermal device was not functional
> > because f/w wasn't loaded due to big delay.
> >
> > I'm not sure if replacing to request_firmware_direct() is a good
> > fix though. For example I can see this problem also on brcmfmac, which
> > use request_firmware_nowait(). I think I would rather prefer special
> > helper for firmware drivers that needs user helper and have
> > request_firmware() be direct as default.
> >
>
> The difference between request_firmware_direct() and request_firmware() is that
> the _direct() version does not wait the 60 seconds for udev interaction. The
> only userspace check performed is to see if the file is there, and if the file
> does exist it is provided to the driver to be applied to the hardware.
>
> So the real question to ask here is whether or not the ath10k, brcmfmac, and
> iwlwifi require udev to do anything beyond checking for the existence and
> loading the firmware image. If they don't, then it is better to use
> request_firmware_direct().
They don't need that, like 99% of the drivers I think, hence changing the
default seems to be more reasonable. However changing 3 drivers would work
for me as well, and that change do not introduce risk of broking drivers
that require udev fw download.
iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
use request_firmware_nowait(), so it first need to be converted to
ordinary request_firmware(), but this should be doable and I can do
that.
However I wonder if changing that will not broke the case when
driver is build-in in the kernel and f/w is not yet available when
driver start to initialize. Or maybe nowadays this is not the case
any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
images are build-in in the kernel or copied to initramfs?
Thanks
Stanislaw
^ permalink raw reply
* [PATCH] mwifiex: fix large amsdu packets causing firmware hang
From: Amitkumar Karwar @ 2016-07-21 11:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
From: Cathy Luo <cluo@marvell.com>
Sometimes host prepares and downloads a large amsdu packet to firmware
which leads to a memory corruption in firmware.
The reason is __dev_alloc_skb() may allocate larger buffer than required
size. This patch solves the problem by checking "adapter->tx_buf_size"
instead of relying on skb_tailroom().
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/11n_aggr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_aggr.c b/drivers/net/wireless/marvell/mwifiex/11n_aggr.c
index dc49c3d..c47d636 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_aggr.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_aggr.c
@@ -205,7 +205,8 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
do {
/* Check if AMSDU can accommodate this MSDU */
- if (skb_tailroom(skb_aggr) < (skb_src->len + LLC_SNAP_LEN))
+ if ((skb_aggr->len + skb_src->len + LLC_SNAP_LEN) >
+ adapter->tx_buf_size)
break;
skb_src = skb_dequeue(&pra_list->skb_head);
--
1.9.1
^ permalink raw reply related
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Prarit Bhargava @ 2016-07-21 10:23 UTC (permalink / raw)
To: Stanislaw Gruszka, Emmanuel Grumbach
Cc: Michal Kazior, Kalle Valo, linux-wireless, ath10k
In-Reply-To: <20160721080541.GB2658@redhat.com>
On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>>>> Firmware files are versioned to prevent older
>>>> driver instances to load unsupported firmware
>>>> blobs. This is reflected with a fallback logic
>>>> which attempts to load several firmware files.
>>>>
>>>> This however produced a lot of unnecessary
>>>> warnings sometimes confusing users and leading
>>>> them to rename firmware files making things even
>>>> more confusing.
>>>
>>> This happens on kernels configured with
>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
>>> but also 60 seconds delay before loading next firmware version.
>>> For some reason RHEL kernel needs above config option, so this
>>> patch is very welcome from my perspective.
>>>
>>
>> Sorry for my ignorance but how does the firmware loading work if not
>> with udev's help?
>
> I'm not sure exactly, but I think kernel VFS layer is capable to copy
> file data directly from mounted filesystem without user space helper.
Here's the situation: request_firmware() waits 60 seconds for udev to do its
loading magic via a "usermode helper". This delay is there to allow, for
example, userspace to unpack or download a new firmware image or verify the
firmware image *in userspace* before providing it to the driver to apply to the HW.
Why 60 seconds? It is arbitrary and there is no way for udev & the kernel to
handshake on completion.
>
>> As you can imagine, iwlwifi is suffering from the
>> same problem and I would be interested in applying the same change,
>> but I'd love to understand a bit more :)
>
> Yes, iwlwifi (and some other drivers) suffer from this. However this
> happen when the newest firmware version is not installed on the system
> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
> it's not common.
request_firmware_direct() was introduced at my request because (as you've
noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
periods of time when starting. The bug that this introduced was a 60 second
delay per logical cpu when starting a system. On a 64 cpu system that meant the
boot would complete in a little over one hour.
>
> I started to see this currently, because that option was enabled on
> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
> happened because of that, i.e. thermal device was not functional
> because f/w wasn't loaded due to big delay.
>
> I'm not sure if replacing to request_firmware_direct() is a good
> fix though. For example I can see this problem also on brcmfmac, which
> use request_firmware_nowait(). I think I would rather prefer special
> helper for firmware drivers that needs user helper and have
> request_firmware() be direct as default.
>
The difference between request_firmware_direct() and request_firmware() is that
the _direct() version does not wait the 60 seconds for udev interaction. The
only userspace check performed is to see if the file is there, and if the file
does exist it is provided to the driver to be applied to the hardware.
So the real question to ask here is whether or not the ath10k, brcmfmac, and
iwlwifi require udev to do anything beyond checking for the existence and
loading the firmware image. If they don't, then it is better to use
request_firmware_direct().
P.
> Stanislaw
>
^ permalink raw reply
* RE: [PATCH 6/9] mwifiex: process rxba_sync event
From: Amitkumar Karwar @ 2016-07-21 9:48 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
Xinming Hu
In-Reply-To: <87mvlex3jx.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Monday, July 18, 2016 10:54 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> Xinming Hu
> Subject: Re: [PATCH 6/9] mwifiex: process rxba_sync event
>
> Amitkumar Karwar <akarwar@marvell.com> writes:
>
> > From: Xinming Hu <huxm@marvell.com>
> >
> > Firmware may filter and drop packets under certain condition, for
> > example, ARP SA=DA packet. this event will be used to synchronize the
> > Rx Block Acknowledgment (BA) window bitmap and to fill any holes in
> > driver side.
> >
> > Signed-off-by: Xinming Hu <huxm@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
>
> [...]
>
> > --- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> > @@ -78,8 +78,15 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct
> mwifiex_private *priv,
> > */
> > static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv,
> > void *payload) {
> > - int ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload);
> >
> > + int ret;
> > +
> > + if (payload == (void *)MWIFIEX_RX_PKT_DROPPED_IN_FW) {
> > + mwifiex_dbg(priv->adapter, INFO, "info: fw drop data\n");
> > + return 0;
> > + }
>
> [...]
>
> > + mwifiex_dbg(priv->adapter, ERROR,
> > + "drop packet,seq=%d\n",
> > + seq_num);
> > +
> > + ret = mwifiex_11n_rx_reorder_pkt
> > + (priv, seq_num, tlv_rxba->tid,
> > + tlv_rxba->mac, 0,
> > + (void *)MWIFIEX_RX_PKT_DROPPED_IN_FW);
>
> [...]
>
> > +/* Indicate packet has been dropped in FW */
> > +#define MWIFIEX_RX_PKT_DROPPED_IN_FW 0xffffffff
>
> That pointer magic is rather ugly, why not use a proper boolean?
>
Thanks for review. I will get rid of this macro and submit updated version.
Regards,
Amitkumar
^ permalink raw reply
* RE: [PATCH 5/9] mwifiex: cfg80211 set_default_mgmt_key handler
From: Amitkumar Karwar @ 2016-07-21 9:18 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <87r3aqx3sq.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Monday, July 18, 2016 10:49 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam
> Subject: Re: [PATCH 5/9] mwifiex: cfg80211 set_default_mgmt_key handler
>
> Amitkumar Karwar <akarwar@marvell.com> writes:
>
> > It is observed that hostapd fails to setup with management frame
> > protection mode enabled when using mwifiex. This patch adds
> > cfg80211_set_default_mgmt_key handler to resolve the problem.
> >
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > ---
> > drivers/net/wireless/marvell/mwifiex/cfg80211.c | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> > b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> > index 8955f8c..bf95cca 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> > @@ -484,6 +484,18 @@ mwifiex_cfg80211_add_key(struct wiphy *wiphy,
> > struct net_device *netdev, }
> >
> > /*
> > + * CFG802.11 operation handler to set default mgmt key.
> > + */
> > +static int
> > +mwifiex_cfg80211_set_default_mgmt_key(struct wiphy *wiphy,
> > + struct net_device *netdev,
> > + u8 key_index)
> > +{
> > + wiphy_dbg(wiphy, "set default mgmt key, key index=%d\n",
> key_index);
> > + return 0;
> > +}
> > +
> > +/*
> > * This function sends domain information to the firmware.
> > *
> > * The following information are passed to the firmware - @@ -4002,6
> > +4014,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
> > .leave_ibss = mwifiex_cfg80211_leave_ibss,
> > .add_key = mwifiex_cfg80211_add_key,
> > .del_key = mwifiex_cfg80211_del_key,
> > + .set_default_mgmt_key = mwifiex_cfg80211_set_default_mgmt_key,
> > .mgmt_tx = mwifiex_cfg80211_mgmt_tx,
> > .mgmt_frame_register = mwifiex_cfg80211_mgmt_frame_register,
> > .remain_on_channel = mwifiex_cfg80211_remain_on_channel,
>
> Is it correct to ignore the key index? I see that brcmfmac ignores it as
> well but I want to still confirm this.
>
> Does this mean that with this patcfh mwifiex properly supports MFP?
>
Yes. We do pass MFP tests with this patch.
Regards,
Amitkumar
^ permalink raw reply
* RE: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC
From: Amitkumar Karwar @ 2016-07-21 9:05 UTC (permalink / raw)
To: Luana Borgia; +Cc: Nestor Machno, linux-wireless@vger.kernel.org
In-Reply-To: <CAD3r-iQScbuUiGiF3uDKzMk-0mycG3WVFDGaYCy6aPxAEjq3mg@mail.gmail.com>
SGkgTHVhbmEsDQoNCj4gRnJvbTogTHVhbmEgQm9yZ2lhIFttYWlsdG86bHVhbmFib3JnaWExOTY5
QGdtYWlsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDIwLCAyMDE2IDY6NTMgUE0NCj4g
VG86IEFtaXRrdW1hciBLYXJ3YXINCj4gQ2M6IE5lc3RvciBNYWNobm87IGxpbnV4LXdpcmVsZXNz
QHZnZXIua2VybmVsLm9yZw0KPiBTdWJqZWN0OiBSZTogbXdpZmlleCt3cGFfc3VwcGxpY2FudCBj
YW5ub3Qgc2V0IHVwIFdQQS9XUEEyIEFESE9DDQo+IA0KPiBIaSBBbWl0a3VtYXIsDQo+IGFueSBu
ZXdzIGFib3V0IHRoaXMgaXNzdWU/IEkndmUgdGhlIHNhbWUgcHJvYmxlbSBhbHNvLi4NCj4gDQo+
IFNlY3VyaXR5IGEgcGFydCwgd2UgY2FuJ3QgbGVhdmUgdGhlIFdJRkkgb3BlbiBvciBqdXN0IHdp
dGggV0VQIGJlY2F1c2UNCj4gd2UgZ2V0IHRvbyBtYW55IG5vdCB0cnVzdGVkIGNvbm5lY3Rpb24g
dGhhdCBjb25zdW1lIGEgbG90IG9mIG91cg0KPiBiYW5kd2lkdGgNCj4gDQoNCldlIGFyZSBzdGls
bCB3b3JraW5nIG9uIHRoaXMuIFdpdGggc29tZSBkcml2ZXIgY2hhbmdlcywgd2UgYXJlIGFibGUg
dG8gUlNOIElFIGluIHRyYW5zbWl0dGVkIGZyYW1lcywgYnV0IDQgd2F5IGhhbmRzaGFrZSBkb2Vz
bid0IG9jY3VyLg0KDQpSZWdhcmRzLA0KQW1pdGt1bWFyDQo=
^ permalink raw reply
* Re: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC
From: Nestor Machno @ 2016-07-21 8:30 UTC (permalink / raw)
To: Luana Borgia, Amitkumar Karwar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAD3r-iQScbuUiGiF3uDKzMk-0mycG3WVFDGaYCy6aPxAEjq3mg@mail.gmail.com>
Luana,
as confirmed by Marvell this is a firmware issue and the firmware is
not free/open so only Marvell is able to fix it.
At the moment the latest firmware available is still the 15.68.7.p5, aka p5.
http://git.marvell.com/?p=mwifiex-firmware.git;a=tree;f=mrvl;hb=HEAD
Unfortunately in this case the community can't give you support..
Regards
Nestor
2016-07-20 15:23 GMT+02:00 Luana Borgia <luanaborgia1969@gmail.com>:
> Hi Amitkumar,
> any news about this issue? I've the same problem also..
>
> Security a part, we can't leave the WIFI open or just with WEP because
> we get too many not trusted connection that consume a lot of our
> bandwidth
>
> Thanks, regards
> Luana
>
> 2016-07-08 11:15 GMT+02:00 Amitkumar Karwar <akarwar@marvell.com>:
>> Yes. This is a bug in our firmware. ADHOC in WPA/WPA2 security is broken. We have asked firmware experts to look into this. As we have a mid-year shutdown this week, they will be able to check the problem next week only. However ADHOC in open mode should work as expected
>>
>>
>> Regards,
>> Amitkumar
^ permalink raw reply
* [PATCH] hostap: Use memdup_user() to reuse code
From: Rajan Vaja @ 2016-07-21 8:14 UTC (permalink / raw)
To: j; +Cc: kvalo, linux-wireless
Fix coccicheck warning which recommends to
use memdup_user() instead of reimplementing its
code.
This patch fixes below coccicheck warnings:
drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3044:9-16: WARNING
opportunity for memdup_user
drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3806:9-16: WARNING
opportunity for memdup_user
Signed-off-by: Rajan Vaja <rajan.vaja@gmail.com>
---
drivers/net/wireless/intersil/hostap/hostap_ioctl.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
index 3e5fa78..a5656bc 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
@@ -3041,13 +3041,9 @@ static int prism2_ioctl_priv_download(local_info_t *local, struct iw_point *p)
p->length > 1024 || !p->pointer)
return -EINVAL;
- param = kmalloc(p->length, GFP_KERNEL);
- if (param == NULL)
- return -ENOMEM;
-
- if (copy_from_user(param, p->pointer, p->length)) {
- ret = -EFAULT;
- goto out;
+ param = memdup_user(p->pointer, p->length);
+ if (IS_ERR(param)) {
+ return PTR_ERR(param);
}
if (p->length < sizeof(struct prism2_download_param) +
@@ -3803,13 +3799,9 @@ static int prism2_ioctl_priv_hostapd(local_info_t *local, struct iw_point *p)
p->length > PRISM2_HOSTAPD_MAX_BUF_SIZE || !p->pointer)
return -EINVAL;
- param = kmalloc(p->length, GFP_KERNEL);
- if (param == NULL)
- return -ENOMEM;
-
- if (copy_from_user(param, p->pointer, p->length)) {
- ret = -EFAULT;
- goto out;
+ param = memdup_user(p->pointer, p->length);
+ if (IS_ERR(param)) {
+ return PTR_ERR(param);
}
switch (param->cmd) {
--
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