strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
After the discussion here:
https://lore.kernel.org/netdev/20210603143453.if7hgifupx5k433b@pali/
which resulted in this patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20210704134325.24842-1-pali@kernel.org/
and many other discussions before it, notably:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1512016235-15909-1-git-send-email-Bhaskar.Upadhaya@nxp.com/
it became apparent that nobody really knows what "SGMII 2500" is.
Certainly, Freescale/NXP hardware engineers name this protocol
"SGMII 2500" in the reference manuals, but the PCS devices do not
support any "SGMII" specific features when operating at the speed of
2500 Mbps, no in-band autoneg and no speed change via symbol replication
. So that leaves a fixed speed of 2500 Mbps using a coding of 8b/10b
with a SERDES lane frequency of 3.125 GHz. In fact, "SGMII 2500 without
in-band autoneg and at a fixed speed" is indistinguishable from
"2500base-x without in-band autoneg", which is precisely what these NXP
devices support.
So it just appears that "SGMII 2500" is an unclear name with no clear
definition that stuck.
As such, in the Linux kernel, the drivers which use this SERDES protocol
use the 2500base-x phy-mode.
This patch converts U-Boot to use 2500base-x too, or at least, as much
as it can.
Note that I would have really liked to delete PHY_INTERFACE_MODE_SGMII_2500
completely, but the mvpp2 driver seems to even distinguish between SGMII
2500 and 2500base-X. Namely, it enables in-band autoneg for one but not
the other, and forces flow control for one but not the other. This goes
back to the idea that maybe 2500base-X is a fiber protocol and SGMII-2500
is an MII protocol (connects a MAC to a PHY such as Aquantia), but the
two are practically indistinguishable through everything except use case.
NXP devices can support both use cases through an identical configuration,
for example RX flow control can be unconditionally enabled in order to
support rate adaptation performed by an Aquantia PHY. At least I can
find no indication in online documents published by Cisco which would
point towards "SGMII-2500" being an actual standard with an actual
definition, so I cannot say "yes, NXP devices support it".
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
NXP Legal insists that the following are not fine:
- Saying "NXP Semiconductors" instead of "NXP", since the company's
registered name is "NXP"
- Putting a "(c)" sign in the copyright string
- Putting a comma in the copyright string
The only accepted copyright string format is "Copyright <year-range> NXP".
This patch changes the copyright headers in the networking files that
were sent by me, or derived from code sent by me.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
The USB peripheral controller is the DWC2 controller 1, not 0.
Update the phandle to fix UDC support on this board.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Siew Chin Lim <elly.siew.chin.lim@intel.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The WDT on this system should be enabled, make it so.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Siew Chin Lim <elly.siew.chin.lim@intel.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
On Intel Tangier the SDHCI #2 provides SD card connection.
Add GPIO card detection for it.
Fixes: 39665beed6 ("x86: tangier: Enable ACPI support for Intel Tangier")
BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
eMMC is non-removable on Intel Edison board. Fix the DTS accordingly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Continue to use the "ssbl" name for GPT partition of secondary boot
stage = U-Boot for basic boot with SPL to avoid to disturb existing user.
The "fip" partition name is only used for TFA_BOOT with FIP, it is a TF-A
BL2 requirement; it the default configuration for STMicroelectronics
boards.
Fixes: b73e8bf453 ("arm: stm32mp: add defconfig for trusted boot with FIP")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
With Device Manager firmware in an elf file form, we cannot load the FIT
image to the exact same address as any of the executable sections of the
elf file itself is located.
However, the device tree descriptions for the ARMV8 bootloader/OS
includes DDR regions only the final sections in DDR where the Device
Manager firmware is actually executing out of.
As the R5 uC is usually operating at a slower rate than an ARMv8 MPU,
by starting the Armv8 ahead of parsing the elf and copying the correct
sections to the required memories creates a race condition where the
ARMv8 could overwrite the elf image loaded from the FIT image prior to
the R5 completing parsing and putting the correct sections of elf in
the required memory locations. OR create rather obscure debug conditions
where data in the section is being modified by ARMV8 OS while the elf
copy is in progress.
To prevent all these conditions, lets make sure that the elf parse and
copy operations are completed ahead of ARMv8 being released to execute.
We will pay a penalty of elf copy time, but that is a valid tradeoff in
comparison to debug of alternate scenarios.
Signed-off-by: Nishanth Menon <nm@ti.com>
NB0 is bridge to SRAM and NB1 is bridge to DDR.
To ensure that SRAM transfers are not stalled due to delays during DDR
refreshes, SRAM traffic should be higher priority (threadmap=2) than
DDR traffic (threadmap=0).
This fixup is critical to provide deterministic access latency to
MSMC from ICSSG, it applies to all AM65 silicon revisions and is due
to incorrect reset values (has no erratum id) and statically setting
things up should be done independent of usecases and board.
This specific style of Northbridge configuration is specific only to
AM65x devices, follow-on K3 devices have different data prioritization
schemes (ASEL and the like) and hence the fixup applies purely to
AM65x.
Without this fix, ICSSG TX lock-ups due to delays in MSMC transfers in
case of SR1 devices, on SR2 devices, lockups were not observed so far
but high retry rates of ICSSG Ethernet (icssg-eth) and, thus, lower
throughput.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
[Jan: rebased, dropped used define, extended commit log]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
[Nishanth: Provide relevant context in the commit message]
Signed-off-by: Nishanth Menon<nm@ti.com>
The K3 SoCs have some PLL output clocks (POSTDIV clocks) which in
turn serve as inputs to other HSDIV output clocks. These clocks use
the actual value to compute the divider clock rate, and need to be
registered with the CLK_DIVIDER_ONE_BASED flags. The current k3-clk
driver and data lacks the infrastructure to pass in divider flags.
Update the driver and data to account for these divider flags.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Add a note to the automatically generated clk-data and dev-data files
for j721e and j7200 to indicate that they are in fact auto-generated and
should not be hand edited.
Also adjust TI URL to use https instead of http and also add an empty
line before first header inclusion.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2
divisors to generate the final FOUTPOSTDIV clock. These are in sequence
with POSTDIV2 following the POSTDIV1 clock. The current J7200 clock data
has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is
opposite of the actual implementation. Fix the data by simply adjusting
the register bit-shifts.
The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0
register values, fix these as well.
Fixes: 277729eaf3 ("arm: mach-k3: Add platform data for j721e and j7200")
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2
divisors to generate the final FOUTPOSTDIV clock. These are in sequence
with POSTDIV2 following the POSTDIV1 clock. The current J721E clock data
has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is
opposite of the actual implementation. Fix the data by simply adjusting
the register bit-shifts.
The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0
register values, fix these as well.
Fixes: 277729eaf3 ("arm: mach-k3: Add platform data for j721e and j7200")
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Add a weak release_resources_for_core_shutdown() stub implementation
that can be overridden by actual implementation if a SoC supports that
function.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Move the XHCI PCI device base up in the virtual address space. This fixes
initialization failure observed with newer Raspberry Pi firmware, later
than 63b1922311 ("firmware: arm_loader: Update armstubs with those from
PR 117). It looks that chosing 0xff800000 as the XHCI PCI device base
conflicts with the updated ARM/VideoCore firmware.
This also requires to reduce the size of the mapped PCI device region
from 8MiB to 4MiB to fit into 32bit address space. This is still enough
for the XHCI PCI device.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Tested-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
At present SMBIOS tables are empty, which breaks some use-cases that
rely on that. Add some minimal information to fulfill this.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
This board has not been converted to CONFIG_DM_PCI by the deadline.
Remove it.
Note that we have to add CONFIG_SPIFLASH to scripts/config_whitelist.txt
because it's not really migrated at this point.
Acked-by: Michael Durrant <mdurrant@arcturusnetworks.com>
Acked-by: Oleksandr Zhadan <oleks@arcturusnetworks.com>
Acked-by: Oleksandr Zhadan and Michael Durrant <arcsupport@arcturusnetworks.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Handle CONFIG_SPIFLASH differently and delete Kconfig file]
Signed-off-by: Tom Rini <trini@konsulko.com>
In the cdns3 usb driver, the clock name looked for is ref. Therefore, fix
the clock-names property in usb0 instance for proper initialization of
cdns3 usb gadget driver.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
As per Device Tree Specification [1], the status parameter of nodes can
be "okay", "disabled", etc. "ok" is not a valid parameter.
U-boot Driver Model does not recognize status="ok" either and treats
the node as disabled.
[1] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Add u-boot,dm-spl tag in the pinmux device tree node, required for MMCSD1
subsystem.
Fixes: b6059ddc45 ("arm: dts: k3-am642: Add r5 specific dt support")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
USB nodes were mistakenly disabled in
commit 942853dd96 ("arm: dts: Resync BeagleBone device trees")
This commit is to fix the following issue:
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
No working controllers found
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0782e8572ce43f521ed6ff15e4a7ab9aa5acdc85
Fixes: 942853dd96 ("arm: dts: Resync BeagleBone device trees")
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Reviewed-by: Paul Barker <paul.barker@sancloud.com>
Since mvpp2 is using the new mdio driver and the cp110 has been
synced with the linux upstream, the mdio has to enabled in the
device tree file.
This is missing for some device tree files and therefore the
network cards do not come online.
Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
Reviewed-by: Stefan Roese <sr@denx.de>
SHA512_ALGO was used as a "either SHA512 or SHA384", although the
implementations of these two algorithms share a majority of code.
From a Kconfig interface perspective, it makes sense to present two
distinct options. This requires #ifdefing out the SHA512
implementation from sha512.c. The latter doesn't make any sense.
It's reasonable to say in Kconfig that SHA384 depends on SHA512, and
seems to be the more polite way to handle the selection.
Thus, automatically select SHA512 when SHA384 is enabled.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We usually use a space in function declaration, rather than a tab.
Signed-off-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
Invokes the common cache_init function to initialize ccache.
Signed-off-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
The enable_caches is a generic hook for architecture-implemented, we
define this function to enable composable cache of sifive platforms.
In sifive_cache, it invokes the generic cache_enable interface of cache
uclass to execute the relative implementation in SiFive ccache driver.
Signed-off-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Rick Chen <rick@andestech.com>
The enable_caches is a generic hook for architecture-implemented, we
leverage this function to enable caches for RISC-V
Signed-off-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Rick Chen <rick@andestech.com>
To make analyzing exceptions easier output the code that leads to it.
We already do the same on the ARM platform.
Here is an example:
=> exception ebreak
Unhandled exception: Breakpoint
EPC: 000000008ff5d50e RA: 000000008ff5d62c TVAL: 0000000000000000
EPC: 000000008020b50e RA: 000000008020b62c reloc adjusted
Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)
To disassemble the code we can use the decodecode script:
$ echo 'Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)' | \
CROSS_COMPILE=riscv64-linux-gnu- scripts/decodecode
Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)
All code
========
0: 2785 addiw a5,a5,1
2: 07a00693 li a3,122
6: fef6dce3 bge a3,a5,0xfffffffffffffffe
a: 47a5 li a5,9
c: 00e7d563 bge a5,a4,0x16
10:* 9002 ebreak <-- trapping instruction
...
Code starting with the faulting instruction
===========================================
0: 9002 ebreak
...
As it is not always clear if the first 16 bits are at the start or in the
middle of a 32bit instruction it may become necessary to strip the first
u16 from the output before calling decodecode to get the correct
disassembled code.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
When booting in EFI, lib/efi_loader/efi_memory.c calls
board_get_usable_ram_top(0) which returns by default
gd->ram_base + gd->ram_size which is the top of DDR.
In case of OPTEE boot, the top of DDR is currently reserved by OPTEE,
board_get_usable_ram_top(0) must return an address outside OPTEE
reserved memory.
gd->ram_top matches this constraint as it has already been initialized
by substracting all DT reserved-memory (included OPTEE memory area).
Fixes: 92b611e8b0 ("stm32mp: correctly handle board_get_usable_ram_top(0)")
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Move the function get_boot_device() from spl.c to cpu.c.
Make it visible, so that it may be used from other files.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
File mach/soc.h is included also in 64-bit mvebu processors, so define
Armada XP related macros only when compiling for Armada XP.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
xilinx:
- Disable CONFIG_ARCH_FIXUP_FDT_MEMORY
- Print information about cpu via soc drivers and enable DISPLAY_CPUINFO
- Wire infrastructure for DTB_RESELECT and MULTI_DTB_FIT
zynq:
- Wire single QSPI
- Use power-source instead of io-standard properties
- Enable nor on zc770-xm012
zynqmp:
- Change handling around multi_boot()
- Setup offset for u-boot.itb in spi
- Generate run time dfu_alt_info for capsule update
- Use explicit values for enums (zynqmp_firmware.h)
- Enable RTC/SHA1/BUTTON/BUTTON_GPIO command
- Disable WDT driver by default
- Bind usb/scsi via preboot because of EFI
- DT updates/fixes
- Add soc driver
- Fix SPL SPI boot mode
versal:
- Add soc driver
sdhci:
- Update tap delay programming for zynq_sdhci driver
cmd:
- Fix RTC uclass handling in date command
- Update pwm help message
- Update reset help message
watchdog:
- Fix wwdt compilation
rtc:
- Deal with seq alias in rtc uclass
- Add zynqmp RTC driver
fdt:
- Add kernel-doc for fdt_fixup_memory_banks()
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQbPNTMvXmYlBPRwx7KSWXLKUoMIQUCYSilpgAKCRDKSWXLKUoM
Id2JAJ9jY19JiEpOd3vuRCT5CE/pzX4yDACeP8DiXDzSi5tLHwDWUCBobUTze2s=
=5lnj
-----END PGP SIGNATURE-----
Merge tag 'xilinx-for-v2021.10-rc3' of https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze
Xilinx changes for v2021.10-rc3
xilinx:
- Disable CONFIG_ARCH_FIXUP_FDT_MEMORY
- Print information about cpu via soc drivers and enable DISPLAY_CPUINFO
- Wire infrastructure for DTB_RESELECT and MULTI_DTB_FIT
zynq:
- Wire single QSPI
- Use power-source instead of io-standard properties
- Enable nor on zc770-xm012
zynqmp:
- Change handling around multi_boot()
- Setup offset for u-boot.itb in spi
- Generate run time dfu_alt_info for capsule update
- Use explicit values for enums (zynqmp_firmware.h)
- Enable RTC/SHA1/BUTTON/BUTTON_GPIO command
- Disable WDT driver by default
- Bind usb/scsi via preboot because of EFI
- DT updates/fixes
- Add soc driver
- Fix SPL SPI boot mode
versal:
- Add soc driver
sdhci:
- Update tap delay programming for zynq_sdhci driver
cmd:
- Fix RTC uclass handling in date command
- Update pwm help message
- Update reset help message
watchdog:
- Fix wwdt compilation
rtc:
- Deal with seq alias in rtc uclass
- Add zynqmp RTC driver
fdt:
- Add kernel-doc for fdt_fixup_memory_banks()
Use TF-A instead of ATF in description. And update generic description with
removing ATF because also configurations without it are supported.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
U-Boot support board detection at run time and based on it change DT.
This feature is implemented for SOM Kria platforms which contain two
eeproms which contain information about SOM module and CC (Carrier card).
Full U-Boot starts with minimal DT file defined by
CONFIG_DEFAULT_DEVICE_TREE which is available in multi DTB fit image.
It is using default setup of board_name variable initializaed to
DEVICE_TREE which corresponds to CONFIG_DEFAULT_DEVICE_TREE option.
When DTB_RESELECT is enabled board_detection() is called. Keep it your mind
that this code is called before relocation. board_detection() is calling
xilinx_read_eeprom() which fills board_info (xilinx_board_description)
structure which are parsed in board_name_decode().
Based on DT configuration and amount of nvmemX aliases name of the board is
composed by concatenating CONFIG_SYS_BOARD "-" <board_name> "-rev"
<board_revision> "-" <cc_name> "-rev" <cc_revision>.
If CC is not present or more are available it keeps going.
When board name is composed and returned from board_name_decode() it is
assigned to board_name variable which is used by
board_fit_config_name_match() which is called via fdtdec_setup() when it
goes over config options in multi dtb FIT image.
From practical point of view multi DTB image is key point here which has to
contain configs for detected combinations. Unfortunately as of now they
have to be full DTBs and DTBOs are not supported.
That's why configuration like:
config_X {
description = "zynqmp-board-cc";
fdt = "board", "cc";
};
needs to be squashed together with:
fdtoverlay -o zynqmp-board-cc -i arch/arm/dts/zynqmp-board.dtb \
arch/arm/dts/zynqmp-cc.dtbo
and only one dtb is in fit:
config_X {
description = "zynqmp-board-cc";
fdt = "board-cc";
};
For creating multi DTBs fit image use mkimage -E, e.g.:
mkimage -E -f all.its all.dtb
When DTB_RESELECT is enabled xilinx_read_eeprom() is called before
relocation and it uses calloc for getting a buffer. Because this is dynamic
memory it is not relocated that's why xilinx_read_eeprom() is called again
as the part of board_init(). This second read with calloc buffer placed in
proper position board_late_init_xilinx() can setup u-boot variables as
before.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
When MULTI_DTB_FIT is enabled fit-dtb.blob fit image is created which
contain all DTBs listed by CONFIG_OF_LIST. And with DTB_RELESELECT there is
a need to handle it as one file with DTBs in it not as separate DTBs in
u-boot.its/itb.
That's why extend mkimage_fit_atf.sh to generate u-boot.itb correctly.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Start of DTB should be 64bit aligned that's why also make sure that end is
also 64bit aligned. It is not required but it is nice thing to do.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
soc_xilinx_versal driver allows identification of family & revision
of versal SoC. This driver is selected by CONFIG_SOC_XILINX_VERSAL.
Probe this driver using platdata U_BOOT_DEVICE structure which is
defined at mach-versal/cpu.c.
Add this config to xilinx_versal_virt_defconfig &
xilinx_versal_mini_ospi_defconfig file to select this driver.
Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com>
Reviewed-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
soc_xilinx_zynqmp driver allows identification of family & revision
of zynqmp SoC. This driver is selected by CONFIG_SOC_XILINX_ZYNQMP.
Add this config to xilinx_zynqmp_virt_defconfig file.
Probe this driver using platdata U_BOOT_DEVICE structure which is
specified in mach-zynqmp/cpu.c.
Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com>
Reviewed-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Replace 'io-standard' property with 'power-source' property in all
zynq dts files to be in sync with Zynq Pinctrl driver.
Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
