From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: Hector Martin <marcan@marcan.st>
Cc: robh@kernel.org, kvalo@codeaurora.org, davem@davemloft.net,
kuba@kernel.org, rafael@kernel.org, lenb@kernel.org,
aspriel@gmail.com, franky.lin@broadcom.com,
hante.meuleman@broadcom.com, chi-hsien.lin@infineon.com,
wright.feng@infineon.com, sven@svenpeter.dev,
alyssa@rosenzweig.io, kettenis@openbsd.org, zajec5@gmail.com,
pieter-paul.giesberts@broadcom.com, linus.walleij@linaro.org,
hdegoede@redhat.com, linville@tuxdriver.com,
sandals@crustytoothpaste.net, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com,
SHA-cyfmac-dev-list@infineon.com
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips
Date: Wed, 29 Dec 2021 17:38:51 +0100 (CET) [thread overview]
Message-ID: <d3cb7aff430324ca@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <1e5e88a1-5457-2211-dc08-fe98415ae21b@marcan.st> (message from Hector Martin on Tue, 28 Dec 2021 02:23:02 +0900)
> From: Hector Martin <marcan@marcan.st>
> Date: Tue, 28 Dec 2021 02:23:02 +0900
>
> 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.
Actually what Apple does here makes quite a bit of sense. Typically
WiFi chips are integrated with some analog components into a shielded
module. The AP6212 mentioned above is an example of such a module. I
suspect that the module defines some of the characteristics encoded in
the "nvmram" files, but certainly not all because the connected
antenna will also affect how the thing behaves. Of course many SBCs
come without an antenna so the actual antenna depends on whatever the
user connects to the board. So using a module-specific "nvram" file
is probably the best one can do here. So I think if you want to have
a generic module name property, it should be called "brcm,module-name"
instead of "brcm,board-name". However...
> > 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.
...if the way the firmware name is constructed remains Apple-specific
because of this non-DT information, keeping the "apple,xxx" properties
has the benefit of signalling that firmware names constructed this way
are desired. Or rather, their absence can signal that the
Apple-specific code in the driver should be skipped.
next prev parent reply other threads:[~2021-12-29 16:38 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-26 15:35 [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
2021-12-26 15:35 ` [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
2021-12-26 21:02 ` Linus Walleij
2021-12-26 23:34 ` Rob Herring
2021-12-27 16:36 ` Rob Herring
2021-12-27 17:23 ` Hector Martin
2021-12-29 16:38 ` Mark Kettenis [this message]
2022-01-02 14:12 ` Hector Martin
2021-12-29 16:42 ` Mark Kettenis
2022-01-04 5:47 ` Hector Martin
2021-12-26 15:35 ` [PATCH 02/34] brcmfmac: pcie: Declare missing firmware files in pcie.c Hector Martin
2021-12-26 21:04 ` Linus Walleij
2021-12-26 15:35 ` [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths Hector Martin
2022-01-02 5:31 ` Linus Walleij
2022-01-02 7:10 ` Dmitry Osipenko
2022-01-02 6:38 ` Dmitry Osipenko
2022-01-02 6:45 ` Dmitry Osipenko
2022-01-02 14:18 ` Hector Martin
2022-01-02 20:11 ` Dmitry Osipenko
2022-01-03 0:41 ` Hector Martin
2022-01-03 1:26 ` Dmitry Osipenko
2022-01-03 6:17 ` Hector Martin
2022-01-02 6:55 ` Dmitry Osipenko
2022-01-03 6:18 ` Hector Martin
2022-01-02 7:08 ` Dmitry Osipenko
2022-01-02 7:20 ` Dmitry Osipenko
2022-01-02 14:25 ` Hector Martin
2022-01-02 20:12 ` Dmitry Osipenko
2021-12-26 15:35 ` [PATCH 04/34] brcmfmac: firmware: Handle per-board clm_blob files Hector Martin
2022-01-02 6:21 ` Linus Walleij
2021-12-26 15:35 ` [PATCH 05/34] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism Hector Martin
2022-01-02 6:22 ` Linus Walleij
2021-12-26 15:35 ` [PATCH 06/34] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
2022-01-02 5:34 ` Linus Walleij
2021-12-26 15:35 ` [PATCH 07/34] brcmfmac: pcie: Read Apple OTP information Hector Martin
2022-01-02 5:38 ` Linus Walleij
2022-01-03 5:51 ` Hector Martin
2022-01-03 11:13 ` Linus Walleij
2021-12-26 15:35 ` [PATCH 08/34] brcmfmac: of: Fetch Apple properties Hector Martin
2022-01-02 5:40 ` Linus Walleij
2021-12-26 15:35 ` [PATCH 09/34] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
2022-01-02 5:44 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 10/34] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
2022-01-02 5:50 ` Linus Walleij
2022-01-03 5:42 ` Hector Martin
2021-12-26 15:36 ` [PATCH 11/34] brcmfmac: msgbuf: Increase RX ring sizes to 1024 Hector Martin
2022-01-02 5:50 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 12/34] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
2022-01-02 5:51 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 13/34] brcmfmac: pcie: Support PCIe core revisions >= 64 Hector Martin
2022-01-02 5:53 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 14/34] brcmfmac: pcie: Add IDs/properties for BCM4378 Hector Martin
2022-01-02 5:53 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 15/34] ACPI / property: Support strings in Apple _DSM props Hector Martin
2021-12-26 18:20 ` Lukas Wunner
2022-01-02 6:20 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
2022-01-02 5:58 ` Linus Walleij
2022-01-03 6:03 ` Hector Martin
2022-01-03 11:14 ` Linus Walleij
[not found] ` <CAHp75VcZcJ+zCDL-J+w8gEeKXGYdJajjLoa1JTj_kkJixrV12Q@mail.gmail.com>
2022-01-03 17:22 ` Hector Martin
[not found] ` <CAHp75Vedgs_zTH2O120jtUuQiuseA0VN62TJiJ7kAi1f5nDQ6Q@mail.gmail.com>
2022-01-04 5:22 ` Hector Martin
2022-01-10 9:59 ` Kalle Valo
2021-12-26 15:36 ` [PATCH 17/34] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
2022-01-02 5:59 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 18/34] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
2022-01-02 6:00 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 19/34] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
2022-01-02 6:01 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 20/34] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin
2022-01-02 6:02 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 21/34] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number Hector Martin
2022-01-02 6:03 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 22/34] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks Hector Martin
2022-01-02 6:09 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 23/34] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
2022-01-02 6:23 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 24/34] brcmfmac: feature: Add support for setting feats based on WLC version Hector Martin
2022-01-02 6:11 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 25/34] brcmfmac: cfg80211: Add support for PMKID_V3 operations Hector Martin
2021-12-27 15:01 ` kernel test robot
2021-12-27 15:01 ` kernel test robot
2022-01-02 6:12 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 26/34] brcmfmac: cfg80211: Pass the PMK in binary instead of hex Hector Martin
2022-01-02 6:13 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 27/34] brcmfmac: pcie: Add IDs/properties for BCM4387 Hector Martin
2022-01-02 6:13 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 28/34] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio Hector Martin
2022-01-02 6:15 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 29/34] brcmfmac: pcie: Read the console on init and shutdown Hector Martin
2022-01-02 6:16 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 30/34] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path Hector Martin
2022-01-02 6:16 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 31/34] brcmfmac: fwil: Constify iovar name arguments Hector Martin
2022-01-02 6:17 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 32/34] brcmfmac: common: Add support for downloading TxCap blobs Hector Martin
2022-01-02 6:18 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 33/34] brcmfmac: pcie: Load and provide " Hector Martin
2022-01-02 6:19 ` Linus Walleij
2021-12-26 15:36 ` [PATCH 34/34] brcmfmac: common: Add support for external calibration blobs Hector Martin
2022-01-02 6:19 ` Linus Walleij
2021-12-26 19:17 ` [RFC PATCH 00/34] brcmfmac: Support Apple T2 and M1 platforms Lukas Wunner
2021-12-26 21:42 ` Hans de Goede
2021-12-27 11:53 ` Hector Martin
2022-01-02 6:25 ` Linus Walleij
2022-01-03 6:27 ` Hector Martin
2022-01-03 10:20 ` Arend van Spriel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d3cb7aff430324ca@bloch.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=SHA-cyfmac-dev-list@infineon.com \
--cc=alyssa@rosenzweig.io \
--cc=aspriel@gmail.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=chi-hsien.lin@infineon.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=franky.lin@broadcom.com \
--cc=hante.meuleman@broadcom.com \
--cc=hdegoede@redhat.com \
--cc=kettenis@openbsd.org \
--cc=kuba@kernel.org \
--cc=kvalo@codeaurora.org \
--cc=lenb@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=marcan@marcan.st \
--cc=netdev@vger.kernel.org \
--cc=pieter-paul.giesberts@broadcom.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=sandals@crustytoothpaste.net \
--cc=sven@svenpeter.dev \
--cc=wright.feng@infineon.com \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.