* 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
* Re: [PATCH] mt76: Use the correct hweight8() function
From: Felix Fietkau @ 2019-02-18 19:11 UTC (permalink / raw)
To: Ben Hutchings, Lorenzo Bianconi; +Cc: linux-wireless
In-Reply-To: <20190212153624.u6x5dqvmixq63div@decadent.org.uk>
On 2019-02-12 16:36, Ben Hutchings wrote:
> mt76_init_stream_cap() and mt76_get_txpower() call __sw_hweight8()
> directly, but that's only defined if CONFIG_GENERIC_HWEIGHT is
> enabled. The function that works on all architectures is hweight8().
>
> Fixes: 551e1ef4d291 ("mt76: add mt76_init_stream_cap routine")
> Fixes: 9313faacbb4e ("mt76: move mt76x02_get_txpower to mt76 core")
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied, thanks.
- Felix
^ permalink raw reply
* Re: [PATCH] iwlwifi: mvm: fix an unaligned access
From: Jonas Gorski @ 2019-02-18 19:08 UTC (permalink / raw)
To: wangxuerui; +Cc: linux-wireless
In-Reply-To: <20190218150952.6889-1-wangxuerui@qiniu.com>
Hi,
On Mon, 18 Feb 2019 at 19:40, <wangxuerui@qiniu.com> wrote:
>
> From: Wang Xuerui <wangxuerui@qiniu.com>
>
> Tested with a Wireless AC 7265 on a MIPS box, confirmed to fix the
> unaligned accesses.
>
> Signed-off-by: Wang Xuerui <wangxuerui@qiniu.com>
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
> index 6653a238f32e..a155e816262e 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
> @@ -57,6 +57,7 @@
> * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> *****************************************************************************/
> +#include <asm/unaligned.h>
> #include <linux/etherdevice.h>
> #include <linux/skbuff.h>
> #include "iwl-trans.h"
> @@ -355,8 +356,8 @@ void iwl_mvm_rx_rx_mpdu(struct iwl_mvm *mvm, struct napi_struct *napi,
> rx_res = (struct iwl_rx_mpdu_res_start *)pkt->data;
> hdr = (struct ieee80211_hdr *)(pkt->data + sizeof(*rx_res));
> len = le16_to_cpu(rx_res->byte_count);
> - rx_pkt_status = le32_to_cpup((__le32 *)
> - (pkt->data + sizeof(*rx_res) + len));
> + rx_pkt_status = le32_to_cpu(get_unaligned((__le32 *)
> + (pkt->data + sizeof(*rx_res) + len)));
There's get_unaligned_le32() for that purpose.
Regards
Jonas
^ permalink raw reply
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Kalle Valo @ 2019-02-18 19:06 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: <877edxt1f1.fsf@kamboji.qca.qualcomm.com>
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.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mt76x02u: remove bogus check and comment padding
From: Felix Fietkau @ 2019-02-18 19:03 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Lorenzo Bianconi
In-Reply-To: <1549963482-13523-1-git-send-email-sgruszka@redhat.com>
On 2019-02-12 10:24, Stanislaw Gruszka wrote:
> In mt76x02u_skb_dma_info() pad is always non-zero. Patch removes
> bogus check and add comments to the function.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Applied, thanks.
- Felix
^ permalink raw reply
* Re: [PATCH] mt76: usb: use dev_err_ratelimited instead of dev_err in mt76u_complete_rx
From: Felix Fietkau @ 2019-02-18 19:03 UTC (permalink / raw)
To: lorenzo; +Cc: linux-wireless, sgruszka
In-Reply-To: <25bdd32592a9e0e64d202b1a53c4680f0d958423.1549928358.git.lorenzo@kernel.org>
On 2019-02-12 00:45, lorenzo@kernel.org wrote:
> From: Lorenzo Bianconi <lorenzo@kernel.org>
>
> During device removal the driver can report multiple error messages.
> Use dev_err_ratelimited instead of dev_err to display urb errors
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Applied, thanks.
- Felix
^ permalink raw reply
* Re: [PATCH RESEND 0/4] do not use sg if not properly supported by usb controller
From: Felix Fietkau @ 2019-02-18 18:56 UTC (permalink / raw)
To: lorenzo, linux-wireless
In-Reply-To: <cover.1549977282.git.lorenzo@kernel.org>
On 2019-02-12 14:42, lorenzo@kernel.org wrote:
> From: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Use linear fragment and not a single usb scatter-gather buffer in mt76u
> {tx,rx} datapath if the usb controller has sg data length constraints.
> Moreover add disable_usb_sg module parameter in order to explicitly
> disable scatter-gather. SG I/O is not supported by all host drivers and
> some users have reported sg issues on AMD IOMMU.
> This series has been tested on AMD IOMMU cpus/motherboards and on rpi3+
>
> Changes since RFC:
> - rebased on top of 'fix multiple issues in mt76u error path'
> https://patchwork.kernel.org/cover/10804919/
>
> I am resending the series since the first attempt seems to be rejected by
> the ML
Applied, thanks.
- Felix
^ permalink raw reply
* Re: [PATCH wireless-drivers 0/3] fix multiple issues in mt76u error path
From: Felix Fietkau @ 2019-02-18 18:56 UTC (permalink / raw)
To: Lorenzo Bianconi, linux-wireless; +Cc: sgruszka, stefan.wahren
In-Reply-To: <cover.1549832428.git.lorenzo.bianconi@redhat.com>
On 2019-02-10 22:49, Lorenzo Bianconi wrote:
> Fix following issues in mt76u initialization error path:
> - NULL pointer dereference in mt76u_mcu_deinit
> - possible memory leak in mt76u_buf_free
> - use-after-free warning since mt76u_queues_deinit is run twice
>
> This series has been tested running mt76x0u driver on rpi3+
> (dwc_otg controller does not support SG I/O)
Applied, thanks.
- Felix
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Felix Fietkau @ 2019-02-18 18:52 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Stefan Wahren, Lorenzo Bianconi, Alan Stern, Doug Anderson,
Minas Harutyunyan, USB list, linux-wireless
In-Reply-To: <20190218150303.GD9602@redhat.com>
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 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.
- Felix
^ permalink raw reply
* Re: -Wimplicit-fallthrough not working with ccache
From: Gustavo A. R. Silva @ 2019-02-18 17:49 UTC (permalink / raw)
To: Kalle Valo
Cc: netdev, linux-wireless, linux-kernel, ath10k, David S. Miller,
linux-kbuild, Kees Cook
In-Reply-To: <87zhqwuggt.fsf_-_@kamboji.qca.qualcomm.com>
Hi Kalle,
On 2/16/19 5:21 AM, Kalle Valo wrote:
> (replying to an old thread but renaming it)
>
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> "Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
>>
>>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>>> where we are expecting to fall through.
>>>
>>> Notice that in this particular case, I replaced "pass through" with
>>> a proper "fall through" comment, which is what GCC is expecting
>>> to find.
>>>
>>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>>
>> Patch applied to ath-next branch of ath.git, thanks.
>>
>> f1d270ae10ff ath10k: htt_tx: mark expected switch fall-throughs
>
> Gustavo, I enabled W=1 on my ath10k build checks and it took me a while
> to figure out why GCC was warning about fall through annotations missing
> even I knew you had fixed them. Finally I figured out that the reason
> was ccache, which I need because I work with different branches and need
> to recompile the kernel quite often.
>
> If the plan is to enable -Wimplicit-fallthrough by default in the kernel
> IMHO this might become an issue, as otherwise people using ccache start
> seeing lots of invalid warnings. Apparently CCACHE_COMMENTS=1 will fix
> that but my version of ccache doesn't support it, and how would everyone
> learn that trick anyway? Or maybe CCACHE_COMMENTS can enabled through
> kernel Makefile?
>
Can you share with me the warning messages you get?
I just see the following warnings with linux-next:
$ make CC="ccache gcc" W=1 drivers/net/wireless/ath/ath10k/htt_tx.o
CC [M] drivers/net/wireless/ath/ath10k/htt_tx.o
In file included from drivers/net/wireless/ath/ath10k/htt_tx.c:19:
drivers/net/wireless/ath/ath10k/htt.h:1727:1: warning: alignment 1 of ‘struct ath10k_htt_txbuf_32’ is less than 4 [-Wpacked-not-aligned]
} __packed;
^
drivers/net/wireless/ath/ath10k/htt.h:1734:1: warning: alignment 1 of ‘struct ath10k_htt_txbuf_64’ is less than 4 [-Wpacked-not-aligned]
} __packed;
^
In my Makefile I have:
KBUILD_CFLAGS += $(call cc-option,-Wimplicit-fallthrough=3,)
Thanks
--
Gustavo
^ permalink raw reply
* Re: [PATCH 0/2] remove qid dependency from mt76-core code
From: Felix Fietkau @ 2019-02-18 18:29 UTC (permalink / raw)
To: lorenzo; +Cc: linux-wireless, sgruszka, ryder.lee, roychl666
In-Reply-To: <cover.1550336347.git.lorenzo@kernel.org>
On 2019-02-16 18:47, lorenzo@kernel.org wrote:
> From: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Move queue id dependency in driver specific tx queue initialization code
> since new chipsets rely on a different tx queue enumeration scheme.
> Add the possibility to specify qid in mt76_tx routine
I've thought about this patch set some more, and I think we should take
a different approach.
If we simply map everything to the BE queue for MT7615, this breaks
per-AC scheduling of intermediate tx queues. Because outstanding packet
batches are currently tracked as part of the hardware queue, we can't
track them separately per AC in that case.
I would suggest the following approach instead.
- add a pointer to struct mt76_queue to make it possible to set a parent
queue
- add a queue identifier to struct mt76_queue_entry
- initialize only QID_AC_BE as a full hardware queue
- point all other data queues to QID_AC_BE
- use swq and swq_queued from the skb queue, all other fields (including
the lock) from the parent queue
Does that make sense?
- Felix
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2019-02-14
From: Kalle Valo @ 2019-02-18 18:25 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi, david.e.box, joe.konno
In-Reply-To: <948cdfe88dcad399e0acb698542fb97a35609059.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> This is the fourth batch of patches intended for v5.1. This includes
> the last two patchsets I sent. Usual development work. More details
> about the contents in the tag description.
>
> I have sent this out before and kbuildbot reported success.
>
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit 34025a1056a3c82b7e16992da9af54d729dd77fe:
>
> rsi: fix indentation issue with a code block (2019-02-08 17:31:23 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2019-02-14
>
> for you to fetch changes up to 99944b73069d8bcea573c07df8dc8d4f33e78586:
>
> iwlwifi: mvm: stop static queues correctly (2019-02-14 11:29:52 +0200)
>
> ----------------------------------------------------------------
> Fourth batch of iwlwifi patches intended for v5.1
>
> * Work on the new debugging infrastructure continues;
> * FTM (Fine Timing Measurement) initiator and responder implementation;
> * Support for a new device family started;
> * Bump supported FW API to 46;
> * General bugfixes;
> * Other cleanups;
>
> ----------------------------------------------------------------
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Kalle Valo @ 2019-02-18 18:08 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: <1550469571-25933-2-git-send-email-yamada.masahiro@socionext.com>
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.
--
Kalle Valo
^ permalink raw reply
* Re: MT76x2U crashes XHCI driver on AMD Ryzen system
From: Robin Murphy @ 2019-02-18 17:01 UTC (permalink / raw)
To: Stanislaw Gruszka, Lorenzo Bianconi
Cc: Samuel Sieb, linux-wireless, linux-kernel, iommu, Rosen Penev,
Alexander Duyck
In-Reply-To: <20190218143742.GA11872@redhat.com>
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).
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).
Robin.
[1]
https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024148.html
^ permalink raw reply
* Re: [PATCH] carl9170: clean up a clamp() call
From: Christian Lamparter @ 2019-02-18 16:04 UTC (permalink / raw)
To: Dan Carpenter
Cc: Christian Lamparter, Kalle Valo, linux-wireless, kernel-janitors
In-Reply-To: <20190218093154.GC7712@kadam>
On Monday, February 18, 2019 10:31:54 AM CET Dan Carpenter wrote:
> The parameter order for clamp is supposed to be clamp(value, low, high).
> When we write it in this order it's equivalent to
> min(head->plcp[3] & 0x7f, 75) which works in this context where the min
> is zero. But it's not a correct use of the API.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
> ---
> drivers/net/wireless/ath/carl9170/rx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c
> index f7c2f19e81c1..8e154f6364a3 100644
> --- a/drivers/net/wireless/ath/carl9170/rx.c
> +++ b/drivers/net/wireless/ath/carl9170/rx.c
> @@ -427,7 +427,7 @@ static int carl9170_rx_mac_status(struct ar9170 *ar,
> if (head->plcp[6] & 0x80)
> status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
>
> - status->rate_idx = clamp(0, 75, head->plcp[3] & 0x7f);
> + status->rate_idx = clamp(head->plcp[3] & 0x7f, 0, 75);
> status->encoding = RX_ENC_HT;
> break;
>
>
^ permalink raw reply
* pull-request: wireless-drivers 2019-02-18
From: Kalle Valo @ 2019-02-18 15:19 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's one more pull request to net tree for 5.0. Please let me know if
you have any problems.
Kalle
The following changes since commit 8c22d81d55353209f8976074ffa9fb1085da0830:
MAINTAINERS: add entry for redpine wireless driver (2019-02-03 21:41:51 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2019-02-18
for you to fetch changes up to d04ca383860bef90a0dab4eb397907f7f05e839e:
mt76x0u: fix suspend/resume (2019-02-07 18:32:16 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 5.0
Hopefully the last set of fixes for 5.0, only fix this time.
mt76
* fix regression with resume on mt76x0u USB devices
----------------------------------------------------------------
Stanislaw Gruszka (1):
mt76x0u: fix suspend/resume
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 46 ++++++++++++++++---------
1 file changed, 29 insertions(+), 17 deletions(-)
^ permalink raw reply
* [PATCH] iwlwifi: mvm: fix an unaligned access
From: wangxuerui @ 2019-02-18 15:09 UTC (permalink / raw)
To: linux-wireless; +Cc: Wang Xuerui
From: Wang Xuerui <wangxuerui@qiniu.com>
Tested with a Wireless AC 7265 on a MIPS box, confirmed to fix the
unaligned accesses.
Signed-off-by: Wang Xuerui <wangxuerui@qiniu.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
index 6653a238f32e..a155e816262e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
@@ -57,6 +57,7 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*****************************************************************************/
+#include <asm/unaligned.h>
#include <linux/etherdevice.h>
#include <linux/skbuff.h>
#include "iwl-trans.h"
@@ -355,8 +356,8 @@ void iwl_mvm_rx_rx_mpdu(struct iwl_mvm *mvm, struct napi_struct *napi,
rx_res = (struct iwl_rx_mpdu_res_start *)pkt->data;
hdr = (struct ieee80211_hdr *)(pkt->data + sizeof(*rx_res));
len = le16_to_cpu(rx_res->byte_count);
- rx_pkt_status = le32_to_cpup((__le32 *)
- (pkt->data + sizeof(*rx_res) + len));
+ rx_pkt_status = le32_to_cpu(get_unaligned((__le32 *)
+ (pkt->data + sizeof(*rx_res) + len)));
/* Dont use dev_alloc_skb(), we'll have enough headroom once
* ieee80211_hdr pulled.
--
2.16.1
^ permalink raw reply related
* Re: MT76x2U crashes XHCI driver on AMD Ryzen system
From: Lorenzo Bianconi @ 2019-02-18 15:15 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Rosen Penev, linux-wireless, Samuel Sieb, Alexander Duyck, iommu,
Joerg Roedel, linux-kernel
In-Reply-To: <20190218143742.GA11872@redhat.com>
> (cc: IOMMU & page_frag_alloc maintainers)
>
> On Tue, Jan 15, 2019 at 10:04:01AM +0100, Lorenzo Bianconi wrote:
> > > On Mon, Jan 14, 2019 at 1:18 AM Lorenzo Bianconi
> > > <lorenzo.bianconi@redhat.com> wrote:
> > > >
> > > > > On Sun, Jan 13, 2019 at 11:00 AM Lorenzo Bianconi
> > > > > <lorenzo.bianconi@redhat.com> wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sun, Jan 13, 2019 at 5:33 AM, Lorenzo Bianconi <lorenzo.bianconi@redhat.com> wrote:
> > > > > > >
> > > > > > > Direct. No VM used. This is the only peripheral causing this issue.
> > > > > > >
> > > > > > > Is the device connected to a usb3.0 port? If so, could you please try to connect the dongle to a 2.0 one?
> > > > > > >
> > > > > > > I tried through a USB 2.0 port. Shouldn't make a difference as they both use the xhci driver.
> > > > > > >
> > > > > >
> > > > > > mt76x2u supports scatter-gather on usb 3.0 (not on 2.0)
> > > > > Tried a USB 3 port. Same result.
> > > > > >
> > > > > > > Could you please double check if IOMMU is enabled?
> > > > > > >
> > > > > >
> > > > > > Have you tried to disable it? Does it make any difference?
> > > > > No idea how. UEFI doesn't seem to show anything similar.
> > > > >
> > > > > Similar bug report: https://bugzilla.kernel.org/show_bug.cgi?id=202241
>
> FWIW: I provided some patches in the bugzilla, which were reported to
> solve the problem. But I looking for confirmation if both are needed:
>
> 0001-mt76x02u-use-usb_bulk_msg-to-upload-firmware.patch
> 0002-mt76usb-do-not-use-compound-head-page-for-SG-I-O.patch
>
> Or problem can be solved by just one of it (either first or second).
>
> Additionally I'm not 100% sure if
>
> 0002-mt76usb-do-not-use-compound-head-page-for-SG-I-O.patch
>
> is correct. So perhaps some IOMMU maintainer could look at it.
>
> > > > You should be able to disable iommu using GRUB_CMDLINE_LINUX in
> > > > /etc/default/grub (I guess setting iommu=off and reinstalling grub)
> > > > https://wiki.gentoo.org/wiki/IOMMU_SWIOTLB
> > > Yep. Working great now. I wonder what mt76 is doing to cause the crash though...
> >
> > Thanks for bisecting the issue.
>
> Lorenzo, what you mean by 'bisecting' here ? Someone did 'git bisect'
> on this issue?
>
Hi Stanislaw,
I was meaning 'help bisecting' the issue
> > I think amd iommu does not support well usb scatter-gather
> > (used by default in mt76u). I am working on a series in order to add the possibility to
> > disable it.
>
> Even if that true that AMD IOMMU does not support 'well' SG (what I think
> is not true) disabling SG in mt76 driver is not right solution. Right
> solution would be propagate the issue to AMD IOMMU maintainers
> (already CCed).
I meant that AMD iommu seems to have different constraints respect to Intel
one.
Regards,
Lorenzo
>
> One problem in mt76 is page_frag_alloc() usage with different sizes.
> page_frag_alloc() unlike like other allocators do not assure alignment
> and relay on callers to provide buffers sizes that are aligned.
> Unaligned buffer might then not be appropriate for DMA.
>
> 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.
>
> Stanislaw
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stanislaw Gruszka @ 2019-02-18 15:03 UTC (permalink / raw)
To: Felix Fietkau
Cc: Stefan Wahren, Lorenzo Bianconi, Alan Stern, Doug Anderson,
Minas Harutyunyan, USB list, linux-wireless
In-Reply-To: <0e29e99a-6ed4-40fe-1f38-30f1b5530a16@nbd.name>
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).
> 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.
Stanislaw
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stanislaw Gruszka @ 2019-02-18 14:47 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Stefan Wahren, Alan Stern, Felix Fietkau, Doug Anderson,
Minas Harutyunyan, USB list, linux-wireless
In-Reply-To: <20190218142527.GA9283@localhost.localdomain>
On Mon, Feb 18, 2019 at 03:25:28PM +0100, Lorenzo Bianconi wrote:
> > commit 0d9813319b40399a0d8fd761d2fcfedee5701487
> > Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> > Date: Fri Sep 7 23:13:12 2018 +0200
>
> [...]
>
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > index 062614ad0d51..08425b1d2c30 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > @@ -550,21 +550,33 @@ void mt76x02_sta_rate_tbl_update(struct ieee80211_hw *hw,
> > }
> > EXPORT_SYMBOL_GPL(mt76x02_sta_rate_tbl_update);
> >
> > -int mt76x02_insert_hdr_pad(struct sk_buff *skb)
> > +void mt76x02_align_skb(struct sk_buff *skb)
> > {
> > - int len = ieee80211_get_hdrlen_from_skb(skb);
> > + int align = ((unsigned long) skb->data) & 3;
> > + int hdrlen, skblen;
> >
> > - if (len % 4 == 0)
> > - return 0;
> > + hdrlen = ieee80211_get_hdrlen_from_skb(skb);
> > + WARN_ON_ONCE(align == 0 && (hdrlen & 3));
> > +
> > + if (align == 0)
> > + return;
>
> Hi Stanislaw,
>
> is it possible that skb->data is 4 byte aligned but hdrlen is not? (e.g 4addr
> data frames, not qos)?
It might be possible, so for now I add this
WARN_ON_ONCE(align == 0 && (hdrlen & 3));
and plan to do some investigation on frame aliment.
> are you sure this is true *only* for probe requests?
> this could hit performances and it is used even in pci code
I'm not 100% sure, but I haven't seen any other frames with
that. All other unaligned frames I've seen in my tests had
unaligned header and adding header pad aligned them.
But obviously I've haven't tested all possible scenarios.
Stanislaw
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Felix Fietkau @ 2019-02-18 14:43 UTC (permalink / raw)
To: Stanislaw Gruszka, Stefan Wahren
Cc: Lorenzo Bianconi, Alan Stern, Doug Anderson, Minas Harutyunyan,
USB list, linux-wireless
In-Reply-To: <20190218135247.GA9602@redhat.com>
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.
And I really don't think we can assume that this code path is going to
be hit for probe requests only.
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
- Felix
^ permalink raw reply
* Re: MT76x2U crashes XHCI driver on AMD Ryzen system
From: Stanislaw Gruszka @ 2019-02-18 14:37 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Rosen Penev, linux-wireless, Samuel Sieb, Alexander Duyck, iommu,
Joerg Roedel, linux-kernel
In-Reply-To: <20190115090400.GA2267@localhost.localdomain>
(cc: IOMMU & page_frag_alloc maintainers)
On Tue, Jan 15, 2019 at 10:04:01AM +0100, Lorenzo Bianconi wrote:
> > On Mon, Jan 14, 2019 at 1:18 AM Lorenzo Bianconi
> > <lorenzo.bianconi@redhat.com> wrote:
> > >
> > > > On Sun, Jan 13, 2019 at 11:00 AM Lorenzo Bianconi
> > > > <lorenzo.bianconi@redhat.com> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > On Sun, Jan 13, 2019 at 5:33 AM, Lorenzo Bianconi <lorenzo.bianconi@redhat.com> wrote:
> > > > > >
> > > > > > Direct. No VM used. This is the only peripheral causing this issue.
> > > > > >
> > > > > > Is the device connected to a usb3.0 port? If so, could you please try to connect the dongle to a 2.0 one?
> > > > > >
> > > > > > I tried through a USB 2.0 port. Shouldn't make a difference as they both use the xhci driver.
> > > > > >
> > > > >
> > > > > mt76x2u supports scatter-gather on usb 3.0 (not on 2.0)
> > > > Tried a USB 3 port. Same result.
> > > > >
> > > > > > Could you please double check if IOMMU is enabled?
> > > > > >
> > > > >
> > > > > Have you tried to disable it? Does it make any difference?
> > > > No idea how. UEFI doesn't seem to show anything similar.
> > > >
> > > > Similar bug report: https://bugzilla.kernel.org/show_bug.cgi?id=202241
FWIW: I provided some patches in the bugzilla, which were reported to
solve the problem. But I looking for confirmation if both are needed:
0001-mt76x02u-use-usb_bulk_msg-to-upload-firmware.patch
0002-mt76usb-do-not-use-compound-head-page-for-SG-I-O.patch
Or problem can be solved by just one of it (either first or second).
Additionally I'm not 100% sure if
0002-mt76usb-do-not-use-compound-head-page-for-SG-I-O.patch
is correct. So perhaps some IOMMU maintainer could look at it.
> > > You should be able to disable iommu using GRUB_CMDLINE_LINUX in
> > > /etc/default/grub (I guess setting iommu=off and reinstalling grub)
> > > https://wiki.gentoo.org/wiki/IOMMU_SWIOTLB
> > Yep. Working great now. I wonder what mt76 is doing to cause the crash though...
>
> Thanks for bisecting the issue.
Lorenzo, what you mean by 'bisecting' here ? Someone did 'git bisect'
on this issue?
> I think amd iommu does not support well usb scatter-gather
> (used by default in mt76u). I am working on a series in order to add the possibility to
> disable it.
Even if that true that AMD IOMMU does not support 'well' SG (what I think
is not true) disabling SG in mt76 driver is not right solution. Right
solution would be propagate the issue to AMD IOMMU maintainers
(already CCed).
One problem in mt76 is page_frag_alloc() usage with different sizes.
page_frag_alloc() unlike like other allocators do not assure alignment
and relay on callers to provide buffers sizes that are aligned.
Unaligned buffer might then not be appropriate for DMA.
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.
Stanislaw
^ permalink raw reply
* Re: [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: Dan Carpenter @ 2019-02-18 14:36 UTC (permalink / raw)
To: maowenan; +Cc: johannes, linux-wireless, kernel-janitors, netdev, kvalo
In-Reply-To: <927ff17c-c506-734f-fc27-796d4c8fba98@huawei.com>
On Mon, Feb 18, 2019 at 09:25:06PM +0800, maowenan wrote:
> Add kalle Valo in mail list.
>
> Hi Kalle Valo,
> Do you have any comments about this patch?
>
It's not done against a recent net-next so it doesn't apply.
Please give people a few days to reply for networking changes.
regards,
dan caprenter
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Lorenzo Bianconi @ 2019-02-18 14:25 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Stefan Wahren, Alan Stern, Felix Fietkau, Doug Anderson,
Minas Harutyunyan, USB list, linux-wireless
In-Reply-To: <20190218135247.GA9602@redhat.com>
> commit 0d9813319b40399a0d8fd761d2fcfedee5701487
> Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> Date: Fri Sep 7 23:13:12 2018 +0200
[...]
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> index 062614ad0d51..08425b1d2c30 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> @@ -550,21 +550,33 @@ void mt76x02_sta_rate_tbl_update(struct ieee80211_hw *hw,
> }
> EXPORT_SYMBOL_GPL(mt76x02_sta_rate_tbl_update);
>
> -int mt76x02_insert_hdr_pad(struct sk_buff *skb)
> +void mt76x02_align_skb(struct sk_buff *skb)
> {
> - int len = ieee80211_get_hdrlen_from_skb(skb);
> + int align = ((unsigned long) skb->data) & 3;
> + int hdrlen, skblen;
>
> - if (len % 4 == 0)
> - return 0;
> + hdrlen = ieee80211_get_hdrlen_from_skb(skb);
> + WARN_ON_ONCE(align == 0 && (hdrlen & 3));
> +
> + if (align == 0)
> + return;
Hi Stanislaw,
is it possible that skb->data is 4 byte aligned but hdrlen is not? (e.g 4addr
data frames, not qos)?
>
> - skb_push(skb, 2);
> - memmove(skb->data, skb->data + 2, len);
> + if (hdrlen & 3) {
> + /* Align frame and add 2 bytes pad after header. */
> + skb_push(skb, 2);
> + memmove(skb->data, skb->data + 2, hdrlen);
>
> - skb->data[len] = 0;
> - skb->data[len + 1] = 0;
> - return 2;
> + skb->data[hdrlen] = 0;
> + skb->data[hdrlen + 1] = 0;
> + } else {
> + /* Only for probe request frames. */
are you sure this is true *only* for probe requests?
this could hit performances and it is used even in pci code
Regards,
Lorenzo
> + skblen = skb->len;
> + skb_push(skb, 2);
> + memmove(skb->data, skb->data + 2, skblen);
> + skb_trim(skb, skblen);
> + }
> }
> -EXPORT_SYMBOL_GPL(mt76x02_insert_hdr_pad);
> +EXPORT_SYMBOL_GPL(mt76x02_align_skb);
>
> void mt76x02_remove_hdr_pad(struct sk_buff *skb, int len)
> {
> --
> 2.7.5
>
^ permalink raw reply
* Re: [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: maowenan @ 2019-02-18 14:04 UTC (permalink / raw)
To: Kalle Valo; +Cc: johannes, linux-wireless, kernel-janitors, netdev
In-Reply-To: <878sydus0p.fsf@kamboji.qca.qualcomm.com>
On 2019/2/18 21:48, Kalle Valo wrote:
> maowenan <maowenan@huawei.com> writes:
>
>> Add kalle Valo in mail list.
>>
>> Hi Kalle Valo,
>> Do you have any comments about this patch?
>
> Why do you ask me? Johannes maintains cfg80211, not me, and he will
> provide comments once he reviews the patch (which might take some time,
> we do have other tasks as well).
I'm sorry for this, my mistake to add wrong maintainer.
>
^ 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