* [PATCH] rtlwifi: Fix alignment issues
From: Larry Finger @ 2016-12-28 21:40 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Ping-Ke Shih, Larry Finger, Stable
From: Ping-Ke Shih <pkshih@realtek.com>
The addresses of Wlan NIC registers are natural alignment, but some
drivers have bugs. These are evident on platforms that need natural
alignment to access registers. This change contains the following:
1. Function _rtl8821ae_dbi_read() is used to read one byte from DBI,
thus it should use rtl_read_byte().
2. Register 0x4C7 of 8192ee is single byte.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
---
Kalle,
Please send this upstream when convenient. These fixes will improve operations
on architectures that are fussy about alignment.
Larry
---
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
index 99827d2..54ea173 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
@@ -1006,7 +1006,7 @@ static void _rtl92ee_hw_configure(struct ieee80211_hw *hw)
rtl_write_word(rtlpriv, REG_SIFS_TRX, 0x100a);
/* Note Data sheet don't define */
- rtl_write_word(rtlpriv, 0x4C7, 0x80);
+ rtl_write_byte(rtlpriv, 0x4C7, 0x80);
rtl_write_byte(rtlpriv, REG_RX_PKT_LIMIT, 0x20);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 0b26bd0..e374320 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1124,7 +1124,7 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, u16 addr)
}
if (0 == tmp) {
read_addr = REG_DBI_RDATA + addr % 4;
- ret = rtl_read_word(rtlpriv, read_addr);
+ ret = rtl_read_byte(rtlpriv, read_addr);
}
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties
From: Rafał Miłecki @ 2016-12-28 22:22 UTC (permalink / raw)
To: Felix Fietkau
Cc: Kalle Valo, linux-wireless@vger.kernel.org, Martin Blumenstingl,
Arnd Bergmann, devicetree@vger.kernel.org,
Rafał Miłecki
In-Reply-To: <ddd1bb11-eb4d-7a53-c3ea-5ff5e59ae100@nbd.name>
On 28 December 2016 at 22:35, Felix Fietkau <nbd@nbd.name> wrote:
> On 2016-12-28 16:59, Rafa=C5=82 Mi=C5=82ecki wrote:
>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>
>> This new file should be used for properties handled at higher level and
>> so usable with all drivers.
>>
>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>> ---
>> .../devicetree/bindings/net/wireless/ieee80211.txt | 16 +++++++++=
+++++++
>> 1 file changed, 16 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee8=
0211.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.tx=
t b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> new file mode 100644
>> index 0000000..c762769
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> @@ -0,0 +1,16 @@
>> +Common IEEE 802.11 properties
>> +
>> +This provides documentation of common properties that are handled by a =
proper
>> +net layer and don't require extra driver code.
>> +
>> +Optional properties:
>> + - ieee80211-min-center-freq : minimal supported frequency in KHz
>> + - ieee80211-max-center-freq : maximal supported frequency in KHz
>> +
>> +Example:
>> +
>> +pcie@0,0 {
>> + reg =3D <0x0000 0 0 0 0>;
>> + ieee80211-min-center-freq =3D <2437000>;
>> + ieee80211-max-center-freq =3D <2457000>;
> I'm not sure that's the best way to deal with enabling/disabling bands.
> If we get more bands in the future, there might be unsupported ones in
> the middle, which min/max won't cover.
Maybe we could try specifying list of ranges? E.g.
ieee80211-center-frequencies =3D <2412000 2422000
2442000 2452>;
or
ieee80211-center-frequencies =3D <2412000 2422000>,
<2442000 2452>;
for device supporting channels 1, 2, 3, 7, 8, 9?
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties
From: Arend van Spriel @ 2016-12-29 8:57 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, linux-wireless@vger.kernel.org, Martin Blumenstingl,
Felix Fietkau, Arnd Bergmann, devicetree@vger.kernel.org,
Rafał Miłecki
In-Reply-To: <CACna6rzJV-UdydKrXTquEzrkCfNXXKsHBrsZGjTJ8F=BSRyUjA@mail.gmail.com>
On 28-12-16 22:30, Rafał Miłecki wrote:
> On 28 December 2016 at 22:28, Rafał Miłecki <zajec5@gmail.com> wrote:
>> On 28 December 2016 at 22:07, Arend van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>> On 28-12-16 16:59, Rafał Miłecki wrote:
>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>
>>>> They allow specifying hardware limitations of supported channels. This
>>>> may be useful for specifying single band devices or devices that support
>>>> only some part of the whole band.
>>>> E.g. some tri-band routers have separated radios for lower and higher
>>>> part of 5 GHz band.
>>>>
>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>> ---
>>>> net/wireless/reg.c | 34 ++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 34 insertions(+)
>>>>
>>>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
>>>> index 5dbac37..35ba5c7 100644
>>>> --- a/net/wireless/reg.c
>>>> +++ b/net/wireless/reg.c
>>>> @@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum nl80211_reg_initiator initiator)
>>>> }
>>>> EXPORT_SYMBOL(reg_initiator_name);
>>>>
>>>> +static bool reg_center_freq_of_valid(struct wiphy *wiphy,
>>>> + struct ieee80211_channel *chan)
>>>> +{
>>>> + struct device_node *np = wiphy_dev(wiphy)->of_node;
>>>> + u32 val;
>>>> +
>>>> + if (!np)
>>>> + return true;
>>>> +
>>>> + if (!of_property_read_u32(np, "ieee80211-min-center-freq", &val) &&
>>>> + chan->center_freq < KHZ_TO_MHZ(val))
>>>> + return false;
>>>> +
>>>> + if (!of_property_read_u32(np, "ieee80211-max-center-freq", &val) &&
>>>> + chan->center_freq > KHZ_TO_MHZ(val))
>>>> + return false;
>>>
>>> I suspect these functions rely on CONFIG_OF. So might not build for
>>> !CONFIG_OF.
>>
>> I compiled it with
>> # CONFIG_OF is not set
>>
>> Can you test it and provide a non-working config if you see a
>> compilation error, please?
>
> include/linux/of.h provides a lot of dummy static inline functions if
> CONFIG_OF is not used (they also allow compiler to drop most of the
> code).
of_propeirty_read_u32 is static inline in of.h calling
of_property_read_u32_array, which has a dummy variant in of.h returning
-ENOSYS so -38. Pretty sure that is not what you want. At least it does
not allow the compiler to drop any code so probably better to do:
if (!IS_ENABLED(CONFIG_OF) || !np)
return true;
So with this patch you change the channel to DISABLED. I am not very
familiar with reg.c so do you know if this is done before or after
calling regulatory notifier in the driver. brcmfmac will enable channels
querying the device upon regulatory notifier call, which may undo the
behavior introduced by your patch.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties
From: Rafał Miłecki @ 2016-12-29 9:43 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kalle Valo, linux-wireless@vger.kernel.org, Martin Blumenstingl,
Felix Fietkau, Arnd Bergmann, devicetree@vger.kernel.org,
Rafał Miłecki
In-Reply-To: <46007537-835c-90db-a44f-c45c8e2ecaed@broadcom.com>
On 29 December 2016 at 09:57, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 28-12-16 22:30, Rafa=C5=82 Mi=C5=82ecki wrote:
>> On 28 December 2016 at 22:28, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>=
wrote:
>>> On 28 December 2016 at 22:07, Arend van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>> On 28-12-16 16:59, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>
>>>>> They allow specifying hardware limitations of supported channels. Thi=
s
>>>>> may be useful for specifying single band devices or devices that supp=
ort
>>>>> only some part of the whole band.
>>>>> E.g. some tri-band routers have separated radios for lower and higher
>>>>> part of 5 GHz band.
>>>>>
>>>>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>> ---
>>>>> net/wireless/reg.c | 34 ++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 34 insertions(+)
>>>>>
>>>>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
>>>>> index 5dbac37..35ba5c7 100644
>>>>> --- a/net/wireless/reg.c
>>>>> +++ b/net/wireless/reg.c
>>>>> @@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum nl80211_re=
g_initiator initiator)
>>>>> }
>>>>> EXPORT_SYMBOL(reg_initiator_name);
>>>>>
>>>>> +static bool reg_center_freq_of_valid(struct wiphy *wiphy,
>>>>> + struct ieee80211_channel *chan)
>>>>> +{
>>>>> + struct device_node *np =3D wiphy_dev(wiphy)->of_node;
>>>>> + u32 val;
>>>>> +
>>>>> + if (!np)
>>>>> + return true;
>>>>> +
>>>>> + if (!of_property_read_u32(np, "ieee80211-min-center-freq", &val=
) &&
>>>>> + chan->center_freq < KHZ_TO_MHZ(val))
>>>>> + return false;
>>>>> +
>>>>> + if (!of_property_read_u32(np, "ieee80211-max-center-freq", &val=
) &&
>>>>> + chan->center_freq > KHZ_TO_MHZ(val))
>>>>> + return false;
>>>>
>>>> I suspect these functions rely on CONFIG_OF. So might not build for
>>>> !CONFIG_OF.
>>>
>>> I compiled it with
>>> # CONFIG_OF is not set
>>>
>>> Can you test it and provide a non-working config if you see a
>>> compilation error, please?
>>
>> include/linux/of.h provides a lot of dummy static inline functions if
>> CONFIG_OF is not used (they also allow compiler to drop most of the
>> code).
>
> of_propeirty_read_u32 is static inline in of.h calling
> of_property_read_u32_array, which has a dummy variant in of.h returning
> -ENOSYS so -38. Pretty sure that is not what you want. At least it does
> not allow the compiler to drop any code so probably better to do:
>
> if (!IS_ENABLED(CONFIG_OF) || !np)
> return true;
Please verify that using a compiler. If there is a problem I'll be
happy to work on it, but I need a proof it exists.
If compilers sees a:
if (!-ENOSYS && chan->center_freq < KHZ_TO_MHZ(val))
condition, it's pretty clear it can be dropped. With both conditional
blocks dropped function always returns "true" and... can be dropped.
Let me see if I can convince you with the following test:
$ grep -m 1 CONFIG_OF .config
# CONFIG_OF is not set
$ objdump --syms net/wireless/reg.o | grep -c reg_center_freq_of_valid
0
$ grep -m 1 CONFIG_OF .config
CONFIG_OF=3Dy
$ objdump --syms net/wireless/reg.o | grep -c reg_center_freq_of_valid
1
> So with this patch you change the channel to DISABLED. I am not very
> familiar with reg.c so do you know if this is done before or after
> calling regulatory notifier in the driver. brcmfmac will enable channels
> querying the device upon regulatory notifier call, which may undo the
> behavior introduced by your patch.
I'm not regulatory export, so I hope someone will review this patch.
So far I can say it works for me after trying it on SR400ac with
BCM43602.
ieee80211-min-center-freq =3D <2437000>;
[ 11.986941] cfg80211: Disabling freq 2412 MHz as it's out of OF limits
[ 12.000466] cfg80211: Disabling freq 2417 MHz as it's out of OF limits
[ 12.013984] cfg80211: Disabling freq 2422 MHz as it's out of OF limits
[ 12.027497] cfg80211: Disabling freq 2427 MHz as it's out of OF limits
[ 12.041012] cfg80211: Disabling freq 2432 MHz as it's out of OF limits
root@lede:/# iw phy phy0 channels
Band 1:
* 2412 MHz [1] (disabled)
* 2417 MHz [2] (disabled)
* 2422 MHz [3] (disabled)
* 2427 MHz [4] (disabled)
* 2432 MHz [5] (disabled)
* 2437 MHz [6]
Maximum TX power: 20.0 dBm
Channel widths: 20MHz HT40- HT40+
* 2442 MHz [7]
Maximum TX power: 20.0 dBm
Channel widths: 20MHz HT40- HT40+
* 2447 MHz [8]
Maximum TX power: 20.0 dBm
Channel widths: 20MHz HT40-
* 2452 MHz [9]
Maximum TX power: 20.0 dBm
Channel widths: 20MHz HT40-
* 2457 MHz [10]
Maximum TX power: 20.0 dBm
Channel widths: 20MHz HT40-
* 2462 MHz [11]
Maximum TX power: 20.0 dBm
Channel widths: 20MHz HT40-
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [1/5] ath10k: fix IRAM banks number for QCA9377
From: Kalle Valo @ 2016-12-29 13:18 UTC (permalink / raw)
To: Bartosz Markowski; +Cc: ath10k, linux-wireless, Bartosz Markowski
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> wrote:
> QCA9377 firmware shall alloc 4 IRAM banks
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
5 patches applied to ath-next branch of ath.git, thanks.
77cf13ad5731 ath10k: fix IRAM banks number for QCA9377
b08b5b53a1ed ath10k: override CE5 config for QCA9377
35bac90abf5e ath10k: decrease num of peers support
7cfe0455ee12 ath10k: set CTS protection VDEV param only if VDEV is up
861769017404 ath10k: add debug trace to rts/cts set function
--
https://patchwork.kernel.org/patch/9464915/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] ath10k: add accounting for the extended peer statistics
From: Kalle Valo @ 2016-12-29 14:11 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k
In-Reply-To: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
Christian Lamparter <chunkeey@googlemail.com> wrote:
> The 10.4 firmware adds extended peer information to the
> firmware's statistics payload. This additional info is
> stored as a separate data field and the elements are
> stored in their own "peers_extd" list.
>
> These elements can pile up in the same way as the peer
> information elements. This is because the
> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> pull the same amount (num_peer_stats) for every statistic
> data unit.
>
> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
My understanding is that I should skip this patch 1. Please let me know if
I misunderstood. But I'm still plannning to apply patch 2.
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9461631/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: merge extended peer info data with existing peers info
From: Mohammed Shafi Shajakhan @ 2016-12-29 14:35 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k, Kalle Valo, michal.kazior
In-Reply-To: <1563376.k5ulprKP3Z@debian64>
Hi Christian,
On Thu, Dec 22, 2016 at 06:58:41PM +0100, Christian Lamparter wrote:
> Hello Shafi,
>
> On Thursday, December 22, 2016 9:18:01 PM CET Mohammed Shafi Shajakhan wrote:
> > > On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote:
> > > > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > > > > The 10.4 firmware adds extended peer information to the
> > > > > firmware's statistics payload. This additional info is
> > > > > stored as a separate data field. During review of
> > > > > "ath10k: add accounting for the extended peer statistics" [0]
> > > > >
> > > > > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > > > > lists are of little use:"... there is not much use in appending
> > > > > the extended peer stats (which gets periodically updated) to the
> > > > > linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> > > > > rid of the below (and the required cleanup as well)
> > > > >
> > > > > list_splice_tail_init(&stats.peers_extd,
> > > > > &ar->debug.fw_stats.peers_extd);
> > > > >
> > > > > since rx_duration is getting updated periodically to the per sta
> > > > > information."
> > > > >
> > > > > This patch replaces the extended peers list with a lookup and
> > > > > puts the retrieved data (rx_duration) into the existing
> > > > > ath10k_fw_stats_peer entry that was created earlier.
> > > >
> > > > [shafi] Its good to maintain the extended stats variable
> > > > and retain the two different functions to update rx_duration.
> > > >
> > > > a) extended peer stats supported - mainly for 10.4
> > > > b) extender peer stats not supported - for 10.2
> > > Well, I have to ask why you want to retain the two different
> > > functions to update the same arsta->rx_duration? I think a
> > > little bit of code that helps to explain what's on your mind
> > > (or how you would do it) would help immensely in this case.
> > > Since I have the feeling that this is the problem here.
> > > So please explain it in C(lang).
> >
> > [shafi] I see you prefer to stuff the 'rx_duration' from
> > the extended stats to the existing global 'ath10k_peer_stats'
> > The idea of extended stats is, ideally its not going to stop
> > for 'rx_duration' . Extended stats is maintained as a seperate
> > list / entry for addition of new fields as well
> I'm guessing you are trying to say here:
>
> replace:
>
> dst->rx_duration = __le32_to_cpu(src->rx_duration);
>
> with
>
> dst->rx_duration += __le32_to_cpu(src->rx_duration);
>
> in ath10k_wmi_10_4_op_pull_fw_stats()?
[shafi] oh no sorry, I am trying to say more members related
to stats shall be added in extended stats structure . The extended
stats structure is specifically introduced for adding more stats related
variables.
>
> Is this correct? If so then can you tell me why ath10k_wmi_10_4_op_pull_fw_stats()
> is using for (i = 0; i < num_peer_stats; i++) to iterate over the extended peer
> stats instead of looking up the number of extended peer items. Because this does
> imply that there are the "same" (and every peer stat has a matching extended
> peer stat)... (This will be important for the comment below - so ***).
> Of course, if this isn't true then this is a bug and should be fixed because
> otherwise the ath10k_wmi_10_4_op_pull_fw_stats functions might return -EPROTO
> at some point which causes a "failed to pull fw stats: -71" and unprocessed/lost
> stats.
[shafi] sorry i am not sure I got you, have you come across this error, please
let me know ?
> > >
> > > > > [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
> > > > > Cc: Mohammed Shafi Shajakhan <mohammed@codeaurora.org>
> > > > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > > > > ---
> > > > > drivers/net/wireless/ath/ath10k/core.h | 2 --
> > > > > drivers/net/wireless/ath/ath10k/debug.c | 17 --------------
> > > > > drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
> > > > > drivers/net/wireless/ath/ath10k/wmi.c | 34 ++++++++++++++++++++-------
> > > > > 4 files changed, 28 insertions(+), 57 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> > > > > index 09ff8b8a6441..3fffbbb18c25 100644
> > > > > --- a/drivers/net/wireless/ath/ath10k/core.h
> > > > > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > > > > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> > > > > };
> > > > >
> > > > > struct ath10k_fw_stats {
> > > > > - bool extended;
> > > > > struct list_head pdevs;
> > > > > struct list_head vdevs;
> > > > > struct list_head peers;
> > > > > - struct list_head peers_extd;
> > > > > };
> > > > >
> > > > > #define ATH10K_TPC_TABLE_TYPE_FLAG 1
> > > > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > > > index 82a4c67f3672..89f7fde77cdf 100644
> > > > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > > > @@ -315,25 +315,13 @@ static void ath10k_fw_stats_peers_free(struct list_head *head)
> > > > > }
> > > > > }
> > > > >
> > > > > -static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
> > > > > -{
> > > > > - struct ath10k_fw_extd_stats_peer *i, *tmp;
> > > > > -
> > > > > - list_for_each_entry_safe(i, tmp, head, list) {
> > > > > - list_del(&i->list);
> > > > > - kfree(i);
> > > > > - }
> > > > > -}
> > > > > -
> > > > > static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
> > > > > {
> > > > > spin_lock_bh(&ar->data_lock);
> > > > > ar->debug.fw_stats_done = false;
> > > > > - ar->debug.fw_stats.extended = false;
> > > >
> > > > [shafi] this looks fine, but not removing the 'extended' variable
> > > > from ath10k_fw_stats structure, I see the design for 'rx_duration'
> > > > arguably some what convoluted !
> > > I removed extended because it is now a write-only variable.
> > > So I figured, there's no point in keeping it around? I don't have
> > > access to the firmware interface documentation, so I don't know
> > > if there's a reason why it would be good to have it later.
> > > So please tell me, what information do we gain from it?
[shafi] sorry this is purely ath10k specific nothing to map with the firmware
> >
> > [shafi] while parsing the stats from 'wmi' we clearly mark there whether
> > the extended stats is available (or) not and if its there parse it and
> > deal with it seperately
> No, there's no difference between stats or extended stats (10.2.4 vs 10.4):
> both ath10k_sta_update_extd_stats_rx_duration() [0]
> and ath10k_sta_update_stats_rx_duration() [1] are adding the
> ath10k_fw_stats_peer(_extd)->rx_duration to ath10k_sta->rx_duration.
>
> With the merge of the peer stats and extended peer stats, this also
> removed the only usage of stats->extended. And hence it becomes a
> write-only variable. So there's no point in keeping it around ATM (as
> all other extended peer stats entries aren't used).
[shafi] ok, I see the extended stats structure is introduced for 10.4 and i was
thinking its good to have two seperate API's for updating the rx_duration ..
>
> > > > *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> > > > *Fetch rx_duration from 'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
> > > > {certainly 'stats' object is for this particular update only, and freed
> > > > up later)
> > > > *Update immediately using 'ath10k_sta_update_rx_duration'
> > > >
> > > > 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> > > > for 10.2 and 10.4 (the later supporting extended peer stats)
> > >
> > > I see that 10.2.4's ath10k_wmi_10_2_4_op_pull_fw_stats()
> > > passes the rx_duration as part of the wmi_10_2_4_ext_peer_stats
> > > element which is basically a carbon-copy of wmi_10_2_4_peer_stats
> > > (but with one extra __le32 for the rx_duration at the end.)
> > > This rx_duration is then used to set the rx_duration field in the
> > > generated ath10k_fw_stats_peer struct.
[shafi] ok
> > >
> > > 10.4's ath10k_wmi_10_4_op_pull_fw_stats() has a "fixed" wmi_10_4_peer_stats
> > > element and uses an separate "fixed" wmi_10_4_peer_extd_stats element for
> > > the communicating the rx_duration to the driver.
[shafi] ok
> > >
> > > Thing is, both function have the same signature. They produce the same
> > > struct ath10k_fw_stats_peer for the given data in the sk_buff input. So
> > > why does 10.4 need to have it's peer_extd infrastructure, when it can use
> > > the existing rx_duration field in the *universal* ath10k_fw_stats_peer?
> >
> > [shafi] agreed we need to fix that, it would have been easier if 10.2.4
> > and 10.4 had the same definitions.
> Ok, I don't know the internals of the firmware to know what's the difference
> between 10.2.4 and 10.4's rx_duration (how both firmwares define them
> differently in this context) ? From what I can tell, it's just that
> the entry has moved from the peer stats to extended peer stats.
> Of course, this is based on the logic that both 10.2.4 and 10.4 rx_durations
> end up being added to arsta->rx_duration in the same way. There's no scaling
> or a comment that would indicate a difference.
[shafi] ok
>
> > >
> > > What's with the extra layers / HAL here? Because it looks like it's merged
> > > back together in the same manner into the same arsta->rx_duration?
> > > [ath10k_sta_update_stats_rx_duration() vs.
> > > ath10k_sta_update_extd_stats_rx_duration() - they are almost carbon copies too]
[shafi] my concern was for updating 'rx_duration' we just iterate over the list
and update the same.
> > >
> > > > > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> > > > > index c893314a191f..c7ec7b9e9b55 100644
> > > > > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > > > > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > > > > @@ -3044,23 +3044,41 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k *ar,
> > > > > if ((stats_id & WMI_10_4_STAT_PEER_EXTD) == 0)
> > > > > return 0;
> > > > >
> > > > > - stats->extended = true;
> > > > > -
> > > > > for (i = 0; i < num_peer_stats; i++) {
> > > > > const struct wmi_10_4_peer_extd_stats *src;
> > > > > - struct ath10k_fw_extd_stats_peer *dst;
> > > > > + struct ath10k_fw_stats_peer *dst;
> > > > >
> > > > > src = (void *)skb->data;
> > > > > if (!skb_pull(skb, sizeof(*src)))
> > > > > return -EPROTO;
> > > > >
> > > > > - dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
> > > > > - if (!dst)
> > > > > - continue;
> > > > > + /* Because the stat data may exceed htc-wmi buffer
> > > > > + * limit the firmware might split the stats data
> > > > > + * and delivers it in multiple update events.
> > > > > + * if we can't find the entry in the current event
> > > > > + * payload, we have to look in main list as well.
> > > > > + */
> >
> > [shafi] thanks ! sorry i might have missed this bug, did you happen
> > to see this condition being hit ?
> This was copied from ath10k_debug_fw_stats_process() [2]. I've added Michal
> Kazior to the discussion since his patch "ath10k: fix fw stats processing"
> added this in debug.c. I think he knows the firmware internals well enough
> to tell if this is a problem or not. As it stands now, it is and will be
> in the future.
[shafi] sure.
>
> > > > > + list_for_each_entry(dst, &stats->peers, list) {
> > > > > + if (ether_addr_equal(dst->peer_macaddr,
> > > > > + src->peer_macaddr.addr))
> > > > > + goto found;
> > > > > + }
> > > > > +
> >
> > [shafi] Again, we can simply cache the macaddress and rx_duration
> > and deal with it later, rather than doing the whole lookup here ?
> > Will it be an overhead for large number of clients ?
> Well, show me how you would do it more efficiently otherwise? I don't
> see how you can cache the macaddress and rx_duration since you are
> basically forced to process all the peer stats first and later all
> the extended peer stats. They don't mix.
[shafi] hmmm, ok.
>
> As for how expensive it is: From what I can tell, the 10.4 firmware
> sends the stat events every few seconds. So they are not part of any
> rx or tx hot-paths. The list_for_each within the for
> (i = 0; i < num_peers;i++) is actually in the O(1) class as far
> as both loops go. This might sound funny at first, but the number of
> extended peer list is limited by TARGET_10_4_MAX_PEER_EXT_STATS to 16.
> And thanks to (***) the limit of num_peers is also 16. Furthermore
> we can add a if (ath10k_peer_stats_enabled(ar)) guard to skip it
> entirely if the stats are disabled.
[shafi] ok.
>
>
> > > > > +#ifdef CONFIG_ATH10K_DEBUGFS
> > > > > + list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> > > > > + if (ether_addr_equal(dst->peer_macaddr,
> > > > > + src->peer_macaddr.addr))
> > > > > + goto found;
> > > > > + }
> > > > > +#endif
> >
> > [shafi] again, this could be handled seperately.
> This is more expensive. As fw_stats.peers can contain more entries than 16.
> However, this might be unnecessary if both peers and extended peers stats
> entries in the wmi event are always for the same stations.
[shafi] ok
>
> Note: There's an alternative way too. Instead of writing rx_duration into
> ath10k_fw_stats, we could skip the middle man write it directly into
> arsta->rx_duration. This would also mean that we can get rid of
> ath10k_sta_update_extd_stats_rx_duration(), ath10k_sta_update_stats_rx_duration()
> and ath10k_sta_update_rx_duration(). This has the benifit that we can
> remove even more.
>
> > > > > +
> > > > > + ath10k_dbg(ar, ATH10K_DBG_WMI,
> > > > > + "Orphaned extended stats entry for station %pM.\n",
> > > > > + src->peer_macaddr.addr);
> > > > > + continue;
> > > > >
> > > > > - ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> > > > > +found:
> > > > > dst->rx_duration = __le32_to_cpu(src->rx_duration);
> > > > > - list_add_tail(&dst->list, &stats->peers_extd);
> > > > > }
> > > > >
> > > > > return 0;
> > > >
> > > > [shafi] Yes i am bit concerned about this change making 10.4 to update
> > > > over the existing peer_stats structure, the idea is to maintain uniformity
> > > > between the structures shared between ath10k and its corresponding to avoid
> > > > confusion/ bugs in the future. Kindly let me know your thoughts, feel free
> > > > to correct me if any of my analysis is incorrect. thank you !
> > > Isn't the point of the ath10k_wmi_10_*_op_pull_fw_stats() functions to make
> > > a "universal" statistic (in your case a unified ath10k_fw_stats_peer structure)
> > > that other functions can use, without caring about if the FW was 10.4
> > > or 10.2.4?
> > >
> > > There's no indication that the rx_duration field in wmi_10_2_4_ext_peer_stats
> > > conveys any different information than the rx_duration in
> > > wmi_10_4_peer_extd_stats. So, what's going on here? Can't you just make
> > > wmi_10_4_peer_extd_stats's rx_duration use the existing field in
> > > ath10k_fw_stats_peer? And if not: why exactly?
> > >
> > [shafi] I will soon test your change and keep you posted. We will also
> > get Kalle's take/view on this.
> Ok. That said, I added him to the CC from the beginning and so far
> he silently agreed.
[shafi] sure, I guess i quickly tested this change and I found things
are fine, it would be good if you can share your test results as well please
Yes we can discuss with Kalle and Michal ! If you guys think this is a more
optimized version of updating the peer stats, I am fine with that as well.
There is no doubt you guys know about open source better than me :-)
>
> Regards,
> Christian
>
> [0] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L21>
> [1] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L40>
> [2] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debug.c#L360>
>
>
^ permalink raw reply
* gpio outputs that disable wireless to PCI Express Mini Card and RFKILL
From: Tim Harvey @ 2016-12-29 15:07 UTC (permalink / raw)
To: linux-wireless
Greetings,
The PCI Express Mini Card (aka Mini PCIe) spec calls out pin 20 as
W_DISABLE# to allow a PCIe host to disable the add-in card's radio
operation and we have run this to a GPIO on our boards for some time.
The M.2 specs also provide such signals. Is there any support in the
Linux RFKILL subsystem to define this?
Looking over the RFKILL subsystem I see support for wireless drivers
to register with rfkill to support on/off/state hooks and support for
gpio based rfkill 'input' switches but I haven't seen anything that
deals with GPIO 'outputs' to add-in card slots. Perhaps support for
this hasn't been deemed necessary because instead software
controllable methods are always used to control rfkill states for the
wireless devices on add-in cards?
Best regards,
Tim
Tim Harvey - Principal Software Engineer
Gateworks Corporation - http://www.gateworks.com/
3026 S. Higuera St. San Luis Obispo CA 93401
805-781-2000
^ permalink raw reply
* Re: gpio outputs that disable wireless to PCI Express Mini Card and RFKILL
From: Johannes Berg @ 2016-12-29 15:18 UTC (permalink / raw)
To: Tim Harvey, linux-wireless
In-Reply-To: <CAJ+vNU33Z05DaQGER8KJoPX5g1w=HWjKFDbNs0S0gxKDcFV7bg@mail.gmail.com>
On Thu, 2016-12-29 at 07:07 -0800, Tim Harvey wrote:
> Greetings,
>
> The PCI Express Mini Card (aka Mini PCIe) spec calls out pin 20 as
> W_DISABLE# to allow a PCIe host to disable the add-in card's radio
> operation and we have run this to a GPIO on our boards for some time.
> The M.2 specs also provide such signals. Is there any support in the
> Linux RFKILL subsystem to define this?
Not directly, but that depends on what you mean by "support". This
whole thing is relatively simple - it's an input signal to the wireless
NIC, so that any reaction to the input originates there.
Typically (I know about Intel and ath9k devices) changes in this input
either trigger an interrupt (Intel) or are polled for (ath9k), and then
the already existing rfkill instance for the wireless NIC will reflect
a "hard block" when the driver notifies upper layers of the new state.
Or did you mean you want to use the CPU to *control* this GPIO? In this
case, I'm not sure that the rfkill subsystem is appropriate, but there
apparently are some such cases already where the platform rfkill's
software state essentially toggles the wireless NIC's hardware state.
I'd argue this is useless though since if you toggle the thing from
software then you might as well rely entirely on software rfkill.
johannes
^ permalink raw reply
* [PATCH] rtlwifi: fix spelling mistake: "contry" -> "country"
From: Colin King @ 2016-12-29 16:00 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo, linux-wireless, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
trivial fix to spelling mistake in RT_TRACE message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtlwifi/regd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c b/drivers/net/wireless/realtek/rtlwifi/regd.c
index 6ee6bf8..558c31b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/regd.c
+++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
@@ -440,7 +440,7 @@ int rtl_regd_init(struct ieee80211_hw *hw,
if (rtlpriv->regd.country_code >= COUNTRY_CODE_MAX) {
RT_TRACE(rtlpriv, COMP_REGD, DBG_DMESG,
- "rtl: EEPROM indicates invalid contry code, world wide 13 should be used\n");
+ "rtl: EEPROM indicates invalid country code, world wide 13 should be used\n");
rtlpriv->regd.country_code = COUNTRY_CODE_WORLD_WIDE_13;
}
--
2.10.2
^ permalink raw reply related
* rtl8xxxu: Testing with 0BDA:8178 (TP-link TL-WN821N with 8192cu)
From: Agustin Martin @ 2016-12-29 16:22 UTC (permalink / raw)
To: linux-wireless
Hi, Jes
Sorry if you already received this feedback, I could not find references.
I am trying a TP-LINK TL-WN821N wifi usb dongle with Realtek 8192cu
(lsusb returns: 0bda:8178 Realtek Semiconductor Corp. RTL8192CU
802.11n WLAN Adapter) and found the same problems described in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1365844
When using kernel rtl8192cu driver, I can connect to wifi, but soon
the connection is dropped.
Since some time ago (2014) you asked for feedback in that bug and I
did not find further references I decided to try your rtl8xxxu driver.
All tests were carried out in a Debian GNU/Linux jessie box (current
stable release) with kernel 4.7.8 from Debian jessie backports (source
package linux_4.7.8-1~bpo8+1.dsc).
Changed kernel config to
## file: drivers/net/wireless/realtek/rtl8xxxu/Kconfig
##
CONFIG_RTL8XXXU=m
CONFIG_RTL8XXXU_UNTESTED=y
built a kernel (slooow here), installed it and added this line to a
file under /etc/modprobe.d
alias usb:v0BDAp8178d*dc*dsc*dp*icFFiscFFipFFin* rtl8xxxu
If the dongle is initially connected, system loads the rtl8xxxu module
instead of rtl8192cu when booting but seems not to initialize the
dongle, so I have no connection. However, if I disconnect the dongle
and reconnect it again with the system on, everything seems to work
well with no connection dropping. Only minimally tested, but apart
from the boot problem apparently much better than with the built-in
rtl8192cu kernel module.
Thanks for all the work you are putting into this driver
--
Agustin
^ permalink raw reply
* [PATCH] wlcore: fix spelling mistake in wl1271_warning
From: Colin King @ 2016-12-29 20:14 UTC (permalink / raw)
To: Kalle Valo, Shahar Patury, Guy Mishol, linux-wireless, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
trivial fix to spelling mistake of function name in wl1271_warning,
should be dynamic_ps_timeout instead of dyanmic_ps_timeout.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/ti/wlcore/debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c b/drivers/net/wireless/ti/wlcore/debugfs.c
index 7f672f6..58e148d 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -281,7 +281,7 @@ static ssize_t dynamic_ps_timeout_write(struct file *file,
}
if (value < 1 || value > 65535) {
- wl1271_warning("dyanmic_ps_timeout is not in valid range");
+ wl1271_warning("dynamic_ps_timeout is not in valid range");
return -ERANGE;
}
--
2.10.2
^ permalink raw reply related
* [PATCH] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"
From: Colin King @ 2016-12-29 20:29 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Larry Finger, Chaoming Li, Kalle Valo,
linux-media, linux-wireless, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
trivial fix to spelling mistake in err message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/media/usb/dvb-usb/gp8psk.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/gp8psk.c b/drivers/media/usb/dvb-usb/gp8psk.c
index 2360e7e..26461f2 100644
--- a/drivers/media/usb/dvb-usb/gp8psk.c
+++ b/drivers/media/usb/dvb-usb/gp8psk.c
@@ -161,7 +161,7 @@ static int gp8psk_load_bcm4500fw(struct dvb_usb_device *d)
goto out_free;
}
if (buflen > 64) {
- err("firmare chunk size bigger than 64 bytes.");
+ err("firmware chunk size bigger than 64 bytes.");
goto out_free;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index ded1493..732de0a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1532,7 +1532,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
key_type = AESCMAC_ENCRYPTION;
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG, "alg:CMAC\n");
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
- "HW don't support CMAC encrypiton, use software CMAC encrypiton\n");
+ "HW don't support CMAC encryption, use software CMAC encryption\n");
err = -EOPNOTSUPP;
goto out_unlock;
default:
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] rtlwifi: fix spelling mistake: "contry" -> "country"
From: Larry Finger @ 2016-12-29 20:58 UTC (permalink / raw)
To: Colin King, Chaoming Li, Kalle Valo, linux-wireless, netdev; +Cc: linux-kernel
In-Reply-To: <20161229160029.22117-1-colin.king@canonical.com>
On 12/29/2016 10:00 AM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> trivial fix to spelling mistake in RT_TRACE message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry
> ---
> drivers/net/wireless/realtek/rtlwifi/regd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c b/drivers/net/wireless/realtek/rtlwifi/regd.c
> index 6ee6bf8..558c31b 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/regd.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
> @@ -440,7 +440,7 @@ int rtl_regd_init(struct ieee80211_hw *hw,
>
> if (rtlpriv->regd.country_code >= COUNTRY_CODE_MAX) {
> RT_TRACE(rtlpriv, COMP_REGD, DBG_DMESG,
> - "rtl: EEPROM indicates invalid contry code, world wide 13 should be used\n");
> + "rtl: EEPROM indicates invalid country code, world wide 13 should be used\n");
>
> rtlpriv->regd.country_code = COUNTRY_CODE_WORLD_WIDE_13;
> }
>
^ permalink raw reply
* Re: [PATCH] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"
From: VDR User @ 2016-12-29 21:23 UTC (permalink / raw)
To: Colin King
Cc: Mauro Carvalho Chehab, Larry Finger, Chaoming Li, Kalle Valo,
mailing list: linux-media, linux-wireless, netdev,
Linux Kernel Mailing List
In-Reply-To: <20161229202952.27448-1-colin.king@canonical.com>
> - err("firmare chunk size bigger than 64 bytes.");
> + err("firmware chunk size bigger than 64 bytes.");
Yup.
> - "HW don't support CMAC encrypiton, use software CMAC encrypiton\n");
> + "HW don't support CMAC encryption, use software CMAC encryption\n");
Should be: "HW doesn't support CMAC encryption, use software CMAC
encryption\n");
^ permalink raw reply
* [PATCH] staging: wilc1000: Fix endian sparse warning
From: Mike Kofron @ 2016-12-29 21:35 UTC (permalink / raw)
To: Aditya Shankar, Ganesh Krishna, Greg Kroah-Hartman
Cc: Mike Kofron, linux-wireless, devel, linux-kernel
drivers/staging/wilc1000/linux_wlan.c:995:18: warning: restricted __be16 degrades to integer
Signed-off-by: Mike Kofron <mpkofron@gmail.com>
---
drivers/staging/wilc1000/linux_wlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c
index e59cab5..f293779 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -992,7 +992,7 @@ int wilc_mac_xmit(struct sk_buff *skb, struct net_device *ndev)
tx_data->skb = skb;
eth_h = (struct ethhdr *)(skb->data);
- if (eth_h->h_proto == 0x8e88)
+ if (eth_h->h_proto == cpu_to_be16(0x8e88))
netdev_dbg(ndev, "EAPOL transmitted\n");
ih = (struct iphdr *)(skb->data + sizeof(struct ethhdr));
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"
From: Colin Ian King @ 2016-12-29 21:35 UTC (permalink / raw)
To: VDR User
Cc: Mauro Carvalho Chehab, Larry Finger, Chaoming Li, Kalle Valo,
mailing list: linux-media, linux-wireless, netdev,
Linux Kernel Mailing List
In-Reply-To: <CAA7C2qjAk6LqTru2zimRr4_JUYXK+4d8VENpyYXjyE0-eJ+RKQ@mail.gmail.com>
On 29/12/16 21:23, VDR User wrote:
>> - err("firmare chunk size bigger than 64 bytes.");
>> + err("firmware chunk size bigger than 64 bytes.");
>
> Yup.
>
>> - "HW don't support CMAC encrypiton, use software CMAC encrypiton\n");
>> + "HW don't support CMAC encryption, use software CMAC encryption\n");
>
> Should be: "HW doesn't support CMAC encryption, use software CMAC
> encryption\n");
>
Very true, I was so focused on the spelling I overlooked the grammar.
I'll re-send with that fixed.
Colin
^ permalink raw reply
* [PATCH][V2] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"
From: Colin King @ 2016-12-29 21:38 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Larry Finger, Chaoming Li, Kalle Valo,
linux-media, linux-wireless, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in err message. Also change "don't" to
"does not".
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/media/usb/dvb-usb/gp8psk.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/gp8psk.c b/drivers/media/usb/dvb-usb/gp8psk.c
index 2360e7e..26461f2 100644
--- a/drivers/media/usb/dvb-usb/gp8psk.c
+++ b/drivers/media/usb/dvb-usb/gp8psk.c
@@ -161,7 +161,7 @@ static int gp8psk_load_bcm4500fw(struct dvb_usb_device *d)
goto out_free;
}
if (buflen > 64) {
- err("firmare chunk size bigger than 64 bytes.");
+ err("firmware chunk size bigger than 64 bytes.");
goto out_free;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index ded1493..732de0a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1532,7 +1532,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
key_type = AESCMAC_ENCRYPTION;
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG, "alg:CMAC\n");
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
- "HW don't support CMAC encrypiton, use software CMAC encrypiton\n");
+ "HW does not support CMAC encryption, use software CMAC encryption\n");
err = -EOPNOTSUPP;
goto out_unlock;
default:
--
2.10.2
^ permalink raw reply related
* Re: rtl8xxxu: Testing with 0BDA:8178 (TP-link TL-WN821N with 8192cu)
From: Agustin Martin @ 2016-12-30 0:05 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAHMXK7gqy9_PsZLKxTW7821XmGO1VOaD0Ex+gEsdzsXgwGenWg@mail.gmail.com>
2016-12-29 17:22 GMT+01:00 Agustin Martin <agustin6martin@gmail.com>:
> Hi, Jes
>
> Sorry if you already received this feedback, I could not find references.
>
> I am trying a TP-LINK TL-WN821N wifi usb dongle with Realtek 8192cu
> (lsusb returns: 0bda:8178 Realtek Semiconductor Corp. RTL8192CU
> 802.11n WLAN Adapter) and found the same problems described in
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1365844
>
> When using kernel rtl8192cu driver, I can connect to wifi, but soon
> the connection is dropped.
>
> Since some time ago (2014) you asked for feedback in that bug and I
> did not find further references I decided to try your rtl8xxxu driver.
>
> All tests were carried out in a Debian GNU/Linux jessie box (current
> stable release) with kernel 4.7.8 from Debian jessie backports (source
> package linux_4.7.8-1~bpo8+1.dsc).
>
> Changed kernel config to
>
> ## file: drivers/net/wireless/realtek/rtl8xxxu/Kconfig
> ##
> CONFIG_RTL8XXXU=m
> CONFIG_RTL8XXXU_UNTESTED=y
>
> built a kernel (slooow here), installed it and added this line to a
> file under /etc/modprobe.d
>
> alias usb:v0BDAp8178d*dc*dsc*dp*icFFiscFFipFFin* rtl8xxxu
>
> If the dongle is initially connected, system loads the rtl8xxxu module
> instead of rtl8192cu when booting but seems not to initialize the
> dongle, so I have no connection. However, if I disconnect the dongle
> and reconnect it again with the system on, everything seems to work
> well with no connection dropping. Only minimally tested, but apart
> from the boot problem apparently much better than with the built-in
> rtl8192cu kernel module.
Hi again Jes, good news,
I do not know what I did wrong before, but I am retesting above kernel
and dongle and things seem to be working from the very beginning, no
problems found after plain boot (just need to enable the network
twice, but that also happemed with the old b/g dongle, may be
something with network manager).
This is not my usual box, it is slow and I do not have it accesible
in a daily basis, but feel free to ask for further testing. Will try
to make my best.
Best regards,
--
Agustin
^ permalink raw reply
* Re: [2/2] ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()
From: Kalle Valo @ 2016-12-30 9:11 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k
In-Reply-To: <e0909741dfae742197d5f5d60709d225cc179b42.1480974623.git.chunkeey@googlemail.com>
Christian Lamparter <chunkeey@googlemail.com> wrote:
> ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...)
> function, which allocates memory. If any of the three error-paths are
> taken, this tb needs to be freed.
>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Patch applied to ath-next branch of ath.git, thanks.
097e46d2ae90 ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()
--
https://patchwork.kernel.org/patch/9461627/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2] ath10k: fix incorrect txpower set by P2P_DEVICE interface
From: Kalle Valo @ 2016-12-30 9:13 UTC (permalink / raw)
To: Ryan Hsu; +Cc: ath10k, linux-wireless, ryanhsu
In-Reply-To: <1481669719-3423-1-git-send-email-ryanhsu@qca.qualcomm.com>
Ryan Hsu <ryanhsu@qca.qualcomm.com> wrote:
> From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
>
> Ath10k reports the phy capability that supports P2P_DEVICE interface.
>
> When we use the P2P supported wpa_supplicant to start connection, it'll
> create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE
> p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).
>
> ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0
> ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0
> ...
> ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1
> ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0
>
> And the txpower in per vif bss_conf will only be set to valid tx power when
> the interface is assigned with channel_ctx.
>
> But this P2P_DEVICE interface will never be used for any connection, so
> that the uninitialized bss_conf.txpower=0 is assinged to the
> arvif->txpower when interface created.
>
> Since the txpower configuration is firmware per physical interface.
> So the smallest txpower of all vifs will be the one limit the tx power
> of the physical device, that causing the low txpower issue on other
> active interfaces.
>
> wlan0: Limiting TX power to 21 (24 - 3) dBm
> ath10k_pci mac vdev_id 0 txpower 21
> ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0
> ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21
> ath10k_pci mac txpower 0
>
> This issue only happens when we use the wpa_supplicant that supports
> P2P or if we use the iw tool to create the control P2P_DEVICE interface.
>
> Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
88407beb1b14 ath10k: fix incorrect txpower set by P2P_DEVICE interface
--
https://patchwork.kernel.org/patch/9473309/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: support dev_coredump for crash dump
From: Kalle Valo @ 2016-12-30 9:14 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <20161221121921.25119.93932.stgit@potku.adurom.net>
Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> From: Arun Khandavalli <akhandav@qti.qualcomm.com>
>
> Whenever firmware crashes, and both CONFIG_ATH10K_DEBUGFS and
> CONFIG_ALLOW_DEV_COREDUMP are enabled, dump information about the crash via a
> devcoredump device. Dump can be read from userspace for further analysis from:
>
> /sys/class/devcoredump/devcd*/data
>
> As until now we have provided the firmware crash dump file via fw_crash_dump
> debugfs keep it still available but deprecate and a warning print that the user
> should switch to using dev_coredump.
>
> Future improvement would be not to depend on CONFIG_ATH10K_DEBUGFS, as there
> might be systems which want to get the firmware crash dump but not enable
> debugfs. How to handle memory consumption is also something which needs to be
> taken into account.
>
> Signed-off-by: Arun Khandavalli <akhandav@qti.qualcomm.com>
> [kvalo@qca.qualcomm.com: rebase, fixes, improve commit log]
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
727000e6af34 ath10k: support dev_coredump for crash dump
--
https://patchwork.kernel.org/patch/9482989/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: recal the txpower when removing interface
From: Kalle Valo @ 2016-12-30 9:15 UTC (permalink / raw)
To: Ryan Hsu; +Cc: ath10k, linux-wireless, ryanhsu
In-Reply-To: <1482445906-20421-1-git-send-email-ryanhsu@qca.qualcomm.com>
Ryan Hsu <ryanhsu@qca.qualcomm.com> wrote:
> From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
>
> The txpower is being recalculated when adding interface to make sure
> txpower won't overshoot the spec, and when removing the interface,
> the txpower should again to be recalculated to restore the correct value
> from the active interface list.
>
> Following is one of the scenario
> vdev0 is created as STA and connected: txpower:23
> vdev1 is created as P2P_DEVICE for control interface: txpower:0
> vdev2 is created as p2p go/gc interface: txpower is 21
>
> So the vdev2@txpower:21 will be set to firmware when vdev2 is created.
> When we tear down the vdev2, the txpower needs to be recalculated to
> re-set it to vdev0@txpower:23 as vdev0/vdev1 are the active interface.
>
> ath10k_pci mac vdev 0 peer create 8c:fd:f0:01:62:98
> ath10k_pci mac vdev_id 0 txpower 23
> ... (adding interface)
> ath10k_pci mac vdev create 2 (add interface) type 1 subtype 3
> ath10k_pci mac vdev_id 2 txpower 21
> ath10k_pci mac txpower 21
> ... (removing interface)
> ath10k_pci mac vdev 2 delete (remove interface)
> ath10k_pci vdev 1 txpower 0
> ath10k_pci vdev 0 txpower 23
> ath10k_pci mac txpower 23
>
> Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
d679fa1b3c89 ath10k: recal the txpower when removing interface
--
https://patchwork.kernel.org/patch/9486925/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: ignore configuring the incorrect board_id
From: Kalle Valo @ 2016-12-30 9:15 UTC (permalink / raw)
To: Ryan Hsu; +Cc: ath10k, linux-wireless, ryanhsu
In-Reply-To: <1482447757-23577-1-git-send-email-ryanhsu@qca.qualcomm.com>
Ryan Hsu <ryanhsu@qca.qualcomm.com> wrote:
> From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
>
> With command to get board_id from otp, in the case of following
>
> boot get otp board id result 0x00000000 board_id 0 chip_id 0
> boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0"
> ...
> failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from
> ath10k/QCA6174/hw3.0/board-2.bin
>
> The invalid board_id=0 will be used as index to search in the board-2.bin.
>
> Ignore the case with board_id=0, as it means the otp is not carrying
> the board id information.
>
> Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
d2e202c06ca4 ath10k: ignore configuring the incorrect board_id
--
https://patchwork.kernel.org/patch/9486941/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Remove passing unused argument for ath10k_mac_tx
From: Kalle Valo @ 2016-12-30 9:16 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1482845555-6076-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 'ath10k_mac_tx' does not seems to use the per station table
> entry pointer 'sta' (struct ieee80211_sta), hence remove passing
> this unused argument
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
a7773b5db155 ath10k: Remove passing unused argument for ath10k_mac_tx
--
https://patchwork.kernel.org/patch/9489231/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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