| Age | Commit message (Collapse) | Author |
|---|
|
Kever has been pulled into different responsibilities at Rockchip and
this means he has less to no time for his maintainership in U-Boot as
has been seen for about a year now. Let's try to improve the situation
and have Rockchip-related things merged again by adding myself as
another maintainer.
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Philipp hasn't been active for years so we thank Philipp for his work
over the years and update the MAINTAINERS entry to reflect the reality.
Reviewed-by: Tom Rini <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
rockusb is a Rockchip feature, so let's match *anything* with that in
the path.
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
A few drivers are not using "rockchip" in their path so they aren't
currently detected by get_maintainer.pl as belonging to the ARM ROCKCHIP
entry, so let's fix that oversight by adding them individually. We could
use N: rk_ but I feel this isn't distinctive enough to avoid too many
false positive and I don't want to be keeping a list of things to not
match against.
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
rkmtd is a Rockchip feature, so let's match *anything* with that in the
path.
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Rockchip has an RV11xx SoC series (RV1103, RV1106, RV1126) so let's
match *anything* in U-Boot which contains this string in the path and
not only the U-Boot Device Trees.
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Rockchip also manufactures PMICs and regulators typically under the
RK8xx naming scheme (e.g. RK806, RK808, RK860, etc.) so let's match
files with rk8 in their path.
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Most Rockchip SoCs have their name start with rk3xxx. Historically, the
second digit is for the generation of SoC, e.g. rk31xx was before
rk32xx, itself before rk33xx and now rk35xx (and the expected rk36xx end
of this year). We won't talk about the rk30xx timeline but it's also
prefixed the same way. So let's match *anything* in U-Boot which
contains rk3 in the path to simplify the MAINTAINERS entry and hopefully
catch as much as possible.
board/firefly/ and board/pine64/ only contain subdirectories and each of
them have rk3 in their name.
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
PX5 is a Rockchip SoC, so let's match *anything* in U-Boot which
contains this string in the path. However, this matches a bit too much,
specifically the PPC-based kmsupx5_defconfig so we need to exclude it
explicitly.
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
PX30 is a Rockchip SoC, so let's match *anything* in U-Boot which
contains this string in the path.
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
It is a tool to be used with Rockchip SoCs so let's add it to the
MAINTAINERS entry for ARM ROCKCHIP.
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
The ARM ROCKCHIP entry already specifies an N: rockchip so we don't need
to repeat a path with F: if it has rockchip in the path, so drop it.
Note that for some reason get_maintainer.pl doesn't return the exact
same list before and after this patch.
Reviewed-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Use N: to match on all zynq/zynqmp files, drop the large list of
entries which represent the same set of relevant files and miss a
few in the process. Combine Zynq and ZynqMP entries into single
entry to further cut down the duplication.
Signed-off-by: Marek Vasut <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
|
|
Since I've added various features in the arm architecture
support and review most of the patches nowadays, add myself
as a co-maintainer
Signed-off-by: Ilias Apalodimas <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
When I merged the changes in commit 0d8e33717d7e ("Merge patch series
"arm: aspeed: add initial AST2700 SoC support"") I didn't fully remove
the before/after changes. Finish this merge now.
Reported-by: Yao Zi <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Adding an entry for the PCI subsystem and add myself to the list
of maintainers to review patches and maintain the PCI subsystem core
along the ongoing work of the PCI platform maintainers.
Acked-by: Tom Rini <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Use N: to match on all cortina files, drop the large list of
entries which represent the same set of relevant files and miss a
few in the process.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Ryan Chen <[email protected]> says:
AST2700 is the 8th generation of Integrated Remote Management
Processor introduced by ASPEED Technology Inc. It is a Board
Management Controller (BMC) SoC family with a dual-die architecture:
SoC0 ("CPU" die with four ARM Cortex-A35 application cores) and
SoC1 ("IO" die with peripherals) each SoC have its own SCU PLLs,
clock dividers and reset domains.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a SDRAM controller driver for the AST2700, derived from the
existing AST2700 controller code used by the Ibex SPL but adapted
to run from ARM U-Boot proper on the Cortex-A35 cores.
The DDR4/DDR5 controller and its DesignWare PHY are programmed by
the Ibex SPL before ARM U-Boot proper takes over. This driver
reads back the configuration left by the SPL, probes the
controller, and exposes ram_info (base and size, with the VGA
carve-out subtracted) via UCLASS_RAM so that dram_init() can
populate gd->ram_size.
The PHY firmware-load entry points (dwc_ddrphy_phyinit_userCustom_*)
are kept compiled but call a __weak fmc_hdr_get_prebuilt() stub
when ARM U-Boot proper is the caller; the real implementation is
provided by the Ibex SPL via the same fmc_hdr.h descriptor format
(here added for the ARM build).
Adds the supporting register-layout headers under
arch/arm/include/asm/arch-aspeed/:
- sdram.h: SDRAM controller and DWC PHY register definitions
- scu.h: SCU bits referenced by the SDRAM driver
- fmc_hdr.h: prebuilt-blob descriptor (binary-compatible with
arch/riscv/include/asm/arch-ast2700/fmc_hdr.h used
by the Ibex SPL)
Signed-off-by: Ryan Chen <[email protected]>
|
|
Add reset controller driver for the dual-die AST2700 SoC. The
controller manages module-level reset signals via the modrst
register block at offset 0x200 within each SCU.
Signed-off-by: Ryan Chen <[email protected]>
|
|
Add initial device tree support for the ASPEED AST27xx family, the
8th-generation Baseboard Management Controller (BMC) SoCs.
AST27xx SOC Family
- https://www.aspeedtech.com/server_ast2700/
- https://www.aspeedtech.com/server_ast2720/
- https://www.aspeedtech.com/server_ast2750/
The AST27xx features a dual-SoC architecture consisting of two ties,
referred to as SoC0 and SoC1 - interconnected through an internal
property bus. Both SoCs share the same address decoding scheme,
while each maintains independent clock and reset domains.
- SoC0 (CPU die): contains a dual-core Cortex-A35 cluster and two
Cortex-M4 cores, along with high-speed peripherals.
- SoC1 (I/O die): includes the BootMCU (responsible for system
boot) and its own clock/reset domains low-speed peripherals.
The device tree describes the SoC0 and SoC1 domains and their peripheral
layouts.
Signed-off-by: Ryan Chen <[email protected]>
|
|
Add initial support for the ASPEED AST2700, an arm64 (Cortex-A35)
Baseboard Management Controller (BMC) SoC. AST2700 is Aspeed's 8th
generation BMC and uses a dual-die architecture: SoC0 (the "CPU"
die) hosts the four Cortex-A35 cores and its own SCU at 0x12c02000,
while SoC1 (the "IO" die) hosts the peripherals and its own SCU at
0x14c02000.
This commit adds:
- ASPEED_AST2700 Kconfig option and the ast2700 mach subdir
(mach Makefile, ast2700/Kconfig, board/aspeed/evb_ast2700/*)
- arm64 MMU map covering the SoC device window and the DRAM
region at 0x4_0000_0000 (up to 8 GiB)
- lowlevel_init.S for early CPU bring-up
- cpu-info: print SoC ID (AST2700/2720/2750 A0/A1/A2 variants)
and reset cause (cold reset, EXT reset, WDT reset)
- board_common: dram_init via UCLASS_RAM, AHBC timeout init
- platform: env_get_location() that selects SPI/eMMC based on
the IO-die HW strap; arch_misc_init() that exposes
${boot_device} and ${verify} to the boot script
- SCU0/SCU1 register layout header (scu_ast2700.h)
- configs/evb-ast2700_defconfig and include/configs/evb_ast2700.h
for the AST2700 EVB board
The defconfig depends on ast2700-evb.dts, which is introduced in
a subsequent patch; this commit must be applied with the
remaining series for evb-ast2700_defconfig to build.
Signed-off-by: Ryan Chen <[email protected]>
|
|
Bastien Curutchet <[email protected]> says:
This series aims to add back the omap4 support. This support was removed
by commit b0ee3fe642c ("arm: ti: Remove omap4 platform support") because
at that moment, none of the OMAP4-based boards had done the migration to
DM_I2C.
My use case is an old product based on the Variscite's omap4 system on
module. I needed to upgrade U-Boot on it for security reasons. I think
that this work could benefit to other people who may have same kind of
product to maintain.
Patch 1 to 3 remove the omap's clock driver dependency to the AM33xx
as it is also present in omap4 platforms. I tested these changes on the
beaglebone black to ensure I didn't break the AM33xx case.
Patch 4 & 5 revert the deletion of the omap4 support. The revert makes
checkpatch.pl angry. I fixed quite a lots of warnings already but it
remains two kinds of warnings:
- CamelCase on timings structure, I left the CamelCase because IMHO it's
more readable this way.
- #ifdef CONFIG_XYZ shouldn't be used anymore. I left one of this because
I didn't find a clean way to get rid of it.
Patch 6 adds support for the Variscite's system on module. This system on
module is supported by the Linux project through
ti/omap/omap4-var-som-om44.dtsi
Link: https://lore.kernel.org/r/[email protected]
|
|
OMAP4 support is present but there isn't any board using it.
Add minimal support for the Variscite OMAP4-SoM (debug console + boot
from SD card).
Use the ti/omap/omap4-var-stk-om44 device-tree from the Linux kernel. The
real representation of the SoM's hardware is located in
ti/omap/omap4-var-som-om44.dtsi included in it.
Set myself as maintainer for it.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
omap4 support was dropped by b0ee3fe642c ("arm: ti: Remove omap4 platform
support") because the supported boards hadn't done the conversion to
CONFIG_DM_I2C in time. It still exists some omap4-based products and
they could benefit from the latest U-Boot support for obvious security
reasons.
Revert part of b0ee3fe642c to introduce back a minimal support for the
omap4 platform.
Fix the checkpatch's warning/errors induced by this revert. Following
warnings are still present:
| arch/arm/include/asm/arch-omap4/clock.h:445: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
| arch/arm/mach-omap2/omap4/hwinit.c:24: WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible
| arch/arm/mach-omap2/omap4/sdram_elpida.c:142: CHECK: Avoid CamelCase: <tRPab>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:143: CHECK: Avoid CamelCase: <tRCD>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:144: CHECK: Avoid CamelCase: <tWR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:145: CHECK: Avoid CamelCase: <tRASmin>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:146: CHECK: Avoid CamelCase: <tRRD>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:147: CHECK: Avoid CamelCase: <tWTRx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:148: CHECK: Avoid CamelCase: <tXSR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:149: CHECK: Avoid CamelCase: <tXPx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:150: CHECK: Avoid CamelCase: <tRFCab>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:151: CHECK: Avoid CamelCase: <tRTPx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:152: CHECK: Avoid CamelCase: <tCKE>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:153: CHECK: Avoid CamelCase: <tCKESR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:154: CHECK: Avoid CamelCase: <tZQCS>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:155: CHECK: Avoid CamelCase: <tZQCL>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:156: CHECK: Avoid CamelCase: <tZQINIT>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:157: CHECK: Avoid CamelCase: <tDQSCKMAXx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:158: CHECK: Avoid CamelCase: <tRASmax>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:159: CHECK: Avoid CamelCase: <tFAW>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:209: CHECK: Avoid CamelCase: <tRL>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:210: CHECK: Avoid CamelCase: <tRP_AB>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:213: CHECK: Avoid CamelCase: <tRAS_MIN>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:215: CHECK: Avoid CamelCase: <tWTR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:216: CHECK: Avoid CamelCase: <tXP>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:217: CHECK: Avoid CamelCase: <tRTP>
I didn't find an clean way to fix the "don't use #ifdef" warning as we
need to define the gpio_bank for the SPL build only.
For the CamelCase warnings, the incriminated attributes represent
timings, so IMHO, it is more readable with CamelCase.
Set myself as OMAP4 maintainer.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-mediatek into next
* Network support for Genio 520/720.
* Order drivers/net Makefile and Kconfig.
* Refactor some common Airoha net/phy functions to a new common file.
* Add new AN8801 chip support.
* Add board-specific devicetree and config.
* Use scnprintf() instead of snprintf() in mtk pinctrl.
* Align configs for Genio EVK boards.
|
|
mach-axiado AX3005 SCM3005 board, a quad-core ARM Cortex-A53 (ARMv8/ARM64) platform."
Siu Ming Tong <[email protected]> says:
Patch 1 adds the device tree files: an SoC-level DTSI describing
GIC-v3, Cadence/Zynq UART, a fixed reference clock, and spin-table
secondary CPU boot, plus a board-level DTS setting the console to
uart3 at 115200 baud with 2 GB DRAM at 0x80000000.
Patch 2 adds mach-axiado to support Axiado SoC-based boards, Kconfig
plumbing (AXIADO_AX3005 and TARGET_SCM3005), defconfig, board source
with ft_board_setup() and a MAINTAINERS entry.
Tested on SCM3005 EVK hardware
Link: https://lore.kernel.org/r/[email protected]
|
|
Use N: to match on all aspeed/ast2500 files, drop the large list of
entries which represent the same set of relevant files and miss a
few in the process.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Introduce mach-axiado to support Axiado SoC-based boards. This adds
the platform Kconfig and build infrastructure, along with initial
SCM3005 board support using the AX3005 SoC.
Introduces AXIADO_AX3005, which selects ARM64, driver
model, GIC-v3, and Zynq UART. TARGET_SCM3005 selects ARCH_AXIADO,
allowing future SoC variants to share the platform configuration.
Secondary cores use spin-table boot. ft_board_setup() corrects
the cpu-release-addr in the FDT, which arch_fixup_fdt() overwrites
with the post-relocation address.
Add U-Boot board support for the Axiado AX3005 based targets, a quad-core
ARM Cortex-A53 (ARMv8) platform.
Tested-by: Siu Ming Tong <[email protected]>
Signed-off-by: Karthikeyan Mitran <[email protected]>
Signed-off-by: Siu Ming Tong <[email protected]>
|
|
Synopsys DWC Ethernet QOS device support for MediaTek SoCs.
in particular this initial commit adds support for Genio 520/720 and
Genio 510/700 EVKs
Signed-off-by: fanyi zhang <[email protected]>
Signed-off-by: Julien Stephan <[email protected]>
Reviewed-by: Macpaul Lin <[email protected]>
Link: https://patch.msgid.link/20260429-add-ethernet-support-for-genio-520-720-v4-7-be54e17239b7@baylibre.com
Signed-off-by: David Lechner <[email protected]>
|
|
Add Airoha AN8801 Ethernet PHY driver (air_an8801.c).
Implement CL22/CL45 MDIO access, LED control, and RGMII delay
configuration. Provide probe, initialization, LED setup, and status
handling. Expose DTS properties for clock delays. Register driver with
PHY framework and trigger on startup.
Signed-off-by: Yanqing Wang <[email protected]>
Signed-off-by: Julien Stephan <[email protected]>
Reviewed-by: Kevin-KW Huang <[email protected]>
Link: https://patch.msgid.link/20260429-add-ethernet-support-for-genio-520-720-v4-6-be54e17239b7@baylibre.com
Signed-off-by: David Lechner <[email protected]>
|
|
In preparation of Airoha AN8801R PHY support, move the BuckPBus
register accessors and definitions, present in air_en8811h driver,
into the Airoha PHY shared code (air_phy_lib), so they will be usable
by the new driver without duplicating them.
Also, update air_en8811h driver to use the new function names.
Adapted from [1].
[1]: https://lore.kernel.org/all/20260326-add-airoha-an8801-support-v2-2-1a42d6b6050f@collabora.com/
Signed-off-by: Julien Stephan <[email protected]>
Link: https://patch.msgid.link/20260429-add-ethernet-support-for-genio-520-720-v4-5-be54e17239b7@baylibre.com
Signed-off-by: David Lechner <[email protected]>
|
|
Add a new entry for drivers/net/phy/airoha/air_en8811.c driver.
Signed-off-by: Julien Stephan <[email protected]>
Reviewed-by: Tommy.Shih <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Link: https://patch.msgid.link/20260429-add-ethernet-support-for-genio-520-720-v4-2-be54e17239b7@baylibre.com
Signed-off-by: David Lechner <[email protected]>
|
|
For consistency, remove trailing colons for the three following
sections: ACPI, ALIST, and INTERCONNECT.
Signed-off-by: Julien Stephan <[email protected]>
Link: https://patch.msgid.link/20260429-add-ethernet-support-for-genio-520-720-v4-1-be54e17239b7@baylibre.com
Signed-off-by: David Lechner <[email protected]>
|
|
It is designed as a generic UCLASS_THERMAL driver for any JEDEC
JC-42.4 family of on-DIMM temperature sensors (TSE2004av and
compatible parts).
The driver reads the temperature register over DM I2C.
The "jedec,jc-42.4-temp" compatible is Linux-aligned (see
Documentation/devicetree/bindings/hwmon/jedec,jc-42.4-temp.yaml in
the Linux tree).
When CMD_TEMPERATURE is enabled, the sensor becomes available with
the standard commands "temperature list" / "temperature get".
Signed-off-by: Vincent Jardin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Introduce a sysinfo driver that can be instantiated from the device,
which will provide information from the EEPROM found on all TQ-Systems
SoMs.
Signed-off-by: Nora Schiffer <[email protected]>
Signed-off-by: Max Merchel <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Alexander Feilke <[email protected]>
|
|
Prepare v2026.07-rc3
|
|
Our official domain is now u-boot-project.org, so update all in-tree
references to use the correct domain.
Reviewed-by: Tony Dinh <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Adding myself to continue Bin's work to help maintain the
NVMe support in U-boot.
Acked-by: Tom Rini <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Reduce the NXP MAINTAINERS entry by using N: entry glob.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Fabio Estevam <[email protected]>
|
|
The main use case for u-boot on Apple silicon based devices is to
provide an EFI based bootloader for operating systems. This uses a
generic u-boot image with DTBs passed from an earlier boot loader
(m1n1). Use the generic board name "mac" for this purpose.
Signed-off-by: Janne Grunau <[email protected]>
|
|
I'm one of the co-maintainers of Apple silicon support in the Linux
kernel and have contributed to u-boot's Apple SoC support.
Signed-off-by: Janne Grunau <[email protected]>
Acked-by: Mark Kettenis <[email protected]>
|
|
The files weren't added to MAINTAINERS but clearly belong to Apple
silicon (M1) support.
Signed-off-by: Janne Grunau <[email protected]>
Acked-by: Mark Kettenis <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-snapdragon
Various Qualcomm additions this cycle:
* USB superspeed support for 1 platform
* Initial support for the Milos platform and the Fairphone Gen 6
(chainloaded from ABL)
* Improved support for booting with OP-TEE on supported platforms
* Initial basic power domain support
Notably there is a generic change to the device core, missing power
domains will no longer cause a device to fail probe and instead will
just print a warning. This shouldn't affect any existing platforms.
|
|
Add the file pattern for Qualcomm PHY drivers to the MAINTAINERS file.
Signed-off-by: Balaji Selvanathan <[email protected]>
Reviewed-by: Varadarajan Narayanan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
Replace old bouncing emails with [email protected]
Signed-off-by: Eugen Hristev <[email protected]>
|
|
Add support for the DesignWare-based PCIe host controller found in
AMD Versal2 SoCs. This enables PCIe functionality (e.g. NVMe storage)
on boards such as the VEK385.
The driver builds on the existing pcie_dw_common infrastructure and
adds Versal2-specific handling: it maps the SLCR register region to
mask and clear TLP interrupt status bits, parses dbi/config/atu/slcr
register regions from device tree, and supports an optional PERST#
GPIO on child nodes for endpoint reset sequencing. The outbound iATU
is programmed for the non-prefetchable memory window from device tree
ranges.
Signed-off-by: Pranav Sanwal <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
Soon I will no longer be working at SECO. Update the mailmap to redirect
to my linux.dev address which I still have access to.
Signed-off-by: Sean Anderson <[email protected]>
Reviewed-by: Sean Anderson <[email protected]>
|
|
Define CONFIG_SYS_SOC in the mach-sc5xx Kconfig. Follow the standard
U-Boot include path convention by moving the SC5xx SoC headers from
arch/arm/include/asm/arch-adi/sc5xx/ to the conventional
arch/arm/include/asm/arch-sc5xx/ location. Update includes from
<asm/arch-adi/sc5xx/*.h> to <asm/arch/*.h> across mach-sc5xx and board
files.
Signed-off-by: Philip Molloy <[email protected]>
|
