Rasmus Villemoes <ravi@prevas.dk> says:
While looking through list.h, I saw that the regular list_* helpers
(and one of the hlist_* ones) still contain the prefetch() that was
removed in linux 14 years ago. It doesn't do anything, but makes the
macros harder to read, so get rid of it, and the fallback, no-op
definition that they relied on. That requires removing a few uses
outside list.h as well.
checkpatch warns about some whitespace issues in list.h, but as I've
copied whole kerneldoc+#define blocks directly from the linux kernel,
I think it's better to just accept that so that we don't introduce
needless diffs. The "macro argument reuse" arguments should also be
ignored, as e.g. the "member" arguments are obviously always just bare
identifiers, and the "pos" arguments must be assigned to multiple
times.
Link: https://lore.kernel.org/r/20250507121246.518691-1-ravi@prevas.dk
These all end up using the no-op prefetch() defined in linux/list.h,
because the only possible real implementation is in
arch/mips/include/asm/processor.h, which is behing
CONFIG_CPU_HAS_PREFETCH which is nowhere defined.
In order to be able to drop that fallback definition from list.h,
first remove all uses.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Contrary to the datasheet, setting both DETACH and PULLD_DIS bits to 1
does not always drive the DP and DM lines to high-impedance. This
prevents the host from reliably detecting a USB disconnect and subsequent
reconnect.
The symptom is that the first gadget command (e.g., dhcp) succeeds, while
subsequent commands (e.g., nfs) fail.
Disabling and re-enabling the controller entirely, instead of toggling the
PULLD_DIS bit, reliably generates a disconnect event.
The Linux driver works correctly because gadget_disconnect/gadget_connect
are always followed by gadget_udc_start/gadget_udc_stop. In U-Boot
pullup() is used solely.
This behavior has been observed on the SAM9X60-Curiosity and
AT91SAM9G25-EK boards and has been reported to Microchip.
Signed-off-by: Zixun LI <admin@hifiphile.com>
Link: https://lore.kernel.org/r/20250602-pullup-v1-1-edcde5a050dd@hifiphile.com
[mkorpershoek: reworded commit title + comment to usba_udc_pullup()]
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Remove duplicate .ops assignment that was overriding the correct
ti_musb_gadget_ops with musb_usb_ops (host ops) in the ti_musb_peripheral
driver. This was causing U-Boot crashes when trying to call the
handle_interrupts operation since the wrong ops structure was being used.
Fixes: 7d98dbcc3d ("usb: musb-new: Add support for DM_USB")
Fixes: 281eaf1ed8 ("usb: gadget: musb: Convert interrupt handling to usb_gadget_generic_ops")
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20250611171031.840277-1-kory.maincent@bootlin.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
The third_arg for a dfu alt is read as an integer and is overloaded for
different supported backends. For ext4 and fat, this third_arg
represents the partition and forms the dev part string, which should
have its partition in hex. This commit fixes dfu ext4/fat usage for
devices with ten or more partitions.
Signed-off-by: Ivan Pang <ipman@amazon.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Link: https://lore.kernel.org/r/20250611050127.38011-1-ipman@amazon.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
The WARN macro requires inclusion of linux/bug.h header. It does
currently work as bitfield.h includes it indirectly but this will
change when bitfield.h will be synced with new Linux version.
Explicitly include the header to fix future compilation error.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The WARN macro requires inclusion of linux/bug.h header. It does
currently work as bitfield.h includes it indirectly but this will
change when bitfield.h will be synced with new Linux version.
Explicitly include the header to fix future compilation error.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
E Shattow <e@freeshell.de> 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/20250606224558.1117422-1-e@freeshell.de
Use consistent lowercase hex prefix style in drivers/*
Does not change hex prefix case in allcaps uppercase style error messages
Signed-off-by: E Shattow <e@freeshell.de>
This function is currently a misnomer at times as we have cases where it
passes arguments to the image. In preparation for making that be a more
common case rename this function to jump_to_image(...). In order to do
this, rename jump_to_image in board_init_r(...) to jumper so that we do
not have a conflict.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Reword the commit message, adding missing cases of
jump_to_image_no_args()]
Signed-off-by: Tom Rini <trini@konsulko.com>
Sukrut Bellary <sbellary@baylibre.com> says:
This patch series adds the support for
1. In am33xx SoC[1], enhanced capture (eCAP) supports auxiliary PWM (APWM).
This series adds the PWM driver support for the APWM feature for eCAP on
AM33xx. AM335X_ECAP0_IN_PWM0_OUT is used to enable the backlight.
2. Fix build warning in ti-ehrpwm driver in dev_deb().
3. Enable eCAP0 PWM and LCD pin muxing to support splash screen on
AM335x EVM[2].
[1] AM335x TRM - https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf
[2] AM335x EVM - https://www.ti.com/tool/TMDXEVM3358
per discussion on the earlier patch series,
https://lore.kernel.org/all/20250319202516.3300444-1-sbellary@baylibre.com/
dropping the device tree changes in this series due to OF_UPSTREAM
conflict.
As we are dropping the DT patch, started with the new series instead of
V2.
This series doesn't contain defconfig changes since we don't want to
enable LCD, splash screen and PWM support by default.
Enabling splash screen and PWM support in defconfig causes u-boot crash
on AM335x based beaglebone black. This will be handled in a separate
patch.
Link: https://lore.kernel.org/r/20250530212232.1686613-1-sbellary@baylibre.com
If CONFIG_PWM_TI_EHRPWM is enabled, it throws the build warning in
dev_dbg() due to incorrect format specifier as,
"warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but
argument 4 has type ‘fdt_addr_t’ {aka ‘unsigned int’}".
Fix this with the correct format specifier.
Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>
In am33xx SoC[1], enhanced capture (eCAP) supports auxiliary PWM (APWM).
This series adds the PWM driver support for the APWM feature for eCAP on
AM33xx.
eCAP HW also supports the capture mode. Currently, this driver only
supports APWM.
This is based on the Linux kernel driver -> drivers/pwm/pwm-tiecap.c
Version: v6.12
Tested on AM335x EVM[2].
[1] AM335x TRM - https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf
[2] AM335x EVM - https://www.ti.com/tool/TMDXEVM3358
Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>
RAM drivers using Device Model currently lack of their own Kconfig menu
entry, which makes Kconfig put all options of the class in the top-level
menu of device drivers. These options are also incorrectly grouped with
pinctrl options in the generated .config, which is hard to read. Let's
create a menu entry for these drivers.
Fixes: 6c51df6859 ("dm: Add support for RAM drivers")
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
When doing the investigation for commit 53bb8fdea1 ("mmc: Kconfig:
Correct dependencies SDHCI ADMA options") I missed the implications of
MMC_SDHCI_ADMA_HELPERS. The problem is that FSL_ESDHC via the
FSL_ESDHC_SUPPORT_ADMA2 option will also enable these helper functions.
This in turn means the correct dependency here is
MMC_SDHCI_ADMA_HELPERS and not *MMC_SDHCI_ADMA.
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Quentin Schulz <foss+uboot@0leil.net> says:
Out of all the dev_read_*_default functions, only two do not properly
use the type as argument and return type: dev_read_u32_default and
dev_read_s32_default. They both use int instead of u32/s32.
Considering that it's generally not guaranteed that an int is 4 bytes
but also for consistency sake, let's have them use the expected type.
Note that I have not tested this, just stumbled upon that inconsistency
by chance.
Link: https://lore.kernel.org/r/20250528-dev_read_x32_default-v1-0-6ab1734dd7a2@cherry.de
dev_read_s32_default is for getting an s32 from a Device Tree property
and allows to take a default value if that property is missing.
Considering it calls ofnode_read_u32_default which takes a u32 and
returns a u32, it should do the same instead of using an int, especially
considering that int size is typically architecture-specific, as opposed
to s32/u32.
s32 and u32 being the same size, dev_read_s32* functions calling
ofnode_read_u32_default shouldn't be an issue (at the type level at
least) as the information will be stored appropriately in 4B regardless
of the sign.
This incidentally matches all other dev_read_*_default functions.
Fixes: a1b17e4f4c ("dm: core: Add a function to read into a unsigned int")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
dev_read_u32_default is for getting a u32 from a Device Tree property
and allows to take a default value if that property is missing.
Considering it calls ofnode_read_u32_default which takes a u32 and
returns a u32, it should do the same instead of using an int, especially
considering that int size is typically architecture-specific, as opposed
to u32.
This incidentally matches all other dev_read_*_default functions (except
dev_read_s32_default which will be tackled in the next commit).
Fixes: 47a0fd3bad ("dm: core: Implement live tree 'read' functions")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/26607
- Add clock and reset drivers support for STM32MP25
- Add STM32H747-Discovery board support
- Add tamp_nvram driver
- Add SPL support and clock tree init to STM32MP13 RCC driver
- Add STM32MP13xx ram support
- Add support for STM32 Image V2.0 for STM32MP13xx
- Fix SYSRAM size on STM32MP13xx
- Fix DBGMCU macro on STM32MP13xx
- Auto-detect ROM API table on STM32MP15xx
Add support for configuring DRAM controller on STM32MP13xx SoC.
The DRAM controller is basically identical to the DWC controller
on STM32MP15xx SoC, except the bus width is reduced from 32bit to
16bit and a few registers and bits are therefore not present.
Handle the difference by factoring these parts out. Use IS_ENABLE()
as much as possible to assure code which is not enabled on builds
for a single SoC gets compiled out. Handle the different offset of
RCC_DDRITFCR register and missing DDRC2 clock the same way.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Add SPL support and clock tree init to STM32MP13 RCC driver. This
consists of two parts, make SCMI into an optional dependency and
add clock tree initialization. The SCMI dependency is made optional
first by registering the few core clock provided by SCMI clock as
fixed clock, and second by letting the clock core parse out the
clock configuration from SoC registers. The clock initialization
code is derived from STM32MP15xx clock tree initialization code,
which is almost identical, except for the use of new PLL2000 for
PLL1 on STM32MP13xx .
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Implement STM32MP25 reset drivers using stm32-core-reset API.
This reset stm32-reset-core API and will be able to use DT binding
index started from 0.
This patch also moves legacy reset into stm32 directory reset.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
In RCC the ops of the CCF registered CLK device can be called directly,
this patch avoid recursive call of clk_ function done by CCF clock
framework which update the clock information, for example
clk_enable is called 2 times, clkp->enable_count is increased 2 times.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Each clock identifier needs to be unique when CCF is activated,
and it is not respected today by SCMI clock driver.
This patch supports a unique clk id by using the uclass API
clk_get_id() / dev_clk_dm() and by activating by default
CONFIG_CLK_AUTO_ID with CCF which adds an offset to the SCMI
clock identifiers.
After this patch, the SCMI clock driver can coexist with other
clock provider without conflict, they can share internal identifier
[0..N] defined in their binding and the clock ID = 0
(reserved for dummy clock) is no more used.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add a new config CONFIG_CLK_AUTO_ID to support a unique clk id
for all the clock providers, managed by clk uclass, when the clock
reference arg[0] is the same.
When the CONFIG is activated, the clock id is limited to the lower
CLK_ID_SZ = 24 bits in default clock xlate function
and the sequence number + 1 of the clk provider device is
added for the 8 higher bits.
We use sequence number + 1 to avoid the "dummy" clock id = 0,
used for invalid clock when CCF is activated.
When this config is activated, the new function clk_get_id()
should be used to get back the internal reference to clock
for the each clock provider.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Since clock protocol 2.0, SCMI specification add an option field
"clock_enable_delay" to CLOCK_ATTRIBUTES command.
scmi_read_resp_from_smt() will return an error ("Buffer too small") as
the message length coming from the SCMI server is not the same as expected.
So implement a condition to SCMI clock protocol version to change the
length of the expected message.
Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add support for the self-test continue command in the TPM v1.2 emulator,
to match the functionality in the TPM v2 emulator.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This reverts commit 159b6f0e11.
Since commit 159b6f0e11 ("caam: Fix CAAM error on startup") the following
regression was reported by Tim Harvey:
"I've found that this patch causes a regression on an imx8mm board
(imx8mm_venice_defconfig) where the first call to caam_rng_read fails
here in jr_dequeue but if you call it again it works. With some
debugging added:
SEC0: RNG instantiated
...
Hit any key to stop autoboot: 0
u-boot=> rng list
RNG #0 - caam-rng
u-boot=> rng 0 10
caam_rng_read caam-rng len=16
run_descriptor_jr_idx idx=0
Error in SEC deq: -1
caam_rng_read_one run_descriptor_jr failed: -1
caam_rng_read caam-rng caam_rng_read_one failed: -5
Reading RNG failed
u-boot=> rng 0 10
caam_rng_read caam-rng len=16
run_descriptor_jr_idx idx=0
00000000: ad 2e ad c0 2a 12 27 c4 65 82 66 19 be ef f6 07 ....*.'.e.f.....
If I revert your patch caam_rng_read works initially and on subsequent
calls."
" I ran into this when I was testing
lwIP HTTPS as it causes anything that uses dm_rng to fail the first
time (such as HTTPS)."
Revert it for now to avoid the regression.
Reported-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
The val (the bits to set) is the second member of the reg_data structure
and mask the third one. We obviously want to clear bits 6 and 7 in order
to only set bit 7 in there instead of only clearing bit 7 in order to
write bits 6 and 7 (which makes no sense).
Fortunately, according to the datasheet, bit 6 value doesn't matter when
bit 7 is set so this is essentially just a cosmetic change, no intended
change in behavior.
Fixes: f172575d92 ("power: rk8xx: add support for RK806")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Allows use of the regulator functions of the RK8XX PMIC in SPL, which is
necessary to support the functionality of the Rockchip IO-domain driver
on relevant platforms.
Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Allows use of the Rockchip IO-domain driver in SPL to configure
the GPIO to match the voltage supplied by specific regulators
(e.g. "vcc_sdio").
Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Log the value of the regulators during initialization of the IO-domain
driver to aid in debugging GPIO voltage configuration problems.
Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The RAM_ROCKCHIP_DEBUG can be used only if DEBUG_UART is
available.
The next commit introduces changes in definition of debug
uart functions, so that DEBUG_UART is required to be defined
in order to initialize uart and use print functions.
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
The high-speed UART from MediaTek supports baudrate accuracy
compensation when using high-speed mode 3.
This is done by calculating the first digit of the fraction part of
sample count value. The fraction value will be then used as the
reference to insert 0 to 10 sample cycle(s) to one frame (assume
that frame format is 8n1, i.e. 10 bits per frame).
The fracdiv_[l/m] registers are used to determine whether a bit in one frame
should be inserted with one sample cycle.
With typical 40MHz source clock, the actual baudrates with/without
accuracy compensation are:
Ideal w/o compensation w/ compensation
======== ================ ===============
9600 9603 9600
115200 114942 115207
921600 930232 921659
3000000 3076923 3007519
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Fix UART register names and offsets according to the programming
guide to allow implementing some enhanced features.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
