| Message ID | 20210504212828.815-1-rsalvaterra@gmail.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | [RFC] mt7601u: make the driver work again | expand |
On Tue, May 04, 2021 at 10:28:28PM +0100, Rui Salvaterra wrote: > This is a tentative fix for a long-standing issue [1] with MT7601U devices. In > my case, this is what I see in the dmesg when I plug the device in: > > [ 660.810386] usb 1-7: new high-speed USB device number 119 using ehci-pci > [ 661.031390] usb 1-7: New USB device found, idVendor=148f, > idProduct=7601, bcdDevice= 0.00 > [ 661.031400] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ 661.031404] usb 1-7: Product: 802.11 n WLAN > [ 661.031408] usb 1-7: Manufacturer: MediaTek > [ 661.031411] usb 1-7: SerialNumber: 1.0 > [ 661.200379] usb 1-7: reset high-speed USB device number 119 using ehci-pci > [ 661.403137] mt7601u 1-7:1.0: ASIC revision: 76010001 MAC revision: 76010500 > [ 661.404566] mt7601u 1-7:1.0: Firmware Version: 0.1.00 Build: 7640 > Build time: 201302052146____ > [ 661.828765] mt7601u 1-7:1.0: EEPROM ver:0d fae:00 > [ 662.005518] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71 > [ 662.005525] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4! > [ 662.010015] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71 > [ 662.010020] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4! > [ 662.014269] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71 > [ 662.014275] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4! > [ 662.018516] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71 > [ 662.018521] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4! > [ 662.022768] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71 > [ 662.022775] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4! > [ 662.022779] mt7601u 1-7:1.0: Error: mt7601u_mcu_wait_resp timed out > [ 662.350350] mt7601u 1-7:1.0: Vendor request req:07 off:0080 failed:-71 > [ 662.650344] mt7601u 1-7:1.0: Vendor request req:02 off:0080 failed:-71 > [ 662.950339] mt7601u 1-7:1.0: Vendor request req:02 off:0080 failed:-71 > [ 662.950389] mt7601u: probe of 1-7:1.0 failed with error -110 > [ 662.950850] usb 1-7: USB disconnect, device number 119 > > This loops continuously. The device never comes up. > Turns out, this issue has been narrowed down to a possible calibration > problem [2]. Stanislaw repeatedly asked if disabling DPD calibration only > (keeping the RXIQ calibration) would fix the problem, but nobody seems to have > paid attention. :) Additionally, he asked for contents of > /sys/kernel/debug/ieee80211/phy0/mt7601u/eeprom_param, so here they are: > > RF freq offset: 5f > RSSI offset: 0 0 > Reference temp: f9 > LNA gain: 0 > Reg channels: 1-14 > Per rate power: > raw:05 bw20:05 bw40:05 > raw:05 bw20:05 bw40:05 > raw:03 bw20:03 bw40:03 > raw:03 bw20:03 bw40:03 > raw:04 bw20:04 bw40:04 > raw:00 bw20:00 bw40:00 > raw:00 bw20:00 bw40:00 > raw:00 bw20:00 bw40:00 > raw:02 bw20:02 bw40:02 > raw:00 bw20:00 bw40:00 > Per channel power: > tx_power ch1:0c ch2:0c > tx_power ch3:0b ch4:0b > tx_power ch5:0a ch6:0a > tx_power ch7:0a ch8:0a > tx_power ch9:0a ch10:0a > tx_power ch11:0a ch12:0a > tx_power ch13:0a ch14:0a > > The attached patch fixes the driver for me. Sending as RFC because this will > probably warrant some kind of quirk to be fixed correctly. Besides, there's an > additional DPD calibration in mt7601u_temp_comp, which I haven't touched, since > it seems a bit more convoluted. The driver works for me regardless (I've sent > this email through one of my MT7601U adapters). I'm not sure if DPD calibration is needed. Maybe is ok to disable it for all MT7601U devices. However safer fix would be doing it only for devices that know to need it for work. For example: add dev->no_dpd_cal variable, set it based on USB ID (using usb_device_id->driver_info) and do not perfrom calibration when it's set. Also please clarify "work again" in the topic. Have your device ever worked with mt7601u driver in some older kernel version? Stanislaw
Hi, Stanislaw, On Wed, 5 May 2021 at 05:50, Stanislaw Gruszka <stf_xl@wp.pl> wrote: > > I'm not sure if DPD calibration is needed. Maybe is ok to disable it for > all MT7601U devices. However safer fix would be doing it only for > devices that know to need it for work. For example: add dev->no_dpd_cal > variable, set it based on USB ID (using usb_device_id->driver_info) and > do not perfrom calibration when it's set. Hm… the struct usb_device already contains a u32 quirks. Shouldn't it be used instead, or is it used for an entirely different set of quirks? > Also please clarify "work again" in the topic. Have your device ever > worked with mt7601u driver in some older kernel version? Personally, my devices never worked. I ordered a bunch of them dirt-cheap from AliExpress, in early 2019. I needed one for my RPi, running OpenWrt 19.07 (Linux 4.19), but it failed the same way. I thought it might be a problem with the driver on ARM, I replaced it with a Ralink adapter and it worked fine. I hadn't used the devices until a couple of days ago, when I needed to connect a x86 machine and saw the exact same error I had seen on the Pi. Thanks Rui
Hi On Wed, May 05, 2021 at 09:01:52AM +0100, Rui Salvaterra wrote: > On Wed, 5 May 2021 at 05:50, Stanislaw Gruszka <stf_xl@wp.pl> wrote: > > > > I'm not sure if DPD calibration is needed. Maybe is ok to disable it for > > all MT7601U devices. However safer fix would be doing it only for > > devices that know to need it for work. For example: add dev->no_dpd_cal > > variable, set it based on USB ID (using usb_device_id->driver_info) and > > do not perfrom calibration when it's set. > > Hm… the struct usb_device already contains a u32 quirks. Shouldn't it > be used instead, or is it used for an entirely different set of > quirks? Yes, those u32 quirks are used to change behaviour of usb-core module and we should not interfere with them. We need quirk for mt7601u driver. > > Also please clarify "work again" in the topic. Have your device ever > > worked with mt7601u driver in some older kernel version? > > Personally, my devices never worked. I ordered a bunch of them > dirt-cheap from AliExpress, in early 2019. I needed one for my RPi, > running OpenWrt 19.07 (Linux 4.19), but it failed the same way. I > thought it might be a problem with the driver on ARM, I replaced it > with a Ralink adapter and it worked fine. I hadn't used the devices > until a couple of days ago, when I needed to connect a x86 machine and > saw the exact same error I had seen on the Pi. Ok, please correct the topic of the patch when you'll be posting next version. Thanks Stanislaw
Hi again, Stanislaw, I was meanwhile wondering if we could try and unconditionally drop the DPD calibration from the driver, and see if anyone complains. You said it yourself [1] the vendor driver has DPD calibration under conditional compilation (I don't know which conditions, though, I haven't looked at it). As far as testing is concerned, all my devices are 148f:7601, so it would be nice for people with other USB IDs to test them. [1] https://github.com/kuba-moo/mt7601u/issues/64#issuecomment-479801642 On Wed, 5 May 2021 at 10:25, Stanislaw Gruszka <stf_xl@wp.pl> wrote: > > Yes, those u32 quirks are used to change behaviour of usb-core module > and we should not interfere with them. We need quirk for mt7601u driver. Right, thanks for clarifying. > Ok, please correct the topic of the patch when you'll be posting next > version. Will do. Thanks, Rui
Hi On Wed, May 05, 2021 at 10:38:58AM +0100, Rui Salvaterra wrote: > Hi again, Stanislaw, > > I was meanwhile wondering if we could try and unconditionally drop the > DPD calibration from the driver, and see if anyone complains. You said > it yourself [1] the vendor driver has DPD calibration under > conditional compilation (I don't know which conditions, though, I > haven't looked at it). As far as testing is concerned, all my devices > are 148f:7601, so it would be nice for people with other USB IDs to > test them. > > [1] https://github.com/kuba-moo/mt7601u/issues/64#issuecomment-479801642 I don't know if it's safe to remove DPD calibration in mt7601u driver for all supported devices. Possibly it is. I don't have my device any longer, but as far I remember removing DPD was harmless for my device. But can not assure that this does not break support for some other devices or cause not easy to notice issue like performance drop on some specific conditions. Regards Stanislaw
Hi, again, Well, this was "fun"… I rebased my patch on top of 5.13-rc1 and now my MT7601U adapters are broken again. I tried different combinations of mine and the the last two upstream patches [1][2], but the result is the same, so now I have no idea of what's going on. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mediatek/mt7601u?h=v5.13-rc1&id=87fce88658ba047ae62e83497d3f3c5dc22fa6f9 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mediatek/mt7601u?h=v5.13-rc1&id=670d9e53886c942b7f29c475b2b494278e586921 Thanks, Rui
On 11/05/2021 11:13, Rui Salvaterra wrote: > Hi, again, > > Well, this was "fun"… I rebased my patch on top of 5.13-rc1 and now my > MT7601U adapters are broken again. I tried different combinations of > mine and the the last two upstream patches [1][2], but the result is > the same, so now I have no idea of what's going on. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mediatek/mt7601u?h=v5.13-rc1&id=87fce88658ba047ae62e83497d3f3c5dc22fa6f9 > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mediatek/mt7601u?h=v5.13-rc1&id=670d9e53886c942b7f29c475b2b494278e586921 If reverting the above patches does not work, I suspect a bisect is required to corner the exact reason. > > Thanks, > Rui >
Hi, Colin, On Tue, 11 May 2021 at 11:16, Colin Ian King <colin.king@canonical.com> wrote: > > If reverting the above patches does not work, I suspect a bisect is > required to corner the exact reason. Sure, I was just trying to be as lazy as possible, but I guess there's no way around it. :) Thanks, Rui
On 11/05/2021 11:21, Rui Salvaterra wrote: > Hi, Colin, > > On Tue, 11 May 2021 at 11:16, Colin Ian King <colin.king@canonical.com> wrote: >> >> If reverting the above patches does not work, I suspect a bisect is >> required to corner the exact reason. > > Sure, I was just trying to be as lazy as possible, but I guess there's > no way around it. :) Lazy is good when it works :-) I'm all for that. > > Thanks, > Rui >
Hi, again, So much for bisecting. Turns out, while trying to bisect on a faster machine, I discovered my MT7601U adapters are also broken on 5.12, with my patch. They're working on a Pentium D 950 and broken on an i7-4770R. The only obvious differences I see are the CPU speeds and USB controllers (USB 2.0 vs 3.0). Since there's only a certain amount of weirdness I can handle on one day, I'm stepping back on this one, for now. Thanks, Rui
diff --git a/drivers/net/wireless/mediatek/mt7601u/phy.c b/drivers/net/wireless/mediatek/mt7601u/phy.c index 8a00f6a75ca9..daa6a042f2c7 100644 --- a/drivers/net/wireless/mediatek/mt7601u/phy.c +++ b/drivers/net/wireless/mediatek/mt7601u/phy.c @@ -589,8 +589,6 @@ void mt7601u_phy_recalibrate_after_assoc(struct mt7601u_dev *dev) if (test_bit(MT7601U_STATE_REMOVED, &dev->state)) return; - mt7601u_mcu_calibrate(dev, MCU_CAL_DPD, dev->curr_temp); - mt7601u_rxdc_cal(dev); } @@ -1157,9 +1155,6 @@ static int mt7601u_init_cal(struct mt7601u_dev *dev) if (ret) return ret; ret = mt7601u_mcu_calibrate(dev, MCU_CAL_RXIQ, 0); - if (ret) - return ret; - ret = mt7601u_mcu_calibrate(dev, MCU_CAL_DPD, dev->dpd_temp); if (ret) return ret;
This is a tentative fix for a long-standing issue [1] with MT7601U devices. In my case, this is what I see in the dmesg when I plug the device in: [ 660.810386] usb 1-7: new high-speed USB device number 119 using ehci-pci [ 661.031390] usb 1-7: New USB device found, idVendor=148f, idProduct=7601, bcdDevice= 0.00 [ 661.031400] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 661.031404] usb 1-7: Product: 802.11 n WLAN [ 661.031408] usb 1-7: Manufacturer: MediaTek [ 661.031411] usb 1-7: SerialNumber: 1.0 [ 661.200379] usb 1-7: reset high-speed USB device number 119 using ehci-pci [ 661.403137] mt7601u 1-7:1.0: ASIC revision: 76010001 MAC revision: 76010500 [ 661.404566] mt7601u 1-7:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 201302052146____ [ 661.828765] mt7601u 1-7:1.0: EEPROM ver:0d fae:00 [ 662.005518] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71 [ 662.005525] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4! [ 662.010015] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71 [ 662.010020] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4! [ 662.014269] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71 [ 662.014275] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4! [ 662.018516] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71 [ 662.018521] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4! [ 662.022768] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71 [ 662.022775] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4! [ 662.022779] mt7601u 1-7:1.0: Error: mt7601u_mcu_wait_resp timed out [ 662.350350] mt7601u 1-7:1.0: Vendor request req:07 off:0080 failed:-71 [ 662.650344] mt7601u 1-7:1.0: Vendor request req:02 off:0080 failed:-71 [ 662.950339] mt7601u 1-7:1.0: Vendor request req:02 off:0080 failed:-71 [ 662.950389] mt7601u: probe of 1-7:1.0 failed with error -110 [ 662.950850] usb 1-7: USB disconnect, device number 119 This loops continuously. The device never comes up. Turns out, this issue has been narrowed down to a possible calibration problem [2]. Stanislaw repeatedly asked if disabling DPD calibration only (keeping the RXIQ calibration) would fix the problem, but nobody seems to have paid attention. :) Additionally, he asked for contents of /sys/kernel/debug/ieee80211/phy0/mt7601u/eeprom_param, so here they are: RF freq offset: 5f RSSI offset: 0 0 Reference temp: f9 LNA gain: 0 Reg channels: 1-14 Per rate power: raw:05 bw20:05 bw40:05 raw:05 bw20:05 bw40:05 raw:03 bw20:03 bw40:03 raw:03 bw20:03 bw40:03 raw:04 bw20:04 bw40:04 raw:00 bw20:00 bw40:00 raw:00 bw20:00 bw40:00 raw:00 bw20:00 bw40:00 raw:02 bw20:02 bw40:02 raw:00 bw20:00 bw40:00 Per channel power: tx_power ch1:0c ch2:0c tx_power ch3:0b ch4:0b tx_power ch5:0a ch6:0a tx_power ch7:0a ch8:0a tx_power ch9:0a ch10:0a tx_power ch11:0a ch12:0a tx_power ch13:0a ch14:0a The attached patch fixes the driver for me. Sending as RFC because this will probably warrant some kind of quirk to be fixed correctly. Besides, there's an additional DPD calibration in mt7601u_temp_comp, which I haven't touched, since it seems a bit more convoluted. The driver works for me regardless (I've sent this email through one of my MT7601U adapters). [1] https://github.com/kuba-moo/mt7601u/issues/64 [2] https://github.com/kuba-moo/mt7601u/issues/64#issuecomment-352250127 Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com> --- drivers/net/wireless/mediatek/mt7601u/phy.c | 5 ----- 1 file changed, 5 deletions(-)