Return-path: Received: from mail-it0-f65.google.com ([209.85.214.65]:33895 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726902AbeINUr4 (ORCPT ); Fri, 14 Sep 2018 16:47:56 -0400 Received: by mail-it0-f65.google.com with SMTP id x79-v6so4987498ita.1 for ; Fri, 14 Sep 2018 08:32:54 -0700 (PDT) MIME-Version: 1.0 References: <20180906093213.GB16539@redhat.com> <20180907082413.GC2725@localhost.localdomain> In-Reply-To: From: Sid Hayn Date: Fri, 14 Sep 2018 11:32:46 -0400 Message-ID: (sfid-20180914_173258_094811_7BE599A2) Subject: Re: mt76x0 bug report To: Lorenzo Bianconi Cc: sgruszka@redhat.com, linux-wireless , Felix Fietkau , linux-mediatek@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Sender: linux-wireless-owner@vger.kernel.org List-ID: *bump* Been a few days, just a reminder that your monitor mode patch fixed all channels below 144 but something appears incorrect in regdomain handling as I cannot get channels 144 or higher working (my main AP being on channel 149. Again, this works on mt76x2u but not on mt76x0. The patch I tested doesn't appear to have landed in wireless-testing yet, so if you haven't, please do push that up. Secondarily, ethtool still doesn't report firmware version and that would be a very helpful thing to have before 4.19 hits. Additionally, with much less severity, t1u still thinks it is dual band and I'm happy to run any command, test any patch, etc. I honestly don't care about this at all short term, but it does slow the hardware down tuning to a bunch of channels which it cannot access so long term it should probably be fixed in some way. Thanks again for all your hard work, watching the mailing list it is obvious how much effort is going into this right now. -Zero On Fri, Sep 7, 2018 at 3:55 PM Sid Hayn wrote: > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi > wrote: > > > > > Actions like that have caused great problems in the past, as the > > > kernel won't allow channel control of a monitor interface at all when > > > there is a managed interface on the same phy (afaik). > > > > > > But just for fun and codepath testing here are two test scenarios: > > > > > > Test 1: "iwconfig t2u mode monitor" > > > Sees nothing on any channel, no packets reported > > > > > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type monitor" > > > Sees nothing on any channel, no packets reported. > > > Despite having a monitor and managed interface on the same phy, > > > iwconfig is reporting that the channel is changing as requested. So > > > perhaps my above "afaik" comment is partially outdated. > > > > > > For both tests the interface was not used to connect to any ap prior > > > to or during testing. > > > > > > > Could you please try following patch? > > Excellent! This seems to work for all channels up to 140, however, > not 144 or above. "iw list" shows these are supported but I cannot > set them in monitor mode: > > * 5720 MHz [144] (22.0 dBm) (no IR, radar detection) > * 5745 MHz [149] (22.0 dBm) (no IR) > * 5765 MHz [153] (22.0 dBm) (no IR) > * 5785 MHz [157] (22.0 dBm) (no IR) > * 5805 MHz [161] (22.0 dBm) (no IR) > * 5825 MHz [165] (22.0 dBm) (no IR) > > remote2 ~ # iw dev t2uhmon set channel 140 > remote2 ~ # iw dev t2uhmon set channel 144 > command failed: Invalid argument (-22) > > Thanks, > Zero > > > Regards, > > > > Lorenzo > > > > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > @@ -756,11 +756,10 @@ __mt76x0_phy_set_channel(struct mt76x0_dev *dev, > > > > /* Vendor driver don't do it */ > > /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */ > > + mt76x0_vco_cal(dev, channel); > > > > if (scan) > > - mt76x0_vco_cal(dev, channel); > > - > > - mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > + mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > mt76x0_phy_set_chan_pwr(dev, channel); > > > > dev->mt76.chandef = *chandef;