drivers: use dev_read_addr_ptr when cast to pointer

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 use
dev_read_addr_ptr instead of the dev_read_addr function in the
various files in the drivers directory that cast to a pointer.
As we are there also streamline the error response to -EINVAL on return.

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

dm: core: Update docs about oftree_from_fdt()

Update this function's comment and also the livetree documentation, so it
is clear when to use the function.

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

dm: core: Allow copying ofnode property data when writing

At present ofnode_write_prop() is inconsistent between livetree and
flattree, in that livetree requires the caller to ensure the property
value is stable (e.g. in rodata or allocated) but flattree does not, since
it makes a copy.

This makes the API call a bit painful to use, since the caller must do
different things depending on OF_LIVE.

Add a new 'copy' argument which tells the function to make a copy if
needed. Add some tests to cover this behaviour.

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

dm: core: Expand ofnode tests

The current tests do not cover all functions, nor do they cover the new
multi-tree functionality. Add and update the tests accordingly and update
the 'future work' notes in the documentation.

There is a still more testing needed for the failure cases, since at
present some ofnode functions return a libfdt error code instead of
converting it to an errno.

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

dm: core: Add the ofnode multi-tree implementation

Add the logic to redirect requests for the device tree through a function
which can look up the tree ID. This works by using the top bits of
ofnode.of_offset to encode a tree.

It is assumed that there will only be a few device trees used at runtime,
typically the control FDT (always tree ID 0) and possibly a separate FDT
to be passed the OS.

The maximum number of device trees supported at runtime is 8, with this
implementation. That would use bits 30:28 of the node-offset value,
meaning that the positive offset range is limited to bits 27:0, versus
30:1 with this feature disabled. That still allows a device tree of up
to 256MB, which should be enough for most FITs. Larger ones can be
supported by using external data with the FIT, or by enabling OF_LIVE.

Update the documentation a little and fix up the comment for
ofnode_valid().

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

test: Make a copy of the device tree before running a test

When the flat device tree changes it can mess up the live tree since that
uses the flat tree for its strings. This affects only a few sandbox tests
which modify the device tree, but the number will grow as ofnode support
for writing improves.

While the control FDT is not intended to change while U-Boot is running,
some tests do so. For example, the ofnode interface only supports
modifying properties in the control FDT, so tests must use that.

To solve this problem, keep a copy of the FDT and restore it as needed
when the test is finished. The copy only happens on sandbox (except SPL
builds), to reduce memory usage and because these tests are not useful on
other boards. For other boards, a checksum is taken to ensure that nothing
changes.

It would be possible to always checksum the FDT on sandbox and only
restore it if needed, but this is slightly slower than restoring it every
time, at least with crc8.

Move the code which checks for success to the very end, for clarity.

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

dm: core: Prepare for updating the device tree with ofnode

Add some documentation and a new flag so that we can safely enabled using
the ofnode interface to write to the device tree.

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

dm: core: Introduce support for multiple trees

At present ofnode only works with a single device tree, for the most part.
This is the control FDT used by U-Boot.

When booting an OS we may obtain a different device tree and want to
modify it. Add some initial support for this into the ofnode API.

Note that we don't permit aliases in this other device tree, since the
of_access implementation maintains a list of aliases collected at
start-up. Also, we don't need aliases to do fixups in the other FDT. So
make sure that flat tree and live tree processing are consistent in this
area.

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

dm: core: Add a note about how livetree updates work

The unflattening algorithm results in a single block of memory being
allocated for the whole tree. When writing new properties, these are
allocated new memory outside that block. When the block is freed, the
allocated properties remain.

Document how this works and the potential memory leak, as well as
mentioning that updating the livetree is actually supported now.

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

doc: Move driver model docs under develop/

These docs are useful for developers, not users. Move them under that
section.

Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>

dm: core: Update docs about oftree_from_fdt()

Update this function's comment and also the livetree documentation, so it
is clear when to use the function.

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

dm: core: Allow copying ofnode property data when writing

