Remove the parent field from the mediatek clock private data structures.
This was no longer used other than debug prints.
The uclass_get_device_* functions had the effect of ensuring that
parents were probed. This is done now by having parent providers
probe on bind, so re-probing here is no longer necessary. Clock trees
could have more than one parent anyway, so the existing code was not
completely correct anyway.
Link: https://patch.msgid.link/20260710-mtk-clk-parent-lookup-improvements-v2-19-f3f3a4a28dca@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
Replace complex and fragile parent/grandparent lookup logic with a
simple lookup that matches CLK_PARENT_* flags to registered clock
providers.
Previously, we were walking priv->parent path to find a the matching
provider by either looking at driver name or driver ops. This was
fragile because more than one udevice could match the criteria and the
search depth had different rules depending on the clock type and the
parent type.
This will also enable more simplification in the future since we no
longer have to keep track of the udevice parents.
Link: https://patch.msgid.link/20260710-mtk-clk-parent-lookup-improvements-v2-18-f3f3a4a28dca@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
Add a new enum, field and function for registering clock tree types.
These types will be later used when looking up parent clocks. This
will replace fragile code that depends on lookup up devices by driver
names or ops.
We also need a way to ensure that any parent clock trees are probed
before trying to use a clock tree that depends on them. Since the
devicetree does not provide these relationships and there are only
a small number of clock parent providers (2 or 3 per SoC) vs. a large
number of clock trees that depend on them, it will simpler to just
always probe the parent clock trees on bind rather than trying to
add device info to all of the clocks to describe their parent
relations. For this, a mtk_common_clk_parent_bind() is added that the
drivers will use to set DM_FLAG_PROBE_AFTER_BIND.
Link: https://patch.msgid.link/20260710-mtk-clk-parent-lookup-improvements-v2-2-f3f3a4a28dca@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
U-Boot autostarts the SoC watchdog (CONFIG_WATCHDOG_AUTOSTART default
y) and services it from its main loop, but nothing services it after
ExitBootServices()/bootm: an EFI-booted OS that does not take over the
watchdog in time is reset mid-boot at a wall-clock-dependent point.
The MediaTek toprgu can count at most ~16 seconds, once firmware stops
servicing it at the handoff, the OS has whatever is left of those 16
seconds.
On the Genio 700 EVK the generic Ubuntu 26.04 arm64 image is hard-reset
before its first boot reaches the login prompt: the mtk-wdt driver is
a module loaded from the rootfs and cannot win that race. Nothing tells
a generic OS that the watchdog is armed, so the failure is silent and,
from the user's side, indistinguishable from broken firmware.
Disable WATCHDOG_AUTOSTART for the Genio EVK boards (mt8365_evk
directly, mt8188.config for the Genio 510/700).
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Link: https://patch.msgid.link/20260706133322.68010-1-ccaione@baylibre.com
Signed-off-by: David Lechner <dlechner@baylibre.com>
The bounds check in do_rw() was written as:
if (cnt + blk > limit)
with cnt and blk declared as uint (unsigned int) and limit as ulong.
C's usual arithmetic conversions are applied per binary operator, so
"cnt + blk" is evaluated entirely in unsigned int and wraps modulo
2^32 before the result is widened for the comparison against limit.
With cnt = 0xFFFFFFFF and blk = 1 the sum wraps to 0 and the guard
passes, allowing blk_dread()/blk_dwrite() to be issued with a 4 GiB
transfer count that runs past the partition (or, when no partition
is selected, the entire device).
Rewrite the check as two comparisons that do not overflow:
if (blk > limit || cnt > limit - blk)
The subtraction is performed in ulong (limit's type), so no truncation
occurs, and the two sub-conditions cover both "start block past end"
and "count would push us past end" failure modes.
Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rasmus Villemoes <rv@rasmusvillemoes.dk> says:
This started by me wanting something like what patch 8 does. That
wasn't too hard, except we had no strcasestr(), and also our regex
engine (which I didn't really want to pull into the mix anyway)
doesn't have a flag that requests case-insensitive matching. So I
wanted to add strcasestr(), but then I stumbled on a bunch of stuff
that should be cleaned up in str-land.
Link: https://lore.kernel.org/r/20260708203711.849489-1-rv@rasmusvillemoes.dk
Add some test cases for the 'config' command, including the ability to
filter the output.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a little documentation for the config command and its new ability
to filter the output.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
When doing development, it can be quite useful to enable
CONFIG_CMD_CONFIG, so that one can always check whether a config knob
one has just enabled has actually made it to target.
Because sometimes, one doesn't flash the right binary, or maybe one
has just done CONFIG_FOO=y in some config fragment, but that had no
effect because one would also have to do CONFIG_BAR=y.
However, 2400+ lines of text are rather hard to read through. One
probably uses a terminal emulator with capturing enabled, but
searching back through the capture file is a little tedious, and one
easily ends up finding something that doesn't pertain to the most
recent 'config' command invocation.
So make it possible to limit the output to those lines containing a
given string. Like the search functionality in menuconfig, make it
case insensitive, because it is much more convenient to type "config
pinctrl" than "config PINCTRL".
Since enabling CONFIG_CMD_CONFIG by itself adds over 10K of data, and
that increases with every U-Boot release even if one doesn't add any
new features to one's own defconfig (because the .config grows lots of
"is not set"), I don't see any point in guarding this by some
CONFIG_CMD_CONFIG_GREP.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Change the existing strstr() test a little so that the substring not
found is "bits", i.e. one that is actually found when doing case
insensitive search.
Then copy all of lib_strstr(), adapt the expectation for the
strcasestr(s1, s3) result, and add another "not found" case.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
While this is not likely needed by any "real" driver code, a later
convenience addition to the "config" command will need this. As usual,
the linker will throw it away if nothing actually uses it, so it
should have no size impact when not used.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
None of these six macros are defined by any architecture. Moreover,
the ifndef guard only exists in either string.h or string.c, making them
completely pointless.
I'm not sure whether we have an explicit coding style discouraging the
"extern" qualifier on function declarations, and string.h has a random
mix of everything, but I can't leave it on strncasecmp() now that it
will be immediately after strcasecmp() which doesn't have it.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
The last use of this function with rather peculiar semantics[*] vanished
in 2021 with 0a527fda78 ("Fix IDE commands issued, fix endian issues,
fix non MMIO"). It has no tests, and should a need for something
similar ever appear, it is better done with some proper
utf16le/utf16be/utf16 abstractions rather than cluttering code with
'#ifdef __LITTLE_ENDIAN'.
[*] The byte-swapping itself is weird enough. But why is an input string
of odd length ok, while the empty string is not allowed?
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
The len parameter for strnstr() concerns the maximum size of the
haystack to consider, not the length of the needle being searched for.
strstr() obviously has no len parameter, so remove the copy-pasta.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
David Lechner
Carlo CaioneandDavid Lechner
Julien StephanandDavid Lechner
Marek VasutandDavid Lechner
Naveen Kumar ChaudharyandTom Rini
Rasmus VillemoesandTom Rini