These compatibles are now handled by the dwmac_meson8b glue driver.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>

This adds a proper glue driver for the Designware DWMAC ethernet MAC IP
found in the Amlogic Meson8, GXBB, GXL, GXM, G12A, G12B & SM1 SoCs.

This is aimed to replace the static ethernet link setup found on the board
init code for the Amlogic SoC based boards.

Tested on a libretech-cc (S905x Internal RMII 10/100 PHY) and Khadas VIM3 (A113d
with external 10/100/1000 RGMII PHY) to cover the most extreme setups.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>

The Amlogic G12A & compatible SoCs embeds a mux to either communicate with
the external PHY or the internal 10/100 PHY.

This adds support for this mux as a MDIO MUX device.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NRamon Fried <rfried.dev@gmail.com>

Add support for DM_MDIO to connect to PHY and expose a MDIO device for the
internal MDIO bus in order to dynamically connect to MDIO PHYs with DT
with eventual MDIO muxes in between.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NRamon Fried <rfried.dev@gmail.com>

Add support for MMIO register MDIO muxes based on the Linux mdio-mux-mmioreg driver.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NRamon Fried <rfried.dev@gmail.com>

In some cases it is useful to compile support for U-Boot command 'wdt'
without starting HW watchdog in early U-Boot phase. For example when the
user want to start the watchdog only on demand by some boot script.

This change adds a new compile option WATCHDOG_AUTOSTART to control whether
U-Boot should automatically start the watchdog during init phase or not.

This option is enabled by default as it was the default behavior prior
introducing this new change. When compiling U-Boot users can decide to turn
this option off.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NStefan Roese <sr@denx.de>

Function wdt_start() may fail. So in initr_watchdog() function check return
value of wdt_start() call and print error message when watchdog starting
failed.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NStefan Roese <sr@denx.de>

Watchdog is ready after successful call of ops->start() callback in
wdt_start() function. And is stopped after successful call of ops->stop()
callback in wdt_stop function.

So move setting of GD_FLG_WDT_READY flag from initr_watchdog() function to
wdt_start() and ensure that GD_FLG_WDT_READY flag is unset in wdt_stop()
function.

This change ensures that GD_FLG_WDT_READY flag is set only when watchdog is
running. And ensures that flag is also also when watchdog was started not
only by initr_watchdog() call (e.g. by U-Boot 'wdt' command).
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NStefan Roese <sr@denx.de>

We had a problem detecting 8/16bit flash devices connected only via
8bits to the SoC for quite a while. Commit 239cb9d9
[mtd: cfi_flash: Fix CFI flash driver for 8-bit bus support] finally
fixed this 8-bit bus support. But also broke some other boards using
this cfi driver. So this patch had to be reverted.

I spotted a different, simpler approach for this 8-bit bus support
on the barebox mailing list posted by
Oleksij Rempel <bug-track@fisher-privat.net>:

http://www.spinics.net/lists/u-boot-v2/msg14687.html

Here the commit text:

"
Many cfi chips support 16 and 8 bit modes. Most important
difference is use of so called "Q15/A-1" pin. In 16bit mode this
pin is used for data IO. In 8bit mode, it is an address input
which add one more least significant bit (LSB). In this case
we should shift all adresses by one:
For example 0xaa << 1 = 0x154
"

This patch now is a port of this barebox patch to U-Boot.

Along with the change w.r.t from barebox,
Some flash chips can support multiple bus widths, override the
interface width and limit it to the port width.

Tested on 16-bit Spansion flash on sequoia.
Tested 8-bit flashes like 256M29EW, 512M29EW.
Signed-off-by: NStefan Roese <sr@denx.de>
Tested-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com>
Cc: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Cc: Aaron Williams <awilliams@marvell.com>
Cc: Chandrakala Chavva <cchavva@marvell.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: York Sun <york.sun@nxp.com>
Cc: Marek Vasut <marek.vasut+renesas@gmail.com>

Update the code to use -ENOSYS, which is the correct error code for an
unimplemented system call in U-Boot.

