[PATCH v5 00/10] Apple Mac System Management Controller
Neal Gompa
neal at gompa.dev
Mon May 12 05:25:16 PDT 2025
On Sun, May 11, 2025 at 4:19 AM Sven Peter via B4 Relay
<devnull+sven.svenpeter.dev at kernel.org> wrote:
>
> Hi,
>
> This series adds support for the System Management Controller found in
> Apple Silicon devices which we model as a mfd. It also includes support
> for the GPIO block and the power/reset block as sub-devices.
>
> Changes between v4 and v5:
> - Alyssa's comments:
> - Made the WARN_ON in the reboot driver more obvious
> - Added missing brackets around a for loop in the reboot driver
> - Used min instead of open-coded variant inside the gpio driver
> - Reoder struct memebers to prevent padding inside the mfd driver
> - Lee's comments:
> - All comments now start with an uppercase letter
> - Removed apple_smc_read_ioft_scaled and apple_smc_read_f32_scaled
> since these are not yet used and likely don't belong into
> drivers/mfd
> - Relaced if (ret != 0) with if (ret) when possible
> - Used devm_platform_get_and_ioremap_resource to get and map the
> SRAM resource
> - Used reverse Christmas-tree formating when declaring variables
> - Dropped _platform left-overs from probe and remove functions
> - Removed dev_dbg prints which are no long required after
> development
> - Reworked is_alive/is_initialized so that it's obvious how errors
> during boot are propagated from the callback to the probe function
> - Used dev_warn instead of dev_err in a few places
> - Removed no-op apple_smc_rtkit_shmem_destroy; this required an
> additional change in rtkit.c because we had a check there that's a
> bit too strict
> - Removed struct resource in apple_smc_rtkit_shmem_setup and
> open-coded resource_contains instead
> - Unwrapped lines with less than 100 chars
> - Made sure to compile with W=1 and ran scripts/kernel-doc -v
> on macsmc.h once and fixed any fallout
> - Removed first_key/last_key from struct smc and moved
> apple_smc_find_first_key_index to the gpio driver since it's only
> used there anyway to find the index of the first GPIO key (gP00)
> - Return -EIO when a command fails instead of whatever SMC returns
> which does not map to Linux errnos on errors
>
> Changes between v3 and v4:
> - Added documentation for all functions and structs
> - Fixed dt-bindings and re-ordered commits so that the mfd one comes
> last and can include the gpio subdevice
> - Added the reset driver and corresponding bindings
> - Reworked the atomic mode inside SMC since the previous implementation
> called mutex_lock from atomic context
> - Removed the backend split for now which lead to a quite intense discussion
> for the previous versions which hadn't been solved as far as I could tell
> from the old threads.
> It's also been 2+ years and I haven't heard of any backend implementation
> for T2 or even older macs. It's also unclear to me which sub-devices
> are actually useful there because at least GPIO and shutdown/reboot
> from this series will not work as-is there.
> I'd rather have this initial version which only supports M1+ macs upstream
> and then iterate there if any other backend is developed.
> I'll gladly help to re-introduce backend support if it's ever required.
>
> Dependencies:
> The code and dt-bindings themselves apply cleanly to 6.15-rc1 but
> the device tree changes require the already merged SPMI controller
> and SPMI NVMEM series which will be part of 6.16.
> The series is also using the printf format specifiers which will
> land in 6.16 via the drm-misc tree.
> A tree with all dependencies for testing is available at
> https://github.com/AsahiLinux/linux/commits/sven/smc-v5/.
>
> Merging:
> The dt-binding patches all depend on each other such that they all
> should probably go together with the mfd device itself.
> The following commits also depend on mfd due to the new header file and
> will either have to go through the mfd tree as well or we'll need an
> immutable branch there or we just wait one kernel release and I'll
> re-submit the rest then.
> I'll take the device tree updates through our tree which also has the
> previous device tree updates these depend on.
>
> v4: https://lore.kernel.org/asahi/20250503-smc-6-15-v4-0-500b9b6546fc@svenpeter.dev/
> v3: https://lore.kernel.org/asahi/Y2qEpgIdpRTzTQbN@shell.armlinux.org.uk/
> v2: https://lore.kernel.org/asahi/YxdInl2qzQWM+3bs@shell.armlinux.org.uk/
> v1: https://lore.kernel.org/asahi/YxC5eZjGgd8xguDr@shell.armlinux.org.uk/
>
> Best,
>
> Sven
>
> ---
> Hector Martin (5):
> gpio: Add new gpio-macsmc driver for Apple Macs
> power: reset: macsmc-reboot: Add driver for rebooting via Apple SMC
> arm64: dts: apple: t8103: Add SMC node
> arm64: dts: apple: t8112: Add SMC node
> arm64: dts: apple: t600x: Add SMC node
>
> Russell King (Oracle) (2):
> dt-bindings: gpio: Add Apple Mac SMC GPIO block
> dt-bindings: mfd: Add Apple Mac System Management Controller
>
> Sven Peter (3):
> dt-bindings: power: reboot: Add Apple Mac SMC Reboot Controller
> soc: apple: rtkit: Make shmem_destroy optional
> mfd: Add Apple Silicon System Management Controller
>
> .../devicetree/bindings/gpio/apple,smc-gpio.yaml | 37 ++
> .../devicetree/bindings/mfd/apple,smc.yaml | 71 +++
> .../bindings/power/reset/apple,smc-reboot.yaml | 52 +++
> MAINTAINERS | 7 +
> arch/arm64/boot/dts/apple/t600x-die0.dtsi | 35 ++
> arch/arm64/boot/dts/apple/t8103.dtsi | 35 ++
> arch/arm64/boot/dts/apple/t8112.dtsi | 35 ++
> drivers/gpio/Kconfig | 10 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-macsmc.c | 293 ++++++++++++
> drivers/mfd/Kconfig | 15 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/macsmc.c | 506 +++++++++++++++++++++
> drivers/power/reset/Kconfig | 11 +
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/macsmc-reboot.c | 363 +++++++++++++++
> drivers/soc/apple/rtkit.c | 3 +-
> include/linux/mfd/macsmc.h | 277 +++++++++++
> 18 files changed, 1751 insertions(+), 2 deletions(-)
> ---
> base-commit: 5abab6ab4ebacfff5857b63bd349902a6568d2e8
> change-id: 20250304-smc-6-15-f0ed619e31d4
>
Series overall looks good to me.
Reviewed-by: Neal Gompa <neal at gompa.dev>
--
真実はいつも一つ!/ Always, there's only one truth!
More information about the linux-arm-kernel
mailing list