At present ofnode_write_prop() is inconsistent between livetree and
flattree, in that livetree requires the caller to ensure the property
value is stable (e.g. in rodata or allocated) but flattree does not, since
it makes a copy.

This makes the API call a bit painful to use, since the caller must do
different things depending on OF_LIVE.

Add a new 'copy' argument which tells the function to make a copy if
needed. Add some tests to cover this behaviour.

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

dm: core: Expand ofnode tests

The current tests do not cover all functions, nor do they cover the new
multi-tree functionality. Add and update the tests accordingly and update
the 'future work' notes in the documentation.

There is a still more testing needed for the failure cases, since at
present some ofnode functions return a libfdt error code instead of
converting it to an errno.

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

dm: core: Add the ofnode multi-tree implementation

Add the logic to redirect requests for the device tree through a function
which can look up the tree ID. This works by using the top bits of
ofnode.of_offset to encode a tree.

It is assumed that there will only be a few device trees used at runtime,
typically the control FDT (always tree ID 0) and possibly a separate FDT
to be passed the OS.

The maximum number of device trees supported at runtime is 8, with this
implementation. That would use bits 30:28 of the node-offset value,
meaning that the positive offset range is limited to bits 27:0, versus
30:1 with this feature disabled. That still allows a device tree of up
to 256MB, which should be enough for most FITs. Larger ones can be
supported by using external data with the FIT, or by enabling OF_LIVE.

Update the documentation a little and fix up the comment for
ofnode_valid().

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

test: Make a copy of the device tree before running a test

When the flat device tree changes it can mess up the live tree since that
uses the flat tree for its strings. This affects only a few sandbox tests
which modify the device tree, but the number will grow as ofnode support
for writing improves.

While the control FDT is not intended to change while U-Boot is running,
some tests do so. For example, the ofnode interface only supports
modifying properties in the control FDT, so tests must use that.

To solve this problem, keep a copy of the FDT and restore it as needed
when the test is finished. The copy only happens on sandbox (except SPL
builds), to reduce memory usage and because these tests are not useful on
other boards. For other boards, a checksum is taken to ensure that nothing
changes.

It would be possible to always checksum the FDT on sandbox and only
restore it if needed, but this is slightly slower than restoring it every
time, at least with crc8.

Move the code which checks for success to the very end, for clarity.

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

dm: core: Prepare for updating the device tree with ofnode

Add some documentation and a new flag so that we can safely enabled using
the ofnode interface to write to the device tree.

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

dm: core: Introduce support for multiple trees

At present ofnode only works with a single device tree, for the most part.
This is the control FDT used by U-Boot.

When booting an OS we may obtain a different device tree and want to
modify it. Add some initial support for this into the ofnode API.

Note that we don't permit aliases in this other device tree, since the
of_access implementation maintains a list of aliases collected at
start-up. Also, we don't need aliases to do fixups in the other FDT. So
make sure that flat tree and live tree processing are consistent in this
area.

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

dm: core: Add a note about how livetree updates work

The unflattening algorithm results in a single block of memory being
allocated for the whole tree. When writing new properties, these are
allocated new memory outside that block. When the block is freed, the
allocated properties remain.

Document how this works and the potential memory leak, as well as
mentioning that updating the livetree is actually supported now.

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

doc: Move driver model docs under develop/

These docs are useful for developers, not users. Move them under that
section.

Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>

dm: core: Allow copying ofnode property data when writing

At present ofnode_write_prop() is inconsistent between livetree and
flattree, in that livetree requires the caller to ensure the property
value is stable (e.g. in rodata or allocated) but flattree does not, since
it makes a copy.

This makes the API call a bit painful to use, since the caller must do
different things depending on OF_LIVE.

Add a new 'copy' argument which tells the function to make a copy if
needed. Add some tests to cover this behaviour.

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

dm: core: Expand ofnode tests

The current tests do not cover all functions, nor do they cover the new
multi-tree functionality. Add and update the tests accordingly and update
the 'future work' notes in the documentation.

