| Message ID | 20191220102638.154206-1-kamel.bouhara@bootlin.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v5,1/2] power: reset: Introduce generic reset reason | expand |
On 12/20/19 2:26 AM, Kamel Bouhara wrote: > This introduce some generic sources of reset reason to expose through > sysfs interface. Update the ABI documentation to list current power on > sources. > > Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com> > Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> > --- > Changes in v2 > ============= > - Be less specific on the crystal oscillator value > - Add an Acked-by > Changes in v3 > ============= > - Really be less specific on the crystal oscillator value > Changes in v4 > ============= > - Rebase to 5.5-rc2 > - Remove remaining crystal specific value in documentation > - Split the patch for the sake of clarity > - Match the documentation with the actual header defines > Changes in v5 > ============= > - Reorder patches for the sake of bisectability You may extract some common names among various SoC vendors for some reset reasons but their semantic is inherently specific to the reset architecture of the SoC and their meaning is very scope specific. For instance, on the SoCs that I work with (ARCH_BRCMSTB), here would be the possible reset reasons: "aux_chip_edge_0" "aux_chip_edge_1", "aux_chip_level_0" "aux_chip_level_1" "avs_watchdog" "cpu_ejtag" "front_panel_4sec" "gen_watchdog_1" "main_chip_input" "mpm" "overtemp" "overvoltage_1" "pcie_0_hot_boot" "pcie_1_hot_boot" "power_on" "s3_wakeup" "security_master "smartcard_insert" "software_master" "tap_in_system" "undervoltage_0" "undervoltage_1" "watchdog_timer" So out of the list you have defined, we share about two to three, and the rest appear to be AT91 specific. I am not sure the abstraction is at the right level here with trying to come up with some generically applicable set of reset reasons which sounds like people will either have to overlay their own reset reasons after the generic ones, or they will just replace them. Standardizing on the sysfs attribute name has value, and maybe that's where the abstraction should be, you offer a set of functions that allow the registration of a sysfs attribute at the right location in the sysfs device hierarchy, and allow passing a driver specific callback for returning a string and that callback can do the decoding internally?
diff --git a/Documentation/ABI/testing/sysfs-devices-platform-power-on-reason b/Documentation/ABI/testing/sysfs-devices-platform-power-on-reason new file mode 100644 index 000000000000..918ab178fee7 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-power-on-reason @@ -0,0 +1,12 @@ +What: /sys/devices/platform/.../power_on_reason + +Date: October 2019 +KernelVersion: 5.5 +Contact: Kamel Bouhara <kamel.bouhara@bootlin.com> +Description: This file shows system power on reason. + The possible sources are: + General System Power-ON, RTC wakeup, Watchdog timeout, + Software reset, User reset button, CPU clock failure, + Oscillator Failure, Low power mode exit, Unknown. + + The file is read only. diff --git a/include/linux/power/power_on_reason.h b/include/linux/power/power_on_reason.h new file mode 100644 index 000000000000..5ef8e78f3de4 --- /dev/null +++ b/include/linux/power/power_on_reason.h @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Author: Kamel Bouhara <kamel.bouhara@bootlin.com> + */ + +#ifndef POWER_ON_REASON_H +#define POWER_ON_REASON_H + +#define POWER_ON_REASON_GENERAL "General system power-on" +#define POWER_ON_REASON_RTC "RTC wakeup" +#define POWER_ON_REASON_WATCHDOG "Watchdog timeout" +#define POWER_ON_REASON_SOFTWARE "Software reset" +#define POWER_ON_REASON_USER "User reset button" +#define POWER_ON_REASON_CPU_FAIL "CPU clock failure" +#define POWER_ON_REASON_XTAL_FAIL "Crystal oscillator failure" +#define POWER_ON_REASON_LOW_POWER "Low power mode exit" +#define POWER_ON_REASON_UNKNOWN "Unknown" + +#endif /* POWER_ON_REASON_H */