All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sid Hayn <sidhayn@gmail.com>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc: sgruszka@redhat.com,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Felix Fietkau <nbd@nbd.name>,
	linux-mediatek@lists.infradead.org
Subject: Re: mt76x0 bug report
Date: Fri, 14 Sep 2018 11:32:46 -0400	[thread overview]
Message-ID: <CAM0KTbAu-LJ2ThAHbmbrggMw_ttpQ8fXr0+HTjGBZF6PBPiD8Q@mail.gmail.com> (raw)
In-Reply-To: <CAM0KTbAputKNN3seOfN-1zhz5XmT6yg_pbKBnapOsR6Vigv1XQ@mail.gmail.com>

*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 <sidhayn@gmail.com> wrote:
>
> On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
> <lorenzo.bianconi@redhat.com> 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;

WARNING: multiple messages have this Message-ID (diff)
From: Sid Hayn <sidhayn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Lorenzo Bianconi
	<lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	linux-wireless
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Felix Fietkau <nbd-Vt+b4OUoWG0@public.gmane.org>,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: mt76x0 bug report
Date: Fri, 14 Sep 2018 11:32:46 -0400	[thread overview]
Message-ID: <CAM0KTbAu-LJ2ThAHbmbrggMw_ttpQ8fXr0+HTjGBZF6PBPiD8Q@mail.gmail.com> (raw)
In-Reply-To: <CAM0KTbAputKNN3seOfN-1zhz5XmT6yg_pbKBnapOsR6Vigv1XQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

*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 <sidhayn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi
> <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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;

  reply	other threads:[~2018-09-14 20:47 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-04 17:33 mt76x0 bug report Sid Hayn
2018-09-04 17:33 ` Sid Hayn
2018-09-04 21:04 ` Lorenzo Bianconi
2018-09-04 21:04   ` Lorenzo Bianconi
2018-09-05 20:52   ` Sid Hayn
2018-09-05 20:52     ` Sid Hayn
2018-09-06  9:32     ` Stanislaw Gruszka
2018-09-06  9:32       ` Stanislaw Gruszka
2018-09-06 15:39       ` Sid Hayn
2018-09-06 15:39         ` Sid Hayn
2018-09-06 15:42         ` Lorenzo Bianconi
2018-09-06 15:42           ` Lorenzo Bianconi
2018-09-06 15:53           ` Sid Hayn
2018-09-06 15:53             ` Sid Hayn
2018-09-07  8:24             ` Lorenzo Bianconi
2018-09-07  8:24               ` Lorenzo Bianconi
2018-09-07 19:55               ` Sid Hayn
2018-09-07 19:55                 ` Sid Hayn
2018-09-14 15:32                 ` Sid Hayn [this message]
2018-09-14 15:32                   ` Sid Hayn
2018-09-14 15:42                   ` Davide Caratti
2018-09-14 15:42                     ` Davide Caratti
2018-09-14 15:47                   ` Lorenzo Bianconi
2018-09-14 15:47                     ` Lorenzo Bianconi
2018-09-14 15:51                     ` Sid Hayn
2018-09-14 15:51                       ` Sid Hayn
2018-09-18  3:18                       ` Sid Hayn
2018-09-18  3:18                         ` Sid Hayn
2018-09-18 11:56                         ` Stanislaw Gruszka
2018-09-18 11:56                           ` Stanislaw Gruszka
2018-09-18 17:36                           ` Sid Hayn
2018-09-18 17:36                             ` Sid Hayn
2018-09-19 11:15                             ` Stanislaw Gruszka
2018-09-19 11:15                               ` Stanislaw Gruszka
2018-09-19 18:01                               ` Sid Hayn
2018-09-19 18:01                                 ` Sid Hayn
2018-09-06 16:51       ` Sid Hayn
2018-09-06 16:51         ` Sid Hayn
2018-09-06 17:13         ` Lorenzo Bianconi
2018-09-06 17:13           ` Lorenzo Bianconi
2018-09-06 22:37           ` Lorenzo Bianconi
2018-09-06 22:37             ` Lorenzo Bianconi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAM0KTbAu-LJ2ThAHbmbrggMw_ttpQ8fXr0+HTjGBZF6PBPiD8Q@mail.gmail.com \
    --to=sidhayn@gmail.com \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=nbd@nbd.name \
    --cc=sgruszka@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.