apple-nvme: add support for ->queue_rqs

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

block: allow queue_rqs with shared tags

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

apple-nvme: support persistent DMA maps

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

io_uring: add IORING_REGISTER_{MAP,UNMAP}_BUFFERS

If supported by the file used for IO, pre-map registered buffers for
DMA. This ties in with registered buffers, and this is only feasible
on a range of buffers that have been registered with
IORING_REGISTER_BUFFERS or IORING_REGISTER_BUFFERS2.

By pre-mapping the buffers for DMA, we retain any DMA mappings across
IO. This means that we no longer have to do a DMA map+unmap for each
IO.

The buffers can be unmapped with IORING_REGISTER_UNMAP_BUFFERS, or
simply just unregistered as per usual and unmapping will happen as
part of that.

This goes for updates through IORING_REGISTER_BUFFERS_UPDATE as well,
if the existing buffer being replaced is DMA mapped, it is unmapped
as part of the update. The new buffer must be DMA mapped afterwards,
if so desired.

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

block: add mq_ops method for DMA mapping bvecs

Add a way for a driver to DMA map an array of bvecs, and return the
device to which it was mapped. This goes along with a set of block
helpers for mapping and unmapping.

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

block: add a DMA field to struct bio_vec

Allows the caller to pass in a fully prepared bvec that has already
been mapped by the driver. This can save a DMAP map+unmap per IO.

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

block: add bvec_set_page() helper

Instead of opencoding this everywhere, add a helper that can initialize
a bio_vec page/length/offset members.

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

net: decouple skb_frag_t from struct bio_vec

There are some hidden dependencies between the size of skb_frag_t, and
hence also struct bio_vec, which causes network data corruption when
the bio_vec is changed. This is at least true on igb, unsure how many
drivers it affects or if it's a core feature that igb just happens to
use.

Since nothing ever came of the skb_frag_t and bio_vec unification, just
add a private skb_frag_struct instead that has the same layout as the
bio_vec.

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>

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>

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>

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

status = "ok" is not spec complient and u-boot does not recognize it

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

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

status = "ok" is not spec complient, disable the flash node to make it
harder to shoot oneself in the foot.

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

ASoC: tas2770: Insert post reset delay

Per TAS2770 datasheet there must be a 1 ms delay from reset to first
command. So insert delays into the driver where appropriate.

Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver")
Signed-off-by: Martin Povišer <povik+lin@protonmail.com>

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

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

ASoC: apple: mca: Move MCLK enable/disable to earlier

Move MCLK enable/disable to earlier in the ALSA setup sequence to make
sure the clock is set up before a codec transitions to it.

t8103 fixup

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

tps6598x: clear int mask on probe failure

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>

KVM: avoid warning on s390 in mark_page_dirty

Avoid warnings on s390 like
[ 1801.980931] CPU: 12 PID: 117600 Comm: kworker/12:0 Tainted: G            E     5.17.0-20220113.rc0.git0.32ce2abb03cf.300.fc35.s390x+next #1
[ 1801.980938] Workqueue: events irqfd_inject [kvm]
[...]
[ 1801.981057] Call Trace:
[ 1801.981060]  [<000003ff805f0f5c>] mark_page_dirty_in_slot+0xa4/0xb0 [kvm]
[ 1801.981083]  [<000003ff8060e9fe>] adapter_indicators_set+0xde/0x268 [kvm]
[ 1801.981104]  [<000003ff80613c24>] set_adapter_int+0x64/0xd8 [kvm]
[ 1801.981124]  [<000003ff805fb9aa>] kvm_set_irq+0xc2/0x130 [kvm]
[ 1801.981144]  [<000003ff805f8d86>] irqfd_inject+0x76/0xa0 [kvm]
[ 1801.981164]  [<0000000175e56906>] process_one_work+0x1fe/0x470
[ 1801.981173]  [<0000000175e570a4>] worker_thread+0x64/0x498
[ 1801.981176]  [<0000000175e5ef2c>] kthread+0x10c/0x110
[ 1801.981180]  [<0000000175de73c8>] __ret_from_fork+0x40/0x58
[ 1801.981185]  [<000000017698440a>] ret_from_fork+0xa/0x40

when writing to a guest from an irqfd worker as long as we do not have
the dirty ring.

Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reluctantly-acked-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <20220113122924.740496-1-borntraeger@linux.ibm.com>
Fixes: 2efd61a608b0 ("KVM: Warn if mark_page_dirty() is called without an active vCPU")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Remove local version

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

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

dt: wip cpufreq

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

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>

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>

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>

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>

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>

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>

dt-bindings: pci: apple,pcie: Drop max-link-speed from example

We no longer use these since 111659c2a570 (and they never worked
anyway); drop them from the example to avoid confusion.

Fixes: 111659c2a570 ("arm64: dts: apple: t8103: Remove PCIe max-link-speed properties")
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>

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>

arm64: Set ARCH_NR_GPIO to 2048 for ARCH_APPLE

We're already running into the 512 GPIO limit on t600[01] depending on
how many SMC GPIOs we allocate, and a 2-die version could double that.
Let's make it 2K to be safe for now.

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>

soc: apple: rtkit: Add recv_message_early callback and apple_rtkit_poll

These allow a client to receive contexts in atomic context, by polling.

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

soc: apple: rtkit: Switch to atomic mailbox API

Turns off tx_block and use the tx_done callback to implement our own
completion handling. This makes our usage of the mailbox API
atomic-safe, and using a per-message completion is also more robust.

Then, implement apple_rtkit_send_message_atomic which polls for
transmission to be complete instead of using a completion. This is
required to send RTKit messages from atomic contexts, notably the
final system shutdown message to SMC.

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

mailbox: apple: Implement peek_data() operation

This allows clients running in atomic context to poll for messages to
arrive.

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

mailbox: apple: Implement flush() operation

This allows clients to use the atomic-safe mailbox API style.

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

fixup! WIP: soc: apple: rtkit: Add RTKit library

Fix shutdown path getting stuck on the worker thread never exiting

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

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

nvme-apple: update RTKit buffer handling in Apple SoC NVMe driver

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

fixup! WIP: soc: apple: rtkit: Add RTKit library

soc: apple: rtkit: Support RTKit devices with mixed AP and IOP managed buffers

DCP uses a IOP managed buffer for the crashlog buffer but expects AP
allocated shared buffers otherwise.

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

fixup! WIP: soc: apple: rtkit: Add RTKit library

soc: apple: rtkit: Add oslog system endpoint (EP 8)

Required for starting dcp.

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

Merge branch 'bits/100-shutdown-notifier' into asahi

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>

regulator: pfuze100: Use devm_register_sys_off_handler()

Use devm_register_sys_off_handler() that replaces global
pm_power_off_prepare variable and allows to register multiple
power-off handlers.

Acked-by: Mark Brown <broonie@kernel.org>
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>

Merge branches 'refs/heads/bits/000-devicetree', 'refs/heads/bits/020-t6000-bringup', 'refs/heads/bits/030-misc', 'refs/heads/bits/060-spi', 'refs/heads/bits/070-audio', 'refs/heads/bits/080-wifi' and 'refs/heads/bits/090-spi-hid' into asahi

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>