usb: musb-new: add Allwinner F1C100s support

The Allwinner F1C100s SoC has a MUSB controller like the one in the A33,
but needs an SRAM region to be claimed like the A10. We do the latter
anyway, even on chips that don't need it, so there is no real difference
in our compatible string matching.

Add a mapping between the config struct used in the Linux to our
requirements here on the way.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: SPL SPI: Add SPI boot support for the Allwinner R528/T113 SoCs

R528/T113 SoCs uses the same SPI IP as the H6, also have the same clocks
and reset bits layout, but the CCU base is different. Another difference
is that the new SoCs do not have a clock divider inside. Instead of this
we should configure sample mode depending on input clock rate.

The pin assignment is also different: the H6 uses PC0, the R528/T113 PC4
instead. This makes for a change in spi0_pinmux_setup() routine.

This patch extends the H6/H616 #ifdef guards to also cover the R528/T113,
using the shared CONFIG_SUNXI_GEN_NCAT2 and CONFIG_MACH_SUN8I_R528
symbols. Also use CONFIG_SUNXI_GEN_NCAT2 symbol for the Kconfig
dependency.

Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com>
Tested-by: Sam Edwards <CFSworks@gmail.com>

Merge tag 'u-boot-imx-master-20240420' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx

CI:
https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20444

- Make i.MX93 boot less verbose.
- Remove unneedd environment variables from Toradex i.MX boards.
- Use gpio-hog on verdin-imx8mm/imx8mp.
- Add PCIe support for i.MX8MM.
- Add TPM support for imx8m*-venice.

Merge tag 'efi-2024-07-rc1-3' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request efi-2024-07-rc1-3

Documentation:

* sort env sub-commands alphabetically
* update list of aliases for the env command

UEFI:

* allow enabling SetVariable at runtime
  for future OS supported writing to ubootefi.var
* use event callback for initrd deregistration

Others:

* correct alignment of x86 firmware tables

x86: all firmware tables must be paragraph aligned

On qemu-x86_64_defconfig the following was observed:

    => efidebug tables
    00000000000f0074  eb9d2d31-2d88-11d3-9a16-0090273fc14d  SMBIOS table

The SMBIOS configuration table does not point to a paragraph-aligned
(16 byte aligned) address. The reason is that in write_tables() rom_addr is
not aligned and copied to gd->arch.smbios_start.

The Simple Firmware Interface requires that the SFI table is paragraph-
aligned but our code does not guarantee this.

As all tables written in write_tables() must be paragraph-aligned, we
should implement the address rounding in write_tables() and not in table
specific routines like copy_pirq_routing_table().

Add paragraph-alignment in write_tables().

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

efi_selftest: add tests for setvariableRT

Since we support SetVariableRT now add the relevant tests

- Search for the RTStorageVolatile and VarToFile variables after EBS
- Try to update with invalid variales (BS, RT only)
- Try to write a variable bigger than our backend storage
- Write a variable that fits and check VarToFile has been updated
  correclty
- Append to the variable and check VarToFile changes
- Try to delete VarToFile which is write protected
- Try to add/delete runtime variables
- Verify VarToFile contains a valid file format

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: add an EFI variable with the file contents

Previous patches enabled SetVariableRT using a RAM backend.
Although EBBR [0] defines a variable format we can teach userspace tools
and write the altered variables, it's better if we skip the ABI
requirements completely.

So let's add a new variable, in its own namespace called "VarToFile"
which contains a binary dump of the updated RT, BS and, NV variables
and will be updated when GetVariable is called.

Some adjustments are needed to do that.
Currently we discard BS-only variables in EBS(). We need to preserve
those on the RAM backend that exposes the variables. Since BS-only
variables can't appear at runtime we need to move the memory masking
checks from efi_var_collect() to efi_get_next_variable_name_mem()/
efi_get_variable_mem() and do the filtering at runtime.

We also need an efi_var_collect() variant available at runtime, in order
to construct the "VarToFile" buffer on the fly.

All users and applications (for linux) have to do when updating a variable
is dd that variable in the file described by "RTStorageVolatile".

Linux efivarfs uses a first 4 bytes of the output to represent attributes
in little-endian format. So, storing variables works like this:

