priv->dev does not exist.  Pass the correct pointer to udevice.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Add basic clock data for Socionext's new SoC PXs3.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

U-Boot does not support fancy clock tree structures like the Linux
common clock framework.  Implement a simple clock tree model at the
driver level.  With this, the clock data will be simplified.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Use dev_dbg() functions.  It will be helpful to prefix log messages
with the corresponding device name when the core framework is ready.

While I am here, I renamed "dev", which was actually private data,
into "priv" because dev->dev looks confusing.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Use dev_dbg() functions.  It will be helpful to prefix log messages
with the corresponding device name when the core framework is ready.

While I am here, I renamed "dev", which was actually private data,
into "priv" because dev->dev looks confusing.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Including <common.h> pulls in a lot of bloat.  What this driver needs
is BIT(), so replace it with <linux/bitops.h>

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Marek Vasut <marex@denx.de>

The pin data are implemented for old SoCs to specify the bit shift of
the IECTRL register.  They are not wortwhile given the required memory
footprint.  Delete all the pin data and enable all bits of the IECTRL
register.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Like other recenct UniPhier SoCs, the pupdctrl number of PXs3
matches to the pin number.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

First, I implemented this driver as per-bank model, but it was
a design mistake.

  - There are 31 banks in the maximum case.  It is painful to add
    so many nodes to DT.

  - The IRQ control registers are shared between banks.  Per-bank
    design is a problem for Linux.  The counterpart for Linux turned
    around to the single node model.

Rework based on the driver for Linux.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Set Features (0xEF) command toggles the R/B# pin after 4 sub feature
parameters are written.

Currently, nand_command(_lp) calls chip->dev_ready immediately after
the address cycle because NAND_CMD_SET_FEATURES falls into default:
label.  No wait is needed at this point.

If you see nand_onfi_set_features(), R/B# is already cared by the
chip->waitfunc call.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>

[ Linux commit: c5d664aa5a4c4b257a54eb35045031630d105f49 ]

Read ID (0x90) command does not toggle the R/B# pin.  Without this
patch, NAND_CMD_READID falls into the default: label, then R/B# is
checked by chip->dev_ready().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>

[ Linux commit: 3158fa0e739615769cc047d2428f30f4c3b6640e ]

