The type of the resource table is known, casting to and from void* only
hides this type which can prevent the compiler from giving helpful
warnings. One warning would have been the accidental use of
"st_resource_table" in a cast, a struct which does not exist.
Use the fw_resource_table type when dealing with resource tables.
Signed-off-by: Andrew Davis <afd@ti.com>
This structure is shared between cores which may have different type
widths. Use fixed width types when defining the structure. We can
also use struct resource_table to help as it is already defined with
fixed width types and removes the need to redefine these elements.
Signed-off-by: Andrew Davis <afd@ti.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In order to bring consistency in-tree, migrate all lib code to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This allows a resource table to be included even if neither virtIO nor the
RAM console are used.
Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
The resource table is needed by the Linux kernel OS
for a rpmsg generic support, but is also recognised by OpenAMP.
This table allows to add trace based on the RAM console
and to support rpmsg protocol.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