$~ efibootmgr -n 0001
$~ dd if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c of=/boot/efi/ubootefi.var skip=4 bs=1

[0] https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage

Suggested-by: Ard Biesheuvel <ardb@kernel.org> # dumping all variables to a variable
Co-developed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> # contributed on efi_var_collect_mem()
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Add OS notifications for SetVariable at runtime

Previous patches enable SetVariable at runtime using a volatile storage
backend using EFI_RUNTIME_SERVICES_DATA allocared memory. Since there's
no recommendation from the spec on how to notify the OS, add a volatile
EFI variable that contains the filename relative to the ESP. OS'es
can use that file and update it at runtime

$~ efivar -p -n b2ac5fc9-92b7-4acd-aeac-11e818c3130c-RTStorageVolatile
GUID: b2ac5fc9-92b7-4acd-aeac-11e818c3130c
Name: "RTStorageVolatile"
Attributes:
Boot Service Access
Runtime Service Access
Value:
00000000  75 62 6f 6f 74 65 66 69  2e 76 61 72 00           |ubootefi.var.   |

Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: conditionally enable SetvariableRT

When we store EFI variables on file we don't allow SetVariable at runtime,
since the OS doesn't know how to access or write that file.  At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous -- if at all possible.

For GetVariable at runtime we copy runtime variables in RAM and expose them
to the OS. Add a Kconfig option and provide SetVariable at runtime using
the same memory backend. The OS will be responsible for syncing the RAM
contents to the file, otherwise any changes made during runtime won't
persist reboots.

It's worth noting that the variable store format is defined in EBBR [0]
and authenticated variables are explicitly prohibited, since they have
to be stored on a medium that's tamper and rollback protected.

- pre-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs (ro,nosuid,nodev,noexec,relatime)

$~ efibootmgr -n 0001
Could not set BootNext: Read-only file system

- post-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

$~ efibootmgr -n 0001
BootNext: 0001
BootCurrent: 0000
BootOrder: 0000,0001
Boot0000* debian        HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x100000)/File(EFI\debian\grubaa64.efi)
Boot0001* virtio 0      VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,850000001f000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,1600850000000000){auto_created_boot_option}

$~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "BootNext"
Attributes:
        Non-Volatile
        Boot Service Access
        Runtime Service Access
Value:
00000000  01 00

FWTS runtime results
Skipped tests are for SetVariable which is now supported
'Passed' test is for QueryVariableInfo which is not yet supported

Test: UEFI miscellaneous runtime service interface tests.
  Test for UEFI miscellaneous runtime service interfaces  6 skipped
  Stress test for UEFI miscellaneous runtime service i..  1 skipped
  Test GetNextHighMonotonicCount with invalid NULL par..  1 skipped
  Test UEFI miscellaneous runtime services unsupported..  1 passed
Test: UEFI Runtime service variable interface tests.
  Test UEFI RT service get variable interface.            1 passed
  Test UEFI RT service get next variable name interface.  4 passed
  Test UEFI RT service set variable interface.            8 passed
  Test UEFI RT service query variable info interface.     1 skipped
  Test UEFI RT service variable interface stress test.    2 passed
  Test UEFI RT service set variable interface stress t..  4 passed
  Test UEFI RT service query variable info interface s..  1 skipped
  Test UEFI RT service get variable interface, invalid..  5 passed
  Test UEFI RT variable services unsupported status.      1 passed, 3 skipped

[0] https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage

Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: use event callback for initrd deregistration

Currently efi_initrd_deregister() is called in bootefi.c
when the image started from bootefi command returns.
Since efi_guid_event_group_return_to_efibootmgr event is
implemented, so let's use this event for invoking
initrd deregistration.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: typo mstching

%s/mstching/matching/

Reported-by: E Shattow <lucent@gmail.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

cmd: eficonfig: check initrd path allocation

After allocating memory for the initrd file path we need to check the
initrd buffer pointer is not NULL.

Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot option")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: update list of aliases for the env command

* add link to askenv man-page
* add printenv

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: sort env sub-commands alphabetically

The 'env' man-page is currently only partially sorted.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

imx8mm_venice_defconfig: Enable PCIe/NVMe support

Enable PCIe/NVMe support. Also, enable the reset
driver which is a prerequisite for PCIe support.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>

pci: dw_imx: add support for IMX8MM

Add support for the IMX8MM SoC by adding driver data with the compatible
string of the GPR controller.

Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>

clk: imx8mm: Add support for PCIe clocks

Add support for PCIe clocks required to enable PCIe support on
iMX8MM SoC.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Marek Vasut <marex@denx.de>

board: toradex: imx: Remove not needed env variables

Remove not needed variables from environment and include config files.

 - setup variable used to be executed from some bootscript, however
   it's not required and there is no point on having this small helper
   here
 - boot_file, kernel_file, ip_dyn variables are not used anywhere
 - fdt_fixup variable is just set empty
 - defargs, vidargs variables used to be used from some bootscript,
   however there is no point on having it here and even old legacy
   bootscript can work without them
 - removed CONFIG_ENABLE_DDR_TRAINING_DEBUG, this is a leftover from
   some copy/paste

On colibri imx6ull/imx7 NAND module, remove consoleblank=0, this is
already the Linux kernel default therefore useless.

Various Linux Kernel command line options removed are not-existing
left-over that applied to some old NXP i.MX downstream branch

Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>

imx8m*_venice_defconfig: enable ipv6, wget and tftpput

Enable ipv6, wget, and tftpput support

Signed-off-by: Tim Harvey <tharvey@gateworks.com>

board: gateworks: venice: fix dt adjustment for gw73xx baseboard for imx8mp

The GW73xx baseboard needs a PCI dt adjustment for revC/D based on a
change of the PCIe switch. Make sure we are only doing this for a pci
based ethernet to avoid causing a boot hang when the ethernet1 alias
points to eqos or fec. To know this is a pcie device ensure the alias
begins with the pcie controller.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>

arm: dts: verdin-imx8mm/imx8mp: use gpio-hog for sleep moci

In Linux, we allow sleep moci to be turned off when the carrier board
supports it and the system is in suspend. In U-Boot, however, we want
the sleep moci to be always on. So we use a gpio hog and disable the
regulator. This change is necessary because we switched to upstream
device tree files with commit 23fe2def1edf
("verdin-imx8mm/verdin-imx8mp: move imx verdins to OF_UPSTREAM"). A
recent upstream patch removes the gpio hog from the Linux device tree,
so we need to add it to the u-boot dtsi. The following patch will remove
the gpio hog from the Linux device tree:
https://lore.kernel.org/linux-devicetree/20240405160720.5977-1-eichest@gmail.com/
The U-Boot patch can be applied without it and will not break the build.

Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>

imx93: Move SoC and lifeclycle information to debug level

The following information printed on every boot is not very
helpful for the users:

SOC: 0xa0009300
LC: 0x40040

Move them to debug() level.

Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Mathieu Othacehe <othacehe@gnu.org>

imx8m*-venice: enable TPM support

Enable support for TPM2 devices. As the ATTPM20P TPM2 used on the
Gateworks Venice boards hangs off the SPI bus we enable SPI support
as well.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>

Merge tag 'u-boot-stm32-20240419' of https://source.denx.de/u-boot/custodians/u-boot-stm

MP1:
 _ Add OHCI HCD support for STM32MP15xx DHSOM
 _ Report OTP-CLOSED instead of rev.? on closed STM32MP15xx
 _ Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
 _ Jump to ep on successful resume in PSCI suspend code
 _ Add FASTBOOT support for STM32MP13
 _ Fix/Rework key and leds management for STM32MP13/15
 _ net: dwc_eth_qos: Clean up STM32 glue code and add STM32MP13xx support

MP2:
 _ Add stm32-fmc-ebi support
 _ Add: sdmmc2 support and fix AARCH64 compilation

Merge tag 'u-boot-dfu-20240419' of https://source.denx.de/u-boot/custodians/u-boot-dfu

u-boot-dfu-20240419

- new "fastboot oem board" command

ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot

The blue led is used to indicate U-Boot entering / exit indication
then Linux heartbeat.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot

As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds"; which is not present in kernel DT.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot

red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.

To avoid this, remove the "default-state" property from red led node.

