* Re: [v2] ath9k: simplify the code-paths when not using the built-in EEPROM
From: Kalle Valo @ 2016-07-19 17:57 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, linux-wireless, ath9k-devel, nbd,
Martin Blumenstingl
In-Reply-To: <20160709230955.27266-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> There were two paths in the code for "external" eeprom sources. The code
> in eeprom.c only handled the cases where the eeprom data was loaded via
> request_firmware. ahb.c and pci.c on the other hand had some duplicate
> code which was only used when the eeprom data was passed via
> ath9k_platform_data.
> With this change all eeprom data handling is now unified in eeprom.c.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
563985199693 ath9k: simplify the code-paths when not using the built-in EEPROM
--
Sent by pwcli
https://patchwork.kernel.org/patch/9222187/
^ permalink raw reply
* Re: ath6kl: sme_state shortcut to SME_DISCONNECTED removed
From: Kalle Valo @ 2016-07-19 17:56 UTC (permalink / raw)
To: engineering; +Cc: ath6kl, linux-wireless
In-Reply-To: <1468026259-25148-1-git-send-email-dan.kephart@lairdtech.com>
engineering@keppy.com wrote:
> From: Dan Kephart <dan.kephart@lairdtech.com>
>
> When an NL80211_DISCONNECT is sent to cfg80211, the driver's cfg80211
> disconnect function sets the sme_state to SME_DISCONNECTED before receiving
> a WMI_DISCONNECT_EVENT from the firmware. This caused cfg80211 to not know
> that the connection is disconnected because the driver fails to notify
> cfg80211 upon receiving WMI_DISCONNECT_EVENT from the firmware believing
> it is already disconnected.
>
> Signed-off-by: Dan Kephart <dan.kephart@lairdtech.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
42e54152e707 ath6kl: sme_state shortcut to SME_DISCONNECTED removed
--
Sent by pwcli
https://patchwork.kernel.org/patch/9221927/
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-19 17:41 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <CANXHH3kKV4m6rw9O=6x_QT2vwr7Tnx9EddpFq1VXfhnVdg9pFg@mail.gmail.com>
So I’ve now disabled IPv6 and have set the GB (Great Britain)
regulation code using:
iw reg set IN
Now when I try to connect to the network using wicd the system seems
to crash - I guess at least it’s doing something more than just asking
for the password again like it did with NetworkManager but so far no
further progress on getting this working properly.
Christopher Williamson
On 19 July 2016 at 18:03:16, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> Absolutely!
>
> With the debug logging enabled I got the following:
>
> Connecting the device initially with debug enabled:
>
> [ 205.302685] libertas_sdio: Libertas SDIO driver
> [ 205.302698] libertas_sdio: Copyright Pierre Ossman
> [ 205.503465] cfg80211: World regulatory domain updated:
> [ 205.503478] cfg80211: DFS Master region: unset
> [ 205.503483] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
> [ 205.503492] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
> [ 205.503499] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
> [ 205.503505] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
> [ 205.503513] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
> [ 205.503522] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
> [ 205.503529] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
> [ 205.503535] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
> [ 205.503542] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
> [ 212.249171] gma500 0000:00:02.0: Backlight lvds set brightness 7a127a12
> [ 212.324898] mmc1: new SDIO card at address 0001
> [ 212.921672] libertas_sdio mmc1:0001:1 (unnamed net_device) (uninitialized): 00:02:78:69:49:94, fw 9.70.20p0, cap 0x00000303
> [ 212.925774] libertas_sdio mmc1:0001:1 (unnamed net_device) (uninitialized): PREP_CMD: command 0x00a3 failed: 2
> [ 212.936190] libertas_sdio mmc1:0001:1 wlan0: Marvell WLAN 802.11 adapter
> [ 213.053612] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>
>
> Strangely when I attempt to connect to the WiFi network I’m using the only error I get is:
>
> [ 338.076632] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>
> I was expecting more output and am guessing I’ve missed something here.
>
> Christopher Williamson
>
> On 19 July 2016 at 17:38:35, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
>
> > On Tue, 2016-07-19 at 12:06 -0400, Christopher Williamson wrote:
> > > Hi everyone!
> > >
> > > I’ve just got myself a Viliv N5 and am trying to get the integrated
> > > Wifi chipset working on it.
> > >
> > > I am able to see networks around me but any attempts to connect them
> > > appear to time out and fail.
> > >
> > > I have filed a linux kernel bug related to this issue:
> > > https://bugzilla.kernel.org/show_bug.cgi?id=135421goo
> > >
> > > I figured here may be a good place to ask about it and hopefully to
> > > get to the bottom of why it happens and how I can help to fix it.
> > >
> > > Happy to provide any information which may be helpful! :)
> >
> > Can you reload the driver stack:
> >
> > rmmod libertas_sdio
> > rmmod libertas
> > modprobe libertas libertas_debug=0x251e7ff
> > modprobe libertas_sdio
> >
> > and then reproduce the issue? The debug info should dump to 'dmesg'
> > and may tell us what's going on.
> >
> > Dan
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-19 17:03 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <1468946312.5661.2.camel@redhat.com>
Absolutely!
With the debug logging enabled I got the following:
Connecting the device initially with debug enabled:
[ 205.302685] libertas_sdio: Libertas SDIO driver
[ 205.302698] libertas_sdio: Copyright Pierre Ossman
[ 205.503465] cfg80211: World regulatory domain updated:
[ 205.503478] cfg80211: DFS Master region: unset
[ 205.503483] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp), (dfs_cac_time)
[ 205.503492] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
(N/A, 2000 mBm), (N/A)
[ 205.503499] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz),
(N/A, 2000 mBm), (N/A)
[ 205.503505] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz),
(N/A, 2000 mBm), (N/A)
[ 205.503513] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz,
160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 205.503522] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz,
160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 205.503529] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz),
(N/A, 2000 mBm), (0 s)
[ 205.503535] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz),
(N/A, 2000 mBm), (N/A)
[ 205.503542] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000
KHz), (N/A, 0 mBm), (N/A)
[ 212.249171] gma500 0000:00:02.0: Backlight lvds set brightness 7a127a12
[ 212.324898] mmc1: new SDIO card at address 0001
[ 212.921672] libertas_sdio mmc1:0001:1 (unnamed net_device)
(uninitialized): 00:02:78:69:49:94, fw 9.70.20p0, cap 0x00000303
[ 212.925774] libertas_sdio mmc1:0001:1 (unnamed net_device)
(uninitialized): PREP_CMD: command 0x00a3 failed: 2
[ 212.936190] libertas_sdio mmc1:0001:1 wlan0: Marvell WLAN 802.11 adapter
[ 213.053612] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Strangely when I attempt to connect to the WiFi network I’m using the
only error I get is:
[ 338.076632] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
I was expecting more output and am guessing I’ve missed something here.
Christopher Williamson
On 19 July 2016 at 17:38:35, Dan Williams
(dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> On Tue, 2016-07-19 at 12:06 -0400, Christopher Williamson wrote:
> > Hi everyone!
> >
> > I’ve just got myself a Viliv N5 and am trying to get the integrated
> > Wifi chipset working on it.
> >
> > I am able to see networks around me but any attempts to connect them
> > appear to time out and fail.
> >
> > I have filed a linux kernel bug related to this issue:
> > https://bugzilla.kernel.org/show_bug.cgi?id=135421goo
> >
> > I figured here may be a good place to ask about it and hopefully to
> > get to the bottom of why it happens and how I can help to fix it.
> >
> > Happy to provide any information which may be helpful! :)
>
> Can you reload the driver stack:
>
> rmmod libertas_sdio
> rmmod libertas
> modprobe libertas libertas_debug=0x251e7ff
> modprobe libertas_sdio
>
> and then reproduce the issue? The debug info should dump to 'dmesg'
> and may tell us what's going on.
>
> Dan
^ permalink raw reply
* Re: [PATCH 3/4] brcmsmac: Fix invalid memcpy() size in brcms_c_d11hdrs_mac80211
From: Florian Fainelli @ 2016-07-19 16:42 UTC (permalink / raw)
To: Arend Van Spriel, brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, hante.meuleman
In-Reply-To: <685abc5d-2e3d-cdce-4849-f7e5beb3309d@broadcom.com>
On 07/19/2016 03:38 AM, Arend Van Spriel wrote:
> On 19-7-2016 1:24, Florian Fainelli wrote:
>> struct ieee80211_rts::ra is only ETH_ALEN wide, yet we attempt to copy 2
>> * ETH_ALEN, which will potentially overrun the destination buffer.
>
> NACK - this is intentional. Have to admit it is a bit of trickery.
This seems fragile, if there is any kind of re-ordering of fields within
that structure your trick breaks apart.
> struct ieee80211_rts is mapped over struct d11txh which is sent to
> hardware. The struct is used for both RTS and CTS. Transmitting CTS will
> only fill 802.11 addr2 in struct ieee80211_rts::ra. Transmitting RTS
> fills 802.11 addr1 in ra and 802.11 addr2 in ta using single memcpy().
> Not very clear, but your change is not the way to go here.
Fair enough, as Kalle suggested, this deserves a comment explaining why,
I would not be surprised other people would trip over that.
>
> Regards,
> Arend
>
>> Reported-by: coverity (CID 145657)
>> Fixes: 5b435de0d7868 ("net: wireless: add brcm80211 drivers")
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
>> index c2a938b59044..59813a3666eb 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
>> @@ -6671,7 +6671,7 @@ brcms_c_d11hdrs_mac80211(struct brcms_c_info *wlc, struct ieee80211_hw *hw,
>> rts->frame_control = cpu_to_le16(IEEE80211_FTYPE_CTL |
>> IEEE80211_STYPE_RTS);
>>
>> - memcpy(&rts->ra, &h->addr1, 2 * ETH_ALEN);
>> + memcpy(&rts->ra, &h->addr1, ETH_ALEN);
>> }
>>
>> /* mainrate
>>
--
Florian
^ permalink raw reply
* Re: [PATCH 0/4] brcm80211: Misc coverity fixes
From: Florian Fainelli @ 2016-07-19 16:41 UTC (permalink / raw)
To: Arend Van Spriel, brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, hante.meuleman
In-Reply-To: <bdbaa850-4ec4-9faf-dbae-e2a6dcc54e7c@broadcom.com>
On 07/19/2016 02:20 AM, Arend Van Spriel wrote:
> + Bob
>
> On 19-7-2016 1:24, Florian Fainelli wrote:
>> Hi,
>>
>> This patch series addresses several coverity issues, they all seemed relevant
>> to me.
>
> Hi Florian,
>
> Been a while so nice to see coverity fixes popping up. Actually
> something that I have on my todo list to add our brcm80211 to coverity
> within Broadcom. So being curious as to whether this comes from a public
> coverity server like scan.coverity.com. Maybe bit redundant to setup
> internally if there is a good coverity analysis publicly available.
This is coming from the public coverity instance, if you create an
account there I could transfer to you the other bugs that affect the
brcm80211 drivers (hint: there is a ton of of them because of
brcmf_fil_iovar_int_get and friends).
>
>> There is also a ton of warnings in Coverity caused by brcmf_fil_iovar_int_get()
>> and friends because of the initial access:
>>
>> __le32 data_le = cpu_to_le32(*data) which can utilize unitialized memory. I am
>> not sure if we actually care about any kind of initial, value, but if we don't,
>> then the fix should be fairly obvious.
>
> If we are talking only about "get" variant than we mostly don't care.
> Some getters support filter variables to be passed towards firmware. I
> have not looked at the analysis to give any judgement here.
Alright, do you have a good way to test a patch that would just zero
initialize the data variable in brcmf_fil_iovar_int_get()? If so, I will
submit one with the appropriate CID references.
Thanks!
--
Florian
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Dan Williams @ 2016-07-19 16:38 UTC (permalink / raw)
To: Christopher Williamson, linux-wireless@vger.kernel.org
In-Reply-To: <CANXHH3n7Gp+0NA8j9ji0S2dsYqbR9SE0MEuB5oKENE6Asz9j=w@mail.gmail.com>
On Tue, 2016-07-19 at 12:06 -0400, Christopher Williamson wrote:
> Hi everyone!
>
> I’ve just got myself a Viliv N5 and am trying to get the integrated
> Wifi chipset working on it.
>
> I am able to see networks around me but any attempts to connect them
> appear to time out and fail.
>
> I have filed a linux kernel bug related to this issue:
> https://bugzilla.kernel.org/show_bug.cgi?id=135421
>
> I figured here may be a good place to ask about it and hopefully to
> get to the bottom of why it happens and how I can help to fix it.
>
> Happy to provide any information which may be helpful! :)
Can you reload the driver stack:
rmmod libertas_sdio
rmmod libertas
modprobe libertas libertas_debug=0x251e7ff
modprobe libertas_sdio
and then reproduce the issue? The debug info should dump to 'dmesg'
and may tell us what's going on.
Dan
^ permalink raw reply
* Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-19 16:06 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi everyone!
I’ve just got myself a Viliv N5 and am trying to get the integrated
Wifi chipset working on it.
I am able to see networks around me but any attempts to connect them
appear to time out and fail.
I have filed a linux kernel bug related to this issue:
https://bugzilla.kernel.org/show_bug.cgi?id=135421
I figured here may be a good place to ask about it and hopefully to
get to the bottom of why it happens and how I can help to fix it.
Happy to provide any information which may be helpful! :)
Christopher Williamson
Note: Apologies for anyone also on the libertas-dev mailing list - I
did also post this there but so far haven’t had any response so I
figured it wouldn’t hurt posting it here too in the hopes someone has
seen this issue before.
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Jes Sorensen @ 2016-07-19 16:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel
In-Reply-To: <3858062.NGQDOLnTj0@wuerfel>
Arnd Bergmann <arnd@arndb.de> writes:
> On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote:
>> > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c
>> > index 2c8a526773ed..e0a2fe5e6148 100644
>> > --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
>> > +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
>> > @@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS,
>> > if (ieee->current_network.qos_data.supported == 0) {
>> > UP = 0;
>> > } else {
>> > - if (!IsACValid(TID)) {
>> > + if (!IsACValid((s8)TID)) {
>> > netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n",
>> > __func__, TID);
>> > return false;
>>
>> TID is a 4-bit field, it should never go negative. The cast to s8 seems
>> wrong to me, if anything it should be using u8. I do realize the macro
>> IsACValid checks against negative too, but that just looks silly to me.
>
> Ok, I'll remove the extra comparison then to avoid the warning:
>
> staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always
> true due to limited range of data type [-Werror=type-limits]
>
> I guess it should be a separate patch. I had just stumbled over the
> same thing before resending the patch but decided not to change it
> to keep the patch simple.
I think that would be better, albeit not a big issue. I'd like to get
rid of all the drivers/staging/rtl* drivers eventually :)
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
From: Yeoh Chun-Yeow @ 2016-07-19 16:01 UTC (permalink / raw)
To: Bob Copeland
Cc: Machani, Yaniv, linux-wireless@vger.kernel.org, Hahn, Maital,
Johannes Berg
In-Reply-To: <20160719134355.GA1833@localhost>
On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Tue, Jul 19, 2016 at 01:02:13PM +0000, Machani, Yaniv wrote:
>> On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote:
>> > > IEEE 802.11-2012 has defined dot11MeshHWMPpreqMinInterval attribute
>> > > to specify the minimum interval of time during which a mesh STA can
>> > > send only one Action frame containing a PREQ element. This is to
>> > > avoid flooding of broadcast PREQ frame especially when the number of
>> > > mesh STA is increased.
>> >
>> > Good point, according to 13.10.9.3, conditions for sending PREQ include:
>> >
>> > "The mesh STA has not sent a PREQ element for the target mesh STAs
>> > less than dot11MeshHWMPpreqMinInterval TUs ago. If this is the case,
>> > the transmission of the PREQ has to be postponed until this condition becomes true."
>> >
>>
>> As I see it, the key point here is "for the target meh STA",
>> Today, the code will not send a PREQ to ANY target if
>> dot11MeshHWMPpreqMinInterval didn't passed.
>> The information is saved in the 'ifmsh->last_preq', and not per path.
>
> The standard also says (which Chun-Yeow partially quoted):
>
> dot11MeshHWMPpreqMinInterval OBJECT-TYPE
> SYNTAX Unsigned32 (1..65535)
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "This is a control variable.
> It is written by an external management entity.
> Changes take effect as soon as practical in the implementation.
> This attribute specifies the minimum interval of time (in TUs) during
> which a mesh STA can send only one Action frame containing a PREQ element."
> DEFVAL { 100 }
> ::= { dot11MeshHWMPConfigEntry 4}
>
> This wording seems to indicate that it is not per path. Perhaps this
> should be clarified in the standard. (If the intent turns out to be per
> path, then I guess we should fix it by storing last_preq per path instead.)
>
>
> Ignoring the standard for a second, let's explore this: can you give
> some idea on how many stations are in your target network, how frequently
> a given pair of nodes unpeer, what sort of improvements you see with the
> patch? It should then be pretty easy to run some simulations to see the
> scenarios where this helps and where it hurts.
>
In addition to Bob's comment, you probably can try to reduce the
dot11MeshHWMPpreqMinInterval to 1 TU (1ms) instead of sticking to
default value 10 TUs. Besides, you can also reduce the
mesh_path_refresh_time which is currently default to 1000 ms and check
whether you can improve on your network scenarios.
When you mentioned "next hop peer disconnect", it could also be the
time taken to re-established the mesh peering before your mesh STA can
transmit the data to your peer mesh STA.
---
Chun-Yeow
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Arnd Bergmann @ 2016-07-19 15:53 UTC (permalink / raw)
To: Jes Sorensen
Cc: linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel
In-Reply-To: <wrfjy44xvdfn.fsf@redhat.com>
On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote:
> > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c
> > index 2c8a526773ed..e0a2fe5e6148 100644
> > --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
> > +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
> > @@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS,
> > if (ieee->current_network.qos_data.supported == 0) {
> > UP = 0;
> > } else {
> > - if (!IsACValid(TID)) {
> > + if (!IsACValid((s8)TID)) {
> > netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n",
> > __func__, TID);
> > return false;
>
> TID is a 4-bit field, it should never go negative. The cast to s8 seems
> wrong to me, if anything it should be using u8. I do realize the macro
> IsACValid checks against negative too, but that just looks silly to me.
Ok, I'll remove the extra comparison then to avoid the warning:
staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due to limited range of data type [-Werror=type-limits]
I guess it should be a separate patch. I had just stumbled over the
same thing before resending the patch but decided not to change it
to keep the patch simple.
Arnd
^ permalink raw reply
* Re: [PATCH 3/3] staging/rtl8192u: use s8 instead of char
From: Jes Sorensen @ 2016-07-19 15:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Raphaël Beamonte, devel, linux-kernel
In-Reply-To: <20160719153403.2967812-3-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
> incorrect code that results from 'char' being unsigned here, e.g.
>
> staging/rtl8192u/r8192U_core.c:4150:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
> staging/rtl8192u/r8192U_dm.c:646:50: error: comparison is always false due to limited range of data type [-Werror=type-limits]
>
> This patch changes all uses of 'char' in this driver that refer to
> 8-bit integers to use 's8' instead, which is signed on all architectures.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/staging/rtl8192u/ieee80211/ieee80211.h | 4 ++--
> drivers/staging/rtl8192u/r8192U.h | 4 ++--
> drivers/staging/rtl8192u/r8192U_core.c | 14 +++++++-------
> 3 files changed, 11 insertions(+), 11 deletions(-)
Looks good to me
Acked-by: Jes Sorensen <Jes.Sorensen@redhat.com>
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Jes Sorensen @ 2016-07-19 15:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel
In-Reply-To: <20160719153403.2967812-2-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
> incorrect code that results from 'char' being unsigned here, e.g.
>
> staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always false due to limited range of data type [-Werror=type-limits]
> staging/rtl8192e/rtl8192e/r8192E_phy.c:1104:36: error: comparison is always false due to limited range of data type [-Werror=type-limits]
> staging/rtl8192e/rtl8192e/rtl_core.c:1987:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
> staging/rtl8192e/rtl8192e/rtl_dm.c:782:37: error: comparison is always false due to limited range of data type [-Werror=type-limits]
> staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due to limited range of data type [-Werror=type-limits]
> staging/rtl8192e/rtllib_softmac_wx.c:465:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
>
> This patch changes all uses of 'char' in this driver that refer to
> 8-bit integers to use 's8' instead, which is signed on all architectures.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 8 ++++----
> drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c | 2 +-
> drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 +++---
> drivers/staging/rtl8192e/rtl8192e/rtl_core.h | 8 ++++----
> drivers/staging/rtl8192e/rtl819x_TSProc.c | 2 +-
> 5 files changed, 13 insertions(+), 13 deletions(-)
>
Most of this looks fine to me. One issue stands out which I don't think
is right:
> diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c
> index 2c8a526773ed..e0a2fe5e6148 100644
> --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
> +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
> @@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS,
> if (ieee->current_network.qos_data.supported == 0) {
> UP = 0;
> } else {
> - if (!IsACValid(TID)) {
> + if (!IsACValid((s8)TID)) {
> netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n",
> __func__, TID);
> return false;
TID is a 4-bit field, it should never go negative. The cast to s8 seems
wrong to me, if anything it should be using u8. I do realize the macro
IsACValid checks against negative too, but that just looks silly to me.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH v2 05/11] Kbuild: don't add obj tree in additional includes
From: Arnd Bergmann @ 2016-07-19 15:38 UTC (permalink / raw)
To: Kalle Valo, Greg Kroah-Hartman
Cc: linux-arm-kernel, Michal Marek, netdev, dri-devel, linux-kernel,
linux-kbuild, akpm, linux-wireless
In-Reply-To: <87a8hdae9j.fsf@purkki.adurom.net>
On Tuesday, July 19, 2016 5:33:44 PM CEST Kalle Valo wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > On Monday, July 18, 2016 10:14:39 PM CEST Michal Marek wrote:
> >> On Wed, Jun 15, 2016 at 05:45:47PM +0200, Arnd Bergmann wrote:
> >> > When building with separate object directories and driver specific
> >> > Makefiles that add additional header include paths, Kbuild adjusts
> >> > the gcc flags so that we include both the directory in the source
> >> > tree and in the object tree.
> >> >
> >> > However, due to another bug I fixed earlier, this did not actually
> >> > include the correct directory in the object tree, so we know that
> >> > we only really need the source tree here. Also, including the
> >> > object tree sometimes causes warnings about nonexisting directories
> >> > when the include path only exists in the source.
> >> >
> >> > This changes the logic to only emit the -I argument for the srctree,
> >> > not for objects. We still need both $(srctree)/$(src) and $(obj)
> >> > though, so I'm adding them manually.
> >> >
> >> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >>
> >> Hi Arnd,
> >>
> >> I applied the series up to this patch to kbuild.git#kbuild. The rest
> >> seem to be related but not dependent patches, so I'll leave it up to the
> >> respective maintainers to pick them up. Is that OK with you?
> >
> > I think that's fine, a couple were already picked up, and what I have
> > left now is
> >
> > a281bfa5713a [SUBMITTED 20160615] [EXPERIMENTAL] Kbuild: enable -Wmissing-include-dirs by default
> > 83934921e68e [SUBMITTED 20160615] rtlwifi: don't add include path for rtl8188ee
>
> Apparently[1] you didn't CC linux-wireless and that's why I didn't see
> the rtlwifi patch in wireless patchwork. Care to resend?
>
> [1] https://patchwork.kernel.org/patch/9178861/
>
Done. I've also thrown in two patches for drivers/staging/rtl8*/ that I submitted
a while ago, but I'm not sure if they should get merged through the staging
tree or the wireless tree. I had previously submitted those two as a combined
patch along with a third one that turned out to be unnecessary.
Arnd
^ permalink raw reply
* [PATCH 3/3] staging/rtl8192u: use s8 instead of char
From: Arnd Bergmann @ 2016-07-19 15:33 UTC (permalink / raw)
To: linux-wireless
Cc: Kalle Valo, Larry Finger, netdev, Jes Sorensen, Arnd Bergmann,
Greg Kroah-Hartman, Raphaël Beamonte, devel, linux-kernel
In-Reply-To: <20160719153403.2967812-1-arnd@arndb.de>
Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
incorrect code that results from 'char' being unsigned here, e.g.
staging/rtl8192u/r8192U_core.c:4150:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192u/r8192U_dm.c:646:50: error: comparison is always false due to limited range of data type [-Werror=type-limits]
This patch changes all uses of 'char' in this driver that refer to
8-bit integers to use 's8' instead, which is signed on all architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/staging/rtl8192u/ieee80211/ieee80211.h | 4 ++--
drivers/staging/rtl8192u/r8192U.h | 4 ++--
drivers/staging/rtl8192u/r8192U_core.c | 14 +++++++-------
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 09e9499b7f9d..077ea13eb1e7 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -746,7 +746,7 @@ struct ieee80211_rx_stats {
bool bisrxaggrsubframe;
bool bPacketBeacon; //cosa add for rssi
bool bToSelfBA; //cosa add for rssi
- char cck_adc_pwdb[4]; //cosa add for rx path selection
+ s8 cck_adc_pwdb[4]; //cosa add for rx path selection
u16 Seq_Num;
};
@@ -1814,7 +1814,7 @@ struct ieee80211_device {
u32 wpax_type_notify; //{added by David, 2006.9.26}
/* QoS related flag */
- char init_wmmparam_flag;
+ s8 init_wmmparam_flag;
/* set on initialization */
u8 qos_support;
diff --git a/drivers/staging/rtl8192u/r8192U.h b/drivers/staging/rtl8192u/r8192U.h
index 5dba6a28dd9b..b28bc7812caa 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -533,7 +533,7 @@ typedef struct _rt_9x_tx_rate_history {
u32 ht_mcs[4][16];
} rt_tx_rahis_t, *prt_tx_rahis_t;
typedef struct _RT_SMOOTH_DATA_4RF {
- char elements[4][100]; /* array to store values */
+ s8 elements[4][100]; /* array to store values */
u32 index; /* index to current array to store */
u32 TotalNum; /* num of valid elements */
u32 TotalVal[4]; /* sum of valid elements */
@@ -1031,7 +1031,7 @@ typedef struct r8192_priv {
s8 cck_present_attentuation;
u8 cck_present_attentuation_20Mdefault;
u8 cck_present_attentuation_40Mdefault;
- char cck_present_attentuation_difference;
+ s8 cck_present_attentuation_difference;
bool btxpower_tracking;
bool bcck_in_ch14;
bool btxpowerdata_readfromEEPORM;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c
index dd0970facdf5..f36b2d3b1ee9 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4209,7 +4209,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv *priv, u8 *buffer,
*
* Return: 0-100 percentage
*---------------------------------------------------------------------------*/
-static u8 rtl819x_query_rxpwrpercentage(char antpower)
+static u8 rtl819x_query_rxpwrpercentage(s8 antpower)
{
if ((antpower <= -100) || (antpower >= 20))
return 0;
@@ -4220,9 +4220,9 @@ static u8 rtl819x_query_rxpwrpercentage(char antpower)
} /* QueryRxPwrPercentage */
-static u8 rtl819x_evm_dbtopercentage(char value)
+static u8 rtl819x_evm_dbtopercentage(s8 value)
{
- char ret_val;
+ s8 ret_val;
ret_val = value;
@@ -4297,8 +4297,8 @@ static void rtl8192_query_rxphystatus(struct r8192_priv *priv,
phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
u8 *prxpkt;
u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg;
- char rx_pwr[4], rx_pwr_all = 0;
- char rx_snrX, rx_evmX;
+ s8 rx_pwr[4], rx_pwr_all = 0;
+ s8 rx_snrX, rx_evmX;
u8 evm, pwdb_all;
u32 RSSI, total_rssi = 0;
u8 is_cck_rate = 0;
@@ -4423,7 +4423,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv *priv,
/* Get Rx snr value in DB */
tmp_rxsnr = pofdm_buf->rxsnr_X[i];
- rx_snrX = (char)(tmp_rxsnr);
+ rx_snrX = (s8)(tmp_rxsnr);
rx_snrX /= 2;
priv->stats.rxSNRdB[i] = (long)rx_snrX;
@@ -4457,7 +4457,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv *priv,
for (i = 0; i < max_spatial_stream; i++) {
tmp_rxevm = pofdm_buf->rxevm_X[i];
- rx_evmX = (char)(tmp_rxevm);
+ rx_evmX = (s8)(tmp_rxevm);
/* Do not use shift operation like "rx_evmX >>= 1"
* because the compiler of free build environment will
--
2.9.0
^ permalink raw reply related
* [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Arnd Bergmann @ 2016-07-19 15:33 UTC (permalink / raw)
To: linux-wireless
Cc: Kalle Valo, Larry Finger, netdev, Jes Sorensen, Arnd Bergmann,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel
In-Reply-To: <20160719153403.2967812-1-arnd@arndb.de>
Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
incorrect code that results from 'char' being unsigned here, e.g.
staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtl8192e/r8192E_phy.c:1104:36: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtl8192e/rtl_core.c:1987:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtl8192e/rtl_dm.c:782:37: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtllib_softmac_wx.c:465:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
This patch changes all uses of 'char' in this driver that refer to
8-bit integers to use 's8' instead, which is signed on all architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 8 ++++----
drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c | 2 +-
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 +++---
drivers/staging/rtl8192e/rtl8192e/rtl_core.h | 8 ++++----
drivers/staging/rtl8192e/rtl819x_TSProc.c | 2 +-
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
index ba64a4f1b3a8..8d6bca61e7aa 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -1487,8 +1487,8 @@ static void _rtl92e_query_rxphystatus(
struct phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
u8 *prxpkt;
u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg;
- char rx_pwr[4], rx_pwr_all = 0;
- char rx_snrX, rx_evmX;
+ s8 rx_pwr[4], rx_pwr_all = 0;
+ s8 rx_snrX, rx_evmX;
u8 evm, pwdb_all;
u32 RSSI, total_rssi = 0;
u8 is_cck_rate = 0;
@@ -1613,7 +1613,7 @@ static void _rtl92e_query_rxphystatus(
2) - 110;
tmp_rxsnr = pofdm_buf->rxsnr_X[i];
- rx_snrX = (char)(tmp_rxsnr);
+ rx_snrX = (s8)(tmp_rxsnr);
rx_snrX /= 2;
priv->stats.rxSNRdB[i] = (long)rx_snrX;
@@ -1643,7 +1643,7 @@ static void _rtl92e_query_rxphystatus(
for (i = 0; i < max_spatial_stream; i++) {
tmp_rxevm = pofdm_buf->rxevm_X[i];
- rx_evmX = (char)(tmp_rxevm);
+ rx_evmX = (s8)(tmp_rxevm);
rx_evmX /= 2;
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
index 5e3bbe5c3ca4..0698131e4300 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
@@ -630,7 +630,7 @@ void rtl92e_set_tx_power(struct net_device *dev, u8 channel)
{
struct r8192_priv *priv = rtllib_priv(dev);
u8 powerlevel = 0, powerlevelOFDM24G = 0;
- char ant_pwr_diff;
+ s8 ant_pwr_diff;
u32 u4RegValue;
if (priv->epromtype == EEPROM_93C46) {
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 13a5ddc2bea5..41e05f206300 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1982,7 +1982,7 @@ void rtl92e_update_rx_statistics(struct r8192_priv *priv,
weighting) / 6;
}
-u8 rtl92e_rx_db_to_percent(char antpower)
+u8 rtl92e_rx_db_to_percent(s8 antpower)
{
if ((antpower <= -100) || (antpower >= 20))
return 0;
@@ -1993,9 +1993,9 @@ u8 rtl92e_rx_db_to_percent(char antpower)
} /* QueryRxPwrPercentage */
-u8 rtl92e_evm_db_to_percent(char value)
+u8 rtl92e_evm_db_to_percent(s8 value)
{
- char ret_val;
+ s8 ret_val;
ret_val = value;
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
index f627fdc15a58..6921125c9d35 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
@@ -503,8 +503,8 @@ struct r8192_priv {
u32 Pwr_Track;
u8 CCKPresentAttentuation_20Mdefault;
u8 CCKPresentAttentuation_40Mdefault;
- char CCKPresentAttentuation_difference;
- char CCKPresentAttentuation;
+ s8 CCKPresentAttentuation_difference;
+ s8 CCKPresentAttentuation;
long undecorated_smoothed_pwdb;
u32 MCSTxPowerLevelOriginalOffset[6];
@@ -604,8 +604,8 @@ void rtl92e_update_rx_pkt_timestamp(struct net_device *dev,
long rtl92e_translate_to_dbm(struct r8192_priv *priv, u8 signal_strength_index);
void rtl92e_update_rx_statistics(struct r8192_priv *priv,
struct rtllib_rx_stats *pprevious_stats);
-u8 rtl92e_evm_db_to_percent(char value);
-u8 rtl92e_rx_db_to_percent(char antpower);
+u8 rtl92e_evm_db_to_percent(s8 value);
+u8 rtl92e_rx_db_to_percent(s8 antpower);
void rtl92e_copy_mpdu_stats(struct rtllib_rx_stats *psrc_stats,
struct rtllib_rx_stats *ptarget_stats);
bool rtl92e_enable_nic(struct net_device *dev);
diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c
index 2c8a526773ed..e0a2fe5e6148 100644
--- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
@@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS,
if (ieee->current_network.qos_data.supported == 0) {
UP = 0;
} else {
- if (!IsACValid(TID)) {
+ if (!IsACValid((s8)TID)) {
netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n",
__func__, TID);
return false;
--
2.9.0
^ permalink raw reply related
* [PATCH 1/3] rtlwifi: don't add include path for rtl8188ee
From: Arnd Bergmann @ 2016-07-19 15:33 UTC (permalink / raw)
To: linux-wireless
Cc: Kalle Valo, Larry Finger, netdev, Jes Sorensen, Arnd Bergmann,
Chaoming Li, linux-kernel
For rtl8188ee, we pass -Idrivers/net/wireless/rtlwifi/ to gcc,
however that directy no longer exists, so evidently this option
is no longer required here and can be removed to avoid a warning
when building with 'make W=1' or 'gcc -Wmissing-include-dirs'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile
index a85419a37651..676e7de27f27 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile
@@ -12,4 +12,4 @@ rtl8188ee-objs := \
obj-$(CONFIG_RTL8188EE) += rtl8188ee.o
-ccflags-y += -Idrivers/net/wireless/rtlwifi -D__CHECK_ENDIAN__
+ccflags-y += -D__CHECK_ENDIAN__
--
2.9.0
^ permalink raw reply related
* Re: [PATCH v2 05/11] Kbuild: don't add obj tree in additional includes
From: Kalle Valo @ 2016-07-19 14:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Michal Marek, netdev, dri-devel, linux-kernel,
linux-kbuild, akpm, linux-wireless
In-Reply-To: <21521763.EfAflxWUP8@wuerfel>
Arnd Bergmann <arnd@arndb.de> writes:
> On Monday, July 18, 2016 10:14:39 PM CEST Michal Marek wrote:
>> On Wed, Jun 15, 2016 at 05:45:47PM +0200, Arnd Bergmann wrote:
>> > When building with separate object directories and driver specific
>> > Makefiles that add additional header include paths, Kbuild adjusts
>> > the gcc flags so that we include both the directory in the source
>> > tree and in the object tree.
>> >
>> > However, due to another bug I fixed earlier, this did not actually
>> > include the correct directory in the object tree, so we know that
>> > we only really need the source tree here. Also, including the
>> > object tree sometimes causes warnings about nonexisting directories
>> > when the include path only exists in the source.
>> >
>> > This changes the logic to only emit the -I argument for the srctree,
>> > not for objects. We still need both $(srctree)/$(src) and $(obj)
>> > though, so I'm adding them manually.
>> >
>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>
>> Hi Arnd,
>>
>> I applied the series up to this patch to kbuild.git#kbuild. The rest
>> seem to be related but not dependent patches, so I'll leave it up to the
>> respective maintainers to pick them up. Is that OK with you?
>
> I think that's fine, a couple were already picked up, and what I have
> left now is
>
> a281bfa5713a [SUBMITTED 20160615] [EXPERIMENTAL] Kbuild: enable -Wmissing-include-dirs by default
> 83934921e68e [SUBMITTED 20160615] rtlwifi: don't add include path for rtl8188ee
Apparently[1] you didn't CC linux-wireless and that's why I didn't see
the rtlwifi patch in wireless patchwork. Care to resend?
[1] https://patchwork.kernel.org/patch/9178861/
--
Kalle Valo
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Felix Fietkau @ 2016-07-19 14:32 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, Toke Høiland-Jørgensen
In-Reply-To: <CA+BoTQ=Bi070XDXNjq6ypzs3w0+9OYM_8tXeikSR_a0TMN2P=g@mail.gmail.com>
On 2016-07-19 15:13, Michal Kazior wrote:
> On 12 July 2016 at 12:09, Felix Fietkau <nbd@nbd.name> wrote:
>> Hi,
>>
>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>> regression when running local iperf on an AP (running the txq stuff) to
>> a wireless client.
>>
>> Here's some things that I found:
>> - when I use only one TCP stream I get around 90-110 Mbit/s
>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
>
> What is the baseline here (i.e. without fq/txq stuff)? Is it ~100mbps?
Yes.
> Did you try running multiple streams, each on separate tids (matching
> the same AC perhaps) or different clients?
Not yet.
- Felix
^ permalink raw reply
* Re: [PATCH] mtd: add arch dependency for MTD_BCM47XXSFLASH symbol
From: Kalle Valo @ 2016-07-19 14:10 UTC (permalink / raw)
To: Brian Norris
Cc: Rafał Miłecki, linux-wireless, David Woodhouse,
open list:MEMORY TECHNOLOGY DEVICES (MTD), open list
In-Reply-To: <20160719072613.GA96986@google.com>
Brian Norris <computersforpeace@gmail.com> writes:
> On Tue, Jul 19, 2016 at 09:08:32AM +0200, Rafał Miłecki wrote:
>> We dropped strict MIPS dependency for bcm47xxsflash driver in:
>> commit 5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of
>> KSEG0ADDR()") but using ioremap_cache still limits building it to few
>> selected architectures only.
>>
>> A recent commit 57d8f7dd2132 ("bcma: allow enabling serial flash support
>> on non-MIPS SoCs") automatically dropped MIPS dependency for
>> MTD_BCM47XXSFLASH which broke building e.g. on powerpc and cris.
>>
>> The bcma change is alright as it doesn't break building bcma code in any
>> way. MTD_BCM47XXSFLASH on the other hand should be limited to archs
>> which need it and can build it (by providing ioremap_cache).
>>
>> Fixes: 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>> Cc: Brian Norris <computersforpeace@gmail.com>
>
> While I might prefer we have a better consistent set of portable I/O
> accessors (it's really a mess), it seems quite reasonable to restrict
> the damage to ARM and MIPS here if it saves some short-term hassle:
>
> Acked-by: Brian Norris <computersforpeace@gmail.com>
>
>> ---
>> That bcma commit breaking building landed in the wireless-drivers-next.
>> Is that possible to get this patch through the same tree?
>
> That's fine with me.
Great, thanks. I'm planning to apply this later tonight to fix the build
error.
--
Kalle Valo
^ permalink raw reply
* Re: linux-next: build failure after merge of the wireless-drivers-next tree
From: Kalle Valo @ 2016-07-19 14:08 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Brian Norris, linux-mtd@lists.infradead.org, Stephen Rothwell,
linux-wireless@vger.kernel.org, linux-next,
Linux Kernel Mailing List
In-Reply-To: <CACna6ry6QgrbUoHuJacmr1EhHZyrwqsXfr51gENvY-0zM9L+3Q@mail.gmail.com>
Rafał Miłecki <zajec5@gmail.com> writes:
> On 19 July 2016 at 09:09, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Rafał Miłecki <zajec5@gmail.com> writes:
>>
>>> On 19 July 2016 at 08:30, Kalle Valo <kvalo@codeaurora.org> wrote:
>>>> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>>>>
>>>>> After merging the wireless-drivers-next tree, today's linux-next build
>>>>> (powerpc allyesconfig) failed like this:
>>>>>
>>>>> drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
>>>>> drivers/mtd/devices/bcm47xxsflash.c:299:17: error: implicit declaration of function 'ioremap_cache' [-Werror=implicit-function-declaration]
>>>>> b47s->window = ioremap_cache(res->start, resource_size(res));
>>>>> ^
>>>>> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
>>>>> b47s->window = ioremap_cache(res->start, resource_size(res));
>>>>> ^
>>>>>
>>>>> Caused by commit
>>>>>
>>>>> 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
>>>>>
>>>>> I have reverted that commit for today.
>>>>
>>>> Thanks, kbuild bot also notified about this.
>>>>
>>>> Rafał, as the merge window is getting really close I would like to
>>>> revert this for now and we can reapply it once we the problem is fully
>>>> solved. And we can use my pending branch for build testing the patch
>>>> with kbuild bot. What do you think?
>>>
>>> The simplest fix sounds pretty much as simple as the revert.
>>
>> The problem is that I don't have much time, I need to send the pull
>> request to Dave within next few days. The fix might create other
>> problems so I'm not enthusiastic about iterating with this patch at the
>> moment. I think it can wait for 4.9.
>
> I sent a patch seconds ago, you may just take a look at it. If you
> still prefer to revert my commit, go ahead.
Ok, let's try your fix. We still have few days. I applied the patch[1]
to the pending branch this morning and if I don't see any errors I apply
it later tonight and hopefully it will be in tomorrow's linux-next
build. Thanks for the quick fix, very much appreciated.
[1] "mtd: add arch dependency for MTD_BCM47XXSFLASH symbol"
https://patchwork.kernel.org/patch/9236053/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
From: Bob Copeland @ 2016-07-19 13:43 UTC (permalink / raw)
To: Machani, Yaniv
Cc: linux-wireless@vger.kernel.org, Hahn, Maital, Johannes Berg,
Chun-Yeow Yeoh
In-Reply-To: <AE1C82FB3D0EC64DB1F752C81CBD110139206115@DFRE01.ent.ti.com>
On Tue, Jul 19, 2016 at 01:02:13PM +0000, Machani, Yaniv wrote:
> On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote:
> > > IEEE 802.11-2012 has defined dot11MeshHWMPpreqMinInterval attribute
> > > to specify the minimum interval of time during which a mesh STA can
> > > send only one Action frame containing a PREQ element. This is to
> > > avoid flooding of broadcast PREQ frame especially when the number of
> > > mesh STA is increased.
> >
> > Good point, according to 13.10.9.3, conditions for sending PREQ include:
> >
> > "The mesh STA has not sent a PREQ element for the target mesh STAs
> > less than dot11MeshHWMPpreqMinInterval TUs ago. If this is the case,
> > the transmission of the PREQ has to be postponed until this condition becomes true."
> >
>
> As I see it, the key point here is "for the target meh STA",
> Today, the code will not send a PREQ to ANY target if
> dot11MeshHWMPpreqMinInterval didn't passed.
> The information is saved in the 'ifmsh->last_preq', and not per path.
The standard also says (which Chun-Yeow partially quoted):
dot11MeshHWMPpreqMinInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the minimum interval of time (in TUs) during
which a mesh STA can send only one Action frame containing a PREQ element."
DEFVAL { 100 }
::= { dot11MeshHWMPConfigEntry 4}
This wording seems to indicate that it is not per path. Perhaps this
should be clarified in the standard. (If the intent turns out to be per
path, then I guess we should fix it by storing last_preq per path instead.)
Ignoring the standard for a second, let's explore this: can you give
some idea on how many stations are in your target network, how frequently
a given pair of nodes unpeer, what sort of improvements you see with the
patch? It should then be pretty easy to run some simulations to see the
scenarios where this helps and where it hurts.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [v2,1/3] ath6kl: Fix WLAN tethering authentication problem.
From: Kalle Valo @ 2016-07-19 13:25 UTC (permalink / raw)
To: Pierre Le Magourou; +Cc: ath6kl, linux-wireless, jmassot, Pierre Le Magourou
In-Reply-To: <20160704110719.7694-2-plemagourou@aldebaran.com>
Pierre Le Magourou <lemagoup@gmail.com> wrote:
> From: Pierre Le Magourou <plemagourou@aldebaran.com>
>
> When enabling WLAN tethering, a new AP is visible and a STA could
> connect to it. When the STA tries to authenticate to the newly created
> AP, the WPA authentication mechanism is stuck in the 1/4 msg of 4-Way
> Handshake.
>
> In ath6kl_rx(), the ath6kl_find_sta() function is looking for the
> h_source field of the Ethernet frame header received by the STA. The
> datap pointer that points to the Ethernet frame header is incorrect,
> and was pointing at the wrong offset in the buffer.
>
> This commit adds a pad_before_data_start offset to set the datap pointer
> to the Ethernet frame header. datap->h_source parameter is now really
> pointing to the source ethernet address and the authentication process
> can continue.
>
> Signed-off-by: Pierre Le Magourou <plemagourou@aldebaran.com>
Thanks, 3 patches applied to ath-next branch of ath.git:
270df8f80d67 ath6kl: Fix WLAN tethering authentication problem.
f3651bae5644 ath6kl: Fix wrong regulatory domain disconnection.
76b817f6c9a9 ath6kl: Unset IFF_LOWER_UP flag on AP mode leave.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9212263/
^ permalink raw reply
* Re: ath10k: disable wake_tx_queue for older devices
From: Kalle Valo @ 2016-07-19 13:19 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, Michal Kazior, ath10k
In-Reply-To: <1467201146-6844-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> wrote:
> Ideally wake_tx_queue should be used regardless as
> it is a requirement for reducing bufferbloat and
> implementing airtime fairness in the future.
>
> However some setups (typically low-end platforms
> hosting QCA988X) suffer performance regressions
> with the current wake_tx_queue implementation.
> Therefore disable it unless it is really
> beneficial with current codebase (which is when
> firmware supports smart pull-push tx scheduling).
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
4ca1807815aa ath10k: disable wake_tx_queue for older devices
--
Sent by pwcli
https://patchwork.kernel.org/patch/9204997/
^ permalink raw reply
* RE: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Machani, Yaniv @ 2016-07-19 13:17 UTC (permalink / raw)
To: Johannes Berg, Bob Copeland
Cc: linux-kernel@vger.kernel.org, Kama, Meirav, David S. Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <1468867942.2944.0.camel@sipsolutions.net>
T24gTW9uLCBKdWwgMTgsIDIwMTYgYXQgMjE6NTI6MjIsIEpvaGFubmVzIEJlcmcgd3JvdGU6DQo+
IGxpbnV4LSB3aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IG5ldGRldkB2Z2VyLmtlcm5lbC5vcmcN
Cj4gU3ViamVjdDogUmU6IFtQQVRDSCAzLzNdIG1hYzgwMjExOiBtZXNoOiBmaXhlZCBIVCBpZXMg
aW4gYmVhY29uIA0KPiB0ZW1wbGF0ZQ0KPiANCj4gT24gTW9uLCAyMDE2LTA3LTE4IGF0IDA5OjM4
IC0wNDAwLCBCb2IgQ29wZWxhbmQgd3JvdGU6DQo+ID4gT24gV2VkLCBKdWwgMTMsIDIwMTYgYXQg
MDI6NDU6NDBQTSArMDMwMCwgWWFuaXYgTWFjaGFuaSB3cm90ZToNCj4gPiA+IFRoZSBIVCBjYXBh
YiBpbmZvIGZpZWxkIGluc2lkZSB0aGUgSFQgY2FwYWIgSUUgb2YgdGhlIG1lc2ggYmVhY29uIA0K
PiA+ID4gaXMgaW5jb3JyZWN0IChpbiB0aGUgY2FzZSBvZiAyME1IeiBjaGFubmVsIHdpZHRoKS4N
Cj4gPiA+IFRvIGZpeCB0aGlzIGRyaXZlciB3aWxsIGNoZWNrIGNvbmZpZ3VyYXRpb24gZnJvbSBj
ZmcgYW5kIHdpbGwgDQo+ID4gPiBidWlsZCBpdCBhY2NvcmRpbmdseS4NCj4gPg0KPiA+ID4gK8Kg
wqDCoMKgLyogZGV0ZXJtaW5lIGNhcGFiaWxpdHkgZmxhZ3MgKi8NCj4gPiA+ICsJY2FwID0gc2Jh
bmQtPmh0X2NhcC5jYXA7DQo+ID4gPiArDQo+ID4gPiArwqDCoMKgwqAvKiBpZiBjaGFubmVsIHdp
ZHRoIGlzIDIwTUh6IC0gY29uZmlndXJlIEhUIGNhcGFiDQo+ID4gPiBhY2NvcmRpbmdseSovDQo+
ID4gPiArCWlmIChzZGF0YS0+dmlmLmJzc19jb25mLmNoYW5kZWYud2lkdGggPT0NCj4gPiA+IE5M
ODAyMTFfQ0hBTl9XSURUSF8yMCkgew0KPiA+ID4gKwkJY2FwICY9IH5JRUVFODAyMTFfSFRfQ0FQ
X1NVUF9XSURUSF8yMF80MDsNCj4gPiA+ICsJCWNhcCAmPSB+SUVFRTgwMjExX0hUX0NBUF9EU1NT
Q0NLNDA7DQo+ID4gPiArCX0NCj4gPg0KPiA+IElzIGl0IHJlcXVpcmVkIHRoYXQgSFQgY2FwYWJp
bGl0eSBtYXRjaCB0aGUgSFQgb3BlcmF0aW9uIGluIHRoaXMgY2FzZT8NCj4gPg0KPiANCj4gSXMg
dGhlcmUgZXZlciBhIGNhc2UgdGhhdCBIVCAqY2FwYWJpbGl0eSogc2hvdWxkIGJlIHJlc3RyaWN0
ZWQgDQo+IGFydGlmaWNpYWxseSBsaWtlIHRoYXQ/IEkgY2FuJ3QgcmVtZW1iZXIgYW55IGNhc2Vz
IC0gd2UgZG8gc29tZXRoaW5nIA0KPiBsaWtlIHRoYXQgdG8gd29yayBhcm91bmQgYnJva2VuIEFQ
cyBpbiBzb21lIGNhc2VzLCBidXQgaGVyZT8NCj4gDQoNCkl0IHdhcyBkb25lIHRvIG92ZXJjb21l
IGFub3RoZXIgbWlzbWF0Y2ggd2l0aCB0aGUgZGVmYXVsdHMgb2YgdGhlIGhvc3RhcCBjb25maWd1
cmF0aW9uLA0KV2UnbGwgaGF2ZSBhbm90aGVyIGxvb2sgb24gaXQuDQoNClRoZXJlIGlzIGFuIElP
UCBxdWVzdGlvbiBoZXJlLCBob3cgdG8gaGFuZGxlIGEgY2FzZSB3aGVyZSB5b3UgaGF2ZSBtaXhl
ZCBjYXBhYmlsaXRpZXMgb2YgcGVlcnMuDQppcyBpdCBwb3NzaWJsZSB0byBkeW5hbWljYWxseSBj
aGFuZ2UgdGhlIGNoYW5uZWwgYmFuZHdpZHRoIHRvIGFsbG93IG5ldyBwZWVycyB0byBqb2luID8N
Cg0KWWFuaXYNCg0K
^ 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