As the return type is "int" for find_ram_top() function and
returning the "base" which is of phys_addr_t is breaking when the
"base" address is 64-bit. So fix this by updating the return type as
phys_addr_t.

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Link: https://lore.kernel.org/r/20241220030742.1745984-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>

As the "peer-hub" property is optional, don't error out just
skip the bind function.

Fixes: 57e30b09fc ("usb: onboard-hub: Bail out if peer hub is already probed")
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>

Patch resolves two kind of bugs, one of which is vulnerability related
to KASLR.

=== Issue briefly ===

  Working with FDT (via non-relocated gd::fdt_blob) from inside bootm
command may lead to the reading the garbage instead of FDT nodes. And
this can result in various side-effects depending on DTS nodes, being
parsed during bootm.

  But below is my specific story how I faced with this issue due to
MESON_RNG probing failure.

=== Bugs description ===

1) Bug is revealed on:
* configuration below
* U-boot 2024.10 - f919c3a889f ("Prepare v2024.10")

  It seems, the following patch is a trigger:
ea955eea4f ("fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled")

  Generally, CONFIG_OF_EMBED=y & CONFIG_RNG_MESON=y are the most
valuable ones for reproducing the issue.
```
  CONFIG_ARCH_FIXUP_FDT_MEMORY=y
  CONFIG_CMD_FDT=y
  CONFIG_DEFAULT_FDT_FILE=""
  CONFIG_FDT_64BIT=y
  CONFIG_OF_BOARD_SETUP=y
  CONFIG_OF_CONTROL=y
  CONFIG_OF_EMBED=y
  CONFIG_OF_LIBFDT_ASSUME_MASK=0x0
  CONFIG_OF_LIBFDT_OVERLAY=y
  CONFIG_OF_LIBFDT=y
  CONFIG_OF_LIST="meson-axg-our-device-name"
  CONFIG_OF_REAL=y
  CONFIG_OF_TRANSLATE=y
  CONFIG_SUPPORT_OF_CONTROL=y
  CONFIG_SYS_FDT_PAD=0x3000
  CONFIG_TOOLS_OF_LIBFDT=y

  CONFIG_DM_RNG=y
  CONFIG_RNG_MESON=y
```

2) Due to CONFIG_OF_EMBED, the DTS is embedded into U-boot ELF and
accessible via __dtb_dt_begin symbol.

  On early boot stage (board_f.c) the fdtdec_setup() is called only
once before U-boot's relocation into top of RAM. fdtdec_setup()
initializes gd::fdt_blob for FDTSRC_EMBED case:
```
  gd->fdt_blob = dtb_dt_embedded();
  gd->fdt_src = FDTSRC_EMBED;
```

3) Then reloc_fdt() is called in board_f.c

  But due to CONFIG_OF_EMBED=y the reloc_fdt() does not update
gd::fdt_blob value (strictly speaking, it is impossible for
CONFIG_OF_EMBED=y, because U-boot ELF has not been relocated yet
at this moment).

  As a result after relocation we get fdt_blob, pointing to DTS address
before relocation:
```
   # bdinfo
  <...>
  relocaddr = 0x000000000fedf000
  reloc off = 0x000000000eedf000
  <...>
  fdt_blob = 0x010ce6c0 << points to __dtb_dt_begin before relocation
  new_fdt = 0x0000000000000000  << empty erroneously
  fdt_size = 0x0000000000000000 << zero erroneously
```

4) During bootm command (according to our ITS-config file) the Linux
is loaded into 0x01080000 (which is very close to fdt_blob addr
0x010ce6c0).
```
  ## Loading kernel from FIT Image at 04000000 ...
     Trying 'kernel' kernel subimage
       <...>
       Load Address: 0x01080000
```

  So Linux image overwrites the gd::fdt_blob memory location
in RAM (0x010ce6c0).

5) Issue:

  Hence any manipulation with DTS (say, via FDT API) inside
implementation of bootm command leads to accessing the fdt_blob area
with garbage, that can lead to two situations:

5.1) Abort.

  Call to fdt_off_dt_struct() from fdt_next_tag() :: fdt_offset_ptr()::
