Copy the devicetree source for the H6 SoC and all existing boards
verbatim from the Linux v5.15 tag.
This update should not impact any existing U-Boot functionality.
Series-to: sunxi
Cover-letter:
sunxi: Devicetree sync from Linux v5.15
This series brings all of our devicetrees up to date with the latest
stable Linux version.
<< something about ABI compat >>
Here is the list of new files which were not added by this sync:
- sun4i-a10-topwise-a721.dts
- sun50i-a100-allwinner-perf1.dts
- sun50i-a100.dtsi
- sun50i-h6-pine-h64-model-b.dts
- sun5i-a13-licheepi-one.dts
- sun5i-a13-pocketbook-touch-lux-3.dts
- sun5i-gr8-evb.dts
- sun7i-a20-linutronix-testbox-v2.dts
- sun7i-a20-olinuxino-lime-emmc.dts
- sun8i-a23-ippo-q8h-v1.2.dts
- sun8i-a23-ippo-q8h-v5.dts
- sun8i-a33-et-q8-v1.6.dts
- sun8i-a33-ippo-q8h-v1.2.dts
- sun8i-h3-nanopi-r1.dts
- sun8i-r16-nintendo-nes-classic.dts
- sun8i-r16-nintendo-super-nes-classic.dts
- sun8i-r40-feta40i.dtsi
- sun8i-r40-oka40i-c.dts
- sun8i-s3-elimo-impetus.dtsi
- sun8i-s3-elimo-initium.dts
- sun8i-t3-cqa3t-bv3.dts
- sun8i-v3-sl631-imx179.dts
- sun8i-v3-sl631.dtsi
END
Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree source for the H5 SoC and all existing boards
from the Linux v5.15 tag, with minor changes to account for the
different directory layout for 64-bit SoCs.
While there were some recent changes to the shared H3/H5 devicetree,
the only H5-specific change is fixing the EMAC phy-mode in one board.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree source for the A64 SoC and all existing boards
verbatim from the Linux v5.15 tag.
As with the other SoCs, updates of note are EMAC phy-mode changes to set
RGMII delays.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree for the R40 SoC verbatim from the Linux v5.15 tag.
None of the existing boards had any devicetree updates.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree source for the V3(s)/S3 SoCs and all existing boards
verbatim from the Linux v5.15 tag.
This update should not impact any existing U-Boot functionality.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree source for the H2+/H3 SoCs and all existing boards
verbatim from the Linux v5.15 tag.
As with the other SoCs, updates of note are EMAC phy-mode changes to set
RGMII delays.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree source for the A83T SoC and all existing boards
verbatim from the Linux v5.15 tag.
As with the other SoCs, updates of note are EMAC phy-mode changes to set
RGMII delays, and adding detection GPIO properties in the USB PHY nodes.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree source for the A80 SoC and all existing boards
verbatim from the Linux v5.15 tag.
This update should not impact any existing U-Boot functionality.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree source for the A10s/A13/GR8, A31(s), and A23/A33/R16
SoCs and all existing boards verbatim from the Linux v5.15 tag.
These SoCs are combined into one commit due to some interdependencies:
- The unit addresses were removed from bitbanged I2C buses, which
drives a Kconfig default change. This affects sun5i-a13-utoo-p66.dts
and sun6i-a31-colombus.dts.
- The pinctrl nodes were renamed, including some used by the shared
sunxi-reference-design-tablet.dtsi.
This commit renames the file sun8i-r16-nintendo-nes-classic-edition.dts
to sun8i-r16-nintendo-nes-classic.dts to match the Linux tree.
As with the other SoCs, updates of note are EMAC phy-mode changes to set
RGMII delays, conversion of GPIO pull-up from pinconf to GPIO flags, and
renaming the detection GPIO properties in the USB PHY nodes.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree source for the A20 SoC and all existing boards
verbatim from the Linux v5.15 tag.
An important change here is to the GMAC phy-mode property on several
boards; this needs to be set correctly once the rtl8211e driver starts
configuring the PHY RGMII delays from the devicetree.
This update also includes changes to the USB PHY detection GPIO
properties which are needed to convert that driver to use the DM GPIO
framework.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree source for the A10 SoC and all existing boards
verbatim from the Linux v5.15 tag.
While this update should not impact any existing U-Boot functionality,
the changes to the USB PHY detection GPIO properties are needed to
convert that driver to use the DM GPIO framework.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This adds a new PSCI implementation which communicates with SCP firmware
running on the AR100 using the SCPI protocol. This allows it to support
the full set of PSCI v1.1 features, including CPU idle states, system
suspend, and multiple reset methods.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Add the new option, function IDs, and prototypes for PSCI v1.1
implementations. In the process, fix some issues with the existing
definitions:
- Fix the incorrectly-named ARM_PSCI_0_2_FN64_SYSTEM_RESET2.
- Replace the deprecated "affinity_level" naming with "power_level".
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that issues with the BROM have been sorted out, we can implement
PSCI system suspend on H3 by delegating to SCP firmware. Let's start by
including the firmware in the FIT image and starting the coprocessor if
valid firmware is loaded.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Due to a bug in the H3 SoC, where the CPU 0 hotplug flag cannot be
written, resuming CPU 0 requires using the "Super Standby" code path in
the BROM instead of the hotplug path. This path requires jumping to an
eGON image in SRAM.
Add support to the build system to generate this eGON image and include
it in the FIT, and add code to direct the BROM to its location in SRAM.
Since the Super Standby code path in the BROM initializes the CPU and
AHB1 clocks to 24 MHz, those registers need to be restored after control
passes back to U-Boot. Furthermore, because the BROM lowers the AHB1
clock divider to /1 before switching to the lower-frequency parent,
PLL_PERIPH0 must be bypassed to prevent AHB1 from temporarily running at
600 MHz. Otherwise, this locks up the SoC.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Do not try to send an SGI from CPU 0 to itself. Since FIQs are masked
when entering monitor mode, this will hang. Plus, CPU 0 cannot fully
power itself off anyway. Instead, have it turn FIQs back on and continue
servicing SGIs from other cores.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that Crust (SCP firmware) has support for H3, we need a FIT image to
load it. H3 also needs to load a SoC-specific eGon blob to support CPU 0
hotplug. Let's first enable FIT support before adding extra firmware.
Update the binman description to work on either 32-bit or 64-bit SoCs:
- Make BL31 optional, since it is not used on 32-bit SoCs (though BL32
may be used in the future).
- Explicitly set the minimum offset of the FIT to 32 KiB, since SPL on
some boards is still only 24 KiB large even with FIT support enabled.
CONFIG_SPL_PAD_TO cannot be used because it is not defined for H616.
FIT unlocks more features (signatures, multiple DTBs, etc.), so enable
it by default. A10 (sun4i) only has 24 KiB of SRAM A1, so it needs
SPL_FIT_IMAGE_TINY. For simplicity, enable that option everywhere.
Cover-letter:
sunxi: SPL FIT support for 32-bit sunxi SoCs
This series makes the necessary changes so 32-bit sunxi SoCs can load
additional device trees or firmware from SPL along with U-Boot proper.
There was no existing binman entry property that put the FIT at the
right offset. The minimum offset is 32k, but this matches neither the
SPL size (which is no more than 24k on some SoCs) nor the FIT alignment
(which is 512 bytes in practice due to SPL size constraints). So instead
of adding a new property, I fixed what is arguably a bug in the offset
property -- though this strategy will not work if someone is
intentionally creating overlapping entries.
END
Series-to: sunxi
Series-to: sjg
Signed-off-by: Samuel Holland <samuel@sholland.org>
Currently, if the "offset" property is given for an entry, the section's
running offset is completely ignored. This causes entries to overlap if
the provided offset is less than the size of the entries earlier in the
section. Avoid the overlap by only using the provided offset when it is
greater than the running offset.
The motivation for this change is the rule used by SPL to find U-Boot on
sunxi boards: U-Boot starts 32 KiB after the start of SPL, unless SPL is
larger than 32 KiB, in which case U-Boot immediately follows SPL.
Signed-off-by: Samuel Holland <samuel@sholland.org>
TOC1 is an container format used by Allwinner's boot0 that can hold
multiple images. It supports encryption and signatures, but that
functionality is not implemented, only the basic "non-secure" subset.
A config file is used to provide the list of data files to include. Its
path is passed as the argument to "-d". It contains sections of the
following form:
[name]
file = /path/to/file
addr = 0x12345678
Specific well-known names, such as "dtb", "opensbi", and "u-boot", are
used by the bootloader to distinguish the items inside the image.
Cover-letter:
tools: mkimage: Add Allwinner TOC1 support
The SPL port for the Allwinner D1 RISC-V SoC will probably take a while
longer than porting U-Boot proper, as none of the relevant drivers are
set up for DM in SPL. In the meantime, we are using[1][2] a fork[3] of
Allwinner's boot0 loader, which they also call "spl" in their BSP. boot0
uses this TOC1 image format.
The vendor tools for generating TOC1 images require a binary config file
generated by their FEX compiler. Instead of trying to support that, I
made up a simple human-readable config file format. I didn't see any
existing platform-agnostic parser for multi-image containers in mkimage.
I am sending this as RFC because it is only of temporary/limited use.
It only works with one specific fork of boot0 which was modified to
"behave" (the the original vendor version monkey-patches a custom header
inside the U-Boot image during boot). So it will be obsolete once U-Boot
SPL is ported. And it is Yet Another Image Format. On the other hand, it
does work, and it is currently being used.
[1]: https://linux-sunxi.org/Allwinner_Nezha#U-Boot
[2]: https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner
[3]: https://github.com/smaeul/sun20i_d1_spl
END
Series-prefix: RFC
Series-to: sunxi
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that mkimage can generate TOC0 images, and the SPL can interpret
them, hook up the build infrastructure so the user can choose which
image type to build. Since the absolute load address is stored in the
TOC0 header, that information must be passed to mkimage.
Cover-letter:
sunxi: TOC0 image type support
This series adds support for the TOC0 image format used by the Allwinner
secure boot ROM (SBROM). This series has been tested on the following
SoCs/boards, with the eFuse burnt to enable secure mode:
- A50: Ainol Q88 Tablet
- A64: Pine A64 Plus
- H5: Orange Pi Zero Plus
- H6: Pine H64 Model B
- H616: Orange Pi Zero 2
This time I also tested it on boards that are not switched to secure
mode (with A64, H3, and H5).
Due to both series changing Makefile.spl, the last patch depends on:
https://patchwork.ozlabs.org/project/uboot/list/?series=267136
I have seen no comments on that series, so I assume that it is ready to
merge along with this one.
END
Series-to: sunxi
Series-version: 5
Series-changes: 2
- Rebase on top of Icenowy's RISC-V support series
- Rename Kconfig symbols to include the full image type name
Cover-changes: 5
- Dropped controversial Kconfig patch
Signed-off-by: Samuel Holland <samuel@sholland.org>
SPL uses the image header to detect the boot device and to find the
offset of the next U-Boot stage. Since this information is stored
differently in the eGON and TOC0 image headers, add code to find the
correct value based on the image type currently in use.
Series-changes: 2
- Moved SPL header signature checks out of sunxi_image.h
- Refactored SPL header signature checks to use fewer casts
Series-changes: 3
- Fixed offset of magic passed to memcmp
- Refactored functions to not return pointers (fixes ambiguous NULL)
Series-changes: 5
- Rebased on top of suniv platform additions
- Took care of additional hardcoded offset in SPL SPI code
Signed-off-by: Samuel Holland <samuel@sholland.org>
Most Allwinner sunxi SoCs have separate boot ROMs in non-secure and
secure mode. The "non-secure" or "normal" boot ROM (NBROM) uses the
existing sunxi_egon image type. The secure boot ROM (SBROM) uses a
completely different image type, known as TOC0.
A TOC0 image is composed of a header and two or more items. One item
is the firmware binary. The others form a chain linking the firmware
signature to the root-of-trust public key (ROTPK), which has its hash
burned in the SoC's eFuses. Signatures are made using RSA-2048 + SHA256.
The pseudo-ASN.1 structure is manually assembled; this is done to work
around bugs/quirks in the boot ROM, which vary between SoCs. This TOC0
implementation has been verified to work with the A50, A64, H5, H6,
and H616 SBROMs, and it may work with other SoCs.
Series-changes: 2
- Moved certificate and key item structures out of sunxi_image.h
- Renamed "main" and "item" variables for clarity
- Improved error messages, and added a hint about key generation
- Added a comment explaining the purpose of the various key files
- Mentioned testing this code on A50 in the commit message
Series-changes: 3
- Removed TOOLS_LIBCRYPTO selection for sunxi, since most boards
do not need it
- Added __packed to all new "ABI" structs
- Added entry to MAINTAINERS for sunxi tools
Signed-off-by: Samuel Holland <samuel@sholland.org>
As mkimage -T sunxi_egon now gains support for -A parameter, specify the
architecture when generating SPL boot image for sunxi.
Series-to: sunxi
Series-cc: Icenowy Zheng <icenowy@aosc.io>
Series-version: 3
Cover-letter:
mkimage: sunxi_egon: add riscv support
This patchset updates mkimage -T sunxi_egon to be able to generate
an eGON.BT0 image for Allwinner RISC-V SoCs (e.g. D1).
In addition, to keep the compatibility, it will still consider the
architecture to be ARM when no architecture is specified.
This v3 is a minor update to Icenowy's patch series, which I have
also tested. Since the TOC0 patch series touches the same lines in
Makefile.spl, it depends on this series.
END
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Samuel Holland <samuel@sholland.org>
There's now a sun20i family in sunxi, which uses RISC-V CPU.
Add support for making eGON.BT0 image for RISC-V.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Refactor some functions in mkimage sunxi_egon type, in order to prepare
for adding support for more CPU architectures (e.g. RISC-V). In
addition, compatibility for operation w/o specified architecture is
kept, in this case the architecture is assumed as ARM.
Series-changes: 3
- Factor out an egon_get_arch() function as suggested by Andre
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Samuel Holland <samuel@sholland.org>
The sunxi_egon type used to take no -A argument (because we assume sunxi
targets are all ARM). However, as Allwinner D1 appears as the first
RISC-V sunxi target, we need to support -A; in addition, as external
projects rely on U-Boot mkimage to generate sunxi eGON.BT0 header, we
need to keep compatibility with command line without -A.
As the default value of arch in mkimage is not proper (IH_ARCH_PPC
instead of IH_ARCH_INVALID), to keep more compatibility, add an Aflag
field to image parameters to describe whether an architecture is
explicitly specified.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Samuel Holland <samuel@sholland.org>
On RK3568, a register bit must be set to enable Enhanced Strobe.
However, it appears that the address of this register may differ from
vendor to vendor and should be read from the underlying MMC IP. Let the
Rockchip SDHCI driver read this address and set the relevant bit when
Enhanced Strobe configuration is requested.
The IP uses a custom mode select value (0x7) for HS400, use that instead
of the common but non-standard SDHCI_CTRL_HS400 value (0x5). Also add
some necessary DLL_STRBIN and DLL_TXCLK configuration for HS400.
Additionally, a bit signifying that the connected hardware is an eMMC
chip must be set to enable Data Strobe for HS400 and HS400ES modes. Also
make the driver set this bit as appropriate.
This is partly ported from Linux's Synopsys DWC MSHC driver which
happens to be the underlying IP. (drivers/mmc/host/sdhci-of-dwcmshc.c in
Linux tree).
Co-developed-by: Yifeng Zhao <yifeng.zhao@rock-chips.com>
Signed-off-by: Yifeng Zhao <yifeng.zhao@rock-chips.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
On RK3399, a register bit must be set to enable Enhanced Strobe.
Let the Rockchip SDHCI driver set it when Enhanced Strobe configuration
is requested. However, having it set makes the lower-speed modes stop
working and makes reinitialization fail, so let it be unset as needed in
set_control_reg().
This is mostly ported from Linux's Arasan SDHCI driver which happens
to be the underlying IP. (drivers/mmc/host/sdhci-of-arasan.c in Linux
tree).
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Delegate setting the Enhanced Strobe configuration to individual drivers
if they set a function for it. Return -ENOTSUPP if they do not, like
what the MMC uclass does.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Generic SDHCI driver received support for checking the busy status by
polling the DAT[0] level instead of waiting for the worst MMC switch time.
Unfortunately, it appears that this does not work for Xenon controllers
despite being a part of the standard SDHCI registers and the Armada 3720
datasheet itself telling that BIT(20) is useful for detecting the DAT[0]
busy signal.
I have tried increasing the timeout value, but I have newer managed to
catch DAT_LEVEL bits change from 0 at all.
This issue appears to hit most if not all SoC-s supported by Xenon driver,
at least A3720, A8040 and CN9130 have non working eMMC currently.
So, until a better solution is found drop the wait_dat0 OP for Xenon.
I was able to only test it on A3720, but it should work for others as well.
Fixes: 40e6f52454fc ("drivers: mmc: Add wait_dat0 support for sdhci driver")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Stefan Roese <sr@denx.de>
e-MMC and SD standards differ for some CID fields:
- 6 Byte Name - assigned by Manufacturer (SD 5 Byte)
- 1 Byte OEM - assigned by Jedec (SD 2 Byte)
See e-MMC standard (JEDEC Standard No. 84-B51), 7.2.3 (OID) and 7.2.4 (PNM)
Signed-off-by: Max Merchel <Max.Merchel@tq-group.com>
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
After commit f132aab40327 ("Revert "mmc: fsl_esdhc_imx: use
VENDORSPEC_FRC_SDCLK_ON to control card clock output""), it
involve issue in mmc_switch_voltage(), because of the special
design of usdhc.
For FSL_USDHC, it do not implement VENDORSPEC_CKEN/PEREN/HCKEN/IPGEN,
these are reserved bits(Though RM contain the definition of these bits,
but actually internal IC logic do not implement, already confirm with
IC team). Instead, use VENDORSPEC_FRC_SDCLK_ON to gate on/off the card
clock output. Here is the definition of this bit in RM:
[8] FRC_SDCLK_ON
Force CLK output active
Do not set this bit to 1 unless it is necessary. Also, make sure that
this bit is cleared when uSDHC’s clock is about to be changed (frequency
change, clock source change, or delay chain tuning).
0b - CLK active or inactive is fully controlled by the hardware.
1b - Force CLK active
In default, the FRC_SDCLK_ON is 0. This means, when there is no command
or data transfer on bus, hardware will gate off the card clock. But in
some case, we need the card clock keep on. Take IO voltage 1.8v switch
as example, after IO voltage change to 1.8v, spec require gate off the
card clock for 5ms, and gate on the clock back, once detect the card
clock on, then the card will draw the dat0 to high immediately. If there
is not clock gate off/on behavior, some card will keep the dat0 to low
level. This is the reason we fail in mmc_switch_voltage().
To fix this issue, and concern that this is only the fsl usdhc hardware
design limitation, set the bit FRC_SDCLK_ON in the beginning of the
wait_dat0() and clear it in the end. To make sure the 1.8v IO voltage
switch process align with SD specification.
For standard tuning process, usdhc specification also require the card
clock keep on, so also add these behavior in fsl_esdhc_execute_tuning().
Reviewed-by: Marek Vasut <marex@denx.de>
Tested-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Commit 0934dddc6436 ("arm: a37xx: Update DTS files to version from
upstream Linux kernel") ported Linux's device-tree files for Armada 3720
SOCs. This broke network on Turris MOX, because the SOC's MDIO bus in
U-Boot currently isn't probed via DM as it's own device, but is
registered as part of mvneta's driver, which means that pinctrl
definitions are not parsed for the MDIO bus node. Also mvneta driver
does not consider "phy-handle" property, only "phy".
For now, fix this by adding armada-3720-turris-mox-u-boot.dtsi file
returning the MDIO to how it was defined previously.
A better solution (using proper mvmdio DM driver) is being work on, but
will need testing on various boards, and we need the bug fixed now for
the upcoming release.
Fixes: 0934dddc6436 ("arm: a37xx: Update DTS files to version from upstream Linux kernel")
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
stm32mp1 bsec: Add permanent lock write support
stm32mp1 bsec: Add dev in function description
cmd_stboard: Update test on misc_read() result
video: fix the check of return value of clk_set_rate in stm32_ltdc
DT: Alignment with kernel v5.17 for stm32mp15
DT: Add USB OTG pinctrl and regulator in SPL for DHCOR
DT: Move vdd_io extras into Avenger96 extras
DT: Add DFU support for DHCOM recovery
ram: stm32mp1: Unconditionally enable ASR
psci: Implement PSCI system suspend and DRAM SSR for stm32mp
-----BEGIN PGP SIGNATURE-----
iQJQBAABCgA6FiEEXyrViUccKBz9c35Jysd4L3sz/6YFAmIwUdYcHHBhdHJpY2Uu
Y2hvdGFyZEBmb3NzLnN0LmNvbQAKCRDKx3gvezP/pj/FEAClzm1xFrw0oxsIGf9J
Ukyd66yIWiC2rjrxnOh7dtE3toHVVr9+GtM3RohS913BFoVTzlwUlfK75LBrxwWg
Qyp6P8BUWIf8P3Q/x+VcLXuHr/Q+o7prROxclumTEnhzcDhlp/Q6zwXcqXIH77cn
uOxjK5BE1Mt1KI8Fz94EqntoOars5UvxPpye7pahAlGzdZ1PDB1YR8dE5ZjCRG3Q
jNx6I0EZBfjQTHBEtLUSIUGykCDWGJwfbPEgZPa1ePdkgOvDrKQDd0ES89lhjU95
SQG9GFChug+rvXh9i4dxPBK1TGsvCjlZCbrmDGZGLnCfwkHsIzv+ajTpyBzXH5xA
t3XWK0vIaCOpAs1CcRrLjVUA6Paz8qkbTyoGGezvWtRwZ7wV35nI0n/g+R9NM1jC
GR5rrH6yIqrhj6TCneckkIVuiGRRVAXrr43a0BazzzBLSw8N9R8QB8BiM+p4hr8C
anakyfZSN2Y8dBp4EAfzyCV2hOPaUNdaUyzcUIxxDu8eQAqZR0nzjXY6vuV8g702
jr8Q/J2nc520INo6nwHKyOTD4+xAOK81cjQ0LTswTkx67afPmtAXH9EjZLeQ/u9P
ReKCnf/krS/0BhN2WoYXuAl7YQmXyLilrcsA9pXg2fc6lLNw48ZKz0eDZzX549kM
mP8xVQ+qQAiCcIxd+ijwuSSmTA==
=H4+P
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20220315' of https://source.denx.de/u-boot/custodians/u-boot-stm
mtd: add NAND write protect support to stm32_fmc2_nand
stm32mp1 bsec: Add permanent lock write support
stm32mp1 bsec: Add dev in function description
cmd_stboard: Update test on misc_read() result
video: fix the check of return value of clk_set_rate in stm32_ltdc
DT: Alignment with kernel v5.17 for stm32mp15
DT: Add USB OTG pinctrl and regulator in SPL for DHCOR
DT: Move vdd_io extras into Avenger96 extras
DT: Add DFU support for DHCOM recovery
ram: stm32mp1: Unconditionally enable ASR
psci: Implement PSCI system suspend and DRAM SSR for stm32mp
Using bias-pull-up would actually cause the pin to have its pull-down
enabled. Fix this.
Original Linux patch by Sean Anderson:
https://lore.kernel.org/linux-gpio/20220209182822.640905-1-seanga2@gmail.com/
Fixes: 7224d5ccf8e1 ("pinctrl: Add support for Kendryte K210 FPIOA")
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
The loop exited too early so the k210_pc_drive_strength[0] array element
was never used.
Original Linux patch by Dan Carpenter:
https://lore.kernel.org/linux-gpio/20220209180804.GA18385@kili/
Fixes: 7224d5ccf8e1 ("pinctrl: Add support for Kendryte K210 FPIOA")
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
