mt76x0u: Probing issues on Raspberry Pi 3 B+

BUG Stanislaw Gruszka 1 participant 1 message Feb 12, 2019

Subsystems (3)

USB Arm MediaTek MediaTek MT76 wireless LAN driver

lore

Share & tools

lore

Stanislaw Gruszka

author

2019-02-12 09:30 UTC #0 lore raw

Quoted 37 lines · Lorenzo Bianconi

Quoted 28 lines · Stanislaw Gruszka
Quoted 17 lines · Alan Stern
Quoted 9 lines · Lorenzo Bianconi
Quoted 7 lines
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
Quoted 3 lines
Has anyone considered adding SG support to dwc2? It shouldn't be very difficult. The corresponding change for ehci-hcd required adding no more than about 30 lines of code.
That would be cool. Perhaps somebody with dwc2 hardware could do this.
Quoted 8 lines
However in mt76x02u we possibly would like to support other usb host drivers with sg_tablesize = 0 . I would like to clarify what is correct to do with such drivers.
Is ok to pass buffer via urb->sg with urb->num_sgs = 1 ? Or maybe urb->num_sgs should be 0 to pass buffer via urb->sg on such drivers ? Or maybe non of above is correct and the only option that will work in 100% is pass buffer via urb->transfer_buffer ?
Quoted 6 lines
See the kerneldoc for usb_sg_init(), usb_sg_wait(), and usb_sg_cancel() in drivers/usb/core/message.c. These routines will always do the right thing -- however usb_sg_wait() must be called in process context.
Alan Stern
Hi Alan,

Quoted 7 lines

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 to support.
I am wondering if the right approach is to add SG to the controller one by one or have legacy I/O in mt76 (not sure what is the 'best' approach)

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 works on rpi. Patch is on top of your error path fixes.

Stanislaw
From f79ac0df967d406523d0a1c03a138d1394e7665a Mon Sep 17 00:00:00 2001
From: Stanislaw Gruszka <[email protected]>
Date: Tue, 12 Feb 2019 10:02:53 +0100
Subject: [PATCH] mt76usb: do not set urb->num_sgs to 1 for non SG usb host
drivers

Track number of segments in mt76u_buf structure and do not submit urbs with urb->num_sgs = 1 if usb host driver sg_tablesize is zero.

This suppose fix problem of mt76 not working with some usb host controllers like dwc2.

Signed-off-by Stanislaw Gruszka <[email protected]>

---
 drivers/net/wireless/mediatek/mt76/mt76.h |  1 +
 drivers/net/wireless/mediatek/mt76/usb.c  | 55 ++++++++++++++---------
 2 files changed, 36 insertions(+), 20 deletions(-)

drivers/net/wireless/mediatek/mt76/mt76.h +1 -0

index 2e5bcb3fdff7..eadc913c37b6 100644
@@ -86,6 +86,7 @@ struct mt76_queue_buf {
 struct mt76u_buf {
 	struct mt76_dev *dev;
 	struct urb *urb;
+	int num_sgs;
 	size_t len;
 	bool done;
 };

drivers/net/wireless/mediatek/mt76/usb.c +35 ~~-20~~

122 lines not on this page · raw message