The definition of our ID table is guarded with OF_REAL however the
U_BOOT_DRIVER that would in turn use the table is guarded with
SERIAL_PRESENT. To avoid a potential warning we must also guard the
ID table with SERIAL_PRESENT.

Signed-off-by: Tom Rini <trini@konsulko.com>

Fix compiler warning:

drivers/serial/ns16550.c: In function ‘serial_in_dynamic’:
drivers/serial/ns16550.c:153:1: warning: control reaches end
    of non-void function [-Wreturn-type]
  153 | }
      | ^

Observed with gcc 15.2.1:

$ riscv64-unknown-linux-gnu-gcc --version
riscv64-unknown-linux-gnu-gcc (Gentoo 15.2.1_p20260214 p5) 15.2.1

Fixes: 62cbde4c4e46 ("serial: ns16550: Support run-time configuration")
Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
Reviewed-by: Tom Rini <trini@konsulko.com>

Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.

Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards
Acked-by: Yao Zi <me@ziyao.cc> #TH1520
Signed-off-by: Peng Fan <peng.fan@nxp.com>

The lone user of this driver has been removed for some time. Remove this
driver as well.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20250227205101.4127604-2-trini@konsulko.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

serial_out_dynamic() takes a u8* addr and uses it for 8-bit or 32-bit
accesses, depending on the value of plat->reg_width. This results in a
pointer type mismatch that the compiler may even turn into an error:

drivers/serial/ns16550.c: In function ‘serial_out_dynamic’:
drivers/serial/ns16550.c:115:42: error: passing argument 1 of ‘out_be32’ from incompatible pointer type [-Wincompatible-pointer-types]
  115 |                                 out_be32(addr, value);
      |                                          ^~~~
      |                                          |
      |                                          u8 * {aka unsigned char *}

This error was observed on PowerPC.

Signed-off-by: J. Neuschäfer <j.ne@posteo.net>

Add compatible string for the Intel XScale variant of the 16550. Needed
to match upstream.

Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Reviewed-by: Stefan Roese <sr@denx.de>

UPL needs to pass the serial details onto the next stage, so adjust the
condition to support this.

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

Increase scope of ops functions and do some clean up for usage in device
-specific UART drivers.

Remove the static functionality of ops functions and migrate certain macros
to header file for usage in device-specific drivers.

Signed-off-by: Gokul Praveen <g-praveen@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Simon Glass <sjg@chromium.org> says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.

Use the new symbol to refer to any 'SPL' build, including TPL and VPL

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