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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
> Candela Technologies Inc  http://www.candelatech.com
>
>