From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
Felix Fietkau <nbd@nbd.name>,
Doug Anderson <dianders@chromium.org>,
Minas Harutyunyan <hminas@synopsys.com>,
USB list <linux-usb@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
Date: Wed, 20 Feb 2019 11:20:50 +0100 [thread overview]
Message-ID: <20190220102050.GA7195@redhat.com> (raw)
On Tue, Feb 19, 2019 at 10:40:47AM -0500, Alan Stern wrote:
> On Tue, 19 Feb 2019, Stanislaw Gruszka wrote:
>
> > 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.
>
> urb->sg != NULL and urb->num_sgs == 0 means that the transfer buffer
> must fit into a single page, which is pointed to by the first element
> of the scatterlist.
I asked about that in other thread
https://lore.kernel.org/linux-wireless/2cc5674a-a3a0-d8fe-65f5-4357da9b85d3@arm.com/
the answer was it is weird but valid. However I think do dma_map_page()
on buffer not fit in the single page is asking for troubles. I just posted
patch that should fix this for mt76usb.
> But now that I look at the code in usb_sg_init(), it seems odd that the
> !use_sg case doesn't increment sg during each loop iteration. I don't
> see how that could possibly work -- it looks like a bug!
Looks for me that this is done via for_each_sg(sg, sg, io->entries, i) loop.
Stanislaw
WARNING: multiple messages have this Message-ID (diff)
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
Felix Fietkau <nbd@nbd.name>,
Doug Anderson <dianders@chromium.org>,
Minas Harutyunyan <hminas@synopsys.com>,
USB list <linux-usb@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
Date: Wed, 20 Feb 2019 11:20:50 +0100 [thread overview]
Message-ID: <20190220102050.GA7195@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1902191032480.1623-100000@iolanthe.rowland.org>
On Tue, Feb 19, 2019 at 10:40:47AM -0500, Alan Stern wrote:
> On Tue, 19 Feb 2019, Stanislaw Gruszka wrote:
>
> > 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.
>
> urb->sg != NULL and urb->num_sgs == 0 means that the transfer buffer
> must fit into a single page, which is pointed to by the first element
> of the scatterlist.
I asked about that in other thread
https://lore.kernel.org/linux-wireless/2cc5674a-a3a0-d8fe-65f5-4357da9b85d3@arm.com/
the answer was it is weird but valid. However I think do dma_map_page()
on buffer not fit in the single page is asking for troubles. I just posted
patch that should fix this for mt76usb.
> But now that I look at the code in usb_sg_init(), it seems odd that the
> !use_sg case doesn't increment sg during each loop iteration. I don't
> see how that could possibly work -- it looks like a bug!
Looks for me that this is done via for_each_sg(sg, sg, io->entries, i) loop.
Stanislaw
next reply other threads:[~2019-02-20 10:20 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-20 10:20 Stanislaw Gruszka [this message]
2019-02-20 10:20 ` [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+ Stanislaw Gruszka
-- 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-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 15:10 Lorenzo Bianconi
2019-02-11 15:10 ` Lorenzo Bianconi
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=20190220102050.GA7195@redhat.com \
--to=sgruszka@redhat.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=stefan.wahren@i2se.com \
--cc=stern@rowland.harvard.edu \
/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.