fdt_offset_ptr_() returns with garbage, that leads to tagp value
being out of RAM top addr (256 Mb in our board), causing the abort:
```
  Boot cmd: bootm 0x4000000#boot_evt1
  bootm_run_states()
  <...>
  image_setup_libfdt()
   fdt_chosen()
    fdt_kaslrseed()
     uclass_get_device()
      uclass_get_device_tail()
       device_probe()
        device_of_to_plat()
        meson_rng_of_to_plat()
         clk_get_by_name_optional()
          clk_get_by_name()
           clk_get_by_name_nodev()
            ofnode_stringlist_search()
             fdt_stringlist_search()
              fdt_getprop()
               fdt_get_property_namelen_()
                fdt_first_property_offset()
                 fdt_check_node_offset_()
                  fdt_next_tag():
                    ```
                      tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
                    ```
                  fdt_next_tag() tagp:0x22890766
                  fdt_next_tag() ram_top:0x10000000 (tagp OUT of RAM)
  "Synchronous Abort" handler, esr 0x96000010, far 0x22890766
  elr: 000000000108be24 lr : 000000000108be24 (reloc)
  elr: 000000000ff6fe24 lr : 000000000ff6fe24
  x0 : 0000000000000041 x1 : 0000000000000000
  x2 : 000000000ff3b57c x3 : 0000000000000012
  x4 : 000000000ded2ad5 x5 : 0000000000000020
  x6 : 00000000ffffffe8 x7 : 000000000ded2f40
  x8 : 00000000ffffffd8 x9 : 000000000000000d
  x10: 0000000000000006 x11: 000000000001869f
  x12: 000000000fffffff x13: 000000000fffffff
  x14: 0000000000000000 x15: 000000000ded2abb
  x16: 000000000ff3b080 x17: 0000000000000001
  x18: 000000000ded3dc0 x19: 0000000022890766
  x20: 00000000010cb0f0 x21: 00000000000015e4
  x22: 000000000ff8f4d8 x23: 000000000000000b
  x24: 000000000ded2fbc x25: 000000000ffe2000
  x22: 000000000ff8f4d8 x23: 000000000000000b
  x24: 000000000ded2fbc x25: 000000000ffe2000
  x26: 000000000ffe2000 x27: 000000000000000b
  x28: 000000000ff9cf2d x29: 000000000ded2f40

  Code: aa1603e1 91197484 52801742 94004de8 (b9400276)
```

5.2) Vulnerability situation "KASLR is disabled".

Almost the same as in (5.1), but 2 situations happen (depending on
the value of garbage):
  * call to fdt_offset_ptr_() :: fdt_off_dt_struct(fdt)
    returns not so big garbage, leading to tagp, being inside RAM.
  * or calculations of absoffset inside fdt_offset_ptr() leads to
    failure of the one of if() conditions with NULL as retval.

  Result is fdt_next_tag() interprets the tagp as FDT_END. And we are
returning from our callstack via functions' error paths, leading to
"No RNG device" and "KASLR disabled due to lack of seed":
```
  fdt_kaslrseed()
   uclass_get_device()
   <...>
    device_probe()
     device_of_to_plat()
      meson_rng_of_to_plat()
       clk_get_by_name()
        clk_get_by_name_nodev()
        <...>
         fdt_stringlist_search()
          fdt_getprop()
           fdt_get_property_namelen_()
            fdt_first_property_offset()
             fdt_check_node_offset_()
              fdt_next_tag():
                ```
                  tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
                ```
              fdt_next_tag() tagp:0000000001890677
              fdt_next_tag() ram_top:0x10000000 (tagp is inside RAM)
      uclass_get_device_tail():486 device_probe() ret:-22
  No RNG device
 Starting kernel ...

  [ 0.000000] Linux version 6.9.12
  [ 0.000000] KASLR disabled due to lack of seed
```

Signed-off-by: Evgeny Bachinin <EABachinin@salutedevices.com>

This breaks chromebook_coral which says:

   Video: No video mode configured in FSP!

This reverts commit 2e9313179a846b581c0fc3f6a49e19f3d343efa8.

Signed-off-by: Simon Glass <sjg@chromium.org>

If BIOSEMU is compiled for RISC-V (SiFive Unmatched board) and the function
dm_pci_run_vga_bios() is executed, U-Boot stops with error message saying
that the SPL malloc pool is too small. So increase the default pool size
when both BIOSEMU and RISCV parameters are set.

Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

The .bind function is implemented to bind the correct
"half" of the hub that the driver wants to bind,
and returning -ENODEV for the other "half".

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Marek Vasut <marex@denx.de>

Add i2c initialization hook and set usb5744 platform
data with function having required i2c initialization sequence.

Apart from the USB command attach, prevent the hub from suspend.
when the “USB Attach with SMBUS (0xAA56)” command is issued to the hub,
the hub is getting enumerated and then it puts in a suspend mode.
This causes the hub to NAK any SMBUS access made by the SMBUS Master
during this period and not able to see the hub's slave address while
running the "i2c probe" command.

Prevent the MCU from the putting the HUB in suspend mode through register
write. The BYPASS_UDC_SUSPEND bit (Bit 3) of the RuntimeFlags2 register at
address 0x411D controls this aspect of the hub. The BYPASS_UDC_SUSPEND
bit in register 0x411Dh must be set to ensure that the MCU is always
enabled and ready to respond to SMBus runtime commands. This register
needs to be written before the USB attach command is issued.
The byte sequence is as follows:
Slave addr: 0x2d           00 00 05 00 01 41 1D 08
Slave addr: 0x2d           99 37 00
Slave addr: 0x2d           AA 56 00

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Marek Vasut <marex@denx.de>

Add support for the Microchip USB5744 USB3.0 and USB2.0 Hub.
The usb5744 driver trigger hub reset signal after soft reset.
The usb5744 hub need to reset after the phy initialization,
which toggles the gpio.

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Marek Vasut <marex@denx.de>

Don't error out if there is no vdd regulator supply, as these are
optional properties.

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Marek Vasut <marex@denx.de>

As part of the reset, sets the direction of the pin to output before
toggling the pin. Delay of millisecond is added in between low and
high to meet the setup and hold time requirement of the reset.
Update the usb2514 hub_data with the reset delay and power on
delay values.

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Marek Vasut <marex@denx.de>