[PATCH wireless 0/4] wifi: mt76: fix RCPI chain 3 mask in sta_poll RSSI extraction

[PATCH wireless 0/4] wifi: mt76: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Joshua Klinesmith]

The fourth receive chain RCPI extraction in sta_poll uses
GENMASK(31, 14), an 18-bit mask spanning bits 14-31. It should
be GENMASK(31, 24), an 8-bit mask for the fourth byte, consistent
with the other three chains and with the RCPI3 definitions used
elsewhere in the driver.

On devices with fewer than 4 antenna chains the corrupted value
is masked out by antenna_mask. On 4-chain devices this produces
incorrect ACK signal strength readings.

Joshua Klinesmith (4):
  wifi: mt76: mt7915: fix RCPI chain 3 mask in sta_poll RSSI extraction
  wifi: mt76: mt7996: fix RCPI chain 3 mask in sta_poll RSSI extraction
  wifi: mt76: mt7921: fix RCPI chain 3 mask in sta_poll RSSI extraction
  wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction

 drivers/net/wireless/mediatek/mt76/mt7915/mac.c | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7921/mac.c | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)


base-commit: d863fb7a97fab243b48ce2e5e21243dee5abbcdd
-- 
2.43.0

[PATCH wireless 1/4] wifi: mt76: mt7915: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Joshua Klinesmith]

The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
for the fourth byte, consistent with the other three chains and
with the RCPI3 definitions used elsewhere in the driver
(MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).

On devices with fewer than 4 antenna chains, the corrupted value
is masked out by antenna_mask in mt76_rx_signal(). On 4-chain
devices, this produces incorrect ACK signal strength readings.

Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
Cc: stable@vger.kernel.org
Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
---
 drivers/net/wireless/mediatek/mt76/mt7915/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mac.c b/drivers/net/wireless/mediatek/mt76/mt7915/mac.c
index 1c0d310146..946d2bd0d9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/mac.c
@@ -221,7 +221,7 @@ static void mt7915_mac_sta_poll(struct mt7915_dev *dev)
 		rssi[0] = to_rssi(GENMASK(7, 0), val);
 		rssi[1] = to_rssi(GENMASK(15, 8), val);
 		rssi[2] = to_rssi(GENMASK(23, 16), val);
-		rssi[3] = to_rssi(GENMASK(31, 14), val);
+		rssi[3] = to_rssi(GENMASK(31, 24), val);
 
 		msta->ack_signal =
 			mt76_rx_signal(msta->vif->phy->mt76->antenna_mask, rssi);
-- 
2.43.0

[PATCH wireless 2/4] wifi: mt76: mt7996: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Joshua Klinesmith]

The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
for the fourth byte, consistent with the other three chains and
with the RCPI3 definitions used elsewhere in the driver
(MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).

On devices with fewer than 4 antenna chains, the corrupted value
is masked out by antenna_mask in mt76_rx_signal(). On 4-chain
devices, this produces incorrect ACK signal strength readings.

Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
Cc: stable@vger.kernel.org
Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
---
 drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
index ca2305ea7c..ab47118fb1 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
@@ -205,7 +205,7 @@ static void mt7996_mac_sta_poll(struct mt7996_dev *dev)
 		rssi[0] = to_rssi(GENMASK(7, 0), val);
 		rssi[1] = to_rssi(GENMASK(15, 8), val);
 		rssi[2] = to_rssi(GENMASK(23, 16), val);
-		rssi[3] = to_rssi(GENMASK(31, 14), val);
+		rssi[3] = to_rssi(GENMASK(31, 24), val);
 
 		mlink = rcu_dereference(msta->vif->mt76.link[wcid->link_id]);
 		if (mlink) {
-- 
2.43.0

[PATCH wireless 3/4] wifi: mt76: mt7921: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Joshua Klinesmith]

The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
for the fourth byte, consistent with the other three chains and
with the RCPI3 definitions used elsewhere in the driver
(MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).

On devices with fewer than 4 antenna chains, the corrupted value
is masked out by antenna_mask in mt76_rx_signal(). On 4-chain
devices, this produces incorrect ACK signal strength readings.

Fixes: 163f4d22c118 ("mt76: mt7921: add MAC support")
Cc: stable@vger.kernel.org
Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
---
 drivers/net/wireless/mediatek/mt76/mt7921/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/mac.c b/drivers/net/wireless/mediatek/mt76/mt7921/mac.c
index bce26389ab..7a46b50171 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/mac.c
@@ -155,7 +155,7 @@ static void mt7921_mac_sta_poll(struct mt792x_dev *dev)
 		rssi[0] = to_rssi(GENMASK(7, 0), val);
 		rssi[1] = to_rssi(GENMASK(15, 8), val);
 		rssi[2] = to_rssi(GENMASK(23, 16), val);
