drivers/net/wireless/broadcom/b43/main.c | 10 +- .../net/wireless/broadcom/b43/radio_2057.c | 230 ++++++++++++++++-- .../net/wireless/broadcom/b43/tables_nphy.c | 58 +++++ 3 files changed, 280 insertions(+), 18 deletions(-)
This series completes b43 support for the Broadcom N-PHY revision 8
paired with radio 2057 revision 8. b43 already supports the surrounding
PHY family - N-PHY rev 8 with radio 2057 rev 5 and rev 7 are handled,
and rev 16 with radio 2057 rev 9 is handled - but the rev 8 + rev 8
combination falls through four dispatcher gaps:
- radio_2057.c, r2057_upload_inittabs(), case 8 lists radio_rev 5
and 7 only;
- radio_2057.c, r2057_get_chantabent_rev7(), case 8 lists radio_rev
5 only;
- tables_nphy.c, b43_nphy_get_ipa_gain_table(), case 8 lists
radio_rev 5 only;
- radio_2057.c carries r2057_rev8_init[] as a 54-entry stub commented
out with "TODO: Which devices should use it?".
Two further pieces of plumbing are needed to reach those dispatchers
in the first place: d11 core revision 0x16 is missing from the b43
bcma id table, and the corerev 22 / radio 2057 combination needs the
24-bit indirect radio access path that brcmsmac uses for the same
silicon generation (see brcmsmac/phy/phy_cmn.c read_radio_reg() /
write_radio_reg()).
The series:
1/6 b43: add d11 core revision 0x16 to id table
2/6 b43: route d11 corerev 22 to 24-bit indirect radio access
3/6 b43: support radio 2057 rev 8
4/6 b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8
5/6 b43: add channel info table for N-PHY r8 + radio 2057 r8
6/6 b43: add RF power offset for N-PHY r8 + radio 2057 r8
Patches are ordered so that each one fixes the next visible failure
in bring-up: 1/6 makes b43 bind to the core, 2/6 lets phy versioning
read coherent radio identifiers, 3/6 unblocks the boot-time radio
calibration that otherwise stalls the PSM at microcode startup, and
4/6-6/6 fill the remaining 2.4 GHz dispatcher entries so
b43_nphy_set_channel completes to the default channel and core_init
proceeds past PHY init.
Tested on a D-Link DSL-3580L (Broadcom BCM6362 SoC, single-die 2.4 GHz
N-PHY rev 8 + radio 2057 rev 8 in 2.4 GHz IPA mode). The chip is in
service worldwide in xDSL CPE devices.
b43 is currently Orphan in MAINTAINERS. These patches do not add a
new chip family or PHY infrastructure; they fill four explicit
dispatcher gaps for a combination of an already-supported PHY and
an already-supported radio.
Alessio Ferri (6):
b43: add d11 core revision 0x16 to id table
b43: route d11 corerev 22 to 24-bit indirect radio access
b43: support radio 2057 rev 8
b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8
b43: add channel info table for N-PHY r8 + radio 2057 r8
b43: add RF power offset for N-PHY r8 + radio 2057 r8
drivers/net/wireless/broadcom/b43/main.c | 10 +-
.../net/wireless/broadcom/b43/radio_2057.c | 230 ++++++++++++++++--
.../net/wireless/broadcom/b43/tables_nphy.c | 58 +++++
3 files changed, 280 insertions(+), 18 deletions(-)
--
2.43.0
On Mon, 18 May 2026 03:49:33 +0200 Alessio Ferri <alessio.ferri@mythread.it> wrote: > This series completes b43 support for the Broadcom N-PHY revision 8 > paired with radio 2057 revision 8. b43 already supports the surrounding > PHY family - N-PHY rev 8 with radio 2057 rev 5 and rev 7 are handled, > and rev 16 with radio 2057 rev 9 is handled - but the rev 8 + rev 8 > combination falls through four dispatcher gaps: > Alessio Ferri (6): > b43: add d11 core revision 0x16 to id table > b43: route d11 corerev 22 to 24-bit indirect radio access > b43: support radio 2057 rev 8 > b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8 > b43: add channel info table for N-PHY r8 + radio 2057 r8 > b43: add RF power offset for N-PHY r8 + radio 2057 r8 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? -- Michael Büsch https://bues.ch/
On Tue, 19 May 2026 17:58:12 +0200 Michael Büsch <m@bues.ch> wrote: > On Mon, 18 May 2026 03:49:33 +0200 > Alessio Ferri <alessio.ferri@mythread.it> wrote: > > > This series completes b43 support for the Broadcom N-PHY revision 8 > > paired with radio 2057 revision 8. b43 already supports the > > surrounding PHY family - N-PHY rev 8 with radio 2057 rev 5 and rev > > 7 are handled, and rev 16 with radio 2057 rev 9 is handled - but > > the rev 8 + rev 8 combination falls through four dispatcher gaps: > > > Alessio Ferri (6): > > b43: add d11 core revision 0x16 to id table > > b43: route d11 corerev 22 to 24-bit indirect radio access > > b43: support radio 2057 rev 8 > > b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8 > > b43: add channel info table for N-PHY r8 + radio 2057 r8 > > b43: add RF power offset for N-PHY r8 + radio 2057 r8 > > > 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? > The patchset is tested on my own DLink DSL 3580L router and generated by claude from our shared notes, i then reviewed it for sanity and verified it by navigating from the router with modified b43 driver with my phone. The shared notes were: logs and dumps taken from the proprietary binary driver while running the stock firmware in the router, files from brcmsmac that had some details for rev 22, GPL released broadcom code in the GPL dump of the vendor, .rodata pieces from the binary driver and finally logs and dumps from the live b43 running in the router flashed with openwrt. Gathering all of this was a week long task, and writing code was only a small part of it, like in the 5% range.
On Tue, 2026-05-19 at 23:02 +0200, Alessio Ferri wrote: > > The patchset is tested on my own DLink DSL 3580L router and generated by > claude from our shared notes, i then reviewed it for sanity and > verified it by navigating from the router with modified b43 driver with > my phone. I would ask you to disclose this in the commits per https://docs.kernel.org/process/coding-assistants.html johannes
Il giorno Wed, 20 May 2026 13:06:05 +0200 Johannes Berg <johannes@sipsolutions.net> ha scritto: > On Tue, 2026-05-19 at 23:02 +0200, Alessio Ferri wrote: > > > > The patchset is tested on my own DLink DSL 3580L router and > > generated by claude from our shared notes, i then reviewed it for > > sanity and verified it by navigating from the router with modified > > b43 driver with my phone. > > I would ask you to disclose this in the commits per > > https://docs.kernel.org/process/coding-assistants.html > > johannes I'm also realizing that i was off by one when i generated the series and missed the first commit, the actual series is 7 patches, the "real" first one fill the gaps in the firmware mappings, so i would had to resend anyway
Il giorno Wed, 20 May 2026 13:06:05 +0200 Johannes Berg <johannes@sipsolutions.net> ha scritto: > On Tue, 2026-05-19 at 23:02 +0200, Alessio Ferri wrote: > > > > The patchset is tested on my own DLink DSL 3580L router and > > generated by claude from our shared notes, i then reviewed it for > > sanity and verified it by navigating from the router with modified > > b43 driver with my phone. > > I would ask you to disclose this in the commits per > > https://docs.kernel.org/process/coding-assistants.html > > johannes Will send a V2 with the required assisted-by in the form: Assisted-by: Claude:claude-4.7-opus
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@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. 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", and now we are going to have a *LLM* work on this? That aside, I don't see any obvious issues in the patchset. [1]: https://lore.kernel.org/b43-dev/DHTYJFGLKPQ0.RYJIDH2VLV3W@ubuntu.com/T/#t
On Tue, 19 May 2026 15:32:44 -0400 "Joshua Peisach" <jpeisach@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@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/
On Tue May 19, 2026 at 3:52 PM EDT, Michael Büsch wrote: > On Tue, 19 May 2026 15:32:44 -0400 > "Joshua Peisach" <jpeisach@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@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. Fair enough. And it was tested anyway :) sorry for any perceived arrogance. I would tag Reviewed-by but I don't have a script to check the tables (there probably is somewhere... it's a personal problem - a "skill issue" as I sometimes like to call it). -Josh
© 2016 - 2026 Red Hat, Inc.