We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
We should not use typedefs in U-Boot. They cannot be used as forward
declarations which means that header files must include the full header to
access them.
Drop the typedef and rename the struct to remove the _s suffix which is
now not useful.
This requires quite a few header-file additions.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present these functions return 0 on success. For some devices we want
to know how many bytes were transferred. It seems useful to adjust the API
to be more like the POSIX read() and write() functions.
Update these two methods, a test and all users.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
With the dev_read_addr_ptr function available, we can change the
efuse driver to use it (and eliminate the explicit type-cast).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This changes the rockchip-efuse driver to use dev_read_addr instead of
devfdt_get_addr.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
This adds a simple driver for reading the efuse block of the RK3399.
It should be easy enough to add drivers for other devices (e.g. the
RK3328, RK3368, etc.) by passing the device details via driver_data.
Unlike the kernel driver (using the nvmem subsystem), we don't expose
the efuse as multiple named cells, but rather as a linear memory that
can be read using misc_read(...).
The primary use case (as of today) is the generation of a 'serial#'
(and a 'cpuid#') environment variable for the RK3399-Q7 (Puma)
system-on-module.
Note that this adds a debug-only (i.e. only if DEBUG is defined)
command 'rk3399_dump_efuses' that dumps the efuse block's content.
N.B.: The name 'rk3399_dump_efuses' was intentionally chosen to
include a SoC-name (together with a comment in the function) to
remind whoever adds support for additional SoCs that this
function currently makes assumptions regarding the size of the
fuse-box based on the RK3399. The hope is that the function is
adjusted to reflect any changes resulting from generalising the
driver for multiple SoCs and is then renamed.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