There is a still more testing needed for the failure cases, since at
present some ofnode functions return a libfdt error code instead of
converting it to an errno.

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

dm: core: Add the ofnode multi-tree implementation

Add the logic to redirect requests for the device tree through a function
which can look up the tree ID. This works by using the top bits of
ofnode.of_offset to encode a tree.

It is assumed that there will only be a few device trees used at runtime,
typically the control FDT (always tree ID 0) and possibly a separate FDT
to be passed the OS.

The maximum number of device trees supported at runtime is 8, with this
implementation. That would use bits 30:28 of the node-offset value,
meaning that the positive offset range is limited to bits 27:0, versus
30:1 with this feature disabled. That still allows a device tree of up
to 256MB, which should be enough for most FITs. Larger ones can be
supported by using external data with the FIT, or by enabling OF_LIVE.

Update the documentation a little and fix up the comment for
ofnode_valid().

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

test: Make a copy of the device tree before running a test

When the flat device tree changes it can mess up the live tree since that
uses the flat tree for its strings. This affects only a few sandbox tests
which modify the device tree, but the number will grow as ofnode support
for writing improves.

While the control FDT is not intended to change while U-Boot is running,
some tests do so. For example, the ofnode interface only supports
modifying properties in the control FDT, so tests must use that.

To solve this problem, keep a copy of the FDT and restore it as needed
when the test is finished. The copy only happens on sandbox (except SPL
builds), to reduce memory usage and because these tests are not useful on
other boards. For other boards, a checksum is taken to ensure that nothing
changes.

It would be possible to always checksum the FDT on sandbox and only
restore it if needed, but this is slightly slower than restoring it every
time, at least with crc8.

Move the code which checks for success to the very end, for clarity.

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

dm: core: Prepare for updating the device tree with ofnode

Add some documentation and a new flag so that we can safely enabled using
the ofnode interface to write to the device tree.

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

dm: core: Introduce support for multiple trees

At present ofnode only works with a single device tree, for the most part.
This is the control FDT used by U-Boot.

When booting an OS we may obtain a different device tree and want to
modify it. Add some initial support for this into the ofnode API.

Note that we don't permit aliases in this other device tree, since the
of_access implementation maintains a list of aliases collected at
start-up. Also, we don't need aliases to do fixups in the other FDT. So
make sure that flat tree and live tree processing are consistent in this
area.

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

dm: core: Add a note about how livetree updates work

The unflattening algorithm results in a single block of memory being
allocated for the whole tree. When writing new properties, these are
allocated new memory outside that block. When the block is freed, the
allocated properties remain.

Document how this works and the potential memory leak, as well as
mentioning that updating the livetree is actually supported now.

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

doc: Move driver model docs under develop/

These docs are useful for developers, not users. Move them under that
section.

Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>

dm: core: Prepare for updating the device tree with ofnode

Add some documentation and a new flag so that we can safely enabled using
the ofnode interface to write to the device tree.

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

dm: core: Introduce support for multiple trees

At present ofnode only works with a single device tree, for the most part.
This is the control FDT used by U-Boot.

When booting an OS we may obtain a different device tree and want to
modify it. Add some initial support for this into the ofnode API.

Note that we don't permit aliases in this other device tree, since the
of_access implementation maintains a list of aliases collected at
start-up. Also, we don't need aliases to do fixups in the other FDT. So
make sure that flat tree and live tree processing are consistent in this
area.

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

dm: core: Add a note about how livetree updates work

The unflattening algorithm results in a single block of memory being
allocated for the whole tree. When writing new properties, these are
allocated new memory outside that block. When the block is freed, the
allocated properties remain.

Document how this works and the potential memory leak, as well as
mentioning that updating the livetree is actually supported now.

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

doc: Move driver model docs under develop/

These docs are useful for developers, not users. Move them under that
section.

Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>

doc: Move driver model docs under develop/

These docs are useful for developers, not users. Move them under that
section.

Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>