Add dt bindings for the keyboard backlight on t6001

Add t6000-fpwm compatible

pwm: apple-m1: Add Apple M1 FPWM controller driver

This PWM module on the Apple M1 SoC is connected to the keyboard
backlight on at least some MacBook Pros (J293).

Signed-off-by: Pip Cet <pipcet@gmail.com>

T6000: kill dead cores

Signed-off-by: Jens Axboe <axboe@kernel.dk>

apple-soc-cpufreq: use atomic poll timeout

From jannau

Signed-off-by: Jens Axboe <axboe@kernel.dk>

apple-nvme: limit admin queue depth to 2

Signed-off-by: Jens Axboe <axboe@kernel.dk>

Kill kbd crc mismatch message

Signed-off-by: Jens Axboe <axboe@kernel.dk>

Remove local version

Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branches 'refs/heads/bits/000-devicetree', 'refs/heads/bits/010-mailbox', 'refs/heads/bits/020-t6000-bringup', 'refs/heads/bits/030-misc', 'refs/heads/bits/050-nvme', 'refs/heads/bits/060-spi', 'refs/heads/bits/070-audio', 'refs/heads/bits/080-wifi', 'refs/heads/bits/090-spi-hid', 'refs/heads/bits/100-shutdown-notifier', 'refs/heads/bits/110-smc', 'refs/heads/bits/120-spmi', 'refs/heads/bits/130-cpufreq' and 'refs/heads/bits/140-pci-pwren' into asahi

rtc: Add new rtc-macsmc driver for Apple Silicon Macs

Apple Silicon Macs (M1, etc.) have an RTC that is part of the PMU IC,
but most of the PMU functionality is abstracted out by the SMC.
On T600x machines, the RTC counter must be accessed via the SMC to
get full functionality, and it seems likely that future machines
will move towards making SMC handle all RTC functionality.

The SMC RTC counter access is implemented on all current machines
as of the time of this writing, on firmware 12.x. However, the RTC
offset (needed to set the time) is still only accessible via direct
PMU access. To handle this, we expose the RTC offset as an NVMEM
cell from the SPMI PMU device node, and this driver consumes that
cell and uses it to compute/set the current time.

Alarm functionality is not yet implemented. This would also go via
the PMU today, but could change in the future.

Signed-off-by: Hector Martin <marcan@marcan.st>

power: reset: macsmc-reboot: Add driver for rebooting via Apple SMC

This driver implements the reboot/shutdown support exposed by the SMC
on Apple Silicon machines, such as Apple M1 Macs.

Signed-off-by: Hector Martin <marcan@marcan.st>

power: supply: macsmc_power: Add AC power supply

Signed-off-by: Hector Martin <marcan@marcan.st>

power: supply: macsmc_power: Turn off OBC flags if macOS left them on

Signed-off-by: Hector Martin <marcan@marcan.st>

power: supply: macsmc_power: Use BUIC instead of BRSC for charge

Signed-off-by: Hector Martin <marcan@marcan.st>

power: supply: macsmc_power: Add more props, rework others

Signed-off-by: Hector Martin <marcan@marcan.st>

power: supply: macsmc_power: Add present prop

Signed-off-by: Hector Martin <marcan@marcan.st>

power: supply: macsmc_power: Add cycle count and health props

Signed-off-by: Hector Martin <marcan@marcan.st>

power: supply: macsmc_power: Driver for Apple SMC power/battery stats

This driver implements support for battery stats on top of the macsmc
framework, to support Apple M1 Mac machines.

Co-authored-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Hector Martin <marcan@marcan.st>

gpio: Add new gpio-macsmc driver for Apple Macs

This driver implements the GPIO service on top of the SMC framework
on Apple Mac machines. In particular, these are the GPIOs present in the
PMU IC which are used to control power to certain on-board devices.

Although the underlying hardware supports various pin config settings
(input/output, open drain, etc.), this driver does not implement that
functionality and leaves it up to the firmware to configure things
properly. We also don't yet support interrupts/events. This is
sufficient for device power control, which is the only thing we need to
support at this point. More features will be implemented when needed.

To our knowledge, only Apple Silicon Macs implement this SMC feature.

Signed-off-by: Hector Martin <marcan@marcan.st>

platform/apple: Add new Apple Mac SMC driver

This driver implements support for the SMC (System Management
Controller) in Apple Macs. In contrast to the existing applesmc driver,
it uses pluggable backends that allow it to support different SMC
implementations, and uses the MFD subsystem to expose the core SMC
functionality so that specific features (gpio, hwmon, battery, etc.) can
be implemented by separate drivers in their respective downstream
subsystems.

