linux-kernel - Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & 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: <1e5e88a1-5457-2211-dc08-fe98415ae21b@marcan.st>
Date:   Tue, 28 Dec 2021 02:23:02 +0900
From:   Hector Martin <marcan@...can.st>
To:     Rob Herring <robh@...nel.org>
Cc:     Kalle Valo <kvalo@...eaurora.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Arend van Spriel <aspriel@...il.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Chi-hsien Lin <chi-hsien.lin@...ineon.com>,
        Wright Feng <wright.feng@...ineon.com>,
        Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Mark Kettenis <kettenis@...nbsd.org>,
        Rafał Miłecki <zajec5@...il.com>,
        Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Hans de Goede <hdegoede@...hat.com>,
        "John W. Linville" <linville@...driver.com>,
        "brian m. carlson" <sandals@...stytoothpaste.net>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, brcm80211-dev-list.pdl@...adcom.com,
        SHA-cyfmac-dev-list@...ineon.com
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple
 properties & chips

On 28/12/2021 01.36, Rob Herring wrote:
> On Mon, Dec 27, 2021 at 12:35:51AM +0900, Hector Martin wrote:
>> +  brcm,cal-blob:
>> +    $ref: /schemas/types.yaml#/definitions/uint8-array
>> +    description: A per-device calibration blob for the Wi-Fi radio. This
>> +      should be filled in by the bootloader from platform configuration
>> +      data, if necessary, and will be uploaded to the device if present.
>> +
>> +  apple,module-instance:
>> +    $ref: /schemas/types.yaml#/definitions/string
>> +    description: Module codename used to identify a specific board on
>> +      Apple platforms. This is used to build the firmware filenames, to allow
>> +      different platforms to have different firmware and/or NVRAM config.
>> +
>> +  apple,antenna-sku:
>> +    $def: /schemas/types.yaml#/definitions/string
>> +    description: Antenna SKU used to identify a specific antenna configuration
>> +      on Apple platforms. This is use to build firmware filenames, to allow
>> +      platforms with different antenna configs to have different firmware and/or
>> +      NVRAM. This would normally be filled in by the bootloader from platform
>> +      configuration data.
> 
> Is there a known set of strings that can be defined?

For apple,module-instance there is, though it will grow with every new
machine. If you're happy with me pushing updates to this through
asahi-soc I can keep it maintained as we add DTs and compatibles there.

I'm curious whether you prefer this approach or something like
brcm,board-name instead. Right now we do:

apple,module-instance = "honshu"

That gets converted to board_name="apple,honshu" in the code, which is
what the firmwares are named after (plus extra info later appended, if
the rest of the Apple data is available).

But we could also do:

brcm,board-name = "apple,honshu"

The latter would be more generically useful for other platforms, since
it would allow e.g. having DTs for different boards that use the same
WiFi module/subsystem and thus a compatible NVRAM fw file alias to the
same file name (right now this is done with symlinks in /lib/firmware,
one for each equivalent board). For non-Apple platforms (i.e. if
antenna-sku and/or the OTP aren't available to do the funky Apple
firmware selection), this just ends up replacing what would normally be
the OF root node compatible in the firmware filename.

E.g. right now we have:

brcmfmac43430-sdio.AP6212.txt
brcmfmac43430-sdio.raspberrypi,3-model-b.txt
brcmfmac43430-sdio.raspberrypi,model-zero-w.txt -> brcmfmac43430-sdio.raspberrypi,3-model-b.txt
brcmfmac43430-sdio.sinovoip,bpi-m2-plus.txt -> brcmfmac43430-sdio.AP6212.txt
brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt -> brcmfmac43430-sdio.AP6212.txt
brcmfmac43430-sdio.sinovoip,bpi-m2-zero.txt -> brcmfmac43430-sdio.AP6212.txt
brcmfmac43430-sdio.sinovoip,bpi-m3.txt -> brcmfmac43430-sdio.AP6212.txt

And this could allow the sinovoip.* DTs to say:
	brcm,board-name = "AP6212";

And the rPi zero one:
	brcm,board-name = "raspberrypi,3-model-b";

And avoid the symlinks.

The antenna-sku thing is specific to the Apple firmware selection
process and doesn't make sense as a more generic property.

antenna-sku right now always seems to be one of "ID", "X0", "X2", "X3",
though that could presumably change in the future. I can add this to the
binding if you want, though since this will be filled in by the
bootloader from platform data we wouldn't be validating it anyway. Not
sure if it's worth it.

> There's also the somewhat standard 'firmware-name' property that
> serves similar purpose, but if there's multiple files, then I guess
> this approach is fine.

Yeah, and the firmware name is constructed using non-DT information too
(and we have several attempted filenames times several firmware types),
so it wouldn't be complete.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub