summaryrefslogtreecommitdiff
path: root/arch/arm/include
AgeCommit message (Collapse)Author
2025-09-30Merge tag 'u-boot-socfpga-next-20250930' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next SoCFPGA updates for v2025.10: CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/27762 This pull request brings a set of updates across SoCFPGA platforms covering Agilex5, Agilex7, N5X, and Stratix10. The changes include: * Agilex5 enhancements: - USB3.1 enablement and DWC3 host driver support - System Manager register configuration for USB3 - Watchdog timeout increase and SDMMC clock API integration - dcache handling improvements in SMC mailbox path - Enable SPL_SYS_DCACHE_OFF in defconfig * Clock driver improvements: - Introduce dt-bindings header for Agilex clocks - Add enable/disable API and EMAC clock selection fixes - Replace manual shifts with FIELD_GET usage * DDR updates: - IOSSM mailbox compatibility check - Correct DDR calibration status handling * Device tree changes: - Agilex5: disable cache allocation for reads - Stratix10: add NAND IP node - Enable driver model watchdog - Enable USB3.1 node for Agilex5 * Config cleanups: - Simplify Agilex7 VAB defconfig - Remove obsolete SYS_BOOTM_LEN from N5X VAB config - Enable CRC32 support for SoCFPGA - Increase USB hub debounce timeout Overall this set improves reliability of DDR and cache flows, adds missing USB and MMC features for Agilex5, and refines clock and configuration handling across platforms. This patch set has been tested on Agilex 5 devkit, and Agilex devkit.
2025-09-30cache: Check dcache availability before calling cache functionsBoon Khai Ng
When the data cache (dcache) is disabled, calling related status functions can lead to compilation errors due to undefined references. Adding a !CONFIG_IS_ENABLED(SYS_DCACHE_OFF) check before invoking dcache_status() (used in common/memsize.c:get_ram_size()) and mmu_status() (from arch/arm/include/asm/io.h). Without this check, builds with dcache disabled will fail to compile. Signed-off-by: Boon Khai Ng <[email protected]> Reviewed-by: Tom Rini <[email protected]>
2025-09-26arm64: Add MIDR entry for Cortex-A720Marek Vasut
Add MIDR entry for Cortex-A720 core. Signed-off-by: Marek Vasut <[email protected]>
2025-09-26imx9: Change container header temp buffer addressYe Li
Due to i.MX95 has reserved first 256MB DDR, change to use the DDR start address in u-boot as the container header buffer. Signed-off-by: Ye Li <[email protected]> Signed-off-by: Alice Guo <[email protected]> Reviewed-by: Peng Fan <[email protected]>
2025-09-26imx9: scmi: Update the files under arch/arm/mach-imx/imx9/scmi/ to support ↵Ye Li
i.MX94 - Add base addresses for WDG3, WDG4, GPIO6, and GPIO7 for i.MX94. - Introduce common.h with macros of clock IDs, power domains, and CPU types for platform-specific replacement (e.g., i.MX94, i.MX95). - Extend imx_get_mac_from_fuse() to support i.MX94. Signed-off-by: Ye Li <[email protected]> Signed-off-by: Alice Guo <[email protected]> Acked-by: Peng Fan <[email protected]> Reviewed-by: Jacky Bai <[email protected]>
2025-09-26imx95: Add get_reset_reason() to retrieve the LM/system last booted/shutdown ↵Peng Fan
reasons System Manager provides the last booted and shutdown reasons of the logical machines (LM) and system using the SCMI misc protocol (Protocol ID: 0x84, Message ID: 0xA). This path adds get_reset_reason() to query and print these reasons in SPL and U-Boot. Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Alice Guo <[email protected]> Reviewed-by: Ye Li <[email protected]>
2025-09-26imx9: Add i.MX94 CPU type and SoC-level KconfigYe Li
Introduce support for the new i.MX94 processor, including its CPU type and SoC-level Kconfig entry. The i.MX94 is a new member of the i.MX9 family. It uses a System Manager to handle system-level functions such as power, clock, sensor and pin control. The System Manager runs on a Cortex-M processor, while the Cortex-A processor communicates with it via the ARM SCMI protocol and a messaging unit. Signed-off-by: Ye Li <[email protected]> Signed-off-by: Alice Guo <[email protected]> Acked-by: Peng Fan <[email protected]> Reviewed-by: Jacky Bai <[email protected]>
2025-09-23Merge tag 'v2025.10-rc5' into nextTom Rini
Prepare v2025.10-rc5
2025-09-21arm: imx9: Fix LPCG number in ccm_reg structureYe Li
The LPCG number on iMX93 and iMX91 is 127 not 122. The wrong value is used in ccm_reg structure and Coverity reports several issues as out-of-bounds write. Signed-off-by: Ye Li <[email protected]> Reviewed-by: Peng Fan <[email protected]>
2025-08-11arm: bcm235xx: Remove this SoCTom Rini
As there are no platforms for this SoC, remove the code. Signed-off-by: Tom Rini <[email protected]>
2025-08-08imx9: soc: Reuse and export low_drive_freq_update()Primoz Fiser
Reuse and export low_drive_freq_update() function. This way global imx9 board_fix_fdt() doesn't duplicate code. While low_drive_freq_update() can be reused on boards such as phyCORE-i.MX93 (TARGET_PHYCORE_IMX93) which is not using the global imx9 board_fix_fdt() implementation. While at it, make printout logic less verbose by only outputting on the error condition and not on each successful clock fixup. Also drop now invalid comment (low_drive_freq_update() now does fixup for internal and kernel device-tree). Signed-off-by: Primoz Fiser <[email protected]>
2025-08-04Merge branch 'u-boot-nand-03082025' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-nand-flash CI: https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/27258 This series address issues found by Andrew Goodbody and mostly drop driver that are not used by any board
2025-08-03mtd: nand: raw: Remove unused lpc32xx_nand_slc driverTom Rini
As no platforms use this driver anymore let's go ahead and remove it. Signed-off-by: Tom Rini <[email protected]>
2025-08-01video: tegra: parametrize PCLK and DE polaritySvyatoslav Ryhel
Configure pixel clock and data enable polarity according to panel flags. Signed-off-by: Svyatoslav Ryhel <[email protected]>
2025-08-01ARM: tegra: Use AES engine for crypto functionsIon Agorria
Previously software based AES encryption was used with previously known device specific keys (SBK), now that we have AES driver we can simply delegate this to the engine without prior knowledge of the key (assuming it is still loaded). Signed-off-by: Ion Agorria <[email protected]>
2025-08-01ARM: tegra: Add LP0 support for ODM productionIon Agorria
Now that we have working AES engine driver we can request the warmboot code to be encrypted and signed with SBK if the device requires so. This unlocks LP0 support for most devices in the wild as they use ODM Production Secure. We are not aware of any "ODM Production Open" device nor have access to thus this has not been tested on one, merely added for completeness. Signed-off-by: Ion Agorria <[email protected]>
2025-08-01crypto: tegra: Add Tegra AES engine driverIon Agorria
This driver allows using Tegra AES engines within BSEV and BSEA blocks to encrypt and decrypt data using different AES algorithms. One use case is allowing u-boot to self update by using the already loaded AES key in the engine's SBK slot by the bootrom. Particular care must be taken as chainloaded u-boot's may not have the SBK slot loaded as the vendor bootloader erases it before leaving it. Signed-off-by: Ion Agorria <[email protected]>
2025-08-01ARM: tegra: Relocate fuse code from warmboot fileIon Agorria
Move a set of helpers used in warmboot code to more appropriate AP and FUSE locations. Signed-off-by: Ion Agorria <[email protected]>
2025-07-29treewide: Fix STMicroelectronics spellingPatrice Chotard
Fix STMicroelectronics spelling in comments. Signed-off-by: Patrice Chotard <[email protected]>
2025-07-27sunxi: A523: add DRAM initialisation routineJernej Skrabec
DRAM init code, as per reverse engineering and matching against previous SoCs. As usual no real documentation, and the DRAM controller is the usual mixture of close-to-previous IP and new inventions. This version supports LPDDR4 for now only, as seen on the early boards. This needs improvements, but it can be done later. Signed-off-by: Jernej Skrabec <[email protected]> Signed-off-by: Andre Przywara <[email protected]>
2025-07-27sunxi: sun50i_h6: add A523 SPL clock setup codeJernej Skrabec
This adds the early A523 clock setup code, for the basic peripheral PLL and the basic bus clocks (APB/AHB). This is quite close to the existing H6 and H616 clock code, so this shares the same file. A few bits and bobs are different, though, so filter for the A523 in a few occasions. Signed-off-by: Jernej Skrabec <[email protected]> Signed-off-by: Andre Przywara <[email protected]>
2025-07-27sunxi: update cpu_sunxi_ncat2.hAndre Przywara
The cpu_sunxi_ncat2.h header file contains addresses of some peripherals that are needed for the SPL, for chips that belong to the "NCAT2" generation. The Allwinner A523 is a member of this group, but a few addresses differ, and we need a few more addresses, for playing with the core reset, for instance. Add the new addresses needed for the A523 and guard existing definitions that conflict with that new chip. Signed-off-by: Andre Przywara <[email protected]>
2025-07-27sunxi: spl: add support for Allwinner A523 watchdogAndre Przywara
The watchdog in the Allwinner A523 SoC differs a bit from the one in the previous SoCs: it lives in a separate register frame, so no longer inside some timer device, and it manages to shuffle around some registers a bit. But it also conveniently adds a direct reset functionality, so we don't need to use a dummy timeout period. Avoid introducing a new MMIO register frame C struct, but just define the one needed register offset as a macro. Then just trigger this new direct reset functionality in the A523 specific reset_cpu() implementation. Signed-off-by: Andre Przywara <[email protected]>
2025-07-27sunxi: clock: H6: add A523 CPU PLL supportAndre Przywara
The Allwinner A523 features 8 CPU cores, organised in two clusters, both driven by separate PLLs. Also there is the DSU PLL, which clocks the hardware that connects the cores to the rest of the system. And while the PLL registers itself are very similar, they are located in a separate register frame, outside the main CCU, and also the register controlling the CPU clock source (mux) is different. Provide a separate function that reparents the two clusters and the DSU, while their PLLs are programmed. For the actual PLL programming, we rely on the existing shared routine. The selection between the new A523 routine and the existing code is made with C if statements, but since the choice is effectively made at compile time already, the compiler optimises away the other code paths, leaving just the one required function in. Signed-off-by: Andre Przywara <[email protected]>
2025-07-27sunxi: clock: H6: factor out clock_set_pll()Andre Przywara
The SPL initial clock setup code for the Allwinner H6 and H616 SoCs uses a simple CPU PLL setup routine, which programs all register bits at once, then waits for the LOCK bit to clear. The manual suggests to follow a certain procedure for bringing up any PLLs, which involves several register writes, one at a time, and some delays. Also the H616 and the new A523 require some tiny changes in this sequence, and the different SoCs also feature some extra bits here and there, which we should not just clear. So factor out the PLL setup routine, and make it follow the manual's suggestion. This will read the PLL register at the beginning, then tweak the bits we need to manipulate, and writes the register several times on the way. This allows to cover the specific bits for different SoCs. Besides improving the reliability of the PLL setup, this helps with the A523, which requires *three* CPU PLLs to be programmed. Signed-off-by: Andre Przywara <[email protected]>
2025-07-27sunxi: clock: H6: unify PLL control bit definitionsAndre Przywara
The Allwinner PLLs share most of their control bits, they differ mostly in the factors and dividers. Drop the PLL specific definition of those common bits, and use one shared macro, for all PLLs. This requires changing the users in the SPL clock and DRAM code. Signed-off-by: Andre Przywara <[email protected]>
2025-07-24imx93_frdm: Add initial board supportFabio Estevam
Add the initial board support for the NXP i.MX93 FRDM board: https://www.nxp.com/design/design-center/development-boards-and-designs/frdm-i-mx-93-development-board:FRDM-IMX93 Based on the NXP U-Boot code. There were attempts to upstream the board devicetree, but it has not been accepted upstream yet: https://lore.kernel.org/linux-arm-kernel/[email protected]/ Once it reaches upstream, we can switch to OF_UPSTREAM. Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Peng Fan <[email protected]>
2025-07-17arm: imx: Remove unused mxcmmc driverTom Rini
As no platforms use this driver anymore, remove it. Signed-off-by: Tom Rini <[email protected]>
2025-07-17arm: imx: Update ELE get_info structure for i.MX94Ye Li
Since i.MX94, the ELE get_info structure is updated to add OEM PQC SRK hash, so update it. Signed-off-by: Ye Li <[email protected]> Signed-off-by: Jacky Bai <[email protected]> Signed-off-by: Alice Guo <[email protected]> Acked-by: Peng Fan <[email protected]>
2025-07-10arm: imx: Remove the rest of i.MX31 supportTom Rini
With the removal of the last i.MX31 platform we can remove the rest of the underlying architecture code as well. Fixes: f247354708ec ("arm: Remove mx31pdk board") Signed-off-by: Tom Rini <[email protected]> Acked-by: Peng Fan <[email protected]>
2025-06-29arch/arm/include/asm/arch-imxrt/gpio.h: imxrt gpio use common gpio.hGiulio Benetti
The current file defines a struct gpio_regs identical to the one in <asm/mach-imx/gpio.h>. To eliminate code duplication and align with the approach used for i.MX8M, include the common header instead of redefining the struct. Signed-off-by: Giulio Benetti <[email protected]>
2025-06-27Merge patch series "Fix io accessors for KVM"Tom Rini
Ilias Apalodimas <[email protected]> says: Instructions that lead ito an exception in the hypervisor can't modify two CPU registers at once for the ARM ISA. These instructions cannot be emulated by KVM as they do not produce syndrome information data that KVM can use to infer the destination register, the faulting address, whether it was a load or store, or if it's a 32 or 64 bit general-purpose register. As a result an external abort is injected from QEMU, via ext_dabt_pending. Link: https://lore.kernel.org/r/[email protected]
2025-06-27arm: io.h: Fix io accessors for KVMIlias Apalodimas
commit 2e2c2a5e72a8 ("arm: qemu: override flash accessors to use virtualizable instructions") explains why we can't have instructions with multiple output registers when running under QEMU + KVM and the instruction leads to an exception to the hypervisor. USB XHCI is such a case (MMIO) where a ldr w1, [x0], #4 is emitted for xhci_start() which works fine with QEMU but crashes for QEMU + KVM. These instructions cannot be emulated by KVM as they do not produce syndrome information data that KVM can use to infer the destination register, the faulting address, whether it was a load or store, or if it's a 32 or 64 bit general-purpose register. As a result an external abort is injected from QEMU, via ext_dabt_pending to KVM and we end up throwing an exception that looks like U-Boot 2025.07-rc4 (Jun 10 2025 - 12:00:15 +0000) [...] Register 8001040 NbrPorts 8 Starting the controller "Synchronous Abort" handler, esr 0x96000010, far 0x10100040 elr: 000000000005b1c8 lr : 000000000005b1ac (reloc) elr: 00000000476fc1c8 lr : 00000000476fc1ac x0 : 0000000010100040 x1 : 0000000000000001 x2 : 0000000000000000 x3 : 0000000000003e80 x4 : 0000000000000000 x5 : 00000000477a5694 x6 : 0000000000000038 x7 : 000000004666f360 x8 : 0000000000000000 x9 : 00000000ffffffd8 x10: 000000000000000d x11: 0000000000000006 x12: 0000000046560a78 x13: 0000000046560dd0 x14: 00000000ffffffff x15: 000000004666eed2 x16: 00000000476ee2f0 x17: 0000000000000000 x18: 0000000046660dd0 x19: 000000004666f480 x20: 0000000000000000 x21: 0000000010100040 x22: 0000000010100000 x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 000000004666f360 Code: d5033fbf aa1503e0 5287d003 52800002 (b8004401) Resetting CPU ... There are two problems making this the default. - It will emit ldr + add or str + add instead of ldr/str(post increment) in somne cases - Some platforms that depend on TPL/SPL grow in size enough so that the binary doesn't fit anymore. So let's add proper I/O accessors add a Kconfig option to turn it off by default apart from our QEMU builds. Reported-by: Mikko Rapeli <[email protected]> Tested-by: Mikko Rapeli <[email protected]> Signed-off-by: Ilias Apalodimas <[email protected]>
2025-06-24sunxi: add support for the Allwinner A100/A133 SoCAndre Przywara
The Allwinner A100 SoC has been around for a while, mostly on cheap tablets, but didn't generate much interest in the community so far. There were some efforts by two Allwinner employees in 2020, which led to basic upstream Linux support for that SoC, although this momentum dried up pretty quickly, leaving a lot of peripherals unsupported. The A100 was silently replaced with the seemingly identical Allwinner A133, which is reportedly a better bin of the A100. So far we assume that both are compatible from a software perspective. There are some more devices with the A133 out there now, so people are working on filling the gaps, and adding U-Boot (and TF-A) support. Based on the just added pinctrl, clock and DRAM support, this adds the missing bits, mostly addresses and values for the SPL. The A133 seems to be an predecessor to the H6, so we can share a lot of code with that (and the H616 code), and just need to adjust some details. Signed-off-by: Andre Przywara <[email protected]>
2025-06-24sunxi: A133: add DRAM init codeCody Eksal
This adds preliminary support for the DRAM controller in the Allwinner A100/A133 SoCs. This is work in progress, and has rough edges, but works on at least three different boards. It contains support for DDR4 and LPDDR4. Signed-off-by: Cody Eksal <[email protected]> [Andre: formatting fixes, adapt to mainline, drop unused parameters, remove struct struct sunxi_mctl_com_reg, hardcode MR registers, switch to mctl_check_pattern(), remove simple DRAM check] Signed-off-by: Andre Przywara <[email protected]>
2025-06-14Merge patch series "Hex value prefix case cleanup"Tom Rini
E Shattow <[email protected]> says: Make consistent use of lowercase hexadecimal prefix '0x' throughout U-Boot. There are a few remaining uses of uppercase 'X' to denote hexadecimal prefix or placeholder in documentation and error messages. External devicetree-rebasing dts/upstream and the generated code of xilinx/zynq are ignored for the series. Link: https://lore.kernel.org/r/[email protected]
2025-06-14arch: use lowercase hex prefix styleE Shattow
Use consistent lowercase hex prefix style in arch/* Signed-off-by: E Shattow <[email protected]>
2025-06-13arm: remove volatile from set_gd prototypeRasmus Villemoes
The global gd pointer is no longer volatile-qualified. Callers of this helper function have been updated to no longer use volatile-qualifed temporary variables, so update the prototype accordingly. Signed-off-by: Rasmus Villemoes <[email protected]>
2025-06-13arm: drop volatile qualifier from gd pointerRasmus Villemoes
There's a bunch of other places where this qualifier should be dropped, e.g. in the set_gd() prototype and for various variables used for stashing the value in the mach-imx/ directory and elsewhere. But that will be done in follow-up patches. Signed-off-by: Rasmus Villemoes <[email protected]> Tested-by: Anshul Dalal <[email protected]>
2025-05-08Merge branch 'staging' of https://source.denx.de/u-boot/custodians/u-boot-tegraTom Rini
2025-05-08video: tegra: add 8-bit CPU driven protocolSvyatoslav Ryhel
Add support for 8-bit CPU driven (primary and secondary) display signal interface found in Tegra 2 and Tegra 3 SoC. Tested-by: Ion Agorria <[email protected]> Signed-off-by: Svyatoslav Ryhel <[email protected]>
2025-05-08rockchip: rk3288: grf: Unify speed/flowctrl fields for clarityChristoph Fritz
Update GMAC speed and flow control fields in GRF_SOC_CON1 to use RK3288_GMAC_* prefix, ensuring a consistent naming convention. It also shifts each mask/bit definition to match the actual hardware bits, which makes future usage easier. Signed-off-by: Christoph Fritz <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-05-03imx9: scmi: add i.MX95 SoC and clock related codePeng Fan
This patch adds i.MX95 SoC and clock related code. Because they are based on SCMI, put them in the scmi subfolder. Signed-off-by: Alice Guo <[email protected]> Signed-off-by: Frank Li <[email protected]> Signed-off-by: Ji Luo <[email protected]> Signed-off-by: Jindong Yue <[email protected]> Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Ranjani Vaidyanathan <[email protected]> Signed-off-by: Ye Li <[email protected]>
2025-04-28Merge patch series "Apple RTKit improvements"Tom Rini
Mark Kettenis <[email protected]> says: This is a collection of improvements for the Apple RTKit code that we have been carrying downstream for some time now. Link: https://lore.kernel.org/r/[email protected]
2025-04-28arm: apple: rtkit: Add endpoint field to buffersHector Martin
To be used for special-case oslog support in rtkit-helper. Signed-off-by: Hector Martin <[email protected]> Signed-off-by: Mark Kettenis <[email protected]>
2025-04-28arm: apple: rtkit: Add a generic RTKit helper driverHector Martin
This driver handles the MTP ASC coprocessor, which does not need any special handling on the RTKit side and communicates out-of-band. Signed-off-by: Hector Martin <[email protected]> Signed-off-by: Mark Kettenis <[email protected]>
2025-04-28arm: apple: rtkit: Add support for AP power & syslogsHector Martin
This is required for MTP to work properly Signed-off-by: Hector Martin <[email protected]> Signed-off-by: Mark Kettenis <[email protected]>
2025-04-28sunxi: clock: H6: remove struct sunxi_prcm_regAndre Przywara
With the SPL clock code and the DRAM init routine we converted all users of the H6 class "struct sunxi_prcm_reg" over to use #define'd register offsets now. Drop the whole definition of this struct now, since it's not needed anymore, for all H6 and H616 boards. This removes the entire fragile and questionable definition, and allows new SoCs to share the code more easily. Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: H6/H616: dram: remove usage of struct sunxi_prcm_regAndre Przywara
The Allwinner H6 and H616 DRAM initialisation code uses a complex C struct, modelling the PRCM clock register frame. For those SoCs, this struct contains 20 registers, but the DRAM code only uses two of them. Since we want to get rid of this struct, drop the usage of the struct in the H6 and H616 DRAM code, by using #define'd register names and their offset, and then adding those names to the base pointer. This removes one more user of the PRCM clock register struct. Signed-off-by: Andre Przywara <[email protected]>
2025-04-28sunxi: clock: H6: drop usage of struct sunxi_prcm_regAndre Przywara
U-Boot drivers often revert to using C structures for modelling hardware register frames. This creates some problems: - A "struct" is a C language construct to group several variables together. The details of the layout of this struct are partly subject to the compiler's discretion (padding and alignment). - The "packed" attribute would force a certain layout, but we are not using it. - The actual source of information from the data sheet is the register offset. Here we create an artificial struct, carefully tuning the layout (with a lot of reserved members) to match that offset. To help with correctness, we put the desired information as a *comment*, though this is purely for the human reader, and has no effect on the generated layout. This sounds all very backwards. - Using a struct suggests we can assign a pointer and then access the register content via the members. But this is not the case, instead every MMIO register access must go through specific accessor functions, to meet the ordering and access size guarantees the hardware requires. - We share those structs in code shared across multiple SoC families, though most SoCs define their own version of the struct. Members must match in their name, across every SoC, otherwise compilation will fail. We work around this with even more #ifdefs in the shared code. - Some SoCs have an *almost* identical layout, but differ in a few registers. This requires hard to maintain #ifdef's in the struct definition. - Some of the register frames are huge: the H6 CCU device defines 127 registers. We use 15 of them. Still the whole frame would need to be described, which is very tedious, but for no reason. - Adding a new SoC often forces people to decide whether to share an existing struct, or to create a new copy. For some cases (say like 80% similarity) this works out badly either way. The Linux kernel heavily frowns upon those register structs, and instead uses a much simpler solution: #define REG_NAME <offset> This easily maps to the actual information from the data sheet, and can much simpler be shared across multiple SoCs, as it allows to have all SoC versions visible, so we can use C "if" statements instead of #ifdef's. Also it requires to just define the registers we need, and we can use alternative locations for some registers much more easily. Drop the usage of "struct sunxi_prcm_reg" in the H6 SPL clock code, by defining the respective register names and their offsets, then adding them to the base pointer. We cannot drop the struct definition quite yet, as it's also used in other drivers, still. Signed-off-by: Andre Przywara <[email protected]>