The initial RTKit backend adds support for Apple Silicon Macs (M1 et
al). We hope a backend for T2 Macs will be written in the future
(since those are not supported by applesmc), and eventually an x86
backend would allow us to fully deprecate applesmc in favor of this
driver.

Signed-off-by: Hector Martin <marcan@marcan.st>

lib/vsprintf: Add support for generic FOURCCs by extending %p4cc

%p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but
it's useful to be able to print generic 4-character codes formatted as
an integer. Extend it to add format specifiers for printing generic
32-bit FOURCCs with various endian semantics:

%p4ch   Host-endian
%p4cl Little-endian
%p4cb Big-endian
%p4cr Reverse-endian

The endianness determines how bytes are interpreted as a u32, and the
FOURCC is then always printed MSByte-first (this is the opposite of
V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would
allow printing LSByte-first FOURCCs stored in host endian order
(other than the hex form being in character order, not the integer
value).

Signed-off-by: Hector Martin <marcan@marcan.st>

Revert "mm/sparsemem: fix 'mem_section' will never be NULL gcc 12 warning"

This reverts commit edecc06b4d34e92a5cd306d3436833e344eb3fa2.

Revert "mm-sparsemem-fix-mem_section-will-never-be-null-gcc-12-warning-v2"

This reverts commit fff3b2a167db5495b47548cc71054e064c440031.

HACK: t8103.dtsi: Work around incompleteness of MCA driver

dt: t8103.dtsi: Put in audio-related device nodes

ASoC: cs42l42: Bypass device ID check

The cs42l42 driver is also applicable to the cs42l83 part.

HACK: ASoC: cs42l42: Disable regcache

There's some issue that has yet to be pinned down.

HACK: ASoC: tas2770: Set no of channels to 1

ASoC: tas2770: Set correct FSYNC polarity

Fix setting of FSYNC polarity for DAI formats other than I2S. Also
add support for polarity inversion.

Signed-off-by: Martin Povišer <povik+lin@cutebit.org>

ASoC: apple-mca: Add platform driver for Apple SoCs

Add ASoC platform driver for the MCA block found on Apple SoCs
from the "Apple Silicon" family.

dmaengine: apple-admac: Add Apple ADMAC driver

Add driver for Audio DMA Controller present on Apple SoCs
from the "Apple Silicon" family.

dt-bindings: dma: Add apple,admac binding

The Audio DMA Controller (ADMAC) is used to load and store audio
samples from/to system memory. It is present on Apple SoCs from
the "Apple Silicon" family.

Signed-off-by: Martin Povišer <povik+lin@cutebit.org>

tps6598x: clear int mask on probe failure

The interrupt mask is enabled before any potential failure points in
the driver, which can leave a failure path where we exit with
interrupts enabled but the device not live. This causes an infinite
stream of interrupts on an Apple M1 Pro laptop on USB-C.

Add a failure label that's used post enabling interrupts, where we
mask them again before returning an error.

Suggested-by: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>

MAINTAINERS: Add clk-apple-nco under ARM/APPLE MACHINE

Acked-by: Sven Peter <sven@svenpeter.dev>
Acked-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>

clk: clk-apple-nco: Add driver for Apple NCO

Add a common clock driver for NCO blocks found on Apple SoCs where they
are typically the generators of audio clocks.

Signed-off-by: Martin Povišer <povik+lin@cutebit.org>

dt-bindings: clock: Add Apple NCO

The NCO block found on Apple SoCs is a programmable clock generator
performing fractional division of a high frequency input clock.

Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>

apple-nvme: remove superflous tcb clears

We clear the whole array at init time, we don't need to clear in
both submit and nvmmu_inval.

Signed-off-by: Jens Axboe <axboe@kernel.dk>

WIP: HID: transport: spi: add Apple SPI transport

Keyboard and trackpad of Apple Sillicon SoCs (M1, M1 Pro/Max) laptops
are are HID devices connected via SPI.

This is the same protocol as implemented by applespi.c. It was not
noticed that protocol is a transport for HID. Adding support for ACPI
based Intel MacBooks will be done in a separate commit.

How HID is mapped in this protocol is not yet fully understood.

Microsoft has a specification for HID over SPI [1] incompatible with the
transport protocol used by Apple.

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/hid-over-spi

Signed-off-by: Janne Grunau <j@jannau.net>

apple-nvme: defer cache flushes by a specified amount

Cache flushes on the M1 nvme are really slow, taking 17-18 msec to
complete. This can slow down workloads considerably, pure random writes
end up being bound by the flush latency and hence run at 55-60 IOPS.

Add a deferred flush work around to provide better performance, at a
minimal risk. By default, flushes are delayed at most 1 second, but this
is configurable.

With this work-around, a pure random write workload runs at ~12K IOPS
rather than 56 IOPS.

Signed-off-by: Jens Axboe <axboe@kernel.dk>

apple-nvme: serialize command issue

Signed-off-by: Jens Axboe <axboe@kernel.dk>

arm64: dts: apple: Add CPUfreq nodes

Signed-off-by: Hector Martin <marcan@marcan.st>

arm64: dts: apple: Add PMU NVMEM and SMC RTC/reboot nodes

Signed-off-by: Hector Martin <marcan@marcan.st>

arm64: dts: apple: Add SMC node to t8103/t6001 devicetrees

Signed-off-by: Hector Martin <marcan@marcan.st>

arm64: dts: apple: Add PCI power enable GPIOs

t8103:
- WLAN (SMC PMU GPIO #13)
t600x:
- WLAN (SMC PMU GPIO #13)
- SD (SMC PMU GPIO #26)

Signed-off-by: Hector Martin <marcan@marcan.st>

arm64: dts: apple: Add WiFi module and antenna properties

Add the new module-instance/antenna-sku properties required to select
WiFi firmwares properly to all board device trees.

Signed-off-by: Hector Martin <marcan@marcan.st>

arm64: dts: apple: t8103: Add spi3/keyboard nodes

Enables keyboard and touchpad input on MacBook Air (M1, 2020) and
MacBook Pro (13-inch, M1, 2020).

Signed-off-by: Janne Grunau <j@jannau.net>

arm64: dts: apple: t600x: Add spi3 and keyboard nodes

Enables keyboard and touchpad input on MacBook Pro (14/16-inch,
M1 Pro/Max, 2021).

Signed-off-by: Janne Grunau <j@jannau.net>

arm64: dts: apple: t600x-j314-j316: Add NOR flash node

Signed-off-by: Hector Martin <marcan@marcan.st>

Makefile: Add -asahi EXTRAVERSION

Signed-off-by: Hector Martin <marcan@marcan.st>

PCI: apple: Add support for optional PWREN GPIO

WiFi and SD card devices on M1 Macs have a separate power enable GPIO.
Add support for this to the PCIe controller. This is modeled after how
pcie-fu740 does it.

Signed-off-by: Hector Martin <marcan@marcan.st>

PCI: apple: Probe all GPIOs for availability first

If we're probing the PCI controller and some GPIOs are not available and
cause a probe defer, we can end up leaving some ports initialized and
not others and making a mess.

Check for PERST# GPIOs for all ports first, and just return
-EPROBE_DEFER if any are not ready yet, without bringing anything up.

Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up")
Cc: stable@vger.kernel.org
Signed-off-by: Hector Martin <marcan@marcan.st>

PCI: apple: GPIO handling nitfixes

- Use devm managed GPIO getter
- GPIO ops can sleep in this context

Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up")
Cc: stable@vger.kernel.org
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: common: Add support for external calibration blobs

The calibration blob for a chip is normally stored in SROM and loaded
internally by the firmware. However, Apple ARM64 platforms instead store
it as part of platform configuration data, and provide it via the Apple
Device Tree. We forward this into the Linux DT in the bootloader.

Add support for taking this blob from the DT and loading it into the
dongle. The loading mechanism is the same as used for the CLM and TxCap
blobs.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie: Load and provide TxCap blobs

These blobs are named .txcap_blob, and exist alongside the existing
.clm_blob files. Use the existing firmware machinery to provide them to
the core.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: common: Add support for downloading TxCap blobs

The TxCap blobs are additional data blobs used on Apple devices, and
are uploaded analogously to CLM blobs. Add core support for doing this.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie: Add IDs/properties for BCM4387

This chip is present on Apple M1 Pro/Max (t600x) platforms:

* maldives   (apple,j314s): MacBook Pro (14-inch, M1 Pro, 2021)
* maldives   (apple,j314c): MacBook Pro (14-inch, M1 Max, 2021)
* madagascar (apple,j316s): MacBook Pro (16-inch, M1 Pro, 2021)
* madagascar (apple,j316c): MacBook Pro (16-inch, M1 Max, 2021)

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmflac: cfg80211: Use WSEC to set SAE password

Using the WSEC command instead of sae_password seems to be the supported
mechanism on newer firmware, and also how the brcmdhd driver does it.

Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: cfg80211: Pass the PMK in binary instead of hex

Apparently the hex passphrase mechanism does not work on newer
chips/firmware (e.g. BCM4387). It seems there was a simple way of
passing it in binary all along, so use that and avoid the hexification.

OpenBSD has been doing it like this from the beginning, so this should
work on all chips.

Also clear the structure before setting the PMK. This was leaking
uninitialized stack contents to the device.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: cfg80211: Add support for PMKID_V3 operations

Add support for the new PMKID_V3 API, which allows performing PMKID
mutations individually, instead of requiring the driver to keep track of
the full list. This new API is required by at least BCM4387.

Note that PMKID_V2 is not implemented yet.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: feature: Add support for setting feats based on WLC version

The "wlc_ver" iovar returns information on the WLC and EPI versions.
This can be used to determine whether the PMKID_V2 and _V3 features are
supported.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: cfg80211: Add support for scan params v2

This new API version is required for at least the BCM4387 firmware. Add
support for it, with a fallback to the v1 API.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: chip: Handle 1024-unit sizes for TCM blocks

BCM4387 has trailing odd-sized blocks as part of TCM which have
their size described as a multiple of 1024 instead of 8192. Handle this
so we can compute the TCM size properly.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: chip: Only disable D11 cores; handle an arbitrary number

At least on BCM4387, the D11 cores are held in reset on cold startup and
firmware expects to release reset itself. Just assert reset here and let
firmware deassert it. Premature deassertion results in the firmware
failing to initialize properly some of the time, with strange AXI bus
errors.

Also, BCM4387 has 3 cores, up from 2. The logic for handling that is in
brcmf_chip_ai_resetcore(), but since we aren't using that any more, just
handle it here.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie: Perform correct BCM4364 firmware selection

This chip exists in two revisions (B2=r3 and B3=r4) on different
platforms, and was added without regard to doing proper firmware
selection or differentiating between them. Fix this to have proper
per-revision firmwares and support Apple NVRAM selection.

Revision B2 is present on at least these Apple T2 Macs:

kauai:    MacBook Pro 15" (Touch/2018-2019)
maui:     MacBook Pro 13" (Touch/2018-2019)
lanai:    Mac mini (Late 2018)
ekans:    iMac Pro 27" (5K, Late 2017)

And these non-T2 Macs:

nihau:    iMac 27" (5K, 2019)

Revision B3 is present on at least these Apple T2 Macs:

bali:     MacBook Pro 16" (2019)
trinidad: MacBook Pro 13" (2020, 4 TB3)
borneo:   MacBook Pro 16" (2019, 5600M)
kahana:   Mac Pro (2019)
kahana:   Mac Pro (2019, Rack)
hanauma:  iMac 27" (5K, 2020)
kure:     iMac 27" (5K, 2020, 5700/XT)

Fixes: 24f0bd136264 ("brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie: Add IDs/properties for BCM4377

This chip is present on at least these Apple T2 Macs:

* tahiti:  MacBook Pro 13" (2020, 2 TB3)
* formosa: MacBook Pro 13" (Touch/2019)
* fiji:    MacBook Air 13" (Scissor, 2020)

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie: Add IDs/properties for BCM4355

This chip is present on at least these Apple T2 Macs:

* hawaii: MacBook Air 13" (Late 2018)
* hawaii: MacBook Air 13" (True Tone, 2019)

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie: Provide a buffer of random bytes to the device

Newer Apple firmwares on chipsets without a hardware RNG require the
host to provide a buffer of 256 random bytes to the device on
initialization. This buffer is present immediately before NVRAM,
suffixed by a footer containing a magic number and the buffer length.

This won't affect chips/firmwares that do not use this feature, so do it
unconditionally.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: acpi: Add support for fetching Apple ACPI properties

On DT platforms, the module-instance and antenna-sku-info properties
are passed in the DT. On ACPI platforms, module-instance is passed via
the analogous Apple device property mechanism, while the antenna SKU
info is instead obtained via an ACPI method that grabs it from
non-volatile storage.

Add support for this, to allow proper firmware selection on Apple
platforms.

Signed-off-by: Hector Martin <marcan@marcan.st>

ACPI / property: Support strings in Apple _DSM props

The Wi-Fi module in Apple machines has a "module-instance" device
property that specifies the platform type and is used for firmware
selection. Its value is a string, so add support for string values in
acpi_extract_apple_properties().

Reviewed-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie: Add IDs/properties for BCM4378

This chip is present on Apple M1 (t8103) platforms:

* atlantisb (apple,j274): Mac mini (M1, 2020)
* honshu    (apple,j293): MacBook Pro (13-inch, M1, 2020)
* shikoku   (apple,j313): MacBook Air (M1, 2020)
* capri     (apple,j456): iMac (24-inch, 4x USB-C, M1, 2020)
* santorini (apple,j457): iMac (24-inch, 2x USB-C, M1, 2020)

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie: Support PCIe core revisions >= 64

These newer PCIe core revisions include new sets of registers that must
be used instead of the legacy ones. Introduce a brcmf_pcie_reginfo to
hold the specific register offsets and values to use for a given
platform, and change all the register accesses to indirect through it.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: msgbuf: Increase RX ring sizes to 1024

Newer chips used on Apple platforms have a max_rxbufpost greater than
512, which causes warnings when brcmf_msgbuf_rxbuf_data_fill tries to
put more entries in the ring than will fit. Increase the ring sizes
to 1024.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: firmware: Allow platform to override macaddr

On Device Tree platforms, it is customary to be able to set the MAC
address via the Device Tree, as it is often stored in system firmware.
This is particularly relevant for Apple ARM64 platforms, where this
information comes from system configuration and passed through by the
bootloader into the DT.

Implement support for this by fetching the platform MAC address and
adding or replacing the macaddr= property in nvram. This becomes the
dongle's default MAC address.

On platforms with an SROM MAC address, this overrides it. On platforms
without one, such as Apple ARM64 devices, this is required for the
firmware to boot (it will fail if it does not have a valid MAC at all).

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie: Perform firmware selection for Apple platforms

On Apple platforms, firmware selection uses the following elements:

  Property         Example   Source
  ==============   =======   ========================
* Chip name        4378      Device ID
* Chip revision    B1        OTP
* Platform         shikoku   DT (ARM64) or ACPI (x86)
* Module type      RASP      OTP
* Module vendor    m         OTP
* Module version   6.11      OTP
* Antenna SKU      X3        DT (ARM64) or ACPI (x86)

In macOS, these firmwares are stored using filenames in this format
under /usr/share/firmware/wifi:

    C-4378__s-B1/P-shikoku-X3_M-RASP_V-m__m-6.11.txt

To prepare firmwares for Linux, we rename these to a scheme following
the existing brcmfmac convention:

    brcmfmac<chip><lower(rev)>-pcie.apple,<platform>-<mod_type>-\
<mod_vendor>-<mod_version>-<antenna_sku>.txt

The NVRAM uses all the components, while the firmware and CLM blob only
use the chip/revision/platform/antenna_sku:

    brcmfmac<chip><lower(rev)>-pcie.apple,<platform>-<antenna_sku>.bin

e.g.

    brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11-X3.txt
    brcm/brcmfmac4378b1-pcie.apple,shikoku-X3.bin

In addition, since there are over 1000 files in total, many of which are
symlinks or outright duplicates, we deduplicate and prune the firmware
tree to reduce firmware filenames to fewer dimensions. For example, the
shikoku platform (MacBook Air M1 2020) simplifies to just 4 files:

    brcm/brcmfmac4378b1-pcie.apple,shikoku.clm_blob
    brcm/brcmfmac4378b1-pcie.apple,shikoku.bin
    brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m.txt
    brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-u.txt

This reduces the total file count to around 170, of which 75 are
symlinks and 95 are regular files: 7 firmware blobs, 27 CLM blobs, and
61 NVRAM config files. We also slightly process NVRAM files to correct
some formatting issues.

To handle this, the driver must try the following path formats when
looking for firmware files:

    brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11-X3.txt
    brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11.txt
    brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m.txt
    brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP.txt
    brcm/brcmfmac4378b1-pcie.apple,shikoku-X3.txt *
    brcm/brcmfmac4378b1-pcie.apple,shikoku.txt

* Not relevant for NVRAM, only for firmware/CLM.

The chip revision nominally comes from OTP on Apple platforms, but it
can be mapped to the PCI revision number, so we ignore the OTP revision
and continue to use the existing PCI revision mechanism to identify chip
revisions, as the driver already does for other chips. Unfortunately,
the mapping is not consistent between different chip types, so this has
to be determined experimentally.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: of: Fetch Apple properties

On Apple ARM64 platforms, firmware selection requires two properties
that come from system firmware: the module-instance (aka "island", a
codename representing a given hardware platform) and the antenna-sku.
We map Apple's module codenames to board_types in the form
"apple,<module-instance>".

The mapped board_type is added to the DTS file in that form, while the
antenna-sku is forwarded by our bootloader from the Apple Device Tree
into the FDT. Grab them from the DT so firmware selection can use
them.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie: Read Apple OTP information

On Apple platforms, the One Time Programmable ROM in the Broadcom chips
contains information about the specific board design (module, vendor,
version) that is required to select the correct NVRAM file. Parse this
OTP ROM and extract the required strings.

Note that the user OTP offset/size is per-chip. This patch does not add
any chips yet.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: firmware: Support passing in multiple board_types

Apple platforms have firmware and config files identified with multiple
dimensions. We want to be able to find the most specific firmware
available for any given platform, progressively trying more general
firmwares.

To do this, first add support for passing in multiple board_types,
which will be tried in sequence.

Since this will cause more log spam due to missing firmwares, also
switch the secondary firmware fecthes to use the _nowarn variant, which
will not log if the firmware is not found.

Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism

Now that the firmware fetcher can handle per-board CLM files, load the
CLM blob alongside the other firmware files and change the bus API to
just return the existing blob, instead of fetching the filename.

This enables per-board CLM blobs, which are required on Apple platforms.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>

brcmfmac: firmware: Handle per-board clm_blob files

Teach brcm_alt_fw_paths to correctly split off variable length
extensions, and enable alt firmware lookups for the CLM blob firmware
requests.

Apple platforms have per-board CLM blob files.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>

dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

This binding is currently used for SDIO devices, but these chips are
also used as PCIe devices on DT platforms and may be represented in the
DT. Re-use the existing binding and add chip compatibles used by Apple
T2 and M1 platforms (the T2 ones are not known to be used in DT
platforms, but we might as well document them).

Then, add properties required for firmware selection and calibration on
M1 machines.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>

cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states

Signed-off-by: Hector Martin <marcan@marcan.st>

nvmem: Add spmi-mfd-nvmem driver

This driver exposes part of an SPMI MFD device as an NVMEM device.
It is intended to be used with e.g. PMUs/PMICs that are used to
hold power-management configuration, such as used on Apple Silicon
Macs.

Signed-off-by: Hector Martin <marcan@marcan.st>

mfd: Add a simple-mfd-spmi driver

This is the SPMI counterpart to simple-mfd-i2c. It merely exposes the
SPMI register address space as an MFD device, such that different
aspects of a device can be managed by separate drivers.

Signed-off-by: Hector Martin <marcan@marcan.st>

spmi: add a first basic spmi driver for Apple SoC that can be used for reading and writing time from the rtc

Signed-off-by: Jean-Francois Bortolotti <jeff@borto.fr>

reboot: Remove pm_power_off_prepare()

All pm_power_off_prepare() users were converted to sys-off handler API.
Remove the obsolete callback.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

ACPI: power: Switch to sys-off handler API

Switch to sys-off API that replaces legacy pm_power_off callbacks.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

memory: emif: Use kernel_can_power_off()

Replace legacy pm_power_off with kernel_can_power_off() helper that
is aware about chained power-off handlers.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>

nds32: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

mips: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

ia64: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

x86: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

sh: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

m68k: Switch to new sys-off handler API

Kernel now supports chained power-off handlers. Use
register_power_off_handler() that registers power-off handlers and
do_kernel_power_off() that invokes chained power-off handlers. Legacy
pm_power_off() will be removed once all drivers will be converted to
the new power-off API.

Normally arch code should adopt only the do_kernel_power_off() at first,
but m68k is a special case because it uses pm_power_off() "inside out",
i.e. pm_power_off() invokes machine_power_off() [in fact it does nothing],
while it's machine_power_off() that should invoke the pm_power_off(), and
thus, we can't convert platforms to the new API separately. There are only
two platforms changed here, so it's not a big deal.

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

powerpc: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

xen/x86: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Acked-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

parisc: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Acked-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

arm64: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

riscv: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Acked-by: Palmer Dabbelt <palmer@dabbelt.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

csky: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Acked-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>

ARM: Use do_kernel_power_off()

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>