[U-Boot] [PATCH v2 3/3] sysreset: psci: support system reset in a generic way with PSCI

[Masahiro Yamada]

Hi Simon,


2017-04-17 4:31 GMT+09:00 Simon Glass <sjg at chromium.org>:
> Hi Masahiro,
>
> On 12 April 2017 at 20:39, Masahiro Yamada
> <yamada.masahiro at socionext.com> 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 <yamada.masahiro at socionext.com>
>> ---
>>
>> 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 <sjg at chromium.org>
>
> 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