Also we should not check for a missing operations array as this is not
permitted. For now this can be covered by an assert().
Signed-off-by: NSimon Glass <sjg@chromium.org>

We don't need to check -ENOTSUPP since this is not used for this purpose
in U-Boot. Update the code accordingly.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NSean Anderson <seanga2@gmail.com>

Update clk_composite_set_parent() to use -ENOSYS, which is the correct
error code for U-Boot. Also rearrange the code so that the error condition
is clearly indicated and the function runs to the end in the normal case,
since this is the common style in U-Boot.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NSean Anderson <seanga2@gmail.com>

At present some drivers use -ENOSUPP to indicate that an unknown or
unsupported clock is used. Most use -EINVAL, indicating an invalid value,
so convert everything to that.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NStefan Roese <sr@denx.de>

Update usb_gadget_release() to use -ENOSYS, which is the correct error
code for U-Boot.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Update this function to use -ENOSPC which is more commly used when a buffer
runs out of space.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Use __func__ instead for function name in debug.
Use Linux style u32 instead of uint32_t.
Signed-off-by: NT Karthik Reddy <t.karthik.reddy@xilinx.com>
Acked-by: NAshok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

With "clk dump" command, few clocks are showing up incorrect values
and some clocks are displayed as "unknown".

Add missing clocks to zynqmp clock driver to display proper
clocks rates.

Implement a simple way to get clock source, instead of calling
functions. Change existing functions to this simple mechanism.

Fix gem clock name "gem_rx" to "gem_tx" which was incorrect.
Change dbf_fpd & dbf_lpd clk names to dbg_fpd & dbg_lpd.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NT Karthik Reddy <t.karthik.reddy@xilinx.com>

The code was trying to disable PCS auto-negotiation when a fixed-link node
is present and enable it otherwise. However, the PCS registers were being
written before the PCSSEL bit was set in the network configuration
register, and it appears that in this state, PCS register writes are
ignored. The result is that the intended change only took effect on the
second network operation that was performed, since at that time PCSSEL is
already enabled.

Fix the order of register writes so that PCS registers are only written to
after the PCS is enabled.

Fixes: 26e62cc9 ("net: gem: Disable PCS autonegotiation in case of fixed-link")
Signed-off-by: NRobert Hancock <robert.hancock@calian.com>
Reviewed-by: NRamon Fried <rfried.dev@gmail.com>
Reviewed-by: NAshok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Add spi memory operations to relocate manually when
CONFIG_NEEDS_MANUAL_RELOC is enabled.
Signed-off-by: NT Karthik Reddy <t.karthik.reddy@xilinx.com>
Acked-by: NAshok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NPratyush Yadav <p.yadav@ti.com>

The _SUPPORT suffix is from an earlier time and interferes with use of
the CONFIG_IS_ENABLED() macro. Rename the option to drop the suffix.

Tidy up the TODO that prompted this.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This feature was dropped from U-Boot some time ago:

   f12f96cf (sf: Drop spl_flash_get_sw_write_prot")

However, we do need a way to see if a flash device is write-protected,
since if it is, it may not be possible to write to do (i.e. failing to
write is expected).

I am not sure of the correct layer to implement this, so this patch is a
stab at it. If spi-flash makes sense then I will add to the 'sf' also.

Re the points mentioned in the removal commit:

    1) This kind of requirement can be achieved using existing
       flash operations and flash locking API calls instead of
       making a separate flash API.

Which uclass is this?

    2) Technically there is no real hardware user for this API to
       use in the source tree.

I do want coral (at least) to support this.

    3) Having a flash operations API for simple register read bits
       also make difficult to extend the flash operations.

This new patch only mentions write-protect being on or off, rather than
the actual mechanism.

    4) Instead of touching generic code, it is possible to have
       this functionality inside spinor operations in the form of
       flash hooks or fixups for associated flash chips.

That sounds to me like what drivers are for. But we still need some sort
of API for it to be accessible.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present when a file is bound to a host device it is always marked as
removeable. Arguably the device is removeable, since it can be unbound at
will. However while it is bound, it is not considered removable by the
user. Also it is useful to be able to model both fixed and removeable
devices for code that distinguishes them.

