linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Wahren <stefan.wahren@i2se.com>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
	Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Felix Fietkau <nbd@nbd.name>,
	Doug Anderson <dianders@chromium.org>,
	Minas Harutyunyan <hminas@synopsys.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	linux-usb@vger.kernel.org
Subject: Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
Date: Mon, 11 Feb 2019 11:33:49 +0100	[thread overview]
Message-ID: <f7c29b08-c7d5-4d10-4be1-958ee79678f1@i2se.com> (raw)
In-Reply-To: <20190211100405.GD3467@localhost.localdomain>

Hi,

Am 11.02.19 um 11:04 schrieb Lorenzo Bianconi:
>> On Sun, Feb 10, 2019 at 11:22:25AM +0100, Lorenzo Bianconi wrote:
>>>> On Sat, Feb 09, 2019 at 09:29:05PM +0100, Stefan Wahren wrote:
>>>>>> could you please test the following series:
>>>>>> https://patchwork.kernel.org/cover/10764453/
>>>>> yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
>>>> So this is either dwc2 scatter-gather problem which should be addressed in
>>>> this driver or mt76x0u does something wrong when configuring SG.
>>>>
>>>> Disabling SG is just workaround, which do not address actual problem.
>>>>
>>>> I think I found mt76x0u issue that could cause this USB probe error
>>>> (and possibly also address AMD IOMMU issue). We seems do not correctly
>>>> set URB transfer length smaller than sg buffer length. Attached  patch
>>>> should correct that.
>>> Hi Stanislaw,
>>>
>>> I think 'sg[0].length' is already set in mt76u_fill_rx_sg().
>> It is, buf->len and sg[0].length are initialized to the same value for 1
>> segment. But then buf->len (assigned to urb->buffer_transfer_length) change
>> to smaller value , but sg[0].length stay the same. What I think can be
>> problem for usb host driver.
>>
>>> Moreover applying this patch I got the following crash (rpi-5.0.y):
>> Ok, so with patch probe fail instantly and trigger yet another bug(s)
>> on error path. You seems to address that already. 
>>
>>> Moreover for mt76x0u SG is 'already' disabled since we use just one
>>> buffer so from performance point of view I do not see any difference
>>> of using a standard usb buffer.
>>> This patch has been tested in multiple scenarios and seems to fix
>>> reported issues (for usb2.0).
>> Ok, so passing buffer via urb->transfer_buffer works. But why urb->sg
>> does not work for 1 segment ?
> Here it is a different issue respect to the AMD IOMMU one, dwc2 host driver
> does not implement SG I/O so probing fails. I guess it is still useful to
> implement a 'legacy' mode that enable mt76 on host controllers that do not implement
> SG I/O (rpi is a very common device so it will be cool to have mt76 working on
> it). Moreover we are not removing functionalities, user experience will remain
> the same
>
i'm not sure that you understand my mail [1] with the summary of my test
results.

In case of using the arm/multi_v7_defconfig (32 bit) the mt76 works like
a charm without your sg avoid patch series, but the arm64/defconfig (64
bit) requires the series to probe at least. So i wouldn't conclude from
the fact that dwc2 doesn't support SG any probing issues on arm64. So we
need to investigate which config option triggers the problem.

Stefan

[1] - https://marc.info/?l=linux-usb&m=154981675724078


  reply	other threads:[~2019-02-11 10:34 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-09 12:08 [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+ Stefan Wahren
2019-02-09 18:46 ` Lorenzo Bianconi
2019-02-09 20:29   ` Stefan Wahren
2019-02-09 20:33     ` Lorenzo Bianconi
2019-02-09 22:47       ` Stefan Wahren
2019-02-10  9:41     ` Stanislaw Gruszka
2019-02-10 10:22       ` Lorenzo Bianconi
2019-02-11  7:44         ` Stanislaw Gruszka
2019-02-11 10:04           ` Lorenzo Bianconi
2019-02-11 10:33             ` Stefan Wahren [this message]
2019-02-11 11:06               ` Lorenzo Bianconi
2019-02-11 14:04                 ` Stefan Wahren
2019-02-11 15:10                   ` Lorenzo Bianconi
2019-02-11 15:27                     ` Stefan Wahren
2019-02-11 15:57                       ` Lorenzo Bianconi
2019-02-13  7:05                         ` Stefan Wahren
2019-02-11 17:22                       ` Stanislaw Gruszka
2019-02-10  9:29   ` Stanislaw Gruszka
2019-02-10 16:38     ` Stefan Wahren
2019-02-10 16:52       ` Lorenzo Bianconi
2019-02-10 17:39         ` Lorenzo Bianconi
2019-02-11  7:50         ` Stanislaw Gruszka
2019-02-11  8:08           ` Stefan Wahren
2019-02-11  9:52             ` Lorenzo Bianconi
     [not found] <20190211173315.GE6292@redhat.com>
     [not found] ` <Pine.LNX.4.44L0.1902111246410.1543-100000@iolanthe.rowland.org>
2019-02-12  0:06   ` Lorenzo Bianconi
2019-02-12  9:30     ` Stanislaw Gruszka
2019-02-12 11:58       ` Lorenzo Bianconi
2019-02-12 13:15         ` Stanislaw Gruszka
2019-02-14  6:49       ` Stefan Wahren
2019-02-14  9:25         ` Stanislaw Gruszka
2019-02-14  9:48           ` Stefan Wahren
2019-02-14  9:54             ` Stanislaw Gruszka
2019-02-15  7:12             ` Stanislaw Gruszka
2019-02-16 11:05               ` Stefan Wahren
2019-02-16 14:07                 ` Stanislaw Gruszka
2019-02-16 19:17                   ` Stefan Wahren
2019-02-18 13:52                     ` Stanislaw Gruszka
2019-02-18 14:25                       ` Lorenzo Bianconi
2019-02-18 14:47                         ` Stanislaw Gruszka
2019-02-18 14:43                       ` Felix Fietkau
2019-02-18 15:03                         ` Stanislaw Gruszka
2019-02-18 18:52                           ` Felix Fietkau
2019-02-19 10:42                             ` Stanislaw Gruszka
2019-02-19 12:19                               ` Felix Fietkau
2019-02-20 13:00                                 ` Stanislaw Gruszka
2019-02-20 13:22                                   ` Lorenzo Bianconi
2019-02-20 16:14                                     ` Stanislaw Gruszka
2019-02-20 16:22                                       ` Lorenzo Bianconi
2019-02-20 16:32                                         ` Stanislaw Gruszka
2019-02-20 16:36                                           ` Lorenzo Bianconi
2019-03-03 21:16                                           ` Stefan Wahren
2019-02-18 22:19                       ` Stefan Wahren
2019-02-19 10:59                         ` Stanislaw Gruszka
2019-02-19 12:11                           ` Felix Fietkau
2019-02-19 15:40                           ` Alan Stern
2019-02-20 10:20                             ` Stanislaw Gruszka
2019-02-20 15:25                               ` Alan Stern
2019-02-19 17:02                           ` Stefan Wahren
2019-02-12 15:27     ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f7c29b08-c7d5-4d10-4be1-958ee79678f1@i2se.com \
    --to=stefan.wahren@i2se.com \
    --cc=dianders@chromium.org \
    --cc=hminas@synopsys.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=nbd@nbd.name \
    --cc=sgruszka@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).