linux-kernel - Re: [PATCH v3 1/3] brcmfmac: Add support for BCM4378 on Apple hardware (with their special OTP).

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] [day] [month] [year] [list]

Message-ID: <510D7CA0-8DED-488B-9F27-1F407F74861C@live.com>
Date:   Fri, 3 Dec 2021 06:41:44 +0000
From:   Aditya Garg <gargaditya08@...e.com>
To:     Hector Martin <marcan@...can.st>
CC:     "aspriel@...il.com" <aspriel@...il.com>,
        "franky.lin@...adcom.com" <franky.lin@...adcom.com>,
        "hante.meuleman@...adcom.com" <hante.meuleman@...adcom.com>,
        "chi-hsien.lin@...ineon.com" <chi-hsien.lin@...ineon.com>,
        "wright.feng@...ineon.com" <wright.feng@...ineon.com>,
        "chung-hsien.hsu@...ineon.com" <chung-hsien.hsu@...ineon.com>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "brcm80211-dev-list.pdl@...adcom.com" 
        <brcm80211-dev-list.pdl@...adcom.com>,
        "SHA-cyfmac-dev-list@...ineon.com" <SHA-cyfmac-dev-list@...ineon.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Stan Skowronek <stan@...ellium.com>,
        Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Joey Gouly <joey.gouly@....com>
Subject: Re: [PATCH v3 1/3] brcmfmac: Add support for BCM4378 on Apple
 hardware (with their special OTP).



> On 03-Nov-2021, at 1:58 PM, Hector Martin <marcan@...can.st> wrote:
> 
> Hi,
> 
> I'd been meaning to rewrite this patch because it's such a mess, but since we're here... (CCing some relevant folks)
> 
> Overall: this patch combines a ton of unrelated random changes, many of which without explanation, with some completely crazy approaches. Stan (CC'ed) has so far refused to interact with the kernel community in any way whatsoever, and I do not feel comfortable using his patches without thorough review, including reverse engineering the changes to figure out what they actually do and why. We've already gone through this with some of his other patches, which ended up being largely rewritten or entirely dropped in the end.
> 
> The firmware situation with this patch is completely unacceptable. It seems the original intent here is to have users load the driver, have it print the required firmware version, and then expect users to copy specifically that firmware file set from macOS, and reload again. This is obviously not the right way to do this. We need to statically copy all firmware from macOS/recovery mode with a naming scheme that this driver can use, at initial install time, and it needs to dynamically select the right firmware for any given platform it is booted on.
> 
> The main issue with these machines is that there is a large set of required firmware variants; a few core firmware files plus many nvram variants for different hardware modules and device revisions. A lot of them are identical and can be symlinked, but we need to work out a naming scheme for these variations. There are several more dimensions of nvram selection than what we're used to on Linux.
Update on the firmware situation :-
Thanks to this commit (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/broadcom/brcm80211/brcmfmac?h=v5.16-rc3&id=5ff013914c62c493c206d70554cfb1d311ea481a), we can have model specific .bin files for Macs.
Example :- brcmfmac4364-pcie.Apple Inc.-MacBookPro16,1.bin is the file specific to MacBook Pro 16 inch, 2019

We would need something like this for the .clm_blob files, that is we would want additional support for per board suffix clm_blob files. This should solve the firmware problem for .bin and .clm_blob files. A patch to get the same feature would be appreciated. I am Ccing the original author of the above commit too.

Next we have is the .txt NVRAM file. This seems tricky cause I haven't been able to find a way to get the module version, on which the variants depend on.