Add a -r flag to the 'host bind' command and plumb it through to provide
this feature.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This can crash if the EC has not yet been probed. Add a check to prevent
this.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This function only exists if CPU is enabled. Update the code to take
account of this, so that it does not have to be enabled on all sandbox
builds.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NSean Anderson <seanga2@gmail.com>

When booting from coreboot we need this driver for the video to work.
Update the driver to be usable on any board.

The driver disables itself if it sees that is not booted from coreboot.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The copy buffer, if enabled, prevents booting from coreboot correctly,
since no memory is allocated for it. Allow it to fall back to disabled
in this situation. This ensures that a console is displayed, even if
it is slow.
Signed-off-by: NSimon Glass <sjg@chromium.org>

It is possible to boot U-Boot for chromebook_coral either 'bare metal' or
from coreboot. In the latter case we want to provide access to the coreboot
sysinfo tables. Move the definitions into a file available to any x86
board.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The driver currently reads the card-detect but does not register it with
the MMC stack. Update this so that card-detect works as expected.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We should not enable debugging by default. Drop this.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The Intel GPIO binding allows GPIOs to be globally numbered, so that it
does not matter which GPIO bank is specified in the device tree. This is
convenient and avoid confusion since the banks do not have the same number
of GPIOs and the numbering is not sequential.

The GPIO uclass ensures that the device mentioned in the devicetree
binding is probed. It is fine for the driver to update gpio_desc to point
to a different driver, but this may not have been probed. If it has not
been, then it cannot be claimed since there is no uclass data.

We could handle this in the GPIO uclass but so far it is an unusual
situation so it is probably not worth the extra code. Handle this case in
the GPIO driver by probing the selected device if necessary.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We should not enable debugging by default. Drop this.
Signed-off-by: NSimon Glass <sjg@chromium.org>

dfu_free_entities() invoking dfu_free_entity_sf() has let to segementation
faults due to double freeing the same device.

spi_flash_free() is not relevant for the driver model but exists only for
compatibility with old drivers.

We must not remove any device here:

* The device may still be referenced.
* We don't want to have to probe again.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Make use of the new priv/plat data region if enabled. This is implemented
as a simple offset from the position set up by dtoc to the new position.

So long as all access goes through dm_priv_to_rw() this is safe.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present the device priv/data data allocated by dtoc is stored in the
data section along with other variables. On some platforms it is better
to allocate space for it separately, e.g. if SPL is running from read-only
memory.

Create a new space with the same size as that allocated by dtoc, ready for
use.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

When of-platdata-inst is active, use the flags in the new udevice_rt
table, dropping them from the main struct udevice. This ensures that the
latter is not updated at runtime.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present when driver model needs to change a device it simply updates
the struct udevice structure. But with of-platdata-inst most of the fields
are not modified at runtime. In fact, typically only the flags need to
change.

For systems running SPL from read-only memory it is convenient to separate
out the runtime information, so that the devices don't need to be copied
before being used.

Create a new udevice_rt table, similar to the existing driver_rt. For now
it just holds the flags, although they are not used in this patch.

Add a new Kconfig for the driver_rt data, since this is not needed when
of-platdata-inst is used.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

With recent changes this can be supported again. Add it back.

This reverts commit d85f2c4f.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present the i2c emulators require access to the devicetree, which is
not possible (by design) with of-platdata.

Add a way for drivers to record the of-platdata index of their emulator,
so that we can still find the emulator.

This allows i2c emulation to work with of-platdata.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This function finds a device by its driver_info index. With
of-platdata-inst we do not use driver_info, but instead instantiate
udevice records at build-time.

However the semantics of using the function are the same in each case:
the caller provides an index and gets back a device.

So rename the function to device_get_by_ofplat_idx(), so that it can be
used for both situations. The caller does not really need to worry about
the details.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present the structs used by these drivers are declared in the C files
and so are not accessible to dtoc. Move them to header files, as required.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>