-		rssi[3] = to_rssi(GENMASK(31, 14), val);
+		rssi[3] = to_rssi(GENMASK(31, 24), val);
 
 		mlink->ack_signal =
 			mt76_rx_signal(msta->vif->phy->mt76->antenna_mask, rssi);
-- 
2.43.0

[PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Joshua Klinesmith]

The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
for the fourth byte, consistent with the other three chains and
with the RCPI3 definitions used elsewhere in the driver
(MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).

On devices with fewer than 4 antenna chains, the corrupted value
is masked out by antenna_mask in mt76_rx_signal(). On 4-chain
devices, this produces incorrect ACK signal strength readings.

Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Cc: stable@vger.kernel.org
Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
---
 drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
index 6334019249..85e91ca84f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
@@ -144,7 +144,7 @@ static void mt7925_mac_sta_poll(struct mt792x_dev *dev)
 		rssi[0] = to_rssi(GENMASK(7, 0), val);
 		rssi[1] = to_rssi(GENMASK(15, 8), val);
 		rssi[2] = to_rssi(GENMASK(23, 16), val);
-		rssi[3] = to_rssi(GENMASK(31, 14), val);
+		rssi[3] = to_rssi(GENMASK(31, 24), val);
 
 		mlink->ack_signal =
 			mt76_rx_signal(msta->vif->phy->mt76->antenna_mask, rssi);
-- 
2.43.0

Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Ben Greear]

On 4/6/26 16:47, Joshua Klinesmith wrote:
> The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
> spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
> for the fourth byte, consistent with the other three chains and
> with the RCPI3 definitions used elsewhere in the driver
> (MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).

Hello Joshua,

How much of this is AI driven?  As far as I know, mt7925 is a 2x2 chipset
at max.  So while the patch may be correct, it may also not matter in practice
and at least may not need to be backported into stable.  If it is a minor
cleanup that doesn't actually matter, that should be described more clearly
in the commit message?

Some of your patches are touching tricky parts of the code and making
subtle comparisons against how the vendor's driver is written.  How well has
this been tested and reviewed by a knowledgeable human in general?

Thanks,
Ben

> 
> On devices with fewer than 4 antenna chains, the corrupted value
> is masked out by antenna_mask in mt76_rx_signal(). On 4-chain
> devices, this produces incorrect ACK signal strength readings.
> 
> Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
> Cc: stable@vger.kernel.org
> Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
> ---
>   drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
> index 6334019249..85e91ca84f 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
> @@ -144,7 +144,7 @@ static void mt7925_mac_sta_poll(struct mt792x_dev *dev)
>   		rssi[0] = to_rssi(GENMASK(7, 0), val);
>   		rssi[1] = to_rssi(GENMASK(15, 8), val);
>   		rssi[2] = to_rssi(GENMASK(23, 16), val);
> -		rssi[3] = to_rssi(GENMASK(31, 14), val);
> +		rssi[3] = to_rssi(GENMASK(31, 24), val);
>   
>   		mlink->ack_signal =
>   			mt76_rx_signal(msta->vif->phy->mt76->antenna_mask, rssi);

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Joshua Klinesmith]

On 4/7/26 11:25, Ben Greear wrote:
> How much of this is AI driven?  As far as I know, mt7925 is a 2x2 chipset
> at max.  So while the patch may be correct, it may also not matter in practice
> and at least may not need to be backported into stable.

Hi Ben,

Please accept my apologies. You are correct that the mt7925 is a 2x2
chipset, so this does not have a practical impact and should not have
been tagged for stable. I did not read the documentation in its
entirety before submitting, and that is on me.

I will be much more careful and diligent with testing and review going forward.

Thanks for the feedback.

Joshua


On Tue, Apr 7, 2026 at 11:25 AM Ben Greear <greearb@candelatech.com> wrote:
>
> On 4/6/26 16:47, Joshua Klinesmith wrote:
> > The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
> > spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
> > for the fourth byte, consistent with the other three chains and
> > with the RCPI3 definitions used elsewhere in the driver
> > (MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).
>
> Hello Joshua,
>
> How much of this is AI driven?  As far as I know, mt7925 is a 2x2 chipset
> at max.  So while the patch may be correct, it may also not matter in practice
> and at least may not need to be backported into stable.  If it is a minor
> cleanup that doesn't actually matter, that should be described more clearly
> in the commit message?
>
> Some of your patches are touching tricky parts of the code and making
> subtle comparisons against how the vendor's driver is written.  How well has
> this been tested and reviewed by a knowledgeable human in general?
>
> Thanks,
> Ben
>
> >
> > On devices with fewer than 4 antenna chains, the corrupted value
> > is masked out by antenna_mask in mt76_rx_signal(). On 4-chain
> > devices, this produces incorrect ACK signal strength readings.
> >
> > Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
> > ---
> >   drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
> > index 6334019249..85e91ca84f 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
> > @@ -144,7 +144,7 @@ static void mt7925_mac_sta_poll(struct mt792x_dev *dev)
> >               rssi[0] = to_rssi(GENMASK(7, 0), val);
> >               rssi[1] = to_rssi(GENMASK(15, 8), val);
> >               rssi[2] = to_rssi(GENMASK(23, 16), val);
> > -             rssi[3] = to_rssi(GENMASK(31, 14), val);
> > +             rssi[3] = to_rssi(GENMASK(31, 24), val);
> >
> >               mlink->ack_signal =
> >                       mt76_rx_signal(msta->vif->phy->mt76->antenna_mask, rssi);
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>

Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Ben Greear]

