[PATCH 0/6] b43: complete N-PHY rev 8 + radio 2057 rev 8 support

[Michael Büsch]

On Tue, 19 May 2026 15:32:44 -0400
"Joshua Peisach" <jpeisach at ubuntu.com> wrote:

> On Tue May 19, 2026 at 11:58 AM EDT, Michael Büsch wrote:
> > On Mon, 18 May 2026 03:49:33 +0200
> > Alessio Ferri <alessio.ferri at mythread.it> wrote:
> >
> > In general this looks Ok.
> > From the style I assume that this is AI generated, right?
> > If so, can you tell us a bit more about the inputs used for the AI?
> > What information is this implementation based on?  
> 
> So... awkward question.

Why?

> Wasn't there just a conversation[1] about the
> future development of this module, that was left off at "don't touch it
> unless you're going to thouroughly test this",

Sure. That's why I ask about the development methods used.

> and now we are going to have a *LLM* work on this?

I don't care whether code was generated with an LLM or not.
What matters is the development methods used.

Changed must be based on actual correct knowledge (e.g. reverse engineering).
Just asking an LLM to do the change without putting that knowledge in is not Ok.
Changes must be tested.
Changes must have a real benefit.
Changes should be low risk, if they can't be tested on all hardware right away.
etc. etc.

Most of this patch set looks to be low risk, because it only seems to
touch code paths for core revisions that were previously unimplemented.

But I'm unsure and I can't remember all the details.
This is why I asked about the development methods used.

What would be Ok? Using an LLM to generate a fully functional and well
tested change from reverse engineered information.

What would not be Ok? Asking an LLM to change the driver just for the
sake of changing it or "cleaning it up". Or using an LLM to make
changes from hallucinated "specifications".


Btw, this looks to be the corresponding tool PR for this change, I guess:
https://github.com/mbuesch/b43-tools/pull/10


-- 
Michael Büsch
https://bues.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20260519/49ae367b/attachment.sig>