All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>,
	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: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
Date: Mon, 11 Feb 2019 16:10:56 +0100	[thread overview]
Message-ID: <20190211151055.GC8128@localhost.localdomain> (raw)

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

So to summarize:
- Raspberry Pi Foundation kernel works just with RFC series
- mainline kernel works out of the box

is my understanding correct? I am still considering adding a legacy mode since
there will not be any regression using it instead of SG I/O with just one SG
buffer

Regards,
Lorenzo

> 
> Maybe this could be helpful.
> 
> Stefan
> 
> > Regards,
> > Lorenzo
> >
> >> In case of using the arm/multi_v7_defconfig (32 bit) the mt76 works like
> >> a charm without your sg avoid patch series, but the arm64/defconfig (64
> >> bit) requires the series to probe at least. So i wouldn't conclude from
> >> the fact that dwc2 doesn't support SG any probing issues on arm64. So we
> >> need to investigate which config option triggers the problem.
> >>
> >> Stefan
> >>
> >> [1] - https://marc.info/?l=linux-usb&m=154981675724078
> >>

WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>,
	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 16:10:56 +0100	[thread overview]
Message-ID: <20190211151055.GC8128@localhost.localdomain> (raw)
In-Reply-To: <8a996497-ed69-4087-2c37-7f73633cbb4e@i2se.com>

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

So to summarize:
- Raspberry Pi Foundation kernel works just with RFC series
- mainline kernel works out of the box

is my understanding correct? I am still considering adding a legacy mode since
there will not be any regression using it instead of SG I/O with just one SG
buffer

Regards,
Lorenzo

