Message-ID: <3659477c-c822-c5d6-868c-ba40c5a80be6@marcan.st>
Date:   Tue, 3 Jan 2023 22:46:56 +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 03/01/2023 22.30, Arend van Spriel wrote:
> 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.

Right, this is standard chip spin numbering, that much I know.

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

So is it always correct to have the same firmware (in a generic
situation, not a customized OEM build) for, say, a BCM4355 rev 12,
regardless of what the PCI ID programmed into the OTP is (and what the
marketing device name is)?

If so, then my conclusion is that the original patch I replied to is
incorrect, all the defines should've been called BCM4355 (not the
Cypress part number), and we probably need two firmware table entries
since (judging by the revision check elsewhere in that patch) there are
other revisions in the wild than the one Apple uses, and therefore there
should at the very least be a firmware name split at C1. It would then
be very helpful to know what revisions *do* exist and their correct naming.

If different PCI device IDs might need different firmware, then the
exiting firmware selection/table mechanism is insufficient.

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

Is there any chance you can provide a list of chips/shipping revisions
and revision IDs, so we can stop guessing at the mappings in the
firmware table? Because this is effectively breaking userspace ABI every
time we make a change to an existing chip, as it can change the firmware
file name that userspace loads. This already happened with BCM4364,
where (at least) B2 and B3 revisions exist in the wild and we need
separate firmwares, yet it was added with a full mask, resulting in
people copying "the right firmware for them" manually and my patch to
split it into properly named firmwares will break those users.

- Hector

Powered by blists - more mailing lists