All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Joshua Peisach" <jpeisach@ubuntu.com>
To: "Jonas Gorski" <jonas.gorski@gmail.com>,
	"Joshua Peisach" <jpeisach@ubuntu.com>
Cc: "Johannes Berg" <johannes@sipsolutions.net>,
	<b43-dev@lists.infradead.org>, <linux-wireless@vger.kernel.org>
Subject: Re: Firmware for reverse engineering b43?
Date: Wed, 15 Apr 2026 07:44:21 -0400	[thread overview]
Message-ID: <DHTPAVC76140.1JLO3HNQARQ9Q@ubuntu.com> (raw)
In-Reply-To: <CAOiHx==kVm0OKWRKi4VHSEEr6ZygzrpNiA=zj+zEHT6_rgZ3CQ@mail.gmail.com>

On Tue Apr 14, 2026 at 8:24 AM EDT, Jonas Gorski wrote:
> On Tue, Apr 14, 2026 at 1:31 PM Joshua Peisach <jpeisach@ubuntu.com> wrote:
>>
>> On Tue Apr 14, 2026 at 5:14 AM EDT, Johannes Berg wrote:
>> > I think there's no easy answer - what are you even trying to achieve?
>> > Does b43 not work sufficiently well? Do you even know if some specific
>> > calibration have a tendency to go out of whack? Is there later firmware
>> > that has some advantage (given how little actually happens in firmware
>> > in these devices, I'd be surprised by that) but isn't compatible with
>> > the driver now, and you want to change that?
>> >
>> > I'd be tempted to say that if there's no problem there don't try to fix
>> > anything, the hardware is ancient anyway, likely has few users, and
>> > those users would probably be fine with just leaving it?
>> >
>> > johannes
>>
>> The BCM4321 (nphy) doesn't connect to my 5G network, so I figured that
>> by filling in TODOs and FIXME's, I could eventually get something
>> working.
>>
>> Other than that, I was thinking of making improvements for the sake of
>> improving the driver.
>
> The initial version of the brcm80211 softmac driver [1] should also
> help in making sense of some of the code (flag names etc). While it
> officially only supports BCM43224 and newer on BCMA, it still had
> remnants of support for older N-PHY revisions, so may help in finding
> differences or explaining what code does.
>
> I once considered trying to clean up b43 based on brcmsmac, but never
> got around to it.

It does appear to be similar - even the current brcm80211. So much so
that I sometimes need to think about whether b43 is actually a
duplicated driver.

Since b43 is in an orphan state, I thought it would be a great place to
start for kernel development. 5G doesn't work on that iMac, some of the
PHYs, like the AC PHYs appear to be incomplete - it felt reasonable.

Because I'm one of those "there's always room for improvement people",
I was going to try to improve the driver, filling out TODOs, fixing
hardcoded register numbers, etc. But if it's best left alone.. then I
guess we can do that.

That is, assuming b43 is actually supposed to be a separate driver,
because if brcmsmac basically has the same code, then maybe we should
focus to centralizing everything? But then there's b43legacy.. hm...

-Josh

>
> Best regards,
> Jonas
>
> [1] https://github.com/torvalds/linux/tree/a9533e7ea3c410fed2f4cd8b3e1e213e48529b75/drivers/staging/brcm80211


_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev

WARNING: multiple messages have this Message-ID (diff)
From: "Joshua Peisach" <jpeisach@ubuntu.com>
To: "Jonas Gorski" <jonas.gorski@gmail.com>,
	"Joshua Peisach" <jpeisach@ubuntu.com>
Cc: "Johannes Berg" <johannes@sipsolutions.net>,
	<b43-dev@lists.infradead.org>, <linux-wireless@vger.kernel.org>
Subject: Re: Firmware for reverse engineering b43?
Date: Wed, 15 Apr 2026 07:44:21 -0400	[thread overview]
Message-ID: <DHTPAVC76140.1JLO3HNQARQ9Q@ubuntu.com> (raw)
In-Reply-To: <CAOiHx==kVm0OKWRKi4VHSEEr6ZygzrpNiA=zj+zEHT6_rgZ3CQ@mail.gmail.com>

On Tue Apr 14, 2026 at 8:24 AM EDT, Jonas Gorski wrote:
> On Tue, Apr 14, 2026 at 1:31 PM Joshua Peisach <jpeisach@ubuntu.com> wrote:
>>
>> On Tue Apr 14, 2026 at 5:14 AM EDT, Johannes Berg wrote:
>> > I think there's no easy answer - what are you even trying to achieve?
>> > Does b43 not work sufficiently well? Do you even know if some specific
>> > calibration have a tendency to go out of whack? Is there later firmware
>> > that has some advantage (given how little actually happens in firmware
>> > in these devices, I'd be surprised by that) but isn't compatible with
>> > the driver now, and you want to change that?
>> >
>> > I'd be tempted to say that if there's no problem there don't try to fix
>> > anything, the hardware is ancient anyway, likely has few users, and
>> > those users would probably be fine with just leaving it?
>> >
>> > johannes
>>
>> The BCM4321 (nphy) doesn't connect to my 5G network, so I figured that
>> by filling in TODOs and FIXME's, I could eventually get something
>> working.
>>
>> Other than that, I was thinking of making improvements for the sake of
>> improving the driver.
>
> The initial version of the brcm80211 softmac driver [1] should also
> help in making sense of some of the code (flag names etc). While it
> officially only supports BCM43224 and newer on BCMA, it still had
> remnants of support for older N-PHY revisions, so may help in finding
> differences or explaining what code does.
>
> I once considered trying to clean up b43 based on brcmsmac, but never
> got around to it.

It does appear to be similar - even the current brcm80211. So much so
that I sometimes need to think about whether b43 is actually a
duplicated driver.

Since b43 is in an orphan state, I thought it would be a great place to
start for kernel development. 5G doesn't work on that iMac, some of the
PHYs, like the AC PHYs appear to be incomplete - it felt reasonable.

Because I'm one of those "there's always room for improvement people",
I was going to try to improve the driver, filling out TODOs, fixing
hardcoded register numbers, etc. But if it's best left alone.. then I
guess we can do that.

That is, assuming b43 is actually supposed to be a separate driver,
because if brcmsmac basically has the same code, then maybe we should
focus to centralizing everything? But then there's b43legacy.. hm...

-Josh

>
> Best regards,
> Jonas
>
> [1] https://github.com/torvalds/linux/tree/a9533e7ea3c410fed2f4cd8b3e1e213e48529b75/drivers/staging/brcm80211


  reply	other threads:[~2026-04-15 11:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-13 12:44 Firmware for reverse engineering b43? Joshua Peisach
2026-04-13 12:44 ` Joshua Peisach
2026-04-14  9:14 ` Johannes Berg
2026-04-14  9:14   ` Johannes Berg
2026-04-14 11:30   ` Joshua Peisach
2026-04-14 11:30     ` Joshua Peisach
2026-04-14 12:24     ` Jonas Gorski
2026-04-14 12:24       ` Jonas Gorski
2026-04-15 11:44       ` Joshua Peisach [this message]
2026-04-15 11:44         ` Joshua Peisach
2026-04-15 11:54         ` Jonas Gorski
2026-04-15 11:54           ` Jonas Gorski
2026-04-15 15:57           ` Michael Büsch
2026-04-15 15:57             ` Michael Büsch
2026-04-15 17:04             ` Joshua Peisach
2026-04-15 17:04               ` Joshua Peisach
2026-04-15 17:41               ` Michael Büsch
2026-04-15 17:41                 ` Michael Büsch
2026-04-15 18:58                 ` Joshua Peisach
2026-04-15 18:58                   ` Joshua Peisach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DHTPAVC76140.1JLO3HNQARQ9Q@ubuntu.com \
    --to=jpeisach@ubuntu.com \
    --cc=b43-dev@lists.infradead.org \
    --cc=johannes@sipsolutions.net \
    --cc=jonas.gorski@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.