IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
J721E common processor board has an onboard mux for selecting whether
the OSPI signals are externally routed to OSPI flash or Hyperflash. The
mux state signal input is tied to WKUP_GPIO0_8 and is used by bootloader
for enabling the corresponding node accordingly. Add pinmux for the same.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513123313.11462-5-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J7200 common processor board has an onboard mux for selecting whether
the OSPI signals are externally routed to OSPI flash or Hyperflash. The
mux state signal input is tied to WKUP_GPIO0_6 and is used by bootloader
for enabling the corresponding node accordingly. Add pinmux for the same.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513123313.11462-4-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J721E SoM has a HyperFlash and HyperRam connected to HyperBus memory
controller, add corresponding node, pinmux and partitions for the same.
HyperBus is muxed with OSPI and only one controller can be active at a
time, therefore keep HyperBus node disabled. Bootloader will detect the
external mux state through a wkup gpio and enable the node as required.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513123313.11462-3-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J721E has a Flash SubSystem that has one OSPI and one HyperBus with
muxed datapath and another independent OSPI. Add DT nodes for HyperBus
controller and keep it disabled and model the data path selection mux as a
reg-mux.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513123313.11462-2-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
MDIO nodes defined in the top-level J721e SoC dtsi files are incomplete
and will not be functional unless they are extended with a pinmux.
As the attached PHY is only known about at the board integration level,
these nodes should only be enabled when provided with this information.
Disable the MDIO nodes in the dtsi files and only enable the ones that
are actually pinned out on a given board.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-5-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Mailbox nodes defined in the top-level AM64x SoC dtsi files are incomplete
and may not be functional unless they are extended with a chosen interrupt
and connection to a remote processor.
As the remote processors depend on memory nodes which are only known at
the board integration level, these nodes should only be enabled when
provided with the above information.
Disable the Mailbox nodes in the dtsi files and only enable the ones that
are actually used on a given board.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-4-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
PCIe nodes defined in the top-level J721e SoC dtsi files are incomplete
and will not be functional unless they are extended with a SerDes PHY.
And usually only one of the two modes can be used at a time as they
share a SerDes link.
As the PHY and mode is only known at the board integration level, these
nodes should only be enabled when provided with this information.
Disable the PCIe nodes in the dtsi files and only enable the ones that
are actually pinned out on a given board.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-3-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
These nodes are example nodes for the PCIe controller in "endpoint" mode.
By default the controller is in "root complex" mode and there is already a
DT node for the same.
Examples should go in the bindings or other documentation.
Remove this node.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-2-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Mailbox nodes are now disabled by default. The BeagleBoard AI64 DT
addition went in at around the same time and must have missed that
change so the mailboxes are not re-enabled. Do that here.
Fixes: fae14a1cb8dd ("arm64: dts: ti: Add k3-j721e-beagleboneai64")
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-1-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
eMMC tuning was incomplete earlier, so support for high speed modes was
kept disabled. Remove no-1-8-v property to enable support for high
speed modes for eMMC in J784S4 SoC.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Link: https://lore.kernel.org/r/20230502090814.144791-1-b-kapoor@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J784S4 has two instances of 8 channel ADCs in MCU domain. Add pinmux
information for both ADC nodes.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Link: https://lore.kernel.org/r/20230502081117.21431-3-b-kapoor@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J784S4 has two instances of 8 channel ADCs in MCU domain. Add support
for both ADC nodes.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Link: https://lore.kernel.org/r/20230502081117.21431-2-b-kapoor@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The OLDI-LCD1EVM add on board has Rocktech RK101II01D-CT panel[1] with
integrated touch screen. The integrated touch screen is Goodix GT928.
This panel connects with AM65 GP-EVM[2].
Add DT nodes for these and connect the endpoint nodes with DSS.
[1]: Panel link
https://www.digimax.it/en/tft-lcd/20881-RK101II01D-CT
[2]: AM654 LCD EVM:
https://www.ti.com/tool/TMDSLCD1EVM
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
[abhatia1@ti.com: Make cosmetic and 6.4 kernel DTSO syntax changes]
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230509102354.10116-2-a-bhatia1@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Update the delay values for various speed modes supported, based on
the revised august 2021 J721E Datasheet.
[1] - Table 7-77. MMC0 DLL Delay Mapping for All Timing Modes and
Table 7-86. MMC1/2 DLL Delay Mapping for All Timing Modes, in
https://www.ti.com/lit/ds/symlink/tda4vm.pdf,
(SPRSP36J – FEBRUARY 2019 – REVISED AUGUST 2021)
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Link: https://lore.kernel.org/r/20230424093827.1378602-1-b-kapoor@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Include documentation of the AMC package pin name as well to keep it
consistent with the rest of the pinctrl documentation.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230418213740.153519-5-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
wkup_uart and main_uart1 on this platform is used by tifs and DM
firmwares. Describe them for completeness including the pinmux.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230418213740.153519-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Looks like a couple of http:// links crept in. Use https instead.
While at it, drop unicode encoded character.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230417225450.1182047-1-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Consolidate the arm64 decision making for the page protections used
for executable pages, used by both the trampoline code and the kernel
text mapping code.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://lore.kernel.org/r/E1q9T3v-00EDmW-BH@rmk-PC.armlinux.org.uk
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The am62ax supports a single Voltage and Thermal Management (VTM) device
located in the wakeup domain with three associated temperature monitors
located in various hot spots of the die.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-4-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The am62x supports a single Voltage and Thermal Management (VTM) module
located in the wakeup domain with two associated temperature monitors
located in hot spots of the die.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-3-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The am64x supports a single VTM module which is located in the main
domain with two associated temperature monitors located at different hot
spots on the die.
Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-2-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add memory reservation for the zap-shader and enable the Adreno SMMU,
GPU clock controller, GMU and the GPU nodes for the SC8280XP CRD and the
Lenovo ThinkPad X13s.
Tested-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230614142204.2675653-3-quic_bjorande@quicinc.com
When the use of pointer authentication is enabled in the kernel it
applies to both the kernel itself as well as KVM's nVHE hypervisor. The
same keys are used for both the kernel and the nVHE hypervisor, which is
less than desirable for pKVM as the host is not trusted at runtime.
Naturally, the fix is to use a different set of keys for the hypervisor
when running in protected mode. Have the host generate a new set of keys
for the hypervisor before deprivileging the kernel. While there might be
other sources of random directly available at EL2, this keeps the
implementation simple, and the host is trusted anyways until it is
deprivileged.
Since the host and hypervisor no longer share a set of pointer
authentication keys, start context switching them on the host entry/exit
path exactly as we do for guest entry/exit. There is no need to handle
CPU migration as the nVHE code is not migratable in the first place.
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Link: https://lore.kernel.org/r/20230614122600.2098901-1-smostafa@google.com
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Some of the regulators must be always-on to ensure correct operation of
the system, e.g. PM8916 L2 for the LPDDR RAM, L5 for most digital I/O
and L7 for the CPU PLL (strictly speaking the CPU PLL might only need
an active-only vote but this is not supported for regulators in
mainline currently).
The RPM firmware seems to enforce that internally, these supplies stay
on even if we vote for them to power off (and there is no other
processor running). This means it's pointless to keep sending
enable/disable requests because they will just be ignored.
Also, drivers are much more likely to get a wrong impression of the
regulator status, because regulator_is_enabled() will return false when
there are no users, even though the regulator is always on.
Describe this properly by marking the regulators as always-on.
The same changes was already made for MSM8916 in commit 8bbd35771f90
("arm64: dts: qcom: msm8916-pm8916: Mark always-on regulators").
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-8-a3c3ac833567@gerhold.net
Right now each MSM8939 device has a huge block of regulator constraints
with allowed voltages for each regulator. For lack of better
documentation these voltages are often copied as-is from the vendor
device tree, without much extra thought.
Unfortunately, the voltages in the vendor device trees are often
misleading or even wrong, e.g. because:
- There is a large voltage range allowed and the actual voltage is
only set somewhere hidden in some messy vendor driver. This is often
the case for pm8916_{l14,l15,l16} because they have a broad range of
1.8-3.3V by default.
- The voltage is actually wrong but thanks to the voltage constraints
in the RPM firmware it still ends up applying the correct voltage.
To have proper regulator constraints it is important to review them in
context of the usage. The current setup in the MSM8939 device trees
makes this quite hard because each device duplicates the standard
voltages for components of the SoC and mixes those with minor
device-specific additions and dummy voltages for completely unused
regulators.
The actual usage of the regulators for the SoC components is in
msm8939-pm8916.dtsi, so it can and should also define the related
voltage constraints. These are not board-specific but defined in the
MSM8939/PM8916 specification. There is no documentation available for
MSM8939 but in practice it's almost identical to MSM8916.
Note that this commit does not make any functional change. All used
regulators still have the same regulator constraints as before. Unused
regulators do not have regulator constraints anymore because most of
these were too broad or even entirely wrong. They should be added back
with proper voltage constraints when there is an actual usage.
The same changes were already made for MSM8916 in commit b0a8f16ae4a0
("arm64: dts: qcom: msm8916: Define regulator constraints next to usage").
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-7-a3c3ac833567@gerhold.net
Add the same comment to msm8939-pm8916.dtsi that was added for the
MSM8916 variant in commit f193264986b5 ("arm64: dts: qcom:
msm8916-pm8916: Clarify purpose").
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-6-a3c3ac833567@gerhold.net
The regulator constraints for the MSM8939 devices were originally taken
from Qualcomm's msm-3.10 vendor device tree (for lack of better
documentation). Unfortunately it turns out that Qualcomm's voltages are
slightly off as well and do not match the voltage constraints applied
by the RPM firmware.
This means that we sometimes request a specific voltage but the RPM
firmware actually applies a much lower or higher voltage. This is
particularly critical for pm8916_l11 which is used as SD card VMMC
regulator: The SD card can choose a voltage from the current range of
1.8 - 2.95V. If it chooses to run at 1.8V we pretend that this is fine
but the RPM firmware will still silently end up configuring 2.95V.
This can be easily reproduced with a multimeter or by checking the
SPMI hardware registers of the regulator.
Apply the same change as for MSM8916 in commit 355750828c55 ("arm64:
dts: qcom: msm8916: Fix regulator constraints") and make the voltages
match the actual "specified range" in the PM8916 Device Specification
which is enforced by the RPM firmware.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-5-a3c3ac833567@gerhold.net
The vendor kernel from Sony does not have regulator-always-on for
pm8916_l6, so we should be able to disable it when setting up the
display properly. Since sony-tulip does not have display set up
currently it should be fine to let the regulator disable until then.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-4-a3c3ac833567@gerhold.net
Update for recent changes to msm8916.dtsi in commit a5cf21b14666
("arm64: dts: qcom: msm8916: Disable audio codecs by default") and
make lpass_codec disabled by default for devices that are not using
the audio codec functionality inside MSM8939.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-2-a3c3ac833567@gerhold.net
Update for recent changes to pm8916.dtsi in commit 38218822a72f
("arm64: dts: qcom: pm8916: Move default regulator "-supply"s")
and add the now missing pm8916_codec supplies to msm8939-pm8916.dtsi
as well.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-1-a3c3ac833567@gerhold.net
This converts TRBIDR_EL1 register to automatic generation without
causing any functional change.
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230614065949.146187-15-anshuman.khandual@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This converts TRBTRG_EL1 register to automatic generation without
causing any functional change.
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230614065949.146187-14-anshuman.khandual@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This converts TRBMAR_EL1 register to automatic generation without
causing any functional change.
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230614065949.146187-13-anshuman.khandual@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This converts TRBSR_EL1 register to automatic generation without
causing any functional change.
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230614065949.146187-12-anshuman.khandual@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This converts TRBBASER_EL1 register to automatic generation without
causing any functional change.
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230614065949.146187-11-anshuman.khandual@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This converts TRBPTR_EL1 register to automatic generation without
causing any functional change.
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230614065949.146187-10-anshuman.khandual@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This converts TRBLIMITR_EL1 register to automatic generation without
causing any functional change.
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230614065949.146187-9-anshuman.khandual@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
