mbox series

[v4,0/6] xen/arm: Add support for S32CC platforms and LINFlexD UART

Message ID 20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com (mailing list archive)
Headers show
Series xen/arm: Add support for S32CC platforms and LINFlexD UART | expand

Message

Andrei Cherechesu Dec. 19, 2024, 11:23 a.m. UTC
From: Andrei Cherechesu <andrei.cherechesu@nxp.com>

Targeting: Xen 4.20
This v4 version of this patch series finishes the work left to support NXP
S32G3 Processors [0], part of the NXP S32CC Family. The LINFlexD UART support
patches have been merged in v2. Platforms using S32G3 Processors are not
affected by the TLBI by VA erratum (discussed in v2), and are security
supported without a workaround needed in Xen or guests. The workaround needed
for S32G2 [1] / S32R45 [2] will be addressed in future series.

The 1st patch introduces a generic mechanism for forwarding SCMI
over SMC calls to firmware running at EL3, selected via
CONFIG_SCMI_SMC. The 2nd patch refactors the SiP SMC handling in
vSMC mechanism, to rely firstly on `platform_smc()` if implemented,
then on the previously introduced generic SCMI handling/forwarding
mechanism.

The 3rd patch adds S32G3 platform config to enable the required drivers for
S32G3-based platforms.

The 4th, 5th and 6th patches modify the CHANGELOG.md, SUPPORT.md
and MAINTAINERS files, respectively, to add mentions about LINFlexD
UART support, S32G3 Processors support, and the new SCMI-SMC layer
introduced.

[0] https://www.nxp.com/products/S32G3
[1] https://www.nxp.com/products/S32G2
[2] https://www.nxp.com/products/S32R45

v3->v4:
  - SCMI-SMC handling layer (Patch [v4,1/6]):
    - Changed license for scmi-smc.c and scmi-smc.h to GPLv2-only
    - Renamed `scmi_support` bool variable to `scmi_enabled`
    - Dropped `scmi_is_enabled()` public function. Driver's internal state is
      now managed internally and based on `scmi_enabled` var. The public
      stub `scmi_handle_smc()` checks first `scmi_enabled`, instead of letting
      callers do this work.
    - Dropped include statement for <asm/regs.h>, replaced with forward
      declaration for `struct cpu_user_regs`
    - Addressed indentation issue for `err` label
    - Changed the `gprintk` from `scmi_handle_smc()` to `gdprintk`, and dropped
      redundant info in the print statement.
  - Handling SiP as SCMI SMC (Patch [v4,2/6]):
    - Dropped usage of `scmi_is_enabled()` since SCMI-SMC driver state is now
      managed internally

v2->v3:
  - linflex-uart (Patch [v2,1/8] and [v2,2/8], now dropped):
    - Patches merged in v2, no longer re-submitted
  - SCMI-SMC handling layer (Patch [v2,3/8], now [v3,1/6]):
    - Changed occurrences of calls coming from "Dom0", to "hwdom" or "hardware
      domain"
    - Made initialization part of initcall chain instead of presmp_initcall
    - Changed occurrences related to "Dom0 DT", to "Host DT"
    - Made `scmi_support` and `scmi_smc_id` variables __ro_after_init
    - Used `current->domain` to print domain ID (with `%pd` formatter)
    - Dropped usage of local string var `smc_id_prop` to store "arm,smc-id"
    - Added usage of XENLOG_* levels to all prints
    - Changed print in `scmi_check_smccc_ver()` to XENLOG_WARNING
    - If `scmi_check_smccc_ver()` fails, initialization fails silently (only
      printing a warning regarding no SMCCC support) since it's optional
    - Made `scmi_is_valid_smc_id()` private to the driver and used it in
      `scmi_handle_smc()` instead of requiring usage by its callers
    - Created a 'firmware' folder in xen/arch/arm, to store the SCMI related
      code, and moved the SCMI-SMC layer implementation there
  - Handling SiP as SCMI SMC (Patch [v2,4/8] now [v3,2/6]):
    - Dropped implementation-specific details in commit message and code
      comments
  - S32G3 platform config (Patch [v2,5/8] now [v3,3/6]):
    - As motivated at the beginning of this cover letter, changed the config
      name and description from S32CC to S32G3
    - Dropped the `s32cc.c` dummy platform code and the CONFIG_S32CC_PLATFORM
      used to enable its compilation
    - Dropped Stefano's "Reviewed-by", since patch had non-trivial changes.
      Please re-approve.
  - CHANGELOG.md (Patch [v2,6/8] now [v3,4/6]):
    - Changed 'dom0' to 'hwdom'
    - Changed S32CC to S32G3, as motivated at the beginning of the cover letter
    - Rephrased to drop the 'Add' word since the entries are already part of
      the 'Added' category
    - Dropped Stefano's and Oleksii's "Acked-by", since patch had non-trivial
      changes. Please re-approve.
  - SUPPORT.md (Patch [v2,7/8] now [v3,5/6]):
    - Changed 'dom0' to 'hwdom'
    - Changed 'Dom0 DT' to 'Host DT'
  - MAINTAINERS (Patch [v2,8/8] now [v3,6/6]):
    - Dropped `linflex-uart.c` driver from ARM Architecture list
    - Dropped `s32cc.c` platform file since it's been dropped from Patch
      [v3,3/6]
    - Changed S32CC to S32G3, as motivated at the beginning of the cover letter
    - Dropped Stefano's "Acked-by", since patch had non-trivial changes. Please
      re-approve.

