Date:   Tue, 3 Jan 2023 14:30:33 +0100
From:   Arend van Spriel <arend.vanspriel@...adcom.com>
To:     Hector Martin <marcan@...can.st>,
        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 1/3/2023 4:55 AM, Hector Martin wrote:
> 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)?

There is probably no easy answer. Mainly because Cypress is a separate 
entity. However, they use the same/similar technology and code base. So 
let me first start with the chip naming. The wifi chip primarily has a 
number and revision. The chip number is straighforward and can be read 
from the device. The chip revision comes in two variants: 1) simple 
increasing number as read from the device, and 2) a <letter><digit> 
format. The latter start at a0, which you almost never see in the wild 
unless we do it "first time right". Whenever spinning a new chip we 
either increase the digit or the letter depending on type/amount of 
changes. There is not predictable mapping between the revision variants. 
Depending on the hurdles in a chip project we may move from a0 to b0, or 
from b0 to b1 or whatever.

If CYW89459 chip reads chip number 0x4355 than it is a BCM4355. If it is 
a different revision it may require different firmware. A different 
letter will always require different firmware. A different digit may 
work although the firmware can have code paths for a specific revision.

The firmware tables in pcie.c have the revmask. With our crystal ball 
being out-of-order we tend to enable a firmware for all revisions 
(0xFFFFFFFF) unless proven otherwise. If otherwise, we come up with a 
sensible new name and add a new entry to the firmware table changing the 
revmasks accordingly.

> More specifically:
> - What BCM4355 variants exist in the wild, and what are their PCI device
> IDs and revision IDs?

Who knows. The PCI revision ID always equals the chip revision afaik. 
The PCI device IDs should be as below.

> - 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?

Right. If you have come across a BCM4355 with PCI device ID 0x4355 than 
my best guess would be that their OTP is corrupted and the PCIe core on 
the chip uses its default as stored in hardware, which equals the chip 
number. This is really a fallback for a faulty device (or a device which 
does not have its OTP programmed).

> <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>

Happy New year to you. Thanks for clearly marking the rant. Makes it 
easier to ignore, but let me get into this. I would not call bcmdhd the 
downstream driver. It is a separate out-of-tree driver. Indeed resources 
were pulled from brcm80211 development, but there always have been only 
2 or 3 people working on it. Me being the constant working mule and 
these days only for 20% of my working hours to do the job. So you are 
not really doing our job as we are not assigned to do so. I guess there 
is no ROI for Broadcom or so it is perceived and there is no customer 
pushing for it. That said I am always happy to help and clarify whatever 
I can.

Regards,
Arend

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4219 bytes)

Powered by blists - more mailing lists