From mboxrd@z Thu Jan 1 00:00:00 1970 From: Masahiro Yamada Date: Mon, 17 Apr 2017 11:26:54 +0900 Subject: [U-Boot] [PATCH v2 3/3] sysreset: psci: support system reset in a generic way with PSCI In-Reply-To: References: <1492051153-12817-1-git-send-email-yamada.masahiro@socionext.com> <1492051153-12817-4-git-send-email-yamada.masahiro@socionext.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, 2017-04-17 4:31 GMT+09:00 Simon Glass : > Hi Masahiro, > > On 12 April 2017 at 20:39, Masahiro Yamada > wrote: >> If the system is running PSCI firmware, the System Reset function >> (func ID: 0x80000009) is supposed to be handled by PSCI, that is, >> the SoC/board specific reset implementation should be moved to PSCI. >> U-Boot should call the PSCI service according to the arm-smccc >> manner. >> >> The arm-smccc is supported on ARMv7 or later. Especially, ARMv8 >> generation SoCs are likely to run ARM Trusted Firmware BL31. In >> this case, U-Boot is a non-secure world boot loader, so it should >> not be able to reset the system directly. >> >> Signed-off-by: Masahiro Yamada >> --- >> >> Changes in v2: None >> >> arch/arm/Kconfig | 1 + >> drivers/Kconfig | 2 + >> drivers/Makefile | 5 +- >> drivers/firmware/Kconfig | 6 +++ >> drivers/firmware/Makefile | 2 + >> drivers/firmware/firmware-uclass.c | 11 +++++ >> drivers/firmware/psci.c | 94 ++++++++++++++++++++++++++++++++++++++ >> drivers/sysreset/Kconfig | 10 ++++ >> drivers/sysreset/Makefile | 1 + >> drivers/sysreset/sysreset_psci.c | 41 +++++++++++++++++ >> include/dm/uclass-id.h | 1 + >> include/linux/psci.h | 13 ++++++ >> 12 files changed, 185 insertions(+), 2 deletions(-) >> create mode 100644 drivers/firmware/Kconfig >> create mode 100644 drivers/firmware/Makefile >> create mode 100644 drivers/firmware/firmware-uclass.c >> create mode 100644 drivers/firmware/psci.c >> create mode 100644 drivers/sysreset/sysreset_psci.c > > Reviewed-by: Simon Glass > > It is not clear what the firmware uclass is for. Also there are no > operations. How about adding a header file with at least a comment in > it? Actually, the firmware uclass does not provide any generalized operation, but in the DM framework, a driver must belong to some uclass. I thought about this a bit, then another idea is perhaps to re-use UCLASS_MISC instead of adding a new opaque uclass. We can use misc_ioctl() for PSCI call. -- Best Regards Masahiro Yamada