* [PATCH 1/6] ath10k: add missing values to wmi_service_name()
From: Kalle Valo @ 2019-02-11 15:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
After implementing the next patch GCC reported:
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_BTCOEX' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_MGMT_TX_WMI' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_SPOOF_MAC_SUPPORT' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_VDEV_DISABLE_4_ADDR_SRC_LRN_SUPPORT' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_BB_TIMING_CONFIG_SUPPORT' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_THERM_THROT' not handled in switch [-Wswitch]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/wmi.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index b10ed523b99e..529f5a26f3f3 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -475,6 +475,7 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_TX_MODE_PUSH_PULL);
SVCSTR(WMI_SERVICE_TX_MODE_DYNAMIC);
SVCSTR(WMI_SERVICE_VDEV_RX_FILTER);
+ SVCSTR(WMI_SERVICE_BTCOEX);
SVCSTR(WMI_SERVICE_CHECK_CAL_VERSION);
SVCSTR(WMI_SERVICE_DBGLOG_WARN2);
SVCSTR(WMI_SERVICE_BTCOEX_DUTY_CYCLE);
@@ -484,13 +485,18 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_SMART_LOGGING_SUPPORT);
SVCSTR(WMI_SERVICE_TDLS_CONN_TRACKER_IN_HOST_MODE);
SVCSTR(WMI_SERVICE_TDLS_EXPLICIT_MODE_ONLY);
+ SVCSTR(WMI_SERVICE_MGMT_TX_WMI);
SVCSTR(WMI_SERVICE_TDLS_WIDER_BANDWIDTH);
SVCSTR(WMI_SERVICE_HTT_MGMT_TX_COMP_VALID_FLAGS);
SVCSTR(WMI_SERVICE_HOST_DFS_CHECK_SUPPORT);
SVCSTR(WMI_SERVICE_TPC_STATS_FINAL);
SVCSTR(WMI_SERVICE_RESET_CHIP);
+ SVCSTR(WMI_SERVICE_SPOOF_MAC_SUPPORT);
SVCSTR(WMI_SERVICE_TX_DATA_ACK_RSSI);
SVCSTR(WMI_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT);
+ SVCSTR(WMI_SERVICE_VDEV_DISABLE_4_ADDR_SRC_LRN_SUPPORT);
+ SVCSTR(WMI_SERVICE_BB_TIMING_CONFIG_SUPPORT);
+ SVCSTR(WMI_SERVICE_THERM_THROT);
SVCSTR(WMI_SERVICE_RTT_RESPONDER_ROLE);
SVCSTR(WMI_SERVICE_PER_PACKET_SW_ENCRYPT);
SVCSTR(WMI_SERVICE_REPORT_AIRTIME);
--
2.7.4
^ permalink raw reply related
* [PATCH 5/6] ath10k: fix documentation in ath10k_wow_convert_8023_to_80211()
From: Kalle Valo @ 2019-02-11 15:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <1549897787-28537-1-git-send-email-kvalo@codeaurora.org>
With W=1 there's a warning:
drivers/net/wireless/ath/ath10k/wow.c:93: warning: Function parameter or member 'new' not described in 'ath10k_wow_convert_8023_to_80211'
drivers/net/wireless/ath/ath10k/wow.c:93: warning: Function parameter or member 'old' not described in 'ath10k_wow_convert_8023_to_80211'
Fix it by changing the documentation marker '/**' to a normal code comment.
While at it, clean up the line wrapping.
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/wow.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wow.c b/drivers/net/wireless/ath/ath10k/wow.c
index 36d4245c308e..b36fa0f8892e 100644
--- a/drivers/net/wireless/ath/ath10k/wow.c
+++ b/drivers/net/wireless/ath/ath10k/wow.c
@@ -77,7 +77,7 @@ static int ath10k_wow_cleanup(struct ath10k *ar)
return 0;
}
-/**
+/*
* Convert a 802.3 format to a 802.11 format.
* +------------+-----------+--------+----------------+
* 802.3: |dest mac(6B)|src mac(6B)|type(2B)| body... |
@@ -88,9 +88,8 @@ static int ath10k_wow_cleanup(struct ath10k *ar)
* 802.11: |4B|dest mac(6B)| 6B |src mac(6B)| 8B |type(2B)| body... |
* +--+------------+----+-----------+---------------+-----------+
*/
-static void ath10k_wow_convert_8023_to_80211
- (struct cfg80211_pkt_pattern *new,
- const struct cfg80211_pkt_pattern *old)
+static void ath10k_wow_convert_8023_to_80211(struct cfg80211_pkt_pattern *new,
+ const struct cfg80211_pkt_pattern *old)
{
u8 hdr_8023_pattern[ETH_HLEN] = {};
u8 hdr_8023_bit_mask[ETH_HLEN] = {};
--
2.7.4
^ permalink raw reply related
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Lorenzo Bianconi @ 2019-02-11 15:10 UTC (permalink / raw)
To: Stefan Wahren
Cc: Stanislaw Gruszka, Felix Fietkau, Doug Anderson,
Minas Harutyunyan, linux-wireless, linux-usb
In-Reply-To: <8a996497-ed69-4087-2c37-7f73633cbb4e@i2se.com>
> Hi Lorenzo,
>
> Am 11.02.19 um 12:06 schrieb Lorenzo Bianconi:
> >> Hi,
> >>
> >> Am 11.02.19 um 11:04 schrieb Lorenzo Bianconi:
> >>>> On Sun, Feb 10, 2019 at 11:22:25AM +0100, Lorenzo Bianconi wrote:
> >>>>>> On Sat, Feb 09, 2019 at 09:29:05PM +0100, Stefan Wahren wrote:
> >>>>>>>> could you please test the following series:
> >>>>>>>> https://patchwork.kernel.org/cover/10764453/
> >>>>>>> yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
> >>>>>> So this is either dwc2 scatter-gather problem which should be addressed in
> >>>>>> this driver or mt76x0u does something wrong when configuring SG.
> >>>>>>
> >>>>>> Disabling SG is just workaround, which do not address actual problem.
> >>>>>>
> >>>>>> I think I found mt76x0u issue that could cause this USB probe error
> >>>>>> (and possibly also address AMD IOMMU issue). We seems do not correctly
> >>>>>> set URB transfer length smaller than sg buffer length. Attached patch
> >>>>>> should correct that.
> >>>>> Hi Stanislaw,
> >>>>>
> >>>>> I think 'sg[0].length' is already set in mt76u_fill_rx_sg().
> >>>> It is, buf->len and sg[0].length are initialized to the same value for 1
> >>>> segment. But then buf->len (assigned to urb->buffer_transfer_length) change
> >>>> to smaller value , but sg[0].length stay the same. What I think can be
> >>>> problem for usb host driver.
> >>>>
> >>>>> Moreover applying this patch I got the following crash (rpi-5.0.y):
> >>>> Ok, so with patch probe fail instantly and trigger yet another bug(s)
> >>>> on error path. You seems to address that already.
> >>>>
> >>>>> Moreover for mt76x0u SG is 'already' disabled since we use just one
> >>>>> buffer so from performance point of view I do not see any difference
> >>>>> of using a standard usb buffer.
> >>>>> This patch has been tested in multiple scenarios and seems to fix
> >>>>> reported issues (for usb2.0).
> >>>> Ok, so passing buffer via urb->transfer_buffer works. But why urb->sg
> >>>> does not work for 1 segment ?
> >>> Here it is a different issue respect to the AMD IOMMU one, dwc2 host driver
> >>> does not implement SG I/O so probing fails. I guess it is still useful to
> >>> implement a 'legacy' mode that enable mt76 on host controllers that do not implement
> >>> SG I/O (rpi is a very common device so it will be cool to have mt76 working on
> >>> it). Moreover we are not removing functionalities, user experience will remain
> >>> the same
> >>>
> >> i'm not sure that you understand my mail [1] with the summary of my test
> >> results.
> >>
> > Yes right, I did not get it sorry :)
> > as indicated here https://www.raspberrypi.org/documentation/linux/kernel/building.md
> > I am using bcm2709_defconfig config (using it I spotted the mt76 crashes and
> > probe failure)
>
> no problem, at the beginning this could be very confusing. I only want
> to clarify that this documentation refers to the vendor kernel (with a
> different USB host driver) of the Raspberry Pi Foundation.
>
> All my results refers to the mainline kernel we all should talk about. I
> started a gist which try to describe the mainline variant:
> https://gist.github.com/lategoodbye/c7317a42bf7f9c07f5a91baed8c68f75
So to summarize:
- Raspberry Pi Foundation kernel works just with RFC series
- mainline kernel works out of the box
is my understanding correct? I am still considering adding a legacy mode since
there will not be any regression using it instead of SG I/O with just one SG
buffer
Regards,
Lorenzo
>
> Maybe this could be helpful.
>
> Stefan
>
> > Regards,
> > Lorenzo
> >
> >> In case of using the arm/multi_v7_defconfig (32 bit) the mt76 works like
> >> a charm without your sg avoid patch series, but the arm64/defconfig (64
> >> bit) requires the series to probe at least. So i wouldn't conclude from
> >> the fact that dwc2 doesn't support SG any probing issues on arm64. So we
> >> need to investigate which config option triggers the problem.
> >>
> >> Stefan
> >>
> >> [1] - https://marc.info/?l=linux-usb&m=154981675724078
> >>
^ permalink raw reply
* [PATCH 6/6] ath10k: copy the whole struct ath10k_bus_params in ath10k_core_register()
From: Kalle Valo @ 2019-02-11 15:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <1549897787-28537-1-git-send-email-kvalo@codeaurora.org>
Instead of copying fields one by one copy the whole structure. This way there's
no need to modify the function every time we add a new field to the struct.
Compile tested only.
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 6c1dd5f8d012..a1b2aea4a77f 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2997,9 +2997,8 @@ static void ath10k_core_register_work(struct work_struct *work)
int ath10k_core_register(struct ath10k *ar,
const struct ath10k_bus_params *bus_params)
{
- ar->bus_param.chip_id = bus_params->chip_id;
- ar->bus_param.dev_type = bus_params->dev_type;
- ar->bus_param.link_can_suspend = bus_params->link_can_suspend;
+ ar->bus_param = *bus_params;
+
queue_work(ar->workqueue, &ar->register_work);
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/6] ath10k: align ath10k_htt_txbuf structures
From: Kalle Valo @ 2019-02-11 15:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <1549897787-28537-1-git-send-email-kvalo@codeaurora.org>
With W=1 GCC warns:
drivers/net/wireless/ath/ath10k/htt.h:1746:1: warning: alignment 1 of 'struct ath10k_htt_txbuf_32' is less than 4 [-Wpacked-not-aligned]
drivers/net/wireless/ath/ath10k/htt.h:1753:1: warning: alignment 1 of 'struct ath10k_htt_txbuf_64' is less than 4 [-Wpacked-not-aligned]
Fix that by using __align(4). Compile tested only.
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/htt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 005fad94edad..d194bbe18fc3 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1743,14 +1743,14 @@ struct ath10k_htt_txbuf_32 {
struct ath10k_htc_hdr htc_hdr;
struct htt_cmd_hdr cmd_hdr;
struct htt_data_tx_desc cmd_tx;
-} __packed;
+} __packed __aligned(4);
struct ath10k_htt_txbuf_64 {
struct htt_data_tx_desc_frag frags[2];
struct ath10k_htc_hdr htc_hdr;
struct htt_cmd_hdr cmd_hdr;
struct htt_data_tx_desc_64 cmd_tx;
-} __packed;
+} __packed __aligned(4);
struct ath10k_htt {
struct ath10k *ar;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/6] ath10k: make wmi_service_name() warn about missing service ids
From: Kalle Valo @ 2019-02-11 15:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <1549897787-28537-1-git-send-email-kvalo@codeaurora.org>
When adding a new value to enum wmi_service it's very easy to miss that the new
value should be also added to wmi_service_name() mapping function. Modify the
function so that GCC can now warn about this:
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_FOO' not handled in switch [-Wswitch]
And also add a reminder to the enum.
Thanks to Jouni Malinen for the idea.
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/wmi.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 529f5a26f3f3..74ce1a4c0e8f 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -212,6 +212,8 @@ enum wmi_service {
WMI_SERVICE_PER_PACKET_SW_ENCRYPT,
WMI_SERVICE_REPORT_AIRTIME,
+ /* Remember to add the new value to wmi_service_name()! */
+
/* keep last */
WMI_SERVICE_MAX,
};
@@ -378,7 +380,7 @@ enum wmi_10_4_service {
WMI_10_4_SERVICE_REPORT_AIRTIME,
};
-static inline char *wmi_service_name(int service_id)
+static inline char *wmi_service_name(enum wmi_service service_id)
{
#define SVCSTR(x) case x: return #x
@@ -501,11 +503,13 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_PER_PACKET_SW_ENCRYPT);
SVCSTR(WMI_SERVICE_REPORT_AIRTIME);
- default:
+ case WMI_SERVICE_MAX:
return NULL;
}
#undef SVCSTR
+
+ return NULL;
}
#define WMI_SERVICE_IS_ENABLED(wmi_svc_bmap, svc_id, len) \
--
2.7.4
^ permalink raw reply related
* [PATCH 3/6] ath10k: change wmi.h to include only ieee80211.h
From: Kalle Valo @ 2019-02-11 15:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <1549897787-28537-1-git-send-email-kvalo@codeaurora.org>
wmi.h does not use anything from mac80211.h so change it to include only
ieee80211.h.
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/wmi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 74ce1a4c0e8f..23fe482834b4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -20,7 +20,7 @@
#define _WMI_H_
#include <linux/types.h>
-#include <net/mac80211.h>
+#include <linux/ieee80211.h>
/*
* This file specifies the WMI interface for the Unified Software
--
2.7.4
^ permalink raw reply related
* [PATCH] cfg80211: fix and clean up cfg80211_gen_new_bssid()
From: Johannes Berg @ 2019-02-11 15:02 UTC (permalink / raw)
To: linux-wireless; +Cc: Jouni Malinen, Peng Xu, Sara Sharon, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Fix cfg80211_gen_new_bssid() to not rely on u64 modulo arithmetic,
which isn't needed since we really just want to mask there. Also,
clean it up to calculate the mask only once and use GENMASK_ULL()
instead of open-coding the mask calculation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/cfg80211.h | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b61b71f369c7..3f7820b2ea4d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -5475,22 +5475,20 @@ cfg80211_inform_bss_frame(struct wiphy *wiphy,
* @bssid: transmitter BSSID
* @max_bssid: max BSSID indicator, taken from Multiple BSSID element
* @mbssid_index: BSSID index, taken from Multiple BSSID index element
- * @new_bssid_addr: address of the resulting BSSID
+ * @new_bssid: address of the resulting BSSID
*/
static inline void cfg80211_gen_new_bssid(const u8 *bssid, u8 max_bssid,
- u8 mbssid_index, u8 *new_bssid_addr)
+ u8 mbssid_index, u8 *new_bssid)
{
- u64 bssid_tmp, new_bssid;
- u64 lsb_n;
+ u64 bssid_u64 = ether_addr_to_u64(bssid_addr);
+ u64 mask = GENMASK_ULL(max_bssid - 1, 0);
+ u64 new_bssid_u64;
- bssid_tmp = ether_addr_to_u64(bssid);
+ new_bssid_u64 = bssid_u64 & ~mask;
- lsb_n = bssid_tmp & ((1 << max_bssid) - 1);
- new_bssid = bssid_tmp;
- new_bssid &= ~((1 << max_bssid) - 1);
- new_bssid |= (lsb_n + mbssid_index) % (1 << max_bssid);
+ new_bssid_u64 |= ((bssid_u64 & mask) + mbssid_index) & mask;
- u64_to_ether_addr(new_bssid, new_bssid_addr);
+ u64_to_ether_addr(new_bssid_u64, new_bssid);
}
/**
--
2.17.2
^ permalink raw reply related
* [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stefan Wahren @ 2019-02-11 15:27 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Stanislaw Gruszka, Felix Fietkau, Doug Anderson,
Minas Harutyunyan, linux-wireless, linux-usb
In-Reply-To: <20190211151055.GC8128@localhost.localdomain>
Hi,
Am 11.02.19 um 16:10 schrieb Lorenzo Bianconi:
>> Hi Lorenzo,
>>
>> Am 11.02.19 um 12:06 schrieb Lorenzo Bianconi:
>>>> Hi,
>>>>
>>>> Am 11.02.19 um 11:04 schrieb Lorenzo Bianconi:
>>>>>> On Sun, Feb 10, 2019 at 11:22:25AM +0100, Lorenzo Bianconi wrote:
>>>>>>>> On Sat, Feb 09, 2019 at 09:29:05PM +0100, Stefan Wahren wrote:
>>>>>>>>>> could you please test the following series:
>>>>>>>>>> https://patchwork.kernel.org/cover/10764453/
>>>>>>>>> yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
>>>>>>>> So this is either dwc2 scatter-gather problem which should be addressed in
>>>>>>>> this driver or mt76x0u does something wrong when configuring SG.
>>>>>>>>
>>>>>>>> Disabling SG is just workaround, which do not address actual problem.
>>>>>>>>
>>>>>>>> I think I found mt76x0u issue that could cause this USB probe error
>>>>>>>> (and possibly also address AMD IOMMU issue). We seems do not correctly
>>>>>>>> set URB transfer length smaller than sg buffer length. Attached patch
>>>>>>>> should correct that.
>>>>>>> Hi Stanislaw,
>>>>>>>
>>>>>>> I think 'sg[0].length' is already set in mt76u_fill_rx_sg().
>>>>>> It is, buf->len and sg[0].length are initialized to the same value for 1
>>>>>> segment. But then buf->len (assigned to urb->buffer_transfer_length) change
>>>>>> to smaller value , but sg[0].length stay the same. What I think can be
>>>>>> problem for usb host driver.
>>>>>>
>>>>>>> Moreover applying this patch I got the following crash (rpi-5.0.y):
>>>>>> Ok, so with patch probe fail instantly and trigger yet another bug(s)
>>>>>> on error path. You seems to address that already.
>>>>>>
>>>>>>> Moreover for mt76x0u SG is 'already' disabled since we use just one
>>>>>>> buffer so from performance point of view I do not see any difference
>>>>>>> of using a standard usb buffer.
>>>>>>> This patch has been tested in multiple scenarios and seems to fix
>>>>>>> reported issues (for usb2.0).
>>>>>> Ok, so passing buffer via urb->transfer_buffer works. But why urb->sg
>>>>>> does not work for 1 segment ?
>>>>> Here it is a different issue respect to the AMD IOMMU one, dwc2 host driver
>>>>> does not implement SG I/O so probing fails. I guess it is still useful to
>>>>> implement a 'legacy' mode that enable mt76 on host controllers that do not implement
>>>>> SG I/O (rpi is a very common device so it will be cool to have mt76 working on
>>>>> it). Moreover we are not removing functionalities, user experience will remain
>>>>> the same
>>>>>
>>>> i'm not sure that you understand my mail [1] with the summary of my test
>>>> results.
>>>>
>>> Yes right, I did not get it sorry :)
>>> as indicated here https://www.raspberrypi.org/documentation/linux/kernel/building.md
>>> I am using bcm2709_defconfig config (using it I spotted the mt76 crashes and
>>> probe failure)
>> no problem, at the beginning this could be very confusing. I only want
>> to clarify that this documentation refers to the vendor kernel (with a
>> different USB host driver) of the Raspberry Pi Foundation.
>>
>> All my results refers to the mainline kernel we all should talk about. I
>> started a gist which try to describe the mainline variant:
>> https://gist.github.com/lategoodbye/c7317a42bf7f9c07f5a91baed8c68f75
> So to summarize:
> - Raspberry Pi Foundation kernel works just with RFC series
> - mainline kernel works out of the box
>
> is my understanding correct?
not really.
Compiling the mainline kernel with arm/multi_v7_defconfig it works.
Using the same kernel but with arm64/defconfig doesn't work. But i don't
think this is a 32/64 bit issue. The arm64 defconfig is much more
complex (e.g. enables more IOMMU stuff).
Regards
Stefan
^ permalink raw reply
* Re: [mac80211-next:cfg80211-mac80211-multi-bssid 8/20] ERROR: "__umoddi3" [net/wireless/cfg80211.ko] undefined!
From: Johannes Berg @ 2019-02-11 14:58 UTC (permalink / raw)
To: Jouni Malinen
Cc: kbuild test robot, Peng Xu, kbuild-all, linux-wireless,
Sara Sharon, Jouni Malinen
In-Reply-To: <20190211145747.GA30703@w1.fi>
On Mon, 2019-02-11 at 16:57 +0200, Jouni Malinen wrote:
> On Sat, Feb 09, 2019 at 09:08:20AM +0100, Johannes Berg wrote:
>
> > but maybe the whole thing is more readable as
> >
> > static inline void cfg80211_gen_new_bssid(const u8 *bssid_addr, u8 max_bssid,
> > u8 mbssid_index, u8 *new_bssid_addr)
> > {
> > u64 bssid = ether_addr_to_u64(bssid_addr);
> > u64 mask = GENMASK_ULL(max_bssid - 1, 0);
> > u64 new_bssid;
> >
> > new_bssid &= bssid & ~mask;
>
> That should be "=" not "&="..
Yes, good point.
> > However, isn't it true that 0 <= mbssid_index < max_bssid? Then the
> > whole masking isn't really needed at all?
>
> 0 <= mbssid_index < 2^max_bssid.
True, sorry.
> The transmitted BSSID (i.e., that
> bssid_addr argument) is not required to be the first BSSID in the range,
> so the masking is needed to cover wraparound for addition modulo
> 2^mbssid_index when max_bssid LSBs of bssid are not zeros.
Ah ok.
Alright, I'll send out a proper patch.
Thanks!
johannes
^ permalink raw reply
* Re: [mac80211-next:cfg80211-mac80211-multi-bssid 8/20] ERROR: "__umoddi3" [net/wireless/cfg80211.ko] undefined!
From: Jouni Malinen @ 2019-02-11 14:57 UTC (permalink / raw)
To: Johannes Berg
Cc: kbuild test robot, Peng Xu, kbuild-all, linux-wireless,
Sara Sharon, Jouni Malinen
In-Reply-To: <9e586a147fa94995b06011d74ab6ee1a082f4b94.camel@sipsolutions.net>
On Sat, Feb 09, 2019 at 09:08:20AM +0100, Johannes Berg wrote:
> but maybe the whole thing is more readable as
>
> static inline void cfg80211_gen_new_bssid(const u8 *bssid_addr, u8 max_bssid,
> u8 mbssid_index, u8 *new_bssid_addr)
> {
> u64 bssid = ether_addr_to_u64(bssid_addr);
> u64 mask = GENMASK_ULL(max_bssid - 1, 0);
> u64 new_bssid;
>
> new_bssid &= bssid & ~mask;
That should be "=" not "&="..
> new_bssid |= ((bssid & mask) + mbssid_index) & mask;
>
> u64_to_ether_addr(new_bssid, new_bssid_addr);
> }
but other than that, this version looks much nicer than the other
alternatives.
> However, isn't it true that 0 <= mbssid_index < max_bssid? Then the
> whole masking isn't really needed at all?
0 <= mbssid_index < 2^max_bssid. The transmitted BSSID (i.e., that
bssid_addr argument) is not required to be the first BSSID in the range,
so the masking is needed to cover wraparound for addition modulo
2^mbssid_index when max_bssid LSBs of bssid are not zeros.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH 12/15] mac80211: shorten debug print to avoid warning
From: Johannes Berg @ 2019-02-11 14:52 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Adiel Aloni, Luca Coelho
In-Reply-To: <20190206111721.29283-13-luca@coelho.fi>
On Wed, 2019-02-06 at 13:17 +0200, Luca Coelho wrote:
> From: Adiel Aloni <adiel.aloni@intel.com>
>
> Signed-off-by: Adiel Aloni <adiel.aloni@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
> net/mac80211/mlme.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 6d1e7e6f1c21..0b27e52daf43 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -184,7 +184,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
> * it should be OK.
> */
> sdata_info(sdata,
> - "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
> + "mismatch: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disable HT\n",
>
I know you also have a patch in the pipeline that just extends the
buffer, so I'm dropping this :)
johannes
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Lorenzo Bianconi @ 2019-02-11 15:57 UTC (permalink / raw)
To: Stefan Wahren
Cc: Stanislaw Gruszka, Felix Fietkau, Doug Anderson,
Minas Harutyunyan, linux-wireless, linux-usb
In-Reply-To: <500c0d4a-611a-1b00-5ea4-7368e5e9f1e9@i2se.com>
> Hi,
>
> Am 11.02.19 um 16:10 schrieb Lorenzo Bianconi:
> >> Hi Lorenzo,
> >>
> >> Am 11.02.19 um 12:06 schrieb Lorenzo Bianconi:
> >>>> Hi,
> >>>>
> >>>> Am 11.02.19 um 11:04 schrieb Lorenzo Bianconi:
> >>>>>> On Sun, Feb 10, 2019 at 11:22:25AM +0100, Lorenzo Bianconi wrote:
> >>>>>>>> On Sat, Feb 09, 2019 at 09:29:05PM +0100, Stefan Wahren wrote:
> >>>>>>>>>> could you please test the following series:
> >>>>>>>>>> https://patchwork.kernel.org/cover/10764453/
> >>>>>>>>> yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
> >>>>>>>> So this is either dwc2 scatter-gather problem which should be addressed in
> >>>>>>>> this driver or mt76x0u does something wrong when configuring SG.
> >>>>>>>>
> >>>>>>>> Disabling SG is just workaround, which do not address actual problem.
> >>>>>>>>
> >>>>>>>> I think I found mt76x0u issue that could cause this USB probe error
> >>>>>>>> (and possibly also address AMD IOMMU issue). We seems do not correctly
> >>>>>>>> set URB transfer length smaller than sg buffer length. Attached patch
> >>>>>>>> should correct that.
> >>>>>>> Hi Stanislaw,
> >>>>>>>
> >>>>>>> I think 'sg[0].length' is already set in mt76u_fill_rx_sg().
> >>>>>> It is, buf->len and sg[0].length are initialized to the same value for 1
> >>>>>> segment. But then buf->len (assigned to urb->buffer_transfer_length) change
> >>>>>> to smaller value , but sg[0].length stay the same. What I think can be
> >>>>>> problem for usb host driver.
> >>>>>>
> >>>>>>> Moreover applying this patch I got the following crash (rpi-5.0.y):
> >>>>>> Ok, so with patch probe fail instantly and trigger yet another bug(s)
> >>>>>> on error path. You seems to address that already.
> >>>>>>
> >>>>>>> Moreover for mt76x0u SG is 'already' disabled since we use just one
> >>>>>>> buffer so from performance point of view I do not see any difference
> >>>>>>> of using a standard usb buffer.
> >>>>>>> This patch has been tested in multiple scenarios and seems to fix
> >>>>>>> reported issues (for usb2.0).
> >>>>>> Ok, so passing buffer via urb->transfer_buffer works. But why urb->sg
> >>>>>> does not work for 1 segment ?
> >>>>> Here it is a different issue respect to the AMD IOMMU one, dwc2 host driver
> >>>>> does not implement SG I/O so probing fails. I guess it is still useful to
> >>>>> implement a 'legacy' mode that enable mt76 on host controllers that do not implement
> >>>>> SG I/O (rpi is a very common device so it will be cool to have mt76 working on
> >>>>> it). Moreover we are not removing functionalities, user experience will remain
> >>>>> the same
> >>>>>
> >>>> i'm not sure that you understand my mail [1] with the summary of my test
> >>>> results.
> >>>>
> >>> Yes right, I did not get it sorry :)
> >>> as indicated here https://www.raspberrypi.org/documentation/linux/kernel/building.md
> >>> I am using bcm2709_defconfig config (using it I spotted the mt76 crashes and
> >>> probe failure)
> >> no problem, at the beginning this could be very confusing. I only want
> >> to clarify that this documentation refers to the vendor kernel (with a
> >> different USB host driver) of the Raspberry Pi Foundation.
> >>
> >> All my results refers to the mainline kernel we all should talk about. I
> >> started a gist which try to describe the mainline variant:
> >> https://gist.github.com/lategoodbye/c7317a42bf7f9c07f5a91baed8c68f75
> > So to summarize:
> > - Raspberry Pi Foundation kernel works just with RFC series
> > - mainline kernel works out of the box
> >
> > is my understanding correct?
>
> not really.
>
> Compiling the mainline kernel with arm/multi_v7_defconfig it works.
> Using the same kernel but with arm64/defconfig doesn't work. But i don't
> think this is a 32/64 bit issue. The arm64 defconfig is much more
> complex (e.g. enables more IOMMU stuff).
thx for the clarification :)
Regards,
Lorenzo
>
> Regards
> Stefan
>
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: Assign 'n_cipher_suites = 11' for WCN3990 to enable WPA3
From: Kalle Valo @ 2019-02-11 16:27 UTC (permalink / raw)
To: Abhishek Ambure; +Cc: ath10k, linux-wireless, Abhishek Ambure
In-Reply-To: <1548339697-17766-2-git-send-email-aambure@codeaurora.org>
Abhishek Ambure <aambure@codeaurora.org> wrote:
> Hostapd uses CCMP, GCMP & GCMP-256 as 'wpa_pairwise' option to run WPA3.
> In WCN3990 firmware cipher suite numbers 9 to 11 are for CCMP,
> GCMP & GCMP-256.
>
> To enable CCMP, GCMP & GCMP-256 cipher suites in WCN3990 firmware,
> host sets 'n_cipher_suites = 11' while initializing hardware parameters.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
>
> Signed-off-by: Abhishek Ambure <aambure@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2 patches applied to ath-next branch of ath.git, thanks.
7ba31e6e0cdc ath10k: assign 'n_cipher_suites = 11' for WCN3990 to enable WPA3
7d94f862d648 ath10k: update GCMP & GCMP-256 cipher suite number for WCN3990
--
https://patchwork.kernel.org/patch/10779097/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] ath10k: implement set_base_macaddr to fix rx-bssid mask in multiple APs conf
From: Kalle Valo @ 2019-02-11 16:28 UTC (permalink / raw)
To: Christian Lamparter
Cc: linux-wireless, ath10k, Brian Norris, Ben Greear, Felix Fietkau,
Mathias Kresin
In-Reply-To: <20190204205714.23858-1-chunkeey@gmail.com>
Christian Lamparter <chunkeey@gmail.com> wrote:
> Many integrated QCA9984 WiFis in various IPQ806x platform routers
> from various vendors (Netgear R7800, ZyXEL NBG6817, TP-LINK C2600,
> etc.) have either blank, bogus or non-unique MAC-addresses in
> their calibration data.
>
> As a result, OpenWrt utilizes a discouraged binary calibration data
> patching method that allows to modify the device's MAC-addresses right
> at the source. This is because the ath10k' firmware extracts the MAC
> address from the supplied radio/calibration data and issues a response
> to the ath10k linux driver. Which was designed to take the main MAC in
> ath10k_wmi_event_ready().
>
> Part of the "setting an alternate MAC" issue was already tackled by a
> patch from Brian Norris:
> commit 9d5804662ce1
> ("ath10k: retrieve MAC address from system firmware if provided")
> by allowing the option to specify an alternate MAC-address with the
> established device_get_mac_address() function which extracts the right
> address from DeviceTree/fwnode mac-address or local-mac-address
> properties and saves it for later.
>
> However, Ben Greear noted that the Qualcomm's ath10k firmware is liable
> to not properly calculate its rx-bssid mask in this case. This can cause
> issues in the popluar "multiple AP with a single ath10k instance"
> configurations.
>
> To improve MAC address handling, Felix Fietkau suggested to call
> pdev_set_base_macaddr_cmdid before bringing up the first vif and
> use the first vif MAC address there. Which is in ath10k_core_start().
>
> This patch implement Felix Fietkau's request to
> "call pdev_set_base_macaddr_cmdid before bringing up the first vif".
> The pdev_set_base_macaddr_cmdid is already declared for all devices
> and version. The driver just needed the support code for this
> function.
>
> Tested on:
> QCA9880/CUS223, firmwares: 10.2.4.13-2, 10.2.4.70.44, 10.2.4-1.0-00041
> QCA9887/MR33 firmware:10.2.4-1.0-00033
> QCA4019/RT-AC58U firmware: 10.4-3.4-00104, 10.4-3.5.3-00057
> QCA9984/R7800 firmware: Candela Technologies (CT) Firmware
>
> BugLink: https://lists.openwrt.org/pipermail/openwrt-devel/2018-November/014595.html
> Fixes: 9d5804662ce1 ("ath10k: retrieve MAC address from system firmware if provided")
> Cc: Brian Norris <briannorris@chromium.org>
> Cc: Ben Greear <greearb@candelatech.com>
> Cc: Felix Fietkau <nbd@nbd.name>
> Cc: Mathias Kresin <dev@kresin.me>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Tested-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
05e7ba24b10d ath10k: implement set_base_macaddr to fix rx-bssid mask in multiple APs conf
--
https://patchwork.kernel.org/patch/10796625/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 1/3] ath10k: Enable bus layer suspend/resume for WCN3990
From: Kalle Valo @ 2019-02-11 16:30 UTC (permalink / raw)
To: Govind Singh; +Cc: ath10k, linux-wireless, Govind Singh
In-Reply-To: <20190206121433.11606-2-govinds@codeaurora.org>
Govind Singh <govinds@codeaurora.org> wrote:
> Register snoc bus layer suspend/resume PM ops and configure
> the wakeup source(CE2) for the device.
>
> Testing:
> Tested on WCN3990 HW.
> Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
>
> Signed-off-by: Govind Singh <govinds@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
3 patches applied to ath-next branch of ath.git, thanks.
185be1c66469 ath10k: enable bus layer suspend/resume for WCN3990
de8781d7e74d ath10k: disable interface pause wow config for integrated chipset
c40e448e0bcf ath10k: request credit report if flow control enabled on ep
--
https://patchwork.kernel.org/patch/10799247/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: pci: use mutex for diagnostic window CE polling
From: Kalle Valo @ 2019-02-11 16:32 UTC (permalink / raw)
To: Brian Norris; +Cc: linux-wireless, ath10k, Carl Huang, Wen Gong, Brian Norris
In-Reply-To: <20190207014143.41529-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> The DIAG copy engine is only used via polling, but it holds a spinlock
> with softirqs disabled. Each iteration of our read/write loops can
> theoretically take 20ms (two 10ms timeout loops), and this loop can be
> run an unbounded number of times while holding the spinlock -- dependent
> on the request size given by the caller.
>
> As of commit 39501ea64116 ("ath10k: download firmware via diag Copy
> Engine for QCA6174 and QCA9377."), we transfer large chunks of firmware
> memory using this mechanism. With large enough firmware segments, this
> becomes an exceedingly long period for disabling soft IRQs. For example,
> with a 500KiB firmware segment, in testing QCA6174A, I see 200 loop
> iterations of about 50-100us each, which can total about 10-20ms.
>
> In reality, we don't really need to block softirqs for this duration.
> The DIAG CE is only used in polling mode, and we only need to hold
> ce_lock to make sure any CE bookkeeping is done without screwing up
> another CE. Otherwise, we only need to ensure exclusion between
> ath10k_pci_diag_{read,write}_mem() contexts.
>
> This patch moves to use fine-grained locking for the shared ce_lock,
> while adding a new mutex just to ensure mutual exclusion of diag
> read/write operations.
>
> Tested on QCA6174A, firmware version WLAN.RM.4.4.1-00132-QCARMSWPZ-1.
>
> Fixes: 39501ea64116 ("ath10k: download firmware via diag Copy Engine for QCA6174 and QCA9377.")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
25733c4e67df ath10k: pci: use mutex for diagnostic window CE polling
--
https://patchwork.kernel.org/patch/10800343/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: Enable Factory Test Mode for WCN3990
From: Kalle Valo @ 2019-02-11 16:34 UTC (permalink / raw)
To: Rakesh Pillai; +Cc: ath10k, linux-wireless, Rakesh Pillai
In-Reply-To: <1535526038-4299-1-git-send-email-pillair@codeaurora.org>
Rakesh Pillai <pillair@codeaurora.org> wrote:
> The support to put WCN3990 firmware into Factory
> test mode is not present currently. The WCN3990
> firmware can operate in Factory test mode based
> on the mode it receives in the wlan enable message
> from the host driver.
>
> When the host driver is started in testmode send
> the operating mode as UTF mode, to the WCN3990
> firmware, in the wlan enable message to start the
> firmware in Factory test mode.
>
> Tested on: WCN3990
> Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
>
> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
3c545a25939c ath10k: enable Factory Test Mode for WCN3990
--
https://patchwork.kernel.org/patch/10579559/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: Fix shadow register implementation for WCN3990
From: Kalle Valo @ 2019-02-11 16:35 UTC (permalink / raw)
To: Rakesh Pillai; +Cc: ath10k, linux-wireless, Rakesh Pillai
In-Reply-To: <1548755647-23356-1-git-send-email-pillair@codeaurora.org>
Rakesh Pillai <pillair@codeaurora.org> wrote:
> WCN3990 supports shadow registers write operation support
> for copy engine for regular operation in powersave mode.
>
> Since WCN3990 is a 64-bit target, the shadow register
> implementation needs to be done in the copy engine handlers
> for 64-bit target. Currently the shadow register implementation
> is present in the 32-bit target handlers of copy engine.
>
> Fix the shadow register copy engine write operation
> implementation for 64-bit target(WCN3990).
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
>
> Fixes: b7ba83f7c414 ("ath10k: add support for shadow register for WNC3990")
> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
1863008369ae ath10k: fix shadow register implementation for WCN3990
--
https://patchwork.kernel.org/patch/10785903/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 12/15] mac80211: shorten debug print to avoid warning
From: Luca Coelho @ 2019-02-11 16:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Adiel Aloni
In-Reply-To: <8409e5d470926c650e37062f4063976989096280.camel@sipsolutions.net>
On Mon, 2019-02-11 at 15:52 +0100, Johannes Berg wrote:
> On Wed, 2019-02-06 at 13:17 +0200, Luca Coelho wrote:
> > From: Adiel Aloni <adiel.aloni@intel.com>
> >
> > Signed-off-by: Adiel Aloni <adiel.aloni@intel.com>
> > Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> > ---
> > net/mac80211/mlme.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> > index 6d1e7e6f1c21..0b27e52daf43 100644
> > --- a/net/mac80211/mlme.c
> > +++ b/net/mac80211/mlme.c
> > @@ -184,7 +184,7 @@ ieee80211_determine_chantype(struct
> > ieee80211_sub_if_data *sdata,
> > * it should be OK.
> > */
> > sdata_info(sdata,
> > - "Wrong control channel: center-freq: %d ht-
> > cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
> > + "mismatch: center-freq: %d ht-cfreq: %d ht-
> > >primary_chan: %d band: %d - Disable HT\n",
> >
>
> I know you also have a patch in the pipeline that just extends the
> buffer, so I'm dropping this :)
Oooohhh, that's insider information! :P
But yeah, I merged the other patch internally one day before I sent
this one out, so my bad... sorry.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH 1/3] iw: Add command to set airtime weight
From: Toke Høiland-Jørgensen @ 2019-02-11 17:04 UTC (permalink / raw)
To: linux-wireless
This adds a new iw command to set the airtime weight for a station, support
for which was recently introduced into mac80211.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
---
station.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/station.c b/station.c
index e1477ef..536120c 100644
--- a/station.c
+++ b/station.c
@@ -651,6 +651,7 @@ COMMAND(station, del, "<MAC address> [subtype <subtype>] [reason-code <code>]",
static const struct cmd *station_set_plink;
static const struct cmd *station_set_vlan;
static const struct cmd *station_set_mesh_power_mode;
+static const struct cmd *station_set_airtime_weight;
static const struct cmd *select_station_cmd(int argc, char **argv)
{
@@ -662,6 +663,8 @@ static const struct cmd *select_station_cmd(int argc, char **argv)
return station_set_vlan;
if (strcmp(argv[1], "mesh_power_mode") == 0)
return station_set_mesh_power_mode;
+ if (strcmp(argv[1], "airtime_weight") == 0)
+ return station_set_airtime_weight;
return NULL;
}
@@ -813,6 +816,54 @@ COMMAND_ALIAS(station, set, "<MAC address> mesh_power_mode "
"Set link-specific mesh power mode for this station",
select_station_cmd, station_set_mesh_power_mode);
+static int handle_station_set_airtime_weight(struct nl80211_state *state,
+ struct nl_msg *msg,
+ int argc, char **argv,
+ enum id_input id)
+{
+ unsigned char mac_addr[ETH_ALEN];
+ unsigned long airtime_weight = 0;
+ char *err = NULL;
+
+ if (argc < 3)
+ return 1;
+
+ if (mac_addr_a2n(mac_addr, argv[0])) {
+ fprintf(stderr, "invalid mac address\n");
+ return 2;
+ }
+ argc--;
+ argv++;
+
+ if (strcmp("airtime_weight", argv[0]) != 0)
+ return 1;
+ argc--;
+ argv++;
+
+ airtime_weight = strtoul(argv[0], &err, 0);
+ if (err && *err) {
+ fprintf(stderr, "invalid airtime weight\n");
+ return 2;
+ }
+ argc--;
+ argv++;
+
+ if (argc)
+ return 1;
+
+ NLA_PUT(msg, NL80211_ATTR_MAC, ETH_ALEN, mac_addr);
+ NLA_PUT_U16(msg, NL80211_ATTR_AIRTIME_WEIGHT, airtime_weight);
+
+ return 0;
+ nla_put_failure:
+ return -ENOBUFS;
+
+}
+COMMAND_ALIAS(station, set, "<MAC address> airtime_weight <weight>",
+ NL80211_CMD_SET_STATION, 0, CIB_NETDEV, handle_station_set_airtime_weight,
+ "Set airtime weight for this station.",
+ select_station_cmd, station_set_airtime_weight);
+
static int handle_station_dump(struct nl80211_state *state,
struct nl_msg *msg,
int argc, char **argv,
^ permalink raw reply related
* [PATCH 2/3] iw: Add printing of station tx duration and airtime weight
From: Toke Høiland-Jørgensen @ 2019-02-11 17:04 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <154990467406.6770.8841156470323507480.stgit@alrua-x1>
This adds printing of the station TX duration (along with the existing RX
duration), and the airtime weight, both of which were added as part of the
airtime fairness patches that were recently merged into mac80211.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
---
station.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/station.c b/station.c
index 536120c..25cbbc3 100644
--- a/station.c
+++ b/station.c
@@ -309,6 +309,7 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
[NL80211_STA_INFO_TID_STATS] = { .type = NLA_NESTED },
[NL80211_STA_INFO_BSS_PARAM] = { .type = NLA_NESTED },
[NL80211_STA_INFO_RX_DURATION] = { .type = NLA_U64 },
+ [NL80211_STA_INFO_TX_DURATION] = { .type = NLA_U64 },
[NL80211_STA_INFO_ACK_SIGNAL] = {.type = NLA_U8 },
[NL80211_STA_INFO_ACK_SIGNAL_AVG] = { .type = NLA_U8 },
};
@@ -401,6 +402,10 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
printf("\n\ttx bitrate:\t%s", buf);
}
+ if (sinfo[NL80211_STA_INFO_TX_DURATION])
+ printf("\n\ttx duration:\t%lld us",
+ (unsigned long long)nla_get_u64(sinfo[NL80211_STA_INFO_TX_DURATION]));
+
if (sinfo[NL80211_STA_INFO_RX_BITRATE]) {
char buf[100];
@@ -420,6 +425,10 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
printf("\n\tavg ack signal:\t%d dBm",
(int8_t)nla_get_u8(sinfo[NL80211_STA_INFO_ACK_SIGNAL_AVG]));
+ if (sinfo[NL80211_STA_INFO_AIRTIME_WEIGHT]) {
+ printf("\n\tairtime weight: %d", nla_get_u16(sinfo[NL80211_STA_INFO_AIRTIME_WEIGHT]));
+ }
+
if (sinfo[NL80211_STA_INFO_EXPECTED_THROUGHPUT]) {
uint32_t thr;
^ permalink raw reply related
* [PATCH 3/3] iw: Print airtime fairness feature
From: Toke Høiland-Jørgensen @ 2019-02-11 17:04 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <154990467406.6770.8841156470323507480.stgit@alrua-x1>
This adds printing of the newly introduced airtime fairness EXT_FEATURE
flag to iw.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
---
info.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/info.c b/info.c
index f1a25da..92c7d1d 100644
--- a/info.c
+++ b/info.c
@@ -694,6 +694,8 @@ broken_combination:
"control port over nl80211");
ext_feat_print(tb, NL80211_EXT_FEATURE_TXQS,
"TXQS", "FQ-CoDel-enabled intermediate TXQs");
+ ext_feat_print(tb, NL80211_EXT_FEATURE_AIRTIME_FAIRNESS,
+ "AIRTIME_FAIRNESS", "airtime fairness scheduling");
}
if (tb_msg[NL80211_ATTR_COALESCE_RULE]) {
^ permalink raw reply related
* Re: linux-next: Tree for Feb 11 (wireless/80211)
From: Randy Dunlap @ 2019-02-11 17:07 UTC (permalink / raw)
To: Stephen Rothwell, Linux Next Mailing List
Cc: Linux Kernel Mailing List, linux-wireless, netdev@vger.kernel.org,
Johannes Berg
In-Reply-To: <20190211183951.3fe1dad9@canb.auug.org.au>
On 2/10/19 11:39 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190208:
>
on i386:
ERROR: "__umoddi3" [net/wireless/cfg80211.ko] undefined!
ERROR: "__umoddi3" [net/mac80211/mac80211.ko] undefined!
--
~Randy
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stanislaw Gruszka @ 2019-02-11 17:22 UTC (permalink / raw)
To: Stefan Wahren
Cc: Lorenzo Bianconi, Felix Fietkau, Doug Anderson, Minas Harutyunyan,
linux-wireless, linux-usb
In-Reply-To: <500c0d4a-611a-1b00-5ea4-7368e5e9f1e9@i2se.com>
On Mon, Feb 11, 2019 at 04:27:40PM +0100, Stefan Wahren wrote:
> >> All my results refers to the mainline kernel we all should talk about. I
> >> started a gist which try to describe the mainline variant:
> >> https://gist.github.com/lategoodbye/c7317a42bf7f9c07f5a91baed8c68f75
> > So to summarize:
> > - Raspberry Pi Foundation kernel works just with RFC series
> > - mainline kernel works out of the box
> >
> > is my understanding correct?
>
> not really.
>
> Compiling the mainline kernel with arm/multi_v7_defconfig it works.
> Using the same kernel but with arm64/defconfig doesn't work. But i don't
> think this is a 32/64 bit issue. The arm64 defconfig is much more
> complex (e.g. enables more IOMMU stuff).
One possible thing that could be broken with IOMMU is allocating
big buffers via page_fraq_alloc(). Theoretically that should work,
but who knows. You can check my patch posted recently, it make
the driver stop doing big allocations via page_frag_alloc():
https://lore.kernel.org/linux-wireless/1549872974-7268-1-git-send-email-sgruszka@redhat.com/
Stanislaw
^ 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