* [PATCH] ath10k: replace config_enabled() with IS_REACHABLE()
From: Masahiro Yamada @ 2016-08-23 16:27 UTC (permalink / raw)
To: ath10k, linux-wireless
Cc: Kalle Valo, Andrew Morton, Masahiro Yamada, netdev, linux-kernel
Commit 97f2645f358b ("tree-wide: replace config_enabled() with
IS_ENABLED()") mostly did away with config_enabled().
This is one of the postponed TODO items as config_enabled() is used
for a tristate option here. Theoretically, config_enabled() is
equivalent to IS_BUILTIN(), but I guess IS_REACHABLE() is the best
fit for this case because both CONFIG_HWMON and CONFIG_ATH10K are
tristate.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/net/wireless/ath/ath10k/thermal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/thermal.c b/drivers/net/wireless/ath/ath10k/thermal.c
index 444b52c..0a47269 100644
--- a/drivers/net/wireless/ath/ath10k/thermal.c
+++ b/drivers/net/wireless/ath/ath10k/thermal.c
@@ -192,7 +192,7 @@ int ath10k_thermal_register(struct ath10k *ar)
/* Avoid linking error on devm_hwmon_device_register_with_groups, I
* guess linux/hwmon.h is missing proper stubs. */
- if (!config_enabled(CONFIG_HWMON))
+ if (!IS_REACHABLE(CONFIG_HWMON))
return 0;
hwmon_dev = devm_hwmon_device_register_with_groups(ar->dev,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2] brcmfmac: shut down AP and set IBSS mode only on primary interface
From: Rafał Miłecki @ 2016-08-23 11:44 UTC (permalink / raw)
To: Wright Feng
Cc: open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Arend Van Spriel, Kalle Valo, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, linux-wireless@vger.kernel.org,
Chi-Hsien Lin
In-Reply-To: <DM5PR06MB2825089C55692920E0432B31D9E80@DM5PR06MB2825.namprd06.prod.outlook.com>
On 22 August 2016 at 05:40, Wright Feng <wefe@cypress.com> wrote:
> This message and any attachments may contain Cypress (or its subsidiaries=
) confidential information. If it has been received in error, please advise=
the sender and immediately delete this message.
You are aware you're writing to few open mailing lists, aren't you? I
don't think such footer makes any/much sense, please avoid it.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: checkpatch: See if modified files are marked obsolete in MAINTAINERS
From: Julia Lawall @ 2016-08-23 10:18 UTC (permalink / raw)
To: SF Markus Elfring
Cc: Joe Perches, Andrew Morton, Kalle Valo, Arend van Spriel,
Andy Whitcroft, linux-wireless, netdev, Jouni Malinen,
kernel-janitors, Julia Lawall, linux-kernel, Fengguang Wu
In-Reply-To: <d5365370-37b5-b367-ba9e-45f4e27f975a@users.sourceforge.net>
On Tue, 23 Aug 2016, SF Markus Elfring wrote:
> > Use get_maintainer to check the status of individual files.
> > If "obsolete", suggest leaving the files alone.
>
> Will another software system like the "kbuild test robot"
> need any more fine-tuning for this change?
It only works on files in which there have been commits, thus by
definition not obsolete.
julia
>
> Regards,
> Markus
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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] ath10k: Added support for extended dbglog module id for 10.4
From: c_mkenna @ 2016-08-23 10:05 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, mkenna, Maharaja Kennadyrajan
From: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
For 10.4 fw versions, dbglog module id has been extended from u32
to u64, hence this patch fixes the same in the ath10k driver side.
This patch doesn't break the older 10.4 releases. The FW change
is already present in the older FWs.
Signed-off-by: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 11 ++++----
drivers/net/wireless/ath/ath10k/wmi-ops.h | 4 +--
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 42 +++++++++++++++++++++++++++--
drivers/net/wireless/ath/ath10k/wmi.h | 14 ++++++++++
6 files changed, 64 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 30ae5bf..b7670f4 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -440,7 +440,7 @@ struct ath10k_debug {
struct completion tpc_complete;
/* protected by conf_mutex */
- u32 fw_dbglog_mask;
+ u64 fw_dbglog_mask;
u32 fw_dbglog_level;
u32 pktlog_filter;
u32 reg_addr;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 8f0fd41..832da6e 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1228,9 +1228,9 @@ static ssize_t ath10k_read_fw_dbglog(struct file *file,
{
struct ath10k *ar = file->private_data;
unsigned int len;
- char buf[64];
+ char buf[96];
- len = scnprintf(buf, sizeof(buf), "0x%08x %u\n",
+ len = scnprintf(buf, sizeof(buf), "0x%16llx %u\n",
ar->debug.fw_dbglog_mask, ar->debug.fw_dbglog_level);
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
@@ -1242,15 +1242,16 @@ static ssize_t ath10k_write_fw_dbglog(struct file *file,
{
struct ath10k *ar = file->private_data;
int ret;
- char buf[64];
- unsigned int log_level, mask;
+ char buf[96];
+ unsigned int log_level;
+ u64 mask;
simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, user_buf, count);
/* make sure that buf is null terminated */
buf[sizeof(buf) - 1] = 0;
- ret = sscanf(buf, "%x %u", &mask, &log_level);
+ ret = sscanf(buf, "%llx %u", &mask, &log_level);
if (!ret)
return -EINVAL;
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 64ebd30..e53a61a 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -123,7 +123,7 @@ struct wmi_ops {
enum wmi_force_fw_hang_type type,
u32 delay_ms);
struct sk_buff *(*gen_mgmt_tx)(struct ath10k *ar, struct sk_buff *skb);
- struct sk_buff *(*gen_dbglog_cfg)(struct ath10k *ar, u32 module_enable,
+ struct sk_buff *(*gen_dbglog_cfg)(struct ath10k *ar, u64 module_enable,
u32 log_level);
struct sk_buff *(*gen_pktlog_enable)(struct ath10k *ar, u32 filter);
struct sk_buff *(*gen_pktlog_disable)(struct ath10k *ar);
@@ -932,7 +932,7 @@ ath10k_wmi_force_fw_hang(struct ath10k *ar,
}
static inline int
-ath10k_wmi_dbglog_cfg(struct ath10k *ar, u32 module_enable, u32 log_level)
+ath10k_wmi_dbglog_cfg(struct ath10k *ar, u64 module_enable, u32 log_level)
{
struct sk_buff *skb;
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index e09337e..fbeac30 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -2441,7 +2441,7 @@ ath10k_wmi_tlv_op_gen_force_fw_hang(struct ath10k *ar,
}
static struct sk_buff *
-ath10k_wmi_tlv_op_gen_dbglog_cfg(struct ath10k *ar, u32 module_enable,
+ath10k_wmi_tlv_op_gen_dbglog_cfg(struct ath10k *ar, u64 module_enable,
u32 log_level) {
struct wmi_tlv_dbglog_cmd *cmd;
struct wmi_tlv *tlv;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index d246288..f54fe963 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -6863,7 +6863,7 @@ ath10k_wmi_op_gen_force_fw_hang(struct ath10k *ar,
}
static struct sk_buff *
-ath10k_wmi_op_gen_dbglog_cfg(struct ath10k *ar, u32 module_enable,
+ath10k_wmi_op_gen_dbglog_cfg(struct ath10k *ar, u64 module_enable,
u32 log_level)
{
struct wmi_dbglog_cfg_cmd *cmd;
@@ -6901,6 +6901,44 @@ ath10k_wmi_op_gen_dbglog_cfg(struct ath10k *ar, u32 module_enable,
}
static struct sk_buff *
+ath10k_wmi_10_4_op_gen_dbglog_cfg(struct ath10k *ar, u64 module_enable,
+ u32 log_level)
+{
+ struct wmi_10_4_dbglog_cfg_cmd *cmd;
+ struct sk_buff *skb;
+ u32 cfg;
+
+ skb = ath10k_wmi_alloc_skb(ar, sizeof(*cmd));
+ if (!skb)
+ return ERR_PTR(-ENOMEM);
+
+ cmd = (struct wmi_10_4_dbglog_cfg_cmd *)skb->data;
+
+ if (module_enable) {
+ cfg = SM(log_level,
+ ATH10K_DBGLOG_CFG_LOG_LVL);
+ } else {
+ /* set back defaults, all modules with WARN level */
+ cfg = SM(ATH10K_DBGLOG_LEVEL_WARN,
+ ATH10K_DBGLOG_CFG_LOG_LVL);
+ module_enable = ~0;
+ }
+
+ cmd->module_enable = __cpu_to_le64(module_enable);
+ cmd->module_valid = __cpu_to_le64(~0);
+ cmd->config_enable = __cpu_to_le32(cfg);
+ cmd->config_valid = __cpu_to_le32(ATH10K_DBGLOG_CFG_LOG_LVL_MASK);
+
+ ath10k_dbg(ar, ATH10K_DBG_WMI,
+ "wmi dbglog cfg modules 0x%016llx 0x%016llx config %08x %08x\n",
+ __le64_to_cpu(cmd->module_enable),
+ __le64_to_cpu(cmd->module_valid),
+ __le32_to_cpu(cmd->config_enable),
+ __le32_to_cpu(cmd->config_valid));
+ return skb;
+}
+
+static struct sk_buff *
ath10k_wmi_op_gen_pktlog_enable(struct ath10k *ar, u32 ev_bitmap)
{
struct wmi_pdev_pktlog_enable_cmd *cmd;
@@ -7968,7 +8006,7 @@ static const struct wmi_ops wmi_10_4_ops = {
.gen_pdev_set_wmm = ath10k_wmi_op_gen_pdev_set_wmm,
.gen_force_fw_hang = ath10k_wmi_op_gen_force_fw_hang,
.gen_mgmt_tx = ath10k_wmi_op_gen_mgmt_tx,
- .gen_dbglog_cfg = ath10k_wmi_op_gen_dbglog_cfg,
+ .gen_dbglog_cfg = ath10k_wmi_10_4_op_gen_dbglog_cfg,
.gen_pktlog_enable = ath10k_wmi_op_gen_pktlog_enable,
.gen_pktlog_disable = ath10k_wmi_op_gen_pktlog_disable,
.gen_pdev_set_quiet_mode = ath10k_wmi_op_gen_pdev_set_quiet_mode,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 3ef4688..b0460a4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6169,6 +6169,20 @@ struct wmi_dbglog_cfg_cmd {
__le32 config_valid;
} __packed;
+struct wmi_10_4_dbglog_cfg_cmd {
+ /* bitmask to hold mod id config*/
+ __le64 module_enable;
+
+ /* see ATH10K_DBGLOG_CFG_ */
+ __le32 config_enable;
+
+ /* mask of module id bits to be changed */
+ __le64 module_valid;
+
+ /* mask of config bits to be changed, see ATH10K_DBGLOG_CFG_ */
+ __le32 config_valid;
+} __packed;
+
enum wmi_roam_reason {
WMI_ROAM_REASON_BETTER_AP = 1,
WMI_ROAM_REASON_BEACON_MISS = 2,
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/1] brcmfmac: fix pmksa->bssid usage
From: Nicolas Iooss @ 2016-08-23 9:37 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, linux-wireless,
brcm80211-dev-list.pdl
Cc: netdev, linux-kernel, Nicolas Iooss
In-Reply-To: <7fc849f7-c178-d13e-e9cf-d107a9f73c61@m4x.org>
The struct cfg80211_pmksa defines its bssid field as:
const u8 *bssid;
contrary to struct brcmf_pmksa, which uses:
u8 bssid[ETH_ALEN];
Therefore in brcmf_cfg80211_del_pmksa(), &pmksa->bssid takes the address
of this field (of type u8**), not the one of its content (which would be
u8*). Remove the & operator to make brcmf_dbg("%pM") and memcmp()
behave as expected.
This bug have been found using a custom static checker (which checks the
usage of %p... attributes at build time). It has been introduced in
commit 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code"),
which replaced pmksa->bssid by &pmksa->bssid while refactoring the code,
without modifying struct cfg80211_pmksa definition.
Replace &pmk[i].bssid with pmk[i].bssid too to make the code clearer,
this change does not affect the semantic.
Fixes: 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code")
Cc: stable@vger.kernel.org
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 2628d5e12c64..201a98016142 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3884,11 +3884,11 @@ brcmf_cfg80211_del_pmksa(struct wiphy *wiphy, struct net_device *ndev,
if (!check_vif_up(ifp->vif))
return -EIO;
- brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", &pmksa->bssid);
+ brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", pmksa->bssid);
npmk = le32_to_cpu(cfg->pmk_list.npmk);
for (i = 0; i < npmk; i++)
- if (!memcmp(&pmksa->bssid, &pmk[i].bssid, ETH_ALEN))
+ if (!memcmp(pmksa->bssid, pmk[i].bssid, ETH_ALEN))
break;
if ((npmk > 0) && (i < npmk)) {
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 1/1] brcmfmac: fix pmksa->bssid usage
From: Nicolas Iooss @ 2016-08-23 9:30 UTC (permalink / raw)
To: Arend Van Spriel, Franky Lin, Hante Meuleman, linux-wireless,
brcm80211-dev-list.pdl
Cc: netdev, linux-kernel
In-Reply-To: <45617c4f-60b9-2587-5e29-6330ba2f40a6@broadcom.com>
On 22/08/16 21:38, Arend Van Spriel wrote:
> On 22-8-2016 15:03, Nicolas Iooss wrote:
>> On 05/08/16 22:34, Nicolas Iooss wrote:
[...]
>>> Fixes: 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code")
>>> Cc: stable@ger.kernel.org
>
> Ah, so you did something wrong after all :-p. The email address should
> be 'stable@vger.kernel.org'.
Thanks for spotting this! I'll fix this address.
>>> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
>>> ---
>>>
>>> scripts/checkpatch.pl reports a warning: "Prefer ether_addr_equal() or
>>> ether_addr_equal_unaligned() over memcmp()". Because some files in
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/ still use memcmp()
>>> to compare addresses and because I do not know whether pmksa->bssid is
>>> always aligned, I did not follow this warning.
>
> As most of this is done in slow path, I prefer memcmp() as I do not want
> to check alignment for minimal performance gain.
OK.
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> index 2628d5e12c64..aceab77cd95a 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> @@ -3884,11 +3884,11 @@ brcmf_cfg80211_del_pmksa(struct wiphy *wiphy, struct net_device *ndev,
>>> if (!check_vif_up(ifp->vif))
>>> return -EIO;
>>>
>>> - brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", &pmksa->bssid);
>>> + brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", pmksa->bssid);
>>>
>>> npmk = le32_to_cpu(cfg->pmk_list.npmk);
>>> for (i = 0; i < npmk; i++)
>>> - if (!memcmp(&pmksa->bssid, &pmk[i].bssid, ETH_ALEN))
>>> + if (!memcmp(pmksa->bssid, &pmk[i].bssid, ETH_ALEN))
>
> I find '&pmk[i].bssid' confusing so maybe you could change it to
> '&pmk[i].bssid[0]' or 'pmk[i].bssid' as I think these two are
> essentially the same.
I agree the three ways of writing this share the same meaning. I'll send
a v2 with 'pmk[i].bssid'.
>
> Regards,
> Arend
Thanks for your review!
Nicolas
^ permalink raw reply
* RE: [PATCH] wlcore: mesh: add zone time sync support
From: Mishol, Guy @ 2016-08-23 9:12 UTC (permalink / raw)
To: Kalle Valo; +Cc: Pedersen, Thomas, linux-wireless@vger.kernel.org
In-Reply-To: <87k2f8vlv2.fsf@kamboji.qca.qualcomm.com>
On Mon, Aug 22, 2016 at 18:56:01, Kalle Valo wrote:
> Subject: Re: [PATCH] wlcore: mesh: add zone time sync support
>
> "Mishol, Guy" <guym@ti.com> writes:
>
> > Kalle/Thomas,
> > Thanks for your feedback.
>
> Please don't top most, it makes using patchwork difficult and is
> annoying to the readers.
OK. Understood.
> > This time sync support is different from the one that mac80211
> > maintains with mesh peers. This time sync is mostly used by upper
> > layers for several applications (like audio). In this case we allow
> > the user to configure for each zone who will be the synchronizer.
> > You can refer to the following Application Report (chapter 6) for
> > more
> > information: http://www.ti.com/lit/an/swaa166/swaa166.pdf
>
> I didn't fully understand what this does, but debugfs doesn't sound
> (no pun
> intended) like a suitable interface for something like this. nl80211
> is more likely candidate.
Agree. The debugfs part was mainly meant for demo and can be omitted. I will submit instead a different patch that only adds the necessary APIs in the wlcore.
Guy
^ permalink raw reply
* Re: [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.
From: Arend van Spriel @ 2016-08-23 8:52 UTC (permalink / raw)
To: Kalle Valo, Toke Høiland-Jørgensen
Cc: linux-wireless, make-wifi-fast, ath9k-devel, Tim Shepard,
Felix Fietkau
In-Reply-To: <877fb8ug0x.fsf@kamboji.qca.qualcomm.com>
On 23-08-16 08:59, Kalle Valo wrote:
> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>
>>>>> This is great work but due to the regressions I'm not sure if this
>>>>> will be ready for 4.9. To get more testing time I wonder if we should
>>>>> wait for 4.10? IMHO applying this in the end of the cycle is too risky
>>>>> and we should try to maximise the time linux-next by applying this
>>>>> just after -rc1 is released.
>>>>>
>>>>> Thoughts?
>>>>
>>>> Well, now that we understand what is causing the throughput regressions,
>>>> fixing them should be fairly straight forward (yeah, famous last words,
>>>> but still...). I already have a patch for the fast path and will go poke
>>>> at the slow path next. It'll probably require another workaround or two,
>>>> so I guess it won't be the architecturally clean ideal solution; but it
>>>> would make it possible to have something that works for 4.9 and then
>>>> iterate for a cleaner design for 4.10.
>>>
>>> But if we try to rush this to 4.9 it won't be in linux-next for long. We
>>> are now in -rc3 and let's say that the patches are ready to apply in two
>>> weeks. That would leave us only two weeks of -next time before the merge
>>> window, which I think is not enough for a controversial patch like this
>>> one. There might be other bugs lurking which haven't been found yet.
>>
>> What, other hidden bugs? Unpossible! :)
>
> Yeah, right ;)
>
>> Would it be possible to merge the partial solution (which is ready now,
>> basically) and fix the slow path in a separate patch later?
>
> What do you mean with partial solution? You mean ath9k users would
> suffer from regressions until they are fixed? We can't do that.
>
>> (Just spit-balling here; I'm still fairly new to this process. But I am
>> concerned that we'll hit a catch-22 where we can't get wider testing
>> before it's "ready" and we can't prove that it's "ready" until we've had
>> wider testing...)
So could the wider testing be accomplished by working on a branch in the
wireless-testing repo and make its availability known on wireless-list,
ath?k-list, LWN or whatever.
Regards,
Arend
> I understand your point, but I don't want to rush this to 4.9 and then
> start getting lots of bug reports and eventually forced to revert it. If
> we just found a new serious regression the chances are that there are
> more lurking somewhere and this patch is just not ready yet.
^ permalink raw reply
* Re: checkpatch: See if modified files are marked obsolete in MAINTAINERS
From: SF Markus Elfring @ 2016-08-23 7:26 UTC (permalink / raw)
To: Joe Perches
Cc: Andrew Morton, Kalle Valo, Arend van Spriel, Andy Whitcroft,
linux-wireless, netdev, Jouni Malinen, kernel-janitors,
Julia Lawall, linux-kernel, Fengguang Wu
In-Reply-To: <7ceaa510dc9d2df05ec4b456baed7bb1415550b3.1471889575.git.joe@perches.com>
> Use get_maintainer to check the status of individual files.
> If "obsolete", suggest leaving the files alone.
Will another software system like the "kbuild test robot"
need any more fine-tuning for this change?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.
From: Kalle Valo @ 2016-08-23 6:59 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: linux-wireless, make-wifi-fast, ath9k-devel, Tim Shepard,
Felix Fietkau
In-Reply-To: <871t1g4thz.fsf@toke.dk>
Toke Høiland-Jørgensen <toke@toke.dk> writes:
>>>> This is great work but due to the regressions I'm not sure if this
>>>> will be ready for 4.9. To get more testing time I wonder if we should
>>>> wait for 4.10? IMHO applying this in the end of the cycle is too risky
>>>> and we should try to maximise the time linux-next by applying this
>>>> just after -rc1 is released.
>>>>
>>>> Thoughts?
>>>
>>> Well, now that we understand what is causing the throughput regressions,
>>> fixing them should be fairly straight forward (yeah, famous last words,
>>> but still...). I already have a patch for the fast path and will go poke
>>> at the slow path next. It'll probably require another workaround or two,
>>> so I guess it won't be the architecturally clean ideal solution; but it
>>> would make it possible to have something that works for 4.9 and then
>>> iterate for a cleaner design for 4.10.
>>
>> But if we try to rush this to 4.9 it won't be in linux-next for long. We
>> are now in -rc3 and let's say that the patches are ready to apply in two
>> weeks. That would leave us only two weeks of -next time before the merge
>> window, which I think is not enough for a controversial patch like this
>> one. There might be other bugs lurking which haven't been found yet.
>
> What, other hidden bugs? Unpossible! :)
Yeah, right ;)
> Would it be possible to merge the partial solution (which is ready now,
> basically) and fix the slow path in a separate patch later?
What do you mean with partial solution? You mean ath9k users would
suffer from regressions until they are fixed? We can't do that.
> (Just spit-balling here; I'm still fairly new to this process. But I am
> concerned that we'll hit a catch-22 where we can't get wider testing
> before it's "ready" and we can't prove that it's "ready" until we've had
> wider testing...)
I understand your point, but I don't want to rush this to 4.9 and then
start getting lots of bug reports and eventually forced to revert it. If
we just found a new serious regression the chances are that there are
more lurking somewhere and this patch is just not ready yet.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] brcmfmac: Add USB ID for Cisco Linksys AE1200
From: Ismael Luceno @ 2016-08-22 22:40 UTC (permalink / raw)
To: linux-wireless
Cc: Ismael Luceno, brcm80211-dev-list, Arend van Spriel,
Rafał Miłecki
The AE1200 comes with different revisions of the BCM43235 chipset,
but all have the same USB ID. Only revision 3 can be supported.
Signed-off-by: Ismael Luceno <ismael@iodev.co.uk>
---
Changes since v1:
- Keep the long device ID in a single line.
- Added desc. about supported devices.
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 4 ++++
drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 66c26a92b29c..5ec005e9f9d7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -1447,11 +1447,15 @@ static int brcmf_usb_reset_resume(struct usb_interface *intf)
#define BRCMF_USB_DEVICE(dev_id) \
{ USB_DEVICE(BRCM_USB_VENDOR_ID_BROADCOM, dev_id) }
+#define LINKSYS_USB_DEVICE(dev_id) \
+ { USB_DEVICE(BRCM_USB_VENDOR_ID_LINKSYS, dev_id) }
+
static struct usb_device_id brcmf_usb_devid_table[] = {
BRCMF_USB_DEVICE(BRCM_USB_43143_DEVICE_ID),
BRCMF_USB_DEVICE(BRCM_USB_43236_DEVICE_ID),
BRCMF_USB_DEVICE(BRCM_USB_43242_DEVICE_ID),
BRCMF_USB_DEVICE(BRCM_USB_43569_DEVICE_ID),
+ LINKSYS_USB_DEVICE(BRCM_USB_43235_LINKSYS_DEVICE_ID),
{ USB_DEVICE(BRCM_USB_VENDOR_ID_LG, BRCM_USB_43242_LG_DEVICE_ID) },
/* special entry for device with firmware loaded and running */
BRCMF_USB_DEVICE(BRCM_USB_BCMFW_DEVICE_ID),
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index 699f2c2782ee..f207c2693877 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -22,6 +22,7 @@
#define BRCM_USB_VENDOR_ID_BROADCOM 0x0a5c
#define BRCM_USB_VENDOR_ID_LG 0x043e
+#define BRCM_USB_VENDOR_ID_LINKSYS 0x13b1
#define BRCM_PCIE_VENDOR_ID_BROADCOM PCI_VENDOR_ID_BROADCOM
/* Chipcommon Core Chip IDs */
@@ -56,6 +57,7 @@
/* USB Device IDs */
#define BRCM_USB_43143_DEVICE_ID 0xbd1e
+#define BRCM_USB_43235_LINKSYS_DEVICE_ID 0x0039
#define BRCM_USB_43236_DEVICE_ID 0xbd17
#define BRCM_USB_43242_DEVICE_ID 0xbd1f
#define BRCM_USB_43242_LG_DEVICE_ID 0x3101
--
2.9.2
^ permalink raw reply related
* Re: [PATCHv7 4/4] mt7601u: use linux/bitfield.h
From: Jakub Kicinski @ 2016-08-22 20:59 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: Kalle Valo, Linux Wireless List
In-Reply-To: <8958bdba-d01d-026c-a018-f2a94bff3e52@broadcom.com>
On Mon, 22 Aug 2016 21:19:41 +0200, Arend Van Spriel wrote:
> On 22-8-2016 12:52, Jakub Kicinski wrote:
> > On Fri, 19 Aug 2016 21:02:02 +0200, Arend Van Spriel wrote:
> >> On 19-8-2016 18:44, Jakub Kicinski wrote:
> >>> Use the newly added linux/bitfield.h.
> >>>
> >>> Reviewed-by: Dinan Gunawardena <dinan.gunawardena@netronome.com>
> >>> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> >>> ---
>
> [snip]
>
> >>> diff --git a/drivers/net/wireless/mediatek/mt7601u/eeprom.c b/drivers/net/wireless/mediatek/mt7601u/eeprom.c
> >>> index 8d8ee0344f7b..da6faea092d6 100644
> >>> --- a/drivers/net/wireless/mediatek/mt7601u/eeprom.c
> >>> +++ b/drivers/net/wireless/mediatek/mt7601u/eeprom.c
> >>> @@ -45,8 +45,8 @@ mt7601u_efuse_read(struct mt7601u_dev *dev, u16 addr, u8 *data,
> >>> val = mt76_rr(dev, MT_EFUSE_CTRL);
> >>> val &= ~(MT_EFUSE_CTRL_AIN |
> >>> MT_EFUSE_CTRL_MODE);
> >>> - val |= MT76_SET(MT_EFUSE_CTRL_AIN, addr & ~0xf) |
> >>> - MT76_SET(MT_EFUSE_CTRL_MODE, mode) |
> >>> + val |= FIELD_PREP(MT_EFUSE_CTRL_AIN, addr & ~0xf) |
> >>> + FIELD_PREP(MT_EFUSE_CTRL_MODE, mode) |
> >>> MT_EFUSE_CTRL_KICK;
> >>
> >> MT_EFUSE_CTRL_KICK is probably a 1-bit field in MT_EFUSE_CTRL register.
> >> It looks like you did not want to go all the way although you do give an
> >> example in bitfield.h, ie. + * #define REG_FIELD_B BIT(7).
> >
> > True, I just wanted to show in the examples that BIT() is OK to use.
> > My feeling is that ORing in always set flags is acceptable, or at least
> > it was my feeling when I wrote this code ;)
>
> I find it tricky to have the user do the field clearing separately.
> Especially if you allow the calling function to pass additional opaque
> "flags". In my experience this is more error prone than anything else
> when dealing with bit fields and as such it is unfortunate this aspect
> is not addressed in your patches.
I don't think anything in this set prevents people from adding a
FIELD_SET() wrapper. Quite the opposite and I'd encourage it.
> I would rather see:
>
> val = mt76_rr(dev, MT_EFUSE_CTRL);
> FIELD_SET(val, MT_EFUSE_CTRL_AIN, addr & ~0xf);
> FIELD_SET(val, MT_EFUSE_CTRL_MODE, mode);
> FIELD_SET(val, MT_EFUSE_CTRL_KICK, 1);
> mt76_wr(dev, MT_EFUSE_CTRL, val);
>
> in which FIELD_SET takes care of clearing the indicated field.
Yes, I agree this is a good solution as well. The reason I didn't go
with this approach (apart from modifying an argument of a macro ;)) is
the experience with rt2x00 which followed this design and I wasn't
particularly fond of the resulting code.
I find PREP macro easier to read (less parameters). It's also
often convenient to not have to zero the variable for pure write
and be able to combine the values in a parameter list:
+ mt7601u_wr(dev, MT_TXOP_CTRL_CFG,
+ FIELD_PREP(MT_TXOP_TRUN_EN, 0x3f) |
+ FIELD_PREP(MT_TXOP_EXT_CCA_DLY, 0x58));
or:
+ reg = cpu_to_le32(FIELD_PREP(MT_TXD_INFO_TYPE, DMA_PACKET) |
+ FIELD_PREP(MT_TXD_INFO_D_PORT, CPU_TX_PORT) |
+ FIELD_PREP(MT_TXD_INFO_LEN, len));
So each approach has it's advantages and I think they complement each
other.
Please note that I'm just using mt7601u as an example, I really don't
need SET in the new code I'm trying to use these macros for now [1].
[1] https://patchwork.ozlabs.org/patch/628779/
^ permalink raw reply
* Re: [PATCH] checkpatch: See if modified files are marked obsolete in MAINTAINERS
From: Joe Perches @ 2016-08-22 20:56 UTC (permalink / raw)
To: SF Markus Elfring
Cc: Andrew Morton, Kalle Valo, Arend van Spriel, Andy Whitcroft,
linux-wireless, netdev, Jouni Malinen, kernel-janitors,
Julia Lawall, linux-kernel
In-Reply-To: <30522d64-8303-cf13-d967-a5759aeb2278@users.sourceforge.net>
On Mon, 2016-08-22 at 22:50 +0200, SF Markus Elfring wrote:
> > @@ -2289,6 +2299,10 @@ sub process {
> > }
> >
> > if ($found_file) {
> > + if (is_maintained_obsolete($realfile)) {
> > + WARN("OBSOLETE",
> > + "$realfile is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please.\n");
> > + }
> How do you think about to avoid a double negation in such a warning message?
>
> Would a wording like "… Only really necessary modifications please.\n"
> be more useful here?
No, probably not.
^ permalink raw reply
* Re: [PATCH] checkpatch: See if modified files are marked obsolete in MAINTAINERS
From: SF Markus Elfring @ 2016-08-22 20:50 UTC (permalink / raw)
To: Joe Perches
Cc: Andrew Morton, Kalle Valo, Arend van Spriel, Andy Whitcroft,
linux-wireless, netdev, Jouni Malinen, kernel-janitors,
Julia Lawall, linux-kernel
In-Reply-To: <7ceaa510dc9d2df05ec4b456baed7bb1415550b3.1471889575.git.joe@perches.com>
> @@ -2289,6 +2299,10 @@ sub process {
> }
>
> if ($found_file) {
> + if (is_maintained_obsolete($realfile)) {
> + WARN("OBSOLETE",
> + "$realfile is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please.\n");
> + }
How do you think about to avoid a double negation in such a warning message?
Would a wording like "… Only really necessary modifications please.\n"
be more useful here?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 2/5] ath9k: Set the "big endian" bit of the AR9003 EEPROM templates
From: Martin Blumenstingl @ 2016-08-22 20:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kvalo, ath9k-devel, linux-wireless, ath9k-devel, devicetree,
robh+dt, mark.rutland, chunkeey, nbd
In-Reply-To: <14216135.Y4g7Oly61q@wuerfel>
On Mon, Aug 22, 2016 at 5:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, August 22, 2016 1:56:46 PM CEST Martin Blumenstingl wrote:
>> On Mon, Aug 22, 2016 at 1:47 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote:
>> >> We will default to the system's native endianness for the eepmisc value.
>> >> This may be overwritten by the actual calibration data. If it is not
>> >> overwritten we interpret the template data in it's native endianness,
>> >> meaning that no swapping is required.
>> >
>> > I'm still skeptical about this one. What is the significance of "native
>> > endianess" here? You are keying the endianess of the eeprom tables off the
>> > way the CPU operates, but for a PCI device there is no correlation between
>> > those two.
>> (the ar9003 eeprom format and handling is different compared to 9287,
>> def and 4k)
>> ar9003_eeprom.c contains EEPROM templates -> these are compiled into
>> the ath9k kernel module. Values from these templates can be
>> overwritten by the EEPROM found on the actual hardware.
>> This change tries to handle the case where the values in the hardware
>> EEPROM do not override any of the template values (means final EEPROM
>> data = template data). In this case the we can simply rely on the
>> endianness which was used to compile ath9k.ko.
>
> Ok, I see what you mean now. However, looking at the source now, I
> also see
>
> #define LE16(x) cpu_to_le16(x)
> #define LE32(x) cpu_to_le32(x)
> .baseEepHeader = {
> .regDmn = { LE16(0), LE16(0x1f) },
>
> suggesting that the fields are meant to be little-endian in object
> code, and your patch does not change that. In fact, Felix's
> ffdc4cbe5b17 ("ath9k_hw: clean up EEPROM endian handling on AR9003")
> seems to have corrected this already.
oh, I totally missed that - thanks for the hint!
This means that eepMisc should be 0 (indicates little endian) in all
cases (it had this value, but the code was not explicit about it).
so please ignore this patch for now, it might cause more harm than good.
^ permalink raw reply
* Re: [PATCH 1/1] brcmfmac: fix pmksa->bssid usage
From: Arend Van Spriel @ 2016-08-22 19:38 UTC (permalink / raw)
To: Nicolas Iooss, Franky Lin, Hante Meuleman, linux-wireless,
brcm80211-dev-list.pdl
Cc: netdev, linux-kernel
In-Reply-To: <96ea6e57-79d7-d4ff-1228-6f22addd4996@m4x.org>
On 22-8-2016 15:03, Nicolas Iooss wrote:
> Hello,
>
> After I sent the following patch a few weeks ago, I have not received
> any feedback. Could you please review it and tell me what I may have
> done wrong?
Nothing. People went on vacation :-)
> Thanks,
> Nicolas
>
> On 05/08/16 22:34, Nicolas Iooss wrote:
>> The struct cfg80211_pmksa defines its bssid field as:
>>
>> const u8 *bssid;
>>
>> contrary to struct brcmf_pmksa, which uses:
>>
>> u8 bssid[ETH_ALEN];
>>
>> Therefore in brcmf_cfg80211_del_pmksa(), &pmksa->bssid takes the address
>> of this field (of type u8**), not the one of its content (which would be
>> u8*). Remove the & operator to make brcmf_dbg("%pM") and memcmp()
>> behave as expected.
>>
>> This bug have been found using a custom static checker (which checks the
>> usage of %p... attributes at build time). It has been introduced in
>> commit 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code"),
>> which replaced pmksa->bssid by &pmksa->bssid while refactoring the code,
>> without modifying struct cfg80211_pmksa definition.
>>
>> Fixes: 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code")
>> Cc: stable@ger.kernel.org
Ah, so you did something wrong after all :-p. The email address should
be 'stable@vger.kernel.org'.
>> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
>> ---
>>
>> scripts/checkpatch.pl reports a warning: "Prefer ether_addr_equal() or
>> ether_addr_equal_unaligned() over memcmp()". Because some files in
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/ still use memcmp()
>> to compare addresses and because I do not know whether pmksa->bssid is
>> always aligned, I did not follow this warning.
As most of this is done in slow path, I prefer memcmp() as I do not want
to check alignment for minimal performance gain.
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> index 2628d5e12c64..aceab77cd95a 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> @@ -3884,11 +3884,11 @@ brcmf_cfg80211_del_pmksa(struct wiphy *wiphy, struct net_device *ndev,
>> if (!check_vif_up(ifp->vif))
>> return -EIO;
>>
>> - brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", &pmksa->bssid);
>> + brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", pmksa->bssid);
>>
>> npmk = le32_to_cpu(cfg->pmk_list.npmk);
>> for (i = 0; i < npmk; i++)
>> - if (!memcmp(&pmksa->bssid, &pmk[i].bssid, ETH_ALEN))
>> + if (!memcmp(pmksa->bssid, &pmk[i].bssid, ETH_ALEN))
I find '&pmk[i].bssid' confusing so maybe you could change it to
'&pmk[i].bssid[0]' or 'pmk[i].bssid' as I think these two are
essentially the same.
Regards,
Arend
>> break;
>>
>> if ((npmk > 0) && (i < npmk)) {
>>
>
^ permalink raw reply
* [PATCH V2] rtlwifi: Fix missing country code for Great Britain
From: Larry Finger @ 2016-08-22 19:27 UTC (permalink / raw)
To: kvalo; +Cc: devel, linux-wireless, Larry Finger, Stable
Some RTL8821AE devices sold in Great Britain have the country code of
0x25 encoded in their EEPROM. This value is not tested in the routine
that establishes the regulatory info for the chip. The fix is to set
this code to have the same capabilities as the EU countries. In addition,
the channels allowed for COUNTRY_CODE_ETSI were more properly suited
for China and Israel, not the EU. This problem has also been fixed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
---
V2 - Explain why channels for ETSI have been modified.
---
drivers/net/wireless/realtek/rtlwifi/regd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c b/drivers/net/wireless/realtek/rtlwifi/regd.c
index 3524441..6ee6bf8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/regd.c
+++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
@@ -345,9 +345,9 @@ static const struct ieee80211_regdomain *_rtl_regdomain_select(
return &rtl_regdom_no_midband;
case COUNTRY_CODE_IC:
return &rtl_regdom_11;
- case COUNTRY_CODE_ETSI:
case COUNTRY_CODE_TELEC_NETGEAR:
return &rtl_regdom_60_64;
+ case COUNTRY_CODE_ETSI:
case COUNTRY_CODE_SPAIN:
case COUNTRY_CODE_FRANCE:
case COUNTRY_CODE_ISRAEL:
@@ -406,6 +406,8 @@ static u8 channel_plan_to_country_code(u8 channelplan)
return COUNTRY_CODE_WORLD_WIDE_13;
case 0x22:
return COUNTRY_CODE_IC;
+ case 0x25:
+ return COUNTRY_CODE_ETSI;
case 0x32:
return COUNTRY_CODE_TELEC_NETGEAR;
case 0x41:
--
2.6.6
^ permalink raw reply related
* Re: [PATCH] rtlwifi: Fix missing country code for Great Britain
From: Larry Finger @ 2016-08-22 19:23 UTC (permalink / raw)
To: Kalle Valo; +Cc: devel, linux-wireless, Stable
In-Reply-To: <87wpj8vmqs.fsf@kamboji.qca.qualcomm.com>
On 08/22/2016 10:36 AM, Kalle Valo wrote:
> Larry Finger <Larry.Finger@lwfinger.net> writes:
>
>> Some RTL8821AE devices sold in Great Britain have the country code of
>> 0x25 encoded in their EEPROM. This value is not tested in the routine
>> that establishes the regulatory info for the chip. The fix is to set
>> this code to have the same capabilities as the EU countries.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> Cc: Stable <stable@vger.kernel.org>
>
> [...]
>
>> --- a/drivers/net/wireless/realtek/rtlwifi/regd.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
>> @@ -345,9 +345,9 @@ static const struct ieee80211_regdomain *_rtl_regdomain_select(
>> return &rtl_regdom_no_midband;
>> case COUNTRY_CODE_IC:
>> return &rtl_regdom_11;
>> - case COUNTRY_CODE_ETSI:
>> case COUNTRY_CODE_TELEC_NETGEAR:
>> return &rtl_regdom_60_64;
>> + case COUNTRY_CODE_ETSI:
>> case COUNTRY_CODE_SPAIN:
>> case COUNTRY_CODE_FRANCE:
>> case COUNTRY_CODE_ISRAEL:
>
> I didn't check the full source, but here you seem to be changing also
> the content of ETSI regdomain. The commit log doesn't mention anything
> about that so I want to double check that this is really intentionally.
Yes, I did intend to change all of ETSI. It was previously allowing channels
appropriate for China and Israel.
I will resubmit with an improved commit message.
Thanks,
Larry
^ permalink raw reply
* Re: [PATCHv7 4/4] mt7601u: use linux/bitfield.h
From: Arend Van Spriel @ 2016-08-22 19:19 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Kalle Valo, Linux Wireless List
In-Reply-To: <20160822115254.62ee6589@jkicinski-Precision-T1700>
On 22-8-2016 12:52, Jakub Kicinski wrote:
> On Fri, 19 Aug 2016 21:02:02 +0200, Arend Van Spriel wrote:
>> On 19-8-2016 18:44, Jakub Kicinski wrote:
>>> Use the newly added linux/bitfield.h.
>>>
>>> Reviewed-by: Dinan Gunawardena <dinan.gunawardena@netronome.com>
>>> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>>> ---
[snip]
>>> diff --git a/drivers/net/wireless/mediatek/mt7601u/eeprom.c b/drivers/net/wireless/mediatek/mt7601u/eeprom.c
>>> index 8d8ee0344f7b..da6faea092d6 100644
>>> --- a/drivers/net/wireless/mediatek/mt7601u/eeprom.c
>>> +++ b/drivers/net/wireless/mediatek/mt7601u/eeprom.c
>>> @@ -45,8 +45,8 @@ mt7601u_efuse_read(struct mt7601u_dev *dev, u16 addr, u8 *data,
>>> val = mt76_rr(dev, MT_EFUSE_CTRL);
>>> val &= ~(MT_EFUSE_CTRL_AIN |
>>> MT_EFUSE_CTRL_MODE);
>>> - val |= MT76_SET(MT_EFUSE_CTRL_AIN, addr & ~0xf) |
>>> - MT76_SET(MT_EFUSE_CTRL_MODE, mode) |
>>> + val |= FIELD_PREP(MT_EFUSE_CTRL_AIN, addr & ~0xf) |
>>> + FIELD_PREP(MT_EFUSE_CTRL_MODE, mode) |
>>> MT_EFUSE_CTRL_KICK;
>>
>> MT_EFUSE_CTRL_KICK is probably a 1-bit field in MT_EFUSE_CTRL register.
>> It looks like you did not want to go all the way although you do give an
>> example in bitfield.h, ie. + * #define REG_FIELD_B BIT(7).
>
> True, I just wanted to show in the examples that BIT() is OK to use.
> My feeling is that ORing in always set flags is acceptable, or at least
> it was my feeling when I wrote this code ;)
I find it tricky to have the user do the field clearing separately.
Especially if you allow the calling function to pass additional opaque
"flags". In my experience this is more error prone than anything else
when dealing with bit fields and as such it is unfortunate this aspect
is not addressed in your patches.
I would rather see:
val = mt76_rr(dev, MT_EFUSE_CTRL);
FIELD_SET(val, MT_EFUSE_CTRL_AIN, addr & ~0xf);
FIELD_SET(val, MT_EFUSE_CTRL_MODE, mode);
FIELD_SET(val, MT_EFUSE_CTRL_KICK, 1);
mt76_wr(dev, MT_EFUSE_CTRL, val);
in which FIELD_SET takes care of clearing the indicated field. I am
wondering how much these two solutions differ in terms of assembly
instructions.
Regards,
Arend
^ permalink raw reply
* [PATCH] zd1211rw: fix spelling mistake "firmeware" -> "firmware"
From: Colin King @ 2016-08-22 18:35 UTC (permalink / raw)
To: Daniel Drake, Ulrich Kunitz, Kalle Valo, linux-wireless, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in dev_err message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_usb.c b/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
index a912dc0..c5effd6c 100644
--- a/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
@@ -193,7 +193,7 @@ static int upload_code(struct usb_device *udev,
0, 0, p, sizeof(ret), 5000 /* ms */);
if (r != sizeof(ret)) {
dev_err(&udev->dev,
- "control request firmeware confirmation failed."
+ "control request firmware confirmation failed."
" Return value %d\n", r);
if (r >= 0)
r = -ENODEV;
--
2.9.3
^ permalink raw reply related
* [PATCH] checkpatch: See if modified files are marked obsolete in MAINTAINERS
From: Joe Perches @ 2016-08-22 18:17 UTC (permalink / raw)
To: Andrew Morton, Kalle Valo, Arend van Spriel, Andy Whitcroft
Cc: SF Markus Elfring, linux-wireless, netdev, Jouni Malinen,
kernel-janitors, Julia Lawall, linux-kernel
In-Reply-To: <87shtwvm63.fsf@kamboji.qca.qualcomm.com>
Use get_maintainer to check the status of individual files.
If "obsolete", suggest leaving the files alone.
Signed-off-by: Joe Perches <joe@perches.com>
---
scripts/checkpatch.pl | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4de3cc4..df5e9d9 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -704,6 +704,16 @@ sub seed_camelcase_file {
}
}
+sub is_maintained_obsolete {
+ my ($filename) = @_;
+
+ return 0 if (!(-e "$root/scripts/get_maintainer.pl"));
+
+ my $status = `perl $root/scripts/get_maintainer.pl --status --nom --nol --nogit --nogit-fallback $filename 2>&1`;
+
+ return $status =~ /obsolete/i;
+}
+
my $camelcase_seeded = 0;
sub seed_camelcase_includes {
return if ($camelcase_seeded);
@@ -2289,6 +2299,10 @@ sub process {
}
if ($found_file) {
+ if (is_maintained_obsolete($realfile)) {
+ WARN("OBSOLETE",
+ "$realfile is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please.\n");
+ }
if ($realfile =~ m@^(?:drivers/net/|net/|drivers/staging/)@) {
$check = 1;
} else {
--
2.8.0.rc4.16.g56331f8
^ permalink raw reply related
* Re: [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.
From: Toke Høiland-Jørgensen @ 2016-08-22 17:13 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, make-wifi-fast, ath9k-devel, Tim Shepard,
Felix Fietkau
In-Reply-To: <87fupwvisn.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes:
>
>> Kalle Valo <kvalo@codeaurora.org> writes:
>>
>>> Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes:
>>>
>>>> This switches ath9k over to using the mac80211 intermediate software
>>>> queueing mechanism for data packets. It removes the queueing inside the
>>>> driver, except for the retry queue, and instead pulls from mac80211 wh=
en
>>>> a packet is needed. The retry queue is used to store a packet that was
>>>> pulled but can't be sent immediately.
>>>>
>>>> The old code path in ath_tx_start that would queue packets has been
>>>> removed completely, as has the qlen limit tunables (since there's no
>>>> longer a queue in the driver to limit).
>>>>
>>>> Based on Tim's original patch set, but reworked quite thoroughly.
>>>>
>>>> Cc: Tim Shepard <shep@alum.mit.edu>
>>>> Cc: Felix Fietkau <nbd@nbd.name>
>>>> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
>>>> ---
>>>> Changes since v3 (most due to Felix; thanks!):
>>>> - Correctly notify mac80211 when there are packets in the retry queue
>>>> on powersave start/stop.
>>>> - Get rid of ath_tx_aggr_resume().
>>>> - Some readability changes and additional WARN_ON/BUG_ON in
>>>> appropriate places.
>>>
>>> This is great work but due to the regressions I'm not sure if this
>>> will be ready for 4.9. To get more testing time I wonder if we should
>>> wait for 4.10? IMHO applying this in the end of the cycle is too risky
>>> and we should try to maximise the time linux-next by applying this
>>> just after -rc1 is released.
>>>
>>> Thoughts?
>>
>> Well, now that we understand what is causing the throughput regressions,
>> fixing them should be fairly straight forward (yeah, famous last words,
>> but still...). I already have a patch for the fast path and will go poke
>> at the slow path next. It'll probably require another workaround or two,
>> so I guess it won't be the architecturally clean ideal solution; but it
>> would make it possible to have something that works for 4.9 and then
>> iterate for a cleaner design for 4.10.
>
> But if we try to rush this to 4.9 it won't be in linux-next for long. We
> are now in -rc3 and let's say that the patches are ready to apply in two
> weeks. That would leave us only two weeks of -next time before the merge
> window, which I think is not enough for a controversial patch like this
> one. There might be other bugs lurking which haven't been found yet.
What, other hidden bugs? Unpossible! :)
Would it be possible to merge the partial solution (which is ready now,
basically) and fix the slow path in a separate patch later?
(Just spit-balling here; I'm still fairly new to this process. But I am
concerned that we'll hit a catch-22 where we can't get wider testing
before it's "ready" and we can't prove that it's "ready" until we've had
wider testing...)
-Toke
^ permalink raw reply
* Re: [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.
From: Kalle Valo @ 2016-08-22 17:02 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: linux-wireless, make-wifi-fast, ath9k-devel, Tim Shepard,
Felix Fietkau
In-Reply-To: <87bn0k4w4d.fsf@toke.dk>
Toke Høiland-Jørgensen <toke@toke.dk> writes:
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>>
>>> This switches ath9k over to using the mac80211 intermediate software
>>> queueing mechanism for data packets. It removes the queueing inside the
>>> driver, except for the retry queue, and instead pulls from mac80211 when
>>> a packet is needed. The retry queue is used to store a packet that was
>>> pulled but can't be sent immediately.
>>>
>>> The old code path in ath_tx_start that would queue packets has been
>>> removed completely, as has the qlen limit tunables (since there's no
>>> longer a queue in the driver to limit).
>>>
>>> Based on Tim's original patch set, but reworked quite thoroughly.
>>>
>>> Cc: Tim Shepard <shep@alum.mit.edu>
>>> Cc: Felix Fietkau <nbd@nbd.name>
>>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>>> ---
>>> Changes since v3 (most due to Felix; thanks!):
>>> - Correctly notify mac80211 when there are packets in the retry queue
>>> on powersave start/stop.
>>> - Get rid of ath_tx_aggr_resume().
>>> - Some readability changes and additional WARN_ON/BUG_ON in
>>> appropriate places.
>>
>> This is great work but due to the regressions I'm not sure if this
>> will be ready for 4.9. To get more testing time I wonder if we should
>> wait for 4.10? IMHO applying this in the end of the cycle is too risky
>> and we should try to maximise the time linux-next by applying this
>> just after -rc1 is released.
>>
>> Thoughts?
>
> Well, now that we understand what is causing the throughput regressions,
> fixing them should be fairly straight forward (yeah, famous last words,
> but still...). I already have a patch for the fast path and will go poke
> at the slow path next. It'll probably require another workaround or two,
> so I guess it won't be the architecturally clean ideal solution; but it
> would make it possible to have something that works for 4.9 and then
> iterate for a cleaner design for 4.10.
But if we try to rush this to 4.9 it won't be in linux-next for long. We
are now in -rc3 and let's say that the patches are ready to apply in two
weeks. That would leave us only two weeks of -next time before the merge
window, which I think is not enough for a controversial patch like this
one. There might be other bugs lurking which haven't been found yet.
--
Kalle Valo
^ permalink raw reply
* Re: ath9k: Fix beacon configuration assertion failure
From: Ioan-Adrian Ratiu @ 2016-08-22 16:18 UTC (permalink / raw)
To: Kalle Valo, Benjamin Berg
Cc: linux-wireless, ath9k-devel, ath9k-devel, linux-kernel,
Felix Fietkau
In-Reply-To: <87r39h3p0f.fsf@purkki.adurom.net>
On Mon, 22 Aug 2016, Kalle Valo <kvalo@codeaurora.org> wrote:
> Benjamin Berg <benjamin.berg@open-mesh.com> writes:
>
>> On Fr, 2016-08-19 at 13:03 +0300, Kalle Valo wrote:
>>> Actually, I see two patches which might be related but not identical:
>>>=20
>>> ath9k: fix client mode beacon configuration
>>> https://patchwork.kernel.org/patch/9247699/
>>>=20
>>> ath9k: Fix beacon configuration assertion failure
>>> https://patchwork.kernel.org/patch/9281191/
>>>=20
>>> Felix (CCed) & Benjamin: please take a look and advice which one I
>>> should take.
>>
>> Yes, both patches are designed to fix the same issue in my patch.
>>
>> Felix solution looks entirely correct to me, the second solution seems
>> slightly wrong because it prevents the call to ath9k_beacon_config from
>> happening instead of ensuring the correct parameter value.
>> ath9k_beacon_config needs to be called even if iter_data.beacons=C2=A0is
>> false as it disables the interrupts.
>
> Ok, I'll the patch from Felix then. Thanks.
Tested Felix patch. Confirm it works great. Thanks!
>
> --=20
> Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/3] hostap: Fine-tuning for a few functions
From: Joe Perches @ 2016-08-22 16:18 UTC (permalink / raw)
To: Kalle Valo, Arend van Spriel
Cc: SF Markus Elfring, linux-wireless, netdev, Jouni Malinen, LKML,
kernel-janitors, Julia Lawall
In-Reply-To: <87shtwvm63.fsf@kamboji.qca.qualcomm.com>
On Mon, 2016-08-22 at 18:49 +0300, Kalle Valo wrote:
> Arend van Spriel <arend.vanspriel@broadcom.com> writes:
[]
> But yeah, not really sure what to do with these obsolete drivers like
> hostap, ray_cs and wl3501.
Maybe marking sections obsolete in MAINTAINERS could
flag some "shouldn't touch this" warning for old code
in checkpatch.pl and/or get_maintainer.pl
^ 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