* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Felix Fietkau @ 2019-02-19 12:19 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Stefan Wahren, Lorenzo Bianconi, Alan Stern, Doug Anderson,
Minas Harutyunyan, USB list, linux-wireless
In-Reply-To: <20190219104208.GA22999@redhat.com>
On 2019-02-19 11:42, Stanislaw Gruszka wrote:
> On Mon, Feb 18, 2019 at 07:52:27PM +0100, Felix Fietkau wrote:
>> On 2019-02-18 16:03, Stanislaw Gruszka wrote:
>> > On Mon, Feb 18, 2019 at 03:43:26PM +0100, Felix Fietkau wrote:
>> >> On 2019-02-18 14:52, Stanislaw Gruszka wrote:
>> >> > On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
>> >> >> this is a misunderstanding. The warning is about memory alignment to 32 bit addresses, not about page alignment. This is a typical ARM restriction. Maybe we need to make sure in mt76 that the DMA buffer needs to be aligned. But it's also possible that the warning isn't the root cause of our problem.
>> >> >>
>> >> >
>> >> > I see, it needs 4 bytes alignment . There is already dwc2 code checks
>> >> > that and allocate new buffer if the alignment is not right:
>> >> > dwc2_alloc_dma_aligned_buffer(), but it does nothing if urb->sg
>> >> > is not NULL. I thought mt76usb already provide aligned buffers, but
>> >> > looks it does not for one TX special case, which are PROBE REQUEST
>> >> > frames. Other frames are aligned by inserting L2 header pad. One
>> >> > solution for this would be just submit urb with NULL sg (same as
>> >> > Lorenzo's patches do, but still allocating buffers via buf->sg),
>> >> > but I think, you have right, we should provide 4 bytes aligned buffers
>> >> > by default as other DMA hardware may require that. I'm attaching yet
>> >> > another patch to test, which fix up alignment for PROBE REQUEST frames.
>> >> This approach looks completely wrong to me. MMIO based hardware does not
>> >> need 4-byte aligned buffers at all, other USB controllers do not need
>> >> this either.
>> >> As Lorenzo already pointed out, re-aligning the buffer is *very*
>> >> expensive, so we should not do this in the driver just to work around
>> >> quirks in a particular USB host driver.
>> >
>> > I decided to this patch because I thought some other USB & MMIO DMA
>> > platforms might also require this alignment. But it was never triggered
>> > in MMIO because on those mt76 is used in AP mode, hence no PROBE
>> > REQUEST frames (and scan can be passive on STA mode).
>> mt76 is regularly used and tested in STA and Mesh mode as well.
>> No DMA alignment related issues there.
>
> The question is why we need to do 2 bytes header pad ? Is this because
> ieee802.11 header length for mt76 hardware has to be multiple of 4 or
> it has to be aligned to 4 bytes? It would be strange if length has
> to be fixed to 4 bytes and alignment not. However this could be
> needed on some platforms and not on others.
Not sure why it was added in the hardware, but the MAC assumes that the
header is padded to a multiple of 4 bytes in the buffer after it has
been copied to device memory via DMA or USB.
Because of that, it has nothing to do with the alignment of the source
buffer, so the two should not be mixed up.
>> >> The way I see it, we have two choices.
>> >> 1. Fix dwc2 to do its alignment quirk for the urb->sg != NULL case
>> >> 2. Rely on urb->transfer_buffer and keep urb->sg NULL
>> >
>> > I agree, if this is only needed for dwc2. Though I would investigate
>> > if this is not a bug on other platforms as well.
>> >From what I can see, using Lorenzo's patches seems to be the better
>> solution, since they avoid these corner cases in dwc2 (and maybe other
>> drivers as well). I will apply them and then we'll see if we need to do
>> any further improvements later on.
>
> They work on rpi dwc2, but they do not address root of the problem.
> There is clearly something wrong how mt76usb handle SG, what is not
> fixed. And adding disable_usb_sg module parameter for hcd's supporting
> SG should be red flag.
I think we're simply dealing with multiple issues here, only some of
which are fixed by Lorenzo's patches.
I'm pretty sure it's still wrong for mt76 to try to align its buffers,
since the Linux USB API supports non-aligned transfer buffers and it
should be up to the controller driver to deal with that.
dwc2 tries to do that, but that has limitations which I already pointed
out and which are properly dealt with by Lorenzo's patches.
Any other issues with sg should be investigated separately, they are
probably unrelated to this one.
- Felix
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Felix Fietkau @ 2019-02-19 12:11 UTC (permalink / raw)
To: Stanislaw Gruszka, Stefan Wahren
Cc: Lorenzo Bianconi, Alan Stern, Doug Anderson, Minas Harutyunyan,
USB list, linux-wireless
In-Reply-To: <20190219105941.GB22999@redhat.com>
On 2019-02-19 11:59, Stanislaw Gruszka wrote:
> On Mon, Feb 18, 2019 at 11:19:40PM +0100, Stefan Wahren wrote:
>> Hi,
>>
>> > Stanislaw Gruszka <sgruszka@redhat.com> hat am 18. Februar 2019 um 14:52 geschrieben:
>> >
>> >
>> > On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
>> > > this is a misunderstanding. The warning is about memory alignment to 32 bit addresses, not about page alignment. This is a typical ARM restriction. Maybe we need to make sure in mt76 that the DMA buffer needs to be aligned. But it's also possible that the warning isn't the root cause of our problem.
>> > >
>> >
>> > I see, it needs 4 bytes alignment . There is already dwc2 code checks
>> > that and allocate new buffer if the alignment is not right:
>> > dwc2_alloc_dma_aligned_buffer(), but it does nothing if urb->sg
>> > is not NULL. I thought mt76usb already provide aligned buffers, but
>> > looks it does not for one TX special case, which are PROBE REQUEST
>> > frames. Other frames are aligned by inserting L2 header pad. One
>> > solution for this would be just submit urb with NULL sg (same as
>> > Lorenzo's patches do, but still allocating buffers via buf->sg),
>> > but I think, you have right, we should provide 4 bytes aligned buffers
>> > by default as other DMA hardware may require that. I'm attaching yet
>> > another patch to test, which fix up alignment for PROBE REQUEST frames.
>> >
>> > > > Attached patch should fix this, plese test, thanks in advance.
>>
>> i saw Felix decided to use Lorenzo's approach.
>>
>> The patches 1,3,5 applied on today's next fixed only the warning and wifi is still broken (authentication timeout).
>>
>> Here are the logs for multi_v7_defconfig:
>> https://gist.github.com/lategoodbye/0a7c5cea7dbf25d0de7944c05d229d79
>
> It would be interesting why urb->num_sgs = 0 & urb->sg cause
> the troubles. This is how usb_sg_init() submit urbs for sg_tablesize = 0
> controllers. So either are there are some requirement on urb->sg
> mapped via dma_map_page() (which mt76usb does not meet) not needed
> for urb->transfer_buffer mapped via dma_map_single() or there
> is something wrong in dwc2 with sg and this driver will not
> work with urb_sg_init() as well. I don't have hardware to investigate
> this and don't want to bother you with more patches.
I think the conditions for skipping the alloc of the DMA aligned buffer
in dwc2 are a bit quirky:
if (urb->num_sgs || urb->sg ||
urb->transfer_buffer_length == 0 ||
!((uintptr_t)urb->transfer_buffer & (DWC2_USB_DMA_ALIGN - 1)))
return 0;
It would probably make more sense to write:
if ((urb->num_sgs && urb->sg &&
urb->transfer_buffer_length == 0) ||
!((uintptr_t)urb->transfer_buffer & (DWC2_USB_DMA_ALIGN - 1)))
return 0;
It would still need some extra code for the urb->num_sgs==1 case though.
That code was originally written for the nvidia tegra host controller
driver and copied to dwc2. Maybe at the time they just didn't want to
write extra code dealing with urb->sg because nobody was using it for
single-buffer transfers, or they didn't have a test case.
Either way, while it might be a good idea to improve dwc2 and tegra, I
still think avoiding the use of urb->sg in single buffer cases is a good
idea. One advantage is that less memory needs to be allocated.
- Felix
^ permalink raw reply
* [PATCH] ath10k: change 'unsigned long int' to 'unsigned long'
From: Kalle Valo @ 2019-02-19 12:11 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
Fixes checkpatch warnings:
Prefer 'unsigned long' over 'unsigned long int' as the int is unnecessary
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/core.h | 16 ++++++++--------
drivers/net/wireless/ath/ath10k/debug.h | 20 ++++++++++----------
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 10 +++++-----
drivers/net/wireless/ath/ath10k/htt_rx.c | 16 ++++++++--------
drivers/net/wireless/ath/ath10k/snoc.h | 2 +-
5 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 2f43600717ec..482e60221ccb 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -448,14 +448,14 @@ enum ath10k_amsdu_subfrm_num {
};
struct ath10k_sta_tid_stats {
- unsigned long int rx_pkt_from_fw;
- unsigned long int rx_pkt_unchained;
- unsigned long int rx_pkt_drop_chained;
- unsigned long int rx_pkt_drop_filter;
- unsigned long int rx_pkt_err[ATH10K_PKT_RX_ERR_MAX];
- unsigned long int rx_pkt_queued_for_mac;
- unsigned long int rx_pkt_ampdu[ATH10K_AMPDU_SUBFRM_NUM_MAX];
- unsigned long int rx_pkt_amsdu[ATH10K_AMSDU_SUBFRM_NUM_MAX];
+ unsigned long rx_pkt_from_fw;
+ unsigned long rx_pkt_unchained;
+ unsigned long rx_pkt_drop_chained;
+ unsigned long rx_pkt_drop_filter;
+ unsigned long rx_pkt_err[ATH10K_PKT_RX_ERR_MAX];
+ unsigned long rx_pkt_queued_for_mac;
+ unsigned long rx_pkt_ampdu[ATH10K_AMPDU_SUBFRM_NUM_MAX];
+ unsigned long rx_pkt_amsdu[ATH10K_AMSDU_SUBFRM_NUM_MAX];
};
enum ath10k_counter_type {
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 5cf16d690724..eecafdbc873f 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -213,12 +213,12 @@ void ath10k_sta_add_debugfs(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
void ath10k_sta_update_rx_duration(struct ath10k *ar,
struct ath10k_fw_stats *stats);
void ath10k_sta_update_rx_tid_stats(struct ath10k *ar, u8 *first_hdr,
- unsigned long int num_msdus,
+ unsigned long num_msdus,
enum ath10k_pkt_rx_err err,
- unsigned long int unchain_cnt,
- unsigned long int drop_cnt,
- unsigned long int drop_cnt_filter,
- unsigned long int queued_msdus);
+ unsigned long unchain_cnt,
+ unsigned long drop_cnt,
+ unsigned long drop_cnt_filter,
+ unsigned long queued_msdus);
void ath10k_sta_update_rx_tid_stats_ampdu(struct ath10k *ar,
u16 peer_id, u8 tid,
struct htt_rx_indication_mpdu_range *ranges,
@@ -232,12 +232,12 @@ void ath10k_sta_update_rx_duration(struct ath10k *ar,
static inline
void ath10k_sta_update_rx_tid_stats(struct ath10k *ar, u8 *first_hdr,
- unsigned long int num_msdus,
+ unsigned long num_msdus,
enum ath10k_pkt_rx_err err,
- unsigned long int unchain_cnt,
- unsigned long int drop_cnt,
- unsigned long int drop_cnt_filter,
- unsigned long int queued_msdus)
+ unsigned long unchain_cnt,
+ unsigned long drop_cnt,
+ unsigned long drop_cnt_filter,
+ unsigned long queued_msdus)
{
}
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 4778a455d81a..ab49793353f4 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -87,12 +87,12 @@ void ath10k_sta_update_rx_tid_stats_ampdu(struct ath10k *ar, u16 peer_id, u8 tid
}
void ath10k_sta_update_rx_tid_stats(struct ath10k *ar, u8 *first_hdr,
- unsigned long int num_msdus,
+ unsigned long num_msdus,
enum ath10k_pkt_rx_err err,
- unsigned long int unchain_cnt,
- unsigned long int drop_cnt,
- unsigned long int drop_cnt_filter,
- unsigned long int queued_msdus)
+ unsigned long unchain_cnt,
+ unsigned long drop_cnt,
+ unsigned long drop_cnt_filter,
+ unsigned long queued_msdus)
{
struct ieee80211_sta *sta;
struct ath10k_sta *arsta;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index d5c666c2504c..1afaa107024a 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1905,7 +1905,7 @@ static void ath10k_htt_rx_h_enqueue(struct ath10k *ar,
}
static int ath10k_unchain_msdu(struct sk_buff_head *amsdu,
- unsigned long int *unchain_cnt)
+ unsigned long *unchain_cnt)
{
struct sk_buff *skb, *first;
int space;
@@ -1954,8 +1954,8 @@ static int ath10k_unchain_msdu(struct sk_buff_head *amsdu,
static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
struct sk_buff_head *amsdu,
- unsigned long int *drop_cnt,
- unsigned long int *unchain_cnt)
+ unsigned long *drop_cnt,
+ unsigned long *unchain_cnt)
{
struct sk_buff *first;
struct htt_rx_desc *rxd;
@@ -2005,7 +2005,7 @@ static bool ath10k_htt_rx_amsdu_allowed(struct ath10k *ar,
static void ath10k_htt_rx_h_filter(struct ath10k *ar,
struct sk_buff_head *amsdu,
struct ieee80211_rx_status *rx_status,
- unsigned long int *drop_cnt)
+ unsigned long *drop_cnt)
{
if (skb_queue_empty(amsdu))
return;
@@ -2025,10 +2025,10 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
struct ieee80211_rx_status *rx_status = &htt->rx_status;
struct sk_buff_head amsdu;
int ret;
- unsigned long int drop_cnt = 0;
- unsigned long int unchain_cnt = 0;
- unsigned long int drop_cnt_filter = 0;
- unsigned long int msdus_to_queue, num_msdus;
+ unsigned long drop_cnt = 0;
+ unsigned long unchain_cnt = 0;
+ unsigned long drop_cnt_filter = 0;
+ unsigned long msdus_to_queue, num_msdus;
enum ath10k_pkt_rx_err err = ATH10K_PKT_RX_ERR_MAX;
u8 first_hdr[RX_HTT_HDR_STATUS_LEN];
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
index 2b2f23cf7c5d..4e256ae4b3ff 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -90,7 +90,7 @@ struct ath10k_snoc {
struct ath10k_vreg_info *vreg;
struct ath10k_clk_info *clk;
struct ath10k_qmi *qmi;
- unsigned long int flags;
+ unsigned long flags;
};
static inline struct ath10k_snoc *ath10k_snoc_priv(struct ath10k *ar)
--
2.7.4
^ permalink raw reply related
* Re: [kbuild] [PATCH] brcmfmac: use bphy_err() in all wiphy-related code
From: Dan Carpenter @ 2019-02-19 11:28 UTC (permalink / raw)
To: Kalle Valo, kbuild, kbuild-all
Cc: Arend van Spriel, Rafał Miłecki, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki,
brcm80211-dev-list
In-Reply-To: <20190215103803.GF2304@kadam>
On Fri, Feb 15, 2019 at 01:38:03PM +0300, Dan Carpenter wrote:
> On Fri, Feb 15, 2019 at 12:04:31PM +0200, Kalle Valo wrote:
> > > 3e0a97e1 drivers/net/wireless/brcm80211/brcmfmac/fweh.c Arend van
> > > Spriel 2012-11-14 108 void *data)
> > > 3e0a97e1 drivers/net/wireless/brcm80211/brcmfmac/fweh.c Arend van
> >
> > This report is very hard to read as the lines seem to be wrapped.
> >
>
> I feel like removing the filenames would make the reports more legible.
> We can get that information from the git hash if we really need it.
>
> Maybe just put the filename at the start:
>
> drivers/net/wireless/brcm80211/brcmfmac/fweh.c
> 5c36b99a Arend van Spriel 2012-11-14 104
> 3e0a97e1 Arend van Spriel 2012-11-14 105 static int brcmf_fweh_call_event_handler(struct brcmf_if *ifp,
These emails are actually from the Intel zero day devs. I just hit
forward on them. They have silently implemented the formatting changes
we asked for.
:)
Thanks so much!
regards,
dan carpenter
^ permalink raw reply
* Re: MT76x2U crashes XHCI driver on AMD Ryzen system
From: Stanislaw Gruszka @ 2019-02-19 11:08 UTC (permalink / raw)
To: Robin Murphy
Cc: Lorenzo Bianconi, Samuel Sieb, linux-wireless, linux-kernel,
iommu, Rosen Penev, Alexander Duyck
In-Reply-To: <2cc5674a-a3a0-d8fe-65f5-4357da9b85d3@arm.com>
On Mon, Feb 18, 2019 at 05:01:59PM +0000, Robin Murphy wrote:
> On 18/02/2019 14:37, Stanislaw Gruszka wrote:
> [...]
> >Another issue is that dma_map_sg() & dma_map_page() may require some
> >constraints. I'm not sure about that and I want to clarify that with
> >CCed mm maintainers. I think DMA drivers may expect sg->offset < PAGE_SIZE
> >for both dma_map_sg() and dma_map_page(). Additionally dma_map_page()
> >maight expect that offset & length specify buffer within one page.
>
> Luckily, this came up a while back[1] and we seemed to reach a
> consensus that sg->offset >= PAGE_SIZE for dma_map_sg() was weird
> but valid. IIRC it was only the Intel IOMMU code which failed to
> handle that case appropriately (and which I fixed) - the AMD IOMMU
> code always looked like it should be OK, but I'm not sure I've ever
> seen definitive test results (and I don't have hardware to do so
> myself).
Funny that we have problems on AMD IOMMU and not with Intel IOMMU.
> For dma_map_page(), length >= PAGE_SIZE should be perfectly valid
> and handled correctly. The offset >= PAGE_SIZE case is a bit harder
> to justify, but at the same time has less scope for the DMA API
> backend to get it wrong, so either way is likely to be OK in
> practice (in particular the AMD IOMMU code looks like it won't have
> a problem, since its map_page() implementation converts page and
> offset to a plain physical address before doing anything else).
Thanks for clarify this. So my patch which do:
- page = virt_to_head_page(data);
+ page = virt_to_page(data);
offset = data - page_address(page);
sg_set_page(&urb->sg[i], page, sglen, offset);
should not be necessary as IOMMU driver do exactly the same internally.
Are there any alignment requirement for offset for dma_map_{page,sg} ?
It will work with let say sg->offset=113 or we have make sure it is
aligned to some boundary. If so, what boundary ?
Stanislaw
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stanislaw Gruszka @ 2019-02-19 10:59 UTC (permalink / raw)
To: Stefan Wahren
Cc: Lorenzo Bianconi, Alan Stern, Felix Fietkau, Doug Anderson,
Minas Harutyunyan, USB list, linux-wireless
In-Reply-To: <1181760295.588129.1550528380134@email.ionos.de>
On Mon, Feb 18, 2019 at 11:19:40PM +0100, Stefan Wahren wrote:
> Hi,
>
> > Stanislaw Gruszka <sgruszka@redhat.com> hat am 18. Februar 2019 um 14:52 geschrieben:
> >
> >
> > On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
> > > this is a misunderstanding. The warning is about memory alignment to 32 bit addresses, not about page alignment. This is a typical ARM restriction. Maybe we need to make sure in mt76 that the DMA buffer needs to be aligned. But it's also possible that the warning isn't the root cause of our problem.
> > >
> >
> > I see, it needs 4 bytes alignment . There is already dwc2 code checks
> > that and allocate new buffer if the alignment is not right:
> > dwc2_alloc_dma_aligned_buffer(), but it does nothing if urb->sg
> > is not NULL. I thought mt76usb already provide aligned buffers, but
> > looks it does not for one TX special case, which are PROBE REQUEST
> > frames. Other frames are aligned by inserting L2 header pad. One
> > solution for this would be just submit urb with NULL sg (same as
> > Lorenzo's patches do, but still allocating buffers via buf->sg),
> > but I think, you have right, we should provide 4 bytes aligned buffers
> > by default as other DMA hardware may require that. I'm attaching yet
> > another patch to test, which fix up alignment for PROBE REQUEST frames.
> >
> > > > Attached patch should fix this, plese test, thanks in advance.
>
> i saw Felix decided to use Lorenzo's approach.
>
> The patches 1,3,5 applied on today's next fixed only the warning and wifi is still broken (authentication timeout).
>
> Here are the logs for multi_v7_defconfig:
> https://gist.github.com/lategoodbye/0a7c5cea7dbf25d0de7944c05d229d79
It would be interesting why urb->num_sgs = 0 & urb->sg cause
the troubles. This is how usb_sg_init() submit urbs for sg_tablesize = 0
controllers. So either are there are some requirement on urb->sg
mapped via dma_map_page() (which mt76usb does not meet) not needed
for urb->transfer_buffer mapped via dma_map_single() or there
is something wrong in dwc2 with sg and this driver will not
work with urb_sg_init() as well. I don't have hardware to investigate
this and don't want to bother you with more patches.
> > > Anyway i tested the following patch combinations against next with the same results as 1,2,3 (no wifi, alignment warning):
> > > 1,3
> > > 1,2,3,4
> >
> > I noticed on my setup that patch 4 can cause troubles, but still
> > device is workable here on my PC machines.
> >
> > > > > Btw i can confirm a regression was introduced after 4.19, because in 4.19 there was no firmware timeout but even no working wifi:
> > > >
> > > > You ment 'no working wifi' or 'working wifi'?
> > >
> > > Wifi is broken in 4.19, 4.20, 5.0 and next. It only worked with Lorenzo's SG avoid patches so far. Btw the regression (firmware timeout) started in 4.20. I also tested it today.
> >
> > That somewhat strange because 4.19 mt76x0u does not use SG.
> > On 4.19 there is phy calibration bug fixed in 4.19.5:
>
> Sorry for being inprecise. I was talking about the branches not the exact tags. I tested 4.19.23 without luck.
In github link you provided someone report mt76x0u working on 4.19 with
dwc_otg with disabled FIQ irq, so perhaps this is due to bug in dwc2
fixed in -next but not backported to 4.19.
> Many thanks anyway
Thanks for testing!
Stanislaw
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stanislaw Gruszka @ 2019-02-19 10:42 UTC (permalink / raw)
To: Felix Fietkau
Cc: Stefan Wahren, Lorenzo Bianconi, Alan Stern, Doug Anderson,
Minas Harutyunyan, USB list, linux-wireless
In-Reply-To: <a035966b-99f8-1109-d96f-0c3862d26518@nbd.name>
On Mon, Feb 18, 2019 at 07:52:27PM +0100, Felix Fietkau wrote:
> On 2019-02-18 16:03, Stanislaw Gruszka wrote:
> > On Mon, Feb 18, 2019 at 03:43:26PM +0100, Felix Fietkau wrote:
> >> On 2019-02-18 14:52, Stanislaw Gruszka wrote:
> >> > On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
> >> >> this is a misunderstanding. The warning is about memory alignment to 32 bit addresses, not about page alignment. This is a typical ARM restriction. Maybe we need to make sure in mt76 that the DMA buffer needs to be aligned. But it's also possible that the warning isn't the root cause of our problem.
> >> >>
> >> >
> >> > I see, it needs 4 bytes alignment . There is already dwc2 code checks
> >> > that and allocate new buffer if the alignment is not right:
> >> > dwc2_alloc_dma_aligned_buffer(), but it does nothing if urb->sg
> >> > is not NULL. I thought mt76usb already provide aligned buffers, but
> >> > looks it does not for one TX special case, which are PROBE REQUEST
> >> > frames. Other frames are aligned by inserting L2 header pad. One
> >> > solution for this would be just submit urb with NULL sg (same as
> >> > Lorenzo's patches do, but still allocating buffers via buf->sg),
> >> > but I think, you have right, we should provide 4 bytes aligned buffers
> >> > by default as other DMA hardware may require that. I'm attaching yet
> >> > another patch to test, which fix up alignment for PROBE REQUEST frames.
> >> This approach looks completely wrong to me. MMIO based hardware does not
> >> need 4-byte aligned buffers at all, other USB controllers do not need
> >> this either.
> >> As Lorenzo already pointed out, re-aligning the buffer is *very*
> >> expensive, so we should not do this in the driver just to work around
> >> quirks in a particular USB host driver.
> >
> > I decided to this patch because I thought some other USB & MMIO DMA
> > platforms might also require this alignment. But it was never triggered
> > in MMIO because on those mt76 is used in AP mode, hence no PROBE
> > REQUEST frames (and scan can be passive on STA mode).
> mt76 is regularly used and tested in STA and Mesh mode as well.
> No DMA alignment related issues there.
The question is why we need to do 2 bytes header pad ? Is this because
ieee802.11 header length for mt76 hardware has to be multiple of 4 or
it has to be aligned to 4 bytes? It would be strange if length has
to be fixed to 4 bytes and alignment not. However this could be
needed on some platforms and not on others.
> >> The way I see it, we have two choices.
> >> 1. Fix dwc2 to do its alignment quirk for the urb->sg != NULL case
> >> 2. Rely on urb->transfer_buffer and keep urb->sg NULL
> >
> > I agree, if this is only needed for dwc2. Though I would investigate
> > if this is not a bug on other platforms as well.
> >From what I can see, using Lorenzo's patches seems to be the better
> solution, since they avoid these corner cases in dwc2 (and maybe other
> drivers as well). I will apply them and then we'll see if we need to do
> any further improvements later on.
They work on rpi dwc2, but they do not address root of the problem.
There is clearly something wrong how mt76usb handle SG, what is not
fixed. And adding disable_usb_sg module parameter for hcd's supporting
SG should be red flag.
Stanislaw
^ permalink raw reply
* [PATCH] ath10k: update the max num of peers supported for WCN3990
From: Abhishek Ambure @ 2019-02-19 10:01 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Abhishek Ambure
WCN3990 firmware versions WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1 & onwards
supports maximum 33 peers including self peer. To support maximum peers,
send updated peer param to firmware during initialization.
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Signed-off-by: Abhishek Ambure <aambure@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/core.c | 6 +++---
drivers/net/wireless/ath/ath10k/hw.h | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index a1b2aea..336c6a4 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -560,10 +560,10 @@
.sw_decrypt_mcast_mgmt = true,
.hw_ops = &wcn3990_ops,
.decap_align_bytes = 1,
- .num_peers = TARGET_HL_10_TLV_NUM_PEERS,
+ .num_peers = TARGET_HL_TLV_NUM_PEERS,
.n_cipher_suites = 11,
- .ast_skid_limit = TARGET_HL_10_TLV_AST_SKID_LIMIT,
- .num_wds_entries = TARGET_HL_10_TLV_NUM_WDS_ENTRIES,
+ .ast_skid_limit = TARGET_HL_TLV_AST_SKID_LIMIT,
+ .num_wds_entries = TARGET_HL_TLV_NUM_WDS_ENTRIES,
.target_64bit = true,
.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL_DUAL_MAC,
.per_ce_irq = true,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index fe6b2ed..67413ae 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -763,9 +763,9 @@ struct ath10k_hw_ops {
#define TARGET_TLV_MGMT_NUM_MSDU_DESC (50)
/* Target specific defines for WMI-HL-1.0 firmware */
-#define TARGET_HL_10_TLV_NUM_PEERS 14
-#define TARGET_HL_10_TLV_AST_SKID_LIMIT 6
-#define TARGET_HL_10_TLV_NUM_WDS_ENTRIES 2
+#define TARGET_HL_TLV_NUM_PEERS 33
+#define TARGET_HL_TLV_AST_SKID_LIMIT 16
+#define TARGET_HL_TLV_NUM_WDS_ENTRIES 2
/* Diagnostic Window */
#define CE_DIAG_PIPE 7
--
1.9.1
^ permalink raw reply related
* [PATCH] ath10k: Fill rx duration for each peer in fw_stats for WCN3990
From: Surabhi Vishnoi @ 2019-02-19 9:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Surabhi Vishnoi
Currently, rx_duration for each peer is not getting populated in
fw_stats debugfs entry for WCN3990.
WCN3990 firmware sends rx duration for each peer as part of
peer_extd_stats in WMI_UPDATE_STATS_EVENT. To enable peer_extd_stats,
firmware expects host to send fw_stats_req_mask with flag
WMI_TLV_PEER_STATS_EXTD set in WMI_REQUEST_STATS_CMD.
Send fw_stats_req_mask with flag WMI_TLV_PEER_STATS_EXTD set in
WMI_REQUEST_STATS_CMD and parse the peer_extd_stats in
WMI_UPDATE_STATS_EVENT to populate the rx_duration of each peer
in fw_stats debugfs entry.
Currently the driver handles 32-bit rx_duration, but the rx_duration
for WCN3990 can be upto 63 bit. The firmware sends rx_duration split
into two 32-bit fields, with the upper 32-bits being valid only if its
MSB is set. This change handles the 63-bit rx_duration obtained from
WCN3990 and maintain the backward compatibility.
To get the rx_duration of each connected peer :
cat /sys/kernel/debug/ieee80211/phyX/ath10k/fw_stats
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/core.c | 4 ++--
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 31 +++++++++++++++++++++++++++++--
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 20 ++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.h | 7 +++++++
6 files changed, 60 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index a1b2aea..5ff9cf4 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2315,8 +2315,8 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
else
ar->htt.max_num_pending_tx = TARGET_TLV_NUM_MSDU_DESC;
ar->wow.max_num_patterns = TARGET_TLV_NUM_WOW_PATTERNS;
- ar->fw_stats_req_mask = WMI_STAT_PDEV | WMI_STAT_VDEV |
- WMI_STAT_PEER;
+ ar->fw_stats_req_mask = WMI_TLV_STAT_PDEV | WMI_TLV_STAT_VDEV |
+ WMI_TLV_STAT_PEER | WMI_TLV_STAT_PEER_EXTD;
ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
ar->wmi.mgmt_max_num_pending_tx = TARGET_TLV_MGMT_NUM_MSDU_DESC;
break;
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 2f43600..e786ce0 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -200,7 +200,7 @@ struct ath10k_fw_stats_peer {
u32 peer_rssi;
u32 peer_tx_rate;
u32 peer_rx_rate; /* 10x only */
- u32 rx_duration;
+ u64 rx_duration;
};
struct ath10k_fw_extd_stats_peer {
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 84de6ec..80c35ad 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -24,6 +24,7 @@
#include "wmi-tlv.h"
#include "p2p.h"
#include "testmode.h"
+#include <linux/bitfield.h>
/***************/
/* TLV helpers */
@@ -1289,6 +1290,7 @@ static int ath10k_wmi_tlv_op_pull_fw_stats(struct ath10k *ar,
{
const void **tb;
const struct wmi_tlv_stats_ev *ev;
+ u32 num_peer_stats_extd;
const void *data;
u32 num_pdev_stats;
u32 num_vdev_stats;
@@ -1296,6 +1298,7 @@ static int ath10k_wmi_tlv_op_pull_fw_stats(struct ath10k *ar,
u32 num_bcnflt_stats;
u32 num_chan_stats;
size_t data_len;
+ u32 stats_id;
int ret;
int i;
@@ -1320,11 +1323,13 @@ static int ath10k_wmi_tlv_op_pull_fw_stats(struct ath10k *ar,
num_peer_stats = __le32_to_cpu(ev->num_peer_stats);
num_bcnflt_stats = __le32_to_cpu(ev->num_bcnflt_stats);
num_chan_stats = __le32_to_cpu(ev->num_chan_stats);
+ stats_id = __le32_to_cpu(ev->stats_id);
+ num_peer_stats_extd = __le32_to_cpu(ev->num_peer_stats_extd);
ath10k_dbg(ar, ATH10K_DBG_WMI,
- "wmi tlv stats update pdev %i vdev %i peer %i bcnflt %i chan %i\n",
+ "wmi tlv stats update pdev %i vdev %i peer %i bcnflt %i chan %i peer_extd %i\n",
num_pdev_stats, num_vdev_stats, num_peer_stats,
- num_bcnflt_stats, num_chan_stats);
+ num_bcnflt_stats, num_chan_stats, num_peer_stats_extd);
for (i = 0; i < num_pdev_stats; i++) {
const struct wmi_pdev_stats *src;
@@ -1389,6 +1394,28 @@ static int ath10k_wmi_tlv_op_pull_fw_stats(struct ath10k *ar,
ath10k_wmi_pull_peer_stats(&src->old, dst);
dst->peer_rx_rate = __le32_to_cpu(src->peer_rx_rate);
+
+ if (stats_id & WMI_TLV_STAT_PEER_EXTD) {
+ const struct wmi_tlv_peer_stats_extd *extd;
+ unsigned long rx_duration_high;
+
+ extd = data + sizeof(*src) * (num_peer_stats - i - 1)
+ + sizeof(*extd) * i;
+
+ dst->rx_duration = __le32_to_cpu(extd->rx_duration);
+ rx_duration_high = __le32_to_cpu
+ (extd->rx_duration_high);
+
+ if (test_bit(WMI_TLV_PEER_RX_DURATION_HIGH_VALID_BIT,
+ &rx_duration_high)) {
+ rx_duration_high =
+ FIELD_GET(WMI_TLV_PEER_RX_DURATION_HIGH_MASK,
+ rx_duration_high);
+ dst->rx_duration |= rx_duration_high <<
+ WMI_TLV_PEER_RX_DURATION_SHIFT;
+ }
+ }
+
list_add_tail(&dst->list, &stats->peers);
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index 4fba581..3165d95 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -1875,6 +1875,22 @@ struct wmi_tlv_req_stats_cmd {
struct wmi_mac_addr peer_macaddr;
} __packed;
+#define WMI_TLV_PEER_RX_DURATION_HIGH_VALID_BIT 31
+#define WMI_TLV_PEER_RX_DURATION_HIGH_MASK GENMASK(30, 0)
+#define WMI_TLV_PEER_RX_DURATION_SHIFT 32
+
+struct wmi_tlv_peer_stats_extd {
+ struct wmi_mac_addr peer_macaddr;
+ __le32 rx_duration;
+ __le32 peer_tx_bytes;
+ __le32 peer_rx_bytes;
+ __le32 last_tx_rate_code;
+ __le32 last_tx_power;
+ __le32 rx_mc_bc_cnt;
+ __le32 rx_duration_high;
+ __le32 reserved[2];
+} __packed;
+
struct wmi_tlv_vdev_stats {
__le32 vdev_id;
__le32 beacon_snr;
@@ -1968,6 +1984,10 @@ struct wmi_tlv_stats_ev {
__le32 num_peer_stats;
__le32 num_bcnflt_stats;
__le32 num_chan_stats;
+ __le32 num_mib_stats;
+ __le32 pdev_id;
+ __le32 num_bcn_stats;
+ __le32 num_peer_stats_extd;
} __packed;
struct wmi_tlv_p2p_noa_ev {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 704c71b..1c51341 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -8315,7 +8315,7 @@ size_t ath10k_wmi_fw_stats_num_vdevs(struct list_head *head)
"Peer TX rate", peer->peer_tx_rate);
len += scnprintf(buf + len, buf_len - len, "%30s %u\n",
"Peer RX rate", peer->peer_rx_rate);
- len += scnprintf(buf + len, buf_len - len, "%30s %u\n",
+ len += scnprintf(buf + len, buf_len - len, "%30s %llu\n",
"Peer RX duration", peer->rx_duration);
len += scnprintf(buf + len, buf_len - len, "\n");
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 0e27878..b3aa696 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4545,6 +4545,13 @@ enum wmi_10_4_stats_id {
WMI_10_4_STAT_VDEV_EXTD = BIT(4),
};
+enum wmi_tlv_stats_id {
+ WMI_TLV_STAT_PDEV = BIT(0),
+ WMI_TLV_STAT_VDEV = BIT(1),
+ WMI_TLV_STAT_PEER = BIT(2),
+ WMI_TLV_STAT_PEER_EXTD = BIT(10),
+};
+
struct wlan_inst_rssi_args {
__le16 cfg_retry_count;
__le16 retry_count;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] brcmfmac: remove set but not used variable 'old_state'
From: Arend Van Spriel @ 2019-02-19 9:23 UTC (permalink / raw)
To: YueHaibing, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo
Cc: linux-wireless, netdev, brcm80211-dev-list.pdl,
brcm80211-dev-list, kernel-janitors
In-Reply-To: <20190218080846.187942-1-yuehaibing@huawei.com>
On 2/18/2019 9:08 AM, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 'brcmf_usb_state_change':
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:578:6: warning:
> variable 'old_state' set but not used [-Wunused-but-set-variable]
>
> It's never used and can be removed.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 2 --
> 1 file changed, 2 deletions(-)
^ permalink raw reply
* [PATCH] ath10k: Add peer param map for tlv and non-tlv
From: Rakesh Pillai @ 2019-02-19 6:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Rakesh Pillai
The peer param id for PEER_PARAM_USE_FIXED_PWR
is different for tlv and non-tlv firmware. This
causes incorrect peer param to be set by the driver
to the firmware(tlv/non-tlv).
Create seperate peer param map for tlv and non-tlv
firmware and attach the peer param id based on the
firmware type during the init.
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
---
This change is dependent on the below patchset
ath10k: add support for controlling tx power to a station (https://patchwork.kernel.org/patch/9562405/)
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 16 ++++++++--------
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 19 +++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 18 ++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 18 ++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 19 +++++++++++++++++++
7 files changed, 84 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 2f43600..5be2d5d 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -180,6 +180,7 @@ struct ath10k_wmi {
struct wmi_cmd_map *cmd;
struct wmi_vdev_param_map *vdev_param;
struct wmi_pdev_param_map *pdev_param;
+ struct wmi_peer_param_map *peer_param;
const struct wmi_ops *ops;
const struct wmi_peer_flags_map *peer_flags;
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 4778a45..a887f71 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -441,7 +441,7 @@ ath10k_dbg_sta_write_peer_debug_trigger(struct file *file,
}
ret = ath10k_wmi_peer_set_param(ar, arsta->arvif->vdev_id, sta->addr,
- WMI_PEER_DEBUG, peer_debug_trigger);
+ ar->wmi.peer_param->debug, peer_debug_trigger);
if (ret) {
ath10k_warn(ar, "failed to set param to trigger peer tid logs for station ret: %d\n",
ret);
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index bce2698..dece2b0 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2744,7 +2744,7 @@ static int ath10k_setup_peer_smps(struct ath10k *ar, struct ath10k_vif *arvif,
return -EINVAL;
return ath10k_wmi_peer_set_param(ar, arvif->vdev_id, addr,
- WMI_PEER_SMPS_STATE,
+ ar->wmi.peer_param->smps_state,
ath10k_smps_map[smps]);
}
@@ -2901,7 +2901,7 @@ static void ath10k_bss_assoc(struct ieee80211_hw *hw,
* poked with peer param command.
*/
ret = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, arvif->bssid,
- WMI_PEER_DUMMY_VAR, 1);
+ ar->wmi.peer_param->dummy_var, 1);
if (ret) {
ath10k_warn(ar, "failed to poke peer %pM param for ps workaround on vdev %i: %d\n",
arvif->bssid, arvif->vdev_id, ret);
@@ -6189,7 +6189,7 @@ static int ath10k_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
if (sta && sta->tdls)
ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
- WMI_PEER_AUTHORIZE, 1);
+ ar->wmi.peer_param->authorize, 1);
exit:
mutex_unlock(&ar->conf_mutex);
@@ -6280,7 +6280,7 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
sta->addr, bw, mode);
err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
- WMI_PEER_PHYMODE, mode);
+ ar->wmi.peer_param->phymode, mode);
if (err) {
ath10k_warn(ar, "failed to update STA %pM peer phymode %d: %d\n",
sta->addr, mode, err);
@@ -6288,7 +6288,7 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
}
err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
- WMI_PEER_CHAN_WIDTH, bw);
+ ar->wmi.peer_param->chan_width, bw);
if (err)
ath10k_warn(ar, "failed to update STA %pM peer bw %d: %d\n",
sta->addr, bw, err);
@@ -6299,7 +6299,7 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
sta->addr, nss);
err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
- WMI_PEER_NSS, nss);
+ ar->wmi.peer_param->nss, nss);
if (err)
ath10k_warn(ar, "failed to update STA %pM nss %d: %d\n",
sta->addr, nss, err);
@@ -6310,7 +6310,7 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
sta->addr, smps);
err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
- WMI_PEER_SMPS_STATE, smps);
+ ar->wmi.peer_param->smps_state, smps);
if (err)
ath10k_warn(ar, "failed to update STA %pM smps %d: %d\n",
sta->addr, smps, err);
@@ -6384,7 +6384,7 @@ static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
mutex_lock(&ar->conf_mutex);
ret = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
- WMI_PEER_USE_FIXED_PWR, txpwr);
+ ar->wmi.peer_param->use_fixed_power, txpwr);
if (ret) {
ath10k_warn(ar, "failed to set tx power for station ret: %d\n",
ret);
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 5d05bff..13f9084 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -4077,6 +4077,24 @@ static struct wmi_pdev_param_map wmi_tlv_pdev_param_map = {
.arp_dstaddr = WMI_PDEV_PARAM_UNSUPPORTED,
};
+static struct wmi_peer_param_map wmi_tlv_peer_param_map = {
+ .smps_state = WMI_TLV_PEER_SMPS_STATE,
+ .ampdu = WMI_TLV_PEER_AMPDU,
+ .authorize = WMI_TLV_PEER_AUTHORIZE,
+ .chan_width = WMI_TLV_PEER_CHAN_WIDTH,
+ .nss = WMI_TLV_PEER_NSS,
+ .use_4addr = WMI_TLV_PEER_USE_4ADDR,
+ .membership = WMI_TLV_PEER_MEMBERSHIP,
+ .user_pos = WMI_TLV_PEER_USERPOS,
+ .crit_proto_hint_enabled = WMI_TLV_PEER_CRIT_PROTO_HINT_ENABLED,
+ .tx_fail_cnt_thr = WMI_TLV_PEER_TX_FAIL_CNT_THR,
+ .set_hw_retry_cts2s = WMI_TLV_PEER_SET_HW_RETRY_CTS2S,
+ .ibss_atim_win_len = WMI_TLV_PEER_IBSS_ATIM_WINDOW_LENGTH,
+ .phymode = WMI_TLV_PEER_PHYMODE,
+ .use_fixed_power = WMI_TLV_PEER_USE_FIXED_PWR,
+ .dummy_var = WMI_TLV_PEER_DUMMY_VAR,
+};
+
static struct wmi_vdev_param_map wmi_tlv_vdev_param_map = {
.rts_threshold = WMI_TLV_VDEV_PARAM_RTS_THRESHOLD,
.fragmentation_threshold = WMI_TLV_VDEV_PARAM_FRAGMENTATION_THRESHOLD,
@@ -4265,6 +4283,7 @@ void ath10k_wmi_tlv_attach(struct ath10k *ar)
ar->wmi.cmd = &wmi_tlv_cmd_map;
ar->wmi.vdev_param = &wmi_tlv_vdev_param_map;
ar->wmi.pdev_param = &wmi_tlv_pdev_param_map;
+ ar->wmi.peer_param = &wmi_tlv_peer_param_map;
ar->wmi.ops = &wmi_tlv_ops;
ar->wmi.peer_flags = &wmi_tlv_peer_flags_map;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index 4fba581..8d50808 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -533,6 +533,24 @@ enum wmi_tlv_vdev_param {
WMI_TLV_VDEV_PARAM_IBSS_PS_1RX_CHAIN_IN_ATIM_WINDOW_ENABLE,
};
+enum wmi_tlv_peer_param {
+ WMI_TLV_PEER_SMPS_STATE = 0x1, /* see %wmi_peer_smps_state */
+ WMI_TLV_PEER_AMPDU = 0x2,
+ WMI_TLV_PEER_AUTHORIZE = 0x3,
+ WMI_TLV_PEER_CHAN_WIDTH = 0x4,
+ WMI_TLV_PEER_NSS = 0x5,
+ WMI_TLV_PEER_USE_4ADDR = 0x6,
+ WMI_TLV_PEER_MEMBERSHIP = 0x7,
+ WMI_TLV_PEER_USERPOS = 0x8,
+ WMI_TLV_PEER_CRIT_PROTO_HINT_ENABLED = 0x9,
+ WMI_TLV_PEER_TX_FAIL_CNT_THR = 0xa,
+ WMI_TLV_PEER_SET_HW_RETRY_CTS2S = 0xb,
+ WMI_TLV_PEER_IBSS_ATIM_WINDOW_LENGTH = 0xc,
+ WMI_TLV_PEER_PHYMODE = 0xd,
+ WMI_TLV_PEER_USE_FIXED_PWR = 0xe,
+ WMI_TLV_PEER_DUMMY_VAR = 0xff,
+};
+
enum wmi_tlv_peer_flags {
WMI_TLV_PEER_AUTH = 0x00000001,
WMI_TLV_PEER_QOS = 0x00000002,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 704c71b..35f9f90 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -753,6 +753,19 @@ static struct wmi_cmd_map wmi_10_4_cmd_map = {
.radar_found_cmdid = WMI_10_4_RADAR_FOUND_CMDID,
};
+static struct wmi_peer_param_map wmi_peer_param_map = {
+ .smps_state = WMI_PEER_SMPS_STATE,
+ .ampdu = WMI_PEER_AMPDU,
+ .authorize = WMI_PEER_AUTHORIZE,
+ .chan_width = WMI_PEER_CHAN_WIDTH,
+ .nss = WMI_PEER_NSS,
+ .use_4addr = WMI_PEER_USE_4ADDR,
+ .use_fixed_power = WMI_PEER_USE_FIXED_PWR,
+ .debug = WMI_PEER_DEBUG,
+ .phymode = WMI_PEER_PHYMODE,
+ .dummy_var = WMI_PEER_DUMMY_VAR,
+};
+
/* MAIN WMI VDEV param map */
static struct wmi_vdev_param_map wmi_vdev_param_map = {
.rts_threshold = WMI_VDEV_PARAM_RTS_THRESHOLD,
@@ -9300,6 +9313,7 @@ int ath10k_wmi_attach(struct ath10k *ar)
ar->wmi.cmd = &wmi_10_4_cmd_map;
ar->wmi.vdev_param = &wmi_10_4_vdev_param_map;
ar->wmi.pdev_param = &wmi_10_4_pdev_param_map;
+ ar->wmi.peer_param = &wmi_peer_param_map;
ar->wmi.peer_flags = &wmi_10_2_peer_flags_map;
ar->wmi_key_cipher = wmi_key_cipher_suites;
break;
@@ -9308,6 +9322,7 @@ int ath10k_wmi_attach(struct ath10k *ar)
ar->wmi.ops = &wmi_10_2_4_ops;
ar->wmi.vdev_param = &wmi_10_2_4_vdev_param_map;
ar->wmi.pdev_param = &wmi_10_2_4_pdev_param_map;
+ ar->wmi.peer_param = &wmi_peer_param_map;
ar->wmi.peer_flags = &wmi_10_2_peer_flags_map;
ar->wmi_key_cipher = wmi_key_cipher_suites;
break;
@@ -9316,6 +9331,7 @@ int ath10k_wmi_attach(struct ath10k *ar)
ar->wmi.ops = &wmi_10_2_ops;
ar->wmi.vdev_param = &wmi_10x_vdev_param_map;
ar->wmi.pdev_param = &wmi_10x_pdev_param_map;
+ ar->wmi.peer_param = &wmi_peer_param_map;
ar->wmi.peer_flags = &wmi_10_2_peer_flags_map;
ar->wmi_key_cipher = wmi_key_cipher_suites;
break;
@@ -9324,6 +9340,7 @@ int ath10k_wmi_attach(struct ath10k *ar)
ar->wmi.ops = &wmi_10_1_ops;
ar->wmi.vdev_param = &wmi_10x_vdev_param_map;
ar->wmi.pdev_param = &wmi_10x_pdev_param_map;
+ ar->wmi.peer_param = &wmi_peer_param_map;
ar->wmi.peer_flags = &wmi_10x_peer_flags_map;
ar->wmi_key_cipher = wmi_key_cipher_suites;
break;
@@ -9332,6 +9349,7 @@ int ath10k_wmi_attach(struct ath10k *ar)
ar->wmi.ops = &wmi_ops;
ar->wmi.vdev_param = &wmi_vdev_param_map;
ar->wmi.pdev_param = &wmi_pdev_param_map;
+ ar->wmi.peer_param = &wmi_peer_param_map;
ar->wmi.peer_flags = &wmi_peer_flags_map;
ar->wmi_key_cipher = wmi_key_cipher_suites;
break;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 9b5a7ec..23666ca 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -5083,6 +5083,25 @@ enum wmi_rate_preamble {
/* Value to disable fixed rate setting */
#define WMI_FIXED_RATE_NONE (0xff)
+struct wmi_peer_param_map {
+ u32 smps_state;
+ u32 ampdu;
+ u32 authorize;
+ u32 chan_width;
+ u32 nss;
+ u32 use_4addr;
+ u32 membership;
+ u32 use_fixed_power;
+ u32 user_pos;
+ u32 crit_proto_hint_enabled;
+ u32 tx_fail_cnt_thr;
+ u32 set_hw_retry_cts2s;
+ u32 ibss_atim_win_len;
+ u32 debug;
+ u32 phymode;
+ u32 dummy_var;
+};
+
struct wmi_vdev_param_map {
u32 rts_threshold;
u32 fragmentation_threshold;
--
2.7.4
^ permalink raw reply related
* [PATCH] mac80211_hwsim::: propagate genlmsg_reply return code
From: Li RongQing @ 2019-02-19 5:12 UTC (permalink / raw)
To: johannes, kvalo, linux-wireless
genlmsg_reply can fail, so propagate its return code
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 320edcac4699..6359053bd0c7 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3554,7 +3554,7 @@ static int hwsim_get_radio_nl(struct sk_buff *msg, struct genl_info *info)
goto out_err;
}
- genlmsg_reply(skb, info);
+ res = genlmsg_reply(skb, info);
break;
}
--
2.16.2
^ permalink raw reply related
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Kalle Valo @ 2019-02-19 4:06 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
X86 ML, linux-wireless, Christoph Hellwig, David S. Miller,
Networking, Linux Kernel Mailing List, Lorenzo Bianconi,
moderated list:ARM/Mediatek SoC support, linux-arm-kernel,
Felix Fietkau, Matthias Brugger
In-Reply-To: <CAK7LNAQMgFXw=rtpdPNZ=xpLw-SiwKGAgM__Owvqd1EhTCUntQ@mail.gmail.com>
Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> On Tue, Feb 19, 2019 at 4:38 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Kalle Valo <kvalo@codeaurora.org> writes:
>>
>> > Kalle Valo <kvalo@codeaurora.org> writes:
>> >
>> >> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
>> >>
>> >>> __sw_hweight8() is just internal implementation.
>> >>>
>> >>> Drivers should use the common API, hweight8().
>> >>>
>> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >>
>> >> Acked-by: Kalle Valo <kvalo@codeaurora.org>
>> >>
>> >>> This patch should go to x86 tree along with 2/2.
>> >>>
>> >>> Otherwise, all{yes,mod}config of x86 would be broken.
>> >>>
>> >>> This patch is trivial enough.
>> >>> I want ACK from the net/wireless maintainer
>> >>> so that this can go in via x86 tree.
>> >>
>> >> Sounds good to me, feel free to push via the x86 tree.
>> >
>> > Actually, can you wait a bit? Felix just reminded me that we have a
>> > similar patch pending from Ben Hutchings:
>> >
>> > https://patchwork.kernel.org/patch/10808203/
>> >
>> > And it seems there are two instances of __sw_hweight8, at least in my
>> > wireless-drivers-next tree:
>> >
>> > drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
>> > __sw_hweight8(dev->antenna_mask);
>> > drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
>> > __sw_hweight8(dev->antenna_mask);
>> >
>> > So we need to think what to do.
>>
>> I think the best would be that Felix applies Ben's patch to the wireless
>> tree and I'll push it to Linus during the next merge window (via
>> net-next). Simpler and less conflicts that way.
>>
>> So Masahiro, could you hold your x86 patch for a while until the mt76
>> patch will be in Linus' tree? That should not take more than two weeks,
>> I think.
>
> Sure.
> I will resend 2/2 later.
Great, thanks!
--
Kalle Valo
^ permalink raw reply
* Re: pull-request: wireless-drivers 2019-02-18
From: David Miller @ 2019-02-19 1:41 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87zhqtt98h.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 18 Feb 2019 17:19:26 +0200
> here's one more pull request to net tree for 5.0. Please let me know if
> you have any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH 2/2] x86: disable CONFIG_GENERIC_HWEIGHT and remove __HAVE_ARCH_SW_HWEIGHT
From: Masahiro Yamada @ 2019-02-19 1:16 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
X86 ML
Cc: Kalle Valo, linux-wireless, Christoph Hellwig,
Linux Kernel Mailing List
In-Reply-To: <1550469571-25933-3-git-send-email-yamada.masahiro@socionext.com>
On Mon, Feb 18, 2019 at 3:09 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> arch/x86/include/asm/arch_hweight.h uses __sw_hweight{32,64} as
> alternatives, but they are implemented in arch/x86/lib/hweight.S
>
> x86 does not rely on the generic C implementation lib/hweight.c
> at all, so CONFIG_GENERIC_HWEIGHT should be disabled.
>
> __HAVE_ARCH_SW_HWEIGHT was unneeded in the first place.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Maintainers,
As I replied to 1/2,
please ignore this for now.
I will resend this later,
hopefully in the next development cycle.
> ---
>
> arch/x86/Kconfig | 3 ---
> arch/x86/include/asm/arch_hweight.h | 2 --
> lib/hweight.c | 4 ----
> 3 files changed, 9 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 6826143..c2813af 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -262,9 +262,6 @@ config GENERIC_BUG
> config GENERIC_BUG_RELATIVE_POINTERS
> bool
>
> -config GENERIC_HWEIGHT
> - def_bool y
> -
> config ARCH_MAY_HAVE_PC_FDC
> def_bool y
> depends on ISA_DMA_API
> diff --git a/arch/x86/include/asm/arch_hweight.h b/arch/x86/include/asm/arch_hweight.h
> index fc06935..ba88edd 100644
> --- a/arch/x86/include/asm/arch_hweight.h
> +++ b/arch/x86/include/asm/arch_hweight.h
> @@ -12,8 +12,6 @@
> #define REG_OUT "a"
> #endif
>
> -#define __HAVE_ARCH_SW_HWEIGHT
> -
> static __always_inline unsigned int __arch_hweight32(unsigned int w)
> {
> unsigned int res;
> diff --git a/lib/hweight.c b/lib/hweight.c
> index 7660d88..c94586b 100644
> --- a/lib/hweight.c
> +++ b/lib/hweight.c
> @@ -10,7 +10,6 @@
> * The Hamming Weight of a number is the total number of bits set in it.
> */
>
> -#ifndef __HAVE_ARCH_SW_HWEIGHT
> unsigned int __sw_hweight32(unsigned int w)
> {
> #ifdef CONFIG_ARCH_HAS_FAST_MULTIPLIER
> @@ -27,7 +26,6 @@ unsigned int __sw_hweight32(unsigned int w)
> #endif
> }
> EXPORT_SYMBOL(__sw_hweight32);
> -#endif
>
> unsigned int __sw_hweight16(unsigned int w)
> {
> @@ -46,7 +44,6 @@ unsigned int __sw_hweight8(unsigned int w)
> }
> EXPORT_SYMBOL(__sw_hweight8);
>
> -#ifndef __HAVE_ARCH_SW_HWEIGHT
> unsigned long __sw_hweight64(__u64 w)
> {
> #if BITS_PER_LONG == 32
> @@ -69,4 +66,3 @@ unsigned long __sw_hweight64(__u64 w)
> #endif
> }
> EXPORT_SYMBOL(__sw_hweight64);
> -#endif
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Masahiro Yamada @ 2019-02-19 1:13 UTC (permalink / raw)
To: Kalle Valo
Cc: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
X86 ML, linux-wireless, Christoph Hellwig, David S. Miller,
Networking, Linux Kernel Mailing List, Lorenzo Bianconi,
moderated list:ARM/Mediatek SoC support, linux-arm-kernel,
Felix Fietkau, Matthias Brugger
In-Reply-To: <87pnrosy29.fsf@kamboji.qca.qualcomm.com>
On Tue, Feb 19, 2019 at 4:38 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Kalle Valo <kvalo@codeaurora.org> writes:
>
> > Kalle Valo <kvalo@codeaurora.org> writes:
> >
> >> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> >>
> >>> __sw_hweight8() is just internal implementation.
> >>>
> >>> Drivers should use the common API, hweight8().
> >>>
> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >>
> >> Acked-by: Kalle Valo <kvalo@codeaurora.org>
> >>
> >>> This patch should go to x86 tree along with 2/2.
> >>>
> >>> Otherwise, all{yes,mod}config of x86 would be broken.
> >>>
> >>> This patch is trivial enough.
> >>> I want ACK from the net/wireless maintainer
> >>> so that this can go in via x86 tree.
> >>
> >> Sounds good to me, feel free to push via the x86 tree.
> >
> > Actually, can you wait a bit? Felix just reminded me that we have a
> > similar patch pending from Ben Hutchings:
> >
> > https://patchwork.kernel.org/patch/10808203/
> >
> > And it seems there are two instances of __sw_hweight8, at least in my
> > wireless-drivers-next tree:
> >
> > drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
> > __sw_hweight8(dev->antenna_mask);
> > drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
> > __sw_hweight8(dev->antenna_mask);
> >
> > So we need to think what to do.
>
> I think the best would be that Felix applies Ben's patch to the wireless
> tree and I'll push it to Linus during the next merge window (via
> net-next). Simpler and less conflicts that way.
>
> So Masahiro, could you hold your x86 patch for a while until the mt76
> patch will be in Linus' tree? That should not take more than two weeks,
> I think.
Sure.
I will resend 2/2 later.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH net] mac80211: mesh: fix missing unlock on error in table_path_del()
From: David Miller @ 2019-02-19 0:30 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, herbert, weiyongjun1
In-Reply-To: <20190218102929.22276-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 18 Feb 2019 11:29:29 +0100
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> spin_lock_bh() is used in table_path_del() but rcu_read_unlock()
> is used for unlocking. Fix it by using spin_unlock_bh() instead
> of rcu_read_unlock() in the error handling case.
>
> Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable walk for mesh tables")
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> Dave, can you take this directly? I see little value in sending a
> pull request for this one patch (but if you prefer can do so.)
Applied, thanks Johannes.
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stefan Wahren @ 2019-02-18 22:19 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Lorenzo Bianconi, Alan Stern, Felix Fietkau, Doug Anderson,
Minas Harutyunyan, USB list, linux-wireless
In-Reply-To: <20190218135247.GA9602@redhat.com>
Hi,
> Stanislaw Gruszka <sgruszka@redhat.com> hat am 18. Februar 2019 um 14:52 geschrieben:
>
>
> On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
> > this is a misunderstanding. The warning is about memory alignment to 32 bit addresses, not about page alignment. This is a typical ARM restriction. Maybe we need to make sure in mt76 that the DMA buffer needs to be aligned. But it's also possible that the warning isn't the root cause of our problem.
> >
>
> I see, it needs 4 bytes alignment . There is already dwc2 code checks
> that and allocate new buffer if the alignment is not right:
> dwc2_alloc_dma_aligned_buffer(), but it does nothing if urb->sg
> is not NULL. I thought mt76usb already provide aligned buffers, but
> looks it does not for one TX special case, which are PROBE REQUEST
> frames. Other frames are aligned by inserting L2 header pad. One
> solution for this would be just submit urb with NULL sg (same as
> Lorenzo's patches do, but still allocating buffers via buf->sg),
> but I think, you have right, we should provide 4 bytes aligned buffers
> by default as other DMA hardware may require that. I'm attaching yet
> another patch to test, which fix up alignment for PROBE REQUEST frames.
>
> > > Attached patch should fix this, plese test, thanks in advance.
i saw Felix decided to use Lorenzo's approach.
The patches 1,3,5 applied on today's next fixed only the warning and wifi is still broken (authentication timeout).
Here are the logs for multi_v7_defconfig:
https://gist.github.com/lategoodbye/0a7c5cea7dbf25d0de7944c05d229d79
> >
> > Anyway i tested the following patch combinations against next with the same results as 1,2,3 (no wifi, alignment warning):
> > 1,3
> > 1,2,3,4
>
> I noticed on my setup that patch 4 can cause troubles, but still
> device is workable here on my PC machines.
>
> > > > Btw i can confirm a regression was introduced after 4.19, because in 4.19 there was no firmware timeout but even no working wifi:
> > >
> > > You ment 'no working wifi' or 'working wifi'?
> >
> > Wifi is broken in 4.19, 4.20, 5.0 and next. It only worked with Lorenzo's SG avoid patches so far. Btw the regression (firmware timeout) started in 4.20. I also tested it today.
>
> That somewhat strange because 4.19 mt76x0u does not use SG.
> On 4.19 there is phy calibration bug fixed in 4.19.5:
Sorry for being inprecise. I was talking about the branches not the exact tags. I tested 4.19.23 without luck.
Many thanks anyway
Stefan
^ permalink raw reply
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Borislav Petkov @ 2019-02-18 21:49 UTC (permalink / raw)
To: Kalle Valo
Cc: Masahiro Yamada, Ingo Molnar, Thomas Gleixner, H . Peter Anvin,
x86, linux-wireless, Christoph Hellwig, David S. Miller, netdev,
linux-kernel, Lorenzo Bianconi, linux-mediatek, linux-arm-kernel,
Felix Fietkau, Matthias Brugger
In-Reply-To: <87pnrosy29.fsf@kamboji.qca.qualcomm.com>
On Mon, Feb 18, 2019 at 09:20:46PM +0200, Kalle Valo wrote:
> So Masahiro, could you hold your x86 patch for a while until the mt76
> patch will be in Linus' tree? That should not take more than two weeks,
> I think.
No hurry - I won't take it into the x86 now and queue it for 5.1 because
it is not something urgent or fixing a bug or so. It is a cleanup and as
such it can surely wait for 5.2, I'd say. Unless there are other aspects
which I'm not thinking of right now...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* pull request: mt76 2019-02-18
From: Felix Fietkau @ 2019-02-18 20:19 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
Hi Kalle,
here's another pull request for 5.1
- Felix
The following changes since commit f77ecde5f206195cdce16dd2ac92d7ca0305ba2b:
Merge tag 'iwlwifi-next-for-kalle-2019-02-14' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next (2019-02-18 20:10:46 +0200)
are available in the Git repository at:
https://github.com/nbd168/wireless tags/mt76-for-kvalo-2019-02-18
for you to fetch changes up to 9f688473408b6334c5da5ec085f9ea1954675fe7:
mt76: mt76x2: simplify per-chain signal strength handling (2019-02-18 20:41:50 +0100)
----------------------------------------------------------------
mt76 patches for 5.1
* beacon support for USB devices (mesh+ad-hoc only)
* mt76x0 tx power fixes
* fixes for encryption, calibration and ED/CCA
* more code unification
* USB fixes
* fix for using the correct hweight8 function
----------------------------------------------------------------
Ben Hutchings (1):
mt76: Use the correct hweight8() function
Felix Fietkau (11):
mt76: fix software encryption issues
mt76: mt76x2: avoid running DPD calibration if tx is blocked
mt76: explicitly disable energy detect cca during scan
mt76: run MAC work every 100ms
mt76: clear CCA timer stats in mt76x02_edcca_init
mt76: measure the time between mt76x02_edcca_check runs
mt76: increase ED/CCA tx block threshold
mt76: fix tx status timeout processing
mt76: fix corrupted software generated tx CCMP PN
mt76: fix resetting software IV flag on key delete
mt76: mt76x2: simplify per-chain signal strength handling
Lorenzo Bianconi (21):
mt76x0: eeprom: fix VHT mcs{8,9} rate power offset
mt76: move mt76_mcu_msg_alloc in mt76-core
mt76: move mt76_mcu_get_response in mt76-core
mt76: move mt76_mcu_rx_event in mt76-core
mt76x0: mcu: remove useless commented configuration
mt76: move mt76_dma_tx_queue_skb_raw in mt76-core module
mt76: remove add_buf pointer in mt76_queue_ops
mt76: move alloc_device common code in mt76_alloc_device
mt76x2u: remove mt76x2u_alloc_device routine
mt76x0: remove mt76x0u_alloc_device routine
mt76x2: remove mt76x2_alloc_device routine
mt76x0: phy: report target_power in debugfs
mt76x0: init: introduce mt76x0_init_txpower routine
mt76: usb: fix possible NULL pointer dereference in mt76u_mcu_deinit
mt76: usb: fix possible memory leak in mt76u_buf_free
mt76: usb: do not run mt76u_queues_deinit twice
mt76: usb: move mt76u_check_sg in usb.c
mt76: usb: do not use sg buffers for mcu messages
mt76: usb: use a linear buffer for tx/rx datapath if sg is not supported
mt76: usb: introduce disable_usb_sg parameter
mt76: usb: use dev_err_ratelimited instead of dev_err in mt76u_complete_rx
Ryder Lee (1):
mt76: change the return type of mt76_dma_attach()
Stanislaw Gruszka (9):
mt76x02: use mask for vifs
mt76x02: use commmon add interface for mt76x2u
mt76x02: initialize mutli bss mode when set up address
mt76x02: minor beaconing init changes
mt76x02: init beacon config for mt76x2u
mt76: beaconing fixes for USB
mt76x02: enable support for IBSS and MESH
mt76x02u: use usb_bulk_msg to upload firmware
mt76x02u: remove bogus check and comment padding
drivers/net/wireless/mediatek/mt76/Makefile | 3 +-
drivers/net/wireless/mediatek/mt76/dma.c | 29 ++++++++++++++++--
drivers/net/wireless/mediatek/mt76/dma.h | 2 +-
drivers/net/wireless/mediatek/mt76/mac80211.c | 11 +++++--
drivers/net/wireless/mediatek/mt76/mcu.c | 60 ++++++++++++++++++++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76.h | 32 ++++++++++++++-----
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 16 +++++-----
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.h | 7 +++--
drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 39 ++++++++++++-----------
drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h | 4 ---
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 19 +++++++-----
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 11 ++++---
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 26 +++++++++-------
drivers/net/wireless/mediatek/mt76/mt76x0/usb_mcu.c | 6 ----
drivers/net/wireless/mediatek/mt76/mt76x02.h | 7 +++--
drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 90 ++++++++++++++++++++++++++++++++++++++++++-----------
drivers/net/wireless/mediatek/mt76/mt76x02_mac.h | 8 ++---
drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c | 69 ++++++-----------------------------------
drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h | 6 ++++
drivers/net/wireless/mediatek/mt76/mt76x02_txrx.c | 12 ++------
drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c | 14 ++++++---
drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c | 72 +++++++++++--------------------------------
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 79 ++++++++++++++++++++++++-----------------------
drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2.h | 1 -
drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2u.h | 1 -
drivers/net/wireless/mediatek/mt76/mt76x2/pci.c | 26 ++++++++++++----
drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c | 31 +------------------
drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c | 6 ++--
drivers/net/wireless/mediatek/mt76/mt76x2/phy.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 24 +++++++++++----
drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c | 32 ++-----------------
drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c | 17 ++--------
drivers/net/wireless/mediatek/mt76/tx.c | 5 +--
drivers/net/wireless/mediatek/mt76/usb.c | 162 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------
drivers/net/wireless/mediatek/mt76/usb_mcu.c | 13 ++++----
37 files changed, 524 insertions(+), 422 deletions(-)
create mode 100644 drivers/net/wireless/mediatek/mt76/mcu.c
^ permalink raw reply
* [PATCH 3/4] mt76: fix resetting software IV flag on key delete
From: Felix Fietkau @ 2019-02-18 19:42 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20190218194218.41314-1-nbd@nbd.name>
It needs to be unset instead of set
Fixes: 23405236460b9 ("mt76: fix transmission of encrypted management frames")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 87ed00768bc7..11b5f664f5b1 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -431,7 +431,7 @@ int mt76x02_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
} else {
if (idx == wcid->hw_key_idx) {
wcid->hw_key_idx = -1;
- wcid->sw_iv = true;
+ wcid->sw_iv = false;
}
key = NULL;
--
2.17.0
^ permalink raw reply related
* [PATCH 4/4] mt76: mt76x2: simplify per-chain signal strength handling
From: Felix Fietkau @ 2019-02-18 19:42 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20190218194218.41314-1-nbd@nbd.name>
There is no need to use a for loop here, supported chips can only support
up to 2 chains.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
index eab713723b7e..be2979f34f31 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
@@ -608,7 +608,7 @@ int mt76x02_mac_process_rx(struct mt76x02_dev *dev, struct sk_buff *skb,
u16 rate = le16_to_cpu(rxwi->rate);
u16 tid_sn = le16_to_cpu(rxwi->tid_sn);
bool unicast = rxwi->rxinfo & cpu_to_le32(MT_RXINFO_UNICAST);
- int i, pad_len = 0, nstreams = dev->mt76.chainmask & 0xf;
+ int pad_len = 0, nstreams = dev->mt76.chainmask & 0xf;
s8 signal;
u8 pn_len;
u8 wcid;
@@ -668,12 +668,13 @@ int mt76x02_mac_process_rx(struct mt76x02_dev *dev, struct sk_buff *skb,
status->chains = BIT(0);
signal = mt76x02_mac_get_rssi(dev, rxwi->rssi[0], 0);
- for (i = 0; i < nstreams; i++) {
- status->chains |= BIT(i);
- status->chain_signal[i] = mt76x02_mac_get_rssi(dev,
- rxwi->rssi[i],
- i);
- signal = max_t(s8, signal, status->chain_signal[i]);
+ status->chain_signal[0] = signal;
+ if (nstreams > 1) {
+ status->chains |= BIT(1);
+ status->chain_signal[1] = mt76x02_mac_get_rssi(dev,
+ rxwi->rssi[1],
+ 1);
+ signal = max_t(s8, signal, status->chain_signal[1]);
}
status->signal = signal;
status->freq = dev->mt76.chandef.chan->center_freq;
--
2.17.0
^ permalink raw reply related
* [PATCH 1/4] mt76: fix tx status timeout processing
From: Felix Fietkau @ 2019-02-18 19:42 UTC (permalink / raw)
To: linux-wireless
Remove bogus check for MT_PACKET_ID_NO_ACK in mt76_tx_status_skb_get, which
is already handled in callers and turns timeout calls into no-ops
Do not clean up pending status items on reordering of tx status information
if the timeout is not reached yet
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/tx.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index ef38e8626da9..5a349fe3e576 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -205,9 +205,6 @@ mt76_tx_status_skb_get(struct mt76_dev *dev, struct mt76_wcid *wcid, int pktid,
{
struct sk_buff *skb, *tmp;
- if (pktid == MT_PACKET_ID_NO_ACK)
- return NULL;
-
skb_queue_walk_safe(&dev->status_list, skb, tmp) {
struct mt76_tx_cb *cb = mt76_tx_skb_cb(skb);
@@ -217,7 +214,7 @@ mt76_tx_status_skb_get(struct mt76_dev *dev, struct mt76_wcid *wcid, int pktid,
if (cb->pktid == pktid)
return skb;
- if (!pktid &&
+ if (pktid >= 0 &&
!time_after(jiffies, cb->jiffies + MT_TX_STATUS_SKB_TIMEOUT))
continue;
--
2.17.0
^ permalink raw reply related
* [PATCH 2/4] mt76: fix corrupted software generated tx CCMP PN
From: Felix Fietkau @ 2019-02-18 19:42 UTC (permalink / raw)
To: linux-wireless; +Cc: stable
In-Reply-To: <20190218194218.41314-1-nbd@nbd.name>
Since ccmp_pn is u8 *, the second half needs to start at array index 4
instead of 0. Fixes a connection stall after a certain amount of traffic
Fixes: 23405236460b9 ("mt76: fix transmission of encrypted management frames")
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
index bf39624c9b98..eab713723b7e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
@@ -314,7 +314,7 @@ void mt76x02_mac_write_txwi(struct mt76x02_dev *dev, struct mt76x02_txwi *txwi,
ccmp_pn[6] = pn >> 32;
ccmp_pn[7] = pn >> 40;
txwi->iv = *((__le32 *)&ccmp_pn[0]);
- txwi->eiv = *((__le32 *)&ccmp_pn[1]);
+ txwi->eiv = *((__le32 *)&ccmp_pn[4]);
}
spin_lock_bh(&dev->mt76.lock);
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Kalle Valo @ 2019-02-18 19:20 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
x86, linux-wireless, Christoph Hellwig, David S. Miller, netdev,
linux-kernel, Lorenzo Bianconi, linux-mediatek, linux-arm-kernel,
Felix Fietkau, Matthias Brugger
In-Reply-To: <87tvh0syq2.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
>>
>>> __sw_hweight8() is just internal implementation.
>>>
>>> Drivers should use the common API, hweight8().
>>>
>>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>>
>> Acked-by: Kalle Valo <kvalo@codeaurora.org>
>>
>>> This patch should go to x86 tree along with 2/2.
>>>
>>> Otherwise, all{yes,mod}config of x86 would be broken.
>>>
>>> This patch is trivial enough.
>>> I want ACK from the net/wireless maintainer
>>> so that this can go in via x86 tree.
>>
>> Sounds good to me, feel free to push via the x86 tree.
>
> Actually, can you wait a bit? Felix just reminded me that we have a
> similar patch pending from Ben Hutchings:
>
> https://patchwork.kernel.org/patch/10808203/
>
> And it seems there are two instances of __sw_hweight8, at least in my
> wireless-drivers-next tree:
>
> drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
> __sw_hweight8(dev->antenna_mask);
> drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
> __sw_hweight8(dev->antenna_mask);
>
> So we need to think what to do.
I think the best would be that Felix applies Ben's patch to the wireless
tree and I'll push it to Linus during the next merge window (via
net-next). Simpler and less conflicts that way.
So Masahiro, could you hold your x86 patch for a while until the mt76
patch will be in Linus' tree? That should not take more than two weeks,
I think.
--
Kalle Valo
^ 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