This will avoid to trigger the led driver probe() to configure the led
default state during startup.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-scmi-u-boot

Add 2 gpio-keys :
  _ button-user-1 for stm32prog mode activation.
  _ button-user-2 for fastboot mode activation.

Remove proprietary st,fastboot-gpios and st,stm32prog-gpios.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-u-boot

The blue led is used to indicate U-Boot entering / exit indication
then Linux heartbeat.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot

As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds" which is not present in kernel DT.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot

red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.

To avoid this, remove the "default-state" property from red led node.

This will avoid to trigger the led driver probe() to configure the led
default state during startup.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-u-boot

Add 2 gpio-keys :
  _ button-user-1 for stm32prog mode activation.
  _ button-user-2 for fastboot mode activation.

Remove proprietary st,fastboot-gpios and st,stm32prog-gpios.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Update u-boot, boot-led for stm32mp157a-dk1-u-boot

As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot

As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot

red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.

To avoid this, remove the "default-state" property from red led node.

This will avoid to trigger the led driver probe() to configure the led
default state during startup.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-u-boot

Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
2 gpio-keys.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot

As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot

As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename "red" led node's name to "led-red".
Remove status property which is useless.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot

red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.

To avoid this, remove the "default-state" property from red led node.

This will avoid to trigger the led driver probe() to configure the led
default state during startup.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-scmi-u-boot

Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
2 gpio-keys.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Clean led-red node for stm32mp135f-dk-u-boot

Remove "color" property from led-red node which is not supported
by U-Boot.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot

led-red and button dedicated to fastboot share the same gpio GPIOA13.
led-blue and button dedicated to stm32prog share the same gpio GPIOA14.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.

To avoid this, remove the "default-state" property from led-red and
led-blue led's node.

This will avoid to trigger the led driver probe() to configure the led
default state during startup.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot

Add 2 gpio-keys :
  _ button-user-1 for stm32prog mode activation.
  _ update button-user's label (defined in kernel DT) to match label
    requested in board_key_check() for fastboot mode activation.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

board: st: stmp32mp1: Use BUTTON UCLASS in board_key_check()

Instead of using gpio directly to detect key pressed on button
dedicated for fastboot and stm32mprog, make usage of BUTTON UCLASS.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp13_defconfig

Enable BUTTON_GPIO flag for STM32MP15.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>

configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_trusted_defconfig

Enable BUTTON_GPIO flag for STM32MP15.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_basic_defconfig

Enable BUTTON_GPIO flag for STM32MP15.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_defconfig

Enable BUTTON_GPIO flag for STM32MP15.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

configs: stm32mp13: Enable FASTBOOT

Enable FASTBOOT relative flags for stm32mp13_defconfig.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>

mmc: stm32_sdmmc2: Fix AARCH64 compilation warnings

When building with AARCH64 defconfig, we got warnings, fix them.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2" compatible

Add compatible used for STM32MP25 family.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcom-u-boot

Fix flash@0 partition node name with correct offset.

Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand
node for stm32mp15xx-dhcom/dhcor")

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcor-u-boot

Fix flash@0 partition node name with correct offset.

Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand node for
stm32mp15xx-dhcom/dhcor")

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Fix partition node name for stm32mp157c-ev1-u-boot

Fix flash@0 and nand@0 partition node name with correct offset.