We have at least a minor count of boards, that failed to re-initialize
PCI express in the Linux kernel. Typical failure rate is 20% on affected
boards. This is mitigated by commit 6ecbe137 ("drivers: pci: imx:
add imx_pcie_remove function").

However, at least on some i.MX6 custom boards, when calling
assert_core_reset() as part of the first-time PCIe init, read access
to PCIE_PL_PFLR simply hangs. Surround this readl() with
imx_pcie_fix_dabt_handler() does not help. For this reason, the forced
LTSSM detection is only used on the second assert_core_reset() that is
called shorly before starting the Linux kernel.

Signed-off-by: Sven-Ola Tuecke <sven-ola.tuecke@numberfour.eu>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: David Müller <d.mueller@elsoft.ch>

Commit 8e6eda7c ("drivers/i2c/muxes/pca954x: Add pca9547 I2C mux
support") introduced a chip_desc for the pca954x devices but failed to
update pca954x_ofdata_to_platdata() to be aware of it. Make
pca954x_ofdata_to_platdata() lookup the chip_desc to validate the device
width.

Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Marek Behun <marek.behun@nic.cz>

The livetree codepath of ofnode_get_addr_size always used the "reg"
property for of_get_property. Use the property parameter of the function
call instead and check the return value if the property exists.
Otherwise return FDT_ADDR_T_NONE.

This was discoverd while using SPI NOR with livetree.
spi_flash_decode_fdt checks for memory-map and will not fail with
livetree even if the property does not exist.

Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The size variable may not be always be a mulitple of
ARCH_DMA_MINALIGN and using it to flush cache leads to cache
misaligned warnings.

Therefore, round up the size to a multiple of ARCH_DMA_MINLAIGN
when allocating private data.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

These checks cannot fail since driver model will not call a driver's
method if it cannot fully create the driver data structures.

It is confusing to have these checks and others might copy them. Drop this
code.

Signed-off-by: Simon Glass <sjg@chromium.org>

In U-Boot -ENODEV means that there is no device. When there is a problem
with the device, drivers should return an error like -ENXIO or -EREMOTEIO.
When the device tree properties cannot be read correct , they should
return -EINVAL.

Update various GPIO drivers to follow this rule, to help with consistency
for future driver writers.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Adam Ford <aford173@gmail.com>

These three drivers all use U_BOOT_DEVICE rather than device tree to
create devices, so have to do manual allocation of platform data. This is
not true for new platforms.

Add a more explicit comment so that people do not copy this approach with
new boards.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Adam Ford <aford173@gmail.com>

It does not look like this driver needs to use a bind() method. It does
not manually create devices with device_bind() nor does it create devices
using U_BOOT_DEVICE(). It seems to only use device tree.

Therefore the manual allocation of platform data is not needed and is
confusing. Also platform data should be set up by the ofdata_to_platdata()
method, not bind().

Update the driver in case others use it as a model in future.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Adam Ford <aford173@gmail.com>

Since e7881d85 "dm: mmc: Drop CONFIG_DM_MMC_OPS" DM_MMC_OPS
is no more used, remove it from STM32_SDMMC2 dependencies

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>

This driver is currently used by STM32F7 and STM32H7 SoCs.
As CONFIG_CLK and OF_CONTROL flags are set by default for these
2 SoCs, this flag becomes useless in this driver, so remove it.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>

stm32f4 doesn't support FIFO and OVERRUN feature.
The enable bit is not at the same location in CR1
register than for STM32F7 and STM32H7.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>

Add fifo mode support for rx and tx.
As only STM32H7 supports this feature, add has_fifo flag
to uart configuration to use fifo only when possible.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>

STM32F4 serial IP is similar to F7 and H7, but registers
are not located at the same offset and some feature are
only supported by F7 and H7 version.

Registers offset must be added for each version and also
some flags indicated the supported feature.

Update registers name to match with datasheet (sr to isr,
rx_dr to rdr and tx_dr to tdr) and remove unused regs
(cr2, gtpr, rtor, and rqr).

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>

This patch remove the extra compatibility string "st,stm32h7-usart"
and "st,stm32f7-usart" to avoid confusion, save some time & space.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>

Use BIT() macro and GENMASK() macro

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>

QEMU emulates such a device with '-machine virt,highmem=off' on ARM.
The 'highmem=off' part is required for things to work as the PCI code
in U-Boot doesn't seem to support 64-bit BARs.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Use the new helpers to avoid boilerplate in the driver.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Use the new helper function to avoid boilerplate in the driver.

Note that this changes __raw_writel et al. to writel. AFAICT this is
no problem because:

- The Linux driver for the same hardware uses the non-__raw variants as
  well (via pci_generic_config_write()).
- This driver seems to be used only on MIPS so far, where the __raw and
  non-__raw accessors are the same.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

This sort of pattern for implementing memory-mapped PCI config space
accesses appears in U-Boot twice already, and a third user is coming up.
So add helper functions to avoid code duplication, similar to how Linux
has pci_generic_config_write and pci_generic_config_read.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

As we discussed before in ML, dm_dbg() causes undefined reference
error if #define DEBUG is added to users, but not drivers/core/util.c

We do not need this macro because we can use pr_debug() instead, and
it is pretty easy to enable it for the DM core by using ccflags-y.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Collect runtime BUG/WARN into a self-contained header <linux/bug.h>
to make these macros easier to use.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

U-Boot widely uses error() as a bit noisier variant of printf().

This macro causes name conflict with the following line in
include/linux/compiler-gcc.h:

  # define __compiletime_error(message) __attribute__((error(message)))

This prevents us from using __compiletime_error(), and makes it
difficult to fully sync BUILD_BUG macros with Linux.  (Notice
Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().)

Let's convert error() into now treewide-available pr_err().

Done with the help of Coccinelle, excluing tools/ directory.

The semantic patch I used is as follows:

// <smpl>
@@@@
-error
+pr_err
 (...)
// </smpl>

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Re-run Coccinelle]
Signed-off-by: Tom Rini <trini@konsulko.com>

When we import code from Linux, with regular re-sync planned, we want
to use printk() and pr_*().  U-Boot does not support them in a clean
way.  So, people end up with local macros, or compat headers here and
there, then we occasionally see build errors of definition conflicts.

We have include/linux/compat.h, but putting all sorts of unrelated
things into a single header is just a temporal workaround.  Hence this
patch, to find the best home for all printk variants.  If you want to
use printk() and friends, please include <linux/printk.h>.  This header
is self-contained, and pulls in only a few headers.

When I was testing this clean-up, I noticed the image size exceeded
its platform limit on some boards.  This is because all pr_*() that
were previously defined as no-op in include/linux/mtd/mtd.h (unless
CONFIG_MTD_DEBUG is set), are now enabled.

To make such boards happy, this commit also implements CONFIG_LOGLEVEL.
The concept is similar to the kernel parameter "loglevel".  (Actually,
the Kconfig help message was taken from kernel-paremeter.txt of Linux)
Messages with a loglevel smaller than console loglevel will be printed.

The difference is the loglevel is build-time determined.  To save the
image size, lower priority pr_*() are compiled out.  I set the default
of CONFIG_LOGLEVEL to 6, i.e. pr_notice and higher priority messages
are compiled in.

I adjusted CONFIG_LOGLEVEL to avoid build error for some boards.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[trini: Add in SPL_LOGLEVEL that is the same as LOGLEVEL]
Signed-off-by: Tom Rini <trini@konsulko.com>

Add pinconf support to the PFC driver, so that it can handle DT
props bias-disable, bias-pull-up, bias-pull-down, drive-strength
and power-source.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

Since we use EHCI generic driver on RCar Gen3 , this driver is useless.
Remove it.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Acked-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

USB_GADGET will fail to compile if USB_MUSB_GADGET is not defined. Make
sure we have that condition right.

Fixes: e0ea88042d51 ("sunxi: Imply USB_ETHER")
Suggested-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The device model was implemented so far using a hook that needed to be
called from the board support, without DT support and only for the host.

Switch to probing both in peripheral and host mode through the DT.

Reviewed-by: Łukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

All the Allwinner boards use the same manufacturer, VID and PID for the
gadgets. Make them the defaults to remove some boilerplate from our
defconfigs.

Reviewed-by: Łukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The usb_ether gadget duplicates the USB settings for the manufacturer,
product ID and vendor ID.

Make sure we use the common option so that we can expect a single VID/PID
couple for a single device.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>