Upgrade the Rust version from 1.62.0 to 1.66.0.

The overwhelming majority of the commit is about upgrading our `alloc`
fork to the new version from upstream [1]. License has not changed [2][3]
(there were changes in the `COPYRIGHT` file, but unrelated to `alloc`).

As in the previous version upgrades (done out of tree so far), upgrading
`alloc` requires checking that our small additions (`try_*`) still match
their original (non`-try_*`) versions.

With this version upgrade, the following unstable Rust features were
stabilized: `bench_black_box` (1.66.0), `const_ptr_offset_from` (1.65.0),
`core_ffi_c` (1.64.0) and `generic_associated_types` (1.65.0). Thus
remove them.

This also implies that only two unstable features remain allowed for
non-`rust/` code: `allocator_api` and `const_refs_to_cell`.

There are some new Clippy warnings that we are triggering (i.e.
introduced since 1.62.0), as well as a few others that were not
triggered before, thus allow them in this commit and clean up or
remove them as needed later on:

  - `borrow_deref_ref` (new in 1.63.0).
  - `explicit_auto_deref` (new in 1.64.0).
  - `bool_to_int_with_if` (new in 1.65.0).
  - `needless_borrow`.
  - `type_complexity`.
  - `unnecessary_cast` (allowed only on `CONFIG_ARM`).

Furthermore, `rustdoc` lint `broken_intra_doc_links` is triggering on
links pointing to `macro_export` `macro_rules` defined in the same
module (i.e. appearing in the crate root).

However, even if the warning appears, the link still gets generated
like in previous versions, thus it is a bit confusing. An issue has
been opened upstream [4], and it appears that the link still being
generated was a compatibility measure, thus we will need to adapt
to the new behavior (done in the next patch).

In addition, there is an added `#[const_trait]` attribute in
`RawDeviceId`, due to 1.66.0's PR "Require `#[const_trait]` on `Trait`
for `impl const Trait`") [5].

Finally, the `-Aunused-imports` was added for compiling `core`. This was
fixed upstream for 1.67.0 in PR "Fix warning when libcore is compiled
with no_fp_fmt_parse" [6], and prevented for the future for that `cfg`
in PR "core: ensure `no_fp_fmt_parse builds` are warning-free" [7].

Reviewed-by: Björn Roy Baron <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Tested-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Vincenzo Palazzo <[email protected]>
Reviewed-by: Alice Ferrazzi <[email protected]>
Tested-by: Alice Ferrazzi <[email protected]>
Reviewed-by: Neal Gompa <[email protected]>
Tested-by: Neal Gompa <[email protected]>
Link: Rust-for-Linux#947
Link: https://github.com/rust-lang/rust/tree/1.66.0/library/alloc/src [1]
Link: https://github.com/rust-lang/rust/blob/1.66.0/library/alloc/Cargo.toml#L4 [2]
Link: https://github.com/rust-lang/rust/blob/1.66.0/COPYRIGHT [3]
Link: rust-lang/rust#106142 [4]
Link: rust-lang/rust#100982 [5]
Link: rust-lang/rust#105434 [6]
Link: rust-lang/rust#105811 [7]
Signed-off-by: Miguel Ojeda <[email protected]>

Commit reference: 3dfc5eb

Signed-off-by: Asahi Lina <[email protected]>

Commit reference: 3dfc5eb

Co-developed-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Asahi Lina <[email protected]>

Commit reference: 3dfc5eb

Commit reference: 3dfc5eb

Signed-off-by: Asahi Lina <[email protected]>

Commit reference: 3dfc5eb

Commit reference: 3dfc5eb

Commit reference: 3dfc5eb

Commit reference: 3dfc5eb

This abstraction enables Rust drivers to walk Device Tree nodes and
query their properties.

Signed-off-by: Asahi Lina <[email protected]>

…ation

In order for modpost to work and correctly generate module aliases from
device ID tables, it needs those tables to exist as global symbols with
a specific name. Additionally, modpost checks the size of the symbol, so
it cannot contain trailing data.

To support this, split IdArrayIds out of IdArray. The former contains
just the IDs. Then split out the device table definition macro from the
macro that defines the device table for a given bus driver, and add
another macro to declare a device table as a module device table.
Drivers can now define their ID table once, and then specify that it
should be used for both the driver and the module:

// Generic OF Device ID table.
kernel::define_of_id_table! {ASAHI_ID_TABLE, &'static hw::HwConfig, [
    (of::DeviceId::Compatible(b"apple,agx-t8103"), Some(&hw::t8103::HWCONFIG)),
    (of::DeviceId::Compatible(b"apple,agx-t8112"), Some(&hw::t8112::HWCONFIG)),
    // ...
]}

/// Platform Driver implementation for `AsahiDriver`.
impl platform::Driver for AsahiDriver {
    /// Data associated with each hardware ID.
    type IdInfo = &'static hw::HwConfig;

    // Assign the above OF ID table to this driver.
    kernel::driver_of_id_table!(ASAHI_ID_TABLE);

    // ...
}

// Export the OF ID table as a module ID table, to make modpost/autoloading work.
kernel::module_of_id_table!(MOD_TABLE, ASAHI_ID_TABLE);

Signed-off-by: Asahi Lina <[email protected]>

This patch adds a logic similar to `devm_platform_ioremap_resource`
function adding:
  - `IoResource` enumerated type that groups the `IORESOURCE_*` macros.
  - `get_resource()` method that is a binding of `platform_get_resource`
  - `ioremap_resource` that is newly written method similar to
    `devm_platform_ioremap_resource`.

Lina: Removed `bit` dependency and rebased

Co-developed-by: Asahi Lina <[email protected]>
Signed-off-by: Maciej Falkowski <[email protected]>

Allows drivers to configure the DMA masks for a device. Implemented
here, not in device, because it requires a mutable platform device
reference this way (device::Device is a safely clonable reference).

Signed-off-by: Asahi Lina <[email protected]>

Apple SoCs require non-posted mappings for MMIO, and this is
automatically handled by devm_ioremap_resource() and friends via a
resource flag. Implement the same logic in kernel::io_mem, so it can
work the same way.

Signed-off-by: Asahi Lina <[email protected]>

Commit reference: 3dfc5eb

Commit reference: 3dfc5eb

TODO: This isn't abstracted properly yet

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Commit reference: 3dfc5eb

Commit reference: 3dfc5eb

Commit reference: 3dfc5eb

Apple Silicon SoCs (M1, M2, etc.) have a GPU with an ARM64 firmware
coprocessor. The firmware and the GPU share page tables in the standard
ARM64 format (the firmware literally sets the base as its TTBR0/1
registers). TTBR0 covers the low half of the address space and is
intended to be per-GPU-VM (GPU user mappings and kernel-managed
buffers), while TTBR1 covers the upper half and is global (firmware
code, data, management structures shared with the AP, and a few
GPU-accessible data structures).

In typical Apple fashion, the permissions are interpreted differently
from traditional ARM PTEs. By default, firmware mappings use Apple SPRR
permission remapping. The firmware only uses that for its own
code/data/MMIO mappings, and those pages are not accessible by the GPU
hardware. We never need to touch/manage these mappings, so this patch
does not support them.

When a specific bit is set in the PTEs, permissions switch to a
different scheme which supports various combinations of firmware/GPU
access. This is the mode intended to be used by AP GPU drivers, and what
we implement here.

The prot bits are interpreted as follows:

- IOMMU_READ and IOMMU_WRITE have the usual meaning.

- IOMMU_PRIV creates firmware-only mappings (no GPU access)
- IOMMU_NOEXEC creates GPU-only structures (no FW access)
- Otherwise structures are accessible by both GPU and FW

- IOMMU_MMIO creates Device mappings for firmware
- IOMMU_CACHE creates Normal-NC mappings for firmware (cache-coherent
  from the point of view of the AP, but slower)
- Otherwise creates Normal mappings for firmware (this requires manual
  cache management on the firmware side, as it is not coherent with the
  SoC fabric)

GPU-only mappings (textures/etc) are expected to use IOMMU_CACHE and are
seemingly coherent with the CPU (or otherwise the firmware/GPU already
issue the required cache management operations when correctly
configured).

