ftgmac100 driver is using hard-coded PHY interface address of zero.
Each board can have different PHY interface address (phy_addr).
This commit modifies the driver to make use of board specific address
by leveraging CONFIG_PHY_ADDR.
Signed-off-by: NThirupathaiah Annapureddy <thiruan@linux.microsoft.com>
Reviewed-by: NCédric Le Goater <clg@kaod.org>

The Linux kernel does set the clock delays to
- 0.2 ns (their default, and lowest, hardware value) if delays should
  not be enabled
- 2.0 ns (which causes the data to be sampled at exactly half way between
  clock transitions at 1000 Mbps) if delays should be enabled
depending on the interface mode

See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/mscc/mscc_main.c#n523

So instead of using arbitrary delay values like now, mimic this behaviour.

The behaviour is the same for all of vsc8530/8531/8540/8541 so move that
to a shared function while at it.
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

The vsc8530/8531/8540/8541 phys have a configurable clock output that
can emit 25, 50 and 125 MHz rates, which in turn may be needed for
stable network connections.

This follows a similar change introduced into the Linux kernel at
  https://lore.kernel.org/netdev/20200609133140.1421109-2-heiko@sntech.deSigned-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

- Disable CMD_IRQ for RISC-V.
- Update sipeed/maix doc
- Obtain reg of SiFive RAM via dev_read_addr_index() instead of regmap API.
- Cleans up RISC-V timer drivers and converts them to DM.
- Correctly handle IPIs already pending upon prior stage bootloader (on the K210)

- Improve our dev_xxx(..) wrappers to be generally used and available
  rather than discarded at link/compile time.

This adorns messages generated by dev_xxx with the device and driver
names. It also redirects dev_xxx to log when it is available. The names
of these functions very roughly take inspiration from Linux, but there is
no deeper correlation.

Both struct udevice and struct device are supported when logging, though
logging with struct device is no better than using log_xxx. The latter is
supported because of the large amount of existing code which logs with
struct device.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

This substitutes literal log levels with their symbolic constants.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

There is no member `dev` in dw_mipi_dsi, but there is one in mipi_dsi_host,
so use that.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NPatrick Delaunay <patrick.delaunay@st.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

This driver does not use DM, so we need to use a struct device instead of a
struct udevice. Not ideal, but it'll have to do for now.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

This can conflict with asm/io.h on some archs, and it isn't needed to build
dwc3-generic.c
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

This driver does not use DM, so use log_xxx instead.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

This logs with the device from struct dwc3. Some files also need to include
dm.h so fields in udevice can be accessed.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

This adds a dev argument to some functions so dev_xxx always has a device
to log with. In one instance we must use use a different log function when
we are compiled without DM_USB.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NPatrick Delaunay <patrick.delaunay@st.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

ep0.c also need to include dm.h so dev_xxx can access udevice fields.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

The rst variable doesn't exist.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Use `bus` instead of `dev`.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NMichal Simek <michal.simek@xilinx.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Use `bus` and not `dev`.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Remove the indirection.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Pass a device to functions which log with one.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Usually we can get a device from the current core, but some dev_dbg calls
have been converted to debug, since we are called on a cluster.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

This function is never used anywhere, and it also tries to log with a
nonexistant device.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Use the phy's device.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NPatrick Delaunay <patrick.delaunay@st.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

`phy` doesn't exist; we need to use `x` instead.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

This uses phy's device
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Get the device from phy, or pass the phy in.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

No need for indirection here.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Without DM_ETH, cpsw_priv.dev is an eth_device. Just use its name instead.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Pass a udevice into a few functions so `dev` is defined.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

There's no dev to log with, so pass the device along with the priv data.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

No drivers in U-Boot use these functions.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

netdev_xxx evaluates to printf in U-Boot, so there is no extra info
printed. mvpp2 one of only two drivers which use these functions in U-Boot.
Convert these functions to dev_xxx where possible (and to log_xxx where
not).
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Remove some prefixes, or get the device from the phy.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

netdev_xxx evaluates to printf in U-Boot, so there is no extra info
printed. mvneta is one of two drivers which use these functions in U-Boot.
Convert these functions to dev_xxx where possible (and to log_xxx where
not).
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

No need for indirection here.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

The name of the device we are working on is `ethdev` and not just `dev`.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Remove the pdev indirection.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

This member was presumably dropped when this driver was converted from
Linux. However, it is still used in log statements during initialization.
This patch adds the member back. In addition, allocation of struct
vf610_nfc has been moved to the callers of vf610_nfc_nand_init. This allows
it to be allocated by DM (if it is being used) and for dev to be
initialized.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

There are too many levels of indirection when calling dev_err. This is an
artifact of the conversion of brcmnand_host.pdev from a struct
platform_device (which has a member `dev` pointing to a struct device) to
struct udevice.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

Use mtd_info to get a device to log with.
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>

dev needs to be gotten from mbox_chan
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NPatrick Delaunay <patrick.delaunay@st.com>