mbox series

[v3,0/9] Make SCMI transport as standalone drivers

Message ID 20240730133318.1573765-1-cristian.marussi@arm.com (mailing list archive)
Headers show
Series Make SCMI transport as standalone drivers | expand

Message

Cristian Marussi July 30, 2024, 1:33 p.m. UTC
Hi all,

Till now the SCMI transport layer was being built embedded into in the core
SCMI stack.

Some of these transports, despite being currently part of the main SCMI
module, are indeed also registered with different subsystems like optee or
virtio, and actively probed also by those: this led to a few awkward and
convoluted tricks to properly handle such interactions at boot time in the
SCMI stack.

Moreover some partner expressed the desire to be able to fully modularize
the transports components.

This series aim to make all such transports as standalone drivers that can
be optionally loaded as modules.

In order to do this, at first some new mechanism is introduced to support
this new capability while maintaining, in parallel, the old legacy embedded
transports; then each transport, one by one, is transitioned to be a
standalone driver and finally the old legacy support for embedded transport
is removed.

Patch [1/9] is a fix around the chan_free method for OPTEE transport; it is
really unrelated to this series, but included to avoid conflicts.

Patch [2/9] is a mostly unrelated (but much needed) clean-up from Peng,
which I included in this series to avoid conflicts at merge.

Patch [3/9] simply collects the existing datagram manipulation helpers in a
pair of function pointers structures, in preparation for later reworks.

Patch [4/9] adds the bulk of the new logic to the core SCMI stack and then
each existing transport is transitioned to be a standalone driver in
patches 5,6,7,8 while shuffling around the compatibles. (no DT change is
needed of curse for backward compatibility)
While doing this I kept the module authorship in line with the main
author(S) as spitted out by git-blame.

Finally patch [9/9] removes all the legacy dead code from the core SCMI
stack.

No new symbol EXPORT has been added.

The new transport drivers have been tested, as built-in and LKM, as
follows:

- mailbox on JUNO
- virtio on emulation
- optee on QEMU/optee using Linaro setup

Exercised using the regular SCMI drivers stack and the SCMI ACS suite,
testing commands, replies, delayed responses and notification.

Multiple virtual SCMI instances support has been tested too.

SMC has NOT been tested/exercised at run-time, only compile-tested.
(due to lack of hardware)

Note that in this new setup, all the probe deferral and retries between the
SCMI core stack and the transports has been removed, since no more needed.

Moreover the new drivers have been tested also with a fully modularized
SCMI stack, i.e.:

  scmi-core.ko + scmi-module.ko + scmi_transport_*.ko [ + vendor modules ]

Based on v6.11-rc1

Any feedback, and especially testing (:D) is welcome.

Thanks,
Cristian

---
v2 --> v3
- rebased on v6.11-rc1
- fixed spacing in Kconfig
- fixed Copyrights all over
- fixed platform_driver_register callsite in OPTEE transport
- refactored DEFINE_SCMI_TRANSPORT_DRIVER() to:
  + use alloc + add_data + add platform drivers methods so as to implictly
    use a standard default device_release method.
  + drop .remove method in favour of devres_add_action_or_reset
  + use explicit parameter passing (no more concatenation)
- renamed scmi_transport_lookup() to scmi_transport_setup()
- use IOMEM_ERR_PTR to avoid sparse issues

v1 --> v2
- fixed setup_shmem_iomap to address also SMC needs (QC/nikunj)
  (silencing also warnings by kernel test robot <lkp@intel.com>)
- using __free OF cleanup.h magic in setup_shmme_iomap
- properly handle platform_driver_register() failures (Dan)
- fixed a few commit message style
- added a few missing static in scmi_desc
  (addresses warnings by kernel test robot <lkp@intel.com>)


