| Age | Commit message (Collapse) | Author |
|
After the K1 build switched to dts/upstream/src/riscv/spacemit/ and the
local arch/riscv/dts/k1.dtsi was deleted, the legacy
reset-controller@d4050000 DT node no longer exists. The of_match driver
in drivers/reset/reset-spacemit-k1.c (compatible "spacemit,k1-reset")
matches nothing and only sits in the binary as dead code.
Remove the legacy driver file, its Makefile entry, the RESET_SPACEMIT_K1
Kconfig symbol, and its bananapi-f3_defconfig selection. The new
syscon-bound reset driver under drivers/reset/spacemit/ has no
DT of_match of its own and is spawned by the K1 clock drivers, so gate
the subdirectory on CONFIG_CLK_SPACEMIT_K1 instead.
Signed-off-by: Guodong Xu <[email protected]>
|
|
The K1 reset driver in drivers/reset/spacemit/ binds by name (no DT
of_match), so the per-syscon clock drivers must spawn it.
Add a .bind hook to k1_mpmu_clk, k1_apbc_clk and k1_apmu_clk that
calls spacemit_k1_reset_bind() to instantiate a UCLASS_RESET sibling
on the same ofnode.
Also introduce k1_apbc2_clk here. Its kernel DT node has #reset-cells
but no #clock-cells, so the driver exists only as the binding hook
for the apbc2 reset spawn.
With this in place, references such as
resets = <&syscon_apbc RESET_TWSI0>;
in the kernel-mainline DT resolve correctly.
Signed-off-by: Guodong Xu <[email protected]>
|
|
The existing K1 reset driver (drivers/reset/reset-spacemit-k1.c) binds
via DT of_match against a top-level reset-controller node, but kernel
mainline DT for K1 has no such node: the mpmu, apbc, apmu and apbc2
syscons each spawn their own reset device as an auxiliary of the
clock controller. The legacy driver therefore cannot consume it.
Add a new reset driver at drivers/reset/spacemit/reset-spacemit-k1.c
bound by name from each per-syscon clock driver via
device_bind_driver_to_node(), without DT of_match, mirroring the
kernel's auxiliary-device pattern.
To keep the series bisectable, this driver coexists link-cleanly with
the legacy spacemit,k1-reset driver during the transition. A
follow-up patch that switches the K1 build to
dts/upstream/src/riscv/spacemit/ will drop the legacy driver.
Signed-off-by: Guodong Xu <[email protected]>
|
|
The K1 SoC exposes four clock providers in the kernel mainline DT: one
PLL controller ("spacemit,k1-pll") and three syscon clock nodes
("spacemit,k1-syscon-{mpmu,apbc,apmu}"). Register a separate
U_BOOT_DRIVER for each.
The controllers register clocks into a single CCF namespace, and a clock
in one controller may parent off a clock owned by another, so a
controller must register only after the controllers that own its parents
have probed. Each probe forces its parent controllers up by driver:
MPMU <- PLL
APMU <- PLL, MPMU
APBC <- PLL, MPMU, APMU
Signed-off-by: Junhui Liu <[email protected]>
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Guodong Xu <[email protected]>
|
|
ufshcd_get_req_rsp() invalidates only sizeof(struct utp_upiu_rsp) of the
DMA'd response, but a READ DESCRIPTOR response's data segment follows the
UPIU header at GENERAL_UPIU_REQUEST_SIZE and can extend past that window.
The tail of a longer descriptor was therefore read from stale cache (the
pre-transfer memset had zeroed it), so its last bytes came back as 0.
This corrupted the last UTF-16 code unit of longer string descriptors:
e.g. a 34-byte product-name descriptor "THGJFGT0T25BAZZA" was read as
"THGJFGT0T25BAZZ\0", dropping the final 'A'. Shorter descriptors that fit
within the invalidated cache line (serial numbers, etc.) were unaffected.
Invalidate the descriptor region before copying it out.
Tested on the Qualcomm IQ-9075-EVK.
Fixes: 7feafb0ae4f7 ("ufs: Add Initial Support for UFS subsystem")
Signed-off-by: Jorge Ramirez-Ortiz <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Reorder the remove path to deregister the controller first (and return
early on failure), then shut down PHY/clocks and finally assert reset.
This prevents register reads/writes after reset and avoids undefined
behavior.
Signed-off-by: Boon Khai Ng <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
The DesignWare SPI controller supports configurable bits_per_word
(typically 4-32 bits), but this was previously hardcoded to 8 bits
in the driver initialization.
This patch enables bits_per_word to be set dynamically by upper-level
device drivers, matching the approach used in Linux. The controller
reads the bits_per_word value from the spi_slave structure during
each transfer, allowing different SPI devices on the same bus to use
different word sizes.
Implementation details:
- Read slave->bits_per_word in dw_spi_xfer() before each transfer
- Validate requested value against controller capabilities (4 to max_xfer)
- Default to 8 bits if not set (maintains backward compatibility)
This follows the Linux model where spi_device drivers set bits_per_word,
and the controller driver reads it in the transfer function. Device
drivers can now set slave->bits_per_word before calling spi_xfer().
Example usage in device driver:
slave->bits_per_word = 16;
spi_xfer(slave, ...);
Backward compatible: Existing drivers that don't set bits_per_word
will continue to work with the default 8-bit transfers.
Signed-off-by: Boon Khai Ng <[email protected]>
|
|
The boundary checks in airoha_clk_enable(), airoha_clk_get_rate(), and
airoha_clk_set_rate() use "id > data->num_clocks" which allows id equal
to num_clocks to pass. Since data->descs[] has exactly num_clocks entries
(indices 0 to num_clocks-1), id=num_clocks results in an out-of-bounds
array access.
This is currently not triggered because the device tree clock IDs are
within bounds, but the check should be defensive. Fix by changing the
comparison from ">" to ">=".
Fixes: d0b81afb5ec9 ("clk: airoha: Add support for Airoha AN7581 SoC clock")
Signed-off-by: Wayen Yan <[email protected]>
|
|
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]>
|