v1->v2:
  - linflex-uart: 
    - Addressed coding style comments from Julien:
      - spaces vs. tabs
      - indentation
      - license issue
      - comments format
      - code reusage
      - misplaced loop exit
    - Made the pointer to struct linflex_uart const in most functions
    since it's not modified
    - Added support for customizable baud rate through console options,
    parsing what Xen gets in its bootargs. other parameters following
    <baud> are discarded for the moment.
  - SCMI SMC handling:
    - Added a generic `scmi-smc` layer (enabled by CONFIG_SCMI_SMC)
    to enable forwarding SCMI requests over SMC to EL3 FW if issued
    by Dom0. If the SCMI firmware node is not found in Dom0's DT during
    initialization, it fails silently as it's not mandatory.
    - Changed the handling for SiP SMCs in vsmc.c to firstly try
    the `platform_smc()` callback if implemented, then try to
    handle the SiP SMC as SCMI if enabled and SMC ID matches.
  - S32CC Platform support:
    - Added dependency on CONFIG_SCMI_SMC
    - Removed the S32CC platform-specific forwarding to EL3 mechanism.
    - Dropped unused headers
  - CHANGELOG.md:
    - Added mentions about S32CC support and SCMI-SMC layer.
  - SUPPORT.md:
    - Added SCMI over SMC forwarding to EL3 feature for Arm as supported.
  - MAINTAINERS:
    - Added myself as maintainer for S32CC platforms and NXP S32 Linux Team
    as reviewer list.

Andrei Cherechesu (6):
  xen/arm: firmware: Add SCMI over SMC calls handling layer
  xen/arm: vsmc: Enable handling SiP-owned SCMI SMC calls
  xen/arm: platforms: Add NXP S32G3 Processors config
  CHANGELOG.md: Add NXP S32G3 and SCMI-SMC layer support mentions
  SUPPORT.md: Describe SCMI-SMC layer feature
  MAINTAINERS: Add myself as maintainer for NXP S32G3

 CHANGELOG.md                                 |   3 +
 MAINTAINERS                                  |   6 +
 SUPPORT.md                                   |   8 +
 xen/arch/arm/Kconfig                         |   2 +
 xen/arch/arm/Makefile                        |   1 +
 xen/arch/arm/firmware/Kconfig                |  13 ++
 xen/arch/arm/firmware/Makefile               |   1 +
 xen/arch/arm/firmware/scmi-smc.c             | 162 +++++++++++++++++++
 xen/arch/arm/include/asm/firmware/scmi-smc.h |  41 +++++
 xen/arch/arm/platforms/Kconfig               |   8 +
 xen/arch/arm/vsmc.c                          |  13 +-
 11 files changed, 257 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/firmware/Kconfig
 create mode 100644 xen/arch/arm/firmware/Makefile
 create mode 100644 xen/arch/arm/firmware/scmi-smc.c
 create mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

