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 'axboe/000-devicetree', 'axboe/010-mailbox', 'axboe/020-t6000-bringup', 'axboe/030-misc', 'axboe/060-spi', 'axboe/070-audio', 'axboe/080-wifi', 'axboe/090-spi-hid', 'axboe/100-shutdown-notifier', 'axboe/110-smc', 'axboe/120-spmi', 'axboe/130-cpufreq' and 'axboe/140-pci-pwren' into m1/2022-03-01

* axboe/000-devicetree:
  HACK: t8103.dtsi: Work around incompleteness of MCA driver
  dt: t8103.dtsi: Put in audio-related device nodes
  arm64: dts: apple: Add CPUfreq nodes
  arm64: dts: apple: Add PMU NVMEM and SMC RTC/reboot nodes
  arm64: dts: apple: Add SMC node to t8103/t6001 devicetrees
  arm64: dts: apple: Add PCI power enable GPIOs
  arm64: dts: apple: Add WiFi module and antenna properties
  arm64: dts: apple: t8103: Add spi3/keyboard nodes
  arm64: dts: apple: t600x: Add spi3 and keyboard nodes
  arm64: dts: apple: t600x-j314-j316: Add NOR flash node
  arm64: dts: apple: t6000: Add spi1 node
  arm64: dts: apple: t6000: Add watchdog node
  arm64: dts: apple: t8103: Add dwc3 nodes
  arm64: dts: apple: t6001: Add ANS2 nodes
  arm64: dts: apple: t8103: Add ANS2 nodes
  arm64: dts: apple: Add J314 and J316 devicetrees
  arm64: dts: apple: t6001: Add i2c1 to i2c5 device nodes
  arm64: dts: apple: t6001: add aop, nub and smc pinctrl nodes
  arm64: dts: apple: t600x: Add PMGR nodes
  arm64: dts: apple: Add initial t6000/t6001 DTs

* axboe/010-mailbox:
  mailbox: apple: Implement peek_data() operation
  mailbox: apple: Implement flush() operation

* axboe/020-t6000-bringup:
  pcie-apple: Fix MSI handling for new phandles
  iommu/io-pgtable: Add DART PTE support for t6000
  iommu: dart: Support t6000 variant
  dt-bindings: iommu: dart: add t6000 compatible
  irqchip/apple-aic: Add support for AICv2
  irqchip/apple-aic: Support multiple dies
  irqchip/apple-aic: Dynamically compute register offsets
  irqchip/apple-aic: Switch to irq_domain_create_tree and sparse hwirqs
  irqchip/apple-aic: Add Fast IPI support
  dt-bindings: interrupt-controller: apple,aic: Add apple,aic2 support

* axboe/030-misc:
  arm64: Set ARCH_NR_GPIO to 2048 for ARCH_APPLE
  dt-bindings: pci: apple,pcie: Drop max-link-speed from example
  tty: serial: samsung_tty: Support runtime PM

* axboe/060-spi:
  spi: apple: Add driver for Apple SPI controller
  dt-bindings: spi: apple,spi: Add binding for Apple SPI controllers
  MAINTAINERS: Add apple-spi driver & binding files
  apple-nvme: remove superflous tcb clears
  apple-nvme: defer cache flushes by a specified amount
  apple-nvme: serialize command issue
  WIP: nvme-apple: add initial Apple SoC NVMe driver
  soc: apple: rtkit: Add recv_message_early callback and apple_rtkit_poll
  soc: apple: rtkit: Switch to atomic mailbox API
  WIP: soc: apple: rtkit: Add RTKit library
  soc: apple: sart: Add SART driver
  dt-bindings: soc: apple: Add ANS NVMe binding
  dt-bindings: soc: apple: Add Apple SART bindings
  usb: dwc3: Add role switch reset quirk for Apple DWC3
  dt-bindings: usb: Add Apple dwc3 bindings

* axboe/070-audio:
  ASoC: cs42l42: Bypass device ID check
  HACK: ASoC: cs42l42: Disable regcache
  HACK: ASoC: tas2770: Set no of channels to 1
  ASoC: tas2770: Set correct FSYNC polarity
  ASoC: apple-mca: Add platform driver for Apple SoCs
  dmaengine: apple-admac: Add Apple ADMAC driver
  dt-bindings: dma: Add apple,admac binding
  MAINTAINERS: Add clk-apple-nco under ARM/APPLE MACHINE
  clk: clk-apple-nco: Add driver for Apple NCO
  dt-bindings: clock: Add Apple NCO

