linux-kernel - Re: [PATCH 1/2] brcmfmac: Use separate struct to declare firmware names for Apple OTP chips

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3785835b-164b-28d1-6905-85454cabb69d@marcan.st>
Date:   Tue, 3 Jan 2023 12:55:59 +0900
From:   Hector Martin <marcan@...can.st>
To:     Arend Van Spriel <arend.vanspriel@...adcom.com>,
        Aditya Garg <gargaditya08@...e.com>, aspriel@...il.com,
        hante.meuleman@...adcom.com, kvalo@...nel.org, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
        lina@...hilina.net, franky.lin@...adcom.com
Cc:     Orlando Chamberlain <redecorating@...tonmail.com>,
        brcm80211-dev-list@...adcom.com,
        brcm80211-dev-list.pdl@...adcom.com,
        linux-wireless@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Asahi Linux <asahi@...ts.linux.dev>
Subject: Re: [PATCH 1/2] brcmfmac: Use separate struct to declare firmware
 names for Apple OTP chips

On 2023/01/03 3:27, Arend Van Spriel wrote:
> On January 2, 2023 4:15:41 PM Hector Martin <marcan@...can.st> wrote:
> 
>> On 02/01/2023 23.40, Aditya Garg wrote:
>>> From: Aditya Garg <gargaditya08@...e.com>
>>>
>>> Commit 'dce45ded7619' added support for 89459 chip pcie device. It uses the
>>> BRCM4355 chip which is also found in Apple hardware. However this commit
>>> causes conflicts in the firmware naming between Apple hardware, which
>>> supports OTP and other non-Apple hardwares. So, this patch makes these
>>> Apple chips use their own firmware table so as to avoid possible conflicts
>>> like these in the future.
>>
>> I think my reply to Arend flew over your head.
>>
>> My point was that I'd rather have the Broadcom/Cypress people actually
>> answer my question so we can figure out how to do this *properly*,
>> instead of doing "safer-but-dumb" things (like this patch) because we
>> just don't have the information to do it properly.
> 
> Fair enough. Can you accurately (re)state your question and I will try to 
> answer it.

As per my original email: Is the CYW89459 just a rebrand of the BCM4355,
or just a subset? Can we consider them equivalent, and equivalent to the
Apple part (BCM4355C1 / revision 12)?

More specifically:
- What BCM4355 variants exist in the wild, and what are their PCI device
IDs and revision IDs?
- Is a single firmware nominally intended to be compatible with all of
those variants? Does that include the CYW89459 branded parts?
- If CYW89459 is a rebrand of BCM4355, is it complete, or are there
still chips being sold as BCM4355?

Even more specifically, bcmdhd has these device IDs:

#define BCM4355_D11AC_ID    0x43dc  /* 4355 802.11ac dualband device */
#define BCM4355_D11AC2G_ID  0x43fc  /* 4355 802.11ac 2.4G device */
#define BCM4355_D11AC5G_ID  0x43fd  /* 4355 802.11ac 5G device */

But the patch I'm replying to uses PCI ID 0x4355, which instead should be:

#define BCM43237_D11N_ID    0x4355  /* 43237 802.11n dualband device */
#define BCM43237_D11N5G_ID  0x4356  /* 43237 802.11n 5GHz device */

So what's up with the BCM43237? Is that a 4355 variant? Is this what got
rebranded as CYW89459? Is it firmware-compatible with the others?

<rant>

I'm going to be honest here: I'm quite saddened by the state of brcmfmac
and Broadcom's neglect of this driver. Other than the Apple OTP /
firmware selection shenanigans, everything else I'm having to implement
to support Apple machines are features that Broadcom's downstream bcmdhd
driver *already* supports on non-Apple machines, not Apple-specific. Not
only that, people are asking for modern WiFi features like newer crypto
modes that bcmdhd supports but brcmfmac doesn't. It seems clear that
Broadcom isn't interested in maintaining this driver and updating it to
support newer chips and features. So I'm basically doing your job for
you all. Which is fine, but if I'm going to be in charge of implementing
all this stuff for you, *please* help me by at least clarifying the
device variant / firmware feature related issues, because getting that
wrong will cause regressions or firmware naming scheme breaks down the
line, and that sucks for users.

</rant>

- Hector