The Linux® kernel reset framework offers a generic API for reset lines management at platform level.
1. Framework purpose[edit source]
The purpose of this article is to introduce the Linux kernel Reset Framework. It provides general information and, based on concrete IP use cases, explains how to use it.
The Linux Reset framework offers a generic API for abstracting and controlling the different reset lines of the platform.
Reset lines can be internal system reset signals or external lines such as a GPIO to reset an external device.
2. System overview[edit source]
2.1. Component description[edit source]
- reset core: kernel reset framework designed for abstracting device reset handling via GPIOs or internal reset controller modules.
- reset-stm32mp1: STM32MP1 RCC specific reset driver
- RCC: Reset and clock controller that generates the different internal reset lines on STM32MP1.
2.2. API description[edit source]
Documentation on the reset interface can be found in kernel documentation folder: https://www.kernel.org/doc/Documentation/devicetree/bindings/reset/reset.txt
- Kernel reset API
To get the line reset from DT:
- devm_reset_control_get_exclusive: looks up and obtains an exclusive reference to a reset controller (cannot be shared with another driver).
- devm_reset_control_get_shared: looks up and obtains a shared reference to reset a controller (can be shared with another driver).
- devm_reset_control_get: same as devm_reset_control_get_exclusive.
- devm_reset_control_get_optional: same as devm_reset_control_get except that the reference name is optional.
- devm_reset_control_get_optional_exclusive: same as devm_reset_control_get_exclusive except that the reference name is optional.
- devm_reset_control_get_optional_shared: same as devm_reset_control_get_shared except that the reference name is optional.
To configure the reset line and retrieve its status from DT:
- reset_control_assert: asserts the reset line
- reset_control_deassert: deasserts the reset line
- reset_control_status: returns if the line is asserted or not
3. Configuration[edit source]
3.1. Kernel configuration[edit source]
By default, the activation of the Reset framework configuration (CONFIG_RESET_CONTROLER) is selected in the kernel configuration, through the Linux Menuconfig tool: Menuconfig or how to configure kernel (CONFIG_ARCH_STM32=y, CONFIG_ARCH_MULTI_V7=y):
3.2. Device tree configuration[edit source]
A detailed device tree configuration is described in Reset device tree configuration.
4. How to use the Reset framework[edit source]
To control a peripheral reset line, a driver must first get a reference on the reset handler thanks to its device tree node.
The driver can then assert and deassert the reset line by calling the reset framework API.
Below an example:
foo: foo@adcdefgh {
compatible = "foo-driver";
...
resets = <&rcc FOO_R>;
...
};
Before using the reset specified in the device tree node, the foo driver has to request it at probe execution.
static int foo_probe(struct platform_device *pdev)
{
struct reset_control *rst;
...
rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
if (IS_ERR(rst)) {
ret = PTR_ERR(rest);
dev_err(&pdev->dev, "reset get failed: %d\n", ret);
goto err_master_put;
}
...
The reset can then be asserted or deasserted using the reset framework API:
...
reset_control_assert(rst);
udelay(2);
reset_control_deassert(rst);
...
5. Source code location[edit source]
Reset core file [1]
STM32MP1 reset file [2]
STM32MP1 reset interface file [3]
6. References[edit source]