> 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: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? > > not really. > > 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 more > complex (e.g. enables more IOMMU stuff). thx for the clarification :) Regards, Lorenzo > > Regards > Stefan >