Cristian Marussi (8):
  firmware: arm_scmi: Fix double free in OPTEE transport
  firmware: arm_scmi: Introduce packet handling helpers
  firmware: arm_scmi: Add support for standalone transport drivers
  firmware: arm_scmi: Make MBOX transport a standalone driver
  firmware: arm_scmi: Make SMC transport a standalone driver
  firmware: arm_scmi: Make OPTEE transport a standalone driver
  firmware: arm_scmi: Make VirtIO transport a standalone driver
  firmware: arm_scmi: Remove legacy transport-layer code

Peng Fan (1):
  firmware: arm_scmi: Introduce setup_shmem_iomap

 drivers/firmware/arm_scmi/Kconfig             |  20 +-
 drivers/firmware/arm_scmi/Makefile            |   9 +-
 drivers/firmware/arm_scmi/common.h            | 184 +++++++++++++-----
 drivers/firmware/arm_scmi/driver.c            | 142 +++++---------
 drivers/firmware/arm_scmi/msg.c               |  32 ++-
 .../{mailbox.c => scmi_transport_mailbox.c}   |  72 +++----
 .../{optee.c => scmi_transport_optee.c}       | 130 ++++++-------
 .../arm_scmi/{smc.c => scmi_transport_smc.c}  |  57 +++---
 .../{virtio.c => scmi_transport_virtio.c}     | 102 +++++-----
 drivers/firmware/arm_scmi/shmem.c             |  85 ++++++--
 10 files changed, 477 insertions(+), 356 deletions(-)
 rename drivers/firmware/arm_scmi/{mailbox.c => scmi_transport_mailbox.c} (86%)
 rename drivers/firmware/arm_scmi/{optee.c => scmi_transport_optee.c} (89%)
 rename drivers/firmware/arm_scmi/{smc.c => scmi_transport_smc.c} (87%)
 rename drivers/firmware/arm_scmi/{virtio.c => scmi_transport_virtio.c} (94%)

Comments

Peng Fan July 31, 2024, 1:12 p.m. UTC | #1
> Subject: [PATCH v3 0/9] Make SCMI transport as standalone drivers
> 
> Hi all,
> 
> Till now the SCMI transport layer was being built embedded into in the
> core SCMI stack.
> 
> Some of these transports, despite being currently part of the main
> SCMI module, are indeed also registered with different subsystems like
> optee or virtio, and actively probed also by those: this led to a few
> awkward and convoluted tricks to properly handle such interactions at
> boot time in the SCMI stack.
> 
> Moreover some partner expressed the desire to be able to fully
> modularize the transports components.
> 
> This series aim to make all such transports as standalone drivers that
> can be optionally loaded as modules.
> 
> In order to do this, at first some new mechanism is introduced to
> support this new capability while maintaining, in parallel, the old
> legacy embedded transports; then each transport, one by one, is
> transitioned to be a standalone driver and finally the old legacy
> support for embedded transport is removed.
> 
> Patch [1/9] is a fix around the chan_free method for OPTEE transport; it
> is really unrelated to this series, but included to avoid conflicts.
> 
> Patch [2/9] is a mostly unrelated (but much needed) clean-up from
> Peng, which I included in this series to avoid conflicts at merge.
> 
> Patch [3/9] simply collects the existing datagram manipulation helpers
> in a pair of function pointers structures, in preparation for later reworks.
> 
> Patch [4/9] adds the bulk of the new logic to the core SCMI stack and
> then each existing transport is transitioned to be a standalone driver in
> patches 5,6,7,8 while shuffling around the compatibles. (no DT change
> is needed of curse for backward compatibility) While doing this I kept
> the module authorship in line with the main
> author(S) as spitted out by git-blame.
> 
> Finally patch [9/9] removes all the legacy dead code from the core
> SCMI stack.
> 
> No new symbol EXPORT has been added.
> 
> The new transport drivers have been tested, as built-in and LKM, as
> follows:
> 
> - mailbox on JUNO
> - virtio on emulation
> - optee on QEMU/optee using Linaro setup
> 
> Exercised using the regular SCMI drivers stack and the SCMI ACS suite,
> testing commands, replies, delayed responses and notification.
> 
> Multiple virtual SCMI instances support has been tested too.
> 
> SMC has NOT been tested/exercised at run-time, only compile-tested.
> (due to lack of hardware)
> 
> Note that in this new setup, all the probe deferral and retries between
> the SCMI core stack and the transports has been removed, since no
> more needed.
> 
> Moreover the new drivers have been tested also with a fully
> modularized SCMI stack, i.e.:
> 
>   scmi-core.ko + scmi-module.ko + scmi_transport_*.ko [ + vendor
> modules ]
> 
> Based on v6.11-rc1
> 
> Any feedback, and especially testing (:D) is welcome.

