Until a live tree is used in U-Boot proper after relocation, use of
ofnode_get_parent() will trigger a call to the very expensive
fdt_parent_offset(), as detailed by the function documentation:

  NOTE: This function is expensive, as it must scan the device tree
  structure from the start to nodeoffset, *twice*.

Re-use the returned value from a single call instead of having to make
multiple calls for same node.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Simon Glass <sjg@chromium.org>

Prior to that, seeing the debug() messages required to enable DM_DEBUG
which defines DEBUG (and then _DEBUG) which in turn makes failing
assert() calls reset U-Boot which isn't necessarily what is desired.

Instead, let's migrate to dm_warn which is using log_debug when unset or
log_warn when set.

While at it, reword the DM_DEBUG symbol in Kconfig to explain what it
now actually does.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Remove <common.h> from this driver directory and when needed
add missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so convert regmap_init_mem_plat() input to handel both. The
syscon class driver also makes use of the regmap_init_mem_plat()
function, but has no way of knowing the format of the
device-specific platform data. In case of odd reg structures other
then that the syscon class driver assumes the regmap must be
filled in the individual syscon driver before pre-probe.
Also fix the ARRAY_SIZE divider in the syscon class driver.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

A recent change to regmap breaks building of phycore-rk3288 for me. The
difference is only a few bytes. Somehow CI seems to pass, even though it
fails when I run docker locally. But it prevents me from sending any more
pull requests.

In any case this board is clearly near the limit. We could revert the
offending change, but it is needed for sandbox tests.

Instead, add a way to drop the range checks in SPL, since they end up
doing nothing if everything is working as expected.

This makes phycore-rk3288 build again for me and reduces the size of SPL
slightly for a number of boards.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 947d4f132b4 ("regmap: fix range checks")

On the 32bit ARM sandbox 'dm ut dm_test_devm_regmap' fails with an abort.
This is due to incorrect range checks.

On 32-bit systems the size of size_t and int is both 32 bit. The expression
(offset + val_len) is bound to overflow if offset == -1. Add an overflow
check.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The devres_alloc() function is intended to avoid the need for freeing
memory, although in practice it may not be enabled, thus leading to a true
leak.

Nevertheless this is intended. Add a comment.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 312951)

There is a serious bug in regmap_read() and regmap_write() functions
where an uint pointer is cast to (void *) which is then cast to (u8 *),
(u16 *), (u32 *) or (u64 *), depending on register width of the map.

For example given a regmap with 16-bit register width the code
	int val = 0x12340000;
	regmap_read(map, 0, &val);
only changes the lower 16 bits of val on little-endian machines.
The upper 16 bits will remain 0x1234.

Nobody noticed this probably because this bug can be triggered with
regmap_write() only on big-endian architectures (which are not used by
many people anymore), and on little endian this bug has consequences
only if register width is 8 or 16 bits and also the memory place to
which regmap_read() should store it's result has non-zero upper bits,
which it seems doesn't happen anywhere in U-Boot normally. CI managed to
trigger this bug in unit test of dm_test_devm_regmap_field when compiled
for sandbox_defconfig using LTO.

Fix this by utilizing an union { u8; u16; u32; u64; } and reading data
into this union / writing data from this union.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Pratyush Yadav <p.yadav@ti.com>