Message ID | 20180907211312.17918-1-lorenzo.bianconi@redhat.com (mailing list archive) |
---|---|
State | Accepted |
Delegated to: | Kalle Valo |
Headers | show |
Series | mt76x0: run vco calibration for each channel configuration | expand |
On Fri, Sep 07, 2018 at 11:13:12PM +0200, Lorenzo Bianconi wrote: > According to vendor sdk, vco calibration has to be executed > for each channel configuration whereas mcu calibration has to be > performed during channel scanning. This patch fixes the mt76x0 > monitor mode issue since in that configuration vco calibration > was never executed > > Fixes: 10de7a8b4ab9 ("mt76x0: phy files") > Tested-by: Sid Hayn <sidhayn@gmail.com> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
On Tue, Sep 18, 2018 at 01:43:56PM +0200, Stanislaw Gruszka wrote: > On Fri, Sep 07, 2018 at 11:13:12PM +0200, Lorenzo Bianconi wrote: > > According to vendor sdk, vco calibration has to be executed > > for each channel configuration whereas mcu calibration has to be > > performed during channel scanning. This patch fixes the mt76x0 > > monitor mode issue since in that configuration vco calibration > > was never executed > > > > Fixes: 10de7a8b4ab9 ("mt76x0: phy files") > > Tested-by: Sid Hayn <sidhayn@gmail.com> > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> > > Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> For the record this is 4.19 material.
Stanislaw Gruszka <sgruszka@redhat.com> writes: > On Tue, Sep 18, 2018 at 01:43:56PM +0200, Stanislaw Gruszka wrote: >> On Fri, Sep 07, 2018 at 11:13:12PM +0200, Lorenzo Bianconi wrote: >> > According to vendor sdk, vco calibration has to be executed >> > for each channel configuration whereas mcu calibration has to be >> > performed during channel scanning. This patch fixes the mt76x0 >> > monitor mode issue since in that configuration vco calibration >> > was never executed >> > >> > Fixes: 10de7a8b4ab9 ("mt76x0: phy files") >> > Tested-by: Sid Hayn <sidhayn@gmail.com> >> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> >> >> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> > > For the record this is 4.19 material. I really want to minimise conflicts and because of so many mt76 patches conflicts are likely to happen, so I'm keeping the bar high for mt76 patches going 4.19. Is this a regression from 4.18? If not, I think this should go to -next and cc stable. And besides, monitor mode isn't that critical anyway.
mt76x0 isn't in 4.18 at all, it's being added in 4.19 isn't it? I'm not sure you can call it a regression, but adding a new driver with a known bug that breaks an entire use case (monitor mode) seems silly when a small and tested fix is available. Pretty please. Thanks, Zero On Tue, Sep 18, 2018 at 8:43 AM Kalle Valo <kvalo@codeaurora.org> wrote: > > Stanislaw Gruszka <sgruszka@redhat.com> writes: > > > On Tue, Sep 18, 2018 at 01:43:56PM +0200, Stanislaw Gruszka wrote: > >> On Fri, Sep 07, 2018 at 11:13:12PM +0200, Lorenzo Bianconi wrote: > >> > According to vendor sdk, vco calibration has to be executed > >> > for each channel configuration whereas mcu calibration has to be > >> > performed during channel scanning. This patch fixes the mt76x0 > >> > monitor mode issue since in that configuration vco calibration > >> > was never executed > >> > > >> > Fixes: 10de7a8b4ab9 ("mt76x0: phy files") > >> > Tested-by: Sid Hayn <sidhayn@gmail.com> > >> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> > >> > >> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> > > > > For the record this is 4.19 material. > > I really want to minimise conflicts and because of so many mt76 patches > conflicts are likely to happen, so I'm keeping the bar high for mt76 > patches going 4.19. Is this a regression from 4.18? If not, I think this > should go to -next and cc stable. And besides, monitor mode isn't that > critical anyway. > > -- > Kalle Valo
On Tue, Sep 18, 2018 at 10:26:09AM -0400, Sid Hayn wrote: > mt76x0 isn't in 4.18 at all, it's being added in 4.19 isn't it? I'm > not sure you can call it a regression, but adding a new driver with a > known bug that breaks an entire use case (monitor mode) seems silly > when a small and tested fix is available. Pretty please. Patch conflict with pending mt76 -next patches. Apply it and rebase all other patches on top of it, is a lot of work. I agree with Kalle that it will be better to apply this patch on top of -next and CC stable. Problem should be fixed in 4.19.1 or 4.19.2 . Regards Stanislaw
Sid Hayn <sidhayn@gmail.com> writes: > mt76x0 isn't in 4.18 at all, it's being added in 4.19 isn't it? I'm > not sure you can call it a regression, but adding a new driver with a > known bug that breaks an entire use case (monitor mode) seems silly > when a small and tested fix is available. Pretty please. Unfortunately it's not that simple as you think. And do take into account that the maintainers need to deal with a lot of patches and email so keeping things simple is important. And please do not top post: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#do_not_top_post_and_edit_your_quotes
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c index 5da7bfbe907f..14e8c575f6c3 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c @@ -757,10 +757,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;