On 4/7/26 09:00, Joshua Klinesmith wrote:
> On 4/7/26 11:25, Ben Greear wrote:
>> How much of this is AI driven?  As far as I know, mt7925 is a 2x2 chipset
>> at max.  So while the patch may be correct, it may also not matter in practice
>> and at least may not need to be backported into stable.
> 
> Hi Ben,
> 
> Please accept my apologies. You are correct that the mt7925 is a 2x2
> chipset, so this does not have a practical impact and should not have
> been tagged for stable. I did not read the documentation in its
> entirety before submitting, and that is on me.
> 
> I will be much more careful and diligent with testing and review going forward.
> 
> Thanks for the feedback.
> 
> Joshua

I am more concerned about the trickier patches that you have been posting
that is utilizing work from upstream vendor code.  How much of that is pure
AI driven?  How much testing has been done to see if there are actual stability
or performance improvements when testing actual hardware?

Thanks,
Ben

> On Tue, Apr 7, 2026 at 11:25 AM Ben Greear <greearb@candelatech.com> wrote:
>>
>> On 4/6/26 16:47, Joshua Klinesmith wrote:
>>> The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
>>> spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
>>> for the fourth byte, consistent with the other three chains and
>>> with the RCPI3 definitions used elsewhere in the driver
>>> (MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).
>>
>> Hello Joshua,
>>
>> How much of this is AI driven?  As far as I know, mt7925 is a 2x2 chipset
>> at max.  So while the patch may be correct, it may also not matter in practice
>> and at least may not need to be backported into stable.  If it is a minor
>> cleanup that doesn't actually matter, that should be described more clearly
>> in the commit message?
>>
>> Some of your patches are touching tricky parts of the code and making
>> subtle comparisons against how the vendor's driver is written.  How well has
>> this been tested and reviewed by a knowledgeable human in general?
>>
>> Thanks,
>> Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Joshua Klinesmith]

On 4/7/26 12:31, Ben Greear wrote:
> I am more concerned about the trickier patches that you have been posting
> that is utilizing work from upstream vendor code.  How much of that is pure
> AI driven?  How much testing has been done to see if there are actual stability
> or performance improvements when testing actual hardware?

Hi Ben,

To be straightforward: my workflow involves pulling GitHub issues into
AI prompts along with firmware analysis tooling to identify potential
fixes. I have an MT6000 available, but I have not been doing thorough
on-hardware testing before submitting. That is a gap I need to close.

I will hold off on submitting further patches to the mt76 driver until
I have a proper test workflow in place and can verify changes on real
hardware.

I appreciate you raising this directly.

Joshua

On Tue, Apr 7, 2026 at 12:31 PM Ben Greear <greearb@candelatech.com> wrote:
>
> On 4/7/26 09:00, Joshua Klinesmith wrote:
> > On 4/7/26 11:25, Ben Greear wrote:
> >> How much of this is AI driven?  As far as I know, mt7925 is a 2x2 chipset
> >> at max.  So while the patch may be correct, it may also not matter in practice
> >> and at least may not need to be backported into stable.
> >
> > Hi Ben,
> >
> > Please accept my apologies. You are correct that the mt7925 is a 2x2
> > chipset, so this does not have a practical impact and should not have
> > been tagged for stable. I did not read the documentation in its
> > entirety before submitting, and that is on me.
> >
> > I will be much more careful and diligent with testing and review going forward.
> >
> > Thanks for the feedback.
> >
> > Joshua
>
> I am more concerned about the trickier patches that you have been posting
> that is utilizing work from upstream vendor code.  How much of that is pure
> AI driven?  How much testing has been done to see if there are actual stability
> or performance improvements when testing actual hardware?
>
> Thanks,
> Ben
>
> > On Tue, Apr 7, 2026 at 11:25 AM Ben Greear <greearb@candelatech.com> wrote:
> >>
> >> On 4/6/26 16:47, Joshua Klinesmith wrote:
> >>> The fourth receive chain RCPI uses GENMASK(31, 14), an 18-bit mask
> >>> spanning bits 14-31. It should be GENMASK(31, 24), an 8-bit mask
> >>> for the fourth byte, consistent with the other three chains and
> >>> with the RCPI3 definitions used elsewhere in the driver
> >>> (MT_PRXV_RCPI3 and MT_TXS7_F0_RCPI_3 both use GENMASK(31, 24)).
> >>
> >> Hello Joshua,
> >>
> >> How much of this is AI driven?  As far as I know, mt7925 is a 2x2 chipset
> >> at max.  So while the patch may be correct, it may also not matter in practice
> >> and at least may not need to be backported into stable.  If it is a minor
> >> cleanup that doesn't actually matter, that should be described more clearly
> >> in the commit message?
> >>
> >> Some of your patches are touching tricky parts of the code and making
> >> subtle comparisons against how the vendor's driver is written.  How well has
> >> this been tested and reviewed by a knowledgeable human in general?
> >>
> >> Thanks,
> >> Ben
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>

Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Ben Greear]

