Hi,
> Stanislaw Gruszka hat am 20. Februar 2019 um 17:32
> geschrieben:
>
>
> On Wed, Feb 20, 2019 at 05:22:18PM +0100, Lorenzo Bianconi wrote:
> > > On Wed, Feb 20, 2019 at 02:22:08PM +0100, Lorenzo Bianconi wrote:
> > > > > On Tue, Feb 19, 2019 at 01:19:26PM +0100, Felix Fietkau wrote:
> > >
> On Wed, Feb 20, 2019 at 05:22:18PM +0100, Lorenzo Bianconi wrote:
> > > On Wed, Feb 20, 2019 at 02:22:08PM +0100, Lorenzo Bianconi wrote:
> > > > > On Tue, Feb 19, 2019 at 01:19:26PM +0100, Felix Fietkau wrote:
> > > > > > >> >> The way I see it, we have two choices.
> > > > > > >> >> 1. Fix dwc2
On Wed, Feb 20, 2019 at 05:22:18PM +0100, Lorenzo Bianconi wrote:
> > On Wed, Feb 20, 2019 at 02:22:08PM +0100, Lorenzo Bianconi wrote:
> > > > On Tue, Feb 19, 2019 at 01:19:26PM +0100, Felix Fietkau wrote:
> > > > > >> >> The way I see it, we have two choices.
> > > > > >> >> 1. Fix dwc2 to do its
> On Wed, Feb 20, 2019 at 02:22:08PM +0100, Lorenzo Bianconi wrote:
> > > On Tue, Feb 19, 2019 at 01:19:26PM +0100, Felix Fietkau wrote:
> > > > >> >> 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
On Wed, Feb 20, 2019 at 02:22:08PM +0100, Lorenzo Bianconi wrote:
> > On Tue, Feb 19, 2019 at 01:19:26PM +0100, Felix Fietkau wrote:
> > > >> >> 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
On Wed, 20 Feb 2019, Stanislaw Gruszka wrote:
> 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_tab
> On Tue, Feb 19, 2019 at 01:19:26PM +0100, Felix Fietkau wrote:
> > >> >> 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
On Tue, Feb 19, 2019 at 01:19:26PM +0100, Felix Fietkau wrote:
> >> >> 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 d
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
Am 19.02.19 um 11:59 schrieb Stanislaw Gruszka:
> On Mon, Feb 18, 2019 at 11:19:40PM +0100, Stefan Wahren wrote:
>> Hi,
>>
>>> Stanislaw Gruszka hat am 18. Februar 2019 um 14:52
>>> geschrieben:
>>>
>>>
>>> On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
>>>
>>> Sorry for being inp
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
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
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 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 misu
On Mon, Feb 18, 2019 at 11:19:40PM +0100, Stefan Wahren wrote:
> Hi,
>
> > Stanislaw Gruszka 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 3
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:
Hi,
> Stanislaw Gruszka 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 restricti
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
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 alignmen
On Mon, Feb 18, 2019 at 03:25:28PM +0100, Lorenzo Bianconi wrote:
> > commit 0d9813319b40399a0d8fd761d2fcfedee5701487
> > Author: Lorenzo Bianconi
> > Date: Fri Sep 7 23:13:12 2018 +0200
>
> [...]
>
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > b/drivers/net/wireless/
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
> commit 0d9813319b40399a0d8fd761d2fcfedee5701487
> Author: Lorenzo Bianconi
> 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/dri
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
Hi Stanislaw,
> Stanislaw Gruszka hat am 16. Februar 2019 um 15:07
> geschrieben:
>
>
> On Sat, Feb 16, 2019 at 12:05:18PM +0100, Stefan Wahren wrote:
> > sorry for the delay, but i do this all in my spare time.
>
> Stefan, thanks for sacrifing your spare time for testing this!
>
> > The res
On Sat, Feb 16, 2019 at 12:05:18PM +0100, Stefan Wahren wrote:
> sorry for the delay, but i do this all in my spare time.
Stefan, thanks for sacrifing your spare time for testing this!
> The results for your recent patch series are better (no firmware timeout),
> but still no working wifi and st
Hi Stanislaw,
> Stanislaw Gruszka hat am 15. Februar 2019 um 08:12
> geschrieben:
>
>
> On Thu, Feb 14, 2019 at 10:48:15AM +0100, Stefan Wahren wrote:
> > Hi Stanislaw,
> >
> > Am 14.02.19 um 10:25 schrieb Stanislaw Gruszka:
> > > On Thu, Feb 14, 2019 at 07:49:57AM +0100, Stefan Wahren wrote:
On Thu, Feb 14, 2019 at 10:48:15AM +0100, Stefan Wahren wrote:
> Hi Stanislaw,
>
> Am 14.02.19 um 10:25 schrieb Stanislaw Gruszka:
> > On Thu, Feb 14, 2019 at 07:49:57AM +0100, Stefan Wahren wrote:
> >> Hi Stanislaw,
> >>
> >>> Stanislaw Gruszka hat am 12. Februar 2019 um 10:30
> >>> geschrieben
On Thu, Feb 14, 2019 at 10:48:15AM +0100, Stefan Wahren wrote:
> Hi Stanislaw,
>
> Am 14.02.19 um 10:25 schrieb Stanislaw Gruszka:
> > On Thu, Feb 14, 2019 at 07:49:57AM +0100, Stefan Wahren wrote:
> >> Hi Stanislaw,
> >>
> >>> Stanislaw Gruszka hat am 12. Februar 2019 um 10:30
> >>> geschrieben
Hi Stanislaw,
Am 14.02.19 um 10:25 schrieb Stanislaw Gruszka:
> On Thu, Feb 14, 2019 at 07:49:57AM +0100, Stefan Wahren wrote:
>> Hi Stanislaw,
>>
>>> Stanislaw Gruszka hat am 12. Februar 2019 um 10:30
>>> geschrieben:
>>>
>>>
>>>
>>> In usb_sg_init() urb->num_sgs is set 0 for sg_tablesize = 0 c
On Thu, Feb 14, 2019 at 07:49:57AM +0100, Stefan Wahren wrote:
> Hi Stanislaw,
>
> > Stanislaw Gruszka hat am 12. Februar 2019 um 10:30
> > geschrieben:
> >
> >
> >
> > In usb_sg_init() urb->num_sgs is set 0 for sg_tablesize = 0 controllers.
> > In mt76 we set urb->num_sgs to 1. I thought it
Hi Stanislaw,
> Stanislaw Gruszka hat am 12. Februar 2019 um 10:30
> geschrieben:
>
>
>
> In usb_sg_init() urb->num_sgs is set 0 for sg_tablesize = 0 controllers.
> In mt76 we set urb->num_sgs to 1. I thought it is fine, but now I think
> this is bug. We can fix that without changing allocati
Hi,
> Lorenzo Bianconi hat am 11. Februar 2019 um
> 16:57 geschrieben:
>
>
> >
> > Compiling the mainline kernel with arm/multi_v7_defconfig it works.
> > Using the same kernel but with arm64/defconfig doesn't work. But i don't
> > think this is a 32/64 bit issue. The arm64 defconfig is much
On Tue, 12 Feb 2019, Lorenzo Bianconi wrote:
> Hi Alan,
>
> I actually used usb_sg_init()/usb_sg_wait() as reference to implement
> mt76u {tx/rx} datapath, but I will double-check.
> I guess we should even consider if there are other usb host drivers
> that do not implement SG I/O and it is worth
On Tue, Feb 12, 2019 at 12:58:43PM +0100, Lorenzo Bianconi wrote:
> > + usb_fill_bulk_urb(buf->urb, udev, pipe, NULL, buf->len, complete_fn,
> > + context);
> > +
> > + if (udev->bus->sg_tablesize > 0) {
> > + buf->urb->num_sgs = buf->num_sgs;
> > + } else {
> >
[...]
> In usb_sg_init() urb->num_sgs is set 0 for sg_tablesize = 0 controllers.
> In mt76 we set urb->num_sgs to 1. I thought it is fine, but now I think
> this is bug. We can fix that without changing allocation method and
> still use SG allocation. Attached patch do this, please check if it w
On Tue, Feb 12, 2019 at 01:06:00AM +0100, Lorenzo Bianconi wrote:
> >
> > On Mon, 11 Feb 2019, Stanislaw Gruszka wrote:
> >
> > > On Mon, Feb 11, 2019 at 10:12:57AM -0500, Alan Stern wrote:
> > > > On Mon, 11 Feb 2019, Lorenzo Bianconi wrote:
> > > >
> > > > > Here it is a different issue respect t
>
> On Mon, 11 Feb 2019, Stanislaw Gruszka wrote:
>
> > On Mon, Feb 11, 2019 at 10:12:57AM -0500, Alan Stern wrote:
> > > On Mon, 11 Feb 2019, Lorenzo Bianconi wrote:
> > >
> > > > Here it is a different issue respect to the AMD IOMMU one, dwc2 host
> > > > driver
> > > > does not implement SG I/O
On Mon, 11 Feb 2019, Stanislaw Gruszka wrote:
> On Mon, Feb 11, 2019 at 10:12:57AM -0500, Alan Stern wrote:
> > On Mon, 11 Feb 2019, Lorenzo Bianconi wrote:
> >
> > > Here it is a different issue respect to the AMD IOMMU one, dwc2 host
> > > driver
> > > does not implement SG I/O so probing fail
On Mon, Feb 11, 2019 at 10:12:57AM -0500, Alan Stern wrote:
> On Mon, 11 Feb 2019, Lorenzo Bianconi wrote:
>
> > 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 t
On Mon, Feb 11, 2019 at 04:27:40PM +0100, Stefan Wahren wrote:
> >> 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:
> Hi,
>
> Am 11.02.19 um 16:10 schrieb Lorenzo Bianconi:
> >> 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, F
Hi,
Am 11.02.19 um 16:10 schrieb Lorenzo Bianconi:
>> 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:0
On Mon, 11 Feb 2019, Lorenzo Bianconi wrote:
> 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
> 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 p
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 fol
> 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/107
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/
> y
> 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 a
> Hi,
>
> Am 11.02.19 um 08:50 schrieb Stanislaw Gruszka:
> > On Sun, Feb 10, 2019 at 05:52:30PM +0100, Lorenzo Bianconi wrote:
> >> Anyway we will need to avoid SG since dwc_otg controller does not support
> >> it
>
> this isn't correct. AFAIK the dwc2 host driver doesn't implement it,
> which
Hi,
Am 11.02.19 um 08:50 schrieb Stanislaw Gruszka:
> On Sun, Feb 10, 2019 at 05:52:30PM +0100, Lorenzo Bianconi wrote:
>> Anyway we will need to avoid SG since dwc_otg controller does not support it
this isn't correct. AFAIK the dwc2 host driver doesn't implement it,
which doesn't mean the contr
On Sun, Feb 10, 2019 at 05:52:30PM +0100, Lorenzo Bianconi wrote:
> Anyway we will need to avoid SG since dwc_otg controller does not support it
What does it mean the dwc_otg does not support SG ? Please be more specific.
Stanislaw
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 drive
> > sorry for all the confusion (i never tested the foundation kernel). I made
> > my functional tests with arm/multi_v7_defconfig which doesn't need any
> > patches to work.
> >
> > Here the current results for next-2019-02-08:
> >
> > arm/multi_v7_defconfig w/o any patches -> wlan0 online
> > a
>
> Hi,
>
> > Stanislaw Gruszka hat am 10. Februar 2019 um 10:29
> > geschrieben:
> >
> >
> > On Sat, Feb 09, 2019 at 07:46:37PM +0100, Lorenzo Bianconi wrote:
> > > > as already reported here [1], that there are probing issues of mt76
> > > > using TP-Link Archer T2UH (wifi USB dongle) on Raspb
Hi,
> Stanislaw Gruszka hat am 10. Februar 2019 um 10:29
> geschrieben:
>
>
> On Sat, Feb 09, 2019 at 07:46:37PM +0100, Lorenzo Bianconi wrote:
> > > as already reported here [1], that there are probing issues of mt76 using
> > > TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
> >
> 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 scatt
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 y
On Sat, Feb 09, 2019 at 07:46:37PM +0100, Lorenzo Bianconi wrote:
> > as already reported here [1], that there are probing issues of mt76 using
> > TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
> >
> > I retested it with recent linux-next 20190208 (aarch64 defconfig + enabling
> > m
Hi Lorenzo,
> Lorenzo Bianconi hat am 9. Februar 2019 um
> 21:33 geschrieben:
>
>
> >
> > Hi Lorenzo,
> >
> > > Lorenzo Bianconi hat am 9. Februar 2019 um
> > > 19:46 geschrieben:
> > >
> > >
> > > >
> > > > Hi,
> > > >
> > > > as already reported here [1], that there are probing issues of m
>
> Hi Lorenzo,
>
> > Lorenzo Bianconi hat am 9. Februar 2019 um
> > 19:46 geschrieben:
> >
> >
> > >
> > > Hi,
> > >
> > > as already reported here [1], that there are probing issues of mt76 using
> > > TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
> > >
> > > I retested it with r
Hi Lorenzo,
> Lorenzo Bianconi hat am 9. Februar 2019 um
> 19:46 geschrieben:
>
>
> >
> > Hi,
> >
> > as already reported here [1], that there are probing issues of mt76 using
> > TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
> >
> > I retested it with recent linux-next 20190208
>
> Hi,
>
> as already reported here [1], that there are probing issues of mt76 using
> TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
>
> I retested it with recent linux-next 20190208 (aarch64 defconfig + enabling
> mt76 driver) and got the following output after plugin the wifi don
Hi,
as already reported here [1], that there are probing issues of mt76 using
TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
I retested it with recent linux-next 20190208 (aarch64 defconfig + enabling
mt76 driver) and got the following output after plugin the wifi dongle:
[ 29.7
62 matches
Mail list logo
