Add a feature to suppress commands. The suppressed commands are not
logged on the command reception.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Add a user possibility to set a callback for receiving a new function.
It allows instant performing some actions, that need to be done before
context switch.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Verify validity of a received command before passing it to the general
handler.
It allows performing some actions, right after receiving the command.
The context switch is not needed. Such feature may be needed for
overloaded system, where instant reboot is required.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Add a function to signal a new host command by a backend.
Use a function instead of giving semaphore, because it allows more
actions on rx event, common for all backends.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Add a config to save the final result of a last host command that has
sent EC_HOST_CMD_IN_PROGRESS response. To get the final result use the
ec_host_cmd_send_in_progress_status function.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The sizeof is used in a wrong way which causes incorrect checking a
version of a command. Use NUM_BITS instead.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The response buffer has to be cleared every command not to pass
unintended content e.g. response from a previous command, or stack
content.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Update the response buffer size, passed to a command handler, every
command, since a backend could change it in runtime.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Add a native way to log Host Command communication.
Use Zephyr logging system to do it. Use debug and normal levels.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Use one common function to send Host Command response. It allows
handling all response types within one function.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The IN_PROGRESS status is a specital status that can be sent during
handling a host command. Synchronous backends don't support it, so
an additional check is required.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
A function to send Host Command response is needed for commands that
that sends IN_PROGRESS status or doesn't return e.g. perform reboot.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Add a config to decide if a new dedicated thread for Host Command is
created during initialization.
If not, the ec_host_cmd_task has to be called by another thread to
handle host commands.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The general handler may provide buffers for a backend. Use ranges to
check if the provided buffer is used, because the backend may shift the
beginning of the buffer to make space for preamble.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Add a separate config to enable autoinitialization of the host command
subsystem, called by the chosen backend.
It allows setting the chosen backend without autoinit.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The application code may need inside information about the host command
e.g. the thread id. Add a function that returns the main host command
structure which contains such data.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add a new backend for Host Commands that uses UART. The backend bases
asynchronous UART API.
The UART backend is mainly used by FPMCU.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Rework the Host Command support. It includes:
-change API to backend
-change a way of defining rx and tx buffers
-fix synchronization between the handler and backend layer
-simplify the HC handler
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Follow naming pattern in the subsystems(logging or shell) and name
the layer between generic handler and peripheral driver "backend".
The name doesn't suit that well to the SHI backend, because there isn't
SHI API itself and the SHI interface is used only for the host
communication. So the backend code includes the peripheral driver itself.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The Host Commands can be used with different transport layers e.g. SHI
or eSPI. The code that provides the peripheral API and allows sending
and receiving Host Commands via different transport layers is not
actually drivers of a peripheral, so move it to the
subsys/mgmt/ec_host_cmd folder.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
This commit adds the support for host commands being transported
by the Serial Host Interface on the NPCX SoC.
Signed-off-by: Michał Barnaś <mb@semihalf.com>
Add missing fields in structure containing the arguments used by
the host commands handlers and change the order of parameters
in macro used for defining the handlers.
Signed-off-by: Michał Barnaś <mb@semihalf.com>
This commit increases the stack size for thread handling the host
commands requests. It was required due to the stack being
corrupted using earlier default size. The thread priority is now
configurable using the Kconfig.
It also adds alignment to the tx_buffer since the npcx MCU requires it
to work correctly and removes clearing the buffer before use due to
the hard time requirements. Tests checking if buffers are cleared
are also removed.
Signed-off-by: Michał Barnaś <mb@semihalf.com>
Move the header file to corresponding directory which refers to
submodule name instead of root of drivers directory.
Signed-off-by: Michał Barnaś <mb@semihalf.com>
Many device pointers are initialized at compile and never changed. This
means that the device pointer can be constified (immutable).
Automated using:
```
perl -i -pe 's/const struct device \*(?!const)(.*)= DEVICE/const struct
device *const $1= DEVICE/g' **/*.c
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
We are working on phasing out use of the devicetree 'label'
property. We can use DEVICE_DT_GET and drop use of DT_LABEL.
Signed-off-by: Kumar Gala <galak@kernel.org>
In order to bring consistency in-tree, migrate all subsystems 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 migrates all the current iterable section usages to the external
API, dropping the "Z_" prefix:
Z_ITERABLE_SECTION_ROM
Z_ITERABLE_SECTION_ROM_GC_ALLOWED
Z_ITERABLE_SECTION_RAM
Z_ITERABLE_SECTION_RAM_GC_ALLOWED
Z_STRUCT_SECTION_ITERABLE
Z_STRUCT_SECTION_ITERABLE_ALTERNATE
Z_STRUCT_SECTION_FOREACH
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Move ec_host_cmd.h out of the top level include/ dir into
include/mgmt/ec_host_cmd.h and deprecated the old location.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add a generic host command handler framework that allows users to
declare new host command handlers with the HOST_COMMAND_HANDLER macro
at build time. The framework will handle incoming messages from the
host command peripheral device and forwards the incoming data to the
appropriate host command handler, which is looked up by id.
The framework will also send the response from the handler back to the
host command peripheral device. The device handles sending the data on
the physical bus.
This type of host command communication is typically done on an embedded
controller for a notebook or computer. The host would be the main
application processor (aka AP, CPU, SoC).
Signed-off-by: Jett Rink <jettrink@google.com>