> 
> Maybe this could be helpful.
> 
> Stefan
> 
> > Regards,
> > Lorenzo
> >
> >> In case of using the arm/multi_v7_defconfig (32 bit) the mt76 works like
> >> a charm without your sg avoid patch series, but the arm64/defconfig (64
> >> bit) requires the series to probe at least. So i wouldn't conclude from
> >> the fact that dwc2 doesn't support SG any probing issues on arm64. So we
> >> need to investigate which config option triggers the problem.
> >>
> >> Stefan
> >>
> >> [1] - https://marc.info/?l=linux-usb&m=154981675724078
> >>

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

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 15:10 Lorenzo Bianconi [this message]
2019-02-11 15:10 ` [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+ Lorenzo Bianconi
  -- strict thread matches above, loose matches on Subject: below --
2019-03-03 21:16 Stefan Wahren
2019-03-03 21:16 ` Stefan Wahren
2019-02-20 16:36 Lorenzo Bianconi
2019-02-20 16:36 ` Lorenzo Bianconi
2019-02-20 16:32 Stanislaw Gruszka
2019-02-20 16:32 ` Stanislaw Gruszka
2019-02-20 16:22 Lorenzo Bianconi
2019-02-20 16:22 ` Lorenzo Bianconi
2019-02-20 16:14 Stanislaw Gruszka
2019-02-20 16:14 ` Stanislaw Gruszka
2019-02-20 15:25 Alan Stern
2019-02-20 15:25 ` Alan Stern
2019-02-20 13:22 Lorenzo Bianconi
2019-02-20 13:22 ` Lorenzo Bianconi
2019-02-20 13:00 Stanislaw Gruszka
2019-02-20 13:00 ` Stanislaw Gruszka
2019-02-20 10:20 Stanislaw Gruszka
2019-02-20 10:20 ` Stanislaw Gruszka
2019-02-19 17:02 Stefan Wahren
2019-02-19 17:02 ` Stefan Wahren
2019-02-19 15:40 Alan Stern
2019-02-19 15:40 ` Alan Stern
2019-02-19 12:19 Felix Fietkau
2019-02-19 12:19 ` Felix Fietkau
2019-02-19 12:11 Felix Fietkau
2019-02-19 12:11 ` Felix Fietkau
2019-02-19 10:59 Stanislaw Gruszka
2019-02-19 10:59 ` Stanislaw Gruszka
2019-02-19 10:42 Stanislaw Gruszka
2019-02-19 10:42 ` Stanislaw Gruszka
2019-02-18 22:19 Stefan Wahren
2019-02-18 22:19 ` Stefan Wahren
2019-02-18 18:52 Felix Fietkau
2019-02-18 18:52 ` Felix Fietkau
2019-02-18 15:03 Stanislaw Gruszka
2019-02-18 15:03 ` Stanislaw Gruszka
2019-02-18 14:47 Stanislaw Gruszka
2019-02-18 14:47 ` Stanislaw Gruszka
2019-02-18 14:43 Felix Fietkau
2019-02-18 14:43 ` Felix Fietkau
2019-02-18 14:25 Lorenzo Bianconi
2019-02-18 14:25 ` Lorenzo Bianconi
2019-02-18 13:52 Stanislaw Gruszka
2019-02-18 13:52 ` Stanislaw Gruszka
2019-02-16 19:17 Stefan Wahren
2019-02-16 19:17 ` Stefan Wahren
2019-02-16 14:07 Stanislaw Gruszka
2019-02-16 14:07 ` Stanislaw Gruszka
2019-02-16 11:05 Stefan Wahren
2019-02-16 11:05 ` Stefan Wahren
2019-02-15  7:12 Stanislaw Gruszka
2019-02-15  7:12 ` Stanislaw Gruszka
2019-02-14  9:54 Stanislaw Gruszka
2019-02-14  9:54 ` Stanislaw Gruszka
2019-02-14  9:48 Stefan Wahren
2019-02-14  9:48 ` Stefan Wahren
2019-02-14  9:25 Stanislaw Gruszka
2019-02-14  9:25 ` Stanislaw Gruszka
2019-02-14  6:49 Stefan Wahren
2019-02-14  6:49 ` Stefan Wahren
2019-02-13  7:05 Stefan Wahren
2019-02-13  7:05 ` Stefan Wahren
2019-02-12 15:27 Alan Stern
2019-02-12 15:27 ` Alan Stern
2019-02-12 13:15 Stanislaw Gruszka
2019-02-12 13:15 ` Stanislaw Gruszka
2019-02-12 11:58 Lorenzo Bianconi
2019-02-12 11:58 ` Lorenzo Bianconi
2019-02-12  9:30 Stanislaw Gruszka
2019-02-12  9:30 ` Stanislaw Gruszka
2019-02-12  0:06 Lorenzo Bianconi
2019-02-12  0:06 ` Lorenzo Bianconi
2019-02-11 17:49 Alan Stern
2019-02-11 17:33 Stanislaw Gruszka
2019-02-11 17:22 Stanislaw Gruszka
2019-02-11 17:22 ` Stanislaw Gruszka
2019-02-11 15:57 Lorenzo Bianconi
2019-02-11 15:57 ` Lorenzo Bianconi
2019-02-11 15:27 Stefan Wahren
2019-02-11 15:27 ` Stefan Wahren
2019-02-11 15:12 Alan Stern
2019-02-11 14:04 Stefan Wahren
2019-02-11 14:04 ` Stefan Wahren
2019-02-11 11:06 Lorenzo Bianconi
2019-02-11 11:06 ` Lorenzo Bianconi
2019-02-11 10:33 Stefan Wahren
2019-02-11 10:33 ` Stefan Wahren
2019-02-11 10:04 Lorenzo Bianconi
2019-02-11 10:04 ` Lorenzo Bianconi
2019-02-11  7:44 Stanislaw Gruszka
2019-02-11  7:44 ` Stanislaw Gruszka
2019-02-10 17:39 Lorenzo Bianconi
2019-02-10 17:39 ` Lorenzo Bianconi
2019-02-10 10:22 Lorenzo Bianconi
2019-02-10 10:22 ` Lorenzo Bianconi
2019-02-10  9:41 Stanislaw Gruszka
2019-02-10  9:41 ` Stanislaw Gruszka
2019-02-09 12:08 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:29   ` Stanislaw Gruszka
2019-02-10 16:38     ` Stefan Wahren
2019-02-10 16:52       ` Lorenzo Bianconi
2019-02-11  7:50         ` Stanislaw Gruszka
2019-02-11  8:08           ` Stefan Wahren
2019-02-11  9:52             ` Lorenzo Bianconi

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=20190211151055.GC8128@localhost.localdomain \
    --to=lorenzo.bianconi@redhat.com \
    --cc=dianders@chromium.org \
    --cc=hminas@synopsys.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nbd@nbd.name \
    --cc=sgruszka@redhat.com \
    --cc=stefan.wahren@i2se.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.