The Kconfig symbols SYS_ARCH, SYS_CPU, SYS_SOC, SYS_VENDOR and
SYS_BOARD are defined in arch/Kconfig as having type string, and most
board files simply amend those definition with suitable
default "foo"
or
default "foo" if BAR
stanzas. But some also include a redundant repetition of the type.
Homogenize the code base by removing those lines.
Generated by
find arch/*/ board -name Kconfig | xargs perl -i -g -pe 's/(config SYS_(ARCH|CPU|SOC|VENDOR|BOARD)\n)\s*string\n/\1/gs'
with the trailing slash in arch/*/ ensuring that arch/Kconfig itself
is not found.
This does not change boards which add a prompt string, e.g.
string "Board name"
because I think those change the semantics of the symbol into being
user-settable.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Tom Rini <trini@konsulko.com>
There are of course not a whole lot of examples in-tree yet, but
before they appear, let's make this API change: Instead of separately
allocating a 'struct cyclic_info', make the users embed such an
instance in their own structure, and make the convention that the
callback simply receives the 'struct cyclic_info *', from which the
clients can get their own data using the container_of() macro.
This has a number of advantages.
First, it means cyclic_register() simply cannot fail, simplifying the
code. The necessary storage will simply be allocated automatically
when the client's own structure is allocated (often via
uclass_priv_auto or similar).
Second, code for which CONFIG_CYCLIC is just an option can more easily
be written without #ifdefs, if we just provide an empty struct
cyclic_info {}. For example, the nested CONFIG_IS_ENABLED()s in
https://lore.kernel.org/u-boot/20240316201416.211480-1-marek.vasut+renesas@mailbox.org/
are mostly due to the existence of the 'struct cyclic_info *' member
being guarded by #ifdef CONFIG_CYCLIC.
And we do probably want to avoid the extra memory overhead of that
member when !CONFIG_CYCLIC. But that is automatic if, instead of a
'struct cyclic_info *', one simply embeds a 'struct cyclic_info',
which will have size 0 when !CONFIG_CYCLIC. Also, the no-op
cyclic_register() function can just unconditionally be called, and the
compiler will see that (1) the callback is referenced, so not emit a
warning for a maybe-unused function and (2) see that it can actually
never be reached, so not emit any code for it.
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Generally speaking, we do not prompt for this value and define it in the
board specific Kconfig file. There are some valid use cases however
today where we do prompt for this value, so instead of having this be
done in a number of locations, do this at the top-level location only.
This removes the question from a number of other locations and makes it
consistent that when we do set the value directly, we always do it the
same way. We don't need to specify the type, it's always string.
Signed-off-by: Tom Rini <trini@konsulko.com>
Add a new event which handles this function. Convert existing use of
the function to use the new event instead.
Make sure that EVENT is enabled by affected boards, by selecting it from
the LAST_STAGE_INIT option. For x86, enable it by default since all boards
need it.
For controlcenterdc, inline the get_tpm() function and make sure the event
is not built in SPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
This patch adds a fixup function related to a PCIe FLR (Function Level
Reset) problem on the NIC23 PCIe board. This function is imported from
the Marvell Octeon 2013 U-Boot version as a (nearly) verbatim copy. It
uses the newly introduced cyclic infrastructure, so that this function
gets called every 100us, which is needed to detect this FLR issue.
Signed-off-by: Aaron Williams <awilliams@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
This patch enables the Kconfig symbols needed for full ethernet support
on the NIC23. Additionally board specific setup is done, mostly GPIOs
related to SFP / GPIO configuration. With this, ethernet can be used on
this board. Here an example of a tftp load:
=> tftp ffffffff81000000 big
Using ethernet-mac-nexus@11800e2000000 device
TFTP from server 192.168.1.5; our IP address is 192.168.1.247
Filename 'big'.
Load address: 0xffffffff81000000
Loading: ################################################## 10 MiB
9.7 MiB/s
done
Bytes transferred = 10485760 (a00000 hex)
Signed-off-by: Stefan Roese <sr@denx.de>
