Skip to content

pmp v1 implementation - #576

Open
dd-dreams wants to merge 54 commits into
AsahiLinux:asahi-wipfrom
dd-dreams:pmp-v1-impl
Open

pmp v1 implementation#576
dd-dreams wants to merge 54 commits into
AsahiLinux:asahi-wipfrom
dd-dreams:pmp-v1-impl

Conversation

@dd-dreams

Copy link
Copy Markdown

No description provided.

jannau and others added 19 commits June 20, 2026 17:01
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>
Apple M2* chips have an embedded MTP processor that handles all HID
functions, and does not go over a traditional bus like SPI. The devices
still have real IDs, so add them here.

Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Hector Martin <marcan@marcan.st>
This maximum is arbitrary. Recent Apple devices have some vendor-defined
reports with 16384 here which fail to parse without this, so let's bump
it to that.

This value is used as follows:

report->size += parser->global.report_size * parser->global.report_count;

[...]

/* Total size check: Allow for possible report index byte */
if (report->size > (max_buffer_size - 1) << 3) {
	hid_err(parser->device, "report is too long\n");
	return -1;
}

All of these fields are unsigned integers, and report_count is bounded
by HID_MAX_USAGES (12288). Therefore, as long as the respective maximums
do not overflow an unsigned integer (let's say a signed integer just in
case), we're safe. This holds for 16384.

Signed-off-by: Hector Martin <marcan@marcan.st>
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.

The Macbook Pro (M1, 13-inch, 2020) uses the same function key mapping
as other Macbook Pros with touchbar and dedicated ESC key.
Apple silicon Macbooks use the same function key mapping as the 2021 and
later Magic Keyboards.

Signed-off-by: Janne Grunau <j@jannau.net>
We use BUS_HOST for MTP HID subdevices

Signed-off-by: Hector Martin <marcan@marcan.st>
This mode is added to ease adding new xkeyboard configs for Apple
silicon Macbook keyboards. The existing ones have strange quirks [1] and
as the keyboard sends a key code for the 'fn' there is desire to use it
as additional modifier [2].

[1]: https://pagure.io/fedora-asahi/remix-bugs/issue/17
[2]: https://asahilinux.org/docs/project/help-wanted/ (Keyboard layout cleanup)

Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
Will be used for supporting MacBook trackpads connected via SPI.

Signed-off-by: Janne Grunau <j@jannau.net>
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>
Apple M2 devices expose the multi-touch device over the HID over
DockChannel transport, which we represent as the HOST bus type. The
report format is the same, except the legacy mouse header is gone and
there is no enable request needed.

Signed-off-by: Hector Martin <marcan@marcan.st>
The trackpad has to request multi touch reports during resume.

Signed-off-by: Janne Grunau <j@jannau.net>
On at least some SPI devices (e.g. recent Apple Silicon machines), the
Broadcom touch controller is prone to crashing. When this happens, the
STM eventually notices and resets it. It then notifies the driver via
HID report 0x60, and the driver needs to re-enable MT mode to make
things work again.

This poses an additional issue: the hidinput core will close the
low-level transport while the device is closed, which can cause us to
miss a reset notification. To fix this, override the input open/close
callbacks and send the MT enable every time the HID device is opened,
instead of only once on probe. This should increase general robustness,
even if the reset mechanism doesn't work for some reason, so it's worth
doing it for USB devices too. MTP devices are exempt since they do not
require the MT enable at all.

Signed-off-by: Hector Martin <marcan@marcan.st>
For SPI/MTP trackpads, query the dimensions via HID report instead of
hardcoding values.

TODO: Does this work for the USB/BT devices? Maybe we can get rid of the
hardcoded sizes everywhere?

Signed-off-by: Hector Martin <marcan@marcan.st>
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

Contains "HID: transport: spi: apple: Increase receive buffer size"

The SPI receive buffer is passed directly to hid_input_report() if it
contains a complete report. It is then passed to hid_report_raw_event()
which computes the expected report size and memsets the "missing
trailing data up to HID_MAX_BUFFER_SIZE (16K) or
hid_ll_driver.max_buffer_size (if set) to zero.

Co-developed-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Janne Grunau <j@jannau.net>
DockChannel is a simple FIFO interface used to communicate between SoC
blocks. Add a driver that represents the shared interrupt controller for
the DockChannel block, and then exposes probe and data transfer
functions that child device drivers can use to instantiate individual
FIFOs.

Signed-off-by: Hector Martin <marcan@marcan.st>
Apple M2 devices have an MTP coprocessor embedded in the SoC that
handles HID for the integrated touchpad/keyboard, and communicates
over the DockChannel interface. This driver implements this new
interface.

Signed-off-by: Hector Martin <marcan@marcan.st>
This driver can be used for coprocessors that do some background task or
communicate out-of-band, and do not do any mailbox I/O beyond the
standard RTKit initialization.

