Pali Rohár [Tue, 2 Aug 2022 09:55:19 +0000 (11:55 +0200)]
arm: mvebu: spl: Always fallback to BootROM boot method
BootROM boot method should always work so always add it as fallback method
to spl_boot_list. In case U-Boot SPI driver fails it is better to try using
BootROM than hanging as by default only one boot method is specified.
Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Mon, 1 Aug 2022 10:11:13 +0000 (12:11 +0200)]
gpio: turris_omnia_mcu: Fix usage of CMD_EXT_CONTROL
CMD_GENERAL_CONTROL takes two 8-bit arguments but CMD_EXT_CONTROL takes
two 16-bit arguments. Fix this issue and change CMD_EXT_CONTROL arguments
to 16-bit.
Fixes: 5e4d24ccc115 ("gpio: Add Turris Omnia MCU driver") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Mon, 1 Aug 2022 10:02:20 +0000 (12:02 +0200)]
arm: mvebu: turris_omnia: Increase fdt size in fixup_mtd_partitions
Sometimes fixup_mtd_partitions() prints during booting kernel error
"Failed fixing SPI NOR partitions!" because it does not have enough space
for creating all paritions nodes. So increase fdt size.
Fixes: 92f36c8e74c1 ("arm: mvebu: turris_omnia: fixup MTD partitions in Linux' DTB") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Marek Behún <kabel@kernel.org>
arm: mvebu: turris_omnia: Add support for design with SW reset signals
New Turris Omnia HW board revision requires that software controls
peripheral reset signals, namely PERST# signals on mPCIe slots, ethernet
phy reset and lan switch reset. Those pins are connected to MCU controlled
by MCU i2c API as GPIOs. On new HW board revision those pins stay in reset
after board reset and software has to release these peripherals from reset
manually. MCU announce this requirement by FEAT_PERIPH_MCU bit in
CMD_GET_FEATURES command.
On older HW board revisions when FEAT_PERIPH_MCU is not announced, all
those reset signals are automatically released after board finish reset.
Detect FEAT_PERIPH_MCU bit in board_fix_fdt() and ft_board_setup()
functions and insert into device tree blob pcie "reset-gpios" and eth phy
"phy-reset-gpios" properties with corresponding MCU gpio definitions.
PCIe and eth PHY drivers then automatically release resets during device
initialization. Both U-Boot and Linux kernel drivers support those device
tree reset properties.
Initialization of lan switch on new HW board revision is more complicated.
Switch strapping pins are shared with switch RGMII pins. And strapping pins
must be in specific configuration after releasing switch reset. Due to pin
sharing, it is first required to switch A385 side of switch pins into GPIO
mode, set strapping configuration, release switch from reset and after that
switch A385 pins back to RGMII mode.
Because this complicated setup is not supported by switch DSA drivers and
cannot be expressed easily in device tree, implement it manually in SPL
function spl_board_init(). So in proper U-Boot and OS/kernel would be lan
switch initialized and be in same configuration like it was on old HW board
revisions (where reset sequence did those steps at hardware level).
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Marek Behún <kabel@kernel.org>
This allows you to specify the type of rgmii-id that will enable phy
internal delay in ethernet phy-mode.
This adds all RGMII cases to all of get_pinmode() except LD11, because LD11
SoC doesn't support RGMII due to the constraint of the hardware. When RGMII
phy mode is specified in the devicetree for LD11, the driver will abort
with an error.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
net: phy: possible NULL dereference in fixed_phy_create()
We check if phydev is NULL. Only but if it is non-NULL we set one
component of phydev. But even if it is NULL we set another. We should not
dereference NULL in either case.
Fixes: e24b58f5ed4f ("net: phy: don't require PHY interface mode during PHY creation") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Marek Behún <kabel@kernel.org>
Ramon Fried [Sun, 5 Jun 2022 00:44:15 +0000 (03:44 +0300)]
net: phy: Remove inline definitions from convinience functions
The convinience functions are not that small and they caused
bloated text segments because of their usage.
There was no need to inline them in the first place, as
they're not part of a fastpath.
Signed-off-by: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Marek Behún <kabel@kernel.org> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Zev Weiss [Tue, 17 May 2022 22:16:39 +0000 (15:16 -0700)]
net: ftgmac100: use bus name in mdio error messages
Previously we'd been using a device name retrieved via
ftgmac100_data->phydev, but the mdio read/write functions may be
called before that member is initialized in ftgmac100_phy_init(),
leading to a NULL pointer dereference while printing the error message
issued if the mdio access fails. We can instead use bus->name, which
is already available at that point.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Fixes: 538e75d3fc54 ("net: ftgmac100: add MDIO bus and phylib support") Reviewed-by: Cédric Le Goater <clg@kaod.org>
Rasmus Villemoes [Thu, 12 May 2022 07:33:07 +0000 (09:33 +0200)]
net: dwc_eth_qos: remove use of DWC_NET_PHYADDR
Only two boards in the tree set the macro DWC_NET_PHYADDR. Both have
CONFIG_DM_ETH_PHY=y, so should set the phy address in DT if necessary.
The imx8mp_evk does set the correct address in device tree.
The other board seems to be a copy-paste-adapt from an old
version of the imx8mp_evk config header, given the "#ifdef
CONFIG_DWC_ETH_QOS" block that has been removed from imx8mp_evk header
in commit 127fb454955. Its device tree doesn't even enable (i.e., set
'status = "okay"') the &eqos node. But the other ethernet device,
&fec, does get enabled, and does have a phy sitting at address 4 (and
it also has a corresponding legacy #define CONFIG_FEC_MXC_PHYADDR
4). So I believe it should be completely safe to remove it from there
as well.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
[trini: Re-apply to top of tree, update imx93_evk.h] Signed-off-by: Tom Rini <trini@konsulko.com>
Rasmus Villemoes [Wed, 11 May 2022 14:58:41 +0000 (16:58 +0200)]
net: dwc_eth_qos: lift parsing of max-speed DT property to common code
I have an iMX8MP with a ti,dp83867 phy in front of the eqos
interface. The phy is Gbit capable - however, the C and D differential
pairs are not physically routed to the RJ45 connector. So I need to
prevent the phy from advertising 1000Mbps.
The necessary code is almost already there in the form of a
phy_set_supported() call in eqos_start(), but the max-speed DT
property is currently only parsed in
eqos_probe_resources_stm32(). Lift that parsing to eqos_probe().
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Rasmus Villemoes [Wed, 11 May 2022 14:12:50 +0000 (16:12 +0200)]
net: dwc_eth_qos: fix double resource leak in eqos_remove()
Not only does eqos_remove() fail to free the buffers that have been
allocated by eqos_probe_resources_core(), it repeats those allocations
and thus drops twice as much memory on the floor.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Marek Vasut [Mon, 25 Apr 2022 18:28:05 +0000 (20:28 +0200)]
net: dm9000: Correctly handle empty FIFO
Assign packet pointer only in case the MAC reports anything in the FIFO.
In case the MAC indicates empty FIFO, return 0 to pass that information
to the network stack.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
This patch adds basic support for the Marvell 88E1240 PHY.
This will be used by the upcoming ethernet support addition for the
Marvell MIPS Octeon EBB7304 platform.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Ramon Fried <rfried.dev@gmail.com> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Aaron Williams <awilliams@marvell.com> Cc: Chandrakala Chavva <cchavva@marvell.com> Reviewed-by: Marek Behún <marek.behun@nic.cz>
Stefan Roese [Thu, 31 Mar 2022 09:43:06 +0000 (11:43 +0200)]
net: phy: marvell: Support reg config via "marvell, reg-init" DT property
This patch adds support for the "marvell,reg-init" DT property, which
is used to describe board specific Marvell PHY register configurations
in the board dts file. This DT property is supported in the Linux Kernel
since a longer time. Adding it to U-Boot now, enables the boards which
describe the register settings in their DT files here as well.
I've included calling this marvell_of_reg_init() to all foo_config()
functions in this patch as well. If CONFIG_DM_ETH is not set, there is
no ofnode, or no "marvell,reg-init" property, the PHY initialization is
unchanged.
The function marvell_of_reg_init() is a port of the Linux version.
Please note that I explicitly did not add error checking and handling
to the U-Boot version, as this is basically not done for phy_read/write
in this Marvell PHY code.
This will be used by the upcoming ethernet support on the MIPS
Octeon EBB 7304 board.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Ramon Fried <rfried.dev@gmail.com> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Aaron Williams <awilliams@marvell.com> Cc: Chandrakala Chavva <cchavva@marvell.com> Cc: Marek Behún <marek.behun@nic.cz> Reviewed-by: Marek Behún <marek.behun@nic.cz>
Andre Kalb [Fri, 28 Jan 2022 08:40:32 +0000 (09:40 +0100)]
net: bootp: Make root path (option 17) length configurable
to adjust the root path length.
Eg to 256 from Linux Kernel
Signed-off-by: Andre Kalb <andre.kalb@sma.de> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
[trini: Guard extern so that !CONFIG_NET platforms will build] Signed-off-by: Tom Rini <trini@konsulko.com>
To quote Simon:
This series drops the need for the genboardscfg.py script, so that the
boards.cfg file is produced (and consumed) entirely within buildman. The
file is not entirely removed since it does have some uses and we need some
sort of cache for the information. The genboardscfg.py script is
effectively incorporated in buildman.
It also improves operation from an IDE with a new -I option and fixes up
some of the pylint warnings in buildman.
Finally, this series also fixes a bug which allows use to drop support for
CONFIG_SYS_EXTRA_OPTIONS which is long-standing desire. It also fixes a
minor bug that causes 'Invalid line' spam when checking for function bloat
with the -B option.
Simon Glass [Tue, 12 Jul 2022 01:04:06 +0000 (19:04 -0600)]
buildman: Replace the Options column with config name
This appears in boards.cfg but we want to remove it. Drop support for
generating it and reading it. Detect an old boards.cfg file that has
this field and regenerate it, to avoid problems.
Instead, add the config name in that place. This fixes a subtle bug in
the generation code, since it uses 'target' for the config name and then
overwrites the value in scan() by setting params['target'] to the name
of the defconfig. The defconfig name is not the same as the
SYS_CONFIG_NAME variable.
With this change, we still have the config name and it can be searched
by buildman, e.g. with:
buildman -nv sun5i
Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Tom Rini <trini@konsulko.com>
Simon Glass [Tue, 12 Jul 2022 01:04:04 +0000 (19:04 -0600)]
buildman: Incorporate the genboardscfg.py tool
Bring this tool into buildman, so we don't have to run it separately. The
board.cfg file is still produced as part of the build, to save time when
doing another build in the same working directory. If it is out of date
with respect to the Kconfig, it is updated.
Time to regenerate on a recent single-thread machine is 4.6s (1.3s on a
32-thread machine), so we do need some sort of cache if we want buildman
to be useful on incremental builds. We could use Python's pickle format
but:
- it seems useful to allow boards.cfg to be regenerated, at least for a
while, in case other tools use it
- it is possible to grep the file easily, e.g. to find boards which use
a particular SoC (similar to 'buildman -nv <soc>'
Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Tom Rini <trini@konsulko.com>
Simon Glass [Tue, 12 Jul 2022 01:03:59 +0000 (19:03 -0600)]
buildman: Fix use of 'boards' in test
We want to create a module called 'boards' so avoid use of this variable
name in this module. Change the global to be capitalised, as required by
Python style.
Simon Glass [Tue, 12 Jul 2022 01:03:58 +0000 (19:03 -0600)]
buildman: Fix use of 'boards' in func_test
We want to create a module called 'boards' so avoid use of this variable
name in this module. Change the global to be capitalised, as required by
Python style.
Simon Glass [Tue, 12 Jul 2022 01:03:57 +0000 (19:03 -0600)]
buildman: Avoid using board as a variable
We have a module called 'board'. Sometimes buildman uses 'brd' as an
instance variable but sometimes it uses 'board', which is confusing and
can mess with the module handling. Update the code to use 'brd'
consistently, making it easier for tools to determine when the module
is being referenced.
Simon Glass [Tue, 12 Jul 2022 01:03:56 +0000 (19:03 -0600)]
buildman: Support running from an IDE
Add a flag to allow buildman to behave properly for use from an IDE. This
shows error/warning output on stderr and drops all summary and progress
information.
This should normally only be used when building a single board.
Fix up a confusing comment for GetResultSummary() while we are here, since
we want to use the Outcome object to access the unprocessed error lines
from the build.
Tom Rini [Sat, 23 Jul 2022 17:05:09 +0000 (13:05 -0400)]
Convert CONFIG_SYS_FSL_CCSR_GUR_BE et al to Kconfig
This converts the following to Kconfig:
CONFIG_SYS_FSL_CCSR_GUR_BE
CONFIG_SYS_FSL_CCSR_SCFG_BE
CONFIG_SYS_FSL_ESDHC_BE
CONFIG_SYS_FSL_IFC_BE
CONFIG_SYS_FSL_PEX_LUT_BE
CONFIG_SYS_FSL_CCSR_GUR_LE
CONFIG_SYS_FSL_CCSR_SCFG_LE
CONFIG_SYS_FSL_ESDHC_LE
CONFIG_SYS_FSL_IFC_LE
CONFIG_SYS_FSL_PEX_LUT_LE
Tom Rini [Sat, 23 Jul 2022 17:05:07 +0000 (13:05 -0400)]
configs: Remove a number of unreferenced CONFIG options.
There are a large number of options under CONFIG_SYS (but some of these
are elsewhere, spotted while cleaning CONFIG_SYS) that are never
referenced, or only used slightly later in the config file. Remove or
restructure these.
Tom Rini [Sat, 23 Jul 2022 17:05:03 +0000 (13:05 -0400)]
Audit <flash.h> inclusion
A large number of files include <flash.h> as it used to be how various
SPI flash related functions were found, or for other reasons entirely.
In order to migrate some further CONFIG symbols to Kconfig we need to
not include flash.h in cases where we don't have a NOR flash of some
sort enabled. Furthermore, in cases where we are in common code and it
doesn't make sense to try and further refactor the code itself in to new
files we need to guard this inclusion.
Tom Rini [Sat, 23 Jul 2022 17:05:00 +0000 (13:05 -0400)]
Convert CONFIG_SYS_FLASH_ERASE_TOUT et al to Kconfig
This converts the following to Kconfig:
CONFIG_SYS_FLASH_ERASE_TOUT
CONFIG_SYS_FLASH_LOCK_TOUT
CONFIG_SYS_FLASH_UNLOCK_TOUT
CONFIG_SYS_FLASH_WRITE_TOUT
In practice, for two m68k platforms we move to hard-coding with a
comment the timeout values, rather than try and make convoluted Kconfig
logic. We add options for the write and erase options to the pic32
flash driver, as this driver does make use of them. Everywhere else
these are unreferenced values.
Tom Rini [Sat, 23 Jul 2022 17:04:56 +0000 (13:04 -0400)]
powerpc: Move CONFIG_SYS_DDR_SIZE to CONFIG_SYS_SDRAM_SIZE
We have a number of CONFIG_SYS_xxx_SIZE options to describe the amount
main memory available. Rework CONFIG_SYS_DDR_SIZE, which described a
size in number of MiB to use CONFIG_SYS_SDRAM_SIZE which is most often
used as a number of bytes. Use shifts of this option when required.
Tom Rini [Sat, 23 Jul 2022 17:04:54 +0000 (13:04 -0400)]
net: Remove CONFIG_SYS_DIRECT_FLASH_TFTP
No platforms enable the functionality to tftp directly to NOR flash, and
this is discouraged by the documentation. Remove this code. Further,
this highlights an oddity of the code. Un-indent the start of this
function.
Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Andrew Davis [Fri, 15 Jul 2022 16:34:35 +0000 (11:34 -0500)]
arm: mach-k3: security: Remove certificate if detected on GP device
If the device is a GP and we detect a signing certificate then remove it.
It would fail to authenticate otherwise as the device is GP and has no
secure authentication services in SYSFW.
This shouldn't happen often as trying to boot signed images on GP devices
doesn't make much sense, but if we run into a signed image we should at
least try to ignore the certificate and boot the image anyway. This could
help with users of GP devices who only have HS images available.
If this does happen, print a nice big warning.
Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Andrew Davis [Fri, 15 Jul 2022 16:34:34 +0000 (11:34 -0500)]
arm: mach-k3: security: Bypass image signing at runtime for GP devices
We can skip the image authentication check at runtime if the device is GP.
This reduces the delta between GP and HS U-Boot builds. End goal is
to re-unify the two build types into one build that can run on all
device types.
Andrew Davis [Fri, 15 Jul 2022 16:34:33 +0000 (11:34 -0500)]
arm: mach-k3: security: Allow signing bypass if type is HS-FS
On HS-FS devices signing boot images is optional. To ease use
we check if we are HS-FS and if no certificate is attached
to the image we skip the authentication step with a warning
that this will fail when the device is set to security enforcing.
Andrew Davis [Fri, 15 Jul 2022 16:34:32 +0000 (11:34 -0500)]
arm: mach-k3: Add support for device type detection
K3 SoCs are available in a number of device types such as
GP, HS-FS, EMU, etc. Like OMAP SoCs we can detect this at runtime
and should print this out as part of the SoC information line.
We add this as part of the common.c file as it will be used
to also modify our security state early in the device boot.
Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
vpl: fix reference in comment to non-existing SPL_SERIAL_SUPPORT
Since commit 2a7360666871 ("serial: Rename SERIAL_SUPPORT to SERIAL")
SPL_SERIAL_SUPPORT is named SPL_SERIAL. So let's update the comment to
point to the correct Kconfig option in the comment of VPL_SERIAL.
Fixes: 747093dd408 ("vpl: Add Kconfig options for VPL") Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
SPL_GPIO_SUPPORT is named SPL_GPIO since commit 83061dbd1c89 ("Rename
GPIO_SUPPORT to GPIO"), SPL_MMC_SUPPORT is named SPL_MMC since commit 103c5f180694 ("mmc: Rename MMC_SUPPORT to MMC"), SPL_SERIAL_SUPPORT is
named SPL_SERIAL since commit 2a7360666871 ("serial: Rename
SERIAL_SUPPORT to SERIAL") so let's select the correct Kconfig options.
Fixes: 8b71576f3842 ("mx7ulp_com: add support for SPL") Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Since commit 83061dbd1c89 ("Rename GPIO_SUPPORT to GPIO"),
SPL_GPIO_SUPPORT has been renamed to SPL_GPIO, meaning that SPL_GPIO_HOG
can never be enabled.
Let's fix this by using the proper name for the Kconfig option.
Fixes: 1d99e673c752 ("gpio: Enable hogging support in SPL") Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
cmd: undefined return value of do_extension_apply()
If 'extension apply all' is executed and no extension is found, the return
value of do_extension_apply() is undefined. Return CMD_RET_FAILURE in this
case.
Fixes: 2f84e9cf06d3 ("cmd: add support for a new "extension" command") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Harald Seiler [Mon, 11 Jul 2022 12:35:32 +0000 (14:35 +0200)]
spl: mmc: Use correct MMC device when loading image
When attempting to load images from multiple MMC devices in sequence,
spl_mmc_load() chooses the wrong device from the second attempt onwards.
The reason is that MMC initialization is only done on its first call and
spl_mmc_load() will then continue using this same device for all future
calls.
Fix this by checking the devnum of the "cached" device struct against
the one which is requested. If they match, use the cached one but if
they do not match, initialize the new device.
This fixes specifying multiple MMC devices in the SPL's boot order to
fall back when U-Boot Proper is corrupted or missing on the first
attempted MMC device.
Fixes: e1eb6ada4e38 ("spl: Make image loader infrastructure more universal") Signed-off-by: Harald Seiler <hws@denx.de>
drivers: xen: events: fix build issues with disabled Xen HVC
Some setups do not use Xen hypervisor console for logging, e.g. they
use emulated PL011 hardware or shared peripherals (real UART). In such
cases Xen HVC will be disabled on a build time and will cause issues in
current driver implementation.
This commit fixes build issues in Xen event channel driver, caused
by absense of console event channel, that is not available when console
config is disabled. Now console related code will be removed when
Xen HVC is turned off.
The 'rng' command dumps a number of random bytes on the console. Add a
set of tests for the 'rng' command. The test function performs basic
sanity testing of the command.
Since a unit test is being added for the command, enable it by default
in the sandbox platforms.
cmd: rng: Use a statically allocated array for random bytes
Use a statically allocated buffer on stack instead of using malloc for
reading the random bytes. Using a local array is faster than
allocating heap memory on every initiation of the command.
The 'rng' u-boot command is used for printing a select number of
random bytes on the console. Currently, the RNG device from which the
random bytes are read is fixed. However, a platform can have multiple
RNG devices, one example being qemu, which has a virtio RNG device and
the RNG pseudo device through the TPM chip.
Extend the 'rng' command so that the user can provide the RNG device
number from which the random bytes are to be read. This will be the
device index under the RNG uclass.
The TPM device comes with the random number generator(RNG)
functionality which is built into the TPM device. Add logic to add the
RNG child device in the TPM uclass post probe callback.
The RNG device can then be used to pass a set of random bytes to the
linux kernel, need for address space randomisation through the
EFI_RNG_PROTOCOL interface.
No compatible string is provided because this is not available in
the binding defined by Linux. If multiple rand devices are in the
system, then some method of selecting them (other than device tree)
will need to be used, or a binding will need to be added.
tpm: rng: Add driver model interface for TPM RNG device
The TPM device has a builtin random number generator(RNG)
functionality. Expose the RNG functions of the TPM device to the
driver model so that they can be used by the EFI_RNG_PROTOCOL if the
protocol is installed.
Also change the function arguments and return type of the random
number functions to comply with the driver model api.
efi_loader: initialize the RNG protocol after the TCC2
Due to U-Boot's lazy binding the RNG presented by the TCG is not available
until the EFI_TCG2 protocol has been initialized. Since the TPM has a
built-in RNG device we can use for the OS randomization, move the RNG
protocol installation after the TCG.
Simon Glass [Fri, 22 Jul 2022 16:02:02 +0000 (21:32 +0530)]
tpm: Export the TPM-version functions
These functions should really be available outside the TPM code, so that
other callers can find out which version the TPM is. Rename them to have
a tpm_ prefix() and add them to the header file.
Marek Behún [Mon, 25 Jul 2022 15:06:15 +0000 (17:06 +0200)]
MAINTAINERS: Change POWERPC MPC85XX maintainer to Marek Behún
After a discussion with Tom Rini, we've agreed that I am going to take
over custodianship of the MPC85XX platform, since it seems other people
do not have necessary interest or time and getting things done over
there takes too long.
Since I am only working on one MPC85XX board, Turris 1.x, and do not
have time to do thorough reviews of patches for this entire platform
(other than those concerning Turris 1.x board), for other boards I will
only run patches through CI and checkpatch, and then send them via PR
upwards to Tom.
Signed-off-by: Marek Behún <kabel@kernel.org> Acked-by: Tom Rini <trini@konsulko.com>
projects / u-boot.git / log