Add support for the PCIe QMP PHY on the SM8550,
SM8650 and x1e80100 SoCs.

The driver is based on the Linux phy/qualcomm/phy-qcom-qmp-pcie.c
driver and adapted to U-Boot.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20241125-topic-pcie-phy-v1-1-bf08811d0a07@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

Copy PHY tables over from Linux to support SA8775.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tag/?h=v6.13-rc6

Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Link: https://lore.kernel.org/r/20250110050817.3819282-5-quic_varada@quicinc.com
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

Prepare v2025.01-rc5

In generic_phy_get_bulk(), if 'phys' property is absent in
the device node then it is not an error condition.

Change print message verbosity to debug to avoid spamming
console in such cases.

Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>

The correct spelling is R-Car, including the dash, update the usage.
Comment changes only, no functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Copy PHY tables over from Linux to support SM8150

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Add configuration for the SC7280, copied from Linux 6.11

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

The ufsphy_v2_regs_layout is not used, drop it and fix:
phy-qcom-qmp-ufs.c:87:27: warning: ‘ufsphy_v2_regs_layout’ defined but not used [-Wunused-const-variable=]

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.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 XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.

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