For the patchset,
Tested-by: Peng Fan <peng.fan@nxp.com>  #i.MX95 19x19 EVK

Regards,
Peng.
> 
> Thanks,
> Cristian
> 
> ---
> v2 --> v3
> - rebased on v6.11-rc1
> - fixed spacing in Kconfig
> - fixed Copyrights all over
> - fixed platform_driver_register callsite in OPTEE transport
> - refactored DEFINE_SCMI_TRANSPORT_DRIVER() to:
>   + use alloc + add_data + add platform drivers methods so as to
> implictly
>     use a standard default device_release method.
>   + drop .remove method in favour of devres_add_action_or_reset
>   + use explicit parameter passing (no more concatenation)
> - renamed scmi_transport_lookup() to scmi_transport_setup()
> - use IOMEM_ERR_PTR to avoid sparse issues
> 
> v1 --> v2
> - fixed setup_shmem_iomap to address also SMC needs (QC/nikunj)
>   (silencing also warnings by kernel test robot <lkp@intel.com>)
> - using __free OF cleanup.h magic in setup_shmme_iomap
> - properly handle platform_driver_register() failures (Dan)
> - fixed a few commit message style
> - added a few missing static in scmi_desc
>   (addresses warnings by kernel test robot <lkp@intel.com>)
> 
> 
> Cristian Marussi (8):
>   firmware: arm_scmi: Fix double free in OPTEE transport
>   firmware: arm_scmi: Introduce packet handling helpers
>   firmware: arm_scmi: Add support for standalone transport drivers
>   firmware: arm_scmi: Make MBOX transport a standalone driver
>   firmware: arm_scmi: Make SMC transport a standalone driver
>   firmware: arm_scmi: Make OPTEE transport a standalone driver
>   firmware: arm_scmi: Make VirtIO transport a standalone driver
>   firmware: arm_scmi: Remove legacy transport-layer code
> 
> Peng Fan (1):
>   firmware: arm_scmi: Introduce setup_shmem_iomap
> 
>  drivers/firmware/arm_scmi/Kconfig             |  20 +-
>  drivers/firmware/arm_scmi/Makefile            |   9 +-
>  drivers/firmware/arm_scmi/common.h            | 184 +++++++++++++----
> -
>  drivers/firmware/arm_scmi/driver.c            | 142 +++++---------
>  drivers/firmware/arm_scmi/msg.c               |  32 ++-
>  .../{mailbox.c => scmi_transport_mailbox.c}   |  72 +++----
>  .../{optee.c => scmi_transport_optee.c}       | 130 ++++++-------
>  .../arm_scmi/{smc.c => scmi_transport_smc.c}  |  57 +++---
>  .../{virtio.c => scmi_transport_virtio.c}     | 102 +++++-----
>  drivers/firmware/arm_scmi/shmem.c             |  85 ++++++--
>  10 files changed, 477 insertions(+), 356 deletions(-)  rename
> drivers/firmware/arm_scmi/{mailbox.c => scmi_transport_mailbox.c}
> (86%)  rename drivers/firmware/arm_scmi/{optee.c =>
> scmi_transport_optee.c} (89%)  rename
> drivers/firmware/arm_scmi/{smc.c => scmi_transport_smc.c} (87%)
> rename drivers/firmware/arm_scmi/{virtio.c => scmi_transport_virtio.c}
> (94%)
> 
> --
> 2.45.2
>
Nikunj Kela Aug. 1, 2024, 6:41 p.m. UTC | #2
On 7/30/2024 6:33 AM, Cristian Marussi wrote:
> Hi all,
>
> Till now the SCMI transport layer was being built embedded into in the core
> SCMI stack.
>
> Some of these transports, despite being currently part of the main SCMI
> module, are indeed also registered with different subsystems like optee or
> virtio, and actively probed also by those: this led to a few awkward and
> convoluted tricks to properly handle such interactions at boot time in the
> SCMI stack.
>
> Moreover some partner expressed the desire to be able to fully modularize
> the transports components.
>
> This series aim to make all such transports as standalone drivers that can
> be optionally loaded as modules.
>
> In order to do this, at first some new mechanism is introduced to support
> this new capability while maintaining, in parallel, the old legacy embedded
> transports; then each transport, one by one, is transitioned to be a
> standalone driver and finally the old legacy support for embedded transport
> is removed.
>
> Patch [1/9] is a fix around the chan_free method for OPTEE transport; it is
> really unrelated to this series, but included to avoid conflicts.
>
> Patch [2/9] is a mostly unrelated (but much needed) clean-up from Peng,
> which I included in this series to avoid conflicts at merge.
>
> Patch [3/9] simply collects the existing datagram manipulation helpers in a
> pair of function pointers structures, in preparation for later reworks.
>
> Patch [4/9] adds the bulk of the new logic to the core SCMI stack and then
> each existing transport is transitioned to be a standalone driver in
> patches 5,6,7,8 while shuffling around the compatibles. (no DT change is
> needed of curse for backward compatibility)
> While doing this I kept the module authorship in line with the main
> author(S) as spitted out by git-blame.
>
> Finally patch [9/9] removes all the legacy dead code from the core SCMI
> stack.
>
> No new symbol EXPORT has been added.
>
> The new transport drivers have been tested, as built-in and LKM, as
> follows:
>
> - mailbox on JUNO
> - virtio on emulation
> - optee on QEMU/optee using Linaro setup
>
> Exercised using the regular SCMI drivers stack and the SCMI ACS suite,
> testing commands, replies, delayed responses and notification.
>
> Multiple virtual SCMI instances support has been tested too.
>
> SMC has NOT been tested/exercised at run-time, only compile-tested.
> (due to lack of hardware)