Comments

Michal Orzel Dec. 20, 2024, 7:32 a.m. UTC | #1
On 19/12/2024 12:23, Andrei Cherechesu (OSS) wrote:
> 
> 
> From: Andrei Cherechesu <andrei.cherechesu@nxp.com>
> 
> Targeting: Xen 4.20
> This v4 version of this patch series finishes the work left to support NXP
> S32G3 Processors [0], part of the NXP S32CC Family. The LINFlexD UART support
> patches have been merged in v2. Platforms using S32G3 Processors are not
> affected by the TLBI by VA erratum (discussed in v2), and are security
> supported without a workaround needed in Xen or guests. The workaround needed
> for S32G2 [1] / S32R45 [2] will be addressed in future series.
> 
> The 1st patch introduces a generic mechanism for forwarding SCMI
> over SMC calls to firmware running at EL3, selected via
> CONFIG_SCMI_SMC. The 2nd patch refactors the SiP SMC handling in
> vSMC mechanism, to rely firstly on `platform_smc()` if implemented,
> then on the previously introduced generic SCMI handling/forwarding
> mechanism.
> 
> The 3rd patch adds S32G3 platform config to enable the required drivers for
> S32G3-based platforms.
> 
> The 4th, 5th and 6th patches modify the CHANGELOG.md, SUPPORT.md
> and MAINTAINERS files, respectively, to add mentions about LINFlexD
> UART support, S32G3 Processors support, and the new SCMI-SMC layer
> introduced.
> 
> [0] https://www.nxp.com/products/S32G3
> [1] https://www.nxp.com/products/S32G2
> [2] https://www.nxp.com/products/S32R45
> 
The series is now committed. Thanks.

~Michal
Andrei Cherechesu Dec. 20, 2024, 1:31 p.m. UTC | #2
Hi,


On 20/12/2024 09:32, Michal Orzel wrote:
>
> On 19/12/2024 12:23, Andrei Cherechesu (OSS) wrote:
>>
>> From: Andrei Cherechesu <andrei.cherechesu@nxp.com>
>>
>> Targeting: Xen 4.20
>> This v4 version of this patch series finishes the work left to support NXP
>> S32G3 Processors [0], part of the NXP S32CC Family. The LINFlexD UART support
>> patches have been merged in v2. Platforms using S32G3 Processors are not
>> affected by the TLBI by VA erratum (discussed in v2), and are security
>> supported without a workaround needed in Xen or guests. The workaround needed
>> for S32G2 [1] / S32R45 [2] will be addressed in future series.
>>
>> The 1st patch introduces a generic mechanism for forwarding SCMI
>> over SMC calls to firmware running at EL3, selected via
>> CONFIG_SCMI_SMC. The 2nd patch refactors the SiP SMC handling in
>> vSMC mechanism, to rely firstly on `platform_smc()` if implemented,
>> then on the previously introduced generic SCMI handling/forwarding
>> mechanism.
>>
>> The 3rd patch adds S32G3 platform config to enable the required drivers for
>> S32G3-based platforms.
>>
>> The 4th, 5th and 6th patches modify the CHANGELOG.md, SUPPORT.md
>> and MAINTAINERS files, respectively, to add mentions about LINFlexD
>> UART support, S32G3 Processors support, and the new SCMI-SMC layer
>> introduced.
>>
>> [0] https://www.nxp.com/products/S32G3
>> [1] https://www.nxp.com/products/S32G2
>> [2] https://www.nxp.com/products/S32R45
>>
> The series is now committed. Thanks.
>
> ~Michal

Thank you too, Michal, for all the quick feedback you provided!
Glad we've been able to get this in despite the busy period right
before FF for you guys.

I also wanted to thank Julien, Stefano, Grygorii, Oleksii, Bertrand,
Andrew and everyone else who spent time and effort on this series :)

Wish you all relaxing and happy Holidays!

Best regards,
Andrei Cherechesu

>