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 <[email protected]>
Signed-off-by: Lorenzo Bianconi <[email protected]>
---
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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;
--
2.18.0
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 <[email protected]> wrote:
>
> Stanislaw Gruszka <[email protected]> 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 <[email protected]>
> >> > Signed-off-by: Lorenzo Bianconi <[email protected]>
> >>
> >> Acked-by: Stanislaw Gruszka <[email protected]>
> >
> > 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 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 <[email protected]>
> > Signed-off-by: Lorenzo Bianconi <[email protected]>
>
> Acked-by: Stanislaw Gruszka <[email protected]>
For the record this is 4.19 material.
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 <[email protected]>
> Signed-off-by: Lorenzo Bianconi <[email protected]>
Acked-by: Stanislaw Gruszka <[email protected]>
Sid Hayn <[email protected]> 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
--
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
Stanislaw Gruszka <[email protected]> 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 <[email protected]>
>> > Signed-off-by: Lorenzo Bianconi <[email protected]>
>>
>> Acked-by: Stanislaw Gruszka <[email protected]>
>
> 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