| Age | Commit message (Collapse) | Author |
|---|
|
Peng Fan (OSS) <[email protected]> says:
A few misc fixes to dm core. More information could be found in each
commit. Patch list:
dm: core: free old name in device_set_name to prevent leak
dm: core: Correct calloc arguments
dm: core: fix wrong strlen check in of_add_subnode
dm: core: free fdt when fdt_create_empty_tree failure
Link: https://lore.kernel.org/r/[email protected]
|
|
If device_set_name is called on a device that already has
DM_FLAG_NAME_ALLOCED set, the old dynamically-allocated name is leaked.
Free it before assigning the new name.
See: drivers/net/mdio_gpio.c:mdio_gpio_bind(). There is
device_set_name() here, however dm_mdio_post_bind() will also call
device_set_name() if "device-name" exists.
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Every other calloc in drivers/core uses calloc(count, size) with count
first. Fix the two reversed calloc(sizeof, 1) calls for consistency.
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Raphaël Gallais-Pou <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The duplicate-name check uses strlen on the search name instead of the
child name, so a child named "trevor" would falsely match a search
for "trev". Fix by checking strlen of child->name.
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Raphaël Gallais-Pou <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
If fdt_create_empty_tree fails, the malloc-ed fdt buffer is never freed.
Add free before the error return.
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Raphaël Gallais-Pou <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-efi
Pull request efi-2026-10-rc1
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-efi/-/pipelines/648
Documentation:
* board: renesas: Document SH/Aarch32/Aarch64 toolchain setup
* board: renesas: Document Aarch32 toolchain setup in RZ/N1
* board: renesas: Document Renesas R-Car Gen3 H3/M3-W/M3-N Salvator-X(S) board
* board: renesas: Document Renesas R-Car Gen3 H3/M3-W/M3-N ULCB board
* board: renesas: Document Renesas R-Car Gen3 M3Le Geist board
* board: renesas: Document Renesas R-Car Gen3 E3 Ebisu board
* board: renesas: Document Renesas R-Car Gen3 D3 Draak board
* board: renesas: Document Retronix R-Car Gen4 V4H Sparrow Hawk board
* board: renesas: Document Renesas R-Car Gen5 X5H Ironhide board
* board: renesas: Update Renesas generic build section
* board: renesas: Convert Renesas board support table to grid table
* boards: amlogic: update documentation for Beelink GT1 Ultimate
* CONTRIBUTE: use internal link instead of hardcoded external URL
* CONTRIBUTE: tell people reviewing *is* contributing
* CONTRIBUTE: explicitly list tests and documentation as welcome contributions
UEFI:
* fix building with CONFIG_EFI_VARIABLES_PRESEED=y
* fix buffer overrun in efi_sigstore_parse_siglist
* Correctly count the size on DTB measurements
* Change the return values if a TPM is missing during GetEventLog
* Measure secure boot variables in the correct PCR if DeployedMode is set
* fix missing EFI_EXIT in efi_disconnect_controller
* efi_selftest: free handles on teardown()
* efi_selftest: test block io revision and pointers
Others:
* qfw: fix RSDP ACPI table ext_checksum computation
|
|
table_compute_checksum() returns the value that makes the byte sum of
the buffer zero. If the ext_checksum field already contains a non-zero
value (as QEMU's firmware-provided RSDP does), adding that existing
value into the sum produces an incorrect complement. Zero the field
before calling table_compute_checksum() so the calculation starts from
a clean state, matching the pattern used in acpi_write_rsdp().
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
readl_relaxed_poll_timeout() relies on timers. On the beaglebone black,
the timer used by readl_relaxed_poll_timeout() depends on this clock
driver. So we have a sort of circular dependency [enable_clock ->
timer_init -> enable_clock -> timer_init]. It leads to a
division-per-zero during the second timer_init() and the beaglebone
fails to boot with following message:
| CPU : AM335X-GP rev 2.1
| Model: TI AM335x BeagleBone Black
| DRAM: 512 MiB
| ### ERROR ### Please RESET the board ###
Replace readl_relaxed_poll_timeout() with a simple loop that uses CPU
ticks to countdown the timeout. This loop and the value of LDELAY are
inspired from what's done in arch/arm/mach-omap2/am33xx/clock.c
Also, arch/arm/mach-omap2/am33xx/clock.c doesn't return an error on
timeout, it only logs it, so let's stick with it.
Fixes: de2e3f00f2fa ("clk: ti: Remove AM33xx dependency")
Signed-off-by: Bastien Curutchet <[email protected]>
Reported-by: Tom Rini <[email protected]>
Tested-by: Tom Rini <[email protected]>
|
|
Billy Tsai <[email protected]> says:
The AST2700 is Aspeed's 7th-generation BMC SoC with a dual-die
architecture: SoC0 (CPU die) and SoC1 (I/O die) each have their own SCU
with independent multi-function pin controls. Initial AST2700 platform
support is already merged in next, including the ast2700.dtsi pinctrl0
and pinctrl1 nodes, but no pinctrl driver backs them yet.
This series adds one pinctrl driver per die, each followed by a patch
adding its pin configuration support. Both drivers use the generic
pinctrl framework and are compatible with the Linux kernel device tree
bindings, using the same group and function names as the Linux
aspeed,ast2700-soc0/soc1-pinctrl drivers so pin states can be shared
between the kernel and U-Boot device trees.
Patch 1 adds the SoC0 driver, which models each (function, group) pair
as a flat register mask/value table covering eMMC, VB, VGA DDC, JTAG
master port select, PCIe RC PERST and USB2/USB3 port routing. Patch 2
adds SoC0 pin configuration support: every GPIO18A/GPIO18B ball has
its own IO control register providing a 3 mA to 41 mA drive strength
selector and bias control.
Patch 3 adds the SoC1 driver, porting the per-pin 4-bit multi-function
selector scheme (220 pins, 238 groups, 217 functions) together with
the virtual pins for PCIe RC2 PERST, the USB2 port C/D mode and SGMII
controls. Patch 4 adds SoC1 pin configuration support: a per-pin bias
enable bit and sparse 2-bit drive strength fields (4 mA to 16 mA in
4 mA steps) mirroring the Linux driver layout.
The bias-disable, bias-pull-down, bias-pull-up and drive-strength
properties can be applied per pin or per group. Both drivers implement
gpio_request_enable so the GPIO driver can reclaim pins through the
gpio-ranges already present in ast2700.dtsi, and provide
get_pin_muxing so "pinmux status" reports the active signal of every
pin.
Link: https://lore.kernel.org/r/[email protected]
|
|
The SoC1 SCU provides a bias enable bit per pin in the registers at
0x480 (setting the bit disables the bias; the pull direction is fixed
in silicon) and 2-bit drive strength fields at 0x4C0 selecting 4 mA to
16 mA in 4 mA steps. The pin-to-field mapping of the drive strength
registers is sparse and non-linear, so it is kept in a lookup table
mirroring the Linux driver; pins without an entry reject
drive-strength with -ENOTSUPP.
Support the bias-disable, bias-pull-down, bias-pull-up and
drive-strength properties per pin and per group, and select PINCONF so
the generic pinctrl framework parses them.
Signed-off-by: Billy Tsai <[email protected]>
|
|
Add the pinctrl driver for the AST2700 SoC1 (I/O) die.
Unlike previous Aspeed generations, the SoC1 SCU assigns every pin a
4-bit multi-function selector field in a contiguous register range
starting at SCU 0x400, eight pins per register. Only bits [2:0] of
each field select the function; bit 3 is reserved read-only and must
not be written. The driver therefore keeps per-pin group tables and
per-function mux values, mirroring the Linux
aspeed,ast2700-soc1-pinctrl driver, and shares the same device tree
bindings: 220 pins, 238 groups and 217 functions with identical names,
so pin states written for the Linux driver work unmodified.
A few controls live outside the pin-indexed range and are handled as
virtual pins: PCIERC2_PERST (SCU 0x908), the USB2 port C/D mode fields
(SCU 0x3B0) and SGMII0 (SCU 0x47C).
The gpio_request_enable hook restores a pin to GPIO by writing mux
value 0, except for the ADC-capable balls W17..AB19 where function 1
selects GPIO and 0 selects the ADC input.
Signed-off-by: Billy Tsai <[email protected]>
|
|
Each GPIO18A/GPIO18B ball has its own IO control register starting at
SCU 0x480, providing a 4-bit drive strength selector (3 mA to 41 mA in
hardware-defined steps), a bias enable bit and a pull direction bit.
Extend the group table with the pin members of the ball-backed groups
so bias-disable, bias-pull-down, bias-pull-up and drive-strength
properties can be applied per group as well as per pin. The routing
groups (USB, JTAG, PCIe RC) have no package balls and reject pin
configuration with -ENOTSUPP.
Select PINCONF so the generic pinctrl framework parses the pin
configuration properties.
Signed-off-by: Billy Tsai <[email protected]>
|
|
The AST2700 is a dual-die BMC SoC: SoC0 (CPU die) and SoC1 (I/O die)
each have their own SCU with independent multi-function pin controls.
Add the pinctrl driver for the SoC0 die. The driver uses the generic
pinctrl framework and is compatible with the Linux kernel device tree
bindings, i.e. pin states are described with the same "function" and
"groups" properties and the same names as the Linux
aspeed,ast2700-soc0-pinctrl driver.
Unlike the older AST2500/AST2600 SCUs where each signal is enabled by
independent bits, the SoC0 mux selections mix single-bit enables
(eMMC, VGA DDC, VB strap), multi-bit selector fields (JTAG master port
select, USB2/USB3 port routing) and reset-control bits (PCIe RC
PERST). Model each (function, group) pair as one register
mask/value write so all of them fit a single flat table.
The gpio_request_enable hook releases the GPIO18A/GPIO18B pins to GPIO
mode by clearing every signal enable bit that claims the pin, matching
the Linux driver behaviour.
Signed-off-by: Billy Tsai <[email protected]>
|
|
Add a UCLASS_I2C_EMUL driver that emulates a PMBus 1.x compliant chip
behind the sandbox I2C bus, plus the test.dts wiring and sandbox
defconfig that bind it to the generic PMBus regulator
(compatible = "pmbus"). This design is a stub only: it lets the
follow-up dm unit test drive lib/pmbus.c, the generic regulator and
the pmbus CLI command with no real hardware.
The emulator models a flat per-command 16-bit register file and the
three identification block strings (MFR_ID / MFR_MODEL /
MFR_REVISION). READ_IIN and READ_POUT are deliberately left
unimplemented (the chip NAKs them) so the telemetry printer's
"(not supported)" path is exercised, mirroring a real buck that only
calibrates a subset of the sensor classes.
Signed-off-by: Vincent Jardin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
The driver is a thin UCLASS_THERMAL: its get_temp reads the
temperature of its parent regulator through the pmbus helper
(READ_TEMPERATURE_1), without any chip-specific code.
Signed-off-by: Vincent Jardin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Per-chip UCLASS_REGULATOR driver for the MPS MPQ8785 / MPM3695 /
MPM3695-25 / MPM82504 family, layered on the shared pmbus_helper
adapter. Runs Linux's mpq8785_identify() VOUT_MODE switch
(LINEAR16 vs DIRECT m=64 R=1) at probe time, applies the optional
mps,vout-fb-divider-ratio-permille DT property, and walks the
documented MPS ADDR_VBOOT windows on MFR_ID failure so a
die-revision address shift just works.
Publishes the pmbus mps last|clear last|clear force vendor
extension subcommands (NVM PROTECTION_LAST read and clear) when
CMD_PMBUS is enabled.
Adapted from Linux code.
Signed-off-by: Vincent Jardin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
PMBus regulators differ in numeric formats and quirks, not in how they
are driven. Share that common behaviour as a regulator-uclass adapter
so chip drivers and the pmbus CLI do not each reimplement the decode
and transport, and add a catch-all driver on compatible = "pmbus" for
compliant chips that have no dedicated driver yet.
Gated by CONFIG_DM_REGULATOR_PMBUS_HELPER and
CONFIG_DM_REGULATOR_PMBUS_GENERIC.
Signed-off-by: Vincent Jardin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Clear the STAT register OR bit every time in .tstc callback, otherwise
a condition may occur when data are fed into the RX FIFO, the FIFO did
overflow, the OR bit is set and prevents any new data from being added
into the RX FIFO, the OR bit is never cleared, and watermark read back
is always 0. If this condition occurs, the .tstc callback will always
report no new characters, and the OR bit will never be cleared, so the
U-Boot shell will be unresponsive until next reboot or kernel boot.
This is easy to trigger on MX95, power on the system and send traffic
on UART from host to the MX95, the MX95 FIFO will overflow and the
U-Boot console will become unresponsive.
Fix this by clearing the OR bit early, in .tstc callback. This way,
even if an overflow occurs, there will be slight loss of RX data, but
the U-Boot console will not become unresponsive.
Signed-off-by: Marek Vasut <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Use CONFIG_IS_ENABLED() instead of IS_ENABLED() when checking the
MMC_IO_VOLTAGE symbol so the Kconfig option is evaluated correctly for
xPL builds.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
The Rockchip RK3399 SoC SDMMC IO domain supports 1.8V and 3.0V mode, and
the 3.0V mode is within SD Standards allowed 2.7V-3.6V range. However,
the commit 0b75109b6aaf ("mmc: dw_mmc: return error for invalid voltage
setting") help enforce strict 1.8V and 3.3V when setting vqmmc-supply
making mmc_set_signal_voltage() now fail for MMC_SIGNAL_VOLTAGE_330 and
leading to an improper switch to MMC_SIGNAL_VOLTAGE_180.
Use regulator_set_value_clamp() to set an SD Standards voltage range,
1.70V-1.95V and 2.7V-3.6V, I/O voltage instead of requiring an exact
regulator value to closer match Linux and to fix use of 3.3V signal
voltage on Rockchip RK3399 boards using MMC_IO_VOLTAGE=y.
Fixes: 0b75109b6aaf ("mmc: dw_mmc: return error for invalid voltage setting")
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add a sandbox LDO3 with a configurable 1.8V to 3.3V range and use it
to test regulator_set_value_clamp().
Test in-range requests, clamping against the regulator limits, invalid
ranges outside the regulator limits and a min value higher than max.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add regulator_set_value_clamp() that clamps a requested target voltage
to both caller-provided limits and the regulator constraints before
setting the regulator voltage value.
Return -EINVAL when the caller limits cannot be satisfied by the
regulator constraints or when the requested range is invalid.
This helper will initially be used to set vqmmc-supply voltage within an
acceptable range according to SD Standards, i.e. 1.70V-1.95V and
2.7V-3.6V.
Signed-off-by: Jonas Karlman <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Prevent NULL pointer dereference with lockstep mode.
Since commit 21d03d60e909 ("j7200 defconfig: add rproc commands"),
issuing rproc init command with cluster configured in lockstep results
in a NULL pointer dereference.
This is because ti_sci_proc_request() is called on both cores on the
same cluster, without checking if they are populated.
To fix that, only request the core being probed, as there is no need to
request the other one.
Moreover, the old code was requesting both cores in lockstep mode, but
only releasing one:
it called k3_r5f_proc_request() with ti_sci_proc_release(), instead of
using k3_r5f_proc_request()/k3_r5f_proc_release() or
ti_sci_proc_request()/ti_sci_proc_release().
So, replacing k3_r5f_proc_request() by ti_sci_proc_request() restores
the intended behavior.
Fixes: 21d03d60e909 ("j7200 defconfig: add rproc commands")
Signed-off-by: Richard Genoud (TI) <[email protected]>
|
|
U-Boot does not support modules, so having tristate options is useless.
Therefore this patch does a blind replace of all tristate options to
bool tree-wide.
Signed-off-by: Anshul Dalal <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Siddharth Vadapalli <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
Reviewed-by: Romain Gantois <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-rockchip
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-rockchip/-/pipelines/597
- Add new rockchip custodian,
- Remove inactive rockchip custodian,
- Preemptively fix rk3528/rk356x DTS issue that will come with 7.1
upstream DTS sync,
- Fix typo in doc,
- Fix variable used before being set in rockchip_nfc,
- Fix asm-operand-widths clang warning for RK3528, RK3576 and RK3588,
- Work around HW undefined state for NVMEs on RK3588 Jaguar,
- Added support for new devices:
- LinkEase EasePi R1
- 9Tripod X3568 v4
|
|
The oobfree[0].length calculation depends on the
rknand->metadata_size value, but this is calculated
after the function rk_nfc_ecc_init is called. Move this
calculation to a location before it's value is required.
Fixes: 1b3fcb3c0456 ("mtd: nand: raw: rockchip_nfc: add layout structure")
Signed-off-by: Johan Jonker <[email protected]>
Tested-by: Hüseyin BIYIK <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/hs/u-boot-i2c
i2c updates for 2026.10-rc1
- i2c: designware: fix i2c probe error
from Coben
It would be good to have some Testers...
- i2c: nx_i2c: updates from Peng
- Added License information
- use dev_read_addr_ptr()
- cmd: kconfig: i2c: add missing I2C API dependency
from Julien
|
|
Mikhail Kshevetskiy <[email protected]> says:
This patch series add pin controller and gpio driver support for EN7523/
AN7581/AN7583 SoCs. The driver based on official linux airoha pinctrl
and gpio driver with Matheus Sampaio Queiroga changes.
The original Matheus Sampaio Queiroga driver can be taken from the repo:
https://sirherobrine23.com.br/airoha_en7523/kernel/src/branch/airoha_en7523_pinctrl
Additionally in the EN7523 case the patches removes existing gpio dts
nodes and replaces them with pinctrl node. It should not be very
dangerous, because:
* No official EN7523 gpio support present in U-Boot
* Legacy Linux EN7523 GPIO driver is mostly abandoned
* The same driver is planned for upstream linux/openwrt
This patchset includes bitfield.h patches created for Linux kernel by
Geert Uytterhoeven. It suits U-Boot fine. I preserve original author and
original commit messages. Please note me, if there is a better way.
The patches were tested on EN7523/AN7581/AN7583 boards.
Link: https://lore.kernel.org/r/[email protected]
|
|
This patch adds U-Boot pin controller and gpio driver for Airoha EN7523 SoC.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Reviewed-by: David Lechner <[email protected]>
|
|
This patch adds U-Boot pin controller and gpio driver for Airoha AN7583 SoC.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Reviewed-by: David Lechner <[email protected]>
|
|
This patch adds U-Boot pin controller and gpio driver for Airoha AN7581 SoC.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Reviewed-by: David Lechner <[email protected]>
|
|
This patch introduce shared Airoha pinctrl code.
Also it sorts contents of pinctrl makefile.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Reviewed-by: David Lechner <[email protected]>
|
|
sorting rules:
* rules for generic pinctrl files placed first,
* obj-y rules,
* obj-$(CONFIG_ARCH_something) rules
* obj-$(CONFIG_PINCTRL_something) rules
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Reviewed-by: David Lechner <[email protected]>
|
|
Drop the driver-specific field_get() and field_prep() macros, in favor
of the globally available variants from <linux/bitfield.h>.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Drop the driver-specific field_get() and field_prep() macros, in favor
of the globally available variants from <linux/bitfield.h>.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Drop the driver-specific field_get() and field_prep() macros, in favor
of the globally available variants from <linux/bitfield.h>.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Drop the driver-specific field_get() and field_prep() macros, in favor
of the globally available variants from <linux/bitfield.h>.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Drop the driver-specific field_get() and field_prep() macros, in favor
of the globally available variants from <linux/bitfield.h>.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Probing i2c slave device just needs its device address.
A certain type of chipsets such as RTC S35390A have no offset,
which means address length should be 0.
But the current designware_i2c_probe_chip function requires
offset 0 and its length 1.
This causes the designware-i2c to be initialized again and again.
Furthermore, after booting into kernel, the designware-i2c kernel
driver complains its controller timeout.
This patch fixes this misbehaviour in such way that only device
address is issued, no reinitialization needs when target device
not detected, the designware-i2c kernel driver continues working.
Signed-off-by: Coben Han <[email protected]>
|
|
Add License information for nx_i2c driver.
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Use dev_read_addr_ptr() which supports both live device tree and flat DT
backends, avoiding direct dependency on devfdt_* helpers.
No functional changes.
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
zynqmp_mmio_read() and zynqmp_mmio_write() selected between direct MMIO
and the firmware (PM_MMIO_READ/WRITE) interface with an in-function
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) / current_el() check. Generic arch
code should not carry firmware-specific ifdefs, and with SCMI the access
method changes again.
Split the accessors like the multiboot and bootmode hooks: the weak
default in arch/arm/mach-zynqmp does the direct MMIO access (used in SPL,
at EL3 and when no firmware is present), while firmware-zynqmp.c provides
a strong definition that issues the firmware call and falls back to the
direct access in SPL/EL3 where the SMC path is unavailable. The raw MMIO
primitives zynqmp_mmio_rawread() and zynqmp_mmio_rawwrite() are exported
for the shared fallback, and the read-modify-write helper now uses the
raw read instead of routing through the firmware-aware accessor.
The firmware-vs-MMIO decision is selected at link time, so adding SCMI
later only requires a third strong definition with no changes to generic
code.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/d532df144d2c8e34be835bad6d0de3b26befdf01.1782219202.git.michal.simek@amd.com
|
|
versal_net_get_bootmode() open-coded the
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call
zynqmp_pm_get_bootmode_reg() and a direct readl() in board code. Like
the Versal change, move the whole function behind an overridable hook so
generic board code stays free of firmware specifics and is ready for
SCMI.
The weak versal_net_get_bootmode() in arch/arm/mach-versal-net does the
plain MMIO read via versal_net_bootmode_reg() and decodes it (used at EL3
and without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled,
firmware-zynqmp.c provides a strong definition that reads the register
through the firmware call, falling back to the direct read at EL3 where
the SMC path to firmware is unavailable. This preserves the existing
firmware-based bootmode behaviour while removing the firmware interface
from board code; the now unused zynqmp_firmware.h include is dropped.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/be67e9c6d0bc36840a46594413886d2003967c64.1782219202.git.michal.simek@amd.com
|
|
versal_get_bootmode() lived in board code and open-coded the
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call
zynqmp_pm_get_bootmode_reg() and a direct readl(). To keep generic board
code free of firmware specifics and SoC register details and ready for
SCMI, move the whole function, including the alt-shift and mask decoding,
behind an overridable hook.
The weak versal_get_bootmode() in arch/arm/mach-versal does the plain
MMIO read via versal_bootmode_reg() and decodes it (used at EL3 and
without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled,
firmware-zynqmp.c provides a strong definition that reads the register
through the firmware call, falling back to the direct read at EL3 where
the SMC path to firmware is unavailable. This preserves the existing
firmware-based bootmode behaviour while removing the firmware interface
from board code; the now unused zynqmp_firmware.h include is dropped.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/d60073feed8da8d3aff9eabee6ab132e0bbd0f8e.1782219202.git.michal.simek@amd.com
|
|
versal_multi_boot() in board code selected between the firmware call
zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not
carry firmware-specific ifdefs, and this becomes harder to maintain once
SCMI introduces yet another access method.
Introduce an overridable accessor versal_pmc_multi_boot(). The weak
default lives in arch/arm/mach-versal and performs the plain MMIO read
(used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE
is enabled, firmware-zynqmp.c provides a strong definition that issues the
firmware call, falling back to the direct read at EL3 where the SMC path
to firmware is unavailable. The shared MMIO read is factored into
versal_multi_boot_reg() so the firmware override does not duplicate it.
versal_multi_boot() keeps the generic JTAG/QEMU workaround and simply
calls the accessor, so board code no longer references the firmware
interface for the multiboot register. The firmware-vs-MMIO decision is
selected at link time, and adding SCMI later only requires a third strong
definition with no board-code changes.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/199ef6a1411c54f154fe4a43b5fef166b9927f7a.1782219202.git.michal.simek@amd.com
|