Signed-off-by: Hector Martin <marcan@marcan.st>
@dd-dreams
dd-dreams force-pushed the pmp-v1-impl branch 6 times, most recently from 9653038 to ae66f0a Compare August 24, 2026 08:29
Comment thread arch/arm64/boot/dts/apple/t8103.dtsi Outdated
Comment thread Documentation/devicetree/bindings/power/apple,pmp-v1.yaml Outdated
Comment thread drivers/pmdomain/apple/Kconfig Outdated
Comment thread drivers/pmdomain/apple/Kconfig Outdated
Comment thread drivers/pmdomain/apple/pmp_v1_report.rs Outdated
Comment thread drivers/soc/apple/Kconfig Outdated
Comment thread drivers/soc/apple/pmp_v1.rs Outdated
Comment thread drivers/soc/apple/pmp_v1.rs Outdated
Comment thread rust/kernel/soc/apple/mod.rs
Comment thread drivers/soc/apple/pmp_v1.rs Outdated
jannau and others added 11 commits August 26, 2026 10:46
Certain Broadcom bluetooth chips (bcm4377/bcm4378/bcm438) need ACL
streams carrying audio to be set as "high priority" using a vendor
specific command to prevent 10-ish second-long dropouts whenever
something does a device scan. This patch sends the command when the
socket priority is set to TC_PRIO_INTERACTIVE, as BlueZ does for audio.

Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
The current approach of silently disabling all rust drivers if the
toolchain is missing results in users that try to compile their own
kernels getting a "successful" build and then being confused about where
did their drivers go. In comparison, missing openssl results in a build
failure, not a disappearance of everything that depends on it.

This also means that allyesconfig will depend on rust, but since the
rust experiment concluded with "rust is here to stay", i believe that
allyesconfig should be building rust drivers too.

Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Apple M3 Pro and Max devices are using 'gp00' keys for GPIO in addition
to 'gP00' keys. Add a second compatible to handle this keys with an
additional macsmc-gpio instance.

Signed-off-by: Janne Grunau <j@jannau.net>
Add support for SMC GPIO keys with a lower letter 'p' via the
"apple,smc-low-gpio" compatible. This adds support for a second
macsmc-gpio controller using 'gp00' keys.
These keys are used on Apple M3 Pro and Max MacBooks in the controller
for keyboard and trackpad and for the built-in DisplayPort to HDMI
converter.

Signed-off-by: Janne Grunau <j@jannau.net>
Apple M3 Pro and Max devices are using 'gp00' keys for GPIO in addition
to 'gP00' keys. These keys are handled by an additional macsmc-gpio
instance using the "apple,smc-low-gpio" compatible.

Signed-off-by: Janne Grunau <j@jannau.net>
Comment thread Documentation/devicetree/bindings/power/apple,pmp-v1-report-entry.yaml Outdated
Comment thread Documentation/devicetree/bindings/power/apple,pmp-v1.yaml Outdated
Signed-off-by: dd-dreams <80887265+dd-dreams@users.noreply.github.com>
Signed-off-by: dd-dreams <80887265+dd-dreams@users.noreply.github.com>
Signed-off-by: dd-dreams <80887265+dd-dreams@users.noreply.github.com>
Signed-off-by: dd-dreams <80887265+dd-dreams@users.noreply.github.com>
Signed-off-by: dd-dreams <80887265+dd-dreams@users.noreply.github.com>
Signed-off-by: dd-dreams <80887265+dd-dreams@users.noreply.github.com>
Signed-off-by: dd-dreams <80887265+dd-dreams@users.noreply.github.com>

@jannau jannau left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please clean your commits up. At least each commit should compile and each drivers should get their own commit. The dts changes need to be separate as well to avoid conflicts between bits/* branches


aliases {
gpu = &gpu;
pmp = &pmp;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for downstream pmp v1 should be optional as pmp v2. Please use the same #ifdefs as in the other device trees.
For upstream this requires select APPLE_PMP_V1 if PM in arch/arm64/Kconfig.platforms. For PMPv2 select APPLE_PMP_REPORT if PM is missing

Comment thread arch/arm64/boot/dts/apple/t8103.dtsi Outdated
msi-parent = <&pcie0>;
msi-ranges = <&aic AIC_IRQ 704 IRQ_TYPE_EDGE_RISING 32>;


Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: unrelated, is this an issue in the downstream or upstream dts. If it's downstream please submit fixup comment for this

Comment thread drivers/pmdomain/apple/pmp_v1_report.rs
Comment thread rust/kernel/soc/apple/pmdomain.rs
Comment thread rust/kernel/soc/apple/pmdomain.rs
Comment thread rust/kernel/soc/apple/pmdomain.rs
Comment thread rust/kernel/soc/apple/pmdomain.rs
#[pin_data]
struct PmpData {
dev: ARef<device::Device>,
pmp_mmio: Pin<KBox<Devres<IoMem<PMP_MMIO_SIZE>>>>,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please try to the iomem out of PmpData. This makes lifetime handling (coming in v7.2) much easier. At least for asc_mmio this should be no problem. If you rebase onto https://github.com/AsahiLinux/linux/tree/bits/250-aop start_cpu() can be simplified to

    asc_mmio.update(ASC_CPU_CONTROL, |r| r.with_const_cpu_run::<1>());

directly inside probe()

is pmp_mmio used at all?

Comment thread arch/arm64/boot/dts/apple/t8103.dtsi
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants