Re: [PATCH] ath10k: disable wake_tx_queue for older devices

[Roman Yeryomin]

On 7 July 2016 at 19:30, Valo, Kalle  wrote:
> Michal Kazior  writes:
>
>> 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 
>
> I think it's too late to send this to 4.7 anymore (and this due to my
> vacation). So I'm planning to queue this to 4.8, but if the feedback is
> positive we can always send this to a 4.7 stable release.
>

Sorry guys, drowned.
So, yes, applying this patch does the job. That is gets me to the
results similar to
https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041448.html

Going to try latest code on same system...

Regards,
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] rtlwifi: remove superfluous condition

[Larry Finger]

On 07/31/2016 05:30 AM, Heinrich Schuchardt wrote:

If sta == NULL, the changed line will not be reached.
So no need to check if stat == NULL here.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


I agree. If sta were NULL, we would never have reached this statement. There is, 
however, a typo in the last line of the commit message. Once this is fixed, you 
may add the line "Acked-by: Larry Finger "


Thanks,

Larry



diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c 
b/drivers/net/wireless/realtek/rtlwifi/core.c
index 41f77f8..7aee5ebb1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1135,7 +1135,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw 
*hw,
mac->mode = WIRELESS_MODE_AC_24G;
}

-   if (vif->type == NL80211_IFTYPE_STATION && sta)
+   if (vif->type == NL80211_IFTYPE_STATION)
rtlpriv->cfg->ops->update_rate_tbl(hw, sta, 0);
rcu_read_unlock();




--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] mwifiex: key_material_v2 remove superfluous condition

[Heinrich Schuchardt]

We are using mac as source address in a memcpy.
In the lines below we can assume mac is not NULL.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 128add8..0d4f9fe 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -706,15 +706,10 @@ mwifiex_cmd_802_11_key_material_v2(struct mwifiex_private 
*priv,
(priv->wep_key_curr_index & KEY_INDEX_MASK))
key_info |= KEY_DEFAULT;
} else {
-   if (mac) {
-   if (is_broadcast_ether_addr(mac))
-   key_info |= KEY_MCAST;
-   else
-   key_info |= KEY_UNICAST |
-   KEY_DEFAULT;
-   } else {
+   if (is_broadcast_ether_addr(mac))
key_info |= KEY_MCAST;
-   }
+   else
+   key_info |= KEY_UNICAST | KEY_DEFAULT;
}
}
km->key_param_set.key_info = cpu_to_le16(key_info);
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] mwifiex: remove superfluous condition (2)

[Kalle Valo]

Heinrich Schuchardt  writes:

> We are using mac as source address in a memcpy.
> In the lines below we can assume mac is not NULL.
>
> Signed-off-by: Heinrich Schuchardt 

Please try to make the commit titles unique, for example you can use
function names or something else. Adding "(2)" is not the way to do
that.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] mwifiex: remove superfluous condition (2)

[Heinrich Schuchardt]

We are using mac as source address in a memcpy.
In the lines below we can assume mac is not NULL.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 128add8..0d4f9fe 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -706,15 +706,10 @@ mwifiex_cmd_802_11_key_material_v2(struct mwifiex_private 
*priv,
(priv->wep_key_curr_index & KEY_INDEX_MASK))
key_info |= KEY_DEFAULT;
} else {
-   if (mac) {
-   if (is_broadcast_ether_addr(mac))
-   key_info |= KEY_MCAST;
-   else
-   key_info |= KEY_UNICAST |
-   KEY_DEFAULT;
-   } else {
+   if (is_broadcast_ether_addr(mac))
key_info |= KEY_MCAST;
-   }
+   else
+   key_info |= KEY_UNICAST | KEY_DEFAULT;
}
}
km->key_param_set.key_info = cpu_to_le16(key_info);
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] mwifiex: remove superfluous condition

[Heinrich Schuchardt]

for_each_property_of_node is only executed if the
property prop is not NULL.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 7897037..128add8 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1482,7 +1482,7 @@ int mwifiex_dnld_dt_cfgdata(struct mwifiex_private *priv,
continue;
 
/* property header is 6 bytes, data must fit in cmd buffer */
-   if (prop && prop->value && prop->length > 6 &&
+   if (prop->value && prop->length > 6 &&
prop->length <= MWIFIEX_SIZE_OF_CMD_BUFFER - S_DS_GEN) {
ret = mwifiex_send_cmd(priv, HostCmd_CMD_CFG_DATA,
   HostCmd_ACT_GEN_SET, 0,
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] rtlwifi: remove superfluous condition

[Heinrich Schuchardt]

If sta == NULL, the changed line will not be reached.
So no need to check if stat == NULL here.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c 
b/drivers/net/wireless/realtek/rtlwifi/core.c
index 41f77f8..7aee5ebb1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1135,7 +1135,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw 
*hw,
mac->mode = WIRELESS_MODE_AC_24G;
}
 
-   if (vif->type == NL80211_IFTYPE_STATION && sta)
+   if (vif->type == NL80211_IFTYPE_STATION)
rtlpriv->cfg->ops->update_rate_tbl(hw, sta, 0);
rcu_read_unlock();
 
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dell Venue 8 Pro "Dell Wireless" (Atheros 6k) chipset with SDIO ID 0271:0418 not recognized/supported

[Kalle Valo]

russianneuroman...@ya.ru writes:

> Please look into commentary 50 from bugreport 
> https://bugzilla.kernel.org/show_bug.cgi?id=67921#c50 
> There is patch for enabling support of Atheros Wireless adapter in Dell Venue 
> 8 Pro tablet.
>  
> Please review if this possible to include this patch into upstream.

Do you mean this ath6kl patch:

https://github.com/AdamWill/baytrail-m/blob/master/kernel/support-Dell-OEM-chipset-found-in-Venue-8-Pro-SDIO-I.patch

That looks good to me, but please submit it officially as defined in the wiki:

https://wireless.wiki.kernel.org/en/users/drivers/ath6kl#hacking_on_ath6kl

I also saw the comment about broken ath.git link, I fixed that now.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

[Dmitry Torokhov]

On July 30, 2016 9:58:17 AM PDT, "Luis R. Rodriguez"  wrote:
>On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote:
>> + Luis (again) ;-)
>> 
>> On 29-07-16 08:13, Daniel Wagner wrote:
>> > On 07/28/2016 09:01 PM, Bjorn Andersson wrote:
>> >> On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote:
>> >>
>> >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote:
>>  From: Daniel Wagner 
>> 
>> >> [..]
>> >>>
>> >>> Do not quite like it... I'd rather asynchronous request give out
>a
>> >>> firmware status pointer that could be used later on.
>> 
>> Excellent. Why not get rid of the callback function as well and have
>> fw_loading_wait() return result (0 = firmware available, < 0 = fail).
>> Just to confirm, you are proposing a new API function next to
>> request_firmware_nowait(), right?
>
>If proposing new firmware_class patches please bounce / Cc me, I've
>recently asked for me to be added to MAINTAINERS so I get these
>e-mails as I'm working on a new flexible API which would allow us
>to extend the firmware API without having to care about the old
>stupid usermode helper at all.

I am not sure why we started calling usermode helper "stupid". We only had to 
implement direct kernel firmware loading because udev/stsremd folks had 
"interesting" ideas how events should be handled; but having userspace to feed 
us data is not stupid.

If we want to overhaul firmware loading support we need to figure out how to 
support case when a driver want to [asynchronously] request 
firmware/config/blob and the rest of the system is not ready. Even if we want 
kernel to do read/load the data we need userspace to tell kernel when firmware 
partition is available, until then the kernel should not fail the request.


Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

[Dmitry Torokhov]

On July 30, 2016 5:42:41 AM PDT, Arend van Spriel 
 wrote:
>+ Luis (again) ;-)
>
>On 29-07-16 08:13, Daniel Wagner wrote:
>> On 07/28/2016 09:01 PM, Bjorn Andersson wrote:
>>> On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote:
>>>
 On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote:
> From: Daniel Wagner 
>
>>> [..]

 Do not quite like it... I'd rather asynchronous request give out a
 firmware status pointer that could be used later on.
>
>Excellent. Why not get rid of the callback function as well and have
>fw_loading_wait() return result (0 = firmware available, < 0 = fail).
>Just to confirm, you are proposing a new API function next to
>request_firmware_nowait(), right?

Yes, that would be a new API call. Maybe we could replace old API with the new 
at some point.


 pcu->fw_st = request_firmware_async(IMS_PCU_FIRMWARE_NAME,
 -   pcu,
 -   ims_pcu_process_async_firmware);
>+  pcu);
 if (IS_ERR(pcu->fw_st))
 return PTR_ERR(pcu->fw_st);

 

 err = fw_loading_wait(pcu->fw_st);
>   if (err)
>   return err;
>
>   fw = fwstat_get_firmware(pcu->fw_st);
>
>Or whatever consistent prefix it is going to be.
>

>>>
>>> In the remoteproc case (patch 6) this would clean up the code,
>rather
>>> than replacing the completion API 1 to 1. I like it!
>> 
>> IIRC most drivers do it the same way. So request_firmware_async()
>indeed
>> would be good thing to have. Let me try that.
>
>While the idea behind this series is a good one I am wondering about
>the
>need for these drivers to use the asynchronous API. The historic reason
>might be to avoid timeout caused by user-mode helper, but that may no
>longer apply and these drivers could be better off using
>request_firmware_direct().

Actually systems using this driver rely on usermode helper to provide necessary 
delay and load the firmware from storage once root partition is mounted. 
Converting to request_firmware_direct() would break them.


Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html