On 4/7/26 09:58, Joshua Klinesmith wrote:
> On 4/7/26 12:31, Ben Greear wrote:
>> I am more concerned about the trickier patches that you have been posting
>> that is utilizing work from upstream vendor code.  How much of that is pure
>> AI driven?  How much testing has been done to see if there are actual stability
>> or performance improvements when testing actual hardware?
> 
> Hi Ben,
> 
> To be straightforward: my workflow involves pulling GitHub issues into
> AI prompts along with firmware analysis tooling to identify potential
> fixes. I have an MT6000 available, but I have not been doing thorough
> on-hardware testing before submitting. That is a gap I need to close.
> 
> I will hold off on submitting further patches to the mt76 driver until
> I have a proper test workflow in place and can verify changes on real
> hardware.
> 
> I appreciate you raising this directly.

Please be sure to add note about using AI to patch submissions,
and link to original bug reports you are trying to fix.

Possibly some of this is useful, but you need to do significant tests
with real hardware if you are proposing non-trivial changes.

If you are referencing publicly available upstream driver source, then
be clear about that and provide links.  'Reverse Engineering' could mean a lot of things,
some of which is grey area for patch submission.  If you talked some AI bot
into finding non public source, or if it can actually generate useful c code out of
vendor binaries, then I am not sure how legit that is to even post.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH wireless 4/4] wifi: mt76: mt7925: fix RCPI chain 3 mask in sta_poll RSSI extraction

[Joshua Klinesmith]

On 4/7/26 Ben Greear wrote:
> If you talked some AI bot into finding non public source, or if it can
> actually generate useful c code out of vendor binaries, then I am not
> sure how legit that is to even post.

Hi Ben,

Thank you for raising this point. After considering your feedback, I
realize my workflow has involved analysis of proprietary vendor
binaries, which raises legitimate provenance and licensing concerns
for kernel submissions. I should not have submitted patches derived
from that process.

I am withdrawing my outstanding patches from this series. I will not
submit further patches based on this workflow.

Going forward, I will limit my contributions to fixes based solely on
publicly available GPL-licensed sources and will clearly document the
source and rationale in my commit messages.

Thank you again for taking the time to flag this.

On Tue, Apr 7, 2026 at 1:31 PM Ben Greear <greearb@candelatech.com> wrote:
>
> On 4/7/26 09:58, Joshua Klinesmith wrote:
> > On 4/7/26 12:31, Ben Greear wrote:
> >> I am more concerned about the trickier patches that you have been posting
> >> that is utilizing work from upstream vendor code.  How much of that is pure
> >> AI driven?  How much testing has been done to see if there are actual stability
> >> or performance improvements when testing actual hardware?
> >
> > Hi Ben,
> >
> > To be straightforward: my workflow involves pulling GitHub issues into
> > AI prompts along with firmware analysis tooling to identify potential
> > fixes. I have an MT6000 available, but I have not been doing thorough
> > on-hardware testing before submitting. That is a gap I need to close.
> >
> > I will hold off on submitting further patches to the mt76 driver until
> > I have a proper test workflow in place and can verify changes on real
> > hardware.
> >
> > I appreciate you raising this directly.
>
> Please be sure to add note about using AI to patch submissions,
> and link to original bug reports you are trying to fix.
>
> Possibly some of this is useful, but you need to do significant tests
> with real hardware if you are proposing non-trivial changes.
>
> If you are referencing publicly available upstream driver source, then
> be clear about that and provide links.  'Reverse Engineering' could mean a lot of things,
> some of which is grey area for patch submission.  If you talked some AI bot
> into finding non public source, or if it can actually generate useful c code out of
> vendor binaries, then I am not sure how legit that is to even post.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>