All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: sudeep.holla@arm.com, lukasz.luba@arm.com,
	james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com,
	f.fainelli@gmail.com, etienne.carriere@linaro.org,
	thara.gopinath@linaro.org, vincent.guittot@linaro.org,
	souvik.chakravarty@arm.com, cristian.marussi@arm.com
Subject: [PATCH v6 0/37] SCMI vendor protocols and modularization
Date: Tue,  2 Feb 2021 22:15:18 +0000	[thread overview]
Message-ID: <20210202221555.41167-1-cristian.marussi@arm.com> (raw)

Hi all,

The current SCMI implementation does not provide an interface to easily
develop and include a custom vendor protocol implementation as prescribed
by the SCMI standard, also because, there is not currently any custom
protocol in the upstream to justify the development of a custom interface
and its maintenance.

Moreover the current interface exposes protocol operations to the SCMI
driver users attaching per-protocol operations directly to the handle
structure, which, in this way, tends to grow indefinitely for each new
protocol addition.

Beside this, protocols private data are also exposed via handle *_priv
pointers, making such private data accessible also to the SCMI drivers
even if neither really needed nor advisable.

This series wants to address this by simplifying the SCMI protocols
interface and reducing it, roughly, to these common generic operations:

	- handle->devm_get_protocol()
	- handle->devm_put_protocol()
	- handle->notify_ops->*

All protocols' private data pointers are removed from handle too and made
accessible only to the protocols code through dedicated internal helpers.

The concept of protocol handle is also introduced in the SCMI protocol code
to represent a protocol instance initialized against a specific SCMI
instance (handle), so that all the new protocol code uses such protocol
handles wherever previously SCMI handle was used: this enable tighter
control of what is exposed to the protocol code vs the SCMI drivers.

Moreover protocol initialization is moved away from device probe and now
happens on demand when the first user shows up (first .get_protocol), while
de-initialization is performed once the last user of the protocol, even in
terms of registered notifications callback, is gone, with the SCMI core
taking care to perform all the needed underlying resource accounting.

This way any new future standard or custom protocol implementation will
expose a common unified interface which does not need to be extended
endlessly: no need to maintain a custom interface only for vendor protos.
SCMI drivers written on top of standard or custom protocols will use this
same common interface to access any protocol operations.

All existent upstream SCMI drivers are converted to this new interface.

In order to make this migration painless and to avoid the need of a big
un-mergeable jumbo patch touching all over the protocols and drivers (like
it was in v2), since v3 the migration process has been heavily split with a
bit of transient code added along the way (to preserve bisectability) and
finally removed towards the ends of the series.
Protocols and SCMI drivers migration to the new interface happens along
patches 11->30.

Leveraging this new centralized and common initialization flow we took
care also to refactor and simplify protocol-events registration and remove
*notify_priv from the handle interface making it accessible only to the
notification core.

Patch 36 builds on top of this new interface and introduces a mechanism to
define an SCMI protocol as a full blown module (possibly loadable) while
leaving the core dealing with proper resource accounting.
Standard protocols are still kept as builtins in this series, though.

Finally, patch 37 introduces dynamic SCMI devices creation to avoid having
to update the static module device table in the core each time a new driver
is added.

The whole SCMI stack can still be built alternatively as a module, with all
the standard protocols included in scmi-module.ko in such a case.

On top of this series an example SCMI Custom protocol 0x99 and related
SCMI Custom Dummy driver has been built and it is available at [1] as a
series of DEBUG patches on top this same series.

The series is currently based on for-next/scmi [2] on top of:

commit f620d93957ca ("firmware: arm_scmi: Fix call site of
		      scmi_notification_exit")

Any feedback welcome.

Thanks,

Cristian

---
v5 --> v6
- rebased on top of for-next/scmi
- added devm_acquire_protocol() helper
- added Cc:

v4 --> v5
- using standard kernel list instead of ad-hoc lists in 36/36
- renamed devm_get/put_ops to devm_get/put_protocol
- dropped RFC patch on non devres get/put_ops

v3 --> v4
- rebased on sudeep/for-next/scmi v5.11-rc1
- added a few comments more

v2 --> v3
- added dynamic SCMI devices creation (getting rid of static device table)
- heavy split of protocols and drivers migrations to the new interface
- rebased on top of next-20201201 so migrating also:
  + SCMIv3.0 Voltage Domain protocol & SCMI Regulator
  + SCMIv3.0 Sensor Extensions

v1 --> v2
- rebased on for-next/scmi v5.10-rc1
- introduced protocol handles
- added devres managed devm_ variant for protocols operations
- made all scmi_protocol refs const
- introduced IDR to handle protocols instead of static array
- refactored code around fast path

[1]:https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_modules_ext_V6/
[2]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi


Cristian Marussi (37):
  firmware: arm_scmi: review protocol registration interface
  firmware: arm_scmi: introduce protocol handle definitions
  firmware: arm_scmi: introduce devres get/put protocols operations
  firmware: arm_scmi: add devm_acquire_protocol helper
  firmware: arm_scmi: make notifications aware of protocols users
  firmware: arm_scmi: introduce new devres notification ops
  firmware: arm_scmi: refactor events registration
  firmware: arm_scmi: convert events registration to protocol handles
  firmware: arm_scmi: add new protocol handle core xfer ops
  firmware: arm_scmi: add helper to access revision area memory
  firmware: arm_scmi: port Base protocol to new interface
  firmware: arm_scmi: port Perf protocol to new protocols interface
  cpufreq: scmi: port driver to the new scmi_perf_proto_ops interface
  firmware: arm_scmi: remove legacy scmi_perf_ops protocol interface
  firmware: arm_scmi: port Power protocol to new protocols interface
  firmware: arm_scmi: port GenPD driver to the new scmi_power_proto_ops
    interface
  firmware: arm_scmi: remove legacy scmi_power_ops protocol interface
  firmware: arm_scmi: port Clock protocol to new protocols interface
  clk: scmi: port driver to the new scmi_clk_proto_ops interface
  firmware: arm_scmi: remove legacy scmi_clk_ops protocol interface
  firmware: arm_scmi: port Reset protocol to new protocols interface
  reset: reset-scmi: port driver to the new scmi_reset_proto_ops
    interface
  firmware: arm_scmi: remove legacy scmi_reset_ops protocol interface
  firmware: arm_scmi: port Sensor protocol to new protocols interface
  hwmon: (scmi) port driver to the new scmi_sensor_proto_ops interface
  firmware: arm_scmi: remove legacy scmi_sensor_ops protocol interface
  firmware: arm_scmi: port SystemPower protocol to new protocols
    interface
  firmware: arm_scmi: port Voltage protocol to new protocols interface
  regulator: scmi: port driver to the new scmi_voltage_proto_ops
    interface
  firmware: arm_scmi: remove legacy scmi_voltage_ops protocol interface
  firmware: arm_scmi: make references to handle const
  firmware: arm_scmi: cleanup legacy protocol init code
  firmware: arm_scmi: cleanup unused core xfer wrappers
  firmware: arm_scmi: cleanup events registration transient code
  firmware: arm_scmi: make notify_priv really private
  firmware: arm_scmi: add protocol modularization support
  firmware: arm_scmi: add dynamic scmi devices creation

 drivers/clk/clk-scmi.c                     |  27 +-
 drivers/cpufreq/scmi-cpufreq.c             |  37 +-
 drivers/firmware/arm_scmi/base.c           | 140 ++--
 drivers/firmware/arm_scmi/bus.c            | 100 ++-
 drivers/firmware/arm_scmi/clock.c          | 129 ++--
 drivers/firmware/arm_scmi/common.h         | 117 ++-
 drivers/firmware/arm_scmi/driver.c         | 799 +++++++++++++++++++--
 drivers/firmware/arm_scmi/notify.c         | 297 ++++++--
 drivers/firmware/arm_scmi/notify.h         |  38 +-
 drivers/firmware/arm_scmi/perf.c           | 262 +++----
 drivers/firmware/arm_scmi/power.c          | 134 ++--
 drivers/firmware/arm_scmi/reset.c          | 146 ++--
 drivers/firmware/arm_scmi/scmi_pm_domain.c |  26 +-
 drivers/firmware/arm_scmi/sensors.c        | 230 +++---
 drivers/firmware/arm_scmi/system.c         |  61 +-
 drivers/firmware/arm_scmi/voltage.c        | 122 ++--
 drivers/hwmon/scmi-hwmon.c                 |  24 +-
 drivers/regulator/scmi-regulator.c         |  40 +-
 drivers/reset/reset-scmi.c                 |  33 +-
 include/linux/scmi_protocol.h              | 191 ++---
 20 files changed, 2044 insertions(+), 909 deletions(-)

-- 
2.17.1


WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: f.fainelli@gmail.com, vincent.guittot@linaro.org,
	sudeep.holla@arm.com, thara.gopinath@linaro.org,
	cristian.marussi@arm.com, james.quinlan@broadcom.com,
	Jonathan.Cameron@Huawei.com, souvik.chakravarty@arm.com,
	etienne.carriere@linaro.org, lukasz.luba@arm.com
Subject: [PATCH v6 0/37] SCMI vendor protocols and modularization
Date: Tue,  2 Feb 2021 22:15:18 +0000	[thread overview]
Message-ID: <20210202221555.41167-1-cristian.marussi@arm.com> (raw)

Hi all,

The current SCMI implementation does not provide an interface to easily
develop and include a custom vendor protocol implementation as prescribed
by the SCMI standard, also because, there is not currently any custom
protocol in the upstream to justify the development of a custom interface
and its maintenance.

Moreover the current interface exposes protocol operations to the SCMI
driver users attaching per-protocol operations directly to the handle
structure, which, in this way, tends to grow indefinitely for each new
protocol addition.

Beside this, protocols private data are also exposed via handle *_priv
pointers, making such private data accessible also to the SCMI drivers
even if neither really needed nor advisable.

This series wants to address this by simplifying the SCMI protocols
interface and reducing it, roughly, to these common generic operations:

	- handle->devm_get_protocol()
	- handle->devm_put_protocol()
	- handle->notify_ops->*

All protocols' private data pointers are removed from handle too and made
accessible only to the protocols code through dedicated internal helpers.

The concept of protocol handle is also introduced in the SCMI protocol code
to represent a protocol instance initialized against a specific SCMI
instance (handle), so that all the new protocol code uses such protocol
handles wherever previously SCMI handle was used: this enable tighter
control of what is exposed to the protocol code vs the SCMI drivers.

Moreover protocol initialization is moved away from device probe and now
happens on demand when the first user shows up (first .get_protocol), while
de-initialization is performed once the last user of the protocol, even in
terms of registered notifications callback, is gone, with the SCMI core
taking care to perform all the needed underlying resource accounting.

This way any new future standard or custom protocol implementation will
expose a common unified interface which does not need to be extended
endlessly: no need to maintain a custom interface only for vendor protos.
SCMI drivers written on top of standard or custom protocols will use this
same common interface to access any protocol operations.

All existent upstream SCMI drivers are converted to this new interface.

In order to make this migration painless and to avoid the need of a big
un-mergeable jumbo patch touching all over the protocols and drivers (like
it was in v2), since v3 the migration process has been heavily split with a
bit of transient code added along the way (to preserve bisectability) and
finally removed towards the ends of the series.
Protocols and SCMI drivers migration to the new interface happens along
patches 11->30.

Leveraging this new centralized and common initialization flow we took
care also to refactor and simplify protocol-events registration and remove
*notify_priv from the handle interface making it accessible only to the
notification core.

Patch 36 builds on top of this new interface and introduces a mechanism to
define an SCMI protocol as a full blown module (possibly loadable) while
leaving the core dealing with proper resource accounting.
Standard protocols are still kept as builtins in this series, though.

Finally, patch 37 introduces dynamic SCMI devices creation to avoid having
to update the static module device table in the core each time a new driver
is added.

The whole SCMI stack can still be built alternatively as a module, with all
the standard protocols included in scmi-module.ko in such a case.

On top of this series an example SCMI Custom protocol 0x99 and related
SCMI Custom Dummy driver has been built and it is available at [1] as a
series of DEBUG patches on top this same series.

The series is currently based on for-next/scmi [2] on top of:

commit f620d93957ca ("firmware: arm_scmi: Fix call site of
		      scmi_notification_exit")

Any feedback welcome.

Thanks,

Cristian

---
v5 --> v6
- rebased on top of for-next/scmi
- added devm_acquire_protocol() helper
- added Cc:

v4 --> v5
- using standard kernel list instead of ad-hoc lists in 36/36
- renamed devm_get/put_ops to devm_get/put_protocol
- dropped RFC patch on non devres get/put_ops

v3 --> v4
- rebased on sudeep/for-next/scmi v5.11-rc1
- added a few comments more

v2 --> v3
- added dynamic SCMI devices creation (getting rid of static device table)
- heavy split of protocols and drivers migrations to the new interface
- rebased on top of next-20201201 so migrating also:
  + SCMIv3.0 Voltage Domain protocol & SCMI Regulator
  + SCMIv3.0 Sensor Extensions

v1 --> v2
- rebased on for-next/scmi v5.10-rc1
- introduced protocol handles
- added devres managed devm_ variant for protocols operations
- made all scmi_protocol refs const
- introduced IDR to handle protocols instead of static array
- refactored code around fast path

[1]:https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_modules_ext_V6/
[2]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi


Cristian Marussi (37):
  firmware: arm_scmi: review protocol registration interface
  firmware: arm_scmi: introduce protocol handle definitions
  firmware: arm_scmi: introduce devres get/put protocols operations
  firmware: arm_scmi: add devm_acquire_protocol helper
  firmware: arm_scmi: make notifications aware of protocols users
  firmware: arm_scmi: introduce new devres notification ops
  firmware: arm_scmi: refactor events registration
  firmware: arm_scmi: convert events registration to protocol handles
  firmware: arm_scmi: add new protocol handle core xfer ops
  firmware: arm_scmi: add helper to access revision area memory
  firmware: arm_scmi: port Base protocol to new interface
  firmware: arm_scmi: port Perf protocol to new protocols interface
  cpufreq: scmi: port driver to the new scmi_perf_proto_ops interface
  firmware: arm_scmi: remove legacy scmi_perf_ops protocol interface
  firmware: arm_scmi: port Power protocol to new protocols interface
  firmware: arm_scmi: port GenPD driver to the new scmi_power_proto_ops
    interface
  firmware: arm_scmi: remove legacy scmi_power_ops protocol interface
  firmware: arm_scmi: port Clock protocol to new protocols interface
  clk: scmi: port driver to the new scmi_clk_proto_ops interface
  firmware: arm_scmi: remove legacy scmi_clk_ops protocol interface
  firmware: arm_scmi: port Reset protocol to new protocols interface
  reset: reset-scmi: port driver to the new scmi_reset_proto_ops
    interface
  firmware: arm_scmi: remove legacy scmi_reset_ops protocol interface
  firmware: arm_scmi: port Sensor protocol to new protocols interface
  hwmon: (scmi) port driver to the new scmi_sensor_proto_ops interface
  firmware: arm_scmi: remove legacy scmi_sensor_ops protocol interface
  firmware: arm_scmi: port SystemPower protocol to new protocols
    interface
  firmware: arm_scmi: port Voltage protocol to new protocols interface
  regulator: scmi: port driver to the new scmi_voltage_proto_ops
    interface
  firmware: arm_scmi: remove legacy scmi_voltage_ops protocol interface
  firmware: arm_scmi: make references to handle const
  firmware: arm_scmi: cleanup legacy protocol init code
  firmware: arm_scmi: cleanup unused core xfer wrappers
  firmware: arm_scmi: cleanup events registration transient code
  firmware: arm_scmi: make notify_priv really private
  firmware: arm_scmi: add protocol modularization support
  firmware: arm_scmi: add dynamic scmi devices creation

 drivers/clk/clk-scmi.c                     |  27 +-
 drivers/cpufreq/scmi-cpufreq.c             |  37 +-
 drivers/firmware/arm_scmi/base.c           | 140 ++--
 drivers/firmware/arm_scmi/bus.c            | 100 ++-
 drivers/firmware/arm_scmi/clock.c          | 129 ++--
 drivers/firmware/arm_scmi/common.h         | 117 ++-
 drivers/firmware/arm_scmi/driver.c         | 799 +++++++++++++++++++--
 drivers/firmware/arm_scmi/notify.c         | 297 ++++++--
 drivers/firmware/arm_scmi/notify.h         |  38 +-
 drivers/firmware/arm_scmi/perf.c           | 262 +++----
 drivers/firmware/arm_scmi/power.c          | 134 ++--
 drivers/firmware/arm_scmi/reset.c          | 146 ++--
 drivers/firmware/arm_scmi/scmi_pm_domain.c |  26 +-
 drivers/firmware/arm_scmi/sensors.c        | 230 +++---
 drivers/firmware/arm_scmi/system.c         |  61 +-
 drivers/firmware/arm_scmi/voltage.c        | 122 ++--
 drivers/hwmon/scmi-hwmon.c                 |  24 +-
 drivers/regulator/scmi-regulator.c         |  40 +-
 drivers/reset/reset-scmi.c                 |  33 +-
 include/linux/scmi_protocol.h              | 191 ++---
 20 files changed, 2044 insertions(+), 909 deletions(-)

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2021-02-02 22:17 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02 22:15 Cristian Marussi [this message]
2021-02-02 22:15 ` [PATCH v6 0/37] SCMI vendor protocols and modularization Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 01/37] firmware: arm_scmi: review protocol registration interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-03-08  4:38   ` Sudeep Holla
2021-03-08  4:38     ` Sudeep Holla
2021-03-08 11:24     ` Cristian Marussi
2021-03-08 11:24       ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 02/37] firmware: arm_scmi: introduce protocol handle definitions Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-03-08  5:50   ` Sudeep Holla
2021-03-08  5:50     ` Sudeep Holla
2021-03-08 11:37     ` Cristian Marussi
2021-03-08 11:37       ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 03/37] firmware: arm_scmi: introduce devres get/put protocols operations Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 04/37] firmware: arm_scmi: add devm_acquire_protocol helper Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 05/37] firmware: arm_scmi: make notifications aware of protocols users Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 06/37] firmware: arm_scmi: introduce new devres notification ops Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 07/37] firmware: arm_scmi: refactor events registration Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 08/37] firmware: arm_scmi: convert events registration to protocol handles Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 09/37] firmware: arm_scmi: add new protocol handle core xfer ops Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 10/37] firmware: arm_scmi: add helper to access revision area memory Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 11/37] firmware: arm_scmi: port Base protocol to new interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 12/37] firmware: arm_scmi: port Perf protocol to new protocols interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 13/37] cpufreq: scmi: port driver to the new scmi_perf_proto_ops interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-03  3:03   ` Viresh Kumar
2021-02-03  3:03     ` Viresh Kumar
2021-02-03 12:10     ` Cristian Marussi
2021-02-03 12:10       ` Cristian Marussi
2021-02-04 11:43       ` Sudeep Holla
2021-02-04 11:43         ` Sudeep Holla
2021-02-04  2:14   ` Viresh Kumar
2021-02-04  2:14     ` Viresh Kumar
2021-02-02 22:15 ` [PATCH v6 14/37] firmware: arm_scmi: remove legacy scmi_perf_ops protocol interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 15/37] firmware: arm_scmi: port Power protocol to new protocols interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 16/37] firmware: arm_scmi: port GenPD driver to the new scmi_power_proto_ops interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 17/37] firmware: arm_scmi: remove legacy scmi_power_ops protocol interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 18/37] firmware: arm_scmi: port Clock protocol to new protocols interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 19/37] clk: scmi: port driver to the new scmi_clk_proto_ops interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-03-10 14:19   ` Cristian Marussi
2021-03-10 14:19     ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 20/37] firmware: arm_scmi: remove legacy scmi_clk_ops protocol interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 21/37] firmware: arm_scmi: port Reset protocol to new protocols interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 22/37] reset: reset-scmi: port driver to the new scmi_reset_proto_ops interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-03-03 14:46   ` Philipp Zabel
2021-03-03 14:46     ` Philipp Zabel
2021-02-02 22:15 ` [PATCH v6 23/37] firmware: arm_scmi: remove legacy scmi_reset_ops protocol interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 24/37] firmware: arm_scmi: port Sensor protocol to new protocols interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 25/37] hwmon: (scmi) port driver to the new scmi_sensor_proto_ops interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-03  1:30   ` Guenter Roeck
2021-02-03  1:30     ` Guenter Roeck
2021-02-02 22:15 ` [PATCH v6 26/37] firmware: arm_scmi: remove legacy scmi_sensor_ops protocol interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 27/37] firmware: arm_scmi: port SystemPower protocol to new protocols interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 28/37] firmware: arm_scmi: port Voltage " Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 29/37] regulator: scmi: port driver to the new scmi_voltage_proto_ops interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-03 13:24   ` Mark Brown
2021-02-03 13:24     ` Mark Brown
2021-02-03 14:39     ` Cristian Marussi
2021-02-03 14:39       ` Cristian Marussi
2021-02-03 16:18   ` Mark Brown
2021-02-03 16:18     ` Mark Brown
2021-02-02 22:15 ` [PATCH v6 30/37] firmware: arm_scmi: remove legacy scmi_voltage_ops protocol interface Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 31/37] firmware: arm_scmi: make references to handle const Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 32/37] firmware: arm_scmi: cleanup legacy protocol init code Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 33/37] firmware: arm_scmi: cleanup unused core xfer wrappers Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 34/37] firmware: arm_scmi: cleanup events registration transient code Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 35/37] firmware: arm_scmi: make notify_priv really private Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-03-08  6:12   ` Sudeep Holla
2021-03-08  6:12     ` Sudeep Holla
2021-03-08 11:39     ` Cristian Marussi
2021-03-08 11:39       ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 36/37] firmware: arm_scmi: add protocol modularization support Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-03-08  7:34   ` Sudeep Holla
2021-03-08  7:34     ` Sudeep Holla
2021-03-09  8:04     ` Cristian Marussi
2021-03-09  8:04       ` Cristian Marussi
2021-02-02 22:15 ` [PATCH v6 37/37] firmware: arm_scmi: add dynamic scmi devices creation Cristian Marussi
2021-02-02 22:15   ` Cristian Marussi
2021-03-15  8:33   ` Sudeep Holla
2021-03-15  8:33     ` Sudeep Holla
2021-03-15  9:03     ` Cristian Marussi
2021-03-15  9:03       ` Cristian Marussi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210202221555.41167-1-cristian.marussi@arm.com \
    --to=cristian.marussi@arm.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=etienne.carriere@linaro.org \
    --cc=f.fainelli@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=souvik.chakravarty@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=thara.gopinath@linaro.org \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.