Bin Meng [Mon, 15 Oct 2018 09:21:13 +0000 (02:21 -0700)]
riscv: qemu: Enumerate virtio bus during early boot
Currently devices on the virtio bus is not automatically enumerated,
which means peripherals on the virtio bus are not discovered by their
drivers. This uses board_init() to do the virtio enumeration.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 15 Oct 2018 09:21:07 +0000 (02:21 -0700)]
blk: Call part_init() in the post_probe() method
part_init() is currently called in every DM BLK driver, either
in its bind() or probe() method. However we can use the BLK
uclass driver's post_probe() method to do it automatically.
Update all DM BLK drivers to adopt this change.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 15 Oct 2018 09:21:06 +0000 (02:21 -0700)]
efi_driver: blk: Switch to use platdata_auto_alloc_size for the driver data
Currently the efi block driver uses priv_auto_alloc_size for the
driver data, however that's only available after the device probe
phase. In order to make it accessible in an earlier phase, switch
to use platdata_auto_alloc_size instead.
This patch is the prerequisite for the follow up patch of DM BLK
driver changes to work with EFI loader.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 15 Oct 2018 09:21:05 +0000 (02:21 -0700)]
sandbox: blk: Switch to use platdata_auto_alloc_size for the driver data
Currently the sandbox block driver uses priv_auto_alloc_size for
the driver data, however that's only available after the device
probe phase. In order to make it accessible in an earlier phase,
switch to use platdata_auto_alloc_size instead.
This patch is the prerequisite for the follow up patch of DM BLK
driver changes to work with Sandbox.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 15 Oct 2018 09:21:04 +0000 (02:21 -0700)]
test: dm: blk: Correct blk_base test case
The blk_base test case creates a USB mass storage block device with
the Sandbox host block device as its parent. This does not make any
sense and causes potential issue, for example if the test case tries
to read/write anything on the USB mass storage block device it will
definitely fail as its parent is not on USB bus at all.
Correct the test case by creating another Sandbox host block device
instead of the USB mass storage one and adjust the case accordingly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 15 Oct 2018 09:21:02 +0000 (02:21 -0700)]
virtio: Add virtio over mmio transport driver
VirtIO can use various different buses and virtio devices are
commonly implemented as PCI devices. But virtual environments
without PCI support (a common situation in embedded devices
models) might use simple memory mapped device (“virtio-mmio”)
instead of the PCI device.
This adds a transport driver that implements UCLASS_VIRTIO for
virtio over mmio.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 15 Oct 2018 09:21:00 +0000 (02:21 -0700)]
dm: Add a new uclass driver for VirtIO transport devices
This adds a new virtio uclass driver for “virtio” [1] family of
devices that are are found in virtual environments like QEMU,
yet by design they look like physical devices to the guest.
The uclass driver provides child_pre_probe() and child_post_probe()
methods to do some common operations for virtio device drivers like
device and driver supported feature negotiation, etc.
Bin Meng [Mon, 15 Oct 2018 09:20:59 +0000 (02:20 -0700)]
riscv: bootm: Add dm_remove_devices_flags() call to do_bootm_linux()
This adds a call to dm_remove_devices_flags() to do_bootm_linux()
so that drivers that have one of the removal flags set (e.g.
DM_FLAG_ACTIVE_DMA_REMOVE) in their driver struct, may do some
last-stage cleanup before the OS is started.
arm and x86 already did such, and we should do the same for riscv.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Mario Six [Mon, 15 Oct 2018 07:24:14 +0000 (09:24 +0200)]
regmap: Add endianness support
Add support for switching the endianness of regmap accesses via the
"little-endian", "big-endian", and "native-endian" boolean properties in
the device tree.
The default endianness is native endianness.
Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Mario Six [Mon, 15 Oct 2018 07:24:12 +0000 (09:24 +0200)]
regmap: Define regmap_{get,set}
It would be convenient if one could use the regmap API in conjunction
with register maps defined as structs (i.e. structs that directly mirror
the memory layout of the registers in question). A similar approach was
planned with the regmap_write32/regmap_read32 macros, but was never
used.
Hence, implement regmap_set/regmap_range_set and
regmap_get/regmap_range_get macros, which, given a register map, a
struct describing the layout of the register map, and a member name
automatically produce regmap_read/regmap_write calls that access the
specified member in the register map.
Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
Mario Six [Mon, 15 Oct 2018 07:24:11 +0000 (09:24 +0200)]
regmap: Support reading from specific range
It is useful to be able to treat the different ranges of a regmap
separately to be able to use distinct offset for them, but this is
currently not implemented in the regmap API.
To preserve backwards compatibility, add regmap_read_range and
regmap_write_range functions that take an additional parameter
'range_num' that identifies the range to operate on.
Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
Mario Six [Mon, 15 Oct 2018 07:24:10 +0000 (09:24 +0200)]
regmap: Add raw read/write functions
The regmap functions currently assume that all register map accesses
have a data width of 32 bits, but there are maps that have different
widths.
To rectify this, implement the regmap_raw_read and regmap_raw_write
functions from the Linux kernel API that specify the width of a desired
read or write operation on a regmap.
Implement the regmap_read and regmap_write functions using these raw
functions in a backwards-compatible manner.
Reviewed-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Simon Glass <sjg@chromium.org>
Mario Six [Mon, 15 Oct 2018 07:24:09 +0000 (09:24 +0200)]
mips: Implement {in, out}_{le, be}_{16, 32, 64} and {in, out}_8
MIPS is the only architecture currently supported by U-Boot that does
not implement any of the in/out register access functions.
To have a interface that is useable across architectures, add the
functions to the MIPS architecture (implemented using the __raw_write
and __raw_read functions).
Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Signed-off-by: Mario Six <mario.six@gdsys.cc>
Simon Glass [Tue, 12 Jun 2018 05:26:46 +0000 (23:26 -0600)]
buildman: Add a --boards option to specify particular boards to build
At present 'buildman sandbox' will build all 5 boards for the sandbox
architecture rather than the single board 'sandbox'. The only current way
to exclude sandbox_spl, sandbox_noblk, etc. is to use -x which is a bit
clumbsy.
Add a --boards option to allow individual build targets to be specified.
Mario Six [Thu, 4 Oct 2018 07:22:24 +0000 (09:22 +0200)]
core: ofnode: Fix mem leak in error path
A newly created property is currently not freed if a name could not be
allocated. This patch fixes the resulting memory leak in the error
patch.
Reported-by: Coverity (CID: 184085) Fixes: e369e58df79c ("core: Add functions to set properties in live-tree") Signed-off-by: Mario Six <mario.six@gdsys.cc>
Mario Six [Thu, 4 Oct 2018 07:00:40 +0000 (09:00 +0200)]
test: regmap: Increase size of syscon0 memory
The upcoming changes to the regmap interface will contain a proper check
for plausibility when reading/writing from/to a register map. To still
have the current tests pass, increase the size of the memory region for
the syscon0 device, since one of the tests reads and writes beyond this
range.
Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
Bin Meng [Thu, 11 Oct 2018 05:07:00 +0000 (22:07 -0700)]
dm: core: Mirror the chosen node parse logic in the livetree scanning
Commit f2006808f099: ("dm: core: parse chosen node") added a logic
to parse the chosen node during dm_scan_fdt_node(), but unfortunately
it missed adding the same logic in dm_scan_fdt_live(). This mirrors
the logic in the livetree version.
The weird thing is that commit f2006808f099 did update the test case
to test such logic, but even if I reset to that commit, the test case
still fails, and I have no idea how it could pass.
With this fix, the following 2 test cases now pass:
Bin Meng [Thu, 11 Oct 2018 05:06:59 +0000 (22:06 -0700)]
dm: Correct pre_reloc_only parameter description in several APIs' comments
The pre_reloc_only parameter description currently only mentions
drivers with the DM_FLAG_PRE_RELOC flag, but does not mention the
special device tree properties. Correct them.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 11 Oct 2018 05:06:58 +0000 (22:06 -0700)]
dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()
Currently the comments of several APIs (eg: dm_init_and_scan()) say:
@pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC
flag. If false bind all drivers.
The 'Pre-Relocation Support' chapter in doc/driver-model/README.txt
documents the same that both device tree properties and driver flag
are supported.
However the implementation only checks these special device tree
properties without checking the driver flag at all. This updates
lists_bind_fdt() to consider both scenarios.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Squashed in http://patchwork.ozlabs.org/patch/996473/ : Signed-off-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 11 Oct 2018 05:06:55 +0000 (22:06 -0700)]
dm: cpu: Fix print_cpuinfo() output
It was observed that current output of print_cpuinfo() on QEMU
x86 targets does not have an ending '\n', neither have a leading
'CPU:' any more. However it used to have these before.
It turns out commit c0434407b595 introduced a unified DM version
of print_cpuinfo() that exposed such issue on QEMU x86.
Fixes: c0434407b595 ("board_f: Use static print_cpuinfo if CONFIG_CPU is active") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Mario Six [Mon, 6 Aug 2018 08:23:41 +0000 (10:23 +0200)]
board_f: Use static print_cpuinfo if CONFIG_CPU is active
When the DM CPU drivers are active, printing information about a CPU
should be delegated to a matching driver.
Hence, add a static print_cpuinfo that implements this delegation when
DM CPU drivers are active.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
Changed condition to CONFIG_IS_ENABLED(CPU): Signed-off-by: Simon Glass <sjg@chromium.org>
Commit fb01e07a95 accidentally broke initialisation of GPIO
descriptor flags from device tree: currently the active low
flag from gpio-specifier is always ignored. Fix it.
Signed-off-by: Anatolij Gustschin <agust@denx.de> Cc: Mario Six <mario.six@gdsys.cc>
Tom Rini [Wed, 14 Nov 2018 00:54:45 +0000 (19:54 -0500)]
configs: Migrate and re-enabled CONFIG_CMD_MTDPARTS
Now that CMD_UBI does not select CMD_MTDPARTS we need to make platforms
that had been enabling it turn it on by hand. This exposed that we had
not yet migrated CMD_MTDPARTS fully, so do so now.
Fixes: 86dfa556d927 ("cmd: ubi: Remove useless call to mtdparts_init()") Signed-off-by: Tom Rini <trini@konsulko.com>
Boris Brezillon [Tue, 13 Nov 2018 11:43:13 +0000 (12:43 +0100)]
mtd: Drop duplicate MTD_PARTITIONS Kconfig option
Commit 9c5b00973bce ("Convert CONFIG_MTD_PARTITIONS et al to Kconfig")
introduced a publicly visible Kconfig entry for the
CONFIG_MTD_PARTITIONS option, while the rework on MTD partitioning
was in progress, and we somehow did not notice that the same Kconfig
entry was added by commit 4048a5c519a8 ("mtd: declare MTD_PARTITIONS
symbol in Kconfig"), but this time as an invisible entry (this can
only be selected by other options).
Keep the non-visible version of this symbol, since MTD_PARTITIONS is
not something the user should be able to enable/disable directly.
Fixes: 4048a5c519a8 ("mtd: declare MTD_PARTITIONS symbol in Kconfig") Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Jagan Teki <jagan@openedev.com>
Boris Brezillon [Tue, 13 Nov 2018 11:43:12 +0000 (12:43 +0100)]
cmd: ubi: Remove useless call to mtdparts_init()
Commit c58fb2cdb3e4 ("cmd: ubi: clean the partition handling")
introduced a call to mtd_probe_devices() in the ubi_attach() path
and this function takes care of parsing mtdparts/mtdids and
creating/registering the associated mtd partitions.
The mtdparts_init() call in the ubi_detach() path is not only
unnecessary but can sometimes print error messages even when things
work properly (that's the case with SPI NAND devices that have not
been probed with 'mtd list'), which is misleading.
Remove this call to mtdparts_init() and drop the dependency on
CMD_MTDPARTS.
Fixes: c58fb2cdb3e4 ("cmd: ubi: clean the partition handling") Reported-by: Stefan Roese <sr@denx.de> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Tested-by: Stefan Roese <sr@denx.de> Reviewed-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Jagan Teki <jagan@openedev.com>
Boris Brezillon [Tue, 13 Nov 2018 11:43:11 +0000 (12:43 +0100)]
mtd: Make {MTDIDS, MTDPARTS}_DEFAULT visible when MTD_PARTITIONS is selected
gwventana configs are relying on CMD_UBI to select CMD_MTDPARTS,
which is then making {MTDIDS,MTDPARTS}_DEFAULT options available.
We are about to remove the 'select CMD_MTDPARTS' statement in the
CMD_UBI entry, but if we do that without first making sure
{MTDIDS,MTDPARTS}_DEFAULT are visible, we end up with a build
failure when building gwventana configs.
Address that by adding a depends on MTD_PARTITIONS to
{MTDIDS,MTDPARTS}_DEFAULT which does the trick since CMD_UBI selects
MTD_UBI which in turn selects MTD_PARTITIONS.
We also get rid of the depends on CMD_MTD, since CMD_MTD also selects
MTD_PARTITIONS.
Reported-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Jagan Teki <jagan@openedev.com>
Boris Brezillon [Tue, 13 Nov 2018 11:43:09 +0000 (12:43 +0100)]
mtd: Use default mtdparts/mtids when not defined in the environment
U-boot provides a mean to define default values for mtdids and mtdparts
when they're not defined in the environment. Patch mtd_probe_devices()
to use those default values when env_get("mtdparts") or
env_get("mtdids") return NULL.
This implementation is based on the logic found in cmd/mtdparts.c.
Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command") Reported-by: Stefan Roese <sr@denx.de> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Tested-by: Stefan Roese <sr@denx.de> Reviewed-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Jagan Teki <jagan@openedev.com>
Marcel Ziswiler [Fri, 9 Nov 2018 14:31:17 +0000 (15:31 +0100)]
imx: mkimage: add size check to the u-boot.imx make target
The make macro to check if the binary exceeds the board size limit is
taken straight from the root Makefile.
Without this and e.g. enabled EFI Vybrid fails booting as the regular
size limit check does not take the final u-boot.imx binary size into
account which is bigger due to alignment as well as IMX header stuff.
Marek Vasut [Tue, 6 Nov 2018 22:42:11 +0000 (23:42 +0100)]
mmc: dw_mmc: Add RCRC handling
This patch adds check for command response CRC failure. The driver
is currently ignoring CRC check failure on command resposes which
have CRC atteched to it, which can be potentially dangerous. Even
more grueling problem happens when the command response is followed
by data transfer though, as in that case, the dwmci_data_transfer()
function will spin until it reaches the 240s timeout.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Lars Povlsen [Tue, 23 Oct 2018 08:21:25 +0000 (10:21 +0200)]
common: Compile error with CONFIG_MULTI_DTB_FIT and not SPL
common/common_fit.c is including <spl.h>, but not actually using it. The
inclusion will cuase compile error on platforms using CONFIG_OF_SEPARATE
and not SPL.
Signed-off-by: Lars Povlsen <lars.povlsen@microsemi.com> Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Andy Shevchenko [Mon, 5 Nov 2018 16:24:03 +0000 (18:24 +0200)]
dm: Fix typo - missed semicolon
The commit
484fdf5ba058 ("dm: Add support for all targets which requires MANUAL_RELOC")
introduces subtle typo, i.e. missed semicolon.
Fixes: 484fdf5ba058 ("dm: Add support for all targets which requires MANUAL_RELOC") Cc: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Michal Simek <michal.simek@xilinx.com>
imx: imx6: perform gpr_init only on suitable cpu types
If the function gpr_init is used in a common MX6 spl
implementation we have to ensure that it is only called for
suitable cpu types, otherwise it breaks hardware parts like
enet1, can1, can2, etc.
Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.de>
It turns out commit c0434407b595 broke some boards which have DM CPU
driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail
to boot when print_cpuinfo() is called during boot.
Fixes are already sent to ML and in u-boot-dm/next, however since
we are getting close to the v2018.11 release, it's safer we revert
the original commit.
This commit should be reverted after v2018.11 release.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Paul Davey [Mon, 5 Nov 2018 05:09:29 +0000 (18:09 +1300)]
fs: ubifs: Fix UBIFS decompression on 64 bit
Add local size_t variable to crypto_comp_decompress as intermediate
storage for destination length to avoid memory corruption and incorrect
results on 64 bit targets.
This is what linux does for the various lz compression implementations.
Stefan Roese [Tue, 23 Oct 2018 10:25:16 +0000 (12:25 +0200)]
arm: mvebu: armada-xp-theadorable.dts: Change CS# for 2nd FPGA
The new board version has the 2nd FPGA connected via CS# 0 instead of
2 on SPI bus 1. Change this setup in the DT accordingly. Please note
that this change does still work on the old board version because the
CS signal is not used on this board.
Stefan Roese [Mon, 22 Oct 2018 12:21:17 +0000 (14:21 +0200)]
arm: mvebu: Move PCI(e) MBUS window to end of RAM
With patch 49b23e035d96 (pci: mvebu: Increase size of PCIe default mapping)
the mapping size for each PCI(e) controller was increased from 32MiB to
128MiB. This leads to problems on boards with multiple PCIe slots / ports
which are unable to map all PCIe ports, e.g. the Armada-XP theadorable:
DRAM: 2 GiB (667 MHz, 64-bit, ECC not enabled)
SF: Detected m25p128 with page size 256 Bytes, erase size 256 KiB, total 16 MiB
Cannot add window '4:f8', conflicts with another window
PCIe unable to add mbus window for mem at f0000000+08000000
Model: Marvell Armada XP theadorable
This patch moves the base address for the PCI(e) memory spaces from
0xe8000000 to the end of SDRAM (clipped to a max of 0xc0000000 right now).
This gives move room and flexibility for PCI(e) mappings.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: VlaoMao <vlaomao@gmail.com> Tested-by: VlaoMao <vlaomao at gmail.com>
Commit 3c28576bb0f0 ("arm: dts: imx8qxp: fix build warining")
fixed the dts warning by removing the unnecessary
#address-cells/#size-cells, but the recommendation for regulators is not
to place them under "simple-bus", so move the reg_usdhc2_vmmc regulator
accordingly.
driver: net: ti: introduce common mdio support library
All existing TI SoCs network HW have similar MDIO implementation, so
introduce common mdio support library which can be reused by TI networking
drivers.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Networking support for all TI K2 boards converted to use DM model and
CONFIG_DM_ETH enabled in all corresponding defconfig files, hence drop
unused non DM K2 networking code.
Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Quentin Schulz [Wed, 31 Oct 2018 10:20:39 +0000 (11:20 +0100)]
net: phy: mscc: add support for VSC8574 PHY
The VSC8574 PHY is a 4-port PHY that is 10/100/1000BASE-T, 100BASE-FX,
1000BASE-X and triple-speed copper SFP capable, can communicate with
the MAC via SGMII, QSGMII or 1000BASE-X, supports WOL, downshifting and
can set the blinking pattern of each of its 4 LEDs, supports SyncE as
well as HP Auto-MDIX detection.
This adds support for 10/100/1000BASE-T and SGMII/QSGMII link with the
MAC.
The VSC8574 has also an internal Intel 8051 microcontroller whose
firmware needs to be patched when the PHY is reset. If the 8051's
firmware has the expected CRC, its patching can be skipped. The
microcontroller can be accessed from any port of the PHY, though the CRC
function can only be done through the PHY that is the base PHY of the
package (internal address 0) due to a limitation of the firmware.
The GPIO register bank is a set of registers that are common to all PHYs
in the package. So any modification in any register of this bank affects
all PHYs of the package.
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Quentin Schulz [Wed, 31 Oct 2018 10:20:38 +0000 (11:20 +0100)]
net: phy: mscc: factorize part of config function for VSC8584
Part of the config is common between the VSC8584 and the VSC8574, so to
prepare for the upcoming support of VSC8574, use the phy_device.priv
pointer that will keep the function that holds code that is PHY-specific
and that should be called during config function.
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
projects / u-boot.git / log