There is a GPU-RO/FW-RW mode, but it is not currently implemented (it
doesn't seem to be very useful for the driver). There seems to be no
real noexec control (i.e. for shaders) on the GPU side. All of these
mappings are implicitly noexec for the firmware.

Drivers are expected to fully manage per-user (TTBR0) page tables, but
ownership of shared kernel (TTBR1) page tables is shared between the
firmware and the AP OS. We handle this by simply using a smaller IAS to
drop down one level of page tables, so the driver can install a PTE in
the top-level (firmware-initialized) page table directly and just add an
offset to the VAs passed into the io_pgtable code. This avoids having to
have any special handling for this here. The firmware-relevant data
structures are small, so we do not expect to ever require more VA space
than one top-level PTE covers (IAS=36 for the next level, 64 GiB).

Only 16K page mode is supported. The coprocessor MMU supports huge pages
as usual for ARM64, but the GPU MMU does not, so we do not enable them.

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

DRM drivers need to be able to declare which driver-specific ioctls they
support. This abstraction adds the required types and a helper macro to
generate the ioctl definition inside the DRM driver.

Note that this macro is not usable until further bits of the
abstraction are in place (but it will not fail to compile on its own, if
not called).

Signed-off-by: Asahi Lina <[email protected]>

Add the initial abstractions for DRM drivers and devices. These go
together in one commit since they are fairly tightly coupled types.

A few things have been stubbed out, to be implemented as further bits of
the DRM subsystem are introduced.

Signed-off-by: Asahi Lina <[email protected]>

A DRM File is the DRM counterpart to a kernel file structure,
representing an open DRM file descriptor. Add a Rust abstraction to
allow drivers to implement their own File types that implement the
DriverFile trait.

Signed-off-by: Asahi Lina <[email protected]>

The DRM GEM subsystem is the DRM memory management subsystem used by
most modern drivers. Add a Rust abstraction to allow Rust DRM driver
implementations to use it.

Signed-off-by: Asahi Lina <[email protected]>

There doesn't seem to be a way for the Rust bindings to get a
compile-time constant reference to drm_gem_shmem_vm_ops, so we need to
duplicate that structure in Rust... this isn't nice...

Signed-off-by: Asahi Lina <[email protected]>

The DRM shmem helper includes common code useful for drivers which
allocate GEM objects as anonymous shmem. Add a Rust abstraction for
this. Drivers can choose the raw GEM implementation or the shmem layer,
depending on their needs.

Signed-off-by: Asahi Lina <[email protected]>

drm_mm provides a simple range allocator, useful for managing virtual
address ranges. Add a Rust abstraction to expose this module to Rust
drivers.

Signed-off-by: Asahi Lina <[email protected]>

DMA fences are the internal synchronization primitive used for DMA
operations like GPU rendering, video en/decoding, etc. Add an
abstraction to allow Rust drivers to interact with this subsystem.

Note: This uses a raw spinlock living next to the fence, since we do
not interact with it other than for initialization.
TODO: Expose this to the user at some point with a safe abstraction.

Signed-off-by: Asahi Lina <[email protected]>

DRM Sync Objects are a container for a DMA fence, and can be waited on
signaled, exported, and imported from userspace. Add a Rust abstraction
so Rust DRM drivers can support this functionality.

Signed-off-by: Asahi Lina <[email protected]>

Some hardware may require more complex resource utilization accounting
than the simple job count supported by drm_sched internally. Add a
can_run_job callback to allow drivers to implement more logic before
deciding whether to run a GPU job.

Signed-off-by: Asahi Lina <[email protected]>

The GPU scheduler manages scheduling GPU jobs and dependencies between
them. This Rust abstraction allows Rust DRM drivers to use this
functionality.

Signed-off-by: Asahi Lina <[email protected]>

Drivers may want to support driver-private objects, which cannot be
shared. This allows them to share a single lock and enables other
optimizations.

Add an `exportable` field to drm_gem_object, which blocks PRIME export
if set to false. It is initialized to true in
drm_gem_private_object_init.

Signed-off-by: Asahi Lina <[email protected]>

This allows drivers to control whether a given GEM object is allowed to
be exported via PRIME to other drivers.

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Most faults seem to be reported as what I call timeouts anyway.

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

This does not work and isn't intended to work. While trivial submissions
like this are valid in Vulkan, Mesa should lower it to waiting on the
last valid syncobj instead, since it doesn't make any sense at the
firmware level.

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

They could complete in either order, and not forcing flushes on both can
leave us with stuck stamps...

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Janne Grunau <[email protected]>

Add the apple,t8112-pmgr-pwrstate compatible for the Apple M2 SoC.

This goes after t8103. The sort order logic here is having SoC numeric
code families in release order, and SoCs within each family in release
order:

- t8xxx (Apple HxxP/G series, "phone"/"tablet" chips)
  - t8103 (Apple H13G/M1)
  - t8112 (Apple H14G/M2)
- t6xxx (Apple HxxJ series, "desktop" chips)
  - t6000 (Apple H13J(S)/M1 Pro)
  - t6001 (Apple H13J(C)/M1 Max)
  - t6002 (Apple H13J(D)/M1 Ultra)

Note that t600[0-2] share the t6000 compatible where the hardware is
100% compatible, which is usually the case in this highly related set
of SoCs.

Signed-off-by: Hector Martin <[email protected]>
Reviewed-by: Janne Grunau <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

The block on Apple M2 SoCs is compatible with the existing driver so
just add its per-SoC compatible.

Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

The block on the Apple M2 SoC is compatible with the existing driver so
add its per-SoC compatible.

Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

These are the CPU cores in the Apple silicon M2 SoC.

Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

…mpatible

The Apple M2 SoC uses AICv2 and is compatible with the existing driver.
Add its per-SoC compatible.
Since multi-die versions of the M2 are not expected decrease
'#interrupt-cells' to 3 for apple,t8112-aic. This is seamlessly handled
inside the driver.

Acked-by: Marc Zyngier <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

"apple,t8112-sart" as found on the Apple M2 SoC appears to be SART3 as
well. To allow for later discovered incompatibilities use
'"apple,t8112-sart", "apple,t6000-sart"' as compatible string.

Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

The mailbox hardware remains unchanged on M2 SoCs so just add its
per-SoC compatible.

Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

"apple,t8112-nvme-ans2" as found on Apple M2 SoCs is compatible with the
existing driver. Add its SoC specific compatible string to allow special
handling if it'll be necessary.
t8112 uses only 2 power-domains as no 4 and 8 TB configurations are
offered.

Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

The block found in the Apple M2 SoC is compatible with the existing
driver, and supports 4 downstream ports like the t6000 one.

Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

This new SoC uses the same pinctrl hardware, so just add a new per-SoC
compatible.

Reviewed-by: Linus Walleij <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

This block on the Apple M2 is compatible with the existing driver so
just add the per-SoC compatible.

Acked-by: Wolfram Sang <[email protected]> # for I2C
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

The block found on Apple's M2 SoC is compatible with the existing driver
so add its per-SoC compatible.

Acked-by: Martin Povišer <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

The block found on Apple's M2 SoC is compatible with the existing driver
so add its per-SoC compatible.

Acked-by: Vinod Koul <[email protected]>
Acked-by: Martin Povišer <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

This adds the following apple,t8112 platforms:

- apple,j413 - MacBook Air (M2, 2022)
- apple,j473 - Mac mini (M2, 2023)
- apple,j493 - MacBook Pro (13-inch, M2, 2022)

The sort order logic here is having SoC numeric code families in release
order, and SoCs within each family in release order:

- t8xxx (Apple HxxP/G series, "phone"/"tablet" chips)
  - t8103 (Apple H13G/M1)
  - t8112 (Apple H14G/M2)
- t6xxx (Apple HxxJ series, "desktop" chips)
  - t6000 (Apple H13J(S)/M1 Pro)
  - t6001 (Apple H13J(C)/M1 Max)
  - t6002 (Apple H13J(D)/M1 Ultra)

Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

This adds device trees for the following devices:
 - Macbook Air (M2, 2022)
 - Macbook Pro 13" (M2, 2022)
 - Mac mini (M2, 2023)

This brings the hardware support of the machines to the same level as M1
and M1 Pro / Max / Ultra. Supported hardware include NVMe, PCIe, serial,
pinctrl/gpio, I2C, iommu, watchdog, admac, nco, cpufreq, boot
framebuffer for laptop panels and the interrupt controller.

The ethernet LAN device on the M2 Mac mini is the only working PCIe
device. The Wlan/BT devices are powered off and controlled by the not
yet supported SMC. The ASMedia xHCI on the M2 Mac mini requires firmware
to be loaded at startup.

The main missing hardware support to make these devices useful are the
integrated USB 2/3/4 controller, keyboard and trackpad on the laptops
and SMC to power the PCIe Wlan/BT device on.
The M2 Mac mini has currently no working display output. Due to changes
in the display pipeline it is currently not possible to initialize the
HDMI output in the bootloader.

Signed-off-by: Hector Martin <[email protected]>
Co-developed-by: Janne Grunau <[email protected]>
Reviewed-by: Sven Peter <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

The PCIe ports are unused (without devices) so disable them instead of
removing them.

Fixes: 7c77ab9 ("arm64: dts: apple: Add missing M1 (t8103) devices")
Signed-off-by: Janne Grunau <[email protected]>

The PCIe ports are unused (without devices) so disable them instead of
removing them.

Signed-off-by: Janne Grunau <[email protected]>

Signed-off-by: Janne Grunau <[email protected]>

Signed-off-by: Hector Martin <[email protected]>

Used for the touchbar, clock frequency is probably wrong.

Signed-off-by: Janne Grunau <[email protected]>

Signed-off-by: Hector Martin <[email protected]>

Signed-off-by: Martin Povišer <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

Signed-off-by: Hector Martin <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

It can be turned off with:

echo 1 > /sys/class/backlight/backlight/bl_power

It can be turned on with:

echo 0 > /sys/class/backlight/backlight/bl_power

Needs CONFIG_BACKLIGHT_GPIO=m.

Signed-off-by: Thomas Glanzmann <[email protected]>
Signed-off-by: Janne Grunau <[email protected]>

Those provide trackpad and keyboard for j413/j493.

Signed-off-by: Janne Grunau <[email protected]>

Signed-off-by: Hector Martin <[email protected]>

In addition to TX channel and RX channel interrupt flags there's
another class of 'global' interrupt flags with unknown semantics. Those
weren't being handled up to now, and they are the suspected cause of
stuck IRQ states that have been sporadically occurring. Check the global
flags and clear them if raised.

Fixes: b127315 ("dmaengine: apple-admac: Add Apple ADMAC driver")
Signed-off-by: Martin Povišer <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Signed-off-by: Asahi Lina <[email protected]>

Fixes following warning when systemd-backlight restores the backlight
level on boot before a mode is set:

Call trace:
  drm_atomic_helper_crtc_duplicate_state+0x58/0x74
  drm_atomic_get_crtc_state+0x84/0x120
  dcp_set_brightness+0xd8/0x21c [apple_dcp]
  backlight_device_set_brightness+0x78/0x130
  ...

Signed-off-by: Janne Grunau <[email protected]>

Backlight drivers are expected to use this instead of accessing
backlight properties.

Signed-off-by: Janne Grunau <[email protected]>

Signed-off-by: Janne Grunau <[email protected]>

Fixes "interrupt-map" parsing in of_irq_parse_raw() which takes the
node's availability into account.

This became apparent after disabling unused PCIe ports in the Apple
silicon device trees instead of disabling them.

Link: https://lore.kernel.org/asahi/20230214-apple_dts_pcie_disable_unused-v1-0-5ea0d3ddcde3@jannau.net/
Link: https://lore.kernel.org/asahi/[email protected]/
Fixes: 1e33888 ("PCI: apple: Add initial hardware bring-up")
Cc: [email protected]
Signed-off-by: Janne Grunau <[email protected]>

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

Signed-off-by: Janne Grunau <[email protected]>

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

Signed-off-by: Hector Martin <[email protected]>

Signed-off-by: Hector Martin <[email protected]>

Signed-off-by: Hector Martin <[email protected]>

Shutting these down breaks dwc3 init done by the firmware. We probably
never want to do this anyway. It might be possible remove this once
a PHY driver is in place to do the init properly, but it may not be
worth it.

Signed-off-by: Hector Martin <[email protected]>

It can be turned off with:

echo 1 > /sys/class/backlight/backlight/bl_power

It can be turned on with:

echo 0 > /sys/class/backlight/backlight/bl_power

Needs CONFIG_BACKLIGHT_GPIO=m.

Signed-off-by: Thomas Glanzmann <[email protected]>

This causes flakiness if shut down; don't do it until we find out
what's going on.

Signed-off-by: Hector Martin <[email protected]>

Signed-off-by: Hector Martin <[email protected]>

Signed-off-by: Hector Martin <[email protected]>