Hi Christian,

I have validated this series on Qualcomm SA8255p(to be upstreamed) Ride
platform that uses Qualcomm SMC transport for SCMI.

Thanks,

-Nikunj

> Note that in this new setup, all the probe deferral and retries between the
> SCMI core stack and the transports has been removed, since no more needed.
>
> Moreover the new drivers have been tested also with a fully modularized
> SCMI stack, i.e.:
>
>   scmi-core.ko + scmi-module.ko + scmi_transport_*.ko [ + vendor modules ]
>
> Based on v6.11-rc1
>
> Any feedback, and especially testing (:D) is welcome.
>
> Thanks,
> Cristian
>
> ---
> v2 --> v3
> - rebased on v6.11-rc1
> - fixed spacing in Kconfig
> - fixed Copyrights all over
> - fixed platform_driver_register callsite in OPTEE transport
> - refactored DEFINE_SCMI_TRANSPORT_DRIVER() to:
>   + use alloc + add_data + add platform drivers methods so as to implictly
>     use a standard default device_release method.
>   + drop .remove method in favour of devres_add_action_or_reset
>   + use explicit parameter passing (no more concatenation)
> - renamed scmi_transport_lookup() to scmi_transport_setup()
> - use IOMEM_ERR_PTR to avoid sparse issues
>
> v1 --> v2
> - fixed setup_shmem_iomap to address also SMC needs (QC/nikunj)
>   (silencing also warnings by kernel test robot <lkp@intel.com>)
> - using __free OF cleanup.h magic in setup_shmme_iomap
> - properly handle platform_driver_register() failures (Dan)
> - fixed a few commit message style
> - added a few missing static in scmi_desc
>   (addresses warnings by kernel test robot <lkp@intel.com>)
>
>
> Cristian Marussi (8):
>   firmware: arm_scmi: Fix double free in OPTEE transport
>   firmware: arm_scmi: Introduce packet handling helpers
>   firmware: arm_scmi: Add support for standalone transport drivers
>   firmware: arm_scmi: Make MBOX transport a standalone driver
>   firmware: arm_scmi: Make SMC transport a standalone driver
>   firmware: arm_scmi: Make OPTEE transport a standalone driver
>   firmware: arm_scmi: Make VirtIO transport a standalone driver
>   firmware: arm_scmi: Remove legacy transport-layer code
>
> Peng Fan (1):
>   firmware: arm_scmi: Introduce setup_shmem_iomap
>
>  drivers/firmware/arm_scmi/Kconfig             |  20 +-
>  drivers/firmware/arm_scmi/Makefile            |   9 +-
>  drivers/firmware/arm_scmi/common.h            | 184 +++++++++++++-----
>  drivers/firmware/arm_scmi/driver.c            | 142 +++++---------
>  drivers/firmware/arm_scmi/msg.c               |  32 ++-
>  .../{mailbox.c => scmi_transport_mailbox.c}   |  72 +++----
>  .../{optee.c => scmi_transport_optee.c}       | 130 ++++++-------
>  .../arm_scmi/{smc.c => scmi_transport_smc.c}  |  57 +++---
>  .../{virtio.c => scmi_transport_virtio.c}     | 102 +++++-----
>  drivers/firmware/arm_scmi/shmem.c             |  85 ++++++--
>  10 files changed, 477 insertions(+), 356 deletions(-)
>  rename drivers/firmware/arm_scmi/{mailbox.c => scmi_transport_mailbox.c} (86%)
>  rename drivers/firmware/arm_scmi/{optee.c => scmi_transport_optee.c} (89%)
>  rename drivers/firmware/arm_scmi/{smc.c => scmi_transport_smc.c} (87%)
>  rename drivers/firmware/arm_scmi/{virtio.c => scmi_transport_virtio.c} (94%)
>
Florian Fainelli Aug. 6, 2024, 4:47 p.m. UTC | #3
On 7/30/24 06:33, Cristian Marussi wrote:
> Hi all,
> 
> Till now the SCMI transport layer was being built embedded into in the core
> SCMI stack.
> 
> Some of these transports, despite being currently part of the main SCMI
> module, are indeed also registered with different subsystems like optee or
> virtio, and actively probed also by those: this led to a few awkward and
> convoluted tricks to properly handle such interactions at boot time in the
> SCMI stack.
> 
> Moreover some partner expressed the desire to be able to fully modularize
> the transports components.
> 
> This series aim to make all such transports as standalone drivers that can
> be optionally loaded as modules.
> 
> In order to do this, at first some new mechanism is introduced to support
> this new capability while maintaining, in parallel, the old legacy embedded
> transports; then each transport, one by one, is transitioned to be a
> standalone driver and finally the old legacy support for embedded transport
> is removed.
> 
> Patch [1/9] is a fix around the chan_free method for OPTEE transport; it is
> really unrelated to this series, but included to avoid conflicts.
> 
> Patch [2/9] is a mostly unrelated (but much needed) clean-up from Peng,
> which I included in this series to avoid conflicts at merge.
> 
> Patch [3/9] simply collects the existing datagram manipulation helpers in a
> pair of function pointers structures, in preparation for later reworks.
> 
> Patch [4/9] adds the bulk of the new logic to the core SCMI stack and then
> each existing transport is transitioned to be a standalone driver in
> patches 5,6,7,8 while shuffling around the compatibles. (no DT change is
> needed of curse for backward compatibility)
> While doing this I kept the module authorship in line with the main
> author(S) as spitted out by git-blame.
> 
> Finally patch [9/9] removes all the legacy dead code from the core SCMI
> stack.
> 
> No new symbol EXPORT has been added.
> 
> The new transport drivers have been tested, as built-in and LKM, as
> follows:
> 
> - mailbox on JUNO
> - virtio on emulation
> - optee on QEMU/optee using Linaro setup
> 
> Exercised using the regular SCMI drivers stack and the SCMI ACS suite,
> testing commands, replies, delayed responses and notification.
> 
> Multiple virtual SCMI instances support has been tested too.
> 
> SMC has NOT been tested/exercised at run-time, only compile-tested.
> (due to lack of hardware)
> 
> Note that in this new setup, all the probe deferral and retries between the
> SCMI core stack and the transports has been removed, since no more needed.
> 
> Moreover the new drivers have been tested also with a fully modularized
> SCMI stack, i.e.:
> 
>    scmi-core.ko + scmi-module.ko + scmi_transport_*.ko [ + vendor modules ]
> 
> Based on v6.11-rc1
> 
> Any feedback, and especially testing (:D) is welcome.

Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Cristian Marussi Aug. 6, 2024, 5:01 p.m. UTC | #4
On Tue, Aug 06, 2024 at 09:47:17AM -0700, Florian Fainelli wrote:
> On 7/30/24 06:33, Cristian Marussi wrote:
> > Hi all,
> > 
> > Till now the SCMI transport layer was being built embedded into in the core
> > SCMI stack.
> > 
> > Some of these transports, despite being currently part of the main SCMI
> > module, are indeed also registered with different subsystems like optee or
> > virtio, and actively probed also by those: this led to a few awkward and
> > convoluted tricks to properly handle such interactions at boot time in the
> > SCMI stack.
> > 
> > Moreover some partner expressed the desire to be able to fully modularize
> > the transports components.
> > 
> > This series aim to make all such transports as standalone drivers that can
> > be optionally loaded as modules.
> > 
> > In order to do this, at first some new mechanism is introduced to support
> > this new capability while maintaining, in parallel, the old legacy embedded
> > transports; then each transport, one by one, is transitioned to be a
> > standalone driver and finally the old legacy support for embedded transport
> > is removed.
> > 
> > Patch [1/9] is a fix around the chan_free method for OPTEE transport; it is
> > really unrelated to this series, but included to avoid conflicts.
> > 
> > Patch [2/9] is a mostly unrelated (but much needed) clean-up from Peng,
> > which I included in this series to avoid conflicts at merge.
> > 
> > Patch [3/9] simply collects the existing datagram manipulation helpers in a
> > pair of function pointers structures, in preparation for later reworks.
> > 
> > Patch [4/9] adds the bulk of the new logic to the core SCMI stack and then
> > each existing transport is transitioned to be a standalone driver in
> > patches 5,6,7,8 while shuffling around the compatibles. (no DT change is
> > needed of curse for backward compatibility)
> > While doing this I kept the module authorship in line with the main
> > author(S) as spitted out by git-blame.
> > 
> > Finally patch [9/9] removes all the legacy dead code from the core SCMI
> > stack.
> > 
> > No new symbol EXPORT has been added.
> > 
> > The new transport drivers have been tested, as built-in and LKM, as
> > follows:
> > 
> > - mailbox on JUNO
> > - virtio on emulation
> > - optee on QEMU/optee using Linaro setup
> > 
> > Exercised using the regular SCMI drivers stack and the SCMI ACS suite,
> > testing commands, replies, delayed responses and notification.
> > 
> > Multiple virtual SCMI instances support has been tested too.
> > 
> > SMC has NOT been tested/exercised at run-time, only compile-tested.
> > (due to lack of hardware)
> > 
> > Note that in this new setup, all the probe deferral and retries between the
> > SCMI core stack and the transports has been removed, since no more needed.
> > 
> > Moreover the new drivers have been tested also with a fully modularized
> > SCMI stack, i.e.:
> > 
> >    scmi-core.ko + scmi-module.ko + scmi_transport_*.ko [ + vendor modules ]
> > 
> > Based on v6.11-rc1
> > 
> > Any feedback, and especially testing (:D) is welcome.
> 
> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>

Thanks !
Cristian