Fixes: e91d3c61767b ("arm: dts: stm32: Add partitions in flash0 and nand
node for stm32mp15xx-ev1")

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx

In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be
released from endless loop in BootROM only by populating TAMP BKPxR 4
and 5 with magic and branch address and sending SGI0 interrupt from
core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized
as well to release the core 1 from endless loop during the second SGI0
handling on core 1. Initialize TAMP_SMCR to protect the first 32 backup
registers, the ones which contain the core 1 magic, branch address and
boot information.

This requirement seems to be undocumented, therefore it was necessary
to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump.
Ultimately, it turns out that a certain BootROM function reads out the
TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero.
If they are zero, the BootROM code again waits for SGI0 using WFI, else
the execution moves forward until it reaches handoff to the TAMP BKPxR 5
branch address.

This fixes CPU core 1 release using U-Boot PSCI implementation on an
OTP-CLOSED system, i.e. system with fuse 0 bit 6 set.

Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

ARM: stm32: Report OTP-CLOSED instead of rev.? on closed STM32MP15xx

SoC revision is only accessible via DBUMCU IDC register,
which requires BSEC.DENABLE DBGSWENABLE bit to be set to
make the register accessible, otherwise an access to the
register triggers bus fault. As BSEC.DBGSWENABLE is zero
in case of an OTP-CLOSED system, do NOT set DBGSWENABLE
bit as this might open a brief window for timing attacks.
Instead, report that this system is OTP-CLOSED and do not
report any SoC revision to avoid confusing users. Use an
SEC/C abbreviation to avoid growing SOC_NAME_SIZE .

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

ARM: stm32: Drop superfluous Makefile entry for ecdsa_romapi.o

The source file is in arch/arm/mach-stm32mp/ecdsa_romapi.c and not
in arch/arm/mach-stm32mp/stm32mp1/ecdsa_romapi.c . There are two
Makefile entries in each subdirectory. Drop the bogus one and keep
only the correct one, the one in arch/arm/mach-stm32mp/Makefile .

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

ARM: stm32: Jump to ep on successful resume in PSCI suspend code

In case the system has resumed successfully, the PSCI suspend resume
code has to jump to the 'ep' successful resume entry point code path,
otherwise the code has to jump to content of the LR register, which
points to failed resume code path.

To implement this distinction, rewrite LR register stored on stack
with 'ep' value in case of a successful resume, which is really in
every case unless some catastrophic failure occurred during suspend.

Without this change, Linux counts every resume as failed in
/sys/power/suspend_stats/fail

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

net: dwc_eth_qos: Add support for st, ext-phyclk property

The "st,ext-phyclk" property is a unification of "st,eth-clk-sel"
and "st,eth-ref-clk-sel" properties. All three properties define
ETH CK clock direction, however:
- "st,eth-clk-sel" selects clock direction for GMII/RGMII mode
- "st,eth-ref-clk-sel" selects clock direction for RMII mode
- "st,ext-phyclk" selects clock direction for all RMII/GMII/RGMII modes
The "st,ext-phyclk" is the preferrable property to use.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>

net: dwc_eth_qos: Add support of STM32MP13xx platform

Add compatible "st,stm32mp13-dwmac" to manage STM32MP13 boards.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
Signed-off-by: Marek Vasut <marex@denx.de> # Rebase, reshuffle, squash code
Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>

net: dwc_eth_qos: Add DT parsing for STM32MP13xx platform

Manage 2 ethernet instances, select which instance to configure with mask
If mask is not present in DT, it is stm32mp15 platform.

Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
Signed-off-by: Marek Vasut <marex@denx.de> # Rework the code
Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>

net: dwc_eth_qos: Constify st, eth-* values parsed out of DT

Use const bool for the values parsed out of DT. Drop the duplicate
assignment of false into those bool variables, assign them directly
with the content parsed out of DT. Abbreviate the variable name too.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>

net: dwc_eth_qos: Use consistent logging prints

Use dev_*() only to print all the logs from this glue code,
instead of mixing dev_*(), log_*(), pr_*() all in one code.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>

net: dwc_eth_qos: Move log_debug statements on top of case block

Move the log_debug() calls on top of the bit manipulation code.
No functional change.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>

net: dwc_eth_qos: Use FIELD_PREP for ETH_SEL bitfield

Use FIELD_PREP to configure content of ETH_SEL bitfield in SYSCFG_PMCSETR
register. No functional change.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>

net: dwc_eth_qos: Scrub ifdeffery

Replace ifdef CONFIG_CLK with if (CONFIG_IS_ENABLED(CLK)) to improve code
build coverage. Some of the functions printed debug("%s: OK\n", __func__);
on exit with and without CLK enabled, some did not, make it consistent and
print nothing if CLK is disabled.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>

net: dwc_eth_qos: Fold board_interface_eth_init into STM32 glue code

Move board_interface_eth_init() into eqos_probe_syscfg_stm32() in STM32
driver glue code. The eqos_probe_syscfg_stm32() parses STM32 specific DT
properties of this MAC and configures SYSCFG registers accordingly, there
is nothing board specific happening in this function, move it into generic
driver code instead. Drop the now unused duplicates from board files.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>

net: dwc_eth_qos: Rename eqos_stm32_config to eqos_stm32mp15_config

The current glue code is specific to STM32MP15xx, the upcoming STM32MP13xx
will introduce another entry specific to the STM32MP13xx. Rename the current
entry to eqos_stm32mp15_config in preparation for STM32MP13xx addition. No
functional change.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>

net: dwc_eth_qos: Split STM32 glue into separate file

Move STM32 glue code into separate file to contain the STM32 specific
code outside of the DWMAC core code. No functional change.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christophe ROULLIER<christophe.roullier@foss.st.com>

mtd: rawnand: stm32_fmc2: add MP25 support

FMC2 IP supports up to 4 chip select. On MP1 SoC, only 2 of them are
available when on MP25 SoC, the 4 chip select are available.

Let's use a platform data structure for parameters that will differ.

Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

memory: stm32-fmc2-ebi: add MP25 RIF support

The FMC2 revision 2 supports security and isolation compliant with
the Resource Isolation Framework (RIF). From RIF point of view,
the FMC2 is composed of several independent resources, listed below,
which can be assigned to different security and compartment domains:
 - 0: Common FMC_CFGR register.
 - 1: EBI controller for Chip Select 1.
 - 2: EBI controller for Chip Select 2.
 - 3: EBI controller for Chip Select 3.
 - 4: EBI controller for Chip Select 4.
 - 5: NAND controller.

Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

memory: stm32-fmc2-ebi: add MP25 support

Add the support of the revision 2 of FMC2 IP.
     - PCSCNTR register has been removed,
     - CFGR register has been added,
     - the bit used to enable the IP has moved from BCR1 to CFGR,
     - the timeout for CEx deassertion has moved from PCSCNTR to BCRx,
     - the continuous clock enable has moved from BCR1 to CFGR,
     - the clk divide ratio has moved from BCR1 to CFGR.

The MP1 SoCs have only one signal to manage all the controllers (NWAIT).
The MP25 SOC has one RNB signal for the NAND controller and one NWAIT
signal for the memory controller.

Let's use a platform data structure for parameters that will differ
between MP1 and MP25.

Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

arm: stm32: Enable OHCI HCD support on STM32MP15xx DHSOM

The OHCI HCD is mandatory for USB 1.1 FS/LS device support, enable it.
This used to be enabled implicitly before, now that implicit dependency
disappeared and this got disabled. Enable it manually.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

stm32mp: cmd_stm32prog: add dependencies with USB_GADGET_DOWNLOAD

This patch avoids compilation issue when CONFIG_USB_GADGET is deactivated
in defconfig, with undefined reference to run_usb_dnl_gadget and to
g_dnl_set_product.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@foundries.io>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

env: mmc: print MMC device being read

This prints the MMC device being read similar to how we print the MMC
device we write to when e.g. calling saveenv.

One of the side effects is that the boot log now shows from which MMC
device the env was loaded:

Loading Environment from MMC... Reading from MMC(1)... OK

This is useful to identify which MMC device the environment was loaded
from for boards where there are more than one (e.g. eMMC and SD card)
without adding some debug messages manually.

Sadly, there's no way to know which of the default or redundant
environment is being read from env_mmc_load before env_import_redund is
called so it is printing a bit later (and possibly after error/warning
messages).

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>

Kconfig: Remove all default n options

default n doesn't need to be specified. It is default option anyway.
Similar changes have been done by commit 18370f14975c ("Kconfig: Remove all
default n/no options").

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

boot: fdt: Turn all addresses and sizes into u64

In case of systems where DRAM bank ends at the edge of 32bit boundary,
start + size calculations would overflow. This happens on STM32MP15xx
with 1 DRAM bank starting at 0xc0000000 and 1 GiB of DRAM. This is a
usual 32bit system DRAM size overflow, fix it by doing all DRAM size
and offset calculations using u64 types. This also covers a case where
a 32bit PAE system might be able to address up to 36bits of DRAM.

Fixes: a4df06e41fa2 ("boot: fdt: Change type of env_get_bootm_low() to phys_addr_t")
Signed-off-by: Marek Vasut <marex@denx.de>

fs/erofs: add DEFLATE algorithm support

This patch adds DEFLATE compression algorithm support. It's a good choice
to trade off between compression ratios and performance compared to LZ4.
Alternatively, DEFLATE could be used for some specific files since EROFS
supports multiple compression algorithms in one image.

Signed-off-by: Jianan Huang <jnhuang95@gmail.com>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>

net: add support to parse the NIS domain for the dhcp options

There is code in the bootp parsing for NIS domain and add the
same support for the dhcp options as well. This allows the same
usage of the data when the dhcp command is used in the boot
command.

Signed-off-by: Charles Hardin <ckhardin@gmail.com>

input: button_kbd: gracefully handle buttons that fail probe

If a button device fails to probe, it will still be added to the uclass
device list, and therefore will still be iterated over in
button_read_keys() resulting in a UAF on the buttons private data.

Resolve this by unbinding button devices that aren't active after
probing, and print a warning so it's clear that the button is broken.

Fixes: e8779962898e ("dm: input: add button_kbd driver")
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

reboot-mode: must depend on CONFIG_DM_RTC

Reading the boot mode from RTC memory requires a real time clock.
Add the missing Kconfig dependency.

Fixes: c74675bd904b ("reboot-mode: read the boot mode from RTC memory")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

configs: am335x_guardian: store boot count in AM3352 RTC block

store bootcount in RTC block scratch register

Signed-off-by: Gireesh Hiremath <Gireesh.Hiremath@in.bosch.com>

Merge tag 'tpm-master-18042024' of https://source.denx.de/u-boot/custodians/u-boot-tpm

Igor says:
"The problem initially was in the TEE sandbox driver implementation
 (drivers/tee/sandbox.c) and it's limitations, which doesn't
 permit to have multiple simultaneous sessions with different TAs.
 This is what actually happened in this CI run [1], firstly "optee_rpmb"
 cmd was executed (and after execution we had one session open), and
 then "scp03", which also makes calls to OP-TEE, however it fails
 in sandbox_tee_open_session() because of this check:

 if (state->ta) {
     printf("A session is already open\n");
     return -EBUSY;
 }

 I had two ways in mind to address that:
 1. Close a session on each optee_rpmb cmd invocation.
 I don't see any reason to keep this session open, as obviously
 there is no other mechanism (tbh, I don't know if DM calls ".remove" for active
 devices) to close it automatically before handing over control to
 Linux kernel. As a result we might end up with some orphaned sessions
 registered in OP-TEE OS core (obvious resource leak).
 2. Extend TEE sandbox driver, add support for multiple
 simultaneous sessions just to handle the case.

 I've chosen the first approach, as IMO it was "kill two birds with one stone",
 I could address resource leak in OP-TEE and bypass limitations of
 TEE sandbox driver."

Link: https://lore.kernel.org/u-boot/CAByghJZVRbnFUwJdgU534tvGA+DX2pArf0i7ySik=BrXgADe3Q@mail.gmail.com/
The CI https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/20414
showed no problems

Merge branch 'for-2024.07' of https://source.denx.de/u-boot/custodians/u-boot-mpc8xx

This pull request adds support for temperature sensors et FPGA loading
on boards from CS GROUP France.

CI: https://source.denx.de/u-boot/custodians/u-boot-mpc8xx/-/pipelines/20416

Revert "Merge patch series "pxe: Allow extlinux booting without CMDLINE enabled""

As reported by Jonas Karlman this series breaks booting on some AArch64
platforms with common use cases. For now the best path forward is to
revert the series.

This reverts commit 777c28460947371ada40868dc994dfe8537d7115, reversing
changes made to ab3453e7b12daef47b9e91da2a2a3d48615dc6fc.

Link: https://lore.kernel.org/u-boot/50dfa3d6-a1ca-4492-a3fc-8d8c56b40b43@kwiboo.se/
Signed-off-by: Tom Rini <trini@konsulko.com>

Merge branch 'master-fdt' of https://source.denx.de/u-boot/custodians/u-boot-sh

board: cssi: Read and display MCR board address

MCR boards are plugged in racks. The position in the rack can be read
in a register.

For MCR3000, that's provided by the FPGA so check it is loaded before
reading the address.

For the other boards, the FPGA is loaded by hardware so it can be
read inconditionnaly.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

board: cssi: Load FPGA on MCR3000 board

Unlike CMPC885 and CMPCPRO boards, the FPGA of MCR3000 board doesn't
load code automatically but needs to be loaded by software through SPI.

Until now it was loaded later by Linux, but we'd like U-boot to have
access to some information that require the FPGA, like board address
in racks.

So, implemented the load of FPGA in U-boot.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
To avoid spamming your email boxes, the code isn't included in
the emailed patch but will be present in the PULL request

board: cssi: Use HAVE_VENDOR_COMMON_LIB logic

Instead of cross using cross-directory makefile directives,
add a Makefile in board/cssi/common/ directory in order to
benefit from HAVE_VENDOR_COMMON_LIB logic.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

spi: mpc8xx: Set up speed as requested

Set the speed requested through mpc8xx_spi_set_speed() instead
of hardcoding a fixed speed.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

spi: mpc8xx: Use 16 bit mode for large transfers with even size

On CPM, the RISC core is a lot more efficiant when doing transfers
in 16-bits chunks than in 8-bits chunks, but unfortunately the
words need to be byte swapped.

So, for large tranfers with an even size, allocate a temporary
buffer and byte-swap data before and after transfer.

This change allows setting higher speed for transfer. For instance
on an MPC 8xx (CPM1 comms RISC processor), the documentation tells
that transfer in byte mode at 1 kbit/s uses 0.200% of CPM load
at 25 MHz while a word transfer at the same speed uses 0.032%
of CPM load. This means the speed can be 6 times higher in
word mode for the same CPM load.

For small transfers, the load reduction is not worth the CPU load
required to allocate the temporary buffer, so do it only when data
size is over 64 bytes.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

spi: mpc8xx: Allow transfer of more than MAX_BUFFER len

Perform multiple transfer of size MAX_BUFFER when the data to be
transferred is longer than MAX_BUFFER.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

powerpc: 8xx: Set SDMA configuration register correcly

SDMA configuration register needs to be set up only once and doesn't
belong to drivers. Also, the value to be used is different on mpc885.

So do the init in cpu_init_f() with 0x40 for mpc885 and 0x1 for others.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

board: cssi: add support for reading temperature

All CSSI boards have an LM74 chip as temperature sensor.

Enable it.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

board: cssi: Add support for SPI bus on MCR3000 board

MCR3000 board has some components tied to the SPI bus, like the Texas
Instruments LM74 temperature sensor.

Add support for SPI bus. The SPI chipselects are a bit special in the
way that they are driven by 3 bits in a register of the board's CPLD
where the value writen in those bits exclusively activates one of the
7 possible chipselects and value 0 sets all chipselets to inactive.

So add a special GPIO driver that simulates GPIOs for those chipselect.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

thermal: Add support for TI LM74

LM74 is a SPI temperature sensor.

Implement a driver to read temperature from it.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

spi: mpc8xx: Fix transfert when input or output buffer is NULL

xfer ops can be passed a NULL input or output buffer. At the
time being the driver ignores it and overwrites memory at 0.

Define a dummy buffer and use it when either input or output
buffer is NULL. Bail out when both are NULL as it shouldn't.

Also increase MAX_BUFFER len to 32k as the current is pretty
low.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

spi: mpc8xx: Add GPIO dependency

Since commit 773ad4ebb1d6 ("spi, mpc8xx: Add support for chipselect via
GPIO and fixups"), DM_GPIO is required for 8xx SPI.

Add the missing dependency to avoid build failures.

Fixes: 773ad4ebb1d6 ("spi, mpc8xx: Add support for chipselect via GPIO and fixups")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

board: cssi: Properly initialise MAC address for fibre on CMPC885 board

CMPC885 board can be pluged on a mother board with fibre interface, so
fibre interface MAC address must be initialised for that case.

Signed-off-by: Hugo Dubois <hugo.dubois.ext@csgroup.eu>
Reviewed-by: CASAUBON Jean Michel <jean-michel.casaubon@csgroup.eu>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>