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 v4 0/37] SCMI vendor protocols and modularization Date: Wed, 6 Jan 2021 20:15:33 +0000 [thread overview] Message-ID: <20210106201610.26538-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_ops() / handle->devm_put_ops() / 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 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_ops), while de-initialization is performed once the last user of the protocol (even in terms of notifications) 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. Patch [4/37] ("firmware: arm_scmi: introduce bare get/put protocols ops") is marked as RFC because I was not sure if this non devres methods are really needed (probbaly not). 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. Note that in v4 all the related SCMI drivers maintainers are still NOT CC'ed given I am still sort of gather consensus about the interface itself. 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 (including all the standard protocols in scmi-module.ko in that 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 6054d97ab512 MAINTAINERS: Update ARM SCMI entry Any feedback welcome. Thanks, Cristian --- 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_V4/ [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 [RFC] firmware: arm_scmi: introduce bare get/put protocols ops 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 | 780 +++++++++++++++++++-- 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 | 39 +- drivers/reset/reset-scmi.c | 33 +- include/linux/scmi_protocol.h | 191 ++--- 20 files changed, 2024 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 v4 0/37] SCMI vendor protocols and modularization Date: Wed, 6 Jan 2021 20:15:33 +0000 [thread overview] Message-ID: <20210106201610.26538-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_ops() / handle->devm_put_ops() / 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 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_ops), while de-initialization is performed once the last user of the protocol (even in terms of notifications) 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. Patch [4/37] ("firmware: arm_scmi: introduce bare get/put protocols ops") is marked as RFC because I was not sure if this non devres methods are really needed (probbaly not). 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. Note that in v4 all the related SCMI drivers maintainers are still NOT CC'ed given I am still sort of gather consensus about the interface itself. 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 (including all the standard protocols in scmi-module.ko in that 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 6054d97ab512 MAINTAINERS: Update ARM SCMI entry Any feedback welcome. Thanks, Cristian --- 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_V4/ [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 [RFC] firmware: arm_scmi: introduce bare get/put protocols ops 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 | 780 +++++++++++++++++++-- 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 | 39 +- drivers/reset/reset-scmi.c | 33 +- include/linux/scmi_protocol.h | 191 ++--- 20 files changed, 2024 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
next reply other threads:[~2021-01-06 20:17 UTC|newest] Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-06 20:15 Cristian Marussi [this message] 2021-01-06 20:15 ` [PATCH v4 0/37] SCMI vendor protocols and modularization Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 01/37] firmware: arm_scmi: review protocol registration interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 02/37] firmware: arm_scmi: introduce protocol handle definitions Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-07 14:29 ` Thara Gopinath 2021-01-07 14:29 ` Thara Gopinath 2021-01-08 12:04 ` Cristian Marussi 2021-01-08 12:04 ` Cristian Marussi 2021-01-08 15:50 ` Thara Gopinath 2021-01-08 15:50 ` Thara Gopinath 2021-01-06 20:15 ` [PATCH v4 03/37] firmware: arm_scmi: introduce devres get/put protocols operations Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-07 14:28 ` Thara Gopinath 2021-01-07 14:28 ` Thara Gopinath 2021-01-08 12:24 ` Cristian Marussi 2021-01-08 12:24 ` Cristian Marussi 2021-01-08 13:42 ` Etienne Carriere 2021-01-08 13:42 ` Etienne Carriere 2021-01-08 16:42 ` Cristian Marussi 2021-01-08 16:42 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 04/37] [RFC] firmware: arm_scmi: introduce bare get/put protocols ops Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-07 14:30 ` Thara Gopinath 2021-01-07 14:30 ` Thara Gopinath 2021-01-06 20:15 ` [PATCH v4 05/37] firmware: arm_scmi: make notifications aware of protocols users Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 06/37] firmware: arm_scmi: introduce new devres notification ops Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 07/37] firmware: arm_scmi: refactor events registration Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 08/37] firmware: arm_scmi: convert events registration to protocol handles Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 09/37] firmware: arm_scmi: add new protocol handle core xfer ops Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 10/37] firmware: arm_scmi: add helper to access revision area memory Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 11/37] firmware: arm_scmi: port Base protocol to new interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 12/37] firmware: arm_scmi: port Perf protocol to new protocols interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 13/37] cpufreq: scmi: port driver to the new scmi_perf_proto_ops interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 14/37] firmware: arm_scmi: remove legacy scmi_perf_ops protocol interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 15/37] firmware: arm_scmi: port Power protocol to new protocols interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 16/37] firmware: arm_scmi: port GenPD driver to the new scmi_power_proto_ops interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 17/37] firmware: arm_scmi: remove legacy scmi_power_ops protocol interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 18/37] firmware: arm_scmi: port Clock protocol to new protocols interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 19/37] clk: scmi: port driver to the new scmi_clk_proto_ops interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 20/37] firmware: arm_scmi: remove legacy scmi_clk_ops protocol interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 21/37] firmware: arm_scmi: port Reset protocol to new protocols interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 22/37] reset: reset-scmi: port driver to the new scmi_reset_proto_ops interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 23/37] firmware: arm_scmi: remove legacy scmi_reset_ops protocol interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 24/37] firmware: arm_scmi: port Sensor protocol to new protocols interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 25/37] hwmon: (scmi) port driver to the new scmi_sensor_proto_ops interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:15 ` [PATCH v4 26/37] firmware: arm_scmi: remove legacy scmi_sensor_ops protocol interface Cristian Marussi 2021-01-06 20:15 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 27/37] firmware: arm_scmi: port SystemPower protocol to new protocols interface Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 28/37] firmware: arm_scmi: port Voltage " Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 29/37] regulator: scmi: port driver to the new scmi_voltage_proto_ops interface Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 30/37] firmware: arm_scmi: remove legacy scmi_voltage_ops protocol interface Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 31/37] firmware: arm_scmi: make references to handle const Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 32/37] firmware: arm_scmi: cleanup legacy protocol init code Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 33/37] firmware: arm_scmi: cleanup unused core xfer wrappers Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 34/37] firmware: arm_scmi: cleanup events registration transient code Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 35/37] firmware: arm_scmi: make notify_priv really private Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 36/37] firmware: arm_scmi: add protocol modularization support Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-06 20:16 ` [PATCH v4 37/37] firmware: arm_scmi: add dynamic scmi devices creation Cristian Marussi 2021-01-06 20:16 ` Cristian Marussi 2021-01-07 14:28 ` Thara Gopinath 2021-01-07 14:28 ` Thara Gopinath 2021-01-08 14:42 ` Cristian Marussi 2021-01-08 14:42 ` Cristian Marussi 2021-01-08 16:32 ` Thara Gopinath 2021-01-08 16:32 ` Thara Gopinath 2021-01-08 16:52 ` Cristian Marussi 2021-01-08 16:52 ` 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=20210106201610.26538-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: linkBe 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.