* axboe/080-wifi: (28 commits)
  brcmfmac: common: Add support for external calibration blobs
  brcmfmac: pcie: Load and provide TxCap blobs
  brcmfmac: common: Add support for downloading TxCap blobs
  brcmfmac: pcie: Add IDs/properties for BCM4387
  brcmflac: cfg80211: Use WSEC to set SAE password
  brcmfmac: cfg80211: Pass the PMK in binary instead of hex
  brcmfmac: cfg80211: Add support for PMKID_V3 operations
  brcmfmac: feature: Add support for setting feats based on WLC version
  brcmfmac: cfg80211: Add support for scan params v2
  brcmfmac: chip: Handle 1024-unit sizes for TCM blocks
  brcmfmac: chip: Only disable D11 cores; handle an arbitrary number
  brcmfmac: pcie: Perform correct BCM4364 firmware selection
  brcmfmac: pcie: Add IDs/properties for BCM4377
  brcmfmac: pcie: Add IDs/properties for BCM4355
  brcmfmac: pcie: Provide a buffer of random bytes to the device
  brcmfmac: acpi: Add support for fetching Apple ACPI properties
  ACPI / property: Support strings in Apple _DSM props
  brcmfmac: pcie: Add IDs/properties for BCM4378
  brcmfmac: pcie: Support PCIe core revisions >= 64
  brcmfmac: msgbuf: Increase RX ring sizes to 1024
  ...

* axboe/090-spi-hid:
  WIP: HID: transport: spi: add Apple SPI transport
  HID: magicmouse: add support for Macbook trackpads
  HID: magicmouse: use ops function pointers for input functionality
  HID: magicmouse: use struct input_mt_pos for X/Y
  HID: magicmouse: use a define of the max number of touch contacts
  HID: apple: add Fn key mapping for Macbook Pro with touchbar
  HID: apple: add Fn key mapping for Apple silicon MacBooks
  HID: apple: add support for internal keyboards
  HID: add device IDs for Apple SPI HID devices
  spi: parse CS delay values from DT
  spi: dt-bindings: add CS delay peripheral-specific properties

* axboe/100-shutdown-notifier:
  reboot: Remove pm_power_off_prepare()
  ACPI: power: Switch to sys-off handler API
  memory: emif: Use kernel_can_power_off()
  nds32: Use do_kernel_power_off()
  mips: Use do_kernel_power_off()
  ia64: Use do_kernel_power_off()
  x86: Use do_kernel_power_off()
  sh: Use do_kernel_power_off()
  m68k: Switch to new sys-off handler API
  powerpc: Use do_kernel_power_off()
  xen/x86: Use do_kernel_power_off()
  parisc: Use do_kernel_power_off()
  arm64: Use do_kernel_power_off()
  riscv: Use do_kernel_power_off()
  csky: Use do_kernel_power_off()
  ARM: Use do_kernel_power_off()
  kernel: Add combined power-off+restart handler call chain API
  reboot: Print error message if restart handler has duplicated priority
  notifier: Add atomic/blocking_notifier_chain_register_unique_prio()
  notifier: Add blocking_notifier_call_chain_is_empty()

* axboe/110-smc:
  rtc: Add new rtc-macsmc driver for Apple Silicon Macs
  power: reset: macsmc-reboot: Add driver for rebooting via Apple SMC
  power: supply: macsmc_power: Add AC power supply
  power: supply: macsmc_power: Turn off OBC flags if macOS left them on
  power: supply: macsmc_power: Use BUIC instead of BRSC for charge
  power: supply: macsmc_power: Add more props, rework others
  power: supply: macsmc_power: Add present prop
  power: supply: macsmc_power: Add cycle count and health props
  power: supply: macsmc_power: Driver for Apple SMC power/battery stats
  gpio: Add new gpio-macsmc driver for Apple Macs
  platform/apple: Add new Apple Mac SMC driver
  lib/vsprintf: Add support for generic FOURCCs by extending %p4cc

* axboe/120-spmi:
  nvmem: Add spmi-mfd-nvmem driver
  mfd: Add a simple-mfd-spmi driver
  spmi: add a first basic spmi driver for Apple SoC that can be used for reading and writing time from the rtc

* axboe/130-cpufreq:
  cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states

* axboe/140-pci-pwren:
  PCI: apple: Add support for optional PWREN GPIO
  PCI: apple: Probe all GPIOs for availability first
  PCI: apple: GPIO handling nitfixes

spi: apple: Add driver for Apple SPI controller

This SPI controller is present in Apple SoCs such as the M1 (t8103) and
M1 Pro/Max (t600x). It is a relatively straightforward design with two
16-entry FIFOs, arbitrary transfer sizes (up to 2**32 - 1) and fully
configurable word size up to 32 bits. It supports one hardware CS line
which can also be driven via the pinctrl/GPIO driver instead, if
desired. TX and RX can be independently enabled.

There are a surprising number of knobs for tweaking details of the
transfer, most of which we do not use right now. Hardware CS control
is available, but we haven't found a way to make it stay low across
multiple logical transfers, so we just use software CS control for now.

There is also a shared DMA offload coprocessor that can be used to handle
larger transfers without requiring an IRQ every 8-16 words, but that
feature depends on a bunch of scaffolding that isn't ready to be
upstreamed yet, so leave it for later.

The hardware shares some register bit definitions with spi-s3c24xx which
suggests it has a shared legacy with Samsung SoCs, but it is too
different to warrant sharing a driver.

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

dt-bindings: spi: apple,spi: Add binding for Apple SPI controllers

The Apple SPI controller is present in SoCs such as the M1 (t8103) and
M1 Pro/Max (t600x). This controller uses one IRQ and one clock, and
doesn't need any special properties, so the binding is trivial.

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

MAINTAINERS: Add apple-spi driver & binding files

This Apple SPI controller is present on Apple ARM SoCs (t8103/t6000).

Splitting this change from the binding/driver commits to avoid merge
conflicts with other things touching this section, as usual.

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>

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>

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>

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>

kernel: Add combined power-off+restart handler call chain API

SoC platforms often have multiple ways of how to perform system's
power-off and restart operations. Meanwhile today's kernel is limited to
a single option. Add combined power-off+restart handler call chain API,
which is inspired by the restart API. The new API provides both power-off
and restart functionality.

The old pm_power_off method will be kept around till all users are
converted to the new API.

Current restart API will be replaced by the new unified API since
new API is its superset. The restart functionality of the sys-off handler
API is built upon the existing restart-notifier APIs.

In order to ease conversion to the new API, convenient helpers are added
for the common use-cases. They will reduce amount of boilerplate code and
remove global variables. These helpers preserve old behaviour for cases
where only one power-off handler is expected, this is what all existing
drivers want, and thus, they could be easily converted to the new API.
Users of the new API should explicitly enable power-off chaining by
setting corresponding flag of the power_handler structure.

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

reboot: Print error message if restart handler has duplicated priority

Add sanity check which ensures that there are no two restart handlers
registered using the same priority. This requirement will become mandatory
once all drivers will be converted to the new API and such errors will be
fixed.

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

notifier: Add atomic/blocking_notifier_chain_register_unique_prio()

Add variant of atomic/blocking_notifier_chain_register() functions that
doesn't allow to register notifier using a duplicated priority. The -EBUSY
error code is returned in this case by the new API functions.

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

notifier: Add blocking_notifier_call_chain_is_empty()

Add blocking_notifier_call_chain_is_empty() that returns true if call
chain is empty.

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

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>

HID: magicmouse: add support for Macbook trackpads

The trackpads in Macbooks beginning in 2015 are HID devices connected
over SPI. On Intel Macbooks they are currently supported by applespi.c.
This chang adds support for the trackpads on Apple Silicon Macbooks
starting in late 2020. They use a new HID over SPI transport driver.
The touch report format differs from USB/BT Magic Trackpads. It is the
same format as the type 4 format supported by bcm5974.c.

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

HID: magicmouse: use ops function pointers for input functionality

Will be used for supporting MacBook trackpads connected via SPI.

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

HID: magicmouse: use struct input_mt_pos for X/Y

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

HID: magicmouse: use a define of the max number of touch contacts

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

HID: apple: add Fn key mapping for Macbook Pro with touchbar

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

HID: apple: add Fn key mapping for Apple silicon MacBooks

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

HID: apple: add support for internal keyboards

Apple MacBook keyboards started using HID over SPI in 2015. With the
addition of the SPI HID transport they can be supported by this driver.
Support all product ids over with the Apple SPI vendor id for now.
Individual product ids will have to be added for a correct Fn/function
key mapping.

Enable by default on the Apple Arm platform.

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

HID: add device IDs for Apple SPI HID devices

Apple Silicon based laptop use SPI as transport for HID. Add support for
SPI-based HID devices and and Apple keyboard and trackpad devices.
Intel based laptops using the keyboard input driver applespi use the
same HID over SPI protocol and can be supported later.

This requires SPI keyboard/mouse HID types since Apple's intenal
keyboards/trackpads use the same product id.

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

spi: parse CS delay values from DT

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

spi: dt-bindings: add CS delay peripheral-specific properties

These properties are modelled after Linux' struct spi_device cs_setup,
cs_hold and cs_inactive delay values.

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

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>

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>

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>

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>

WIP: nvme-apple: add initial Apple SoC NVMe driver

Signed-off-by: Sven Peter <sven@svenpeter.dev>